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

[Chris Apple <capple@xxxxxxx>]

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
capple@xxxxxxxxxxxxxxx
+1 973 236 6470                 Tired of slow directories?  Try AnyWho.
------------------------------------------------------------------------