RE: Correction to Last Call posting

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 protected]> 
(V) 610-425-2860


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

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.

BEGIN:VCARD
VERSION:2.1
N:Apple;Chris
FN:Chris Apple (E-mail)
ORG:UMI
TITLE:Program Manager
TEL;WORK;VOICE:(610) 425-2860
TEL;HOME;VOICE:(215) 873-0850
TEL;CELL;VOICE:(610) 585-4241
TEL;WORK;FAX:(610) 425-6501
ADR;WORK:;;1161 McDermott Drive;West Chester;Pa.;19380;United States of America
LABEL;WORK;ENCODING=QUOTED-PRINTABLE:1161 McDermott Drive=0D=0AWest Chester, Pa. 19380=0D=0AUnited States of Amer=
ica
EMAIL;PREF;INTERNET:[email protected]
REV:20010621T205341Z
END:VCARD