Subject: LDAP Requirements comments

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Wed, 21 Nov 2001 13:47:25 -0800

In trying to understand where this WG is going, I recently
re-reading the LDAP Requirements. I came across a few issues
which likely should be fixed before this document is progressed
further.  While most editorial in nature, a couple are technical
(and substantive) in nature.  In particular, I suggest that
the current security consideration section be replaced.

Section 2:
  Anonymous Replication - Replication where the endpoints are
  identified to each other but not authenticated. 

I suggest "Anonymous Replication" be replaced with "Unauthenticated Replication" as an endpoint which is identified is not anonymous. 

  Area of Replication
And every use of "replication area", except the note in the
"Area of Replication" definition, should be changed to "Area
of Replication". 

  Sparse Replication - The capability to filter some subset
  of entries (other than a complete collection) of a
  replication base entry for replication.

likely should be:
  Sparse Replication - The capability to filter some subset
  of entries (other than a complete collection) of a
  Area of Replication.

  Multi-Master Replication - A replication model where entries
  can be written and updated on any of several master replica
  copies without requiring communication with other master
  replicas before the write or update is performed. 

By this definition, multi-master replication with Transactional
data consistency is not multi-master replication.  Suggest:
  Multi-Master Replication - A replication model that assumes
  multiple servers, each a master, allow LDAP write access to
  the replicated data.

  Slave (or Read-Only) Replica - A replica that cannot be
  directly updated via LDAP requests. Changes may only be made
  via replication from a master replica. Read-only replicas may
  occur in both single- and multi-master systems. 

I suggest s/may/can/ in both instances.  I also note that there
likely should be an explicit requirement that LDUP support
multi-master systems with slave replicas.

Section 3, pp 1.  s/must/is intended to/
(I view Models part of Section 3 as providing definition
of terms, likely more appropriately done in section 2.)
Section 3, Model 3, s/may/are allowed to/
Section 3, Model 4, s/may not be/is not necessarily/ 

In pp starting with "Consistency models..." s/may/can/

  Models 4 and 5 involve unregistered replicas that "pull"
  updates from another directory server without that
  server's knowledge.

Assuming LDAP as the access protocol, an unregistered
replica cannot "pull" updates from a server without that
server's knowledge. 
  These models violate a directory's security policies.

How?  An "unregistered" replica can enforce security policies
just as well as a "registered" replica.

In pp starting with "Models 2 and 3 illustrate", s/must/are/.

In pp starting with "Interoperability among ...", s/may/can/.

In last pp of Section 3, suggest replace:
  specified by the LDAP core documents (RFC 2251-2256, 2829, 2830).
with:
  defined in the LDAP Technical Specification [LDAPTS].
(LDAPTS == draft-ietf-ldapbis-ts-00.txt). And replace:
  "core" specifications 
with:
  LDAP Technical Specification
and likewise in G8.

In "may be limited", s/may/can/
  Use of applicability statements to improve interoperability
  in particular application spaces is RECOMMENDED. 

LDAP Replication is one such application where an applicability
statement upon LDAP will be REQUIRED to obtain interoperability.

In G3, G4, and elsewhere the phase "LDAP Replication Standard"
should be replaced with "LDAP Replication" (and LDAP Replication
should not be written with a capital R).  Also, all occurrences
of the adjective "standard" should likely be stricken (or
replaced with the word "common").

  G7. All policy and state data pertaining to replication MUST
  be accessible via LDAP. 

All?  This needs to be constrained to the subset of policy and
state information necessary to effectively administrate LDAP
Replication.

G9 states two distinct requirements.  Should be separated into
two.  (I note my previously stated opinion that the second G9
requirement is inappropriate and should be stricken).

M1 g).  I suggest "manual request" be an LDAP request.

AM7. and LDAP replication MUST prevent the establishment of
a 'blank' (or partially synced) replica from blanking (or
partially syncing) other replicas.

Suggest:
  AM8. Vendors SHOULD provide tools to audit schema compatibility
  within a potential replica-group.
be replaced with:
  AM8. Administrative tool creating new replicas SHOULD detect
  LDAP Replication SHOULD detect schema incompatibilities prior
  to instantiating a replication agreement.

S6/S7:  s/privacy/confidentiality/

Security considerations:
  As noted in Section 3, interoperability may be impacted when
  replicating among servers that implement non-standard extensions
  to basic LDAP semantics. 
This doesn't grasp the follow extent of the interoperability issue
impacting security.   And:
   Since LDAPv3 access control is a set of standards-based
   extensions
LDAPv3 access control is not yet defined.  It may never be.

Anyways, I suggest replacing the paragraph with:
  This document includes security requirements (listed in
  section 4.8 above) for the replication model and protocol.
  As noted in Section 3, interoperability may be impacted when
  replicating amount servers which implement different elective
  features of LDAP.  Hence, security (and general interoperability)
  will be significantly impacted by the degree of consistency
  with which LDAP implementations support elective features of
  LDAP.  This can be mitigated by requiring each implementation
  in a replicated environment implement, in a consistent manner,
  the same set of elective features.

Lastly, the document should be updated according to the (proposed)
RFC policy <http://www.rfc-editor.org/policy.html>.  In particular,
the abstract should be shorter and the normative and informative
references distinguished.

Kurt

---

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Wed, 21 Nov 2001 14:33:07 -0800

>references distinguished.

Whoops.  The length of this document's abstract is fine,
just the reference to [RFC2251] should be removed and
the mnemonic LDAPv3 spelled out.  Sorry, I hit the send
button a little too fast.

Kurt

---

From: Ryan Moats <[email-masked]>
Date: Wed, 21 Nov 2001 20:09:40 -0600

On Wed, Nov 21, 2001 at 01:47:25PM -0800, Kurt D. Zeilenga wrote:
| 
| In trying to understand where this WG is going, I recently
| re-reading the LDAP Requirements. I came across a few issues
| which likely should be fixed before this document is progressed
| further.  While most editorial in nature, a couple are technical
| (and substantive) in nature.  In particular, I suggest that
| the current security consideration section be replaced.

Process point...

I thought that a document past WG Last Call is off limits
until IETF Last call.

Ryan

---

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Wed, 21 Nov 2001 19:06:17 -0800

>I thought that a document past WG Last Call is off limits

First, I assume you mean off limits in the RFC 2418, Section
7.5, last paragraph sense.  To the best of my knowledge, the
document has not yet been submitted to the IESG for
consideration in accordance with RFC 2418, Section 7.5,
as the I-D is not listed in:
  http://www.ietf.org/IESG/status.html
  http://www.ietf.org/IESG/request.html
  http://www.ietf.org/iesg/1protocol_actions.txt
as required if the WG had achieved rough consensus that the
document should be progressed.  Hence my assumption the WG is
still the appropriate place to raise these concerns.

Second, if the document was actually submitted, nothing in
RFC 2418, Section 7.5 should be taken (IMO) as precluding
discussions regarding the submission are off-limits in the WG.
Such discussions would be quite relevant to the IESG
determination on how to progress the I-D.

So, until advised otherwise by a chair or AD, I assume that
the discussion is within scope.

Kurt

---

From: Ryan Moats <[email-masked]>
Date: Wed, 21 Nov 2001 23:40:07 -0600

On Wed, Nov 21, 2001 at 07:06:17PM -0800, Kurt D. Zeilenga wrote:
| At 06:09 PM 2001-11-21, Ryan Moats wrote:
| >On Wed, Nov 21, 2001 at 01:47:25PM -0800, Kurt D. Zeilenga wrote:
| >| In trying to understand where this WG is going, I recently
| >| re-reading the LDAP Requirements. I came across a few issues
| >| which likely should be fixed before this document is progressed
| >| further.  While most editorial in nature, a couple are technical
| >| (and substantive) in nature.  In particular, I suggest that
| >| the current security consideration section be replaced.
| >
| >Process point...
| >
| >I thought that a document past WG Last Call is off limits
| >until IETF Last call.
| 
| First, I assume you mean off limits in the RFC 2418, Section
| 7.5, last paragraph sense.  To the best of my knowledge, the
| document has not yet been submitted to the IESG for
| consideration in accordance with RFC 2418, Section 7.5,
| as the I-D is not listed in:
|   http://www.ietf.org/IESG/status.html
|   http://www.ietf.org/IESG/request.html
|   http://www.ietf.org/iesg/1protocol_actions.txt
| as required if the WG had achieved rough consensus that the
| document should be progressed.  Hence my assumption the WG is
| still the appropriate place to raise these concerns.

Well, my understanding
(based on http://www.imc.org/ietf-ldup/mail-archive/msg01122.html) is
that it has:

"       - passed WG Last Call - Request sent to Applications Area ADs for IESG Review"

Therefore, I think it is off our plate for now.

| Second, if the document was actually submitted, nothing in
| RFC 2418, Section 7.5 should be taken (IMO) as precluding
| discussions regarding the submission are off-limits in the WG.
| Such discussions would be quite relevant to the IESG
| determination on how to progress the I-D.

Uh, then what the *heck* does "Last Call" mean?  If folks can bring
up new points on the WG mailing list *AFTER* "Last Call" has closed, then
the whole concept is *bogus*, IMHO.  If I look at 2026 as well as 2418,
I'd claim these comments (if really for IESG detemrination) should
be going to the IESG during the IETF-wide "Last Call".  Since
that call hasn't been made, and since I don't see the iesg
mailing lists on these posts, I find this claim to be rather
disingenuous (sp?).

Ryan

---

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Thu, 22 Nov 2001 04:04:55 -0800

>"       - passed WG Last Call - Request sent to Applications Area ADs for IESG Review"

Well, obviously, that's in error or the IESG status pages
are in error.  I assume the chair will clarify and, if the
IESG are at fault, request the IESG Secretary appropriate
corrective action be taken.

>Therefore, I think it is off our plate for now.

The document is still a product of the WG.  A WG remains
free to discuss the I-D and provide input to the AD and
IESG.  This input may be solicited or unsolicited by the
IESG.  So, until such time the the chair advises me that
these comments is not appropriate for the WG to discuss, I
will continue to discuss them on the list.

>Uh, then what the *heck* does "Last Call" mean?

A last call is simply a process tool, calling for detailed
review and comment by all interested parties, to gauge
consensus regarding a pending action.

>If folks can bring up new points on the WG mailing list
>*AFTER* "Last Call" has closed, then the whole concept is
>*bogus*, IMHO. 

Folks can bring up new points at any time during the process.
Folks are encouraged to bring them sooner than later, which is
why I raised the issues soon after I came upon them.

>If I look at 2026 as well as 2418,
>be going to the IESG during the IETF-wide "Last Call".

It would be disingenuous to delay raising new points.

Kurt

---

From: "Chris Apple" <[email-masked]>
Date: Fri, 23 Nov 2001 18:51:27 -0600

The requirements document has indeed passed WG Last Call.

A recommendation was made to the Applications ADs as indicated
Previously and as referenced by Ryan.

Neither John nor I have heard from Patrik that the document
is not being considered or that there is something which would
keep it from moving forward. I'll ask Patrik what's going on
with the document. I don't know why it doesn't show up so far
on the list which Kurt mentions.

I'd prefer that any comments with regards to the requirements document
be handled as a part of IETF Last Call unless they are show stoppers.

Chris.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
On Behalf Of Kurt D. Zeilenga
Sent: Thursday, November 22, 2001 6:05 AM
To: Ryan Moats
Cc: [email-masked]
Subject: Re: Process Point (Was: LDAP Requirements comments)

Kurt

---

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Fri, 23 Nov 2001 17:58:26 -0800

>be handled as a part of IETF Last Call unless they are show stoppers.

Do you consider any of the issues raised "show stoppers"?

In particular,

1) The multi-master definition precluded transactional
consistency, counter to the document's G2 requirement
that transactional consistency not be precluded,

2) Per Ed's comment, it would appear wise to state that
LDUP design MAY preclude transactional consistency,

3) confusing use of RFC 2119 imperatives, and

4) Security considerations issues due to the changes in
assumptions made by WG (namely LDAPext delivering an ACM).

5) any of the other issues noted by either Ed or I in
recent WG discussions.

Kurt

---

From: "Chris Apple" <[email-masked]>
Date: Sat, 24 Nov 2001 01:22:19 -0600

I was only replying to the process point. I have not been able to read
the other postings that you mention yet. But will reply more
specifically
in context after I do.

Chris.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
On Behalf Of Kurt D. Zeilenga
Sent: Friday, November 23, 2001 7:58 PM
To: [email-masked]
Cc: 'Ryan Moats'; [email-masked]
Subject: RE: Process Point (Was: LDAP Requirements comments)

In particular,

Kurt