Subject: WG Last Call: draft-ietf-ldup-model-02.txt

From: John Strassner <[email-masked]>
Date: Thu, 09 Dec 1999 22:42:23 -0800

PURPOSE?

The purpose of this message is to initiate the LDUP working
group last call on the LDAPv3 Replication Architecture document.
 
WHAT DOCUMENT?
 
The LDAPv3 Replication Architecture document in last call is:
 
         draft-ietf-ldup-model-02.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 (Friday, December 10, 1999) and
will last approximately two weeks. It will end on 
Friday, December 24, 1999.
 
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 slink back and 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 ([email-masked]) or my co-chair 
Chris Apple ([email-masked]).
 
Read, enjoy, and send your comments in!

Thanks and regards,
John and Chris

---

From: Mark Wahl <[email-masked]>
Date: Tue, 21 Dec 1999 20:32:32 -0600

I have a procedural question on this last call.   draft-ietf-ldup-model-02.txt
references the following drafts, among others, which I believe have never been
through a working group last call.

    [LDUP Info.] - E. Reed, "LDUP Replication Information Model", Internet
    Draft, draft-reed-ldup-infomod-00-1.txt, August 1998.

    [LDUP Protocol] - G. Good, E. Stokes 'The LDUP Replication Update
    Protocol' , Internet Draft, draft-ietf-ldup-protocol-00.txt, May 1999.

    [LDUP URP] -  S. Legg 'LDUP Update Reconciliation Procedures',
    Internet Draft, draft-legg-ldup-urp-00.txt, February 1999.

    [UUID] - P. Leach, R. Salz, "UUIDs and GUIDs", Internet draft, draft-
    leach-uuids-guids-01.txt, February 1998.

The draft-ietf-ldup-model-02.txt make explicit reference to these drafts
to define how LDUP operates.  Furthermore, draft-ietf-ldup-model-02.txt
fairly significantly constrains the contents of these documents, for 
example:

    The LDUP Protocol document [LDUP Protocol] defines an LDAP Extended
    Response, End Replication Response, that is sent in reply to an End
    Replication Request, from the Responder to the Supplier. The Response
    can optionally include an Update Vector.

    If the [*** NON ASCII CHARACTER 0221 ***]return update vector’ flag in the request was set then the
    Consumer should return its Update Vector to the Supplier.

Now in LDAPEXT we just ran into a problem where we last called the Java LDAP 
API, but I didn't notice that it relied on a Java SASL API internet draft 
until after the Java LDAP API last call ended.  Then we found that the Java 
SASL API draft had not gone through last call, and so we might need to rework 
one part of the LDAP API to change the use to the SASL API draft.

I wouldn't think the model draft would go through the IESG without them
wanting to review the documents on which this depend.  

So in reviewing draft-ietf-ldup-model-02.txt, how should we treat sections of 
this draft which depend on these other drafts?  Should we assume the 
information model, protocol, URP are part of this last call?  If so, should
the last call make this explicit?  

If not, then the problem would be if model goes through last call, but a 
dependency draft in its last call sometime later needs a change which would 
affect the model draft.  The model draft would then presumably come back to 
the working group, we last call it, and start again.  If this has to happen 
for each of the other LDUP drafts then it might be easier to do this all at 
once.

For one example, I feel strongly that naming contexts are identified by 
operational attributes and pointers from other entries, not by their object 
class values.  This change would primarily impact the Information Model, 
except that the Replication Architecture section 5.1 states as well

    The Naming Context Auxiliary Class is added to container entries that
    may have separately defined replication policy. [LDUP Info]

If my comment were submitted during the last call for draft-reed-ldup-infomod
and accepted, then the drafts would be out of synch with each other.  

Mark Wahl, Directory Product Architect
Innosoft International, Inc.