From owner-ietf-ldup@imc.org Mon Jan 3 20:10:33 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA09858 for ; Mon, 3 Jan 2000 20:10:31 -0500 (EST) Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id QAA23964 for ietf-ldup-bks; Mon, 3 Jan 2000 16:30:59 -0800 (PST) Received: from dir1.control.att.com ([135.207.251.15]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id QAA23960 for ; Mon, 3 Jan 2000 16:30:57 -0800 (PST) Received: from att.com (pest.control.att.com [135.207.251.76]) by dir1.control.att.com (Postfix) with ESMTP id 26DED71F7; Mon, 3 Jan 2000 19:30:48 -0500 (EST) Message-ID: <38714017.E0B4C635@att.com> Date: Mon, 03 Jan 2000 19:34:31 -0500 From: Chris Apple Organization: AT&T Labs X-Mailer: Mozilla 4.7 [en] (Win98; I) X-Accept-Language: en MIME-Version: 1.0 To: Mark Wahl Cc: John Strassner , ietf-ldup@imc.org Subject: Re: WG Last Call: draft-ietf-ldup-model-02.txt References: <25202.945829952@threadgill.austin.innosoft.com> Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Sender: owner-ietf-ldup@imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 8bit 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@control.att.com +1 973 236 6470 Tired of slow directories? Try AnyWho. ------------------------------------------------------------------------ From owner-ietf-ldup@imc.org Tue Jan 18 20:02:22 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA08259 for ; Tue, 18 Jan 2000 20:02:15 -0500 (EST) Received: by ns.secondary.com (8.9.3/8.9.3) id QAA28576 for ietf-ldup-bks; Tue, 18 Jan 2000 16:28:34 -0800 (PST) Received: from THOR.INNOSOFT.COM (SYSTEM@THOR.INNOSOFT.COM [192.160.253.66]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id QAA28572 for ; Tue, 18 Jan 2000 16:28:33 -0800 (PST) Received: from threadgill.austin.innosoft.com ([207.8.108.5]) by INNOSOFT.COM (PMDF V6.0-19 #30494) with ESMTP id <01JKUUDO1XHQ9BVJQP@INNOSOFT.COM> for ietf-ldup@imc.org; Tue, 18 Jan 2000 16:28:39 -0800 (PST) Received: from threadgill.austin.innosoft.com (threadgill.austin.innosoft.com [207.8.108.5]) by austin.innosoft.com (PMDF V5.2-32 #41296) with SMTP id <0FOK00I2J3ZQ12@austin.innosoft.com>; Tue, 18 Jan 2000 18:28:38 -0600 (CST) Date: Tue, 18 Jan 2000 18:28:38 -0600 From: Mark Wahl Subject: Re: WG Last Call: draft-ietf-ldup-model-02.txt In-reply-to: "Your message of Mon, 03 Jan 2000 19:34:31 EST." <38714017.E0B4C635@att.com> To: Chris Apple Cc: John Strassner , ietf-ldup@imc.org Message-id: <27576.948241718@threadgill.austin.innosoft.com> Sender: owner-ietf-ldup@imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: On January 3rd you wrote: > John and I will have to confer on this and get back to you/the list. Any update on this? Mark Wahl, Directory Product Architect Innosoft International, Inc. From owner-ietf-ldup@imc.org Wed Jan 19 09:36:45 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA29566 for ; Wed, 19 Jan 2000 09:36:45 -0500 (EST) Received: by ns.secondary.com (8.9.3/8.9.3) id FAA06155 for ietf-ldup-bks; Wed, 19 Jan 2000 05:58:00 -0800 (PST) Received: from omega.cisco.com (omega.cisco.com [171.69.63.141]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id FAA06151 for ; Wed, 19 Jan 2000 05:57:58 -0800 (PST) Received: from jstrassn-lt (newyork-dhcp-193.cisco.com [171.68.50.193]) by omega.cisco.com (8.8.8-Cisco List Logging/8.8.8) with ESMTP id FAA16516; Wed, 19 Jan 2000 05:58:06 -0800 (PST) Message-Id: <4.2.0.58.20000119055733.00bcce10@omega.cisco.com> X-Sender: jstrassn@omega.cisco.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58 Date: Wed, 19 Jan 2000 05:59:03 -0800 To: Mark Wahl , Chris Apple From: "John C. Strassner" Subject: Re: WG Last Call: draft-ietf-ldup-model-02.txt Cc: John Strassner , ietf-ldup@imc.org In-Reply-To: <27576.948241718@threadgill.austin.innosoft.com> References: <"Your message of Mon, 03 Jan 2000 19:34:31 EST." <38714017.E0B4C635@att.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ietf-ldup@imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: 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 At 06:28 PM 1/18/00 -0600, Mark Wahl wrote: >On January 3rd you wrote: > > > John and I will have to confer on this and get back to you/the list. > >Any update on this? > >Mark Wahl, Directory Product Architect >Innosoft International, Inc. From owner-ietf-ldup@imc.org Mon Jan 31 17:33:02 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA17290 for ; Mon, 31 Jan 2000 17:33:02 -0500 (EST) Received: by ns.secondary.com (8.9.3/8.9.3) id NAA20427 for ietf-ldup-bks; Mon, 31 Jan 2000 13:53:17 -0800 (PST) Received: from prv-mail20.provo.novell.com (prv-mail20.provo.novell.com [137.65.82.195]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id NAA20423 for ; Mon, 31 Jan 2000 13:53:16 -0800 (PST) Received: from INET-PRV-Message_Server by prv-mail20.provo.novell.com with Novell_GroupWise; Mon, 31 Jan 2000 14:54:06 -0700 Message-Id: X-Mailer: Novell GroupWise Internet Agent 5.5.2.1 Date: Mon, 31 Jan 2000 14:53:53 -0700 From: "Jim Sermersheim" To: Subject: Root naming context Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Disposition: inline Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ns.secondary.com id NAA20424 Sender: owner-ietf-ldup@imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 8bit Novell's implementation of LDAP allows one to root a naming context at the root of the tree. For example, you could have a DIT that looks like this: \ (naming context 1) | | +-cn=schema | +-o=administration | | + / +-c=US \ (naming context 2) | + / +-c=AU \ (naming context 3) + / Where the root of the tree, the schema, and the o=administration container all fit into naming context 1. This is possible because we have an actual entry at the root of the tree which we can attach the nameContext auxilliary class to (described in the arch and info model doc's). Thie only slightly quirky thing is that this entry is not named. This tends to work out quite well with the way LDAP is defined however. The namingContexts attribute in the root DSE can (and many times does) contain a zero length DN which names the root of the tree as a naming context root. It also comes in handy when assigning ACLs which are to inherit down the entire hierarchy. What I'm wondering (read: lack of ambition to do my own research) is whether this unnamed root entry will cause problems when replicating with other directories. Or in other words, do/will other LDAP directories allow this? Jim