[x500standard] Re: SV: [Spam] Re: SV: Re: Administrative points
- From: Steven Legg <steven.legg@xxxxxxxxxxxxxxxxxx>
- To: x500standard@xxxxxxxxxxxxx
- Date: Mon, 04 Jul 2011 10:14:24 +1000
Hi Erik,
On 3/07/2011 12:32 AM, Erik Andersen wrote:
Hi Steven,
Thanks for your thorough answer.
Yes, for sure, an administrative system can warn the administrator, but
X.501 is not concerned with that, only when administration is performed over
Dap (or LDAP).
What happens if we a autonomous administrative point at {a b c} and we have
a specific administrative point in {a b c d e f g} and a new autonomous
point is added at {a b c d e}, will we then assume that the specific
administrative point now belongs to the new autonomous area?
Yes.
We are talking about a situation (an exceedingly rare one at that) where
the authority controlling the { a b c } subtree is handing control for the
{ a b c d e } subtree to some other authority. It makes operational sense
for the { a b c } authority to hand over a fully functional, self-contained
subtree to the new authority, which can then reorganize it how it likes.
The subtree at { a b c d e f g } isn't a problem because it is already
self-contained and internally consistent. The point at { a b c d e } is the
issue. If we suddenly make it an autonomous point, then we are also making
it a specific point for every aspect of administration. If nothing else is
done, then this cripples the { a b c d e } subtree (apart from the
{ a b c d e f g } subtree, which continues to function as before).
A good administration tool will reconfigure the { a b c d e } entry as
a fully functional specific administrative point (that is, make the
{ a b c d e } subtree self-contained and internally consistent) *before*
making it an autonomous point and relinquishing control. However, I don't
see there is anything that the standard can reasonably do to enforce that
in the protocol. We could insist that a entry can only be made an autonomous
point if it is already a specific point for every aspect of administration,
but that just means that a dumb user and/or dumb administration tool needs
two simple operations instead of one to do something reckless.
A good administration tool will copy over subschema, relevant access
controls and collective attributes to subentries of the autonomous point
to be, but that is also making assumptions about what is going on between
the two authorities. In some cases it may also be appropriate to omit or
modify some of the copied information. In some cases it may be appropriate
to copy nothing and simply clean out the subtree of the autonomous
point to be. In short, there is no single "right thing" to do, so the
standard should not be prescriptive. If you feel something needs to be
done (I don't), then I suggest you just provide some discussion of the
effects of making an entry an autonomous point when it is not already
a specific administration point and recommend a procedure for
administrators and administration tools to follow first (basically what
I said in the first sentence of this paragraph).
The same issues apply when changing non-leaf entries into specific
administration points, which the standard is not prescriptive about.
The only difference is there is no assumed relinquishing of control.
Regards,
Steven
Erik
-----Oprindelig meddelelse-----
Fra: x500standard-bounce@xxxxxxxxxxxxx
[mailto:x500standard-bounce@xxxxxxxxxxxxx] På vegne af Steven Legg
Sendt: 28. juni 2011 08:37
Til: x500standard@xxxxxxxxxxxxx
Cc: Erik Andersen
Emne: [Spam] [x500standard] Re: SV: Re: Administrative points
Erik,
I'm not seeing a big problem here. There is wording throughout X.501
suggesting
that specific administrative areas partition autonomous areas and that
specific areas do not span autonomous points. I take this to mean that
an autonomous point is also a specific administrative point for every
aspect of administration. As a consequence, making an entry within a
specific area an autonomous point automatically truncates the specific area
(and of course the autonomous area within which it is contained), in the
same
way that simply making that entry a specific administrative point for the
same
aspect of administration would do so.
Our DSA generates a constraint error if the administrativeRole attribute
has the autonomousArea value but not the accessControlSpecificArea,
subschemaAdminSpecificArea and collectiveAttributeSpecificArea values.
For backward compatibility, we treat an autonomous point as an implied
specific administration point for other aspects of administration. One
way or another, we don't have specific areas extending beyond the boundaries
of autonomous areas, and that works fine.
On 26/06/2011 5:07 PM, Erik Andersen wrote:
Hi David,
Thanks for your answer.
I believe the question is a little more complicated than indicated in the
original question. There may be many specific administrative areas within
an
autonomous administrative area. Some existing specific administrative
areas
or inner area may be completely contained within a new autonomous
administrative area, etc.
A similar thing can happen when just adding a new specific administration
point.
It may not be a wise thing to do in particular cases, and vendors are free
to build their tools to warn or advise the administrator in those cases or
to
automate the reconfiguration of new specific areas, but I don't see a defect
in the standard, nor the need for extending the protocol.
There is no value is special provisions for autonomous areas when users can
create functionally equivalent, dumb specific area configurations without
using
autonomousArea at all.
> The Directory may not know what the final outcome
should be.
From my perspective the outcome is always well defined, even if dumb.
Possibly, an new update problem code could be defined telling that
proposed
new admin point is in conflict with the current admin area configuration.
There is no conflict if autonomous points are also specific points for every
aspect of administration, like the standard appears to me to be saying.
Regards,
Steven
Also text could be provided to discuss the issue. The administrator would
then have to clean up the current admin area configuration before
establishing a new one.
Regards,
Erik Andersen
Andersen's L-Service
Elsevej 48,
DK-3500 Vaerloese
Denmark
Mobile: +45 2097 1490
e-amail: era@xxxxxxx
Skype: andersen-erik
http://www.x500.eu/
http://www.x500standard.com/
http://dk.linkedin.com/in/andersenerik
-----Oprindelig meddelelse-----
Fra: x500standard-bounce@xxxxxxxxxxxxx
[mailto:x500standard-bounce@xxxxxxxxxxxxx] På vegne af David Chadwick
Sendt: 25. juni 2011 13:08
Til: x500standard@xxxxxxxxxxxxx
Emne: [x500standard] Re: Administrative points
I would say that the GUI gives the user a choice. Warning do you want to
continue and truncate the existing specific area, or do you want to
abandon the operation. This implies a protocol flag saying truncate
existing area, true or false. The GUI sets this to false initially and
sets it to true second time around if the user says go ahead.
regards
David
On 25/06/2011 08:26, Erik Andersen wrote:
Hi implementers and others
I got the following very good question:
Standard defines autonomous area as: starting at AAP entry in the DIT,
and continue downwards until either leaves or other autonomous
administrative points are encountered. But in a case when an autonomous
area contains specific area and we want to add an autonomous entry
within this specific area how should the program respond? Should it
reject adding this autonomous entry into this specific area? Or should
it automatically update specific area by changing it's subtree
specification ?
What is a good answer?
Erik Andersen
Andersen's L-Service
Elsevej 48,
DK-3500 Vaerloese
Denmark
Mobile: +45 2097 1490
e-amail: era@xxxxxxx
Skype: andersen-erik
http://www.x500.eu/
http://www.x500standard.com/
http://dk.linkedin.com/in/andersenerik
-----
www.x500standard.com: The central source for information on the X.500
Directory Standard.
-----
www.x500standard.com: The central source for information on the X.500 Directory
Standard.
-----
www.x500standard.com: The central source for information on the X.500 Directory
Standard.
Other related posts:
