Subject: Re: ACM & Replication (Was: LDAPEXT Minutes)

From: [email-masked] (Richard V Huber)
Date: Tue, 17 Apr 2001 17:00:14 -0400

The main replication-related change to the ACM draft is to make it
clear that the ACM applies to wire-line flows of data being
replicated.

Ellen Stokes agreed to add that to the ACM draft.  I'll propose
specific wording if needed.

Rick Huber

: To: [email-masked]
: From: "Kurt D. Zeilenga" <[email-masked]>
: Subject: ACM & Replication (Was: LDAPEXT Minutes)
: Cc: [email-masked]
: 
: At 10:56 AM 4/17/01, Mark Wahl wrote:
: >ACL
: > - replication requirements
: >
: >As John Strassner, co-chair of LDUP, requested that replication requirements 
: >of a document should be addressed in the working group where the document is 
: >authored, Rick Huber will incorporate replication requirements into the 
: >access control drafts.
: 
: Is there a description of what "replication requirements" which
: need to be addressed?  I can find no discussion of replication
: requirements upon the LDAP ACM in RFC 2820 nor the LDUP requirements
: document (though the latter details requirements upon LDUP to
: replicate access control information).
: 
: Thanks, Kurt

---

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Tue, 17 Apr 2001 15:48:33 -0700

>clear that the ACM applies to wire-line flows of data being

Are you saying here that LDAP ACM would be used to control what
was replicated between servers?  That seems presumptive.

>specific wording if needed.

Please do. That would allow some WG discussion of the specifics.
I certainly not sure what type of clarification you trying to
make.

I note I belief that the section paragraph of the Introduction and
the second paragraph of the Security Considerations were pretty
clear as how LDAP replication issues related to the LDAP ACM
are to be addressed.  That is, such issues are "out of scope".
I would certainly question any attempt to bring them into scope.

Kurt

---

From: Ellen Stokes <[email-masked]>
Date: Tue, 17 Apr 2001 20:53:59 -0500

From discussion with Rick Huber in Minneapolis, the following paragraphs
of the model draft have been modified and now read as follows (excerpted
from their sections with section headers):

2.  The LDAPv3 Access Control Model
    - What flows on the wire for interoperability

      The existing LDAP protocol flows for ldap operations
      are used to manipulate access control information.
      These same flows on the wire apply when ACI is
      transmitted during replication.  A set of permissions
      and their semantics with respect to ldap operations is
      defined.  The permissions parallel the defined set of
      ldap operations.  What is transmitted is exactly what
      is read back.  Encoding of access control information
      on the wire is per the LDAPv3 specifications.

4.  The Access Control Information Attributes and Syntax
The attributes are defined so access control information
(ACI) can be addressed in a server independent of server
implementation.  These attributes are used in typical LDAP
APIs, in LDIF output of ACI and in transfer of ACI during
replication. These attributes may be queried or set on all
directory objects.  The BNF and definitions are given below.

Ellen

---

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Tue, 17 Apr 2001 19:39:54 -0700

>     on the wire is per the LDAPv3 specifications.

This basically says:
        Access control information is represented as elements
        of the LDAP data model and can be manipulated using
       normal LDAP operations.  A set of permissions and their
       semantics with respect to LDAP operations is defined.  The
       permissions parallel the defined set of LDAP operations.

That is, LDAP defines the wire format of LDAP operations
including data elements.  All this "on the wire" stuff just
muddies the waters and is completely unnecessary. 

I note that statement:
      "What is transmitted is exactly what is read back."

implies that the server is not free to store the values as it
pleases (which is contrary to other statements in the ACM as
well as rfc2251).  The data and service model only requires,
in general, that information can be read back in an equivalent
form.  This is needed to support multiple transfer modes
(string v. ;binary) and to give the server to store the data
in alternative forms, such as needed to support other
protocols/services.

>implementation.

Suggest replacing "can be... " with:
    can be represented in an implementation independent
    manner.

>These attributes are used in typical LDAP
>replication.

s/are used/may be used/

>These attributes may be queried or set on all