[x500standard] SV: [Spam] Re: SV: Re: Administrative points
- From: "Erik Andersen" <era@xxxxxxx>
- To: <x500standard@xxxxxxxxxxxxx>, "SG17-Q11" <t09sg17q11@xxxxxxxxxxxxx>
- Date: Sat, 2 Jul 2011 16:32:05 +0200
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?
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.
Other related posts:
