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

From: Chris Apple <[email-masked]>
Date: Mon, 03 Jan 2000 19:34:31 -0500

Mark,

John and I will have to confer on this and get back to you/the list.

Chris.

Mark Wahl wrote:
> 
> 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.

-- 
------------------------------------------------------------------------
Chris Apple                     Business Site: AnyWho Directory Service
Internet Directory Group                       http://www.anywho.com
AT&T Labs
[email-masked]
+1 973 236 6470                 Tired of slow directories?  Try AnyWho.
------------------------------------------------------------------------

---

From: Mark Wahl <[email-masked]>
Date: Tue, 18 Jan 2000 18:28:38 -0600

> John and I will have to confer on this and get back to you/the list.

Any update on this?

---

From: "John C. Strassner" <[email-masked]>
Date: Wed, 19 Jan 2000 05:59:03 -0800

Hi Mark,

Chris and I have discussed this with our ADs, and we are of the opinion 
that the references should be removed from the document. This not only 
solves the pesky problems that you've raised, but also enables the document 
to be more like a true architecture document and stand on its own. But we 
need to check with the authors first.

So I'll be writing a message soon to this effect and keep you posted.

Thanks for your comments.

regards,
John