Re: Comments to draft-ietf-ldapext-acl-model-02.txt (April 15th version).

[djbyrne@us.ibm.com]

Ludovic,

Thanks for the comments. My responses are prefaced by (djb)

Debbie

---
page 12:
          7.  Access Control Information (ACI) Controls

             The access control information controls provide a way to
             manipulate access control information in conjunction with
             an LDAP operation such as ldap_add, ldap_modify, or
             ldap_search.

This led to believe that the controls could be used with any ldap
operation. But of the 3 controls defined after, 2 are for searches
operation
only and the last one (specifyCredentials) is for ldap_bind.
I think ldap_add and ldap_modify shouldn't be mentioned if the controls
cannot
be applied to them.

(djb) Ok, we'll take a look at modifying this

----
pages 14 and 18:
Sections 7.1.2, 7.2.2:
Redefinition of SearchResultEntry.


In both sections 7.1.2 and 7.2.2 the SearchResultEntry structure is
redefined
with a different ASN1 definition from RFC 2251. I don't think it is a
good
idea. This will lead to confusion and may implies some deep changes in
the
decoding parts of the clients.

(djb) There is an unintentional redefinition of the SearchResultEntry. We'll fix
this in the next draft. The PartialEffectiveRightsList should be in the control
part of the LDAPMessage.


---
page 21:
          7.3.2  Response Control

             This control is included in the ldap_search message as
             part of the controls field of the LDAPMessage, as defined
             in Section 4.1.12 of [LDAPv3].

May be a copy/paste error, but this should apply to an ldap_bind
message.

(djb) yes, this is a copy / paste error.

page 22:
             Although this extends the bind operation, there are no
             incompatibilities between versions.  LDAPv2 cannot send a
             control.  A LDAPv3 client cannot send this request to a
             LDAPv2 server.  A LDAPv3 server not supporting this
             control cannot return the additional data.

May be a copy/paste mistake, but this paragraph doesn't make any sense
here. The BindResponse ASN1 definition wasn't changed.

( djb ) This was just an attempt to clarify expected v2 - v3 interactions ( or
lack thereof ) It is taken care of simply by the definition of controls, and
their behavior.

page 22:          7.3.3  Client-Server Interaction

             The specifyCredentialsRequest control specifies the
             credentials that the client was the server to use for
                                         ^^^^^
                                         wants
             access control in subsequent ldap operations.  The server
             ...
(djb) will change.

page 23:
             The client application is assured that the correct
             credentials are used by the server when specified by the
             client for subsequent ldap operations if and only if the
             specifyCredentialResponse is successful.  If the server
             omits the specifyCredentialResponse control from the
             searchResponse message, the client SHOULD assume that the
             control was ignored by the server.

May be a copy/paste mistake, but this control is to be part of a
bindResponse
not a searchResponse.

(djb ) you're right.

---
page 33:
Globally, several aci examples don't respect the BNF as specified in
section

(djb) yes, there are several errors in the BNF which have been corrected. I'll
make sure the ones you've mentioned are amoung them!

< text deleted >
----
page 37:
     10.4 BNF:
     ...
              <permission> : "a" | "d" | "r" | "s" | "w" | "c"
                                 | "g" | "s" | "m" | "u"
                             These are the permissions defined for
                         the IETF family OID.

I suggest that the document clearly explain which permission is
specified by
which letter. "a" for Add...

( djb ) Ok. The permissions match with those in section 5.2.1.1. I'll make it
clearer what everthing stands for.

---
page 37:
          10.5  Examples

(djb ) I'll make sure the examples correspond to the BNF


< text deleted >

--
Ludovic Poitou
Sun Microsystems Inc.
Sun-Aol Alliance - Directory Group - Grenoble - France




INet: djbyrne@us.ibm.com
Lotus Notes : djbyrne@ibmus
Phone: (512)838-1930 ( T/L 678 )