LDAP Requirements comments

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