re:draft-ietf-ldapext-acl-model-05

I have a few questions after the first reading:

On page 11:
"..... If the server does not support partial inheritance and both the
entry and subtree scope are used, then entry is the prevailing scope".

What does this mean, especially "partial inheritance"?

< djb > The ldapAci attribute is multivalued. The syntax we have defined
for the attribute value has a property called 'scope'. It is therefore
possile for two ldapAci attributes to have different scopes; one might
contain 'entry' and another might contain 'subtree'.  This implies that
some ldapAci values inherit down the tree, and others do not; partial
inheritance of the ldapAci attribute. This draft is not meant to define the
inheritance model behavior. However, we did want to clarify the expected
behavior of servers which only support inheriting the entire ldapAci
attribute.

On page 22, there is an example of ldamodify - delete syntax.

"Given an ACI of:

           ldapACI: 1.2.3.4#subtree#grant;r,w;
                      collection:[all]#group#cn=Dept XYZ
           ldapACI: 1.2.3.4#subtree#grant;r;
                      attribute:attr1#group#cn=Dept XYZ

            dn: cn = some Entry
            changetype: modify
            delete: ldapACI
            ldapACI: 1.2.3.4#subtree#grant;r;
                       attribute:attr1#group#cn=Dept XYZ

          would yield a remaining ACI on the server of

          ldapACI: 1.2.3.4#subtree#grant;r,w;
                     collection:[all]#group#cn=Dept XYZ"

Given the same ACI, what would the result if the input to modify-delete is:
           ldapACI:1.2.3.4#subtree#grant;r;collection:[all]#group#cn=Dept
XYZ

Will the operation fail( no exact match), or will it return

 ldapACI: 1.2.3.4#subtree#grant;w;collection:[all]#group#cn=Dept XYZ (w
instead of r,w)
 ldapACI: 1.2.3.4#subtree#grant;r;attribute:attr1#group#cn=Dept XYZ

< djb > According to LDAPModify-delete semantics, the operation should fail
because no exact match is found.

What would be result if the input is:

ldapACI:1.2.3.4#subtree#grant;w;attribute:attr1#group#cn=DeptXYZ?

< djb > Again, no match is found so the operation should fail. If the
client wants to map the error to success, that is up to the client.


Section from the RFC :

   - modification: A list of modifications to be performed on the entry.
     The entire list of entry modifications MUST be performed
     in the order they are listed, as a single atomic operation.  While
     individual modifications may violate the directory schema, the
     resulting entry after the entire list of modifications is performed
     MUST conform to the requirements of the directory schema. The
     values that may be taken on by the 'operation' field in each
     modification construct have the following semantics respectively:

             add: add values listed to the given attribute, creating
             the attribute if necessary;

***             delete: delete values listed from the given attribute,
             removing the entire attribute if no values are listed, or
             if all current values of the attribute are listed for
             deletion;

             replace: replace all existing values of the given attribute
             with the new values listed, creating the attribute if it
             did not already exist.  A replace with no value will delete
             the entire attribute if it exists, and is ignored if the
             attribute does not exist.

   The result of the modify attempted by the server upon receipt of a
   Modify Request is returned in a Modify Response, defined as follows:

        ModifyResponse ::= [APPLICATION 7] LDAPResult

   Upon receipt of a Modify Request, a server will perform the necessary
   modifications to the DIT.


Wahl, et. al.               Standards Track                    [Page 33]

RFC 2251                         LDAPv3                    December 1997


   The server will return to the client a single Modify Response
   indicating either the successful completion of the DIT modification,
   or the reason that the modification failed. Note that due to the
   requirement for atomicity in applying the list of modifications in
   the Modify Request, the client may expect that no modifications of
   the DIT have been performed if the Modify Response received indicates
   any sort of error, and that all requested modifications have been
   performed if the Modify Response indicates successful completion of
   the Modify Operation.  If the connection fails, whether the
   modification occurred or not is indeterminate.

   The Modify Operation cannot be used to remove from an entry any of
   its distinguished values, those values which form the entry's
   relative distinguished name.  An attempt to do so will result in the
   server returning the error notAllowedOnRDN.  The Modify DN Operation
   described in section 4.9 is used to rename an entry.

***   If an equality match filter has not been defined for an attribute
type,
   clients MUST NOT attempt to delete individual values of that attribute
   from an entry using the "delete" form of a modification, and MUST
   instead use the "replace" form.

   Note that due to the simplifications made in LDAP, there is not a
   direct mapping of the modifications in an LDAP ModifyRequest onto the
   EntryModifications of a DAP ModifyEntry operation, and different
   implementations of LDAP-DAP gateways may use different means of
   representing the change.  If successful, the final effect of the
   operations on the entry MUST be identical.



On page 29,  the "public" DN is for setting access to all users.   Have you
considered to support another DN to represent "authenticated" users, to
differentiate "authenticated" from "unauthenticated"?

< djb > We have considered this, and have had similar requests from others.
I agree that authenticated vs unauthenticated is a very useful distinction.
Would anyone have an object to adding another 'pseudo user' which
represents all authenticated users, regardless of method of authentication
? While I understand that method of authentication is another useful
distinction, I do not ( at this point ) want to get tied up back in the
authentication question.