Subject: Correction to Last Call posting

From: Christopher Apple <[email-masked]>
Date: Fri, 22 Jun 2001 18:45:03 -0400

Correcting an error pointed out by Kurt Zeilenga.

The previously revised message incorrectly indicates
that the document would be published as a
proposed standard. This document would be published
as informational. This correction is included below.

CORRECTED LAST CALL ANNOUNCEMENT

The purpose of this message is to initiate the LDUP
working group last call on the LDAPv3 Replication
Requirements I-D document.

WHAT DOCUMENT?

The document in last call is:

http://www.ietf.org/internet-drafts/draft-ietf-ldup-replica-req-09.txt

WHAT IS A LAST CALL FOR?

The purpose of the working group last call is to ensure
that the working group has reached consensus on the
document, believes that all the known outstanding issues
have been addressed, and is ready to put the document
forward for proposed standard status.

During the last call, any comments on the document are
collected and discussed on the mailing list.

HOW LONG DOES IT LAST?

The last call starts today and will last approximately two
weeks. It will end on Friday, June 29, 2001.

WHAT'S THE NEXT STEP?

After the last call completes, there are three possible
outcomes:

1) No changes are required and we request our ADs to put
   forward the documents to the IESG for informational
   status.

2) Minor changes agreed to on the list are required, and
   the document is revised. We then ask our ADs to put
   forward the revised document to the IESG for
   informational status.

3) Major issues are raised and no consensus is reached on
   the list. In this case, we discuss things until consensus
   is reached, at which time another working group last call
   will be issued.

Assuming we achieve outcome 1) or 2), and that the ADs
agree with our assessment, the next stop for the document
is with the IESG. The IESG reads them and may approve the
document (with or without changes), or send the document
back to the working group to have major issues addressed.

If the first outcome happens, the document is put forward
for a two-week last call to the entire IETF, and after
successful completion the document is published as RFCs
with informational status.

If the second outcome happens, we go back and address
the issues, putting the documents forward again when we
believe they're ready.

WHAT SHOULD YOU DO?

You should read the document, making sure that 1) there
are no problems or deficiencies or outstanding issues that
need to be resolved; and 2) that there are no typos,
formatting problems, grammatical errors, etc.

Any substantive problems you find, you should send to the
list. Any minor problems (typos, etc.) you may send to the
list or just to the authors. If, for some reason, you have
comments you don't want to send to the entire list, you may
send them to me and/or LDUP WG co-chair John Strassner.

Silence means consent.

Read, enjoy, and send your comments in!

regards,
Chris Apple and John Strassner

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

---

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Wed, 27 Jun 2001 16:41:25 -0700

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.

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.

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.

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.

Security Considerations:
  "As noted in Section 3, security may be impacted..."

Section 3 makes no statement about security.  It makes a
statement about interoperability.

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.

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