From owner-ietf-ldup@mail.imc.org Sun Sep 1 13:00:05 2002 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA24498 for ; Sun, 1 Sep 2002 13:00:04 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g81Gp0U24460 for ietf-ldup-bks; Sun, 1 Sep 2002 09:51:00 -0700 (PDT) Received: from dns.caledonia.net (dns.caledonia.net [207.40.197.238]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g81Gow224450 for ; Sun, 1 Sep 2002 09:50:58 -0700 (PDT) Received: from D7ST2111 (pool-141-158-56-157.phil.east.verizon.net [141.158.56.157]) by dns.caledonia.net; Sun, 01 Sep 2002 10:50:37 -0600 Reply-To: From: "Chris Apple" To: Cc: "John Strassner" Subject: WG Last Call: LCUP Draft Date: Sun, 1 Sep 2002 12:49:17 -0400 Organization: DSI-Consulting, Inc. Message-ID: <000601c251d7$83e0ee10$0400a8c0@D7ST2111> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.3416 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Importance: Normal Sender: owner-ietf-ldup@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit The purpose of this message is to initiate the LDUP working group last call on the LDAP Client Update Protocol draft. WHAT DOCUMENT? The document in last call is: http://www.ietf.org/internet-drafts/draft-ietf-ldup-lcup-03.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 Tuesday, September 3, 2002 and will Last approximately two weeks. It will end on Tuesday, September 17, 2002 at 1700 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 - Principal Architect DSI Consulting, Inc. mailto:capple@dsi-consulting.net http://www.dsi-consulting.com From owner-ietf-ldup@mail.imc.org Tue Sep 3 12:59:06 2002 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA04899 for ; Tue, 3 Sep 2002 12:59:06 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g83GpgN18560 for ietf-ldup-bks; Tue, 3 Sep 2002 09:51:42 -0700 (PDT) Received: from prv-mail20.provo.novell.com (prv-mail20.provo.novell.com [137.65.81.122]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g83Gpf218554 for ; Tue, 3 Sep 2002 09:51:41 -0700 (PDT) Received: from INET-PRV-MTA by prv-mail20.provo.novell.com with Novell_GroupWise; Tue, 03 Sep 2002 10:51:36 -0600 Message-Id: X-Mailer: Novell GroupWise Internet Agent 6.0.2 Beta Date: Tue, 03 Sep 2002 10:48:46 -0600 From: "Jim Sermersheim" To: , Cc: Subject: LCUP Issue: UUID Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Disposition: inline Sender: owner-ietf-ldup@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit The syntax of UUID is directory string, and moreover, the matching rule is case ignore match. I see this as overly limiting and suggest that the syntax be changed to octet string. This is made even more apparent by the fact that this document leaves standardization of the value generation to a future specification. From owner-ietf-ldup@mail.imc.org Tue Sep 3 13:08:44 2002 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA05298 for ; Tue, 3 Sep 2002 13:08:43 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g83H4cJ20189 for ietf-ldup-bks; Tue, 3 Sep 2002 10:04:38 -0700 (PDT) Received: from prv-mail20.provo.novell.com (prv-mail20.provo.novell.com [137.65.81.122]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g83H4b220185 for ; Tue, 3 Sep 2002 10:04:37 -0700 (PDT) Received: from INET-PRV-MTA by prv-mail20.provo.novell.com with Novell_GroupWise; Tue, 03 Sep 2002 11:04:33 -0600 Message-Id: X-Mailer: Novell GroupWise Internet Agent 6.0.2 Beta Date: Tue, 03 Sep 2002 11:01:39 -0600 From: "Jim Sermersheim" To: , , "Jim Sermersheim" Cc: Subject: LCUP Issue: Cookie problem Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Disposition: inline Sender: owner-ietf-ldup@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit Section 4.2 states: "The cookie value MUST be included except when a client has no stored state; i.e., when the client is requesting a full synchronization" It's not clear whether this refers to a cookie in a ClientUpdateControlValue, and/or a EntryUpdateControlValue , and/or a ClientUpdateDoneControlValue. Jim From owner-ietf-ldup@mail.imc.org Tue Sep 3 13:15:40 2002 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA05500 for ; Tue, 3 Sep 2002 13:15:39 -0400 (EDT) Received: by above.proper.com (8.11.6/8.11.3) id g83HBZs20584 for ietf-ldup-bks; Tue, 3 Sep 2002 10:11:35 -0700 (PDT) Received: from prv-mail20.provo.novell.com (prv-mail20.provo.novell.com [137.65.81.122]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g83HBX220579 for ; Tue, 3 Sep 2002 10:11:34 -0700 (PDT) Received: from INET-PRV-MTA by prv-mail20.provo.novell.com with Novell_GroupWise; Tue, 03 Sep 2002 11:11:29 -0600 Message-Id: X-Mailer: Novell GroupWise Internet Agent 6.0.2 Beta Date: Tue, 03 Sep 2002 11:08:37 -0600 From: "Jim Sermersheim" To: , Cc: Subject: LCUP Issue: lcupClientDisconnect result code Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Disposition: inline Sender: owner-ietf-ldup@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit The draft defines a new result code called "lcupClientDisconnect". I think the result code "canceled" defined in Section 7.3 of draft-zeilenga-ldap-cancel-06.txt serves exaclty the same purpose and is where this result code should be defined. Jim From owner-ietf-ldup@mail.imc.org Tue Sep 3 13:26:10 2002 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA05884 for ; Tue, 3 Sep 2002 13:26:10 -0400 (EDT) Received: by above.proper.com (8.11.6/8.11.3) id g83HMnC21239 for ietf-ldup-bks; Tue, 3 Sep 2002 10:22:49 -0700 (PDT) Received: from pretender.boolean.net (root@router.boolean.net [198.144.206.49]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g83HMl221234 for ; Tue, 3 Sep 2002 10:22:47 -0700 (PDT) Received: from nomad.OpenLDAP.org (root@localhost [127.0.0.1]) by pretender.boolean.net (8.12.5/8.12.5) with ESMTP id g83HMkkC099260; Tue, 3 Sep 2002 17:22:46 GMT (envelope-from Kurt@OpenLDAP.org) Message-Id: <5.1.0.14.0.20020903100656.02918fb8@127.0.0.1> X-Sender: kurt@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Tue, 03 Sep 2002 10:22:21 -0700 To: "Jim Sermersheim" From: "Kurt D. Zeilenga" Subject: Re: LCUP Issue: UUID Cc: , , In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-ldup@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: At 09:48 AM 2002-09-03, Jim Sermersheim wrote: >The syntax of UUID is directory string, and moreover, the matching rule >is case ignore match. I see this as overly limiting and suggest that the >syntax be changed to octet string. This is made even more apparent by >the fact that this document leaves standardization of the value >generation to a future specification. I suggest a couple of comments regarding UUID. First and foremost, UUID support needs to be mandatory. The protocol won't work otherwise. I also suggest that, instead of returning the UUID as an attribute value (which are subject to normal access controls), it should be returned within the control (which *should* be subject to some kind of access restrictions). This to avoid having to deal with no UUID as being a valid response to a CRITICAL update request. Instead, if the server is unwilling to provide the UUID, the CRITICAL request will fail. I do believe a specification of how the server represents UUIDs (and CSNs) in the directory should be standardized, but suggest this be done in a separate document... as, if UUIDs are passed in the control, LCUP doesn't depend on the particulars representation in the DIT. For the specifications of entryUUID (and entryCSN) I suggest using either octetString/octetStringMatch or UUID/UUIDMatch (where UUID was a constrained OCTET STRING with a string syntax). I prefer the latter. There is no need to leave the string syntax up to future standardization. ISO/IEC 11578:1996 can be referenced. Kurt From owner-ietf-ldup@mail.imc.org Tue Sep 3 13:42:36 2002 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA06654 for ; Tue, 3 Sep 2002 13:42:36 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g83HblO21804 for ietf-ldup-bks; Tue, 3 Sep 2002 10:37:47 -0700 (PDT) Received: from e1.ny.us.ibm.com (e1.ny.us.ibm.com [32.97.182.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g83Hbi221789 for ; Tue, 3 Sep 2002 10:37:44 -0700 (PDT) Received: from northrelay04.pok.ibm.com (northrelay04.pok.ibm.com [9.56.224.206]) by e1.ny.us.ibm.com (8.12.2/8.12.2) with ESMTP id g83HafEG187996 for ; Tue, 3 Sep 2002 13:36:45 -0400 Received: from d27ml001.rchland.ibm.com (d27ml001.rchland.ibm.com [9.10.226.142]) by northrelay04.pok.ibm.com (8.12.3/NCO/VER6.4) with ESMTP id g83Hadwr021132 for ; Tue, 3 Sep 2002 13:36:39 -0400 Subject: Re: LCUP Issue: UUID To: ietf-ldup@imc.org X-Mailer: Lotus Notes Release 5.0.10 March 22, 2002 Message-ID: From: John McMeeking Date: Tue, 3 Sep 2002 12:36:38 -0500 X-MIMETrack: Serialize by Router on d27ml001/27/M/IBM(Build V60_07142002NP|July 14, 2002) at 09/03/2002 12:36:41 MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII Sender: owner-ietf-ldup@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: I think that some reasonable uses of the attribute warrant a string representation. For example, an application may want to search for an entry with a specific entryuuid. And some LDUP conflict resolution procedures call for renaming an entry to have a DN like "cn=some value + entryuuid=xxxx". Constructing such search filters and DNs is much cleaner if entryuuid has a string syntax. Granted, a well-written application should be able to construct search filters and DNs containing binary values. Case ignore match may be too restrictive. Certainly, there is no reason why an application can't use the entry uuid in the case provided by the originating server. That aside, don't we have to define what an entry uuid looks like? The remaining LDUP drafts, at least, requires that a given server be able to generate a entryuuid that is unique across all entries on all servers. I don't see how a server can generate a unique entryuuid without knowing the format or generation algorithm. If we don't want to specify an algorithm (DCE UUIDs have been bandied about, but there seems to be some reluctance to agree to specify them), then we at least need to define a format that includes the algorithm, and a mechanism for uniquely identifying the algorithm. A maximum size would probably be helpful to server vendors so as to not have to provide a search and storage mechanism (DB table for example) that has to support arbirary length values generated by other servers. Just to get things started, I propose that we use the DCE UUID algorithms, which have a well defined string representation. And we should be able to define a entryuuid syntax with a string representation, which is probably a bit cleaner than using "directory string" or "octet string." John McMeeking "Jim Sermersheim" , com> cc: Sent by: owner- Subject: LCUP Issue: UUID ietf-ldup@mail. imc.org 09/03/2002 11:48 AM The syntax of UUID is directory string, and moreover, the matching rule is case ignore match. I see this as overly limiting and suggest that the syntax be changed to octet string. This is made even more apparent by the fact that this document leaves standardization of the value generation to a future specification. From owner-ietf-ldup@mail.imc.org Tue Sep 3 13:43:33 2002 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA06716 for ; Tue, 3 Sep 2002 13:43:33 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g83HcRV21858 for ietf-ldup-bks; Tue, 3 Sep 2002 10:38:27 -0700 (PDT) Received: from wstutil12a.ml.com (wstutil12a-v.ml.com [209.65.19.67]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g83HcQ221853 for ; Tue, 3 Sep 2002 10:38:26 -0700 (PDT) Received: from wstutil13a.ml.com (wstutil13a [146.125.185.11]) by wstutil12a.ml.com (8.11.3/8.11.3/wstutil12a-1.2) with ESMTP id g83HcLd23168; Tue, 3 Sep 2002 13:38:21 -0400 (EDT) Received: from ewstwt01.exchange.ml.com (ewstwt01.exchange.ml.com [146.125.249.151]) by wstutil13a.ml.com (8.11.3/8.11.3/wstutil13a-1.1) with SMTP id g83HcK100131; Tue, 3 Sep 2002 13:38:20 -0400 (EDT) Received: from 169.242.226.176 by ewstwt01.exchange.ml.com with ESMTP ( Tumbleweed MMS SMTP Relay (MMS v4.7);); Tue, 03 Sep 2002 13:37:41 -0400 X-Server-Uuid: 3789b954-9c4e-11d3-af68-0008c73b0911 Received: by ehope09.hew.us.ml.com with Internet Mail Service ( 5.5.2653.19) id ; Tue, 3 Sep 2002 13:37:37 -0400 Message-ID: <9B5CBD4986A9D511BE2100065B045DDF0238BDE0@ehope21.hew.us.ml.com> From: "Liben, Michael (GTS)" To: "'Jim Sermersheim'" , capple@dsi-consulting.net, ietf-ldup@imc.org cc: john.strassner@intelliden.com Subject: RE: LCUP Issue: UUID Date: Tue, 3 Sep 2002 13:37:36 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) X-WSS-ID: 116A2CEF119420-01-01 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-ldup@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit My vote is to leave it as directory string. I do not see any significant server-side benefit from storing as an octet string. And a directory string is far easier to debug. -----Original Message----- From: Jim Sermersheim [mailto:jimse@novell.com] Sent: Tuesday, September 03, 2002 12:49 PM To: capple@dsi-consulting.net; ietf-ldup@imc.org Cc: john.strassner@intelliden.com Subject: LCUP Issue: UUID The syntax of UUID is directory string, and moreover, the matching rule is case ignore match. I see this as overly limiting and suggest that the syntax be changed to octet string. This is made even more apparent by the fact that this document leaves standardization of the value generation to a future specification. From owner-ietf-ldup@mail.imc.org Tue Sep 3 14:50:29 2002 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA09296 for ; Tue, 3 Sep 2002 14:50:28 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g83IdIP24644 for ietf-ldup-bks; Tue, 3 Sep 2002 11:39:18 -0700 (PDT) Received: from pretender.boolean.net (root@router.boolean.net [198.144.206.49]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g83IdG224640 for ; Tue, 3 Sep 2002 11:39:16 -0700 (PDT) Received: from nomad.OpenLDAP.org (root@localhost [127.0.0.1]) by pretender.boolean.net (8.12.5/8.12.5) with ESMTP id g83IdFkC099590; Tue, 3 Sep 2002 18:39:15 GMT (envelope-from Kurt@OpenLDAP.org) Message-Id: <5.1.0.14.0.20020903111712.02909390@127.0.0.1> X-Sender: kurt@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Tue, 03 Sep 2002 11:38:50 -0700 To: From: "Kurt D. Zeilenga" Subject: Re: WG Last Call: LCUP Draft Cc: , "John Strassner" In-Reply-To: <000601c251d7$83e0ee10$0400a8c0@D7ST2111> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-ldup@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: A month or so ago, I provided the authors with a laundry list of technical and editorial comments. Before I echo each of these on the list (which I will before the end of comment period), I like to raise what I consider my biggest concern. My biggest concern is that this protocol provide the client will all the events necessary for it to "synchronize" update its copy of the fragment of the DIT previously returned to that which would be returned if the original request would have been repeated. In the worst case, a client repeating the original request may find that the copy "synchronized" by LCUP is MOSTLY changed! The protocol basically needs not only to send a copy of all entries which are within scope which have significantly changed, but also send a list of UUIDs and CSNs of all the entries which have not changed. This would not only allows the client to determine the set of entries which have been deleted from the fragment, but also determine if an entry returned but not updated needs to be refreshed. In which case, it can request a copy of those entries which it believes need to be refreshed. This can be done out of band with a persist operation. The persist needs a bit of work as well. Basically, the server needs to be required to generate the set of events necessary for eventual convergence of the client's copy of the DIT fragment. Kurt At 09:49 AM 2002-09-01, Chris Apple wrote: >The purpose of this message is to initiate the LDUP >working group last call on the LDAP Client Update Protocol >draft. > >WHAT DOCUMENT? > >The document in last call is: > >http://www.ietf.org/internet-drafts/draft-ietf-ldup-lcup-03.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 Tuesday, September 3, 2002 and will >Last approximately two weeks. > >It will end on Tuesday, September 17, 2002 at 1700 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 - Principal Architect > >DSI Consulting, Inc. > >mailto:capple@dsi-consulting.net > >http://www.dsi-consulting.com From owner-ietf-ldup@mail.imc.org Tue Sep 3 17:07:46 2002 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA14326 for ; Tue, 3 Sep 2002 17:07:45 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g83KwWa04643 for ietf-ldup-bks; Tue, 3 Sep 2002 13:58:32 -0700 (PDT) Received: from dns.caledonia.net (dns.caledonia.net [207.40.197.238]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g83KwU204639 for ; Tue, 3 Sep 2002 13:58:30 -0700 (PDT) Received: from D7ST2111 ([151.155.252.30]) by dns.caledonia.net; Tue, 03 Sep 2002 14:58:08 -0600 Reply-To: From: "Chris Apple" To: "'Kurt D. Zeilenga'" Cc: , "'John Strassner'" Subject: RE: WG Last Call: LCUP Draft Date: Tue, 3 Sep 2002 16:56:51 -0400 Organization: DSI-Consulting, Inc. Message-ID: <000501c2538c$6e475290$1efc9b97@D7ST2111> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.3416 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Importance: Normal In-Reply-To: <5.1.0.14.0.20020903111712.02909390@127.0.0.1> Sender: owner-ietf-ldup@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit Please do post the laundry list to the WG mailing list. I want to be in a position to track all issues raised shortly after the WG Last Call period is over. Chris Apple - Principal Architect DSI Consulting, Inc. mailto:capple@dsi-consulting.net http://www.dsi-consulting.com -----Original Message----- From: owner-ietf-ldup@mail.imc.org [mailto:owner-ietf-ldup@mail.imc.org] On Behalf Of Kurt D. Zeilenga Sent: Tuesday, September 03, 2002 2:39 PM To: capple@dsi-consulting.net Cc: ietf-ldup@imc.org; John Strassner Subject: Re: WG Last Call: LCUP Draft A month or so ago, I provided the authors with a laundry list of technical and editorial comments. Before I echo each of these on the list (which I will before the end of comment period), I like to raise what I consider my biggest concern. My biggest concern is that this protocol provide the client will all the events necessary for it to "synchronize" update its copy of the fragment of the DIT previously returned to that which would be returned if the original request would have been repeated. In the worst case, a client repeating the original request may find that the copy "synchronized" by LCUP is MOSTLY changed! The protocol basically needs not only to send a copy of all entries which are within scope which have significantly changed, but also send a list of UUIDs and CSNs of all the entries which have not changed. This would not only allows the client to determine the set of entries which have been deleted from the fragment, but also determine if an entry returned but not updated needs to be refreshed. In which case, it can request a copy of those entries which it believes need to be refreshed. This can be done out of band with a persist operation. The persist needs a bit of work as well. Basically, the server needs to be required to generate the set of events necessary for eventual convergence of the client's copy of the DIT fragment. Kurt At 09:49 AM 2002-09-01, Chris Apple wrote: >The purpose of this message is to initiate the LDUP >working group last call on the LDAP Client Update Protocol >draft. > >WHAT DOCUMENT? > >The document in last call is: > >http://www.ietf.org/internet-drafts/draft-ietf-ldup-lcup-03.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 Tuesday, September 3, 2002 and will >Last approximately two weeks. > >It will end on Tuesday, September 17, 2002 at 1700 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 - Principal Architect > >DSI Consulting, Inc. > >mailto:capple@dsi-consulting.net > >http://www.dsi-consulting.com From owner-ietf-ldup@mail.imc.org Tue Sep 3 17:49:44 2002 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA15470 for ; Tue, 3 Sep 2002 17:49:43 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g83LjTM05898 for ietf-ldup-bks; Tue, 3 Sep 2002 14:45:29 -0700 (PDT) Received: from dns.caledonia.net (dns.caledonia.net [207.40.197.238]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g83LjR205894 for ; Tue, 3 Sep 2002 14:45:28 -0700 (PDT) Received: from D7ST2111 ([151.155.252.30]) by dns.caledonia.net; Tue, 03 Sep 2002 15:44:53 -0600 Reply-To: From: "Chris Apple" To: Cc: "'John Strassner'" Subject: RE: Access Control Design Team Work Program Date: Tue, 3 Sep 2002 17:43:34 -0400 Organization: DSI-Consulting, Inc. Message-ID: <000001c25392$f5756f80$1efc9b97@D7ST2111> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.3416 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Importance: Normal In-Reply-To: <000001c2120c$bea16170$0300a8c0@D7ST2111> Sender: owner-ietf-ldup@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit I'm running a few days behind on delivering a report to the WG on the activities of the Access Control Design Team. The work program schedule previously posted to the WG mailing list indicates that there is to be a report of the design team's activities through the month of August for discussion in September 2002. Expect a report on the design team's progress by COB ET Monday, 9/9/2002. I want to give the design team members a chance to review it for consistency with team discussions before posting to the WG mailing list. Chris Apple - Principal Architect DSI Consulting, Inc. mailto:capple@dsi-consulting.net http://www.dsi-consulting.com -----Original Message----- From: owner-ietf-ldup@mail.imc.org [mailto:owner-ietf-ldup@mail.imc.org] On Behalf Of Chris Apple Sent: Wednesday, June 12, 2002 8:29 AM To: ietf-ldup@imc.org Cc: John Strassner Subject: Access Control Design Team Work Program Text file attached. Please review and post comments to the LDUP WG mailing list or send directly to John Strassner or myself. Also note that despite e-mail address change, christopher.apple@verizon.net ends up in my mail client as well - so if you get bounced mail, try sending to the old one as a second choice. Should be taken care of on the WG Charter page soon. Chris Apple Principal Architect DSI Consulting, Inc. mailto: capple@dsi-consulting.net http://www.dsi-consulting.com From owner-ietf-ldup@mail.imc.org Tue Sep 3 18:15:33 2002 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA16036 for ; Tue, 3 Sep 2002 18:15:32 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g83MAJW06379 for ietf-ldup-bks; Tue, 3 Sep 2002 15:10:19 -0700 (PDT) Received: from netscape.com (c3po.netscape.com [205.217.237.46]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g83MAH206375 for ; Tue, 3 Sep 2002 15:10:17 -0700 (PDT) Received: from dredd.mcom.com (dredd.nscp.aoltw.net [10.169.8.48]) by netscape.com (8.10.0/8.10.0) with ESMTP id g83LKdm05294 for ; Tue, 3 Sep 2002 14:20:40 -0700 (PDT) Received: from netscape.com ([10.0.198.53]) by dredd.mcom.com (Netscape Messaging Server 4.15) with ESMTP id H1VUUP00.VTO for ; Tue, 3 Sep 2002 15:08:49 -0700 Message-ID: <3D7532C8.4030008@netscape.com> Date: Tue, 03 Sep 2002 16:08:08 -0600 From: richm@netscape.com (Rich Megginson) Organization: Netscape - Enterprise Products User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.1) Gecko/20020823 Netscape/7.0 X-Accept-Language: en,pdf MIME-Version: 1.0 To: ietf-ldup@imc.org Subject: LCUP issues to consider Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms090702080503030000030203" Sender: owner-ietf-ldup@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a cryptographically signed message in MIME format. --------------ms090702080503030000030203 Content-Type: multipart/mixed; boundary="------------000907070609030003060205" This is a multi-part message in MIME format. --------------000907070609030003060205 Content-Type: multipart/alternative; boundary="------------080106070804070501030101" --------------080106070804070501030101 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit I've attached the email I received from Kurt. imap://richm@dredd.mcom.com:993/fetch>UID>/lcup>316?part=1.2&type=text/plain&filename=draft-ietf-ldup-lcup-xx.txt --------------080106070804070501030101 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit I've attached the email I received from Kurt.

imap://richm@dredd.mcom.com:993/fetch>UID>/lcup>316?part=1.2&type=text/plain&filename=draft-ietf-ldup-lcup-xx.txt

--------------080106070804070501030101-- --------------000907070609030003060205 Content-Type: text/plain; name="imap://richm@dredd.mcom.com:993/fetch>UID>/lcup>316?part=1.2&type=text/plain&filename=draft-ietf-ldup-lcup-xx.txt" Content-Transfer-Encoding: 8bit Content-Disposition: inline; filename="imap://richm@dredd.mcom.com:993/fetch>UID>/lcup>316?part=1.2&type=text/plain&filename=draft-ietf-ldup-lcup-xx.txt" Content-Transfer-Encoding: 8bit >From > LDAP Client Update Protocol > >1. Abstract > > This document defines the LDAP Client Update Protocol (LCUP). The > protocol is intended to allow an LDAP client to synchronize with the > content of a directory information tree (DIT) stored by an LDAP > server and to be notified about the changes to that content. > > >2. Conventions used in this document > > In the protocol flow definition, the notation C->S and S->C > specifies the direction of the data flow from the client to the > server and from the server to the client respectively. > > The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", > "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in > this document are to be interpreted as described in RFC-2119 > [KEYWORDS]. > >3. Overview > > The LCUP protocol is intended to allow LDAP clients to synchronize > with the content stored by LDAP servers. LCUP and LDAP should be spelled on on first use in body. Normative reference to draft-ietf-ldapbis-ldapv3-ts (or RFC 2251) added. > The problem areas addressed by the protocol include: > > - mobile clients that maintain a local read-only copy of the > directory data. While off-line, the client uses the local copy of > the data. When the client connects to the network, it > synchronizes with the current directory content and can be > optionally notified about the changes that occur while it is on- > line. For example, a mail client can maintain a local copy of the > corporate address book that it synchronizes with the master copy > whenever the client gets connected to the corporate network. > > - applications intending to synchronize heterogeneous data stores. > A meta directory application, for instance, would periodically > retrieve a list of modified entries from the directory, construct > the changes and apply them to a foreign data store. > > - clients that need to take certain actions when a directory entry > is modified. For instance, an electronic mail repository may want > to perform a "create mailbox" task when a new person entry is > added to an LDAP directory and a "delete mailbox" task when a > person entry is removed. > > The problem areas not being considered: > > - directory server to directory server synchronization. The IETF is > developing a LDAP replication protocol, called [LDUP], which is > specifically designed to address this problem area. LDUP should be spelled out on first use. [LDUP] should be added to a new "Informative References" section. > There are currently several protocols in use for LDAP client server > synchronization. While each protocol addresses the needs of a > particular group of clients (e.g., on-line clients or off-line > clients) none satisfies the requirements of all clients in the > target group. For instance, a mobile client that was off-line and > wants to become up to date with the server and stay up to date while > connected can't be easily supported by any of the existing > protocols. I suggest the following paragraph provide a synopsis of the LCUP design, not a comparision to LDUP. Hence, I suggest the first paragraph be deleted. > Several features of the protocol distinguish it from LDUP > replication. LCUP is designed such that the server does not need to > maintain state information on behalf of the client. The clients are > responsible for storing the information about how up to date they > are with respect to the server's content. LCUP design avoids the > need for LCUP-specific update agreements to be made between client > and server prior to LCUP use. The client decides when and from where > to retrieve the changes. LCUP design requires clients to initiate > the update session and "pull" the changes from server. Both of the following paragraphs should be incorporated into the Protocol Specification. > LCUP operations are subject to administrative and access > control policies enforced by the server. > > A part of the DIT which is enabled for LCUP is referred to as an > LCUP Context. A server may support one or more LCUP Contexts. First use of DIT (in body of memo) should be spelled out. Is a part a subtree? >4. Protocol Specification > > This section describes the protocol elements and the protocol flow. > >4.1 Universally Unique Identifiers > > Distinguished names can change, so are therefore unreliable > as identifiers. The server SHOULD assign a Universally Unique > Identifier (or UUID for short) to each entry as it is created. Does this protocol work when UUIDs are not assigned? I believe that the protocol needs to mandate use of UUID, that is, UUIDs are necessary to ensure interoperability. I suggest that instead of transferring it as an attribute (as the attribute may not be requested), that the control attached to entry responses include the UUID. Then how the server maintains the UUID becomes irrelevant. Then its okay for this schema to be only recommended. Otherwise, this schema needs to be required and the client needs to be required to always request return of this attribute and a server always required to provide it. > This identifier will be stored as an operational attribute of the entry, > named `entryUUID'. The entryUUID attribute is single valued. A > consistent algorithm for generating such universally unique > identifiers may be standardized at some point in the future. Subsequent introduction of a consistent algorithm would be problematic as existing implements might use a variety of algorithms. Fortunately there already is a algorithm which we can RECOMMEND be used here. That is, UUIDs as defined in ISO/IEC 11578:1996. Basically, the I-D should say "MUST be use unique, SHOULD be generated per ISO/IEC 11578." > The definition of the entryUUID attribute type, written using the > BNF form of AttributeDescription described in RFC 2252 [RFC2252] is: > > ( OID-To-Be-Specified > NAME `entryUUID' > DESC `universally unique entry identifier' > EQUALITY caseIgnoreMatch > SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 > SINGLE-VALUE > NO-USER-MODIFICATION > USAGE directoryOperation ) s/`/'/ Add: The directoryString (1.3.6.1.4.1.1466.115.121.1.15) syntax and the caseIgnoreMatch matching rule are defined in [RFC2252]. Also, you need to note that this schema definition is line wrapped for readability. Suggest OID-To-Be-Specified be replaced with .1 (likewise elsewhere) and then add a note to the Editor (near top of memo): [[Note to RFC-Editor: The string is to be replaced with the IANA assigned OID requested in Section X.]] Where section X is the IANA Considerations section (which should be added). I can offer text for this section if necessary (or you can use draft-zeilenga-ldap-*.txt as examples). Note that the next (and final) revision of draft-ietf-ldapbis-iana will have a "LDAP Protocol Mechansims" registry. It will be required to register OIDs of Controls and Extended Operations. Schema for entryCSN should be provided as OPTIONAL. >4.2 LCUP Cookie Value > > The LCUP protocol uses a cookie to hold the state of the client's > data with respect to the server's data. The LCUP Cookie is a value > of the following ASN.1 type: Need reference to X.680. > LCUPCookie ::= SEQUENCE { > scheme LDAPOID, > value OCTET STRING OPTIONAL > } > > scheme - this is the OID which identifies the format of the value. Spell out OID on first use. > The scheme OID, like all object identifiers, MUST be unique for a > given cookie scheme. The cookie value may be opaque or it may be > exposed to LCUP clients. For cookie schemes that expose their > value, the preferred form of documentation is an RFC. It is > expected that there will be one or more standards track cookie > schemes where the value format is exposed and described in detail. I will separately comment on cookie schemes. > value - this is the actual data describing the state of the > client's data. This value may be opaque, or its value may have > some well-known format, depending on the scheme. The cookie value > MUST be included except when a client has no stored state; i.e., > when the client is requesting a full synchronization. When the > server sends back a cookie, the cookie value MUST be present. s/a full/full/ > Further uses of the LCUP Cookie value are described below. > >4.3 Additional LDAP Result Codes defined by LCUP > > The LDAP result code names and numbers defined in the following > table are to be replaced with IANA assigned result code names and > numbers per draft-ietf-ldapbis-iana-xx.txt. I suggest the above sentence be incorporated into an "IANA Considerations" section (see draft-zeilenga-ldap-cancel-xx.txt for example). Regardless, add: Implementations of this specification SHALL recognize the following additional resultCode values: > lcupResourcesExhausted (TBD) the server is running out of > resources Seems like a general purpose service code could be returned instead. > lcupSecurityViolation (TBD) the client is suspected of malicious > actions Seems like a general purpose security code could be returned instead. > lcupInvalidCookie (TBD) invalid cookie was supplied by the > client - both/either the scheme > and/or the value part was invalid Seems like protocolError or lcupUnsupportedScheme should be returned instead. > lcupUnsupportedScheme (TBD) The scheme part of the cookie is a > valid OID but is not supported by > this server > lcupClientDisconnect (TBD) client requested search termination > using the LDAP Cancel extended > operation request [CANCEL] [CANCEL] requires the canceled resultCode be returned. > lcupReloadRequired (TBD) indicates that client data needs to > be reinitialized. This reason is > returned if the server does not > contain sufficient information to > synchronize the client or if the > server's data was reloaded since the > last synchronization session > > The uses of these codes are described below. > >4.4 Client Update Control Value > > A client initiates a synchronization session with a server by > attaching a clientUpdate control to an LDAP searchRequest message. This would be better worded: A client initiates a synchronization session with a server by issuing an LDAP searchRequest with includes a clientUpdate control. > The client SHOULD specify entryUUID in the attributes list in the > searchRequest message. The search specification determines the part > of the directory information tree (DIT) the client wishes to > synchronize with, the set of attributes it is interested in and the > amount of data the client is willing to receive. The clientUpdate > control contains the client's synchronization specification. The > controlType field for the clientUpdate control is > ClientUpdateControlOID (to be assigned). The controlValue is an > OCTET STRING, whose contents are the bytes of the BER encoding of > the following: Reference to X.690 here. Also, the control should be encoded per Section 5.1 of RFC 2251. > ClientUpdateControlValue ::= SEQUENCE { > updateType ENUMERATED { > synchronizeOnly (0), > synchronizeAndPersist (1), > persistOnly (2) }, > sendCookieInterval INTEGER OPTIONAL, > cookie LCUPCookie OPTIONAL > } > > updateType - specifies the type of update requested by the client > > synchronizeOnly - the server sends all the data needed to > synchronize the client with the server, then closes the > connection > > synchronizeAndPersist - the server sends all the data needed to > synchronize the client with the server, then leaves open the > connection, sending to the client any new added, modified, or > deleted entries that satisfy the search criteria. > > persistOnly - the server does not synchronize the data with the > client but leaves open the connection and sends over any new > added, modified, or deleted entries that satisfy the search > criteria. > > sendCookieInterval û (optional) the server SHOULD send the cookie s/û/-/ (ASCII) SHOULD misused here. This should define the semantics of the field. The RECOMMENDATION that servers implement this semantic should be stated separately. > back in the entryUpdate control value for every > sendCookieInterval number of SearchResultEntry PDUs returned to > the client. For example, if the value is 5, the server SHOULD > send the cookie back in the entryUpdate control value for every 5 > search results returned to the client. If this value is absent, > zero or less than zero, the server chooses the interval. > > cookie - a value that represents the current state of the client's > data. If a cookie is provided, the server MUST use the enclosed > scheme throughout the duration of the LCUP session or until an > LCUP context boundary is crossed, since a new cookie may be > required in that case. If the value or scheme part of the cookie > is invalid, the server MUST return immediately with a > SearchResultDone message with the resultCode set to the value of > lcupInvalidCookie. If the scheme part of the cookie is a valid > OID, but is not supported, the server MUST return immediately > with a SearchResultDone message with the resultCode set to the > value of lcupUnsupportedScheme. > > If the cookie is omitted, the server MAY use any scheme it > supports. > >4.5 Entry Update Control Value > > In response to the client's synchronization request, the server > returns one or more SearchResultEntry PDU that fits the client's > specification. Each SearchResultEntry PDU also contains an > entryUpdateControl that describes the LCUP state of the returned > entry. To represent a deleted entry, the server attaches an > entryUpdate control to the corresponding SearchResultEntry. The > SearchResultEntry corresponding to a deleted entry MUST contain a > valid DN and SHOULD contain a valid UUID but, to reduce the amount > of data sent to the client, it SHOULD not contain any other > attributes. s/SHOULD/MUST/ The DN provided may not be same as known previously to the client. Hence, the UUID is necessary to communicate exactly which entry needs to be deleted. Additionally, the client needs to be warned that a new entry with same DN may have been created and, as changes may be sent out of order, may receive the new entry before the old entry is deleted. > Furthermore, the server may elect to periodically return to the > client the cookie that represents the state of the client's data. How does the server send a new cookie when it has no entry to send? > This information is useful in case the client crashes or gets > disconnected. The client MAY specify how often to receive the cookie > by the use of the sendCookieInterval in the clientUpdate control > value (see above). If the client does not specify a value, the > server will determine the interval. > > The controlType field for the entryUpdate control is > EntryUpdateControlOID (to be assigned). The controlValue is an > OCTET STRING, whose contents are the bytes of the BER encoding of > the following: BER per Section 5.1 of RFC 2251, please. Add reference to X.690. > EntryUpdateControlValue ::= SEQUENCE { > stateUpdate BOOLEAN, > entryDeleted BOOLEAN, > cookie LCUPCookie OPTIONAL > } BOOLEANs should have default values and be optional. Only sent if value isn't default. > stateUpdate - if set to TRUE, indicates that the entry to which the > control is attached contains no changes and it is sent only to > communicate to the client the new cookie. In this case, the > entryDeleted field MUST be ignored and the cookie field MUST > contain the updated cookie. This feature allows updating the > client's cookie when there are no changes that effect the > client's data store. Note that the control MUST be attached to a > valid SearchResultEntry, which should contain a valid LDAPDN in > the objectName field, and MAY contain an entryUUID attribute, but > SHOULD NOT contain any other attributes. The server MAY send the > entry named by the baseObject from the client's search request. > > entryDeleted - if set to TRUE, indicates that the entry to which > the control is attached was deleted. The server MAY also set > this to TRUE if the entry has left the client's search result > set. As far as the client is concerned, a deleted entry is no > different than an entry that has left the result set. > > cookie - the LCUP cookie value that represents the current state of > the client's data. > >4.6 Client Update Done Control Value > > When the server has finished processing the client's request, it > attaches a clientUpdateDone control to the SearchResultDone message > and sends it to the client. However, if the SearchResultDone message > contains a resultCode that is not success or lcupClientDisconnect, > > > > the clientUpdateDone control MAY be omitted. The controlType field > for the clientUpdateDone control is ClientUpdateDoneControlOID (to > be assigned). The controlValue is an OCTET STRING, whose contents > are the bytes of the BER encoding of the following: > > ClientUpdateDoneControlValue ::= SEQUENCE { > cookie LCUPCookie OPTIONAL > } > > cookie - the LCUP cookie value that represents the current state of > the client's data. Although this value is OPTIONAL, it MUST be set > in the ClientUpdateDoneControlValue if the SearchResultDone > resultCode is success or lcupClientDisconnect. This provides a > good "checksum" of what the server thinks the state of the client > is. If some error occurred, either an LDAP search error (e.g. > insufficientAccessRights) or an LCUP error (e.g. > lcupUnsupportedScheme), the cookie MAY be omitted. > > If server resources become tight, the server can terminate one or > more search operations by sending a SearchResultDone message to the > client(s) with a resultCode of lcupResourcesExhausted. Unless the > client sets the updateType field to persistOnly, the server attaches > a clientUpdateDone control that contains the cookie that corresponds > to the current state of the client's data. A server set policy is > used to decide which searches to terminate. This can also be used as > a security mechanism to disconnect clients that are suspected of > malicious actions, but if the server can infer that the client is > malicious, the server should return lcupSecurityViolation instead. > >4.7 Client Initiated Termination > > If the client needs to terminate the synchronization process and it > wishes to obtain the cookie that represents the current state of its > data, it issues an LDAP Cancel operation [CANCEL]. The server > responds immediately with a LDAP Cancel response [CANCEL]. The > server MAY send any pending SearchResultEntry PDUs if the server > cannot easily abort or remove those search results from its outgoing > queue. The server SHOULD send as few of these remaining > SearchResultEntry PDUs as possible. Finally, the server sends the > message SearchResultDone with the clientUpdateDone control attached. > > If the client is not interested in the state information, it can > simply abandon the search operation or disconnect from the server. > >4.8 Protocol Flow > > The client server interaction can proceed in three different ways > depending on the client's requirements. Protocol flows beginning > with an asterisk (*) are optional or conditional. > > If the client's intent is not to synchronize data but to trigger > actions in response to directory modifications, the protocol > proceeds as follows: > > C->S Sends a search operation with a clientUpdate control attached. > The search specification determines the part of the DIT the > client wishes to synchronize with and the set of attributes it > is interested in. The updateType field of the control value > should be set to persistOnly. > *S->C If there is an error (invalid search scope, invalid cookie) > the server returns the appropriate error codes and terminates > the request (SearchResultDone message with optional > clientUpdateDone control) > S->C Sends change notification to the client for each change to the > data within the client's search specification. Each > SearchResultEntry may have an entryUpdate control attached. > *S->C If the server starts to run out of resources or the client is > suspected of malicious actions, the server SHOULD terminate > the search operation by sending to the client a > SearchResultDone message with optional clientUpdateDone > control attached. The resultCode in the SearchResultDone > mesasge SHOULD be set to lcupResourcesExhausted or > lcupSecurityViolation depending on the reason for termination. > *C->S If the client receives lcupResourcesExhausted error from the > server, it MUST wait for a while before attempting another > synchronization session with the server. It is RECOMMENDED > that clients use an exponential backoff strategy. > C->S The client terminates the search. The client can do this by > abandoning the search operation, disconnecting from the > server, or by sending an LDAP Cancel operation. > *S->C If the server receives the LDAP Cancel op, it will immediately > send back the LDAP Cancel response > *S->C If the server sent the LDAP Cancel response, the server MAY > send any pending SearchResultEntry PDUs in its outgoing queue > *S->C If the server sent the LDAP Cancel response, after the server > sends the response and any pending SearchResultEntry PDUs, the > server sends the SearchResultDone message with the > clientUpdateDone control attached. The resultCode in the > SearchResultDone message will be either lcupClientDisconnect > or some LDAP error code (not success). > S->C Stops sending changes to the client and closes the connection. > > If the client's intent is to synchronize with the server and then > disconnect, the protocol proceeds as follows: > > C->S Sends a search operation with the clientUpdate control > attached. The search specification determines the part of the > DIT the client wishes to synchronize with, the set of > attributes it is interested in and the amount of data the > client is willing to receive. If this is the initial > synchronization session, the client either does not provide a > cookie or provides a cookie with no value; otherwise, the > cookie field of the control is set to the cookie received from > the server at the end of the last synchronization session. If > the scheme field of the cookie was provided, the server MUST > use that scheme throughout the duration of the LCUP session or > until an LCUP boundary is crossed, since the server will > usually require a different cookie in that case anyway. (Note > > > > that the client can synchronize with different servers during > different synchronization sessions.) The updateType field of > the control value is set to synchronizeOnly. > *S->C If there is an error (invalid search scope, invalid cookie) > the server returns the appropriate error codes and terminates > the request (SearchResultDone message with optional > clientUpdateDone control) > *S->C If no cookie is specified in the clientUpdate control, or if > the value field of the cookie is empty, the server sends all > data that matches the client's search specification followed > by the SearchResultDone message with a clientUpdateDone > control attached. The control contains the cookie that > corresponds to the current state of the client's data. If > synchronization was successful, the resultCode in the > SearchResultDone message should be success. > *S->C If an invalid cookie is specified, the server sends the > SearchResultDone message with the resultCode set to > lcupInvalidCookie. > *S->C If a valid cookie is specified and the data that matches the > search specification has been reloaded or the server does not > contain enough state information to synchronize the client, > the server sends a SearchResultDone message with the > resultCode set to lcupReloadRequired. > *S->C If the cookie is valid and the client is up to date, the > server sends a success response to the client. > S->C If the cookie is valid and there is data to be sent, the > server sends the modified entries to the client. Each > SearchResultEntry contains the attributes requested by the > client in the search specification regardless of whether they > were modified. An entryUpdate control with the entryDeleted > field set to TRUE MUST be attached to every deleted entry. The > server may also periodically attach an entryUpdate control to > the entries sent to the client to indicate the current state > of the client's data. In that case, the cookie field of the > control represents the state of the client's data including > the entry to which the control is attached. Once all the > changes are sent successfully, the server sends a > SearchResultDone with the clientUpdateDone control attached. > The control contains the cookie that represents the current > state of the client's data. The resultCode in the > SearchResultDone message is set to success. If the resultCode > is not success, the server may OPTIONALLY attach the > clientUpdateDone control to the SearchResultDone message. > The client stores the cookie received from the server until > the next synchronization session. > *C->S If the resultCode in the SearchResultDone message is set > lcupReloadRequired, the client clears its data store and > repeats the synchronization process by sending the search > operation with clientUpdate control that contains no cookie, > or that contains a cookie with no value field. > > If the client's intent is to be synchronized with the server and > stay notified about data modifications, the protocol proceeds as > follows: > > > > > C->S The client behaves exactly as in the previous case except it > sets the updateType field in the control value to > synchronizeAndPersist. > S->C The server behaves exactly as in the previous case except the > connection is kept open after the initial set of changes is > sent to the client. A SearchResultDone message is not sent to > the client; instead, the server keeps sending changes to the > client. > *S->C If the server starts to run out of resources or the client is > suspected of malicious actions, the server SHOULD terminate > the search operation by sending to the client a > SearchResultDone message with the resultCode set to > lcupResourcesExhausted or lcupSecurityViolation depending on > the reason for termination. > *C->S If the client receives lcupResourcesExhausted error from the > server, it MUST wait for a while before attempting another > synchronization session with the server. We recommend > exponential backoff strategy. > C->S Sends an LDAP Cancel operation to the server to terminate the > synchronization session. > S->C Responds with an LDAP Cancel response, followed optionally by > SearchResultEntry PDUs, followed by a SearchResultDone with > the clientUpdateDone control optionally attached. If the > control is present, it contains the cookie that represents the > current state of the client's data. The value of the > resultCode in the SearchResultDone message will be either > lcupClientDisconnect or some other LDAPResult resultCode (not > success). The control may not be present if some error > occurred. > >4.9 Size and Time Limits > > The search request size or the time limits can only be imposed for > non-persistent operations, those that set the updateType field of > the ClientUpdateControlValue to synchronizeOnly (for the entire > operation) or synchronizeAndPersist (for the initial synchronization > phase only). All other operations MUST set both limits to 0. The > server SHOULD ignore the limits set for persistent operations. Why? It seems quite reasonable for implementations to support size and time limits during persistent operations. >4.10 Changes vs. Operations > > A server that supports UUIDs SHOULD communicate a modifyDN > operation by sending the client the current form of the entry (with > its new DN) along with an entryUUID attribute. A server that does > not support UUIDs SHOULD communicate a modifyDN operation by sending > the client a deletion for the previous DN followed by an entry for > the new DN. Note that for servers that do not support UUIDs, no > guarantees are made about the correctness of the client state in the > presence of modifyDN operations. Hence, UUIDs support should be mandated. > Communicating modifyDN operations by sending a delete of the old DN > followed by an entry with the new DN makes it impossible for an LCUP > client to distinguish between a modifyDN operation, which is one > atomic operation, and an delete operation followed by an add of a > new entry. The loss of information about atomicity may cause > problems for some LCUP clients. For example, when an entry is > renamed, a client that manages resources such as a person's mailbox > might delete the mailbox and everything in it instead of merely > changing the name associated with the mailbox. > > Also note that regardless of how a modifyDN operation is > communicated to the client, if the client state shows that the > object that underwent the modifyDN operation was the root of a > subtree, the client MUST infer that the DNs of all objects in the > subtree have changed such that they reflect the new DN of the > subtree root. This is problematic and may lead to incorrect synchronization. Consider a subtree at base cn=A, with child cn=B,cn=A, which is moved to cn=C. Then new entry is added at cn=A and child cn=B,cn=C moved back to cn=B,cn=A. If the entry for the rename of the child is sent previous to the rename of the parent, then the client would not pick up on the move. I don't have a solution to offer... yet. >4.11 Operations on the Same Connection > > It is permissible for the client to issue other LDAP operations on > the connection used by the protocol. Since each LDAP > request/response carries a message id there will be no ambiguity > about which PDU belongs to which operation. By sharing the > connection among multiple operations, the server will be able to > conserve its resources. > >4.12 Interactions with Other LDAP Search and Response Controls This section is not consistent with RFC 2251. > LCUP defines neither restrictions nor guarantees about the ability > to use the LDAP client update control defined in this document in > conjunction with other LDAP controls, except for the following: A > server MAY ignore non-critical controls supplied with the LCUP > control. A server MAY ignore the LCUP control if it is non-critical > and it is supplied with other critical controls. If the server recongize the control, it MUST make use of it. If the client provides a set of recongized controls which don't make sense to the client, the server should return an error. > If a server > receives a critical LCUP control with another critical control, and > the server does not support both controls at the same time, the > server SHOULD return unavailableCriticalExtension. s/SHOULD/MUST/ How does this control interact with existing search controls? Paging? Sorting? Matched Values? Duplicate entries? etc. >5. Additional Features > > There are several features present in other protocols or considered > useful by clients that are currently not included in the protocol > primarily because they are difficult to implement on the server. > These features are briefly discussed in this section. This section > is intended to open a discussion on the merits of including and > approaches to implementing these features. > >5.1 Triggered Search Change Type > > This feature is present in the Triggered Search specification. Add informative reference. > A flag is attached to each entry returned to the client indicating the > reason why this entry is returned. The possible reasons from the > draft are > "- notChange: the entry existed in the directory and matched the > search at the time the operation is being performed, > - enteredSet: the entry entered the result, > - leftSet: the entry left the result, > - modified: the entry was part of the result set, was modified or > renamed, and still is in the result set." > > The leftSet feature is particularly useful because it indicates to > the client that an entry is no longer within the client's search > specification and the client can remove the associated data from its > data store. Ironically, this feature is the hardest to implement on > the server because the server does not keep track of the client's > state and has no easy way of telling which entries moved out of > scope between synchronization sessions with the client. > > A compromise could be reached by only providing this feature for the > operations that occur while the client is connected to the server. > This is easier to accomplish because the decision about the change > type can be made based only on the change without need for any > historical information. This, however, would add complexity to the > protocol. > >5.2 Persistent Search Change Type > > This feature is present in the Persistent Search specification. Add informative reference. > Persistent search has the notion of changeTypes. The client > specifies which type of updates will cause entries to be returned, > and optionally whether the server tags each returned entry with the > type of change that caused that entry to be returned. > > For LCUP, the intention is full synchronization, not partial. Each > entry returned by an LCUP search will have some change associated > with it that may concern the client. The client may have to have a > local index of entries by DN or UUID to determine if the entry has > been added or just modified. It is easy for clients to determine if > the entry has been deleted because the entryDeleted value of the > entryUpdateControl will be TRUE. > >5.3 Sending Changes > > Some earlier synchronization protocols sent the client(s) only the > modified attributes of the entry rather than the entire entry. While > this approach can significantly reduce the amount of data returned > to the client, it has several disadvantages. First, unless a > separate mechanism (like the change type described above) is used to > notify the client about entries moving into the search scope, > sending only the changes can result in the client having an > incomplete version of the data. Let's consider an example. An > attribute of an entry is modified. As a result of the change, the > entry enters the scope of the client's search. If only the changes > are sent, the client would never see the initial data of the entry. > Second, this feature is hard to implement since the server might not > contain sufficient information to construct the changes based solely > on the server's state and the client's cookie. On the other hand, > this feature can be easily implemented by the client assuming that > the client has the previous version of the data and can perform > value by value comparisons. > > > > >5.4 Data Size Limits > > Some earlier synchronization protocols allowed clients to control > the amount of data sent to them in the search response. This feature > was intended to allow clients with limited resources to process > synchronization data in batches. However, an LDAP search operation > already provides the means for the client to specify the size limit > by setting the sizeLimit field in the SearchRequest to the maximum > number of entries the client is willing to receive. While the > granularity is not the same, the assumption is that regular LDAP > clients that can deal with the limitations of the LDAP protocol will > implement LCUP. But LCUP places undue restrictions on size and time limits... >5.5 Data Ordering > > Some earlier synchronization protocols allowed a client to specify > that parent entries should be sent before the children for add > operations and children entries sent before their parents during > delete operations. This ordering helps clients to maintain a > hierarchical view of the data in their data store. While possibly > useful, this feature is relatively hard to implement and is > expensive to perform. > >6. Client Side Considerations > > Clients SHOULD always specify entryUUID in the SearchRequest > attribute list. > > The cookie received from the server after a synchronization session > can only be used with the same or more restrictive search > specification than the search that generated the cookie. The server > will reject the search operation with a cookie that does not satisfy > this condition. This is because the client can end up with an > incomplete data store otherwise. A more restrictive search > specification is the one that generates a subset of the data > produced by the original search specification. > > Because an LCUP client specifies the area of the tree with which it > wishes to synchronize through the standard LDAP search > specification, the client can be returned noSuchObject error if the > root of the synchronization area was renamed between the > synchronization sessions or during a synchronization session. If > this condition occurs, the client can attempt to locate the root by > using the root's UUID saved in client's local data store. It then > can repeat the synchronization request using the new search base. In > general, a client can detect that an entry was renamed and apply the > changes received to the right entry by using the UUID rather than DN > based addressing. > > Each active persistent operation requires that an open TCP > connection be maintained between an LDAP client and an LDAP server > that might not otherwise be kept open. Therefore, client > implementors are encouraged to avoid using persistent operations for > non-essential tasks and to close idle LDAP connections as soon as > practical. The server may close connections if server resources > become tight. > > The client MAY receive a continuation reference > (SearchResultReference [RFC2251 SECTION 4.5.3]) if the search > request spans multiple parts of the DIT, some of which may require a > different LCUP cookie, some of which may not even be managed by > LCUP. The client SHOULD maintain a cache of the LDAP URLs returned > in the continuation references and the cookies associated with them. > The client is responsible for performing another LCUP search to > follow the references, and SHOULD use the cookie corresponding to > the LDAP URL for that reference (if it has a cookie). Are servers allowed to send continuation references at anytime? How do they notify the client that a reference presently sent has been modified or deleted? Seems to me, like aliases, it may be best to say LCUP control implies ManageDsaIT (at least when it comes to subordinate references). > The client may receive a referral (Referral [RFC2251 SECTION > 4.1.11]) when the search base is a subordinate reference, and this > will end the operation. A referral can be returned for many reasons. Also, it should be stated that the client may chase the referral and, in doing so, initiates a new LCUP synchronization operation. > For alias dereferencing, the server will behave as if the client had > requested neverDerefAliases or derefFindingBaseObj as the > derefAliases field in the search request [RFC2251, Section 4.5.1]. > If the client specifies a value other than neverDerefAliases or > derefFindingBaseObj, the server will return protocolError to the > client. The first sentence is oddly worded. I suggest the paragraph be replaced with: LCUP design does not consider issues assoicated with alias dereferencing in search. Clients MUST specify derefAliases as either neverDerefAliases or derefFindingBaseObj. Servers are to return protcolError if the client specifies either derefInSearching or derefAlways. > > Changes to data (e.g., that might affect the LCUP client's filter or > scope) or meta-data (e.g., that might affect the client's read > access) may affect the presence of entries in the search set. > Servers MAY notify LCUP clients of changes to the search set that > result from such changes, but an LCUP client MUST NOT assume that > such notification will occur. Therefore, in the case where a client > is maintaining a cache of entries using LCUP, the data held by the > client may be a superset or a subset of the entries that would be > returned by a new search request. For example, if access control > meta information is changed to deny access to particular entries in > the search result set, and the access control information is outside > of the search scope (e.g., in a parent entry), the client may have > entries stored locally which are no longer part of its desired > search set. Similarly, if entries are added to the search result > set due to changes in meta-data, the client's cache of entries may > not include these entries. > > Some clients may wish to perform an initial synchronization in order > to prime a cache or establish a baseline set of entries, then look > for changes after that. The recommended way to do this is to first > issue an LCUP search with the updateType field of the clientUpdate > control value set to synchronizeOnly, then after that search > successfully completes, immediately issue an LCUP search with the > updateType field of the clientUpdate control value set to > synchronizeAndPersist. > > Some clients may have unreliable connections, for example, a > wireless device or a WAN connection. These clients may want to > insure that the cookie is returned often in the entryUpdate control > value, so that if they have to reconnect, they do not have to > process many redundant entries. These clients should set the > sendCookieInterval in the clientUpdate control value to a low > number, perhaps even 1. Also, some clients may have a limited > bandwidth connection, and may not want to receive the cookie very > often, or even at all (however, the cookie is always sent back in > the clientUpdateDone control value upon successful completion). > These clients should set the sendCookieInterval in the clientUpdate > control value to a high number. > >7. Server Implementation Considerations > > Servers SHOULD support UUIDs. Otherwise, it will be very difficult > to support modifyDN operations. Adding support for UUIDs should be > seen as a necessary component of LCUP. s/SHOULD/MUST/ > By design, the protocol supports multiple cookie schemes. This is > to allow different implementations the flexibility of storing any > information applicable to their environment. A reasonable > implementation for an LDUP compliant server would be to use the > Replica Update Vector (RUV). For each master, RUV contains the > largest CSN seen from this master. In addition, the RUV implemented > by some directory servers (not yet in LDUP) contains replica > generation - an opaque string that identifies the replica's data > store. The replica generation value changes whenever the replica's > data is reloaded. Replica generation is intended to signal the > replication/synchronization peers that the replica's data was > reloaded and that all other replicas need to be reinitialized. RUV > satisfies the three most important properties of the cookie: (1) it > uniquely identifies the state of client's data, (2) it can be used > to synchronize with multiple servers, and (3) it can be used to > detect that the server's data was reloaded. > > A server may support one or more LCUP cookie schemes. It is > expected that schemes will be published along with their OIDs as > RFCs. If a client initiates an LCUP session with a particular > scheme, the server MUST use that same scheme throughout the LCUP > session, or until an LCUP context boundary is crossed, in which case > the server will usually require a different cookie anyway. > > In addition, the cookie must contain enough information to allow the > server to determine whether the cookie can be safely used with the > search specification it is attached to. As discussed earlier in the > document, the cookie can only be used with the search specification > that is equally or more restrictive than the one for which the > cookie was generated. > > An implementation must make sure that it can correctly update the > client's cookie when there is a size limit imposed on the search > results by either the client's request or by the server's > configuration. If RUV is used as the cookie, entries last modified > by a particular master must be sent to the client in the order of > their last modified CSN. This ordering guarantees that the RUV can > be updated after each entry is sent. > > The server's DIT may be partitioned into different sections which > may have different cookies associated with them. For example, some > servers may use some sort of replication mechanism to support LCUP. > If so, the DIT may be partitioned into multiple replicas. A client > may send an LCUP search request that spans multiple replicas. Some > parts of the DIT spanned by the search request scope may be managed > by LCUP and some may not. A part of the DIT which is enabled for > LCUP is referred to as an LCUP Context. The server SHOULD send a > SearchResultReference [RFC2251, SECTION 4.5.3] when the LCUP Context > for a returned entry changes. The server SHOULD return all entries > for a particular LCUP Context before returning a reference to other > LCUP Contexts or non-LCUP enabled parts of the DIT, in order to > minimize the processing burden on the clients. The LDAP URL(s) > returned MUST contain the DN(s) of the base of another section of > the DIT (however the server implementation has partitioned the DIT). > The client will then issue another LCUP search using the LDAP URL > returned. Each section of the DIT MAY require a different cookie > value, so the client SHOULD maintain a cache, mapping the different > LDAP URL values to different cookies. If the cookie changes, the > scheme may change as well, but the cookie scheme MUST be the same > within a given LCUP Context. > > An implementation SHOULD notify the client about all entries deleted > from the search set since the client's last session, but an LCUP > client MUST NOT assume that such notification will occur. For > example, the server might not notify the client of the deletion of > an object if the object left the search set following the client's > last synchronization and prior to the object's deletion. An LDUP > compliant implementation can achieve this through the use of entry > tombstones. The implementation should avoid aggressive tombstone > purging since lack of tombstones would cause client's data to be > reloaded. We suggest that only the tombstone content be removed > during the regular trimming cycle while tombstones themselves are > discarded much less frequently. > > The specification makes no guarantees about how soon a server should > send notification of a changed entry to the client when the > connection between the client and the server is kept open. This is > intentional as any specific maximum delay would be impossible to > meet in a distributed directory service implementation. Server > implementors are encouraged to minimize the delay before sending > notifications to ensure that clients' needs for timeliness of change > notification are met. > > Implementors of servers that support the mechanism described in this > document should ensure that their implementation scales well as the > number of active persistent operations and the number of changes > made in the directory increases. Server implementors are also > encouraged to support a large number of client connections if they > need to support large numbers of persistent operations. > >8. Synchronizing Heterogeneous Data Stores > > Clients, like a meta directory join engine, synchronizing multiple > writable data stores will only work correctly if each piece of > information is single mastered (for instance, only by an LDUP > compliant directory). This is because different systems have > different notions of time and different update resolution > procedures. As a result, a change applied on one system can be > discarded by the other, thus preventing the data stores from > converging. > >9. Security Considerations > > In some situations, it may be important to prevent general exposure > of information about changes that occur in an LDAP server. > Therefore, servers that implement the mechanism described in this > document SHOULD provide a means to enforce access control on the > entries returned and MAY also provide specific access control > mechanisms to control the use of the controls and extended > operations defined in this document. > > As with normal LDAP search requests, a malicious client can initiate > a large number of persistent search requests in an attempt to > consume all available server resources and deny service to > legitimate clients. The protocol provides the means to stop > malicious clients by disconnecting them from the server. The servers > that implement the mechanism SHOULD provide the means to detect the > malicious clients. In addition, the servers SHOULD provide the means > to limit the number of resources that can be consumed by a single > client. > > Access control on the data can be modified in such a way that the > data is no longer visible to the client. The specification does not > specify how the server should handle this condition. Moreover, data > consistency is not guaranteed if access control is changed from a > more restrictive to a less restrictive one. This is because access > control can be considered as an additional filter on the search > specification and the protocol does not support going from a more to > a less restrictive search specification. See Client Side > Considerations Section for more detailed explanation of the problem. > >10. Normative References > > [KEYWORDS] S. Bradner, "Keywords for use in RFCs to Indicate > Requirement Levels", RFC 2119, March 1997. > > [RFC2251] M. Wahl, T. Howes, S. Kille "Lightweight Directory > Access Protocol", RFC 2251, December 1997. > > [RFC2252] M. Wahl, A. Coulbeck, T. Howes, S. Kille, "Lightweight > Directory Access Protocol (v3): Attribute Syntax > Definitions", RFC 2252, December 1997. > > [CANCEL] K. Zeilenga, "LDAP Cancel Extended Operation", > draft-zeilenga-ldap-cancel-xx.txt, a work in progress. --------------000907070609030003060205-- --------------ms090702080503030000030203 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIK6DCC A4MwggLsoAMCAQICAlukMA0GCSqGSIb3DQEBBAUAMIGTMQswCQYDVQQGEwJVUzELMAkGA1UE CBMCQ0ExFjAUBgNVBAcTDU1vdW50YWluIFZpZXcxGzAZBgNVBAoTEkFtZXJpY2EgT25saW5l IEluYzEZMBcGA1UECxMQQU9MIFRlY2hub2xvZ2llczEnMCUGA1UEAxMeSW50cmFuZXQgQ2Vy dGlmaWNhdGUgQXV0aG9yaXR5MB4XDTAyMDUzMDE4MDMzOFoXDTAyMTEyNjE4MDMzOFowfTEL MAkGA1UEBhMCVVMxGzAZBgNVBAoTEkFtZXJpY2EgT25saW5lIEluYzEVMBMGCgmSJomT8ixk AQETBXJpY2htMSEwHwYJKoZIhvcNAQkBFhJyaWNobUBuZXRzY2FwZS5jb20xFzAVBgNVBAMT DlJpY2ggTWVnZ2luc29uMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQC2a3aAuvsFm17d ZvHQwqxJb5wk1vNxdJOr8WhMunW9m8uKFDVqbJPZWGfyugV0bADQcez4BHq5/eqpiOwft8QF 4unGHyWFIQzqQFmND7pAdEUv5CT4HgpIFrsxn/84NupZJ2JAdudPP0Pa542m1wv7+Uq8pow2 waljZI00z9/xKQIDAQABo4H6MIH3MB0GA1UdJQQWMBQGCCsGAQUFBwMCBggrBgEFBQcDBDAO BgNVHQ8BAf8EBAMCBeAwQwYJYIZIAYb4QgENBDYWNElzc3VlZCBieSBOZXRzY2FwZSBDZXJ0 aWZpY2F0ZSBNYW5hZ2VtZW50IFN5c3RlbSA0LjUwHQYDVR0RBBYwFIEScmljaG1AbmV0c2Nh cGUuY29tMB8GA1UdIwQYMBaAFCnbsi2Dfn+LI7vCzGa5Oegp8wKGMEEGCCsGAQUFBwEBBDUw MzAxBggrBgEFBQcwAYYlaHR0cDovL2NlcnRpZmljYXRlcy5uZXRzY2FwZS5jb20vb2NzcDAN BgkqhkiG9w0BAQQFAAOBgQBK3Wgmiix5FP5IFXudFvuCTG1hIP9OqAPvF1UCcOqHddQoyaei T8261hqpU1wM/AIW7OPnfeaaDS2xqx3vdE9GFg4FXaO25FRb+NrMQNvaCBQn98Nv66hQqf1R I2h2aAWKYgryRdd/WBL9Xb7fueDmHcYQ+TMP41xZRFRbJbAhBzCCA4MwggLsoAMCAQICAluk MA0GCSqGSIb3DQEBBAUAMIGTMQswCQYDVQQGEwJVUzELMAkGA1UECBMCQ0ExFjAUBgNVBAcT DU1vdW50YWluIFZpZXcxGzAZBgNVBAoTEkFtZXJpY2EgT25saW5lIEluYzEZMBcGA1UECxMQ QU9MIFRlY2hub2xvZ2llczEnMCUGA1UEAxMeSW50cmFuZXQgQ2VydGlmaWNhdGUgQXV0aG9y aXR5MB4XDTAyMDUzMDE4MDMzOFoXDTAyMTEyNjE4MDMzOFowfTELMAkGA1UEBhMCVVMxGzAZ BgNVBAoTEkFtZXJpY2EgT25saW5lIEluYzEVMBMGCgmSJomT8ixkAQETBXJpY2htMSEwHwYJ KoZIhvcNAQkBFhJyaWNobUBuZXRzY2FwZS5jb20xFzAVBgNVBAMTDlJpY2ggTWVnZ2luc29u MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQC2a3aAuvsFm17dZvHQwqxJb5wk1vNxdJOr 8WhMunW9m8uKFDVqbJPZWGfyugV0bADQcez4BHq5/eqpiOwft8QF4unGHyWFIQzqQFmND7pA dEUv5CT4HgpIFrsxn/84NupZJ2JAdudPP0Pa542m1wv7+Uq8pow2waljZI00z9/xKQIDAQAB o4H6MIH3MB0GA1UdJQQWMBQGCCsGAQUFBwMCBggrBgEFBQcDBDAOBgNVHQ8BAf8EBAMCBeAw QwYJYIZIAYb4QgENBDYWNElzc3VlZCBieSBOZXRzY2FwZSBDZXJ0aWZpY2F0ZSBNYW5hZ2Vt ZW50IFN5c3RlbSA0LjUwHQYDVR0RBBYwFIEScmljaG1AbmV0c2NhcGUuY29tMB8GA1UdIwQY MBaAFCnbsi2Dfn+LI7vCzGa5Oegp8wKGMEEGCCsGAQUFBwEBBDUwMzAxBggrBgEFBQcwAYYl aHR0cDovL2NlcnRpZmljYXRlcy5uZXRzY2FwZS5jb20vb2NzcDANBgkqhkiG9w0BAQQFAAOB gQBK3Wgmiix5FP5IFXudFvuCTG1hIP9OqAPvF1UCcOqHddQoyaeiT8261hqpU1wM/AIW7OPn feaaDS2xqx3vdE9GFg4FXaO25FRb+NrMQNvaCBQn98Nv66hQqf1RI2h2aAWKYgryRdd/WBL9 Xb7fueDmHcYQ+TMP41xZRFRbJbAhBzCCA9YwggM/oAMCAQICBAIAAeYwDQYJKoZIhvcNAQEF BQAwRTELMAkGA1UEBhMCVVMxGDAWBgNVBAoTD0dURSBDb3Jwb3JhdGlvbjEcMBoGA1UEAxMT R1RFIEN5YmVyVHJ1c3QgUm9vdDAeFw0wMTA2MDExMjQ3MDBaFw0wNDA2MDEyMzU5MDBaMIGT MQswCQYDVQQGEwJVUzELMAkGA1UECBMCQ0ExFjAUBgNVBAcTDU1vdW50YWluIFZpZXcxGzAZ BgNVBAoTEkFtZXJpY2EgT25saW5lIEluYzEZMBcGA1UECxMQQU9MIFRlY2hub2xvZ2llczEn MCUGA1UEAxMeSW50cmFuZXQgQ2VydGlmaWNhdGUgQXV0aG9yaXR5MIGfMA0GCSqGSIb3DQEB AQUAA4GNADCBiQKBgQDi718sdkOJSxpfs+X4qm+LL4FNZ/+9Sg9jLsTchfaeLEkmIP8AF+SI iGne/YNX4KMRGRGq1ty877PSFS5Uxm58v9m5w0bTCQWE5VNcSO2EhZoOOz0WB1zws3mrmhCl vMGk0XhMBuVkQfwFJWMm6+8Mx25UoYzOVFe2H5LashJLjQIDAQABo4IBgjCCAX4wTQYDVR0f BEYwRDBCoECgPoY8aHR0cDovL3d3dzEudXMtaG9zdGluZy5iYWx0aW1vcmUuY29tL2NnaS1i aW4vQ1JML0dURVJvb3QuY2dpMB0GA1UdDgQWBBQp27Itg35/iyO7wsxmuTnoKfMChjBmBgNV HSAEXzBdMEYGCiqGSIb4YwECAQUwODA2BggrBgEFBQcCARYqaHR0cDovL3d3dy5iYWx0aW1v cmUuY29tL0NQUy9PbW5pUm9vdC5odG1sMBMGAyoDBDAMMAoGCCsGAQUFBwIBMFgGA1UdIwRR ME+hSaRHMEUxCzAJBgNVBAYTAlVTMRgwFgYDVQQKEw9HVEUgQ29ycG9yYXRpb24xHDAaBgNV BAMTE0dURSBDeWJlclRydXN0IFJvb3SCAgGjMCsGA1UdEAQkMCKADzIwMDEwNjAxMTI0NzMw WoEPMjAwMzA5MDEyMzU5MDBaMA4GA1UdDwEB/wQEAwIBBjAPBgNVHRMECDAGAQH/AgEBMA0G CSqGSIb3DQEBBQUAA4GBAEpiDtn6RncECmwN3f7SIjmZEAquiC2GPVeE5hIkN2n7WV7iEbD5 n6RXhoppHwZj0X3uMzZJECAPH5cXLCdsPWw5BHviReiHG1S2YEFtHa4F8535OjSa43trTHH4 66grg7A1kEwZaHHt8GMiXsJb7CB6tbBRc+kH7oFndnlT95XUMYICpjCCAqICAQEwgZowgZMx CzAJBgNVBAYTAlVTMQswCQYDVQQIEwJDQTEWMBQGA1UEBxMNTW91bnRhaW4gVmlldzEbMBkG A1UEChMSQW1lcmljYSBPbmxpbmUgSW5jMRkwFwYDVQQLExBBT0wgVGVjaG5vbG9naWVzMScw JQYDVQQDEx5JbnRyYW5ldCBDZXJ0aWZpY2F0ZSBBdXRob3JpdHkCAlukMAkGBSsOAwIaBQCg ggFhMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTAyMDkwMzIy MDgwOFowIwYJKoZIhvcNAQkEMRYEFG5yBhh9EASfd6g3qxclDTt9ahMfMFIGCSqGSIb3DQEJ DzFFMEMwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsO AwIHMA0GCCqGSIb3DQMCAgEoMIGtBgsqhkiG9w0BCRACCzGBnaCBmjCBkzELMAkGA1UEBhMC VVMxCzAJBgNVBAgTAkNBMRYwFAYDVQQHEw1Nb3VudGFpbiBWaWV3MRswGQYDVQQKExJBbWVy aWNhIE9ubGluZSBJbmMxGTAXBgNVBAsTEEFPTCBUZWNobm9sb2dpZXMxJzAlBgNVBAMTHklu dHJhbmV0IENlcnRpZmljYXRlIEF1dGhvcml0eQICW6QwDQYJKoZIhvcNAQEBBQAEgYCAnP71 Q7n3oiu5K0ukiz6JYC1MdCLV6WxHXLnagvI1fZjIBjshYHz278TWc05UYcPG9WeV4sZ8pX26 v7iujpToDRtTEu4asRR25/OIqpfdT/oOBN+kwfCU3KkVV/JkvdopWNF20JIb2wHVFrJApCTU HAqCcM+4cCfOD3VcIxVw5AAAAAAAAA== --------------ms090702080503030000030203-- From owner-ietf-ldup@mail.imc.org Tue Sep 3 21:51:04 2002 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA20305 for ; Tue, 3 Sep 2002 21:51:04 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g841jta17580 for ietf-ldup-bks; Tue, 3 Sep 2002 18:45:55 -0700 (PDT) Received: from prv-mail20.provo.novell.com (prv-mail20.provo.novell.com [137.65.81.122]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g841js217576 for ; Tue, 3 Sep 2002 18:45:54 -0700 (PDT) Received: from INET-PRV-MTA by prv-mail20.provo.novell.com with Novell_GroupWise; Tue, 03 Sep 2002 19:45:51 -0600 Message-Id: X-Mailer: Novell GroupWise Internet Agent 6.0.2 Beta Date: Tue, 03 Sep 2002 19:42:58 -0600 From: "Jim Sermersheim" To: Subject: Re: LCUP issues to consider Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Disposition: inline Sender: owner-ietf-ldup@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit It would be nice if someone would break out the editorials and send those to the authors, and create a thread for each of the other items. For now, I'll just try to avoid duplicating issues I find that already exist in this report. >>> Rich Megginson 09/03/02 04:08PM >>> I've attached the email I received from Kurt. From owner-ietf-ldup@mail.imc.org Tue Sep 3 22:06:42 2002 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA20648 for ; Tue, 3 Sep 2002 22:06:41 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g84231Q18749 for ietf-ldup-bks; Tue, 3 Sep 2002 19:03:01 -0700 (PDT) Received: from prv-mail20.provo.novell.com (prv-mail20.provo.novell.com [137.65.81.122]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g84230218743 for ; Tue, 3 Sep 2002 19:03:00 -0700 (PDT) Received: from INET-PRV-MTA by prv-mail20.provo.novell.com with Novell_GroupWise; Tue, 03 Sep 2002 20:02:58 -0600 Message-Id: X-Mailer: Novell GroupWise Internet Agent 6.0.2 Beta Date: Tue, 03 Sep 2002 20:00:10 -0600 From: "Jim Sermersheim" To: Subject: LCUP Issue: Alias dereferencing Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Disposition: inline Sender: owner-ietf-ldup@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit The server instructions for alias deferencing are found in the Client Side Considerations section. Specifically, it says that a server will respond with protocolError if any other than neverDerefAliases or derefFindingBaseObj is specified. This should be moved to, copied to, or referenced in a more server-centric part of the draft. Also, I think it should say "... the server MUST return protocolError..." Jim From owner-ietf-ldup@mail.imc.org Tue Sep 3 22:24:52 2002 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA20884 for ; Tue, 3 Sep 2002 22:24:52 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g842K7319393 for ietf-ldup-bks; Tue, 3 Sep 2002 19:20:07 -0700 (PDT) Received: from pretender.boolean.net (root@router.boolean.net [198.144.206.49]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g842K6219389 for ; Tue, 3 Sep 2002 19:20:06 -0700 (PDT) Received: from nomad.OpenLDAP.org (root@localhost [127.0.0.1]) by pretender.boolean.net (8.12.5/8.12.5) with ESMTP id g842KAkC002056; Wed, 4 Sep 2002 02:20:10 GMT (envelope-from Kurt@OpenLDAP.org) Message-Id: <5.1.0.14.0.20020903190011.04404ce0@127.0.0.1> X-Sender: kurt@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Tue, 03 Sep 2002 19:19:44 -0700 To: "Jim Sermersheim" From: "Kurt D. Zeilenga" Subject: Re: LCUP issues to consider Cc: In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-ldup@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: At 06:42 PM 2002-09-03, Jim Sermersheim wrote: >It would be nice if someone would break out the editorials and send >those to the authors, and create a thread for each of the other items. >For now, I'll just try to avoid duplicating issues I find that already >exist in this report. Personally, I'd like to hear your comments based upon your own independent review. I suggest you raise issues you have to the list without regard to my early review notes. (This, of course, helps the chairs determine how to proceed with regard to each individual issue as well as the I-D as a whole.) I intend to echo the major technical and editorial comments (in separate threads) as I work through my WG Last Call review of the I-D. At present, I've only posted my greatest concern. When I complete my review, I'll post my review notes (e.g., the laundry list) for completeness. >>>> Rich Megginson 09/03/02 04:08PM >>> >I've attached the email I received from Kurt. From owner-ietf-ldup@mail.imc.org Tue Sep 3 22:48:11 2002 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA21566 for ; Tue, 3 Sep 2002 22:48:11 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g842hrr19847 for ietf-ldup-bks; Tue, 3 Sep 2002 19:43:53 -0700 (PDT) Received: from pretender.boolean.net (root@router.boolean.net [198.144.206.49]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g842hq219843 for ; Tue, 3 Sep 2002 19:43:52 -0700 (PDT) Received: from nomad.OpenLDAP.org (root@localhost [127.0.0.1]) by pretender.boolean.net (8.12.5/8.12.5) with ESMTP id g842htkC002206 for ; Wed, 4 Sep 2002 02:43:56 GMT (envelope-from Kurt@OpenLDAP.org) Message-Id: <5.1.0.14.0.20020903193412.029214d0@127.0.0.1> X-Sender: kurt@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Tue, 03 Sep 2002 19:43:30 -0700 To: ietf-ldup@imc.org From: "Kurt D. Zeilenga" Subject: LCUP: updating cookie when no entries are to be sent Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-ldup@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: I believe LCUP needs to provide a mechanism which allows the server to send, at any time, a new cookie to the client without requiring the server to send an entry. This is useful in cases where the cookie the server previously sent is no quite old and a new cookie would allow more efficient resync if the session where to be unexpectedly dropped. In fact, the cookie may be so old to cause a full sync to occur when no changes would be necessary if the cookie were updated. Kurt From owner-ietf-ldup@mail.imc.org Tue Sep 3 23:11:07 2002 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA21956 for ; Tue, 3 Sep 2002 23:11:07 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g8437Bw20503 for ietf-ldup-bks; Tue, 3 Sep 2002 20:07:11 -0700 (PDT) Received: from prv-mail20.provo.novell.com (prv-mail20.provo.novell.com [137.65.81.122]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g8437A220497 for ; Tue, 3 Sep 2002 20:07:10 -0700 (PDT) Received: from INET-PRV-MTA by prv-mail20.provo.novell.com with Novell_GroupWise; Tue, 03 Sep 2002 21:07:08 -0600 Message-Id: X-Mailer: Novell GroupWise Internet Agent 6.0.2 Beta Date: Tue, 03 Sep 2002 21:04:25 -0600 From: "Jim Sermersheim" To: Subject: LCUP issue: trigger mechanism or not? Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Disposition: inline Sender: owner-ietf-ldup@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit The draft states that it "is intended to allow LDAP clients to synchronize with the content stored by LDAP servers". but also states that it wants to solve the problem of triggered actions (Section 3, Bullet 3). Most of the rest of the draft is consistent with the notion of synchronization, but tends to downplay support for triggered responses. Do we want this to be a useful event driver, or is the idea that we just preserve the easy stuff of what prior drafts could do? Specifically, the left-out items in Sections 5.1, 5.2, and 5.3 deter from the effectiveness of the "persist" mode. Curent users of Persistent Search rely on the notion of change types. Section 5.2 assumes that change types are used for partial replication, and thus discounts them as useful for LCUP. I don't think this is valid. Jim From owner-ietf-ldup@mail.imc.org Tue Sep 3 23:15:56 2002 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA22006 for ; Tue, 3 Sep 2002 23:15:56 -0400 (EDT) Received: by above.proper.com (8.11.6/8.11.3) id g843CNe20957 for ietf-ldup-bks; Tue, 3 Sep 2002 20:12:23 -0700 (PDT) Received: from prv-mail20.provo.novell.com (prv-mail20.provo.novell.com [137.65.81.122]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g843CK220949 for ; Tue, 3 Sep 2002 20:12:20 -0700 (PDT) Received: from INET-PRV-MTA by prv-mail20.provo.novell.com with Novell_GroupWise; Tue, 03 Sep 2002 21:12:18 -0600 Message-Id: X-Mailer: Novell GroupWise Internet Agent 6.0.2 Beta Date: Tue, 03 Sep 2002 21:09:31 -0600 From: "Jim Sermersheim" To: , Subject: Re: LCUP: updating cookie when no entries are to be sent Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Disposition: inline Sender: owner-ietf-ldup@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit Isn't that what the stateUpdate boolean is used for? Maybe the draft should instruct the client to not assume that the search result entry represents a change of any kind Jim >>> "Kurt D. Zeilenga" 09/03/02 08:43PM >>> I believe LCUP needs to provide a mechanism which allows the server to send, at any time, a new cookie to the client without requiring the server to send an entry. This is useful in cases where the cookie the server previously sent is no quite old and a new cookie would allow more efficient resync if the session where to be unexpectedly dropped. In fact, the cookie may be so old to cause a full sync to occur when no changes would be necessary if the cookie were updated. Kurt From owner-ietf-ldup@mail.imc.org Wed Sep 4 00:07:16 2002 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA22720 for ; Wed, 4 Sep 2002 00:07:15 -0400 (EDT) Received: by above.proper.com (8.11.6/8.11.3) id g8443sw23603 for ietf-ldup-bks; Tue, 3 Sep 2002 21:03:54 -0700 (PDT) Received: from pretender.boolean.net (root@router.boolean.net [198.144.206.49]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g8443q223599 for ; Tue, 3 Sep 2002 21:03:52 -0700 (PDT) Received: from nomad.OpenLDAP.org (root@localhost [127.0.0.1]) by pretender.boolean.net (8.12.5/8.12.5) with ESMTP id g8443ukC003040; Wed, 4 Sep 2002 04:03:56 GMT (envelope-from Kurt@OpenLDAP.org) Message-Id: <5.1.0.14.0.20020903203416.043ea8a0@127.0.0.1> X-Sender: kurt@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Tue, 03 Sep 2002 21:03:31 -0700 To: "Jim Sermersheim" From: "Kurt D. Zeilenga" Subject: Re: LCUP: updating cookie when no entries are to be sent Cc: In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-ldup@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: At 08:09 PM 2002-09-03, Jim Sermersheim wrote: >Isn't that what the stateUpdate boolean is used for? Maybe the draft >should instruct the client to not assume that the search result entry >represents a change of any kind No. The stateUpdate flag is a control which must be attached to an entry. There may be no entries to send. Kurt From owner-ietf-ldup@mail.imc.org Wed Sep 4 00:26:40 2002 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA23275 for ; Wed, 4 Sep 2002 00:26:39 -0400 (EDT) Received: by above.proper.com (8.11.6/8.11.3) id g844HLA24014 for ietf-ldup-bks; Tue, 3 Sep 2002 21:17:21 -0700 (PDT) Received: from prv-mail20.provo.novell.com (prv-mail20.provo.novell.com [137.65.81.122]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g844HK224010 for ; Tue, 3 Sep 2002 21:17:20 -0700 (PDT) Received: from INET-PRV-MTA by prv-mail20.provo.novell.com with Novell_GroupWise; Tue, 03 Sep 2002 22:17:19 -0600 Message-Id: X-Mailer: Novell GroupWise Internet Agent 6.0.2 Beta Date: Tue, 03 Sep 2002 22:14:31 -0600 From: "Jim Sermersheim" To: Cc: Subject: Re: LCUP: updating cookie when no entries are to be sent Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Disposition: inline Sender: owner-ietf-ldup@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit Right, I think the draft acknowledges that (This feature allows updating the client's cookie when there are no changes that effect the client's data store). The wording following that statement needs some rework. I believe it intends to say that even though an entry is being returned, it doesn't mean that entry was changed. Furthermore, it suggests that the root of the search be used as the entry (I think). Jim >>> "Kurt D. Zeilenga" 09/03/02 10:03PM >>> At 08:09 PM 2002-09-03, Jim Sermersheim wrote: >Isn't that what the stateUpdate boolean is used for? Maybe the draft >should instruct the client to not assume that the search result entry >represents a change of any kind No. The stateUpdate flag is a control which must be attached to an entry. There may be no entries to send. Kurt From owner-ietf-ldup@mail.imc.org Wed Sep 4 00:37:50 2002 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA23453 for ; Wed, 4 Sep 2002 00:37:50 -0400 (EDT) Received: by above.proper.com (8.11.6/8.11.3) id g844YPZ24302 for ietf-ldup-bks; Tue, 3 Sep 2002 21:34:25 -0700 (PDT) Received: from prv-mail20.provo.novell.com (prv-mail20.provo.novell.com [137.65.81.122]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g844YN224298 for ; Tue, 3 Sep 2002 21:34:23 -0700 (PDT) Received: from INET-PRV-MTA by prv-mail20.provo.novell.com with Novell_GroupWise; Tue, 03 Sep 2002 22:34:22 -0600 Message-Id: X-Mailer: Novell GroupWise Internet Agent 6.0.2 Beta Date: Tue, 03 Sep 2002 22:31:34 -0600 From: "Jim Sermersheim" To: Subject: LCUP Issue: Search Filter and returnd entries Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Disposition: inline Sender: owner-ietf-ldup@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit The draft states in Section 5.2 that "For LCUP, the intention is full synchronization, not partial.". What is the implication of the search filter? I assume that only entries matching the search filter (and scope) are returned. Is this true? Jim From owner-ietf-ldup@mail.imc.org Wed Sep 4 00:44:06 2002 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA23551 for ; Wed, 4 Sep 2002 00:44:06 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g844eUJ24427 for ietf-ldup-bks; Tue, 3 Sep 2002 21:40:30 -0700 (PDT) Received: from pretender.boolean.net (root@router.boolean.net [198.144.206.49]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g844eT224422 for ; Tue, 3 Sep 2002 21:40:29 -0700 (PDT) Received: from nomad.OpenLDAP.org (root@localhost [127.0.0.1]) by pretender.boolean.net (8.12.5/8.12.5) with ESMTP id g844eWkC003208; Wed, 4 Sep 2002 04:40:32 GMT (envelope-from Kurt@OpenLDAP.org) Message-Id: <5.1.0.14.0.20020903213811.0441cc00@127.0.0.1> X-Sender: kurt@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Tue, 03 Sep 2002 21:40:07 -0700 To: "Jim Sermersheim" From: "Kurt D. Zeilenga" Subject: Re: LCUP: updating cookie when no entries are to be sent Cc: In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-ldup@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: At 09:14 PM 2002-09-03, Jim Sermersheim wrote: >Right, I think the draft acknowledges that (This feature allows updating >the client's cookie when there are no changes that effect the client's >data store). But it also doesn't allow the server to send a cookie after completing synchronization set of zero entries. >The wording following that statement needs some rework. I >believe it intends to say that even though an entry is being returned, >it doesn't mean that entry was changed. Furthermore, it suggests that >the root of the search be used as the entry (I think). What if no entry (presently) matches the filter? >Jim > >>>> "Kurt D. Zeilenga" 09/03/02 10:03PM >>> > >At 08:09 PM 2002-09-03, Jim Sermersheim wrote: >>Isn't that what the stateUpdate boolean is used for? Maybe the draft >>should instruct the client to not assume that the search result entry >>represents a change of any kind > >No. The stateUpdate flag is a control which must be attached >to an entry. There may be no entries to send. > >Kurt From owner-ietf-ldup@mail.imc.org Wed Sep 4 00:49:05 2002 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA23612 for ; Wed, 4 Sep 2002 00:49:04 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g844ftb24467 for ietf-ldup-bks; Tue, 3 Sep 2002 21:41:55 -0700 (PDT) Received: from prv-mail20.provo.novell.com (prv-mail20.provo.novell.com [137.65.81.122]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g844fs224462 for ; Tue, 3 Sep 2002 21:41:54 -0700 (PDT) Received: from INET-PRV-MTA by prv-mail20.provo.novell.com with Novell_GroupWise; Tue, 03 Sep 2002 22:41:53 -0600 Message-Id: X-Mailer: Novell GroupWise Internet Agent 6.0.2 Beta Date: Tue, 03 Sep 2002 22:38:50 -0600 From: "Jim Sermersheim" To: , "Jim Sermersheim" Subject: LCUP issue: Does entryDeleted break the protocol? Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Disposition: inline Sender: owner-ietf-ldup@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit The description for entryDeleted states at first that it indicates that the entry being returned has been deleted--then goes on to say that it also might indicate that the entry has left the result set. In the case of it being due to the entry has left the result set, we need to answer these: 1) If due to a rename, what DN is used (old or new) 2) If the entry is not in the result set, doesn't it break the LDAP protocol to return it (it doesn't match the filter)? Jim From owner-ietf-ldup@mail.imc.org Wed Sep 4 00:52:07 2002 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA23702 for ; Wed, 4 Sep 2002 00:52:07 -0400 (EDT) Received: by above.proper.com (8.11.6/8.11.3) id g844mh024632 for ietf-ldup-bks; Tue, 3 Sep 2002 21:48:43 -0700 (PDT) Received: from prv-mail20.provo.novell.com (prv-mail20.provo.novell.com [137.65.81.122]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g844mg224628 for ; Tue, 3 Sep 2002 21:48:42 -0700 (PDT) Received: from INET-PRV-MTA by prv-mail20.provo.novell.com with Novell_GroupWise; Tue, 03 Sep 2002 22:48:41 -0600 Message-Id: X-Mailer: Novell GroupWise Internet Agent 6.0.2 Beta Date: Tue, 03 Sep 2002 22:45:53 -0600 From: "Jim Sermersheim" To: Cc: Subject: Re: LCUP: updating cookie when no entries are to be sent Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Disposition: inline Sender: owner-ietf-ldup@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit >What if no entry (presently) matches the filter? Good point. This was a defect in psearch, and hasn't been resolved yet in LCUP. We assumed that in this case, the operation fails with no such entry. From owner-ietf-ldup@mail.imc.org Wed Sep 4 00:54:47 2002 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA23782 for ; Wed, 4 Sep 2002 00:54:47 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g844pdI24773 for ietf-ldup-bks; Tue, 3 Sep 2002 21:51:39 -0700 (PDT) Received: from prv-mail20.provo.novell.com (prv-mail20.provo.novell.com [137.65.81.122]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g844pc224769 for ; Tue, 3 Sep 2002 21:51:38 -0700 (PDT) Received: from INET-PRV-MTA by prv-mail20.provo.novell.com with Novell_GroupWise; Tue, 03 Sep 2002 22:51:37 -0600 Message-Id: X-Mailer: Novell GroupWise Internet Agent 6.0.2 Beta Date: Tue, 03 Sep 2002 22:48:53 -0600 From: "Jim Sermersheim" To: Subject: LCUP issue: Is the EntryUpdateControlValue optional? Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Disposition: inline Sender: owner-ietf-ldup@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit First, is the EntryUpdateControlValue supposed to be returned during an initial synchronization session? Next, Section 4.8 states: "Each SearchResultEntry may have an entryUpdate control attached. ". This indicates that the control is optional. Is it? Jim From owner-ietf-ldup@mail.imc.org Wed Sep 4 00:59:16 2002 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA23912 for ; Wed, 4 Sep 2002 00:59:15 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g844tRs24852 for ietf-ldup-bks; Tue, 3 Sep 2002 21:55:27 -0700 (PDT) Received: from prv-mail20.provo.novell.com (prv-mail20.provo.novell.com [137.65.81.122]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g844tQ224846 for ; Tue, 3 Sep 2002 21:55:26 -0700 (PDT) Received: from INET-PRV-MTA by prv-mail20.provo.novell.com with Novell_GroupWise; Tue, 03 Sep 2002 22:55:24 -0600 Message-Id: X-Mailer: Novell GroupWise Internet Agent 6.0.2 Beta Date: Tue, 03 Sep 2002 22:52:37 -0600 From: "Jim Sermersheim" To: , "Jim Sermersheim" Subject: LCUP issue: What is "a while"? Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Disposition: inline Sender: owner-ietf-ldup@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit Section 4.8 states "it MUST wait for a while before attempting another synchronization session with the server. " If we're going to use an imperative like MUST, we ought to not use vague language like "a while". I suggest we drop the MUST anyway--is there an interoperability issue here? Jim From owner-ietf-ldup@mail.imc.org Wed Sep 4 01:03:02 2002 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA24002 for ; Wed, 4 Sep 2002 01:03:01 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g844uoi24901 for ietf-ldup-bks; Tue, 3 Sep 2002 21:56:50 -0700 (PDT) Received: from pretender.boolean.net (root@router.boolean.net [198.144.206.49]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g844um224897 for ; Tue, 3 Sep 2002 21:56:48 -0700 (PDT) Received: from nomad.OpenLDAP.org (root@localhost [127.0.0.1]) by pretender.boolean.net (8.12.5/8.12.5) with ESMTP id g844urkC003279; Wed, 4 Sep 2002 04:56:53 GMT (envelope-from Kurt@OpenLDAP.org) Message-Id: <5.1.0.14.0.20020903214252.02928670@127.0.0.1> X-Sender: kurt@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Tue, 03 Sep 2002 21:56:27 -0700 To: "Jim Sermersheim" From: "Kurt D. Zeilenga" Subject: Re: LCUP Issue: Search Filter and returnd entries Cc: In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-ldup@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: At 09:31 PM 2002-09-03, Jim Sermersheim wrote: >The draft states in Section 5.2 that "For LCUP, the intention is full >synchronization, not partial.". This may be referring to the fact that in LCUP, each entry sent is "full" (includes all attributes regardless of whether they've been changed) instead of "partial" (only those attributes (or only those values) which changed). But in the sense you took it... note that the number of entries sent upon full synchronization may be zero! For example, the scope is one-level and the baseObject has no subordinates. >What is the implication of the search filter? I believe LCUP must support both partial (not necessarily all entries within scope) and fractional (not necessarily all attributes of each entry) synchronization. >I assume that only entries matching the search filter (and >scope) are returned. Is this true? Section 6: Changes to data (e.g., that might affect the LCUP client's filter or scope) or meta-data (e.g., that might affect the client's read access) may affect the presence of entries in the search set. From owner-ietf-ldup@mail.imc.org Wed Sep 4 01:04:02 2002 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA24022 for ; Wed, 4 Sep 2002 01:04:02 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g844xfQ24980 for ietf-ldup-bks; Tue, 3 Sep 2002 21:59:41 -0700 (PDT) Received: from prv-mail20.provo.novell.com (prv-mail20.provo.novell.com [137.65.81.122]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g844xe224976 for ; Tue, 3 Sep 2002 21:59:40 -0700 (PDT) Received: from INET-PRV-MTA by prv-mail20.provo.novell.com with Novell_GroupWise; Tue, 03 Sep 2002 22:59:39 -0600 Message-Id: X-Mailer: Novell GroupWise Internet Agent 6.0.2 Beta Date: Tue, 03 Sep 2002 22:56:54 -0600 From: "Jim Sermersheim" To: Subject: LCUP issue: note about syncing to different servers Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Disposition: inline Sender: owner-ietf-ldup@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit What does the "(Note that the client can synchronize with different servers during different synchronization sessions.) " mean in the context of the paragraph it's in? From owner-ietf-ldup@mail.imc.org Wed Sep 4 01:09:41 2002 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA24105 for ; Wed, 4 Sep 2002 01:09:41 -0400 (EDT) Received: by above.proper.com (8.11.6/8.11.3) id g84567N25130 for ietf-ldup-bks; Tue, 3 Sep 2002 22:06:07 -0700 (PDT) Received: from prv-mail20.provo.novell.com (prv-mail20.provo.novell.com [137.65.81.122]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g84566225126 for ; Tue, 3 Sep 2002 22:06:06 -0700 (PDT) Received: from INET-PRV-MTA by prv-mail20.provo.novell.com with Novell_GroupWise; Tue, 03 Sep 2002 23:06:05 -0600 Message-Id: X-Mailer: Novell GroupWise Internet Agent 6.0.2 Beta Date: Tue, 03 Sep 2002 23:03:12 -0600 From: "Jim Sermersheim" To: Subject: LCUP issue: Need for lcupReloadRequired Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Disposition: inline Sender: owner-ietf-ldup@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit Why is this error needed? It seems that if this scenario exists, the server would simply send the full set of entries, and a new cookie. The current specification indicates that the client would try to sync, receive an error, then try to sync again with an empty cookie. Is there a benefit to the extra step? Jim From owner-ietf-ldup@mail.imc.org Wed Sep 4 01:15:12 2002 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA24198 for ; Wed, 4 Sep 2002 01:15:12 -0400 (EDT) Received: by above.proper.com (8.11.6/8.11.3) id g845BnM25296 for ietf-ldup-bks; Tue, 3 Sep 2002 22:11:49 -0700 (PDT) Received: from pretender.boolean.net (root@router.boolean.net [198.144.206.49]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g845Bm225292 for ; Tue, 3 Sep 2002 22:11:48 -0700 (PDT) Received: from nomad.OpenLDAP.org (root@localhost [127.0.0.1]) by pretender.boolean.net (8.12.5/8.12.5) with ESMTP id g845BqkC003380; Wed, 4 Sep 2002 05:11:52 GMT (envelope-from Kurt@OpenLDAP.org) Message-Id: <5.1.0.14.0.20020903220703.04425f20@127.0.0.1> X-Sender: kurt@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Tue, 03 Sep 2002 22:11:26 -0700 To: "Jim Sermersheim" From: "Kurt D. Zeilenga" Subject: Re: LCUP: updating cookie when no entries are to be sent Cc: In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-ldup@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: At 09:45 PM 2002-09-03, Jim Sermersheim wrote: >>What if no entry (presently) matches the filter? > >Good point. This was a defect in psearch, and hasn't been resolved yet >in LCUP. We assumed that in this case, the operation fails with no such >entry. Yikes... noSuchObject should only be used to indicate that the baseObject of the search request was not located. Kurt From owner-ietf-ldup@mail.imc.org Wed Sep 4 01:19:40 2002 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA24322 for ; Wed, 4 Sep 2002 01:19:39 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g845EhE25500 for ietf-ldup-bks; Tue, 3 Sep 2002 22:14:43 -0700 (PDT) Received: from prv-mail20.provo.novell.com (prv-mail20.provo.novell.com [137.65.81.122]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g845Eg225495 for ; Tue, 3 Sep 2002 22:14:42 -0700 (PDT) Received: from INET-PRV-MTA by prv-mail20.provo.novell.com with Novell_GroupWise; Tue, 03 Sep 2002 23:14:41 -0600 Message-Id: X-Mailer: Novell GroupWise Internet Agent 6.0.2 Beta Date: Tue, 03 Sep 2002 23:11:16 -0600 From: "Jim Sermersheim" To: Subject: Re: LCUP issue: Need for lcupReloadRequired Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Disposition: inline Sender: owner-ietf-ldup@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit I suppose the benefit is that in the event entries have been deleted, or are not in the result set anymore, this two-step process lets the client know that it's current cache may be inconsistent with the entries in the directory. >>> "Jim Sermersheim" 09/03/02 11:03PM >>> Why is this error needed? It seems that if this scenario exists, the server would simply send the full set of entries, and a new cookie. The current specification indicates that the client would try to sync, receive an error, then try to sync again with an empty cookie. Is there a benefit to the extra step? Jim From owner-ietf-ldup@mail.imc.org Wed Sep 4 01:28:24 2002 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA24524 for ; Wed, 4 Sep 2002 01:28:24 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g845N6I25715 for ietf-ldup-bks; Tue, 3 Sep 2002 22:23:06 -0700 (PDT) Received: from prv-mail20.provo.novell.com (prv-mail20.provo.novell.com [137.65.81.122]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g845N5225711 for ; Tue, 3 Sep 2002 22:23:05 -0700 (PDT) Received: from INET-PRV-MTA by prv-mail20.provo.novell.com with Novell_GroupWise; Tue, 03 Sep 2002 23:23:04 -0600 Message-Id: X-Mailer: Novell GroupWise Internet Agent 6.0.2 Beta Date: Tue, 03 Sep 2002 23:20:09 -0600 From: "Jim Sermersheim" To: Cc: Subject: Re: LCUP: updating cookie when no entries are to be sent Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Disposition: inline Sender: owner-ietf-ldup@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit Sorry, yes. This is a subset of the resaons why no entry presently matches the filter. The scenario I was thinking of is one where the base existed when a persistent LCUP session starts, but later is renamed or deleted. Jim >>> "Kurt D. Zeilenga" 09/03/02 11:11PM >>> At 09:45 PM 2002-09-03, Jim Sermersheim wrote: >>What if no entry (presently) matches the filter? > >Good point. This was a defect in psearch, and hasn't been resolved yet >in LCUP. We assumed that in this case, the operation fails with no such >entry. Yikes... noSuchObject should only be used to indicate that the baseObject of the search request was not located. Kurt From owner-ietf-ldup@mail.imc.org Wed Sep 4 01:29:36 2002 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA24561 for ; Wed, 4 Sep 2002 01:29:36 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g845Nlw25744 for ietf-ldup-bks; Tue, 3 Sep 2002 22:23:47 -0700 (PDT) Received: from pretender.boolean.net (root@router.boolean.net [198.144.206.49]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g845Nk225740 for ; Tue, 3 Sep 2002 22:23:46 -0700 (PDT) Received: from nomad.OpenLDAP.org (root@localhost [127.0.0.1]) by pretender.boolean.net (8.12.5/8.12.5) with ESMTP id g845NkkC003425; Wed, 4 Sep 2002 05:23:46 GMT (envelope-from Kurt@OpenLDAP.org) Message-Id: <5.1.0.14.0.20020903221949.04430240@127.0.0.1> X-Sender: kurt@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Tue, 03 Sep 2002 22:23:21 -0700 To: "Jim Sermersheim" From: "Kurt D. Zeilenga" Subject: Re: LCUP issue: Need for lcupReloadRequired Cc: In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-ldup@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: At 10:03 PM 2002-09-03, Jim Sermersheim wrote: >Why is this error needed? It seems that if this scenario exists, the >server would simply send the full set of entries, and a new cookie. The >current specification indicates that the client would try to sync, >receive an error, then try to sync again with an empty cookie. Is there >a benefit to the extra step? Yes, it tells the client to delete everything it has. Otherwise it might be left with entries which should be have been deleted but were not. Of course, give that LCUP doesn't ensure this doesn't happen under success resync is part of my greatest concern. Kurt From owner-ietf-ldup@mail.imc.org Wed Sep 4 01:32:59 2002 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA24691 for ; Wed, 4 Sep 2002 01:32:59 -0400 (EDT) Received: by above.proper.com (8.11.6/8.11.3) id g845QYn25841 for ietf-ldup-bks; Tue, 3 Sep 2002 22:26:34 -0700 (PDT) Received: from prv-mail20.provo.novell.com (prv-mail20.provo.novell.com [137.65.81.122]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g845QX225837 for ; Tue, 3 Sep 2002 22:26:33 -0700 (PDT) Received: from INET-PRV-MTA by prv-mail20.provo.novell.com with Novell_GroupWise; Tue, 03 Sep 2002 23:26:31 -0600 Message-Id: X-Mailer: Novell GroupWise Internet Agent 6.0.2 Beta Date: Tue, 03 Sep 2002 23:23:46 -0600 From: "Jim Sermersheim" To: Subject: LCUP issue: sync, then sync and persist Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Disposition: inline Sender: owner-ietf-ldup@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit Why is there a suggestion in Section 6 to "perform an initial synchronization...(synchronizeOnly)" and then immediately perform a synchronizeAndPersist session? Why not just perform a synchronizeAndPersist session to begin with? Jim From owner-ietf-ldup@mail.imc.org Wed Sep 4 01:40:23 2002 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA24759 for ; Wed, 4 Sep 2002 01:40:22 -0400 (EDT) Received: by above.proper.com (8.11.6/8.11.3) id g845YjW26098 for ietf-ldup-bks; Tue, 3 Sep 2002 22:34:45 -0700 (PDT) Received: from pretender.boolean.net (root@router.boolean.net [198.144.206.49]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g845Yh226094 for ; Tue, 3 Sep 2002 22:34:43 -0700 (PDT) Received: from nomad.OpenLDAP.org (root@localhost [127.0.0.1]) by pretender.boolean.net (8.12.5/8.12.5) with ESMTP id g845YmkC003473; Wed, 4 Sep 2002 05:34:48 GMT (envelope-from Kurt@OpenLDAP.org) Message-Id: <5.1.0.14.0.20020903223056.02923340@127.0.0.1> X-Sender: kurt@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Tue, 03 Sep 2002 22:34:22 -0700 To: "Jim Sermersheim" From: "Kurt D. Zeilenga" Subject: Re: LCUP issue: Need for lcupReloadRequired Cc: In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-ldup@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: At 10:11 PM 2002-09-03, Jim Sermersheim wrote: >I suppose the benefit is that in the event entries have been deleted, or >are not in the result set anymore, this two-step process lets the client >know that it's current cache may be inconsistent with the entries in the >directory. IMO, an update protocol which doesn't ensure that at completion of the synchronization that there all inconsistencies can be detected and resolved, should be referred to as a "content synchronization protocol". Kurt From owner-ietf-ldup@mail.imc.org Wed Sep 4 01:41:09 2002 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA24784 for ; Wed, 4 Sep 2002 01:41:09 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g845bJl26253 for ietf-ldup-bks; Tue, 3 Sep 2002 22:37:19 -0700 (PDT) Received: from pretender.boolean.net (root@router.boolean.net [198.144.206.49]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g845bI226247 for ; Tue, 3 Sep 2002 22:37:18 -0700 (PDT) Received: from nomad.OpenLDAP.org (root@localhost [127.0.0.1]) by pretender.boolean.net (8.12.5/8.12.5) with ESMTP id g845bMkC003502; Wed, 4 Sep 2002 05:37:22 GMT (envelope-from Kurt@OpenLDAP.org) Message-Id: <5.1.0.14.0.20020903223546.0444eeb0@127.0.0.1> X-Sender: kurt@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Tue, 03 Sep 2002 22:36:57 -0700 To: "Jim Sermersheim" From: "Kurt D. Zeilenga" Subject: LCUP: rename of baseObject (was something else) Cc: In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-ldup@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: At 10:20 PM 2002-09-03, Jim Sermersheim wrote: >The scenario I was thinking of is one where the base existed when a >persistent LCUP session starts, but later is renamed or deleted. LCUP should be clear on the expected behavior here... Kurt From owner-ietf-ldup@mail.imc.org Wed Sep 4 01:43:07 2002 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA24834 for ; Wed, 4 Sep 2002 01:43:07 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g845dUr26479 for ietf-ldup-bks; Tue, 3 Sep 2002 22:39:30 -0700 (PDT) Received: from prv-mail20.provo.novell.com (prv-mail20.provo.novell.com [137.65.81.122]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g845dT226475 for ; Tue, 3 Sep 2002 22:39:29 -0700 (PDT) Received: from INET-PRV-MTA by prv-mail20.provo.novell.com with Novell_GroupWise; Tue, 03 Sep 2002 23:39:27 -0600 Message-Id: X-Mailer: Novell GroupWise Internet Agent 6.0.2 Beta Date: Tue, 03 Sep 2002 23:36:34 -0600 From: "Jim Sermersheim" To: Cc: Subject: Re: LCUP Issue: Search Filter and returned entries Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Disposition: inline Sender: owner-ietf-ldup@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit >>> "Kurt D. Zeilenga" 09/03/02 10:56PM >>> >At 09:31 PM 2002-09-03, Jim Sermersheim wrote: >>The draft states in Section 5.2 that "For LCUP, the intention is full >>synchronization, not partial.". >This may be referring to the fact that in LCUP, each entry >sent is "full" (includes all attributes regardless of whether >they've been changed) instead of "partial" (only those attributes >(or only those values) which changed). >But in the sense you took it... note that the number of entries sent >upon full synchronization may be zero! For example, the scope is >one-level and the baseObject has no subordinates. Yes, or the scope is base, and it no longer matches the filter. Or for that matter, simply none of the entries match the filter. >>What is the implication of the search filter? >I believe LCUP must support both partial (not necessarily >all entries within scope) and fractional (not necessarily >all attributes of each entry) synchronization. >>I assume that only entries matching the search filter (and >>scope) are returned. Is this true? >Section 6: > Changes to data (e.g., that might affect the LCUP client's filter or > scope) or meta-data (e.g., that might affect the client's read > access) may affect the presence of entries in the search set. And the next sentence says "Servers MAY notify LCUP clients of changes to the search set that result from such changes". Meaning--servers MAY break the protocol. From owner-ietf-ldup@mail.imc.org Wed Sep 4 01:54:11 2002 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA24927 for ; Wed, 4 Sep 2002 01:54:10 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g845oeE26881 for ietf-ldup-bks; Tue, 3 Sep 2002 22:50:40 -0700 (PDT) Received: from pretender.boolean.net (root@router.boolean.net [198.144.206.49]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g845od226877 for ; Tue, 3 Sep 2002 22:50:39 -0700 (PDT) Received: from nomad.OpenLDAP.org (root@localhost [127.0.0.1]) by pretender.boolean.net (8.12.5/8.12.5) with ESMTP id g845ohkC003602; Wed, 4 Sep 2002 05:50:43 GMT (envelope-from Kurt@OpenLDAP.org) Message-Id: <5.1.0.14.0.20020903224322.0441da90@127.0.0.1> X-Sender: kurt@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Tue, 03 Sep 2002 22:50:17 -0700 To: "Jim Sermersheim" From: "Kurt D. Zeilenga" Subject: Re: LCUP issue: sync, then sync and persist Cc: In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-ldup@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: At 10:23 PM 2002-09-03, Jim Sermersheim wrote: >Why is there a suggestion in Section 6 to "perform an initial >synchronization...(synchronizeOnly)" and then immediately perform a >synchronizeAndPersist session? Why not just perform a >synchronizeAndPersist session to begin with? Because the client has no other way to determine that it presently has a complete copy of the DIT fragment. Kurt From owner-ietf-ldup@mail.imc.org Wed Sep 4 01:57:54 2002 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA24996 for ; Wed, 4 Sep 2002 01:57:54 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g845sPA26944 for ietf-ldup-bks; Tue, 3 Sep 2002 22:54:25 -0700 (PDT) Received: from prv-mail20.provo.novell.com (prv-mail20.provo.novell.com [137.65.81.122]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g845sO226940 for ; Tue, 3 Sep 2002 22:54:24 -0700 (PDT) Received: from INET-PRV-MTA by prv-mail20.provo.novell.com with Novell_GroupWise; Tue, 03 Sep 2002 23:54:23 -0600 Message-Id: X-Mailer: Novell GroupWise Internet Agent 6.0.2 Beta Date: Tue, 03 Sep 2002 23:51:37 -0600 From: "Jim Sermersheim" To: Cc: Subject: Re: LCUP issue: sync, then sync and persist Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Disposition: inline Sender: owner-ietf-ldup@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit I don't get it... A synchronizeAndPersist session should return the complete copy, then drop into the "persist" mode. What am I missing? Jim >>> "Kurt D. Zeilenga" 09/03/02 11:50PM >>> At 10:23 PM 2002-09-03, Jim Sermersheim wrote: >Why is there a suggestion in Section 6 to "perform an initial >synchronization...(synchronizeOnly)" and then immediately perform a >synchronizeAndPersist session? Why not just perform a >synchronizeAndPersist session to begin with? Because the client has no other way to determine that it presently has a complete copy of the DIT fragment. Kurt From owner-ietf-ldup@mail.imc.org Wed Sep 4 02:14:56 2002 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA04305 for ; Wed, 4 Sep 2002 02:14:56 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g846BM700290 for ietf-ldup-bks; Tue, 3 Sep 2002 23:11:22 -0700 (PDT) Received: from pretender.boolean.net (root@router.boolean.net [198.144.206.49]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g846BL200282 for ; Tue, 3 Sep 2002 23:11:21 -0700 (PDT) Received: from nomad.OpenLDAP.org (root@localhost [127.0.0.1]) by pretender.boolean.net (8.12.5/8.12.5) with ESMTP id g846BPkC003687; Wed, 4 Sep 2002 06:11:25 GMT (envelope-from Kurt@OpenLDAP.org) Message-Id: <5.1.0.14.0.20020903231037.04444a20@127.0.0.1> X-Sender: kurt@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Tue, 03 Sep 2002 23:11:00 -0700 To: "Jim Sermersheim" From: "Kurt D. Zeilenga" Subject: Re: LCUP issue: sync, then sync and persist Cc: In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-ldup@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: At 10:51 PM 2002-09-03, Jim Sermersheim wrote: >I don't get it... A synchronizeAndPersist session should return the >complete copy, then drop into the "persist" mode. What am I missing? A sync to persist transition notification. >Jim > >>>> "Kurt D. Zeilenga" 09/03/02 11:50PM >>> >At 10:23 PM 2002-09-03, Jim Sermersheim wrote: >>Why is there a suggestion in Section 6 to "perform an initial >>synchronization...(synchronizeOnly)" and then immediately perform a >>synchronizeAndPersist session? Why not just perform a >>synchronizeAndPersist session to begin with? > >Because the client has no other way to determine that >it presently has a complete copy of the DIT fragment. > >Kurt From owner-ietf-ldup@mail.imc.org Wed Sep 4 02:32:16 2002 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA16806 for ; Wed, 4 Sep 2002 02:32:15 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g846J9E02253 for ietf-ldup-bks; Tue, 3 Sep 2002 23:19:09 -0700 (PDT) Received: from pretender.boolean.net (root@router.boolean.net [198.144.206.49]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g846J8202248 for ; Tue, 3 Sep 2002 23:19:08 -0700 (PDT) Received: from nomad.OpenLDAP.org (root@localhost [127.0.0.1]) by pretender.boolean.net (8.12.5/8.12.5) with ESMTP id g846J7kC003718 for ; Wed, 4 Sep 2002 06:19:07 GMT (envelope-from Kurt@OpenLDAP.org) Message-Id: <5.1.0.14.0.20020903231206.044639f8@127.0.0.1> X-Sender: kurt@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Tue, 03 Sep 2002 23:18:42 -0700 To: From: "Kurt D. Zeilenga" Subject: Re: LCUP: rename of baseObject (was something else) In-Reply-To: <5.1.0.14.0.20020903223546.0444eeb0@127.0.0.1> References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-ldup@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: At 10:36 PM 2002-09-03, Kurt D. Zeilenga wrote: >At 10:20 PM 2002-09-03, Jim Sermersheim wrote: >>The scenario I was thinking of is one where the base existed when a >>persistent LCUP session starts, but later is renamed or deleted. > >LCUP should be clear on the expected behavior here... Client Considerations implies noSuchObject is returned in this case. This needs to be detailed in Section 4 (along with many other protocol details found in sections 6 and 7). From owner-ietf-ldup@mail.imc.org Wed Sep 4 02:38:24 2002 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA18782 for ; Wed, 4 Sep 2002 02:38:24 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g846WDo04490 for ietf-ldup-bks; Tue, 3 Sep 2002 23:32:13 -0700 (PDT) Received: from nexus.adacel.com (shelob.adacel.com.au [203.36.26.146] (may be forged)) by above.proper.com (8.11.6/8.11.3) with SMTP id g846W5204482 for ; Tue, 3 Sep 2002 23:32:07 -0700 (PDT) Received: (qmail 17626 invoked from network); 4 Sep 2002 06:22:06 -0000 Received: from unknown (HELO osmium) (10.32.24.165) by nexus.adacel.com with SMTP; 4 Sep 2002 06:22:06 -0000 Reply-To: From: "Steven Legg" To: "'John McMeeking'" , Subject: RE: LCUP Issue: UUID Date: Wed, 4 Sep 2002 17:31:15 +1100 Message-ID: <003b01c253dc$ac5e58d0$a518200a@osmium.mtwav.adacel.com.au> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook 8.5, Build 4.71.2377.0 In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V4.72.2120.0 Importance: Normal Sender: owner-ietf-ldup@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit John, John McMeeking wrote: > I think that some reasonable uses of the attribute warrant a string > representation. For example, an application may want to search for an > entry with a specific entryuuid. And some LDUP conflict resolution > procedures call for renaming an entry to have a DN like > "cn=some value + > entryuuid=xxxx". Constructing such search filters and DNs is > much cleaner > if entryuuid has a string syntax. I agree. > Granted, a well-written application > should be able to construct search filters and DNs containing binary > values. Case ignore match may be too restrictive. The allComponentsMatch matching rule, already referenced by URP, performs a character by character code-point comparison when applied to a string type (there are some caveats on DirectoryString). This avoids all the letter case, white-space and other normalization that comes with caseIgnoreMatch and caseExactMatch. > Certainly, there is no > reason why an application can't use the entry uuid in the > case provided by > the originating server. > > That aside, don't we have to define what an entry uuid looks > like? Yes. > A maximum size would probably be helpful to > server vendors so > as to not have to provide a search and storage mechanism (DB table for > example) that has to support arbirary length values generated by other > servers. Speaking as a vendor, I already support arbitrary length attribute values. A maximum size for entry uuids would be an irritation rather than an advantage to me. > Just to get things started, I propose that we use the DCE > UUID algorithms, > which have a well defined string representation. And we > should be able to > define a entryuuid syntax with a string representation, which > is probably a > bit cleaner than using "directory string" or "octet string." What character set does the DCE algorithm use ? Would PrintableString or IA5String be sufficient ? Otherwise we can just define an LDAP syntax OID for UTF8String. Regards, Steven From owner-ietf-ldup@mail.imc.org Wed Sep 4 09:12:30 2002 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA26918 for ; Wed, 4 Sep 2002 09:12:30 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g84D8EN16043 for ietf-ldup-bks; Wed, 4 Sep 2002 06:08:14 -0700 (PDT) Received: from telutil12a.ml.com (telutil12a-v.ml.com [199.43.34.196]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g84D8C216037 for ; Wed, 4 Sep 2002 06:08:12 -0700 (PDT) Received: from telutil13a.ml.com (telutil13a [146.125.226.11]) by telutil12a.ml.com (8.11.3/8.11.3/telutil12a-1.2) with ESMTP id g84D8Dv16457; Wed, 4 Sep 2002 09:08:13 -0400 (EDT) Received: from ehudwt02.exchange.ml.com (ehudwt02.exchange.ml.com [199.201.37.23]) by telutil13a.ml.com (8.11.3/8.11.3/telutil13a-1.1) with SMTP id g84D8Df13255; Wed, 4 Sep 2002 09:08:13 -0400 (EDT) Received: from 172.25.100.10 by ehudwt02.exchange.ml.com with ESMTP ( Tumbleweed MMS SMTP Relay (MMS v4.7);); Wed, 04 Sep 2002 09:07:48 -0400 X-Server-Uuid: 3789b954-9c4e-11d3-af68-0008c73b0911 Received: by ewst10.exchange.ml.com with Internet Mail Service ( 5.5.2654.52) id ; Wed, 4 Sep 2002 09:07:30 -0400 Message-ID: <9B5CBD4986A9D511BE2100065B045DDF0238BDEB@ehope21.hew.us.ml.com> From: "Liben, Michael (GTS)" To: "'Jim Sermersheim'" , ietf-ldup@imc.org Subject: RE: LCUP issue: Does entryDeleted break the protocol? Date: Wed, 4 Sep 2002 09:07:27 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2654.52) X-WSS-ID: 1168DA2E385677-01-01 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-ldup@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit Result sets are often intermediate 'snapshots' that reflect the result of a query at some point in time. If it is possible that the data is no longer in the result set, it would be appropriate to refresh the result set. -----Original Message----- From: Jim Sermersheim [mailto:jimse@novell.com] Sent: Wednesday, September 04, 2002 12:39 AM To: ietf-ldup@imc.org; Jim Sermersheim Subject: LCUP issue: Does entryDeleted break the protocol? The description for entryDeleted states at first that it indicates that the entry being returned has been deleted--then goes on to say that it also might indicate that the entry has left the result set. In the case of it being due to the entry has left the result set, we need to answer these: 1) If due to a rename, what DN is used (old or new) 2) If the entry is not in the result set, doesn't it break the LDAP protocol to return it (it doesn't match the filter)? Jim From owner-ietf-ldup@mail.imc.org Wed Sep 4 09:23:58 2002 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA27517 for ; Wed, 4 Sep 2002 09:23:58 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g84DJra16827 for ietf-ldup-bks; Wed, 4 Sep 2002 06:19:53 -0700 (PDT) Received: from telutil12a.ml.com (telutil12a-v.ml.com [199.43.34.196]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g84DJp216819 for ; Wed, 4 Sep 2002 06:19:51 -0700 (PDT) Received: from telutil13a.ml.com (telutil13a [146.125.226.11]) by telutil12a.ml.com (8.11.3/8.11.3/telutil12a-1.2) with ESMTP id g84DJnv11588; Wed, 4 Sep 2002 09:19:49 -0400 (EDT) Received: from ehudwt01.exchange.ml.com (ehudwt01.exchange.ml.com [199.201.37.22]) by telutil13a.ml.com (8.11.3/8.11.3/telutil13a-1.1) with SMTP id g84DJnf08888; Wed, 4 Sep 2002 09:19:49 -0400 (EDT) Received: from 169.242.226.175 by ehudwt01.exchange.ml.com with ESMTP ( Tumbleweed MMS SMTP Relay (MMS v4.7);); Wed, 04 Sep 2002 09:19:46 -0400 X-Server-Uuid: 3789b954-9c4e-11d3-af68-0008c73b0911 Received: by ehope08.hew.us.ml.com with Internet Mail Service ( 5.5.2654.52) id ; Wed, 4 Sep 2002 09:19:08 -0400 Message-ID: <9B5CBD4986A9D511BE2100065B045DDF0238BDED@ehope21.hew.us.ml.com> From: "Liben, Michael (GTS)" To: "'steven.legg@adacel.com.au'" , "'John McMeeking'" , ietf-ldup@imc.org Subject: RE: LCUP Issue: UUID Date: Wed, 4 Sep 2002 09:18:57 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2654.52) X-WSS-ID: 1168D7F8475904-01-01 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-ldup@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit I don't think specifying a UUID algorithm is necessary. If the durn thing is universally unique--as its name implies--then specifying the algorithm should be irrelevant. Specifying a 'well-defined sting representation' would be exremely useful. Mike -----Original Message----- From: Steven Legg [mailto:steven.legg@adacel.com.au] Sent: Wednesday, September 04, 2002 2:31 AM To: 'John McMeeking'; ietf-ldup@imc.org Subject: RE: LCUP Issue: UUID John, John McMeeking wrote: > I think that some reasonable uses of the attribute warrant a string > representation. For example, an application may want to search for an > entry with a specific entryuuid. And some LDUP conflict resolution > procedures call for renaming an entry to have a DN like > "cn=some value + > entryuuid=xxxx". Constructing such search filters and DNs is > much cleaner > if entryuuid has a string syntax. I agree. > Granted, a well-written application > should be able to construct search filters and DNs containing binary > values. Case ignore match may be too restrictive. The allComponentsMatch matching rule, already referenced by URP, performs a character by character code-point comparison when applied to a string type (there are some caveats on DirectoryString). This avoids all the letter case, white-space and other normalization that comes with caseIgnoreMatch and caseExactMatch. > Certainly, there is no > reason why an application can't use the entry uuid in the > case provided by > the originating server. > > That aside, don't we have to define what an entry uuid looks > like? Yes. > A maximum size would probably be helpful to > server vendors so > as to not have to provide a search and storage mechanism (DB table for > example) that has to support arbirary length values generated by other > servers. Speaking as a vendor, I already support arbitrary length attribute values. A maximum size for entry uuids would be an irritation rather than an advantage to me. > Just to get things started, I propose that we use the DCE > UUID algorithms, > which have a well defined string representation. And we > should be able to > define a entryuuid syntax with a string representation, which > is probably a > bit cleaner than using "directory string" or "octet string." What character set does the DCE algorithm use ? Would PrintableString or IA5String be sufficient ? Otherwise we can just define an LDAP syntax OID for UTF8String. Regards, Steven From owner-ietf-ldup@mail.imc.org Wed Sep 4 09:30:57 2002 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA27951 for ; Wed, 4 Sep 2002 09:30:57 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g84DRIj17010 for ietf-ldup-bks; Wed, 4 Sep 2002 06:27:18 -0700 (PDT) Received: from wstutil12a.ml.com (wstutil12a-v.ml.com [209.65.19.67]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g84DRH217006 for ; Wed, 4 Sep 2002 06:27:17 -0700 (PDT) Received: from wstutil13a.ml.com (wstutil13a [146.125.185.11]) by wstutil12a.ml.com (8.11.3/8.11.3/wstutil12a-1.2) with ESMTP id g84DRHd14555; Wed, 4 Sep 2002 09:27:18 -0400 (EDT) Received: from ewstwt02.exchange.ml.com (ewstwt02.exchange.ml.com [146.125.249.152]) by wstutil13a.ml.com (8.11.3/8.11.3/wstutil13a-1.1) with SMTP id g84DRG102921; Wed, 4 Sep 2002 09:27:16 -0400 (EDT) Received: from 169.242.226.175 by ewstwt02.exchange.ml.com with ESMTP ( Tumbleweed MMS SMTP Relay (MMS v4.7);); Wed, 04 Sep 2002 09:26:52 -0400 X-Server-Uuid: 3789b954-9c4e-11d3-af68-0008c73b0911 Received: by ehope08.hew.us.ml.com with Internet Mail Service ( 5.5.2654.52) id ; Wed, 4 Sep 2002 09:26:35 -0400 Message-ID: <9B5CBD4986A9D511BE2100065B045DDF0238BDEF@ehope21.hew.us.ml.com> From: "Liben, Michael (GTS)" To: "'Jim Sermersheim'" , ietf-ldup@imc.org Subject: RE: LCUP issue: What is "a while"? Date: Wed, 4 Sep 2002 09:26:32 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2654.52) X-WSS-ID: 1168D596343944-01-01 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-ldup@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit The "MUST wait for a while" would be consistent with most other network algorithms. If it doesn't wait, it may cause unintentional denial of service attacks by swamping the server with connection requests. -----Original Message----- From: Jim Sermersheim [mailto:jimse@novell.com] Sent: Wednesday, September 04, 2002 12:53 AM To: ietf-ldup@imc.org; Jim Sermersheim Subject: LCUP issue: What is "a while"? Section 4.8 states "it MUST wait for a while before attempting another synchronization session with the server. " If we're going to use an imperative like MUST, we ought to not use vague language like "a while". I suggest we drop the MUST anyway--is there an interoperability issue here? Jim From owner-ietf-ldup@mail.imc.org Wed Sep 4 09:34:45 2002 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA28287 for ; Wed, 4 Sep 2002 09:34:45 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g84DVZS17167 for ietf-ldup-bks; Wed, 4 Sep 2002 06:31:35 -0700 (PDT) Received: from wstutil12a.ml.com (wstutil12a-v.ml.com [209.65.19.67]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g84DVX217163 for ; Wed, 4 Sep 2002 06:31:34 -0700 (PDT) Received: from wstutil13a.ml.com (wstutil13a [146.125.185.11]) by wstutil12a.ml.com (8.11.3/8.11.3/wstutil12a-1.2) with ESMTP id g84DVYd24057; Wed, 4 Sep 2002 09:31:34 -0400 (EDT) Received: from ewstwt01.exchange.ml.com (ewstwt03.exchange.ml.com [146.125.249.153]) by wstutil13a.ml.com (8.11.3/8.11.3/wstutil13a-1.1) with SMTP id g84DVY112745; Wed, 4 Sep 2002 09:31:34 -0400 (EDT) Received: from 172.25.100.10 by ewstwt01.exchange.ml.com with ESMTP ( Tumbleweed MMS SMTP Relay (MMS v4.7);); Wed, 04 Sep 2002 09:30:52 -0400 X-Server-Uuid: 3789b954-9c4e-11d3-af68-0008c73b0911 Received: by ewst10.exchange.ml.com with Internet Mail Service ( 5.5.2654.52) id ; Wed, 4 Sep 2002 09:30:51 -0400 Message-ID: <9B5CBD4986A9D511BE2100065B045DDF0238BDF0@ehope21.hew.us.ml.com> From: "Liben, Michael (GTS)" To: "'Kurt D. Zeilenga'" , ietf-ldup@imc.org Subject: RE: LCUP: rename of baseObject (was something else) Date: Wed, 4 Sep 2002 09:30:50 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2654.52) X-WSS-ID: 1168D486340149-01-01 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-ldup@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit I would recommend a requery of the object using a persistent value such as a UUID immediately before attempting an update. This would return the 'current' dn of the object and minimize instances where it has been renamed or deleted. -----Original Message----- From: Kurt D. Zeilenga [mailto:Kurt@OpenLDAP.org] Sent: Wednesday, September 04, 2002 2:19 AM To: ietf-ldup@imc.org Subject: Re: LCUP: rename of baseObject (was something else) At 10:36 PM 2002-09-03, Kurt D. Zeilenga wrote: >At 10:20 PM 2002-09-03, Jim Sermersheim wrote: >>The scenario I was thinking of is one where the base existed when a >>persistent LCUP session starts, but later is renamed or deleted. > >LCUP should be clear on the expected behavior here... Client Considerations implies noSuchObject is returned in this case. This needs to be detailed in Section 4 (along with many other protocol details found in sections 6 and 7). From owner-ietf-ldup@mail.imc.org Wed Sep 4 09:52:20 2002 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA29573 for ; Wed, 4 Sep 2002 09:52:20 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g84Djx717697 for ietf-ldup-bks; Wed, 4 Sep 2002 06:45:59 -0700 (PDT) Received: from prv-mail20.provo.novell.com (prv-mail20.provo.novell.com [137.65.81.122]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g84Djw217693 for ; Wed, 4 Sep 2002 06:45:58 -0700 (PDT) Received: from INET-PRV-MTA by prv-mail20.provo.novell.com with Novell_GroupWise; Wed, 04 Sep 2002 07:45:53 -0600 Message-Id: X-Mailer: Novell GroupWise Internet Agent 6.0.2 Beta Date: Wed, 04 Sep 2002 07:43:04 -0600 From: "Jim Sermersheim" To: Cc: Subject: Re: LCUP issue: sync, then sync and persist Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Disposition: inline Sender: owner-ietf-ldup@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit Ah, seems like this could be done with another field on the update control. Jim >>> "Kurt D. Zeilenga" 09/04/02 12:11AM >>> At 10:51 PM 2002-09-03, Jim Sermersheim wrote: >I don't get it... A synchronizeAndPersist session should return the >complete copy, then drop into the "persist" mode. What am I missing? A sync to persist transition notification. >Jim > >>>> "Kurt D. Zeilenga" 09/03/02 11:50PM >>> >At 10:23 PM 2002-09-03, Jim Sermersheim wrote: >>Why is there a suggestion in Section 6 to "perform an initial >>synchronization...(synchronizeOnly)" and then immediately perform a >>synchronizeAndPersist session? Why not just perform a >>synchronizeAndPersist session to begin with? > >Because the client has no other way to determine that >it presently has a complete copy of the DIT fragment. > >Kurt From owner-ietf-ldup@mail.imc.org Wed Sep 4 09:55:08 2002 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA29754 for ; Wed, 4 Sep 2002 09:55:08 -0400 (EDT) Received: by above.proper.com (8.11.6/8.11.3) id g84DooF17794 for ietf-ldup-bks; Wed, 4 Sep 2002 06:50:50 -0700 (PDT) Received: from prv-mail20.provo.novell.com (prv-mail20.provo.novell.com [137.65.81.122]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g84Don217789 for ; Wed, 4 Sep 2002 06:50:49 -0700 (PDT) Received: from INET-PRV-MTA by prv-mail20.provo.novell.com with Novell_GroupWise; Wed, 04 Sep 2002 07:50:44 -0600 Message-Id: X-Mailer: Novell GroupWise Internet Agent 6.0.2 Beta Date: Wed, 04 Sep 2002 07:47:43 -0600 From: "Jim Sermersheim" To: , , Subject: RE: LCUP: rename of baseObject (was something else) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Disposition: inline Sender: owner-ietf-ldup@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit Often, the LCUP client is not the same, thus not aware of the "updater" and its actions. >>> "Liben, Michael (GTS)" 09/04/02 07:30AM >>> I would recommend a requery of the object using a persistent value such as a UUID immediately before attempting an update. This would return the 'current' dn of the object and minimize instances where it has been renamed or deleted. -----Original Message----- From: Kurt D. Zeilenga [mailto:Kurt@OpenLDAP.org] Sent: Wednesday, September 04, 2002 2:19 AM To: ietf-ldup@imc.org Subject: Re: LCUP: rename of baseObject (was something else) At 10:36 PM 2002-09-03, Kurt D. Zeilenga wrote: >At 10:20 PM 2002-09-03, Jim Sermersheim wrote: >>The scenario I was thinking of is one where the base existed when a >>persistent LCUP session starts, but later is renamed or deleted. > >LCUP should be clear on the expected behavior here... Client Considerations implies noSuchObject is returned in this case. This needs to be detailed in Section 4 (along with many other protocol details found in sections 6 and 7). From owner-ietf-ldup@mail.imc.org Wed Sep 4 10:20:34 2002 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA01100 for ; Wed, 4 Sep 2002 10:20:33 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g84EGUX18617 for ietf-ldup-bks; Wed, 4 Sep 2002 07:16:30 -0700 (PDT) Received: from pretender.boolean.net (root@router.boolean.net [198.144.206.49]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g84EGT218612 for ; Wed, 4 Sep 2002 07:16:29 -0700 (PDT) Received: from nomad.OpenLDAP.org (root@localhost [127.0.0.1]) by pretender.boolean.net (8.12.5/8.12.5) with ESMTP id g84EGUkC005607; Wed, 4 Sep 2002 14:16:30 GMT (envelope-from Kurt@OpenLDAP.org) Message-Id: <5.1.0.14.0.20020904070552.044a8e88@127.0.0.1> X-Sender: kurt@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Wed, 04 Sep 2002 07:15:58 -0700 To: "Jim Sermersheim" From: "Kurt D. Zeilenga" Subject: Re: LCUP issue: sync, then sync and persist Cc: In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-ldup@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: At 06:43 AM 2002-09-04, Jim Sermersheim wrote: >Ah, seems like this could be done with another field on the update >control. IMO, what's needed is a intermediate response PDU indicating the end of the synchronize phase and provide a a new cookie. This not only works when there are no sync events, but also works when there are persist event occurring during synchronization. Calling it an "end of sync phase" marker doesn't prevent an overlapping "persist" phase. I have no problem will allowing an overlapping "persist" phase (as the current I-D does) AS LONG AS it is clear to the client when it has a complete copy of the DIT fragment. Then, we can work on providing the client with a complete and accurate copy... Kurt From owner-ietf-ldup@mail.imc.org Wed Sep 4 11:07:47 2002 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA03912 for ; Wed, 4 Sep 2002 11:07:46 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g84F3j722633 for ietf-ldup-bks; Wed, 4 Sep 2002 08:03:45 -0700 (PDT) Received: from e2.ny.us.ibm.com (e2.ny.us.ibm.com [32.97.182.102]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g84F3h222625; Wed, 4 Sep 2002 08:03:43 -0700 (PDT) Received: from northrelay04.pok.ibm.com (northrelay04.pok.ibm.com [9.56.224.206]) by e2.ny.us.ibm.com (8.12.2/8.12.2) with ESMTP id g84F0fIV100016; Wed, 4 Sep 2002 11:00:42 -0400 Received: from d27ml001.rchland.ibm.com (d27ml001.rchland.ibm.com [9.10.226.142]) by northrelay04.pok.ibm.com (8.12.3/NCO/VER6.4) with ESMTP id g84F0cMO077130; Wed, 4 Sep 2002 11:00:38 -0400 Subject: RE: LCUP Issue: UUID To: "Liben, Michael (GTS)" Cc: ietf-ldup@imc.org, owner-ietf-ldup@mail.imc.org, "'steven.legg@adacel.com.au'" X-Mailer: Lotus Notes Release 5.0.10 March 22, 2002 Message-ID: From: John McMeeking Date: Wed, 4 Sep 2002 10:00:37 -0500 X-MIMETrack: Serialize by Router on d27ml001/27/M/IBM(Build V60_07142002NP|July 14, 2002) at 09/04/2002 10:00:38 MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII Sender: owner-ietf-ldup@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Michael, If the UUID has to be unique across all entries on all servers (as required by LDUP), then you do need to have an algorithm or combination of algorithm and value. As single server could use any algorithm it wants and guarantee uniqueness across all entries on that server. It cannot guarantee that any given value it generates does not conflict with a value generated on another server using the same or different algorithm. Even if the algorithm generates universally unique values (the DCE UUID algorithm, for example), those values are unique only if everyone uses the same algorithm. The "foo" algorithm could generate universally unique values, but if it happens to generate values that are the same size as DCE UUIDs, they will eventually collide. John McMeeking "Liben, Michael (GTS)" To: "'steven.legg@adacel.com.au'" , John cc: Sent by: owner- Subject: RE: LCUP Issue: UUID ietf-ldup@mail. imc.org 09/04/2002 08:18 AM I don't think specifying a UUID algorithm is necessary. If the durn thing is universally unique--as its name implies--then specifying the algorithm should be irrelevant. Specifying a 'well-defined sting representation' would be exremely useful. Mike -----Original Message----- From: Steven Legg [mailto:steven.legg@adacel.com.au] Sent: Wednesday, September 04, 2002 2:31 AM To: 'John McMeeking'; ietf-ldup@imc.org Subject: RE: LCUP Issue: UUID John, John McMeeking wrote: > I think that some reasonable uses of the attribute warrant a string > representation. For example, an application may want to search for an > entry with a specific entryuuid. And some LDUP conflict resolution > procedures call for renaming an entry to have a DN like > "cn=some value + > entryuuid=xxxx". Constructing such search filters and DNs is > much cleaner > if entryuuid has a string syntax. I agree. > Granted, a well-written application > should be able to construct search filters and DNs containing binary > values. Case ignore match may be too restrictive. The allComponentsMatch matching rule, already referenced by URP, performs a character by character code-point comparison when applied to a string type (there are some caveats on DirectoryString). This avoids all the letter case, white-space and other normalization that comes with caseIgnoreMatch and caseExactMatch. > Certainly, there is no > reason why an application can't use the entry uuid in the > case provided by > the originating server. > > That aside, don't we have to define what an entry uuid looks > like? Yes. > A maximum size would probably be helpful to > server vendors so > as to not have to provide a search and storage mechanism (DB table for > example) that has to support arbirary length values generated by other > servers. Speaking as a vendor, I already support arbitrary length attribute values. A maximum size for entry uuids would be an irritation rather than an advantage to me. > Just to get things started, I propose that we use the DCE > UUID algorithms, > which have a well defined string representation. And we > should be able to > define a entryuuid syntax with a string representation, which > is probably a > bit cleaner than using "directory string" or "octet string." What character set does the DCE algorithm use ? Would PrintableString or IA5String be sufficient ? Otherwise we can just define an LDAP syntax OID for UTF8String. Regards, Steven From owner-ietf-ldup@mail.imc.org Wed Sep 4 15:26:57 2002 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA17450 for ; Wed, 4 Sep 2002 15:26:57 -0400 (EDT) Received: by above.proper.com (8.11.6/8.11.3) id g84JKnp05139 for ietf-ldup-bks; Wed, 4 Sep 2002 12:20:49 -0700 (PDT) Received: from netscape.com (r2d2.netscape.com [205.217.237.47]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g84JKm205134 for ; Wed, 4 Sep 2002 12:20:48 -0700 (PDT) Received: from judge.mcom.com (judge.nscp.aoltw.net [10.169.8.47]) by netscape.com (8.10.0/8.10.0) with ESMTP id g84IV7u02769 for ; Wed, 4 Sep 2002 11:31:07 -0700 (PDT) Received: from netscape.com ([10.169.192.36]) by judge.mcom.com (Netscape Messaging Server 4.15) with ESMTP id H1XHQ301.DLT; Wed, 4 Sep 2002 12:20:27 -0700 Message-ID: <3D765D02.3090507@netscape.com> Date: Wed, 04 Sep 2002 15:20:34 -0400 From: mcs@netscape.com (Mark C Smith) Organization: Netscape Communications Corp. User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.1) Gecko/20020823 Netscape/7.0 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Jim Sermersheim CC: ietf-ldup@imc.org Subject: Re: LCUP issue: trigger mechanism or not? References: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-ldup@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit Jim Sermersheim wrote: > > The draft states that it "is intended to allow LDAP clients to > synchronize with the content stored by LDAP servers". but also states > that it wants to solve the problem of triggered actions (Section 3, > Bullet 3). I agree that triggered actions should be within LCUP's scope. The LCUP authors have tried to balance the server implementation burden with the client implementation burden. In particular, I would really like to avoid creating an LCUP protocol that requires a server to store client-specific state (that just won't scale when their are thousands or hundreds of thousands of clients). > Most of the rest of the draft is consistent with the notion of > synchronization, but tends to downplay support for triggered responses. > Do we want this to be a useful event driver, or is the idea that we just > preserve the easy stuff of what prior drafts could do? > > Specifically, the left-out items in Sections 5.1, 5.2, and 5.3 deter > from the effectiveness of the "persist" mode. > > Curent users of Persistent Search rely on the notion of change types. > Section 5.2 assumes that change types are used for partial replication, > and thus discounts them as useful for LCUP. I don't think this is > valid. Are you saying that LCUP should support clients that only want to store a subset of the entries that are targetted by the LCUP search they issue? Even if you do want to support that, I don't see the problem. The LCUP model (as defined today) is that it is up to the client to determine whether a change is interesting or not. The assumption is that clients will store UUIDs for each entry they are interested in, and that the client can compare stored data with the new entry data to determine what has changed. That does not seem like an excessive burden to me. A related comment: perhaps section 5 should be moved to an appendix that is named "Features Left Out of LCUP." It is not core to LCUP, but is useful to provide historical context and rationale for why some things are not included in LCUP. -Mark Smith Netscape From owner-ietf-ldup@mail.imc.org Wed Sep 4 15:31:22 2002 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA17764 for ; Wed, 4 Sep 2002 15:31:21 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g84JR1m05486 for ietf-ldup-bks; Wed, 4 Sep 2002 12:27:01 -0700 (PDT) Received: from wstutil12a.ml.com (wstutil12a-v.ml.com [209.65.19.67]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g84JQx205478; Wed, 4 Sep 2002 12:26:59 -0700 (PDT) Received: from wstutil13a.ml.com (wstutil13a [146.125.185.11]) by wstutil12a.ml.com (8.11.3/8.11.3/wstutil12a-1.2) with ESMTP id g84JQWd06947; Wed, 4 Sep 2002 15:26:32 -0400 (EDT) Received: from ewstwt02.exchange.ml.com (ewstwt02.exchange.ml.com [146.125.249.152]) by wstutil13a.ml.com (8.11.3/8.11.3/wstutil13a-1.1) with SMTP id g84JQV129759; Wed, 4 Sep 2002 15:26:31 -0400 (EDT) Received: from 172.25.100.10 by ewstwt02.exchange.ml.com with ESMTP ( Tumbleweed MMS SMTP Relay (MMS v4.7);); Wed, 04 Sep 2002 15:26:06 -0400 X-Server-Uuid: 3789b954-9c4e-11d3-af68-0008c73b0911 Received: by ewst10.exchange.ml.com with Internet Mail Service ( 5.5.2654.52) id ; Wed, 4 Sep 2002 15:25:47 -0400 Message-ID: <9B5CBD4986A9D511BE2100065B045DDF0238BDFC@ehope21.hew.us.ml.com> From: "Liben, Michael (GTS)" To: "'John McMeeking'" , "Liben, Michael (GTS)" cc: ietf-ldup@imc.org, owner-ietf-ldup@mail.imc.org, "'steven.legg@adacel.com.au'" Subject: RE: LCUP Issue: UUID Date: Wed, 4 Sep 2002 15:25:44 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2654.52) X-WSS-ID: 116881C426545-01-01 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-ldup@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit The UUID only needs to be unique in the DIT in which it has meaning (the context). As long as the server(s) holding the DIT create the UUID using a consistent algorithm (server-assigned per the spec), we shouldn't care which algorithm is employed. Combined with a server-assigned LCUP cookie, the opportunity of collision is academic at best. -----Original Message----- From: John McMeeking [mailto:jmcmeek@us.ibm.com] Sent: Wednesday, September 04, 2002 11:01 AM To: Liben, Michael (GTS) Cc: ietf-ldup@imc.org; owner-ietf-ldup@mail.imc.org; 'steven.legg@adacel.com.au' Subject: RE: LCUP Issue: UUID Michael, If the UUID has to be unique across all entries on all servers (as required by LDUP), then you do need to have an algorithm or combination of algorithm and value. As single server could use any algorithm it wants and guarantee uniqueness across all entries on that server. It cannot guarantee that any given value it generates does not conflict with a value generated on another server using the same or different algorithm. Even if the algorithm generates universally unique values (the DCE UUID algorithm, for example), those values are unique only if everyone uses the same algorithm. The "foo" algorithm could generate universally unique values, but if it happens to generate values that are the same size as DCE UUIDs, they will eventually collide. John McMeeking "Liben, Michael (GTS)" To: "'steven.legg@adacel.com.au'" , John cc: Sent by: owner- Subject: RE: LCUP Issue: UUID ietf-ldup@mail. imc.org 09/04/2002 08:18 AM I don't think specifying a UUID algorithm is necessary. If the durn thing is universally unique--as its name implies--then specifying the algorithm should be irrelevant. Specifying a 'well-defined sting representation' would be exremely useful. Mike -----Original Message----- From: Steven Legg [mailto:steven.legg@adacel.com.au] Sent: Wednesday, September 04, 2002 2:31 AM To: 'John McMeeking'; ietf-ldup@imc.org Subject: RE: LCUP Issue: UUID John, John McMeeking wrote: > I think that some reasonable uses of the attribute warrant a string > representation. For example, an application may want to search for an > entry with a specific entryuuid. And some LDUP conflict resolution > procedures call for renaming an entry to have a DN like > "cn=some value + > entryuuid=xxxx". Constructing such search filters and DNs is > much cleaner > if entryuuid has a string syntax. I agree. > Granted, a well-written application > should be able to construct search filters and DNs containing binary > values. Case ignore match may be too restrictive. The allComponentsMatch matching rule, already referenced by URP, performs a character by character code-point comparison when applied to a string type (there are some caveats on DirectoryString). This avoids all the letter case, white-space and other normalization that comes with caseIgnoreMatch and caseExactMatch. > Certainly, there is no > reason why an application can't use the entry uuid in the > case provided by > the originating server. > > That aside, don't we have to define what an entry uuid looks > like? Yes. > A maximum size would probably be helpful to > server vendors so > as to not have to provide a search and storage mechanism (DB table for > example) that has to support arbirary length values generated by other > servers. Speaking as a vendor, I already support arbitrary length attribute values. A maximum size for entry uuids would be an irritation rather than an advantage to me. > Just to get things started, I propose that we use the DCE > UUID algorithms, > which have a well defined string representation. And we > should be able to > define a entryuuid syntax with a string representation, which > is probably a > bit cleaner than using "directory string" or "octet string." What character set does the DCE algorithm use ? Would PrintableString or IA5String be sufficient ? Otherwise we can just define an LDAP syntax OID for UTF8String. Regards, Steven From owner-ietf-ldup@mail.imc.org Wed Sep 4 16:00:40 2002 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA19054 for ; Wed, 4 Sep 2002 16:00:39 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g84Jt7N07473 for ietf-ldup-bks; Wed, 4 Sep 2002 12:55:07 -0700 (PDT) Received: from pretender.boolean.net (root@router.boolean.net [198.144.206.49]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g84Jt5207465; Wed, 4 Sep 2002 12:55:05 -0700 (PDT) Received: from nomad.OpenLDAP.org (root@localhost [127.0.0.1]) by pretender.boolean.net (8.12.5/8.12.5) with ESMTP id g84JsYkC007713; Wed, 4 Sep 2002 19:54:35 GMT (envelope-from Kurt@OpenLDAP.org) Message-Id: <5.1.0.14.0.20020904124055.044ac570@127.0.0.1> X-Sender: kurt@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Wed, 04 Sep 2002 12:54:08 -0700 To: "Liben, Michael (GTS)" From: "Kurt D. Zeilenga" Subject: RE: LCUP Issue: UUID Cc: "'John McMeeking'" , "Liben, Michael (GTS)" , ietf-ldup@imc.org, owner-ietf-ldup@mail.imc.org, "'steven.legg@adacel.com.au'" In-Reply-To: <9B5CBD4986A9D511BE2100065B045DDF0238BDFC@ehope21.hew.us.ml .com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-ldup@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: At 12:25 PM 2002-09-04, Liben, Michael (GTS) wrote: >The UUID only needs to be unique in the DIT in which it has meaning (the context). LDAP and X.500 are designed to support a global DIT. >As long as the server(s) holding the DIT create the UUID using a consistent algorithm (server-assigned per the spec), >we shouldn't care which algorithm is employed. Consider a server which masters one context and shadows a subordinate context. UUIDs in the spanning LCUP context must be unique. This requires that both servers (this one and the own who masters the shadowed context) need to agree on the algorithm to be employed. To ensure interoperability, a standard algorithm should be implemented by both. A REQUIRED algorithm is needed. In my opinion, UUIDs in LDAP should conform to ISO/IEC 11578:1996. >Combined with a server-assigned LCUP cookie, the opportunity of collision is academic at best. If entryUUID were only to be used by LCUP, I might agree with you. But I believe the desire is to define entryUUID so that they have broader applicability. (Which is one of the reasons why I believe entryUUID and entryCSN should be detailed in a separate document.) Kurt From owner-ietf-ldup@mail.imc.org Wed Sep 4 16:03:40 2002 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA19181 for ; Wed, 4 Sep 2002 16:03:39 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g84JxCE07540 for ietf-ldup-bks; Wed, 4 Sep 2002 12:59:12 -0700 (PDT) Received: from pretender.boolean.net (root@router.boolean.net [198.144.206.49]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g84JxA207536 for ; Wed, 4 Sep 2002 12:59:10 -0700 (PDT) Received: from nomad.OpenLDAP.org (root@localhost [127.0.0.1]) by pretender.boolean.net (8.12.5/8.12.5) with ESMTP id g84JxDkC007731; Wed, 4 Sep 2002 19:59:13 GMT (envelope-from Kurt@OpenLDAP.org) Message-Id: <5.1.0.14.0.20020904125829.044d0580@127.0.0.1> X-Sender: kurt@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Wed, 04 Sep 2002 12:58:46 -0700 To: mcs@netscape.com (Mark C Smith) From: "Kurt D. Zeilenga" Subject: Re: LCUP issue: trigger mechanism or not? Cc: Jim Sermersheim , ietf-ldup@imc.org In-Reply-To: <3D765D02.3090507@netscape.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-ldup@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: At 12:20 PM 2002-09-04, Mark C Smith wrote: >A related comment: perhaps section 5 should be moved to an appendix that is named "Features Left Out of LCUP." It is not core to LCUP, but is useful to provide historical context and rationale for why some things are not included in LCUP. I concur. Kurt From owner-ietf-ldup@mail.imc.org Wed Sep 4 16:12:13 2002 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA19487 for ; Wed, 4 Sep 2002 16:12:12 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g84K8hr07682 for ietf-ldup-bks; Wed, 4 Sep 2002 13:08:43 -0700 (PDT) Received: from telutil12a.ml.com (telutil12a-v.ml.com [199.43.34.196]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g84K8g207678; Wed, 4 Sep 2002 13:08:42 -0700 (PDT) Received: from telutil13a.ml.com (telutil13a [146.125.226.11]) by telutil12a.ml.com (8.11.3/8.11.3/telutil12a-1.2) with ESMTP id g84K8Fv11113; Wed, 4 Sep 2002 16:08:15 -0400 (EDT) Received: from ehudwt01.exchange.ml.com (ehudwt01.exchange.ml.com [199.201.37.22]) by telutil13a.ml.com (8.11.3/8.11.3/telutil13a-1.1) with SMTP id g84K8Ef15672; Wed, 4 Sep 2002 16:08:14 -0400 (EDT) Received: from 169.242.226.175 by ehudwt01.exchange.ml.com with ESMTP ( Tumbleweed MMS SMTP Relay (MMS v4.7);); Wed, 04 Sep 2002 16:08:12 -0400 X-Server-Uuid: 3789b954-9c4e-11d3-af68-0008c73b0911 Received: by ehope08.hew.us.ml.com with Internet Mail Service ( 5.5.2654.52) id ; Wed, 4 Sep 2002 16:07:30 -0400 Message-ID: <9B5CBD4986A9D511BE2100065B045DDF0238BDFD@ehope21.hew.us.ml.com> From: "Liben, Michael (GTS)" To: "'Kurt D. Zeilenga'" , "Liben, Michael (GTS)" cc: "'John McMeeking'" , "Liben, Michael (GTS)" , ietf-ldup@imc.org, owner-ietf-ldup@mail.imc.org, "'steven.legg@adacel.com.au'" Subject: RE: LCUP Issue: UUID Date: Wed, 4 Sep 2002 16:07:21 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2654.52) X-WSS-ID: 1168B7A611134-01-01 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-ldup@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit -----Original Message----- From: Kurt D. Zeilenga [mailto:Kurt@OpenLDAP.org] Sent: Wednesday, September 04, 2002 3:54 PM To: Liben, Michael (GTS) Cc: 'John McMeeking'; Liben, Michael (GTS); ietf-ldup@imc.org; owner-ietf-ldup@mail.imc.org; 'steven.legg@adacel.com.au' Subject: RE: LCUP Issue: UUID At 12:25 PM 2002-09-04, Liben, Michael (GTS) wrote: >>The UUID only needs to be unique in the DIT in which it has meaning (the context). >LDAP and X.500 are designed to support a global DIT. Is that a global DIT or a global namespace? I believe the DIT would be appropriately partitioned into administrative contexts. From owner-ietf-ldup@mail.imc.org Wed Sep 4 16:37:21 2002 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA20599 for ; Wed, 4 Sep 2002 16:37:20 -0400 (EDT) Received: by above.proper.com (8.11.6/8.11.3) id g84KVsZ08151 for ietf-ldup-bks; Wed, 4 Sep 2002 13:31:54 -0700 (PDT) Received: from pretender.boolean.net (root@router.boolean.net [198.144.206.49]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g84KVq208141; Wed, 4 Sep 2002 13:31:52 -0700 (PDT) Received: from nomad.OpenLDAP.org (root@localhost [127.0.0.1]) by pretender.boolean.net (8.12.5/8.12.5) with ESMTP id g84KVHkC007841; Wed, 4 Sep 2002 20:31:17 GMT (envelope-from Kurt@OpenLDAP.org) Message-Id: <5.1.0.14.0.20020904132143.044b2c38@127.0.0.1> X-Sender: kurt@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Wed, 04 Sep 2002 13:30:51 -0700 To: "Liben, Michael (GTS)" From: "Kurt D. Zeilenga" Subject: RE: LCUP Issue: UUID Cc: "Liben, Michael (GTS)" , "'John McMeeking'" , "Liben, Michael (GTS)" , ietf-ldup@imc.org, owner-ietf-ldup@mail.imc.org, "'steven.legg@adacel.com.au'" In-Reply-To: <9B5CBD4986A9D511BE2100065B045DDF0238BDFD@ehope21.hew.us.ml .com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-ldup@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: At 01:07 PM 2002-09-04, Liben, Michael (GTS) wrote: >-----Original Message----- >From: Kurt D. Zeilenga [mailto:Kurt@OpenLDAP.org] >Sent: Wednesday, September 04, 2002 3:54 PM >To: Liben, Michael (GTS) >Cc: 'John McMeeking'; Liben, Michael (GTS); ietf-ldup@imc.org; owner-ietf-ldup@mail.imc.org; 'steven.legg@adacel.com.au' >Subject: RE: LCUP Issue: UUID > >At 12:25 PM 2002-09-04, Liben, Michael (GTS) wrote: >>>The UUID only needs to be unique in the DIT in which it has meaning (the context). > >>LDAP and X.500 are designed to support a global DIT. > >Is that a global DIT or a global namespace? Global DIT. >I believe the DIT would be appropriately partitioned into administrative contexts. The global DIT can be appropriately partitioned into administrative contexts. Bring this back to UUIDs... the universe of an entry UUIDs is the global DIT. From owner-ietf-ldup@mail.imc.org Wed Sep 4 17:08:10 2002 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA21604 for ; Wed, 4 Sep 2002 17:08:09 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g84L1tl11690 for ietf-ldup-bks; Wed, 4 Sep 2002 14:01:55 -0700 (PDT) Received: from pretender.boolean.net (root@router.boolean.net [198.144.206.49]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g84L1s211684 for ; Wed, 4 Sep 2002 14:01:54 -0700 (PDT) Received: from nomad.OpenLDAP.org (root@localhost [127.0.0.1]) by pretender.boolean.net (8.12.5/8.12.5) with ESMTP id g84L1skC007983; Wed, 4 Sep 2002 21:01:54 GMT (envelope-from Kurt@OpenLDAP.org) Message-Id: <5.1.0.14.0.20020904134656.044711e0@127.0.0.1> X-Sender: kurt@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Wed, 04 Sep 2002 14:01:28 -0700 To: "Liben, Michael (GTS)" From: "Kurt D. Zeilenga" Subject: RE: LCUP issue: What is "a while"? Cc: "'Jim Sermersheim'" , ietf-ldup@imc.org In-Reply-To: <9B5CBD4986A9D511BE2100065B045DDF0238BDEF@ehope21.hew.us.ml .com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-ldup@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: At 06:26 AM 2002-09-04, Liben, Michael (GTS) wrote: >The "MUST wait for a while" would be consistent with most other network algorithms. If it doesn't wait, it may cause unintentional denial of service attacks by swamping the server with connection requests. Jim's comment was that the phrase "MUST wait a while" is a meaningless mandatory requirement. A nanosecond can be viewed as a long while in some contexts, a century can be viewed as a short while in some contexts. While the document could attempt to define what an appropriate while is in this context, the document likely would be better off not stating this as mandatory requirement. Kurt >-----Original Message----- >From: Jim Sermersheim [mailto:jimse@novell.com] >Sent: Wednesday, September 04, 2002 12:53 AM >To: ietf-ldup@imc.org; Jim Sermersheim >Subject: LCUP issue: What is "a while"? > > >Section 4.8 states "it MUST wait for a while before attempting another >synchronization session with the server. " > >If we're going to use an imperative like MUST, we ought to not use >vague language like "a while". I suggest we drop the MUST anyway--is >there an interoperability issue here? > >Jim From owner-ietf-ldup@mail.imc.org Wed Sep 4 23:04:21 2002 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA28760 for ; Wed, 4 Sep 2002 23:04:21 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g8530NF27094 for ietf-ldup-bks; Wed, 4 Sep 2002 20:00:23 -0700 (PDT) Received: from pretender.boolean.net (root@router.boolean.net [198.144.206.49]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g8530M227088 for ; Wed, 4 Sep 2002 20:00:22 -0700 (PDT) Received: from nomad.OpenLDAP.org (root@localhost [127.0.0.1]) by pretender.boolean.net (8.12.5/8.12.5) with ESMTP id g8530Qft001190 for ; Thu, 5 Sep 2002 03:00:26 GMT (envelope-from Kurt@OpenLDAP.org) Message-Id: <5.1.0.14.0.20020904193928.0450c878@127.0.0.1> X-Sender: kurt@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Wed, 04 Sep 2002 19:59:59 -0700 To: ietf-ldup@imc.org From: "Kurt D. Zeilenga" Subject: LCUP: subordinate references Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-ldup@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: The document is quite unclear how references are to be handled. What happens when a named subordinate referral object [RFC 3296] within scope of the search is added, deleted, or modified? One approach is would be to return a searchResultReference with a control much like the EntryUpdateControl, but with the UUID of the referral object. Or one could just redefine (and rename) the EntryUpdateControl to include the UUID. (As I noted previously, that would avoid the problems created by clients not requesting entryUUID or servers not returning it.) Another approach would be require the presence of the ManageDsaIT control in the request. This, basically, requests that all referral objects be treated as entry objects. However, the problem with this, is that the ManageDsaIT control may be used to manage other kinds of knowledge information. It selects a management plane within the DsaIT. An LCUP with ManageDsaIT should be treated as a LCUP request within the management plane normally selected by the ManageDsaIt. So, I think this is not an appropriate solution. Another option is to just to say the all referral objects are treated as entry objects when the LCUP control is present. There may be other options. I'm not sure what the best option is.... Kurt From owner-ietf-ldup@mail.imc.org Wed Sep 4 23:27:21 2002 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA29105 for ; Wed, 4 Sep 2002 23:27:20 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g853NvY27703 for ietf-ldup-bks; Wed, 4 Sep 2002 20:23:57 -0700 (PDT) Received: from pretender.boolean.net (root@router.boolean.net [198.144.206.49]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g853Nu227695 for ; Wed, 4 Sep 2002 20:23:56 -0700 (PDT) Received: from nomad.OpenLDAP.org (root@localhost [127.0.0.1]) by pretender.boolean.net (8.12.5/8.12.5) with ESMTP id g853Nxft001675 for ; Thu, 5 Sep 2002 03:23:59 GMT (envelope-from Kurt@OpenLDAP.org) Message-Id: <5.1.0.14.0.20020904200549.044d1380@127.0.0.1> X-Sender: kurt@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Wed, 04 Sep 2002 20:23:32 -0700 To: ietf-ldup@imc.org From: "Kurt D. Zeilenga" Subject: LCUP: collective attributes, subentries, etc. Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-ldup@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Some statement should be made with how LCUP interacts with collective attributes appearing both in the filter and returned entries. The simple approach would be to say: 1) filter should not contain assertions upon collective attributes, 2) changes to an collective subentry will not cause entries within the collection to be "updated", 3) clients are interested in maintaining sync with collective attributes should include the collective subentry within an LCUP request. Which leads to my next question: how does a client ask for update of both entry and subentry DSEs subordinate to the baseObject object? This is similar to the subordinate referral issue. One could generalize the question to: How does a client ask for update of all DSEs of a particular combination of DSE types subordinate to the baseObject? Kurt From owner-ietf-ldup@mail.imc.org Wed Sep 4 23:31:56 2002 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA29180 for ; Wed, 4 Sep 2002 23:31:56 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g853SVP28092 for ietf-ldup-bks; Wed, 4 Sep 2002 20:28:31 -0700 (PDT) Received: from prv-mail20.provo.novell.com (prv-mail20.provo.novell.com [137.65.81.122]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g853SU228086 for ; Wed, 4 Sep 2002 20:28:30 -0700 (PDT) Received: from INET-PRV-MTA by prv-mail20.provo.novell.com with Novell_GroupWise; Wed, 04 Sep 2002 21:28:28 -0600 Message-Id: X-Mailer: Novell GroupWise Internet Agent 6.0.2 Beta Date: Wed, 04 Sep 2002 21:25:25 -0600 From: "Jim Sermersheim" To: Cc: Subject: Re: LCUP issue: trigger mechanism or not? Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Disposition: inline Sender: owner-ietf-ldup@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit >>> Mark C Smith 09/04/02 01:20PM >>> >Jim Sermersheim wrote: > > >> The draft states that it "is intended to allow LDAP clients to >> synchronize with the content stored by LDAP servers". but also states >> that it wants to solve the problem of triggered actions (Section 3, >> Bullet 3). > >I agree that triggered actions should be within LCUP's scope. The LCUP >authors have tried to balance the server implementation burden with the >client implementation burden. In particular, I would really like to >avoid creating an LCUP protocol that requires a server to store >client-specific state (that just won't scale when their are thousands or >hundreds of thousands of clients). > > >> Most of the rest of the draft is consistent with the notion of >> synchronization, but tends to downplay support for triggered responses. >> Do we want this to be a useful event driver, or is the idea that we just >> preserve the easy stuff of what prior drafts could do? >> >> Specifically, the left-out items in Sections 5.1, 5.2, and 5.3 deter >> from the effectiveness of the "persist" mode. >> >> Current users of Persistent Search rely on the notion of change types. >> Section 5.2 assumes that change types are used for partial replication, >> and thus discounts them as useful for LCUP. I don't think this is >> valid. > >Are you saying that LCUP should support clients that only want to store > a subset of the entries that are targetted by the LCUP search they >issue? No, even worse. I'm saying there are clients that wish to store nothing. They only want to be triggered when a certain action occurs. >Even if you do want to support that, I don't see the problem. The >LCUP model (as defined today) is that it is up to the client to >determine whether a change is interesting or not. The assumption is that >clients will store UUIDs for each entry they are interested in, and that >the client can compare stored data with the new entry data to determine >what has changed. That does not seem like an excessive burden to me. For a client that stores nothing, and makes no comparisons today with psearch, the extra burden is huge. >A related comment: perhaps section 5 should be moved to an appendix that >is named "Features Left Out of LCUP." It is not core to LCUP, but is >useful to provide historical context and rationale for why some things >are not included in LCUP. > >-Mark Smith > Netscape Jim From owner-ietf-ldup@mail.imc.org Wed Sep 4 23:36:13 2002 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA29239 for ; Wed, 4 Sep 2002 23:36:12 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g853VSf28499 for ietf-ldup-bks; Wed, 4 Sep 2002 20:31:28 -0700 (PDT) Received: from prv-mail20.provo.novell.com (prv-mail20.provo.novell.com [137.65.81.122]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g853VQ228486 for ; Wed, 4 Sep 2002 20:31:26 -0700 (PDT) Received: from INET-PRV-MTA by prv-mail20.provo.novell.com with Novell_GroupWise; Wed, 04 Sep 2002 21:31:25 -0600 Message-Id: X-Mailer: Novell GroupWise Internet Agent 6.0.2 Beta Date: Wed, 04 Sep 2002 21:28:33 -0600 From: "Jim Sermersheim" To: , Cc: , , , Subject: RE: LCUP Issue: UUID Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Disposition: inline Sender: owner-ietf-ldup@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit I agree. if the attribute is called entryUUID it should be unique within the universe of the global DIT. Otherwise, call it an lcupUID. Jim >>> "Kurt D. Zeilenga" 09/04/02 01:54PM >>> At 12:25 PM 2002-09-04, Liben, Michael (GTS) wrote: >The UUID only needs to be unique in the DIT in which it has meaning (the context). LDAP and X.500 are designed to support a global DIT. >As long as the server(s) holding the DIT create the UUID using a consistent algorithm (server-assigned per the spec), >we shouldn't care which algorithm is employed. Consider a server which masters one context and shadows a subordinate context. UUIDs in the spanning LCUP context must be unique. This requires that both servers (this one and the own who masters the shadowed context) need to agree on the algorithm to be employed. To ensure interoperability, a standard algorithm should be implemented by both. A REQUIRED algorithm is needed. In my opinion, UUIDs in LDAP should conform to ISO/IEC 11578:1996. >Combined with a server-assigned LCUP cookie, the opportunity of collision is academic at best. If entryUUID were only to be used by LCUP, I might agree with you. But I believe the desire is to define entryUUID so that they have broader applicability. (Which is one of the reasons why I believe entryUUID and entryCSN should be detailed in a separate document.) Kurt From owner-ietf-ldup@mail.imc.org Wed Sep 4 23:39:41 2002 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA29292 for ; Wed, 4 Sep 2002 23:39:41 -0400 (EDT) Received: by above.proper.com (8.11.6/8.11.3) id g853Zut28682 for ietf-ldup-bks; Wed, 4 Sep 2002 20:35:56 -0700 (PDT) Received: from prv-mail20.provo.novell.com (prv-mail20.provo.novell.com [137.65.81.122]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g853Zs228678 for ; Wed, 4 Sep 2002 20:35:55 -0700 (PDT) Received: from INET-PRV-MTA by prv-mail20.provo.novell.com with Novell_GroupWise; Wed, 04 Sep 2002 21:35:53 -0600 Message-Id: X-Mailer: Novell GroupWise Internet Agent 6.0.2 Beta Date: Wed, 04 Sep 2002 21:33:01 -0600 From: "Jim Sermersheim" To: , Subject: Re: LCUP: subordinate references Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Disposition: inline Sender: owner-ietf-ldup@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit I tend to prefer something like the first approach (for add, and mod). I guess a delete would just be a delete. >>> "Kurt D. Zeilenga" 09/04/02 08:59PM >>> The document is quite unclear how references are to be handled. What happens when a named subordinate referral object [RFC 3296] within scope of the search is added, deleted, or modified? One approach is would be to return a searchResultReference with a control much like the EntryUpdateControl, but with the UUID of the referral object. Or one could just redefine (and rename) the EntryUpdateControl to include the UUID. (As I noted previously, that would avoid the problems created by clients not requesting entryUUID or servers not returning it.) Another approach would be require the presence of the ManageDsaIT control in the request. This, basically, requests that all referral objects be treated as entry objects. However, the problem with this, is that the ManageDsaIT control may be used to manage other kinds of knowledge information. It selects a management plane within the DsaIT. An LCUP with ManageDsaIT should be treated as a LCUP request within the management plane normally selected by the ManageDsaIt. So, I think this is not an appropriate solution. Another option is to just to say the all referral objects are treated as entry objects when the LCUP control is present. There may be other options. I'm not sure what the best option is.... Kurt From owner-ietf-ldup@mail.imc.org Wed Sep 4 23:56:09 2002 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA29546 for ; Wed, 4 Sep 2002 23:56:08 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g853poC29681 for ietf-ldup-bks; Wed, 4 Sep 2002 20:51:50 -0700 (PDT) Received: from prv-mail20.provo.novell.com (prv-mail20.provo.novell.com [137.65.81.122]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g853pn229676 for ; Wed, 4 Sep 2002 20:51:49 -0700 (PDT) Received: from INET-PRV-MTA by prv-mail20.provo.novell.com with Novell_GroupWise; Wed, 04 Sep 2002 21:51:47 -0600 Message-Id: X-Mailer: Novell GroupWise Internet Agent 6.0.2 Beta Date: Wed, 04 Sep 2002 21:48:58 -0600 From: "Jim Sermersheim" To: Subject: LCUP: operational attributes Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Disposition: inline Sender: owner-ietf-ldup@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit Along with the issue Kurt raised in the message "LCUP: collective attributes, subentries, etc", we need to state how updates to operational attributes (both stored and not stored) affect LCUP. There are different classes of this: 1) A server internally increments a numSubordinates attribute on the parent of an entry being added or deleted (server responding to client action) 2) A server modifies replication-related information (server responding to bilateral processes) 3) A server updates the state of a transitional attribute (response to an internal, timed operation) 4) An entire set of operations like those above that affect the value of an operational attribute, but the value is generated dynamically, only when read by a client. 5) A client updates an operational attribute. We should also discuss any differences in behavior among the three different types of operational attribute (directoryOperation, distributedOperation, dSAOperation). Jim From owner-ietf-ldup@mail.imc.org Thu Sep 5 00:01:14 2002 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA29629 for ; Thu, 5 Sep 2002 00:01:13 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g853u8Q00283 for ietf-ldup-bks; Wed, 4 Sep 2002 20:56:08 -0700 (PDT) Received: from prv-mail20.provo.novell.com (prv-mail20.provo.novell.com [137.65.81.122]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g853u7200279 for ; Wed, 4 Sep 2002 20:56:07 -0700 (PDT) Received: from INET-PRV-MTA by prv-mail20.provo.novell.com with Novell_GroupWise; Wed, 04 Sep 2002 21:56:05 -0600 Message-Id: X-Mailer: Novell GroupWise Internet Agent 6.0.2 Beta Date: Wed, 04 Sep 2002 21:53:21 -0600 From: "Jim Sermersheim" To: Subject: LCUP: Changes to attributes not in attributes list Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Disposition: inline Sender: owner-ietf-ldup@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit When we implemented psearch, there was contention over whether or not the client should be updated when a modification is made to an attribute that was not requested by the client. The case for NOT sending these entries is pretty strong. I'm not sure what arguments can be made for sending them. In either case, this needs to be spelled out in the draft. Jim From owner-ietf-ldup@mail.imc.org Thu Sep 5 12:24:05 2002 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA24443 for ; Thu, 5 Sep 2002 12:24:04 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g85GJhi01371 for ietf-ldup-bks; Thu, 5 Sep 2002 09:19:43 -0700 (PDT) Received: from telutil12a.ml.com (telutil12a-v.ml.com [199.43.34.196]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g85GJf201367; Thu, 5 Sep 2002 09:19:41 -0700 (PDT) Received: from telutil13a.ml.com (telutil13a [146.125.226.11]) by telutil12a.ml.com (8.11.3/8.11.3/telutil12a-1.2) with ESMTP id g85GJav20850; Thu, 5 Sep 2002 12:19:36 -0400 (EDT) Received: from ehudwt02.exchange.ml.com (ehudwt02.exchange.ml.com [199.201.37.23]) by telutil13a.ml.com (8.11.3/8.11.3/telutil13a-1.1) with SMTP id g85GJaf19156; Thu, 5 Sep 2002 12:19:36 -0400 (EDT) Received: from 169.242.226.176 by ehudwt02.exchange.ml.com with ESMTP ( Tumbleweed MMS SMTP Relay (MMS v4.7);); Thu, 05 Sep 2002 12:19:10 -0400 X-Server-Uuid: 3789b954-9c4e-11d3-af68-0008c73b0911 Received: by ehope09.hew.us.ml.com with Internet Mail Service ( 5.5.2653.19) id ; Thu, 5 Sep 2002 12:18:50 -0400 Message-ID: <9B5CBD4986A9D511BE2100065B045DDF0238BE00@ehope21.hew.us.ml.com> From: "Liben, Michael (GTS)" To: "'Kurt D. Zeilenga'" cc: "'John McMeeking'" , ietf-ldup@imc.org, owner-ietf-ldup@mail.imc.org, "'steven.legg@adacel.com.au'" Subject: RE: LCUP Issue: UUID Date: Thu, 5 Sep 2002 12:18:44 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) X-WSS-ID: 11695C74274553-01-01 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-ldup@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit Now I understand. Your desire is for a unique identifier in the universal namespace--the (currently) 128 bit namespace known as a UUID/GUID. I believe this poses a rather significant challenge. Most algorithms depend on an IEEE 802.1 node address--commonly referred to as a MAC address--as a unique value. In theory, this is spatially unique. In practice, it is not. IP networks over Ethernet have emerged as the dominant network combination. These networks do not depend on the universal uniqueness of the node address. The node address need only be unique on the Ethernet router segment. In our 100,000 node network, we currently have at least 30 cases of multiple host instances 'sharing' node addresses, most courtesy of VM-Ware. Similarly, every LPAR on a mainframe utilizes the same small handful of available network nodes. Highly reconfigurable systems, such as the Unisys ES7000 series, can freely associate up to 96 PCI channels with any of up to 8 independent partitions, each running a different OS. We regularly acquire Sun machines with quad network cards. By default, all four ports are configured with the same node address. Very often, each of these nodes is connected to a separate IP/Ethernet segment so the namespace collision is irrelevant. The node address can be overridden in software when necessary. In a nutshell, I believe the node address component is no longer sufficient to guarantee uniqueness of a uuid. Mike Liben -----Original Message----- From: Kurt D. Zeilenga [mailto:Kurt@OpenLDAP.org] Sent: Wednesday, September 04, 2002 4:31 PM To: Liben, Michael (GTS) Cc: Liben, Michael (GTS); 'John McMeeking'; Liben, Michael (GTS); ietf-ldup@imc.org; owner-ietf-ldup@mail.imc.org; 'steven.legg@adacel.com.au' Subject: RE: LCUP Issue: UUID At 01:07 PM 2002-09-04, Liben, Michael (GTS) wrote: >-----Original Message----- >From: Kurt D. Zeilenga [mailto:Kurt@OpenLDAP.org] >Sent: Wednesday, September 04, 2002 3:54 PM >To: Liben, Michael (GTS) >Cc: 'John McMeeking'; Liben, Michael (GTS); ietf-ldup@imc.org; owner-ietf-ldup@mail.imc.org; 'steven.legg@adacel.com.au' >Subject: RE: LCUP Issue: UUID > >At 12:25 PM 2002-09-04, Liben, Michael (GTS) wrote: >>>The UUID only needs to be unique in the DIT in which it has meaning (the context). > >>LDAP and X.500 are designed to support a global DIT. > >Is that a global DIT or a global namespace? Global DIT. >I believe the DIT would be appropriately partitioned into administrative contexts. The global DIT can be appropriately partitioned into administrative contexts. Bring this back to UUIDs... the universe of an entry UUIDs is the global DIT. From owner-ietf-ldup@mail.imc.org Thu Sep 5 12:47:15 2002 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA25053 for ; Thu, 5 Sep 2002 12:47:15 -0400 (EDT) Received: by above.proper.com (8.11.6/8.11.3) id g85GgxF01806 for ietf-ldup-bks; Thu, 5 Sep 2002 09:42:59 -0700 (PDT) Received: from pretender.boolean.net (root@router.boolean.net [198.144.206.49]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g85Ggv201798; Thu, 5 Sep 2002 09:42:57 -0700 (PDT) Received: from nomad.OpenLDAP.org (root@localhost [127.0.0.1]) by pretender.boolean.net (8.12.5/8.12.5) with ESMTP id g85Ggnft005008; Thu, 5 Sep 2002 16:42:49 GMT (envelope-from Kurt@OpenLDAP.org) Message-Id: <5.1.0.14.0.20020905092805.0454ce60@127.0.0.1> X-Sender: kurt@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Thu, 05 Sep 2002 09:42:22 -0700 To: "Liben, Michael (GTS)" From: "Kurt D. Zeilenga" Subject: RE: LCUP Issue: UUID Cc: "'John McMeeking'" , ietf-ldup@imc.org, owner-ietf-ldup@mail.imc.org, "'steven.legg@adacel.com.au'" In-Reply-To: <9B5CBD4986A9D511BE2100065B045DDF0238BE00@ehope21.hew.us.ml .com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-ldup@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: At 09:18 AM 2002-09-05, Liben, Michael (GTS) wrote: >In a nutshell, I believe the node address component is no longer sufficient to guarantee uniqueness of a uuid. By itself, yes... however, I believe ISO/IEC 11578:1996 adequately addresses this very old UUID issue. Kurt From owner-ietf-ldup@mail.imc.org Thu Sep 5 18:36:28 2002 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA10304 for ; Thu, 5 Sep 2002 18:36:28 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g85MTOr22034 for ietf-ldup-bks; Thu, 5 Sep 2002 15:29:24 -0700 (PDT) Received: from tconl91223.tconl.com (tconl91223.tconl.com [204.26.91.223]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g85MT8222027 for ; Thu, 5 Sep 2002 15:29:08 -0700 (PDT) Received: (from jayhawk@localhost) by tconl91223.tconl.com (8.11.6/8.11.0) id g85MLxb04772 for ietf-ldup@imc.org; Thu, 5 Sep 2002 17:21:59 -0500 Date: Thu, 5 Sep 2002 17:21:58 -0500 From: Ryan Moats To: ietf-ldup@imc.org Subject: RE: LCUP issue: What is "a while"? Message-ID: <20020905172158.J2119@privateer.local.windrose.omaha.ne.us> Reply-To: rmoats@lemurnetworks.net Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i Sender: owner-ietf-ldup@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: | At 06:26 AM 2002-09-04, Liben, Michael (GTS) wrote: | >The "MUST wait for a while" would be consistent with most other network | >algorithms. If it doesn't wait, it may cause unintentional denial of | >service attacks by swamping the server with connection requests. | | Jim's comment was that the phrase "MUST wait a while" is a | meaningless mandatory requirement. A nanosecond can be viewed | as a long while in some contexts, a century can be viewed | as a short while in some contexts. While the document | could attempt to define what an appropriate while is in | this context, the document likely would be better off not | stating this as mandatory requirement. | | Kurt ?!?!?!?!? Speaking as one who has implemented something similar to one of the proposed use cases for LCUP, we completely ignored this protocol because of the use of persistent open TCP connections and lack of a viable client backoff requirement. Since LCUP is proposing persistent open TCP connections (which IMHO is questionable, but I bow to the working group on that) and the use of an error code for resources exhaustion, "acceptable" client behavior ought to be specified to help determine a "malicious" client. Since Kurt's comments imply that different use cases of LCUP require different back off periods, I'd think that having the server specify the initial backoff period in seconds with the lcupResorcesExhausted error would be worth consideration. Ryan From owner-ietf-ldup@mail.imc.org Thu Sep 5 22:55:01 2002 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA15003 for ; Thu, 5 Sep 2002 22:55:00 -0400 (EDT) Received: by above.proper.com (8.11.6/8.11.3) id g862o3D07228 for ietf-ldup-bks; Thu, 5 Sep 2002 19:50:03 -0700 (PDT) Received: from pretender.boolean.net (root@router.boolean.net [198.144.206.49]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g862o1k07224 for ; Thu, 5 Sep 2002 19:50:01 -0700 (PDT) Received: from nomad.OpenLDAP.org (root@localhost [127.0.0.1]) by pretender.boolean.net (8.12.5/8.12.5) with ESMTP id g862o5ft008222 for ; Fri, 6 Sep 2002 02:50:05 GMT (envelope-from Kurt@OpenLDAP.org) Message-Id: <5.1.0.14.0.20020905194657.0298dc78@127.0.0.1> X-Sender: kurt@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Thu, 05 Sep 2002 19:49:37 -0700 To: ietf-ldup@imc.org From: "Kurt D. Zeilenga" Subject: LCUP: Interaction with other controls? Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-ldup@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: How does this control interact with other controls? How does this control interact with existing search controls? Paging? Sorting? Matched Values? Duplicate Entries? VLV? etc. Kurt From owner-ietf-ldup@mail.imc.org Fri Sep 6 08:28:40 2002 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA01301 for ; Fri, 6 Sep 2002 08:28:40 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g86CMLu28966 for ietf-ldup-bks; Fri, 6 Sep 2002 05:22:21 -0700 (PDT) Received: from telutil12a.ml.com (telutil12a-v.ml.com [199.43.34.196]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g86CMJk28958 for ; Fri, 6 Sep 2002 05:22:19 -0700 (PDT) Received: from telutil13a.ml.com (telutil13a [146.125.226.11]) by telutil12a.ml.com (8.11.3/8.11.3/telutil12a-1.2) with ESMTP id g86CMJv13342; Fri, 6 Sep 2002 08:22:19 -0400 (EDT) Received: from ehudwt01.exchange.ml.com (ehudwt01.exchange.ml.com [199.201.37.22]) by telutil13a.ml.com (8.11.3/8.11.3/telutil13a-1.1) with SMTP id g86CMJf14113; Fri, 6 Sep 2002 08:22:19 -0400 (EDT) Received: from 169.242.226.175 by ehudwt01.exchange.ml.com with ESMTP ( Tumbleweed MMS SMTP Relay (MMS v4.7);); Fri, 06 Sep 2002 08:22:16 -0400 X-Server-Uuid: 3789b954-9c4e-11d3-af68-0008c73b0911 Received: by ehope08.hew.us.ml.com with Internet Mail Service ( 5.5.2654.52) id ; Fri, 6 Sep 2002 08:21:33 -0400 Message-ID: <9B5CBD4986A9D511BE2100065B045DDF0238BE0A@ehope21.hew.us.ml.com> From: "Liben, Michael (GTS)" To: "'rmoats@lemurnetworks.net'" , ietf-ldup@imc.org Subject: RE: LCUP issue: What is "a while"? Date: Fri, 6 Sep 2002 08:21:24 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2654.52) X-WSS-ID: 11664272616867-01-01 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-ldup@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit >...Since Kurt's comments imply that different use cases of LCUP require >different back off periods, I'd think that having the server specify >the initial backoff period in seconds with the lcupResorcesExhausted error >would be worth consideration. Excellent suggestion. From owner-ietf-ldup@mail.imc.org Sat Sep 7 09:25:17 2002 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA12531 for ; Sat, 7 Sep 2002 09:25:16 -0400 (EDT) Received: by above.proper.com (8.11.6/8.11.3) id g87DCjp07009 for ietf-ldup-bks; Sat, 7 Sep 2002 06:12:45 -0700 (PDT) Received: from telutil12a.ml.com (telutil12a-v.ml.com [199.43.34.196]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g87DChk07003 for ; Sat, 7 Sep 2002 06:12:43 -0700 (PDT) Received: from telutil13a.ml.com (telutil13a [146.125.226.11]) by telutil12a.ml.com (8.11.3/8.11.3/telutil12a-1.2) with ESMTP id g87DChv11674; Sat, 7 Sep 2002 09:12:43 -0400 (EDT) Received: from ehudwt03.exchange.ml.com (ehudwt03.exchange.ml.com [199.201.37.24]) by telutil13a.ml.com (8.11.3/8.11.3/telutil13a-1.1) with SMTP id g87DChf18694; Sat, 7 Sep 2002 09:12:43 -0400 (EDT) Received: from 169.242.226.176 by ehudwt03.exchange.ml.com with ESMTP ( Tumbleweed MMS SMTP Relay (MMS v4.7);); Sat, 07 Sep 2002 09:12:20 -0400 X-Server-Uuid: 3789b954-9c4e-11d3-af68-0008c73b0911 Received: by ehope09.hew.us.ml.com with Internet Mail Service ( 5.5.2653.19) id ; Sat, 7 Sep 2002 09:11:55 -0400 Message-ID: <9B5CBD4986A9D511BE2100065B045DDF0238BE10@ehope21.hew.us.ml.com> From: "Liben, Michael (GTS)" To: "'Jim Sermersheim'" , ietf-ldup@imc.org Subject: RE: LCUP: operational attributes Date: Sat, 7 Sep 2002 09:11:51 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) X-WSS-ID: 116724BE128929-01-01 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-ldup@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit Under what circumstances might 'classes' 4 or 5 occur? Mike -----Original Message----- From: Jim Sermersheim [mailto:jimse@novell.com] Sent: Wednesday, September 04, 2002 11:49 PM To: ietf-ldup@imc.org Subject: LCUP: operational attributes Along with the issue Kurt raised in the message "LCUP: collective attributes, subentries, etc", we need to state how updates to operational attributes (both stored and not stored) affect LCUP. There are different classes of this: 1) A server internally increments a numSubordinates attribute on the parent of an entry being added or deleted (server responding to client action) 2) A server modifies replication-related information (server responding to bilateral processes) 3) A server updates the state of a transitional attribute (response to an internal, timed operation) 4) An entire set of operations like those above that affect the value of an operational attribute, but the value is generated dynamically, only when read by a client. 5) A client updates an operational attribute. We should also discuss any differences in behavior among the three different types of operational attribute (directoryOperation, distributedOperation, dSAOperation). Jim From owner-ietf-ldup@mail.imc.org Sat Sep 7 10:26:07 2002 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA13525 for ; Sat, 7 Sep 2002 10:26:06 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g87EJSK09624 for ietf-ldup-bks; Sat, 7 Sep 2002 07:19:28 -0700 (PDT) Received: from clmboh1-smtp3.columbus.rr.com (clmboh1-smtp3.columbus.rr.com [65.24.0.112]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g87EJRk09620 for ; Sat, 7 Sep 2002 07:19:27 -0700 (PDT) Received: from willeke.com (dhcp024-166-083-155.neo.rr.com [24.166.83.155]) by clmboh1-smtp3.columbus.rr.com (8.11.2/8.11.2) with ESMTP id g87EJOh08943; Sat, 7 Sep 2002 10:19:24 -0400 (EDT) Message-ID: <3D7A0AB3.5010607@willeke.com> Date: Sat, 07 Sep 2002 10:18:27 -0400 From: Jim Willeke User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.1b) Gecko/20020721 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Liben, Michael (GTS)" CC: "'Jim Sermersheim'" , ietf-ldup@imc.org Subject: Re: LCUP: operational attributes References: <9B5CBD4986A9D511BE2100065B045DDF0238BE10@ehope21.hew.us.ml.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-ldup@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit For class 5, I have clients that set operational attributes to work-around some feature not available in various LDAP server implementations. One that is common is iPlanet 4.x, with a password policy inplace, the client needs to have some user entries never-expire, so thjey set the passwordexpirationtime to some date much in the future. -jim Liben, Michael (GTS) wrote: >Under what circumstances might 'classes' 4 or 5 occur? > >Mike > >-----Original Message----- >From: Jim Sermersheim [mailto:jimse@novell.com] >Sent: Wednesday, September 04, 2002 11:49 PM >To: ietf-ldup@imc.org >Subject: LCUP: operational attributes > > >Along with the issue Kurt raised in the message "LCUP: collective >attributes, subentries, etc", we need to state how updates to >operational attributes (both stored and not stored) affect LCUP. There >are different classes of this: >1) A server internally increments a numSubordinates attribute on the >parent of an entry being added or deleted (server responding to client >action) >2) A server modifies replication-related information (server responding >to bilateral processes) >3) A server updates the state of a transitional attribute (response to >an internal, timed operation) >4) An entire set of operations like those above that affect the value >of an operational attribute, but the value is generated dynamically, >only when read by a client. >5) A client updates an operational attribute. > >We should also discuss any differences in behavior among the three >different types of operational attribute (directoryOperation, >distributedOperation, dSAOperation). > >Jim > > > > From owner-ietf-ldup@mail.imc.org Sun Sep 8 00:18:27 2002 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA23170 for ; Sun, 8 Sep 2002 00:18:26 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g883qB922425 for ietf-ldup-bks; Sat, 7 Sep 2002 20:52:11 -0700 (PDT) Received: from prv-mail20.provo.novell.com (prv-mail20.provo.novell.com [137.65.81.122]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g883q9k22418 for ; Sat, 7 Sep 2002 20:52:10 -0700 (PDT) Received: from INET-PRV-MTA by prv-mail20.provo.novell.com with Novell_GroupWise; Sat, 07 Sep 2002 21:52:03 -0600 Message-Id: X-Mailer: Novell GroupWise Internet Agent 6.0.2 Beta Date: Sat, 07 Sep 2002 21:48:45 -0600 From: "Jim Sermersheim" To: , Subject: RE: LCUP: operational attributes Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Disposition: inline Sender: owner-ietf-ldup@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit #4 could happen for things like a "dynamicMember" attribute which is built when the attribute is read. It can also happen for many attributes on the root DSE, or attributes that are used to read statistics, usages, etc. Jim W. has already talked about #4 >>> "Liben, Michael (GTS)" 09/07/02 07:11AM >>> Under what circumstances might 'classes' 4 or 5 occur? Mike -----Original Message----- From: Jim Sermersheim [mailto:jimse@novell.com] Sent: Wednesday, September 04, 2002 11:49 PM To: ietf-ldup@imc.org Subject: LCUP: operational attributes Along with the issue Kurt raised in the message "LCUP: collective attributes, subentries, etc", we need to state how updates to operational attributes (both stored and not stored) affect LCUP. There are different classes of this: 1) A server internally increments a numSubordinates attribute on the parent of an entry being added or deleted (server responding to client action) 2) A server modifies replication-related information (server responding to bilateral processes) 3) A server updates the state of a transitional attribute (response to an internal, timed operation) 4) An entire set of operations like those above that affect the value of an operational attribute, but the value is generated dynamically, only when read by a client. 5) A client updates an operational attribute. We should also discuss any differences in behavior among the three different types of operational attribute (directoryOperation, distributedOperation, dSAOperation). Jim From owner-ietf-ldup@mail.imc.org Mon Sep 9 22:13:28 2002 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA22472 for ; Mon, 9 Sep 2002 22:13:27 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g8A23Xp00996 for ietf-ldup-bks; Mon, 9 Sep 2002 19:03:33 -0700 (PDT) Received: from dns.caledonia.net (dns.caledonia.net [207.40.197.238]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g8A23Uk00992 for ; Mon, 9 Sep 2002 19:03:30 -0700 (PDT) Received: from D7ST2111 (pool-141-158-56-157.phil.east.verizon.net [141.158.56.157]) by dns.caledonia.net; Mon, 09 Sep 2002 20:02:40 -0600 Reply-To: From: "Chris Apple" To: Subject: LDAPv3 Replication Access Control Design Team Report Date: Mon, 9 Sep 2002 22:00:48 -0400 Organization: DSI-Consulting, Inc. Message-ID: <000701c2586d$e9b862d0$0400a8c0@D7ST2111> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.4024 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Importance: Normal Sender: owner-ietf-ldup@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit This represents the progress of the Design Team to date and meets its obligation to report on activities up to and including work item 5 of the Design Team Work Program posted to the WG mailing list: http://www.imc.org/ietf-ldup/mail-archive/msg01491.html LDAPv3 Design Team Report to the LDUP WG Date: 9/9/2002 Terms and Definitions: access control decision function - algorithm used to perform access control checks to establish if an identified and authenticated entity is allowed to add, access, update, or delete information stored in the directory. access control information - the data used in applying the access control decision function access control model - format of the access control information access control scheme - from X.500, identifies the access control model and access control decision function examples of access control schemes: X.500 Basic Access Control + role-based X.500 Simple Access Control + role-based Direction & Minimal Requirements A. For an given object being replicated, the same access control scheme must apply to that object in all replicas. B. This can be accomplished in either of two ways: 1) LDUP can define and all interoperable implementations agree to use a single identified and defined access control scheme; or 2) LDUP can define a way to identify the access control scheme used. C. In an area of replication there is a single access control scheme that applies to all data elements in the area of replication. D. We need an administrative model which can be used to indicate the access control scheme that is applied to each data element in the area of replication. It is important in this context to make a distinction between ACI "external to the directory" (i.e., ACI outside of the DIT) and ACI "outside of the area of replication" (i.e., possibly ACI inherited from part of the DIT that is not replicated). The first, seems forbidden by RFC2820 requirement G3 (quoted later in this report) and so this Design Team proposes a distinction to G3 that one deliverable of this WG must be a specification for a common set of over-the-wire ACI semantics and that a part of this specification must include a requirement that Implementors of ACI outside of the DIT shall publish a specification of the mapping between their internal ACI scheme and the over-the-wire scheme (and that the internal schemes shall have an OID associated with them). The subject of whether or not these OIDs and internal ACI schemes should be standards track or of some other status once published as RFCs should be discussed on the WG mailing list. If an access control scheme relies on information external to the directory (i.e. access control information is held outside of the area of replication), the access control scheme MUST provide for consistent access to the information by cooperating replicas in support of the access control decision function employed by those replicas. The access control scheme MUST define how the access control decision function uses/accesses the same access control information. If access control information is held in the directory and in the area of replication then this information will be replicated by LDUP. RFC 2820 Minimal Requirements: U6. Management of access to resources in an entire subtree SHOULD require only one ACL (at the subtree root). Note that this makes access control based explicitly on attribute types very hard, unless you constrain the types of entries in subtrees. For example, another attribute is added to an entry. That attribute may fall outside the grouping covered by the ACL and hence require additional administration where the desired affect is indeed a different ACL. Access control information specified in one administrative area MUST NOT have jurisdiction in another area. You SHOULD NOT be able to control access to the aliased entry in the alias. You SHOULD be able to control access to the alias name. U17. Administrator MUST be able to determine where inherited policy information comes from, that is, where ACLs are located and which ACLs were applied. Where inheritance of ACLs is applied, it must be able to be shown how/where that new ACL is derived from. U6 and U17 either deal with implying that an administrative model is required or deal with determining where inherited policy comes from. With "partitions" and "sparse/fractional" replicas, the Design Team felt this could become relevant to LDUP. G3. ACL administration SHOULD be part of the LDAP protocol. Access control information MUST be an LDAP attribute. G3 seems "related" to LDUP because ACL information MUST be (viewable as) LDAP attributes, replication MUST ensure that the "view" of this information is IDENTICAL between any replicas that have the same entry(ies). G4. Object reuse protection SHOULD be provided and MUST NOT inhibit implementation of object reuse. The directory SHOULD support policy controlling the re-creation of deleted DNs, particularly in cases where they are re-created for the purpose of assigning them to a subject other than the owner of the deleted DN. G4 is basically the justification for the LDUP entry UUID, and while it's not strictly an LDUP feature (it's really a change to the underlying information model of the directory, in my opinion), LDUP has identified it as a requirement and specified it in the LDUP specifications. This requirement makes implications about use of UUIDs associated with entries and the need to "keep track of" deleted entries - which are two things that LDUP happens to provide already. So it is "fortuitous" that LDUP happens to be "in line" with what G4 would require. U13. A single administrator SHOULD be able to define policy for the entire directory tree. An administrator MUST be able to delegate policy administration for specific subtrees to other users. This allows for the partitioning of the entire directory tree for policy administration, but still allows a single policy to be defined for the entire tree independent of partitioning. (Partition in this context means scope of administration). An administrator MUST be able to create new partitions at any point in the directory tree, and MUST be able to merge a superior and subordinate partition. An administrator MUST be able to configure whether delegated access control information from superior partitions is to be accepted or not. U13 is basically a statement that there must be an administrative model for ACM, that such a model must take into account LDUP logical operations like splitting and joining areas of replication (partitions) in the namespace, by insuring that each area of replication winds up, after the split/join operation, with an unambiguous ACM governing all the entries that need to be addressed to enable access control in that area of replication. In LDUP we go further, below, and say that there must be a single unambiguous ACM governing each entry and that it must be the same ACM in all replicas that hold the entry, but that is a refinement proposed by this Design Team. Approaches arriving at work programs for addressing these requirements: 1) The LDUP WG can define a new administrative model 2) The LDUP WG can LDUP can look for an administrative model that already exists. 3) The LDUP WG can seek to establish a working liaison with an external group to solve the problems required and adopt their solution. Prod/Con Analysis of Each Approach: Approach Pros Cons 1 None Essentially the same set of contributors have tried and failed to achieve consensus on such a model within the IETF 2 Some existing models Most models are vendor-specific and already have broad proprietary; thus there will be deployment impedance towards adoption because the intellectual property is not One adaptation of a freely available for creation of complimentary (x.500) derivative works model exists as I-Ds already 3 The work could proceed No such work has materialized to in parallel with that date. in the IETF and would not significantly Efforts that might produce useful impact the WG from a documents in this subject area resource perspective are not expected to do so in a timeframe generally thought to be useful to LDUP. Because the second approach seems like the most reasonable balance between defining a new model or looking elsewhere for a new model, the Design Team has elected to make that recommendation to the WG at this time. So we present this list of existing administrative models for consideration: - various proprietary models from existing implementations - subentry draft (withdrawn) from Ed Reed - subentry + (first part of) ACM draft from Kurt Zeilenga and Steven Legg The last model, Kurt Zeilenga's subentry draft in combination with the first part of Steven Legg's ACM draft (the part of the draft that discusses the X.500 administrative model) appears to offer everything that is needed by LDUP to describe the access control scheme employed in an area of replication. These drafts are available at these locations: http://www.ietf.org/internet-drafts/draft-zeilenga-ldap-subentry-07.txt http://www.ietf.org/internet-drafts/draft-legg-ldap-acm-admin-00.txt We believe that this identifies the minimal set of things that LDUP needs to do in the area of access control in order to ensure consistent and secure access to information replicated between two replicas. Rather than expend time and energy in producing multiple work programs as the Design Team charter suggests, the Design Team felt that it's energies were best directed to produce a single work program for the Working Group to consider related to the recommended approach towards solving the Access Control problems associated with LDUP. Proposed LDUP Access Control Work Program: 1. Definition of the administrative model to be used. 2. Definition of how access control schemes are identified using the model (depends on 1.) 3. Guidelines for documenting access control schemes to promote interoperability (depends on 2.) 4. Definition of access control schemes that can be employed in an area of replication or with respect to a replicated entry (depends on 3.) Chris Apple - Principal Architect DSI Consulting, Inc. mailto:capple@dsi-consulting.net http://www.dsi-consulting.com From owner-ietf-ldup@mail.imc.org Tue Sep 10 00:31:00 2002 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA24896 for ; Tue, 10 Sep 2002 00:30:59 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g8A4Q2Q04136 for ietf-ldup-bks; Mon, 9 Sep 2002 21:26:02 -0700 (PDT) Received: from pretender.boolean.net (root@router.boolean.net [198.144.206.49]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g8A4Pxk04132 for ; Mon, 9 Sep 2002 21:25:59 -0700 (PDT) Received: from nomad.OpenLDAP.org (root@localhost [127.0.0.1]) by pretender.boolean.net (8.12.5/8.12.5) with ESMTP id g8A4Q1ft035674; Tue, 10 Sep 2002 04:26:01 GMT (envelope-from Kurt@OpenLDAP.org) Message-Id: <5.1.0.14.0.20020909202120.0292ee48@127.0.0.1> X-Sender: kurt@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Mon, 09 Sep 2002 21:25:27 -0700 To: From: "Kurt D. Zeilenga" Subject: Re: LDAPv3 Replication Access Control Design Team Report Cc: In-Reply-To: <000701c2586d$e9b862d0$0400a8c0@D7ST2111> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-ldup@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: I don't have much time to waste on this rat hole, so I'm not going to waste my time (or the WGs) debating the technical points made in this report. Except to say that the minimal amount of work the LDUP WG needs to do in specifying an LDAP ACM (or ACM framework) is none. Per the recently completed LDUP requirements document (approved for publication), LDUP does not require a standard LDAP ACM. This plan doesn't attempt to provide a standard LDAP ACM. So, it seems, the proponents of this plan have already conceded this point. I believe all work suggested in the plan can be written as an extension to LDUP and/or LDAP. I see no reason to burden the LDUP WG with this work. The LDUP WG is already struggling to meet its deliverables and the addition of this work item will significantly hinder progress on those deliverables. Hence, I suggest that the charter not be amended to include any new work items and that the proponents of this work be asked to continue it on an individual basis. Kurt At 07:00 PM 2002-09-09, Chris Apple wrote: >This represents the progress of the Design Team to date and meets >its obligation to report on activities up to and including work item >5 of the Design Team Work Program posted to the WG mailing list: > >http://www.imc.org/ietf-ldup/mail-archive/msg01491.html > >LDAPv3 Design Team Report to the LDUP WG > >Date: 9/9/2002 > >Terms and Definitions: > >access control decision function - algorithm used to perform access >control >checks to establish if an identified and authenticated entity is allowed >to >add, access, update, or delete information stored in the directory. > >access control information - the data used in applying the access >control >decision function > >access control model - format of the access control information > >access control scheme - from X.500, identifies the access control model >and > >access control decision function > >examples of access control schemes: > > X.500 Basic Access Control + role-based > X.500 Simple Access Control + role-based > >Direction & Minimal Requirements > >A. For an given object being replicated, the same access control scheme >must apply to that object in all replicas. > >B. This can be accomplished in either of two ways: 1) LDUP can define >and >all interoperable implementations agree to use a single identified and >defined access control scheme; or 2) LDUP can define a way to identify >the >access control scheme used. > >C. In an area of replication there is a single access control scheme >that >applies to all data elements in the area of replication. > >D. We need an administrative model which can be used to indicate the >access >control scheme that is applied to each data element in the area of >replication. It is important in this context to make a distinction >between >ACI "external to the directory" (i.e., ACI outside of the DIT) and ACI >"outside of the area of replication" (i.e., possibly ACI inherited from >part >of the DIT that is not replicated). The first, seems forbidden by >RFC2820 >requirement G3 (quoted later in this report) and so this Design Team >proposes >a distinction to G3 that one deliverable of this WG must be a >specification >for a common set of over-the-wire ACI semantics and that a part of this >specification must include a requirement that Implementors of ACI >outside >of the DIT shall publish a specification of the mapping between their >internal ACI scheme and the over-the-wire scheme (and that the internal >schemes shall have an OID associated with them). The subject of whether >or not these OIDs and internal ACI schemes should be standards track or >of some other status once published as RFCs should be discussed on the >WG mailing list. > >If an access control scheme relies on information external to the >directory >(i.e. access control information is held outside of the area of >replication), the access control scheme MUST provide for consistent >access >to the information by cooperating replicas in support of the access >control >decision function employed by those replicas. > >The access control scheme MUST define how the access control decision >function uses/accesses the same access control information. If access >control information is held in the directory and in the area of >replication >then this information will be replicated by LDUP. > >RFC 2820 Minimal Requirements: > >U6. Management of access to resources in an entire subtree SHOULD > require only one ACL (at the subtree root). Note that this makes > access control based explicitly on attribute types very hard, unless > you constrain the types of entries in subtrees. For example, another > attribute is added to an entry. That attribute may fall outside the > grouping covered by the ACL and hence require additional > administration where the desired affect is indeed a different ACL. > Access control information specified in one administrative area MUST > NOT have jurisdiction in another area. You SHOULD NOT be able to > control access to the aliased entry in the alias. You SHOULD be able > to control access to the alias name. > > >U17. Administrator MUST be able to determine where inherited policy > information comes from, that is, where ACLs are located and which > ACLs were applied. Where inheritance of ACLs is applied, it must be > able to be shown how/where that new ACL is derived from. > >U6 and U17 either deal with implying that an administrative model >is required or deal with determining where inherited policy comes from. >With "partitions" and "sparse/fractional" replicas, the Design Team felt >this could become relevant to LDUP. > >G3. ACL administration SHOULD be part of the LDAP protocol. Access > control information MUST be an LDAP attribute. > >G3 seems "related" to LDUP because ACL information MUST be (viewable as) >LDAP attributes, replication MUST ensure that the "view" of this >information >is IDENTICAL between any replicas that have the same entry(ies). > >G4. Object reuse protection SHOULD be provided and MUST NOT inhibit > implementation of object reuse. The directory SHOULD support policy > controlling the re-creation of deleted DNs, particularly in cases > where they are re-created for the purpose of assigning them to a > subject other than the owner of the deleted DN. > >G4 is basically the justification for the LDUP entry UUID, and while >it's not strictly an LDUP feature (it's really a change to the >underlying >information model of the directory, in my opinion), LDUP has identified >it as a requirement and specified it in the LDUP specifications. This >requirement makes implications about use of UUIDs associated with >entries >and the need to "keep track of" deleted entries - which are two things >that LDUP happens to provide already. So it is "fortuitous" that LDUP >happens to be "in line" with what G4 would require. > >U13. A single administrator SHOULD be able to define policy for the > entire directory tree. An administrator MUST be able to delegate > policy administration for specific subtrees to other users. This > allows for the partitioning of the entire directory tree for policy > administration, but still allows a single policy to be defined for > the entire tree independent of partitioning. (Partition in this > context means scope of administration). An administrator MUST be > able to create new partitions at any point in the directory tree, and > MUST be able to merge a superior and subordinate partition. An > administrator MUST be able to configure whether delegated access > control information from superior partitions is to be accepted or > not. > >U13 is basically a statement that there must be an administrative >model for ACM, that such a model must take into account LDUP logical >operations like splitting and joining areas of replication (partitions) >in the namespace, by insuring that each area of replication winds up, >after the split/join operation, with an unambiguous ACM governing all >the entries that need to be addressed to enable access control in that >area of replication. In LDUP we go further, below, and say that >there must be a single unambiguous ACM governing each entry and that >it must be the same ACM in all replicas that hold the entry, but that >is a refinement proposed by this Design Team. > >Approaches arriving at work programs for addressing these requirements: > >1) The LDUP WG can define a new administrative model >2) The LDUP WG can LDUP can look for an administrative model that >already exists. >3) The LDUP WG can seek to establish a working liaison with an external >group to > solve the problems required and adopt their solution. > >Prod/Con Analysis of Each Approach: > >Approach Pros Cons > > 1 None Essentially the same set > of contributors have tried > and failed to achieve consensus > on such a model within the IETF > > 2 Some existing models Most models are vendor-specific >and > already have broad proprietary; thus there will be > deployment impedance towards adoption >because > the intellectual property is not > One adaptation of a freely available for creation of > complimentary (x.500) derivative works > model exists as I-Ds > already > > 3 The work could proceed No such work has materialized to > in parallel with that date. > in the IETF and would > not significantly Efforts that might produce >useful > impact the WG from a documents in this subject area > resource perspective are not expected to do so in a > timeframe generally thought to >be > useful to LDUP. > > >Because the second approach seems like the most reasonable balance >between >defining a new model or looking elsewhere for a new model, the Design >Team >has elected to make that recommendation to the WG at this time. So we >present >this list of existing administrative models for consideration: > > - various proprietary models from existing implementations > - subentry draft (withdrawn) from Ed Reed > - subentry + (first part of) ACM draft from Kurt Zeilenga and Steven >Legg > >The last model, Kurt Zeilenga's subentry draft in combination with the >first part of Steven Legg's ACM draft (the part of the draft that >discusses >the X.500 administrative model) appears to offer everything that is >needed >by LDUP to describe the access control scheme employed in an area of >replication. These drafts are available at these locations: > >http://www.ietf.org/internet-drafts/draft-zeilenga-ldap-subentry-07.txt > >http://www.ietf.org/internet-drafts/draft-legg-ldap-acm-admin-00.txt > >We believe that this identifies the minimal set of things that LDUP >needs >to do in the area of access control in order to ensure consistent and >secure access to information replicated between two replicas. > >Rather than expend time and energy in producing multiple work programs >as the Design Team charter suggests, the Design Team felt that it's >energies were best directed to produce a single work program for the >Working Group to consider related to the recommended approach towards >solving the Access Control problems associated with LDUP. > >Proposed LDUP Access Control Work Program: > >1. Definition of the administrative model to be used. > >2. Definition of how access control schemes are identified using the >model >(depends on 1.) > >3. Guidelines for documenting access control schemes to promote >interoperability (depends on 2.) > >4. Definition of access control schemes that can be employed in an area >of >replication or with respect to a replicated entry (depends on 3.) > >Chris Apple - Principal Architect > >DSI Consulting, Inc. > >mailto:capple@dsi-consulting.net > >http://www.dsi-consulting.com From owner-ietf-ldup@mail.imc.org Tue Sep 10 01:39:15 2002 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA25974 for ; Tue, 10 Sep 2002 01:39:14 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g8A5YQ905999 for ietf-ldup-bks; Mon, 9 Sep 2002 22:34:26 -0700 (PDT) Received: from dns.caledonia.net (dns.caledonia.net [207.40.197.238]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g8A5YNk05995 for ; Mon, 9 Sep 2002 22:34:23 -0700 (PDT) Received: from D7ST2111 (pool-141-158-55-241.phil.east.verizon.net [141.158.55.241]) by dns.caledonia.net; Mon, 09 Sep 2002 23:33:59 -0600 Reply-To: From: "Chris Apple" To: Subject: RE: LDAPv3 Replication Access Control Design Team Report Date: Tue, 10 Sep 2002 01:32:18 -0400 Organization: DSI-Consulting, Inc. Message-ID: <000201c2588b$6f0a7550$0400a8c0@D7ST2111> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.4024 In-Reply-To: <5.1.0.14.0.20020909202120.0292ee48@127.0.0.1> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Importance: Normal Sender: owner-ietf-ldup@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit Kurt, This is not a rat hole. It's a report from the Design Team that the WG agreed should form. Various deliverables of the LDUP WG will have to reference ACM/ACI-related specifications regardless of where they are produced. The Working Group has already agreed to discuss the technical points contained in this report, per consensus established around the Design Team work program posted to the mailing list (and referenced below). I would also like to state the obvious: the WG isn't prohibited from discussing the expansion of its own charter based on input from the Design Team. Your suggestion is noted and appreciated. However, John and I would be creating the impression of prematurely judging consensus if we were to simply agree with you and ask the WG members if they do also. You are of course free to ignore any subsequent discussion on this topic as is anyone else who deems it to be a waste of their time. However, as a Co-chair, I would think you'd be interested in whether or not the WG might adopt one of your drafts as a deliverable. John and I need to see some indications about whether or not it would be a good or bad idea (and why) to add the work items suggested. From other folks. Now that there is at least a proposal on the table for the WG to consider about how to proceed with our work, we can begin to discuss what that means and where we collectively believe the ACM/ACI/Administrative Model work ought to happen. So, we need to discuss the report, its content, and figure out the following as the Design Team's work program suggests: 1) Are the recommendations of the design team sufficient to address the ACM/ACI/Administrative Model requirements for LDAPv3 Replication? 2) Where should the recommended work items be completed? Silence, in this case, is not likely to mean consent as it sometimes does in the IETF...it is likely to mean that John and I will have to evaluate whether or not to suggest to the Applications Area Directors that the LDUP WG be prematurely concluded. Anyone who doesn't want to see us forced into that decision point, should post your views on the above to the list. Chris Apple - Principal Architect DSI Consulting, Inc. mailto:capple@dsi-consulting.net http://www.dsi-consulting.com -----Original Message----- From: Kurt D. Zeilenga [mailto:Kurt@OpenLDAP.org] Sent: Tuesday, September 10, 2002 12:25 AM To: capple@dsi-consulting.net Cc: ietf-ldup@imc.org Subject: Re: LDAPv3 Replication Access Control Design Team Report I don't have much time to waste on this rat hole, so I'm not going to waste my time (or the WGs) debating the technical points made in this report. Except to say that the minimal amount of work the LDUP WG needs to do in specifying an LDAP ACM (or ACM framework) is none. Per the recently completed LDUP requirements document (approved for publication), LDUP does not require a standard LDAP ACM. This plan doesn't attempt to provide a standard LDAP ACM. So, it seems, the proponents of this plan have already conceded this point. I believe all work suggested in the plan can be written as an extension to LDUP and/or LDAP. I see no reason to burden the LDUP WG with this work. The LDUP WG is already struggling to meet its deliverables and the addition of this work item will significantly hinder progress on those deliverables. Hence, I suggest that the charter not be amended to include any new work items and that the proponents of this work be asked to continue it on an individual basis. Kurt At 07:00 PM 2002-09-09, Chris Apple wrote: >This represents the progress of the Design Team to date and meets >its obligation to report on activities up to and including work item >5 of the Design Team Work Program posted to the WG mailing list: > >http://www.imc.org/ietf-ldup/mail-archive/msg01491.html > >LDAPv3 Design Team Report to the LDUP WG > >Date: 9/9/2002 > >Terms and Definitions: > >access control decision function - algorithm used to perform access >control >checks to establish if an identified and authenticated entity is allowed >to >add, access, update, or delete information stored in the directory. > >access control information - the data used in applying the access >control >decision function > >access control model - format of the access control information > >access control scheme - from X.500, identifies the access control model >and > >access control decision function > >examples of access control schemes: > > X.500 Basic Access Control + role-based > X.500 Simple Access Control + role-based > >Direction & Minimal Requirements > >A. For an given object being replicated, the same access control scheme >must apply to that object in all replicas. > >B. This can be accomplished in either of two ways: 1) LDUP can define >and >all interoperable implementations agree to use a single identified and >defined access control scheme; or 2) LDUP can define a way to identify >the >access control scheme used. > >C. In an area of replication there is a single access control scheme >that >applies to all data elements in the area of replication. > >D. We need an administrative model which can be used to indicate the >access >control scheme that is applied to each data element in the area of >replication. It is important in this context to make a distinction >between >ACI "external to the directory" (i.e., ACI outside of the DIT) and ACI >"outside of the area of replication" (i.e., possibly ACI inherited from >part >of the DIT that is not replicated). The first, seems forbidden by >RFC2820 >requirement G3 (quoted later in this report) and so this Design Team >proposes >a distinction to G3 that one deliverable of this WG must be a >specification >for a common set of over-the-wire ACI semantics and that a part of this >specification must include a requirement that Implementors of ACI >outside >of the DIT shall publish a specification of the mapping between their >internal ACI scheme and the over-the-wire scheme (and that the internal >schemes shall have an OID associated with them). The subject of whether >or not these OIDs and internal ACI schemes should be standards track or >of some other status once published as RFCs should be discussed on the >WG mailing list. > >If an access control scheme relies on information external to the >directory >(i.e. access control information is held outside of the area of >replication), the access control scheme MUST provide for consistent >access >to the information by cooperating replicas in support of the access >control >decision function employed by those replicas. > >The access control scheme MUST define how the access control decision >function uses/accesses the same access control information. If access >control information is held in the directory and in the area of >replication >then this information will be replicated by LDUP. > >RFC 2820 Minimal Requirements: > >U6. Management of access to resources in an entire subtree SHOULD > require only one ACL (at the subtree root). Note that this makes > access control based explicitly on attribute types very hard, unless > you constrain the types of entries in subtrees. For example, another > attribute is added to an entry. That attribute may fall outside the > grouping covered by the ACL and hence require additional > administration where the desired affect is indeed a different ACL. > Access control information specified in one administrative area MUST > NOT have jurisdiction in another area. You SHOULD NOT be able to > control access to the aliased entry in the alias. You SHOULD be able > to control access to the alias name. > > >U17. Administrator MUST be able to determine where inherited policy > information comes from, that is, where ACLs are located and which > ACLs were applied. Where inheritance of ACLs is applied, it must be > able to be shown how/where that new ACL is derived from. > >U6 and U17 either deal with implying that an administrative model >is required or deal with determining where inherited policy comes from. >With "partitions" and "sparse/fractional" replicas, the Design Team felt >this could become relevant to LDUP. > >G3. ACL administration SHOULD be part of the LDAP protocol. Access > control information MUST be an LDAP attribute. > >G3 seems "related" to LDUP because ACL information MUST be (viewable as) >LDAP attributes, replication MUST ensure that the "view" of this >information >is IDENTICAL between any replicas that have the same entry(ies). > >G4. Object reuse protection SHOULD be provided and MUST NOT inhibit > implementation of object reuse. The directory SHOULD support policy > controlling the re-creation of deleted DNs, particularly in cases > where they are re-created for the purpose of assigning them to a > subject other than the owner of the deleted DN. > >G4 is basically the justification for the LDUP entry UUID, and while >it's not strictly an LDUP feature (it's really a change to the >underlying >information model of the directory, in my opinion), LDUP has identified >it as a requirement and specified it in the LDUP specifications. This >requirement makes implications about use of UUIDs associated with >entries >and the need to "keep track of" deleted entries - which are two things >that LDUP happens to provide already. So it is "fortuitous" that LDUP >happens to be "in line" with what G4 would require. > >U13. A single administrator SHOULD be able to define policy for the > entire directory tree. An administrator MUST be able to delegate > policy administration for specific subtrees to other users. This > allows for the partitioning of the entire directory tree for policy > administration, but still allows a single policy to be defined for > the entire tree independent of partitioning. (Partition in this > context means scope of administration). An administrator MUST be > able to create new partitions at any point in the directory tree, and > MUST be able to merge a superior and subordinate partition. An > administrator MUST be able to configure whether delegated access > control information from superior partitions is to be accepted or > not. > >U13 is basically a statement that there must be an administrative >model for ACM, that such a model must take into account LDUP logical >operations like splitting and joining areas of replication (partitions) >in the namespace, by insuring that each area of replication winds up, >after the split/join operation, with an unambiguous ACM governing all >the entries that need to be addressed to enable access control in that >area of replication. In LDUP we go further, below, and say that >there must be a single unambiguous ACM governing each entry and that >it must be the same ACM in all replicas that hold the entry, but that >is a refinement proposed by this Design Team. > >Approaches arriving at work programs for addressing these requirements: > >1) The LDUP WG can define a new administrative model >2) The LDUP WG can LDUP can look for an administrative model that >already exists. >3) The LDUP WG can seek to establish a working liaison with an external >group to > solve the problems required and adopt their solution. > >Prod/Con Analysis of Each Approach: > >Approach Pros Cons > > 1 None Essentially the same set > of contributors have tried > and failed to achieve consensus > on such a model within the IETF > > 2 Some existing models Most models are vendor-specific >and > already have broad proprietary; thus there will be > deployment impedance towards adoption >because > the intellectual property is not > One adaptation of a freely available for creation of > complimentary (x.500) derivative works > model exists as I-Ds > already > > 3 The work could proceed No such work has materialized to > in parallel with that date. > in the IETF and would > not significantly Efforts that might produce >useful > impact the WG from a documents in this subject area > resource perspective are not expected to do so in a > timeframe generally thought to >be > useful to LDUP. > > >Because the second approach seems like the most reasonable balance >between >defining a new model or looking elsewhere for a new model, the Design >Team >has elected to make that recommendation to the WG at this time. So we >present >this list of existing administrative models for consideration: > > - various proprietary models from existing implementations > - subentry draft (withdrawn) from Ed Reed > - subentry + (first part of) ACM draft from Kurt Zeilenga and Steven >Legg > >The last model, Kurt Zeilenga's subentry draft in combination with the >first part of Steven Legg's ACM draft (the part of the draft that >discusses >the X.500 administrative model) appears to offer everything that is >needed >by LDUP to describe the access control scheme employed in an area of >replication. These drafts are available at these locations: > >http://www.ietf.org/internet-drafts/draft-zeilenga-ldap-subentry-07.txt > >http://www.ietf.org/internet-drafts/draft-legg-ldap-acm-admin-00.txt > >We believe that this identifies the minimal set of things that LDUP >needs >to do in the area of access control in order to ensure consistent and >secure access to information replicated between two replicas. > >Rather than expend time and energy in producing multiple work programs >as the Design Team charter suggests, the Design Team felt that it's >energies were best directed to produce a single work program for the >Working Group to consider related to the recommended approach towards >solving the Access Control problems associated with LDUP. > >Proposed LDUP Access Control Work Program: > >1. Definition of the administrative model to be used. > >2. Definition of how access control schemes are identified using the >model >(depends on 1.) > >3. Guidelines for documenting access control schemes to promote >interoperability (depends on 2.) > >4. Definition of access control schemes that can be employed in an area >of >replication or with respect to a replicated entry (depends on 3.) > >Chris Apple - Principal Architect > >DSI Consulting, Inc. > >mailto:capple@dsi-consulting.net > >http://www.dsi-consulting.com From owner-ietf-ldup@mail.imc.org Tue Sep 10 08:29:13 2002 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA10770 for ; Tue, 10 Sep 2002 08:29:12 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g8ACJop20109 for ietf-ldup-bks; Tue, 10 Sep 2002 05:19:50 -0700 (PDT) Received: from e6.ny.us.ibm.com (e6.ny.us.ibm.com [32.97.182.106]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g8ACJnk20102 for ; Tue, 10 Sep 2002 05:19:49 -0700 (PDT) Received: from northrelay02.pok.ibm.com (northrelay02.pok.ibm.com [9.56.224.150]) by e6.ny.us.ibm.com (8.12.2/8.12.2) with ESMTP id g8ACJilg020988 for ; Tue, 10 Sep 2002 08:19:44 -0400 Received: from d01mlc96.pok.ibm.com (d01mlc96.pok.ibm.com [9.117.250.33]) by northrelay02.pok.ibm.com (8.12.3/NCO/VER6.4) with ESMTP id g8ACJgKd111492 for ; Tue, 10 Sep 2002 08:19:42 -0400 Subject: RE: LDAPv3 Replication Access Control Design Team Report To: ietf-ldup@imc.org X-Mailer: Lotus Notes Release 5.0.7 March 21, 2001 Message-ID: From: "Timothy Hahn" Date: Tue, 10 Sep 2002 08:19:24 -0400 X-MIMETrack: Serialize by Router on D01MLC96/01/M/IBM(Release 5.0.11 |July 29, 2002) at 09/10/2002 08:19:43 AM MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: owner-ietf-ldup@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Hi all, Since "silence" seems not to be an option in this case, I'll log my opinion here as siding IN FAVOR of the proposed work program. My reasoning here is that I feel that a) something needs to be done with respect to maintaining the security around information access, even when that information is subject to being replicated across a heterogeneous set of servers b) mandating any one particular access control model implementation is (as has been noted) a "rat hole" that is too deep and slimy to be productive c) a mechanism for identifying an access control model + agreement that, within an area of replication, a single access control model is applied is a good way to "isolate" this problem from the main LDUP tasks of defining a replication model (wire flows, data formats, administrative actions). By isolating the problem, we can "agree to disagree" (as a collective group) and still make progress on a replication protocol. The approach will also allow for those that CAN come to some agreement on an access control model to be able to employ LDUP mechanisms. I think that inserting this "level of indirection" with respect to access control model frees up the LDUP WG to concentrate on replication flows instead of being "stuck" as it has been for quite some time. Regards, Tim Hahn Internet: hahnt@us.ibm.com Internal: Timothy Hahn/Durham/IBM@IBMUS phone: 919.224.1565 tie-line: 8/687.1565 fax: 919.224.2540 From owner-ietf-ldup@mail.imc.org Tue Sep 10 08:45:44 2002 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA11334 for ; Tue, 10 Sep 2002 08:45:43 -0400 (EDT) Received: by above.proper.com (8.11.6/8.11.3) id g8ACgmF22132 for ietf-ldup-bks; Tue, 10 Sep 2002 05:42:48 -0700 (PDT) Received: from pretender.boolean.net (root@router.boolean.net [198.144.206.49]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g8ACgkk22127 for ; Tue, 10 Sep 2002 05:42:46 -0700 (PDT) Received: from nomad.OpenLDAP.org (root@localhost [127.0.0.1]) by pretender.boolean.net (8.12.5/8.12.5) with ESMTP id g8ACgcft037525; Tue, 10 Sep 2002 12:42:39 GMT (envelope-from Kurt@OpenLDAP.org) Message-Id: <5.1.0.14.0.20020910051508.0552f1d8@127.0.0.1> X-Sender: kurt@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Tue, 10 Sep 2002 05:42:03 -0700 To: From: "Kurt D. Zeilenga" Subject: RE: LDAPv3 Replication Access Control Design Team Report Cc: In-Reply-To: <000201c2588b$6f0a7550$0400a8c0@D7ST2111> References: <5.1.0.14.0.20020909202120.0292ee48@127.0.0.1> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-ldup@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Let's cut to the key question: Does LDAP replication REQUIRE a standard LDAP ACM? (REQUIRE here in the RFC 2119 sense). If the consensus is yes, then we should determine how this requirement is going to be fulfilled. (I note that the proposed plan doesn't produce a standard LDAP ACM.) If the consensus is no, then we need not determine how an LDAP ACM will or will not be produced. It simply can remain out of scope. I see little point is discussing the details of the plan until we've actually agreed upon requirements... Kurt From owner-ietf-ldup@mail.imc.org Tue Sep 10 09:14:14 2002 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA12473 for ; Tue, 10 Sep 2002 09:14:13 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g8ADAog23232 for ietf-ldup-bks; Tue, 10 Sep 2002 06:10:50 -0700 (PDT) Received: from e3.ny.us.ibm.com (e3.ny.us.ibm.com [32.97.182.103]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g8ADAkk23224 for ; Tue, 10 Sep 2002 06:10:46 -0700 (PDT) Received: from northrelay04.pok.ibm.com (northrelay04.pok.ibm.com [9.56.224.206]) by e3.ny.us.ibm.com (8.12.2/8.12.2) with ESMTP id g8ADAflN117870 for ; Tue, 10 Sep 2002 09:10:41 -0400 Received: from d01mlc96.pok.ibm.com (d01mlc96.pok.ibm.com [9.117.250.33]) by northrelay04.pok.ibm.com (8.12.3/NCO/VER6.4) with ESMTP id g8ADAd50062506 for ; Tue, 10 Sep 2002 09:10:39 -0400 Subject: RE: LDAPv3 Replication Access Control Design Team Report To: ietf-ldup@imc.org X-Mailer: Lotus Notes Release 5.0.7 March 21, 2001 Message-ID: From: "Timothy Hahn" Date: Tue, 10 Sep 2002 09:04:36 -0400 X-MIMETrack: Serialize by Router on D01MLC96/01/M/IBM(Release 5.0.11 |July 29, 2002) at 09/10/2002 09:10:40 AM MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: owner-ietf-ldup@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Kurt, My opinions below. Regards, Tim Hahn Internet: hahnt@us.ibm.com Internal: Timothy Hahn/Durham/IBM@IBMUS phone: 919.224.1565 tie-line: 8/687.1565 fax: 919.224.2540 "Kurt D. Zeilenga" To: g> Subject: RE: LDAPv3 Replication Access Control Design Team Report Sent by: owner-ietf-ldup@m ail.imc.org 09/10/2002 08:42 AM Let's cut to the key question: Does LDAP replication REQUIRE a standard LDAP ACM? (REQUIRE here in the RFC 2119 sense). TJH> I believe that LDAP replication MUST ensure that the security TJH> (i.e. authorization to access - add/modify/search/delete) TJH> is NOT compromised by the LDAP replication mechanism defined. TJH> TJH> Thus, I believe that LDAP replication REQUIRES that access TJH> control issues be "attended to" (in the RFC 2119 sense). TJH> TJH> But I DO NOT feel that LDAP replication needs define a specific TJH> Access Control Model (ACM). LDAP replication need only ensure TJH> that SOME ACM can be applied across the servers involved in the TJH> data replicated amongst them and that LDAP replication doesn't TJH> "mess that up". If the consensus is yes, then we should determine how this requirement is going to be fulfilled. (I note that the proposed plan doesn't produce a standard LDAP ACM.) If the consensus is no, then we need not determine how an LDAP ACM will or will not be produced. It simply can remain out of scope. TJH> Unfortunately, I don't believe the answer is as "binary" TJH> as this. LDAP replication REQUIRES that things be done TJH> "securely" but it does NOT REQUIRE a specific ACM. I see little point is discussing the details of the plan until we've actually agreed upon requirements... Kurt From owner-ietf-ldup@mail.imc.org Tue Sep 10 09:32:10 2002 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA13164 for ; Tue, 10 Sep 2002 09:32:09 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g8ADSjI25125 for ietf-ldup-bks; Tue, 10 Sep 2002 06:28:45 -0700 (PDT) Received: from telutil12a.ml.com (telutil12a-v.ml.com [199.43.34.196]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g8ADSik25121 for ; Tue, 10 Sep 2002 06:28:44 -0700 (PDT) Received: from wstutil13a.ml.com (wstutil13a [146.125.185.11]) by telutil12a.ml.com (8.11.3/8.11.3/telutil12a-1.2) with ESMTP id g8ADSiv15643; Tue, 10 Sep 2002 09:28:44 -0400 (EDT) Received: from ewstwt01.exchange.ml.com (ewstwt03.exchange.ml.com [146.125.249.153]) by wstutil13a.ml.com (8.11.3/8.11.3/wstutil13a-1.1) with SMTP id g8ADSi115468; Tue, 10 Sep 2002 09:28:44 -0400 (EDT) Received: from 172.25.100.10 by ewstwt01.exchange.ml.com with ESMTP ( Tumbleweed MMS SMTP Relay (MMS v4.7);); Tue, 10 Sep 2002 09:27:50 -0400 X-Server-Uuid: 3789b954-9c4e-11d3-af68-0008c73b0911 Received: by ewst10.exchange.ml.com with Internet Mail Service ( 5.5.2654.52) id ; Tue, 10 Sep 2002 09:27:48 -0400 Message-ID: <9B5CBD4986A9D511BE2100065B045DDF04B4C442@ehope21.hew.us.ml.com> From: "Liben, Michael (GTS)" To: "'Timothy Hahn'" , ietf-ldup@imc.org Subject: RE: LDAPv3 Replication Access Control Design Team Report Date: Tue, 10 Sep 2002 09:27:47 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2654.52) X-WSS-ID: 11632CDC168313-01-01 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-ldup@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit I believe the security issues to be a business/technical problem that falls outside of the replication protocol. There are other mechanisms required to ensure that a server is trusted. The replicator always has the option of not replicating with an untrusted partner. Mike -----Original Message----- From: Timothy Hahn [mailto:hahnt@us.ibm.com] Sent: Tuesday, September 10, 2002 8:19 AM To: ietf-ldup@imc.org Subject: RE: LDAPv3 Replication Access Control Design Team Report Hi all, Since "silence" seems not to be an option in this case, I'll log my opinion here as siding IN FAVOR of the proposed work program. My reasoning here is that I feel that a) something needs to be done with respect to maintaining the security around information access, even when that information is subject to being replicated across a heterogeneous set of servers b) mandating any one particular access control model implementation is (as has been noted) a "rat hole" that is too deep and slimy to be productive c) a mechanism for identifying an access control model + agreement that, within an area of replication, a single access control model is applied is a good way to "isolate" this problem from the main LDUP tasks of defining a replication model (wire flows, data formats, administrative actions). By isolating the problem, we can "agree to disagree" (as a collective group) and still make progress on a replication protocol. The approach will also allow for those that CAN come to some agreement on an access control model to be able to employ LDUP mechanisms. I think that inserting this "level of indirection" with respect to access control model frees up the LDUP WG to concentrate on replication flows instead of being "stuck" as it has been for quite some time. Regards, Tim Hahn Internet: hahnt@us.ibm.com Internal: Timothy Hahn/Durham/IBM@IBMUS phone: 919.224.1565 tie-line: 8/687.1565 fax: 919.224.2540 From owner-ietf-ldup@mail.imc.org Tue Sep 10 09:44:01 2002 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA13670 for ; Tue, 10 Sep 2002 09:44:00 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g8ADeqi25388 for ietf-ldup-bks; Tue, 10 Sep 2002 06:40:52 -0700 (PDT) Received: from pretender.boolean.net (root@router.boolean.net [198.144.206.49]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g8ADepk25383 for ; Tue, 10 Sep 2002 06:40:51 -0700 (PDT) Received: from nomad.OpenLDAP.org (root@localhost [127.0.0.1]) by pretender.boolean.net (8.12.5/8.12.5) with ESMTP id g8ADefft037750; Tue, 10 Sep 2002 13:40:42 GMT (envelope-from Kurt@OpenLDAP.org) Message-Id: <5.1.0.14.0.20020910061405.0292b778@127.0.0.1> X-Sender: kurt@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Tue, 10 Sep 2002 06:40:07 -0700 To: From: "Kurt D. Zeilenga" Subject: concluding LDUP WG (Was: LDAPv3 Replication Access Control Design Team Report) Cc: In-Reply-To: <000201c2588b$6f0a7550$0400a8c0@D7ST2111> References: <5.1.0.14.0.20020909202120.0292ee48@127.0.0.1> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-ldup@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: At 10:32 PM 2002-09-09, Chris Apple wrote: >Silence, in this case, is not likely to mean consent as >it sometimes does in the IETF...it is likely to mean that >John and I will have to evaluate whether or not to suggest >to the Applications Area Directors that the LDUP WG be >prematurely concluded. Regardless of consensus on this issue, you should evaluate (with WG input) whether or not the WG can complete its deliverables in a reasonable amount of time and, if not, recommend the WG be shutdown. While I think we can complete the LCUP work item in a reasonable amount of time, I have serious doubts the WG will ever complete LDUP work items. The WG seems to be floundering here, not able to focus on the critical issues and hopelessly lost in requirement debates. So, not only do I believe new WG items should not be added to our charter, we should either 1) narrow the focus to the basic replication protocol work or 2) concluded (after completing LCUP work). Kurt From owner-ietf-ldup@mail.imc.org Tue Sep 10 09:51:52 2002 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA14191 for ; Tue, 10 Sep 2002 09:51:51 -0400 (EDT) Received: by above.proper.com (8.11.6/8.11.3) id g8ADmj925633 for ietf-ldup-bks; Tue, 10 Sep 2002 06:48:45 -0700 (PDT) Received: from netscape.com (c3po.netscape.com [205.217.237.46]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g8ADmik25627 for ; Tue, 10 Sep 2002 06:48:44 -0700 (PDT) Received: from judge.mcom.com (judge.nscp.aoltw.net [10.169.8.47]) by netscape.com (8.10.0/8.10.0) with ESMTP id g8ACx4m29826 for ; Tue, 10 Sep 2002 05:59:04 -0700 (PDT) Received: from netscape.com ([10.169.192.22]) by judge.mcom.com (Netscape Messaging Server 4.15) with ESMTP id H286CI02.UWW; Tue, 10 Sep 2002 06:48:18 -0700 Message-ID: <3D7DF82F.6080109@netscape.com> Date: Tue, 10 Sep 2002 09:48:31 -0400 From: mcs@netscape.com (Mark C Smith) Organization: Netscape Communications Corp. User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.1) Gecko/20020823 Netscape/7.0 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Kurt D. Zeilenga" CC: capple@dsi-consulting.net, ietf-ldup@imc.org Subject: Re: concluding LDUP WG (Was: LDAPv3 Replication Access Control Design Team Report) References: <5.1.0.14.0.20020909202120.0292ee48@127.0.0.1> <5.1.0.14.0.20020910061405.0292b778@127.0.0.1> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-ldup@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit Kurt D. Zeilenga wrote: > > Regardless of consensus on this issue, you should evaluate > (with WG input) whether or not the WG can complete its > deliverables in a reasonable amount of time and, if not, > recommend the WG be shutdown. > > While I think we can complete the LCUP work item in a > reasonable amount of time, I have serious doubts the WG > will ever complete LDUP work items. The WG seems to be > floundering here, not able to focus on the critical issues > and hopelessly lost in requirement debates. I don't think the group is hopeless lost in requirement debates, but I agree that not much progress has been made lately. I think this is mainly a "time and energy and focus" issue though. Therefore my question for the chairs and the group as a whole is: do we have enough volunteers with enough time and desire and expertise to complete the work? I don't know the answer. -Mark Smith Netscape From owner-ietf-ldup@mail.imc.org Tue Sep 10 10:09:33 2002 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA14884 for ; Tue, 10 Sep 2002 10:09:33 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g8AE62Q27591 for ietf-ldup-bks; Tue, 10 Sep 2002 07:06:02 -0700 (PDT) Received: from e2.ny.us.ibm.com (e2.ny.us.ibm.com [32.97.182.102]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g8AE61k27578; Tue, 10 Sep 2002 07:06:01 -0700 (PDT) Received: from northrelay04.pok.ibm.com (northrelay04.pok.ibm.com [9.56.224.206]) by e2.ny.us.ibm.com (8.12.2/8.12.2) with ESMTP id g8AE5uIV275912; Tue, 10 Sep 2002 10:05:56 -0400 Received: from d27ml001.rchland.ibm.com (d27ml001.rchland.ibm.com [9.10.226.142]) by northrelay04.pok.ibm.com (8.12.3/NCO/VER6.4) with ESMTP id g8AE5s50095994; Tue, 10 Sep 2002 10:05:54 -0400 Subject: RE: LDAPv3 Replication Access Control Design Team Report To: Timothy Hahn Cc: ietf-ldup@imc.org, owner-ietf-ldup@mail.imc.org X-Mailer: Lotus Notes Release 5.0.10 March 22, 2002 Message-ID: From: John McMeeking Date: Tue, 10 Sep 2002 09:05:54 -0500 X-MIMETrack: Serialize by Router on d27ml001/27/M/IBM(Build V60_07142002NP|July 14, 2002) at 09/10/2002 09:05:54 MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII Sender: owner-ietf-ldup@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: I agree with Tim. I see this as similar to how X.501 separates the general security model from a specific access control model. The X.501 security model defines a mechanism for identifying the access control schema and its scope of control, while its Basic Access Control defines one (of possibly many) access control schemes. I think we need the security model portion. At a minimum it provides a basis for determining whether all the servers support a given access control scheme. Beyond that, if a server supported multiple access control schemes, it provides a framework for specifying which access control scheme is used for some area of the DIT, or how servers should behave in the presence of differing or identical acces control schemes. We do not need to specify a specific access control scheme. We need to ensure that LDUP makes consistent access control across servers possible, possibly specifying that ACI is replicated (if the specific scheme represents ACI as operational attributes and/or LDAP objects). I'm sure some folks would love it if they could manage access control across a hetergenous directory network, but that is a much tougher nut to crack -- both from the perspective of agreeing on such a beast, and then getting vendors to implement it. Given the security model pieces, we can then define how LDUP should handle ACI information. For example: - If the same access control scheme is used on two servers that replicate to one another, the attributes and / or LDAP objects that define ACI are replicated. - If different access control schemes are used -- writeable server(s) use same model to control updates, read only servers might allow anonymous searches to all data -- LDUP could use this knowledge to not replicate the same attributes and / or objects. The above does not require that we define a specific scheme, only that we have a means to identify -- possibly select -- the access control model used by various servers for a given area of the DIT, and that a server that implements an access control model know how to behave with respect to replication of access control information. John McMeeking jmcmeek@us.ibm.com Timothy Hahn/Durham/IBM@I To: ietf-ldup@imc.org BMUS cc: Sent by: owner- Subject: RE: LDAPv3 Replication Access Control Design Team Report ietf-ldup@mail. imc.org 09/10/2002 08:04 AM Kurt, My opinions below. Regards, Tim Hahn Internet: hahnt@us.ibm.com Internal: Timothy Hahn/Durham/IBM@IBMUS phone: 919.224.1565 tie-line: 8/687.1565 fax: 919.224.2540 "Kurt D. Zeilenga" To: g> Subject: RE: LDAPv3 Replication Access Control Design Team Report Sent by: owner-ietf-ldup@m ail.imc.org 09/10/2002 08:42 AM Let's cut to the key question: Does LDAP replication REQUIRE a standard LDAP ACM? (REQUIRE here in the RFC 2119 sense). TJH> I believe that LDAP replication MUST ensure that the security TJH> (i.e. authorization to access - add/modify/search/delete) TJH> is NOT compromised by the LDAP replication mechanism defined. TJH> TJH> Thus, I believe that LDAP replication REQUIRES that access TJH> control issues be "attended to" (in the RFC 2119 sense). TJH> TJH> But I DO NOT feel that LDAP replication needs define a specific TJH> Access Control Model (ACM). LDAP replication need only ensure TJH> that SOME ACM can be applied across the servers involved in the TJH> data replicated amongst them and that LDAP replication doesn't TJH> "mess that up". If the consensus is yes, then we should determine how this requirement is going to be fulfilled. (I note that the proposed plan doesn't produce a standard LDAP ACM.) If the consensus is no, then we need not determine how an LDAP ACM will or will not be produced. It simply can remain out of scope. TJH> Unfortunately, I don't believe the answer is as "binary" TJH> as this. LDAP replication REQUIRES that things be done TJH> "securely" but it does NOT REQUIRE a specific ACM. I see little point is discussing the details of the plan until we've actually agreed upon requirements... Kurt From owner-ietf-ldup@mail.imc.org Tue Sep 10 10:14:26 2002 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA15050 for ; Tue, 10 Sep 2002 10:14:26 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g8AEBQD28414 for ietf-ldup-bks; Tue, 10 Sep 2002 07:11:26 -0700 (PDT) Received: from e1.ny.us.ibm.com (e1.ny.us.ibm.com [32.97.182.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g8AEBMk28406; Tue, 10 Sep 2002 07:11:22 -0700 (PDT) Received: from northrelay02.pok.ibm.com (northrelay02.pok.ibm.com [9.56.224.150]) by e1.ny.us.ibm.com (8.12.2/8.12.2) with ESMTP id g8AEB2EG251882; Tue, 10 Sep 2002 10:11:03 -0400 Received: from d27ml001.rchland.ibm.com (d27ml001.rchland.ibm.com [9.10.226.142]) by northrelay02.pok.ibm.com (8.12.3/NCO/VER6.4) with ESMTP id g8AEB0Kd104498; Tue, 10 Sep 2002 10:11:00 -0400 Subject: RE: LDAPv3 Replication Access Control Design Team Report To: "Liben, Michael (GTS)" Cc: ietf-ldup@imc.org, owner-ietf-ldup@mail.imc.org, "'Timothy Hahn'" X-Mailer: Lotus Notes Release 5.0.10 March 22, 2002 Message-ID: From: John McMeeking Date: Tue, 10 Sep 2002 09:10:59 -0500 X-MIMETrack: Serialize by Router on d27ml001/27/M/IBM(Build V60_07142002NP|July 14, 2002) at 09/10/2002 09:11:01 MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII Sender: owner-ietf-ldup@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Mike, I believe your reply addresses authentication of servers to each other in replication. I think that is a separate issue from LDUP requirements or behavior with respect to ensuring (or enabling) clients have the same authroity to access data on each of multiple replicas. The latter issue is what this report addresses. John McMeeking "Liben, Michael (GTS)" To: Timothy Hahn/Durham/IBM@IBMUS, ietf-ldup@imc.org Subject: RE: LDAPv3 Replication Access Control Design Team Report Sent by: owner- ietf-ldup@mail. imc.org 09/10/2002 08:27 AM I believe the security issues to be a business/technical problem that falls outside of the replication protocol. There are other mechanisms required to ensure that a server is trusted. The replicator always has the option of not replicating with an untrusted partner. Mike -----Original Message----- From: Timothy Hahn [mailto:hahnt@us.ibm.com] Sent: Tuesday, September 10, 2002 8:19 AM To: ietf-ldup@imc.org Subject: RE: LDAPv3 Replication Access Control Design Team Report Hi all, Since "silence" seems not to be an option in this case, I'll log my opinion here as siding IN FAVOR of the proposed work program. My reasoning here is that I feel that a) something needs to be done with respect to maintaining the security around information access, even when that information is subject to being replicated across a heterogeneous set of servers b) mandating any one particular access control model implementation is (as has been noted) a "rat hole" that is too deep and slimy to be productive c) a mechanism for identifying an access control model + agreement that, within an area of replication, a single access control model is applied is a good way to "isolate" this problem from the main LDUP tasks of defining a replication model (wire flows, data formats, administrative actions). By isolating the problem, we can "agree to disagree" (as a collective group) and still make progress on a replication protocol. The approach will also allow for those that CAN come to some agreement on an access control model to be able to employ LDUP mechanisms. I think that inserting this "level of indirection" with respect to access control model frees up the LDUP WG to concentrate on replication flows instead of being "stuck" as it has been for quite some time. Regards, Tim Hahn Internet: hahnt@us.ibm.com Internal: Timothy Hahn/Durham/IBM@IBMUS phone: 919.224.1565 tie-line: 8/687.1565 fax: 919.224.2540 From owner-ietf-ldup@mail.imc.org Tue Sep 10 10:18:34 2002 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA15188 for ; Tue, 10 Sep 2002 10:18:33 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g8AEFdR28546 for ietf-ldup-bks; Tue, 10 Sep 2002 07:15:39 -0700 (PDT) Received: from pretender.boolean.net (root@router.boolean.net [198.144.206.49]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g8AEFck28541 for ; Tue, 10 Sep 2002 07:15:38 -0700 (PDT) Received: from nomad.OpenLDAP.org (root@localhost [127.0.0.1]) by pretender.boolean.net (8.12.5/8.12.5) with ESMTP id g8AEFdft037838; Tue, 10 Sep 2002 14:15:39 GMT (envelope-from Kurt@OpenLDAP.org) Message-Id: <5.1.0.14.0.20020910064056.05559668@127.0.0.1> X-Sender: kurt@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Tue, 10 Sep 2002 07:15:04 -0700 To: "Timothy Hahn" From: "Kurt D. Zeilenga" Subject: RE: LDAPv3 Replication Access Control Design Team Report Cc: ietf-ldup@imc.org In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-ldup@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: At 06:04 AM 2002-09-10, Timothy Hahn (TJH) commented to my post: >Let's cut to the key question: > > Does LDAP replication REQUIRE a standard LDAP ACM? > >(REQUIRE here in the RFC 2119 sense). >TJH> I believe that LDAP replication MUST ensure that the security >TJH> (i.e. authorization to access - add/modify/search/delete) >TJH> is NOT compromised by the LDAP replication mechanism defined. >TJH> >TJH> Thus, I believe that LDAP replication REQUIRES that access >TJH> control issues be "attended to" (in the RFC 2119 sense). They can be "attended to" by detailing appropriate security considerations in the LDAP replication technical specifications. That is, the security consideration in the LDAP Replication requirement document can be addressed by security considerations in the LDAP Replication technical specification. >TJH> But I DO NOT feel that LDAP replication needs define a specific >TJH> Access Control Model (ACM). LDAP replication need only ensure >TJH> that SOME ACM can be applied across the servers involved in the >TJH> data replicated amongst them and that LDAP replication doesn't >TJH> "mess that up". First, I disagree that SOME ACM has to be applied across all servers. I frequently work in deployments where per-ACMs are not only in use, but DESIRED. (Not to day that they wouldn't prefer to have one ACM which does everything they want, but there is a realization by many deployers that they need different ACMs for different purposes and also need to be sure information across purposes.) An access control policy has to be applied. LDUP can rely on the authorities establishing the replication agreements to establish controls within each replica implementing the access control policy. Kurt From owner-ietf-ldup@mail.imc.org Tue Sep 10 10:57:09 2002 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA16565 for ; Tue, 10 Sep 2002 10:57:08 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g8AEquV29792 for ietf-ldup-bks; Tue, 10 Sep 2002 07:52:56 -0700 (PDT) Received: from pretender.boolean.net (root@router.boolean.net [198.144.206.49]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g8AEqsk29783; Tue, 10 Sep 2002 07:52:54 -0700 (PDT) Received: from nomad.OpenLDAP.org (root@localhost [127.0.0.1]) by pretender.boolean.net (8.12.5/8.12.5) with ESMTP id g8AEqsft037970; Tue, 10 Sep 2002 14:52:55 GMT (envelope-from Kurt@OpenLDAP.org) Message-Id: <5.1.0.14.0.20020910072831.0552af60@127.0.0.1> X-Sender: kurt@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Tue, 10 Sep 2002 07:52:20 -0700 To: John McMeeking From: "Kurt D. Zeilenga" Subject: Replicating policy information (RE: LDAPv3 Replication Access Control Design Team Report) Cc: Timothy Hahn , ietf-ldup@imc.org, owner-ietf-ldup@mail.imc.org In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-ldup@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: John hits on a interesting point, but he limits it to just access control information. I also disagree with his conclusion he draws from the point. When replicating between heterogeneous servers, each server will have different operational attributes (as well as entries which only hold operational information). Some of these operational attributes are maintained by the server and provide information to the directory users. Some are maintained by directory users and are used by the directory server in its processing. Those of the latter can be viewed as policy attributes. In some cases, it may be desirable to share values of policy information. In other cases, no. What LDUP needs to ensure is that replications agreements can express the POLICY for which policy attributes are to be replicated and which ones are not to be replicated. Then the authority (or authorities) establishing the replication agreement will have the means for ensuring only information appropriate to be replicated is replicated. Hence, LDUP MUST support fractional and partial replication and LDUP replication agreements must be capable of expressing the fraction and/or part to be replicated. However, I believe it unwise (and insecure) for LDUP to support negotiate (select) what policy information should be exchanged between replicas. What to replicate should be explicit in the replication agreement. Kurt At 07:05 AM 2002-09-10, John McMeeking wrote: > > > > > >I agree with Tim. > >I see this as similar to how X.501 separates the general security model >from a specific access control model. The X.501 security model defines a >mechanism for identifying the access control schema and its scope of >control, while its Basic Access Control defines one (of possibly many) >access control schemes. > >I think we need the security model portion. At a minimum it provides a >basis for determining whether all the servers support a given access >control scheme. Beyond that, if a server supported multiple access control >schemes, it provides a framework for specifying which access control scheme >is used for some area of the DIT, or how servers should behave in the >presence of differing or identical acces control schemes. > >We do not need to specify a specific access control scheme. We need to >ensure that LDUP makes consistent access control across servers possible, >possibly specifying that ACI is replicated (if the specific scheme >represents ACI as operational attributes and/or LDAP objects). I'm sure >some folks would love it if they could manage access control across a >hetergenous directory network, but that is a much tougher nut to crack -- >both from the perspective of agreeing on such a beast, and then getting >vendors to implement it. > >Given the security model pieces, we can then define how LDUP should handle >ACI information. For example: >- If the same access control scheme is used on two servers that replicate >to one another, the attributes and / or LDAP objects that define ACI are >replicated. >- If different access control schemes are used -- writeable server(s) use >same model to control updates, read only servers might allow anonymous >searches to all data -- LDUP could use this knowledge to not replicate the >same attributes and / or objects. > >The above does not require that we define a specific scheme, only that we >have a means to identify -- possibly select -- the access control model >used by various servers for a given area of the DIT, and that a server that >implements an access control model know how to behave with respect to >replication of access control information. > > >John McMeeking >jmcmeek@us.ibm.com > > > > > Timothy > Hahn/Durham/IBM@I To: ietf-ldup@imc.org > BMUS cc: > Sent by: owner- Subject: RE: LDAPv3 Replication Access Control Design Team Report > ietf-ldup@mail. > imc.org > > > 09/10/2002 08:04 > AM > > > > > > > >Kurt, > >My opinions below. > >Regards, >Tim Hahn > >Internet: hahnt@us.ibm.com >Internal: Timothy Hahn/Durham/IBM@IBMUS >phone: 919.224.1565 tie-line: 8/687.1565 >fax: 919.224.2540 > > > > > "Kurt D. > > Zeilenga" To: consulting.net> > org> > g> Subject: RE: LDAPv3 >Replication Access Control Design Team Report > Sent by: > > owner-ietf-ldup@m > > ail.imc.org > > > > 09/10/2002 08:42 > > AM > > > > > > > >Let's cut to the key question: > > Does LDAP replication REQUIRE a standard LDAP ACM? > >(REQUIRE here in the RFC 2119 sense). >TJH> I believe that LDAP replication MUST ensure that the security >TJH> (i.e. authorization to access - add/modify/search/delete) >TJH> is NOT compromised by the LDAP replication mechanism defined. >TJH> >TJH> Thus, I believe that LDAP replication REQUIRES that access >TJH> control issues be "attended to" (in the RFC 2119 sense). >TJH> >TJH> But I DO NOT feel that LDAP replication needs define a specific >TJH> Access Control Model (ACM). LDAP replication need only ensure >TJH> that SOME ACM can be applied across the servers involved in the >TJH> data replicated amongst them and that LDAP replication doesn't >TJH> "mess that up". > >If the consensus is yes, then we should determine how this >requirement is going to be fulfilled. (I note that the >proposed plan doesn't produce a standard LDAP ACM.) > >If the consensus is no, then we need not determine how an >LDAP ACM will or will not be produced. It simply can remain >out of scope. > >TJH> Unfortunately, I don't believe the answer is as "binary" >TJH> as this. LDAP replication REQUIRES that things be done >TJH> "securely" but it does NOT REQUIRE a specific ACM. > >I see little point is discussing the details of the plan >until we've actually agreed upon requirements... > >Kurt From owner-ietf-ldup@mail.imc.org Tue Sep 10 11:03:03 2002 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA16794 for ; Tue, 10 Sep 2002 11:03:03 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g8AExhw29945 for ietf-ldup-bks; Tue, 10 Sep 2002 07:59:43 -0700 (PDT) Received: from wstutil12a.ml.com (wstutil12a-v.ml.com [209.65.19.67]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g8AExfk29941; Tue, 10 Sep 2002 07:59:41 -0700 (PDT) Received: from wstutil13a.ml.com (wstutil13a [146.125.185.11]) by wstutil12a.ml.com (8.11.3/8.11.3/wstutil12a-1.2) with ESMTP id g8AExfd14031; Tue, 10 Sep 2002 10:59:41 -0400 (EDT) Received: from ewstwt01.exchange.ml.com (ewstwt01.exchange.ml.com [146.125.249.151]) by wstutil13a.ml.com (8.11.3/8.11.3/wstutil13a-1.1) with SMTP id g8AExf118554; Tue, 10 Sep 2002 10:59:41 -0400 (EDT) Received: from 172.25.100.10 by ewstwt01.exchange.ml.com with ESMTP ( Tumbleweed MMS SMTP Relay (MMS v4.7);); Tue, 10 Sep 2002 10:58:48 -0400 X-Server-Uuid: 3789b954-9c4e-11d3-af68-0008c73b0911 Received: by ewst10.exchange.ml.com with Internet Mail Service ( 5.5.2654.52) id ; Tue, 10 Sep 2002 10:58:44 -0400 Message-ID: <9B5CBD4986A9D511BE2100065B045DDF04B4C444@ehope21.hew.us.ml.com> From: "Liben, Michael (GTS)" To: "'John McMeeking'" cc: ietf-ldup@imc.org, owner-ietf-ldup@mail.imc.org, "'Timothy Hahn'" Subject: RE: LDAPv3 Replication Access Control Design Team Report Date: Tue, 10 Sep 2002 10:58:42 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2654.52) X-WSS-ID: 1160D722204554-01-01 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-ldup@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit No, that's exactly what I had in mind. Preserving security context across servers for access control is well beyond the scope of the protocol. Mike -----Original Message----- From: John McMeeking [mailto:jmcmeek@us.ibm.com] Sent: Tuesday, September 10, 2002 10:11 AM To: Liben, Michael (GTS) Cc: ietf-ldup@imc.org; owner-ietf-ldup@mail.imc.org; 'Timothy Hahn' Subject: RE: LDAPv3 Replication Access Control Design Team Report >Mike, >I believe your reply addresses authentication of servers to each other in >replication. I think that is a separate issue from LDUP requirements or >behavior with respect to ensuring (or enabling) clients have the same >authroity to access data on each of multiple replicas. The latter issue is >what this report addresses. >John McMeeking From owner-ietf-ldup@mail.imc.org Tue Sep 10 11:49:05 2002 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA18152 for ; Tue, 10 Sep 2002 11:49:04 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g8AFjWk04004 for ietf-ldup-bks; Tue, 10 Sep 2002 08:45:32 -0700 (PDT) Received: from e5.ny.us.ibm.com (e5.ny.us.ibm.com [32.97.182.105]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g8AFjUk03989; Tue, 10 Sep 2002 08:45:30 -0700 (PDT) Received: from northrelay02.pok.ibm.com (northrelay02.pok.ibm.com [9.56.224.150]) by e5.ny.us.ibm.com (8.12.2/8.12.2) with ESMTP id g8AFjQvI010606; Tue, 10 Sep 2002 11:45:26 -0400 Received: from d27ml001.rchland.ibm.com (d27ml001.rchland.ibm.com [9.10.226.142]) by northrelay02.pok.ibm.com (8.12.3/NCO/VER6.4) with ESMTP id g8AFjOKd059566; Tue, 10 Sep 2002 11:45:24 -0400 Subject: Re: Replicating policy information (RE: LDAPv3 Replication Access Control Design Team Report) To: "Kurt D. Zeilenga" Cc: ietf-ldup@imc.org, owner-ietf-ldup@mail.imc.org, Timothy Hahn X-Mailer: Lotus Notes Release 5.0.10 March 22, 2002 Message-ID: From: John McMeeking Date: Tue, 10 Sep 2002 10:45:24 -0500 X-MIMETrack: Serialize by Router on d27ml001/27/M/IBM(Build V60_07142002NP|July 14, 2002) at 09/10/2002 10:45:25 MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII Sender: owner-ietf-ldup@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Kurt, I have no problem with a more general solution/framework for replication of policy information. That certainly beats defining a new set of schema and behavior to handle each policy that is affected by replication. I did not intend to suggest that LDUP should negotiate replication of access control information, only that armed with information about what access control schemes were used, LDUP (likely under control of an administrator) could behave differently. I would certainly want an administrator to determine that access control information would not be replicated. But LDUP could adopt a default behavior that went the other way, and refuse to replicate with a server that does not support the proper access control scheme. Again, I only wanted to point out kinds of behavior related to access control (or other policies) that LDUP should address, and that LDUP required only a means to identify, possibly select, the access control scheme used, and not a specific access control scheme. John McMeeking "Kurt D. Zeilenga" To: John McMeeking/Rochester/IBM@IBMUS ldup@mail.imc.org Subject: Replicating policy information (RE: LDAPv3 Replication Access 09/10/2002 09:52 Control Design Team Report) AM John hits on a interesting point, but he limits it to just access control information. I also disagree with his conclusion he draws from the point. When replicating between heterogeneous servers, each server will have different operational attributes (as well as entries which only hold operational information). Some of these operational attributes are maintained by the server and provide information to the directory users. Some are maintained by directory users and are used by the directory server in its processing. Those of the latter can be viewed as policy attributes. In some cases, it may be desirable to share values of policy information. In other cases, no. What LDUP needs to ensure is that replications agreements can express the POLICY for which policy attributes are to be replicated and which ones are not to be replicated. Then the authority (or authorities) establishing the replication agreement will have the means for ensuring only information appropriate to be replicated is replicated. Hence, LDUP MUST support fractional and partial replication and LDUP replication agreements must be capable of expressing the fraction and/or part to be replicated. However, I believe it unwise (and insecure) for LDUP to support negotiate (select) what policy information should be exchanged between replicas. What to replicate should be explicit in the replication agreement. Kurt At 07:05 AM 2002-09-10, John McMeeking wrote: > > > > > >I agree with Tim. > >I see this as similar to how X.501 separates the general security model >from a specific access control model. The X.501 security model defines a >mechanism for identifying the access control schema and its scope of >control, while its Basic Access Control defines one (of possibly many) >access control schemes. > >I think we need the security model portion. At a minimum it provides a >basis for determining whether all the servers support a given access >control scheme. Beyond that, if a server supported multiple access control >schemes, it provides a framework for specifying which access control scheme >is used for some area of the DIT, or how servers should behave in the >presence of differing or identical acces control schemes. > >We do not need to specify a specific access control scheme. We need to >ensure that LDUP makes consistent access control across servers possible, >possibly specifying that ACI is replicated (if the specific scheme >represents ACI as operational attributes and/or LDAP objects). I'm sure >some folks would love it if they could manage access control across a >hetergenous directory network, but that is a much tougher nut to crack -- >both from the perspective of agreeing on such a beast, and then getting >vendors to implement it. > >Given the security model pieces, we can then define how LDUP should handle >ACI information. For example: >- If the same access control scheme is used on two servers that replicate >to one another, the attributes and / or LDAP objects that define ACI are >replicated. >- If different access control schemes are used -- writeable server(s) use >same model to control updates, read only servers might allow anonymous >searches to all data -- LDUP could use this knowledge to not replicate the >same attributes and / or objects. > >The above does not require that we define a specific scheme, only that we >have a means to identify -- possibly select -- the access control model >used by various servers for a given area of the DIT, and that a server that >implements an access control model know how to behave with respect to >replication of access control information. > > >John McMeeking >jmcmeek@us.ibm.com > > > > > Timothy > Hahn/Durham/IBM@I To: ietf-ldup@imc.org > BMUS cc: > Sent by: owner- Subject: RE: LDAPv3 Replication Access Control Design Team Report > ietf-ldup@mail. > imc.org > > > 09/10/2002 08:04 > AM > > > > > > > >Kurt, > >My opinions below. > >Regards, >Tim Hahn > >Internet: hahnt@us.ibm.com >Internal: Timothy Hahn/Durham/IBM@IBMUS >phone: 919.224.1565 tie-line: 8/687.1565 >fax: 919.224.2540 > > > > > "Kurt D. > > Zeilenga" To: consulting.net> > org> > g> Subject: RE: LDAPv3 >Replication Access Control Design Team Report > Sent by: > > owner-ietf-ldup@m > > ail.imc.org > > > > 09/10/2002 08:42 > > AM > > > > > > > >Let's cut to the key question: > > Does LDAP replication REQUIRE a standard LDAP ACM? > >(REQUIRE here in the RFC 2119 sense). >TJH> I believe that LDAP replication MUST ensure that the security >TJH> (i.e. authorization to access - add/modify/search/delete) >TJH> is NOT compromised by the LDAP replication mechanism defined. >TJH> >TJH> Thus, I believe that LDAP replication REQUIRES that access >TJH> control issues be "attended to" (in the RFC 2119 sense). >TJH> >TJH> But I DO NOT feel that LDAP replication needs define a specific >TJH> Access Control Model (ACM). LDAP replication need only ensure >TJH> that SOME ACM can be applied across the servers involved in the >TJH> data replicated amongst them and that LDAP replication doesn't >TJH> "mess that up". > >If the consensus is yes, then we should determine how this >requirement is going to be fulfilled. (I note that the >proposed plan doesn't produce a standard LDAP ACM.) > >If the consensus is no, then we need not determine how an >LDAP ACM will or will not be produced. It simply can remain >out of scope. > >TJH> Unfortunately, I don't believe the answer is as "binary" >TJH> as this. LDAP replication REQUIRES that things be done >TJH> "securely" but it does NOT REQUIRE a specific ACM. > >I see little point is discussing the details of the plan >until we've actually agreed upon requirements... > >Kurt From owner-ietf-ldup@mail.imc.org Tue Sep 10 13:58:11 2002 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA21640 for ; Tue, 10 Sep 2002 13:58:11 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g8AHsWD12760 for ietf-ldup-bks; Tue, 10 Sep 2002 10:54:32 -0700 (PDT) Received: from dns.caledonia.net (dns.caledonia.net [207.40.197.238]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g8AHsKk12734 for ; Tue, 10 Sep 2002 10:54:23 -0700 (PDT) Received: from D7ST2111 (pool-141-158-55-250.phil.east.verizon.net [141.158.55.250]) by dns.caledonia.net; Tue, 10 Sep 2002 11:53:54 -0600 Reply-To: From: "Chris Apple" To: Subject: RE: WG Last Call: LCUP Draft Date: Tue, 10 Sep 2002 13:51:47 -0400 Organization: DSI-Consulting, Inc. Message-ID: <001001c258f2$c5f93a10$0400a8c0@D7ST2111> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.4024 Importance: Normal In-Reply-To: <000601c251d7$83e0ee10$0400a8c0@D7ST2111> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Sender: owner-ietf-ldup@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit Thanks for the review and discussion so far. Per the WG Last Call announcement, the period of review will conclude on Tuesday, September 17, 2002 at 1700 ET. After that time, John and I will prepare a comprehensive issues/defects list, review that with the LCUP document editors, and post to the mailing list our findings. I'll post a target date for accomplishing this on Wednesday, September 18, 2002. Chris Apple - Principal Architect DSI Consulting, Inc. mailto:capple@dsi-consulting.net http://www.dsi-consulting.com -----Original Message----- From: owner-ietf-ldup@mail.imc.org [mailto:owner-ietf-ldup@mail.imc.org] On Behalf Of Chris Apple Sent: Sunday, September 01, 2002 12:49 PM To: ietf-ldup@imc.org Cc: John Strassner Subject: WG Last Call: LCUP Draft The purpose of this message is to initiate the LDUP working group last call on the LDAP Client Update Protocol draft. WHAT DOCUMENT? The document in last call is: http://www.ietf.org/internet-drafts/draft-ietf-ldup-lcup-03.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 Tuesday, September 3, 2002 and will Last approximately two weeks. It will end on Tuesday, September 17, 2002 at 1700 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 - Principal Architect DSI Consulting, Inc. mailto:capple@dsi-consulting.net http://www.dsi-consulting.com From owner-ietf-ldup@mail.imc.org Tue Sep 10 19:40:21 2002 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA29499 for ; Tue, 10 Sep 2002 19:40:20 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g8ANZbD00677 for ietf-ldup-bks; Tue, 10 Sep 2002 16:35:37 -0700 (PDT) Received: from kcmso2.proxy.att.com (kcmso2.att.com [192.128.134.71]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g8ANZak00673 for ; Tue, 10 Sep 2002 16:35:36 -0700 (PDT) Received: from qsun.mt.att.com ([135.16.31.2]) by kcmso2.proxy.att.com (AT&T IPNS/MSO-4.0) with SMTP id g8ANZYWQ027097 for ; Tue, 10 Sep 2002 18:35:35 -0500 (CDT) Received: from att.com by qsun.mt.att.com (SMI-8.6/ATTEMS-1.4.1 sol2) id TAA12144; Tue, 10 Sep 2002 19:35:32 -0400 Message-ID: <3D7E818B.CE209CD5@att.com> Date: Tue, 10 Sep 2002 19:34:35 -0400 From: Richard Huber X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en,ru MIME-Version: 1.0 To: ietf-ldup@imc.org Subject: Re: LDAPv3 Replication Access Control Design Team Report References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-ldup@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit I agree with Tim. If access controls are being used in a directory, the directory administrator has decided that it is important to control access to all or part of the data in the tree. So if replication is used in a directory that has access controls, there needs to be a way to make sure that those access controls are not lost because of replication. A standard access control mechanism for all LDAP directories is one way to do this. But it can also be done by making sure that the ACM in effect for any given part of the DIT is well defined, and that the definition can be carried as part of the data being replicated. So as Kurt noted, the design team did not propose a plan to design the one true access control mechanism. But we do need a replicatable way to express what ACM is in effect at any point in the DIT. Otherwise, administrators will have to choose between reliability (multiple copies via replication) and data security (access controls). If, as discussed by John McMeeking and Kurt, this leads to a general framework for replicating policy information, so much the better. This makes it possible to replicate policy information if the situation so demands. Requiring that LDUP make this possible is not the same as requiring that LDUP make this happen automatically. I agree with Kurt that LDUP should not automatically negotiate what policy data to transfer. But LDUP should make it possible to transfer policy data where needed, and we need the administrative structure to make this doable. I believe that is where the design team proposal is heading. Rick Huber Timothy Hahn wrote: > Kurt, > > My opinions below. > > Regards, > Tim Hahn > > Internet: hahnt@us.ibm.com > Internal: Timothy Hahn/Durham/IBM@IBMUS > phone: 919.224.1565 tie-line: 8/687.1565 > fax: 919.224.2540 > > > "Kurt D. > Zeilenga" To: > > g> Subject: RE: LDAPv3 Replication Access Control Design Team Report > Sent by: > owner-ietf-ldup@m > ail.imc.org > > > 09/10/2002 08:42 > AM > > > > Let's cut to the key question: > > Does LDAP replication REQUIRE a standard LDAP ACM? > > (REQUIRE here in the RFC 2119 sense). > TJH> I believe that LDAP replication MUST ensure that the security > TJH> (i.e. authorization to access - add/modify/search/delete) > TJH> is NOT compromised by the LDAP replication mechanism defined. > TJH> > TJH> Thus, I believe that LDAP replication REQUIRES that access > TJH> control issues be "attended to" (in the RFC 2119 sense). > TJH> > TJH> But I DO NOT feel that LDAP replication needs define a specific > TJH> Access Control Model (ACM). LDAP replication need only ensure > TJH> that SOME ACM can be applied across the servers involved in the > TJH> data replicated amongst them and that LDAP replication doesn't > TJH> "mess that up". > > If the consensus is yes, then we should determine how this > requirement is going to be fulfilled. (I note that the > proposed plan doesn't produce a standard LDAP ACM.) > > If the consensus is no, then we need not determine how an > LDAP ACM will or will not be produced. It simply can remain > out of scope. > > TJH> Unfortunately, I don't believe the answer is as "binary" > TJH> as this. LDAP replication REQUIRES that things be done > TJH> "securely" but it does NOT REQUIRE a specific ACM. > > I see little point is discussing the details of the plan > until we've actually agreed upon requirements... > > Kurt From owner-ietf-ldup@mail.imc.org Tue Sep 10 20:27:00 2002 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA00329 for ; Tue, 10 Sep 2002 20:26:59 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g8B0Nq702066 for ietf-ldup-bks; Tue, 10 Sep 2002 17:23:52 -0700 (PDT) Received: from mail4.microsoft.com (mail4.microsoft.com [131.107.3.122]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g8B0Nlk02054 for ; Tue, 10 Sep 2002 17:23:48 -0700 (PDT) Received: from inet-vrs-04.redmond.corp.microsoft.com ([157.54.8.149]) by mail4.microsoft.com with Microsoft SMTPSVC(5.0.2195.4905); Tue, 10 Sep 2002 17:23:45 -0700 Received: from 157.54.5.25 by inet-vrs-04.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Tue, 10 Sep 2002 17:23:46 -0700 Received: from red-imc-01.redmond.corp.microsoft.com ([157.54.9.102]) by inet-hub-03.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.2966); Tue, 10 Sep 2002 17:23:46 -0700 Received: from win-imc-02.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.84]) by red-imc-01.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.4905); Tue, 10 Sep 2002 17:23:46 -0700 Received: from win-msg-01.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.52]) by win-imc-02.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(6.0.3663.0); Tue, 10 Sep 2002 17:23:47 -0700 Content-class: urn:content-classes:message Subject: RE: LDAPv3 Replication Access Control Design Team Report MIME-Version: 1.0 Date: Tue, 10 Sep 2002 17:23:44 -0700 Content-Type: multipart/signed; boundary="----=_NextPart_000_0033_01C258EE.C3FD18C0"; micalg=SHA1; protocol="application/x-pkcs7-signature" X-MimeOLE: Produced By Microsoft Exchange V6.5.6728.0 Message-ID: <4AEE3169443CDD4796CA8A00B02191CD049299A1@win-msg-01.wingroup.windeploy.ntdev.microsoft.com> X-MS-Has-Attach: yes Thread-Topic: LDAPv3 Replication Access Control Design Team Report Thread-Index: AcJZIzhGe2h6fK3XTxiEeMbn2l9nqwABFvdw From: "Paul Leach" To: "Richard Huber" , X-OriginalArrivalTime: 11 Sep 2002 00:23:47.0774 (UTC) FILETIME=[7EEC45E0:01C25929] Sender: owner-ietf-ldup@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multi-part message in MIME format. ------=_NextPart_000_0033_01C258EE.C3FD18C0 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: 7bit > -----Original Message----- > From: Richard Huber [mailto:rvh@att.com] > Sent: Tuesday, September 10, 2002 4:35 > To: ietf-ldup@imc.org > Subject: Re: LDAPv3 Replication Access Control Design Team Report > > > > I agree with Tim. > > If access controls are being used in a directory, the > directory administrator has decided that it is important to > control access to all or part of the data in the tree. So if > replication is used in a directory that has access controls, > there needs to be a way to make sure that those access > controls are not lost because of replication. > > A standard access control mechanism for all LDAP directories > is one way to do this. But it can also be done by making > sure that the ACM in effect for any given part of the DIT is > well defined, and that the definition can be carried as part > of the data being replicated. Or it can be carried out of band. > > So as Kurt noted, the design team did not propose a plan to > design the one true access control mechanism. But we do need > a replicatable way to express what ACM is in effect at any > point in the DIT. Otherwise, administrators will have to > choose between reliability (multiple copies via replication) > and data security (access controls). No -- they can independently configure it at each replica. Often not very convenient, but it does show that it is possible to divorce ACM from replication. As long as the authorization policy and the shape of the DIT don't change very often, then it may not be all that big a problem. For example -- if I just replicate all my users' email SMIME certificates to another directory, then saying that they are world readable at the server level may be all the access control I need. > > If, as discussed by John McMeeking and Kurt, this leads to a > general framework for replicating policy information, so much > the better. This makes it possible to replicate policy > information if the situation so demands. Policy information that is stored as directory objects with no special semantics will get replicated just like any other object. That holds for authorization policy too. Heterogenous directories that agree on the schema for said objects will replicate their policy transparently. Ones that don't, won't, and their administrators will have to arrange that the correct policy gets configured in some other way at all replicas. The replication protocol need say nothing more than that. Paul ------=_NextPart_000_0033_01C258EE.C3FD18C0 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Disposition: attachment; filename="smime.p7s" Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIjZTCCA0Aw ggKpoAMCAQICECElZvdedYS4R497WbSp4hIwDQYJKoZIhvcNAQEFBQAwTDELMAkGA1UEBhMCVVMx EjAQBgNVBAoTCU1pY3Jvc29mdDEOMAwGA1UECxMFTnRkZXYxGTAXBgNVBAMTEE5UREVWIFNBIFJv b3QgQ0EwHhcNMDAwOTIwMjEyNDQ1WhcNMDIwOTIwMjEzMzI4WjBMMQswCQYDVQQGEwJVUzESMBAG A1UEChMJTWljcm9zb2Z0MQ4wDAYDVQQLEwVOdGRldjEZMBcGA1UEAxMQTlRERVYgU0EgUm9vdCBD QTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAxym3bBtJ93ep9YM9eFtrJSmFA8NG6OtxTKRL LyorXMYNUzLsdozvGWdSZwlzbvATakzrzriuqq7QgaBzJvS0Oq8yAzthqf0jBQysGvTH1LHieo3b mCFFOOUtGvfdJGbEMvTb8cT0yxAgPJ7Or0WZta77f/ARUNWWv6g7TNUUhe0CAwEAAaOCASEwggEd MBMGCSsGAQQBgjcUAgQGHgQAQwBBMAsGA1UdDwQEAwIBRjAPBgNVHRMBAf8EBTADAQH/MB0GA1Ud DgQWBBR3yXRpLDn+OGX0hwVYCM69upfaEDCBtgYDVR0fBIGuMIGrMIGooIGloIGihk5odHRwOi8v d2hpY2FzYXJvb3RjYS5udGRldi5taWNyb3NvZnQuY29tL0NlcnRFbnJvbGwvTlRERVYlMjBTQSUy MFJvb3QlMjBDQS5jcmyGUGZpbGU6Ly9cXHdoaWNhc2Fyb290Y2EubnRkZXYubWljcm9zb2Z0LmNv bVxDZXJ0RW5yb2xsXE5UREVWJTIwU0ElMjBSb290JTIwQ0EuY3JsMBAGCSsGAQQBgjcVAQQDAgEA MA0GCSqGSIb3DQEBBQUAA4GBAAj54W8kzais9v83BJCkQFSgVejj3junPZCxUeCnGzzDmrxUuOPc ofoYlSwZ/11uLoVVc5qCkEZknWSmwRRViiizyf3dRuYsR9seP2ixJUtKHHwbqHeoQpUpZpOt+czy LOKJpPc9ihx917XumDCrNTF0Urn8pouG9wYyB3wUnmSdMIIFcjCCBTKgAwIBAgIKGB2IeAAEAAAB 9jAJBgcqhkjOOAQDMGExCzAJBgNVBAYTAlVTMRIwEAYDVQQKEwlNaWNyb3NvZnQxDjAMBgNVBAsT BU50ZGV2MS4wLAYDVQQDEyVOVERFViBJbnRlcm1lZGlhdGUgU3Vib3JkaW5hdGUgV2hpY2EyMB4X DTAyMDgyMTIyNDkzNFoXDTA0MDgyMTIyNTkzNFowSzELMAkGA1UEBhMCVVMxEjAQBgNVBAoTCU1p Y3Jvc29mdDEOMAwGA1UECxMFTnRkZXYxGDAWBgNVBAMTD05UREVWIElTU1VFMyBDQTCBnzANBgkq hkiG9w0BAQEFAAOBjQAwgYkCgYEArJQVl2NDU7SFdidDGOYUE5VbRZTx9ytu2VV23RlDHtLM1yP4 4a5LZEQyDWV9L+no9wli/Zkr6qnlX2FCeEQ3LjY48dbQYm0OU5OLo1VyIl3ScCkwYrt2Kg4b/Go6 I2YAEq0JwDs/qjRrdxD9Up9GGjcYz76cu8ixQ3dzu0I8Z4ECAwEAAaOCA6AwggOcMA8GA1UdEwEB /wQFMAMBAf8wHQYDVR0OBBYEFIvRzWHx6a+OvJHQQOopv+YuhUBXMAsGA1UdDwQEAwIBhjASBgkr BgEEAYI3FQEEBQIDAgACMCMGCSsGAQQBgjcVAgQWBBQUKdnR8pZTN2GPEm80nT68ux4XfjARBgNV HSAECjAIMAYGBFUdIAAwGQYJKwYBBAGCNxQCBAweCgBTAHUAYgBDAEEwHwYDVR0jBBgwFoAU4r4D cNWLINJBRGqv5sh3cVolAB8wggFcBgNVHR8EggFTMIIBTzCCAUugggFHoIIBQ4ZfaHR0cDovL3do aWNhMi5udGRldi5taWNyb3NvZnQuY29tL0NlcnRFbnJvbGwvTlRERVYlMjBJbnRlcm1lZGlhdGUl MjBTdWJvcmRpbmF0ZSUyMFdoaWNhMig0KS5jcmyGgd9sZGFwOi8vL0NOPU5UREVWJTIwSW50ZXJt ZWRpYXRlJTIwU3Vib3JkaW5hdGUlMjBXaGljYTIoNCksQ049d2hpY2EyLENOPUNEUCxDTj1QdWJs aWMlMjBLZXklMjBTZXJ2aWNlcyxDTj1TZXJ2aWNlcyxDTj1Db25maWd1cmF0aW9uLERDPW50ZGV2 LERDPW1pY3Jvc29mdCxEQz1jb20/Y2VydGlmaWNhdGVSZXZvY2F0aW9uTGlzdD9iYXNlP29iamVj dENsYXNzPWNSTERpc3RyaWJ1dGlvblBvaW50MIIBcwYIKwYBBQUHAQEEggFlMIIBYTCB1QYIKwYB BQUHMAKGgchsZGFwOi8vL0NOPU5UREVWJTIwSW50ZXJtZWRpYXRlJTIwU3Vib3JkaW5hdGUlMjBX aGljYTIsQ049QUlBLENOPVB1YmxpYyUyMEtleSUyMFNlcnZpY2VzLENOPVNlcnZpY2VzLENOPUNv bmZpZ3VyYXRpb24sREM9bnRkZXYsREM9bWljcm9zb2Z0LERDPWNvbT9jQUNlcnRpZmljYXRlP2Jh c2U/b2JqZWN0Q2xhc3M9Y2VydGlmaWNhdGlvbkF1dGhvcml0eTCBhgYIKwYBBQUHMAKGemh0dHA6 Ly93aGljYTIubnRkZXYubWljcm9zb2Z0LmNvbS9DZXJ0RW5yb2xsL3doaWNhMi5udGRldi5taWNy b3NvZnQuY29tX05UREVWJTIwSW50ZXJtZWRpYXRlJTIwU3Vib3JkaW5hdGUlMjBXaGljYTIoNCku Y3J0MAkGByqGSM44BAMDLwAwLAIUX6dw7hXG7KIivNRBFbae0EHs9S4CFAKjwVGR/bQ3ivkUXIKp p7oW+uGNMIIF2DCCBUGgAwIBAgIKSkl2VQAAAAAALjANBgkqhkiG9w0BAQUFADBMMQswCQYDVQQG EwJVUzESMBAGA1UEChMJTWljcm9zb2Z0MQ4wDAYDVQQLEwVOdGRldjEZMBcGA1UEAxMQTlRERVYg U0EgUm9vdCBDQTAeFw0wMjA4MDcwMzQ1MDJaFw0wMjA5MjAyMTMzMjhaMEwxCzAJBgNVBAYTAlVT MRIwEAYDVQQKEwlNaWNyb3NvZnQxDjAMBgNVBAsTBU50ZGV2MRkwFwYDVQQDExBOVERFViBTQSBS b290IENBMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA6gj42lDjCdbV7XWQ+SFOeKAA 7SR53dEkZ+2Ud0YPcM87A0CRNHNO1IhBNhmRPH4Cy75qiqyu7p53pb8zGF3v4PFDYTqdcW893tad IyoQGsAhM5ZwSlJlpLZp9Yvu6nlHvDo9mXz6WF6i18lUx1SAO0G+AELzFOzs8P7NPT2Jng9yEgtM rQN0pdQnXreuit1lIbRyZ4JX6nPX8S0G3Dq4Py0uwOUhw1ZCemHgxxiOY1/qN227O7Cv74IYeLlI QCEcuXRaO3DMAWW1J9GaPZVyWOKPOlM8SPSUedcf8bj2iGHbg17F3NDQoeNqOQzfqsh8mmWYAIOT OYi+XpKOTLMlbQIDAQABo4IDOzCCAzcwHQYDVR0OBBYEFIjJzZycOiKA6uQt2hVHL/X7xLybMBAG CSsGAQQBgjcVFgQDAgEBMB8GA1UdIwQYMBaAFHfJdGksOf44ZfSHBVgIzr26l9oQMIIBOgYDVR0f BIIBMTCCAS0wggEpoIIBJaCCASGGgc5sZGFwOi8vL0NOPU5UREVWJTIwU0ElMjBSb290JTIwQ0Es Q049d2hpY2FzYXJvb3RjYSxDTj1DRFAsQ049UHVibGljJTIwS2V5JTIwU2VydmljZXMsQ049U2Vy dmljZXMsQ049Q29uZmlndXJhdGlvbixEQz1udGRldixEQz1taWNyb3NvZnQsREM9Y29tP2NlcnRp ZmljYXRlUmV2b2NhdGlvbkxpc3Q/YmFzZT9vYmplY3RDbGFzcz1jUkxEaXN0cmlidXRpb25Qb2lu dIZOaHR0cDovL3doaWNhc2Fyb290Y2EubnRkZXYubWljcm9zb2Z0LmNvbS9DZXJ0RW5yb2xsL05U REVWJTIwU0ElMjBSb290JTIwQ0EuY3JsMIIBUwYIKwYBBQUHAQEEggFFMIIBQTCBwAYIKwYBBQUH MAKGgbNsZGFwOi8vL0NOPU5UREVWJTIwU0ElMjBSb290JTIwQ0EsQ049QUlBLENOPVB1YmxpYyUy MEtleSUyMFNlcnZpY2VzLENOPVNlcnZpY2VzLENOPUNvbmZpZ3VyYXRpb24sREM9bnRkZXYsREM9 bWljcm9zb2Z0LERDPWNvbT9jQUNlcnRpZmljYXRlP2Jhc2U/b2JqZWN0Q2xhc3M9Y2VydGlmaWNh dGlvbkF1dGhvcml0eTB8BggrBgEFBQcwAoZwaHR0cDovL3doaWNhc2Fyb290Y2EubnRkZXYubWlj cm9zb2Z0LmNvbS9DZXJ0RW5yb2xsL3doaWNhc2Fyb290Y2EubnRkZXYubWljcm9zb2Z0LmNvbV9O VERFViUyMFNBJTIwUm9vdCUyMENBLmNydDAdBgkrBgEEAYI3FAIEEB4OAEMAcgBvAHMAcwBDAEEw CwYDVR0PBAQDAgGGMBEGA1UdIAQKMAgwBgYEVR0gADAPBgNVHRMBAf8EBTADAQH/MA0GCSqGSIb3 DQEBBQUAA4GBAFcI+rIRHNCdB3c0hBxZYHjkS3tMhunxRZzER6vsqqF9huqp1oVE1hFqiQR1wimW AF/haAGYnvhk8IkKpmBnUqXM1Dtk19KiZfzijLuZepoHOsUtuveN+9ginb+pvIZygr/VdZC5ghy3 jVCk0Ktq/janEuXZRmq99Rnofs7EUKUnMIIGqDCCBhGgAwIBAgIKE/JikQACABzjhTANBgkqhkiG 9w0BAQUFADBLMQswCQYDVQQGEwJVUzESMBAGA1UEChMJTWljcm9zb2Z0MQ4wDAYDVQQLEwVOdGRl djEYMBYGA1UEAxMPTlRERVYgSVNTVUUzIENBMB4XDTAyMDkxMDE3NTgzNloXDTAyMTIwOTE3NTgz NlowgbAxEzARBgoJkiaJk/IsZAEZFgNjb20xGTAXBgoJkiaJk/IsZAEZFgltaWNyb3NvZnQxFDAS BgoJkiaJk/IsZAEZFgRjb3JwMRUwEwYKCZImiZPyLGQBGRYFbnRkZXYxEDAOBgNVBAsTB0lNLVNl bGYxFzAVBgNVBAsTDkxpZ2h0bHlNYW5hZ2VkMREwDwYDVQQLEwhMb3dUQ08tRTETMBEGA1UEAxMK UGF1bCBMZWFjaDCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAxxyTBho/oXG5/N7VPUeu5khf cd2JYWlxN5v83jVm/ZjdHnEA6m7dLCCZUu3ZGpq9bu3fqzFtjvucUVasSWeMbRRxZhqUgwMBIRFp ImHgGQBW5Q7sZMqjd5MA7WCPpgFetljOs5JRxJTobsCePGRd2m6/ZLS0Kis2Eg1wxjp23SkCAwEA AaOCBCswggQnMAsGA1UdDwQEAwIHgDAdBgNVHQ4EFgQUO0Nh4m79Mkt0Rnzq47o2pRNM5nwwPgYJ KwYBBAGCNxUHBDEwLwYnKwYBBAGCNxUIjeDRiU6E15zDB4amhvscj9O/phWCv5z2fIbe5oBUAgF0 AgEAMB8GA1UdIwQYMBaAFIvRzWHx6a+OvJHQQOopv+YuhUBXMIIBiAYDVR0fBIIBfzCCAXswggF3 oIIBc6CCAW+Ggc9sZGFwOi8vL0NOPU5UREVWJTIwSVNTVUUzJTIwQ0EoMiksQ049V0hJQ0EzLENO PUNEUCxDTj1QdWJsaWMlMjBLZXklMjBTZXJ2aWNlcyxDTj1TZXJ2aWNlcyxDTj1Db25maWd1cmF0 aW9uLERDPW50ZGV2LERDPWNvcnAsREM9bWljcm9zb2Z0LERDPWNvbT9jZXJ0aWZpY2F0ZVJldm9j YXRpb25MaXN0P2Jhc2U/b2JqZWN0Q2xhc3M9Y1JMRGlzdHJpYnV0aW9uUG9pbnSGTWh0dHA6Ly93 aGljYXdlYi5udGRldi5jb3JwLm1pY3Jvc29mdC5jb20vTlRERVZDUkxzL05UREVWJTIwSVNTVUUz JTIwQ0EoMikuY3JshkxodHRwOi8vd2hpY2EzLm50ZGV2LmNvcnAubWljcm9zb2Z0LmNvbS9DZXJ0 RW5yb2xsL05UREVWJTIwSVNTVUUzJTIwQ0EoMikuY3JsMIIBVAYIKwYBBQUHAQEEggFGMIIBQjCB xQYIKwYBBQUHMAKGgbhsZGFwOi8vL0NOPU5UREVWJTIwSVNTVUUzJTIwQ0EsQ049QUlBLENOPVB1 YmxpYyUyMEtleSUyMFNlcnZpY2VzLENOPVNlcnZpY2VzLENOPUNvbmZpZ3VyYXRpb24sREM9bnRk ZXYsREM9Y29ycCxEQz1taWNyb3NvZnQsREM9Y29tP2NBQ2VydGlmaWNhdGU/YmFzZT9vYmplY3RD bGFzcz1jZXJ0aWZpY2F0aW9uQXV0aG9yaXR5MHgGCCsGAQUFBzAChmxodHRwOi8vd2hpY2EzLm50 ZGV2LmNvcnAubWljcm9zb2Z0LmNvbS9DZXJ0RW5yb2xsL1dISUNBMy5udGRldi5jb3JwLm1pY3Jv c29mdC5jb21fTlRERVYlMjBJU1NVRTMlMjBDQSgyKS5jcnQwEwYDVR0lBAwwCgYIKwYBBQUHAwQw LQYDVR0gBCYwJDAiBiArBgEEAYI3FQiN4NGJToTXnMMHhqaG+xyP07+mFQGDETAbBgkrBgEEAYI3 FQoEDjAMMAoGCCsGAQUFBwMEMFMGA1UdEQRMMEqgKgYKKwYBBAGCNxQCA6AcDBpwYXVsbGVAbnRk ZXYubWljcm9zb2Z0LmNvbYEccGF1bGxlQHdpbmRvd3MubWljcm9zb2Z0LmNvbTANBgkqhkiG9w0B AQUFAAOBgQAOHgisD+85vwjg4TzZGwiU/JvJdssUskTEVlWgn4yHKPqUaiUgh13S1rRkLzWIAzAQ oo9JOSG6i2R3JNr5PX1wY2SA5xB5EQ/6yWvD/AOb/2jgkW+PkMqTpG7CI+TOg/jROudWg1p2QBDV 1CeG1bzdY5msNEg3zlPjBMnGH3g3gjCCBuwwggZVoAMCAQICChPyWz4AAgAc44MwDQYJKoZIhvcN AQEFBQAwSzELMAkGA1UEBhMCVVMxEjAQBgNVBAoTCU1pY3Jvc29mdDEOMAwGA1UECxMFTnRkZXYx GDAWBgNVBAMTD05UREVWIElTU1VFMyBDQTAeFw0wMjA5MTAxNzU4MzRaFw0wMjExMDkxNzU4MzRa MIHdMRMwEQYKCZImiZPyLGQBGRYDY29tMRkwFwYKCZImiZPyLGQBGRYJbWljcm9zb2Z0MRQwEgYK CZImiZPyLGQBGRYEY29ycDEVMBMGCgmSJomT8ixkARkWBW50ZGV2MRAwDgYDVQQLEwdJTS1TZWxm MRcwFQYDVQQLEw5MaWdodGx5TWFuYWdlZDERMA8GA1UECxMITG93VENPLUUxEzARBgNVBAMTClBh dWwgTGVhY2gxKzApBgkqhkiG9w0BCQEWHHBhdWxsZUB3aW5kb3dzLm1pY3Jvc29mdC5jb20wgZ8w DQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBAOxtV4ncbRKk4dGkkeoIIQw7uGPZ8CARCb8VTLHFZRKq d8Q5xZHOqWzYrFEl1tYel4ix5RJA8RXiq6hNIPIXp+YCj+a7Kw9LXb15Sy4coHHZR6oGQoQIOtYx 08aE3W8CgkjFa8WgNh7gKi9S+iLg77kJ+qBtJJYKgBAnacKFgWnfAgMBAAGjggRCMIIEPjALBgNV HQ8EBAMCBDAwRAYJKoZIhvcNAQkPBDcwNTAOBggqhkiG9w0DAgICAIAwDgYIKoZIhvcNAwQCAgCA MAcGBSsOAwIHMAoGCCqGSIb3DQMHMB0GA1UdDgQWBBTO6NDbk11+X6HBJspDxOXuBb7kCTA+Bgkr BgEEAYI3FQcEMTAvBicrBgEEAYI3FQiN4NGJToTXnMMHhqaG+xyP07+mFYenvuIJjrGt8U0CAXQC AQAwHwYDVR0jBBgwFoAUi9HNYfHpr468kdBA6im/5i6FQFcwggGIBgNVHR8EggF/MIIBezCCAXeg ggFzoIIBb4aBz2xkYXA6Ly8vQ049TlRERVYlMjBJU1NVRTMlMjBDQSgyKSxDTj1XSElDQTMsQ049 Q0RQLENOPVB1YmxpYyUyMEtleSUyMFNlcnZpY2VzLENOPVNlcnZpY2VzLENOPUNvbmZpZ3VyYXRp b24sREM9bnRkZXYsREM9Y29ycCxEQz1taWNyb3NvZnQsREM9Y29tP2NlcnRpZmljYXRlUmV2b2Nh dGlvbkxpc3Q/YmFzZT9vYmplY3RDbGFzcz1jUkxEaXN0cmlidXRpb25Qb2ludIZNaHR0cDovL3do aWNhd2ViLm50ZGV2LmNvcnAubWljcm9zb2Z0LmNvbS9OVERFVkNSTHMvTlRERVYlMjBJU1NVRTMl MjBDQSgyKS5jcmyGTGh0dHA6Ly93aGljYTMubnRkZXYuY29ycC5taWNyb3NvZnQuY29tL0NlcnRF bnJvbGwvTlRERVYlMjBJU1NVRTMlMjBDQSgyKS5jcmwwggFUBggrBgEFBQcBAQSCAUYwggFCMIHF BggrBgEFBQcwAoaBuGxkYXA6Ly8vQ049TlRERVYlMjBJU1NVRTMlMjBDQSxDTj1BSUEsQ049UHVi bGljJTIwS2V5JTIwU2VydmljZXMsQ049U2VydmljZXMsQ049Q29uZmlndXJhdGlvbixEQz1udGRl dixEQz1jb3JwLERDPW1pY3Jvc29mdCxEQz1jb20/Y0FDZXJ0aWZpY2F0ZT9iYXNlP29iamVjdENs YXNzPWNlcnRpZmljYXRpb25BdXRob3JpdHkweAYIKwYBBQUHMAKGbGh0dHA6Ly93aGljYTMubnRk ZXYuY29ycC5taWNyb3NvZnQuY29tL0NlcnRFbnJvbGwvV0hJQ0EzLm50ZGV2LmNvcnAubWljcm9z b2Z0LmNvbV9OVERFViUyMElTU1VFMyUyMENBKDIpLmNydDATBgNVHSUEDDAKBggrBgEFBQcDBDAb BgkrBgEEAYI3FQoEDjAMMAoGCCsGAQUFBwMEMFMGA1UdEQRMMEqgKgYKKwYBBAGCNxQCA6AcDBpw YXVsbGVAbnRkZXYubWljcm9zb2Z0LmNvbYEccGF1bGxlQHdpbmRvd3MubWljcm9zb2Z0LmNvbTAN BgkqhkiG9w0BAQUFAAOBgQAfnH21DqFEF7Q75/vv+H4JqoZAM1GWY6McH8DpVqNhZu9jqSZe1COU ejbFlLqvVEGZniUYNz7OfmXHYjAGRtlHNYEQzATaDUXm3eM9NphHsCWlhkRwPztKdNhofsdKznpx CaCtB/QlxLof9T047nyrtrLaoUVB3I2fZhpUseX60jCCBy8wggYXoAMCAQICCkrFlxQAAQAAADAw DQYJKoZIhvcNAQEFBQAwTDELMAkGA1UEBhMCVVMxEjAQBgNVBAoTCU1pY3Jvc29mdDEOMAwGA1UE CxMFTnRkZXYxGTAXBgNVBAMTEE5UREVWIFNBIFJvb3QgQ0EwHhcNMDIwODA3MDYwMDI5WhcNMDUw ODA3MDYxMDI5WjBhMQswCQYDVQQGEwJVUzESMBAGA1UEChMJTWljcm9zb2Z0MQ4wDAYDVQQLEwVO dGRldjEuMCwGA1UEAxMlTlRERVYgSW50ZXJtZWRpYXRlIFN1Ym9yZGluYXRlIFdoaWNhMjCCAbcw ggErBgcqhkjOOAQBMIIBHgKBgQD6Es97u5iwea4ZR+QhOQGpawZejbbLfr2SzT0T4SPAAazbhymF pUeoVnf4pD+SDIA0K+w1KSa63b+Gdk9aST1RByMQrmtx01/6Pl1Rk2V3Qb+MfjoRy5rddSnE8vQf tLaYN6bCQuJvrWjjWm3fssPxAfQKD5XRnR6BgQUhjnQC4wIVAJhPlD2ydVrV6RStlMJjOhv86OtD AoGAZsoPfe8UED5wq+CK2salIubF17L0j74psDv1BBcScAIlkvDlLp754exndP7HA+WDZFQLG0WB flzYMmFQrGLrAtSx/A76Ds6uB8/JYPSv9pAPNL9kpK+Ax9RBTNiRtyfR26t+tg5PYvFehwGRAPz/ JAffyfnCNS6F5VrX8ObmgpgDgYUAAoGBAKJK0lYkyELe2RtGLY69hi3HKuW08w7JlHUTkM9aovXm +XDiGGtmF4BOnJmUyCBTi8emz3YG8GUgLDnwUKH0KCxt7yXkHBrAP74+8M45s5WiJmLARfTmURSp ewt6/0y0oR1wU0B6Nes3Ahriwl4ULzrK4yYZSr4b0eXzJjaTiuI5o4IDZzCCA2MwDwYDVR0TAQH/ BAUwAwEB/zAdBgNVHQ4EFgQU4r4DcNWLINJBRGqv5sh3cVolAB8wCwYDVR0PBAQDAgGGMBIGCSsG AQQBgjcVAQQFAgMEAAQwIwYJKwYBBAGCNxUCBBYEFDKNeP+E6hL1pLoIS+yzD+lHTfN9MBEGA1Ud IAQKMAgwBgYEVR0gADAZBgkrBgEEAYI3FAIEDB4KAFMAdQBiAEMAQTAfBgNVHSMEGDAWgBSIyc2c nDoigOrkLdoVRy/1+8S8mzCCAUAGA1UdHwSCATcwggEzMIIBL6CCASugggEnhoHRbGRhcDovLy9D Tj1OVERFViUyMFNBJTIwUm9vdCUyMENBKDEpLENOPXdoaWNhc2Fyb290Y2EsQ049Q0RQLENOPVB1 YmxpYyUyMEtleSUyMFNlcnZpY2VzLENOPVNlcnZpY2VzLENOPUNvbmZpZ3VyYXRpb24sREM9bnRk ZXYsREM9bWljcm9zb2Z0LERDPWNvbT9jZXJ0aWZpY2F0ZVJldm9jYXRpb25MaXN0P2Jhc2U/b2Jq ZWN0Q2xhc3M9Y1JMRGlzdHJpYnV0aW9uUG9pbnSGUWh0dHA6Ly93aGljYXNhcm9vdGNhLm50ZGV2 Lm1pY3Jvc29mdC5jb20vQ2VydEVucm9sbC9OVERFViUyMFNBJTIwUm9vdCUyMENBKDEpLmNybDCC AVYGCCsGAQUFBwEBBIIBSDCCAUQwgcAGCCsGAQUFBzAChoGzbGRhcDovLy9DTj1OVERFViUyMFNB JTIwUm9vdCUyMENBLENOPUFJQSxDTj1QdWJsaWMlMjBLZXklMjBTZXJ2aWNlcyxDTj1TZXJ2aWNl cyxDTj1Db25maWd1cmF0aW9uLERDPW50ZGV2LERDPW1pY3Jvc29mdCxEQz1jb20/Y0FDZXJ0aWZp Y2F0ZT9iYXNlP29iamVjdENsYXNzPWNlcnRpZmljYXRpb25BdXRob3JpdHkwfwYIKwYBBQUHMAKG c2h0dHA6Ly93aGljYXNhcm9vdGNhLm50ZGV2Lm1pY3Jvc29mdC5jb20vQ2VydEVucm9sbC93aGlj YXNhcm9vdGNhLm50ZGV2Lm1pY3Jvc29mdC5jb21fTlRERVYlMjBTQSUyMFJvb3QlMjBDQSgxKS5j cnQwDQYJKoZIhvcNAQEFBQADggEBAMhZCmS2ZzCpdJOV0OXdQHXXklt2Ph7T93XRBSSGwfnUBZRH PpFRk8oEgWGl9sQjs4pTSnZbZuP3j0t2+YUB6Es4ZD/LXl++BlcUGKQ2GAt1oS60c+zcHRoJN3Gl 4DapmN8efogKcYOuE1WExi8TPlnmB9Y37rkg9HXke34za6IWWaQ0pyWN2m7lykVlKCXZ8Vp5jueP fa2BTGGzgjT5wUCJcNjvyQXqzz/pYR5/Xh5fQaCjNd5Xo+1jhvTCsPzm4kKgE+wXFysNSFLX78UL WOuRfjlhHEuHAAtTIUk0ozDrGty4q2U6wgATBOjYw4QumF1jKpEyLUnKwbeJ2NlfZ1YxggKfMIIC mwIBATBZMEsxCzAJBgNVBAYTAlVTMRIwEAYDVQQKEwlNaWNyb3NvZnQxDjAMBgNVBAsTBU50ZGV2 MRgwFgYDVQQDEw9OVERFViBJU1NVRTMgQ0ECChPyYpEAAgAc44UwCQYFKw4DAhoFAKCCAZwwGAYJ KoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMDIwOTExMDAyMzIzWjAjBgkq hkiG9w0BCQQxFgQUmSBpWei9H1POpa+zqCZ1Z2YrbRYwZwYJKoZIhvcNAQkPMVowWDAKBggqhkiG 9w0DBzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwIC ASgwBwYFKw4DAhowCgYIKoZIhvcNAgUwaAYJKwYBBAGCNxAEMVswWTBLMQswCQYDVQQGEwJVUzES MBAGA1UEChMJTWljcm9zb2Z0MQ4wDAYDVQQLEwVOdGRldjEYMBYGA1UEAxMPTlRERVYgSVNTVUUz IENBAgoT8ls+AAIAHOODMGoGCyqGSIb3DQEJEAILMVugWTBLMQswCQYDVQQGEwJVUzESMBAGA1UE ChMJTWljcm9zb2Z0MQ4wDAYDVQQLEwVOdGRldjEYMBYGA1UEAxMPTlRERVYgSVNTVUUzIENBAgoT 8ls+AAIAHOODMA0GCSqGSIb3DQEBAQUABIGAWe4NuNbTCJJtF46yau95zToODldnCgyvRtd1Ai8C PKQpZFLggv5zUywoG/+plILwGIJ+at3xnvPLsVmkZS2YEHlLiQMTE8u7l6b0h0a3Sn6lUJXHGc61 V9rpLJmWzvyNukw9mcBoFYhED6aCXeGNkg/xfc9CXjhdxjgqNI7JMGkAAAAAAAA= ------=_NextPart_000_0033_01C258EE.C3FD18C0-- From owner-ietf-ldup@mail.imc.org Wed Sep 11 10:36:23 2002 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA11221 for ; Wed, 11 Sep 2002 10:36:22 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g8BETA812579 for ietf-ldup-bks; Wed, 11 Sep 2002 07:29:10 -0700 (PDT) Received: from pretender.boolean.net (root@router.boolean.net [198.144.206.49]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g8BET9k12573 for ; Wed, 11 Sep 2002 07:29:09 -0700 (PDT) Received: from nomad.OpenLDAP.org (root@localhost [127.0.0.1]) by pretender.boolean.net (8.12.5/8.12.5) with ESMTP id g8BET5ft043692; Wed, 11 Sep 2002 14:29:05 GMT (envelope-from Kurt@OpenLDAP.org) Message-Id: <5.1.0.14.0.20020911071920.0498ee20@127.0.0.1> X-Sender: kurt@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Wed, 11 Sep 2002 07:28:39 -0700 To: Richard Huber From: "Kurt D. Zeilenga" Subject: Re: LDAPv3 Replication Access Control Design Team Report Cc: ietf-ldup@imc.org In-Reply-To: <3D7E818B.CE209CD5@att.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-ldup@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: At 04:34 PM 2002-09-10, Richard Huber wrote: >If access controls are being used in a directory, the directory administrator has decided that it is important to >control access to all or part of the data in the tree. So if replication is used in a directory that has access >controls, there needs to be a way to make sure that those access controls are not lost because of replication. It not sufficient to just ensure access controls are not lost because of replication. http://www.imc.org/ietf-ldup/mail-archive/msg01261.html >A standard access control mechanism for all LDAP directories is one way to do this. A standard access control mechanism, by itself, is not sufficient. See above article. >But it can also be done by >making sure that the ACM in effect for any given part of the DIT is well defined, and that the definition can be >carried as part of the data being replicated. Likewise, a standard framework for non-standard ACMs, by itself, is not sufficient. Kurt From owner-ietf-ldup@mail.imc.org Wed Sep 11 13:22:58 2002 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA17609 for ; Wed, 11 Sep 2002 13:22:57 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g8BHJBX22691 for ietf-ldup-bks; Wed, 11 Sep 2002 10:19:11 -0700 (PDT) Received: from pretender.boolean.net (root@router.boolean.net [198.144.206.49]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g8BHJAk22687 for ; Wed, 11 Sep 2002 10:19:10 -0700 (PDT) Received: from nomad.OpenLDAP.org (root@localhost [127.0.0.1]) by pretender.boolean.net (8.12.5/8.12.5) with ESMTP id g8BHJCft044484 for ; Wed, 11 Sep 2002 17:19:12 GMT (envelope-from Kurt@OpenLDAP.org) Message-Id: <5.1.0.14.0.20020911095027.04988220@127.0.0.1> X-Sender: kurt@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Wed, 11 Sep 2002 10:18:45 -0700 To: From: "Kurt D. Zeilenga" Subject: LCUP: convergence? In-Reply-To: <001001c258f2$c5f93a10$0400a8c0@D7ST2111> References: <000601c251d7$83e0ee10$0400a8c0@D7ST2111> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-ldup@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: In my analysis of the various possible uses of LCUP, I see a strong requirement for the protocol to provide "eventual convergence" of the synchronized content. However, in reviewing the LCUP I-D (see previously posts for details), I see that it provides for only "lossy convergence". That is, LCUP I-D allows the synchronized content to diverge. It is not clear to me that "lossy convergence" meets the needs of the applications described in the document. What's convergence level(s) are intended to be supported by this protocol? Kurt From owner-ietf-ldup@mail.imc.org Wed Sep 11 16:28:52 2002 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA23648 for ; Wed, 11 Sep 2002 16:28:51 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g8BKNSi02157 for ietf-ldup-bks; Wed, 11 Sep 2002 13:23:28 -0700 (PDT) Received: from e2.ny.us.ibm.com (e2.ny.us.ibm.com [32.97.182.102]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g8BKNQk02153 for ; Wed, 11 Sep 2002 13:23:26 -0700 (PDT) Received: from northrelay02.pok.ibm.com (northrelay02.pok.ibm.com [9.56.224.150]) by e2.ny.us.ibm.com (8.12.2/8.12.2) with ESMTP id g8BKNNIV280886 for ; Wed, 11 Sep 2002 16:23:23 -0400 Received: from d01mlc96.pok.ibm.com (d01mlc96.pok.ibm.com [9.117.250.33]) by northrelay02.pok.ibm.com (8.12.3/NCO/VER6.4) with ESMTP id g8BKNKkn056812 for ; Wed, 11 Sep 2002 16:23:20 -0400 Subject: Re: LCUP: convergence? To: ietf-ldup@imc.org X-Mailer: Lotus Notes Release 5.0.7 March 21, 2001 Message-ID: From: "Timothy Hahn" Date: Wed, 11 Sep 2002 16:20:35 -0400 X-MIMETrack: Serialize by Router on D01MLC96/01/M/IBM(Release 5.0.11 |July 29, 2002) at 09/11/2002 04:23:21 PM MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: owner-ietf-ldup@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Hi all, I agree with Kurt on this. I believe that the LCUP draft needs to clearly state that "eventual convergence" is the goal and show how the protocol can, indeed, be used to get there (through appropriate use of synchronize, or synchronizeAndPersist operations, for example). Right now, it is unclear how to use the protocol to get "eventual convergence" in a client. Also to be covered should be a discussion of when it can be assumed by the client to be "safe" to use only "persistOnly" and still be sure of gaining "eventual convergence". Equally important is a discussion of how clients will know that, with the request that was made, "eventual convergence" cannot be ensured by the server. (so that a client can re-formulate its held data and LCUP request(s). Regards, Tim Hahn Internet: hahnt@us.ibm.com Internal: Timothy Hahn/Durham/IBM@IBMUS phone: 919.224.1565 tie-line: 8/687.1565 fax: 919.224.2540 "Kurt D. Zeilenga" To: Subject: LCUP: convergence? Sent by: owner-ietf-ldup@m ail.imc.org 09/11/2002 01:18 PM In my analysis of the various possible uses of LCUP, I see a strong requirement for the protocol to provide "eventual convergence" of the synchronized content. However, in reviewing the LCUP I-D (see previously posts for details), I see that it provides for only "lossy convergence". That is, LCUP I-D allows the synchronized content to diverge. It is not clear to me that "lossy convergence" meets the needs of the applications described in the document. What's convergence level(s) are intended to be supported by this protocol? Kurt From owner-ietf-ldup@mail.imc.org Wed Sep 11 17:46:48 2002 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA26109 for ; Wed, 11 Sep 2002 17:46:47 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g8BLhGB05703 for ietf-ldup-bks; Wed, 11 Sep 2002 14:43:16 -0700 (PDT) Received: from netscape.com (r2d2.netscape.com [205.217.237.47]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g8BLhFk05699 for ; Wed, 11 Sep 2002 14:43:15 -0700 (PDT) Received: from judge.mcom.com (judge.nscp.aoltw.net [10.169.8.47]) by netscape.com (8.10.0/8.10.0) with ESMTP id g8BKrdu00369 for ; Wed, 11 Sep 2002 13:53:39 -0700 (PDT) Received: from netscape.com ([10.169.192.27]) by judge.mcom.com (Netscape Messaging Server 4.15) with ESMTP id H2AMZI00.ZD4; Wed, 11 Sep 2002 14:42:54 -0700 Message-ID: <3D7FB8EB.6030303@netscape.com> Date: Wed, 11 Sep 2002 17:43:07 -0400 From: mcs@netscape.com (Mark C Smith) Organization: Netscape Communications Corp. User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.1) Gecko/20020823 Netscape/7.0 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Timothy Hahn CC: ietf-ldup@imc.org Subject: Re: LCUP: convergence? References: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-ldup@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit Timothy Hahn wrote: > > Hi all, > > I agree with Kurt on this. > > I believe that the LCUP draft needs to clearly state that "eventual > convergence" is the goal and show how the protocol can, indeed, be used to > get there (through appropriate use of synchronize, or synchronizeAndPersist > operations, for example). Right now, it is unclear how to use the protocol > to get "eventual convergence" in a client. I also agree. This area needs more text and probably protocol changes as well. > Also to be covered should be a discussion of when it can be assumed by the > client to be "safe" to use only "persistOnly" and still be sure of gaining > "eventual convergence". The answer may be "never" but some people do not like that answer ;-) > Equally important is a discussion of how clients will know that, with the > request that was made, "eventual convergence" cannot be ensured by the > server. (so that a client can re-formulate its held data and LCUP > request(s). Agreed. -- Mark Smith Netscape Directory Product Development My words are my own, not my employer's. From owner-ietf-ldup@mail.imc.org Wed Sep 11 17:59:57 2002 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA26384 for ; Wed, 11 Sep 2002 17:59:56 -0400 (EDT) Received: by above.proper.com (8.11.6/8.11.3) id g8BLv2q06613 for ietf-ldup-bks; Wed, 11 Sep 2002 14:57:02 -0700 (PDT) Received: from pretender.boolean.net (root@router.boolean.net [198.144.206.49]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g8BLv1k06607 for ; Wed, 11 Sep 2002 14:57:01 -0700 (PDT) Received: from nomad.OpenLDAP.org (root@localhost [127.0.0.1]) by pretender.boolean.net (8.12.5/8.12.5) with ESMTP id g8BLuxft045396; Wed, 11 Sep 2002 21:56:59 GMT (envelope-from Kurt@OpenLDAP.org) Message-Id: <5.1.0.14.0.20020911145301.028e9d80@127.0.0.1> X-Sender: kurt@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Wed, 11 Sep 2002 14:56:33 -0700 To: mcs@netscape.com (Mark C Smith) From: "Kurt D. Zeilenga" Subject: Re: LCUP: convergence? Cc: Timothy Hahn , ietf-ldup@imc.org In-Reply-To: <3D7FB8EB.6030303@netscape.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-ldup@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: At 02:43 PM 2002-09-11, Mark C Smith wrote: >>Also to be covered should be a discussion of when it can be assumed by the >>client to be "safe" to use only "persistOnly" and still be sure of gaining >>"eventual convergence". > >The answer may be "never" but some people do not like that answer ;-) I think it should be noted that 'persistOnly' is not a synchronization mechanism, but is an change notification mechanism. Kurt From owner-ietf-ldup@mail.imc.org Wed Sep 11 22:14:20 2002 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA00943 for ; Wed, 11 Sep 2002 22:14:19 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g8C2A5V26800 for ietf-ldup-bks; Wed, 11 Sep 2002 19:10:05 -0700 (PDT) Received: from e5.ny.us.ibm.com (e5.ny.us.ibm.com [32.97.182.105]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g8C2A3k26791 for ; Wed, 11 Sep 2002 19:10:03 -0700 (PDT) Received: from northrelay02.pok.ibm.com (northrelay02.pok.ibm.com [9.56.224.150]) by e5.ny.us.ibm.com (8.12.2/8.12.2) with ESMTP id g8C2A1vI007962 for ; Wed, 11 Sep 2002 22:10:01 -0400 Received: from d01mlc96.pok.ibm.com (d01mlc96.pok.ibm.com [9.117.250.33]) by northrelay02.pok.ibm.com (8.12.3/NCO/VER6.4) with ESMTP id g8C29wkn080684 for ; Wed, 11 Sep 2002 22:09:58 -0400 Subject: RE: WG Last Call: LCUP Draft To: ietf-ldup@imc.org X-Mailer: Lotus Notes Release 5.0.7 March 21, 2001 Message-ID: From: "Timothy Hahn" Date: Wed, 11 Sep 2002 22:09:46 -0400 X-MIMETrack: Serialize by Router on D01MLC96/01/M/IBM(Release 5.0.11 |July 29, 2002) at 09/11/2002 10:10:00 PM MIME-Version: 1.0 Content-type: multipart/mixed; Boundary="0__=0ABBE6A1DF98E9EC8f9e8a93df938690918c0ABBE6A1DF98E9EC" Content-Disposition: inline Sender: owner-ietf-ldup@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: --0__=0ABBE6A1DF98E9EC8f9e8a93df938690918c0ABBE6A1DF98E9EC Content-type: text/plain; charset=us-ascii Hi all, I hope this attachment makes it through the mailing list. I am attaching a lcupdraft.zip file containing a single file: draft-ietf-lcup-03.htm. I zipped it to reduce the mail message size. (See attached file: lcupdraft.ZIP) I used HTML mark-ups to embed my comments into the draft (so that they could be viewed in context). Regards, Tim Hahn Internet: hahnt@us.ibm.com Internal: Timothy Hahn/Durham/IBM@IBMUS phone: 919.224.1565 tie-line: 8/687.1565 fax: 919.224.2540 "Chris Apple" lting.net> cc: Sent by: Subject: RE: WG Last Call: LCUP Draft owner-ietf-ldup@m ail.imc.org 09/10/2002 01:51 PM Please respond to capple Thanks for the review and discussion so far. Per the WG Last Call announcement, the period of review will conclude on Tuesday, September 17, 2002 at 1700 ET. After that time, John and I will prepare a comprehensive issues/defects list, review that with the LCUP document editors, and post to the mailing list our findings. I'll post a target date for accomplishing this on Wednesday, September 18, 2002. Chris Apple - Principal Architect DSI Consulting, Inc. mailto:capple@dsi-consulting.net http://www.dsi-consulting.com -----Original Message----- From: owner-ietf-ldup@mail.imc.org [mailto:owner-ietf-ldup@mail.imc.org] On Behalf Of Chris Apple Sent: Sunday, September 01, 2002 12:49 PM To: ietf-ldup@imc.org Cc: John Strassner Subject: WG Last Call: LCUP Draft The purpose of this message is to initiate the LDUP working group last call on the LDAP Client Update Protocol draft. WHAT DOCUMENT? The document in last call is: http://www.ietf.org/internet-drafts/draft-ietf-ldup-lcup-03.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 Tuesday, September 3, 2002 and will Last approximately two weeks. It will end on Tuesday, September 17, 2002 at 1700 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 - Principal Architect DSI Consulting, Inc. mailto:capple@dsi-consulting.net http://www.dsi-consulting.com --0__=0ABBE6A1DF98E9EC8f9e8a93df938690918c0ABBE6A1DF98E9EC Content-type: application/zip; name="lcupdraft.ZIP" Content-Disposition: attachment; filename="lcupdraft.ZIP" Content-Transfer-Encoding: base64 UEsDBBQAAAAIAAOxKy0WpQjwbEgAAEb+AAAbACQAZHJhZnQtaWV0Zi1sZHVwLWxjdXAtMDMuaHRt CgAgAAAAAAABABgAYImCOgFawgGQEIQ6AVrCAaAVMWeQWcIBzL37c9tGtif+O2v/iC5VbUW6S9KW H0nsO5u5jEQnvGNLvnpMbr5Tqdom0SQxBgEOAErmbN2/fH9ZnFf3aQCUlNjfqnXVZGwJaPTj9Hl+ zjl/+ng1/WEw+NOyyGuzKLKi/J9H82znjn74049XPwxu/v3nt+as2GxcXldmvjc36cb8bNf50Lx5 dnr67MXz5y8Gf3oGb9MLg1leuzJ3tTkv7bI2T/lzNTYf3GqV5lXRjDtN0roozeC8WOzgs2/NnxIY apS6ejnKkt12lC2a/zx/Oa4/1z8cGvTD2Fxv0nptBme2dqui3L81H8tiW1QuMde1zRNbJode1n8u XF0t7NaZwVOebv2Brdvl6cLWaZFXzT/L7fgPDSR/Lsfmwtafirt0sf6igfjPr3ZdFF860L+PzUdb ru3mjwz0IV2URVUsa9ydosSt+uIZ7XJngDhpoPCfvj/vzycfzVmWurw2t9vE1g4opS4WRaZfv65t vatMsTT1Oq3MB7cpwq9v4EcJk6xp/m5zI1dhRFfB5gn8Is3NcpdlZlHky6Lc2HzhzD0SajOMbX6x LYu7tEJ6ab517Ra4IafP4V9X785ePH/xrfnb6W9jtaz4S83Hy2bMovyU5is/KZ658w+bab5Kc+dK eArXYKtP5l1RNhM6nk1v3p0MTUqD2WpI02/+KeOuymK3rcbmoqhdM66tcYyi+ULJvzMbu29WVBUm Sau6TOe7um9atgrzhyFoDY8tD3mCGuXOZmlilkVpbPPdz+lmt4EFV+lnHGJT5PW6wkXArObO7PCk k6Ep3TazC/hb83Ixr4rMNT8HZkeLCd/AE4KD3Js63bixmdV0ona7LYttmQLp1IXZVWGXR0YmTe+X bulKB4e+aZ5uXsngs81LixT30W34s/Xa5vDSEewYUE3ziVXpqmp8ZDTdOZOlVQ1rXezKEqivvV2L ZqBmwXaxaN5uVsZHta7r7dtnz+7v78fAWsdFuXoGf3l2miYjO6/q0i7qCpjsOPpM97DM9domxb05 T0u3qIsydb/roxW+PV7Xm4yZ4+B0TFdzwtM4dNESt0zz5mtA1w9d4+P3Z7cfT2gdMMpWfoHHV7s8 aaZYF3D/mnU0U8fBFjRY8/Nqny/WZZGn/+TLWvNAiwLexn2xJuH175sx8W7jza1L58zx+ezmxFTN L4m05BMwRuXKO1cibTafmjuTF3W6TGHT5sWuxm8t1jZfwUILumv83bFmUC/GInTyu+Z3yEF2sPdp TizLb5u6WTi6344lLB83NYX3h/jbZjq0krPRD9c4zevRD2c09a1bwFTpBGj98CSzmsTWlsZclsWG FuL3VLZQLd8/xT/jp/id0sHn6vTOZftxfAU+uT1wlqQyRx9ur2+OhvT/5uIS/341/Y/b2dX0HP5+ /fPk/Xv/F34Cxml+cHn7np+Bv4W3zy4/fJhenOMAzciTX4+IHx5dfryZXV5M3h/BHsMg8T4Do6Ij BSIrtyVyFts84apFmc7pbK7enY1enJ6+wQH+9pfpr79cXp1f/xad7Us+28s7V96l7p5//N8GA9kC oPBH6FoRddWmahjGU7ZQdaBXfJVOJWLNN0Q988xtSFAYmyQlXfnmtYi40nyR7RL3Vq1rZDbFPM1c mBUQ98Y2c2/+Z6zJioXNTDNwMirybN/MbLsX6hrQloRbB+Q2Nr+sYcBiuRxlae6GmoJ2FVMqDSuD 8UBCsTCEy/V7iyLPm29UQpC5q4Erg3yUl9VeVmojmSWHOcrWAvkwj+QRii1cHZs1q3yIAcAGFYtm YHOPC01RBhX5iIeBRY9BjBv32W62mRuiREwzv5jmq50d7tnXBatjTo7UzIviE02g+Wj/gje2ql1J w/E492uXO7zNYUNXDuQS7SpRKJGdfJE3OOjKTC12u828Nk0EDspEi5bXrplDsWo+W+wqYkJIyZUf b2I2rtYMWw08RC0izasadLOhuS92WWK2rkyLpHkEzodHKV1dps3SYBdZOG6aZ/DkmlWiHPQszX9r CAuv6nK3qDXlyQEDYcBs9qQMwOWFCbl0lauldHYmukC54021n5qBXUlHvaBtg/OIhBVM1a8prfwa iIrCRtjcuKx5B3Z5QSRVum1RpTgKqFX3Ng9rKmDPQAw2HztalA7OFV6aF5+PmplVn2QmubuHR6si 56mklQxiE2FgLC/VicE+maOkmdKhgXmQ9til2xR3sLwHuFhe1GbugLbgsNLElS6JGVeYSRBWnZ8F qkTSIgUEdGu1xsTduazYwrcsLRI0UiZGzz2HBkjPJeZv789vP/42hNu/WKthWBQTgSauSlc5bx3f XhRNepXxBpQOxRVzrAyW0KzAZn4GaLqAagvXQ+tHvNZBxAV5vcSMnW2m6uWASIiKealLKtKfUDOz ZZ0udpllKwIVW6btYzdejYfA64DJ+R+D2s7cnnQy+vmJyYvmJ1Uzk8qrKKX7xy4tnTeIwOCScdLc s7/alitX0wzGpn0PYqFFV+7eVmEWQJsoUC1L2rlbFBuwOZBK4CZ4jqnUn+YD++gZ3DxWM5lVLmz+ DZCmcbZK4ZR2221R1qJVeibuPqdVLZadP0J15Nd8vEtn613pvHnojymhAXZptQZ+j4wMaI/NGE+i Y1I90ipQXbVbrGlb1AqTwtG9Eu6EdpkIombtzYq13lyAcFzbbCkzo+0eP+ysmjXfgR3a5Ykr4cQS sy7uRXUx9/jLtb1DxSx8HU4ng4s4aD6mZ1G6zGoRRUeeLg0xnsDo4fKsijRfDZpH5QNzZ46A2jZz YCBHeMrbAhSAFO/p0aIoPqXuCMzXHcrRLBscfLn5vcuysXa4IUMRAoYp0OFUW+Ba84wuK0gMFJPr eIdJu4DtUUTXPETCAJ0IQKWsd8sW0FZ+UwUbBM+fDt/YuyJNKn+R8KyRYTTPjIRHsfFt7Kp0fBdp vRubuOb/63vnctlrnAvcDiKjbZmSwYxf3VVurPagmcUiTZwIOTEp7pG9DUgqeamtpG68BmYSldaV 0SKCOQ9YXvMSKldVuJdgDmx3WXYUSXP8PM1c3T38WLF1JWsysNXVbv533mWbbJrPgeULxg5JOrSj jVFCH7a/LDKzLbJ0ARTo4GgXQfH2n33wwnxIV2tkKKuiQDLPvUMHbkW9BsrJ0k+g5dCqBqiTeDLg qcl0KlcD2yDvz8KCwLDK6pu7we3F5Mf307bSdoy+myyT2x6Z0KxzbmCug2au6yJDxc9mYBrsT6I7 Qdvc/Heg3MquHjdPj3t8wCMz/byF435rzt0Cbxu5DvnPC29mTVA6yQTPZzcP7+wis2W63JsjeOso vrZeervczjN1R0hBWbqyZOmNrkRPNGdw58Aj00yGLwTsM0sBAwKvGWhTlC563jP+V2xHes/ItagN we3q3SwVW/NirVaxgHAZ3130XLTdCOGLp/jF2zwFDoxsr/n7P3bOzBJghMsUGLP/8nkQOy4xud2w M4lob2iqgsxquNKgF5tdXroshV2kAWxl0jAwcQfeKrbrbUWsqm9O6BXxr5vjojS3t7Nz4qProqxP 4FRQoSGFEj6HJhipuMmY9g7GCdNAxg6XjC1qOlXPAWxmbC0eUhHgMDp5JmATEvO/8CcwmW9oUf7f 6mU4tTRfZY4kSjObiTCLKq3I8sxWRZnW6w2uCawkmES+Iqm9U1uyoy1praUSD2rFNyj9J/n3UIhu ixTkI6lSyx2oFmOvYwfPUrTK1hrq/RbMrmaOzXzNrhLRBaP8ePEOpo2+3Ym8cY70uY1oVTwr5sWL 1y/M38Bx3vzlN5NWb+NwwLG5nJ2PborRj27El8El/rfGXEw+TPXeq1+dT6/PzP/q2TE2NfyW6Zem /3E7eT+7+dUsbOVmq7wo3QdbR9Gc618vbib/aU7HL8ffjk/Hr5r/nb76tvnr6evx6YtT+Odr/fjs 4qf309FfJ+9vp48we//xDXwyzVdXu8z9ucM8aeGXo9vr6dXow+X57N3sbAKeLvXV2+vJT9Ng8VwK LZuT5qHBqzHxT2ZCoOSYvwJFwi97PVbom7GGFCK4Y8DjSY6hahgpgd/QBUN7+EEdhfw54XM8FQjQ 0A2hqAWNvSzATQbkNrm+GJ8iIUbUAkPwCG/f/k9zPf2P2+nF2dT8b78v1WLtNs5EsaXL2fnQP0Af VQG9s5vpjbm+uZpd/GTEnchP/5f+No88IjsuJV7cDC2iRIit4qWA7JSF4UfFbUcMkUbDqZFwB8lL Goi66kODblQIlxBlU4CFxlmld6Cl0X7QgLzV/DNaK3OLYmthALCkavkZjeM+k0QWnY61LpBUYHhF H2AHB70Ca0tLHgU/NmQ5JAJUWIV4ZIlCKTx39e6s+QSFcPxE2B/FpgtqwMS4tWQVxtdMprSLTzJD fU4V65x+9+VEQOTzekFsRuwqcbVNM+335XfjQ7eLemczIn5+X1hkdFVoBH9h/FVIq76TGdLR6N+h IcKrAt4O1sfoU17c57yaYfP9LfvgCmL5h+mABhJ6YmdwYtznhdvW4rJhRXGNLhiRlriqfzXp2I3l IuHjgR+Q1tSsgmxeSyHWjjciOHZ5VeylaZZQmTkcpTAgdhvr+cvMt6WrotDL11EzX3o1892uxAgg ckQ+S828aDoYBPXUM3eRyvWSvJxJkrJ6gf6aK1ftMoizg4VEoTNy7p+xVR9YM7mh8PFF8zjrYUCx +Q6mHt4XUe95J/lPQB0L4Q+JsRKznk0uJqyENT/q/wzqPfypLXgPNAbEbudpNUptbkefP1OEUt0Z gIc0Sy125cJV089ru6vgUh/f/Hh+oh0SQDO7PEfi3dUqEPDgn1JGVl+7dotdmdb7v6ZFRixGfS1Q aLWrmMGAp9iC2QYO6qd8VZy34ZuzHEPeTBOkyuA3U/qFEC84psA8aGbhLcOnfJGnPTLzol4/cykH pb3oeNKs8+RZUSomiPYTzEgmGdZzm3tX1jULUVqPElfa/FooSf6EudDnQF7Od3gY4ImKnGdPGKQm q8i7O2nmFHM+Tyv20vmT8HFLZEzAyJwtwTPmyk2aPx3oElRginGDGzIz7jPH954yhDc1ZDbmb2eT i7Pp+9+iS5MVNrki70cSkRREPmqRvuJrAQFE7tv6aRgi5ATkScnAamBbCTzuJJafdgHrXYmcZ9nr XnwScRfs99stl+A8QZNF+RuethztvlA3HeTo8sn3LFJV8W6UeAxALingRJ46UGarui3yvHsq4u5K sFQOGW/1sDh5RbiCCFtxxv4erdVPPLNjbxlczkNTQlEgfiS5gLauLRomXhfgz4l7ScWC6DZdMT1v mmHtSrTcm3AcbPST73GvLE6WXN7wrCiKp8IAh75ALgW8y1XkP0kc3W1xlQC/UgbGowARRUX34ADx N6sNQBky6RPyJKyAXBGINiCWk+bePYP7uyl2BFdBcovlE+i6HE5t5unSu8i3ygehXY98jSoTWWad A9dbFDA4PMjNfuvMMnUZ+cDq9vfkW8wdztTvmASBqR+TniFKxYlXQPEJotHUu9K00QWRtKLymIdK vEtmvq+D/vXj9Mq4fFGQqrv0XmCv9oidKH++llr4yquFfUunhfXbouSgxu31voeL2w/Tq8nN9FyZ rE/gbpcAvZA/x89Phr/n5UmefHQleJ/g5dMnvLylx6Ov4pdfnJj/8q+D1k7aDyLS7mxmZhc305+m V2hXsyntH18oRUmM82DOx5Z3ZHirfRy1AE/gIABq4FhAEPSsZ6kIRg9OBNc30jKMDBEwxT16CuRr CJc9JHZaEUXkEBBEKSTSOlDSL2fX7sPuIjaXyPSUpSdDZDG12RYVxZhCpM9uxPm1sXtw1FcugL14 nh9u39/MPkIAIN24qhlsSYgLD1epxS84AGnoERXzPVmhBI+URWOI1FtIXraA0ltDMG1bFhCeSPPV M1IcEHxqa/tnY2bLZsQha3VrhHkQ+s4l3YBC7xEq2v7/+yAzZ++AH20jCzY6zSF+lzm4GhDCwgCy QDTF0O8oWvx+mHY8kyJAGDyXcBIKvEWZIm61hUCJb+2oVzNrrze47+IF0axBT28vWlEuhQRhmwuK n9Ma/Sh9i33qGsNU1GIHh7jO/zHHgt2K7EtRPBzL38hNRO4G1jVIJ4nlnfcaGQjU7x/gemQmE1ic 9BUwqKd4DT+e31ZBYw7Ep+LpJgaLpcplCBf99bBnTWoyemm/d02vw0C47+QKiCcczXTG4Hs/OzsH DuOZ/D9dWcBBZwR4sTn+JFrBYl14jpjyFn5BTsZAC5eR9yojZZWOfUVVBAY87M9mlzYt1CoTF3MC kJ7VStAhtSM3KCgnGWoWg8gRXa/LYrdaC4ow2bEVqN1KwjSL0uzyOs1ESxL3PWpGn2szL3ags+wp 2FUAxnPINgqBuHi+kXNXgunsKALr0ULMno5S6AyCawdN/IBMY69BdxeIYEy62bgE7I5sL+YFv6xv xjn4clmZD+yHaA98Y6hWM+Xx9LxrqON5CSt5xEeh/R3kd+9zRDxpaQKspBX+0aUNdECimXCvE8bf DPq/WXtdxQaidK1pT35FsgSWzJvicbI8PMajB6/Gr0ktRVb1gF05ywXT4mKW0GNtsBIWzWjg3QZV 5Mjv5ZdEpcu0bpk1Aw2yI1NmCmHg/kEw78XbR3yjFE+UZeLH4gA7XUrNJDw//GpmxWtvVuCcwFwq Ar8CeKgSlftoM8lEd32L0lY6A3rp3FAp6WxUsAW7exi/ioiTaEp0OcSPQ/ecrtj5BeUokKQKT9Bv 0fKf74A+YMHJjj0sbBizsU5A247uioBvHhiurR88l2Qh9mGwOS5qA3v0geairQROiZBaRssGhDHf enVVBUITrl+fjOmXLSRUPK5DOx9SzBFZ7gCej6xZK46L0qITAnECnACVeD8n+e+CXj/51TtZAFNW LCF8H3wJbZbONhJwCp5vj26T5oc9AgPPvY4r5wDNdudOAj8WL6XXPnluVocKVQIKRvq8A6dPP/CO pYOei767wI6Laefu/z/ltzC9U3zIv4Ckxms15sfLy/fTyYXXxHAnzvnGdn4bG+MH7XCZmLbH9WdH oK2ySLu5up0O255qfybwBAXKlehTJ8RMLQksOy8iSD451pAlYCJKUKUXPse3JZwY3ix60ZiyrUB5 spUiv/ZmEUX5OCkiRBLvxOOdUw8NYpd2wCYm/sN46xnoS7lAFT2joTU6ViyxIw6XMjZcbQlF4ZdL 5F09A+hMhZAhWgfS9gv0O488fqCjNR2pIKh3NtbbvB28wucXJs21lUOghgvwTOCmUeYWMKvAvftg SKSfifroE8J6eL7m9+wa9nqQt5D0STOgixng3FbukpAXrSw50G7EMEKlRrSxQYdo/shN0KZgz00A HwqL3O66UL2B7w1UZIy/LSYkfQ5C+Zlb1gfWhbFfbwUisLEyS1sCRC72TjdzXEDiKZxgSxdALTrk gy2XrqT7Z8Pp0jZEs+Gv42cfdoT9XNybrMhXZrOr6hC08PDsIxrd4xeOPuXu/mhAAGs/gxRsrATC qIUBGAXfrwKp5BmeHl7UzAKcYuDf6zeHye/RtuJaYK5BZJ36hyNgw5Ns1Y7fIFIrMEr0bU+UCA2S PpXeIzF4K+FgAByIqM/gtIs/6HV7tieCKhppCPjRlip60EoK8HLwJaUtjW8MR+/QC8dU/eBAQeHX RhfBl8XSI7g0OCl6YsfDr6fif+tV/LYGFe0P3GYAAZEhNz6k4cA4ffGZaKxmjWet37V0HVT8nqTv PKjrSH7Co/rOQV3nwDwfUnhEaXkwbDD4mvet57aZSVavwaXTcoSFeEdae9nqGTTrBQ8u+hB9Dxj1 ItSMQJYHiVhQZuy18ggNzDA4Wqzd4lO12xzBMu9FNjEbgHSDTwdNGV5MRUo+RgNcWUL+1wI3MBka BqrEMWJ+CvPHZENC6H+Ci7mC3ILqBNYEL8Opdd7qdZGcRFix9nXyFAcTpjUGBBGnhdXw6dhJ2UxB UCIee0h1LErvpVYJJBAbYdf/Aw6hjjV53KyXvUjqgNkX1IVQjc1tzp7VyCatHFOxCpUR1yCzVsIC /W4EvMsP8G8pdxACzcr8DW6CSvJ7Hne10k36E9Qk+eR+iAQ/JFr9MAlhnJrSa3xOKtZTgFQpzDMS dRQ3nIL1/tTGIoef8Xcey1srgRg2oC8SWs5jOh0wPakScwTskufEkxk8Phl0noJ/P4BgCbkJIu6o lVCGFkpOKt7c0VesnFPFUDezcWALpNWGEl89+ClKRKbEJoV6o5w/Qb4xqo1docv2DUjzJRVCqVuq YDRKRFVsGbD7pB+bB5mcziZf4PQHbec7re3MGO+SmJs2tmtg2h4JD5kKx4MraDkyWQkS65MKNAgm pJh7Y+8Bb1DnGqR1AM6jpDh8CdKq2rnq9xExm0n4akRUwo4ZuhbQaIJCiy2MkMQIKlnXqa/H8o7h 1lDKs+MNMbDZBK98IFYWUyEyOZuD4sb5tnaOeVYlZ5E3D4Ni0opfoR0He13saswJxYH+sXM7Fy9U hwhBAXb3AZfVfMCmubx8YLrNSxKGh0BeivUjht1QtHBsEQUdGRFKVhxixGIYjg/RNWu4MfgoSHLl dXyE9BY2/31092Hya0RuePbA7+C8bJ4INr0lNzEkHDhXq/pMgL99H6fMvYNaKoM2zExAxbB64mvI w/AWy1YA0CuYp/d2z7exDaKPDB5JVx+rKSzRhTN3qzT3FEJ3A2pGQci6+mSO/+UEGbAEp2G5zVoF E37oHL/hyhr+QFuJmujaAYYNHKxMVytxezNEOY2DNQHzRqF4rt4xjDMGOUt9gawRbgLq7CpX6+vY RN8pNBUUM4J7hUiNLm0wq+n1PLeuAv+5Wf8OVGBIIu0APBdtAGCn+pQ4A3vxf3qotIUFJId9R03z 4UodptfjBHQM+5iUVseb8C9YFIpJqRQrjlVogXvL9iyKLUANIqT6SfRFxcEkcodhGlVpjcZm+Crs iIjTqjOSgJ6PHw6W+pvSPY4uQ+T50rKZjsg9yvV7Fh5MrJgkgh8gbMiPxsFYDwHA+aQtbtBHXGND UUg9QFdWHOa1G7v/Ml6LSULehfrgPYlIxMun2paUYl/ucknECCZS5HJoQ8QPJFR4tbILXAkqV5fY WgxA2VQtONXBzX6AojpUNGjB0eP9uonD9kwJ/bY5/2m+aysQ7bTScFcP5MNo8NfBPJaOaGKsPrqC gqorB0xMNVYLOPxXHZoHXWMvfAcdbHxwadzblG6QJeDfw5R6CYyoIgIl0wqXzUGYEfCwtd1WqsxB YHO2ar4NjwMvGw7k0SNroDQDF5c8BWuoyJMjE3ldm/cxMd3WtdtsKSEtD+HhLvqvBxev1RBKUVRV 6Fq0a4PRRbALzDDMqcgIYrKK5dJgOQm3EnbN4k8pMIp9hvswjh4BhSYpaP9aGTOsZwWjNb5NQ6Vo wTMPHndRRg6NA7bDQ0zF01w7aabYIjVhrLcHUhNQbQhla7/t9ZoH2JnjwF/fex2YTOezT7FQ8ti0 QLPij8/ILmtJ7NKJTWFOUjiJl26fNMvhgcNVIz6OW3qKFFY88wDTfCKzpjRfdh/2pnXpgQCwBq47 3NOgiJhj5eM/GccaQl0As+Ftiwp6BtECVQEDYjvAXR8LUP2y3hPSIa1pgNb7f4aIi0UnC+Oni1y8 A8GPOABzgcqece02YJi+dl8YrVtu5UEr4lAFVV35FOJBMb6kZSI8aB4IQ3tYnW/btxGURBhZJIN/ rz6vBhLV/lF1PsrliWfylLSenpSeQceYOJDdI3jaVPCwmJqn3z8gpaKymnxpPNKG/f6xosRuqqLU YQHBGcDh5AUZHv9KFHqftkASapBeqwXhGSF8R0/ySrkO1KDXvvDRcT/kQ6l0FHtoj0Qwx9a8fP7t YfiuGoeQvABI/0PQXT2SoHjxmQdgu2o2yACj2ewYiIYeCCwYKY4LgX8qQC+IhHu7H5tjRHt8NYP9 +2CwK3WnjlWSDm8JU5W6b8nOlzk3bZjAgYOuxicHreXW8ceGcyDEVrJPpLF8JUP5q9nJX2gmP2Il +zUDhsijh31K0UM4vyEn1LbmyrkEPTcOSmxstnWfG9TGRM4ME0sO1xQ0eczeZtETp10zkufhXeuJ cQ0eMwH7Ey2Vwz8aIYTCfkcYrMXN2peBygegPrPcZUPTwpN3dayDm6B8SDRe+zpgxEcTeivrrHOa T/3yA0B4/X4Ptr81QXNwdl4a95OU3uA+ogL0yxxqHvrc76J8LLmdacK4HOEA3QKaLVUjnP3wAAPh O/L7NPPunnZLCfQwPrWJtKke4OgVllCUsqMHtCYseIT+JIFIDX/468SO6QwLcqHk9cNfx6rX7arP re+3PXR9cHd1wZXi10kp7VHtouBGTFelW9kywZg9gi2cVPGILN57WHeo+jzpd+b5w4+Ah2oY4sUK hNiL8aTMrwi/97BpQ2Ft5EOw3G3p7sDLl+29K0fX4PQ3ib8w0JoOPYYeR5dERkxIRYjP2LcwidD5 tJ5DXs+4eoTsGJAFmeIxRrjwSM0elq3G6efeM6WDDbsA4a5VIpN8ct6AoUpNLe3pALC6B0c6NpeY Ica5sHoqAq8u6Z4pOdMbw7QPMvvfHcAMQZtHpeyBsLomlwck7KNuiYP8VmmSIjKFgakBB1G8Rzkg OrkmAhJ7/6uQcC9L+f0oyu6WclAUy+6bgwaZmh8ZLS0SyyHv8KAhpnzO3V055DJv7W1L/sdyK7Jy F1kzVIW+t4BuN1KrykvDrbNypw4AOnRgoSfn2LS9Fv11UCJYlNeqI9FelK3H+g1u4hVPCgezUAxa RdLrzBnQjeg0ssB9eygMrH08hDgNfp6vY1C+CQalchspkoWa4+A5dp/tAsrgY7EqniVJHjJ4uW5d HHA9jITzYB1tKcaSoreuQKS83IRt/p3T7EoByaNPK/MJnsAc++AMFlcQu6WEV8cBuK48g3qzD105 5E78VtuIxgH+VeBZEfP65Nxh32mHf/Wpm18ebfxKwcYviDX+EQOnw9/64oBPiP11PAWPhgG/VhTw y4KAvQG7PxCue3K07henkJxqgCfH5NiFfQgxVxftDlkRivDxKUcc5Uo8BoIe6g8SeaeHalIUBwAP hYH8m9Ce4oDW1ssIepQQ9fGgy80OqriIQHeV5O0+VbvTIz3Ff3KjywQcNo4f00daEajWve0EoyQA RYQKp8bVPdUnj1segxCXitTeDQlqVdsUk8kCul6rFAy0f0o8Kq2g14YA8GygA81iVUokVeShUAc/ PRzUkicE7d1UjB69K/4Xlc9NOVLIpCMqRN/KiHo1fkMUC04R0FZuUgjkpRsCxw5iJJe4RCt4mr8B hYtMRi+A/xkTQiFXc0PKyJL3LC/yEU8njrMNGTZK7n5X96sMKl33YOmvrpOZGimwfQae+4HWKDG/ ob+AkX/Pi/4W/0CM3hqUCljwydhMoGY00p9KRUAeDWuCuqGyS800n4/bsFxBC2OGK8Vd6Gl4GybT u3eqr8BzZJqsDNw1v7kM05CChMIncae5+AQWAahChYCQv8va6f78wsT71lbaxXpX1qDUmg6m8bHn brAqyAQ+vzgxFhMJhd/2ZJ6OW9NG5x/Rk1/Dk5bQO/s4IUxSKVMR5lqBbIaI2LfkIwp9S37z+YVO 8sVOCRx24fl3Zz6UhM3VzpY2rx37AbABjOp6Bz7tRZ2zA0vNW9ydnuMS61o434Ut2oFKmTeqKTNk dHafjdNpuMMYfx6K0jcPB+OktTdeH6CNaRb0ieO3G18vbalyjHRphyLquSRtcPoOVLX/4jjCV7GO Tp9768jWxSZd6C8S8MNvh6et1jbYJAndvGATfIER7LtIB9ntQkTfw8QS3zeGQcHQsIwYPEEuohrx Ue0q7voTt5ErHaZbD1UbGnLP5xb4RlD+sf8FdObgjnHfVNJWjqDz2CiHl0+9DumXsDHo1SQQGeJz xIpBanSlQIzQchEeAtMCoFmxoNQRTzo8sCLZCbggQ2Oe2K0LxTZ6bz1vgOIOSaeeSc+lqpoBqxBo RT7IvYngZ9hZ6164X89n7zl1uyyKOpBCtZtDodPIpYKyopXlc37hG7PRV6PGbDwKg/qQ9SdxuzEI WS8zqUvAt1BpZjICzE7JEmxSo+RHweoanNGZqpdIDhLUUZqHN6m60nXs1YUkGKWeaf7CwpQdAjL2 rqdp6thco/8aIcO+YzArJc98vGNhS2pCFmztpNXAIC+M3czT1Q7uGN5wvHfER6BiEdT8hb5N3qGr kHY/7k21tqUuF6FL8W0oNT6r023mWnpOjDCAYACWjCxkEPwtCkh/E8dUHOoU2dIsJFSwlXIZ9pS0 abyBV7IXrB9VrXZb0io6ZwUbgDRlyuPmUOFGSSIvgOw8zWTDuLO3h9JJU9nYMRfVxY+awuey5L/v 8kVw7ykS4TGqobhthKxUCjM39FEgQlagQNuEeoUp9XPlTfCl3z13CWKHnhkrNUkN5x/15pTo5tGH JH2e66NEX2OkWXtOUt4uSvZi74ANj0cfZ3Wpf8Shdzr2hUxF70B91O+LrlgK+nynHBCrVpxJuMvt nU0zoN0z/voU6q8rg3rwemxMq+3CO2muOGi12aza3Re95ZXztvmejZy2w01IJQsVKjbN991sy9C/ k3KxuMuG9w1G+TbpxpYp2i4kcJF9YiXwFJKjwZwETiaJo77Hh8qPusFcNb8MBBCWqVtCE9K0Wuwq 3YC8EjBj1F5sEBJVpF81OSNlBO4GieLGlQh+XaqwlBw+Yl6s5L76WTPTUrNE/vKa+5LdUAqTk3Iz bFAYNMQGoWiWlM9Jo7OCOXVGaCVo0IXFqh66vkrcRuxAjQ+ODWrGy663+/WeNlX1taUhyNDy2iY9 X8W+NWyn4RtGQvfzERAMrf2tsmGwj2ggoLj/LkEcEj9qgDfw9UJLGdVmrZS0EKY+ZjGCb8JGXrs6 mgP9VHk41StQzaX1fKvAy9erqXF6quFoIx8z1x9HvJ9ChIYiM0MT1TMOjpWgoUIdkhqx6V7rUUVq jkxUhoxXHlGm756b7T2X4Mud1romUNE2BImD5FFFHVAIUHIfzEUatIsitnEc4B/xqbKRuovBIJ8p 69t5cdGoGXaZlmzW+P7BQGtbJuCXafOnlhRQnK0jGCCowB2c2q69gQ/pCqYgh9tawfFSi11HYFrS lCS+j32ldTMZxO95S+4Q0LAdu9aKP2jv27LYpFj+hAFUpSMWMt+T74nwpcQk1FaJ9hB5MqpuC/m6 XWcpbsses3tCC0M2NLmf7QJmmJHFGjYbahJUwbyrfU9UOiFgrtz+nnq+WriHuBjm9Pw0bA0M4BvJ Qu4BDNFMBNraghqgrEkSLUOwiahqD3VvB6MUp+k+gzanAkdB0UaZQDf9Y3A89QoFfwkflAvdUdqZ e4P4W3yn1mw/QfCU8L60F/DxKiq5qG6fqwSGEdWkJ9g329MuoJPmoajo0Otwyr+uoELeF2VXFUks L6taLg9/sn7KAk6hShXwdw8aUTNQ9P6O26CSOkaBZ5YafS29hoQ3B64HDD0ArVpClVwTDJnGTcZt QSsSnQo8XcWefEp16h0Ge6lBFhelVgfiu6ZJD2iyfbOCyDRxn2Fv5ByaWYFtyh1GsaqIVJ/slFCj wkmgFSUMD/w7lCILqC02SpFJwT1RvYujYQcReqcNl4rucAT06oQ4eorZiokH4K+gFb/kABE51MRf y7JPF9WApzDqYMss7XbPVyqxz2kKdWyoKqOUORAhq6B0kWu2tEzeNjfKV86+ql9843Xkp6JYEtg8 XeV4h1HJ7laQlTwMXbO3p4osbLwYAUla2eSuGRAcUmPzLi2hxtmOau2w98RtLcQKVdmVY+zbqFgl Xr3Qw4fqoXKBV1/7HREZUQiGGLQSYeTE8sxfA9FpKhIU5g2XcDyJetRWIm0BbgIn8qGqnxMnbhYD PuI0pDRQQO29owqUZPFQOiP69xCZGBXYRUeRUlkUhjGUYPPCnRsIR/RLuiXjdVBYt1UByYOcLbsr ljJkASUqyT4odXJH4DUXhVWQOjQx0k25xsh0V9kBRSfWcjq5G+SZlGDf472tYG/rcreoo8WQCK6K TJyVkbUHO+EVomiDpMjoJT1O1mszJguWaD0s8rmWil9SJyxoq2q3IX2GQe4ROVVxnKKHjCiTDupv kJWhigU3X6K/ABnaMq04OvDVjARuGP6a22adw3Qw2OhjjF/C+iSOqvj7QmWx9XAihdLZmBgtLA7E VolYlH02Nsnxu/6rKBkxXEcdHNmFDpUhGOU26EEgMJ7UzAkar4ortuq1BXMRrxh1eQ+JY+QJsHnV 43eVMs+4Sth1nKVUnObu9P63eCQxROs6avrFbHBjPyOIJLSl1II8VqD7Eu1+8Yo2Br1Km4ORBrqo FFlhZ9RQzKTdZiuaj/j84ZXgBI5cP5iZ7axCaeOyxd+8DF5L7wLyGV+Bs4CCxIrw60C7l1CzlEKH f4BObc/ZDCSRa2sxdCr7qMuMND9mYA4xqTRLmmfJBEiStk2D112ecRpuHQZJS/5elA7WjmdVfBcK WfXaZdtKXzcoy6Sqzq/T5s2y+TjoeHepL+HkqZ0+rY1bogb20OyVS6/L/ksHaKw74MldSYCOV7pq 0Ls4r1JSPZnp4VF+y17JM+6GB4mZZyxco1j5Ga9QmuRnWJ/oYNu8+JrEYjkLwMVQM/1h+C8hDw93 C+RKXB5rgTpNAF+BG1e6OnjP/p077Kbwmh8/geTIzfDZ1RSqZzvtq8Z7U7q/S4jpYOUgBTEKzmhu NuQloy/INPa2tVbBlRcF8GS7rQcOtFQpBUn26bPgenz6jrBjBeLJ0WZQgs2cgaCesNl4BvXXS++i TFdQguxQpRpPET/yEsUok/hj1F3Nls4rShiyw6Vz4LtdEC/OdCq5Qqrzvboj8dJZ/LC92co6NXlx vVusuUQ3IaLSYAZJlLPuQXzjCqilJ5f8Zk+QjzUc8ghBZTLiUQevxFgy92I6Is9O1VkRwxsxQavw 6SY4+7mwIJGM8NNvCCZjKntH7l+v8JE1Gznr6pC/T1YAoOB7t0TwVOFjEKLlcwEVFHNaUEgi/WUq bk9CrvaR6AC6UFuMMIXtVhmDouB63sMyvUS1mUaY79WMcN3aQmTAB2nINklKOIF89RgIjnqNtF76 szHnBVI4GCwOK6qwdXTkOeiIlXHclqOBeMdoROmipYGV3quBrCf0zAO01vlFf70GdJZY4gp9UCvJ /a78bmNY5ubsYzsAjF48EoqKyEWnE52e8CN8Dz07Jd+Kt2A884JBPTCdvCwlivKh9n55WViUFHyC 4s+70q5Yab0r0oRPthdNFmH1XFUxQLe21SdOli64nkaaZM5HaXnhmKdQFXDTq69nP7z0QYYtBr4X 6Nq6iVN5aFJ6KmlPgWHyGoUiw22hHDq3SJMWi9ZEmu+EBJaQJL+gmxTlhV/5X/3t6t3ZixevT831 9AwSjMyr8evxy99OQjFNz3U9nHIL2ruHDIAHr1I18YYMbl0yu4cVh0oEgyh9XxXY7nsNa3feOSbS HCmDGR68+fANTgqzL3Z0TeHp0cJuEb/AALdWDmFP22GlLC7AaR/p4rdX76vYUZSGNJHuGVTB+Mbl Vn3ooc24c76pz4z1WBXWEDXYXXtH2VlEPIbDUDKJoW6v5PUUUnY6XZvEJJXlssGG9oyQzzEhC8Cs F63p5DHWOjNJAehirBfe/AtBSSjribEWOdRDDYyWioFS5COX4xssGK8m24m/vxcbBMutbEtX44nH 7Uc1PjOtBtsCHkZuwapQ1XdT+vlwy38cbiJuETgIj6/kb52rBgO8Gp+OT09/O/H9WrQ8xZgzKHCI nwa573d+aPx+ecXWMYW1y2yJc95mKfYFkUHSfNWH8iHnd9XCl61tormAYxfZOYw2gYEpBQdHf5ci Ef1I3VGkHQhZbOrxyHRvYbZls4bgXMOrBIzp9LdxX/XaoHtKD8ciKAC90/Rziafa3Q7GkIhtPEUV slOM/XGSr3arFfokyPm1cHjLwDG8Ku12jRyuIG0Nm4rImk+73WwHCjlNSfaWCt0PtUC2ocGPUtO/ gV3PwFzjTUDHKSLLN662o8cHU/VtmSIsZSZQvnV4UIN6xapv5btjzxhyoBLmGKQZe7k1VFRnsbV8 264Ofkb2GaN5irhCfodqlLfsFcQvQlMg9Ne4MAq+GVUBRUJA1TzWZYThw029J3hQpN9UXoJwU3wR IrIdpNyEmBnu/houxXzfojDpzAnsALQhsOjKjnUXnFqaGYYWiqJyKr3dtyfqtJKlc408lEAj7RZ0 guTEYFW+l9fAleERDZoABnEincZYiIhsfbn1wWJXgwdEN+fXkQ4hX5Tbykm1P4nsKh/uk3gCep3A JkrISsJIKmgi3D6LARWCD8FcYlelguuKaPo63aQI5MCNlNFhIAoBxkRchk5KcJYJ5Yb4tM08XM1h y33fJihYlGQbMH6M8VP8hJII6AuUCwYvgkGuPFBwYQ6lk/huSBwgAziaCxReGleB5IUBLUqyLEXJ XavJSm/sovjkO9T4sgKcy2olRuvT8rC5FQahkyLUPyvMEgJvfO0AvNsJGbO36WD9ZJ2orRCWLE+Q z3TydXgJYbaRk0JVRDDi64Ge6ap05cNzHcQd7A/Pt3eug4NpyQ/LKvYasl0rFKC74EhBQoo+ClgB q2H4izpgHDJCVdI8xvUERwrvi4oAtbZ4IDwBs397Hgrr+nOnjnw/neOt3+Wly1LUDpUh1upmb1m3 ah4FfpS4u3ThiO/+MrmISjwymDK6Tzb3BwE9a0oXkPKhho1nzNRzMz3cgduHwcBUYvUVtyPgFuCa hPqLe0nfkV9/NTP3lTJzKWS0AWwPRNSbAUJUoLMvHCWQvLlBf1f09HBFsZB9bw3V8pegztAXBUaT 8XRMqRdsV3YIwPoQGLmH8uQ+TQhl7FvyE06S7FA5zZ6OqL7HOx4h1jzDKcAVyTJz7AFN8cmLlx4j Hdx9ffBYHi0tf7cFX6JnMOoanQQT8vC2P3HLu2wQt32drta854/pvdAi6psqfufPiJvCg7JmtUsT Eg6Q4v38v6N8+My5+tySY0A6KCo/c1fXVCOYxAGX4HKla6eKfsexE1ItzSzuoNMbRREtVDp76KS3 ZrTLUNpSyhDP+fAD5poForzbm82GKHNIh+WHlgwj0kE0uhlARLBNuYOTtiUJEsxFh52SmJ945veo kazyVmUOnzvpfTZMhFStshoHbCBPnwLGwU8T9x8ic24JgDxOsWjmgog+lBl75ngqTQwyCxaSPEIx NZffpWWRb7jwBCGd8ZGB9g1an96I/kd0FwFk0foCkUHPVUkeMMaVw69KO8O/IvjZHF/d/vWEc88s +pmg58bQND82UZo5gr9siVbb2fUFnQaHvlC1h/fQ4205aYC2HQbS6AiJXgMXChBsybLEPO+9Q9gN LO8kTKLk+QeHOu7FiLy59h8g6uvSIy1SaAgVIjD8tlSCIlQsevxvwm/1uAysYA0M3BFOqgeHsTzU l8KbWO9u7HdajdZKCgCqtJnCweML8OSzThja+ezTnnXcM57OF9sj/YBZLZn9/EpFwFPBK7ImA4Vv xnhIuCUY05M9oy4vm6KilM+yBiqDYpyurNMAQ6Pb89Ycn55IMGuXp//YoUYXn4KvPhBVHhia4xf4 KoerMCAqnKNdENVfWiYZEkvHLzsDsKqhoywRBsjvXzg4hVVW/mnhS9y7DsOQuhViYBuEW5QYNgGP UQ2mJzyT3O7QGIDjChnUxAcuge/xoV69O/MZRuL/5O5cldKSVfUOq41MPFD8crdY786n7EO4ub9M r8+u4k+gJN9FBXnhckJdq97CvGnOFiN6BFpodtyKJ1TmlWK8/mg6DIYfxHa2i7iQZAssZr0LWCVH RaBSjRUWPzCRVGWXjhIRktgi6S1WyJUfQn4MwvhCFpFgTlQ6qCTXDdsfPwAT6PusD0IBevYftLd9 UAKPGACSBmES9xNX5Z49jEBfjrwtj3DvIT3cBLWebyOnvcPWkdyJ/Tjf9DXoJjdvADxJMYoiN50Y DKpEIFA4F7LlkyPvKXVhiG4/K3PLdLUT5/BsScKKUabsppVwjPgUsKC2j0qyNIvuHYlC2hTB/7RT oRhjkBD4iu9GWrZGP7u+aEN4VGqnZ2koqxlHMRebPmE7XCVmpaRdj79uJ6rT1976udE7DEXj2UuH mwObLA5dXdVa8mF9I29vk7SZwcEgUeSqQ80iXHCycYDf4S8q5ORLLXLj/o/C7UmZ9P1Oi6FvcnVo UV4yicDFdFTlAUVh4jh2rDwcQqbEkONwohrrWhbWDjHiO3nArrSGJTcgz1rihky4OA3M1YLB2bjD ebdbe/kqDQ7V0lAaBodA/QcCOxysDvLpjETEA80CO00Bu+HYYSseG8JD+hveb2bbeR2sxvVOgkMa oC/JHQ/jqGsdfYmhePQuubNDFBCyPmupfKRfw1gLhOepJy9vZDdinKru6lSvIU83UvhYdRSf75qn fEKpFJJ4NNyYVnblQUiovdNWjNFmElC8itUegbzaHw0HlghzBJohqpstHPNRgZdnl6f1/ih4JSEX v1kThHeyzGXjwY+7ul2GRn8us7U7GsbhNqoMuS7A5UQt+waVK0mDjcN82BCpLNbpPK0lqgSfVYHA yDWGNCFRXci/iAIEqC6JXkFVHTBHg44Lw5II3Zdg6kK8d6LwwOURn4fWgFoydM3JlsJS+NWTbgwc VSf0tIq/tBv1DgggH67Wq5L8IjVdmSohKA7qY22v22MggWHzk+1WJhOGw6shU8MBKXrXZvnjdp1r H8TyChgpr4gkkdQnc++yjOJc6lV+Uko5e7Sl5EfhrFcp+Kpi1jU4oPfwmg8lomiWkqgi0wow6qN2 IRMigNOwdYfo3jpmp+JgvXG7R2J275hze5HZm4DRXZVgJl1wUVO+nRRV4RA5/8vnLqtl+uoP3STV 3k4lIJq2ZRqCzDT2N5WfxRgPBl0hXCGG3SGts0KAxGKdOtR/ESEaoJW7yseNpEDGZl7VRS5Ziq3B 2DFFmCy7WiEgDp3K/BrJ6V2JFXLobDPJzvVDs6uG8KORRcxWurbssRxjCJsj+oORgeGraI8hUpwz lYngGH9JbJaw93WZbhAzs9gvMifZs2FqoFlVLrvjOJ20M4JU5cRsgL4wBrBEJQPyx1p4rNgwodJR edGtTAIVfwh2ZuK+1+ILj+kYa/BIiNVJAqZOV1orTGqE61NRloDi0/y40iA97QH0uZs2I81m75fn sykSl0GMwwNuQokskeGOvFpYCoKxkUnLAwayLaa0sffYDh6HCEZqAk2I9RRdMU3vJ/Jcp4IxrEN8 w529EeKUbtAlXSncQWcgqnjmNCpvpidbLONCaqJlw0yD+h0y/lDW8vb7sjNMGS4OHqUdUVotbOZI BmiwTUh2eQApGoBp4XGdI4cp3mm7gkSaL8BjC9ziuiXd5aiw9D4F1/WZyUZYcq7qrxKVtnCRvuGB OPNkAP067vfBkoOD7yUW4Jkt0MbP4AUpwODHgnmY6kU1z5tXvpqx+K03Fs+I1IYGkz8tgSnClv69 QD9O80VQNaKZeuMIBXeZEqotoLjZ0Yb88b4oPyknBMAPQPHZpo6gOG3fPNjIzTea8ciMb9aG1SSh CJpFoBn5Y/beAR9LHb+Ak24WhLJ6983YmyogLsKvKFWe7AFEEeSJ+i07UQAWm+28zwdNgmSH9WBU uujQ80oKOZALBUGD+H3xbcXMXRIgQKcE1WCH1QDuQvmZaKd9M7JFkd85lHfCA974kBOVY+6PMs1y NszTeieltlKP7wl+Z4RV4DQETo91iJEVMPSlW4rPo6TWvk5Emreg20HBFiBTxKlCitLv4lWsGob+ cZTkh+y2+cqig+op8iidF3RGb4MADYBeTu07eEgvgnqBSTzNKKlSaTqkFUsBKaj695mjE61stEM1 wLQ/kHMoc9j8LMpOYRcEOOlNqDMunM3jKTi42uWB205FCRmRz1GlgjARohYMmrevctXFkuOdAnCW CF1+PXOrZjobjK9LVUbUZnRV/3beJvDgutiydIjXiJ7JuF0spq52+vPf+L9Xyot7gPRatBVNxYc7 XP+EeiJ0VRzn7Q6LEyrYGRuLRpUvu7Y+/sLHIAkdxE8jeKinnd5LgAxGaqqIMxTzwAF/RogncX7q EFyApd2lXvkKGt+4RzON2lFJhuCawwSxRgqJ4Jnr5Lp9KEpXIJ7BRxYx4x/IduGTYr3im/RgCRVs ECmDRum67RHlwd2h/E8RH94WNfyBgYIsqLPh+mvkpbOhxptgYTt+9v66SP5WdArUUTtfXguug29Y z/z7E+yunYvyPKnabSQ/BAm9lBBH4mqbgkfNfd5mNo96THLxVdR/Tp+TZLogadHM4So4n0gq/e0v 019/ubw6v/4NJdjY/FjaJIdDPvqL24c63ViNKsdIHSxxJv2PBqb9hxuxUHKyu3NZdTSE98yL09M3 Q/MBN+H0zZvv1O0Q9ydO4sPY/GLX2dDcULJ5NYR5/SXNMmeO3oPZfu/QeD/3OlRnFnzdPvLByQzQ w+rVNZpEZxYv4llMxuas2GVzt/jUN6VhPKfOTMIkW3Myx3cvT96aic/Avd7ntf3cMwJIJqTcKqzj RWcdYRlnk4uz6XtchfnL2Px/Ls1cvrIw0/PQKWAqgtBXUD0adj+ORedG/+QhRllit6MFDjD6/Hlc f0bdC3VP8HuWBXoIvnbg5TvSpU9Px3y4n/LiPnPJCqmsig1ydBz5G5tKkQxyy9Zy5w+WixrgfVEG 3welCZGKMN8DFX8y1xvsBPxTUUKx/J+KIhlCYXocgqkEq5wWc/OLy+qNZTkEp3D3sqeKYRGXI+XQ BX6LaFEYEp0jPw7XM1DZdU8FeD3xtFmNy8yk3KR/L8b+nIFbvODt3dXrAgJbE0qA9LziCgIj/kBp p1xdLezW6QLdwLLOinJLVPDm+am5trmZ5HUzqcJcJXzlPtqsMJOsLobmbNI89+rl85ejV2+eP6df f7Bphv23zfXZ5PQ7MzIvmpHwxXWRu7fmf5ya189fm+/efDf67rtvX1B6JJRhfmvKZqKbf8t5buOF tBGG/1xmK2subP2puJM43K92XTSzmOULmvJ3zYewoI+Z3HGbrOtdnu/vLFz3ZrJvXj3//k1rLs2P zMtXb0bfnr5+qedSNN/L/20PnxilzRcWcU/jzh9au1DX/wOb/O3r5+bNy+9GL199951e2GZRHdji f3fLZfPlcm3phx9SgEoUyxpnXKgqIZe5U7/9hVHsVy7ZYF2dXybmzffPX78YffvyTWe/X7w233// YvT98++f62n9vfn4tvn2v21kXJ7c4PQl0fc7KEp2Vmz3lEx8DVCdjbjqj8Ivjs+omTBiJZuVmuti kbp6b47BNOVeClfwaAWVjEGFSlTFPW8h4aUtbV5lobRHMPwWxVZ6kS4hxFatA6QHTVPmIhAWvyMh DuxW9FCEQyJXK0qViIuKAVU1x4FKcJtDxwj8WdXBNXCkt4SSVQBpoVkNFYBHCs4ppx4jX4oM4ULM YIdGyv+pas0UOaLT/ZTC0Up77aDfYu0r+DBvP/gHFi6ku4WcqQGXcPKVcguKalLuD8y86t0yVbum a8emdeWypW6sohVymPy93Q99wfn5nhzPqW7P0J57UepoH6voHXKSg2MvAf+2KFdWmHgoLs3gNo5K o763K0GaiosnAY2rwDiUH0rqKVQtpJIPsqJHxce5/TJaRrGeuh/R48AZBKKbLAyJ7iTKhmQtF4Fr m4K1ZfPVDsv6q+S9r6Y6hGbk03wFpNxy3wsYXArDw/1coQHD1diQ0prfbl29A7d4npDTjYmEIhd3 xafgUOo7YGyRQrht9BLTfVxFPS56uMY67g7M0dnmU+DDgasc+tTjJSCuejS5NrPrI1B8UroJNz9P zeziZnp1Mb0x15dns+nNr2ZycR7/Ynrx0+xiOr2aXfxEE5pc/8W8u7w6m5rz2fXZ+8nsw7WZvH9v fplcXU0ubmbT66GZ/ufHq+n1tbm8MrMPH9/PpufDZsSz97fnMsyPtxS4ez/7MLuZNt+8bD79qwzy azOHyQ1O5PZ6ai7f8Zya736Y+HTZn6dX09mF+WXWfB3Gan4P05ziSFezn36+wRnAv3gWapIwKMqh 6dXZz82PJj/O3s+aDzcvvJvdXMDs38HL5uPk6mZ2dvt+cmU+3l59vLz2FRFPX7FutN1ChOFz8/DI XO82G8ACFktVIVFnaUK6XV34WmfPX74Npw0CCzrzYENG5bAiQHgLoRicUSHaIB4ULmdXl0W+yvYt rzsMSiM+hCcf+D5eurSqCVO94hhbAKKQDeGdaapWdG6W9g542tKXCqFB+nujibXS+uJPRW3K1Kc9 Ybe70DEaEPfQHB9zPTL9k4A95b3ReXezycWEpqHegEghyDTsx6jBQL5ql/EclHNLfMyxDsWecShq 1f+5Dn4vhYqSpC5Ig28ldrQWT/SToNSBIUG4+V5aFBnlNK0Iq0PYbF8JlRD90LIEw58ennQBVAnP V5CG0jOI9dsQCAMQE3FDJkpfDTBso5DE6O7XMGKmAA0ROkBil1miUr9fvKVWaohruCZYAz3/C9Ur 9ioENYxIEwrpg/uJatGDx2offIrs56Qx+h3DyincxTGzJMQaPOfXU6Ey7CwSqMZL3AMHG2sFR7eI IjczwZCXCClioCf8FjgIglxpmJ7nC3jwdnZ+1PrihOgfcQBwvCrJ/FtzdHawwNgRsyooMn/zpcUO vrjeAQ+CyzhQ8uCob92WG/A8ddEqVu9v0BNSWjHzi/B3AAU6cASSydmThRV5b3vS/0wvm/iDa2Tb QDRXE9oO7KqQ7NCd5fjraWXS0fchYfkiEpYRS7hhiRCxBU8KoKV5p5pgoHilWJugbt/ioQ88zZ1+ JmQz+iLVJi6qHD7UZgy+dQ5W1oPnMePBM9U4pyIqDUXgOy+GdP5BAA+bwInxuFRKl54WzVYQfbMb T7K+lKQRiFg0z6fNp0WQoXzFazNSlZt3uzSh+MA9tasJjbbwfEZS5FohP0C94TRWSVDnHJu9LsZt OQXHzM6VFWWM1AA7jqsKAWocnz/hHO4K8Uep1EGICvsc6pCqDRWBu+nkdg9Za5ZK40TAZyxX1ubg 6sh0Hbu5sHyVnZ16+o2rNzKWSr/bim74iTx4bqQyHbF9yeXITNFbY7k17JFwsu26xLpw5ugmhJdg Pyrh3EQZKrYVl+Xz36EGZH9sMmbGxYYolAXVW1XVfUZVxcJNNgTHWxblwZ36lin8YMYu07sU6Pfm teF6hD6yVvmM5VrlFmsu0xqSRokGBm7YGZcqYiDda/3Zz6OvSe1Jr4xRdWleNOt+an8v0ex6u3zF X5hnu3Lu4aSdekWUKK1lnNdPvrjCEY0DdY6+rMbR16ty9HXqHH2lSkc+mN3SsESXpWIcefdkvrhg KEuE+ktKhn550dBgA31R2dAHCocePaFyqOojdEhhOo0UphvUjjFbmFmK7xtRbTNxvtX3BadljODb pElFu48W4uXsnJuJiiKqWmgD2yxKL2K5ygJ5rXgUiNflJtJyh3Gv+joAFoDf4ETGQe2jYV6NX3g4 UuW9C7w8/iA5fqlvoMqb8Zh+Y/7qVemvosy+eB4aTGmORrWW5Ha/ZHHxoNrKxmRoKvzomT+PzjxY GomPGaN46Kobx+AcpGpHHIHwADep/nf7EVzgDlAPC7Ou6+3bZ8+4s0Lq6uW4KFfPUvZ1jjBOXD2j cDGTTvPQKEt22xEOM3r+LcSLwYUlPmzwTySdCWNqpGimxELwEAmpa3sWAykDjF1hJY9oK3D3gjCM B3wOFv25gpGIjXN6zcy+aX7jgf4tXZVvKntmqFCClEuUMSixgVJXwlS9Ah4m3D/Vs8xZ4FG7bYxI gW7ph1wpweqn0mieGL9/KxZiFfIqKMeGRgi55/2lgH2vVUwrWah6OBpOHs4vmjKHbZCx9DgQLXWm vPfgeNPFmZPnhxnVofLjae37o4oxPz4yIz/FAKKqS0zz8ZkpPbMKepefPuHGqHUrWB/LHknfOpnD dvmRPx6tVnKowd15u6bH+UI636H6rwc0OQz29wMp2mR06GaIU5oQUUzAEIc4QI7gd4B20a1hIER7 Dy7su+b9omwRc9CPTs3I6xwP9dZXnetwBGgZp7oBU9cB5KbYeh/VNPIAQgqqJRLYGN8HXpfi8rmh NjfTi9sP06sJRDQ4vxDUF8rwYq7cKRvWW7+KJCsjQOE52YHWBrxA2nVm2mniRGvnlWDpCfYheSU8 agsVCB9l9fn03eT2/Q1PnStI+aRuL5NxnBExFQdhs5zLM+zNtqi5CLNvVxytoccJSTwfRPlWo9ei eZIGjSMcB+b14uRtZFX63gdVwYWOUqQraGili76b0D3L83EBr3ZqEsLlqMzSlj47XtkKBItcOOrE ZiMfgLRhDEh2VNJD2fOgW0Uz6baMjA+efX15H+QPJ7OtmYYD+g6HkThxR2oeoLJX/mN8Sn0s2hsy pAEOTOhhJNh51dSapxneZySxmsHX0cRUq0+6AAnNahG3U4ItARhQtAPCpWKAFCm9uB0a1cKAUgRK HdbS2s2OtK52RCirSvN9+k4LZWWDouuStC7ic3uaQLHaUUxqPB6f16yZnH02dMmR7gNyBQHCIQEi ngqzHkGnIW8Kkzl+NT49aaYkzpjEw6+9P7pY9vFsWQPlwFQYeqUsGSRSrD8b3Kvh+nHKbf+gShDE a0FMVLwgaZuiG5cf+c2t1AWiGZCdQhMEltm5RpRuO3jCn691P7DL1Z+effy/C3K14wIAUEsBAhoA FAAAAAgAA7ErLRalCPBsSAAARv4AABsAAAAAAAAAAQAgAAAAAAAAAGRyYWZ0LWlldGYtbGR1cC1s Y3VwLTAzLmh0bVBLBQYAAAAAAQABAEkAAADJSAAAAAA= --0__=0ABBE6A1DF98E9EC8f9e8a93df938690918c0ABBE6A1DF98E9EC-- From owner-ietf-ldup@mail.imc.org Thu Sep 12 09:00:34 2002 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA21892 for ; Thu, 12 Sep 2002 09:00:34 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g8CCt3G27978 for ietf-ldup-bks; Thu, 12 Sep 2002 05:55:03 -0700 (PDT) Received: from telutil12a.ml.com (telutil12a-v.ml.com [199.43.34.196]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g8CCt1k27974 for ; Thu, 12 Sep 2002 05:55:01 -0700 (PDT) Received: from telutil13a.ml.com (telutil13a [146.125.226.11]) by telutil12a.ml.com (8.11.3/8.11.3/telutil12a-1.2) with ESMTP id g8CCsqv17825; Thu, 12 Sep 2002 08:54:52 -0400 (EDT) Received: from ehudwt01.exchange.ml.com (ehudwt01.exchange.ml.com [199.201.37.22]) by telutil13a.ml.com (8.11.3/8.11.3/telutil13a-1.1) with SMTP id g8CCspf00398; Thu, 12 Sep 2002 08:54:51 -0400 (EDT) Received: from 169.242.226.176 by ehudwt01.exchange.ml.com with ESMTP ( Tumbleweed MMS SMTP Relay (MMS v4.7);); Thu, 12 Sep 2002 08:54:48 -0400 X-Server-Uuid: 3789b954-9c4e-11d3-af68-0008c73b0911 Received: by ehope09.hew.us.ml.com with Internet Mail Service ( 5.5.2653.19) id ; Thu, 12 Sep 2002 08:53:52 -0400 Message-ID: <9B5CBD4986A9D511BE2100065B045DDF04B4C44F@ehope21.hew.us.ml.com> From: "Liben, Michael (GTS)" To: "'Richard Huber'" , ietf-ldup@imc.org Subject: RE: LDAPv3 Replication Access Control Design Team Report Date: Thu, 12 Sep 2002 08:53:49 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) X-WSS-ID: 119E5112210870-01-01 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-ldup@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit Once the directory data is replicated to another administrative authority, that authority owns access control, including its definition. If both replicas are governed by a common authority, then the ACM data can travel as an attribute of the object. -----Original Message----- From: Richard Huber [mailto:rvh@att.com] Sent: Tuesday, September 10, 2002 7:35 PM To: ietf-ldup@imc.org Subject: Re: LDAPv3 Replication Access Control Design Team Report I agree with Tim. If access controls are being used in a directory, the directory administrator has decided that it is important to control access to all or part of the data in the tree. So if replication is used in a directory that has access controls, there needs to be a way to make sure that those access controls are not lost because of replication. A standard access control mechanism for all LDAP directories is one way to do this. But it can also be done by making sure that the ACM in effect for any given part of the DIT is well defined, and that the definition can be carried as part of the data being replicated. So as Kurt noted, the design team did not propose a plan to design the one true access control mechanism. But we do need a replicatable way to express what ACM is in effect at any point in the DIT. Otherwise, administrators will have to choose between reliability (multiple copies via replication) and data security (access controls). If, as discussed by John McMeeking and Kurt, this leads to a general framework for replicating policy information, so much the better. This makes it possible to replicate policy information if the situation so demands. Requiring that LDUP make this possible is not the same as requiring that LDUP make this happen automatically. I agree with Kurt that LDUP should not automatically negotiate what policy data to transfer. But LDUP should make it possible to transfer policy data where needed, and we need the administrative structure to make this doable. I believe that is where the design team proposal is heading. Rick Huber Timothy Hahn wrote: > Kurt, > > My opinions below. > > Regards, > Tim Hahn > > Internet: hahnt@us.ibm.com > Internal: Timothy Hahn/Durham/IBM@IBMUS > phone: 919.224.1565 tie-line: 8/687.1565 > fax: 919.224.2540 > > > "Kurt D. > Zeilenga" To: > > g> Subject: RE: LDAPv3 Replication Access Control Design Team Report > Sent by: > owner-ietf-ldup@m > ail.imc.org > > > 09/10/2002 08:42 > AM > > > > Let's cut to the key question: > > Does LDAP replication REQUIRE a standard LDAP ACM? > > (REQUIRE here in the RFC 2119 sense). > TJH> I believe that LDAP replication MUST ensure that the security > TJH> (i.e. authorization to access - add/modify/search/delete) > TJH> is NOT compromised by the LDAP replication mechanism defined. > TJH> > TJH> Thus, I believe that LDAP replication REQUIRES that access > TJH> control issues be "attended to" (in the RFC 2119 sense). > TJH> > TJH> But I DO NOT feel that LDAP replication needs define a specific > TJH> Access Control Model (ACM). LDAP replication need only ensure > TJH> that SOME ACM can be applied across the servers involved in the > TJH> data replicated amongst them and that LDAP replication doesn't > TJH> "mess that up". > > If the consensus is yes, then we should determine how this > requirement is going to be fulfilled. (I note that the > proposed plan doesn't produce a standard LDAP ACM.) > > If the consensus is no, then we need not determine how an > LDAP ACM will or will not be produced. It simply can remain > out of scope. > > TJH> Unfortunately, I don't believe the answer is as "binary" > TJH> as this. LDAP replication REQUIRES that things be done > TJH> "securely" but it does NOT REQUIRE a specific ACM. > > I see little point is discussing the details of the plan > until we've actually agreed upon requirements... > > Kurt From owner-ietf-ldup@mail.imc.org Thu Sep 12 15:53:03 2002 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA05557 for ; Thu, 12 Sep 2002 15:53:03 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g8CJetD20725 for ietf-ldup-bks; Thu, 12 Sep 2002 12:40:55 -0700 (PDT) Received: from e5.ny.us.ibm.com (e5.ny.us.ibm.com [32.97.182.105]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g8CJerk20721 for ; Thu, 12 Sep 2002 12:40:54 -0700 (PDT) Received: from northrelay04.pok.ibm.com (northrelay04.pok.ibm.com [9.56.224.206]) by e5.ny.us.ibm.com (8.12.2/8.12.2) with ESMTP id g8CJeovI046818 for ; Thu, 12 Sep 2002 15:40:50 -0400 Received: from d01mlc96.pok.ibm.com (d01mlc96.pok.ibm.com [9.117.250.33]) by northrelay04.pok.ibm.com (8.12.3/NCO/VER6.4) with ESMTP id g8CJeksq078938 for ; Thu, 12 Sep 2002 15:40:46 -0400 Subject: Re: LDAPv3 Replication Access Control Design Team Report To: ietf-ldup@imc.org X-Mailer: Lotus Notes Release 5.0.7 March 21, 2001 Message-ID: From: "Timothy Hahn" Date: Thu, 12 Sep 2002 15:32:39 -0400 X-MIMETrack: Serialize by Router on D01MLC96/01/M/IBM(Release 5.0.11 |July 29, 2002) at 09/12/2002 03:40:48 PM MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: owner-ietf-ldup@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Kurt, With respect to your comment: "Likewise, a standard framework for non-standard ACMs, by itself, is not sufficient." I have to ask: Why not? I thought LDUP was about "directory replication". Meaning, that for the information "replicated", the view of the information, when ANY of the servers which are participating in replicating that information, is intended to be the SAME. Furthermore, it is my belief that the IESG will not allow a protocol to be developed which would allow the same information to be distributed/replicated such that "controlled access" to that information could not be guaranteed. I suppose you could counter and say that by sending the information to a "client", a "server" is already unable to guarantee "controlled access". But it seems to me that for "replication", we're clearly talking about LDAP "server"s communicating with one another, with the intent that if a "client" lands on any one of those "replicating" servers, that the results of their query will be the SAME (modulo the "eventual convergence" issues of course). How can such a thing be provided unless the same access control semantics are applied (with respect to the information replicated)? Note here that I did not specify a PARTICULAR access control semantic - only that the replicating servers use the same access control semantic for the bits of information that is replicated. In one example provided it was stated that one server would want to allow "global read" to the information it held as a "replica". Would not the OTHER replica also offer that as well? I would assert YES, it would ... otherwise I wouldn't consider them "replicas", I'd consider them "synchronized". Perhaps I'm splitting hairs at this point. But I see the proposal laid forth as a way to 1) isolate away from LDUP the issues around defining a particular access control model (which is agreed by all to be a "rat hole"), while 2) providing a means for LDUP to show that "replicas" (and employment of replication protocol) is still SECURE (i.e. access to information replicated is "controlled" such that if a client accesses either replica, they will get the same result, for the information requested). Regards, Tim Hahn Internet: hahnt@us.ibm.com Internal: Timothy Hahn/Durham/IBM@IBMUS phone: 919.224.1565 tie-line: 8/687.1565 fax: 919.224.2540 "Kurt D. Zeilenga" To: Richard Huber Subject: Re: LDAPv3 Replication Access Control Design Team Report Sent by: owner-ietf-ldup@m ail.imc.org 09/11/2002 10:28 AM At 04:34 PM 2002-09-10, Richard Huber wrote: >If access controls are being used in a directory, the directory administrator has decided that it is important to >control access to all or part of the data in the tree. So if replication is used in a directory that has access >controls, there needs to be a way to make sure that those access controls are not lost because of replication. It not sufficient to just ensure access controls are not lost because of replication. http://www.imc.org/ietf-ldup/mail-archive/msg01261.html >A standard access control mechanism for all LDAP directories is one way to do this. A standard access control mechanism, by itself, is not sufficient. See above article. >But it can also be done by >making sure that the ACM in effect for any given part of the DIT is well defined, and that the definition can be >carried as part of the data being replicated. Likewise, a standard framework for non-standard ACMs, by itself, is not sufficient. Kurt From owner-ietf-ldup@mail.imc.org Thu Sep 12 18:20:11 2002 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA09913 for ; Thu, 12 Sep 2002 18:20:10 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g8CMElG28349 for ietf-ldup-bks; Thu, 12 Sep 2002 15:14:47 -0700 (PDT) Received: from pretender.boolean.net (root@router.boolean.net [198.144.206.49]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g8CMEjk28343 for ; Thu, 12 Sep 2002 15:14:45 -0700 (PDT) Received: from nomad.OpenLDAP.org (root@localhost [127.0.0.1]) by pretender.boolean.net (8.12.5/8.12.5) with ESMTP id g8CMEhCx003777; Thu, 12 Sep 2002 22:14:48 GMT (envelope-from Kurt@OpenLDAP.org) Message-Id: <5.1.0.14.0.20020912131117.0496dae8@127.0.0.1> X-Sender: kurt@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Thu, 12 Sep 2002 15:14:15 -0700 To: "Timothy Hahn" From: "Kurt D. Zeilenga" Subject: Re: LDAPv3 Replication Access Control Design Team Report Cc: ietf-ldup@imc.org In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-ldup@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: At 12:32 PM 2002-09-12, Timothy Hahn wrote: >With respect to your comment: > >"Likewise, a standard framework for non-standard ACMs, by itself, is not >sufficient." > >I have to ask: Why not? Because, like a standard ACM, any common non-standard ACM would also depend on identity management and other security services. >But it seems to me that for "replication", we're clearly talking about LDAP >"server"s communicating with one another, with the intent that if a >"client" lands on any one of those "replicating" servers, that the results >of their query will be the SAME (modulo the "eventual convergence" issues >of course). That's one of may uses. Another use is replicating information between enterprises under some agreement . This agreement can allow each enterprise to define its own access control policy (for access to the replicated information in that enterprise). Other is where one uses two LCUP to replicating information between an internal-use-only server and a publicly-accessible server. For security reasons, it may be inappropriate to replicate access control information between servers! >How can such a thing be provided unless the same access >control semantics are applied (with respect to the information replicated)? By divorcing itself from those semantics! Kurt From owner-ietf-ldup@mail.imc.org Fri Sep 13 09:32:46 2002 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA04917 for ; Fri, 13 Sep 2002 09:32:46 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g8DDNbe17412 for ietf-ldup-bks; Fri, 13 Sep 2002 06:23:37 -0700 (PDT) Received: from e2.ny.us.ibm.com (e2.ny.us.ibm.com [32.97.182.102]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g8DDNZk17403; Fri, 13 Sep 2002 06:23:35 -0700 (PDT) Received: from northrelay02.pok.ibm.com (northrelay02.pok.ibm.com [9.56.224.150]) by e2.ny.us.ibm.com (8.12.2/8.12.2) with ESMTP id g8DDNUIV271100; Fri, 13 Sep 2002 09:23:30 -0400 Received: from d27ml001.rchland.ibm.com (d27ml001.rchland.ibm.com [9.10.226.142]) by northrelay02.pok.ibm.com (8.12.3/NCO/VER6.4) with ESMTP id g8DDNSog030218; Fri, 13 Sep 2002 09:23:28 -0400 Subject: Re: LDAPv3 Replication Access Control Design Team Report To: "Kurt D. Zeilenga" Cc: ietf-ldup@imc.org, owner-ietf-ldup@mail.imc.org, Timothy Hahn X-Mailer: Lotus Notes Release 5.0.10 March 22, 2002 Message-ID: From: John McMeeking Date: Fri, 13 Sep 2002 08:23:27 -0500 X-MIMETrack: Serialize by Router on d27ml001/27/M/IBM(Build V60_08252002|August 25, 2002) at 09/13/2002 08:23:29 MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII Sender: owner-ietf-ldup@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Kurt, It's been a while since I've dabbled in "necessary and sufficient" ;-) I'll grant that replication of access control attributes (or other policy information) is not "sufficient" to ensure equivalent enforcement of that policy on different servers, though in some cases (perhaps quite common), it will be sufficient. You earlier referenced a note that explained that quite well. Replication of access control information (where the specific scheme has any attributes to replicate) is, however, "necessary." And a few of us think that a standard framework for access control would go a long way towards enabling LDUP to satisfy the necessary conditions that are within the realm of LDUP. We can use that framework to specify which operational attributes should or should not be replicated under given agreements. John McMeeking "Kurt D. Zeilenga" To: Timothy Hahn/Durham/IBM@IBMUS Subject: Re: LDAPv3 Replication Access Control Design Team Report Sent by: owner-ietf-ldup@m ail.imc.org 09/12/2002 05:14 PM At 12:32 PM 2002-09-12, Timothy Hahn wrote: >With respect to your comment: > >"Likewise, a standard framework for non-standard ACMs, by itself, is not >sufficient." > >I have to ask: Why not? Because, like a standard ACM, any common non-standard ACM would also depend on identity management and other security services. >But it seems to me that for "replication", we're clearly talking about LDAP >"server"s communicating with one another, with the intent that if a >"client" lands on any one of those "replicating" servers, that the results >of their query will be the SAME (modulo the "eventual convergence" issues >of course). That's one of may uses. Another use is replicating information between enterprises under some agreement . This agreement can allow each enterprise to define its own access control policy (for access to the replicated information in that enterprise). Other is where one uses two LCUP to replicating information between an internal-use-only server and a publicly-accessible server. For security reasons, it may be inappropriate to replicate access control information between servers! >How can such a thing be provided unless the same access >control semantics are applied (with respect to the information replicated)? By divorcing itself from those semantics! Kurt From owner-ietf-ldup@mail.imc.org Fri Sep 13 10:13:39 2002 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA06421 for ; Fri, 13 Sep 2002 10:13:39 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g8DE8aB20434 for ietf-ldup-bks; Fri, 13 Sep 2002 07:08:36 -0700 (PDT) Received: from pretender.boolean.net (root@router.boolean.net [198.144.206.49]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g8DE8Zk20430 for ; Fri, 13 Sep 2002 07:08:35 -0700 (PDT) Received: from nomad.OpenLDAP.org (root@localhost [127.0.0.1]) by pretender.boolean.net (8.12.5/8.12.5) with ESMTP id g8DE8ZCx009186; Fri, 13 Sep 2002 14:08:35 GMT (envelope-from Kurt@OpenLDAP.org) Message-Id: <5.1.0.14.0.20020913065702.04e09750@127.0.0.1> X-Sender: kurt@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Fri, 13 Sep 2002 07:08:07 -0700 To: John McMeeking From: "Kurt D. Zeilenga" Subject: Re: LDAPv3 Replication Access Control Design Team Report Cc: ietf-ldup@imc.org, Timothy Hahn In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-ldup@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: At 06:23 AM 2002-09-13, John McMeeking wrote: >It's been a while since I've dabbled in "necessary and sufficient" ;-) > >I'll grant that replication of access control attributes (or other policy >information) is not "sufficient" to ensure equivalent enforcement of that >policy on different servers, though in some cases (perhaps quite common), >it will be sufficient. You earlier referenced a note that explained that >quite well. > >Replication of access control information (where the specific scheme has >any attributes to replicate) is, however, "necessary." But is necessary for LDUP to have any understanding that the attributes to replicate hold access control information? Is in not sufficient to provide a means to transfer operational information where the administrator, as stated in the replication agreement, that this information should be transferred? Is not it necessary, for security and other reasons, to not only allow the administrator to control which user application attributes are transferred, but to control which operational attributes are transferred? Why wouldn't these controls be insufficient for controlling the transfer of access control information? Kurt From owner-ietf-ldup@mail.imc.org Fri Sep 13 12:09:16 2002 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA10702 for ; Fri, 13 Sep 2002 12:09:15 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g8DG3MF29101 for ietf-ldup-bks; Fri, 13 Sep 2002 09:03:22 -0700 (PDT) Received: from pretender.boolean.net (root@router.boolean.net [198.144.206.49]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g8DG3Kk29097 for ; Fri, 13 Sep 2002 09:03:20 -0700 (PDT) Received: from nomad.OpenLDAP.org (root@localhost [127.0.0.1]) by pretender.boolean.net (8.12.5/8.12.5) with ESMTP id g8DG3LCx009948 for ; Fri, 13 Sep 2002 16:03:21 GMT (envelope-from Kurt@OpenLDAP.org) Message-Id: <5.1.0.14.0.20020913084535.04dec020@127.0.0.1> X-Sender: kurt@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Fri, 13 Sep 2002 09:02:53 -0700 To: ietf-ldup@imc.org From: "Kurt D. Zeilenga" Subject: Policy Security Consideration (Was: Replicating policy information) In-Reply-To: <5.1.0.14.0.20020910072831.0552af60@127.0.0.1> References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-ldup@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: I note that my statement: In some cases, it may be desirable to share values of policy information. Applies not only to attributes/objects representing access control, collective attributes, subschema, authentication, identity management, etc., it also applies to the attributes/objects representing replication policy. That is, there are cases where it is not desirable to replicate attributes/objects representing replication agreements. For example, where replication of that policy would disclose, or make vulnerable, security sensitive information. Security consideration: As policy often contains confidential or otherwise security sensitive information, LDAP Replication must not require replication of policy information. LDAP Replication should allow each server holding a (complete or fractional) copy of an object to apply local policy. Coordination of policy between servers is a matter left to controlling authorities (e.g., the directory administrator(s)). Kurt At 07:52 AM 2002-09-10, Kurt D. Zeilenga wrote: >John hits on a interesting point, but he limits it to just >access control information. I also disagree with his >conclusion he draws from the point. > >When replicating between heterogeneous servers, each server >will have different operational attributes (as well as entries >which only hold operational information). Some of these >operational attributes are maintained by the server and provide >information to the directory users. Some are maintained by >directory users and are used by the directory server in its >processing. Those of the latter can be viewed as policy >attributes. > >In some cases, it may be desirable to share values of policy >information. In other cases, no. What LDUP needs to ensure >is that replications agreements can express the POLICY for >which policy attributes are to be replicated and which ones are >not to be replicated. Then the authority (or authorities) >establishing the replication agreement will have the means >for ensuring only information appropriate to be replicated >is replicated. > >Hence, LDUP MUST support fractional and partial replication >and LDUP replication agreements must be capable of expressing >the fraction and/or part to be replicated. > >However, I believe it unwise (and insecure) for LDUP to >support negotiate (select) what policy information should be >exchanged between replicas. What to replicate should be >explicit in the replication agreement. > >Kurt > > >At 07:05 AM 2002-09-10, John McMeeking wrote: > >> >> >> >> >> >>I agree with Tim. >> >>I see this as similar to how X.501 separates the general security model >>from a specific access control model. The X.501 security model defines a >>mechanism for identifying the access control schema and its scope of >>control, while its Basic Access Control defines one (of possibly many) >>access control schemes. >> >>I think we need the security model portion. At a minimum it provides a >>basis for determining whether all the servers support a given access >>control scheme. Beyond that, if a server supported multiple access control >>schemes, it provides a framework for specifying which access control scheme >>is used for some area of the DIT, or how servers should behave in the >>presence of differing or identical acces control schemes. >> >>We do not need to specify a specific access control scheme. We need to >>ensure that LDUP makes consistent access control across servers possible, >>possibly specifying that ACI is replicated (if the specific scheme >>represents ACI as operational attributes and/or LDAP objects). I'm sure >>some folks would love it if they could manage access control across a >>hetergenous directory network, but that is a much tougher nut to crack -- >>both from the perspective of agreeing on such a beast, and then getting >>vendors to implement it. >> >>Given the security model pieces, we can then define how LDUP should handle >>ACI information. For example: >>- If the same access control scheme is used on two servers that replicate >>to one another, the attributes and / or LDAP objects that define ACI are >>replicated. >>- If different access control schemes are used -- writeable server(s) use >>same model to control updates, read only servers might allow anonymous >>searches to all data -- LDUP could use this knowledge to not replicate the >>same attributes and / or objects. >> >>The above does not require that we define a specific scheme, only that we >>have a means to identify -- possibly select -- the access control model >>used by various servers for a given area of the DIT, and that a server that >>implements an access control model know how to behave with respect to >>replication of access control information. >> >> >>John McMeeking >>jmcmeek@us.ibm.com >> >> >> >> >> Timothy >> Hahn/Durham/IBM@I To: ietf-ldup@imc.org >> BMUS cc: >> Sent by: owner- Subject: RE: LDAPv3 Replication Access Control Design Team Report >> ietf-ldup@mail. >> imc.org >> >> >> 09/10/2002 08:04 >> AM >> >> >> >> >> >> >> >>Kurt, >> >>My opinions below. >> >>Regards, >>Tim Hahn >> >>Internet: hahnt@us.ibm.com >>Internal: Timothy Hahn/Durham/IBM@IBMUS >>phone: 919.224.1565 tie-line: 8/687.1565 >>fax: 919.224.2540 >> >> >> >> >> "Kurt D. >> >> Zeilenga" To: >consulting.net> >> >org> >> g> Subject: RE: LDAPv3 >>Replication Access Control Design Team Report >> Sent by: >> >> owner-ietf-ldup@m >> >> ail.imc.org >> >> >> >> 09/10/2002 08:42 >> >> AM >> >> >> >> >> >> >> >>Let's cut to the key question: >> >> Does LDAP replication REQUIRE a standard LDAP ACM? >> >>(REQUIRE here in the RFC 2119 sense). >>TJH> I believe that LDAP replication MUST ensure that the security >>TJH> (i.e. authorization to access - add/modify/search/delete) >>TJH> is NOT compromised by the LDAP replication mechanism defined. >>TJH> >>TJH> Thus, I believe that LDAP replication REQUIRES that access >>TJH> control issues be "attended to" (in the RFC 2119 sense). >>TJH> >>TJH> But I DO NOT feel that LDAP replication needs define a specific >>TJH> Access Control Model (ACM). LDAP replication need only ensure >>TJH> that SOME ACM can be applied across the servers involved in the >>TJH> data replicated amongst them and that LDAP replication doesn't >>TJH> "mess that up". >> >>If the consensus is yes, then we should determine how this >>requirement is going to be fulfilled. (I note that the >>proposed plan doesn't produce a standard LDAP ACM.) >> >>If the consensus is no, then we need not determine how an >>LDAP ACM will or will not be produced. It simply can remain >>out of scope. >> >>TJH> Unfortunately, I don't believe the answer is as "binary" >>TJH> as this. LDAP replication REQUIRES that things be done >>TJH> "securely" but it does NOT REQUIRE a specific ACM. >> >>I see little point is discussing the details of the plan >>until we've actually agreed upon requirements... >> >>Kurt From owner-ietf-ldup@mail.imc.org Fri Sep 13 16:41:46 2002 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA18270 for ; Fri, 13 Sep 2002 16:41:45 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g8DKZAG12546 for ietf-ldup-bks; Fri, 13 Sep 2002 13:35:10 -0700 (PDT) Received: from dns.caledonia.net (dns.caledonia.net [207.40.197.238]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g8DKZ9k12541 for ; Fri, 13 Sep 2002 13:35:09 -0700 (PDT) Received: from D7ST2111 (pool-141-158-52-87.phil.east.verizon.net [141.158.52.87]) by dns.caledonia.net; Fri, 13 Sep 2002 14:29:47 -0600 Reply-To: From: "Chris Apple" To: Subject: RE: LDAPv3 Replication Access Control Design Team Report Date: Fri, 13 Sep 2002 16:29:52 -0400 Organization: DSI-Consulting, Inc. Message-ID: <000201c25b64$51426c40$0400a8c0@D7ST2111> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.4024 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Importance: Normal In-Reply-To: Sender: owner-ietf-ldup@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit One comment below. Chris Apple - Principal Architect DSI Consulting, Inc. mailto:capple@dsi-consulting.net http://www.dsi-consulting.com -----Original Message----- From: owner-ietf-ldup@mail.imc.org [mailto:owner-ietf-ldup@mail.imc.org] On Behalf Of Timothy Hahn Sent: Thursday, September 12, 2002 3:33 PM To: ietf-ldup@imc.org Subject: Re: LDAPv3 Replication Access Control Design Team Report Kurt, With respect to your comment: "Likewise, a standard framework for non-standard ACMs, by itself, is not sufficient." I have to ask: Why not? I thought LDUP was about "directory replication". Meaning, that for the information "replicated", the view of the information, when ANY of the servers which are participating in replicating that information, is intended to be the SAME. Furthermore, it is my belief that the IESG will not allow a protocol to be developed which would allow the same information to be distributed/replicated such that "controlled access" to that information could not be guaranteed. CHRIS> Speaking as a Co-Chair, its safe to say that no one can really CHRIS> predict what the IESG might approve outright, approve with conditions, CHRIS> or flat out reject as unsound unless they explicitly document it as CHRIS> "things you must/must not do in a specification." And even if we could CHRIS> issue a prediction based on historical data, the IESG could change its CHRIS> posture over time. CHRIS> CHRIS> So, I think its better to leave those sentiments out of the discussion CHRIS> for now and remain focused on technical issues and associated merits CHRIS> (as the rest of this posting does). I suppose you could counter and say that by sending the information to a "client", a "server" is already unable to guarantee "controlled access". But it seems to me that for "replication", we're clearly talking about LDAP "server"s communicating with one another, with the intent that if a "client" lands on any one of those "replicating" servers, that the results of their query will be the SAME (modulo the "eventual convergence" issues of course). How can such a thing be provided unless the same access control semantics are applied (with respect to the information replicated)? Note here that I did not specify a PARTICULAR access control semantic - only that the replicating servers use the same access control semantic for the bits of information that is replicated. In one example provided it was stated that one server would want to allow "global read" to the information it held as a "replica". Would not the OTHER replica also offer that as well? I would assert YES, it would ... otherwise I wouldn't consider them "replicas", I'd consider them "synchronized". Perhaps I'm splitting hairs at this point. But I see the proposal laid forth as a way to 1) isolate away from LDUP the issues around defining a particular access control model (which is agreed by all to be a "rat hole"), while 2) providing a means for LDUP to show that "replicas" (and employment of replication protocol) is still SECURE (i.e. access to information replicated is "controlled" such that if a client accesses either replica, they will get the same result, for the information requested). CHRIS> Speaking as a technologist, I believe that's the clearest statement CHRIS> I've seen about the intent of the report from the Design Team and CHRIS> why the Design Team members believe their proposal to be a Good Thing. CHRIS> I only wish I'd thought to say it that way when posting the report CHRIS> to the WG... Regards, Tim Hahn Internet: hahnt@us.ibm.com Internal: Timothy Hahn/Durham/IBM@IBMUS phone: 919.224.1565 tie-line: 8/687.1565 fax: 919.224.2540 "Kurt D. Zeilenga" To: Richard Huber Subject: Re: LDAPv3 Replication Access Control Design Team Report Sent by: owner-ietf-ldup@m ail.imc.org 09/11/2002 10:28 AM At 04:34 PM 2002-09-10, Richard Huber wrote: >If access controls are being used in a directory, the directory administrator has decided that it is important to >control access to all or part of the data in the tree. So if replication is used in a directory that has access >controls, there needs to be a way to make sure that those access controls are not lost because of replication. It not sufficient to just ensure access controls are not lost because of replication. http://www.imc.org/ietf-ldup/mail-archive/msg01261.html >A standard access control mechanism for all LDAP directories is one way to do this. A standard access control mechanism, by itself, is not sufficient. See above article. >But it can also be done by >making sure that the ACM in effect for any given part of the DIT is well defined, and that the definition can be >carried as part of the data being replicated. Likewise, a standard framework for non-standard ACMs, by itself, is not sufficient. Kurt From owner-ietf-ldup@mail.imc.org Sat Sep 14 22:01:28 2002 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA17986 for ; Sat, 14 Sep 2002 22:01:28 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g8F1leN09574 for ietf-ldup-bks; Sat, 14 Sep 2002 18:47:40 -0700 (PDT) Received: from pretender.boolean.net (root@router.boolean.net [198.144.206.49]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g8F1ldk09570 for ; Sat, 14 Sep 2002 18:47:39 -0700 (PDT) Received: from nomad.OpenLDAP.org (root@localhost [127.0.0.1]) by pretender.boolean.net (8.12.5/8.12.5) with ESMTP id g8F1lgCx020066 for ; Sun, 15 Sep 2002 01:47:43 GMT (envelope-from Kurt@OpenLDAP.org) Message-Id: <5.1.0.14.0.20020914181722.02902f80@127.0.0.1> X-Sender: kurt@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Sat, 14 Sep 2002 18:47:14 -0700 To: From: "Kurt D. Zeilenga" Subject: LCUP: confusing text: cookies and schemes In-Reply-To: <001001c258f2$c5f93a10$0400a8c0@D7ST2111> References: <000601c251d7$83e0ee10$0400a8c0@D7ST2111> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-ldup@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: I find the wording used in the document quite confusing. Namely because it defines a cookie as represent client state, but is then says it may be sent initially (without value) to indicating the desired scheme. I believe the specification would be a lot clearer if the cookie/scheme were defined as: LCUPScheme ::= LDAPOID LCUPCookie ::= SEQUENCE { scheme LCUPScheme, value OCTET STRING } and request control was defined as: ClientUpdateControlValue ::= SEQUENCE { updateType ENUMERATED { synchronizeOnly (0), synchronizeAndPersist (1), persistOnly (2) }, sendCookieInterval INTEGER OPTIONAL, scheme LCUPScheme OPTIONAL, cookie LCUPCookie OPTIONAL } where scheme may only be specified on initial request to indicate desired scheme and cookie must be provided on subsequent requests. From owner-ietf-ldup@mail.imc.org Sat Sep 14 22:28:30 2002 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA18340 for ; Sat, 14 Sep 2002 22:28:30 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g8F2MYs11660 for ietf-ldup-bks; Sat, 14 Sep 2002 19:22:34 -0700 (PDT) Received: from pretender.boolean.net (root@router.boolean.net [198.144.206.49]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g8F2MXk11653 for ; Sat, 14 Sep 2002 19:22:33 -0700 (PDT) Received: from nomad.OpenLDAP.org (root@localhost [127.0.0.1]) by pretender.boolean.net (8.12.5/8.12.5) with ESMTP id g8F2MbCx020147 for ; Sun, 15 Sep 2002 02:22:37 GMT (envelope-from Kurt@OpenLDAP.org) Message-Id: <5.1.0.14.0.20020914184737.02976fe8@127.0.0.1> X-Sender: kurt@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Sat, 14 Sep 2002 19:22:08 -0700 To: ietf-ldup@imc.org From: "Kurt D. Zeilenga" Subject: LCUP: cookie schemes, why? Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-ldup@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: The document doesn't adequately describe why cookie schemes are necessary... in particular, why would a client ever want to request a particular scheme? How would a client determine which schemes where supported by the server? And, if the server is allowed to support differ schemes in different subtrees, how would a client determine which schemes where supported in which subtrees. From past discussions, the main purpose of the scheme was to facilitate protocol operations in replicated environments. That is, where the client resumes an LCUP session on a different server then that which provided the cookie, the scheme allows the server to determine the cookie format used by the other server. If the doesn't recognize the scheme, it can return an error (or a referral to the servers which do understand the scheme?). I don't see any need to allow the client to request particular cookie schemes. If there is a need for this, then we need to make sure adequate discovery mechanisms are provided so that client can which schemes are supported where (yuk). If there is no reason, I suggest that no means be provided to allow a client to request a particular scheme. If later some need arises, LCUP can be extended. That extension would have to deal with scheme discovery issues. Kurt From owner-ietf-ldup@mail.imc.org Tue Sep 17 16:26:27 2002 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA28813 for ; Tue, 17 Sep 2002 16:26:26 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g8HKAq705218 for ietf-ldup-bks; Tue, 17 Sep 2002 13:10:52 -0700 (PDT) Received: from e6.ny.us.ibm.com (e6.ny.us.ibm.com [32.97.182.106]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g8HKAok05214 for ; Tue, 17 Sep 2002 13:10:51 -0700 (PDT) Received: from northrelay04.pok.ibm.com (northrelay04.pok.ibm.com [9.56.224.206]) by e6.ny.us.ibm.com (8.12.2/8.12.2) with ESMTP id g8HKAglg030728 for ; Tue, 17 Sep 2002 16:10:42 -0400 Received: from smtp.linux.ibm.com (ltc-eth1000.torolab.ibm.com [9.26.4.197]) by northrelay04.pok.ibm.com (8.12.3/NCO/VER6.4) with ESMTP id g8HKAb9h098288; Tue, 17 Sep 2002 16:10:38 -0400 Received: from CORE (unknown [9.2.219.145]) by smtp.linux.ibm.com (Postfix) with SMTP id 730F73FE06; Tue, 17 Sep 2002 16:10:35 -0400 (EDT) Message-ID: <002401c25e86$4ef71740$91db0209@CORE> Reply-To: "Jong" From: "Jong" To: Subject: Some LCUP Issues Date: Tue, 17 Sep 2002 16:10:45 -0400 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0021_01C25E64.C7992C00" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2919.6700 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 Sender: owner-ietf-ldup@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multi-part message in MIME format. ------=_NextPart_000_0021_01C25E64.C7992C00 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi. I'm Jong Choi of IBM Research. Below are the issues I found in the LCUP draft.
It is stated that the server SHOULD send the cookie in the entryUpdate control for every sendCookieInterval=20 number of SearchResultEntry PDUs to the client. It seems not clear whether this applies to synchronize as well as persist. (Below, I assumed RUV (as in section 7) as the cookie.) In the case that RUV is returned to the client periodically during a synchronize session, it may not have much=20 meaning unless the returned entries are sorted=20 (as in size limit case in section 7). Otherwise, upon error during a synchronization session,=20 the next synchronization should restart from the RUV before the failed synchronization not from the last=20 received RUV before error. If this is the case, periodic delivery of cookies during=20 a synchronize section may be meaningless.
The contents of this section seems to be applied to persist scenario = only. The synchronization case need to be considered as well in this = discussion.
> If server resources become tight, the server can terminate one or=20 > more search operations by sending a SearchResultDone message to the=20 > client(s) with a resultCode of lcupResourcesExhausted. Unless the=20 > client sets the updateType field to persistOnly, the server attaches = > a clientUpdateDone control that contains the cookie that corresponds = > to the current state of the client's data. A server set policy is=20 > used to decide which searches to terminate. This can also be used as = > a security mechanism to disconnect clients that are suspected of=20 > malicious actions, but if the server can infer that the client is=20 > malicious, the server should return lcupSecurityViolation instead. Does synchronizeAndPersist become the same as persistOnly after the latter finishes the initial priming ? Hence, we need to distinguish whether a synchronizeAndPersist in the initial mode and in the change notification mode to be able to terminate synchronizeAndPersist in the initial mode only. On the other hand, it may be required for the server to terminate persistOnly or synchronizeAndPersist in the change notification mode. If there are too many persist searches to take care of upon = modification, it may be required to terminate some of them to limit their performance = impact.
> An implementation must make sure that it can correctly update the=20 > client's cookie when there is a size limit imposed on the search=20 > results by either the client's request or by the server's=20 > configuration. If RUV is used as the cookie, entries last modified=20 > by a particular master must be sent to the client in the order of=20 > their last modified CSN. This ordering guarantees that the RUV can=20 > be updated after each entry is sent. It seems that the above paragraph also holds when a time limit is = imposed. A possible issue with the time limit is that the time to sort the result = set may be larger than the time limit itself.=20 The sorting may also be required when we decided to cope with errors = during a synchronization session in such a way that avoids restart from the = pre-session state.
The issue of leftSet change type in the triggered search change type = support needs to be brought out to the general discussion of how to maintain the = convergence.
It is said that an LDUP compliant server can notify the client of the = deletion using the tombstone. It is not clear how this notification is delivered = to the client, whether the deleted entries are automatically delivered to a client as a = part of the resynchronization or the client has to issue separate = resynchronization search to tombstone to get the list of all deleted entries after the = last synchronization time. Because only a small set of required attributes=20 are retained in the tombstone, it may happen that a search specification = cannot=20 match entries in the tombstone using its filter containing non-retained = attributes. In this case, it seems that all the deleted entries after the last = synchronization point should be delivered to the client. LCUP clients needs to request = synchronization at least more frequently than the lifetime of the entries in the = tombstone. It would be helpful for the server to optionally deliver this lifetime value as a = part of control, so that the client may consider this value when deciding the = synchronization interval. ------------------------ Jong Hyuk Choi IBM Thomas J. Watson Research Center - Enterprise Linux Group P. O. Box 218, Yorktown Heights, NY 10598 email: jongchoi@us.ibm.com, jongchoi@OpenLDAP.org (phone) 914-945-3979 (fax) 914-945-4425 TL: 862-3979 ------=_NextPart_000_0021_01C25E64.C7992C00 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hi. I'm Jong Choi of IBM = Research.
Below are the issues I found in the = LCUP=20 draft.
 
<Section 4.4>
It is stated = that the server=20 SHOULD send the cookie
in the entryUpdate control for every=20 sendCookieInterval
number of SearchResultEntry PDUs to the = client.
It=20 seems  not clear whether this applies to synchronize
as well as persist.
(Below, I = assumed RUV (as in=20 section 7) as the cookie.)
In the case that RUV is returned to the = client=20 periodically
during a synchronize session, it may = not have much=20
meaning unless the returned entries are = sorted=20
(as in size limit case in section = 7).
Otherwise,=20 upon error during a synchronization session,
the next synchronization should restart = from
the=20 RUV before the failed synchronization not from the last
received RUV before error.
If this = is the case,=20 periodic delivery of cookies during
a synchronize section may be=20 meaningless.
 
<Section 4.5>
The contents of = this section=20 seems to be applied to persist scenario only.
The synchronization = case need=20 to be considered as well in this discussion.
 
<Section 4.6>
>   = If server=20 resources become tight, the server can terminate one or =
>  =20 more search operations by sending a SearchResultDone message to the=20
>   client(s) with a resultCode of = lcupResourcesExhausted.=20 Unless the
>   client sets the updateType field to = persistOnly,=20 the server attaches
>   a clientUpdateDone control that = contains the cookie that corresponds
>   to the current = state=20 of the client's data. A server set policy is
>   used = to decide=20 which searches to terminate. This can also be used as =
>   a=20 security mechanism to disconnect clients that are suspected of=20
>   malicious actions, but if the server can infer that = the=20 client is
>   malicious, the server should return=20 lcupSecurityViolation instead.
 
Does synchronizeAndPersist become the = same as=20 persistOnly
after the latter finishes the initial = priming=20 ?
Hence, we need to distinguish whether a = synchronizeAndPersist
in the initial mode and in the change = notification=20 mode
to be able to terminate synchronizeAndPersist in the initial = mode=20 only.
 
On the other hand, it may be required = for the=20 server to terminate
persistOnly or synchronizeAndPersist in = the change=20 notification mode.
If there are too many persist searches = to take care=20 of upon modification,
it may be required to terminate some of them to = limit=20 their performance impact.
 
<Section 4.9 and the following = paragraph from=20 Section 7>
>   An implementation must make sure that = it can=20 correctly update the
>   client's cookie when there is = a size=20 limit imposed on the search
>   results by either the = client's=20 request or by the server's
>   configuration. If RUV is = used as=20 the cookie, entries last modified
>   by a particular = master=20 must be sent to the client in the order of
>   their = last=20 modified CSN. This ordering guarantees that the RUV can =
>   be=20 updated after each entry is sent.
 
It seems that the above paragraph also = holds when a=20 time limit is imposed.
A possible issue with the time limit is that = the time=20 to sort the result set
may be larger than the time limit itself. =
The=20 sorting may also be required when we decided to cope with errors = during
a=20 synchronization session in such a way that avoids restart from the = pre-session=20 state.
 
<Section 5.1>
The issue of = leftSet change=20 type in the triggered search change type support
needs to be brought = out to=20 the general discussion of how to maintain the convergence.
 
<Section 7>
It is said that an = LDUP=20 compliant server can notify the client of the deletion
using the tombstone. It is not clear = how this=20 notification is delivered to the client,
whether the deleted entries are = automatically=20 delivered to a client as a part
of the resynchronization or the client = has to issue=20 separate resynchronization
search to tombstone to get the list of = all deleted=20 entries after the last
synchronization time. Because only a = small set of=20 required attributes
are retained in the tombstone, it may happen = that a=20 search specification cannot
match entries in the tombstone using = its filter=20 containing non-retained attributes.
In this case, it seems that all the = deleted entries=20 after the last synchronization
point should be delivered to the = client. LCUP=20 clients needs to request synchronization
at least more frequently than the = lifetime of the=20 entries in the tombstone. It would be
helpful for the server to optionally = deliver this=20 lifetime value as a part of control,
so that the client may consider = this=20 value when deciding the synchronization interval.
------------------------
Jong Hyuk = Choi
IBM=20 Thomas J. Watson Research Center - Enterprise Linux Group
P. O. Box = 218,=20 Yorktown Heights, NY 10598
email: jongchoi@us.ibm.com, jongchoi@OpenLDAP.org
(phone= )=20 914-945-3979    (fax) 914-945-4425   TL:=20 862-3979
------=_NextPart_000_0021_01C25E64.C7992C00-- From owner-ietf-ldup@mail.imc.org Wed Sep 18 18:05:56 2002 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA01772 for ; Wed, 18 Sep 2002 18:05:56 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g8ILx2p17867 for ietf-ldup-bks; Wed, 18 Sep 2002 14:59:02 -0700 (PDT) Received: from dns.caledonia.net (dns.caledonia.net [207.40.197.238]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g8ILwik17861 for ; Wed, 18 Sep 2002 14:58:54 -0700 (PDT) Received: from D7ST2111 (pool-141-158-56-63.phil.east.verizon.net [141.158.56.63]) by dns.caledonia.net; Wed, 18 Sep 2002 15:57:57 -0600 Reply-To: From: "Chris Apple" To: Subject: RE: WG Last Call: LCUP Draft Date: Wed, 18 Sep 2002 17:57:51 -0400 Organization: DSI-Consulting, Inc. Message-ID: <000901c25f5e$713776a0$0400a8c0@D7ST2111> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.4024 Importance: Normal In-Reply-To: <001001c258f2$c5f93a10$0400a8c0@D7ST2111> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Sender: owner-ietf-ldup@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit The WG Last Call Period ended yesterday at 1700 ET. I expect to have an issues list prepared and posted to the list on Friday, September 20, 2002. John and I are expecting to do a subsequent WG Last Call on this document based on the number and Scope of issues raised on the list. This WG Last Call would take place after a subsequent version of the document is published. I'll be looking to the LCUP draft editors to indicate when that is feasible after reviewing the issues list to be posted to the WG Mailing List this Friday. Chris Apple - Principal Architect DSI Consulting, Inc. mailto:capple@dsi-consulting.net http://www.dsi-consulting.com -----Original Message----- From: owner-ietf-ldup@mail.imc.org [mailto:owner-ietf-ldup@mail.imc.org] On Behalf Of Chris Apple Sent: Tuesday, September 10, 2002 1:52 PM To: ietf-ldup@imc.org Subject: RE: WG Last Call: LCUP Draft Thanks for the review and discussion so far. Per the WG Last Call announcement, the period of review will conclude on Tuesday, September 17, 2002 at 1700 ET. After that time, John and I will prepare a comprehensive issues/defects list, review that with the LCUP document editors, and post to the mailing list our findings. I'll post a target date for accomplishing this on Wednesday, September 18, 2002. Chris Apple - Principal Architect DSI Consulting, Inc. mailto:capple@dsi-consulting.net http://www.dsi-consulting.com -----Original Message----- From: owner-ietf-ldup@mail.imc.org [mailto:owner-ietf-ldup@mail.imc.org] On Behalf Of Chris Apple Sent: Sunday, September 01, 2002 12:49 PM To: ietf-ldup@imc.org Cc: John Strassner Subject: WG Last Call: LCUP Draft The purpose of this message is to initiate the LDUP working group last call on the LDAP Client Update Protocol draft. WHAT DOCUMENT? The document in last call is: http://www.ietf.org/internet-drafts/draft-ietf-ldup-lcup-03.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 Tuesday, September 3, 2002 and will Last approximately two weeks. It will end on Tuesday, September 17, 2002 at 1700 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 - Principal Architect DSI Consulting, Inc. mailto:capple@dsi-consulting.net http://www.dsi-consulting.com From owner-ietf-ldup@mail.imc.org Fri Sep 20 02:21:32 2002 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA14197 for ; Fri, 20 Sep 2002 02:21:32 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g8K6Au723774 for ietf-ldup-bks; Thu, 19 Sep 2002 23:10:56 -0700 (PDT) Received: from nexus.adacel.com (shelob.adacel.com.au [203.36.26.146] (may be forged)) by above.proper.com (8.11.6/8.11.3) with SMTP id g8K6Ark23763 for ; Thu, 19 Sep 2002 23:10:53 -0700 (PDT) Received: (qmail 22066 invoked from network); 20 Sep 2002 06:09:07 -0000 Received: from unknown (HELO osmium) (10.32.24.165) by nexus.adacel.com with SMTP; 20 Sep 2002 06:09:07 -0000 Reply-To: From: "Steven Legg" To: Subject: Updated I-Ds for Administration and Access Control Date: Fri, 20 Sep 2002 17:09:56 +1100 Message-ID: <003501c2606c$58b24dd0$a518200a@osmium.mtwav.adacel.com.au> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook 8.5, Build 4.71.2377.0 X-MimeOLE: Produced By Microsoft MimeOLE V4.72.2120.0 Importance: Normal Sender: owner-ietf-ldup@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit Folks, Revisions of my I-Ds on "Access Control Administration in LDAP" (draft-legg-ldap-acm-admin-01.txt) and "Basic and Simplified Access Control in LDAP" (draft-legg-ldap-acm-bac-01.txt) are now available in the usual place. I pulled the general policy administration stuff out of draft-legg-ldap-acm-admin-01.txt and into its own I-D: "Directory Administrative Model in LDAP" (draft-legg-ldap-admin-00.txt). I made some technical changes to the application of permissions to LDAP search operations. See the end of draft-legg-ldap-acm-bac-01.txt for the details. All the other changes are editorial in nature. Regards, Steven From owner-ietf-ldup@mail.imc.org Tue Sep 24 19:37:30 2002 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA15250 for ; Tue, 24 Sep 2002 19:37:30 -0400 (EDT) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id g8ONSlo19055 for ietf-ldup-bks; Tue, 24 Sep 2002 16:28:47 -0700 (PDT) Received: from dns.caledonia.net (dns.caledonia.net [207.40.197.238]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g8ONSjv19050 for ; Tue, 24 Sep 2002 16:28:46 -0700 (PDT) Received: from D7ST2111 (pool-141-151-14-21.phil.east.verizon.net [141.151.14.21]) by dns.caledonia.net; Tue, 24 Sep 2002 17:27:32 -0600 Reply-To: From: "Chris Apple" To: Subject: RE: WG Last Call: LCUP Draft Date: Tue, 24 Sep 2002 19:27:56 -0400 Organization: DSI-Consulting, Inc. Message-ID: <000401c26422$0aafbc30$0300a8c0@D7ST2111> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.4024 In-Reply-To: <000901c25f5e$713776a0$0400a8c0@D7ST2111> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Sender: owner-ietf-ldup@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit Running behind schedule on this. I now expect it will be completed by this Friday or earlier. Chris Apple - Principal Architect DSI Consulting, Inc. mailto:capple@dsi-consulting.net http://www.dsi-consulting.com -----Original Message----- From: owner-ietf-ldup@mail.imc.org [mailto:owner-ietf-ldup@mail.imc.org] On Behalf Of Chris Apple Sent: Wednesday, September 18, 2002 5:58 PM To: ietf-ldup@imc.org Subject: RE: WG Last Call: LCUP Draft The WG Last Call Period ended yesterday at 1700 ET. I expect to have an issues list prepared and posted to the list on Friday, September 20, 2002. John and I are expecting to do a subsequent WG Last Call on this document based on the number and Scope of issues raised on the list. This WG Last Call would take place after a subsequent version of the document is published. I'll be looking to the LCUP draft editors to indicate when that is feasible after reviewing the issues list to be posted to the WG Mailing List this Friday. Chris Apple - Principal Architect DSI Consulting, Inc. mailto:capple@dsi-consulting.net http://www.dsi-consulting.com -----Original Message----- From: owner-ietf-ldup@mail.imc.org [mailto:owner-ietf-ldup@mail.imc.org] On Behalf Of Chris Apple Sent: Tuesday, September 10, 2002 1:52 PM To: ietf-ldup@imc.org Subject: RE: WG Last Call: LCUP Draft Thanks for the review and discussion so far. Per the WG Last Call announcement, the period of review will conclude on Tuesday, September 17, 2002 at 1700 ET. After that time, John and I will prepare a comprehensive issues/defects list, review that with the LCUP document editors, and post to the mailing list our findings. I'll post a target date for accomplishing this on Wednesday, September 18, 2002. Chris Apple - Principal Architect DSI Consulting, Inc. mailto:capple@dsi-consulting.net http://www.dsi-consulting.com -----Original Message----- From: owner-ietf-ldup@mail.imc.org [mailto:owner-ietf-ldup@mail.imc.org] On Behalf Of Chris Apple Sent: Sunday, September 01, 2002 12:49 PM To: ietf-ldup@imc.org Cc: John Strassner Subject: WG Last Call: LCUP Draft The purpose of this message is to initiate the LDUP working group last call on the LDAP Client Update Protocol draft. WHAT DOCUMENT? The document in last call is: http://www.ietf.org/internet-drafts/draft-ietf-ldup-lcup-03.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 Tuesday, September 3, 2002 and will Last approximately two weeks. It will end on Tuesday, September 17, 2002 at 1700 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 - Principal Architect DSI Consulting, Inc. mailto:capple@dsi-consulting.net http://www.dsi-consulting.com