Subject: WG Last Call on URP I-D

From: Christopher Apple <[email-masked]>
Date: Mon, 13 Aug 2001 18:30:51 -0400

The purpose of this message is to initiate the LDUP
Working Group last call on the LDUP Update
Reconciliation Procedures I-D document.

WHAT DOCUMENT?

The document in last call is:

http://www.ietf.org/internet-drafts/draft-ietf-ldup-urp-04.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 documents are
collected and discussed on the mailing list.

HOW LONG DOES IT LAST?

The last call starts today and will last approximately three
weeks. It will end on Tuesday, September 4, 2001 at 1830 US ET.

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 proposed standard
   status.

2) Minor changes agreed to on the list are required, and
   the documents are revised. We then ask our ADs to put
   forward the revised documents to the IESG for
   proposed standard 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 documents
is with the IESG. The IESG reads them and may approve the
documents (with or without changes), or send the documents
back to the working group to have major issues addressed.

If the first outcome happens, the documents are put forward
for a two-week last call to the entire IETF, and after
successful completion the documents are published as RFCs
with proposed standard 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 documents, 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: Ryan Moats <[email-masked]>
Date: Fri, 24 Aug 2001 11:03:35 -0500

I sat down last night and did a pass comparing between URP and the
requirements document.  Others may want to do this as well, because
where I found an acceptable explanation, others may not.

What I seemed to miss was the discussion of primitive generation
with respect to attribute types, attribute subtypes and attribute options.
Specifically there was no clarification

- whether attribute subtypes and options were or were not supported.  I
  believe absense of a restriction means they are, but others could read
  absense of a restriction to mean they are not.

- whether or not dsaOperation types could be replicated.  Since the
  requirements draft states this as a MUST NOT (req G10), the lack of
  a discussion in the primitive generation portion of the document
  disturbs me.

Ryan

---

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Fri, 24 Aug 2001 09:49:57 -0700

I think the editors need to review the document to
ensure all necessary normative references are in
place.  The document appears to be dependent on
LCUP (for entryUUID) and a variety of other LDUP
documents but contains no reference to them.  I note
as well that no other LDUP document formally references
this specification.

As such, I am unsure of the context in which this
specification is meant to be used and hence find it
hard to perform a complete review.

I note the only context I have from the I-D is LDAPv3
and X.500, both which provide no support for multiple
master replication and, hence, have no need for such
procedures.  It seems the Abstract and Introduction
need more work to detail the context in which this
specification is used.

Kurt