Subject: RE: Correction to Last Call posting

From: Christopher Apple <[email-masked]>
Date: Thu, 5 Jul 2001 17:20:29 -0400

These are the only comments we've received on this document.

Because they are relatively minor and because WG consensus
has already been established to not explicitly address at
least one of the previously made comments, after they are
all resolved - we will recommend that the IESG consider this
document for publication as an Informational document
without an additional WG Last Call.

Comments/responses below...

Chris Apple
Program Manager - Directory Services
United Messaging Inc.
<http://www.unitedmessaging.com>
<mailto:[email-masked]> 
(V) 610-425-2860

   >-----Original Message-----
   >From: Kurt D. Zeilenga [mailto:[email-masked]]
   >Sent: Wednesday, June 27, 2001 7:41 PM
   >To: Christopher Apple; [email-masked]
   >Cc: [email-masked]
   >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.

This comment is unresolved.

   >
   >G9. Sentence 1.
   >  LDAP replication SHOULD support replication of
   >  directoryOperation and distributedOperation attribute
   >  types defined in standards track LDAP extensions.
   >
   >I note that Dynamic Directory Services Extensions
   >(RFC 2589) standard track may be quite difficult to
   >support.

No change needs to be made to the document to accommodate
or account for this comment. The requirement has a force
of SHOULD. This means that, provided there are good reasons
for doing so, implementers wouldn't be required to support
ALL such attribute types. If the words "quite difficult"
turn out to mean that supporting the DDS extensions means
that you can't possibly guarantee any level of replicated
DIB consistency from master to slave copies - that would
be a good reason not to support those extensions. The
existing requirement force already allows for that sort
of exception you are seeking to accommodate.

I consider that comment to be resolved because no changes
are needed to accommodate Kurt's concerns.

   >
   >G9. Sentence 2.
   >  Future standards track specifications SHOULD include
   >  a "Replication Considerations" section which indicates
   >  how and whether the new feature operates in a replicated
   >  environment.
   >
   >I note that this is not a requirement upon LDUP but a
   >requirement upon future standard track specifications
   >to detail how to operate in yet specified replicated
   >environment.  I believe this should be reworded without
   >use of a RFC 2119 imperative or other wording implying
   >this is a requirement which future specifications need
   >to consider.  If such a requirement were needed to be
   >stated, it should be stated in a document (BCP?)
   >detailing guidelines to developers of LDAP extensions.
   >I note that such a guideline is under development.

WG Consensus was that this requirement be left in the document.

Our Co-ADs are aware of the discussion and will most likely make
a recommendation about where this sort of requirement
belongs during their review of the document over the next few
weeks.

I'm not even saying that I personally disagree with Kurt's position
of moving it into a different type of document. However, WG consensus
indicates that it should remain in the document for now. So it will.

I consider this one to be resolved with respect to the WG
Last Call process because it was resolved prior to initiating
the most recent one.

   >
   >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.

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.

   >
   >Editorial comments:
   >  The RFC 2119 paragraph should be moved from the Abstract
   >  to end of section 1 or added to section 2, which details
   >  terminology used.

I see no harm in moving this text. To avoid unnecessary work for
the editors, I believe its most appropriate to simply move the
paragraph to the end of section 1 and be done with it.

I consider this issue to be resolved because it is purely editorial
in nature and won't require significant work to implement in the
document itself.

   >
   >  "privacy" (S6,S7) should be replaced with "confidentiality".
   >

I believe Kurt's comment is consistent with the security glossary
documented in RFC 2828 - not quite sure how this was missed during
similar discussions about other passages in the document. The word
substitutions should be made to S6 and S7.

I consider this issue to be resolved.

---

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Fri, 06 Jul 2001 12:48:44 -0700

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

>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).

>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.

>an explicit proposal for the text to be contained in the

The suggested text addresses my concerns.