Re: Correction to Last Call posting

We basically agree with the three proposed changes, but we did make some
edits.  For the first change (to the last paragraph of Section 3), we
propose this wording:

"Interoperability among directories using LDAP replication may be limited
for implementations that add semantics beyond those specified by the LDAP
core documents (RFC 2251-2256, 2829, 2830). In addition, the "core"
specifications include numerous features which are not
mandatory-to-implement (e.g. RECOMMENDED or OPTIONAL).  There are also
numerous elective extensions.  Thus LDAP replication interoperability
between independent implementations of LDAP which support different options
may be limited.  Use of applicability statements to improve interoperability
in particular application spaces is RECOMMENDED."

We agree with Kurt's comment, but we also want to retain the point of the
original version of the paragraph, which we feel is still valid.

For requirement M5, we propose:

"M5.  LDAP replication MUST NOT require that all copies of the replicated
information be complete, but MAY require that at least one copy be
complete.  The model MUST support Partial Replicas."

We agree with Kurt's point and we think this wording captures it.

For Section 5 (Security Considerations) we propose:

"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 among servers that
implement non-standard extensions to basic LDAP semantics.  Since LDAPv3
access control is a set of standards-based extensions, security-related and
even general LDAP interoperability will be significantly impacted by the
degree of consistency with which LDAP implementations support the access
control model [ACModel]."

[ACModel] is the current Access Control Model draft
(draft-ietf-ldapext-acl-model-08.txt); it will be added to the references.

If these changes are acceptable to the list, we will resubmit the draft.
Since these are relatively minor changes resulting from WG last call, we
assume the new draft would go to the IESG.

Rick Huber (for the editors)


Christopher Apple wrote:

> Thanks. What do the document editors think about
> the proposed text changes? Other WG members?
>
> Chris Apple
> Program Manager - Directory Services
> United Messaging Inc.
> <http://www.unitedmessaging.com>
> <mailto:[email protected]>
> (V) 610-425-2860
>
>    >-----Original Message-----
>    >From: Kurt D. Zeilenga [mailto:[email protected]]
>    >Sent: Friday, July 06, 2001 3:49 PM
>    >To: Christopher Apple
>    >Cc: Christopher Apple; [email protected];
>    >[email protected]
>    >Subject: RE: Correction to Last Call posting
>    >
>    >
>    >I've restricted my comments to just those issues in which
>    >you explicitly requested further comment.  In regards to
>    >my other comments, I believe the WG has adequately
>    >addressed my concerns (not necessarily to my liking) and
>    >hence I support (with previously stated reservations)
>    >the progression of this document after these remaining
>    >issues are addressed (not necessarily to my liking).
>    >
>    >Kurt
>    >
>    >At 02:20 PM 7/5/2001, Christopher Apple wrote:
>    >>   >-----Original Message-----
>    >>   >From: Kurt D. Zeilenga [mailto:[email protected]]
>    >>   >Sent: Wednesday, June 27, 2001 7:41 PM
>    >>   >To: Christopher Apple; [email protected]
>    >>   >Cc: [email protected]
>    >>   >Subject: Re: Correction to Last Call posting
>    >>   >
>    >>   >
>    >>   >This message mostly reiterates previously raised issues.
>    >>   >
>    >>   >Section 3:
>    >>   >  Interoperability among directories using LDUP
>    >replication may be
>    >>   >  limited for implementations that add semantics beyond
>    >>   >those specified
>    >>   >  by the LDAP core documents (RFC 2251-2256, 2829, 2830).
>    >>   >
>    >>   >I note that Interoperability among directories using LDUP
>    >>   >replication
>    >>   >may also be limited for implementations which
>    >implement different
>    >>   >subsets of the semantics defined in the LDAP "core"
>    >specification.
>    >>   >For example, one implementation may support subtyping
>    >another not.
>    >>   >Another may require ;binary for some standard track attribute
>    >>   >while another disallows ;binary for same.  As an alternative to
>    >>   >adding a clarification to the statement (as I would prefer),
>    >>   >removing the statement (as it doesn't place a requirement upon
>    >>   >LDUP) would be acceptable.
>    >>
>    >>Please propose full replacement text for the statement you
>    >>are commenting on. I can't determine exactly what you are
>    >>proposing to add as clarifying text based on what you wrote.
>    >
>    >        As LDAP "core" specification includes numerous features
>    >        which are not mandatory-to-implement (e.g. RECOMMENDED
>    >        or OPTIONAL) as well supports elective extensions,
>    >       interoperability between independent implementations of
>    >        LDAP and the LDUP replication extension may be limited.
>    >        Use of applicability statements to improve interoperability
>    >        in particular application spaces is RECOMMENDED.
>    >
>    >My point is not that this LDAP Replication issue is not limited
>    >just by "semantics beyond" the core specification, but to
>    >non-mandatory semantics within the core specification and
>    >"semantics beyond".  And, I believe both can be addressed
>    >through use of applicability statements (which narrows the
>    >applicable specifications).
>    >
>    >>   >M5.  LDAP replication MUST NOT require all copies of
>    >the replicated
>    >>   >information to be complete copies of the replicated object.
>    >>   > The model
>    >>   >MUST support Partial Replicas.
>    >>   >
>    >>   >I assume this applies to copies, not to the original.
>    >>   >That is, I assume that LDAP replication MAY require
>    >>   >some master (if not all masters) to hold a complete
>    >>   >instance of the object.  Some clarification here may
>    >>   >be appropriate.
>    >>
>    >>Please propose clarifying text explicitly so the WG can
>    >>evaluate it. I can't tell quite what to suggest as clarifying
>    >>text based on your comment.
>    >
>    >LDAP replication MUST NOT require all copies of the replicated
>    >information to be complete copies of the replicated object
>    >but MAY require that a complete copy to be held by at least
>    >one replica.  The model MUST support Partial Replicas.
>    >
>    >
>    >>This issue is unresolved.
>    >>
>    >>   >
>    >>   >Security Considerations:
>    >>   >  "As noted in Section 3, security may be impacted..."
>    >>   >
>    >>   >Section 3 makes no statement about security.  It makes a
>    >>   >statement about interoperability.
>    >>
>    >>Current Text:
>    >>
>    >>This document includes security requirements (listed in section 4.8
>    >>above) for the replication model and protocol. As noted in
>    >Section 3,
>    >>security may be impacted when replicating among servers
>    >that implement
>    >>non-standard extensions to basic LDAP semantics.  Access
>    >control is one
>    >>common case which affects security; work to address this
>    >issue is going
>    >>on in LDAPEXT as documented in RFC 2820 [RFC2820].
>    >>
>    >>Proposed Text to clarify the section based on Kurt's comment:
>    >>
>    >>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 among servers that implement non-standard extensions
>    >>to basic LDAP semantics. Since LDAPv3 access control work is being
>    >>treated as a set of standards-based extensions, security-related
>    >>and even general LDUP interoperability will be significantly
>    >>impacted by the degree of consistency with which LDUP
>    >>implementations support the LDAPv3 access control requirements
>    >>documented in RFC 2820 [RFC2820].
>    >>
>    >>This issue is unresolved until we hear from at least the
>    >>document editors about whether or not this proposed text
>    >>fits or not. Also need some reaction from Kurt about whether
>    >>this clarifies the text based on his perspective. If not,
>    >>I think it would be reasonable for us to expect to see
>    >>an explicit proposal for the text to be contained in the
>    >>section.
>    >
>    >The suggested text addresses my concerns.
>    >