Re: draft-ietf-ldapext-acl-model-04.txt

[Ellen Stokes <stokes@austin.ibm.com>]

The supportedAciMechanisms and aCIMechanism attributes work together.
supportedAciMechanisms says what that directory server supports.
aCIMechanism tells what mechanism is supported in what part(s) of 
the directory tree served by that server.  If you're crossing directory
servers via a naming context (e.g. "a" is on server A and "b" is below
A but on server B), then the aCIMechanism for "b" on B needs to be specified
on B, not inherited from A.
Ellen

At 11:01 PM 10/07/1999 -0600, Natarajan SK wrote:
>On the same vein, why should the aCIMechanism subschema attribute be in
>the subschema entry only if it is different from the one in the parent
>naming context supported by the same directory server.  What should be
>the behaviour if the adjacent naming context is not supported by the
>directory server.  Would the aCIMechanism attribute be available in the
>current naming context or not.  ?
>
>Natarajan
>
>S.K.Natarajan
>Senior Software Engineer
>Novell Software, Bangalore
>E-mail sknatarajan@novell.com
>Ph. no. 91-80-572-1856/58 Extn. 2213
>Fx 91-80-572-1870
>
>
>>>> Ellen Stokes <stokes@austin.ibm.com> 10/07/99 07:16PM >>>
>Response embedded below.
>Ellen
>
>
>At 02:13 AM 10/06/1999 -0600, Natarajan SK wrote:
>>In the draft section 5.2 says,
>>
>>
>>          5.2  Subschema Attribute for Access Control Mechanism
>>
>>             A given naming context must provide information about
>>             which access control mechanism is in effect for that
>>             portion of the namespace.  The following attribute must
>>             be in each subschema entry associated with a naming
>>             context whose access control mechanism is different from
>>             adjacent naming contexts supported by that directory
>>             server.
>>
>>Does this mean that there could be more than one subschema entries
>>associated with the naming context. This clashes with the idea that
>the
>>schema should be common across a naming context. 
>>
>>Or do you mean to say that if the ACIMechanism of a particular naming
>>context is different from that of the adjacent naming contexts, then
>the
>>(single) subschema entry of that naming context should have  the
>>aCIMechanism attribute ? 
>>
>>I guess it is the latter.
>(EJS)  Yes.
>
>>
>>Also the last part of it says 
>>
>>"whose access control mechanism is different from
>>             adjacent naming contexts supported by that directory
>>             server."
>>What is meant by an adjacent naming context? I didn't find the  term
>>anywhere.  I gues you mean to say  the superior which is a naming
>>context and to which this naming context belongs. 
>(EJS)  Yes.
>
>>
>>Natarajan
>>
>>S.K.Natarajan
>>Senior Software Engineer
>>Novell Software, Bangalore
>>E-mail sknatarajan@novell.com 
>>Ph. no. 91-80-572-1856/58 Extn. 2213
>>Fx 91-80-572-1870
>>
>>
>>>>> Ellen Stokes <stokes@austin.ibm.com> 10/06/99 01:52AM >>>
>>ldapext folks, 
>>Attached is the revised internet draft for ldap 
>>access control (already sent to internet-drafts editor
>>to publish). It incorporates all the changes 
>>identified/presented at the July IETF. Comments 
>>to the list (or me personally if you prefer).
>>
>>Mark Wahl/Tim Howes, 
>>Because this spec has settled down much over the last 
>>year, I'd like to see if we can make this one a copy 
>>that can go to workgroup last call real shortly.
>>Ellen
>> 
>