From owner-ietf-ldup@mail.imc.org Mon Feb 5 21:50:12 2001 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id VAA23515 for ; Mon, 5 Feb 2001 21:50:11 -0500 (EST) Received: by ns.secondary.com (8.9.3/8.9.3) id SAA12578 for ietf-ldup-bks; Mon, 5 Feb 2001 18:10:42 -0800 (PST) Received: from sj-msg-core-4.cisco.com (sj-msg-core-4.cisco.com [171.71.163.10]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id SAA12573 for ; Mon, 5 Feb 2001 18:10:40 -0800 (PST) Received: from mira-sjcm-1.cisco.com (mira-sjcm-1.cisco.com [171.69.2.212]) by sj-msg-core-4.cisco.com (8.9.3/8.9.1) with ESMTP id SAA09873; Mon, 5 Feb 2001 18:17:22 -0800 (PST) Received: from jstrassnlap (dhcp-128-107-131-252.cisco.com [128.107.131.252]) by mira-sjcm-1.cisco.com (Mirapoint) with SMTP id AKT21100; Mon, 5 Feb 2001 18:17:18 -0800 (PST) Message-ID: <00d201c08fe3$6a348970$fc836b80@cisco.com> Reply-To: "John Strassner" From: "John Strassner" To: Cc: , "Chris Apple" , =?iso-8859-1?Q?Patrik_F=E4ltstr=F6m?= Subject: WG Last Call on the LDAPv3 Directory Replication I-D Date: Mon, 5 Feb 2001 18:20:46 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-Mimeole: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: owner-ietf-ldup@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit LDUPers, The purpose of this message is to initiate the LDAPEXT working group last call on the LDAPv3 Directory Replication Requirements I-D document. WHAT DOCUMENT? The document in last call is: http://www.ietf.org/internet-drafts/ draft-ietf-ldup-replica-req-06.txt WHAT IS A LAST CALL FOR? The purpose of the working group last call is to ensure that the working group has reached consensus on the document, believes that all the known outstanding issues have been addressed, and is ready to put the document forward for proposed standard status. During the last call, any comments on the documents are collected and discussed on the mailing list. HOW LONG DOES IT LAST? The last call starts today and will last approximately two weeks. It will end on Tuesday, February 20, 2001. 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 informational 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 informational status. 3) Major issues are raised and no consensus is reached on the list. In this case, we slink back and discuss things until consensus is reached, at which time another working group last call will be issued. Assuming we achieve outcome 1) or 2), and that the ADs agree with our assessment, the next stop for the documents is with the IESG. The IESG reads them and may approve the documents (with or without changes), or send the documents back to the working group to have major issues addressed. If the first outcome happens, the documents are put forward for a two-week last call to the entire IETF, and after successful completion the documents are published as RFCs with proposed standard status. If the second outcome happens, we go back and address the issues, putting the documents forward again when we believe they're ready. WHAT SHOULD YOU DO? You should read the documents, making sure that 1) there are no problems or deficiencies or outstanding issues that need to be resolved; and 2) that there are no typos, formatting problems, grammatical errors, etc. Any substantive problems you find, you should send to the list. Any minor problems (typos, etc.) you may send to the list or just to the authors. If, for some reason, you have comments you don't want to send to the entire list, you may send them to me or my co-chair Chris Apple. Silence means consent. Read, enjoy, and send your comments in! regards, John Strassner and Chris Apple From owner-ietf-ldup@mail.imc.org Tue Feb 6 14:33:08 2001 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA29114 for ; Tue, 6 Feb 2001 14:33:07 -0500 (EST) Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id KAA25945 for ietf-ldup-bks; Tue, 6 Feb 2001 10:44:07 -0800 (PST) Received: from DF-INET-1.dogfoodinternet.com (df-inet1.exchange.microsoft.com [131.107.8.8]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id KAA25939 for ; Tue, 6 Feb 2001 10:44:06 -0800 (PST) Received: from yuri.dns.microsoft.com ([172.30.236.11]) by DF-INET-1.dogfoodinternet.com with Microsoft SMTPSVC(5.0.2195.1600); Tue, 6 Feb 2001 10:18:22 -0800 Received: from DF-BOWWOW.platinum.corp.microsoft.com ([172.30.236.100]) by yuri.dns.microsoft.com with Microsoft SMTPSVC(5.0.2195.2532); Tue, 6 Feb 2001 10:19:11 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.0.4638.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: WG Last Call on the LDAPv3 Directory Replication I-D Date: Tue, 6 Feb 2001 10:19:10 -0800 Message-ID: <5B90AD65A9E8934987DB0C8C0762657493DD94@DF-BOWWOW.platinum.corp.microsoft.com> Thread-Topic: WG Last Call on the LDAPv3 Directory Replication I-D Thread-Index: AcCP5HY9fw2/PIuYQC+oULzgUxaapgAgz+xQ From: "Mark Brown (REDMOND)" To: "John Strassner" , Cc: "Chris Apple" , =?iso-8859-1?Q?Patrik_F=E4ltstr=F6m?= X-OriginalArrivalTime: 06 Feb 2001 18:19:11.0833 (UTC) FILETIME=[4DD7D490:01C09069] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ns.secondary.com id KAA25940 Sender: owner-ietf-ldup@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 8bit The LDAPv3 Directory Replication Requirements I-D document does not address the interoperability limits issue that we discussed in December-January. I append the most recent message on the topic. --mark -----Original Message----- From: Mark Brown (REDMOND) Sent: Thursday, January 11, 2001 7:41 PM To: Ellen Stokes; Kurt D. Zeilenga Cc: ietf-ldup@imc.org Subject: RE: interoperability limits: proposed addition to draft-ietf-ldup-replica-req-05.txt Oops, I left off the examples. Let's try again: I suggest inserting the following material right after the first paragraph of Section 3 ("The Models") of the requirements draft (just before the sentence "There are five data consistency models.") --mark * * * * * The objective is limited to replication between directory servers that implement a passive store fully described by its LDAP interface. "Passive store" means that the servers are limited to storing entries that come in via LDAP and retrieving those entries later in response to LDAP requests. The entire semantics of the passive store is defined by its LDAP interface. Any restrictions on what the server can store must be expressed in the server's schema, and any restrictions on the access that clients have to the store must be expressed in terms of a standardized LDAP access control scheme. This is in contrast to an "active store" that implements triggers or other rules that extend the semantics of entries beyond what's implied by LDAP. Replication between such active stores should be specified in extensions to LDUP. Here are some examples of ways in which directory servers implement semantics that go beyond what the LDAP access protocol defines: * Access control. LDAP does not currently define an access control scheme. (The ldapext WG is working to extend LDAP with an access control scheme.) Most directory servers implement an access control scheme. Replication between directory servers with different access control schemes would compromise directory security, so such replication is not supported by LDUP. * Password policy. Some directory servers restrict changes to password attributes, requiring that the new password value conform to a specific security policy (e.g. the value is sufficiently long and complex.) Doing so reduces the security risk associated with passwords that are easy to attack. Replication between directory servers with different password policies (e.g. one server implements a password policy and a second server implements no policy) would compromise directory security, so such replication is not supported by LDUP. * Password hashing. Some directory servers don't store a user's password directly, but instead store one or more secure hashes of the password. Doing so makes it less likely that anyone (even an administrator) can discover the password. Replication between a directory server that stores passwords and a directory server that stores only hashes will compromise directory integrity, causing authentications to fail unexpectedly, so such replication is not supported by LDUP. * * * * * -----Original Message----- From: Mark Brown (REDMOND) Sent: Thursday, January 11, 2001 3:10 PM To: Ellen Stokes; 'Kurt D. Zeilenga' Cc: ietf-ldup@imc.org Subject: RE: interoperability limits: proposed addition to draft-ietf-ldup-replica-req-05.txt We appear to be in total agreement. So I suggest inserting the following paragraph right after the first paragraph of Section 3 ("The Models") of the requirements draft (just before the sentence "There are five data consistency models.") --mark * * * * * The objective is limited to replication between directory servers that implement a passive store fully described by its LDAP interface. "Passive store" means that the servers are limited to storing entries that come in via LDAP and retrieving those entries later in response to LDAP requests. The entire semantics of the passive store is defined by its LDAP interface. Any restrictions on what the server can store must be expressed in the server's schema, and any restrictions on the access that clients have to the store must be expressed in terms of a standardized LDAP access control scheme. This is in contrast to an "active store" that implements triggers or other rules that extend the semantics of entries beyond what's implied by LDAP. Replication between such active stores should be specified in extensions to LDUP. * * * * * --mark -----Original Message----- From: Kurt D. Zeilenga [mailto:Kurt@OpenLDAP.org] Sent: Tuesday, January 09, 2001 4:54 PM To: Mark Brown (REDMOND) Cc: Ellen Stokes; ietf-ldup@imc.org Subject: RE: interoperability limits: proposed addition to draft-ietf-ldup-replica-req-05.txt Mark, Replication in the face of triggers or any other LDAP extension should be specified in extensions to the LDUP. LDUP should assume 'passive' servers as this, I believe, is the LDAP/X.500 data model. That is, servers should not muck with user data. Kurt From owner-ietf-ldup@mail.imc.org Tue Feb 6 16:34:17 2001 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA02642 for ; Tue, 6 Feb 2001 16:34:16 -0500 (EST) Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id MAA03467 for ietf-ldup-bks; Tue, 6 Feb 2001 12:46:23 -0800 (PST) Received: from ckmso1.proxy.att.com (ckmso1.att.com [12.20.58.69]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id MAA03445 for ; Tue, 6 Feb 2001 12:45:44 -0800 (PST) Received: from qsun.mt.att.com ([135.16.157.16]) by ckmso1.proxy.att.com (AT&T IPNS/MSO-3.0) with SMTP id f16KqE120715; Tue, 6 Feb 2001 15:52:14 -0500 (EST) Received: by qsun.mt.att.com (SMI-8.6/ATTEMS-1.4.1 sol2) id PAA28930; Tue, 6 Feb 2001 15:52:13 -0500 Date: Tue, 6 Feb 2001 15:52:13 -0500 Message-Id: <200102062052.PAA28930@qsun.mt.att.com> From: rvh@qsun.mt.att.com (Richard V Huber) To: ietf-ldup@imc.org, johns@cisco.com, mabrown@Exchange.MICROSOFT.com Subject: RE: WG Last Call on the LDAPv3 Directory Replication I-D Cc: capple@ecal.com, paf@cisco.com, rmoats@coreon.com, rweiser@digsigtrust.com, stokes@austin.ibm.com Sender: owner-ietf-ldup@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: We addressed these issues in version -06, though we cut down the text. Here is the summary that was included when I sent version -06 to the list. I haven't seen any comments on it since it was posted. : Internet Drafts Editor - : : Please publish the draft below as draft-ietf-ldup-replica-req-06.txt : It replaces the -05 draft from November. : : LDUP Mailing list - : : The attached version of the draft incorporates changes to address the : comments from San Diego. We trimmed Mark's proposed changes since we : were concerned that they went into too much detail that wasn't really : LDUP related. : : Our specific changes are: : : Insert the following as the last paragraph in Section 3: : : Interoperability of replicas between directory servers may be limited : by servers that implement semantics that go beyond what the LDAP : access protocol defines. Examples (not an exhaustive list) of such : semantics include: (1) replication among directory servers with : different access control systems/semantics may compromise directory : security, and (2) replication among directory servers with different : application trigger semantics may compromise directory data : integrity. : : Add the following at the end of the Security Considerations Section: : : As noted in Section 3, security may be impacted when replicating : among servers that implement non-standard extensions to basic LDAP : semantics. Access control is one common case which affects security; : work to address this issue is documented in RFC 2820 [RFC2820]. : : Add the new reference to the References: : : [RFC2820] E. Stokes, D. Byrne, B. Blakley, P. Behera, "Access : Control Requirements for LDAP", RFC 2820, May 2000. : : Change the draft number and the publication and expiration dates. : : As always, please send comments to the list. Rick Huber --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- : Subject: RE: WG Last Call on the LDAPv3 Directory Replication I-D : Thread-Topic: WG Last Call on the LDAPv3 Directory Replication I-D : Thread-Index: AcCP5HY9fw2/PIuYQC+oULzgUxaapgAgz+xQ : From: "Mark Brown (REDMOND)" : To: "John Strassner" , : Cc: "Chris Apple" , : =?iso-8859-1?Q?Patrik_F=E4ltstr=F6m?= : Sender: owner-ietf-ldup@mail.imc.org : : The LDAPv3 Directory Replication Requirements I-D document does : not address the interoperability limits issue that we discussed : in December-January. : : I append the most recent message on the topic. : : --mark : : -----Original Message----- : From: Mark Brown (REDMOND) : Sent: Thursday, January 11, 2001 7:41 PM : To: Ellen Stokes; Kurt D. Zeilenga : Cc: ietf-ldup@imc.org : Subject: RE: interoperability limits: proposed addition to : draft-ietf-ldup-replica-req-05.txt : : Oops, I left off the examples. Let's try again: : : I suggest inserting the following material right after : the first paragraph of Section 3 ("The Models") of the : requirements draft (just before the sentence "There are five : data consistency models.") : : --mark : : * * * * * : : The objective is limited to replication between directory servers : that implement a passive store fully described by its LDAP : interface. "Passive store" means that the servers are limited to : storing entries that come in via LDAP and retrieving those entries : later in response to LDAP requests. The entire semantics of : the passive store is defined by its LDAP interface. Any : restrictions on what the server can store must be : expressed in the server's schema, and any restrictions on the : access that clients have to the store must be expressed in terms : of a standardized LDAP access control scheme. This is in : contrast to an "active store" that implements triggers : or other rules that extend the semantics of entries beyond : what's implied by LDAP. Replication between such active : stores should be specified in extensions to LDUP. : : Here are some examples of ways in which directory servers : implement semantics that go beyond what the LDAP access : protocol defines: : : * Access control. LDAP does not currently define an access : control scheme. (The ldapext WG is working to extend LDAP : with an access control scheme.) Most directory servers : implement an access control scheme. : : Replication between directory servers with different : access control schemes would compromise directory security, : so such replication is not supported by LDUP. : : * Password policy. Some directory servers restrict changes : to password attributes, requiring that the new password : value conform to a specific security policy (e.g. the value : is sufficiently long and complex.) Doing so reduces the : security risk associated with passwords that are easy to : attack. : : Replication between directory servers with different : password policies (e.g. one server implements a password : policy and a second server implements no policy) would : compromise directory security, so such replication is not : supported by LDUP. : : * Password hashing. Some directory servers don't store a user's : password directly, but instead store one or more secure : hashes of the password. Doing so makes it less likely that : anyone (even an administrator) can discover the password. : : Replication between a directory server that stores passwords : and a directory server that stores only hashes will compromise : directory integrity, causing authentications to fail : unexpectedly, so such replication is not supported by LDUP. : : * * * * * : : -----Original Message----- : From: Mark Brown (REDMOND) : Sent: Thursday, January 11, 2001 3:10 PM : To: Ellen Stokes; 'Kurt D. Zeilenga' : Cc: ietf-ldup@imc.org : Subject: RE: interoperability limits: proposed addition to : draft-ietf-ldup-replica-req-05.txt : : : We appear to be in total agreement. : : So I suggest inserting the following paragraph right after : the first paragraph of Section 3 ("The Models") of the : requirements draft (just before the sentence "There are five : data consistency models.") : : --mark : : * * * * * : : The objective is limited to replication between directory servers : that implement a passive store fully described by its LDAP : interface. "Passive store" means that the servers are limited to : storing entries that come in via LDAP and retrieving those entries : later in response to LDAP requests. The entire semantics of : the passive store is defined by its LDAP interface. Any : restrictions on what the server can store must be : expressed in the server's schema, and any restrictions on the : access that clients have to the store must be expressed in terms : of a standardized LDAP access control scheme. This is in : contrast to an "active store" that implements triggers : or other rules that extend the semantics of entries beyond : what's implied by LDAP. Replication between such active : stores should be specified in extensions to LDUP. : : * * * * * : : --mark : : -----Original Message----- : From: Kurt D. Zeilenga [mailto:Kurt@OpenLDAP.org] : Sent: Tuesday, January 09, 2001 4:54 PM : To: Mark Brown (REDMOND) : Cc: Ellen Stokes; ietf-ldup@imc.org : Subject: RE: interoperability limits: proposed addition to : draft-ietf-ldup-replica-req-05.txt : : : Mark, : : Replication in the face of triggers or any other LDAP extension : should be specified in extensions to the LDUP. : : LDUP should assume 'passive' servers as this, I believe, is the : LDAP/X.500 data model. That is, servers should not muck with : user data. : : Kurt From owner-ietf-ldup@mail.imc.org Fri Feb 9 16:06:59 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA01901 for ; Fri, 9 Feb 2001 16:06:59 -0500 (EST) Received: by above.proper.com (8.9.3/8.9.3) id MAA29984 for ietf-ldup-bks; Fri, 9 Feb 2001 12:08:09 -0800 (PST) Received: from sj-msg-core-1.cisco.com (sj-msg-core-1.cisco.com [171.71.163.11]) by above.proper.com (8.9.3/8.9.3) with ESMTP id MAA29980 for ; Fri, 9 Feb 2001 12:08:08 -0800 (PST) Received: from mira-sjcm-1.cisco.com (mira-sjcm-1.cisco.com [171.69.2.212]) by sj-msg-core-1.cisco.com (8.9.3/8.9.1) with ESMTP id MAA02162 for ; Fri, 9 Feb 2001 12:08:00 -0800 (PST) Received: from JSTRASSN-W2K1.cisco.com ([171.69.108.130]) by mira-sjcm-1.cisco.com (Mirapoint) with ESMTP id AKY17169; Fri, 9 Feb 2001 12:07:28 -0800 (PST) Message-Id: <4.3.2.7.2.20010209085053.00b6bf08@mira-sjcm-1.cisco.com> X-Sender: jstrassn@mira-sjcm-1.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Fri, 09 Feb 2001 09:11:18 -0800 To: ietf-ldup@imc.org From: John Strassner Subject: Deadline warning! Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ietf-ldup@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Hello to all current and prospective LDUP I-D authors, The deadline for new draft submissions for the Minneapolis meeting is 23 February at 5pm EST. I would note that we agreed that the following NEW drafts are on the docket for this meeting: Mar 01 Submit I-D on LDAPv3 Mandatory Replica Management. Mar 01 Submit I-D on LDAPv3 Multi-Master Replication Profile. Mar 01 Submit I-D on LDAPv3 Master-Slave Replication Profile. Existing drafts must be submitted by March 2. Please note, however, that the IETF does the bulk of its work via email discussions. Note, as well, that the IETF meetings are not for technology presentations but rather for face time to resolve outstanding issues. Not that anyone has done such a presentation in LDUP so far, but there is something to be said for paranoia. ;-) What should be inferred from this is that the meeting deadlines should probably not be regarded as having some necessary relationship to progression of the deliverables. For those who have material that they feel needs attention in Minneapolis, it would be useful to get your drafts in early enough for us to be able to get a handle on what the outstanding issues are in advance of the meeting. thanks and kind regards, John + Chris From owner-ietf-ldup@mail.imc.org Sat Feb 10 12:57:06 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA26892 for ; Sat, 10 Feb 2001 12:57:05 -0500 (EST) Received: by above.proper.com (8.9.3/8.9.3) id JAA13713 for ietf-ldup-bks; Sat, 10 Feb 2001 09:24:55 -0800 (PST) Received: from gate1.ewag.kamenz.de (netgate-ewag.heitech.net [212.185.189.86] (may be forged)) by above.proper.com (8.9.3/8.9.3) with SMTP id JAA13709 for ; Sat, 10 Feb 2001 09:24:53 -0800 (PST) From: bigjoe@japan.com Received: (qmail 11039 invoked from network); 8 Feb 2001 22:50:04 -0000 Received: from 1cust219.tnt3.irving2.tx.da.uu.net (HELO 1Cust219.tnt3.irving2.tx.da.uu.net??63.24.178.219?) (63.24.178.219) by netgate-ewag.heitech.net with SMTP; 8 Feb 2001 22:50:04 -0000 Received: from middletown.total.net by 1Cust219.tnt3.irving2.tx.da.uu.net with ESMTP; Thu, 08 Feb 2001 15:50:05 -0600 Message-ID: <000008e40401$0000190c$00005f99@middletown.total.net> To: Subject: Brand New E-Mail pager for FR-EE! 24473 Date: Thu, 08 Feb 2001 15:49:58 -0600 MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal Reply-To: bigjoe@japan.com Sender: owner-ietf-ldup@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit No long term contract No activation fee No big prepayment of airtime No credit check PAGING AMERICA is going to give you absolutely Free the Brand new Motorola Accessmate E-Mail display pager. This is the top of the line PCS technology pager made today. This side viewable display pager has a retail value of $189.00and comes with its own e-mail address so you can receive your e-mails as well as alpha-numeric and numeric messages instantly where ever you are. Your new e-mail pager has features like 50,000 character memory, message time stamping, automatic garbled message correction, beeps or vibrates, incandescent backlight, saved message folder, a unique never out of range feature that allows your pager to retrieve messages sent earlier when your pager was out of range or turned completely off. You can also receive weather, news and sports .The Motorola e-mail pager is very small and uses only a single double A battery. All we ask before we ship you your Free pager is for you to allow us to provide the airtime for you. There is no long term contract or credit check. Airtime is month to month and can be cancelled at any time. This pager will comes pre-programmed with its own e-mail address as well as a local telephone number to receive numeric pages. This pager comes with a complete 30 day money back guarantee, if after receiving this pager you're not completely happy, send it back and receive a full refund. For immediate delivery call Paging America at toll free at 877-699-8546 Brand New E-Mail pager for FREE! From owner-ietf-ldup@mail.imc.org Tue Feb 13 01:18:23 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id BAA01368 for ; Tue, 13 Feb 2001 01:18:22 -0500 (EST) Received: by above.proper.com (8.9.3/8.9.3) id VAA08578 for ietf-ldup-bks; Mon, 12 Feb 2001 21:49:36 -0800 (PST) Received: from sj-msg-core-1.cisco.com (sj-msg-core-1.cisco.com [171.71.163.11]) by above.proper.com (8.9.3/8.9.3) with ESMTP id VAA08574 for ; Mon, 12 Feb 2001 21:49:35 -0800 (PST) Received: from mira-sjcm-1.cisco.com (mira-sjcm-1.cisco.com [171.69.2.212]) by sj-msg-core-1.cisco.com (8.9.3/8.9.1) with ESMTP id VAA13239 for ; Mon, 12 Feb 2001 21:49:26 -0800 (PST) Received: from JSTRASSN-W2K1.cisco.com ([171.69.108.130]) by mira-sjcm-1.cisco.com (Mirapoint) with ESMTP id ALB01025; Mon, 12 Feb 2001 21:49:07 -0800 (PST) Message-Id: <4.3.2.7.2.20010212214500.00b77368@mira-sjcm-1.cisco.com> X-Sender: jstrassn@mira-sjcm-1.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Mon, 12 Feb 2001 21:48:58 -0800 To: ietf-ldup@imc.org From: John Strassner Subject: Draft Agenda Meeting Times Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ietf-ldup@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: LDUPers, We're slotted in for Tuesday, 20 March at 9am - 11:30am. Here's what we're scheduled against: TUESDAY, March 20, 2001 0900-1130 Morning Sessions APP ldup LDAP Duplication/Replication/Update Protocols WG (that's US) INT dhc Dynamic Host Configuration WG OPS opsarea Operations & Management Open Area RTG msdp Multicast Source Discovery Protocol WG SEC ipsra IP Security Remote Access WG TSV sip Session Initiation Protocol WG regards, John From owner-ietf-ldup@mail.imc.org Tue Feb 13 22:58:44 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id WAA07248 for ; Tue, 13 Feb 2001 22:58:44 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.9.3/8.9.3) id TAA21269 for ietf-ldup-bks; Tue, 13 Feb 2001 19:12:34 -0800 (PST) Received: from DF-INET-1.dogfoodinternet.com (df-inet1.exchange.microsoft.com [131.107.8.8]) by above.proper.com (8.9.3/8.9.3) with ESMTP id TAA21261 for ; Tue, 13 Feb 2001 19:12:32 -0800 (PST) Received: from df-virus1.platinum.corp.microsoft.com ([172.30.236.36]) by DF-INET-1.dogfoodinternet.com with Microsoft SMTPSVC(5.0.2195.1600); Tue, 13 Feb 2001 18:37:29 -0800 Received: from 172.30.236.11 by df-virus1.platinum.corp.microsoft.com (InterScan E-Mail VirusWall NT); Tue, 13 Feb 2001 18:38:13 -0800 (Pacific Standard Time) Received: from DINO.platinum.corp.microsoft.com ([172.30.236.101]) by yuri.dns.microsoft.com with Microsoft SMTPSVC(5.0.2195.2532); Tue, 13 Feb 2001 18:38:14 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.0.4643.0 content-class: urn:content-classes:message Subject: RE: WG Last Call on the LDAPv3 Directory Replication I-D MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Date: Tue, 13 Feb 2001 18:38:13 -0800 Message-ID: <5B90AD65A9E8934987DB0C8C0762657493DDBF@DF-BOWWOW.platinum.corp.microsoft.com> Thread-Topic: WG Last Call on the LDAPv3 Directory Replication I-D Thread-Index: AcCQfsKDiFaKX5tBSfaoB7PIz+Jz1gFsB7qA From: "Mark Brown (REDMOND)" To: "Richard V Huber" , , Cc: , , , , X-OriginalArrivalTime: 14 Feb 2001 02:38:14.0588 (UTC) FILETIME=[2E01E7C0:01C0962F] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id TAA21263 Sender: owner-ietf-ldup@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 8bit So sorry -- I missed those changes when the -06 version came out. Shortening my suggested addition seems like a good idea. But the intent of my suggestion was to set a clear requirement for LDUP's ability to provide interoperability. That way, as other LDUP drafts progress, we'll be able to tell if they are meeting the goal set in the requirements. Since we are doing this work in the IETF, interoperability should be one of the primary concerns of the work. But the proposed text : Interoperability of replicas between directory servers may be limited : by servers that implement semantics that go beyond what the LDAP : access protocol defines. Examples (not an exhaustive list) of such : semantics include: (1) replication among directory servers with : different access control systems/semantics may compromise directory : security, and (2) replication among directory servers with different : application trigger semantics may compromise directory data : integrity. does not set a clear requirement for LDUP's ability to provide interoperability. It says that when we are done designing LDUP, it is OK that certain directory servers will not be able to replicate. It does not say that for the LDUP design to be considered a viable IETF standard, it is necessary that there is some pair of directory servers (not from the same code base) that LDUP enables to replicate. Of course, we don't want to state such a goal in terms like "LDUP will enable OpenLDAP and the Siemens DS to replicate," we want to state the goal in terms of the functional characteristics of a pair of systems that are able to replicate. That's what my suggested text tried to do. How about this: : The goal of LDUP is to support replication between directory servers : that each implements a passive store fully described by its LDAP interface. : "Passive store" means that the servers are limited to storing entries that : come in via LDAP and retrieving those identical entries later in response : to LDAP requests. The entire semantics of such a store is defined by its : LDAP interface. Any restrictions on what the server can store must be : expressed in the server's schema, and any restrictions on the access that : clients have to the store must be expressed in terms of a standardized : LDAP access control scheme. : : LDUP is not required to support replication between directory : servers that each implements an active store extending LDAP : semantics with non-standard access control rules or with triggers. : Examples of triggers include password length/complexity policies and : automatic storage of secure password hashes instead of passwords. --mark -----Original Message----- From: Richard V Huber [mailto:rvh@qsun.mt.att.com] Sent: Tuesday, February 06, 2001 12:52 PM To: ietf-ldup@imc.org; johns@cisco.com; Mark Brown (REDMOND) Cc: capple@ecal.com; paf@cisco.com; rmoats@coreon.com; rweiser@digsigtrust.com; stokes@austin.ibm.com Subject: RE: WG Last Call on the LDAPv3 Directory Replication I-D We addressed these issues in version -06, though we cut down the text. Here is the summary that was included when I sent version -06 to the list. I haven't seen any comments on it since it was posted. : Internet Drafts Editor - : : Please publish the draft below as draft-ietf-ldup-replica-req-06.txt : It replaces the -05 draft from November. : : LDUP Mailing list - : : The attached version of the draft incorporates changes to address the : comments from San Diego. We trimmed Mark's proposed changes since we : were concerned that they went into too much detail that wasn't really : LDUP related. : : Our specific changes are: : : Insert the following as the last paragraph in Section 3: : : Interoperability of replicas between directory servers may be limited : by servers that implement semantics that go beyond what the LDAP : access protocol defines. Examples (not an exhaustive list) of such : semantics include: (1) replication among directory servers with : different access control systems/semantics may compromise directory : security, and (2) replication among directory servers with different : application trigger semantics may compromise directory data : integrity. : : Add the following at the end of the Security Considerations Section: : : As noted in Section 3, security may be impacted when replicating : among servers that implement non-standard extensions to basic LDAP : semantics. Access control is one common case which affects security; : work to address this issue is documented in RFC 2820 [RFC2820]. : : Add the new reference to the References: : : [RFC2820] E. Stokes, D. Byrne, B. Blakley, P. Behera, "Access : Control Requirements for LDAP", RFC 2820, May 2000. : : Change the draft number and the publication and expiration dates. : : As always, please send comments to the list. Rick Huber --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- : Subject: RE: WG Last Call on the LDAPv3 Directory Replication I-D : Thread-Topic: WG Last Call on the LDAPv3 Directory Replication I-D : Thread-Index: AcCP5HY9fw2/PIuYQC+oULzgUxaapgAgz+xQ : From: "Mark Brown (REDMOND)" : To: "John Strassner" , : Cc: "Chris Apple" , : =?iso-8859-1?Q?Patrik_F=E4ltstr=F6m?= : Sender: owner-ietf-ldup@mail.imc.org : : The LDAPv3 Directory Replication Requirements I-D document does : not address the interoperability limits issue that we discussed : in December-January. : : I append the most recent message on the topic. : : --mark : : -----Original Message----- : From: Mark Brown (REDMOND) : Sent: Thursday, January 11, 2001 7:41 PM : To: Ellen Stokes; Kurt D. Zeilenga : Cc: ietf-ldup@imc.org : Subject: RE: interoperability limits: proposed addition to : draft-ietf-ldup-replica-req-05.txt : : Oops, I left off the examples. Let's try again: : : I suggest inserting the following material right after : the first paragraph of Section 3 ("The Models") of the : requirements draft (just before the sentence "There are five : data consistency models.") : : --mark : : * * * * * : : The objective is limited to replication between directory servers : that implement a passive store fully described by its LDAP : interface. "Passive store" means that the servers are limited to : storing entries that come in via LDAP and retrieving those entries : later in response to LDAP requests. The entire semantics of : the passive store is defined by its LDAP interface. Any : restrictions on what the server can store must be : expressed in the server's schema, and any restrictions on the : access that clients have to the store must be expressed in terms : of a standardized LDAP access control scheme. This is in : contrast to an "active store" that implements triggers : or other rules that extend the semantics of entries beyond : what's implied by LDAP. Replication between such active : stores should be specified in extensions to LDUP. : : Here are some examples of ways in which directory servers : implement semantics that go beyond what the LDAP access : protocol defines: : : * Access control. LDAP does not currently define an access : control scheme. (The ldapext WG is working to extend LDAP : with an access control scheme.) Most directory servers : implement an access control scheme. : : Replication between directory servers with different : access control schemes would compromise directory security, : so such replication is not supported by LDUP. : : * Password policy. Some directory servers restrict changes : to password attributes, requiring that the new password : value conform to a specific security policy (e.g. the value : is sufficiently long and complex.) Doing so reduces the : security risk associated with passwords that are easy to : attack. : : Replication between directory servers with different : password policies (e.g. one server implements a password : policy and a second server implements no policy) would : compromise directory security, so such replication is not : supported by LDUP. : : * Password hashing. Some directory servers don't store a user's : password directly, but instead store one or more secure : hashes of the password. Doing so makes it less likely that : anyone (even an administrator) can discover the password. : : Replication between a directory server that stores passwords : and a directory server that stores only hashes will compromise : directory integrity, causing authentications to fail : unexpectedly, so such replication is not supported by LDUP. : : * * * * * : : -----Original Message----- : From: Mark Brown (REDMOND) : Sent: Thursday, January 11, 2001 3:10 PM : To: Ellen Stokes; 'Kurt D. Zeilenga' : Cc: ietf-ldup@imc.org : Subject: RE: interoperability limits: proposed addition to : draft-ietf-ldup-replica-req-05.txt : : : We appear to be in total agreement. : : So I suggest inserting the following paragraph right after : the first paragraph of Section 3 ("The Models") of the : requirements draft (just before the sentence "There are five : data consistency models.") : : --mark : : * * * * * : : The objective is limited to replication between directory servers : that implement a passive store fully described by its LDAP : interface. "Passive store" means that the servers are limited to : storing entries that come in via LDAP and retrieving those entries : later in response to LDAP requests. The entire semantics of : the passive store is defined by its LDAP interface. Any : restrictions on what the server can store must be : expressed in the server's schema, and any restrictions on the : access that clients have to the store must be expressed in terms : of a standardized LDAP access control scheme. This is in : contrast to an "active store" that implements triggers : or other rules that extend the semantics of entries beyond : what's implied by LDAP. Replication between such active : stores should be specified in extensions to LDUP. : : * * * * * : : --mark : : -----Original Message----- : From: Kurt D. Zeilenga [mailto:Kurt@OpenLDAP.org] : Sent: Tuesday, January 09, 2001 4:54 PM : To: Mark Brown (REDMOND) : Cc: Ellen Stokes; ietf-ldup@imc.org : Subject: RE: interoperability limits: proposed addition to : draft-ietf-ldup-replica-req-05.txt : : : Mark, : : Replication in the face of triggers or any other LDAP extension : should be specified in extensions to the LDUP. : : LDUP should assume 'passive' servers as this, I believe, is the : LDAP/X.500 data model. That is, servers should not muck with : user data. : : Kurt From owner-ietf-ldup@mail.imc.org Thu Feb 15 22:07:20 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id WAA06286 for ; Thu, 15 Feb 2001 22:07:20 -0500 (EST) Received: by above.proper.com (8.9.3/8.9.3) id SAA09863 for ietf-ldup-bks; Thu, 15 Feb 2001 18:25:22 -0800 (PST) Received: from sj-msg-core-4.cisco.com (sj-msg-core-4.cisco.com [171.71.163.10]) by above.proper.com (8.9.3/8.9.3) with ESMTP id SAA09856 for ; Thu, 15 Feb 2001 18:25:21 -0800 (PST) Received: from mira-sjcm-1.cisco.com (mira-sjcm-1.cisco.com [171.69.2.212]) by sj-msg-core-4.cisco.com (8.9.3/8.9.1) with ESMTP id SAA08643; Thu, 15 Feb 2001 18:24:56 -0800 (PST) Received: from JSTRASSN-W2K1.cisco.com (sj-dial-4-117.cisco.com [171.68.181.246]) by mira-sjcm-1.cisco.com (Mirapoint) with ESMTP id ALE01439; Thu, 15 Feb 2001 18:24:50 -0800 (PST) Message-Id: <4.3.2.7.2.20010215182223.00b5ffc8@mira-sjcm-1.cisco.com> X-Sender: jstrassn@mira-sjcm-1.cisco.com (Unverified) X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Thu, 15 Feb 2001 18:24:04 -0800 To: ietf-ldup@imc.org From: John Strassner Subject: Our agenda Cc: capple@ecal.com Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ietf-ldup@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Greetings, LDUPers, please forward me any specific agenda items that you have. Otherwise, it will be the same format of going through each deliverable on our charter and getting an update. Authors, please remember our deadlines - Feb 23 for new drafts, and March 2 for updates. regards, John + Chris From owner-ietf-ldup@mail.imc.org Fri Feb 16 02:41:37 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id CAA24596 for ; Fri, 16 Feb 2001 02:41:36 -0500 (EST) Received: by above.proper.com (8.9.3/8.9.3) id XAA16788 for ietf-ldup-bks; Thu, 15 Feb 2001 23:03:36 -0800 (PST) Received: from pretender.boolean.net (root@router.boolean.net [198.144.206.49]) by above.proper.com (8.9.3/8.9.3) with ESMTP id XAA16777 for ; Thu, 15 Feb 2001 23:03:35 -0800 (PST) Received: from gypsy.OpenLDAP.org (gypsy.boolean.net [10.192.1.2]) by pretender.boolean.net (8.11.1/8.11.1/Boolean/Hub) with ESMTP id f1G72UD02641 for ; Fri, 16 Feb 2001 07:02:30 GMT (envelope-from Kurt@OpenLDAP.org) Message-Id: <5.0.2.1.0.20010215221755.00aed450@router.boolean.net> X-Sender: guru@router.boolean.net X-Mailer: QUALCOMM Windows Eudora Version 5.0.2 Date: Thu, 15 Feb 2001 23:02:29 -0800 To: From: "Kurt D. Zeilenga" Subject: RE: WG Last Call on the LDAPv3 Directory Replication I-D In-Reply-To: <5B90AD65A9E8934987DB0C8C0762657493DDBF@DF-BOWWOW.platinum. corp.microsoft.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: Section B.3 discusses replication issues due to schema mismatches. I note that even with a common schema, servers may have different requirements for schema management. 1) schema may not be updatable via LDAP 2) server may require a common schema, instead of per administrative area schema 3) schema may be held in an entry, not a subentry. Also, one must be careful not to replicate schema descriptions which are indicative of support for specific features, such as extensibleObject. Also, there seems to be similar replication issues due to other "feature" differences between two LDAPv3 servers. Including: - subtypes may not be supported, or supported with restrictions - schema entry v. schema subentry - different ;binary use restrictions - extensions (e.g. language tags, dynamic objects) - [structural] object class modify - extensible object support The I-D notes that a Standard Track ACM is needed. I note that the ACM model under development by LDAPext may be insufficient in replicated environments (but that's another thread). One likely also needs a Standard Track referral representation. I note that there need not be a requirement that replicas implement the same access control model. The requirement is (RFC 2251, 3.2): Servers which perform caching or shadowing MUST ensure that they do not violate any access control constraints placed on the data by the originating server. That is, it's the policy that counts, not the model. Editorial, I dislike the use of "Standard" when referring to documents which are not Standards. I suggest replacing "Standard" with "Specification" or "Technical Specification". From owner-ietf-ldup@mail.imc.org Fri Feb 16 16:34:16 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA10075 for ; Fri, 16 Feb 2001 16:34:16 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.9.3/8.9.3) id MAA22735 for ietf-ldup-bks; Fri, 16 Feb 2001 12:36:13 -0800 (PST) Received: from mail.coreon.net (IDENT:mirapoint@mail.coreon.net [216.74.131.6]) by above.proper.com (8.9.3/8.9.3) with ESMTP id MAA22730 for ; Fri, 16 Feb 2001 12:36:11 -0800 (PST) Received: from rmoats2 (wenjus3.coreon.net [216.74.131.3]) by mail.coreon.net (Mirapoint) with ESMTP id AAB30539 (AUTH rmoats); Fri, 16 Feb 2001 15:35:59 -0500 (EST) From: "Ryan Moats" To: "Mark Brown \(REDMOND\)" , "Richard V Huber" , , Cc: , , , , Subject: RE: WG Last Call on the LDAPv3 Directory Replication I-D Date: Fri, 16 Feb 2001 14:40:28 -0600 Message-ID: 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 IMO, Build 9.0.2416 (9.0.2911.0) In-Reply-To: <5B90AD65A9E8934987DB0C8C0762657493DDBF@DF-BOWWOW.platinum.corp.microsoft.com> Importance: Normal 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: Content-Transfer-Encoding: 7bit See ... below... Ryan -----Original Message----- From: Mark Brown (REDMOND) [mailto:mabrown@Exchange.Microsoft.com] Sent: Tuesday, February 13, 2001 8:38 PM To: Richard V Huber; ietf-ldup@imc.org; johns@cisco.com Cc: capple@ecal.com; paf@cisco.com; rmoats@coreon.net; rweiser@digsigtrust.com; stokes@austin.ibm.com Subject: RE: WG Last Call on the LDAPv3 Directory Replication I-D So sorry -- I missed those changes when the -06 version came out. Shortening my suggested addition seems like a good idea. Good But the intent of my suggestion was to set a clear requirement for LDUP's ability to provide interoperability. That way, as other LDUP drafts progress, we'll be able to tell if they are meeting the goal set in the requirements. I personally am willing to do the following text adjustment, (the other authors still get to comment)... ... A standard mechanism for directory replication in a multi-vendor environment is critical to the continued success of LDAP in the market place. This document sets out the requirements for replication between multiple standard-conformant LDAP servers. ... ^^^^^^^^^^^^^^^^^^^ <- new text Beyond this, I disagree that LDUP requirements need to be stated to cover items that don't have an LDAP standard yet. Any new LDAP standard should cover the impact of replication on that standard, not the other way around. Since we are doing this work in the IETF, interoperability should be one of the primary concerns of the work. But the proposed text : Interoperability of replicas between directory servers may be limited : by servers that implement semantics that go beyond what the LDAP : access protocol defines. Examples (not an exhaustive list) of such : semantics include: (1) replication among directory servers with : different access control systems/semantics may compromise directory : security, and (2) replication among directory servers with different : application trigger semantics may compromise directory data : integrity. does not set a clear requirement for LDUP's ability to provide interoperability. It says that when we are done designing LDUP, it is OK that certain directory servers will not be able to replicate. It does not say that for the LDUP design to be considered a viable IETF standard, it is necessary that there is some pair of directory servers (not from the same code base) that LDUP enables to replicate. Of course, we don't want to state such a goal in terms like "LDUP will enable OpenLDAP and the Siemens DS to replicate," we want to state the goal in terms of the functional characteristics of a pair of systems that are able to replicate. That's what my suggested text tried to do. How about this: : The goal of LDUP is to support replication between directory servers : that each implements a passive store fully described by its LDAP interface. : "Passive store" means that the servers are limited to storing entries that : come in via LDAP and retrieving those identical entries later in response : to LDAP requests. The entire semantics of such a store is defined by its : LDAP interface. Any restrictions on what the server can store must be : expressed in the server's schema, and any restrictions on the access that : clients have to the store must be expressed in terms of a standardized : LDAP access control scheme. : : LDUP is not required to support replication between directory : servers that each implements an active store extending LDAP : semantics with non-standard access control rules or with triggers. : Examples of triggers include password length/complexity policies and : automatic storage of secure password hashes instead of passwords. --mark -----Original Message----- From: Richard V Huber [mailto:rvh@qsun.mt.att.com] Sent: Tuesday, February 06, 2001 12:52 PM To: ietf-ldup@imc.org; johns@cisco.com; Mark Brown (REDMOND) Cc: capple@ecal.com; paf@cisco.com; rmoats@coreon.com; rweiser@digsigtrust.com; stokes@austin.ibm.com Subject: RE: WG Last Call on the LDAPv3 Directory Replication I-D We addressed these issues in version -06, though we cut down the text. Here is the summary that was included when I sent version -06 to the list. I haven't seen any comments on it since it was posted. : Internet Drafts Editor - : : Please publish the draft below as draft-ietf-ldup-replica-req-06.txt : It replaces the -05 draft from November. : : LDUP Mailing list - : : The attached version of the draft incorporates changes to address the : comments from San Diego. We trimmed Mark's proposed changes since we : were concerned that they went into too much detail that wasn't really : LDUP related. : : Our specific changes are: : : Insert the following as the last paragraph in Section 3: : : Interoperability of replicas between directory servers may be limited : by servers that implement semantics that go beyond what the LDAP : access protocol defines. Examples (not an exhaustive list) of such : semantics include: (1) replication among directory servers with : different access control systems/semantics may compromise directory : security, and (2) replication among directory servers with different : application trigger semantics may compromise directory data : integrity. : : Add the following at the end of the Security Considerations Section: : : As noted in Section 3, security may be impacted when replicating : among servers that implement non-standard extensions to basic LDAP : semantics. Access control is one common case which affects security; : work to address this issue is documented in RFC 2820 [RFC2820]. : : Add the new reference to the References: : : [RFC2820] E. Stokes, D. Byrne, B. Blakley, P. Behera, "Access : Control Requirements for LDAP", RFC 2820, May 2000. : : Change the draft number and the publication and expiration dates. : : As always, please send comments to the list. Rick Huber --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- : Subject: RE: WG Last Call on the LDAPv3 Directory Replication I-D : Thread-Topic: WG Last Call on the LDAPv3 Directory Replication I-D : Thread-Index: AcCP5HY9fw2/PIuYQC+oULzgUxaapgAgz+xQ : From: "Mark Brown (REDMOND)" : To: "John Strassner" , : Cc: "Chris Apple" , : =?iso-8859-1?Q?Patrik_F=E4ltstr=F6m?= : Sender: owner-ietf-ldup@mail.imc.org : : The LDAPv3 Directory Replication Requirements I-D document does : not address the interoperability limits issue that we discussed : in December-January. : : I append the most recent message on the topic. : : --mark : : -----Original Message----- : From: Mark Brown (REDMOND) : Sent: Thursday, January 11, 2001 7:41 PM : To: Ellen Stokes; Kurt D. Zeilenga : Cc: ietf-ldup@imc.org : Subject: RE: interoperability limits: proposed addition to : draft-ietf-ldup-replica-req-05.txt : : Oops, I left off the examples. Let's try again: : : I suggest inserting the following material right after : the first paragraph of Section 3 ("The Models") of the : requirements draft (just before the sentence "There are five : data consistency models.") : : --mark : : * * * * * : : The objective is limited to replication between directory servers : that implement a passive store fully described by its LDAP : interface. "Passive store" means that the servers are limited to : storing entries that come in via LDAP and retrieving those entries : later in response to LDAP requests. The entire semantics of : the passive store is defined by its LDAP interface. Any : restrictions on what the server can store must be : expressed in the server's schema, and any restrictions on the : access that clients have to the store must be expressed in terms : of a standardized LDAP access control scheme. This is in : contrast to an "active store" that implements triggers : or other rules that extend the semantics of entries beyond : what's implied by LDAP. Replication between such active : stores should be specified in extensions to LDUP. : : Here are some examples of ways in which directory servers : implement semantics that go beyond what the LDAP access : protocol defines: : : * Access control. LDAP does not currently define an access : control scheme. (The ldapext WG is working to extend LDAP : with an access control scheme.) Most directory servers : implement an access control scheme. : : Replication between directory servers with different : access control schemes would compromise directory security, : so such replication is not supported by LDUP. : : * Password policy. Some directory servers restrict changes : to password attributes, requiring that the new password : value conform to a specific security policy (e.g. the value : is sufficiently long and complex.) Doing so reduces the : security risk associated with passwords that are easy to : attack. : : Replication between directory servers with different : password policies (e.g. one server implements a password : policy and a second server implements no policy) would : compromise directory security, so such replication is not : supported by LDUP. : : * Password hashing. Some directory servers don't store a user's : password directly, but instead store one or more secure : hashes of the password. Doing so makes it less likely that : anyone (even an administrator) can discover the password. : : Replication between a directory server that stores passwords : and a directory server that stores only hashes will compromise : directory integrity, causing authentications to fail : unexpectedly, so such replication is not supported by LDUP. : : * * * * * : : -----Original Message----- : From: Mark Brown (REDMOND) : Sent: Thursday, January 11, 2001 3:10 PM : To: Ellen Stokes; 'Kurt D. Zeilenga' : Cc: ietf-ldup@imc.org : Subject: RE: interoperability limits: proposed addition to : draft-ietf-ldup-replica-req-05.txt : : : We appear to be in total agreement. : : So I suggest inserting the following paragraph right after : the first paragraph of Section 3 ("The Models") of the : requirements draft (just before the sentence "There are five : data consistency models.") : : --mark : : * * * * * : : The objective is limited to replication between directory servers : that implement a passive store fully described by its LDAP : interface. "Passive store" means that the servers are limited to : storing entries that come in via LDAP and retrieving those entries : later in response to LDAP requests. The entire semantics of : the passive store is defined by its LDAP interface. Any : restrictions on what the server can store must be : expressed in the server's schema, and any restrictions on the : access that clients have to the store must be expressed in terms : of a standardized LDAP access control scheme. This is in : contrast to an "active store" that implements triggers : or other rules that extend the semantics of entries beyond : what's implied by LDAP. Replication between such active : stores should be specified in extensions to LDUP. : : * * * * * : : --mark : : -----Original Message----- : From: Kurt D. Zeilenga [mailto:Kurt@OpenLDAP.org] : Sent: Tuesday, January 09, 2001 4:54 PM : To: Mark Brown (REDMOND) : Cc: Ellen Stokes; ietf-ldup@imc.org : Subject: RE: interoperability limits: proposed addition to : draft-ietf-ldup-replica-req-05.txt : : : Mark, : : Replication in the face of triggers or any other LDAP extension : should be specified in extensions to the LDUP. : : LDUP should assume 'passive' servers as this, I believe, is the : LDAP/X.500 data model. That is, servers should not muck with : user data. : : Kurt From owner-ietf-ldup@mail.imc.org Fri Feb 16 19:09:48 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA12048 for ; Fri, 16 Feb 2001 19:09:47 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.9.3/8.9.3) id PAA02405 for ietf-ldup-bks; Fri, 16 Feb 2001 15:07:30 -0800 (PST) Received: from DF-INET-1.dogfoodinternet.com (df-inet1.exchange.microsoft.com [131.107.8.8]) by above.proper.com (8.9.3/8.9.3) with ESMTP id PAA02401 for ; Fri, 16 Feb 2001 15:07:29 -0800 (PST) Received: from df-virus1.platinum.corp.microsoft.com ([172.30.236.36]) by DF-INET-1.dogfoodinternet.com with Microsoft SMTPSVC(5.0.2195.2831); Fri, 16 Feb 2001 14:47:45 -0800 Received: from 172.30.236.11 by df-virus1.platinum.corp.microsoft.com (InterScan E-Mail VirusWall NT); Fri, 16 Feb 2001 14:48:29 -0800 (Pacific Standard Time) Received: from DF-BOWWOW.platinum.corp.microsoft.com ([172.30.236.101]) by yuri.dns.microsoft.com with Microsoft SMTPSVC(5.0.2195.2831); Fri, 16 Feb 2001 14:39:34 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.0.4648.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: WG Last Call on the LDAPv3 Directory Replication I-D Date: Fri, 16 Feb 2001 13:43:11 -0800 Message-ID: <5B90AD65A9E8934987DB0C8C0762657493DDD1@DF-BOWWOW.platinum.corp.microsoft.com> Thread-Topic: WG Last Call on the LDAPv3 Directory Replication I-D Thread-Index: AcCYW4AjA/tEISoNS8WZnTZpB6gxUAAAQoUQ From: "Mark Brown (REDMOND)" To: "Ryan Moats" , "Richard V Huber" , , Cc: , , , X-OriginalArrivalTime: 16 Feb 2001 22:39:34.0569 (UTC) FILETIME=[55D9A990:01C09869] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id PAA02402 Sender: owner-ietf-ldup@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 8bit ... ... A standard mechanism for directory replication in a multi-vendor environment is critical to the continued success of LDAP in the market place. This document sets out the requirements for replication between multiple standard-conformant LDAP servers. ... ^^^^^^^^^^^^^^^^^^^ <- new text ... An LDAP server that implements semantics not mentioned in the LDAP RFCs does not thereby become non-standard-conformant. For instance, most LDAP servers today implement an access control scheme. No access control scheme is mentioned in the LDAP RFCs. Yet LDAP servers that implement access control are conformant with the LDAP standard. Similarly, a server that implements internal triggers for the purpose of maintaining certain invariants in the directory can conform with the LDAP standard. LDUP is designed to solve the problem of replicating the representations of directories. But the correspondence between these representations and the LDAP protocol is not a simple one in general -- it is only simple for directories that are completely passive stores. When LDUP is used to replicate (the representations of) non-passive stores, it is up to the developers of those stores, not LDUP, to define how to achieve interoperability. (Most likely, they'll do this pairwise.) Readers of the requirements draft, even with your proposed amendment, are likely to think that LDUP is meant to provide interoperability between directories rather than between their representations. They are likely to blame LDAP directory implementors for not providing the same degree of interoperability as, say, DNS server implementors do. As Kurt says down at the start of this thread, that's not LDUP's job. It is worth adding a paragraph to the draft so that it says so clearly. --mark -----Original Message----- From: Ryan Moats [mailto:rmoats@coreon.net] Sent: Friday, February 16, 2001 12:40 PM To: Mark Brown (REDMOND); Richard V Huber; ietf-ldup@imc.org; johns@cisco.com Cc: capple@ecal.com; paf@cisco.com; rmoats@coreon.net; rweiser@digsigtrust.com; stokes@austin.ibm.com Subject: RE: WG Last Call on the LDAPv3 Directory Replication I-D See ... below... Ryan -----Original Message----- From: Mark Brown (REDMOND) [mailto:mabrown@Exchange.Microsoft.com] Sent: Tuesday, February 13, 2001 8:38 PM To: Richard V Huber; ietf-ldup@imc.org; johns@cisco.com Cc: capple@ecal.com; paf@cisco.com; rmoats@coreon.net; rweiser@digsigtrust.com; stokes@austin.ibm.com Subject: RE: WG Last Call on the LDAPv3 Directory Replication I-D So sorry -- I missed those changes when the -06 version came out. Shortening my suggested addition seems like a good idea. Good But the intent of my suggestion was to set a clear requirement for LDUP's ability to provide interoperability. That way, as other LDUP drafts progress, we'll be able to tell if they are meeting the goal set in the requirements. I personally am willing to do the following text adjustment, (the other authors still get to comment)... ... A standard mechanism for directory replication in a multi-vendor environment is critical to the continued success of LDAP in the market place. This document sets out the requirements for replication between multiple standard-conformant LDAP servers. ... ^^^^^^^^^^^^^^^^^^^ <- new text Beyond this, I disagree that LDUP requirements need to be stated to cover items that don't have an LDAP standard yet. Any new LDAP standard should cover the impact of replication on that standard, not the other way around. Since we are doing this work in the IETF, interoperability should be one of the primary concerns of the work. But the proposed text : Interoperability of replicas between directory servers may be limited : by servers that implement semantics that go beyond what the LDAP : access protocol defines. Examples (not an exhaustive list) of such : semantics include: (1) replication among directory servers with : different access control systems/semantics may compromise directory : security, and (2) replication among directory servers with different : application trigger semantics may compromise directory data : integrity. does not set a clear requirement for LDUP's ability to provide interoperability. It says that when we are done designing LDUP, it is OK that certain directory servers will not be able to replicate. It does not say that for the LDUP design to be considered a viable IETF standard, it is necessary that there is some pair of directory servers (not from the same code base) that LDUP enables to replicate. Of course, we don't want to state such a goal in terms like "LDUP will enable OpenLDAP and the Siemens DS to replicate," we want to state the goal in terms of the functional characteristics of a pair of systems that are able to replicate. That's what my suggested text tried to do. How about this: : The goal of LDUP is to support replication between directory servers : that each implements a passive store fully described by its LDAP interface. : "Passive store" means that the servers are limited to storing entries that : come in via LDAP and retrieving those identical entries later in response : to LDAP requests. The entire semantics of such a store is defined by its : LDAP interface. Any restrictions on what the server can store must be : expressed in the server's schema, and any restrictions on the access that : clients have to the store must be expressed in terms of a standardized : LDAP access control scheme. : : LDUP is not required to support replication between directory : servers that each implements an active store extending LDAP : semantics with non-standard access control rules or with triggers. : Examples of triggers include password length/complexity policies and : automatic storage of secure password hashes instead of passwords. --mark -----Original Message----- From: Richard V Huber [mailto:rvh@qsun.mt.att.com] Sent: Tuesday, February 06, 2001 12:52 PM To: ietf-ldup@imc.org; johns@cisco.com; Mark Brown (REDMOND) Cc: capple@ecal.com; paf@cisco.com; rmoats@coreon.com; rweiser@digsigtrust.com; stokes@austin.ibm.com Subject: RE: WG Last Call on the LDAPv3 Directory Replication I-D We addressed these issues in version -06, though we cut down the text. Here is the summary that was included when I sent version -06 to the list. I haven't seen any comments on it since it was posted. : Internet Drafts Editor - : : Please publish the draft below as draft-ietf-ldup-replica-req-06.txt : It replaces the -05 draft from November. : : LDUP Mailing list - : : The attached version of the draft incorporates changes to address the : comments from San Diego. We trimmed Mark's proposed changes since we : were concerned that they went into too much detail that wasn't really : LDUP related. : : Our specific changes are: : : Insert the following as the last paragraph in Section 3: : : Interoperability of replicas between directory servers may be limited : by servers that implement semantics that go beyond what the LDAP : access protocol defines. Examples (not an exhaustive list) of such : semantics include: (1) replication among directory servers with : different access control systems/semantics may compromise directory : security, and (2) replication among directory servers with different : application trigger semantics may compromise directory data : integrity. : : Add the following at the end of the Security Considerations Section: : : As noted in Section 3, security may be impacted when replicating : among servers that implement non-standard extensions to basic LDAP : semantics. Access control is one common case which affects security; : work to address this issue is documented in RFC 2820 [RFC2820]. : : Add the new reference to the References: : : [RFC2820] E. Stokes, D. Byrne, B. Blakley, P. Behera, "Access : Control Requirements for LDAP", RFC 2820, May 2000. : : Change the draft number and the publication and expiration dates. : : As always, please send comments to the list. Rick Huber --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- : Subject: RE: WG Last Call on the LDAPv3 Directory Replication I-D : Thread-Topic: WG Last Call on the LDAPv3 Directory Replication I-D : Thread-Index: AcCP5HY9fw2/PIuYQC+oULzgUxaapgAgz+xQ : From: "Mark Brown (REDMOND)" : To: "John Strassner" , : Cc: "Chris Apple" , : =?iso-8859-1?Q?Patrik_F=E4ltstr=F6m?= : Sender: owner-ietf-ldup@mail.imc.org : : The LDAPv3 Directory Replication Requirements I-D document does : not address the interoperability limits issue that we discussed : in December-January. : : I append the most recent message on the topic. : : --mark : : -----Original Message----- : From: Mark Brown (REDMOND) : Sent: Thursday, January 11, 2001 7:41 PM : To: Ellen Stokes; Kurt D. Zeilenga : Cc: ietf-ldup@imc.org : Subject: RE: interoperability limits: proposed addition to : draft-ietf-ldup-replica-req-05.txt : : Oops, I left off the examples. Let's try again: : : I suggest inserting the following material right after : the first paragraph of Section 3 ("The Models") of the : requirements draft (just before the sentence "There are five : data consistency models.") : : --mark : : * * * * * : : The objective is limited to replication between directory servers : that implement a passive store fully described by its LDAP : interface. "Passive store" means that the servers are limited to : storing entries that come in via LDAP and retrieving those entries : later in response to LDAP requests. The entire semantics of : the passive store is defined by its LDAP interface. Any : restrictions on what the server can store must be : expressed in the server's schema, and any restrictions on the : access that clients have to the store must be expressed in terms : of a standardized LDAP access control scheme. This is in : contrast to an "active store" that implements triggers : or other rules that extend the semantics of entries beyond : what's implied by LDAP. Replication between such active : stores should be specified in extensions to LDUP. : : Here are some examples of ways in which directory servers : implement semantics that go beyond what the LDAP access : protocol defines: : : * Access control. LDAP does not currently define an access : control scheme. (The ldapext WG is working to extend LDAP : with an access control scheme.) Most directory servers : implement an access control scheme. : : Replication between directory servers with different : access control schemes would compromise directory security, : so such replication is not supported by LDUP. : : * Password policy. Some directory servers restrict changes : to password attributes, requiring that the new password : value conform to a specific security policy (e.g. the value : is sufficiently long and complex.) Doing so reduces the : security risk associated with passwords that are easy to : attack. : : Replication between directory servers with different : password policies (e.g. one server implements a password : policy and a second server implements no policy) would : compromise directory security, so such replication is not : supported by LDUP. : : * Password hashing. Some directory servers don't store a user's : password directly, but instead store one or more secure : hashes of the password. Doing so makes it less likely that : anyone (even an administrator) can discover the password. : : Replication between a directory server that stores passwords : and a directory server that stores only hashes will compromise : directory integrity, causing authentications to fail : unexpectedly, so such replication is not supported by LDUP. : : * * * * * : : -----Original Message----- : From: Mark Brown (REDMOND) : Sent: Thursday, January 11, 2001 3:10 PM : To: Ellen Stokes; 'Kurt D. Zeilenga' : Cc: ietf-ldup@imc.org : Subject: RE: interoperability limits: proposed addition to : draft-ietf-ldup-replica-req-05.txt : : : We appear to be in total agreement. : : So I suggest inserting the following paragraph right after : the first paragraph of Section 3 ("The Models") of the : requirements draft (just before the sentence "There are five : data consistency models.") : : --mark : : * * * * * : : The objective is limited to replication between directory servers : that implement a passive store fully described by its LDAP : interface. "Passive store" means that the servers are limited to : storing entries that come in via LDAP and retrieving those entries : later in response to LDAP requests. The entire semantics of : the passive store is defined by its LDAP interface. Any : restrictions on what the server can store must be : expressed in the server's schema, and any restrictions on the : access that clients have to the store must be expressed in terms : of a standardized LDAP access control scheme. This is in : contrast to an "active store" that implements triggers : or other rules that extend the semantics of entries beyond : what's implied by LDAP. Replication between such active : stores should be specified in extensions to LDUP. : : * * * * * : : --mark : : -----Original Message----- : From: Kurt D. Zeilenga [mailto:Kurt@OpenLDAP.org] : Sent: Tuesday, January 09, 2001 4:54 PM : To: Mark Brown (REDMOND) : Cc: Ellen Stokes; ietf-ldup@imc.org : Subject: RE: interoperability limits: proposed addition to : draft-ietf-ldup-replica-req-05.txt : : : Mark, : : Replication in the face of triggers or any other LDAP extension : should be specified in extensions to the LDUP. : : LDUP should assume 'passive' servers as this, I believe, is the : LDAP/X.500 data model. That is, servers should not muck with : user data. : : Kurt From owner-ietf-ldup@mail.imc.org Fri Feb 16 21:47:02 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id VAA14508 for ; Fri, 16 Feb 2001 21:47:00 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.9.3/8.9.3) id RAA09937 for ietf-ldup-bks; Fri, 16 Feb 2001 17:53:08 -0800 (PST) Received: from mail.coreon.net (IDENT:mirapoint@mail.coreon.net [216.74.131.6]) by above.proper.com (8.9.3/8.9.3) with ESMTP id RAA09932 for ; Fri, 16 Feb 2001 17:53:06 -0800 (PST) Received: from rmoats2 (wenjus3.coreon.net [216.74.131.3]) by mail.coreon.net (Mirapoint) with ESMTP id AAB31423 (AUTH rmoats); Fri, 16 Feb 2001 20:52:52 -0500 (EST) From: "Ryan Moats" To: "Mark Brown \(REDMOND\)" , "Ryan Moats" , "Richard V Huber" , , Cc: , , , Subject: RE: WG Last Call on the LDAPv3 Directory Replication I-D Date: Fri, 16 Feb 2001 19:57:24 -0600 Message-ID: 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 IMO, Build 9.0.2416 (9.0.2911.0) Importance: Normal In-Reply-To: <5B90AD65A9E8934987DB0C8C0762657493DDD1@DF-BOWWOW.platinum.corp.microsoft.com> 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: Content-Transfer-Encoding: 7bit John, Chris, do you have a sense of the working group from the list messages? I've not seen enough reaction to see whether we've got rough consensus one way or another, and I'm worried that this discussion threatens to become a rat-hole. See ... below... Ryan -----Original Message----- From: Mark Brown (REDMOND) [mailto:mabrown@Exchange.Microsoft.com] Subject: RE: WG Last Call on the LDAPv3 Directory Replication I-D ... ... A standard mechanism for directory replication in a multi-vendor environment is critical to the continued success of LDAP in the market place. This document sets out the requirements for replication between multiple standard-conformant LDAP servers. ... ^^^^^^^^^^^^^^^^^^^ <- new text ... An LDAP server that implements semantics not mentioned in the LDAP RFCs does not thereby become non-standard-conformant. Never said it didn't For instance, most LDAP servers today implement an access control scheme. No access control scheme is mentioned in the LDAP RFCs. Yet LDAP servers that implement access control are conformant with the LDAP standard. In the absence of an LDAP standard for access control, you can't have interoperability of access control in the IETF sense. However, I am not willing to delay this document for something that is the responsibility of another working group. The proper IETF procedure (as I understand it) is for this document to go forward and it become the responsibility of the access control draft authors to include the replication implications of the new standard. That avoids a "boil the ocean" conundrum preventing progress. Similarly, a server that implements internal triggers for the purpose of maintaining certain invariants in the directory can conform with the LDAP standard. Again, in the absence of an LDAP standard for internal triggers you can't have IETF interoperability to replicate that information with LDUP. If you want interoperability in replicating internal triggers, the proper process is to develop an RFC and address the issues there. LDUP is designed to solve the problem of replicating the representations of directories. But the correspondence between these representations and the LDAP protocol is not a simple one in general -- it is only simple for directories that are completely passive stores. When LDUP is used to replicate (the representations of) non-passive stores, it is up to the developers of those stores, not LDUP, to define how to achieve interoperability. (Most likely, they'll do this pairwise.) Readers of the requirements draft, even with your proposed amendment, are likely to think that LDUP is meant to provide interoperability between directories rather than between their representations. They are likely to blame LDAP directory implementors for not providing the same degree of interoperability as, say, DNS server implementors do. As Kurt says down at the start of this thread, that's not LDUP's job. It is worth adding a paragraph to the draft so that it says so clearly. I claim we've addressed the issue already in -06 and with the suggested text above. Therefore, at this point, I think I'd like to ask the chairs to get a sense of the mailing list to see if we have rough-consensus, because I can see argument turning into a rat-hole. --mark -----Original Message----- From: Ryan Moats [mailto:rmoats@coreon.net] Sent: Friday, February 16, 2001 12:40 PM To: Mark Brown (REDMOND); Richard V Huber; ietf-ldup@imc.org; johns@cisco.com Cc: capple@ecal.com; paf@cisco.com; rmoats@coreon.net; rweiser@digsigtrust.com; stokes@austin.ibm.com Subject: RE: WG Last Call on the LDAPv3 Directory Replication I-D See ... below... Ryan -----Original Message----- From: Mark Brown (REDMOND) [mailto:mabrown@Exchange.Microsoft.com] Sent: Tuesday, February 13, 2001 8:38 PM To: Richard V Huber; ietf-ldup@imc.org; johns@cisco.com Cc: capple@ecal.com; paf@cisco.com; rmoats@coreon.net; rweiser@digsigtrust.com; stokes@austin.ibm.com Subject: RE: WG Last Call on the LDAPv3 Directory Replication I-D So sorry -- I missed those changes when the -06 version came out. Shortening my suggested addition seems like a good idea. Good But the intent of my suggestion was to set a clear requirement for LDUP's ability to provide interoperability. That way, as other LDUP drafts progress, we'll be able to tell if they are meeting the goal set in the requirements. I personally am willing to do the following text adjustment, (the other authors still get to comment)... ... A standard mechanism for directory replication in a multi-vendor environment is critical to the continued success of LDAP in the market place. This document sets out the requirements for replication between multiple standard-conformant LDAP servers. ... ^^^^^^^^^^^^^^^^^^^ <- new text Beyond this, I disagree that LDUP requirements need to be stated to cover items that don't have an LDAP standard yet. Any new LDAP standard should cover the impact of replication on that standard, not the other way around. Since we are doing this work in the IETF, interoperability should be one of the primary concerns of the work. But the proposed text : Interoperability of replicas between directory servers may be limited : by servers that implement semantics that go beyond what the LDAP : access protocol defines. Examples (not an exhaustive list) of such : semantics include: (1) replication among directory servers with : different access control systems/semantics may compromise directory : security, and (2) replication among directory servers with different : application trigger semantics may compromise directory data : integrity. does not set a clear requirement for LDUP's ability to provide interoperability. It says that when we are done designing LDUP, it is OK that certain directory servers will not be able to replicate. It does not say that for the LDUP design to be considered a viable IETF standard, it is necessary that there is some pair of directory servers (not from the same code base) that LDUP enables to replicate. Of course, we don't want to state such a goal in terms like "LDUP will enable OpenLDAP and the Siemens DS to replicate," we want to state the goal in terms of the functional characteristics of a pair of systems that are able to replicate. That's what my suggested text tried to do. How about this: : The goal of LDUP is to support replication between directory servers : that each implements a passive store fully described by its LDAP interface. : "Passive store" means that the servers are limited to storing entries that : come in via LDAP and retrieving those identical entries later in response : to LDAP requests. The entire semantics of such a store is defined by its : LDAP interface. Any restrictions on what the server can store must be : expressed in the server's schema, and any restrictions on the access that : clients have to the store must be expressed in terms of a standardized : LDAP access control scheme. : : LDUP is not required to support replication between directory : servers that each implements an active store extending LDAP : semantics with non-standard access control rules or with triggers. : Examples of triggers include password length/complexity policies and : automatic storage of secure password hashes instead of passwords. --mark -----Original Message----- From: Richard V Huber [mailto:rvh@qsun.mt.att.com] Sent: Tuesday, February 06, 2001 12:52 PM To: ietf-ldup@imc.org; johns@cisco.com; Mark Brown (REDMOND) Cc: capple@ecal.com; paf@cisco.com; rmoats@coreon.com; rweiser@digsigtrust.com; stokes@austin.ibm.com Subject: RE: WG Last Call on the LDAPv3 Directory Replication I-D We addressed these issues in version -06, though we cut down the text. Here is the summary that was included when I sent version -06 to the list. I haven't seen any comments on it since it was posted. : Internet Drafts Editor - : : Please publish the draft below as draft-ietf-ldup-replica-req-06.txt : It replaces the -05 draft from November. : : LDUP Mailing list - : : The attached version of the draft incorporates changes to address the : comments from San Diego. We trimmed Mark's proposed changes since we : were concerned that they went into too much detail that wasn't really : LDUP related. : : Our specific changes are: : : Insert the following as the last paragraph in Section 3: : : Interoperability of replicas between directory servers may be limited : by servers that implement semantics that go beyond what the LDAP : access protocol defines. Examples (not an exhaustive list) of such : semantics include: (1) replication among directory servers with : different access control systems/semantics may compromise directory : security, and (2) replication among directory servers with different : application trigger semantics may compromise directory data : integrity. : : Add the following at the end of the Security Considerations Section: : : As noted in Section 3, security may be impacted when replicating : among servers that implement non-standard extensions to basic LDAP : semantics. Access control is one common case which affects security; : work to address this issue is documented in RFC 2820 [RFC2820]. : : Add the new reference to the References: : : [RFC2820] E. Stokes, D. Byrne, B. Blakley, P. Behera, "Access : Control Requirements for LDAP", RFC 2820, May 2000. : : Change the draft number and the publication and expiration dates. : : As always, please send comments to the list. Rick Huber --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- : Subject: RE: WG Last Call on the LDAPv3 Directory Replication I-D : Thread-Topic: WG Last Call on the LDAPv3 Directory Replication I-D : Thread-Index: AcCP5HY9fw2/PIuYQC+oULzgUxaapgAgz+xQ : From: "Mark Brown (REDMOND)" : To: "John Strassner" , : Cc: "Chris Apple" , : =?iso-8859-1?Q?Patrik_F=E4ltstr=F6m?= : Sender: owner-ietf-ldup@mail.imc.org : : The LDAPv3 Directory Replication Requirements I-D document does : not address the interoperability limits issue that we discussed : in December-January. : : I append the most recent message on the topic. : : --mark : : -----Original Message----- : From: Mark Brown (REDMOND) : Sent: Thursday, January 11, 2001 7:41 PM : To: Ellen Stokes; Kurt D. Zeilenga : Cc: ietf-ldup@imc.org : Subject: RE: interoperability limits: proposed addition to : draft-ietf-ldup-replica-req-05.txt : : Oops, I left off the examples. Let's try again: : : I suggest inserting the following material right after : the first paragraph of Section 3 ("The Models") of the : requirements draft (just before the sentence "There are five : data consistency models.") : : --mark : : * * * * * : : The objective is limited to replication between directory servers : that implement a passive store fully described by its LDAP : interface. "Passive store" means that the servers are limited to : storing entries that come in via LDAP and retrieving those entries : later in response to LDAP requests. The entire semantics of : the passive store is defined by its LDAP interface. Any : restrictions on what the server can store must be : expressed in the server's schema, and any restrictions on the : access that clients have to the store must be expressed in terms : of a standardized LDAP access control scheme. This is in : contrast to an "active store" that implements triggers : or other rules that extend the semantics of entries beyond : what's implied by LDAP. Replication between such active : stores should be specified in extensions to LDUP. : : Here are some examples of ways in which directory servers : implement semantics that go beyond what the LDAP access : protocol defines: : : * Access control. LDAP does not currently define an access : control scheme. (The ldapext WG is working to extend LDAP : with an access control scheme.) Most directory servers : implement an access control scheme. : : Replication between directory servers with different : access control schemes would compromise directory security, : so such replication is not supported by LDUP. : : * Password policy. Some directory servers restrict changes : to password attributes, requiring that the new password : value conform to a specific security policy (e.g. the value : is sufficiently long and complex.) Doing so reduces the : security risk associated with passwords that are easy to : attack. : : Replication between directory servers with different : password policies (e.g. one server implements a password : policy and a second server implements no policy) would : compromise directory security, so such replication is not : supported by LDUP. : : * Password hashing. Some directory servers don't store a user's : password directly, but instead store one or more secure : hashes of the password. Doing so makes it less likely that : anyone (even an administrator) can discover the password. : : Replication between a directory server that stores passwords : and a directory server that stores only hashes will compromise : directory integrity, causing authentications to fail : unexpectedly, so such replication is not supported by LDUP. : : * * * * * : : -----Original Message----- : From: Mark Brown (REDMOND) : Sent: Thursday, January 11, 2001 3:10 PM : To: Ellen Stokes; 'Kurt D. Zeilenga' : Cc: ietf-ldup@imc.org : Subject: RE: interoperability limits: proposed addition to : draft-ietf-ldup-replica-req-05.txt : : : We appear to be in total agreement. : : So I suggest inserting the following paragraph right after : the first paragraph of Section 3 ("The Models") of the : requirements draft (just before the sentence "There are five : data consistency models.") : : --mark : : * * * * * : : The objective is limited to replication between directory servers : that implement a passive store fully described by its LDAP : interface. "Passive store" means that the servers are limited to : storing entries that come in via LDAP and retrieving those entries : later in response to LDAP requests. The entire semantics of : the passive store is defined by its LDAP interface. Any : restrictions on what the server can store must be : expressed in the server's schema, and any restrictions on the : access that clients have to the store must be expressed in terms : of a standardized LDAP access control scheme. This is in : contrast to an "active store" that implements triggers : or other rules that extend the semantics of entries beyond : what's implied by LDAP. Replication between such active : stores should be specified in extensions to LDUP. : : * * * * * : : --mark : : -----Original Message----- : From: Kurt D. Zeilenga [mailto:Kurt@OpenLDAP.org] : Sent: Tuesday, January 09, 2001 4:54 PM : To: Mark Brown (REDMOND) : Cc: Ellen Stokes; ietf-ldup@imc.org : Subject: RE: interoperability limits: proposed addition to : draft-ietf-ldup-replica-req-05.txt : : : Mark, : : Replication in the face of triggers or any other LDAP extension : should be specified in extensions to the LDUP. : : LDUP should assume 'passive' servers as this, I believe, is the : LDAP/X.500 data model. That is, servers should not muck with : user data. : : Kurt From owner-ietf-ldup@mail.imc.org Sat Feb 17 01:22:44 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id BAA19465 for ; Sat, 17 Feb 2001 01:22:43 -0500 (EST) Received: by above.proper.com (8.9.3/8.9.3) id VAA13048 for ietf-ldup-bks; Fri, 16 Feb 2001 21:36:43 -0800 (PST) Received: from relay1.pair.com (relay1.pair.com [209.68.1.20]) by above.proper.com (8.9.3/8.9.3) with SMTP id VAA13044 for ; Fri, 16 Feb 2001 21:36:37 -0800 (PST) Received: (qmail 16377 invoked from network); 17 Feb 2001 05:36:09 -0000 Received: from cpe-144-132-70-18.vic.bigpond.net.au (HELO w98) (144.132.70.18) by relay1.pair.com with SMTP; 17 Feb 2001 05:36:09 -0000 X-pair-Authenticated: 144.132.70.18 Reply-To: From: "Albert Langer" To: "'Ryan Moats'" , "'Mark Brown \(REDMOND\)'" , "'Richard V Huber'" , , Cc: , , , Subject: RE: WG Last Call on the LDAPv3 Directory Replication I-D Date: Sat, 17 Feb 2001 16:39:38 +1100 Message-ID: <002201c098a4$05120760$6628a8c0@nowhere.com> 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 CWS, Build 9.0.2416 (9.0.2910.0) Importance: Normal In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Sender: owner-ietf-ldup@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit [Ryan] John, Chris, do you have a sense of the working group from the list messages? I've not seen enough reaction to see whether we've got rough consensus one way or another, and I'm worried that this discussion threatens to become a rat-hole. [...] In the absence of an LDAP standard for access control, you can't have interoperability of access control in the IETF sense. However, I am not willing to delay this document for something that is the responsibility of another working group. The proper IETF procedure (as I understand it) is for this document to go forward and it become the responsibility of the access control draft authors to include the replication implications of the new standard. That avoids a "boil the ocean" conundrum preventing progress. [Albert] There is an overlap between the authors of the requirements draft and the authors of LDAP access control requirements and other drafts but a radical inconsistency between currently proposed access control schemes that rely on atomicity and the lack of understanding of atomicity issues in LDUP. The actual wording of the LDUP requirements does now require both atomicity and eventual convergence and is certainly a vast improvement on previous drafts, although it proposes that sysadmins should "boil the ocean" by resolving resulting problems manually. Unfortunately neither the wording nor that implication appears to be based on the actual understanding of members of the WG, as reflected in the current drafts for implementation, the minutes of WG meetings at IETF and non-normative explanatory notes in the draft. Chris has apparantly decided not to comment on the access control issue after first indicating that he would do so and being reminded of that. There may well be a "rough consensus" for proceeding on this basis, but I am certainly not part of it. As my views are already on the record I won't waste time repeating them here unless somebody else expresses interest. Put succinctly: LDUP directories won't interoperate. Period. From owner-ietf-ldup@mail.imc.org Sat Feb 17 11:33:10 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA05261 for ; Sat, 17 Feb 2001 11:33:10 -0500 (EST) Received: by above.proper.com (8.9.3/8.9.3) id HAA07242 for ietf-ldup-bks; Sat, 17 Feb 2001 07:56:42 -0800 (PST) Received: from pretender.boolean.net (root@router.boolean.net [198.144.206.49]) by above.proper.com (8.9.3/8.9.3) with ESMTP id HAA07238 for ; Sat, 17 Feb 2001 07:56:31 -0800 (PST) Received: from gypsy.OpenLDAP.org (gypsy.boolean.net [10.192.1.2]) by pretender.boolean.net (8.11.1/8.11.1/Boolean/Hub) with ESMTP id f1HFt9D11129; Sat, 17 Feb 2001 15:55:09 GMT (envelope-from Kurt@OpenLDAP.org) Message-Id: <5.0.2.1.0.20010217074033.00a53140@router.boolean.net> X-Sender: guru@router.boolean.net X-Mailer: QUALCOMM Windows Eudora Version 5.0.2 Date: Sat, 17 Feb 2001 07:55:08 -0800 To: From: "Kurt D. Zeilenga" Subject: RE: WG Last Call on the LDAPv3 Directory Replication I-D Cc: In-Reply-To: <002201c098a4$05120760$6628a8c0@nowhere.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:39 PM 2/17/01 +1100, Albert Langer wrote: >Put succinctly: LDUP directories won't interoperate. Period. I would say that two LDUP peers could interoperate (from a protocol perspective) but that this, in itself, does not: 1) preserve LDAP/X.500 semantics nor 2) provide "equally capable" replicas. The former issue can not be resolved unless one requires transactional consistency in multiple master replication. The latter issue can be tackled by writing a very tight applicability statements. Kurt From owner-ietf-ldup@mail.imc.org Sat Feb 17 11:47:23 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA05323 for ; Sat, 17 Feb 2001 11:47:22 -0500 (EST) Received: by above.proper.com (8.9.3/8.9.3) id IAA07434 for ietf-ldup-bks; Sat, 17 Feb 2001 08:11:49 -0800 (PST) Received: from mail.coreon.net (IDENT:mirapoint@mail.coreon.net [216.74.131.6]) by above.proper.com (8.9.3/8.9.3) with ESMTP id IAA07430 for ; Sat, 17 Feb 2001 08:11:47 -0800 (PST) Received: from rmoats2 (wenjus3.coreon.net [216.74.131.3]) by mail.coreon.net (Mirapoint) with ESMTP id AAB59319 (AUTH rmoats); Sat, 17 Feb 2001 11:03:36 -0500 (EST) From: "Ryan Moats" To: , "'Mark Brown \(REDMOND\)'" , "'Richard V Huber'" , , Cc: , , , Subject: RE: WG Last Call on the LDAPv3 Directory Replication I-D Date: Sat, 17 Feb 2001 10:08:07 -0600 Message-ID: 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 IMO, Build 9.0.2416 (9.0.2911.0) In-Reply-To: <002201c098a4$05120760$6628a8c0@nowhere.com> Importance: Normal 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: Content-Transfer-Encoding: 7bit Ok, since is quoted, I'll use ... this time... Ryan -----Original Message----- From: Albert Langer [mailto:Albert.Langer@Directory-Designs.org] Subject: RE: WG Last Call on the LDAPv3 Directory Replication I-D [Ryan] John, Chris, do you have a sense of the working group from the list messages? I've not seen enough reaction to see whether we've got rough consensus one way or another, and I'm worried that this discussion threatens to become a rat-hole. [...] In the absence of an LDAP standard for access control, you can't have interoperability of access control in the IETF sense. However, I am not willing to delay this document for something that is the responsibility of another working group. The proper IETF procedure (as I understand it) is for this document to go forward and it become the responsibility of the access control draft authors to include the replication implications of the new standard. That avoids a "boil the ocean" conundrum preventing progress. [Albert] There is an overlap between the authors of the requirements draft and the authors of LDAP access control requirements and other drafts but a radical inconsistency between currently proposed access control schemes that rely on atomicity and the lack of understanding of atomicity issues in LDUP. I'll admit I don't understand the technical point of this comment. The actual wording of the LDUP requirements does now require both atomicity ... Uh, it must support the propagation of atomicity information, that's different than requiring atomicity, imho. ...and eventual convergence and is certainly a vast improvement on previous drafts, although it proposes that sysadmins should "boil the ocean" by resolving resulting problems manually. I disagree. What it requires is that if conflict resolution would result in loss of data, ensure that the sysadmin is notified and can override if the algorithm is wrong. That is not unreasonable given the issues raised in Appendix B. Unfortunately neither the wording nor that implication appears to be based on the actual understanding of members of the WG, as reflected in the current drafts for implementation, the minutes of WG meetings at IETF and non-normative explanatory notes in the draft. Again I don't see the point of this comment. From owner-ietf-ldup@mail.imc.org Sat Feb 17 12:22:35 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA05628 for ; Sat, 17 Feb 2001 12:22:34 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.9.3/8.9.3) id IAA07817 for ietf-ldup-bks; Sat, 17 Feb 2001 08:37:12 -0800 (PST) Received: from mail.coreon.net (IDENT:mirapoint@mail.coreon.net [216.74.131.6]) by above.proper.com (8.9.3/8.9.3) with ESMTP id IAA07813 for ; Sat, 17 Feb 2001 08:37:10 -0800 (PST) Received: from rmoats2 (wenjus3.coreon.net [216.74.131.3]) by mail.coreon.net (Mirapoint) with ESMTP id AAB59911 (AUTH rmoats); Sat, 17 Feb 2001 11:12:06 -0500 (EST) From: "Ryan Moats" To: "Mark Brown \(REDMOND\)" , "Richard V Huber" , , Cc: , , , Subject: RE: WG Last Call on the LDAPv3 Directory Replication I-D Date: Sat, 17 Feb 2001 10:16:40 -0600 Message-ID: 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 IMO, Build 9.0.2416 (9.0.2911.0) In-Reply-To: Importance: Normal 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: Content-Transfer-Encoding: 7bit After some more reflection, I want to add some other comments to this thread that I hope will help... See ... below... Ryan -----Original Message----- From: Ryan Moats [mailto:rmoats@coreon.com] Subject: RE: WG Last Call on the LDAPv3 Directory Replication I-D John, Chris, do you have a sense of the working group from the list messages? I've not seen enough reaction to see whether we've got rough consensus one way or another, and I'm worried that this discussion threatens to become a rat-hole. See ... below... Ryan -----Original Message----- From: Mark Brown (REDMOND) [mailto:mabrown@Exchange.Microsoft.com] Subject: RE: WG Last Call on the LDAPv3 Directory Replication I-D ... ... A standard mechanism for directory replication in a multi-vendor environment is critical to the continued success of LDAP in the market place. This document sets out the requirements for replication between multiple standard-conformant LDAP servers. ... ^^^^^^^^^^^^^^^^^^^ <- new text ... An LDAP server that implements semantics not mentioned in the LDAP RFCs does not thereby become non-standard-conformant. Never said it didn't For instance, most LDAP servers today implement an access control scheme. No access control scheme is mentioned in the LDAP RFCs. Yet LDAP servers that implement access control are conformant with the LDAP standard. In the absence of an LDAP standard for access control, you can't have interoperability of access control in the IETF sense. However, I am not willing to delay this document for something that is the responsibility of another working group. The proper IETF procedure (as I understand it) is for this document to go forward and it become the responsibility of the access control draft authors to include the replication implications of the new standard. That avoids a "boil the ocean" conundrum preventing progress. Similarly, a server that implements internal triggers for the purpose of maintaining certain invariants in the directory can conform with the LDAP standard. Again, in the absence of an LDAP standard for internal triggers you can't have IETF interoperability to replicate that information with LDUP. If you want interoperability in replicating internal triggers, the proper process is to develop an RFC and address the issues there. These two cases are examples of where LDUP won't replicate the semantics. My point is that while it is probably worthwhile to point out this issue in an LDUP document (and I think I know which one should handle it), I don't think its right to point it out in *this* document. As to active versus passive, I can (as a gedanken experiment) postulate a system that uses application triggers for some purpose and whose information, including that used in the triggers could be replicated via LDUP in a single-master environment. While this is a convoluted case, I think it does point out that making the "passive" comment is too restrictive. LDUP is designed to solve the problem of replicating the representations of directories. But the correspondence between these representations and the LDAP protocol is not a simple one in general -- it is only simple for directories that are completely passive stores. When LDUP is used to replicate (the representations of) non-passive stores, it is up to the developers of those stores, not LDUP, to define how to achieve interoperability. (Most likely, they'll do this pairwise.) Readers of the requirements draft, even with your proposed amendment, are likely to think that LDUP is meant to provide interoperability between directories rather than between their representations. They are likely to blame LDAP directory implementors for not providing the same degree of interoperability as, say, DNS server implementors do. As Kurt says down at the start of this thread, that's not LDUP's job. It is worth adding a paragraph to the draft so that it says so clearly. I claim we've addressed the issue already in -06 and with the suggested text above. Therefore, at this point, I think I'd like to ask the chairs to get a sense of the mailing list to see if we have rough-consensus, because I can see argument turning into a rat-hole. --mark -----Original Message----- From: Ryan Moats [mailto:rmoats@coreon.net] Sent: Friday, February 16, 2001 12:40 PM To: Mark Brown (REDMOND); Richard V Huber; ietf-ldup@imc.org; johns@cisco.com Cc: capple@ecal.com; paf@cisco.com; rmoats@coreon.net; rweiser@digsigtrust.com; stokes@austin.ibm.com Subject: RE: WG Last Call on the LDAPv3 Directory Replication I-D See ... below... Ryan -----Original Message----- From: Mark Brown (REDMOND) [mailto:mabrown@Exchange.Microsoft.com] Sent: Tuesday, February 13, 2001 8:38 PM To: Richard V Huber; ietf-ldup@imc.org; johns@cisco.com Cc: capple@ecal.com; paf@cisco.com; rmoats@coreon.net; rweiser@digsigtrust.com; stokes@austin.ibm.com Subject: RE: WG Last Call on the LDAPv3 Directory Replication I-D So sorry -- I missed those changes when the -06 version came out. Shortening my suggested addition seems like a good idea. Good But the intent of my suggestion was to set a clear requirement for LDUP's ability to provide interoperability. That way, as other LDUP drafts progress, we'll be able to tell if they are meeting the goal set in the requirements. I personally am willing to do the following text adjustment, (the other authors still get to comment)... ... A standard mechanism for directory replication in a multi-vendor environment is critical to the continued success of LDAP in the market place. This document sets out the requirements for replication between multiple standard-conformant LDAP servers. ... ^^^^^^^^^^^^^^^^^^^ <- new text Beyond this, I disagree that LDUP requirements need to be stated to cover items that don't have an LDAP standard yet. Any new LDAP standard should cover the impact of replication on that standard, not the other way around. Since we are doing this work in the IETF, interoperability should be one of the primary concerns of the work. But the proposed text : Interoperability of replicas between directory servers may be limited : by servers that implement semantics that go beyond what the LDAP : access protocol defines. Examples (not an exhaustive list) of such : semantics include: (1) replication among directory servers with : different access control systems/semantics may compromise directory : security, and (2) replication among directory servers with different : application trigger semantics may compromise directory data : integrity. does not set a clear requirement for LDUP's ability to provide interoperability. It says that when we are done designing LDUP, it is OK that certain directory servers will not be able to replicate. It does not say that for the LDUP design to be considered a viable IETF standard, it is necessary that there is some pair of directory servers (not from the same code base) that LDUP enables to replicate. Of course, we don't want to state such a goal in terms like "LDUP will enable OpenLDAP and the Siemens DS to replicate," we want to state the goal in terms of the functional characteristics of a pair of systems that are able to replicate. That's what my suggested text tried to do. How about this: : The goal of LDUP is to support replication between directory servers : that each implements a passive store fully described by its LDAP interface. : "Passive store" means that the servers are limited to storing entries that : come in via LDAP and retrieving those identical entries later in response : to LDAP requests. The entire semantics of such a store is defined by its : LDAP interface. Any restrictions on what the server can store must be : expressed in the server's schema, and any restrictions on the access that : clients have to the store must be expressed in terms of a standardized : LDAP access control scheme. : : LDUP is not required to support replication between directory : servers that each implements an active store extending LDAP : semantics with non-standard access control rules or with triggers. : Examples of triggers include password length/complexity policies and : automatic storage of secure password hashes instead of passwords. --mark -----Original Message----- From: Richard V Huber [mailto:rvh@qsun.mt.att.com] Sent: Tuesday, February 06, 2001 12:52 PM To: ietf-ldup@imc.org; johns@cisco.com; Mark Brown (REDMOND) Cc: capple@ecal.com; paf@cisco.com; rmoats@coreon.com; rweiser@digsigtrust.com; stokes@austin.ibm.com Subject: RE: WG Last Call on the LDAPv3 Directory Replication I-D We addressed these issues in version -06, though we cut down the text. Here is the summary that was included when I sent version -06 to the list. I haven't seen any comments on it since it was posted. : Internet Drafts Editor - : : Please publish the draft below as draft-ietf-ldup-replica-req-06.txt : It replaces the -05 draft from November. : : LDUP Mailing list - : : The attached version of the draft incorporates changes to address the : comments from San Diego. We trimmed Mark's proposed changes since we : were concerned that they went into too much detail that wasn't really : LDUP related. : : Our specific changes are: : : Insert the following as the last paragraph in Section 3: : : Interoperability of replicas between directory servers may be limited : by servers that implement semantics that go beyond what the LDAP : access protocol defines. Examples (not an exhaustive list) of such : semantics include: (1) replication among directory servers with : different access control systems/semantics may compromise directory : security, and (2) replication among directory servers with different : application trigger semantics may compromise directory data : integrity. : : Add the following at the end of the Security Considerations Section: : : As noted in Section 3, security may be impacted when replicating : among servers that implement non-standard extensions to basic LDAP : semantics. Access control is one common case which affects security; : work to address this issue is documented in RFC 2820 [RFC2820]. : : Add the new reference to the References: : : [RFC2820] E. Stokes, D. Byrne, B. Blakley, P. Behera, "Access : Control Requirements for LDAP", RFC 2820, May 2000. : : Change the draft number and the publication and expiration dates. : : As always, please send comments to the list. Rick Huber --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- : Subject: RE: WG Last Call on the LDAPv3 Directory Replication I-D : Thread-Topic: WG Last Call on the LDAPv3 Directory Replication I-D : Thread-Index: AcCP5HY9fw2/PIuYQC+oULzgUxaapgAgz+xQ : From: "Mark Brown (REDMOND)" : To: "John Strassner" , : Cc: "Chris Apple" , : =?iso-8859-1?Q?Patrik_F=E4ltstr=F6m?= : Sender: owner-ietf-ldup@mail.imc.org : : The LDAPv3 Directory Replication Requirements I-D document does : not address the interoperability limits issue that we discussed : in December-January. : : I append the most recent message on the topic. : : --mark : : -----Original Message----- : From: Mark Brown (REDMOND) : Sent: Thursday, January 11, 2001 7:41 PM : To: Ellen Stokes; Kurt D. Zeilenga : Cc: ietf-ldup@imc.org : Subject: RE: interoperability limits: proposed addition to : draft-ietf-ldup-replica-req-05.txt : : Oops, I left off the examples. Let's try again: : : I suggest inserting the following material right after : the first paragraph of Section 3 ("The Models") of the : requirements draft (just before the sentence "There are five : data consistency models.") : : --mark : : * * * * * : : The objective is limited to replication between directory servers : that implement a passive store fully described by its LDAP : interface. "Passive store" means that the servers are limited to : storing entries that come in via LDAP and retrieving those entries : later in response to LDAP requests. The entire semantics of : the passive store is defined by its LDAP interface. Any : restrictions on what the server can store must be : expressed in the server's schema, and any restrictions on the : access that clients have to the store must be expressed in terms : of a standardized LDAP access control scheme. This is in : contrast to an "active store" that implements triggers : or other rules that extend the semantics of entries beyond : what's implied by LDAP. Replication between such active : stores should be specified in extensions to LDUP. : : Here are some examples of ways in which directory servers : implement semantics that go beyond what the LDAP access : protocol defines: : : * Access control. LDAP does not currently define an access : control scheme. (The ldapext WG is working to extend LDAP : with an access control scheme.) Most directory servers : implement an access control scheme. : : Replication between directory servers with different : access control schemes would compromise directory security, : so such replication is not supported by LDUP. : : * Password policy. Some directory servers restrict changes : to password attributes, requiring that the new password : value conform to a specific security policy (e.g. the value : is sufficiently long and complex.) Doing so reduces the : security risk associated with passwords that are easy to : attack. : : Replication between directory servers with different : password policies (e.g. one server implements a password : policy and a second server implements no policy) would : compromise directory security, so such replication is not : supported by LDUP. : : * Password hashing. Some directory servers don't store a user's : password directly, but instead store one or more secure : hashes of the password. Doing so makes it less likely that : anyone (even an administrator) can discover the password. : : Replication between a directory server that stores passwords : and a directory server that stores only hashes will compromise : directory integrity, causing authentications to fail : unexpectedly, so such replication is not supported by LDUP. : : * * * * * : : -----Original Message----- : From: Mark Brown (REDMOND) : Sent: Thursday, January 11, 2001 3:10 PM : To: Ellen Stokes; 'Kurt D. Zeilenga' : Cc: ietf-ldup@imc.org : Subject: RE: interoperability limits: proposed addition to : draft-ietf-ldup-replica-req-05.txt : : : We appear to be in total agreement. : : So I suggest inserting the following paragraph right after : the first paragraph of Section 3 ("The Models") of the : requirements draft (just before the sentence "There are five : data consistency models.") : : --mark : : * * * * * : : The objective is limited to replication between directory servers : that implement a passive store fully described by its LDAP : interface. "Passive store" means that the servers are limited to : storing entries that come in via LDAP and retrieving those entries : later in response to LDAP requests. The entire semantics of : the passive store is defined by its LDAP interface. Any : restrictions on what the server can store must be : expressed in the server's schema, and any restrictions on the : access that clients have to the store must be expressed in terms : of a standardized LDAP access control scheme. This is in : contrast to an "active store" that implements triggers : or other rules that extend the semantics of entries beyond : what's implied by LDAP. Replication between such active : stores should be specified in extensions to LDUP. : : * * * * * : : --mark : : -----Original Message----- : From: Kurt D. Zeilenga [mailto:Kurt@OpenLDAP.org] : Sent: Tuesday, January 09, 2001 4:54 PM : To: Mark Brown (REDMOND) : Cc: Ellen Stokes; ietf-ldup@imc.org : Subject: RE: interoperability limits: proposed addition to : draft-ietf-ldup-replica-req-05.txt : : : Mark, : : Replication in the face of triggers or any other LDAP extension : should be specified in extensions to the LDUP. : : LDUP should assume 'passive' servers as this, I believe, is the : LDAP/X.500 data model. That is, servers should not muck with : user data. : : Kurt From owner-ietf-ldup@mail.imc.org Sat Feb 17 12:43:41 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA05777 for ; Sat, 17 Feb 2001 12:43:40 -0500 (EST) Received: by above.proper.com (8.9.3/8.9.3) id JAA09494 for ietf-ldup-bks; Sat, 17 Feb 2001 09:14:29 -0800 (PST) Received: from pretender.boolean.net (root@router.boolean.net [198.144.206.49]) by above.proper.com (8.9.3/8.9.3) with ESMTP id JAA09487 for ; Sat, 17 Feb 2001 09:14:28 -0800 (PST) Received: from gypsy.OpenLDAP.org (gypsy.boolean.net [10.192.1.2]) by pretender.boolean.net (8.11.1/8.11.1/Boolean/Hub) with ESMTP id f1HHD6D11304; Sat, 17 Feb 2001 17:13:06 GMT (envelope-from Kurt@OpenLDAP.org) Message-Id: <5.0.2.1.0.20010217081710.00a559e0@router.boolean.net> X-Sender: guru@router.boolean.net X-Mailer: QUALCOMM Windows Eudora Version 5.0.2 Date: Sat, 17 Feb 2001 09:13:05 -0800 To: "'Ryan Moats'" From: "Kurt D. Zeilenga" Subject: RE: WG Last Call on the LDAPv3 Directory Replication I-D Cc: In-Reply-To: <002201c098a4$05120760$6628a8c0@nowhere.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:39 PM 2/17/01 +1100, Ryan Moats wrote: >However, I am not willing >to delay this document for something that is the >responsibility of another working group. The proper >IETF procedure (as I understand it) is for this document >to go forward and it become the responsibility of >the access control draft authors to include the replication >implications of the new standard. I disagree. I assert that LDAP ACM replication issues are NOT within scope of LDAPext WG and are properly addressed within documents produced by the LDUP WG. Kurt From owner-ietf-ldup@mail.imc.org Sat Feb 17 16:00:11 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA07106 for ; Sat, 17 Feb 2001 16:00:10 -0500 (EST) Received: by above.proper.com (8.9.3/8.9.3) id MAA18366 for ietf-ldup-bks; Sat, 17 Feb 2001 12:27:45 -0800 (PST) Received: from relay1.pair.com (relay1.pair.com [209.68.1.20]) by above.proper.com (8.9.3/8.9.3) with SMTP id MAA18343 for ; Sat, 17 Feb 2001 12:27:36 -0800 (PST) Received: (qmail 4062 invoked from network); 17 Feb 2001 20:27:07 -0000 Received: from cpe-144-132-70-18.vic.bigpond.net.au (HELO w98) (144.132.70.18) by relay1.pair.com with SMTP; 17 Feb 2001 20:27:07 -0000 X-pair-Authenticated: 144.132.70.18 Reply-To: From: "Albert Langer" To: "'Kurt D. Zeilenga'" Cc: Subject: RE: WG Last Call on the LDAPv3 Directory Replication I-D Date: Sun, 18 Feb 2001 07:30:51 +1100 Message-ID: <002701c09920$85d97c80$6628a8c0@nowhere.com> 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 CWS, Build 9.0.2416 (9.0.2910.0) Importance: Normal In-Reply-To: <5.0.2.1.0.20010217074033.00a53140@router.boolean.net> X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Sender: owner-ietf-ldup@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit [Kurt] At 04:39 PM 2/17/01 +1100, Albert Langer wrote: >Put succinctly: LDUP directories won't interoperate. Period. I would say that two LDUP peers could interoperate (from a protocol perspective) but that this, in itself, does not: 1) preserve LDAP/X.500 semantics nor 2) provide "equally capable" replicas. The former issue can not be resolved unless one requires transactional consistency in multiple master replication. The latter issue can be tackled by writing a very tight applicability statements. [Albert] We seem to be agreed that "LDUP directories won't interoperate" (unless of course you mean that an LDUP directory need not preserve LDAP semantics - which seems implausible ;-) If by "transactional" consistency you are referring to updates affecting more than one directory entry, that is not part of LDAP semantics. If you mean "atomic operations", that is part of LDAP semantics and I certainly agree that the issue cannot be resolved without it ;-) A necessary consequence of multi-master, as opposed to single master, is that in addition to transient inconsitencies between data read from different directory servers there will also be problems with data read from a single server. There are 2 options possible for multi-master: 1) Conflicting updates to the same entry are prioritized so that only one succeeds and the others are rolled back. That necessarily results in different behaviour to single master directories but is not fundamentally inconsistent with LDAP semantics and does not prevent interoperability. Problems arising can be resolved by users rather than sysadmins by notifying them of lost updates (whether due to name conflicts or other conflicts). An applicability statement should clearly indicate that multi-master is unsuitable in any situation with a high rate of concurrent changes to the same entries. 2) Changes are not "rolled back" so, by definition, atomicity is not preserved when updates conflict. This necessarily results in both transient and permanent loss of data integrity. In particular it breaks currently proposed access control mechanisms. I mention it as an "option" only because it is the current architecture, not because it has any technical merit whatever. An "inapplicability statement" should then clearly indicate that multi-master is unsuitable in any situation that requires data integrity. Since interoperable directories require high integrity access control mechanisms that means it is simply "not applicable". From owner-ietf-ldup@mail.imc.org Sat Feb 17 16:08:57 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA07232 for ; Sat, 17 Feb 2001 16:08:56 -0500 (EST) Received: by above.proper.com (8.9.3/8.9.3) id MAA21042 for ietf-ldup-bks; Sat, 17 Feb 2001 12:43:39 -0800 (PST) Received: from sj-msg-core-4.cisco.com (sj-msg-core-4.cisco.com [171.71.163.10]) by above.proper.com (8.9.3/8.9.3) with ESMTP id MAA21032 for ; Sat, 17 Feb 2001 12:43:37 -0800 (PST) Received: from mira-sjcm-1.cisco.com (mira-sjcm-1.cisco.com [171.69.2.212]) by sj-msg-core-4.cisco.com (8.9.3/8.9.1) with ESMTP id MAA00989 for ; Sat, 17 Feb 2001 12:43:12 -0800 (PST) Received: from JSTRASSN-W2K1.cisco.com (sj-dial-4-6.cisco.com [171.68.181.135]) by mira-sjcm-1.cisco.com (Mirapoint) with ESMTP id ALO02182; Sat, 17 Feb 2001 12:43:07 -0800 (PST) Message-Id: <4.3.2.7.2.20010217124030.00b69ce0@mira-sjcm-1.cisco.com> X-Sender: jstrassn@mira-sjcm-1.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Sat, 17 Feb 2001 12:42:57 -0800 To: ietf-ldup@imc.org From: John Strassner Subject: Our Meeting Dates Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ietf-ldup@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: LDUPers, our meeting dates haven't changed, but I haven't seen my original message on the list. So, here it is again: TUESDAY, March 20, 2001 0900-1130 Morning Sessions APP ldup LDAP Duplication/Replication/Update Protocols WG INT dhc Dynamic Host Configuration WG OPS opsarea Operations & Management Open Area RTG msdp Multicast Source Discovery Protocol WG SEC ipsra IP Security Remote Access WG TSV sip Session Initiation Protocol WG regards, John From owner-ietf-ldup@mail.imc.org Sat Feb 17 16:09:09 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA07244 for ; Sat, 17 Feb 2001 16:09:09 -0500 (EST) Received: by above.proper.com (8.9.3/8.9.3) id MAA21129 for ietf-ldup-bks; Sat, 17 Feb 2001 12:44:08 -0800 (PST) Received: from relay1.pair.com (relay1.pair.com [209.68.1.20]) by above.proper.com (8.9.3/8.9.3) with SMTP id MAA21121 for ; Sat, 17 Feb 2001 12:44:07 -0800 (PST) Received: (qmail 3305 invoked from network); 17 Feb 2001 20:43:38 -0000 Received: from cpe-144-132-70-18.vic.bigpond.net.au (HELO w98) (144.132.70.18) by relay1.pair.com with SMTP; 17 Feb 2001 20:43:38 -0000 X-pair-Authenticated: 144.132.70.18 Reply-To: From: "Albert Langer" To: "'John Strassner'" , Cc: "'Chris Apple'" , "=?iso-8859-1?Q?'Patrik_F=E4ltstr=F6m'?=" Subject: RE: WG Last Call on the LDAPv3 Directory Replication I-D Date: Sun, 18 Feb 2001 07:47:23 +1100 Message-ID: <002901c09922$d4b45620$6628a8c0@nowhere.com> 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 CWS, Build 9.0.2416 (9.0.2910.0) Importance: Normal In-Reply-To: <00d201c08fe3$6a348970$fc836b80@cisco.com> X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Sender: owner-ietf-ldup@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit [John and Chris] Silence means consent. Read, enjoy, and send your comments in! regards, John Strassner and Chris Apple [Albert] Could you please explain why a revised WG charter dated 10 February 2001 was posted to: http://www.ietf.org/html.charters/ldup-charter.html with revised dates some of which expired the previous month, and with a schedule to adopt URP as a "proposed standard" 3 months prior to finalizing the architecture and information model? I objected formally to both those aspects: http://www.imc.org/ietf-ldup/mail-archive/msg00784.html I have checked the archives and am not aware of any response to those objections from the WG co-chairs or any attempt to seek a consensus from the WG about them nor even any announcement to the WG that a consensus has in fact been reached. There were also some other comments and questions from Timothy Hahn: http://www.imc.org/ietf-ldup/mail-archive/msg00791.html These included at least one minor editorial correction (typo) which I cannot imagine anybody would have taken exception to. Therefore I am inclined to assume the document was simply posted "as is" without bothering to consider any comments made on it, despite having asked for comments. Was that the case? Who took the decision, and why were we not informed? From owner-ietf-ldup@mail.imc.org Sat Feb 17 16:43:25 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA07702 for ; Sat, 17 Feb 2001 16:43:25 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.9.3/8.9.3) id NAA25670 for ietf-ldup-bks; Sat, 17 Feb 2001 13:16:59 -0800 (PST) Received: from sj-msg-core-2.cisco.com (sj-msg-core-2.cisco.com [171.69.43.88]) by above.proper.com (8.9.3/8.9.3) with ESMTP id NAA25662 for ; Sat, 17 Feb 2001 13:16:57 -0800 (PST) Received: from mira-sjcm-1.cisco.com (mira-sjcm-1.cisco.com [171.69.2.212]) by sj-msg-core-2.cisco.com (8.9.3/8.9.1) with ESMTP id NAA15955; Sat, 17 Feb 2001 13:16:42 -0800 (PST) Received: from JSTRASSN-W2K1.cisco.com (sj-dial-4-6.cisco.com [171.68.181.135]) by mira-sjcm-1.cisco.com (Mirapoint) with ESMTP id ALO02291; Sat, 17 Feb 2001 13:16:21 -0800 (PST) Message-Id: <4.3.2.7.2.20010217130057.00b32598@mira-sjcm-1.cisco.com> X-Sender: jstrassn@mira-sjcm-1.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Sat, 17 Feb 2001 13:16:12 -0800 To: From: John Strassner Subject: RE: WG Last Call on the LDAPv3 Directory Replication I-D Cc: "'John Strassner'" , , "'Chris Apple'" , =?iso-8859-1?Q?=22=27Patrik_F=E4ltstr=F6m=27=22?= In-Reply-To: <002901c09922$d4b45620$6628a8c0@nowhere.com> References: <00d201c08fe3$6a348970$fc836b80@cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ietf-ldup@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Albert, I posted the revised charter for discussion for this group. You were the only person that made a comment. If you would be so kind as to actually read the charter, you'll find that your complaint of having LDUP appoint two liaisons was dropped from the charter. As far as your complaint: [revision] Jan 01 LDAPv3 Directory Replication Requirements I-D goes to WG Last Call as Informational. Jan 01 LDAPv3 Update Reconciliation Procedures I-D goes to WG Last Call as Proposed Standard. [Albert] I do not think it is appropriate to issue new deadlines that have already passed. I would point out that Jan 01 means by the end of January, not 1 January. We did successfully meet the first objective. We didn't meet the second objective because we had some comments on the requirements draft, and I felt uncomfortable issuing URP for last call until we had passed last call for the requirements draft. You objected that you haven't seen any mailing list activity on the drafts from the new authors. The minutes simply said that the new authors would write these drafts and make every effort to get them posted in the repository before the next cut-off date. It didn't say that we had to discuss a draft that hadn't been written yet. As far as your unprofessional remark about URP, you are the only person objecting to it. Therefore, in the face of only one objection, and considering that we did discuss charter updates at the WG meeting, there was clear consent of the working group for adopting this new charter. The charter was so adopted. I didn't issue a note to the working group because I was, and still am, ON VACATION. I will now issue such a note, even though I am still ON VACATION. As far as Tim's message, I simply did not see it. Thanks for the link, I'll take a look at it, and we can discuss the changes on the list next week, when I'm back from vacation. John At 07:47 AM 2/18/2001 +1100, Albert Langer wrote: >[John and Chris] >Silence means consent. > >Read, enjoy, and send your comments in! > >regards, >John Strassner and Chris Apple > >[Albert] >Could you please explain why a revised WG charter dated 10 February 2001 was >posted to: > >http://www.ietf.org/html.charters/ldup-charter.html > >with revised dates some of which expired the previous month, and with a >schedule to >adopt URP as a "proposed standard" 3 months prior to finalizing the >architecture >and information model? > >I objected formally to both those aspects: > >http://www.imc.org/ietf-ldup/mail-archive/msg00784.html > >I have checked the archives and am not aware of any response to those >objections from the WG co-chairs or any attempt to seek a consensus from the >WG about them nor even any announcement to the WG that a consensus has in >fact been reached. > >There were also some other comments and questions from Timothy Hahn: > >http://www.imc.org/ietf-ldup/mail-archive/msg00791.html > >These included at least one minor editorial correction (typo) which I cannot >imagine anybody would have taken exception to. Therefore I am inclined to >assume the document was simply posted "as is" without bothering to consider >any comments made on it, despite having asked for comments. > >Was that the case? > >Who took the decision, and why were we not informed? From owner-ietf-ldup@mail.imc.org Sat Feb 17 16:58:19 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA07809 for ; Sat, 17 Feb 2001 16:58:18 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.9.3/8.9.3) id MAA18705 for ietf-ldup-bks; Sat, 17 Feb 2001 12:30:29 -0800 (PST) Received: from relay1.pair.com (relay1.pair.com [209.68.1.20]) by above.proper.com (8.9.3/8.9.3) with SMTP id MAA18699 for ; Sat, 17 Feb 2001 12:30:28 -0800 (PST) Received: (qmail 8934 invoked from network); 17 Feb 2001 20:29:59 -0000 Received: from cpe-144-132-70-18.vic.bigpond.net.au (HELO w98) (144.132.70.18) by relay1.pair.com with SMTP; 17 Feb 2001 20:29:59 -0000 X-pair-Authenticated: 144.132.70.18 Reply-To: From: "Albert Langer" To: "'Ryan Moats'" , "'Mark Brown \(REDMOND\)'" , "'Richard V Huber'" , , Cc: , , , Subject: RE: WG Last Call on the LDAPv3 Directory Replication I-D Date: Sun, 18 Feb 2001 07:33:41 +1100 Message-ID: <002801c09920$eaf1eb20$6628a8c0@nowhere.com> 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 CWS, Build 9.0.2416 (9.0.2910.0) Importance: Normal In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Sender: owner-ietf-ldup@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit [Albert] There is an overlap between the authors of the requirements draft and the authors of LDAP access control requirements and other drafts but a radical inconsistency between currently proposed access control schemes that rely on atomicity and the lack of understanding of atomicity issues in LDUP. I'll admit I don't understand the technical point of this comment. [Albert] Try plugging examples similar to those discussed in Appendix B using access control attributes as specified in current access control drafts, taking into account the transient outcomes I quoted from Alison's discussion of URP consistency model in: http://www.imc.org/ietf-ldup/mail-archive/msg00738.html BTW That message is actually Chris's reply, disrupting an attempt to discuss this issue and other issues with Rick, from which I hope you will understand why I am not currently inclined to pursue the issue in this forum. I believe Chris should respond as he said he would, instead of just forgetting about it after delivering himself of that tirade. [Albert] The actual wording of the LDUP requirements does now require both atomicity ... Uh, it must support the propagation of atomicity information, that's different than requiring atomicity, imho. ...and eventual convergence and is certainly a vast improvement on previous drafts, although it proposes that sysadmins should "boil the ocean" by resolving resulting problems manually. I disagree. What it requires is that if conflict resolution would result in loss of data, ensure that the sysadmin is notified and can override if the algorithm is wrong. That is not unreasonable given the issues raised in Appendix B. [Albert] Ok, "support the propagation of atomicity information" is different from requiring atomicity. The difference is essentially that the protocols are required to maintain all the information necessary to notify admins about problems but are not required to fix the problems. That is what I meant by "it proposes that sysadmins should 'boil the ocean' by resolving resulting problems manually". I still regard it as a vast improvement on the previous because it clearly rules out the current architecture and URP, which is not capable of maintaining the information needed to notify admins as required. I disagree with the analysis in appendix B, but it is explicitly stated to be not part of the actual requirements. Once an architecture is adopted that *is* capable of meeting the requirements mandated for notification to sysadmins, I believe it will become obvious that it makes more sense to actually fix the problems by rollbacks and notifications to users. [Albert] Unfortunately neither the wording nor that implication appears to be based on the actual understanding of members of the WG, as reflected in the current drafts for implementation, the minutes of WG meetings at IETF and non-normative explanatory notes in the draft. Again I don't see the point of this comment. [Albert] The minutes show that the same meeting which agreed the requirements draft was ready for final call also agreed that the URP was ready for final call despite the fact that it is incapable of meeting the requirements as stated. The "non-normative explanatory notes" I was referring to are mainly the Appendix B you mention. In addition the current drafts do not meet the requirement for eventual convergence (although they are capable of being fixed to do so, unlike their fundamental inability to propagate atomicity information needed for notification requirements). Although the plain words of the document unambiguously rule out URP, I am not under any illusion that this reflects a consensus of the WG to do so. Consequently I do not believe adoption of the requirements will in fact resolve the most important requirements issues and am therefore not part of any consensus to adopt them - although I will certainly elaborate on the requirements not met by URP when that comes up. From owner-ietf-ldup@mail.imc.org Sat Feb 17 17:14:54 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA07911 for ; Sat, 17 Feb 2001 17:14:54 -0500 (EST) Received: by above.proper.com (8.9.3/8.9.3) id NAA29777 for ietf-ldup-bks; Sat, 17 Feb 2001 13:48:39 -0800 (PST) Received: from pretender.boolean.net (root@router.boolean.net [198.144.206.49]) by above.proper.com (8.9.3/8.9.3) with ESMTP id NAA29772 for ; Sat, 17 Feb 2001 13:48:38 -0800 (PST) Received: from gypsy.OpenLDAP.org (gypsy.boolean.net [10.192.1.2]) by pretender.boolean.net (8.11.1/8.11.1/Boolean/Hub) with ESMTP id f1HLlaD11900; Sat, 17 Feb 2001 21:47:36 GMT (envelope-from Kurt@OpenLDAP.org) Message-Id: <5.0.2.1.0.20010217130809.00a693a0@router.boolean.net> X-Sender: guru@router.boolean.net X-Mailer: QUALCOMM Windows Eudora Version 5.0.2 Date: Sat, 17 Feb 2001 13:47:35 -0800 To: From: "Kurt D. Zeilenga" Subject: RE: WG Last Call on the LDAPv3 Directory Replication I-D Cc: In-Reply-To: <002701c09920$85d97c80$6628a8c0@nowhere.com> References: <5.0.2.1.0.20010217074033.00a53140@router.boolean.net> 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 07:30 AM 2/18/01 +1100, Albert Langer wrote: >If by "transactional" consistency you are referring to updates affecting >more than one directory entry, that is not part of LDAP semantics. I am using the term "transactional consistency", I hope, as defined by LDUP requirements I-D. X.500 and LDAP state that all modifications requested as part of a single modify happen as a single atomic action. Using this feature, applications can (and do) build mutually exclusive locks, semaphores, monotonically increasing counters, and other structures used for application synchronization purposes. This feature is preserved by X.500 data model as it supports only single master replication. It is not possible to build these structures in multiple master environments without "transactional consistency". >An applicability statement should clearly indicate >that multi-master is unsuitable in any situation with a high rate of >concurrent changes to the same entries. Change "high" to "any" and I would concur. Kurt From owner-ietf-ldup@mail.imc.org Sat Feb 17 17:15:19 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA07923 for ; Sat, 17 Feb 2001 17:15:18 -0500 (EST) Received: by above.proper.com (8.9.3/8.9.3) id NAA00267 for ietf-ldup-bks; Sat, 17 Feb 2001 13:51:26 -0800 (PST) Received: from mail.coreon.net (IDENT:mirapoint@mail.coreon.net [216.74.131.6]) by above.proper.com (8.9.3/8.9.3) with ESMTP id NAA00262 for ; Sat, 17 Feb 2001 13:51:24 -0800 (PST) Received: from mail.coreon.net (mail.coreon.net [216.74.131.6]) by mail.coreon.net (Mirapoint) with SMTP id AAB75297; Sat, 17 Feb 2001 15:14:59 -0500 (EST) From: Message-Id: <200102172014.AAB75297@mail.coreon.net> Date: Sat, 17 Feb 2001 15:12:39 -0500 Subject: RE: WG Last Call on the LDAPv3 Directory Replication I-D To: "Kurt D. Zeilenga" Cc: ietf-ldup@imc.org 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 ---- >Date: Sat, 17 Feb 2001 09:13:05 -0800 >From: "Kurt D. Zeilenga" >Subject: RE: WG Last Call on the LDAPv3 Directory Replication I-D >To: "'Ryan Moats'" >Cc: > >At 04:39 PM 2/17/01 +1100, Ryan Moats wrote: >>However, I am not willing >>to delay this document for something that is the >>responsibility of another working group. The proper >>IETF procedure (as I understand it) is for this document >>to go forward and it become the responsibility of >>the access control draft authors to include the replication >>implications of the new standard. > >I disagree. I assert that LDAP ACM replication issues are >NOT within scope of LDAPext WG and are properly addressed >within documents produced by the LDUP WG. > >Kurt Well, I think LDUP should NOT be responsible for trying to address the replication issues of a to be standard document that isn't finished yet in another WG. That's not the way things have been handled in the IETF in my experience and I believe its a real good way to halt progress through charter creep. I say this because I fear someone whould take your argument and publish a -00 I-D draft related to LDAP, have LDAPEXT (or some other WG) agree that it should eventually be standard track and then come to LDUP and say "LDUP must handle replicating this -00 draft". I don't believe this is a desireable situation. Ryan From owner-ietf-ldup@mail.imc.org Sat Feb 17 19:27:22 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA08841 for ; Sat, 17 Feb 2001 19:27:21 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.9.3/8.9.3) id PAA15725 for ietf-ldup-bks; Sat, 17 Feb 2001 15:55:59 -0800 (PST) Received: from relay1.pair.com (relay1.pair.com [209.68.1.20]) by above.proper.com (8.9.3/8.9.3) with SMTP id PAA15721 for ; Sat, 17 Feb 2001 15:55:57 -0800 (PST) Received: (qmail 6813 invoked from network); 17 Feb 2001 23:55:28 -0000 Received: from cpe-144-132-70-18.vic.bigpond.net.au (HELO w98) (144.132.70.18) by relay1.pair.com with SMTP; 17 Feb 2001 23:55:28 -0000 X-pair-Authenticated: 144.132.70.18 Reply-To: From: "Albert Langer" To: "'Kurt D. Zeilenga'" Cc: Subject: RE: WG Last Call on the LDAPv3 Directory Replication I-D Date: Sun, 18 Feb 2001 10:59:15 +1100 Message-ID: <002b01c0993d$a2b80e80$6628a8c0@nowhere.com> 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 CWS, Build 9.0.2416 (9.0.2910.0) Importance: Normal In-Reply-To: <5.0.2.1.0.20010217130809.00a693a0@router.boolean.net> X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Sender: owner-ietf-ldup@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit [Kurt] At 07:30 AM 2/18/01 +1100, Albert Langer wrote: >If by "transactional" consistency you are referring to updates affecting >more than one directory entry, that is not part of LDAP semantics. I am using the term "transactional consistency", I hope, as defined by LDUP requirements I-D. X.500 and LDAP state that all modifications requested as part of a single modify happen as a single atomic action. Using this feature, applications can (and do) build mutually exclusive locks, semaphores, monotonically increasing counters, and other structures used for application synchronization purposes. This feature is preserved by X.500 data model as it supports only single master replication. It is not possible to build these structures in multiple master environments without "transactional consistency". [Albert] Since X.500 and LDAP refer to a "single atomic action" I prefer to use the term "atomic" for this issue because reference to "transactions" is easily confused with updates affecting multiple entries rather than just modifications to multiple attributes of a single entry, which is the only guarantee provided by X.500 and LDAP and is deliberately much weaker than a DBMS style requirement to maintain consistency for updates to different entries. Leaving aside terminology, we seem to be broadly in agreement. However the way you have put it sounds like you are opposed to LDUP developing multi-master standards at all, since it is technically impossible to maintain such things as monotonically increasing counters for application synchronization. Is that the case? If so, could you please elaborate on applications that depend on such features. My view is that the critically important requirement that applications depend on is simply that a change can be reliably made to exactly the entry you thought you were changing and not result in some mixture of updates combined with unknown concurrent changes by some other application. That is essential for basic data integrity and easily achieved by the provisions regarding modify operations in the LDAP standards. The whole point of those provisions is that by explicitly asserting that all relevant attributes have particular values at the start of a modify and particular values at the end, you are guaranteed that the operation will fail if that turns out not to be the case due to some other change between when you read an entry and when you modified it, rather than ending up with randomly garbled entries. Although it is possible to use that mechanism for such things as (cooperative) locking, semaphores and counters, that is not it's intended use and I agree with the requirements draft characterization of applications doing that as making inappropriate use of the directory. What I disagree with in Appendix B is the confusion of such inappropriate use with the perfectly normal use of the carefully designed characteristics of "modify" atomicity to ensure data integrity. That normal use can be achieved with multi-master (at the cost of notifications about operations failing after intially appearing to have succeeded). The statement that rolling back a change to one attribute of a single entry would cause "more surprise" than letting two separate users/applications mixup changes to the same data without knowing what the results of their combined activity would be, shows a quite breathtaking incomprehension of very basic data integrity issues. It seems to me that multi-master does have important operational benefits that would justify deployment so long as basic data integrity is not compromised. Are you saying it should not be deployed at all? >An applicability statement should clearly indicate >that multi-master is unsuitable in any situation with a high rate of >concurrent changes to the same entries. [Kurt] Change "high" to "any" and I would concur. [Albert] That does seem to be saying multi-master should not be deployed at all, since by definition of multi-master, DSAs do not contact each other before performing updates and therefore the *possibility* of concurrent changes *cannot* be excluded. That breaks any application relying on semaphores etc. But rollbacks are quite sufficient for applications that merely require data integrity (such as access control). Surely a directory service that guarantees that only changes actually made by DUAs will ever be visible could be useful even though occasional notifications about changes that have been revoked would be necessary? After all, even in a single master situation a change made can be subsequently unmade by another DUA and there is no mechanism for *enforcing* cooperative use of semaphores, counters etc, so no properly designed application could depend on no other DUA interfering. If you have specific applications in mind that do depend on single master semantics, please list them. Discussion of such issues is what requirements analysis should be about. For my part, I think it is sufficient to just list access control as an example of a directory application that requires a level of data integrity that simply cannot be met without atomicity. From owner-ietf-ldup@mail.imc.org Sat Feb 17 19:32:14 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA08874 for ; Sat, 17 Feb 2001 19:32:14 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.9.3/8.9.3) id PAA15765 for ietf-ldup-bks; Sat, 17 Feb 2001 15:56:24 -0800 (PST) Received: from relay1.pair.com (relay1.pair.com [209.68.1.20]) by above.proper.com (8.9.3/8.9.3) with SMTP id PAA15757 for ; Sat, 17 Feb 2001 15:56:21 -0800 (PST) Received: (qmail 7395 invoked from network); 17 Feb 2001 23:55:53 -0000 Received: from cpe-144-132-70-18.vic.bigpond.net.au (HELO w98) (144.132.70.18) by relay1.pair.com with SMTP; 17 Feb 2001 23:55:53 -0000 X-pair-Authenticated: 144.132.70.18 Reply-To: From: "Albert Langer" To: "'John Strassner'" Cc: "'John Strassner'" , , "'Chris Apple'" , "=?iso-8859-1?Q?'Patrik_F=E4ltstr=F6m'?=" Subject: RE: WG Last Call on the LDAPv3 Directory Replication I-D Date: Sun, 18 Feb 2001 10:59:38 +1100 Message-ID: <002c01c0993d$afe13280$6628a8c0@nowhere.com> 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 CWS, Build 9.0.2416 (9.0.2910.0) Importance: Normal In-Reply-To: <4.3.2.7.2.20010217130057.00b32598@mira-sjcm-1.cisco.com> X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Sender: owner-ietf-ldup@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit [John] I posted the revised charter for discussion for this group. You were the only person that made a comment. If you would be so kind as to actually read the charter, you'll find that your complaint of having LDUP appoint two liaisons was dropped from the charter. [Albert] Thank you for your prompt response. I made no complaint about LDUP appointing two liaisons. I simply asked the the following question: *** [revision] The LDUP WG Chairs will assign one or two persons to be official LDUP WG liasons to ITU, to monitor X.500 replication work in the ITU, and to coordinate the work of the LDUP WG with similar work in ITU. [Albert] My understanding is that X.500 dropped the URP proposals for multi-master as a work item. Who is or are the liaisons and what coordination has been or is being done? *** I did not notice that the charter had been amended to remove all reference to appointing liasons, thank you for drawing that to my attention. Rather than having to do a diff to discover such changes I would expect to know about them because they would have been put to and discussed in the WG email list. There was no mention of any such change in the only document you put to the WG. It appears that instead of answering my question, someone, perhaps you, has taken a decision not to have liason with the ITU to monitor X.500 replication work in the ITU and to coordinate the work of the LDUP WG with similar work in the ITU. Surely decisions about liasons between standards bodies require some degree of formality. Who took that decision, why and why was the WG not asked for an opinion about it? Since you appear to have misunderstood my question as a complaint, I will volunteer my opinion despite not having been asked for it. I believe it is important that there *should* be active liason with X.500 replication work and the reasons for URP being dropped as a work item there should be studied and thought about here. Be that as it may, revision of the WG charter to remove a commitment to establish a liason is not something that should be done in response to a single comment, whether correctly understood or not. It should have been, and should now be, put to the WG formally. [John] As far as your complaint: [revision] Jan 01 LDAPv3 Directory Replication Requirements I-D goes to WG Last Call as Informational. Jan 01 LDAPv3 Update Reconciliation Procedures I-D goes to WG Last Call as Proposed Standard. [Albert] I do not think it is appropriate to issue new deadlines that have already passed. I would point out that Jan 01 means by the end of January, not 1 January. [Albert] Thank you. I had not understood that 01 referred to 2001 in my original comments although I understood after seeing Timothy Hahn's reference to this. Nevertheless, the WG Final call was issued on 5 February and the revised charter was subsequently issued on 10 February after 2 of the dates had already expired, as I originally stated. [John] We did successfully meet the first objective. We didn't meet the second objective because we had some comments on the requirements draft, and I felt uncomfortable issuing URP for last call until we had passed last call for the requirements draft. [Albert] Certainly issuing the final call within a few days of the end of the month successfully meets the objective (indeed something of a record as far as LDUP schedules are concerned). My point however was simply that a revised charter should not specify delivery dates that have already passed, which is precisely what you did. [John] You objected that you haven't seen any mailing list activity on the drafts from the new authors. The minutes simply said that the new authors would write these drafts and make every effort to get them posted in the repository before the next cut-off date. It didn't say that we had to discuss a draft that hadn't been written yet. [Albert] The minutes did not say we should discuss a draft that has not been written yet and as I pointed out, and you seem to be confirming, they did not say that anybody had committed to producing such a draft by the end of March. The revised charter does say that LDUP is committed to produce a draft by March 2001. My point was that under the circumstances it could be unrealistic to commit to a schedule of March 2001 for an I-D. Do you believe it is a realistic schedule? Or do you believe the schedule in a charter does not involve any sort of commitment? [John] As far as your unprofessional remark about URP, you are the only person objecting to it. Therefore, in the face of only one objection, and considering that we did discuss charter updates at the WG meeting, there was clear consent of the working group for adopting this new charter. The charter was so adopted. [Albert] I made only two references to URP, the one quoted above, and the following: *** [revision] Apr 01 LDAPv3 Replication Information Model I-D goes to WG Last Call as Proposed Standard. Apr 01 LDAPv3 Replication Architecture I-D goes to WG Last Call as Informational. [...] [Albert] Propos[al] to finalize the Update Reconciliation Procedures four months [actually 3 -AL] prior to finalizing the Information Model and Architecture lacks common sense. *** If you genuinely considered either of those references to be "unprofessional" I would have expected some private email from you at the time. I cannot even imagine what it is you now claim to be "unprofessional" about either of them, but since you have said so publicly, please either justify your statement or withdraw it. If there is a consensus in the WG to finalize detailed protocols before finalizing architecture and information model then so be it. But the WG was originally chartered to decide on the architecture and information model before finalizing protocol details - for reasons that I believe are obvious, "common sense" and indeed "professional". Any such consensus to reverse the normal and previously agreed sequence should be established on the mailing list by asking the participants what they think. Once an objection has been raised a consensus cannot be assumed on the basis of discussions at an IETF meeting. [John] I didn't issue a note to the working group because I was, and still am, ON VACATION. I will now issue such a note, even though I am still ON VACATION. As far as Tim's message, I simply did not see it. Thanks for the link, I'll take a look at it, and we can discuss the changes on the list next week, when I'm back from vacation. John [Albert] Thank you, that answers my concern that the document might have simply been posted without bothering to look at the comments. In future when you propose to take some formal action on behalf of the WG, and you happen to be on vacation, could you please postpone it until you are able to consult or at least inform the WG. There is no need to take such actions while on vacation just as there is no need to reply to this email while you are on vacation. ________________________________ At 07:47 AM 2/18/2001 +1100, Albert Langer wrote: >[John and Chris] >Silence means consent. > >Read, enjoy, and send your comments in! > >regards, >John Strassner and Chris Apple > >[Albert] >Could you please explain why a revised WG charter dated 10 February 2001 was >posted to: > >http://www.ietf.org/html.charters/ldup-charter.html > >with revised dates some of which expired the previous month, and with a >schedule to >adopt URP as a "proposed standard" 3 months prior to finalizing the >architecture >and information model? > >I objected formally to both those aspects: > >http://www.imc.org/ietf-ldup/mail-archive/msg00784.html > >I have checked the archives and am not aware of any response to those >objections from the WG co-chairs or any attempt to seek a consensus from the >WG about them nor even any announcement to the WG that a consensus has in >fact been reached. > >There were also some other comments and questions from Timothy Hahn: > >http://www.imc.org/ietf-ldup/mail-archive/msg00791.html > >These included at least one minor editorial correction (typo) which I cannot >imagine anybody would have taken exception to. Therefore I am inclined to >assume the document was simply posted "as is" without bothering to consider >any comments made on it, despite having asked for comments. > >Was that the case? > >Who took the decision, and why were we not informed? From owner-ietf-ldup@mail.imc.org Sat Feb 17 21:39:56 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id VAA10435 for ; Sat, 17 Feb 2001 21:39:55 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.9.3/8.9.3) id SAA29758 for ietf-ldup-bks; Sat, 17 Feb 2001 18:05:51 -0800 (PST) Received: from mail.coreon.net (IDENT:mirapoint@mail.coreon.net [216.74.131.6]) by above.proper.com (8.9.3/8.9.3) with ESMTP id SAA29749 for ; Sat, 17 Feb 2001 18:05:49 -0800 (PST) Received: from mail.coreon.net (mail.coreon.net [216.74.131.6]) by mail.coreon.net (Mirapoint) with SMTP id AAB81305; Sat, 17 Feb 2001 16:55:24 -0500 (EST) From: Message-Id: <200102172155.AAB81305@mail.coreon.net> Date: Sat, 17 Feb 2001 16:52:59 -0500 Subject: RE: WG Last Call on the LDAPv3 Directory Replication I-D To: Albert.Langer@directory-designs.org Cc: "'Mark Brown (REDMOND)'" , "'Richard V Huber'" , ietf-ldup@imc.org, johns@cisco.com, capple@ecal.com, paf@cisco.com, rweiser@digsigtrust.com, stokes@austin.ibm.com 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 think I'm using ... this time... Ryan >Date: Sun, 18 Feb 2001 07:33:41 +1100 >Subject: RE: WG Last Call on the LDAPv3 Directory Replication I-D > >[Albert] >There is an overlap between the authors of the requirements draft and the >authors of LDAP access control requirements and other drafts but a radical >inconsistency between currently proposed access control schemes that rely on >atomicity and the lack of understanding of atomicity issues in LDUP. > >I'll admit I don't understand the technical point of this comment. > > >[Albert] >Try plugging examples similar to those discussed in Appendix B using access >control attributes as specified in current access control drafts, taking >into account the transient outcomes I quoted from Alison's discussion of >URP consistency model in: > >http://www.imc.org/ietf-ldup/mail-archive/msg00738.html Well, as I explained to Mark, in the absense of an access control standard, I don't see the point and (here's where folks disagree) I don't think we should talk about it here, but rather in LDAPEXT where the access control work is being done. Mind you, I'm not saying access control will or won't be replicated, I'm making a procedural distinction. If the chairs of LDAPEXT/LDUP disagree with me, we can certainly open it here, but its (IMHO) a done deal that LDUP won't make any progress until the access control model is finished, and I'm certainly not in favor of that. >BTW That message is actually Chris's reply, disrupting an attempt to discuss >this issue and other issues with Rick, from which I hope you will understand >why I am not currently inclined to pursue the issue in this forum. I believe >Chris should respond as he said he would, instead of just forgetting about >it after delivering himself of that tirade. > >[Albert] >The actual wording of the LDUP requirements does now require both atomicity >... > > Uh, it must support the propagation of atomicity information, >that's different than requiring atomicity, imho. > >...and eventual convergence and is certainly a vast improvement on previous >drafts, although it proposes that sysadmins should >"boil the ocean" by resolving resulting problems manually. > >I disagree. What it requires is that if conflict resolution >would result in loss of data, ensure that the sysadmin is notified >and can override if the algorithm is wrong. That is not unreasonable >given the issues raised in Appendix B. > >[Albert] >Ok, "support the propagation of atomicity information" is different from >requiring atomicity. The difference is essentially that the protocols are >required to maintain all the information necessary to notify admins about >problems but are not required to fix the problem. That is what I meant by >"it proposes that sysadmins should 'boil the ocean' by resolving resulting >problems manually". I'm going to make another slight distinction. The requirements don't say "don't fix the problem", they say "if fixing the problem involves loss of data, you'd better tell somebody about because if the fix is wrong, losing what was the correct data is a BAD Thing". I don't claim to know what every directory administrator will want in every case, so I think that some administrator notification in cases where data would be lost (even including your preference below of rollbacks/notifications) is a GOOD Thing. >I still regard it as a vast improvement on the previous because it clearly >rules out the current architecture and URP, which is not capable of >maintaining >the information needed to notify admins as required. Another IETF procedural point: I don't believe that the requirements "rule out" the current architecture and protocol. I believe the ADs/charis will agree that what this does is put the onus on the architecture and protocol drafts to explain WHY (in acceptable detail) they are ignoring specific requirements. Of course, if the ADs/chairs disagree, that would be good to know too :-) > >I disagree with the analysis in appendix B, but it is explicitly stated to be not part of the actual requirements. That's a fair opinion, although I believe that most "if not all" of those examples are taken from real life cases. >Once an architecture is adopted that *is* capable of meeting >the requirements mandated for notification to sysadmins, I >believe it will become obvious that it makes more sense to >actually fix the problems by rollbacks and notifications >to users. That could be true, and we shall certainly see. >[Albert] >Unfortunately neither the wording nor that implication >appears to be based on the actual understanding of members >of the WG, as reflected in the current drafts for >implementation, the minutes of WG meetings at IETF and non- >normative explanatory notes in the draft. > >Again I don't see the point of this comment. > >[Albert] >The minutes show that the same meeting which agreed the >requirements draft was ready for final call also agreed >that the URP was ready for final call despite the fact >that it is incapable of meeting the requirements as stated. >The "non-normative explanatory notes" I was referring to >are mainly the Appendix B you mention. In addition the >current drafts do not meet the requirement for eventual >convergence (although they are capable of being >fixed to do so, unlike their fundamental inability to >propagate atomicity information needed for notification >requirements). Thanks, now I have a clearer picture. I don't remember seeing a "last call" call for the URP draft yet (although I'm not looking at the archives at this moment) and I do believe that the point I raised above is a fair comment for the URP draft to answer when it goes to last call >Although the plain words of the document unambiguously >rule out URP, I am not under any illusion that this >reflects a consensus of the WG to do so. I believe the reason for this is the procedural distinction I made above. >Consequently I do not believe adoption of the requirements >will in fact resolve the most important requirements issues >and am therefore not part of any consensus to adopt them - >although I will certainly elaborate on the >requirements not met by URP when that comes up. From owner-ietf-ldup@mail.imc.org Sat Feb 17 23:32:15 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id XAA12271 for ; Sat, 17 Feb 2001 23:32:15 -0500 (EST) Received: by above.proper.com (8.9.3/8.9.3) id UAA10792 for ietf-ldup-bks; Sat, 17 Feb 2001 20:04:27 -0800 (PST) Received: from cisco.com (nordic.cisco.com [144.254.116.47]) by above.proper.com (8.9.3/8.9.3) with ESMTP id UAA10787 for ; Sat, 17 Feb 2001 20:04:25 -0800 (PST) Received: from [10.21.51.77] (herbst-isdn4.cisco.com [10.21.51.77]) by cisco.com (8.8.8+Sun/8.8.8) with ESMTP id FAA09714; Sun, 18 Feb 2001 05:03:18 +0100 (MET) Mime-Version: 1.0 X-Sender: pfaltstr@nordic.cisco.com Message-Id: In-Reply-To: <002c01c0993d$afe13280$6628a8c0@nowhere.com> References: <002c01c0993d$afe13280$6628a8c0@nowhere.com> Date: Sat, 17 Feb 2001 18:58:00 -0800 To: "Albert Langer" , "'John Strassner'" From: Patrik =?iso-8859-1?Q?F=E4ltstr=F6m?= Subject: RE: WG Last Call on the LDAPv3 Directory Replication I-D Cc: "'John Strassner'" , , "'Chris Apple'" , Ned Freed Content-Type: text/plain; charset="iso-8859-1" ; format="flowed" Sender: owner-ietf-ldup@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: X-MIME-Autoconverted: from 8bit to quoted-printable by above.proper.com id UAA10792 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id XAA12271 At 10.59 +1100 01-02-18, Albert Langer wrote: >[John] >I posted the revised charter for discussion for this group. You were the >only person that made a comment. If you would be so kind as to actually >read the charter, you'll find that your complaint of having LDUP appoint >two liaisons was dropped from the charter. > >[Albert] >Thank you for your prompt response. > >I made no complaint about LDUP appointing two liaisons. I simply asked the >the following question: > >*** >[revision] >The LDUP WG Chairs will assign one or two persons to be official >LDUP WG liasons to ITU, to monitor X.500 replication work in the ITU, >and to coordinate the work of the LDUP WG with similar work in ITU. This is a hypothetical discussion as a WG doesn't appoint liasons. Because of some misunderstandings between the IESG and the IESG Secretariat, a wrong charter has been published, and it will be updated. Also, Albert, note that the IETF follow the principle of rough consensus, and that a wg chair have the full responsibility and power of declaring such consensus. I must ask you to follow the decisions made in the wg following this principle, and only if you have very explicit objections that the decisions made were wrong, you can send in a formal appeal to the Area Director and/or the IESG. I can not allow you to delay the work in the wg by being the only person working against consensus which is declared by the wg chair(s). paf -- Patrik Fältström Internet Engineering Task Force Area Director, Applications Area http://www.ietf.org Phone: (Stockholm) +46-8-4494212 (San Jose) +1-408-525-0940 PGP: 2DFC AAF6 16F0 F276 7843 2DC1 BC79 51D9 7D25 B8DC From owner-ietf-ldup@mail.imc.org Sun Feb 18 01:56:35 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id BAA19295 for ; Sun, 18 Feb 2001 01:56:34 -0500 (EST) Received: by above.proper.com (8.9.3/8.9.3) id WAA24521 for ietf-ldup-bks; Sat, 17 Feb 2001 22:31:33 -0800 (PST) Received: from pretender.boolean.net (root@router.boolean.net [198.144.206.49]) by above.proper.com (8.9.3/8.9.3) with ESMTP id WAA24517 for ; Sat, 17 Feb 2001 22:31:32 -0800 (PST) Received: from gypsy.OpenLDAP.org (gypsy.boolean.net [10.192.1.2]) by pretender.boolean.net (8.11.1/8.11.1/Boolean/Hub) with ESMTP id f1I6UMD13257; Sun, 18 Feb 2001 06:30:22 GMT (envelope-from Kurt@OpenLDAP.org) Message-Id: <5.0.2.1.0.20010217213230.00a4e260@router.boolean.net> X-Sender: guru@router.boolean.net X-Mailer: QUALCOMM Windows Eudora Version 5.0.2 Date: Sat, 17 Feb 2001 22:30:21 -0800 To: From: "Kurt D. Zeilenga" Subject: RE: WG Last Call on the LDAPv3 Directory Replication I-D Cc: ietf-ldup@imc.org In-Reply-To: <200102172155.AAB81305@mail.coreon.net> 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:52 PM 2/17/01 -0500, rmoats@coreon.net wrote: >Well, as I explained to Mark, in the absense of an >access control standard, I don't see the point and (here's >where folks disagree) I don't think we should talk about >it here, but rather in LDAPEXT where the access control >work is being done. In general, I concur. But I do note that LDUP must take an active role in ensuring their needs (whatever they might be) are being met as LDAPext has no specific requirement to met replication demands. >Mind you, I'm not saying access control will or won't be replicated, Neither am I. I however note that it's likely not wise to assume that LDAP ACM will support replication, especially multiple master replication, when there is no specific requirement. >I'm making a procedural >distinction. If the chairs of LDAPEXT/LDUP disagree with >me, we can certainly open it here, but its (IMHO) a done >deal that LDUP won't make any progress until the access >control model is finished, and I'm certainly not in favor >of that. And neither do I. I believe the LDUP Requirements I-D should not state that the LDAP ACM is addressing replication requirements/issues as clearly RFC 2820 has no specific requirement for LDAP ACMs to address any replication issue [nor is the current LDAP ACM actually addressing replication issues]. However, if LDUP requires an ACM which does support replication it should clearly state so. Kurt From owner-ietf-ldup@mail.imc.org Sun Feb 18 02:26:49 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id CAA26781 for ; Sun, 18 Feb 2001 02:26:46 -0500 (EST) Received: by above.proper.com (8.9.3/8.9.3) id XAA27957 for ietf-ldup-bks; Sat, 17 Feb 2001 23:02:19 -0800 (PST) Received: from pretender.boolean.net (root@router.boolean.net [198.144.206.49]) by above.proper.com (8.9.3/8.9.3) with ESMTP id XAA27947 for ; Sat, 17 Feb 2001 23:02:18 -0800 (PST) Received: from gypsy.OpenLDAP.org (gypsy.boolean.net [10.192.1.2]) by pretender.boolean.net (8.11.1/8.11.1/Boolean/Hub) with ESMTP id f1I71GD13315; Sun, 18 Feb 2001 07:01:17 GMT (envelope-from Kurt@OpenLDAP.org) Message-Id: <5.0.2.1.0.20010217205223.00a79900@router.boolean.net> X-Sender: guru@router.boolean.net X-Mailer: QUALCOMM Windows Eudora Version 5.0.2 Date: Sat, 17 Feb 2001 23:01:15 -0800 To: From: "Kurt D. Zeilenga" Subject: RE: WG Last Call on the LDAPv3 Directory Replication I-D Cc: In-Reply-To: <002b01c0993d$a2b80e80$6628a8c0@nowhere.com> References: <5.0.2.1.0.20010217130809.00a693a0@router.boolean.net> 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:59 AM 2/18/01 +1100, Albert Langer wrote: >However the way you have put it sounds like you are opposed to LDUP >developing >multi-master standards at all, since it is technically impossible to >maintain >such things as monotonically increasing counters for application >synchronization. >Is that the case? Though I have voiced in the past an opinion that I felt this work on multiple-master replication was more suitable for the Experimental track, I do not object to this WG attempting to produce Standard Track protocol. That's what they were chartered to do. I raised the point only because the requirement document dismisses Model 1 "Transactional Consistency" without noting the consequences of this choice. I wouldn't mind seeing more discussion of these consequences. However, as this discussion would likely not alter the actual requirements, it's not a critical issue. >If so, could you please elaborate on applications that depend on such >features. Provisioning of services. >Although it is possible to use that mechanism for such things as >(cooperative) >locking, semaphores and counters, that is not it's intended use I cannot argue wether it was an intended use or not. I wasn't there. However, this use is common. I've even seen this use in LDAP/X.500 educational materials and numerous real world applications (namely custom provision solutions). >and I agree >with >the requirements draft characterization of applications doing that as making >inappropriate use of the directory. I do not concur with this characterization nor a good deal of the rational behind it. However, I don't think changing it would have a significant impact on the stated requirements (as I believe the consensus of the WG is not to provide Model 1, "transactional consistency"). >Are you saying it should not be deployed at all? No. I'm saying I don't believe LDUP multiple master replication as maintaining full LDAP semantics. From owner-ietf-ldup@mail.imc.org Sun Feb 18 09:44:54 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA09473 for ; Sun, 18 Feb 2001 09:44:52 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.9.3/8.9.3) id GAA04439 for ietf-ldup-bks; Sun, 18 Feb 2001 06:04:13 -0800 (PST) Received: from relay1.pair.com (relay1.pair.com [209.68.1.20]) by above.proper.com (8.9.3/8.9.3) with SMTP id GAA04431 for ; Sun, 18 Feb 2001 06:04:10 -0800 (PST) Received: (qmail 1394 invoked from network); 18 Feb 2001 14:03:39 -0000 Received: from cpe-144-132-70-18.vic.bigpond.net.au (HELO w98) (144.132.70.18) by relay1.pair.com with SMTP; 18 Feb 2001 14:03:39 -0000 X-pair-Authenticated: 144.132.70.18 Reply-To: From: "Albert Langer" To: Cc: "'Mark Brown \(REDMOND\)'" , "'Richard V Huber'" , , , , , , Subject: RE: WG Last Call on the LDAPv3 Directory Replication I-D Date: Mon, 19 Feb 2001 01:07:31 +1100 Message-ID: <003a01c099b4$232a1f60$6628a8c0@nowhere.com> 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 CWS, Build 9.0.2416 (9.0.2910.0) Importance: Normal In-Reply-To: <200102172155.AAB81305@mail.coreon.net> X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Sender: owner-ietf-ldup@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit [Ryan] I think I'm using ... this time... Ryan http://www.imc.org/ietf-ldup/mail-archive/msg00821.html [Albert] I will just provide the link above to your original message and select bits for reply. >[Albert] >Try plugging examples similar to those discussed in Appendix B using access >control attributes as specified in current access control drafts, taking >into account the transient outcomes I quoted from Alison's discussion of >URP consistency model in: > >http://www.imc.org/ietf-ldup/mail-archive/msg00738.html [Ryan] Well, as I explained to Mark, in the absense of an access control standard, I don't see the point and (here's where folks disagree) I don't think we should talk about it here, but rather in LDAPEXT where the access control work is being done. Mind you, I'm not saying access control will or won't be replicated, I'm making a procedural distinction. If the chairs of LDAPEXT/LDUP disagree with me, we can certainly open it here, but its (IMHO) a done deal that LDUP won't make any progress until the access control model is finished, and I'm certainly not in favor of that. [Albert] Nevertheless access control mechanisms proposed by one of the authors of this requirements draft provide an excellent illustration of application mechanisms that one might assume would work ok with the approach discussed in appendix B but which don't when you take a closer look. I repeat my advice to take that closer look. As to "not saying access control will or won't be replicated" and the "procedural distinction", the draft clearly states: "M4. LDAP replication MUST encompass schema definitions, attribute names and values, access control information, and name space information." and "AM6. Access control information (ACI) associated with sensitive data MUST be deleted after or simultaneously with the deletion of the sensitive data. Likewise, during Adds, ACI MUST be added first or simultaneously with the addition of that data." Certainly there isn't going to be much deployment of LDUP without an access control standard and that is clearly recognized in the WG charter. But given that, it is all the more important to understand what LDUP protocols will be required to achieve in order for access controls to *work*. The most recent draft for an access control model is: http://www.ietf.org/internet-drafts/draft-ietf-ldapext-acl-model-06.txt (expired 14 January 2001) This uses multiple attribute values for a single ldapACI attribute and relies on atomic semantics of LDAP modify operations. The most recent draft for LDUP URP is: http://www.ietf.org/internet-drafts/draft-ietf-ldup-urp-03.txt (expired 29 December 2000 - but listed for final call in January 2001 in a WG charter posted on 10 February 2001) That splits a single ldapACI or any other attribute into independent attribute values each of which can be updated independently by "primitives" not corresponding to a single LDAP modify operation, but processed and forwarded as they arrive from different operations by different DUAs via different DSAs. This completely breaks both the semantics of the LDAP modify operation and the proposed access control mechanism. Given adoption of M4 and AM6, LDUP would be precluded from adopting URP unless LADP-EXT drops its current acl model. I see no problem in that, and presumably Ellen doesn't either as an author of both those requirements and the acl draft, but Steve and Alison might and should not be left under any illusions about it. [...] [Ryan] I'm going to make another slight distinction. The requirements don't say "don't fix the problem", they say "if fixing the problem involves loss of data, you'd better tell somebody about because if the fix is wrong, losing what was the correct data is a BAD Thing". I don't claim to know what every directory administrator will want in every case, so I think that some administrator notification in cases where data would be lost (even including your preference below of rollbacks/notifications) is a GOOD Thing. [Albert] When I first drafted MDCR I personally thought that notificatins would be essential but left it open because of likely (and indeed subsequently expressed) opposition to adding that burden on implementors. If indeed that resistance has been overcome and there is now a consensus on mandatory storage and notification I think that's great. As to what can be done to minimize the burden on administrators by using rollbacks and notifications to users, I agree with your remark below that this can be left to emerge from later discussion. I agree with the requirements as stated: "MM5. Multi-master replication MUST NOT lose information during replication. If conflict resolution would result in the loss of directory information, the replication process MUST store that information, notify the administrator of the nature of the conflict and the information that was lost, and provide a mechanism for possible override by the administrator." "MM6. Multi-master replication MUST support convergence of the values of attributes and entries. Convergence may result in an event as described in MM5." "P6. The protocol MUST support propagation of atomicity information." The discussion of create and rename conflicts in B.5.1 and B.5.2 makes it quite clear that the intended meaning as well as the actual words precludes a specification that has no means of storing information about conflicts and no means of propagating such information. *** "Whichever change arrives first, requirement MM6 says that the values from replica A must be those in place on all replicas at the end of the replication cycle. Requirement MM5 states that the system cannot quietly ignore the values from replica B. The values from replica B might be logged with some notice to the administrators, or they might be added to the DIT with a machine generated DN (again with notice to the administrators). If they are stored with a machine generated DN, the same DN must be used on all servers in the replica ring (otherwise requirement M3 would be violated). Note that in the case where the entry in question is a container, storage with a machine generated DN provides a place where descendent entries may be stored if any descendents were generated before the replication cycle was completed. In any case, some mechanism must be provided to allow the administrator to reverse the conflict resolution algorithm and force the values originally created on B into place on all replicas if desired." *** The discussion in B.5.3 confuses the issue as involving some sort of "locking" when it is simply a matter of ensuring that "what you changed is what you saw". Nevertheless the reference there to the necessity for any mechanism that resolves mody conflicts as opposed to create and rename conflicts to not violate G6 leaves no doubt that the natural meaning of the requirements language used in the actual numbered requirements is in fact what the authors intended. Obviously URP cannot propagate atomicity information since it has no such concept but replicates each attribute value independently and will therefore forward changes originating concurrently from different DUAs at different servers to values of the same attribute with no means of unscrambling the omelette. That is the whole point of the design (which avoids logging). Consequently it *fundamentally* cannot notify anybody about events it has no concept of. In addition of course URP and the architecture currently fails to support: "G1. LDAP Replication MUST support models 2 (Eventual Consistency) and 3 (Limited Effort Eventual Consistency) above." Though that is easily fixed by abandoning the reliance on timestamps, just as I believe MDCR could be easily fixed to comply with G6. I object to the failure to require actual atomic operations in P6, just as I object to the requirement to also support "eventual divergence" in G1. More fundamentally I doubt that adoption of the requirements document will actually resolve the requirements issues since it is quite clear that the same meeting which considered this draft ready for "final call" also considered URP equally "ready", despite the unambiguous conflict between them. >I still regard it as a vast improvement on the previous because it clearly >rules out the current architecture and URP, which is not capable of >maintaining >the information needed to notify admins as required. [Ryan] Another IETF procedural point: I don't believe that the requirements "rule out" the current architecture and protocol. I believe the ADs/charis will agree that what this does is put the onus on the architecture and protocol drafts to explain WHY (in acceptable detail) they are ignoring specific requirements. Of course, if the ADs/chairs disagree, that would be good to know too :-) [Albert] Surely that is the distinction between MUST and SHOULD as used consistently in the draft, with an explicit reference to RFC 2119. In this context a SHOULD requirement could be met by an explanation in acceptable detail of why other design constraints made it necessary to not satisfy (as opposed to "ignore") the SHOULD. But if a MUST requirement is not met, then either the proposed specification or the requirements document would have to be amended. Otherwise what could possibly be the point of using the word MUST in this context? For example: "G6. Meta-data collected by the LDAP replication mechanism MUST NOT grow without bound." I read that as "ruling out" my MDCR proposal in its current form. Once adopted as a "requirement" I would be obliged to modify the proposal to meet that requirement rather than waste the WG's time rehashing a settled issue, by submitting another version without fixing the problem - and rightly so. In the same sense, the MUST requirements cited above "rule out" the current architecture and URP proposals. Otherwise they simply don't mean anything at all, and the whole exercise is pointless. That may well be the case, given the current level of understanding, but I'm certainly not going to be a party to a "consensus" about nothing in particular. >I disagree with the analysis in appendix B, but it is explicitly stated to be not part of the actual requirements. [Ryan] That's a fair opinion, although I believe that most "if not all" of those examples are taken from real life cases. [Albert] Yes, and they therefore could provide a useful basis for discussing concrete issues about conflict resolution. Unfortunately such discussion was squelched by Chris when it was about to start between Rick and me and I am not willing to make a second attempt at the moment. >Once an architecture is adopted that *is* capable of meeting >the requirements mandated for notification to sysadmins, I >believe it will become obvious that it makes more sense to >actually fix the problems by rollbacks and notifications >to users. [Ryan] That could be true, and we shall certainly see. [Albert] Agreed. [...] [Ryan] Thanks, now I have a clearer picture. I don't remember seeing a "last call" call for the URP draft yet (although I'm not looking at the archives at this moment) and I do believe that the point I raised above is a fair comment for the URP draft to answer when it goes to last call >Although the plain words of the document unambiguously >rule out URP, I am not under any illusion that this >reflects a consensus of the WG to do so. I believe the reason for this is the procedural distinction I made above. [Albert] There has been no "last call" on URP yet. Just a charter posted that announced that it was scheduled to be done together with the requirements last call in January and a recent explanation by John that it will now be after requirements have gone through. Hopefully somebody will ensure an unexpired version is available before issuing a final call this time. Anyway, the authors of URP and the current architecture have now had the requirements issues explicitly drawn to their attention and should not be surprised about being expected to address any requirements that have been adopted when those documents go to last call. From owner-ietf-ldup@mail.imc.org Sun Feb 18 10:27:50 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA09918 for ; Sun, 18 Feb 2001 10:27:50 -0500 (EST) Received: by above.proper.com (8.9.3/8.9.3) id HAA11609 for ietf-ldup-bks; Sun, 18 Feb 2001 07:03:11 -0800 (PST) Received: from mail.coreon.net (IDENT:mirapoint@mail.coreon.net [216.74.131.6]) by above.proper.com (8.9.3/8.9.3) with ESMTP id HAA11604 for ; Sun, 18 Feb 2001 07:03:09 -0800 (PST) Received: from rmoats2 (wenjus3.coreon.net [216.74.131.3]) by mail.coreon.net (Mirapoint) with ESMTP id AAA03513 (AUTH rmoats); Sun, 18 Feb 2001 09:11:07 -0500 (EST) From: "Ryan Moats" To: "Kurt D. Zeilenga" , Cc: Subject: RE: WG Last Call on the LDAPv3 Directory Replication I-D Date: Sun, 18 Feb 2001 08:15:50 -0600 Message-ID: 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 IMO, Build 9.0.2416 (9.0.2911.0) Importance: Normal In-Reply-To: <5.0.2.1.0.20010217205223.00a79900@router.boolean.net> 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: Content-Transfer-Encoding: 7bit Hmm, I see something in here that really bothers me, I'm going to use ... since this is my first comment on this part of the thread... Ryan -----Original Message----- From: owner-ietf-ldup@mail.imc.org [mailto:owner-ietf-ldup@mail.imc.org]On Behalf Of Kurt D. Zeilenga Subject: RE: WG Last Call on the LDAPv3 Directory Replication I-D >If so, could you please elaborate on applications that depend on such >features. Provisioning of services. Whoa! This is something I'm not unfamiliar with and I claim that it can be done without relying on things like implementing locks or semaphores in the directory that won't replicate, thus I can't support the idea that provisioning of services "depend" on such features. From owner-ietf-ldup@mail.imc.org Sun Feb 18 10:55:03 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA10219 for ; Sun, 18 Feb 2001 10:55:02 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.9.3/8.9.3) id HAA13686 for ietf-ldup-bks; Sun, 18 Feb 2001 07:20:59 -0800 (PST) Received: from relay1.pair.com (relay1.pair.com [209.68.1.20]) by above.proper.com (8.9.3/8.9.3) with SMTP id HAA13682 for ; Sun, 18 Feb 2001 07:20:57 -0800 (PST) Received: (qmail 21951 invoked from network); 18 Feb 2001 15:20:27 -0000 Received: from cpe-144-132-70-18.vic.bigpond.net.au (HELO w98) (144.132.70.18) by relay1.pair.com with SMTP; 18 Feb 2001 15:20:27 -0000 X-pair-Authenticated: 144.132.70.18 Reply-To: From: "Albert Langer" To: "'Kurt D. Zeilenga'" Cc: Subject: RE: WG Last Call on the LDAPv3 Directory Replication I-D Date: Mon, 19 Feb 2001 02:24:26 +1100 Message-ID: <003c01c099be$e18687a0$6628a8c0@nowhere.com> 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 CWS, Build 9.0.2416 (9.0.2910.0) Importance: Normal In-Reply-To: <5.0.2.1.0.20010217205223.00a79900@router.boolean.net> X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Sender: owner-ietf-ldup@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit [Kurt] At 10:59 AM 2/18/01 +1100, Albert Langer wrote: >However the way you have put it sounds like you are opposed to LDUP >developing >multi-master standards at all, since it is technically impossible to >maintain >such things as monotonically increasing counters for application >synchronization. >Is that the case? Though I have voiced in the past an opinion that I felt this work on multiple-master replication was more suitable for the Experimental track, I do not object to this WG attempting to produce Standard Track protocol. That's what they were chartered to do. I raised the point only because the requirement document dismisses Model 1 "Transactional Consistency" without noting the consequences of this choice. I wouldn't mind seeing more discussion of these consequences. However, as this discussion would likely not alter the actual requirements, it's not a critical issue. [Albert] Ok, well as I agree with the consensus on this and you seem to be resigned to it, I won't attempt to convince you that it's correct. Let's just take it as a given, the requirements we are discussing, for good or ill are not attempting to support model 1, but model 2 (X.500/LDAP). >If so, could you please elaborate on applications that depend on such >features. [Kurt] Provisioning of services. >Although it is possible to use that mechanism for such things as >(cooperative) >locking, semaphores and counters, that is not it's intended use I cannot argue wether it was an intended use or not. I wasn't there. However, this use is common. I've even seen this use in LDAP/X.500 educational materials and numerous real world applications (namely custom provision solutions). [Albert] Well, provisioning of services is almost as relevant to general LDAP user requirements as access controls. So I would like to discuss what is needed to support it, given that model 1 transactions and cooperative, locking, semaphores and counters will not be available with multi-master. BTW I'd also be interested in any URLs you could provide on the educational materials and real world applications including custom provision solutions, whether or not they require single master semantics - both for this discussion or if you consider them irrelevant to it, then by direct email. As it happens I've been working on a project in precisely this area. My conclusions have been as folows: 1. Service provisioning needs various forms of strict transactional support, including mandatory (not just cooperative) locking as well as semaphores and counters, that simply cannot by provided by even a single master distributed directory as distribution of subtrees among different servers results in synchronization becoming unscalable. It also has requirements for updates that are written almost as often as they are read, while processing changes. Therefore it requires the use of full DBMS facilities. 2. Service provisioning also needs a lot of information that is relatively static but must be efficiently available for frequent lookups by the provisioned services and also needs to be searchable by their users and administrators. This aspect is ideally suited to directories. It can be and I suspect usually is, handled by single master directories with failover. 3. Service provisioning also needs multi-master replication. This is both to support a more robust and scalable form of failover than is possible with single master and, less importantly, for the normal reasons of enabling immediate availability of local changes. DBMS replication is far too complex and expensive but the full semantics of DBMS replication are not needed to meet the service provisioning requirements for multi-master replication. The result is that the data and operations have to be partitioned, rendering unto the DBMS that which belongs to the DBMS and rendering unto the Directory, that which belongs to the Directory. (There is also an important role for DNS as much of the static data is just "lookup only" and does not need to be searchable). Unfortunately actually available multi-master directory services do not fit the directory requirements well - eg Active Directory replicates each attribute independently instead of complying with the LDAP/X.500 standards requiring that granularity of a directory is at the level of individual entries, not individual attributes. As a result it has to maintain ACI information in a single attribute that cannot have independent changes to separate attribute values and similar encoding work arounds are necessary for other aspects. Nevertheless, I believe it *can* be worked around whereas if it had adopted the granularity of an individual attribute value, like URP, it would be completely useless. I do not believe it will be possible to eliminate the requirements for DBMSes in service provisioning applications (after having tried long and hard to find a way to do so). But it would certainly be possible to provide multi-master directory support far superior to Borg technology, which naturally enough is based on the usual Borg assumptions about a hierarchically administered hive rather than the emerging reality of interweaved federated webs of use, administration and service provision. >and I agree >with >the requirements draft characterization of applications doing that as making >inappropriate use of the directory. [Kurt] I do not concur with this characterization nor a good deal of the rational behind it. However, I don't think changing it would have a significant impact on the stated requirements (as I believe the consensus of the WG is not to provide Model 1, "transactional consistency"). >Are you saying it should not be deployed at all? No. I'm saying I don't believe LDUP multiple master replication as maintaining full LDAP semantics. [Albert] Ok, I think I understand your position now. But surely just because you can't have model 1 from multi-master that doesn't mean you can't have model 2 which is explicitly defined as the LDAP/X.500 model. That model does not support transactions, because it can't in a globally scalable distributed directory. But it does support atomic operations so that "what you changed is what you saw", as well as supporting "eventual convergence". It is logically impossible to support semaphores and counters with multi-master, but quite feasible to support the semantics of LDAP modify operations as you described them. Surely that is a goal that should be required (and indeed must be required for a standard claiming to be consistent with LDAP). "All or nothing" is seldom a useful attitude. From owner-ietf-ldup@mail.imc.org Sun Feb 18 10:59:30 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA10264 for ; Sun, 18 Feb 2001 10:59:29 -0500 (EST) Received: by above.proper.com (8.9.3/8.9.3) id HAA15760 for ietf-ldup-bks; Sun, 18 Feb 2001 07:30:55 -0800 (PST) Received: from relay1.pair.com (relay1.pair.com [209.68.1.20]) by above.proper.com (8.9.3/8.9.3) with SMTP id HAA15751 for ; Sun, 18 Feb 2001 07:30:53 -0800 (PST) Received: (qmail 6788 invoked from network); 18 Feb 2001 15:30:23 -0000 Received: from cpe-144-132-70-18.vic.bigpond.net.au (HELO w98) (144.132.70.18) by relay1.pair.com with SMTP; 18 Feb 2001 15:30:23 -0000 X-pair-Authenticated: 144.132.70.18 Reply-To: From: "Albert Langer" To: "'Ryan Moats'" , "'Kurt D. Zeilenga'" Cc: Subject: RE: WG Last Call on the LDAPv3 Directory Replication I-D Date: Mon, 19 Feb 2001 02:34:23 +1100 Message-ID: <003d01c099c0$45afe5e0$6628a8c0@nowhere.com> 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 CWS, Build 9.0.2416 (9.0.2910.0) Importance: Normal In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Sender: owner-ietf-ldup@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit [Albert] >If so, could you please elaborate on applications that depend on such >features. [Kurt] Provisioning of services. [Ryan] Whoa! This is something I'm not unfamiliar with and I claim that it can be done without relying on things like implementing locks or semaphores in the directory that won't replicate, thus I can't support the idea that provisioning of services "depend" on such features. [Albert] Just a note to clarify my message that crossed with this. I agree with Kurt that service provisioning does need locks and semaphores - as with any other resource allocation problem. In particular if a service is being paid for it can't be supplied until the payment is authorized and the payment cannot be captured unless the service provision has been successfully fulfilled. That involves ye olde transactions. I also agree with Ryan that it "can be done wihtout relying on things like implementing locks and semaphores in the directory". That is because those aspects should be done outside the directory in a DBMS that is specifically designed for that sort of thing. Other aspects of service provisioning should be done in the directory, but not the transactional aspects. Of course if a directory doesn't support "what you changed is what you saw" data integrity then it can't support reliable access controls and is therefore useless for service provisioning, or anything else for that matter. From owner-ietf-ldup@mail.imc.org Sun Feb 18 11:47:55 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA10493 for ; Sun, 18 Feb 2001 11:47:54 -0500 (EST) Received: by above.proper.com (8.9.3/8.9.3) id IAA25998 for ietf-ldup-bks; Sun, 18 Feb 2001 08:18:56 -0800 (PST) Received: from cisco.com (nordic.cisco.com [144.254.116.47]) by above.proper.com (8.9.3/8.9.3) with ESMTP id IAA25987 for ; Sun, 18 Feb 2001 08:18:53 -0800 (PST) Received: from [10.21.51.77] (herbst-isdn4.cisco.com [10.21.51.77]) by cisco.com (8.8.8+Sun/8.8.8) with ESMTP id RAA24553; Sun, 18 Feb 2001 17:18:19 +0100 (MET) Mime-Version: 1.0 X-Sender: pfaltstr@nordic.cisco.com Message-Id: In-Reply-To: <003b01c099b5$0876af20$6628a8c0@nowhere.com> References: <003b01c099b5$0876af20$6628a8c0@nowhere.com> Date: Sun, 18 Feb 2001 08:10:16 -0800 To: "Albert Langer" From: Patrik =?iso-8859-1?Q?F=E4ltstr=F6m?= Subject: RE: WG Last Call on the LDAPv3 Directory Replication I-D Cc: ietf-ldup@imc.org Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-ietf-ldup@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: At 01.13 +1100 01-02-19, Albert Langer wrote: >[Albert] >I don't understand this statement. Do you mean: > >a) The version dated 10 February 2001 is wrong and will be withdrawn. That very paragraph talking about liasons in the version of the charter will be replaced by a new paragraph. The rest of the charter will not be changed. The new paragraph will read: > The work being done in the LDUP WG should be coordinated > to the closest extent possible with similar work being > done in the ITU. This is necessary both because LDAP > depends on X.500 and because it makes sense from an > operational perspective. paf From owner-ietf-ldup@mail.imc.org Sun Feb 18 12:24:18 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA10686 for ; Sun, 18 Feb 2001 12:24:18 -0500 (EST) Received: by above.proper.com (8.9.3/8.9.3) id IAA00736 for ietf-ldup-bks; Sun, 18 Feb 2001 08:56:32 -0800 (PST) Received: from pretender.boolean.net (root@router.boolean.net [198.144.206.49]) by above.proper.com (8.9.3/8.9.3) with ESMTP id IAA00730 for ; Sun, 18 Feb 2001 08:56:31 -0800 (PST) Received: from gypsy.OpenLDAP.org (gypsy.boolean.net [10.192.1.2]) by pretender.boolean.net (8.11.1/8.11.1/Boolean/Hub) with ESMTP id f1IGtOD14076; Sun, 18 Feb 2001 16:55:25 GMT (envelope-from Kurt@OpenLDAP.org) Message-Id: <5.0.2.1.0.20010218081025.00a90cd0@router.boolean.net> X-Sender: guru@router.boolean.net X-Mailer: QUALCOMM Windows Eudora Version 5.0.2 Date: Sun, 18 Feb 2001 08:55:24 -0800 To: "Ryan Moats" From: "Kurt D. Zeilenga" Subject: RE: WG Last Call on the LDAPv3 Directory Replication I-D Cc: , In-Reply-To: References: <5.0.2.1.0.20010217205223.00a79900@router.boolean.net> 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:15 AM 2/18/01 -0600, Ryan Moats wrote: >Provisioning of services. > >Whoa! This is something I'm not unfamiliar with and I claim that >it can be done without relying on things like implementing locks or >semaphores in the directory that won't replicate, thus I can't support >the idea that provisioning of services "depend" on such features. Obviously you can rely on some form of external synchronization to implement these services. In that one can always use external synchronization, no application "depends" on the well defined semantics of LDAP/X.500 operations for synchronization purposes. The fact is that there are numerous applications using these semantics to provide synchronization between clients. There is also sufficient demand for multiple-master replication with less than "transactional consistency (model 1)". My point is that folks should realize that they cannot have both. I think you and most folks in the LDUP community realize this. My point is I'd like to make it more clear to those reading LDUP specifications that LDUP does not support applications relying on synchronization structures built using atomic semantics of LDAP operations. Specifically, I suggest a brief note in a "Background and Intended Use" section within the TS. Same applies to extensions providing "LDAP Transactions," but here the extension can note the limitation. I don't it necessary for the Requirements I-D to require this explicitly. Kurt From owner-ietf-ldup@mail.imc.org Sun Feb 18 21:13:48 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id VAA13108 for ; Sun, 18 Feb 2001 21:13:47 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.9.3/8.9.3) id RAA03866 for ietf-ldup-bks; Sun, 18 Feb 2001 17:25:28 -0800 (PST) Received: from DF-INET-1.dogfoodinternet.com (df-inet1.exchange.microsoft.com [131.107.8.8]) by above.proper.com (8.9.3/8.9.3) with ESMTP id RAA03860 for ; Sun, 18 Feb 2001 17:25:25 -0800 (PST) Received: from df-virus2.platinum.corp.microsoft.com ([172.30.236.33]) by DF-INET-1.dogfoodinternet.com with Microsoft SMTPSVC(5.0.2195.2831); Fri, 16 Feb 2001 23:17:19 -0800 Received: from 172.30.236.11 by df-virus2.platinum.corp.microsoft.com (InterScan E-Mail VirusWall NT); Fri, 16 Feb 2001 23:18:05 -0800 (Pacific Standard Time) Received: from DF-BOWWOW.platinum.corp.microsoft.com ([172.30.236.101]) by yuri.dns.microsoft.com with Microsoft SMTPSVC(5.0.2195.2831); Fri, 16 Feb 2001 23:18:05 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.0.4648.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: WG Last Call on the LDAPv3 Directory Replication I-D Date: Fri, 16 Feb 2001 23:18:03 -0800 Message-ID: <5B90AD65A9E8934987DB0C8C076265744730FA@DF-BOWWOW.platinum.corp.microsoft.com> Thread-Topic: WG Last Call on the LDAPv3 Directory Replication I-D Thread-Index: AcCYhL5x8JcQUPRpSYuY6s93R0I2egALJzSA From: "Paul Leach" To: "Ryan Moats" , "Mark Brown (REDMOND)" , "Richard V Huber" , , Cc: , , , X-OriginalArrivalTime: 17 Feb 2001 07:18:05.0128 (UTC) FILETIME=[C5303C80:01C098B1] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id RAA03861 Sender: owner-ietf-ldup@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 8bit You're right -- it isn't the job of LDUP to say how to replicate ACLs. However, it is appropriate to point out that until such a standard exists, LDAP conformant directories will not be able to be replicated via LDUP. So, one of the requirements for replication between multiple standards conformant LDAP servers using LDUP is that said servers not implement anything other than standard LDAP acess to totally passive data. > -----Original Message----- > From: Ryan Moats [mailto:rmoats@coreon.net] > Sent: Friday, February 16, 2001 5:57 PM > To: Mark Brown (REDMOND); Ryan Moats; Richard V Huber; > ietf-ldup@imc.org; johns@cisco.com > Cc: capple@ecal.com; paf@cisco.com; rweiser@digsigtrust.com; > stokes@austin.ibm.com > Subject: RE: WG Last Call on the LDAPv3 Directory Replication I-D > > > John, Chris, do you have a sense of the working group from > the list messages? I've not seen enough reaction to see > whether we've got rough consensus one way or another, and > I'm worried that this discussion threatens to become a > rat-hole. > > See ... below... Ryan > > -----Original Message----- > From: Mark Brown (REDMOND) [mailto:mabrown@Exchange.Microsoft.com] > Subject: RE: WG Last Call on the LDAPv3 Directory Replication I-D > > > ... > ... A standard mechanism for directory replication in a > multi-vendor environment is critical to the continued > success of LDAP in the market place. This document sets > out the requirements for replication between multiple > standard-conformant LDAP servers. ... > ^^^^^^^^^^^^^^^^^^^ <- new text > ... > > An LDAP server that implements semantics not > mentioned in the LDAP RFCs does not thereby > become non-standard-conformant. > > Never said it didn't > > For instance, most LDAP servers today implement an > access control scheme. No access control scheme > is mentioned in the LDAP RFCs. Yet LDAP servers > that implement access control are conformant with > the LDAP standard. > > In the absence of an LDAP standard for access > control, you can't have interoperability of access > control in the IETF sense. However, I am not willing > to delay this document for something that is the > responsibility of another working group. The proper > IETF procedure (as I understand it) is for this document > to go forward and it become the responsibility of > the access control draft authors to include the replication > implications of the new standard. That avoids > a "boil the ocean" conundrum preventing progress. > > Similarly, a server that implements internal > triggers for the purpose of maintaining certain > invariants in the directory can conform with > the LDAP standard. > > Again, in the absence of an LDAP standard for internal > triggers you can't have IETF interoperability to > replicate that information with LDUP. If you want > interoperability in replicating internal triggers, > the proper process is to develop an RFC and address > the issues there. > > LDUP is designed to solve the problem of replicating > the representations of directories. But the > correspondence between these representations and the > LDAP protocol is not a simple one in general -- it is > only simple for directories that are completely passive > stores. When LDUP is used to replicate (the representations > of) non-passive stores, it is up to the developers of those > stores, not LDUP, to define how to achieve > interoperability. (Most likely, they'll do this pairwise.) > > Readers of the requirements draft, even with your > proposed amendment, are likely to think that LDUP > is meant to provide interoperability between directories > rather than between their representations. They are > likely to blame LDAP directory implementors for not > providing the same degree of interoperability as, say, > DNS server implementors do. > > As Kurt says down at the start of this thread, that's not > LDUP's job. It is worth adding a paragraph to the draft > so that it says so clearly. > > I claim we've addressed the issue already in -06 > and with the suggested text above. Therefore, at > this point, I think I'd like to ask the chairs to get a > sense of the mailing list to see if we have rough-consensus, > because I can see argument turning into a rat-hole. > > --mark > > -----Original Message----- > From: Ryan Moats [mailto:rmoats@coreon.net] > Sent: Friday, February 16, 2001 12:40 PM > To: Mark Brown (REDMOND); Richard V Huber; ietf-ldup@imc.org; > johns@cisco.com > Cc: capple@ecal.com; paf@cisco.com; rmoats@coreon.net; > rweiser@digsigtrust.com; stokes@austin.ibm.com > Subject: RE: WG Last Call on the LDAPv3 Directory Replication I-D > > > See ... below... Ryan > > -----Original Message----- > From: Mark Brown (REDMOND) [mailto:mabrown@Exchange.Microsoft.com] > Sent: Tuesday, February 13, 2001 8:38 PM > To: Richard V Huber; ietf-ldup@imc.org; johns@cisco.com > Cc: capple@ecal.com; paf@cisco.com; rmoats@coreon.net; > rweiser@digsigtrust.com; stokes@austin.ibm.com > Subject: RE: WG Last Call on the LDAPv3 Directory Replication I-D > > > So sorry -- I missed those changes when the -06 version came out. > > Shortening my suggested addition seems like a good idea. > > Good > > But the intent of my suggestion was to set a clear requirement for > LDUP's ability to provide interoperability. That way, as other LDUP > drafts progress, we'll be able to tell if they are meeting the goal > set in the requirements. > > I personally am willing to do the following text adjustment, > (the other authors still get to comment)... > > ... A standard mechanism for directory replication in a > multi-vendor environment is critical to the continued > success of LDAP in the market place. This document sets > out the requirements for replication between multiple > standard-conformant LDAP servers. ... > ^^^^^^^^^^^^^^^^^^^ <- new text > > Beyond this, I disagree that LDUP requirements need to be stated > to cover items that don't have an LDAP standard yet. Any new LDAP > standard should cover the impact of replication on that standard, > not the other way around. > > Since we are doing this work in the IETF, interoperability should be > one of the primary concerns of the work. > > But the proposed text > > : Interoperability of replicas between directory servers may be > limited > : by servers that implement semantics that go beyond what the LDAP > : access protocol defines. Examples (not an exhaustive > list) of such > : semantics include: (1) replication among directory servers with > : different access control systems/semantics may compromise > directory > : security, and (2) replication among directory servers > with different > : application trigger semantics may compromise directory data > : integrity. > > does not set a clear requirement for LDUP's ability to provide > interoperability. It says that when we are done designing LDUP, it is > OK that certain directory servers will not be able to replicate. It > does not say that for the LDUP design to be considered a viable IETF > standard, it is necessary that there is some pair of directory > servers (not from the same code base) that LDUP enables to replicate. > > Of course, we don't want to state such a goal in terms like "LDUP will > enable OpenLDAP and the Siemens DS to replicate," we want to state the > goal in terms of the functional characteristics of a pair of systems > that > are able to replicate. That's what my suggested text tried to do. > > How about this: > > : The goal of LDUP is to support replication between directory servers > : that each implements a passive store fully described by its LDAP > interface. > : "Passive store" means that the servers are limited to > storing entries > that > : come in via LDAP and retrieving those identical entries later in > response > : to LDAP requests. The entire semantics of such a store is defined by > its > : LDAP interface. Any restrictions on what the server can > store must be > : expressed in the server's schema, and any restrictions on the access > that > : clients have to the store must be expressed in terms of a > standardized > : LDAP access control scheme. > : > : LDUP is not required to support replication between directory > : servers that each implements an active store extending LDAP > : semantics with non-standard access control rules or with triggers. > : Examples of triggers include password length/complexity policies and > : automatic storage of secure password hashes instead of passwords. > > --mark > > -----Original Message----- > From: Richard V Huber [mailto:rvh@qsun.mt.att.com] > Sent: Tuesday, February 06, 2001 12:52 PM > To: ietf-ldup@imc.org; johns@cisco.com; Mark Brown (REDMOND) > Cc: capple@ecal.com; paf@cisco.com; rmoats@coreon.com; > rweiser@digsigtrust.com; stokes@austin.ibm.com > Subject: RE: WG Last Call on the LDAPv3 Directory Replication I-D > > > We addressed these issues in version -06, though we cut down the text. > > Here is the summary that was included when I sent version -06 to the > list. I haven't seen any comments on it since it was posted. > > : Internet Drafts Editor - > : > : Please publish the draft below as draft-ietf-ldup-replica-req-06.txt > : It replaces the -05 draft from November. > : > : LDUP Mailing list - > : > : The attached version of the draft incorporates changes to > address the > : comments from San Diego. We trimmed Mark's proposed > changes since we > : were concerned that they went into too much detail that > wasn't really > : LDUP related. > : > : Our specific changes are: > : > : Insert the following as the last paragraph in Section 3: > : > : Interoperability of replicas between directory servers may be > limited > : by servers that implement semantics that go beyond what the LDAP > : access protocol defines. Examples (not an exhaustive > list) of such > : semantics include: (1) replication among directory servers with > : different access control systems/semantics may compromise > directory > : security, and (2) replication among directory servers > with different > : application trigger semantics may compromise directory data > : integrity. > : > : Add the following at the end of the Security Considerations Section: > : > : As noted in Section 3, security may be impacted when replicating > : among servers that implement non-standard extensions to basic LDAP > : semantics. Access control is one common case which affects > security; > : work to address this issue is documented in RFC 2820 [RFC2820]. > : > : Add the new reference to the References: > : > : [RFC2820] E. Stokes, D. Byrne, B. Blakley, P. Behera, "Access > : Control Requirements for LDAP", RFC 2820, May 2000. > : > : Change the draft number and the publication and expiration dates. > : > : As always, please send comments to the list. > > Rick Huber > > --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- > : Subject: RE: WG Last Call on the LDAPv3 Directory Replication I-D > : Thread-Topic: WG Last Call on the LDAPv3 Directory Replication I-D > : Thread-Index: AcCP5HY9fw2/PIuYQC+oULzgUxaapgAgz+xQ > : From: "Mark Brown (REDMOND)" > : To: "John Strassner" , > : Cc: "Chris Apple" , > : =?iso-8859-1?Q?Patrik_F=E4ltstr=F6m?= > : Sender: owner-ietf-ldup@mail.imc.org > : > : The LDAPv3 Directory Replication Requirements I-D document does > : not address the interoperability limits issue that we discussed > : in December-January. > : > : I append the most recent message on the topic. > : > : --mark > : > : -----Original Message----- > : From: Mark Brown (REDMOND) > : Sent: Thursday, January 11, 2001 7:41 PM > : To: Ellen Stokes; Kurt D. Zeilenga > : Cc: ietf-ldup@imc.org > : Subject: RE: interoperability limits: proposed addition to > : draft-ietf-ldup-replica-req-05.txt > : > : Oops, I left off the examples. Let's try again: > : > : I suggest inserting the following material right after > : the first paragraph of Section 3 ("The Models") of the > : requirements draft (just before the sentence "There are five > : data consistency models.") > : > : --mark > : > : * * * * * > : > : The objective is limited to replication between directory servers > : that implement a passive store fully described by its LDAP > : interface. "Passive store" means that the servers are limited to > : storing entries that come in via LDAP and retrieving those entries > : later in response to LDAP requests. The entire semantics of > : the passive store is defined by its LDAP interface. Any > : restrictions on what the server can store must be > : expressed in the server's schema, and any restrictions on the > : access that clients have to the store must be expressed in terms > : of a standardized LDAP access control scheme. This is in > : contrast to an "active store" that implements triggers > : or other rules that extend the semantics of entries beyond > : what's implied by LDAP. Replication between such active > : stores should be specified in extensions to LDUP. > : > : Here are some examples of ways in which directory servers > : implement semantics that go beyond what the LDAP access > : protocol defines: > : > : * Access control. LDAP does not currently define an access > : control scheme. (The ldapext WG is working to extend LDAP > : with an access control scheme.) Most directory servers > : implement an access control scheme. > : > : Replication between directory servers with different > : access control schemes would compromise directory security, > : so such replication is not supported by LDUP. > : > : * Password policy. Some directory servers restrict changes > : to password attributes, requiring that the new password > : value conform to a specific security policy (e.g. the value > : is sufficiently long and complex.) Doing so reduces the > : security risk associated with passwords that are easy to > : attack. > : > : Replication between directory servers with different > : password policies (e.g. one server implements a password > : policy and a second server implements no policy) would > : compromise directory security, so such replication is not > : supported by LDUP. > : > : * Password hashing. Some directory servers don't store a user's > : password directly, but instead store one or more secure > : hashes of the password. Doing so makes it less likely that > : anyone (even an administrator) can discover the password. > : > : Replication between a directory server that stores passwords > : and a directory server that stores only hashes will compromise > : directory integrity, causing authentications to fail > : unexpectedly, so such replication is not supported by LDUP. > : > : * * * * * > : > : -----Original Message----- > : From: Mark Brown (REDMOND) > : Sent: Thursday, January 11, 2001 3:10 PM > : To: Ellen Stokes; 'Kurt D. Zeilenga' > : Cc: ietf-ldup@imc.org > : Subject: RE: interoperability limits: proposed addition to > : draft-ietf-ldup-replica-req-05.txt > : > : > : We appear to be in total agreement. > : > : So I suggest inserting the following paragraph right after > : the first paragraph of Section 3 ("The Models") of the > : requirements draft (just before the sentence "There are five > : data consistency models.") > : > : --mark > : > : * * * * * > : > : The objective is limited to replication between directory servers > : that implement a passive store fully described by its LDAP > : interface. "Passive store" means that the servers are limited to > : storing entries that come in via LDAP and retrieving those entries > : later in response to LDAP requests. The entire semantics of > : the passive store is defined by its LDAP interface. Any > : restrictions on what the server can store must be > : expressed in the server's schema, and any restrictions on the > : access that clients have to the store must be expressed in terms > : of a standardized LDAP access control scheme. This is in > : contrast to an "active store" that implements triggers > : or other rules that extend the semantics of entries beyond > : what's implied by LDAP. Replication between such active > : stores should be specified in extensions to LDUP. > : > : * * * * * > : > : --mark > : > : -----Original Message----- > : From: Kurt D. Zeilenga [mailto:Kurt@OpenLDAP.org] > : Sent: Tuesday, January 09, 2001 4:54 PM > : To: Mark Brown (REDMOND) > : Cc: Ellen Stokes; ietf-ldup@imc.org > : Subject: RE: interoperability limits: proposed addition to > : draft-ietf-ldup-replica-req-05.txt > : > : > : Mark, > : > : Replication in the face of triggers or any other LDAP extension > : should be specified in extensions to the LDUP. > : > : LDUP should assume 'passive' servers as this, I believe, is the > : LDAP/X.500 data model. That is, servers should not muck with > : user data. > : > : Kurt > > From owner-ietf-ldup@mail.imc.org Mon Feb 19 05:21:40 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id FAA00848 for ; Mon, 19 Feb 2001 05:21:39 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.9.3/8.9.3) id BAA23694 for ietf-ldup-bks; Mon, 19 Feb 2001 01:43:01 -0800 (PST) Received: from prv-mail25.provo.novell.com (prv-mail25.provo.novell.com [137.65.81.121]) by above.proper.com (8.9.3/8.9.3) with SMTP id BAA23690 for ; Mon, 19 Feb 2001 01:42:59 -0800 (PST) Received: from INET-PRV1-Message_Server by prv-mail25.provo.novell.com with Novell_GroupWise; Mon, 19 Feb 2001 02:41:35 -0700 Message-Id: X-Mailer: Novell GroupWise 5.5.5 Date: Mon, 19 Feb 2001 02:41:14 -0700 From: "Mangal Vithal Shriram" To: Subject: Replication protocol element definitions Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="=_772CD05F.05647F85" Sender: owner-ietf-ldup@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a MIME message. If you are reading this text, you may want to consider changing to a mail reader or gateway that understands how to properly handle MIME multipart messages. --=_772CD05F.05647F85 Content-Type: text/plain; charset=US-ASCII Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hi, I have been working on LDUP. I have studied a LDUP replication update = protocol document. I have some questions on the definitions of StartReplica= tionResponse and EndReplicationResponse. The StartReplicationResponse extended operations are defined as follws StartReplicationResponse::=3D[APPLICATION 23] SEQUENCE { requestName [0]LDAPOID, requestValue [1]OCTET STRING } reuestValue::=3DSEQUENCE { responseCode LDUPResponseCode, replicaUpdateVector Attribute } Actually LDAP extended operation response should have APPLICATION tag = 24. and the context tag of requestName and requestValue should be 10 and = 11 resply.=20 If you don't change this tag LDAP client will not understand this reponse = unless you change currently availabe LDAP sdk library API=20 So to preserve a LDAP operations definitions can't we change the = definitions of StartReplicatioRequest and EndReplicationRequest to LDAP = extended reponse.=20 Expecting a early response. Thanks and Regard mangal --=_772CD05F.05647F85 Content-Type: TEXT/HTML Content-Disposition: attachment; filename="TEXT.htm" Content-Transfer-Encoding: base64 PCFET0NUWVBFIEhUTUwgUFVCTElDICItLy9XM0MvL0RURCBIVE1MIDQuMCBUcmFuc2l0aW9uYWwv L0VOIj4NCjxIVE1MPjxIRUFEPg0KPE1FVEEgY29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PWlz by04ODU5LTEiIGh0dHAtZXF1aXY9Q29udGVudC1UeXBlPg0KPE1FVEEgY29udGVudD0iTVNIVE1M IDUuMDAuMzAxMy4yNjAwIiBuYW1lPUdFTkVSQVRPUj48L0hFQUQ+DQo8Qk9EWSBzdHlsZT0iRk9O VDogOHB0IE1TIFNhbnMgU2VyaWY7IE1BUkdJTi1MRUZUOiAycHg7IE1BUkdJTi1UT1A6IDJweCI+ DQo8RElWPjxGT05UIHNpemU9MT5IaSw8L0ZPTlQ+PC9ESVY+DQo8RElWPjxGT05UIHNpemU9MT5J IGhhdmUgYmVlbiB3b3JraW5nIG9uIExEVVAuIEkgaGF2ZSBzdHVkaWVkIGEgTERVUCByZXBsaWNh dGlvbiANCnVwZGF0ZSBwcm90b2NvbCBkb2N1bWVudC4gSSBoYXZlIHNvbWUgcXVlc3Rpb25zIG9u IHRoZSBkZWZpbml0aW9ucyBvZiANClN0YXJ0UmVwbGljYXRpb25SZXNwb25zZSZuYnNwOyBhbmQg RW5kUmVwbGljYXRpb25SZXNwb25zZS48L0ZPTlQ+PC9ESVY+DQo8RElWPiZuYnNwOzwvRElWPg0K PERJVj48Rk9OVCBzaXplPTE+VGhlIFN0YXJ0UmVwbGljYXRpb25SZXNwb25zZSBleHRlbmRlZCBv cGVyYXRpb25zIGFyZSBkZWZpbmVkIA0KYXMgZm9sbHdzPC9GT05UPjwvRElWPg0KPERJVj4mbmJz cDs8L0RJVj4NCjxESVY+PEZPTlQgc2l6ZT0xPlN0YXJ0UmVwbGljYXRpb25SZXNwb25zZTo6PVtB UFBMSUNBVElPTiAyM10gU0VRVUVOQ0UgDQp7PC9GT05UPjwvRElWPg0KPERJVj48Rk9OVCANCnNp emU9MT4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgDQpyZXF1ZXN0TmFtZSZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBbMF1MREFQT0lELDwvRk9OVD48L0RJVj4NCjxESVY+ PEZPTlQgDQpzaXplPTE+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IA0KcmVxdWVzdFZhbHVlJm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IFsxXU9DVEVUIA0KU1RS SU5HPC9GT05UPjwvRElWPg0KPERJVj48Rk9OVCBzaXplPTE+fTwvRk9OVD48L0RJVj4NCjxESVY+ Jm5ic3A7PC9ESVY+DQo8RElWPjxGT05UIHNpemU9MT5yZXVlc3RWYWx1ZTo6PVNFUVVFTkNFIHs8 L0ZPTlQ+PC9ESVY+DQo8RElWPjxGT05UIA0Kc2l6ZT0xPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyANCnJlc3Bv bnNlQ29kZSZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyANCkxEVVBSZXNwb25zZUNvZGUsPC9GT05UPjwvRElWPg0KPERJ Vj48Rk9OVCANCnNpemU9MT4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgDQpyZXBsaWNhVXBkYXRlVmVjdG9yJm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IA0KQXR0 cmlidXRlPC9GT05UPjwvRElWPg0KPERJVj48Rk9OVCBzaXplPTE+fTwvRk9OVD48L0RJVj4NCjxE SVY+Jm5ic3A7PC9ESVY+DQo8RElWPjxGT05UIHNpemU9MT5BY3R1YWxseSBMREFQIGV4dGVuZGVk IG9wZXJhdGlvbiByZXNwb25zZSBzaG91bGQgaGF2ZSANCkFQUExJQ0FUSU9OJm5ic3A7IHRhZyZu YnNwOyAyNC4gYW5kIHRoZSBjb250ZXh0IHRhZyBvZiByZXF1ZXN0TmFtZSBhbmQgDQpyZXF1ZXN0 VmFsdWUgc2hvdWxkIGJlIDEwIGFuZCAxMSByZXNwbHkuIDwvRk9OVD48L0RJVj4NCjxESVY+Jm5i c3A7PC9ESVY+DQo8RElWPjxGT05UIHNpemU9MT5JZiB5b3UgZG9uJ3QgY2hhbmdlIHRoaXMgdGFn IExEQVAgY2xpZW50IHdpbGwgbm90IHVuZGVyc3RhbmQgDQp0aGlzIHJlcG9uc2UgdW5sZXNzIHlv dSBjaGFuZ2UgY3VycmVudGx5IGF2YWlsYWJlIExEQVAgc2RrIGxpYnJhcnkgQVBJIA0KPC9GT05U PjwvRElWPg0KPERJVj48Rk9OVCBzaXplPTE+PC9GT05UPiZuYnNwOzwvRElWPg0KPERJVj48Rk9O VCBzaXplPTE+U28mbmJzcDt0byZuYnNwOyZuYnNwO3ByZXNlcnZlIGEmbmJzcDtMREFQJm5ic3A7 b3BlcmF0aW9ucyANCmRlZmluaXRpb25zIGNhbid0IHdlIGNoYW5nZSB0aGUgZGVmaW5pdGlvbnMg b2YmbmJzcDsgDQpTdGFydFJlcGxpY2F0aW9SZXF1ZXN0Jm5ic3A7IGFuZCBFbmRSZXBsaWNhdGlv blJlcXVlc3QgdG8gTERBUCBleHRlbmRlZCByZXBvbnNlLiANCjwvRk9OVD48L0RJVj4NCjxESVY+ Jm5ic3A7PC9ESVY+DQo8RElWPkV4cGVjdGluZyBhIGVhcmx5IHJlc3BvbnNlLjwvRElWPg0KPERJ Vj4mbmJzcDs8L0RJVj4NCjxESVY+VGhhbmtzIGFuZCBSZWdhcmQ8L0RJVj4NCjxESVY+bWFuZ2Fs PC9ESVY+DQo8RElWPiZuYnNwOzwvRElWPjwvQk9EWT48L0hUTUw+DQo= --=_772CD05F.05647F85-- From owner-ietf-ldup@mail.imc.org Mon Feb 19 11:28:49 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA08267 for ; Mon, 19 Feb 2001 11:28:48 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.9.3/8.9.3) id HAA06360 for ietf-ldup-bks; Mon, 19 Feb 2001 07:34:24 -0800 (PST) Received: from relay1.pair.com (relay1.pair.com [209.68.1.20]) by above.proper.com (8.9.3/8.9.3) with SMTP id HAA06348 for ; Mon, 19 Feb 2001 07:34:21 -0800 (PST) Received: (qmail 7184 invoked from network); 19 Feb 2001 15:33:50 -0000 Received: from cpe-144-132-70-18.vic.bigpond.net.au (HELO w98) (144.132.70.18) by relay1.pair.com with SMTP; 19 Feb 2001 15:33:50 -0000 X-pair-Authenticated: 144.132.70.18 Reply-To: From: "Albert Langer" To: "=?iso-8859-1?Q?'Patrik_F=E4ltstr=F6m'?=" , "'John Strassner'" Cc: "'John Strassner'" , , "'Chris Apple'" , "'Ned Freed'" Subject: RE: WG Last Call on the LDAPv3 Directory Replication I-D Date: Tue, 20 Feb 2001 02:37:00 +1100 Message-ID: <000f01c09a89$cdd41800$6628a8c0@nowhere.com> 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 CWS, Build 9.0.2416 (9.0.2910.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 In-Reply-To: Importance: Normal Sender: owner-ietf-ldup@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit [Patrik] This is a hypothetical discussion as a WG doesn't appoint liasons. Because of some misunderstandings between the IESG and the IESG Secretariat, a wrong charter has been published, and it will be updated. http://www.imc.org/ietf-ldup/mail-archive/msg00822.html [Albert] A "thank you" for having drawn this to the WG's attention was not necessary. It is quite sufficient that you have now indicated that the wrong charter will be fixed as I requested. However your remarks below were completely uncalled for, and after having waited for more than my customary 24 hours and thought about it carefully, I consider it necessary to reply sharply. [Patrik] Also, Albert, note that the IETF follow the principle of rough consensus, and that a wg chair have the full responsibility and power of declaring such consensus. [Albert] The liason with the ITU was removed from the WG charter without any consensus "rough" or otherwise. Nor was any consensus "declared". The only document shown to the WG included the paragraph you have now agreed should not have been removed. It was removed unilaterally without any consultation whatsoever. No doubt that was an oversight, which has now been corrected and does not require any further comment. Your remarks below however are rather more serious. [Patrik] I must ask you to follow the decisions made in the wg following this principle, and only if you have very explicit objections that the decisions made were wrong, you can send in a formal appeal to the Area Director and/or the IESG. [Albert] No decision was made in the WG about the matter you are responding to - liason with the ITU. That is absolutely clear and has now been corrected. I raised a very specific objection about it in the proper place and at the proper time. It would have been quite wrong to formally appeal to anybody without raising the issue first. BTW the CC to you was because the message I was responding to was CCed to you and I used "reply all" as usual. Likewise the CC list now is for exactly the same reason - not because I am appealing to anybody about anything. I am simply responding to your public remarks to the same people you addressed them to. [Patrik] I can not allow you to delay the work in the wg by being the only person working against consensus which is declared by the wg chair(s). [Albert] By admonishing me for raising the matter, you are actively discouraging members of the WG (whether generally or just me is irrelevant), from quite properly raising issues about matters they have explicitly been asked to comment on, and asserting - absurdly - that WG chairs have "powers" to simply "declare consensus" without asking anybody what they actually think about what they propose to do - and indeed without even bothering to tell them when they have done it. Only the sheer absurdity of your accusation mitigates its outrageousness. You could not possibly really intend to intimidate me or anyone else from raising such issues, nor to encourage WG chairs to "declare consensus" without telling anybody, or you would not have picked such a totally clear cut, black and white case to shoot yourself in the foot. What remains however, is that you are being gratuitously offensive. If the cause of that is some other matter that you want to raise with me, either publicly or privately, I suggest that you do so, rather than making really ridiculous public accusations in an absurd context. If you want me to take anything you do have to say seriously, I suggest you do not respond immediately, but carefully review the sequence of messages and take at least 24 hours to decide whether you ought to withdraw your gratuitously offensive remarks. Meanwhile, I hereby formally reject your admonishment. Whether you "allow" it or not, I intend to continue carrying out my responsibility as a WG participant to respond to formal requests for comment by stating my views. That is not "working against consensus" - it is absolutely vital to the mechanism by which consensus is determined. Attempting to silence people who disagree with popular views is not "working for consensus" but actively preventing it. If I am indeed "the only person" with a particular view, that can quite obviously neither prevent the WG from reaching a consensus nor delay its work. It would certainly be irresponsible for me to refrain from expressing those views when asked for comment. No consensus has been "declared" on any matter that I have commented on. The WG is currently considering a "final call" on a document, *after* which it is the responsibility (not "power") of WG chairs to determine whether a consensus exists. In case the sniping I have been copping from you, Chris and John is related to my having "held up" the requirements draft by objecting to a previous final call on it, here's a reminder of the actual situation: According to Chris (email 18 July 2000): *** 1) I've read it CAREFULLY and believe that its ready. 2) My co-chair has read it CAREFULLY and believes that its ready. 3) Active members of the Working Group who represent a majority of the most prevalent players in the LDAP industry have read it CAREFULLY, many, many times and believe that its ready. 4) Adding clarifications to the document such as adding an explicit statement indicating that atomicity of operations will not be addressed by LDUP can and should be handled DURING IETF Last Call. That's my interpretation and position on how to handle comments like this that are introduced after the WG last call window has elapsed. 5) If you believe that there are serious breeches in the requirements having had adequate review and believe that it is directly related to the way the WG processes are being managed by John and myself, you should feel free to take that up directly with Patrik Faltstrom and Ned Freed. I can assure you that there is absolutely no chance I will ever agree with you about whether or not the document is ready for IETF Last Call. And since I'm co-chair and John agrees with me, the request we have made of the Applications ADs for IESG Review prior to IETF Last Call WILL proceed. *** Your contribution at the time was as folows (email 20 July 200): *** I think you have a plan, which for me looks like "discussions at the next IETF" and "then close the box by approving the minutes". I will see, as AD, that the box will close, and stay closed. *** Needless to say the document wasn't ready and the "plan" was not carried out. I wasn't at the IETF meeting a couple of weeks after that chest thumping, and all I know of what happened is from the minutes. A quite different result emerged. The document was largely re-written, with two new authors added and is *much* better for it. So don't accuse me of "delaying the work in the wg by being the only person working against consensus which is declared by the wg chair(s)", and don't be surprised that I am not inclined to simply take anybody's opinion as to whether a document is ready on the basis of their authority as a WG chair. You find out whether a consensus exists by *asking*, not by thumping your chest. The WG has also been informed of a proposal to change the charter and asked whether anybody objected to that process being accelerated. I objected and there has been no subsequent attempt to ascertain the opinions of the WG on the matters I raised. In particular the WG has not been asked whether they agree that the current charter should be amended so that the URP protocol is finalized before the architecture and information model is finalized, or whether they agree with my objection or have some other view. All that is needed is to simply *ask*. There may well be a consensus one way or another, but not even the most omniscient WG chair could possibly find out without asking. From owner-ietf-ldup@mail.imc.org Mon Feb 19 12:17:36 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA09575 for ; Mon, 19 Feb 2001 12:17:36 -0500 (EST) Received: by above.proper.com (8.9.3/8.9.3) id IAA10340 for ietf-ldup-bks; Mon, 19 Feb 2001 08:39:05 -0800 (PST) Received: from cisco.com (nordic.cisco.com [144.254.116.47]) by above.proper.com (8.9.3/8.9.3) with ESMTP id IAA10331 for ; Mon, 19 Feb 2001 08:39:03 -0800 (PST) Received: from [10.21.51.77] (herbst-isdn4.cisco.com [10.21.51.77]) by cisco.com (8.8.8+Sun/8.8.8) with ESMTP id RAA13761; Mon, 19 Feb 2001 17:37:49 +0100 (MET) Mime-Version: 1.0 X-Sender: pfaltstr@nordic.cisco.com Message-Id: In-Reply-To: <000f01c09a89$cdd41800$6628a8c0@nowhere.com> References: <000f01c09a89$cdd41800$6628a8c0@nowhere.com> Date: Mon, 19 Feb 2001 08:36:03 -0800 To: "Albert Langer" , "'John Strassner'" From: Patrik =?iso-8859-1?Q?F=E4ltstr=F6m?= Subject: RE: WG Last Call on the LDAPv3 Directory Replication I-D Cc: "'John Strassner'" , , "'Chris Apple'" , "'Ned Freed'" Content-Type: text/plain; charset="iso-8859-1" ; format="flowed" Sender: owner-ietf-ldup@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: X-MIME-Autoconverted: from 8bit to quoted-printable by above.proper.com id IAA10340 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id MAA09575 At 02.37 +1100 01-02-20, Albert Langer wrote: >[Albert] >The liason with the ITU was removed from the WG charter without any >consensus "rough" or otherwise. Nor was any consensus "declared". > >The only document shown to the WG included the paragraph you have now >agreed should not have been removed. It was removed unilaterally >without any consultation whatsoever. The charter can be changed by the IESG without any other consultation with the wg than information of the change being done. This information had not been sent to the wg, as the charter was not supposed to have been published until the new paragraph was constructed. >[Albert] >By admonishing me for raising the matter, you are actively discouraging >members of the WG (whether generally or just me is irrelevant), from quite >properly raising issues about matters they have explicitly been asked to >comment on, and asserting - absurdly - that WG chairs have "powers" >to simply "declare consensus" without asking anybody what they actually >think about what they propose to do - and indeed without even bothering >to tell them when they have done it. What obviously was unclear from my message was that I talked about two different issues: (a) The fact that the discussion about liasons was not needed as IESG took decisions on what text should go in the charter (b) The number of issues which the wg chair have declared being consensus in the wg -- and you still bring up the issues >Only the sheer absurdity of your accusation mitigates its outrageousness. >You could not possibly really intend to intimidate me or anyone else >from raising such issues, nor to encourage WG chairs to "declare consensus" >without telling anybody, or you would not have picked such a totally clear >cut, black and white case to shoot yourself in the foot. I have seen discussions on this mailing list, and on some IETF meetings, going around in circles regarding multimaster replication where the wg chair(s) together with other wg participants have tried to tell you that the model you propose is not what the wg is doing. The discussion basically started (as far I can recollect) with your submission of draft-langer-ldup-mdcr-00.txt in april 2000. Do _you_ have any suggestion on how the wg can get some more progress? paf -- Patrik Fältström Internet Engineering Task Force Area Director, Applications Area http://www.ietf.org Phone: (Stockholm) +46-8-4494212 (San Jose) +1-408-525-0940 PGP: 2DFC AAF6 16F0 F276 7843 2DC1 BC79 51D9 7D25 B8DC From owner-ietf-ldup@mail.imc.org Mon Feb 19 13:42:01 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA11376 for ; Mon, 19 Feb 2001 13:42:01 -0500 (EST) Received: by above.proper.com (8.9.3/8.9.3) id KAA13658 for ietf-ldup-bks; Mon, 19 Feb 2001 10:04:31 -0800 (PST) Received: from correo.007mundo.com ([63.171.232.45]) by above.proper.com (8.9.3/8.9.3) with ESMTP id KAA13637 for ; Mon, 19 Feb 2001 10:04:20 -0800 (PST) Received: from mail01bg ([192.168.168.21]) by correo.007mundo.com with Microsoft SMTPSVC(5.5.1877.197.19); Mon, 19 Feb 2001 13:03:09 -0500 Received: from correo.007mundo.com ([192.168.170.2]) by mail01bg (NAVIEG 2.1 bld 63) with SMTP id M2001021913030626080 for ; Mon, 19 Feb 2001 13:03:07 -0500 From: To: Date: Mon, 19 Feb 2001 09:21:43 Message-Id: <478.56831.50287@correo.007mundo.com> Mime-Version: 1.0 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 < get your own 100 meg web site for only $11.95 per month today! STOP PAYING $19.95 or more PER MONTH for your web site, WHEN YOU CAN GET ONE FOR ONLY $11.95 PER MONTH! DO YOU ALREADY HAVE A WEBSITE? ALL YOU HAVE TO DO IS TRANSFER THE DOMAIN TO OUR SERVERS AND UPLOAD YOUR DATA AND YOU ARE READY TO GO! YOUR NEW WEB SPACE CAN BE CREATED INSTANTLY WITH JUST A SIMPLE PHONE CALL OUR OFFICE. YOU CAN CHANGE YOUR SITE AS MUCH AS YOU WANT with no extra charge! UNLIMITED TRAFFIC -- no extra charge! A SET UP FEE OF $40.00 APPLIES for FIRST TIME CUSTOMERS. ALL FEES PREPAID IN ADVANCE FOR THE YEAR PLUS A $40.00 SET UP CHARGE. FOR DETAILS CALL 1 888 248 0765 or fax 240 337 8325 WEB HOSTING INTERNATIONAL From owner-ietf-ldup@mail.imc.org Mon Feb 19 16:39:36 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA15368 for ; Mon, 19 Feb 2001 16:39:33 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.9.3/8.9.3) id NAA17751 for ietf-ldup-bks; Mon, 19 Feb 2001 13:02:36 -0800 (PST) Received: from sj-msg-core-1.cisco.com (sj-msg-core-1.cisco.com [171.71.163.11]) by above.proper.com (8.9.3/8.9.3) with ESMTP id NAA17747 for ; Mon, 19 Feb 2001 13:02:35 -0800 (PST) Received: from mira-sjcm-1.cisco.com (mira-sjcm-1.cisco.com [171.69.43.102]) by sj-msg-core-1.cisco.com (8.9.3/8.9.1) with ESMTP id NAA23400; Mon, 19 Feb 2001 13:02:25 -0800 (PST) Received: from JSTRASSN-W2K1.cisco.com (sj-dial-4-75.cisco.com [171.68.181.204]) by mira-sjcm-1.cisco.com (Mirapoint) with ESMTP id AAC01767; Mon, 19 Feb 2001 13:01:58 -0800 (PST) Message-Id: <4.3.2.7.2.20010219100603.00b4bab0@mira-sjcm-1.cisco.com> X-Sender: jstrassn@mira-sjcm-1.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Mon, 19 Feb 2001 10:26:44 -0800 To: From: John Strassner Subject: RE: WG Last Call on the LDAPv3 Directory Replication I-D Cc: "'Kurt D. Zeilenga'" , In-Reply-To: <002701c09920$85d97c80$6628a8c0@nowhere.com> References: <5.0.2.1.0.20010217074033.00a53140@router.boolean.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ietf-ldup@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Please see comments inline, delineated by ... regards, John At 07:30 AM 2/18/2001 +1100, Albert Langer wrote: >[Kurt] >At 04:39 PM 2/17/01 +1100, Albert Langer wrote: > >Put succinctly: LDUP directories won't interoperate. Period. > >I would say that two LDUP peers could interoperate (from >a protocol perspective) but that this, in itself, does >not: > 1) preserve LDAP/X.500 semantics nor > 2) provide "equally capable" replicas. > >The former issue can not be resolved unless one requires >transactional consistency in multiple master replication. >The latter issue can be tackled by writing a very tight >applicability statements. > >[Albert] >We seem to be agreed that "LDUP directories won't interoperate" >(unless of course you mean that an LDUP directory need not preserve LDAP >semantics - which seems implausible ;-) > >If by "transactional" consistency you are referring to updates affecting >more than one directory entry, that is not part of LDAP semantics. > >If you mean "atomic operations", that is part of LDAP semantics and I >certainly agree that the issue cannot be resolved without it ;-) > >A necessary consequence of multi-master, as opposed to single master, >is that in addition to transient inconsitencies between data read from >different directory servers there will also be problems with data read >from a single server. There are 2 options possible for multi-master: > >1) Conflicting updates to the same entry are prioritized so that only >one succeeds and the others are rolled back. That necessarily results >in different behaviour to single master directories but is not >fundamentally inconsistent with LDAP semantics and does not prevent >interoperability. Problems arising can be resolved by users rather than >sysadmins by notifying them of lost updates (whether due to name conflicts >or other conflicts). Albert, the wg looked at this option and rejected it. We thought that it would be a Bad Thing to have different behavior in the multi-master system compared to the single-master system. While it may not be inconsistent with LDAP semantics, it is inconsistent with what the user would expect. This has been clearly documented in both the minutes and presentations of past meetings. Why are you bringing it up again? >An applicability statement should clearly indicate >that multi-master is unsuitable in any situation with a high rate of >concurrent changes to the same entries. Again, the wg doesn't concur. Plus, I'm confused why you would make this statement, as you positioned your proposal as solving these problems. We have figured out that you don't agree with the design. ;-) The bottom line is that as chair, I need positive comments detailing how to fix a problem. We've had enough complaints through these threads, so I'm asking you to please contain your commentary to clear, explicit corrective action. >2) Changes are not "rolled back" so, by definition, atomicity is not >preserved when updates conflict. This necessarily results in both transient >and permanent loss of data integrity. Not true. First, applications can certainly build locking and other mechanisms to isolate operations affecting an update. The requirement I-D states that IF data loss could occur, then the sysadmin should be notified. This is not the same as just throwing away the update. Furthermore, I don't see how you are going to "roll back" changes given the current LDAP data model. If you'd like to talk to me off-line, I'd be happy to discuss this point with you. >In particular it breaks >currently proposed access control mechanisms. I mention it as an >"option" only because it is the current architecture, not because it >has any technical merit whatever. An "inapplicability statement" should >then clearly indicate that multi-master is unsuitable in any situation that >requires data integrity. Since interoperable directories require high >integrity access control mechanisms that means it is simply "not >applicable". Statements such as this are not helpful. Please try and comment in a positive manner. From owner-ietf-ldup@mail.imc.org Mon Feb 19 16:42:21 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA15415 for ; Mon, 19 Feb 2001 16:42:21 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.9.3/8.9.3) id MAA17321 for ietf-ldup-bks; Mon, 19 Feb 2001 12:49:00 -0800 (PST) Received: from relay1.pair.com (relay1.pair.com [209.68.1.20]) by above.proper.com (8.9.3/8.9.3) with SMTP id MAA17317 for ; Mon, 19 Feb 2001 12:48:57 -0800 (PST) Received: (qmail 26475 invoked from network); 19 Feb 2001 20:48:41 -0000 Received: from cpe-144-132-70-18.vic.bigpond.net.au (HELO w98) (144.132.70.18) by relay1.pair.com with SMTP; 19 Feb 2001 20:48:41 -0000 X-pair-Authenticated: 144.132.70.18 Reply-To: From: "Albert Langer" To: "=?iso-8859-1?Q?'Patrik_F=E4ltstr=F6m'?=" , "'John Strassner'" Cc: "'John Strassner'" , , "'Chris Apple'" , "'Ned Freed'" Subject: RE: WG Last Call on the LDAPv3 Directory Replication I-D Date: Tue, 20 Feb 2001 07:51:55 +1100 Message-ID: <001601c09ab5$cb956ea0$6628a8c0@nowhere.com> 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 CWS, Build 9.0.2416 (9.0.2910.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Importance: Normal Sender: owner-ietf-ldup@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit [Patrik] I have seen discussions on this mailing list, and on some IETF meetings, going around in circles regarding multimaster replication where the wg chair(s) together with other wg participants have tried to tell you that the model you propose is not what the wg is doing. The discussion basically started (as far I can recollect) with your submission of draft-langer-ldup-mdcr-00.txt in april 2000. Do _you_ have any suggestion on how the wg can get some more progress? [Albert] That draft expired long ago and I have not renewed it because no interest was shown in it. I do have several suggestions as to how the WG can get more progress. They are in no way related to my MDCR draft. I intend to make them when the WG chairs place the question of revising the charter properly before the WG. I explained that clearly in response to the proposed accelerated revision submitted by the WG chairs: *** [John and Chris revision] Hi LDUPers, below is a revised charter for our workgroup. Chris and I need your comments asap, so that we can present our new charter to our AD. Please especially note the new dates for our delierables. I'd like this review closed as soon as possible. If anyone objects to review ending next Friday 19 January, please object soon. regards, John and Chris [Albert] This was dated 13 January and received here on 14 January. In my view charter revision should be taken as an opportunity to formally review the progress and direction of the WG and should therefore not be pushed through casually with less time for comment than a WG final call. [...] [Albert] Propos[al] to finalize the Update Reconciliation Procedures four months [actually 3 -AL] prior to finalizing the Information Model and Architecture lacks common sense. [revision] Dec 01 Reevaluate Charter and Milestones [Albert] If nobody else thinks there should be an earlier reevaluation of the progress so far in the light of earlier milestones, fine. But WG members should be explicitly asked to reflect on this rather [than] treating a consistent inability to achieve milestones as grounds for accelerating the process by which new milestones are adopted, especially when the proposed means to achieve new milestones is [..] for RFCs on detailed implementation to be settled before Information Model and Architecture. *** http://www.imc.org/ietf-ldup/mail-archive/msg00784.html I am still waiting for the WG chairs to ask the question. It may well be that nobody else other than me (and perhaps you) does think some review of progress is desirable now, in which case it would be disruptive to simply proceed to introduce a new agenda item that has not been agreed on. We won't know whether the WG wants to discuss how to get more progress until the WG chairs do ask the question, or delay doing so for unreasonably long, - which is not the case yet, as I posted that request in mid-January which is often a vacation period and one of the WG co-chairs is (now) known to be currently on vacation. I do however insist that they must ask the question, and have made that clear by promptly objecting to the unauthorized posting of a revised WG charter as soon as I noticed it. If you want a "sneak preview" I believe that the fundamental problems are: 1) Natural consequence of having attempted to work through detailed protocol issues before finalizing requirements, architecture and information model. That *always* results in lack of progress and I see nothing surprising about it having happened here. What is surprising is the grim determination with which those who made that mistake two years ago refuse to learn from it. 2) Exacerbated by the failure of the WG chairs to actively participate in technical discussions on the list and guide them towards resolution rather than aimless meandering. I have seen competent and useful summaries of discussions at IETF meetings in the minutes they have circulated, which provide a regular quarterly survey of the (lack of) progress. But they do nothing to ever pose issues for resolution, ask for clarification, attempt to restate different viewpoints etc etc in mailing list discussions as opposed to IETF meetings, although the mailing list is ultimately where the WG has to conduct its business. Consequently there is no sense of a discussion having actually "got anywhere" and people just view the passing parade of LDUP messages and assorted spam traversing their mailboxes as a sort of "spectacle" rather than an actual standards development process which they can contribute to bringing to fruition. Although you refer to: "(b) The number of issues which the wg chair have declared being consensus in the wg -- and you still bring up the issues" the real problem is opposite - the complete failure to actually put any issues for decision in the mailing list and then declare the question resolved. If you believe your impression is accurate, please simply cite URLs from the archives showing conclusions of discussions that have been announced as consensus decisions by the WG chairs followed by further discussion from me. Here are some examples of "action" items as far back as from the minutes of the August 2000 IETF: *** 3. Change reports - Use ProtocolOps or Primitives Action: no consensus, need further discussion on the list. It was note that we need to include how each addresses (or doesn't address) atomicity. 4. Eventual convergence - Version numbers or timestamps Action: looks like a religious argument; no consensus reached. 5. Oscillation The claim has been made that MDCR oscillates. Everyone agrees that oscillation is bad. Needs more discussion on the list. *** http://www.imc.org/ietf-ldup/mail-archive/msg00688.html All of these are explicit minuted recognition that various issues I have raised have not reached consensus and should be discussed further on the list. Now show me where the WG chairs have: a) Opened the discussion b) Led it to a conclusion c) Announced the result Your "plan" was that IETF meeting would simply adopt the "consensus" which Chris was thumping his chest about in email "then close the box by approving the minutes". If you believe that plan was successfully executed and are now trying to carry through your commitment "I will see, as AD, that the box will close, and stay closed", then you are simply hallucinating. It was Chris who said: *** 1) I've read it CAREFULLY and believe that its ready. 2) My co-chair has read it CAREFULLY and believes that its ready. 3) Active members of the Working Group who represent a majority of the most prevalent players in the LDAP industry have read it CAREFULLY, many, many times and believe that its ready. [...] I can assure you that there is absolutely no chance I will ever agree with you about whether or not the document is ready for IETF Last Call. [...] *** That was not a declaration of consensus by a WG chair but a personal opinion by Chris. I wasn't at the IETF meeting so don't blame me for him having got the actual situation so spectacularly wrong. As for going around in circles on (atomicity) in multi-master that is really the same problem. From time to time somebody says something, someone else responds and so it goes. The WG chairs simply do not attempt to state clear questions for resolution to the mailing list and have them resolved. For my part I concluded long ago that further argument on atomicity would be pointless within the WG and that the technical mistake I believe is being made will ultimately have to be resolved elsewhere: *** 2. My objection to non-atomicity still stands for final call but I'm assuming there is little point arguing about it further within LDUP unless others want to take it up. The draft now at least makes it possible to have serious discussion about the issue in IETF review and does include several requirements which cannot in fact be met without atomicity, such as accurate replication of access controls and attributes such as "modifiers name". although I disagree with much of the analysis in appendix B.5 and also the continued misunderstanding of applications for multi-master replication in appendix A on usage scenarios. There are still some inadequacies in presentation of the issue but the fundamental question is now simply whether or not atomicity should be a requirement rather than whether a document that shows no comprehension of the issue at all should be presented to the IETF at all. I still believe a fundamental technical mistake is being made on that question. I also still believe the requirements draft should be actively seeking input from directory users on the impact of non-atomicity. *** That was 20 October 2000. http://www.imc.org/ietf-ldup/mail-archive/msg00712.html *** I assume the absence of expressed opposition from others, and the report of discussions at the last LDUP meeting at IETF, does reflect a "rough consensus" within the WG against "atomicity" etc. My understanding is that my continuing belief that this is a fundamental technical mistake should therefore be expressed as opposition to LDUP's final position rather than delaying LDUP from publishing that as it's final position. The WG has had an adequate opportunity to change it's position. *** http://www.imc.org/ietf-ldup/mail-archive/msg00734.html That was in response to Rick's request for a final call on 14 November: http://www.imc.org/ietf-ldup/mail-archive/msg00733.html It led to Rick apparantly wanting to pursue some further discussion on it: http://www.imc.org/ietf-ldup/mail-archive/msg00736.html Which was promptly squelched by chest thumping from Chris: http://www.imc.org/ietf-ldup/mail-archive/msg00738.html Needless to say, Chris did not keep his commitment to prepare some comments on the atomicity and access control issue (it would I believe have been his *first* technical contribution to the list in the entire period I have been participating). Nor did he issue any final call as requested by the authors of the draft. You can hardly blame me for it *still* not being resolved, when I explicitly said that I thought a consensus (which I disagreed with) existed, and that my opposition should not be grounds for further delay publishing the WG's position. Unless of course you think the reluctance to actually finalize the matter and get on with it is due to knowing that there are no technical arguments available to defend the position in IETF final call and that therefore it is my fault because I have made it clear that it will be necessary to do so. My understanding is that posturing about how many people agree with you and how often they have said so is no substitute for technical argument in the IETF. If my technical arguments are rejected by the IETF that will be the end of it. So far no decision has been taken by LDUP WG, let alone the IETF. Instead of acceeding to Rick's request for final call last millenium, supported by me, this little gem appeared in the draft minutes of the San Diego IETF LDUP meeting: *** 3. Atomicity issues. RESPONSE: Albert wants all changes from a server to be handled in an atomic fashion. This was basically the same position as was argued in the last session (please refer to the last minutes on this subject). This requirement seems unreasonable. The obvious counter-example is when multiple servers each write to one or more attributes of the same entry. In a single- master situation, one would hope that you would end up with the cumulative changes, and there is no reason to have a multi-master system not exhibit that same behavior. [...] The room consensus was to keep the draft as is. *** http://www.imc.org/ietf-ldup/mail-archive/msg00767.html I'm seriously thinking of buying a printed copy of the formal proceedings just so that I can have that laminated as a memento that an entire room full of people at an IETF meeting actually did endorse such patent nonsense. (BTW there are still no final minutes from LDUP in the proceedings) Reasonable people with an expert knowledge of LDAP can reasonably disagree about what trade offs should be made concerning atomicity and other design constraints in a multi-master context. But there is absolutely no point discussing technical questions about atomicity in a WG where an entire roomful of people can be found *all* of whom agreed with this "obvious counter example". They simply do not understand what the issue is about and are therefore not qualified to take the final decision on it. They may have expert knowledge of LDAP and many other things, but they are simply not qualified to be tackling issues concerning concurrent updates in multi-master replication. Nevertheless, when a final call is issued, with the words "silence is consent", WG members have a responsibility to state their position before taking the issue elsewhere. My position is that the whole point of the requirement for atomicity spelt out in the specifications of the LDAP modify operation is precisely to prevent cumulative changes from conflicting writes which could otherwise occur even on a single server due to changes being made by other DUAs after a read and before a write. That is essential for applications that require data integrity, which of course includes access control applications. Without high integrity access control, interoperability is impossible. If you have a WG chaired by someone who actually thinks accumulation of changes from conflicting writes is *desirable* and it is "unreasonable" to try and prevent it, and nobody in the room can correct the mistake, then that WG is simply not qualified to take the final decision. Basically the WG is going around in circles on numerous issues concerning multi-master replication because it simply does not have the technical expertize to be tackling a project as difficult as multi-master replication of directory services. Incidentally, if you check the archives, you will find that several people who do were actively involved in the WG when it was first chartered but dropped out long before I joined. I repeat my suggestion that in establishing liason with the ITU, the WG should study *why* they dropped the URP proposal as a work item. It was after all introduced and originally accepted here as a joint project. When the WG *does* take a decision it can be reviewed. Until then it can't be. Presumably a decision will *have* to be taken when either architecture or URP goes through final call. The responsibility for not having taken a decision and moved on lies entirely with the WG chairs. Accusing me of "working against" a decision that has not been taken is absurd. Chris, John and you should damn well stop the sniping and get on with the job. It is *especially* absurd that you 3 are the ones engaging in the sniping when *none* of you have participated in the various arguments in which I have sharply disagreed with the views of other members of the WG. It is not unusual for sharp technical disputes to spill over into flame wars which require intervention by either WG chairs or even Area Directors to restore a sense of perspective. What is unusual is for WG chairs and Area Directors to be inflaming things when others are able to simply agree to disagree, and do so without chest thumping, accusations of "unprofessional" comments or nonsensical claims about "working against" decisions that haven't been taken. From owner-ietf-ldup@mail.imc.org Mon Feb 19 16:47:12 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA15524 for ; Mon, 19 Feb 2001 16:47:12 -0500 (EST) Received: by above.proper.com (8.9.3/8.9.3) id NAA18411 for ietf-ldup-bks; Mon, 19 Feb 2001 13:14:56 -0800 (PST) Received: from mail.coreon.net (IDENT:mirapoint@mail.coreon.net [216.74.131.6]) by above.proper.com (8.9.3/8.9.3) with ESMTP id NAA18405 for ; Mon, 19 Feb 2001 13:14:54 -0800 (PST) Received: from rmoats2 (wenjus3.coreon.net [216.74.131.3]) by mail.coreon.net (Mirapoint) with ESMTP id AAA75804 (AUTH rmoats); Mon, 19 Feb 2001 16:13:21 -0500 (EST) From: "Ryan Moats" To: "John Strassner" Cc: , "'Mark Brown \(REDMOND\)'" , "'Richard V Huber'" , , , , , , Subject: RE: WG Last Call on the LDAPv3 Directory Replication I-D Date: Mon, 19 Feb 2001 15:18:10 -0600 Message-ID: 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 IMO, Build 9.0.2416 (9.0.2911.0) Importance: Normal In-Reply-To: <4.3.2.7.2.20010219102747.00b48770@mira-sjcm-1.cisco.com> 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: Content-Transfer-Encoding: 7bit Sure John, I'm extracting the relavant pieces and using this time. Ryan [...snip...] > >I still regard it as a vast improvement on the previous >because it clearly > >rules out the current architecture and URP, which is not >capable of > >maintaining > >the information needed to notify admins as required. > >Another IETF procedural point: I don't believe that >the requirements "rule out" the current architecture and >protocol. I believe the ADs/charis will agree that what >this does is put the onus on the architecture and protocol >drafts to explain WHY (in acceptable detail) they are ignoring >specific requirements. Of course, if the ADs/chairs >disagree, that would be good to know too :-) I agree with Ryan's characterization. [...snip...] >Thanks, now I have a clearer picture. I don't remember >seeing a "last call" call for the URP draft yet (although >I'm not looking at the archives at this moment) and I >do believe that the point I raised above is a fair comment >for the URP draft to answer when it goes to last call The URP draft has NOT been issued as a last call yet. Sorry Ryan, but I'm not sure that I know which "point above" you are referring to. Could you please point this out? If URP goes to last call without (at least for me) acceptible statements as to why it doesn't meet certain requirements, I'll try to be first in line saying "uh, I don't see that you've met requirement nor do I see a statement as to why", that's all. From owner-ietf-ldup@mail.imc.org Mon Feb 19 16:49:32 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA15607 for ; Mon, 19 Feb 2001 16:49:32 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.9.3/8.9.3) id NAA17758 for ietf-ldup-bks; Mon, 19 Feb 2001 13:02:57 -0800 (PST) Received: from sj-msg-core-1.cisco.com (sj-msg-core-1.cisco.com [171.71.163.11]) by above.proper.com (8.9.3/8.9.3) with ESMTP id NAA17753 for ; Mon, 19 Feb 2001 13:02:56 -0800 (PST) Received: from mira-sjcm-1.cisco.com (mira-sjcm-1.cisco.com [171.69.43.102]) by sj-msg-core-1.cisco.com (8.9.3/8.9.1) with ESMTP id NAA23501; Mon, 19 Feb 2001 13:02:41 -0800 (PST) Received: from JSTRASSN-W2K1.cisco.com (sj-dial-4-75.cisco.com [171.68.181.204]) by mira-sjcm-1.cisco.com (Mirapoint) with ESMTP id AAC01770; Mon, 19 Feb 2001 13:02:08 -0800 (PST) Message-Id: <4.3.2.7.2.20010219102747.00b48770@mira-sjcm-1.cisco.com> X-Sender: jstrassn@mira-sjcm-1.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Mon, 19 Feb 2001 11:04:32 -0800 To: rmoats@coreon.net From: John Strassner Subject: RE: WG Last Call on the LDAPv3 Directory Replication I-D Cc: Albert.Langer@directory-designs.org, "'Mark Brown (REDMOND)'" , "'Richard V Huber'" , ietf-ldup@imc.org, johns@cisco.com, capple@ecal.com, paf@cisco.com, rweiser@digsigtrust.com, stokes@austin.ibm.com In-Reply-To: <200102172155.AAB81305@mail.coreon.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ietf-ldup@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Please see comments inline, delineated by ... regards, John At 04:52 PM 2/17/2001 -0500, rmoats@coreon.net wrote: >I think I'm using ... this time... Ryan > > >Date: Sun, 18 Feb 2001 07:33:41 +1100 > >Subject: RE: WG Last Call on the LDAPv3 Directory >Replication I-D > > > >[Albert] > >There is an overlap between the authors of the requirements >draft and the > >authors of LDAP access control requirements and other drafts >but a radical > >inconsistency between currently proposed access control >schemes that rely on > >atomicity and the lack of understanding of atomicity issues >in LDUP. > > > >I'll admit I don't understand the technical point of >this comment. > > > > > >[Albert] > >Try plugging examples similar to those discussed in Appendix >B using access > >control attributes as specified in current access control >drafts, taking > >into account the transient outcomes I quoted from Alison's >discussion of > >URP consistency model in: > > > >http://www.imc.org/ietf-ldup/mail-archive/msg00738.html > >Well, as I explained to Mark, in the absense of an >access control standard, I don't see the point and (here's >where folks disagree) I don't think we should talk about >it here, but rather in LDAPEXT where the access control >work is being done. Mind you, I'm not saying access >control will or won't be replicated, I'm making a procedural >distinction. If the chairs of LDAPEXT/LDUP disagree with >me, we can certainly open it here, but its (IMHO) a done >deal that LDUP won't make any progress until the access >control model is finished, and I'm certainly not in favor >of that. With chair hat on, I for one think that access control replication needs to happen in LDAPext. There are two reasons that I think this. First, LDAPext is currently chartered to do access control. Suppose they finish and produce a standards-track RFC, and LDUP comes along and says "wait a minute, something's wrong". Shouldn't the original authors fix the problems? Second, and more troubling, if we follow this model, then every draft that presents unique information, or information that should be specially handled, should require LDUP to fix it. This will ensure that we have a never-diminishing charter, which is a Bad Thing. > >BTW That message is actually Chris's reply, disrupting an >attempt to discuss > >this issue and other issues with Rick, from which I hope you >will understand > >why I am not currently inclined to pursue the issue in this >forum. I believe > >Chris should respond as he said he would, instead of just >forgetting about > >it after delivering himself of that tirade. Sorry, I've lost the context here. What is Chris's (Apple?) reply, and what issue are you talking about that it disrupted? > > > >[Albert] > >The actual wording of the LDUP requirements does now require >both atomicity > >... > > > > Uh, it must support the propagation of atomicity >information, > >that's different than requiring atomicity, imho. > > > >...and eventual convergence and is certainly a vast >improvement on previous > >drafts, although it proposes that sysadmins should > >"boil the ocean" by resolving resulting problems manually. > > > >I disagree. What it requires is that if conflict >resolution > >would result in loss of data, ensure that the sysadmin is >notified > >and can override if the algorithm is wrong. That is not >unreasonable > >given the issues raised in Appendix B. > > > >[Albert] > >Ok, "support the propagation of atomicity information" is >different from > >requiring atomicity. The difference is essentially that the >protocols are > >required to maintain all the information necessary to notify >admins about > >problems but are not required to fix the problem. That is >what I meant by > >"it proposes that sysadmins should 'boil the ocean' by >resolving resulting > >problems manually". But in this case, we're talking about losing data. There is no way for the protocol to fix the problem by itself without introducing semantics that will confuse users, as previously documented. I personally don't see any other option than requiring the sysadmin to fix the problem, and the wg has concurred. What concrete suggestion or improvement, other than replacing URP, do you have? >I'm going to make another slight distinction. The >requirements don't say "don't fix the problem", they say >"if fixing the problem involves loss of data, you'd better >tell somebody about because if the fix is wrong, losing >what was the correct data is a BAD Thing". I don't claim >to know what every directory administrator will want in >every case, so I think that some administrator notification >in cases where data would be lost (even including your >preference below of rollbacks/notifications) is a GOOD >Thing. > > >I still regard it as a vast improvement on the previous >because it clearly > >rules out the current architecture and URP, which is not >capable of > >maintaining > >the information needed to notify admins as required. > >Another IETF procedural point: I don't believe that >the requirements "rule out" the current architecture and >protocol. I believe the ADs/charis will agree that what >this does is put the onus on the architecture and protocol >drafts to explain WHY (in acceptable detail) they are ignoring >specific requirements. Of course, if the ADs/chairs >disagree, that would be good to know too :-) I agree with Ryan's characterization. > > > >I disagree with the analysis in appendix B, but it is >explicitly stated to be not part of the actual requirements. > >That's a fair opinion, although I believe that most >"if not all" of those examples are taken from real life >cases. > > >Once an architecture is adopted that *is* capable of meeting > >the requirements mandated for notification to sysadmins, I > >believe it will become obvious that it makes more sense to > >actually fix the problems by rollbacks and notifications > >to users. Since LDAP does not have rollback and notification semantics, how do you propose to do this? >That could be true, and we shall certainly see. > > >[Albert] > >Unfortunately neither the wording nor that implication > >appears to be based on the actual understanding of members > >of the WG, as reflected in the current drafts for > >implementation, the minutes of WG meetings at IETF and non- > >normative explanatory notes in the draft. > > > >Again I don't see the point of this comment. Not only do I also not see the point of this comment, I think the WG disagrees with you. You are postulating, without any evidence to the contrary, that the WG doesn't understand why it agreed to put the I-D into last call. That's absurd. > > > >[Albert] > >The minutes show that the same meeting which agreed the > >requirements draft was ready for final call also agreed > >that the URP was ready for final call despite the fact > >that it is incapable of meeting the requirements as stated. The working group has made a set of decisions, and I as one of the chairs respect those decisions and see a consensus. Therefore, please stop making blanket statements and instead provide facts. Please don't reissue your proposal, as it has already been rejected by the working group. Rather, please try and make constructive comments to the existing drafts. If you would like, I'd be happy to discuss this with you off-line. Otherwise, please detail exactly what is wrong and, more importantly, exactly how to fix it. Thanks. > >The "non-normative explanatory notes" I was referring to > >are mainly the Appendix B you mention. In addition the > >current drafts do not meet the requirement for eventual > >convergence (although they are capable of being > >fixed to do so, unlike their fundamental inability to > >propagate atomicity information needed for notification > >requirements). Again, this comment is not helpful. Please follow the guidelines in my previous comment. >Thanks, now I have a clearer picture. I don't remember >seeing a "last call" call for the URP draft yet (although >I'm not looking at the archives at this moment) and I >do believe that the point I raised above is a fair comment >for the URP draft to answer when it goes to last call The URP draft has NOT been issued as a last call yet. Sorry Ryan, but I'm not sure that I know which "point above" you are referring to. Could you please point this out? > >Although the plain words of the document unambiguously > >rule out URP, I am not under any illusion that this > >reflects a consensus of the WG to do so. > >I believe the reason for this is the procedural >distinction I made above. > > >Consequently I do not believe adoption of the requirements > >will in fact resolve the most important requirements issues > >and am therefore not part of any consensus to adopt them - > >although I will certainly elaborate on the > >requirements not met by URP when that comes up. Albert, if you're this convinced that URP does not meet the requirements document, please elaborate now, rather than later, in a separate thread (since this one is already so long). Thanks. From owner-ietf-ldup@mail.imc.org Mon Feb 19 17:02:28 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA15902 for ; Mon, 19 Feb 2001 17:02:27 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.9.3/8.9.3) id NAA17746 for ietf-ldup-bks; Mon, 19 Feb 2001 13:02:29 -0800 (PST) Received: from sj-msg-core-1.cisco.com (sj-msg-core-1.cisco.com [171.71.163.11]) by above.proper.com (8.9.3/8.9.3) with ESMTP id NAA17742 for ; Mon, 19 Feb 2001 13:02:27 -0800 (PST) Received: from mira-sjcm-1.cisco.com (mira-sjcm-1.cisco.com [171.69.43.102]) by sj-msg-core-1.cisco.com (8.9.3/8.9.1) with ESMTP id NAA23308; Mon, 19 Feb 2001 13:02:11 -0800 (PST) Received: from JSTRASSN-W2K1.cisco.com (sj-dial-4-75.cisco.com [171.68.181.204]) by mira-sjcm-1.cisco.com (Mirapoint) with ESMTP id AAC01764; Mon, 19 Feb 2001 13:01:30 -0800 (PST) Message-Id: <4.3.2.7.2.20010218195900.00b4e690@mira-sjcm-1.cisco.com> X-Sender: jstrassn@mira-sjcm-1.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Sun, 18 Feb 2001 21:46:44 -0800 To: "Paul Leach" From: John Strassner Subject: RE: WG Last Call on the LDAPv3 Directory Replication I-D Cc: "Ryan Moats" , "Mark Brown (REDMOND)" , "Richard V Huber" , , , , , , In-Reply-To: <5B90AD65A9E8934987DB0C8C076265744730FA@DF-BOWWOW.platinum. corp.microsoft.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ietf-ldup@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: I disagree on several counts. First, if we start singling out particular types of information that can or can not be replicated, where do we stop? Second, please stop using the term "passive data" as no one on this list has defined it in an unambiguous and satisfactory manner. It is impossible to consider using LDUP in this fashion until a definition for this term that we can all agree with is offered and agreed to. Third, what you're basically saying is that we should close up shop until LDAPext has finished a standards-track access control model RFC. I don't agree at all. First of all, RFC 2251, section 3.2, says that "Servers which perform caching or shadowing MUST ensure that they do not violate any access control constraints placed on the data by the originating server." Finally, we have a lot of work to do in this wg, and all of it hinges on this draft. We can't go forward with anything else until this draft goes forward. I don't think our ADs nor the wg as a whole wants to wait any longer. John At 11:18 PM 2/16/2001 -0800, Paul Leach wrote: >You're right -- it isn't the job of LDUP to say how to replicate ACLs. > >However, it is appropriate to point out that until such a standard >exists, LDAP conformant directories will not be able to be replicated >via LDUP. > >So, one of the requirements for replication between multiple standards >conformant LDAP servers using LDUP is that said servers not implement >anything other than standard LDAP acess to totally passive data. > > > -----Original Message----- > > From: Ryan Moats [mailto:rmoats@coreon.net] > > Sent: Friday, February 16, 2001 5:57 PM > > To: Mark Brown (REDMOND); Ryan Moats; Richard V Huber; > > ietf-ldup@imc.org; johns@cisco.com > > Cc: capple@ecal.com; paf@cisco.com; rweiser@digsigtrust.com; > > stokes@austin.ibm.com > > Subject: RE: WG Last Call on the LDAPv3 Directory Replication I-D > > > > > > John, Chris, do you have a sense of the working group from > > the list messages? I've not seen enough reaction to see > > whether we've got rough consensus one way or another, and > > I'm worried that this discussion threatens to become a > > rat-hole. > > > > See ... below... Ryan > > > > -----Original Message----- > > From: Mark Brown (REDMOND) [mailto:mabrown@Exchange.Microsoft.com] > > Subject: RE: WG Last Call on the LDAPv3 Directory Replication I-D > > > > > > ... > > ... A standard mechanism for directory replication in a > > multi-vendor environment is critical to the continued > > success of LDAP in the market place. This document sets > > out the requirements for replication between multiple > > standard-conformant LDAP servers. ... > > ^^^^^^^^^^^^^^^^^^^ <- new text > > ... > > > > An LDAP server that implements semantics not > > mentioned in the LDAP RFCs does not thereby > > become non-standard-conformant. > > > > Never said it didn't > > > > For instance, most LDAP servers today implement an > > access control scheme. No access control scheme > > is mentioned in the LDAP RFCs. Yet LDAP servers > > that implement access control are conformant with > > the LDAP standard. > > > > In the absence of an LDAP standard for access > > control, you can't have interoperability of access > > control in the IETF sense. However, I am not willing > > to delay this document for something that is the > > responsibility of another working group. The proper > > IETF procedure (as I understand it) is for this document > > to go forward and it become the responsibility of > > the access control draft authors to include the replication > > implications of the new standard. That avoids > > a "boil the ocean" conundrum preventing progress. > > > > Similarly, a server that implements internal > > triggers for the purpose of maintaining certain > > invariants in the directory can conform with > > the LDAP standard. > > > > Again, in the absence of an LDAP standard for internal > > triggers you can't have IETF interoperability to > > replicate that information with LDUP. If you want > > interoperability in replicating internal triggers, > > the proper process is to develop an RFC and address > > the issues there. > > > > LDUP is designed to solve the problem of replicating > > the representations of directories. But the > > correspondence between these representations and the > > LDAP protocol is not a simple one in general -- it is > > only simple for directories that are completely passive > > stores. When LDUP is used to replicate (the representations > > of) non-passive stores, it is up to the developers of those > > stores, not LDUP, to define how to achieve > > interoperability. (Most likely, they'll do this pairwise.) > > > > Readers of the requirements draft, even with your > > proposed amendment, are likely to think that LDUP > > is meant to provide interoperability between directories > > rather than between their representations. They are > > likely to blame LDAP directory implementors for not > > providing the same degree of interoperability as, say, > > DNS server implementors do. > > > > As Kurt says down at the start of this thread, that's not > > LDUP's job. It is worth adding a paragraph to the draft > > so that it says so clearly. > > > > I claim we've addressed the issue already in -06 > > and with the suggested text above. Therefore, at > > this point, I think I'd like to ask the chairs to get a > > sense of the mailing list to see if we have rough-consensus, > > because I can see argument turning into a rat-hole. > > > > --mark > > > > -----Original Message----- > > From: Ryan Moats [mailto:rmoats@coreon.net] > > Sent: Friday, February 16, 2001 12:40 PM > > To: Mark Brown (REDMOND); Richard V Huber; ietf-ldup@imc.org; > > johns@cisco.com > > Cc: capple@ecal.com; paf@cisco.com; rmoats@coreon.net; > > rweiser@digsigtrust.com; stokes@austin.ibm.com > > Subject: RE: WG Last Call on the LDAPv3 Directory Replication I-D > > > > > > See ... below... Ryan > > > > -----Original Message----- > > From: Mark Brown (REDMOND) [mailto:mabrown@Exchange.Microsoft.com] > > Sent: Tuesday, February 13, 2001 8:38 PM > > To: Richard V Huber; ietf-ldup@imc.org; johns@cisco.com > > Cc: capple@ecal.com; paf@cisco.com; rmoats@coreon.net; > > rweiser@digsigtrust.com; stokes@austin.ibm.com > > Subject: RE: WG Last Call on the LDAPv3 Directory Replication I-D > > > > > > So sorry -- I missed those changes when the -06 version came out. > > > > Shortening my suggested addition seems like a good idea. > > > > Good > > > > But the intent of my suggestion was to set a clear requirement for > > LDUP's ability to provide interoperability. That way, as other LDUP > > drafts progress, we'll be able to tell if they are meeting the goal > > set in the requirements. > > > > I personally am willing to do the following text adjustment, > > (the other authors still get to comment)... > > > > ... A standard mechanism for directory replication in a > > multi-vendor environment is critical to the continued > > success of LDAP in the market place. This document sets > > out the requirements for replication between multiple > > standard-conformant LDAP servers. ... > > ^^^^^^^^^^^^^^^^^^^ <- new text > > > > Beyond this, I disagree that LDUP requirements need to be stated > > to cover items that don't have an LDAP standard yet. Any new LDAP > > standard should cover the impact of replication on that standard, > > not the other way around. > > > > Since we are doing this work in the IETF, interoperability should be > > one of the primary concerns of the work. > > > > But the proposed text > > > > : Interoperability of replicas between directory servers may be > > limited > > : by servers that implement semantics that go beyond what the LDAP > > : access protocol defines. Examples (not an exhaustive > > list) of such > > : semantics include: (1) replication among directory servers with > > : different access control systems/semantics may compromise > > directory > > : security, and (2) replication among directory servers > > with different > > : application trigger semantics may compromise directory data > > : integrity. > > > > does not set a clear requirement for LDUP's ability to provide > > interoperability. It says that when we are done designing LDUP, it is > > OK that certain directory servers will not be able to replicate. It > > does not say that for the LDUP design to be considered a viable IETF > > standard, it is necessary that there is some pair of directory > > servers (not from the same code base) that LDUP enables to replicate. > > > > Of course, we don't want to state such a goal in terms like "LDUP will > > enable OpenLDAP and the Siemens DS to replicate," we want to state the > > goal in terms of the functional characteristics of a pair of systems > > that > > are able to replicate. That's what my suggested text tried to do. > > > > How about this: > > > > : The goal of LDUP is to support replication between directory servers > > : that each implements a passive store fully described by its LDAP > > interface. > > : "Passive store" means that the servers are limited to > > storing entries > > that > > : come in via LDAP and retrieving those identical entries later in > > response > > : to LDAP requests. The entire semantics of such a store is defined by > > its > > : LDAP interface. Any restrictions on what the server can > > store must be > > : expressed in the server's schema, and any restrictions on the access > > that > > : clients have to the store must be expressed in terms of a > > standardized > > : LDAP access control scheme. > > : > > : LDUP is not required to support replication between directory > > : servers that each implements an active store extending LDAP > > : semantics with non-standard access control rules or with triggers. > > : Examples of triggers include password length/complexity policies and > > : automatic storage of secure password hashes instead of passwords. > > > > --mark > > > > -----Original Message----- > > From: Richard V Huber [mailto:rvh@qsun.mt.att.com] > > Sent: Tuesday, February 06, 2001 12:52 PM > > To: ietf-ldup@imc.org; johns@cisco.com; Mark Brown (REDMOND) > > Cc: capple@ecal.com; paf@cisco.com; rmoats@coreon.com; > > rweiser@digsigtrust.com; stokes@austin.ibm.com > > Subject: RE: WG Last Call on the LDAPv3 Directory Replication I-D > > > > > > We addressed these issues in version -06, though we cut down the text. > > > > Here is the summary that was included when I sent version -06 to the > > list. I haven't seen any comments on it since it was posted. > > > > : Internet Drafts Editor - > > : > > : Please publish the draft below as draft-ietf-ldup-replica-req-06.txt > > : It replaces the -05 draft from November. > > : > > : LDUP Mailing list - > > : > > : The attached version of the draft incorporates changes to > > address the > > : comments from San Diego. We trimmed Mark's proposed > > changes since we > > : were concerned that they went into too much detail that > > wasn't really > > : LDUP related. > > : > > : Our specific changes are: > > : > > : Insert the following as the last paragraph in Section 3: > > : > > : Interoperability of replicas between directory servers may be > > limited > > : by servers that implement semantics that go beyond what the LDAP > > : access protocol defines. Examples (not an exhaustive > > list) of such > > : semantics include: (1) replication among directory servers with > > : different access control systems/semantics may compromise > > directory > > : security, and (2) replication among directory servers > > with different > > : application trigger semantics may compromise directory data > > : integrity. > > : > > : Add the following at the end of the Security Considerations Section: > > : > > : As noted in Section 3, security may be impacted when replicating > > : among servers that implement non-standard extensions to basic LDAP > > : semantics. Access control is one common case which affects > > security; > > : work to address this issue is documented in RFC 2820 [RFC2820]. > > : > > : Add the new reference to the References: > > : > > : [RFC2820] E. Stokes, D. Byrne, B. Blakley, P. Behera, "Access > > : Control Requirements for LDAP", RFC 2820, May 2000. > > : > > : Change the draft number and the publication and expiration dates. > > : > > : As always, please send comments to the list. > > > > Rick Huber > > > > --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- > > : Subject: RE: WG Last Call on the LDAPv3 Directory Replication I-D > > : Thread-Topic: WG Last Call on the LDAPv3 Directory Replication I-D > > : Thread-Index: AcCP5HY9fw2/PIuYQC+oULzgUxaapgAgz+xQ > > : From: "Mark Brown (REDMOND)" > > : To: "John Strassner" , > > : Cc: "Chris Apple" , > > : =?iso-8859-1?Q?Patrik_F=E4ltstr=F6m?= > > : Sender: owner-ietf-ldup@mail.imc.org > > : > > : The LDAPv3 Directory Replication Requirements I-D document does > > : not address the interoperability limits issue that we discussed > > : in December-January. > > : > > : I append the most recent message on the topic. > > : > > : --mark > > : > > : -----Original Message----- > > : From: Mark Brown (REDMOND) > > : Sent: Thursday, January 11, 2001 7:41 PM > > : To: Ellen Stokes; Kurt D. Zeilenga > > : Cc: ietf-ldup@imc.org > > : Subject: RE: interoperability limits: proposed addition to > > : draft-ietf-ldup-replica-req-05.txt > > : > > : Oops, I left off the examples. Let's try again: > > : > > : I suggest inserting the following material right after > > : the first paragraph of Section 3 ("The Models") of the > > : requirements draft (just before the sentence "There are five > > : data consistency models.") > > : > > : --mark > > : > > : * * * * * > > : > > : The objective is limited to replication between directory servers > > : that implement a passive store fully described by its LDAP > > : interface. "Passive store" means that the servers are limited to > > : storing entries that come in via LDAP and retrieving those entries > > : later in response to LDAP requests. The entire semantics of > > : the passive store is defined by its LDAP interface. Any > > : restrictions on what the server can store must be > > : expressed in the server's schema, and any restrictions on the > > : access that clients have to the store must be expressed in terms > > : of a standardized LDAP access control scheme. This is in > > : contrast to an "active store" that implements triggers > > : or other rules that extend the semantics of entries beyond > > : what's implied by LDAP. Replication between such active > > : stores should be specified in extensions to LDUP. > > : > > : Here are some examples of ways in which directory servers > > : implement semantics that go beyond what the LDAP access > > : protocol defines: > > : > > : * Access control. LDAP does not currently define an access > > : control scheme. (The ldapext WG is working to extend LDAP > > : with an access control scheme.) Most directory servers > > : implement an access control scheme. > > : > > : Replication between directory servers with different > > : access control schemes would compromise directory security, > > : so such replication is not supported by LDUP. > > : > > : * Password policy. Some directory servers restrict changes > > : to password attributes, requiring that the new password > > : value conform to a specific security policy (e.g. the value > > : is sufficiently long and complex.) Doing so reduces the > > : security risk associated with passwords that are easy to > > : attack. > > : > > : Replication between directory servers with different > > : password policies (e.g. one server implements a password > > : policy and a second server implements no policy) would > > : compromise directory security, so such replication is not > > : supported by LDUP. > > : > > : * Password hashing. Some directory servers don't store a user's > > : password directly, but instead store one or more secure > > : hashes of the password. Doing so makes it less likely that > > : anyone (even an administrator) can discover the password. > > : > > : Replication between a directory server that stores passwords > > : and a directory server that stores only hashes will compromise > > : directory integrity, causing authentications to fail > > : unexpectedly, so such replication is not supported by LDUP. > > : > > : * * * * * > > : > > : -----Original Message----- > > : From: Mark Brown (REDMOND) > > : Sent: Thursday, January 11, 2001 3:10 PM > > : To: Ellen Stokes; 'Kurt D. Zeilenga' > > : Cc: ietf-ldup@imc.org > > : Subject: RE: interoperability limits: proposed addition to > > : draft-ietf-ldup-replica-req-05.txt > > : > > : > > : We appear to be in total agreement. > > : > > : So I suggest inserting the following paragraph right after > > : the first paragraph of Section 3 ("The Models") of the > > : requirements draft (just before the sentence "There are five > > : data consistency models.") > > : > > : --mark > > : > > : * * * * * > > : > > : The objective is limited to replication between directory servers > > : that implement a passive store fully described by its LDAP > > : interface. "Passive store" means that the servers are limited to > > : storing entries that come in via LDAP and retrieving those entries > > : later in response to LDAP requests. The entire semantics of > > : the passive store is defined by its LDAP interface. Any > > : restrictions on what the server can store must be > > : expressed in the server's schema, and any restrictions on the > > : access that clients have to the store must be expressed in terms > > : of a standardized LDAP access control scheme. This is in > > : contrast to an "active store" that implements triggers > > : or other rules that extend the semantics of entries beyond > > : what's implied by LDAP. Replication between such active > > : stores should be specified in extensions to LDUP. > > : > > : * * * * * > > : > > : --mark > > : > > : -----Original Message----- > > : From: Kurt D. Zeilenga [mailto:Kurt@OpenLDAP.org] > > : Sent: Tuesday, January 09, 2001 4:54 PM > > : To: Mark Brown (REDMOND) > > : Cc: Ellen Stokes; ietf-ldup@imc.org > > : Subject: RE: interoperability limits: proposed addition to > > : draft-ietf-ldup-replica-req-05.txt > > : > > : > > : Mark, > > : > > : Replication in the face of triggers or any other LDAP extension > > : should be specified in extensions to the LDUP. > > : > > : LDUP should assume 'passive' servers as this, I believe, is the > > : LDAP/X.500 data model. That is, servers should not muck with > > : user data. > > : > > : Kurt > > > > From owner-ietf-ldup@mail.imc.org Mon Feb 19 17:47:47 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA17133 for ; Mon, 19 Feb 2001 17:47:45 -0500 (EST) Received: by above.proper.com (8.9.3/8.9.3) id OAA20107 for ietf-ldup-bks; Mon, 19 Feb 2001 14:17:37 -0800 (PST) Received: from relay1.pair.com (relay1.pair.com [209.68.1.20]) by above.proper.com (8.9.3/8.9.3) with SMTP id OAA20103 for ; Mon, 19 Feb 2001 14:17:35 -0800 (PST) Received: (qmail 1729 invoked from network); 19 Feb 2001 22:17:02 -0000 Received: from cpe-144-132-70-18.vic.bigpond.net.au (HELO w98) (144.132.70.18) by relay1.pair.com with SMTP; 19 Feb 2001 22:17:02 -0000 X-pair-Authenticated: 144.132.70.18 Reply-To: From: "Albert Langer" To: "'John Strassner'" , Cc: "'Mark Brown \(REDMOND\)'" , "'Richard V Huber'" , , , , , , Subject: RE: WG Last Call on the LDAPv3 Directory Replication I-D Date: Tue, 20 Feb 2001 09:20:17 +1100 Message-ID: <001701c09ac2$243a3020$6628a8c0@nowhere.com> 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 CWS, Build 9.0.2416 (9.0.2910.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 In-Reply-To: <4.3.2.7.2.20010219102747.00b48770@mira-sjcm-1.cisco.com> Importance: Normal Sender: owner-ietf-ldup@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit Albert, if you're this convinced that URP does not meet the requirements document, please elaborate now, rather than later, in a separate thread (since this one is already so long). Thanks. [Albert] An excellent request of exactly the sort that I indicated has been lacking from WG chairs in a message that crossed in in the ether with this one. So I will comply with it fully, despite the fact that you have still not withdrawn your remark about "unprofessional" comments. I will also take it as an excuse not to respond directly to the several specific points you directed towards me in your recent messages and concentrate instead on fulfilling the above, as a good way of starting afresh rather than getting entangled in the various bits and pieces. I have now said what I think needed to be said in response to other things and would greatly prefer to turn to positive technical dialogue as you propose, rather than continuing on those matters. Also I agree with your comment in your other recent message, concerning my statement: "I mention it as an "option" only because it is the current architecture, not because it has any technical merit whatever." Statements such as this are not helpful. Please try and comment in a positive manner. That was a product of my general irritation and I agree it is not helpful. I have been up all night and am now going to get some sleep before responding exactly as you have requested. From owner-ietf-ldup@mail.imc.org Mon Feb 19 18:04:09 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA17479 for ; Mon, 19 Feb 2001 18:04:08 -0500 (EST) Received: by above.proper.com (8.9.3/8.9.3) id OAA20559 for ietf-ldup-bks; Mon, 19 Feb 2001 14:37:37 -0800 (PST) Received: from pretender.boolean.net (root@router.boolean.net [198.144.206.49]) by above.proper.com (8.9.3/8.9.3) with ESMTP id OAA20555 for ; Mon, 19 Feb 2001 14:37:36 -0800 (PST) Received: from gypsy.OpenLDAP.org (gypsy.boolean.net [10.192.1.2]) by pretender.boolean.net (8.11.1/8.11.1/Boolean/Hub) with ESMTP id f1JMacD18223; Mon, 19 Feb 2001 22:36:38 GMT (envelope-from Kurt@OpenLDAP.org) Message-Id: <5.0.2.1.0.20010219130722.00a99b80@router.boolean.net> X-Sender: guru@router.boolean.net X-Mailer: QUALCOMM Windows Eudora Version 5.0.2 Date: Mon, 19 Feb 2001 14:36:37 -0800 To: John Strassner From: "Kurt D. Zeilenga" Subject: "equally capable" Requirments (Was: WG Last Call on the LDAPv3 Directory Replication I-D) Cc: ietf-ldup@imc.org In-Reply-To: <4.3.2.7.2.20010218201101.00b70ed8@mira-sjcm-1.cisco.com> References: <5.0.2.1.0.20010215221755.00aed450@router.boolean.net> <5B90AD65A9E8934987DB0C8C0762657493DDBF@DF-BOWWOW.platinum. corp.microsoft.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: John, The post you refer to was introductory. I did post some more specific comments, in particular regarding: "equally capable" and "access control" requirements up replicas (RFC 2251) Security Considerations and RFC 2820 I'll recap briefly here and repost as these comments might have been overlooked as they were buried in another thread. In the former, I think the requirement I-D needs to state that "application-level interoperability" is will not be guaranteed by the protocol, but may be resolvable by applicability statements (profiles). In the end, "application interoperability" requires that all replicas implement the same features in the same manner and this, IMO, is beyond the scope of LDUP. In the latter, I note that Security Considerations section is saying specific issues are being addressed in RFC 2820 (and the work in progress) when this is clearly not the case. Also, I note my opinion that LDUP specifications can be progressed without a Standard Track ACM. First, there are other ways to meet the "access control" requirements set forth in RFC 2251. Second, LDAP ACM does not guarantee that all implementations are "equally capable". I would be happy to elaborate on these issues as necessary. Kurt From owner-ietf-ldup@mail.imc.org Mon Feb 19 18:28:54 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA17888 for ; Mon, 19 Feb 2001 18:28:54 -0500 (EST) Received: by above.proper.com (8.9.3/8.9.3) id PAA21194 for ietf-ldup-bks; Mon, 19 Feb 2001 15:03:39 -0800 (PST) Received: from pretender.boolean.net (root@router.boolean.net [198.144.206.49]) by above.proper.com (8.9.3/8.9.3) with ESMTP id PAA21190 for ; Mon, 19 Feb 2001 15:03:38 -0800 (PST) Received: from gypsy.OpenLDAP.org (gypsy.boolean.net [10.192.1.2]) by pretender.boolean.net (8.11.1/8.11.1/Boolean/Hub) with ESMTP id f1JN2jD18282; Mon, 19 Feb 2001 23:02:45 GMT (envelope-from Kurt@OpenLDAP.org) Message-Id: <5.0.2.1.0.20010219143640.00ab8070@router.boolean.net> X-Sender: guru@router.boolean.net X-Mailer: QUALCOMM Windows Eudora Version 5.0.2 Date: Mon, 19 Feb 2001 15:02:44 -0800 To: John Strassner From: "Kurt D. Zeilenga" Subject: Re: several counts (Was: WG Last Call on the LDAPv3 Directory Replication I-D) Cc: In-Reply-To: <4.3.2.7.2.20010218195900.00b4e690@mira-sjcm-1.cisco.com> References: <5B90AD65A9E8934987DB0C8C076265744730FA@DF-BOWWOW.platinum. corp.microsoft.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:46 PM 2/18/01 -0800, John Strassner wrote: >I disagree on several counts. > >First, if we start singling out particular types of information that can or can not be replicated, where do we stop? Personally, I think LDUP MUST support userApplication attributes, SHOULD support subtypes, SHOULD support ;binary, MAY support language tags. I believe LDUP SHOULD support replication of directoryOperation attributes listed in RFC 2251, 3.2.1. Support for other directoryOperation and distributedOperation attributes SHOULD be handled by extension. There likely SHOULD be some requirements upon subschema entries (or subentries) as well (but this gets messy and may be better left as an extension). >Second, please stop using the term "passive data" as no one on this list has defined it in an unambiguous and satisfactory manner. It is impossible to consider using LDUP in this fashion until a definition for this term that we can all agree with is offered and agreed to. I agree. I believe we should use the term "userApplication" attribute. This is well defined. >Third, what you're basically saying is that we should close up shop until LDAPext has finished a standards-track access control model RFC. I don't agree at all. First of all, RFC 2251, section 3.2, says that "Servers which perform caching or shadowing MUST ensure that they do not violate any access control constraints placed on the data by the originating server." Though I believe LDUP documents MUST address this issue, I believe it fine for LDUP to say that it does not resolve this issue and that deployers of LDUP must ensure that replicas do not violate these constraints. There should not be any LDUP dependency upon LDAP ACM as LDAP ACM is: an elective extension, not the only ACM, doesn't itself ensure the constraints are met. >Finally, we have a lot of work to do in this wg, and all of it hinges on this draft. We can't go forward with anything else until this draft goes forward. I don't think our ADs nor the wg as a whole wants to wait any longer. I, too, would like to see the requirements I-D progressed soon. I note most of the issues are in "justification" portions of the I-D, not the actual requirements... I would hope we could reach consensus on the requirements soon. If not, we are doomed. From owner-ietf-ldup@mail.imc.org Mon Feb 19 19:51:37 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA19051 for ; Mon, 19 Feb 2001 19:51:37 -0500 (EST) Received: by above.proper.com (8.9.3/8.9.3) id QAA23628 for ietf-ldup-bks; Mon, 19 Feb 2001 16:26:51 -0800 (PST) Received: from pretender.boolean.net (root@router.boolean.net [198.144.206.49]) by above.proper.com (8.9.3/8.9.3) with ESMTP id QAA23624 for ; Mon, 19 Feb 2001 16:26:49 -0800 (PST) Received: from gypsy.OpenLDAP.org (gypsy.boolean.net [10.192.1.2]) by pretender.boolean.net (8.11.1/8.11.1/Boolean/Hub) with ESMTP id f1K0PqD18584; Tue, 20 Feb 2001 00:25:52 GMT (envelope-from Kurt@OpenLDAP.org) Message-Id: <5.0.2.1.0.20010219162328.00a8ddd0@router.boolean.net> X-Sender: guru@router.boolean.net X-Mailer: QUALCOMM Windows Eudora Version 5.0.2 Date: Mon, 19 Feb 2001 16:25:50 -0800 To: "Mangal Vithal Shriram" From: "Kurt D. Zeilenga" Subject: Re: Replication protocol element definitions 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 02:41 AM 2/19/01 -0700, Mangal Vithal Shriram wrote: >Hi, >I have been working on LDUP. I have studied a LDUP replication update protocol document. I have some questions on the definitions of StartReplicationResponse and EndReplicationResponse. These definitions should be written in terms of the ASN.1 provided in RFC 2251. Kurt From owner-ietf-ldup@mail.imc.org Mon Feb 19 21:26:05 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id VAA20172 for ; Mon, 19 Feb 2001 21:26:04 -0500 (EST) Received: by above.proper.com (8.9.3/8.9.3) id RAA25290 for ietf-ldup-bks; Mon, 19 Feb 2001 17:52:46 -0800 (PST) Received: from DF-INET-1.dogfoodinternet.com (df-inet1.exchange.microsoft.com [131.107.8.8]) by above.proper.com (8.9.3/8.9.3) with ESMTP id RAA25286 for ; Mon, 19 Feb 2001 17:52:44 -0800 (PST) Received: from df-virus2.platinum.corp.microsoft.com ([172.30.236.33]) by DF-INET-1.dogfoodinternet.com with Microsoft SMTPSVC(5.0.2195.2831); Mon, 19 Feb 2001 17:51:37 -0800 Received: from 172.30.236.11 by df-virus2.platinum.corp.microsoft.com (InterScan E-Mail VirusWall NT); Mon, 19 Feb 2001 17:50:44 -0800 (Pacific Standard Time) Received: from DF-BOWWOW.platinum.corp.microsoft.com ([172.30.236.101]) by yuri.dns.microsoft.com with Microsoft SMTPSVC(5.0.2195.2831); Mon, 19 Feb 2001 17:50:44 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.0.4648.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: WG Last Call on the LDAPv3 Directory Replication I-D Date: Mon, 19 Feb 2001 17:50:43 -0800 Message-ID: <5B90AD65A9E8934987DB0C8C0762657406005A02@DF-BOWWOW.platinum.corp.microsoft.com> Thread-Topic: WG Last Call on the LDAPv3 Directory Replication I-D Thread-Index: AcCat6DyOltWl+CsRrqPi+Nj3/G+XQAJ42HQ From: "Paul Leach" To: "John Strassner" , Cc: "Kurt D. Zeilenga" , X-OriginalArrivalTime: 20 Feb 2001 01:50:44.0506 (UTC) FILETIME=[89B467A0:01C09ADF] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id RAA25287 Sender: owner-ietf-ldup@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 8bit > -----Original Message----- > From: John Strassner [mailto:jstrassn@cisco.com] > Sent: Monday, February 19, 2001 10:27 AM > To: Albert.Langer@directory-designs.org > Cc: Kurt D. Zeilenga; ietf-ldup@imc.org > Subject: RE: WG Last Call on the LDAPv3 Directory Replication I-D > > > Not true. First, applications can certainly build locking and other > mechanisms to isolate operations affecting an update. Huh? The application instances could be operating on different replicas, so will never even see the "locking" operations of the other. They will proceed as if they were isolated, and then their updates will clash laters. When the attributes being modified overlap partially but not completely, neither one of them will get a consistent set. From owner-ietf-ldup@mail.imc.org Mon Feb 19 23:25:05 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id XAA23412 for ; Mon, 19 Feb 2001 23:25:04 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.9.3/8.9.3) id TAA27133 for ietf-ldup-bks; Mon, 19 Feb 2001 19:42:31 -0800 (PST) Received: from arnie.adacel.com.au (arnie.adacel.com.au [203.36.26.147]) by above.proper.com (8.9.3/8.9.3) with SMTP id TAA27127 for ; Mon, 19 Feb 2001 19:42:27 -0800 (PST) Received: (qmail 17551 invoked from network); 20 Feb 2001 03:45:53 -0000 Received: from unknown (HELO osmium) (203.8.85.176) by arnie.adacel.com.au with SMTP; 20 Feb 2001 03:45:53 -0000 Reply-To: From: "Steven Legg" To: Subject: Comments on draft-ietf-ldup-replica-req-06.txt Date: Tue, 20 Feb 2001 14:43:42 +1100 Message-ID: <000201c09aef$533e31a0$b05508cb@osmium.adacel.com.au> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_0003_01C09B4B.86B03040" 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 In-Reply-To: <5B90AD65A9E8934987DB0C8C0762657493DDBF@DF-BOWWOW.platinum.corp.microsoft.com> Importance: Normal X-MS-TNEF-Correlator: 00000000959925F7459DD311B46500E02915D5DB04AE2F00 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_0003_01C09B4B.86B03040 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Folks, Some comments on draft-ietf-ldup-replica-req-06.txt . > 2 Terminology > Replica - A collection of entries in the DIT, defined by a naming > context, and including all or some of the depending entries contained > therein, which divides directory data into a discrete partition whose > propagation behavior may be independently configured from other > partitions. Replicas may overlap or be nested. The use of "discrete" seems to be at odds with "overlap" and "nested". The term "replica" is inconsistently used. Sometimes it is used to mean a portion of the DIT, i.e. roughly synonymous with area of replication, while at other times it refers to one of the servers holding a copy of a particular area of replication. > Replica-Ring - The servers that hold a particular replica. A server > may be part of several replica-rings. Here "replica" means a particular area of replication whereas elsewhere the servers in the replica-ring are referred to as separate replicas. I suggest using area of replication to refer to the portion of the DIT and defining "replica" to mean one instance or copy of that area of replication held in a directory server. > Replication Initiation Conflict - In multi-master replication, a > Replication Initiation Conflict is a situation where two masters want > to update the same replica at the same time. It isn't just master replicas that can have such a conflict. Read-only replicas can be forwarding updates from a master upstream. A Replication Initiation Conflict is a situation where two replicas want to initiate replication sessions with a third replica at the same time. > 3 The Models > Consistency models 1, 2 and 3 involve the use of prearranged > replication agreements among servers. The added complexity of the > distributed 2-phase commit required for Model 1 is significant; > therefor, model 1 will not be considered at this time. Models 4 and 5 > involve unregistered replicas that "pull" updates from another > directory server without that server's knowledge. These models violate > a directory's security policies. It seems to me that any of the five models could violate, or preserve, a directory's security policies. It all depends on whether the consumer of the replicated data receives and honours the security information. > M3. A value shared between replicas in a replica ring must eventually > converge to the same value on all of its constituent replicas. A shared value is almost by definition the same everywhere, otherwise in what sense can it be said to be shared ? This requirement is really trying to say that an attribute in an entry must eventually converge to the same set of values in every replica holding that entry, and is just duplicating MM6 anyway. > P2. The supplier MUST track updates sent to the consumer and not > resend already acknowledged ones, even in the event of recovery from a > failed replica cycle. Not resending acknowledged updates to a consumer requires something like two-phase commit for the replication session between the supplier and consumer, which isn't part of the current protocol proposal, and doesn't need to be since URP absorbs any duplicates. Also, with the Update Vector, it is the consumer that keeps track of the updates that have been received rather than the supplier keeping track of the updates that have been sent. I imagine there are two things this requirement might really be trying to say: 1) The replication architecture SHOULD avoid sending to a consumer an update that the consumer has already seen. 2) An update received by a consumer more than once MUST NOT produce a different outcome than if the update were received exactly once. > P7. The protocol SHOULD NOT preclude support of Transactional > Consistency (model 1). I think this should be more general than just the protocol. The replication architecture SHOULD NOT preclude ... > AM6. Access control information (ACI) associated with sensitive data > MUST be deleted after or simultaneously with the deletion of the > sensitive data. Likewise, during Adds, ACI MUST be added first or > simultaneously with the addition of that data. This is a requirement on LDAP users rather than the replication architecture. The requirement for replication would be that where there are updates to sensitive data and the ACIs controlling access to those data, the updates SHOULD/MUST be applied at other replicas in the same order. > A.6. Consumer Initiated Replication > > Again a single mastered replication topology, but the replica initiates ^^^^^^^ slave > the replication exchange rather than the master. An example of this is > a replica that resides on a laptop computer that may run disconnected > for a period of time. > A.10. Enterprise Directory Replication Mesh > > A Corporation builds a mesh of directory servers within the enterprise > utilizing LDAP servers from various vendors. Five servers are holding > the same area of replication. The predetermined replication > agreement(s) for the enterprise mesh are under a single management, and > the security domain allows a single predetermined replication agreement > to manage the 5 servers replication. > > The requirements that follow from this scenario are: > . Predefined replication agreements that manage more than a single area > of replication that is held on numerous servers. The preceding paragraph suggests there is exactly one area of replication. > B.5.3. Locking Based on Atomicity of ModifyRequest > > There is an entry with distinguished name DN that contains attributes > X, Y, and Z. The value of X is 1. On replica A, a ModifyRequest is > processed which includes modifications to change that value of X from 1 > to 0 and to set the value of Y to "USER1". At the same time, replica B > process a ModifyRequest which includes modifications to change the ^^^^^^^ processes Regards, Steven ------=_NextPart_000_0003_01C09B4B.86B03040 Content-Type: application/ms-tnef; name="winmail.dat" Content-Disposition: attachment; filename="winmail.dat" Content-Transfer-Encoding: base64 eJ8+IiwDAQaQCAAEAAAAAAABAAEAAQeQBgAIAAAA5AQAAAAAAADoAAEIgAcAGAAAAElQTS5NaWNy b3NvZnQgTWFpbC5Ob3RlADEIAQ2ABAACAAAAAgACAAEGgAMADgAAANEHAgAUAA4AKwAAAAIAKQEB A5AGAGwRAAAqAAAACwACAAEAAAALACMAAAAAAAMAJgAAAAAACwApAAAAAAALACsAAAAAAAMALgAA AAAAAwA2AAAAAAAeAHAAAQAAADAAAABDb21tZW50cyBvbiBkcmFmdC1pZXRmLWxkdXAtcmVwbGlj YS1yZXEtMDYudHh0IAACAXEAAQAAABYAAAABwJrvTwI38kChBrUR1aB9AIDITmn1AAACAR0MAQAA AB8AAABTTVRQOlNURVZFTi5MRUdHQEFEQUNFTC5DT00uQVUAAAsAAQ4AAAAAQAAGDgA6XzjvmsAB AgEKDgEAAAAYAAAAAAAAAJWZJfdFndMRtGUA4CkV1dvCgAAAAwAUDgEAAAALAB8OAQAAAAMABhAW vc1FAwAHEH0SAAAeAAgQAQAAAGUAAABGT0xLUyxTT01FQ09NTUVOVFNPTkRSQUZULUlFVEYtTERV UC1SRVBMSUNBLVJFUS0wNlRYVDJURVJNSU5PTE9HWVJFUExJQ0EtQUNPTExFQ1RJT05PRkVOVFJJ RVNJTlRIRURJAAAAAAIBCRABAAAAnAwAAJgMAAAlGwAATFpGdeEquv8DAAoAcmNwZzEyNeIyA0N0 ZXgFQQEDAff/CoACpAPkBxMCgA/zAFAEVj8IVQeyESUOUQMBAgBjaOEKwHNldDIGAAbDESX2MwRG E7cwEiwRMwjvCfe2OxgfDjA1ESIMYGMAULMLCQFkMzYWUAunYwEwiwrjCoBGBvBrcywdNKUdNFMD cGUgBaBtB4CHAjAEIAIgIGRyYQGABi0IkAAwLWxkdXAuLRggC1AN4GEgsXEt2DA2LgzQBUAuHfod NKQ+IBRAIFQEkG0LgCkXoWd5ImxSINQgLZMQwB7xbGwFkHRpH5F4b2YgH0EIgQQgC4AghHRoHuBE SVQsH7CHARALgAmAIGJ5ICVg9G5hI6FnIsYFoAIwDsGvJ8AAcChAC4BjCkBkKOHvKIAl4B+ABcBz HsImcSdS/QEAcAnwKrMmpimSC3EJgJ8ixidRGCALgCfAd2gN4OJoH7BpdmkBAAQgKrDPGCAmEAWw KHBkYQGQJxH/MCAogSqwBPEUIB7gCrEmINsmIy7wbxQQIsZwA2AKsOZnMIAmMmJlE+AvcAWxvwDA KHAz8CcRLDQfQWwocPspkSgAZwhwKDEDUh+ALmLzMrcx1nMuI1AlBQQgNILsb3YEkAtgcCsyNMEo IKpzDrBkIftUJ2F1FBC1JmIiMTYiK2AJ4G0EIM8w4TTBMIAfgGRkBCAD8F8nUDvwOUU8kCoiIjok Iv86jw6wI5A78CDFPJAEACpS/zgRBAAOsDWDO5E6cAYAHsH/JiAHgjIAQZJCwj0CB4AAcDsdNCVg cBfBJjUnV2kuRmU4QANgdWdoNaFz+nkjwG4GwAhgPdUKwESw/yZiIMUmIh3lLvEl8D1jLmL3J0BD dhggZgSQPPMCICun/RQQcjlRBCAycCBwKsMe8TZwOSEmgGEdNDHDY3U/C2AFwEh/AiAh+yTnLVL/ KsIlgDtSTOYnUD1xTWIogf9O+SDFOEEloEzkIsY0hTHC/yZiFBA5UQdASOYgsCjhODD9HfpILoFA +USiBCBUG0+v5zIzLoE40WVsFBBc8x00/0yqJyVX+luiS4Q2QjDiBCDfFBAKsTCAX3dYvEkrYEcQ /mc6MTuBYCVb7zDhS5M9AvsnUkVvVETlKjEn4yrCQQjfRHVMIwuAOkAAcGMroQXA/04GU3NkdR00 XDonYFPhJyG/MRIv9kzkIf8kySYjSQMA/yYgM5QIUDXwIPEFQCWAcTD3NHBbYCYgLQDAOkFUx0lj P052cF9xb0GhJWAAkHR1e1yZJ0B3RIFzMz3RAHB0/y3nMPAgkDBxQJFMsijAX3efPWJ6Z0NiYqxD 0m4nBUD+ajuQBUBzLFNVIRBtYTQgf0zBGtBIUTXDciI4QCUAYfxkLQIgNaBsay0xA5E0wf0CEHJ5 AAsgKsJ59AQgNoPfJWBzJSCQOkBkgW04QCWg/3T5YxV1z3bfd+h+l3kCPQL/aKGHEjKlXDoUEAQQ OAJIFb8nQS/gKEB6/3wPIpkzI1F9J2FNBHFdgCJsceFCJGPnKHAEYl2AIDEnwBRAKiL7kJALgHYG 8H/RJ1I7lTMw/0SwYOAAcGPALddcOjNwCdH/HzQowAIgKuBM5ThBO1KBMP8BAChAHwELUA7AMgBr VTKnMzExJsFidTpRIzAtcM8T4DuhHwJLY3F1L+E2Yd8FspESk2BBkgCQZwMAKAD9f3F0GTAt+oMB J8CTA53x/wPwKxEjwAVANMFB8wSBKDGfjkNBoY8DI1CRBCA0KhOmNSLGlCZ1bhggZ0Iy0zZCfpwi cFtgbDyQg7z/oQE2+W4uPeMIYI5SPXFM5KonBCBrI8B3JfBkY8D/mMQ7oZMFNDELYIsmIyBuCf+r ERQQW1AFEJoRZrAg8Sbh/3x+PLeO0muzR7ArtigAf9H/kwUFoFtgKECs1SfABbGVUf9M4x3lrc+u 3XWga9ErESw03x9zXPFKtCdhQfJ1B4A3Ff8rxUj2KDEwcy/xLqA5UFrB/yoxMnAjwAhwU1JMwq7F C4BPgwEAwFCfIsZNM1VTdr8HQApQK2AT4SgyFCB3CeH/foht043GYBNywGPhV4ECMP+IoCXgJBUp czlRY8BmNnqj/8AUlxIrEiaAMgAtMzpAiIF/H0FiHx1DVYHAhMAUiCJsfwRgY+EoYWh0ZWR6dleC ef9c87QBLmID8TTSSbaqgwCA/x7hA5FDwTTBeqAvgD0FwHX+P1KhQaGc1R8yQZJkgcPR/ydAMEAo 5zDheqDSIbGEPWH/m1VtwwOgJqKS4cMsxH96ov8dNBQRJmLAEycDzCONt01m/1Nz1PMqBQQgfdMg gUkkKPbYTU02sbJ5AHm+XyMCbFAymMVjkHAg4RKBTdhVU1TSMQDQa4OnzlF/inO4+ioToQGWCM5R U/Fs/WSBZChx4ICrVihATDEd0P/DUycWw2NItAWg2ROENCLGfmYLcKuBjbeS0CqAfGxO/6ER43Qq w+R6g7Yw4+H3nNXfYXFDMi8AKtEg8Gtd9nhQ/5v8nWK6SowpwNdMo9+GKiH/HTS5Ni7WfXRW9rjz CHAYIP+KYTMxMCAXkTMjMoAHQCoE/GRvB5B9kR00KCBERM8ioyphHuBVUlAogGIrcF5y+jCxs9vm txJBXYBv1y7RPgInUlV6BFYwAx3l/0PE4btTc+7AINA88eBjK8X/7BdTg3/CM/DBM7ujLdVh0f+4 tNPB8pv/Utoj/88A3+Ej/2KtQ3AzcCgRLlRgU3hC7kP/U1LQvSOgRyBLctHzPUHSRJc9AdeVNJA6 HfoxKVKjfZaLchPQMgAmATYxQxBI8E9VTEQogJRAz3Hqxv/snETGefeOReH375Hj1zyx9VDMMg4w QW3gefUB9ihUf+H3mAB4EgNS1mBqweADTn5P4DAzMSCAasFOhSqwZv9mAeZzm5AfARilnpAFaS7g /1miFwcp0OBwNZIZEt2f3qP+N5jF9pcQJRm05vAqkd9U+2bBJmJUlaF6oCYTt4CRz/WS0SigNSli re5C4JCiU//AcLNDPUEYc2PALbBXsgNDf33TZnP2pR7VDl8PbyGdLrctwB7vkGFB3QBVUmNqwD/x sNZC1RD28b2pJTBBQ/5JDjA40O4Ar3C64z3zzlL/N+F/0bsyvyfgEj1BncE8YX1T8WZzUp1xoaBy wopQZf9H4dYh/Ac0g0WokBYyrJjBvkzusc0y5XD64GATQT2x/+VwMVEz95k0nqBL0D2BVff/NZ/8 JZkxyzRrdjkjLfrQk++II9DqcbEQYEH6AJThS9H/At4q/w+lKkvRCJ1iXDsnlv9Tc3flCOeDtdKo MrvbE2di/zFRL+dfwOsTL7NmQ8pwMyTv5XAFeQ3EECQvO0ffk6IDf8zjwVt6Z51wocEt7y7zLv8v UZJC4jOG5Zlhhd900C63/mfPYG3iZCLpcHh1pZhlZfmvMW9n2vGbgV9KireRVd+/0FzPXd9e718h XmA07fD/s8CYgJ8ZRyuZ4CvQlbJC//9+JIWRYmKX8JnBsfRA461If43G/wO0YaGxuCOOILPAcP9a IZmDm5H+5X4g2UGk8JsS/9ZR+NByQJXonWKOILfgvVDPnbCx848fVEcxML/BXyLeRdXQQsD3IM1C RKjndPr6TbvgaFbvh4FusJ1w8TT/m4DocLgRhIFwkcaSqN6M1J/l5m6HkBabkOhwaXruYv9CU3RW hDPAEGuxlODJoBEB+51wmLFGsoJ0Vgky2eVhCv+Os9AhjiDms4X3v8AgdJXgPzSxMMAIkVlLrUeX Vihz/w4w8FZ1iHMkSZPbMBIiWFj/I9DE4Eai2wN6+7Y2+ABkEP/B8reQq2CINFiDfZ+Wv+Ln97ES gzP8QzV0R3yKcM5F/f8GFZ1gheLnZCckHrAj0Gux7wkiDVVxIL/AUIbiywGHj/+XZ2klidMYeFhH fAJxRr/Qv3xc/vTbYfxgJ7FCIW5VQv94onRVP/2Gsx6w2hP1UZIR81CwMoF1Z8TgJND+EyxRH9th Hhh7774fcUZCLjWqLr+xTPbQa+5iQu+h/ZczQakg8BCvcL1xxqGjEf0cUHlvwEZQmxGLz5t21Mf/ MlNp8dxSRmDQALsBI9DL8fxETv70MAJYAUEh1AZl1+pY5XBZ2wRaIEXF1SMQ6lhBAjG/wU/BR7/g 2wH/oXxlufchL7IyIvSkGSAtcv9BILLBHFBHdbDzYqX/A6lJ9edzMYkJMEu0SrITdKlHClnPkiLg EEVSMSK/v8ITdMWDbDLlcOjGQqxt/6s/rY+un6+lN/VgGKzmSjX/vHpvwFfwUyDlYE9l/NDDcQUN xH2/QAMAEBAAAAAAAwAREAAAAAAeAEIQAQAAAE8AAAA8NUI5MEFENjVBOUU4OTM0OTg3REIwQzhD MDc2MjY1NzQ5M0REQkZAREYtQk9XV09XLnBsYXRpbnVtLmNvcnAubWljcm9zb2Z0LmNvbT4AAAsA AIAIIAYAAAAAAMAAAAAAAABGAAAAAAOFAAAAAAAAAwACgAggBgAAAAAAwAAAAAAAAEYAAAAAEIUA AAAAAAADAAiACCAGAAAAAADAAAAAAAAARgAAAABShQAAPBgAAB4ACYAIIAYAAAAAAMAAAAAAAABG AAAAAFSFAAABAAAABAAAADguNQALAAqACCAGAAAAAADAAAAAAAAARgAAAAAGhQAAAAAAAAMAC4AI IAYAAAAAAMAAAAAAAABGAAAAAAGFAAAAAAAACwAUgAggBgAAAAAAwAAAAAAAAEYAAAAADoUAAAAA AAADABWACCAGAAAAAADAAAAAAAAARgAAAAARhQAAAAAAAAMAF4AIIAYAAAAAAMAAAAAAAABGAAAA ABiFAAAAAAAAHgAmgAggBgAAAAAAwAAAAAAAAEYAAAAANoUAAAEAAAABAAAAAAAAAB4AJ4AIIAYA AAAAAMAAAAAAAABGAAAAADeFAAABAAAAAQAAAAAAAAAeACiACCAGAAAAAADAAAAAAAAARgAAAAA4 hQAAAQAAAAEAAAAAAAAACwAzgAsgBgAAAAAAwAAAAAAAAEYAAAAAAIgAAAAAAAALADWACyAGAAAA AADAAAAAAAAARgAAAAAFiAAAAAAAAAIB+A8BAAAAEAAAAJWZJfdFndMRtGUA4CkV1dsCAfoPAQAA ABAAAACVmSX3RZ3TEbRlAOApFdXbAgH7DwEAAABPAAAAAAAAADihuxAF5RAaobsIACsqVsIAAG1z cHN0LmRsbAAAAAAATklUQfm/uAEAqgA32W4AAABVOlxzbGVnZ1xtYWlsXG1haWxib3gucHN0AAAD AP4PBQAAAAMADTT9NwAAAgF/AAEAAAAxAAAAMDAwMDAwMDA5NTk5MjVGNzQ1OUREMzExQjQ2NTAw RTAyOTE1RDVEQjA0QUUyRjAwAAAAAJox ------=_NextPart_000_0003_01C09B4B.86B03040-- From owner-ietf-ldup@mail.imc.org Mon Feb 19 23:34:54 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id XAA23821 for ; Mon, 19 Feb 2001 23:34:53 -0500 (EST) Received: by above.proper.com (8.9.3/8.9.3) id UAA27620 for ietf-ldup-bks; Mon, 19 Feb 2001 20:08:11 -0800 (PST) Received: from pretender.boolean.net (root@router.boolean.net [198.144.206.49]) by above.proper.com (8.9.3/8.9.3) with ESMTP id UAA27616 for ; Mon, 19 Feb 2001 20:08:10 -0800 (PST) Received: from gypsy.OpenLDAP.org (gypsy.boolean.net [10.192.1.2]) by pretender.boolean.net (8.11.1/8.11.1/Boolean/Hub) with ESMTP id f1K47KD19560; Tue, 20 Feb 2001 04:07:20 GMT (envelope-from Kurt@OpenLDAP.org) Message-Id: <5.0.2.1.0.20010219200326.00aac720@router.boolean.net> X-Sender: guru@router.boolean.net X-Mailer: QUALCOMM Windows Eudora Version 5.0.2 Date: Mon, 19 Feb 2001 20:07:19 -0800 To: "Paul Leach" From: "Kurt D. Zeilenga" Subject: RE: WG Last Call on the LDAPv3 Directory Replication I-D Cc: In-Reply-To: <5B90AD65A9E8934987DB0C8C0762657406005A02@DF-BOWWOW.platinu m.corp.microsoft.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 05:50 PM 2/19/01 -0800, Paul Leach wrote: >> From: John Strassner [mailto:jstrassn@cisco.com] >> Subject: RE: WG Last Call on the LDAPv3 Directory Replication I-D >> >> >> Not true. First, applications can certainly build locking and other >> mechanisms to isolate operations affecting an update. > >Huh? The application instances could be operating on different replicas, >so will never even see the "locking" operations of the other. They will >proceed as if they were isolated, and then their updates will clash >laters. When the attributes being modified overlap partially but not >completely, neither one of them will get a consistent set. Unless the directory was using single master replication or multiple master with "transactional consistency" (model 1). Kurt From owner-ietf-ldup@mail.imc.org Tue Feb 20 05:29:11 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id FAA09677 for ; Tue, 20 Feb 2001 05:29:10 -0500 (EST) Received: by above.proper.com (8.9.3/8.9.3) id BAA07260 for ietf-ldup-bks; Tue, 20 Feb 2001 01:56:19 -0800 (PST) Received: from DF-INET-1.dogfoodinternet.com (df-inet1.exchange.microsoft.com [131.107.8.8]) by above.proper.com (8.9.3/8.9.3) with ESMTP id BAA07256 for ; Tue, 20 Feb 2001 01:56:18 -0800 (PST) Received: from df-virus2.platinum.corp.microsoft.com ([172.30.236.33]) by DF-INET-1.dogfoodinternet.com with Microsoft SMTPSVC(5.0.2195.2831); Tue, 20 Feb 2001 01:54:00 -0800 Received: from 172.30.236.11 by df-virus2.platinum.corp.microsoft.com (InterScan E-Mail VirusWall NT); Tue, 20 Feb 2001 01:53:07 -0800 (Pacific Standard Time) Received: from DF-MAX.platinum.corp.microsoft.com ([172.30.236.101]) by yuri.dns.microsoft.com with Microsoft SMTPSVC(5.0.2195.2831); Tue, 20 Feb 2001 01:53:07 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.0.4648.0 Content-Class: urn:content-classes:message Subject: RE: WG Last Call on the LDAPv3 Directory Replication I-D MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Tue, 20 Feb 2001 01:53:06 -0800 Message-ID: <5B90AD65A9E8934987DB0C8C07626574473101@DF-BOWWOW.platinum.corp.microsoft.com> Thread-Topic: WG Last Call on the LDAPv3 Directory Replication I-D thread-index: AcCa8wzg0dntpPX+QueC9tVv33scIQALtOkg From: "Paul Leach" To: "Kurt D. Zeilenga" Cc: X-OriginalArrivalTime: 20 Feb 2001 09:53:07.0558 (UTC) FILETIME=[ED1BA860:01C09B22] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id BAA07257 Sender: owner-ietf-ldup@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 8bit > -----Original Message----- > From: Kurt D. Zeilenga [mailto:Kurt@OpenLDAP.org] > Sent: Monday, February 19, 2001 8:07 PM > To: Paul Leach > Cc: ietf-ldup@imc.org > Subject: RE: WG Last Call on the LDAPv3 Directory Replication I-D > [Summary: I asked: How can you do locking in replicated environment? They won't see the locking operations... ] > > Unless the directory was using single master replication or > multiple master with "transactional consistency" (model 1). I agree that it would work with single master -- I thought the context of the thread was multimaster. I don't see how even transactional consistency would make locking operations work with multi-master. Nor do I have any idea how to make transactional consistency work with multimaster in the face of partially overlapping write sets, for that matter. (Unless you're prepared to undo transactions that the clients were told had committed, which I think is a horrible idea -- programmers will never get it.) Paul From owner-ietf-ldup@mail.imc.org Tue Feb 20 05:51:36 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id FAA09878 for ; Tue, 20 Feb 2001 05:51:35 -0500 (EST) Received: by above.proper.com (8.9.3/8.9.3) id CAA07864 for ietf-ldup-bks; Tue, 20 Feb 2001 02:20:22 -0800 (PST) Received: from DF-INET-1.dogfoodinternet.com (df-inet1.exchange.microsoft.com [131.107.8.8]) by above.proper.com (8.9.3/8.9.3) with ESMTP id CAA07860 for ; Tue, 20 Feb 2001 02:20:21 -0800 (PST) Received: from df-virus2.platinum.corp.microsoft.com ([172.30.236.33]) by DF-INET-1.dogfoodinternet.com with Microsoft SMTPSVC(5.0.2195.2831); Tue, 20 Feb 2001 02:20:40 -0800 Received: from 172.30.236.11 by df-virus2.platinum.corp.microsoft.com (InterScan E-Mail VirusWall NT); Tue, 20 Feb 2001 02:19:47 -0800 (Pacific Standard Time) Received: from DF-MAX.platinum.corp.microsoft.com ([172.30.236.101]) by yuri.dns.microsoft.com with Microsoft SMTPSVC(5.0.2195.2831); Tue, 20 Feb 2001 02:19:47 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.0.4648.0 Content-Class: urn:content-classes:message Subject: RE: several counts (Was: WG Last Call on the LDAPv3 Directory Replication I-D) MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Date: Tue, 20 Feb 2001 02:19:45 -0800 Message-ID: <5B90AD65A9E8934987DB0C8C07626574473102@DF-BOWWOW.platinum.corp.microsoft.com> Thread-Topic: several counts (Was: WG Last Call on the LDAPv3 Directory Replication I-D) thread-index: AcCayPMfxjkJNP2KSoereQ4AmmFhYgAXDxlw From: "Paul Leach" To: "Kurt D. Zeilenga" , "John Strassner" Cc: X-OriginalArrivalTime: 20 Feb 2001 10:19:47.0199 (UTC) FILETIME=[A69180F0:01C09B26] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id CAA07861 Sender: owner-ietf-ldup@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 8bit > -----Original Message----- > From: Kurt D. Zeilenga [mailto:Kurt@OpenLDAP.org] > Sent: Monday, February 19, 2001 3:03 PM > To: John Strassner > Cc: ietf-ldup@imc.org > Subject: Re: several counts (Was: WG Last Call on the LDAPv3 Directory > Replication I-D) > > >Second, please stop using the term "passive data" as no one > on this list has defined it in an unambiguous and > satisfactory manner. It is impossible to consider using LDUP > in this fashion until a definition for this term that we can > all agree with is offered and agreed to. > > I agree. I believe we should use the term "userApplication" > attribute. > This is well defined. Well, I used "passive data" recently, and I don't know if "userApplication" is at all related. What I mean by "passive data" is this: An attribute may be said to be "passive data" when a write to the attribute followed by a read of the same attribute returns exactly the data written, and no other attribute's value is affected. An attribute that is not "passive data" is "active data". A directory may be LDAP compliant and still contain active data. Two different directory implementations may therefore be LDAP compliant yet implement different forms of active data (different attributes may be active, for example). However, issues have been raised about the ability to replicate active data, between directories that implement their active data differently, and hence on the viability of the requirement that LDUP be able to replicate any LDAP compliant directory. From owner-ietf-ldup@mail.imc.org Tue Feb 20 11:25:14 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA15288 for ; Tue, 20 Feb 2001 11:25:14 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.9.3/8.9.3) id HAA18659 for ietf-ldup-bks; Tue, 20 Feb 2001 07:30:41 -0800 (PST) Received: from sj-msg-core-4.cisco.com (sj-msg-core-4.cisco.com [171.71.163.10]) by above.proper.com (8.9.3/8.9.3) with ESMTP id HAA18652 for ; Tue, 20 Feb 2001 07:30:40 -0800 (PST) Received: from mira-sjcm-1.cisco.com (mira-sjcm-1.cisco.com [171.69.43.102]) by sj-msg-core-4.cisco.com (8.9.3/8.9.1) with ESMTP id HAA19612; Tue, 20 Feb 2001 07:30:13 -0800 (PST) Received: from JSTRASSN-W2K1.cisco.com ([171.69.108.130]) by mira-sjcm-1.cisco.com (Mirapoint) with ESMTP id AAC08626; Tue, 20 Feb 2001 07:29:15 -0800 (PST) Message-Id: <4.3.2.7.2.20010219181608.03d79008@mira-sjcm-1.cisco.com> X-Sender: jstrassn@mira-sjcm-1.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Mon, 19 Feb 2001 18:37:21 -0800 To: From: John Strassner Subject: RE: WG Last Call on the LDAPv3 Directory Replication I-D Cc: "'Kurt D. Zeilenga'" , In-Reply-To: <002b01c0993d$a2b80e80$6628a8c0@nowhere.com> References: <5.0.2.1.0.20010217130809.00a693a0@router.boolean.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ietf-ldup@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Please see comments inline, delineated by .. regards, John At 10:59 AM 2/18/2001 +1100, Albert Langer wrote: >[Kurt] >At 07:30 AM 2/18/01 +1100, Albert Langer wrote: > >If by "transactional" consistency you are referring to updates affecting > >more than one directory entry, that is not part of LDAP semantics. > >I am using the term "transactional consistency", I hope, as >defined by LDUP requirements I-D. X.500 and LDAP state that >all modifications requested as part of a single modify happen >as a single atomic action. Using this feature, applications can >(and do) build mutually exclusive locks, semaphores, monotonically >increasing counters, and other structures used for application >synchronization purposes. This feature is preserved by X.500 >data model as it supports only single master replication. > >It is not possible to build these structures in multiple >master environments without "transactional consistency". > >[Albert] >Since X.500 and LDAP refer to a "single atomic action" I prefer to use the >term >"atomic" for this issue because reference to "transactions" is easily >confused with >updates affecting multiple entries rather than just modifications to >multiple >attributes of a single entry, which is the only guarantee provided by X.500 >and >LDAP and is deliberately much weaker than a DBMS style requirement to >maintain >consistency for updates to different entries. Being an ex-database person, I tend to agree with Albert here. >Leaving aside terminology, we seem to be broadly in agreement. > >However the way you have put it sounds like you are opposed to LDUP >developing >multi-master standards at all, since it is technically impossible to >maintain >such things as monotonically increasing counters for application >synchronization. Please clarify if you mean that it is technically impossible to build and maintain monotonically increasing counters and the like within the directory server itself. You've got an argument on your hands if you think that it can't be done externally, by the way. >Is that the case? > >If so, could you please elaborate on applications that depend on such >features. > >My view is that the critically important requirement that applications >depend on >is simply that a change can be reliably made to exactly the entry you >thought you >were changing and not result in some mixture of updates combined with >unknown >concurrent changes by some other application. Albert, you presented your way, and it was the consensus of the working group that the behavior you proposed was NOT what the user would have expected. That is why the working group has adopted the approach it has. With the chair hat on, I would therefore ask you to stop bringing this up. If you have an explicit suggestion that would make our current approach better in some way, please say it. But simply stating that it won't work, or talking about your alternative, are not helping the working group make progress. Please stop. >That is essential for basic data integrity and easily achieved by the >provisions >regarding modify operations in the LDAP standards. The whole point of those >provisions is that by explicitly asserting that all relevant attributes have >particular values at the start of a modify and particular values at the end, >you are guaranteed that the operation will fail if that turns out not to be >the case due to some other change between when you read an entry and when >you modified it, rather than ending up with randomly garbled entries. same comment as above, this doesn't help >Although it is possible to use that mechanism for such things as >(cooperative) >locking, semaphores and counters, that is not it's intended use and I agree >with >the requirements draft characterization of applications doing that as making >inappropriate use of the directory. > >What I disagree with in Appendix B is the confusion of such inappropriate >use with the perfectly >normal use of the carefully designed characteristics of "modify" atomicity >to >ensure data integrity. Sorry, but I don't understand your point. Could you please restate it? >That normal use can be achieved with multi-master (at >the cost of >notifications about operations failing after intially appearing to have >succeeded). So, how do you propose to handle this? There is no standard notification mechanism, though there are a lot of conflicting vendor-specific mechanisms that **might** be able to be used for this purpose. Remember, please answer assuming the current approach of the WG, or please don't answer. >The >statement that rolling back a change to one attribute of a single entry >would cause "more >surprise" than letting two separate users/applications mixup changes to the >same data >without knowing what the results of their combined activity would be, shows >a quite >breathtaking incomprehension of very basic data integrity issues. First, that's insulting. You'll probably convince people in the working group to listen to you if you don't call them stupid. Second, your refusal to acknowledge that your approach was rejected is not productive. Especially when you make outrageous statements like the above with no backup whatsoever. Note that the working group discussed your contrary proposal, and rejected it. It discussed the current proposal and accepted it. >It seems to me that multi-master does have important operational benefits >that would >justify deployment so long as basic data integrity is not compromised. > >Are you saying it should not be deployed at all? > > >An applicability statement should clearly indicate > >that multi-master is unsuitable in any situation with a high rate of > >concurrent changes to the same entries. > >[Kurt] >Change "high" to "any" and I would concur. Kurt, I don't follow you here. Any could be interpreted as once per day or week. I don't think that that's what you meant. Could you please elaborate on what you meant by "any"? >[Albert] >That does seem to be saying multi-master should not be deployed at all, >since by definition >of multi-master, DSAs do not contact each other before performing updates >and therefore >the *possibility* of concurrent changes *cannot* be excluded. > >That breaks any application relying on semaphores etc. But rollbacks are >quite sufficient for applications that merely require data integrity (such >as access control). > >Surely a directory service that guarantees that only changes actually made >by DUAs will ever be visible could be useful even though occasional >notifications about changes that have been revoked would be necessary? After >all, even in a single master situation a change made can be subsequently >unmade by another DUA and there is no mechanism for *enforcing* cooperative >use of semaphores, counters etc, so no properly designed application could >depend on no other >DUA interfering. > >If you have specific applications in mind that do depend on single master >semantics, please list them. > >Discussion of such issues is what requirements analysis should be about. > >For my part, I think it is sufficient to just list access control as an >example of a directory application that requires a level of data integrity >that simply cannot be met without atomicity. From owner-ietf-ldup@mail.imc.org Tue Feb 20 11:32:22 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA15459 for ; Tue, 20 Feb 2001 11:32:21 -0500 (EST) Received: by above.proper.com (8.9.3/8.9.3) id HAA20955 for ietf-ldup-bks; Tue, 20 Feb 2001 07:46:05 -0800 (PST) Received: from ns.oncalldba.com ([66.1.184.87]) by above.proper.com (8.9.3/8.9.3) with ESMTP id HAA20950 for ; Tue, 20 Feb 2001 07:46:03 -0800 (PST) Received: from reed.oncalldba.com (reed.OnCallDBA.COM [192.168.1.3]) by ns.oncalldba.com (8.11.0/8.8.7) with SMTP id f1KFjKw23047 for ; Tue, 20 Feb 2001 08:45:20 -0700 Received: from RMINC_DOM-Message_Server by reed.oncalldba.com with Novell_GroupWise; Tue, 20 Feb 2001 08:41:53 -0700 Message-Id: X-Mailer: Novell GroupWise Internet Agent 5.5.2.1 Date: Tue, 20 Feb 2001 08:41:31 -0700 From: "Ed Reed" To: , Cc: Subject: RE: WG Last Call on the LDAPv3 Directory Replication I-D Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Disposition: inline Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id HAA20952 Sender: owner-ietf-ldup@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 8bit Hmmm...I've found a point of agreement with Albert ;-)... see [eer] ================= Ed Reed Reed-Matthews, Inc. +1 801 796 7065 http://www.Reed-Matthews.COM >>> "Albert Langer" 02/17/01 01:30PM >>> [Kurt] At 04:39 PM 2/17/01 +1100, Albert Langer wrote: >Put succinctly: LDUP directories won't interoperate. Period. I would say that two LDUP peers could interoperate (from a protocol perspective) but that this, in itself, does not: 1) preserve LDAP/X.500 semantics nor 2) provide "equally capable" replicas. The former issue can not be resolved unless one requires transactional consistency in multiple master replication. The latter issue can be tackled by writing a very tight applicability statements. [Albert] ...snip... A necessary consequence of multi-master, as opposed to single master, is that in addition to transient inconsitencies between data read from different directory servers there will also be problems with data read from a single server. There are 2 options possible for multi-master: 1) Conflicting updates to the same entry are prioritized so that only one succeeds and the others are rolled back. That necessarily results in different behaviour to single master directories but is not fundamentally inconsistent with LDAP semantics and does not prevent interoperability. Problems arising can be resolved by users rather than sysadmins by notifying them of lost updates (whether due to name conflicts or other conflicts). An applicability statement should clearly indicate that multi-master is unsuitable in any situation with a high rate of concurrent changes to the same entries. [eer] I certainly agree that we should make clear (if we have not already), that multi-master is unsuitable in any situation with a high rate (say, frequently faster than the time it takes for a change to fully propagate to all registered replicas) of concurrent changes to the same entries at different master replicas. The "frequently..." qualifier represents my own bias as to what is "reasonable" and might be changed to simply say "faster than...". [/eer] From owner-ietf-ldup@mail.imc.org Tue Feb 20 12:14:05 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA16996 for ; Tue, 20 Feb 2001 12:14:05 -0500 (EST) Received: by above.proper.com (8.9.3/8.9.3) id IAA23733 for ietf-ldup-bks; Tue, 20 Feb 2001 08:22:08 -0800 (PST) Received: from sj-msg-core-4.cisco.com (sj-msg-core-4.cisco.com [171.71.163.10]) by above.proper.com (8.9.3/8.9.3) with ESMTP id IAA23729 for ; Tue, 20 Feb 2001 08:22:07 -0800 (PST) Received: from mira-sjcm-1.cisco.com (mira-sjcm-1.cisco.com [171.69.43.102]) by sj-msg-core-4.cisco.com (8.9.3/8.9.1) with ESMTP id IAA29735; Tue, 20 Feb 2001 08:21:41 -0800 (PST) Received: from JSTRASSN-W2K1.cisco.com ([171.69.108.130]) by mira-sjcm-1.cisco.com (Mirapoint) with ESMTP id AAC09371; Tue, 20 Feb 2001 08:21:37 -0800 (PST) Message-Id: <4.3.2.7.2.20010220082010.00b2dea0@mira-sjcm-1.cisco.com> X-Sender: jstrassn@mira-sjcm-1.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Tue, 20 Feb 2001 08:21:29 -0800 To: "Ed Reed" From: John Strassner Subject: RE: WG Last Call on the LDAPv3 Directory Replication I-D Cc: , , In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ietf-ldup@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This seems reasonable, but I would suggest that we quantify this, perhaps in terms relative to the (average) replication frequency of the system. Thoughts? regards, John At 08:41 AM 2/20/2001 -0700, Ed Reed wrote: >Hmmm...I've found a point of agreement with Albert ;-)... see [eer] > >================= >Ed Reed >Reed-Matthews, Inc. >+1 801 796 7065 >http://www.Reed-Matthews.COM > > >>> "Albert Langer" 02/17/01 > 01:30PM >>> >[Kurt] >At 04:39 PM 2/17/01 +1100, Albert Langer wrote: > >Put succinctly: LDUP directories won't interoperate. Period. > >I would say that two LDUP peers could interoperate (from >a protocol perspective) but that this, in itself, does >not: > 1) preserve LDAP/X.500 semantics nor > 2) provide "equally capable" replicas. > >The former issue can not be resolved unless one requires >transactional consistency in multiple master replication. >The latter issue can be tackled by writing a very tight >applicability statements. > >[Albert] > >...snip... > >A necessary consequence of multi-master, as opposed to single master, >is that in addition to transient inconsitencies between data read from >different directory servers there will also be problems with data read >from a single server. There are 2 options possible for multi-master: > >1) Conflicting updates to the same entry are prioritized so that only >one succeeds and the others are rolled back. That necessarily results >in different behaviour to single master directories but is not >fundamentally inconsistent with LDAP semantics and does not prevent >interoperability. Problems arising can be resolved by users rather than >sysadmins by notifying them of lost updates (whether due to name conflicts >or >other conflicts). An applicability statement should clearly indicate >that multi-master is unsuitable in any situation with a high rate of >concurrent changes to the same entries. > >[eer] I certainly agree that we should make clear (if we have not >already), that multi-master is unsuitable in any situation with a >high rate (say, frequently faster than the time it takes for a change >to fully propagate to all registered replicas) of concurrent changes >to the same entries at different master replicas. > >The "frequently..." qualifier represents my own bias as to what >is "reasonable" and might be changed to simply say "faster than...". > >[/eer] From owner-ietf-ldup@mail.imc.org Tue Feb 20 13:17:48 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA19351 for ; Tue, 20 Feb 2001 13:17:47 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.9.3/8.9.3) id JAA25755 for ietf-ldup-bks; Tue, 20 Feb 2001 09:39:42 -0800 (PST) Received: from DF-INET-1.dogfoodinternet.com (df-inet1.exchange.microsoft.com [131.107.8.8]) by above.proper.com (8.9.3/8.9.3) with ESMTP id JAA25751 for ; Tue, 20 Feb 2001 09:39:41 -0800 (PST) Received: from df-virus2.platinum.corp.microsoft.com ([172.30.236.33]) by DF-INET-1.dogfoodinternet.com with Microsoft SMTPSVC(5.0.2195.2831); Tue, 20 Feb 2001 09:36:39 -0800 Received: from 172.30.236.11 by df-virus2.platinum.corp.microsoft.com (InterScan E-Mail VirusWall NT); Tue, 20 Feb 2001 09:35:46 -0800 (Pacific Standard Time) Received: from DF-MAX.platinum.corp.microsoft.com ([172.30.236.101]) by yuri.dns.microsoft.com with Microsoft SMTPSVC(5.0.2195.2831); Tue, 20 Feb 2001 09:35:45 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.0.4648.0 Content-Class: urn:content-classes:message Subject: RE: WG Last Call on the LDAPv3 Directory Replication I-D MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Tue, 20 Feb 2001 09:35:44 -0800 Message-ID: <5B90AD65A9E8934987DB0C8C0762657406005A07@DF-BOWWOW.platinum.corp.microsoft.com> Thread-Topic: WG Last Call on the LDAPv3 Directory Replication I-D thread-index: AcCbWZqb726JB1ykT+SUp1pmxvJzcAACZpBg From: "Paul Leach" To: "John Strassner" , "Ed Reed" Cc: , , X-OriginalArrivalTime: 20 Feb 2001 17:35:45.0534 (UTC) FILETIME=[8E26A9E0:01C09B63] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id JAA25752 Sender: owner-ietf-ldup@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 8bit Very roughly, if there are N replicas, and each can tolerate an update rate (if it were the only replica) of R, then the total update rate supportable by the replicated directory would be R/N. I do not believe that the replication frequency has much to do with it, unless a low-ish frequency causes many updates to be transferred per replication interval and thereby leads to increased efficiency (due to some batching effect or other). > -----Original Message----- > From: John Strassner [mailto:jstrassn@cisco.com] > Sent: Tuesday, February 20, 2001 8:21 AM > To: Ed Reed > Cc: Albert.Langer@directory-designs.org; Kurt@OpenLDAP.org; > ietf-ldup@imc.org > Subject: RE: WG Last Call on the LDAPv3 Directory Replication I-D > > > This seems reasonable, but I would suggest that we quantify > this, perhaps > in terms relative to the (average) replication frequency of > the system. > Thoughts? > > regards, > John > > At 08:41 AM 2/20/2001 -0700, Ed Reed wrote: > >Hmmm...I've found a point of agreement with Albert ;-)... see [eer] > > > >================= > >Ed Reed > >Reed-Matthews, Inc. > >+1 801 796 7065 > >http://www.Reed-Matthews.COM > > > > >>> "Albert Langer" 02/17/01 > > 01:30PM >>> > >[Kurt] > >At 04:39 PM 2/17/01 +1100, Albert Langer wrote: > > >Put succinctly: LDUP directories won't interoperate. Period. > > > >I would say that two LDUP peers could interoperate (from > >a protocol perspective) but that this, in itself, does > >not: > > 1) preserve LDAP/X.500 semantics nor > > 2) provide "equally capable" replicas. > > > >The former issue can not be resolved unless one requires > >transactional consistency in multiple master replication. > >The latter issue can be tackled by writing a very tight > >applicability statements. > > > >[Albert] > > > >...snip... > > > >A necessary consequence of multi-master, as opposed to single master, > >is that in addition to transient inconsitencies between data > read from > >different directory servers there will also be problems with > data read > >from a single server. There are 2 options possible for multi-master: > > > >1) Conflicting updates to the same entry are prioritized so that only > >one succeeds and the others are rolled back. That necessarily results > >in different behaviour to single master directories but is not > >fundamentally inconsistent with LDAP semantics and does not prevent > >interoperability. Problems arising can be resolved by users > rather than > >sysadmins by notifying them of lost updates (whether due to > name conflicts > >or > >other conflicts). An applicability statement should clearly indicate > >that multi-master is unsuitable in any situation with a high rate of > >concurrent changes to the same entries. > > > >[eer] I certainly agree that we should make clear (if we have not > >already), that multi-master is unsuitable in any situation with a > >high rate (say, frequently faster than the time it takes for a change > >to fully propagate to all registered replicas) of concurrent changes > >to the same entries at different master replicas. > > > >The "frequently..." qualifier represents my own bias as to what > >is "reasonable" and might be changed to simply say "faster than...". > > > >[/eer] > From owner-ietf-ldup@mail.imc.org Tue Feb 20 14:01:15 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA20863 for ; Tue, 20 Feb 2001 14:01:14 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.9.3/8.9.3) id JAA25528 for ietf-ldup-bks; Tue, 20 Feb 2001 09:28:38 -0800 (PST) Received: from ns.oncalldba.com ([66.1.184.87]) by above.proper.com (8.9.3/8.9.3) with ESMTP id JAA25524 for ; Tue, 20 Feb 2001 09:28:35 -0800 (PST) Received: from reed.oncalldba.com (reed.OnCallDBA.COM [192.168.1.3]) by ns.oncalldba.com (8.11.0/8.8.7) with SMTP id f1KHRsw23301 for ; Tue, 20 Feb 2001 10:27:54 -0700 Received: from RMINC_DOM-Message_Server by reed.oncalldba.com with Novell_GroupWise; Tue, 20 Feb 2001 10:24:06 -0700 Message-Id: X-Mailer: Novell GroupWise Internet Agent 5.5.2.1 Date: Tue, 20 Feb 2001 10:23:50 -0700 From: "Ed Reed" To: , Cc: Subject: RE: WG Last Call on the LDAPv3 Directory Replication I-D Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Disposition: inline Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id JAA25525 Sender: owner-ietf-ldup@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 8bit Ahh - the crux of the matter... ================= Ed Reed Reed-Matthews, Inc. +1 801 796 7065 http://www.Reed-Matthews.COM >>> "Albert Langer" 02/17/01 04:59PM >>> [snip] My view is that the critically important requirement that applications depend on is simply that a change can be reliably made to exactly the entry you thought you were changing and not result in some mixture of updates combined with unknown concurrent changes by some other application. [eer] My view is exactly, precisely, and PROFOUNDLY the oposite - that it is critically important that changes to different attributes made at the "same time" to the same entry at two different master replicas MUST interleave and both be preserved. That, in fact, the expected (by reasonable application users sharing information for multiple applications using LDUP replication to facilitate locally improved performance and availability of directory content for those applications) behavior is atomic at the attribute level (if, indeed, not at the attribute-value level) for each attribute being changed. This is, of course, the administration application of the directory as a distributed nameservice for which vendors like Microsoft, Novell, and Lotus use directories. That there is no practical way to utter the request "change attribute A to have value "alpha" if and only if attribute B has exactly the value "beta"" using LDAP and X.500 absent locking mechanisms (theoretical discussions to the contrary being considerably outside the scope of "normal and customary" usage to be expected of application developers). That distributed databases of whatever nature which support such things do so outside the scope of what can reasonably considered "LDAP". And that LDUP is not appropriate for preserving such locking semantics, and is not intended to be. That when such locking semantics are defined for LDAP, that LDUP may then consider how or indeed if they can be reliably replicated via some use of LDUP or some modification of LDUP, but that until such semantics are defined that it is foolish to attempt to preserve them in LDUP. That the simple perspective that because it is possible (by standing on your head and waving a chicken about with precisely the correct flapping pattern of your legs) to achieve some sort of "test and set" behavior against a single server, that the ability to continue to provide the behavior to a group of distributed, replicated servers operating without benefit of distributed memory of any sort (and thus, operating locally autonomously - which IS the desired behavior to provide continued access and availability to the data that ARE present for local applications in the face of network outages) should somehow be a show-stopper represents a fundamental disagreement over what is desired from a "loose consistency multi-master replication scheme for directories supporting LDAP". That there are LOTS of alternative approaches to providing shared application profile information, ranging from ACAP (which I would characterize as a network accessible associative memory service) to a distributed shared memory system intended to provide cluster-level disk sector semaphores (with or without write-down mandatory access control prohibitions). These are things LDAP and LDUP are not suitable to support. That if needed to move things forward, to encourage multi-vendor inter-replication of LDAP directory content, I would gladly advise developers who attempt to create their own locking or test-and-set operations to be sure that, as Albert has correctly described "a change can be reliably made to exactly the entry you thought you were changing and not result in some mixture of updates combined with unknown concurrent changes by some other application" that they do so at their own peril when operating against directories supporting LDUP. Look, folks - this all would have been easy to provide for fully atomic operations against multiple-master replicas...just add XA semantics to LDAP for enforcement among all master (updateable) replicas with full two-phase commit support for each required atomic operation. Phase one, all masters would verify that they had no pending operations which are in conflict with the proposed changes and that they're blocking any new such requests until the commit or rollback command is received. Phase two, commit or rollback after all updateable replicas reply "ready". But that's NOT WHAT WE SET OUT TO DO. THAT'S NOT WHAT ANY OF US WANTED TO IMPOSE. THAT'S NOT WHY WE'RE USING LDAP. STOP TRYING TO MOVE US THERE! Albert - as far as I can tell, even Microsoft has moved towards interleaving attribute changes, away from the entry-level sequence number scheme that CODA and ADSv1 used. No, LDUP won't do that. I personally don't think it SHOULD do that. We may agree to disagree on that point. Best regards, Ed From owner-ietf-ldup@mail.imc.org Tue Feb 20 14:05:25 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA21024 for ; Tue, 20 Feb 2001 14:05:25 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.9.3/8.9.3) id KAA27247 for ietf-ldup-bks; Tue, 20 Feb 2001 10:20:48 -0800 (PST) Received: from DF-INET-1.dogfoodinternet.com (df-inet1.exchange.microsoft.com [131.107.8.8]) by above.proper.com (8.9.3/8.9.3) with ESMTP id KAA27243 for ; Tue, 20 Feb 2001 10:20:47 -0800 (PST) Received: from df-virus2.platinum.corp.microsoft.com ([172.30.236.33]) by DF-INET-1.dogfoodinternet.com with Microsoft SMTPSVC(5.0.2195.2831); Tue, 20 Feb 2001 10:20:10 -0800 Received: from 172.30.236.11 by df-virus2.platinum.corp.microsoft.com (InterScan E-Mail VirusWall NT); Tue, 20 Feb 2001 10:19:16 -0800 (Pacific Standard Time) Received: from DF-MAX.platinum.corp.microsoft.com ([172.30.236.101]) by yuri.dns.microsoft.com with Microsoft SMTPSVC(5.0.2195.2831); Tue, 20 Feb 2001 10:19:15 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.0.4648.0 Content-Class: urn:content-classes:message Subject: RE: WG Last Call on the LDAPv3 Directory Replication I-D MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Date: Tue, 20 Feb 2001 10:19:14 -0800 Message-ID: <5B90AD65A9E8934987DB0C8C07626574473104@DF-BOWWOW.platinum.corp.microsoft.com> Thread-Topic: WG Last Call on the LDAPv3 Directory Replication I-D thread-index: AcCbYyc1Qa3/SqaISeyKOPEmJnUq9wABAlng From: "Paul Leach" To: "Ed Reed" , , Cc: X-OriginalArrivalTime: 20 Feb 2001 18:19:15.0547 (UTC) FILETIME=[A1D70AB0:01C09B69] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id KAA27244 Sender: owner-ietf-ldup@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 8bit > -----Original Message----- > From: Ed Reed [mailto:eer@OnCallDBA.COM] > Sent: Tuesday, February 20, 2001 9:24 AM > To: Albert.Langer@directory-designs.org; Kurt@OpenLDAP.org > Cc: ietf-ldup@imc.org > Subject: RE: WG Last Call on the LDAPv3 Directory Replication I-D > > > Ahh - the crux of the matter... > > > > ================= > Ed Reed > Reed-Matthews, Inc. > +1 801 796 7065 > http://www.Reed-Matthews.COM > > >>> "Albert Langer" > 02/17/01 04:59PM >>> > [snip] > My view is that the critically important requirement that applications > depend on > is simply that a change can be reliably made to exactly the entry you > thought you > were changing and not result in some mixture of updates combined with > unknown > concurrent changes by some other application. > > [eer] > > My view is exactly, precisely, and PROFOUNDLY the oposite - > that it is critically > important that changes to different attributes made at the > "same time" to > the same entry at two different master replicas MUST > interleave and both > be preserved. I view this as an unfortunate side effect of the ability to independently change one replica even when others are not accessible, not as a requirement. Suppose one app does an atomic update of attributes A, B and C on object with DN X at replica R1 and another app does an atomic update of X with attributes B, C, and D. If the result is that B's ultimate value after all replication ends comes from the first app and C's comes from the second, I can guarantee you that many programmers will not have correctly programmed their apps to handle that. > That if needed to move things forward, to encourage multi-vendor > inter-replication of LDAP directory content, I would gladly advise > developers who attempt to create their own locking or test-and-set > operations to be sure that, as Albert has correctly described > "a change > can be reliably made to exactly the entry you thought you > were changing and not result in some mixture of updates combined with > unknown concurrent changes by some other application" that they > do so at their own peril when operating against directories supporting > LDUP. I think this should be pointed out. > > Look, folks - this all would have been easy to provide for fully > atomic operations against multiple-master replicas...just add XA > semantics to LDAP for enforcement among all master (updateable) > replicas with full two-phase commit support for each required > atomic operation. Phase one, all masters would verify that > they had no pending operations which are in conflict with > the proposed changes and that they're blocking any new such > requests until the commit or rollback command is received. Phase > two, commit or rollback after all updateable replicas reply "ready". I would not even call this "multi-master". It does not permit operations to proceed in the face of a network partition. I.e., there's really only one master (dynamically selected, perhaps, and distributed), but unless the master is accessible to a client, no updates can be done by that client. > > Albert - as far as I can tell, even Microsoft has moved towards > interleaving attribute changes, away from the entry-level sequence > number scheme that CODA and ADSv1 used. This is not a correct understanding of what we do now nor any future direction. We have always interleaved attribute changes -- replication is on an individual attribute basis (not an object basis). Paul From owner-ietf-ldup@mail.imc.org Tue Feb 20 17:49:12 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA28503 for ; Tue, 20 Feb 2001 17:49:11 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.9.3/8.9.3) id OAA02078 for ietf-ldup-bks; Tue, 20 Feb 2001 14:10:30 -0800 (PST) Received: from myrealbox.com (mail.myrealbox.com [192.108.102.201]) by above.proper.com (8.9.3/8.9.3) with ESMTP id OAA02074 for ; Tue, 20 Feb 2001 14:10:28 -0800 (PST) Received: from [192.168.1.209] [64.50.112.2] by myrealbox.com with Novonyx SMTP Server $Revision: 2.76 $; Tue, 20 Feb 2001 15:01:14 -0700 (MDT) User-Agent: Microsoft-Entourage/9.0.2509 Date: Tue, 20 Feb 2001 14:09:38 -0800 Subject: Re: WG Last Call on the LDAPv3 Directory Replication I-D From: Jerry Combs To: Paul Leach , John Strassner , Ed Reed CC: , , Message-ID: In-Reply-To: <5B90AD65A9E8934987DB0C8C0762657406005A07@DF-BOWWOW.platinum.corp.microsoft.com> Mime-version: 1.0 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 This assumes that replication is implemented as a 1 to N function. If transitive replication was implemented instead, each replicas efficiency could be maintained by limiting the number of replicas that it communicates to directly. While at low update rates transitive synchronization lengthens the update interval, at high update rates it is vastly more efficient. Lack of transitive synchronization will limit LDUP scalability. Transitive synch also allows you to minimize the impact of slow communication links. JC Principal Consultant JWCOMBS@LDAPEXPERTS.COM On 2/20/01 9:35 AM, "Paul Leach" wrote: > Very roughly, if there are N replicas, and each can tolerate an update > rate (if it were the only replica) of R, then the total update rate > supportable by the replicated directory would be R/N. > > I do not believe that the replication frequency has much to do with it, > unless a low-ish frequency causes many updates to be transferred per > replication interval and thereby leads to increased efficiency (due to > some batching effect or other). > >> -----Original Message----- >> From: John Strassner [mailto:jstrassn@cisco.com] >> Sent: Tuesday, February 20, 2001 8:21 AM >> To: Ed Reed >> Cc: Albert.Langer@directory-designs.org; Kurt@OpenLDAP.org; >> ietf-ldup@imc.org >> Subject: RE: WG Last Call on the LDAPv3 Directory Replication I-D >> >> >> This seems reasonable, but I would suggest that we quantify >> this, perhaps >> in terms relative to the (average) replication frequency of >> the system. >> Thoughts? >> >> regards, >> John >> >> At 08:41 AM 2/20/2001 -0700, Ed Reed wrote: >>> Hmmm...I've found a point of agreement with Albert ;-)... see [eer] >>> >>> ================= >>> Ed Reed >>> Reed-Matthews, Inc. >>> +1 801 796 7065 >>> http://www.Reed-Matthews.COM >>> >>>>>> "Albert Langer" 02/17/01 >>> 01:30PM >>> >>> [Kurt] >>> At 04:39 PM 2/17/01 +1100, Albert Langer wrote: >>>> Put succinctly: LDUP directories won't interoperate. Period. >>> >>> I would say that two LDUP peers could interoperate (from >>> a protocol perspective) but that this, in itself, does >>> not: >>> 1) preserve LDAP/X.500 semantics nor >>> 2) provide "equally capable" replicas. >>> >>> The former issue can not be resolved unless one requires >>> transactional consistency in multiple master replication. >>> The latter issue can be tackled by writing a very tight >>> applicability statements. >>> >>> [Albert] >>> >>> ...snip... >>> >>> A necessary consequence of multi-master, as opposed to single master, >>> is that in addition to transient inconsitencies between data >> read from >>> different directory servers there will also be problems with >> data read >>> from a single server. There are 2 options possible for multi-master: >>> >>> 1) Conflicting updates to the same entry are prioritized so that only >>> one succeeds and the others are rolled back. That necessarily results >>> in different behaviour to single master directories but is not >>> fundamentally inconsistent with LDAP semantics and does not prevent >>> interoperability. Problems arising can be resolved by users >> rather than >>> sysadmins by notifying them of lost updates (whether due to >> name conflicts >>> or >>> other conflicts). An applicability statement should clearly indicate >>> that multi-master is unsuitable in any situation with a high rate of >>> concurrent changes to the same entries. >>> >>> [eer] I certainly agree that we should make clear (if we have not >>> already), that multi-master is unsuitable in any situation with a >>> high rate (say, frequently faster than the time it takes for a change >>> to fully propagate to all registered replicas) of concurrent changes >>> to the same entries at different master replicas. >>> >>> The "frequently..." qualifier represents my own bias as to what >>> is "reasonable" and might be changed to simply say "faster than...". >>> >>> [/eer] >> > From owner-ietf-ldup@mail.imc.org Tue Feb 20 18:48:15 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA29585 for ; Tue, 20 Feb 2001 18:48:13 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.9.3/8.9.3) id PAA03756 for ietf-ldup-bks; Tue, 20 Feb 2001 15:10:57 -0800 (PST) Received: from almso1.proxy.att.com (almso1.att.com [192.128.167.69]) by above.proper.com (8.9.3/8.9.3) with ESMTP id PAA03752 for ; Tue, 20 Feb 2001 15:10:55 -0800 (PST) Received: from qsun.mt.att.com ([135.16.31.2]) by almso1.proxy.att.com (AT&T IPNS/MSO-3.0) with SMTP id f1KNAKO11642; Tue, 20 Feb 2001 18:10:20 -0500 (EST) Received: from att.com by qsun.mt.att.com (SMI-8.6/ATTEMS-1.4.1 sol2) id SAA21810; Tue, 20 Feb 2001 18:10:18 -0500 Message-ID: <3A92F933.468B3523@att.com> Date: Tue, 20 Feb 2001 18:09:39 -0500 From: Richard Huber X-Mailer: Mozilla 4.75 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: John Strassner CC: Ed Reed , Albert.Langer@directory-designs.org, Kurt@OpenLDAP.org, ietf-ldup@imc.org Subject: Re: WG Last Call on the LDAPv3 Directory Replication I-D References: <4.3.2.7.2.20010220082010.00b2dea0@mira-sjcm-1.cisco.com> 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 John, I really don't think the requirements document is the place to quantify this. If the list really thinks we need to quantify it, let's do it in the profile document (though it probably won't make the -00 draft which needs to get in by Friday). As for Albert's/Ed's original point, I agree. The requirements already note in B.5.5 that having multiple users/applications changing the same data at the same time is a way to get into trouble. I suppose we could change "at the same time" to "before previous changes have replicated" if that makes it clearer. Rick Huber John Strassner wrote: > This seems reasonable, but I would suggest that we quantify this, perhaps > in terms relative to the (average) replication frequency of the system. > Thoughts? > > regards, > John > > At 08:41 AM 2/20/2001 -0700, Ed Reed wrote: > >Hmmm...I've found a point of agreement with Albert ;-)... see [eer] > > > >================= > >Ed Reed > >Reed-Matthews, Inc. > >+1 801 796 7065 > >http://www.Reed-Matthews.COM > > > > >>> "Albert Langer" 02/17/01 > > 01:30PM >>> > >[Kurt] > >At 04:39 PM 2/17/01 +1100, Albert Langer wrote: > > >Put succinctly: LDUP directories won't interoperate. Period. > > > >I would say that two LDUP peers could interoperate (from > >a protocol perspective) but that this, in itself, does > >not: > > 1) preserve LDAP/X.500 semantics nor > > 2) provide "equally capable" replicas. > > > >The former issue can not be resolved unless one requires > >transactional consistency in multiple master replication. > >The latter issue can be tackled by writing a very tight > >applicability statements. > > > >[Albert] > > > >...snip... > > > >A necessary consequence of multi-master, as opposed to single master, > >is that in addition to transient inconsitencies between data read from > >different directory servers there will also be problems with data read > >from a single server. There are 2 options possible for multi-master: > > > >1) Conflicting updates to the same entry are prioritized so that only > >one succeeds and the others are rolled back. That necessarily results > >in different behaviour to single master directories but is not > >fundamentally inconsistent with LDAP semantics and does not prevent > >interoperability. Problems arising can be resolved by users rather than > >sysadmins by notifying them of lost updates (whether due to name conflicts > >or > >other conflicts). An applicability statement should clearly indicate > >that multi-master is unsuitable in any situation with a high rate of > >concurrent changes to the same entries. > > > >[eer] I certainly agree that we should make clear (if we have not > >already), that multi-master is unsuitable in any situation with a > >high rate (say, frequently faster than the time it takes for a change > >to fully propagate to all registered replicas) of concurrent changes > >to the same entries at different master replicas. > > > >The "frequently..." qualifier represents my own bias as to what > >is "reasonable" and might be changed to simply say "faster than...". > > > >[/eer] From owner-ietf-ldup@mail.imc.org Tue Feb 20 19:01:03 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA29840 for ; Tue, 20 Feb 2001 19:01:03 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.9.3/8.9.3) id PAA03993 for ietf-ldup-bks; Tue, 20 Feb 2001 15:20:11 -0800 (PST) Received: from DF-INET-1.dogfoodinternet.com (df-inet1.exchange.microsoft.com [131.107.8.8]) by above.proper.com (8.9.3/8.9.3) with ESMTP id PAA03989 for ; Tue, 20 Feb 2001 15:20:10 -0800 (PST) Received: from df-virus2.platinum.corp.microsoft.com ([172.30.236.33]) by DF-INET-1.dogfoodinternet.com with Microsoft SMTPSVC(5.0.2195.2831); Tue, 20 Feb 2001 15:16:25 -0800 Received: from 172.30.236.11 by df-virus2.platinum.corp.microsoft.com (InterScan E-Mail VirusWall NT); Tue, 20 Feb 2001 15:15:30 -0800 (Pacific Standard Time) Received: from DF-MAX.platinum.corp.microsoft.com ([172.30.236.101]) by yuri.dns.microsoft.com with Microsoft SMTPSVC(5.0.2195.2831); Tue, 20 Feb 2001 15:15:23 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.0.4648.0 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: WG Last Call on the LDAPv3 Directory Replication I-D Date: Tue, 20 Feb 2001 11:29:22 -0800 Message-ID: <5B90AD65A9E8934987DB0C8C07626574473106@DF-BOWWOW.platinum.corp.microsoft.com> Thread-Topic: WG Last Call on the LDAPv3 Directory Replication I-D thread-index: AcCauLwyH0eOlngWTJqwtV0VlA1TgAAuHVXg From: "Paul Leach" To: "John Strassner" Cc: "Ryan Moats" , "Mark Brown (REDMOND)" , "Richard V Huber" , , , , , , X-OriginalArrivalTime: 20 Feb 2001 23:15:23.0873 (UTC) FILETIME=[00966D10:01C09B93] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id PAA03990 Sender: owner-ietf-ldup@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 8bit > -----Original Message----- > From: John Strassner [mailto:jstrassn@cisco.com] > Sent: Sunday, February 18, 2001 9:47 PM > To: Paul Leach > Cc: Ryan Moats; Mark Brown (REDMOND); Richard V Huber; > ietf-ldup@imc.org; johns@cisco.com; capple@ecal.com; paf@cisco.com; > rweiser@digsigtrust.com; stokes@austin.ibm.com > Subject: RE: WG Last Call on the LDAPv3 Directory Replication I-D > > > I disagree on several counts. > > First, if we start singling out particular types of > information that can or > can not be replicated, where do we stop? We should describe the general class of information that can not be replicated, plus some examples, and stop at the place where enough examples are listed to make the issue clear. > > Second, please stop using the term "passive data" as no one > on this list > has defined it in an unambiguous and satisfactory manner. It > is impossible > to consider using LDUP in this fashion until a definition for > this term > that we can all agree with is offered and agreed to. I did post such a definition. I had thought that the term was generally understood. > > Third, what you're basically saying is that we should close > up shop until > LDAPext has finished a standards-track access control model > RFC. I don't > agree at all. First of all, RFC 2251, section 3.2, says that > "Servers which > perform caching or shadowing MUST ensure that they do not violate any > access control constraints placed on the data by the > originating server." No, I'm not. I just said we should point out that such a standard has to be finished, and until it is, otherwise standards compliant LDAP servers that use ACLs won't be able to interoperably replicate. And that such a situation is just one example of a general problem -- some of which won't be able to be solved as easily. The two general cases that will present issues are 1. Active data. Subcases are virtual attributes and writes with side effects 2. "Hidden data". By this I mean state the effect the behavior of the directory, but which is manipulated by by means outside the LDAP standard, and effect LDAP behavior. ACLs currently fall in this category. Currently, LDAP directories can do both of these things, and yet be totally conformant to the LDAP standard. In every such case, before interoperability can take place, a standard which maps the effects onto some standard replication interchange format will have to be put in place. That means that any two directories that are totally LDAP compliant and which support _any_ thing falling into those two categories, can not interoperably replicate. I claim this is counter-intuitive: each is totally LDAP compliant, after all, so most people would think that of course they should replicate correctly. I therefore think it is important to make clear that there is no requirement that LDUP be able to replicate such directories -- otherwise we will be setting ourselves an impossible task. > > Finally, we have a lot of work to do in this wg, and all of > it hinges on > this draft. Good reason to make sure its a solid spec and doesn't require impossibilities. We can't go forward with anything else until this > draft goes > forward. I don't think our ADs nor the wg as a whole wants to > wait any longer. Seems like there a quite a few people who still have comments on the draft. From owner-ietf-ldup@mail.imc.org Tue Feb 20 20:07:27 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA00960 for ; Tue, 20 Feb 2001 20:07:26 -0500 (EST) Received: by above.proper.com (8.9.3/8.9.3) id QAA05558 for ietf-ldup-bks; Tue, 20 Feb 2001 16:23:45 -0800 (PST) Received: from pretender.boolean.net (root@router.boolean.net [198.144.206.49]) by above.proper.com (8.9.3/8.9.3) with ESMTP id QAA05554 for ; Tue, 20 Feb 2001 16:23:43 -0800 (PST) Received: from gypsy.OpenLDAP.org (gypsy.boolean.net [10.192.1.2]) by pretender.boolean.net (8.11.1/8.11.1/Boolean/Hub) with ESMTP id f1L0MmD22467; Wed, 21 Feb 2001 00:22:49 GMT (envelope-from Kurt@OpenLDAP.org) Message-Id: <5.0.2.1.0.20010219214225.00a92ab0@router.boolean.net> X-Sender: guru@router.boolean.net X-Mailer: QUALCOMM Windows Eudora Version 5.0.2 Date: Tue, 20 Feb 2001 16:21:51 -0800 To: From: "Kurt D. Zeilenga" Subject: Re: Comments on draft-ietf-ldup-replica-req-06.txt Cc: In-Reply-To: <000201c09aef$533e31a0$b05508cb@osmium.adacel.com.au> References: <5B90AD65A9E8934987DB0C8C0762657493DDBF@DF-BOWWOW.platinum.corp.microsoft.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 02:43 PM 2/20/01 +1100, Steven Legg wrote: >> 3 The Models > >> Consistency models 1, 2 and 3 involve the use of prearranged >> replication agreements among servers. The added complexity of the >> distributed 2-phase commit required for Model 1 is significant; >> therefor, model 1 will not be considered at this time. Models 4 and 5 >> involve unregistered replicas that "pull" updates from another >> directory server without that server's knowledge. These models violate >> a directory's security policies. > >It seems to me that any of the five models could violate, or preserve, >a directory's security policies. It all depends on whether the consumer >of the replicated data receives and honours the security information. ... in the same way. That is, you can have two servers implementing the same Standard Track ACM but still have significant differences in how each applies the same access control information. One doesn't have to go far to find a SHOULD or MAY in the TS which impacts access control processing. >> P7. The protocol SHOULD NOT preclude support of Transactional >> Consistency (model 1). > >I think this should be more general than just the protocol. >The replication architecture SHOULD NOT preclude ... Yes, please. > AM6. Access control information (ACI) associated with sensitive data >> MUST be deleted after or simultaneously with the deletion of the >> sensitive data. Likewise, during Adds, ACI MUST be added first or >> simultaneously with the addition of that data. > >This is a requirement on LDAP users rather than the replication >architecture. >The requirement for replication would be that where there are updates >to sensitive data and the ACIs controlling access to those data, the updates >SHOULD/MUST be applied at other replicas in the same order. I concur. From owner-ietf-ldup@mail.imc.org Tue Feb 20 20:13:18 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA01100 for ; Tue, 20 Feb 2001 20:13:18 -0500 (EST) Received: by above.proper.com (8.9.3/8.9.3) id QAA05755 for ietf-ldup-bks; Tue, 20 Feb 2001 16:32:55 -0800 (PST) Received: from pretender.boolean.net (root@router.boolean.net [198.144.206.49]) by above.proper.com (8.9.3/8.9.3) with ESMTP id QAA05751 for ; Tue, 20 Feb 2001 16:32:54 -0800 (PST) Received: from gypsy.OpenLDAP.org (gypsy.boolean.net [10.192.1.2]) by pretender.boolean.net (8.11.1/8.11.1/Boolean/Hub) with ESMTP id f1L0W8D22490 for ; Wed, 21 Feb 2001 00:32:08 GMT (envelope-from Kurt@OpenLDAP.org) Message-Id: <5.0.2.1.0.20010219203244.00a90b20@router.boolean.net> X-Sender: guru@router.boolean.net X-Mailer: QUALCOMM Windows Eudora Version 5.0.2 Date: Tue, 20 Feb 2001 16:32:08 -0800 To: ietf-ldup@imc.org From: "Kurt D. Zeilenga" Subject: additional comments: draft-ietf-ldup-replica-req-06.txt 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: This post provides comments in addition to my past posts. draft-ietf-ldup-replica-req-06.txt [trimmed]: > There are five data consistency models. > > Model 1: Transactional Consistency -- Environments that exhibit all > four of the ACID properties (Atomicity, Concurrency, Independence, > Durability) [ACID]. > > Model 2: Eventual (or Transient) Consistency -- Environments where > definite knowledge of the topology is provided through predetermined > replication agreements. Examples include X.500 Directories I would like a note added here that X.500 replication model is single master. > Consistency models 1, 2 and 3 involve the use of prearranged > replication agreements among servers. The added complexity of the > distributed 2-phase commit required for Model 1 is significant; > therefor, model 1 will not be considered at this time. I would like the above sentence replaced with "While Model 1 is required to provide atomicity, the complexity of distributed 2-phase commit required for Model 1 is significant and, therefor, Model 1 is not to be considered at this time." or like statement which highlights the lost capabilities of this choice. [note, I do not intend to re-discuss the choice, but to clarify the pros and cons of the choice]. > Interoperability of replicas between directory servers may be limited > by servers that implement semantics that go beyond what the LDAP access > protocol defines. Or optional features the protocol defines (such as subtypes). > Examples (not an exhaustive list) of such semantics > include: (1) replication among directory servers with different access > control systems/semantics may compromise directory security, and (2) > replication among directory servers with different application trigger > semantics may compromise directory data integrity. I'd like to see knowledge information representation/semantics added to this non-exhaustive list. > 4 Requirements I would like a section added discussing RFC 2251 statements which imply requirements upon replicas. In particular, the statement regarding access controls constraints and "equally capable" servers. > M2. The replication model MUST support both master-slave and multi- > master relationships. How about mixed relationships? M masters and N slaves? Is there a minimum number of masters the model must support? More generally, are there topologies which must be supported? Are there topologies which need not be supported? > M4. LDAP replication MUST encompass schema definitions, attribute > names and values, access control information, and name space > information. I suggest adding "knowledge information" to this list. I'd also think the MUST could be a SHOULD. From owner-ietf-ldup@mail.imc.org Tue Feb 20 20:43:36 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA01502 for ; Tue, 20 Feb 2001 20:43:35 -0500 (EST) Received: by above.proper.com (8.9.3/8.9.3) id RAA06418 for ietf-ldup-bks; Tue, 20 Feb 2001 17:06:59 -0800 (PST) Received: from pretender.boolean.net (root@router.boolean.net [198.144.206.49]) by above.proper.com (8.9.3/8.9.3) with ESMTP id RAA06414 for ; Tue, 20 Feb 2001 17:06:58 -0800 (PST) Received: from gypsy.OpenLDAP.org (gypsy.boolean.net [10.192.1.2]) by pretender.boolean.net (8.11.1/8.11.1/Boolean/Hub) with ESMTP id f1L16AD22602; Wed, 21 Feb 2001 01:06:11 GMT (envelope-from Kurt@OpenLDAP.org) Message-Id: <5.0.2.1.0.20010220164809.00a59670@router.boolean.net> X-Sender: guru@router.boolean.net X-Mailer: QUALCOMM Windows Eudora Version 5.0.2 Date: Tue, 20 Feb 2001 17:06:10 -0800 To: "Paul Leach" From: "Kurt D. Zeilenga" Subject: RE: several counts (Was: WG Last Call on the LDAPv3 Directory Replication I-D) Cc: In-Reply-To: <5B90AD65A9E8934987DB0C8C07626574473102@DF-BOWWOW.platinum. corp.microsoft.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 02:19 AM 2/20/01 -0800, Paul Leach wrote: >> -----Original Message----- >> From: Kurt D. Zeilenga [mailto:Kurt@OpenLDAP.org] >> Sent: Monday, February 19, 2001 3:03 PM >> To: John Strassner >> Cc: ietf-ldup@imc.org >> Subject: Re: several counts (Was: WG Last Call on the LDAPv3 Directory >> Replication I-D) >> >> >Second, please stop using the term "passive data" as no one >> on this list has defined it in an unambiguous and >> satisfactory manner. It is impossible to consider using LDUP >> in this fashion until a definition for this term that we can >> all agree with is offered and agreed to. >> >> I agree. I believe we should use the term "userApplication" >> attribute. >> This is well defined. > >Well, I used "passive data" recently, and I don't know if >"userApplication" is at all related. Well, I think the problem is that you are trying to describe experimental semantics. >What I mean by "passive data" is this: An attribute may be said to be >"passive data" when >a write to the attribute followed by a read of the same attribute >returns exactly the data written, and no other attribute's value is >affected. That sounds like userApplication usage to me. >An attribute that is not "passive data" is "active data". "active data" sounds like "operational" usage to me. That is, operational usage includes (but not limited to) attributes which the server maintains. Kurt From owner-ietf-ldup@mail.imc.org Tue Feb 20 21:13:48 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id VAA01879 for ; Tue, 20 Feb 2001 21:13:47 -0500 (EST) Received: by above.proper.com (8.9.3/8.9.3) id RAA07578 for ietf-ldup-bks; Tue, 20 Feb 2001 17:36:35 -0800 (PST) Received: from sj-msg-core-1.cisco.com (sj-msg-core-1.cisco.com [171.71.163.11]) by above.proper.com (8.9.3/8.9.3) with ESMTP id RAA07573 for ; Tue, 20 Feb 2001 17:36:34 -0800 (PST) Received: from mira-sjcm-1.cisco.com (mira-sjcm-1.cisco.com [171.69.43.102]) by sj-msg-core-1.cisco.com (8.9.3/8.9.1) with ESMTP id RAA10948; Tue, 20 Feb 2001 17:36:24 -0800 (PST) Received: from JSTRASSN-W2K1.cisco.com (rtp-dial-1-213.cisco.com [10.83.97.213]) by mira-sjcm-1.cisco.com (Mirapoint) with ESMTP id AAE09285; Tue, 20 Feb 2001 17:35:41 -0800 (PST) Message-Id: <4.3.2.7.2.20010220143508.01fe33c0@mira-sjcm-1.cisco.com> X-Sender: jstrassn@mira-sjcm-1.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Tue, 20 Feb 2001 14:36:30 -0800 To: "Paul Leach" From: John Strassner Subject: RE: WG Last Call on the LDAPv3 Directory Replication I-D Cc: "John Strassner" , , "Kurt D. Zeilenga" , In-Reply-To: <5B90AD65A9E8934987DB0C8C0762657406005A02@DF-BOWWOW.platinu m.corp.microsoft.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ietf-ldup@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: I don't understand your "Huh?", as the application instances could just as easily be operating on the same replica, or one could build a more robust system that front-ends the replicas and handles conflicts there. John At 05:50 PM 2/19/2001 -0800, Paul Leach wrote: > > -----Original Message----- > > From: John Strassner [mailto:jstrassn@cisco.com] > > Sent: Monday, February 19, 2001 10:27 AM > > To: Albert.Langer@directory-designs.org > > Cc: Kurt D. Zeilenga; ietf-ldup@imc.org > > Subject: RE: WG Last Call on the LDAPv3 Directory Replication I-D > > > > > > Not true. First, applications can certainly build locking and other > > mechanisms to isolate operations affecting an update. > >Huh? The application instances could be operating on different replicas, >so will never even see the "locking" operations of the other. They will >proceed as if they were isolated, and then their updates will clash >laters. When the attributes being modified overlap partially but not >completely, neither one of them will get a consistent set. From owner-ietf-ldup@mail.imc.org Tue Feb 20 21:14:13 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id VAA01892 for ; Tue, 20 Feb 2001 21:14:12 -0500 (EST) Received: by above.proper.com (8.9.3/8.9.3) id RAA07622 for ietf-ldup-bks; Tue, 20 Feb 2001 17:37:06 -0800 (PST) Received: from sj-msg-core-4.cisco.com (sj-msg-core-4.cisco.com [171.71.163.10]) by above.proper.com (8.9.3/8.9.3) with ESMTP id RAA07614 for ; Tue, 20 Feb 2001 17:37:05 -0800 (PST) Received: from mira-sjcm-1.cisco.com (mira-sjcm-1.cisco.com [171.69.43.102]) by sj-msg-core-4.cisco.com (8.9.3/8.9.1) with ESMTP id RAA01352; Tue, 20 Feb 2001 17:36:41 -0800 (PST) Received: from JSTRASSN-W2K1.cisco.com (rtp-dial-1-213.cisco.com [10.83.97.213]) by mira-sjcm-1.cisco.com (Mirapoint) with ESMTP id AAE09304; Tue, 20 Feb 2001 17:36:14 -0800 (PST) Message-Id: <4.3.2.7.2.20010220144318.01ff95d8@mira-sjcm-1.cisco.com> X-Sender: jstrassn@mira-sjcm-1.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Tue, 20 Feb 2001 14:47:12 -0800 To: "Paul Leach" From: John Strassner Subject: RE: several counts (Was: WG Last Call on the LDAPv3 Directory Replication I-D) Cc: "Kurt D. Zeilenga" , "John Strassner" , In-Reply-To: <5B90AD65A9E8934987DB0C8C07626574473102@DF-BOWWOW.platinum. corp.microsoft.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ietf-ldup@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Thanks for providing a better definition, but I still don't see how we can use this one. There's no guarantee, for instance, that what is at one moment in time "passive" data won't change to "active data" soon thereafter. This means that the data can't be consistently nor deterministically characterized as either "passive" or "active". Plus, data of a particular type or use may be active in one replica and passive in another. There are yet more variations that we could consider, but I think that these are plenty for now. If you can solve these and related problems, please respond. Otherwise, let's just drop the use of the term. thanks, John At 02:19 AM 2/20/2001 -0800, Paul Leach wrote: > > -----Original Message----- > > From: Kurt D. Zeilenga [mailto:Kurt@OpenLDAP.org] > > Sent: Monday, February 19, 2001 3:03 PM > > To: John Strassner > > Cc: ietf-ldup@imc.org > > Subject: Re: several counts (Was: WG Last Call on the LDAPv3 Directory > > Replication I-D) > > > > >Second, please stop using the term "passive data" as no one > > on this list has defined it in an unambiguous and > > satisfactory manner. It is impossible to consider using LDUP > > in this fashion until a definition for this term that we can > > all agree with is offered and agreed to. > > > > I agree. I believe we should use the term "userApplication" > > attribute. > > This is well defined. > >Well, I used "passive data" recently, and I don't know if >"userApplication" is at all related. > >What I mean by "passive data" is this: An attribute may be said to be >"passive data" when >a write to the attribute followed by a read of the same attribute >returns exactly the data written, and no other attribute's value is >affected. > >An attribute that is not "passive data" is "active data". A directory >may be LDAP compliant and still contain active data. Two different >directory implementations may therefore be LDAP compliant yet implement >different forms of active data (different attributes may be active, for >example). However, issues have been raised about the ability to >replicate active data, between directories that implement their active >data differently, and hence on the viability of the requirement that >LDUP be able to replicate any LDAP compliant directory. From owner-ietf-ldup@mail.imc.org Tue Feb 20 21:14:48 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id VAA01903 for ; Tue, 20 Feb 2001 21:14:48 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.9.3/8.9.3) id RAA07553 for ietf-ldup-bks; Tue, 20 Feb 2001 17:36:08 -0800 (PST) Received: from sj-msg-core-4.cisco.com (sj-msg-core-4.cisco.com [171.71.163.10]) by above.proper.com (8.9.3/8.9.3) with ESMTP id RAA07549 for ; Tue, 20 Feb 2001 17:36:06 -0800 (PST) Received: from mira-sjcm-1.cisco.com (mira-sjcm-1.cisco.com [171.69.43.102]) by sj-msg-core-4.cisco.com (8.9.3/8.9.1) with ESMTP id RAA00675; Tue, 20 Feb 2001 17:35:37 -0800 (PST) Received: from JSTRASSN-W2K1.cisco.com (rtp-dial-1-213.cisco.com [10.83.97.213]) by mira-sjcm-1.cisco.com (Mirapoint) with ESMTP id AAE09267; Tue, 20 Feb 2001 17:34:53 -0800 (PST) Message-Id: <4.3.2.7.2.20010220140958.01fe8d88@mira-sjcm-1.cisco.com> X-Sender: jstrassn@mira-sjcm-1.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Tue, 20 Feb 2001 14:18:16 -0800 To: From: John Strassner Subject: RE: WG Last Call on the LDAPv3 Directory Replication I-D Cc: "'John Strassner'" , , "'Mark Brown \(REDMOND\)'" , "'Richard V Huber'" , , , , , , In-Reply-To: <001701c09ac2$243a3020$6628a8c0@nowhere.com> References: <4.3.2.7.2.20010219102747.00b48770@mira-sjcm-1.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ietf-ldup@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Albert, I would very much like the emotion to be reduced and have just technical issues be discussed on this list. I did respond to you privately (another ether crossing message, as you put it) as to why I thought your remark was unprofessional, and will be happy to continue that discussion offline with you. My only worry is that when discussing these matters, please don't refer to your MDCR draft. It has been the feeling of several members that you are still promoting this draft. This most likely comes from your using similar arguments or examples as those you used in the MDCR discussion. What I would encourage you to do is to start with specific text from the requirements draft and then frame a discussion around it. Last call is due to end today, 20 February, but in light of the recent volume of postings, what I propose to do (yes, the chair hat is ON) is to encourage EVERYONE to respond to the current threads. I will then collect them and, over the weekend, summarize and declare what we do and don't have consensus on. I will then recommend the next steps for the WG to take on this, the charter, and the URP draft. Albert, I look forward to your positive comments. sincerely, John At 09:20 AM 2/20/2001 +1100, Albert Langer wrote: > >Albert, if you're this convinced that URP does not meet the requirements >document, please elaborate now, rather than later, in a separate thread >(since this one is already so long). Thanks. > > >[Albert] >An excellent request of exactly the sort that I indicated has been lacking >from >WG chairs in a message that crossed in in the ether with this one. So I will >comply with it fully, despite the fact that you have still not withdrawn >your >remark about "unprofessional" comments. I will also take it as an excuse not >to >respond directly to the several specific points you directed towards me in >your >recent messages and concentrate instead on fulfilling the above, as a good >way of starting afresh rather than getting entangled in the various bits and >pieces. I have now said what I think >needed to be said in response to other things and would greatly prefer to >turn to positive technical dialogue as you propose, rather than continuing >on those matters. > >Also I agree with your comment in your other recent message, concerning my >statement: > >"I mention it as an "option" only because it is the current architecture, >not because it >has any technical merit whatever." > > >Statements such as this are not helpful. Please try and comment in a >positive manner. > > >That was a product of my general irritation and I agree it is not helpful. > >I have been up all night and am now going to get some sleep before >responding exactly as you have requested. From owner-ietf-ldup@mail.imc.org Tue Feb 20 21:15:31 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id VAA01920 for ; Tue, 20 Feb 2001 21:15:31 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.9.3/8.9.3) id RAA07372 for ietf-ldup-bks; Tue, 20 Feb 2001 17:31:57 -0800 (PST) Received: from sj-msg-core-2.cisco.com (sj-msg-core-2.cisco.com [171.69.43.88]) by above.proper.com (8.9.3/8.9.3) with ESMTP id RAA07368 for ; Tue, 20 Feb 2001 17:31:55 -0800 (PST) Received: from mira-sjcm-1.cisco.com (mira-sjcm-1.cisco.com [171.69.43.102]) by sj-msg-core-2.cisco.com (8.9.3/8.9.1) with ESMTP id RAA12474; Tue, 20 Feb 2001 17:31:44 -0800 (PST) Received: from JSTRASSN-W2K1.cisco.com (rtp-dial-1-213.cisco.com [10.83.97.213]) by mira-sjcm-1.cisco.com (Mirapoint) with ESMTP id AAE09182; Tue, 20 Feb 2001 17:30:39 -0800 (PST) Message-Id: <4.3.2.7.2.20010220132135.00b80918@mira-sjcm-1.cisco.com> X-Sender: jstrassn@mira-sjcm-1.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Tue, 20 Feb 2001 13:23:30 -0800 To: "Paul Leach" From: John Strassner Subject: RE: WG Last Call on the LDAPv3 Directory Replication I-D Cc: "John Strassner" , "Ed Reed" , , , In-Reply-To: <5B90AD65A9E8934987DB0C8C0762657406005A07@DF-BOWWOW.platinu m.corp.microsoft.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ietf-ldup@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: First, this seems to prove my point. Second, if your system was calling for a hundred updates a minute, and the replication frequency was 15 minutes, you would know by inspection that your system couldn't handle the load. So, if you're still convinced that replication frequency has nothing to do with it, please come up with some other characterization that is better than "we can't support a high rate of updates". John At 09:35 AM 2/20/2001 -0800, Paul Leach wrote: >Very roughly, if there are N replicas, and each can tolerate an update >rate (if it were the only replica) of R, then the total update rate >supportable by the replicated directory would be R/N. > >I do not believe that the replication frequency has much to do with it, >unless a low-ish frequency causes many updates to be transferred per >replication interval and thereby leads to increased efficiency (due to >some batching effect or other). > > > -----Original Message----- > > From: John Strassner [mailto:jstrassn@cisco.com] > > Sent: Tuesday, February 20, 2001 8:21 AM > > To: Ed Reed > > Cc: Albert.Langer@directory-designs.org; Kurt@OpenLDAP.org; > > ietf-ldup@imc.org > > Subject: RE: WG Last Call on the LDAPv3 Directory Replication I-D > > > > > > This seems reasonable, but I would suggest that we quantify > > this, perhaps > > in terms relative to the (average) replication frequency of > > the system. > > Thoughts? > > > > regards, > > John > > > > At 08:41 AM 2/20/2001 -0700, Ed Reed wrote: > > >Hmmm...I've found a point of agreement with Albert ;-)... see [eer] > > > > > >================= > > >Ed Reed > > >Reed-Matthews, Inc. > > >+1 801 796 7065 > > >http://www.Reed-Matthews.COM > > > > > > >>> "Albert Langer" 02/17/01 > > > 01:30PM >>> > > >[Kurt] > > >At 04:39 PM 2/17/01 +1100, Albert Langer wrote: > > > >Put succinctly: LDUP directories won't interoperate. Period. > > > > > >I would say that two LDUP peers could interoperate (from > > >a protocol perspective) but that this, in itself, does > > >not: > > > 1) preserve LDAP/X.500 semantics nor > > > 2) provide "equally capable" replicas. > > > > > >The former issue can not be resolved unless one requires > > >transactional consistency in multiple master replication. > > >The latter issue can be tackled by writing a very tight > > >applicability statements. > > > > > >[Albert] > > > > > >...snip... > > > > > >A necessary consequence of multi-master, as opposed to single master, > > >is that in addition to transient inconsitencies between data > > read from > > >different directory servers there will also be problems with > > data read > > >from a single server. There are 2 options possible for multi-master: > > > > > >1) Conflicting updates to the same entry are prioritized so that only > > >one succeeds and the others are rolled back. That necessarily results > > >in different behaviour to single master directories but is not > > >fundamentally inconsistent with LDAP semantics and does not prevent > > >interoperability. Problems arising can be resolved by users > > rather than > > >sysadmins by notifying them of lost updates (whether due to > > name conflicts > > >or > > >other conflicts). An applicability statement should clearly indicate > > >that multi-master is unsuitable in any situation with a high rate of > > >concurrent changes to the same entries. > > > > > >[eer] I certainly agree that we should make clear (if we have not > > >already), that multi-master is unsuitable in any situation with a > > >high rate (say, frequently faster than the time it takes for a change > > >to fully propagate to all registered replicas) of concurrent changes > > >to the same entries at different master replicas. > > > > > >The "frequently..." qualifier represents my own bias as to what > > >is "reasonable" and might be changed to simply say "faster than...". > > > > > >[/eer] > > From owner-ietf-ldup@mail.imc.org Tue Feb 20 21:48:32 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id VAA03033 for ; Tue, 20 Feb 2001 21:48:32 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.9.3/8.9.3) id SAA08576 for ietf-ldup-bks; Tue, 20 Feb 2001 18:07:56 -0800 (PST) Received: from ns.oncalldba.com ([66.1.184.87]) by above.proper.com (8.9.3/8.9.3) with ESMTP id SAA08572 for ; Tue, 20 Feb 2001 18:07:55 -0800 (PST) Received: from reed.oncalldba.com (reed.OnCallDBA.COM [192.168.1.3]) by ns.oncalldba.com (8.11.0/8.8.7) with SMTP id f1L27Iw25410 for ; Tue, 20 Feb 2001 19:07:18 -0700 Received: from RMINC_DOM-Message_Server by reed.oncalldba.com with Novell_GroupWise; Tue, 20 Feb 2001 19:01:43 -0700 Message-Id: X-Mailer: Novell GroupWise Internet Agent 5.5.2.1 Date: Tue, 20 Feb 2001 19:01:27 -0700 From: "Ed Reed" To: , , Cc: , Subject: RE: WG Last Call on the LDAPv3 Directory Replication I-D - applications doing locking Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Disposition: inline Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id SAA08573 Sender: owner-ietf-ldup@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 8bit This anecdote is not intended to make any important points, but instead to merely relate a particularly - how shall I say it? - perverse example of the law of unintended consequences. ============================== >>> "Paul Leach" 02/19/01 06:50PM >>> > -----Original Message----- > From: John Strassner [mailto:jstrassn@cisco.com] > Sent: Monday, February 19, 2001 10:27 AM > To: Albert.Langer@directory-designs.org > Cc: Kurt D. Zeilenga; ietf-ldup@imc.org > Subject: RE: WG Last Call on the LDAPv3 Directory Replication I-D > > > Not true. First, applications can certainly build locking and other > mechanisms to isolate operations affecting an update. Huh? The application instances could be operating on different replicas, so will never even see the "locking" operations of the other. They will proceed as if they were isolated, and then their updates will clash laters. When the attributes being modified overlap partially but not completely, neither one of them will get a consistent set. [eer] Worse than that - we've seen applications using client libraries that were "overly agressive" when it came to load balancing across replicas, and sometimes consecutive operations from the same application thread would wind up going against different directory servers. Pathological, I'll admit, but just an example of the kind of trouble you can get into. In this case, the client library (not an LDAP one, but the native client for NDS at the time) handled all connection setup, authentication, cacheing and teardown for applications to "preserve the location independence" of the data in the directory. A worthy objective, but one that is not meaningfull when that client issued "create user" to one directory and "create file system directory for user" to a file server on a different machine. The second create would fail until the first create propagated via directory synchronization to the second server...utterly mysterious to the poor application developer who just wanted to create a home directory for the user. Note that in this example there were NOT two directory operations issued by the application, but rather a directory operation (the first create of the user) and a file service operation whose side effect was to check the validity of the user who would own the file directory to be created. The file system's resource ownership integrity logic issued a directory operation (what's the user id of this user?) before the user creation had occured at the directory replica coresident with the file system (to which the file system was told to talk when needing directory information like user ids). The details of why the problem occured are wrapped up in the specific implementation details of NDS and the NetWare file service, but they illustrate these points: race conditions are made worse by loose consistincy replication race conditions may occur as a result of side effects, not just by the primary actions of a single application nor even by the random operations of two independent operators to help avoid race conditions, try to make sequential operations against a single server, at least until changes propagate to the other servers you would use (and use client libraries that either follow that behaviour for all the applications operations and for the actions that will likely generate third party side-effects) In this instance, the directory was not "at fault", but rather the overly-helpful client libraries, optimized to spread queries against multiple servers, didn't provide the degree of connection management needed by the application who had "special" needs. Library developers take heed! (Actually, all the LDAP libraries I know leave connection management to the application, so they're not likely to suffer this same problem, but the potential effects of side effects in the chain of events is a problem). [/eer] ================= Ed Reed Reed-Matthews, Inc. +1 801 796 7065 http://www.Reed-Matthews.COM From owner-ietf-ldup@mail.imc.org Tue Feb 20 22:35:52 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id WAA04443 for ; Tue, 20 Feb 2001 22:35:52 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.9.3/8.9.3) id TAA09909 for ietf-ldup-bks; Tue, 20 Feb 2001 19:02:37 -0800 (PST) Received: from DF-INET-1.dogfoodinternet.com (df-inet1.exchange.microsoft.com [131.107.8.8]) by above.proper.com (8.9.3/8.9.3) with ESMTP id TAA09905 for ; Tue, 20 Feb 2001 19:02:36 -0800 (PST) Received: from df-virus2.platinum.corp.microsoft.com ([172.30.236.33]) by DF-INET-1.dogfoodinternet.com with Microsoft SMTPSVC(5.0.2195.2831); Tue, 20 Feb 2001 19:02:15 -0800 Received: from 172.30.236.11 by df-virus2.platinum.corp.microsoft.com (InterScan E-Mail VirusWall NT); Tue, 20 Feb 2001 19:01:22 -0800 (Pacific Standard Time) Received: from DF-MAX.platinum.corp.microsoft.com ([172.30.236.101]) by yuri.dns.microsoft.com with Microsoft SMTPSVC(5.0.2195.2831); Tue, 20 Feb 2001 19:01:22 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.0.4648.0 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: several counts (Was: WG Last Call on the LDAPv3 Directory Replication I-D) Date: Tue, 20 Feb 2001 19:01:22 -0800 Message-ID: <5B90AD65A9E8934987DB0C8C0762657493DDEE@DF-BOWWOW.platinum.corp.microsoft.com> Thread-Topic: several counts (Was: WG Last Call on the LDAPv3 Directory Replication I-D) thread-index: AcCbqCS5XYLaoFWNScaIO2ndleRFGQAB56zw From: "Mark Brown (REDMOND)" To: "John Strassner" , "Paul Leach" Cc: "Kurt D. Zeilenga" , X-OriginalArrivalTime: 21 Feb 2001 03:01:22.0692 (UTC) FILETIME=[92460440:01C09BB2] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id TAA09906 Sender: owner-ietf-ldup@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 8bit If the concept of "passive data" becomes one of the characteristics that defines when it is OK for two LDAP directory servers to replicate via LDUP, then directory implementors will be forced to pay attention to the concept. The guarantee that "passive data" won't abuptly turn to "active data" will be made by the directory implementor. If the directory implementor lies, and LDUP replication causes security or corruption problems as a result, the directory implementor will be in hot water with the person who bought his server. Similarly, if some attribute is passive in one DS and active in another, then clearly the two shouldn't replicate via LDUP. We require some way to characterize what directories can sensibly replicate and what directories can not. "Passive data" (or "userApplication") is a well-defined proposal. If you have a better proposal you should make it, but we need some characterization because the requirement is not going away. --mark -----Original Message----- From: John Strassner [mailto:jstrassn@cisco.com] Sent: Tuesday, February 20, 2001 2:47 PM To: Paul Leach Cc: Kurt D. Zeilenga; John Strassner; ietf-ldup@imc.org Subject: RE: several counts (Was: WG Last Call on the LDAPv3 Directory Replication I-D) Thanks for providing a better definition, but I still don't see how we can use this one. There's no guarantee, for instance, that what is at one moment in time "passive" data won't change to "active data" soon thereafter. This means that the data can't be consistently nor deterministically characterized as either "passive" or "active". Plus, data of a particular type or use may be active in one replica and passive in another. There are yet more variations that we could consider, but I think that these are plenty for now. If you can solve these and related problems, please respond. Otherwise, let's just drop the use of the term. thanks, John At 02:19 AM 2/20/2001 -0800, Paul Leach wrote: > > -----Original Message----- > > From: Kurt D. Zeilenga [mailto:Kurt@OpenLDAP.org] > > Sent: Monday, February 19, 2001 3:03 PM > > To: John Strassner > > Cc: ietf-ldup@imc.org > > Subject: Re: several counts (Was: WG Last Call on the LDAPv3 Directory > > Replication I-D) > > > > >Second, please stop using the term "passive data" as no one > > on this list has defined it in an unambiguous and > > satisfactory manner. It is impossible to consider using LDUP > > in this fashion until a definition for this term that we can > > all agree with is offered and agreed to. > > > > I agree. I believe we should use the term "userApplication" > > attribute. > > This is well defined. > >Well, I used "passive data" recently, and I don't know if >"userApplication" is at all related. > >What I mean by "passive data" is this: An attribute may be said to be >"passive data" when >a write to the attribute followed by a read of the same attribute >returns exactly the data written, and no other attribute's value is >affected. > >An attribute that is not "passive data" is "active data". A directory >may be LDAP compliant and still contain active data. Two different >directory implementations may therefore be LDAP compliant yet implement >different forms of active data (different attributes may be active, for >example). However, issues have been raised about the ability to >replicate active data, between directories that implement their active >data differently, and hence on the viability of the requirement that >LDUP be able to replicate any LDAP compliant directory. From owner-ietf-ldup@mail.imc.org Tue Feb 20 22:45:04 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id WAA04663 for ; Tue, 20 Feb 2001 22:45:03 -0500 (EST) Received: by above.proper.com (8.9.3/8.9.3) id TAA10069 for ietf-ldup-bks; Tue, 20 Feb 2001 19:11:44 -0800 (PST) Received: from DF-INET-1.dogfoodinternet.com (df-inet1.exchange.microsoft.com [131.107.8.8]) by above.proper.com (8.9.3/8.9.3) with ESMTP id TAA10065 for ; Tue, 20 Feb 2001 19:11:44 -0800 (PST) Received: from df-virus2.platinum.corp.microsoft.com ([172.30.236.33]) by DF-INET-1.dogfoodinternet.com with Microsoft SMTPSVC(5.0.2195.2831); Tue, 20 Feb 2001 19:10:34 -0800 Received: from 172.30.236.11 by df-virus2.platinum.corp.microsoft.com (InterScan E-Mail VirusWall NT); Tue, 20 Feb 2001 19:09:41 -0800 (Pacific Standard Time) Received: from DF-MAX.platinum.corp.microsoft.com ([172.30.236.101]) by yuri.dns.microsoft.com with Microsoft SMTPSVC(5.0.2195.2831); Tue, 20 Feb 2001 19:09:41 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.0.4648.0 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: several counts (Was: WG Last Call on the LDAPv3 Directory Replication I-D) Date: Tue, 20 Feb 2001 19:09:40 -0800 Message-ID: <5B90AD65A9E8934987DB0C8C0762657447310D@DF-BOWWOW.platinum.corp.microsoft.com> Thread-Topic: several counts (Was: WG Last Call on the LDAPv3 Directory Replication I-D) thread-index: AcCbpyWEAI99VcXMQz2R+kwrScuQCgACzo3A From: "Paul Leach" To: "John Strassner" Cc: "Kurt D. Zeilenga" , X-OriginalArrivalTime: 21 Feb 2001 03:09:41.0107 (UTC) FILETIME=[BB5A1C30:01C09BB3] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id TAA10066 Sender: owner-ietf-ldup@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 8bit > -----Original Message----- > From: John Strassner [mailto:jstrassn@cisco.com] > Sent: Tuesday, February 20, 2001 2:47 PM > To: Paul Leach > Cc: Kurt D. Zeilenga; John Strassner; ietf-ldup@imc.org > Subject: RE: several counts (Was: WG Last Call on the LDAPv3 Directory > Replication I-D) > > > Thanks for providing a better definition, but I still don't > see how we can > use this one. I don't suggest that anyone use it in the standard. However, I think its a lot more suggestive of its meaning than "userApplication" and "operational". > There's no guarantee, for instance, that what is at one > moment in time "passive" data won't change to "active data" soon > thereafter. > This means that the data can't be consistently nor > deterministically characterized as either "passive" or > "active". And then why don't "userApplication" and "operational" suffer from the same problem? Kurt assures me they are the same thing. > Plus, data > of a particular type or use may be active in one replica and > passive in > another. Exactly why they won't interop, and why the requirements should say they aren't expected to. > There are yet more variations that we could > consider, but I think > that these are plenty for now. If Kurt is correct, and all I've done is invent new terms that match existing ones, then this is just FUD. And we've got all those problems you mention anyway. Paul From owner-ietf-ldup@mail.imc.org Tue Feb 20 22:58:29 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id WAA04784 for ; Tue, 20 Feb 2001 22:58:29 -0500 (EST) Received: by above.proper.com (8.9.3/8.9.3) id TAA10682 for ietf-ldup-bks; Tue, 20 Feb 2001 19:27:17 -0800 (PST) Received: from pretender.boolean.net (root@router.boolean.net [198.144.206.49]) by above.proper.com (8.9.3/8.9.3) with ESMTP id TAA10678 for ; Tue, 20 Feb 2001 19:27:16 -0800 (PST) Received: from gypsy.OpenLDAP.org (gypsy.boolean.net [10.192.1.2]) by pretender.boolean.net (8.11.1/8.11.1/Boolean/Hub) with ESMTP id f1L3QTD23448; Wed, 21 Feb 2001 03:26:29 GMT (envelope-from Kurt@OpenLDAP.org) Message-Id: <5.0.2.1.0.20010220191924.00ab1d90@router.boolean.net> X-Sender: guru@router.boolean.net X-Mailer: QUALCOMM Windows Eudora Version 5.0.2 Date: Tue, 20 Feb 2001 19:26:27 -0800 To: "Paul Leach" From: "Kurt D. Zeilenga" Subject: RE: several counts (Was: WG Last Call on the LDAPv3 Directory Replication I-D) Cc: "John Strassner" , In-Reply-To: <5B90AD65A9E8934987DB0C8C0762657447310D@DF-BOWWOW.platinum. corp.microsoft.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 07:09 PM 2/20/01 -0800, Paul Leach wrote: >> There are yet more variations that we could >> consider, but I think >> that these are plenty for now. > >If Kurt is correct, and all I've done is invent new terms that match >existing ones, then this is just FUD. And we've got all those problems >you mention anyway. Well, I don't think you are using the terms "active" and "passive" in a manner 100% synonmous with "userApplications" and "operational". From your prior posts, you seem to imply that some user application attributes could be "active". This does fit into the X.500 data model well. Hence, my comment that you apparently were try to describe something which is "experimental" in nature. I don't see why LDUP requirements need to say that some yet to be specified extension to the LDAP data model need not be supported. Kurt From owner-ietf-ldup@mail.imc.org Tue Feb 20 23:23:54 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id XAA05018 for ; Tue, 20 Feb 2001 23:23:54 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.9.3/8.9.3) id TAA11076 for ietf-ldup-bks; Tue, 20 Feb 2001 19:51:56 -0800 (PST) Received: from myrealbox.com (mail.myrealbox.com [192.108.102.201]) by above.proper.com (8.9.3/8.9.3) with ESMTP id TAA11072 for ; Tue, 20 Feb 2001 19:51:54 -0800 (PST) Received: from [192.168.1.209] [64.50.112.2] by myrealbox.com with Novonyx SMTP Server $Revision: 2.76 $; Tue, 20 Feb 2001 20:49:56 -0700 (MDT) User-Agent: Microsoft-Entourage/9.0.2509 Date: Tue, 20 Feb 2001 19:51:12 -0800 Subject: Re: WG Last Call on the LDAPv3 Directory Replication I-D From: Jerry Combs To: John Strassner , Paul Leach CC: , "Kurt D. Zeilenga" , Message-ID: In-Reply-To: <4.3.2.7.2.20010220143508.01fe33c0@mira-sjcm-1.cisco.com> Mime-version: 1.0 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 think the following item should be removed from the requirements doc. >>>P6. The protocol MUST support propagation of atomicity information. The point of replication is the convergence of the committed state of the object on that particular replica. Atomicity allows an application resolve discrepancies at the time of the modification according to logic that is inherently application dependent. Once the modification is committed to a specific replica, the directory should only be responsible for replicating the resulting committed state of the object. If there are changes to the object on multiple replicas the replication mechanism should be responsible for resolving the differences in state...it should not be responsible for application level transaction integrity. As an example, suppose you have a replica with a replication interval of 5 minutes. On this replica you modify an attribute 10 times during the 5 minute interval. When it is time to begin the replication the attribute has a specific state. Should all ten "transactions" be replicated or should only the current state be replicated? I contend that the replication mechanism should only guarantee the replication of the current state. This reduces the amount of replication traffic dramatically. Note that attributes that are high priority could be replicated immediately and would therefore replicate each state change. Both methods should supported. If you accept that in a directory replication of state and not replication of modification sequence is acceptable then you must agree that propagation of atomicity is impossible. Applications should be designed to deal with state and not modification sequence. If a record of modification sequence is needed it can be maintained separately as a log, audit database, etc. This can work, even for the Provisioning application that someone mentioned because I've just finished writing such an application. JC On 2/20/01 2:36 PM, "John Strassner" wrote: > I don't understand your "Huh?", as the application instances could just as > easily be operating on the same replica, or one could build a more robust > system that front-ends the replicas and handles conflicts there. > > John > > At 05:50 PM 2/19/2001 -0800, Paul Leach wrote: > > >>> -----Original Message----- >>> From: John Strassner [mailto:jstrassn@cisco.com] >>> Sent: Monday, February 19, 2001 10:27 AM >>> To: Albert.Langer@directory-designs.org >>> Cc: Kurt D. Zeilenga; ietf-ldup@imc.org >>> Subject: RE: WG Last Call on the LDAPv3 Directory Replication I-D >>> >>> >>> Not true. First, applications can certainly build locking and other >>> mechanisms to isolate operations affecting an update. >> >> Huh? The application instances could be operating on different replicas, >> so will never even see the "locking" operations of the other. They will >> proceed as if they were isolated, and then their updates will clash >> laters. When the attributes being modified overlap partially but not >> completely, neither one of them will get a consistent set. > > From owner-ietf-ldup@mail.imc.org Tue Feb 20 23:28:02 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id XAA05048 for ; Tue, 20 Feb 2001 23:28:02 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.9.3/8.9.3) id TAA11180 for ietf-ldup-bks; Tue, 20 Feb 2001 19:56:30 -0800 (PST) Received: from myrealbox.com (mail.myrealbox.com [192.108.102.201]) by above.proper.com (8.9.3/8.9.3) with ESMTP id TAA11176 for ; Tue, 20 Feb 2001 19:56:30 -0800 (PST) Received: from [192.168.1.209] [64.50.112.2] by myrealbox.com with Novonyx SMTP Server $Revision: 2.76 $; Tue, 20 Feb 2001 20:54:28 -0700 (MDT) User-Agent: Microsoft-Entourage/9.0.2509 Date: Tue, 20 Feb 2001 19:55:48 -0800 Subject: Re: WG Last Call on the LDAPv3 Directory Replication I-D - applications doing locking From: Jerry Combs To: Ed Reed , , , CC: , Message-ID: In-Reply-To: Mime-version: 1.0 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 This makes my point that only the commit to a specific replica should be atomic. Anything beyond that must be the responsibility of the application. JC On 2/20/01 6:01 PM, "Ed Reed" wrote: > This anecdote is not intended to make any important points, but > instead to merely relate a particularly - how shall I say it? - perverse > example of the law of unintended consequences. > ============================== >>>> "Paul Leach" 02/19/01 06:50PM >>> > > >> -----Original Message----- >> From: John Strassner [mailto:jstrassn@cisco.com] >> Sent: Monday, February 19, 2001 10:27 AM >> To: Albert.Langer@directory-designs.org >> Cc: Kurt D. Zeilenga; ietf-ldup@imc.org >> Subject: RE: WG Last Call on the LDAPv3 Directory Replication I-D >> >> >> Not true. First, applications can certainly build locking and other >> mechanisms to isolate operations affecting an update. > > Huh? The application instances could be operating on different replicas, > so will never even see the "locking" operations of the other. They will > proceed as if they were isolated, and then their updates will clash > laters. When the attributes being modified overlap partially but not > completely, neither one of them will get a consistent set. > > [eer] > Worse than that - we've seen applications using client libraries that were > "overly agressive" when it came to load balancing across replicas, and > sometimes consecutive operations from the same application thread > would wind up going against different directory servers. Pathological, > I'll admit, but just an example of the kind of trouble you can get into. > > In this case, the client library (not an LDAP one, but the native client > for NDS at the time) handled all connection setup, authentication, cacheing > and teardown for applications to "preserve the location independence" > of the data in the directory. A worthy objective, but one that is not > meaningfull when that client issued "create user" to one directory and > "create file system directory for user" to a file server on a different > machine. The second create would fail until the first create propagated > via directory synchronization to the second server...utterly mysterious > to the poor application developer who just wanted to create a home > directory for the user. > > Note that in this example there were NOT two directory operations > issued by the application, but rather a directory operation (the first > create of the user) and a file service operation whose side effect > was to check the validity of the user who would own the file directory > to be created. The file system's resource ownership integrity logic > issued a directory operation (what's the user id of this user?) before > the user creation had occured at the directory replica coresident > with the file system (to which the file system was told to talk when > needing directory information like user ids). > > The details of why the problem occured are wrapped up in the > specific implementation details of NDS and the NetWare file service, > but they illustrate these points: > > race conditions are made worse by loose consistincy replication > race conditions may occur as a result of side effects, not just by > the primary actions of a single application nor even by the > random operations of two independent operators > to help avoid race conditions, try to make sequential operations > against a single server, at least until changes propagate to > the other servers you would use (and use client libraries > that either follow that behaviour for all the applications > operations and for the actions that will likely generate > third party side-effects) > > In this instance, the directory was not "at fault", but rather the > overly-helpful client libraries, optimized to spread queries against > multiple servers, didn't provide the degree of connection management > needed by the application who had "special" needs. > > Library developers take heed! (Actually, all the LDAP libraries > I know leave connection management to the application, so they're > not likely to suffer this same problem, but the potential effects of > side effects in the chain of events is a problem). > > [/eer] > > > > > ================= > Ed Reed > Reed-Matthews, Inc. > +1 801 796 7065 > http://www.Reed-Matthews.COM > From owner-ietf-ldup@mail.imc.org Tue Feb 20 23:46:43 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id XAA05633 for ; Tue, 20 Feb 2001 23:46:42 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.9.3/8.9.3) id UAA11627 for ietf-ldup-bks; Tue, 20 Feb 2001 20:11:18 -0800 (PST) Received: from myrealbox.com (mail.myrealbox.com [192.108.102.201]) by above.proper.com (8.9.3/8.9.3) with ESMTP id UAA11623 for ; Tue, 20 Feb 2001 20:11:15 -0800 (PST) Received: from [192.168.1.209] [64.50.112.2] by myrealbox.com with Novonyx SMTP Server $Revision: 2.76 $; Tue, 20 Feb 2001 21:09:15 -0700 (MDT) User-Agent: Microsoft-Entourage/9.0.2509 Date: Tue, 20 Feb 2001 20:10:44 -0800 Subject: Re: several counts (Was: WG Last Call on the LDAPv3 Directory Replication I-D) From: Jerry Combs To: "Mark Brown (REDMOND)" , John Strassner , Paul Leach CC: "Kurt D. Zeilenga" , Message-ID: In-Reply-To: <5B90AD65A9E8934987DB0C8C0762657493DDEE@DF-BOWWOW.platinum.corp.microsoft.com> Mime-version: 1.0 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 In most implementations there are no attributes that meet your definition of "passive". Any write normally results in changes to operational attributes such as modificationTimeStamp or lastModifiedBy. I fail to see the value of the distinction between "active" and "passive" data. On 2/20/01 7:01 PM, "Mark Brown (REDMOND)" wrote: > If the concept of "passive data" becomes one of the > characteristics that defines when it is OK for two > LDAP directory servers to replicate via LDUP, then > directory implementors will be forced to pay attention > to the concept. The guarantee that "passive data" won't > abuptly turn to "active data" will be made by the directory > implementor. If the directory implementor lies, and > LDUP replication causes security or corruption problems > as a result, the directory implementor will be in hot > water with the person who bought his server. > > Similarly, if some attribute is passive in one DS > and active in another, then clearly the two shouldn't > replicate via LDUP. > > We require some way to characterize what directories > can sensibly replicate and what directories can not. > "Passive data" (or "userApplication") is a well-defined > proposal. If you have a better proposal you should > make it, but we need some characterization because the > requirement is not going away. > > --mark > > -----Original Message----- > From: John Strassner [mailto:jstrassn@cisco.com] > Sent: Tuesday, February 20, 2001 2:47 PM > To: Paul Leach > Cc: Kurt D. Zeilenga; John Strassner; ietf-ldup@imc.org > Subject: RE: several counts (Was: WG Last Call on the LDAPv3 Directory > Replication I-D) > > > Thanks for providing a better definition, but I still don't see how we > can > use this one. There's no guarantee, for instance, that what is at one > moment in time "passive" data won't change to "active data" soon > thereafter. This means that the data can't be consistently nor > deterministically characterized as either "passive" or "active". Plus, > data > of a particular type or use may be active in one replica and passive in > another. There are yet more variations that we could consider, but I > think > that these are plenty for now. > > If you can solve these and related problems, please respond. Otherwise, > let's just drop the use of the term. > > thanks, > John > > At 02:19 AM 2/20/2001 -0800, Paul Leach wrote: > > >>> -----Original Message----- >>> From: Kurt D. Zeilenga [mailto:Kurt@OpenLDAP.org] >>> Sent: Monday, February 19, 2001 3:03 PM >>> To: John Strassner >>> Cc: ietf-ldup@imc.org >>> Subject: Re: several counts (Was: WG Last Call on the LDAPv3 > Directory >>> Replication I-D) >>> >>>> Second, please stop using the term "passive data" as no one >>> on this list has defined it in an unambiguous and >>> satisfactory manner. It is impossible to consider using LDUP >>> in this fashion until a definition for this term that we can >>> all agree with is offered and agreed to. >>> >>> I agree. I believe we should use the term "userApplication" >>> attribute. >>> This is well defined. >> >> Well, I used "passive data" recently, and I don't know if >> "userApplication" is at all related. >> >> What I mean by "passive data" is this: An attribute may be said to be >> "passive data" when >> a write to the attribute followed by a read of the same attribute >> returns exactly the data written, and no other attribute's value is >> affected. >> >> An attribute that is not "passive data" is "active data". A directory >> may be LDAP compliant and still contain active data. Two different >> directory implementations may therefore be LDAP compliant yet implement >> different forms of active data (different attributes may be active, for >> example). However, issues have been raised about the ability to >> replicate active data, between directories that implement their active >> data differently, and hence on the viability of the requirement that >> LDUP be able to replicate any LDAP compliant directory. > > From owner-ietf-ldup@mail.imc.org Wed Feb 21 03:23:26 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id DAA20759 for ; Wed, 21 Feb 2001 03:23:25 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.9.3/8.9.3) id XAA16204 for ietf-ldup-bks; Tue, 20 Feb 2001 23:07:12 -0800 (PST) Received: from relay1.pair.com (relay1.pair.com [209.68.1.20]) by above.proper.com (8.9.3/8.9.3) with SMTP id XAA16185 for ; Tue, 20 Feb 2001 23:07:08 -0800 (PST) Received: (qmail 24534 invoked from network); 21 Feb 2001 07:06:33 -0000 Received: from cpe-144-132-70-18.vic.bigpond.net.au (HELO w98) (144.132.70.18) by relay1.pair.com with SMTP; 21 Feb 2001 07:06:33 -0000 X-pair-Authenticated: 144.132.70.18 Reply-To: From: "Albert Langer" To: "'Ed Reed'" , Cc: Subject: RE: WG Last Call on the LDAPv3 Directory Replication I-D Date: Wed, 21 Feb 2001 18:09:42 +1100 Message-ID: <000801c09bd5$43f5dea0$6628a8c0@nowhere.com> 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 CWS, Build 9.0.2416 (9.0.2910.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Importance: Normal In-Reply-To: Sender: owner-ietf-ldup@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit [Ed] Ahh - the crux of the matter... [Albert] Agreed. I am still working on meeting John's request for an elaboration on why I say the URP (and architecture) drafts do not comply with the requirements draft (and will not finish today). I am therefore postponing replies to the many other issues John has since directed towards me. However your message does go to the crux of the matter as far as I am concerned, so I'm taking time off to respond and I hope the reply below will be helpful as background for meeting John's request as well. (Though I hope you have also noticed - as Paul just remarked and Chris, John and Patrik are bound to eventually notice too, that there are *many* people with *many* concerns about *various* different matters and Pandora's box is now well and truly open. That means LDUP WG is now actually *functioning*, which is great!) ================= Ed Reed Reed-Matthews, Inc. +1 801 796 7065 http://www.Reed-Matthews.COM >>> "Albert Langer" 02/17/01 04:59PM >>> [snip] My view is that the critically important requirement that applications depend on is simply that a change can be reliably made to exactly the entry you thought you were changing and not result in some mixture of updates combined with unknown concurrent changes by some other application. [eer] My view is exactly, precisely, and PROFOUNDLY the oposite - that it is critically important that changes to different attributes made at the "same time" to the same entry at two different master replicas MUST interleave and both be preserved. That, in fact, the expected (by reasonable application users sharing information for multiple applications using LDUP replication to facilitate locally improved performance and availability of directory content for those applications) behavior is atomic at the attribute level (if, indeed, not at the attribute-value level) for each attribute being changed. This is, of course, the administration application of the directory as a distributed nameservice for which vendors like Microsoft, Novell, and Lotus use directories. [Albert] Our views are indeed opposite. However your explanation of your view below, together with your agreement in another message that multi-master is inherently unsuitable for situations with a high rate of concurrent changes to the same entry (with the meaning of "high" to be specified), suggests to me that there is more common ground than might be thought. I agree with your assumption above that the dominant application for multi-master is "to facilitate locally improved performance and availability of directory content [...]". Incidentally I do not believe that is brought out clearly enough in the usage examples given in the requirements draft. Locally improved performance and availability is the driving force behind multi-master. There are other means of distributing the directory and other means of providing high availability. But there is no other means of providing locally available changeable copies. Changes made to a particular local DSA need to be immediately available within the local area serviced by that DSA, regardless of replication schedules, connectivity etc. At the same time changes made within the local area need to be replicated as information available to other local areas and conversely and it must be possible for one local DSA to smoothly takeover the local area normally serviced by another that has failed without much delay and additional complexity and costs for fully transactional database replication. All local DSAs therefore need to be able to support both reads and writes about data that needs to be immediately changeable in other local areas as well as in their own. Data about the organization as a whole needs to be available everywhere and often changeable everywhere. There may also of course be multiple "local" DSAs with load sharing and the organization may be partitioned in various ways including separate "central" partitions. That is a common situation in which multi-master is applicable and useful and where what it offers can provide benefits not available from single master with failover. In that situation one can: a) Expect a reasonably low rate of concurrent changes to attributes and attribute values of a single entry. That is because changes are predominantly (though not exclusively) being made locally to the local DSA (or it's replacement on failure) and are therefore largely, though not entirely serialized as though in single master mode. (Provided of course that one isn't using Novell client libraries with load sharing ;-) b) Expect that applications are generally changing attributes of an entry that are largely independent of each other but simply share a common name tying together a loose bundle of properties (several hundred in some deployed multi-master DSAs for enterprise LAN/WAN "single sign on" directory applications). Thus the large majority of users of multi-master view directory data with a granularity of an attribute rather than an entry, and are not particularly interested in any form of "locking" while making related changes to different attributes of a single entry. As your recent anecdote illustrated, problems are just as likely to arise from writing and reading from different load sharing servers. Now I'm going to get less agreeable below. Could you please pause before reading on, to check the above carefully to confirm that I do have a reasonable appreciation of where you are coming from. If not, I need to know what I have misunderstood because only you can actually *know* where you are coming from and I have to get it right when arguing with you. I don't expect you to agree with what comes below but I'd really hope that if you do confirm that first, a natural assumption that my disagreement below arises from "just not getting the practical realities" could be less likely. PAUSE HERE (CHECK ABOVE ;-) **************************************************************************** ********** **************************************************************************** ********** Ok, well I hope you paused... and I hope I got it right. What follows as a logical necessity from any attempt to meet the actual, real world requirements for multi-master is that concurrent changes to the same entry by different DUAs *will* occur. That is a logical necessity from the very definition of multi-master - the DSAs do not contact each other before processing changes from DUAs (that is the means they use - in order to satisfy the need for "locally improved performance and availability"). Now you describe that logical necessity "that changes to different attributes made at the 'same time' to the same entry at two different master replicas MUST interleave" as a "critical requirement" and add "both must be preserved". Three subtle shifts have occurred in that one sentence: 1) You have turned a necessity in order to meet a requirement ("locally improved performance and availability") into a requirement - and indeed a "critical requirement". 2) You have focussed only on changes to *unrelated* attributes, when in fact exactly the same phenomena occurs for: a) Changes to different values of a single attribute. b) Changes to related attribute values, including RDN name components. 3) You have added "both must be preserved" as though it follows logically from the necessity that they MUST interleave, when in fact this is clearly impossible for case b) and therefore cannot be a logical necessity in other cases. I agree with Paul's response: "I view this as an unfortunate side effect of the ability to independently change one replica even when others are not accessible, not as a requirement." My own words in MDCR were: The goals of Multi-Master replication are high availability and local availability of changeable copies. Occasional concurrent changes to the same entry are not a goal but an unavoidable consequence. You have adopted preservation of concurrent changes as a goal and the architecture and URP are designed to meet that goal. They meet it very simply, for the case of changes to different attributes of an entry, by just accepting *both* changes. However: 1. Different attributes are not always independent attributes. According to Alison's consistency summary, URP will even cheerfully delete a component from an RDN that has two components at each of two different DSAs and leave the entry with no name. But is that really a "critical requirement"? You really need to explain why both deletions MUST be preserved. The only relevant requirement I can see is the one in the current draft - that information about what happened must be preserved so somebody can FIX the mess. 2. They do exactly the same thing for different values of a single attribute, including ldapACI attribute values which are highly dependent. You really need to explain *precisely* how an access control model like the one in the current LDAP-EXT draft is supposed to work with your architecture. Because it really IS a "critical requirement" that a multi-master standard be able to support standardized access controls. This is a requirements discussion as part of a final call on a requirements draft, which does not contain *your* goal, on which the architecture and URP have been designed, at all. You need to explain *why* we should try to meet *your* goal, and why we should do so at the expense of other goals, including conformance to LDAP standards relied on by other standards track WGs developing other proposals. You have not done so in the message below and have just gone ahead and designed an architecture without actually getting a signoff on the goals first. [EER] That there is no practical way to utter the request "change attribute A to have value 'alpha' if and only if attribute B has exactly the value 'beta'" using LDAP and X.500 absent locking mechanisms (theoretical discussions to the contrary being considerably outside the scope of "normal and customary" usage to be expected of application developers). [Albert] What you describe, with increasing sarcasm and vehemence below, happens to be *precisely* the semantics elaborately prescribed for the LDAP "Modify Operation" in section 4.6 of LADPv3, RFC 2251. That RFC is not a "theoretical discussion" and it has nothing to do with "normal and customary" usage to be expected of application developers. It is a mandatory requirement of a standards track IETF protocol which imposes certain obligations on DSA implementations claiming to conform to LDAP. IETF standardizes internet protocols, not application development. I do not share the contempt for those semantics which you display below. On the contrary, despite its apparant "complication" of LDAP, I regard it as a *classic* example of the IETF talent for standardizing "lightweight" protocols that actually get implemented in the real world, doing just enough, and no more than, what is required to ensure they meet global internet rather than "enterprise" or "vendor" or "academic" requirements. Application developers are of course free to ignore the precise modify, semantics and for many purposes are right to do so. Only applications that need a high level of data integrity need to use it. (Applications that need an even higher level should not use the directory at all but fully transactional DBMS implementations). Likewise deployments are free to combine ridiculously large numbers of attributes under a single entry rather than respecting the natural granularity of the directory as being entries. What the standard requires is simply that DSAs observe certain very minimal rules to ensure that the *various* different applications for LDAP directories can *interoperate* using a standard client server protocol instead of having to figure out what the particular server will or will not do in a particular situation and thus limiting the applications that can be deployed *globally* on the internet to whatever happens to have been thought useful by a particular implementor. I suspect the hardest part of the original LDAP standardization work was coming up with that simplification of the X.500 standard for modify operations in a way that provided the necessary interoperability without implementors having to cope with all the cruft in the corresponding X.511 section 11.3. [EER] That distributed databases of whatever nature which support such things do so outside the scope of what can reasonably considered "LDAP". And that LDUP is not appropriate for preserving such locking semantics, and is not intended to be. [Albert] Single master LDAP is and always has been a *distributed* database intended to become part of a scalable global directory service. The IETF doesn't do much standardization work on things that aren't distributed. Its primary concern is with global scalability, not "enterprise" level. It has a solid reputation for trying to keep protocols as "light" as possible by stripping out of them *anything* that can not be demonstrated to be *necessary*. LDAP is widely considered an excellent example of that philosophy. Here is the relevant text from 4.6: - modification: A list of modifications to be performed on the entry. The entire list of entry modifications MUST be performed in the order they are listed, as a single atomic operation. While individual modifications may violate the directory schema, the resulting entry after the entire list of modifications is performed MUST conform to the requirements of the directory schema. The values that may be taken on by the 'operation' field in each modification construct have the following semantics respectively: add: add values listed to the given attribute, creating the attribute if necessary; delete: delete values listed from the given attribute, removing the entire attribute if no values are listed, or if all current values of the attribute are listed for deletion; replace: replace all existing values of the given attribute with the new values listed, creating the attribute if it did not already exist. A replace with no value will delete the entire attribute if it exists, and is ignored if the attribute does not exist. [...] The server will return to the client a single Modify Response indicating either the successful completion of the DIT modification, or the reason that the modification failed. Note that due to the requirement for atomicity in applying the list of modifications in the Modify Request, the client may expect that no modifications of the DIT have been performed if the Modify Response received indicates any sort of error, and that all requested modifications have been performed if the Modify Response indicates successful completion of the Modify Operation. If the connection fails, whether the modification occurred or not is indeterminate. This elaborate provision would be completely unecessary if all that was needed for LDAP interoperability was "add any values that aren't already there, delete any values that are". It adds something quite different and significantly more complex - do each requested part of the change in the exact order requested and fail the entire operation, leaving the entry unchanged, if any one of them fails. It wouldn't be there if a formal determination had not been made by a WG charged with that responsibility, and that takes its responsibilities seriously, that this feature is *necessary* and if that determination had not withstood scrutiny by people trying to show that it can be done "simpler". The whole point of specifying that each individual add or delete must be performed separately in the exact order listed and that the whole operation be atomic, either succeeding entirely or failing entirely if any part of it fails, is precisely so that you can specify: delete: B, beta add: A, alpha add: B, beta and be guaranteed that you will get A=alpha, B=beta if and only if B already had the value beta and A did not already have the value alpha. There isn't anything else supported by those semantics that could not be specified much more simply without them. Now isn't that *exactly* what you said is "outside the scope of what can reasonably considered 'LDAP'". How about we pause again, so you can check back and confirm that is *exactly* what you said and that you are 100% dead wrong. PAUSE ****************************************************************** ****************************************************************** So we as an IETF WG have a responsibility to find out who needs it, what they need it for and what can be done about that. This is done by *asking*, not proclaiming. A "requirements" RFC is a very good place to *ask*. Common sense says that you do that *before* signing off on architecture and you sign off on architecture *before* doing detailed protocol implementation. Most application developers do not really need to know about the detailed modify semantics or understand it, let alone use it. Even DSA implentors do not need to understand it. They just have to implement it. That is so that those applications which *do* need it do not get broken by ignorant vandalism. Remember this is global internet standards we're working on, not enterprise standards. We don't get to decide what applications are going to be installed *anywhere*, let alone everywhere. Now here's a simple question for you. Have you ever found it necessary to *disable* the implementation of LDAP modify as described above in a local DSA? Do you know of any applications common in the environment that is a typical use of multi-master, that are hindered in any way by the fact that a local DSA will fail a request like the one above if a DUA happens to make it and the value beta was not there? It seems to me highly unlikely, since any application that would be hindered would simply not make such very specificly contrived requests that are *intended* to fail under *exactly* those circumstances. Yet it's pretty obvious that if multi-master DSAs that don't support this behaviour are deploysed in the same global scalable directory service with referrals etc as existing DSAs that do support it, any applications that rely on it are going to break immediately. *That's* the sort of interoperability issues that IETF standards are *about*. Conflicting writes to the same entry may occur at a local DSA due to an application reading an entry, deciding on the basis of what it has read to add or delete a value and then have that write operation fail because some other DUA has in the meantime added a value it intended to add, or deleted a value it intended to delete at the same DSA. Such failures are *normal* and any properly designed LDAP client application will recover from them by re-reading the entry and deciding what it wants to do again. (Some applications don't bother, because the interval is short, but no applications whatever have any "problem" from this feature of LDAP that is not simply a bug in their own programming). In fact the LDUP architecture draft specifies that each multi-master DSA MUST implement this behaviour, as constraint 6 in Appendix A. 6) Elements of Protocol - Modify Operation - The entire list of entry modifications MUST be performed in the order they are listed, as a single atomic operation. (p33) That completely refutes your claim that "it is critically important that changes to different attributes made at the 'same time' to the same entry at two different master replicas MUST interleave and both be preserved". If it was "critically important" you would not have specified that it only be allowed when the two DUAs happen to be communicating with different DSAs - after all, most changes important to multi-master are made locally - that's the point of it - and LDAP is designed to conceal as far as possible from application users what DSA they are using. So as well as your view being "exactly, precisely, and PROFOUNDLY the oposite" to mine, it is equally "exactly, precisely, and PROFOUNDLY the oposite" to your own. Forgive me for not being greatly impressed by how PROFOUNDLY you refute yourself. Furthermore, you *concurrently* wrote that interleaved changes are inherently unsuitable for multi-master *and* that preserving them is critically important to it. That is a classic "write conflict" which would have benefited from "conflict resolution" rather than "update reconciliation". [EER] That when such locking semantics are defined for LDAP, that LDUP may then consider how or indeed if they can be reliably replicated via some use of LDUP or some modification of LDUP, but that until such semantics are defined that it is foolish to attempt to preserve them in LDUP. [Albert] They are defined for LDAP and have been ever since it first got on the standards track. The same wording has survived through the revisions for RFC 1487, 1777 right through to 2251. "Now why would anyone want to do that". Perhaps it's about time you tried to find out. BTW, have you ever wondered why Microsoft doesn't implement "modifiersName"? It is a rather important operational attribute sadly missed by sysadmins trying to figure out "who done what" when something goes wrong and is needed to support "critical requirements" like audit trails. What is there about *their* design that makes it impossible for them to include it in a schema with many hundreds of attribute definitions? BTW does Novell implement it? Incidentally this requirement is *very* carefully designed to avoid any need for "locking semantics". It does not require DSAs to maintain any kind of "locking" at all. They can process each operation as it comes without maintaining any state about other operations apart from the results. This is very precisely calibrated to *not* impose any burden on DSA implementations and provide *exactly* the minimalist degree of support for applications that require high data integrity that is possible, without compromising the characteristics of a highly scalable global distributed directory service. There is no "may" about it. LDUP MUST now consider "how or indeed if they can be replicated via some use of LDUP or some modification of LDUP". Until that consideration has been given it is "foolish" to assume that IETF will not preserve the requirements of an existing and widely adopted standards track protocol to meet the unsupported claims of a rather minor and somewhat vendor dominated WG. There are procedures by which mandatory requirements of existing standards can be altered or waived. But they do not consist, as some seem to imagine, of repeatedly telling me to stop mentioning that they are there because some undocumented "consensus" of the flat earth society has decided that they aren't. (BTW sincere thanks for having not done that - it is the mark of people who at least believe they have a valid argument that they do put it forward rather than repeatedly claiming the issue is "settled" no matter how obviously the mere fact that they need to keep repeating themselves shows that it is not). [EER] That the simple perspective that because it is possible (by standing on your head and waving a chicken about with precisely the correct flapping pattern of your legs) to achieve some sort of "test and set" behavior against a single server, that the ability to continue to provide the behavior to a group of distributed, replicated servers operating without benefit of distributed memory of any sort (and thus, operating locally autonomously - which IS the desired behavior to provide continued access and availability to the data that ARE present for local applications in the face of network outages) should somehow be a show-stopper represents a fundamental disagreement over what is desired from a "loose consistency multi-master replication scheme for directories supporting LDAP". [Albert] I just *loved* the bit about waving a chicken, but I got a bit lost in the rest and have missed any point you were making that is responsive to anything I have actually said. I think the key point you are making is in the words "show stopper". It is possible using the semantics *required* by LDAP, to implement various forms of counters, semaphores etc as described by Kurt. Such use could plausibly be described as "by standing on your head and waving a chicken about with precisely the correct flapping pattern of your legs". However that description is not entirely fair. There is no reason to assume that Kurt is wrong about some applications making use of that possibility for good reasons and such experimentation is very much part of what internet protocol development is about, so I wouldn't be so dismissive. Incidentally, even if Kurt is still the only committer, I suspect that OpenLDAP will eventually take off as the dominant LDAP implementation and Kurt may therefore be the most significant implementor here. Don't forget that the whole LDAP "industry" owes its existence to the open source Umich implementations, *not* to either the proprietary directories developed by vendors like Novell or to the X.500 standards work which never got as widely implemented (though the latter did make a *major* contribution - unlike "vendors"). The simple answer to Kurt's point is that multi-master *unfortunately* cannot, and therefore does not, work with applications that use such facilities. That need not be a show stopper. If it could likewise be shown that multi-master *cannot* provide for the normal use of the *required* modify semantics to ensure "what you changed is what you saw", then that need not be a show stopper either. Even if LDUP could simply show that it has very good reasons for needing a waiver, despite it being *possible* to conform - and that the damage would be minimal and the benefits great, I suspect that would not be a show stopper either. In fact you might only need to show that you have seriously considered alternative options and give good reasons for your approach being better. But you will have to give *some* reasons that actually stand up to scrutiny, not just unsustainable assertions and demands. BTW I have already published an I-D showing that supporting the existing standards is not impossible, within the inherent limitations of multi-master. So the obligation on you is to demonstrate why *your* goal, never adopted even by the LDUP WG, should be met instead. I'm sure you can show a *better* way to do it than I did - all I claim to have established is that it is *possible*. In fact your own architecture draft makes it obvious in 3.7 that the required semantics *can* be implemented, within the limitations of multi-master: *** In the case of a single-server or single-mastered Replication Context all LDAP Constraints are immediately enforced at the single updateable replica. An error result code is returned to an LDAP Client that presents an operation that would violate the constraints. In the case of a multi-mastered Replication Context not all LDAP Constraints can be immediately enforced at the updateable replica to which the LDAP Update Operation is applied. This loosely consistent replication architecture ensures that at each replica all constraints are imposed, but as updates are replicated constraint violations arise that cannot be reported to the appropriate client. Any constraint violations that occur are repaired by a set of update resolution procedures. Any LDAP client that has been implemented to expect immediate enforcement of all LDAP Constraints may not behave as expected against a multi-mastered Replication Context. *** Unlike your assumptions in this message, the above, which I assume you also had at least a hand in writing, is an *accurate* assessment of the limitations and necessities of multi-master. Certain LDAP constraints which an application can expect to be enforced immediately in a single master environment can only be enforced after the fact in a multi-master environment. That is a simple objective limitation of the applicability of multi-master, which cannot be a show stopper or LDUP would not have been assigned a charter to develop multi-master standards. The architecture draft *does* enforce those constraints it acknowledges. In particular it resolves conflicts between rename and create operations in the only way feasible. It does so after the fact because that is the only possibility for multi-master and it preserves all the information available for users or administrators to sort out the problems that inevitably *do* arise as a result of only being able to enforce the constraints after violations have already happened - because that is the common sense thing to do. But for the constraints specified by the modify operation the architecture, and consequently URP, has adopted the exact opposite approach - of simply pretending those constraints are not there, except locally. It does not even retain sufficient information to enable administrators to fix the problems - as explicitly required by the current requirements draft. That's what happens when you go ahead with architecture before finalizing requirements. The "goal" you are trying to meet was never agreed on as an LDUP WG goal, let alone put forward to IETF seeking a waiver or alteration to existing LDAP standards, and is not even stated as a requirement in the current LDUP requirements draft now at final call. You need to explain *why* you have chosen *not* to enforce the constraints of the LDAP modify operation semantics. I doubt that saying that they don't exist and you "may then consider" them if they should happen to come into existence at some future time will be an acceptable explanation. You need to explain *why* LDUP could not, or at least should not, adopt the same approach for modify operations as it has adopted for create and rename. In particular you need to explain that in a context where you have already *agreed* that multi-master is unsuitable for situations with a high rate of concurrent changes. If all you can demonstrate is that you neither know nor care about the existing standards work but are very convincing and witty, you are in the wrong place. [EER] That there are LOTS of alternative approaches to providing shared application profile information, ranging from ACAP (which I would characterize as a network accessible associative memory service) to a distributed shared memory system intended to provide cluster-level disk sector semaphores (with or without write-down mandatory access control prohibitions). These are things LDAP and LDUP are not suitable to support. [Albert] There are also LOTS of alternative approaches to providing directory services, and even directory services that can be used with standard LDAP clients. For example you can even just bolt-on a non-standard semi-LDAP veneer over a fundamentally non-compliant existing proprietary directory server and call it an LDAP server as Novell has done, or design one from the ground up adopting those aspects of the standards that seem convenient and ignoring those that don't, like Microsoft. Nobody will stop you. IETF doesn't need to go around trying to enforce non-use of an "LDAP service mark" or anything silly like that. It just so happens that the requirements of internet interoperability do eventually drive all sorts of vendors with different agendas to the conclusion that they need to conform to objective common standards that they are unable to impose themselves and which they often find more useful to develop through the IETF process than through industry forums etc. Meeting vendor requirements to support their pet design ideas is not one of the things that IETF standards process are good for. If you benefitted from LDAP standards work, think very carefully about those benefits. At this stage, after more than two years work, you have not yet reached the level of having even 2 interoperable actual implementations conforming to a published specification that demonstrates that your architecture at least *can* be standardized, whether or not it should be. No more experience of the practical operational implications of multi-master standardization has been acquired by the IETF so far as a result of chartering this WG, than would have been obtained by just monitoring the experience of the non-interoperable Microsoft and Novell implementations. You are in no position to be making demands that the requirements of existing standards be ignored to meet the goals of your architecture. [EER] That if needed to move things forward, to encourage multi-vendor inter-replication of LDAP directory content, I would gladly advise developers who attempt to create their own locking or test-and-set operations to be sure that, as Albert has correctly described "a change can be reliably made to exactly the entry you thought you were changing and not result in some mixture of updates combined with unknown concurrent changes by some other application" that they do so at their own peril when operating against directories supporting LDUP. [Albert] If you develop an architecture that ignores existing standards and makes interoperation with applications based on those standards "perilous" you had better be prepared to justify it. If your justification is that you think: "it is critically important that changes to different attributes made at the 'same time' to the same entry at two different master replicas MUST interleave and both be preserved" then you had better be prepared to present an explanation that actually stands up to scrutiny, because that is what it will receive at IETF last call. You have agreed that this is "correctly described" as meaning applications which expect "a change can be reliably made to exactly the entry you thought you were changing and not result in some mixture of updates combined with unknown concurrent changes by some other application" do so at their own peril when operating against directories implementing your architecure. You had better be prepared to do some actual requirements analysis and document the effect on existing applications and the measures you have taken to minimize the "peril". In particular you had better take a look at parallel standardization work on access control - without which LDUP deployment would be useless, and which is fundamentally broken by your architecture. [EER] Look, folks - this all would have been easy to provide for fully atomic operations against multiple-master replicas...just add XA semantics to LDAP for enforcement among all master (updateable) replicas with full two-phase commit support for each required atomic operation. Phase one, all masters would verify that they had no pending operations which are in conflict with the proposed changes and that they're blocking any new such requests until the commit or rollback command is received. Phase two, commit or rollback after all updateable replicas reply "ready". But that's NOT WHAT WE SET OUT TO DO. THAT'S NOT WHAT ANY OF US WANTED TO IMPOSE. THAT'S NOT WHY WE'RE USING LDAP. STOP TRYING TO MOVE US THERE! [Albert] Ok, so I'm Australian. But I've never worked for ICL and you are shouting at the wrong person. delete: B, beta add: A, alpha add: B, beta Look Ma, no locks! No two phase commit. No XA transaction protocol monitors. No acres of glistening dinosaurs with hundreds of kilometres of optical fibre. Isn't it amazing what those crude amateurs can achieve by ignoring the advice of experts from established vendors well known by their fame. Just two extra lines of code and no waving of chickens between our legs in precisely the right flapping pattern. And a draft showing it's possible to implement in a distributed multi-master environment can be written in a week when it takes "engineering teams" *years* to write drafts that don't even meet the requirements developed in the same WG. But now that you have started SHOUTING, perhaps it's a good time to ask. Just why *are* you here? And why are you using LDAP? Why are you trying to move IETF somewhere. If you don't think much of the LDAP standard, and can't even be bothered proposing an amendment to it when you think some aspect of it is useless or harmful? Why not develop your own through a vendor forum? I assume you are here because you want the IETF to adopt a new standards track protocol which will provide interoperability benefits for implementations of directory services. You are using LDAP because it turned out be one hell of a lot more deployable in practice on the internet than the proprietary clients you had already developed for a very widely deployed and indeed completely dominant enterprise LAN/WAN directory server. If so, you are going to have to go through the IETF process, whether you like it or not. This includes the benefit of helpful and thoughtful comments from people who have a lot of experience and know exactly what they are talking about. It also comes with having to put up with ignorant comments from people who don't. You have to answer both and show that your proposals are technically justified. If you think my comments are in the latter category, that's up to you. But you still have to answer them. You might want to pause to consider whether it would have been easier to do so if you had paid more attention to the very quietly spoken, non-obnoxious guy who dropped in briefly to the LDUP WG very early on and offered this "two cents worth" of advice before disappearing again: *** Each LDAP operation (add, modify, delete, moddn) as a whole is atomic. The whole operation either happens or it doesn't. Changes cannot be half-applied to any single LDAP server. The replication consistency model must assume and build on this basic fact to define how multiple LDAP replicas converge to the same state over time, in the absence of additional changes. This kind of loose consistency model is pretty fundamental to the notion of a directory. My two cents on what's important in a replication consistency model are that it must be 1) predictable, and that it should 2) make some kind of sense to people using the system. All this talk of consistency at different levels (e.g., between applications using the directory at the same time) is a red herring. Our job is to define a consistency model for the directory itself. Some applications may find this model sufficient for their needs. Others may have to build more elaborate models on top. But let's start with the basics. -- Tim *** It isn't as though you ended up with me getting obnoxious about it without having been told very politely by people who are much more authoriative. The advice was worth a lot more than 2 cents. Note the word "must". It doesn't have to spelled MUST for most people to pay attention. Would you characterize the 9 transient states that can arise with URP from changes to just two attribute values as "predictable"? Can you point me to any standards track protocol that is more convoluted and harder to make sense of than URP? You didn't listen and you've been going around in circles for more than two years since. Start listening. [EER] Albert - as far as I can tell, even Microsoft has moved towards interleaving attribute changes, away from the entry-level sequence number scheme that CODA and ADSv1 used. No, LDUP won't do that. I personally don't think it SHOULD do that. We may agree to disagree on that point. [Albert] Ed you have been the architect for Novell directory services, and your most critical competitor has been Microsoft. They did their homework and studied your design very carefully because they knew they had to beat it. You should have done *your* home work and studied theirs. As far as I can tell, I know a *lot* more about Active Directory then you do - so I knew you were wrong about that before Paul pointed it out. I can tell, because I did spend several hours discussing things with you before writing my draft, in which I benefited greatly from a lot of insights from you - duly acknowedged in the draft, but in which you were the one asking me questions about AD. Do your homework. "Even Microsoft" used sequence numbers rather than timestamps so that their non-compliant directory is at least capable of satisfying "eventual convergence" - which your architecture does not. "Even Microsoft" at least maintained the granularity of replication at the attribute level, which means that it is *possible* for application developers to maintain data integrity (by using Microsoft APIs rather than LDAP standard APIs) whereas your architecture actually goes down to the attribute value level, thus making it impossible - despite the fact that your own explanation points to attribute level granularity. They haven't "moved" anywhere - they broke atomicity right from the start, but did so in a way that was at least viable and suited their own commercial interests. And "even Microsoft" *learns* from its participation in IETF WGs and leaves the spouting to the marketing department outside. The only thing that will supplant them is a *better* design, not a worse one - and they are probably smart enough to adopt one rather than stick their heads in the sand. So you'd better be prepared to really think about being willing to evolve rather than just persisting with "WHAT WE SET OUT TO DO". Sorry I'm picking on you. But please take it as a compliment, because I have spent several hours learning from you and I think there is at least the possibility that you *could* start listening, because you actually do know what you are talking about. Likewise I have been willing to argue with Steve, whose draft I completely reject, whereas I am far too "respectful" of some to take them on in a way I don't think they could handle. From owner-ietf-ldup@mail.imc.org Wed Feb 21 09:10:56 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA27056 for ; Wed, 21 Feb 2001 09:10:56 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.9.3/8.9.3) id FAA01495 for ietf-ldup-bks; Wed, 21 Feb 2001 05:32:20 -0800 (PST) Received: from mail.coreon.net (IDENT:mirapoint@mail.coreon.net [216.74.131.6]) by above.proper.com (8.9.3/8.9.3) with ESMTP id FAA01490 for ; Wed, 21 Feb 2001 05:32:18 -0800 (PST) Received: from rmoats2 (wenjus3.coreon.net [216.74.131.3]) by mail.coreon.net (Mirapoint) with ESMTP id AAA80618 (AUTH rmoats); Wed, 21 Feb 2001 08:30:27 -0500 (EST) From: "Ryan Moats" To: "Jerry Combs" , "John Strassner" , "Paul Leach" Cc: , "Kurt D. Zeilenga" , Subject: RE: WG Last Call on the LDAPv3 Directory Replication I-D Date: Wed, 21 Feb 2001 07:35:31 -0600 Message-ID: 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 IMO, Build 9.0.2416 (9.0.2911.0) In-Reply-To: Importance: Normal 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: Content-Transfer-Encoding: 7bit I disagree. The protocol must be able to support propagation of atomicity information. That's not to say you need to use it in a particular scenario that you are directory administator for. Ryan -----Original Message----- From: owner-ietf-ldup@mail.imc.org [mailto:owner-ietf-ldup@mail.imc.org]On Behalf Of Jerry Combs Sent: Tuesday, February 20, 2001 9:51 PM To: John Strassner; Paul Leach Cc: Albert.Langer@directory-designs.org; Kurt D. Zeilenga; ietf-ldup@imc.org Subject: Re: WG Last Call on the LDAPv3 Directory Replication I-D I think the following item should be removed from the requirements doc. >>>P6. The protocol MUST support propagation of atomicity information. The point of replication is the convergence of the committed state of the object on that particular replica. Atomicity allows an application resolve discrepancies at the time of the modification according to logic that is inherently application dependent. Once the modification is committed to a specific replica, the directory should only be responsible for replicating the resulting committed state of the object. If there are changes to the object on multiple replicas the replication mechanism should be responsible for resolving the differences in state...it should not be responsible for application level transaction integrity. As an example, suppose you have a replica with a replication interval of 5 minutes. On this replica you modify an attribute 10 times during the 5 minute interval. When it is time to begin the replication the attribute has a specific state. Should all ten "transactions" be replicated or should only the current state be replicated? I contend that the replication mechanism should only guarantee the replication of the current state. This reduces the amount of replication traffic dramatically. Note that attributes that are high priority could be replicated immediately and would therefore replicate each state change. Both methods should supported. If you accept that in a directory replication of state and not replication of modification sequence is acceptable then you must agree that propagation of atomicity is impossible. Applications should be designed to deal with state and not modification sequence. If a record of modification sequence is needed it can be maintained separately as a log, audit database, etc. This can work, even for the Provisioning application that someone mentioned because I've just finished writing such an application. JC On 2/20/01 2:36 PM, "John Strassner" wrote: > I don't understand your "Huh?", as the application instances could just as > easily be operating on the same replica, or one could build a more robust > system that front-ends the replicas and handles conflicts there. > > John > > At 05:50 PM 2/19/2001 -0800, Paul Leach wrote: > > >>> -----Original Message----- >>> From: John Strassner [mailto:jstrassn@cisco.com] >>> Sent: Monday, February 19, 2001 10:27 AM >>> To: Albert.Langer@directory-designs.org >>> Cc: Kurt D. Zeilenga; ietf-ldup@imc.org >>> Subject: RE: WG Last Call on the LDAPv3 Directory Replication I-D >>> >>> >>> Not true. First, applications can certainly build locking and other >>> mechanisms to isolate operations affecting an update. >> >> Huh? The application instances could be operating on different replicas, >> so will never even see the "locking" operations of the other. They will >> proceed as if they were isolated, and then their updates will clash >> laters. When the attributes being modified overlap partially but not >> completely, neither one of them will get a consistent set. > > From owner-ietf-ldup@mail.imc.org Wed Feb 21 10:03:58 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA28871 for ; Wed, 21 Feb 2001 10:03:57 -0500 (EST) Received: by above.proper.com (8.9.3/8.9.3) id GAA07900 for ietf-ldup-bks; Wed, 21 Feb 2001 06:28:29 -0800 (PST) Received: from dokka.maxware.no (dokka.maxware.no [195.139.236.69]) by above.proper.com (8.9.3/8.9.3) with ESMTP id GAA07888 for ; Wed, 21 Feb 2001 06:28:26 -0800 (PST) Received: from HALVESTR-8KCDT.alvestrand.no (localhost [127.0.0.1]) by dokka.maxware.no (8.9.3/8.9.3) with ESMTP id PAA07042; Wed, 21 Feb 2001 15:27:01 +0100 Message-Id: <4.3.2.7.2.20010221151639.03ddcef0@nordic.cisco.com> X-Sender: hta@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Wed, 21 Feb 2001 15:26:41 +0100 To: directory@apps.ietf.org From: Harald Alvestrand Subject: Non-WG Call on draft-alvestrand-directory-defs-01.txt Cc: dnsop@cafax.se, ietf-ldapext@netscape.com, ietf-ldup@imc.org, tf-lsd@terena.nl, rwhois@rwhois.net, ietf-else@OpenLDAP.org Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ietf-ldup@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This message is intentionally copied quite widely, to a number of mailing lists where people who do "directory-like things" hang out. This is a Last Call before submitting to the IESG on the document draft-alvestrand-directory-defs-01.txt, available from the I-D directories, such as http://www.ietf.org/internet-drafts/draft-alvestrand-directory-defs-01.txt From the introduction: "When discussing systems for making information accessible through the Internet in standardized ways, it may be useful if the people discussing have a common understanding of the terms they use. One group of such systems is known under the term "directories". This document is not intended to be either comprehensive or definitive, but is intended to give some aid in mutual comprehension when discussing information access methods to be incorporated into Internet Standards-Track documents. Reference to this document would, for instance, give one the power to agree that the Domain Name Service is a global lookup repository with perimeter integrity and loose, converging consistency, while an LDAP directory server is a local, centralized repository with both lookup and search capability." In other words - a document to give a common understanding of terms like "The DNS is not a directory". There are 2 typos in the document that I know of already, so this is not the version that will be last-called. (See if you find them too .-) However, if you have other comments, PLEASE send them to myself and to directory@apps.ietf.org. DO NOT SEND TO THE LISTS IN THE CC: LINE! (my apologies for being unable to insert the oft-feared Reply-to: line) If no serious objections are made, I hope to submit version -03 to the IESG for consideration before the Minneapolis IETF meeting. Thank you. -- Harald Tveit Alvestrand, alvestrand@cisco.com +47 41 44 29 94 Personal email: Harald@Alvestrand.no From owner-ietf-ldup@mail.imc.org Wed Feb 21 13:13:08 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA04740 for ; Wed, 21 Feb 2001 13:13:05 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.9.3/8.9.3) id JAA20657 for ietf-ldup-bks; Wed, 21 Feb 2001 09:26:40 -0800 (PST) Received: from ns.oncalldba.com ([66.1.184.87]) by above.proper.com (8.9.3/8.9.3) with ESMTP id JAA20653 for ; Wed, 21 Feb 2001 09:26:37 -0800 (PST) Received: from reed.oncalldba.com (reed.OnCallDBA.COM [192.168.1.3]) by ns.oncalldba.com (8.11.0/8.8.7) with SMTP id f1LHPww24243 for ; Wed, 21 Feb 2001 10:25:58 -0700 Received: from RMINC_DOM-Message_Server by reed.oncalldba.com with Novell_GroupWise; Wed, 21 Feb 2001 10:17:16 -0700 Message-Id: X-Mailer: Novell GroupWise Internet Agent 5.5.2.1 Date: Wed, 21 Feb 2001 10:16:58 -0700 From: "Ed Reed" To: , Subject: Inheriting / Cacheing / Replicating policy from superior administrative areas Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Disposition: inline Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id JAA20654 Sender: owner-ietf-ldup@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 8bit Preamble At the San Diego IETF in December a bar boff (1 round = $89 or so USD) was convened to consider how to deal with inheritance of policy down through a tree from superior to subordinate contexts. The topic came up because it's an issue for access control policy, which many of us would like to see be able to be inheritable from parents to children, so that an access granted to a parent or superior organizational unit, for instance, could be interpreted correctly as being implicitly granted to all the subordinate entries of that parent. Other policy information could benefit from such inheritance, and the general case is that policy set at the root of an enterprise (for instance) administrative area is applied to the whole of the administrative area, even if the administrative area is partitioned and distributed among several servers (or groups of servers) throughout the enterprise. Real world examples include Novell NDS trees, Microsoft ADS Forests, and probably things like th! e directory information tree in X.500 for a country, a governmental agency or any other sort of large organization. Since this discussion grew out of the LDAPSubentry internet draft discussion about inheritance, I've copied both the ldup and ldapext distribution lists. The requirement To support the kind of top-down policy inheritance described above, servers holding subordinate partitions of the administrative area (in other words, simple subtrees rooted below the root of the administrative area where the policy is set) need to be informed of the policy that they are supposed to inherit from above. Note that I've not said anything about how the policy is represented yet. It may be via attributes on the root of the administrative area, or it may be via subentries located immediately subordinate to the root of the administrative area, or by some other means. In fact, for the general case that includes the full X.500 subentry definition with subtree specifications in the subentry, it's only necessary that the policy subentry applies to the entry and its attributes being governed (I think - David? Helmut? Richard? Others?) So the question is how to make the subordinate partition of the namespace, that does not necessarily coreside on a server where the administrative area is rooted and where the inheritable governing policy is asserted, how does that subordinate namespace "know" about the inherited policy so that it can enforce it? Possible approaches There are several ways this has been approached in the past, and one can imagine many others. 1) the inheritable policy could be asserted when the superior/subordinate references are being administratively set to glue the two namespaces together, either manually by the administrators or programmatically via some hierarchical operational binding protocol, for instance. I think this is how X.500 implementation generally handle it. 2) a specialized form of replication that knows of the need to maintain cached information aggregated from superior administrative areas in the directory information tree takes responsibility to identify inheritable information and to maintain copies of it on or near subordinate partition roots. This makes the information available locally to the subordinate namespace in a "read-only" fashion that facilitates decision making and makes the specialized replication scheme responsible for propagating policy changes to all the subordinates when needed. This is how Novell's NDS does it. 3) servers holding subordinate partitions of an administrative area can "opportunistically cache" policy information locally. In this scenario, the access control policy engine (probably, as the direct consumer of the inherited policy information in one example) knows that policy information may be defined in superior areas of the directory information tree that it needs to know about, and so it "walks the tree" until it finds what is clearly the "top" of the authoritative administrative area within which it is supposed to operate. (I say it this way to highlight that the subordinate may well know its not supposed to walk the tree all the way to "dc=com", for instance, if the root of the organizations administrative area is "dc=oncalldba, dc=com", for instance) At any rate, the policy engine walks the tree "as far as its supposed to go" accumulating policy information that applies to it and cacheing it locally for future use. The walk would take place at server startup tim! e, or when the partition is placed "in service" (if it ever goes off line), or on scheduled "has anything changed I need to know about" walkabouts. Each policy engine would be responsible for its own cache of information and its own walkabouts (I like that term for this...) 4) whenever policy is defined at an administrative point that applies to subordinate entries, a process (either client or server-based, or some combination of both) performs the inverse to the walkabout described in #3 above - that is, it descends the tree depositing policy information (or changing policy information it finds there) on subordinate entries (either on partition roots or on each leaf entry itself) as it goes. This approach has the benefit of "pushing" changes from the point of administrative action to all the areas subject to the policy change, rather than relying on the "opportunistic cache" of #3. With some care, it need not be any more bandwidth consuming than the specialized replication scheme described in #2 above. And is more dynamic than the static configuration of #1 above. I think this is generally how Microsoft handles inheritable policy for access controls. (and yes, in professional contexts of previous lives I've dinged them for how they do it, b! ut that was nit picking over implementation approaches of what to decorate, not over the general concept of how to propagate changes). ["Ed"itorial note - this note alread covers more than we discussed at the bar boff] There are probably other approaches. In fact, we came up with one more at the bar boff. 5) each server holding a subordinate partition of an administrative area could also hold a "sparse replica" of the otherwise non-resident superior administrative areas which hold policy information relevant to the partition it does hold. This approach would allow LDUP to be responsible for propagating changes to policy "as written" to subordinate servers that need it, avoids creating specialized mechanisms that need to know how to aggregate policy information through multiple tiers of administrative area roots (something both #2 and #4 require, and something I for one really, really, really don't want to try to generalize for a standard), leaves interpretation of superior policy entirely up to the local policy decision functions (where it belongs) and "only" requires read-only replicas of the superior administrative root entry and its subentries. Being "read-only" replicas, the LDUP house keeping is kept to a minimum (because there will never be changes flowing from the subo! rdinate copy to the administrative area root "master" replica). There will be replication traffic, which can be scheduled or event driven. The sparse replica replication agreements can be set via administrators to control how or what subentries are replicated (maybe only those flagged "inheritable"). As a read-only replica, it can be configured via transitive synch to take its changes from another read-only replica so you don't HAVE to have the situation where every server in the enterprise is banging away at the root-most master server for policy information, so we should be able to manage the network traffic scaling issues in large trees (though its true that using transitive synch lengthens the time it takes for changes to propagate to all servers). And, if you don't need it, don't use it. The cool thing is that this approach works for any number of inheritable policy information, including schema, password policy, etc. as well as for access control information. Anyway, that's the idea we came up with. Discussion is invited, if only to cause a change in subject on the mailing list ;-) Does this need to be an RFC? If the chairs think so, let me know whether to submit it as an internet draft under the ldup group name or as an individual submission. Thanks, Ed ================= Ed Reed Reed-Matthews, Inc. +1 801 796 7065 http://www.Reed-Matthews.COM From owner-ietf-ldup@mail.imc.org Wed Feb 21 15:34:42 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA09327 for ; Wed, 21 Feb 2001 15:34:41 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.9.3/8.9.3) id LAA12085 for ietf-ldup-bks; Wed, 21 Feb 2001 11:56:50 -0800 (PST) Received: from relay1.pair.com (relay1.pair.com [209.68.1.20]) by above.proper.com (8.9.3/8.9.3) with SMTP id LAA12071 for ; Wed, 21 Feb 2001 11:56:47 -0800 (PST) Received: (qmail 9461 invoked from network); 21 Feb 2001 19:56:12 -0000 Received: from cpe-144-132-70-18.vic.bigpond.net.au (HELO w98) (144.132.70.18) by relay1.pair.com with SMTP; 21 Feb 2001 19:56:12 -0000 X-pair-Authenticated: 144.132.70.18 Reply-To: From: "Albert Langer" To: "'Ed Reed'" , , Subject: RE: Inheriting / Cacheing / Replicating policy from superioradministrative areas Date: Thu, 22 Feb 2001 06:59:40 +1100 Message-ID: <001301c09c40$d40c74c0$6628a8c0@nowhere.com> 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 CWS, Build 9.0.2416 (9.0.2910.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Importance: Normal In-Reply-To: Sender: owner-ietf-ldup@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit [Ed] Anyway, that's the idea we came up with. Discussion is invited, if only to cause a change in subject on the mailing list ;-) [Albert] Quick response for similar reason, as a break while still working on LDUP final call issues. I think it should be based directly on X.500 framework for administrative areas with whatever LDAP style simplifications can be achieved in those aspects that relate to operational bindings etc but no departures at all from a common conceptual framework as to how policy is inherited. Seems to me that the standards themselves and David Chadwick's online book about them point to a "natural" description that is very similar your option 5 "sparse replica". That is to treat admin points very much like "glue" entries necessary to maintain a connection from a subordinate context to the global tree. You simply replicate all superior admin points that a replicated area is nested within like any other glue. Then you use the glue style entries for those admin points at the replica to drive whatever implementation specific machinery is used to prioritize and enforce policy in strict accordance with the X.500 conceptual framework. If I understood correctly that seems to be what you saying about a "sparse replica", but integrates it with what's also needed in this context (and has been all along before dealing with multi-master) - a framework for directory distribution based on X.500 with detailed specification of operational bindings, glue entries etc. Administrative areas can't be defined independently of that framework without running into the fact that they are closely connected to it. Interesting issue relevant to current other discussions is that I suspect this replication could be an example where multi-master may be inapplicable due to the extreme hairiness of allowing for policy update conflicts. That in turn raises hairy issues about how one could combine single master partitions (even if only containing such "admin points" and other "glue"), with multi-master replicas subordinate to them on the same DSA implementation, with an overlap between the two at the innermost nested admin point. It also points to the necessity for actually implementing the LDUP WG charter to provide for single master as well as multi-master replication (the difference isn't just a "topology" but involves both conformance levels for DSAs and directory service replication requirements). Also points to need for replication management to be standardized with provisions for creating and merging replication areas etc. This may also closely relate to schema replication (for which X.500 defines similar admin points in the same conceptual framework). There are requirements about schema replication in the current requirements draft and machinery is needed to be able to coordinate schema changes with the replication of entries dependent on the schema changes - but there is no such machinery in the current architecture drafts. Similar machinery could be needed for coordination of policy changes. Any such coordination machinery has to be enforced by the conflict resolution mechanism and since none is currently specified, none is currently implemented by URP (whether or not it could do so, given that it does not retain log information that might be necessary). Then coordination machinery for any of these aspects is likely to involve something like the concepts of a "floating" or "failover" single master for that specific aspect as in the "schema master" and "infrastructure master" for AD. This is also needed to achieve eventual convegence as there is of course no way to guarantee that without some means of specifying which DSAs are currently authoritatively considered to be part of the replication network and which are excluded from it - otherwise meta-data would grow without bound while waiting for a failed DSA that isn't going to come back. Again there is no such machinery in the current architecture, consequently none in URP and no eventual convergence possible. Hmm, ... oh well, *some* of that was a "break" and it *is* all relevant to your original posting, which I have at least refrained from dissecting line by line ;-) From owner-ietf-ldup@mail.imc.org Wed Feb 21 15:54:22 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA09940 for ; Wed, 21 Feb 2001 15:54:21 -0500 (EST) Received: by above.proper.com (8.9.3/8.9.3) id MAA16519 for ietf-ldup-bks; Wed, 21 Feb 2001 12:16:43 -0800 (PST) Received: from pretender.boolean.net (root@router.boolean.net [198.144.206.49]) by above.proper.com (8.9.3/8.9.3) with ESMTP id MAA16508 for ; Wed, 21 Feb 2001 12:16:41 -0800 (PST) Received: from gypsy.OpenLDAP.org (gypsy.boolean.net [10.192.1.2]) by pretender.boolean.net (8.11.1/8.11.1/Boolean/Hub) with ESMTP id f1LKFSD25952; Wed, 21 Feb 2001 20:15:28 GMT (envelope-from Kurt@OpenLDAP.org) Message-Id: <5.0.2.1.0.20010221120137.00a9bb10@router.boolean.net> X-Sender: guru@router.boolean.net X-Mailer: QUALCOMM Windows Eudora Version 5.0.2 Date: Wed, 21 Feb 2001 12:15:27 -0800 To: From: "Kurt D. Zeilenga" Subject: RE: Inheriting / Cacheing / Replicating policy from superioradministrative areas Cc: "'Ed Reed'" , , In-Reply-To: <001301c09c40$d40c74c0$6628a8c0@nowhere.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 06:59 AM 2/22/01 +1100, Albert Langer wrote: >I think it should be based directly on X.500 framework for administrative >areas with whatever >LDAP style simplifications can be achieved in those aspects that relate to >operational bindings etc but no departures at all from a common conceptual >framework as to how policy is inherited. I concur. I would prefer to keep the directory's administrative model simple and as consistent as possible with the X.500 models. Such features as policy inheritance can be push into the administration application space. I note that one must be careful not to assume that naming relationships have any particular significance to the policy in force. Also, I note (like Albert) that the administrative model in X.500 does not to address the needs of multiple-master replication and hence may require significant adaptation. This may be difficult to engineer by itself, however it will be much harder to engineer if numerous unnecessary requirements are added to the mix. Kurt From owner-ietf-ldup@mail.imc.org Wed Feb 21 16:57:39 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA11912 for ; Wed, 21 Feb 2001 16:57:38 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.9.3/8.9.3) id MAA24343 for ietf-ldup-bks; Wed, 21 Feb 2001 12:59:35 -0800 (PST) Received: from ns.oncalldba.com ([66.1.184.87]) by above.proper.com (8.9.3/8.9.3) with ESMTP id MAA24338 for ; Wed, 21 Feb 2001 12:59:33 -0800 (PST) Received: from reed.oncalldba.com (reed.OnCallDBA.COM [192.168.1.3]) by ns.oncalldba.com (8.11.0/8.8.7) with SMTP id f1LKwmw27061 for ; Wed, 21 Feb 2001 13:58:48 -0700 Received: from RMINC_DOM-Message_Server by reed.oncalldba.com with Novell_GroupWise; Wed, 21 Feb 2001 13:49:22 -0700 Message-Id: X-Mailer: Novell GroupWise Internet Agent 5.5.2.1 Date: Wed, 21 Feb 2001 13:49:11 -0700 From: "Ed Reed" To: , , Subject: RE: Inheriting / Cacheing / Replicating policy from superioradministrative areas Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Disposition: inline Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id MAA24339 Sender: owner-ietf-ldup@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 8bit Yeah - some policy information (in particular distributed knowledge about replica topology) is, in my opinion, better served via a single-master approach - and that's why "primary" is there as a replica type along with "updateable". The notion is borrowed from Novell's use of "master" to refer to the single replica in a ring that would act as the transaction coordinator for what are really two-phase commit-like state transitions in replica toplogy. But, alas, others insist that you can manage such things without having a single "master" responsible for topology configuration changes...splitting and joining partitions, creating and deleting replicas and replication agreements, etc. I look forward to seeing how they do it in a completely egalitarian setting where all updateable replicas are "equal". So clearly I'm not opposed to single master configurations...and have retained the one designation of one updateable replica of a partition as the "first among equals" to assist applications looking for a rendezvous point for serialization of their (application specific) operations. With regard to the option 5 similarity to X.500 - I agree that the sparse replicas might even be implemented as caches on external references (some directory implementations do external references - NDS does - though LDAP doesn't recognize the concept - yet). They're there for the convenience of the various policy engines running on the local server, and so can be considered entirely "operational" in nature, and even "private" if the policy engines are sufficiently tightly bound to the directory service process itself. However, to be more general, I'd simply make them "operational" and not private (as would be the case if they were really external references) so that new policy engines can be added willy-nilly. Ed ================= Ed Reed Reed-Matthews, Inc. +1 801 796 7065 http://www.Reed-Matthews.COM >>> "Albert Langer" 02/21/01 12:59PM >>> [Ed] Anyway, that's the idea we came up with. Discussion is invited, if only to cause a change in subject on the mailing list ;-) [Albert] Quick response for similar reason, as a break while still working on LDUP final call issues. I think it should be based directly on X.500 framework for administrative areas with whatever LDAP style simplifications can be achieved in those aspects that relate to operational bindings etc but no departures at all from a common conceptual framework as to how policy is inherited. Seems to me that the standards themselves and David Chadwick's online book about them point to a "natural" description that is very similar your option 5 "sparse replica". That is to treat admin points very much like "glue" entries necessary to maintain a connection from a subordinate context to the global tree. You simply replicate all superior admin points that a replicated area is nested within like any other glue. Then you use the glue style entries for those admin points at the replica to drive whatever implementation specific machinery is used to prioritize and enforce policy in strict accordance with the X.500 conceptual framework. If I understood correctly that seems to be what you saying about a "sparse replica", but integrates it with what's also needed in this context (and has been all along before dealing with multi-master) - a framework for directory distribution based on X.500 with detailed specification of operational bindings, glue entries etc. Administrative areas can't be defined independently of that framework without running into the fact that they are closely connected to it. Interesting issue relevant to current other discussions is that I suspect this replication could be an example where multi-master may be inapplicable due to the extreme hairiness of allowing for policy update conflicts. That in turn raises hairy issues about how one could combine single master partitions (even if only containing such "admin points" and other "glue"), with multi-master replicas subordinate to them on the same DSA implementation, with an overlap between the two at the innermost nested admin point. It also points to the necessity for actually implementing the LDUP WG charter to provide for single master as well as multi-master replication (the difference isn't just a "topology" but involves both conformance levels for DSAs and directory service replication requirements). Also points to need for replication management to be standardized with provisions for creating and merging replication areas etc. This may also closely relate to schema replication (for which X.500 defines similar admin points in the same conceptual framework). There are requirements about schema replication in the current requirements draft and machinery is needed to be able to coordinate schema changes with the replication of entries dependent on the schema changes - but there is no such machinery in the current architecture drafts. Similar machinery could be needed for coordination of policy changes. Any such coordination machinery has to be enforced by the conflict resolution mechanism and since none is currently specified, none is currently implemented by URP (whether or not it could do so, given that it does not retain log information that might be necessary). Then coordination machinery for any of these aspects is likely to involve something like the concepts of a "floating" or "failover" single master for that specific aspect as in the "schema master" and "infrastructure master" for AD. This is also needed to achieve eventual convegence as there is of course no way to guarantee that without some means of specifying which DSAs are currently authoritatively considered to be part of the replication network and which are excluded from it - otherwise meta-data would grow without bound while waiting for a failed DSA that isn't going to come back. Again there is no such machinery in the current architecture, consequently none in URP and no eventual convergence possible. Hmm, ... oh well, *some* of that was a "break" and it *is* all relevant to your original posting, which I have at least refrained from dissecting line by line ;-) From owner-ietf-ldup@mail.imc.org Wed Feb 21 16:58:21 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA11929 for ; Wed, 21 Feb 2001 16:58:20 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.9.3/8.9.3) id NAA24857 for ietf-ldup-bks; Wed, 21 Feb 2001 13:06:58 -0800 (PST) Received: from ns.oncalldba.com ([66.1.184.87]) by above.proper.com (8.9.3/8.9.3) with ESMTP id NAA24852 for ; Wed, 21 Feb 2001 13:06:54 -0800 (PST) Received: from reed.oncalldba.com (reed.OnCallDBA.COM [192.168.1.3]) by ns.oncalldba.com (8.11.0/8.8.7) with SMTP id f1LL6Gw30189 for ; Wed, 21 Feb 2001 14:06:16 -0700 Received: from RMINC_DOM-Message_Server by reed.oncalldba.com with Novell_GroupWise; Wed, 21 Feb 2001 13:56:47 -0700 Message-Id: X-Mailer: Novell GroupWise Internet Agent 5.5.2.1 Date: Wed, 21 Feb 2001 13:56:32 -0700 From: "Ed Reed" To: Cc: , , , , , "Ed Reed" , Subject: draft-ietf-ldup-inheritance-00.txt Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="=_7229D19F.1C7D1182" Sender: owner-ietf-ldup@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: --=_7229D19F.1C7D1182 Content-Type: text/plain; charset=US-ASCII Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Please publish the attached new internet draft. Abstract: There are several possible ways to manage inheritance of policy=20 information in a directory service. This document describes several=20 known mechanisms and recommends one for general use that can be=20 implemented using [LDUP].=20 To the LDUP and LDAPEXT working groups: This is the draftified version of my notes on inheritance mechanisms for which there is already discussion taking place on the mailing lists. I've broken out this inheritance discussion from the LDAP Subentries internet draft so as to keep the two discussions separate and on-track. To the LDUP and LDAPEXT chairs: I'd appreciate a short time to discuss this document in one or both work group meetings in Minneapolis, if you think that appropriate. To Rick: Here's wondering if it arrives in base64 encoding for you ;-) Regards, Ed =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Ed Reed Reed-Matthews, Inc. +1 801 796 7065 http://www.Reed-Matthews.COM --=_7229D19F.1C7D1182 Content-Type: text/plain Content-Disposition: attachment; filename="draft-ietf-ldup-inheritance-00.txt" Content-Transfer-Encoding: base64 DQoKCgoKCklOVEVSTkVULURSQUZUIA0KZHJhZnQtaWV0Zi1sZHVwLWluaGVyaXRhbmNlLTAwLnR4 dCANCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg RWQgUmVlZCANCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgUmVlZC1N YXR0aGV3cywgSW5jLiANCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICBGZWJydWFyeSAyMSwgMjAwMSANCiANCiAgICAgICAgICAgUG9saWN5IEluaGVyaXRhbmNlIE1l Y2hhbmlzbXMgZm9yIExEQVAgDQogDQoKCjEgIFN0YXR1cyBvZiB0aGlzIE1lbW8gDQoKIA0KVGhp cyBkb2N1bWVudCBpcyBhbiBJbnRlcm5ldC1EcmFmdCBhbmQgaXMgaW4gZnVsbCBjb25mb3JtYW5j ZSB3aXRoIGFsbCANCnByb3Zpc2lvbnMgb2YgU2VjdGlvbiAxMCBvZiBSRkMyMDI2LiANCiANCklu dGVybmV0LURyYWZ0cyBhcmUgd29ya2luZyBkb2N1bWVudHMgb2YgdGhlIEludGVybmV0IEVuZ2lu ZWVyaW5nIFRhc2sgDQpGb3JjZSAoSUVURiksIGl0cyBhcmVhcywgYW5kIGl0cyB3b3JraW5nIGdy b3Vwcy4gTm90ZSB0aGF0IG90aGVyIGdyb3VwcyANCm1heSBhbHNvIGRpc3RyaWJ1dGUgd29ya2lu ZyBkb2N1bWVudHMgYXMgSW50ZXJuZXQtRHJhZnRzLiAgDQogDQpJbnRlcm5ldC1EcmFmdHMgYXJl IGRyYWZ0IGRvY3VtZW50cyB2YWxpZCBmb3IgYSBtYXhpbXVtIG9mIHNpeCBtb250aHMgDQphbmQg bWF5IGJlIHVwZGF0ZWQsIHJlcGxhY2VkLCBvciBvYnNvbGV0ZWQgYnkgb3RoZXIgZG9jdW1lbnRz IGF0IGFueSANCnRpbWUuIEl0IGlzIGluYXBwcm9wcmlhdGUgdG8gdXNlIEludGVybmV0LURyYWZ0 cyBhcyByZWZlcmVuY2UgbWF0ZXJpYWwgDQpvciB0byBjaXRlIHRoZW0gb3RoZXIgdGhhbiBhcyAi d29yayBpbiBwcm9ncmVzcy4iICANCiANClRoZSBsaXN0IG9mIGN1cnJlbnQgSW50ZXJuZXQtRHJh ZnRzIGNhbiBiZSBhY2Nlc3NlZCBhdCANCmh0dHA6Ly93d3cuaWV0Zi5vcmcvaWV0Zi8xaWQtYWJz dHJhY3RzLnR4dC4gIA0KIA0KVGhlIGxpc3Qgb2YgSW50ZXJuZXQtRHJhZnQgU2hhZG93IERpcmVj dG9yaWVzIGNhbiBiZSBhY2Nlc3NlZCBhdCANCmh0dHA6Ly93d3cuaWV0Zi5vcmcvc2hhZG93Lmh0 bWwuIA0KIA0KVGhpcyBJbnRlcm5ldC1EcmFmdCBleHBpcmVzIG9uIEF1Z3VzdCAyMSwgMjAwMS4g DQogDQoKCjIgIEFic3RyYWN0IC8gRGVzY3JpcHRpb24gDQoKVGhlcmUgYXJlIHNldmVyYWwgcG9z c2libGUgd2F5cyB0byBtYW5hZ2UgaW5oZXJpdGFuY2Ugb2YgcG9saWN5IA0KaW5mb3JtYXRpb24g aW4gYSBkaXJlY3Rvcnkgc2VydmljZS4gIFRoaXMgZG9jdW1lbnQgZGVzY3JpYmVzIHNldmVyYWwg DQprbm93biBtZWNoYW5pc21zIGFuZCByZWNvbW1lbmRzIG9uZSBmb3IgZ2VuZXJhbCB1c2UgdGhh dCBjYW4gYmUgDQppbXBsZW1lbnRlZCB1c2luZyBbTERVUF0uIA0KCgozICBQcmVhbWJsZSANCgpB dCB0aGUgU2FuIERpZWdvIElFVEYgKDQ5KSBpbiBEZWNlbWJlciAyMDAwIGEgYmFyIGJvZmYgKDEg cm91bmQgPSAkODkgDQpvciBzbyBVU0Qgc28gdGhlcmUgd2VyZSAyMC0zMCBwZW9wbGUgaW4gYXR0 ZW5kYW5jZSkgd2FzIGNvbnZlbmVkIHRvIA0KY29uc2lkZXIgaG93IHRvIGRlYWwgd2l0aCBpbmhl cml0YW5jZSBvZiBwb2xpY3kgZG93biB0aHJvdWdoIGEgdHJlZSANCmZyb20gc3VwZXJpb3IgdG8g c3Vib3JkaW5hdGUgY29udGV4dHMuICBUaGUgdG9waWMgY2FtZSB1cCBiZWNhdXNlIGl0J3MgDQph biBpc3N1ZSBmb3IgYWNjZXNzIGNvbnRyb2wgcG9saWN5LCB3aGljaCBtYW55IG9mIHVzIHdvdWxk IGxpa2UgdG8gc2VlIA0KYmUgYWJsZSB0byBiZSBpbmhlcml0YWJsZSBmcm9tIHBhcmVudHMgdG8g Y2hpbGRyZW4sIHNvIHRoYXQgYW4gYWNjZXNzIA0KZ3JhbnRlZCB0byBhIHBhcmVudCBvciBzdXBl cmlvciBvcmdhbml6YXRpb25hbCB1bml0LCBmb3IgaW5zdGFuY2UsIA0KY291bGQgYmUgaW50ZXJw cmV0ZWQgY29ycmVjdGx5IGFzIGJlaW5nIGltcGxpY2l0bHkgZ3JhbnRlZCB0byBhbGwgdGhlIA0K c3Vib3JkaW5hdGUgZW50cmllcyBvZiB0aGF0IHBhcmVudC4gICANCiANCgoKUmVlZCAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBbUGFnZSAxIG9mIDVdIA0KICAgICAg ICAgICAgICAgICAgRXhwaXJlcyBBdWd1c3QgMjEsIDIwMDEgDA0KCgpJTlRFUk5FVCBEUkFGVCAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICBGZWJydWFyeSAyMSwgMjAwMSANCiAgICAgICAg ICAgICBkcmFmdC1pZXRmLWxkdXAtaW5oZXJpdGFuY2UtMDAudHh0IA0KCk90aGVyIHBvbGljeSBp bmZvcm1hdGlvbiBjb3VsZCBiZW5lZml0IGZyb20gc3VjaCBpbmhlcml0YW5jZSwgYW5kIHRoZSAN CmdlbmVyYWwgY2FzZSBpcyB0aGF0IHBvbGljeSBzZXQgYXQgdGhlIHJvb3Qgb2YgYW4gZW50ZXJw cmlzZSAoZm9yIA0KaW5zdGFuY2UpIGFkbWluaXN0cmF0aXZlIGFyZWEgaXMgYXBwbGllZCB0byB0 aGUgd2hvbGUgb2YgdGhlIA0KYWRtaW5pc3RyYXRpdmUgYXJlYSwgZXZlbiBpZiB0aGUgYWRtaW5p c3RyYXRpdmUgYXJlYSBpcyBwYXJ0aXRpb25lZCBhbmQgDQpkaXN0cmlidXRlZCBhbW9uZyBzZXZl cmFsIHNlcnZlcnMgKG9yIGdyb3VwcyBvZiBzZXJ2ZXJzKSB0aHJvdWdob3V0IHRoZSANCmVudGVy cHJpc2UuICBSZWFsIHdvcmxkIGV4YW1wbGVzIGluY2x1ZGUgTm92ZWxsIE5EUyB0cmVlcywgTWlj cm9zb2Z0IA0KQURTIEZvcmVzdHMsIGFuZCBwcm9iYWJseSB0aGluZ3MgbGlrZSB0aGUgZGlyZWN0 b3J5IGluZm9ybWF0aW9uIHRyZWUgaW4gDQpYLjUwMCBmb3IgYSBjb3VudHJ5LCBhIGdvdmVybm1l bnRhbCBhZ2VuY3kgb3IgYW55IG90aGVyIHNvcnQgb2YgbGFyZ2UgDQpvcmdhbml6YXRpb24uIA0K Cgo0ICBUaGUgUmVxdWlyZW1lbnQgDQoKVG8gc3VwcG9ydCB0aGUga2luZCBvZiB0b3AtZG93biBw b2xpY3kgaW5oZXJpdGFuY2UgZGVzY3JpYmVkIGFib3ZlLCANCnNlcnZlcnMgaG9sZGluZyBzdWJv cmRpbmF0ZSBwYXJ0aXRpb25zIG9mIHRoZSBhZG1pbmlzdHJhdGl2ZSBhcmVhIChpbiANCm90aGVy IHdvcmRzLCBzaW1wbGUgc3VidHJlZXMgcm9vdGVkIGJlbG93IHRoZSByb290IG9mIHRoZSANCmFk bWluaXN0cmF0aXZlIGFyZWEgd2hlcmUgdGhlIHBvbGljeSBpcyBzZXQpIG5lZWQgdG8gYmUgaW5m b3JtZWQgb2YgdGhlIA0KcG9saWN5IHRoYXQgdGhleSBhcmUgc3VwcG9zZWQgdG8gaW5oZXJpdCBm cm9tIGFib3ZlLiANCiANCk5vdGUgdGhhdCBJJ3ZlIG5vdCBzYWlkIGFueXRoaW5nIGFib3V0IGhv dyB0aGUgcG9saWN5IGlzIHJlcHJlc2VudGVkIA0KeWV0LiAgSXQgbWF5IGJlIHZpYSBhdHRyaWJ1 dGVzIG9uIHRoZSByb290IG9mIHRoZSBhZG1pbmlzdHJhdGl2ZSBhcmVhLCANCm9yIGl0IG1heSBi ZSB2aWEgc3ViZW50cmllcyBsb2NhdGVkIGltbWVkaWF0ZWx5IHN1Ym9yZGluYXRlIHRvIHRoZSBy b290IA0Kb2YgdGhlIGFkbWluaXN0cmF0aXZlIGFyZWEsIG9yIGJ5IHNvbWUgb3RoZXIgbWVhbnMu ICBJbiBmYWN0LCBmb3IgdGhlIA0KZ2VuZXJhbCBjYXNlIHRoYXQgaW5jbHVkZXMgdGhlIGZ1bGwg WC41MDAgc3ViZW50cnkgZGVmaW5pdGlvbiB3aXRoIA0Kc3VidHJlZSBzcGVjaWZpY2F0aW9ucyBp biB0aGUgc3ViZW50cnksIGl0J3Mgb25seSBuZWNlc3NhcnkgdGhhdCB0aGUgDQpwb2xpY3kgc3Vi ZW50cnkgYXBwbGllcyB0byB0aGUgZW50cnkgYW5kIGl0cyBhdHRyaWJ1dGVzIGJlaW5nIGdvdmVy bmVkIA0KKEkgdGhpbmsgLSBEYXZpZD8gIEhlbG11dD8gIFJpY2hhcmQ/ICBPdGhlcnM/KSANCiAN ClNvIHRoZSBxdWVzdGlvbiBpcyBob3cgdG8gbWFrZSB0aGUgc3Vib3JkaW5hdGUgcGFydGl0aW9u IG9mIHRoZSANCm5hbWVzcGFjZSwgdGhhdCBkb2VzIG5vdCBuZWNlc3NhcmlseSBjby1yZXNpZGUg b24gYSBzZXJ2ZXIgd2hlcmUgdGhlIA0KYWRtaW5pc3RyYXRpdmUgYXJlYSBpcyByb290ZWQgYW5k IHdoZXJlIHRoZSBpbmhlcml0YWJsZSBnb3Zlcm5pbmcgDQpwb2xpY3kgaXMgYXNzZXJ0ZWQsIGhv dyBkb2VzIHRoYXQgc3Vib3JkaW5hdGUgbmFtZXNwYWNlICJrbm93IiBhYm91dCANCnRoZSBpbmhl cml0ZWQgcG9saWN5IHNvIHRoYXQgaXQgY2FuIGVuZm9yY2UgaXQ/IA0KCgo1ICBQb3NzaWJsZSBB cHByb2FjaGVzIChpbmNvbXBsZXRlIGxpc3QpIA0KClRoZXJlIGFyZSBzZXZlcmFsIHdheXMgdGhp cyBoYXMgYmVlbiBhcHByb2FjaGVkIGluIHRoZSBwYXN0LCBhbmQgb25lIA0KY2FuIGltYWdpbmUg bWFueSBvdGhlcnMuIA0KIA0KMSkgVGhlIGluaGVyaXRhYmxlIHBvbGljeSBjb3VsZCBiZSBhc3Nl cnRlZCB3aGVuIHN1cGVyaW9yL3N1Ym9yZGluYXRlIA0KcmVmZXJlbmNlcyBhcmUgYmVpbmcgYWRt aW5pc3RyYXRpdmVseSBzZXQgdG8gZ2x1ZSB0aGUgdHdvIG5hbWVzcGFjZXMgDQp0b2dldGhlciwg ZWl0aGVyIG1hbnVhbGx5IGJ5IHRoZSBhZG1pbmlzdHJhdG9ycyBvciBwcm9ncmFtbWF0aWNhbGx5 IHZpYSANCnNvbWUgaGllcmFyY2hpY2FsIG9wZXJhdGlvbmFsIGJpbmRpbmcgcHJvdG9jb2wsIGZv ciBpbnN0YW5jZS4gIEkgdGhpbmsgDQp0aGlzIGlzIGhvdyBYLjUwMCBpbXBsZW1lbnRhdGlvbnMg Z2VuZXJhbGx5IGhhbmRsZSBpdC4gW0VkaXRvcjogIGNoYW5nZSANCnRoaXMgdG8gYW4gYWZmaXJt YXRpdmUgc3RhdGVtZW50IHdoZW4gdmVyaWZpZWRdIA0KIA0KMikgQSBzcGVjaWFsaXplZCBmb3Jt IG9mIHJlcGxpY2F0aW9uIHRoYXQga25vd3Mgb2YgdGhlIG5lZWQgdG8gbWFpbnRhaW4gDQpjYWNo ZWQgaW5mb3JtYXRpb24gYWdncmVnYXRlZCBmcm9tIHN1cGVyaW9yIGFkbWluaXN0cmF0aXZlIGFy ZWFzIGluIHRoZSANCmRpcmVjdG9yeSBpbmZvcm1hdGlvbiB0cmVlIHRha2VzIHJlc3BvbnNpYmls aXR5IHRvIGlkZW50aWZ5IGluaGVyaXRhYmxlIA0KaW5mb3JtYXRpb24gYW5kIHRvIG1haW50YWlu IGNvcGllcyBvZiBpdCBvbiBvciBuZWFyIHN1Ym9yZGluYXRlIA0KcGFydGl0aW9uIHJvb3RzLiAg VGhpcyBtYWtlcyB0aGUgaW5mb3JtYXRpb24gYXZhaWxhYmxlIGxvY2FsbHkgdG8gdGhlIA0Kc3Vi b3JkaW5hdGUgbmFtZXNwYWNlIGluIGEgInJlYWQtb25seSIgZmFzaGlvbiB0aGF0IGZhY2lsaXRh dGVzIA0KZGVjaXNpb24tbWFraW5nIGFuZCBtYWtlcyB0aGUgc3BlY2lhbGl6ZWQgcmVwbGljYXRp b24gc2NoZW1lIA0KcmVzcG9uc2libGUgZm9yIHByb3BhZ2F0aW5nIHBvbGljeSBjaGFuZ2VzIHRv IGFsbCB0aGUgc3Vib3JkaW5hdGVzIHdoZW4gDQpuZWVkZWQuICBUaGlzIGlzIGhvdyBOb3ZlbGwn cyBORFMgZG9lcyBpdC4gICANCgoKUmVlZCAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICBbUGFnZSAyIG9mIDVdIA0KICAgICAgICAgICAgICAgICAgRXhwaXJlcyBBdWd1 c3QgMjEsIDIwMDEgDA0KCgpJTlRFUk5FVCBEUkFGVCAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICBGZWJydWFyeSAyMSwgMjAwMSANCiAgICAgICAgICAgICBkcmFmdC1pZXRmLWxkdXAtaW5o ZXJpdGFuY2UtMDAudHh0IA0KCiANCjMpIFNlcnZlcnMgaG9sZGluZyBzdWJvcmRpbmF0ZSBwYXJ0 aXRpb25zIG9mIGFuIGFkbWluaXN0cmF0aXZlIGFyZWEgY2FuIA0KIm9wcG9ydHVuaXN0aWNhbGx5 IGNhY2hlIiBwb2xpY3kgaW5mb3JtYXRpb24gbG9jYWxseS4gIEluIHRoaXMgDQpzY2VuYXJpbywg dGhlIGFjY2VzcyBjb250cm9sIHBvbGljeSBlbmdpbmUgKHByb2JhYmx5LCBhcyB0aGUgZGlyZWN0 IA0KY29uc3VtZXIgb2YgdGhlIGluaGVyaXRlZCBwb2xpY3kgaW5mb3JtYXRpb24gaW4gb25lIGV4 YW1wbGUpIGtub3dzIHRoYXQgDQpwb2xpY3kgaW5mb3JtYXRpb24gbWF5IGJlIGRlZmluZWQgaW4g c3VwZXJpb3IgYXJlYXMgb2YgdGhlIGRpcmVjdG9yeSANCmluZm9ybWF0aW9uIHRyZWUgdGhhdCBp dCBuZWVkcyB0byBrbm93IGFib3V0LCBhbmQgc28gaXQgIndhbGtzIHRoZSANCnRyZWUiIHVudGls IGl0IGZpbmRzIHdoYXQgaXMgY2xlYXJseSB0aGUgInRvcCIgb2YgdGhlIGF1dGhvcml0YXRpdmUg DQphZG1pbmlzdHJhdGl2ZSBhcmVhIHdpdGhpbiB3aGljaCBpdCBpcyBzdXBwb3NlZCB0byBvcGVy YXRlLiAgKEkgc2F5IGl0IA0KdGhpcyB3YXkgdG8gaGlnaGxpZ2h0IHRoYXQgdGhlIHN1Ym9yZGlu YXRlIG1heSB3ZWxsIGtub3cgaXRzIG5vdCANCnN1cHBvc2VkIHRvIHdhbGsgdGhlIHRyZWUgYWxs IHRoZSB3YXkgdG8gImRjPWNvbSIsIGZvciBpbnN0YW5jZSwgaWYgdGhlIA0Kcm9vdCBvZiB0aGUg b3JnYW5pemF0aW9ucyBhZG1pbmlzdHJhdGl2ZSBhcmVhIGlzICJkYz1vbmNhbGxkYmEsIA0KZGM9 Y29tIiwgZm9yIGluc3RhbmNlKSAgQXQgYW55IHJhdGUsIHRoZSBwb2xpY3kgZW5naW5lIHdhbGtz IHRoZSB0cmVlIA0KImFzIGZhciBhcyBpdHMgc3VwcG9zZWQgdG8gZ28iIGFjY3VtdWxhdGluZyBw b2xpY3kgaW5mb3JtYXRpb24gdGhhdCANCmFwcGxpZXMgdG8gaXQgYW5kIGNhY2hpbmcgaXQgbG9j YWxseSBmb3IgZnV0dXJlIHVzZS4gIFRoZSB3YWxrIHdvdWxkIA0KdGFrZSBwbGFjZSBhdCBzZXJ2 ZXIgc3RhcnR1cCB0aW1lLCBvciB3aGVuIHRoZSBwYXJ0aXRpb24gaXMgcGxhY2VkICJpbiANCnNl cnZpY2UiIChpZiBpdCBldmVyIGdvZXMgb2ZmIGxpbmUpLCBvciBvbiBzY2hlZHVsZWQgImhhcyBh bnl0aGluZyANCmNoYW5nZWQgSSBuZWVkIHRvIGtub3cgYWJvdXQiIHdhbGthYm91dHMuICBFYWNo IHBvbGljeSBlbmdpbmUgd291bGQgYmUgDQpyZXNwb25zaWJsZSBmb3IgaXRzIG93biBjYWNoZSBv ZiBpbmZvcm1hdGlvbiBhbmQgaXRzIG93biB3YWxrYWJvdXRzIChJIA0KbGlrZSB0aGF0IHRlcm0g Zm9yIHRoaXMuLi4pIA0KIA0KNCkgd2hlbmV2ZXIgcG9saWN5IGlzIGRlZmluZWQgYXQgYW4gYWRt aW5pc3RyYXRpdmUgcG9pbnQgdGhhdCBhcHBsaWVzIA0KdG8gc3Vib3JkaW5hdGUgZW50cmllcywg YSBwcm9jZXNzIChlaXRoZXIgY2xpZW50IG9yIHNlcnZlci1iYXNlZCwgb3IgDQpzb21lIGNvbWJp bmF0aW9uIG9mIGJvdGgpIHBlcmZvcm1zIHRoZSBpbnZlcnNlIHRvIHRoZSB3YWxrYWJvdXQgDQpk ZXNjcmliZWQgaW4gIzMgYWJvdmUgLSB0aGF0IGlzLCBpdCBkZXNjZW5kcyB0aGUgdHJlZSBkZXBv c2l0aW5nIHBvbGljeSANCmluZm9ybWF0aW9uIChvciBjaGFuZ2luZyBwb2xpY3kgaW5mb3JtYXRp b24gaXQgZmluZHMgdGhlcmUpIG9uIA0Kc3Vib3JkaW5hdGUgZW50cmllcyAoZWl0aGVyIG9uIHBh cnRpdGlvbiByb290cyBvciBvbiBlYWNoIGxlYWYgZW50cnkgDQppdHNlbGYpIGFzIGl0IGdvZXMu ICBUaGlzIGFwcHJvYWNoIGhhcyB0aGUgYmVuZWZpdCBvZiAicHVzaGluZyIgY2hhbmdlcyANCmZy b20gdGhlIHBvaW50IG9mIGFkbWluaXN0cmF0aXZlIGFjdGlvbiB0byBhbGwgdGhlIGFyZWFzIHN1 YmplY3QgdG8gdGhlIA0KcG9saWN5IGNoYW5nZSwgcmF0aGVyIHRoYW4gcmVseWluZyBvbiB0aGUg Im9wcG9ydHVuaXN0aWMgY2FjaGUiIG9mICMzLiAgDQpXaXRoIHNvbWUgY2FyZSwgaXQgbmVlZCBu b3QgYmUgYW55IG1vcmUgYmFuZHdpZHRoIGNvbnN1bWluZyB0aGFuIHRoZSANCnNwZWNpYWxpemVk IHJlcGxpY2F0aW9uIHNjaGVtZSBkZXNjcmliZWQgaW4gIzIgYWJvdmUuICBBbmQgaXMgbW9yZSAN CmR5bmFtaWMgdGhhbiB0aGUgc3RhdGljIGNvbmZpZ3VyYXRpb24gb2YgIzEgYWJvdmUuICBJIHRo aW5rIHRoaXMgaXMgDQpnZW5lcmFsbHkgaG93IE1pY3Jvc29mdCBoYW5kbGVzIGluaGVyaXRhYmxl IHBvbGljeSBmb3IgYWNjZXNzIA0KY29udHJvbHMuICBbRWRpdG9yOiAgY2hhbmdlIHRoaXMgdG8g YW4gYWZmaXJtYXRpdmUgc3RhdGVtZW50IHdoZW4gDQp2ZXJpZmllZF0gIA0KIA0KW0VkaXRvcmlh bCBub3RlIC0gdGhpcyBub3RlIGFscmVhZHkgY292ZXJzIG1vcmUgdGhhbiB3ZSBkaXNjdXNzZWQg YXQgDQp0aGUgYmFyIGJvZmZdIA0KIA0KVGhlcmUgYXJlIHByb2JhYmx5IG90aGVyIGFwcHJvYWNo ZXMuICBJbiBmYWN0LCB3ZSBjYW1lIHVwIHdpdGggb25lIG1vcmUgDQphdCB0aGUgYmFyIGJvZmYu IA0KIA0KNSkgRWFjaCBzZXJ2ZXIgaG9sZGluZyBhIHN1Ym9yZGluYXRlIHBhcnRpdGlvbiBvZiBh biBhZG1pbmlzdHJhdGl2ZSANCmFyZWEgY291bGQgYWxzbyBob2xkIGEgInNwYXJzZSByZXBsaWNh IiBvZiB0aGUgb3RoZXJ3aXNlIG5vbi1yZXNpZGVudCANCnN1cGVyaW9yIGFkbWluaXN0cmF0aXZl IGFyZWFzIHRoYXQgaG9sZCBwb2xpY3kgaW5mb3JtYXRpb24gcmVsZXZhbnQgdG8gDQp0aGUgcGFy dGl0aW9uIGl0IGRvZXMgaG9sZC4gIFRoaXMgYXBwcm9hY2ggd291bGQgYWxsb3cgTERVUCB0byBi ZSANCnJlc3BvbnNpYmxlIGZvciBwcm9wYWdhdGluZyBjaGFuZ2VzIHRvIHBvbGljeSAiYXMgd3Jp dHRlbiIgdG8gDQpzdWJvcmRpbmF0ZSBzZXJ2ZXJzIHRoYXQgbmVlZCBpdCwgYXZvaWRzIGNyZWF0 aW5nIHNwZWNpYWxpemVkIA0KbWVjaGFuaXNtcyB0aGF0IG5lZWQgdG8ga25vdyBob3cgdG8gYWdn cmVnYXRlIHBvbGljeSBpbmZvcm1hdGlvbiANCnRocm91Z2ggbXVsdGlwbGUgdGllcnMgb2YgYWRt aW5pc3RyYXRpdmUgYXJlYSByb290cyAoc29tZXRoaW5nIGJvdGggIzIgDQphbmQgIzQgcmVxdWly ZSwgYW5kIHNvbWV0aGluZyBJIGZvciBvbmUgcmVhbGx5LCByZWFsbHksIHJlYWxseSBkb24ndCAN CndhbnQgdG8gdHJ5IHRvIGdlbmVyYWxpemUgZm9yIGEgc3RhbmRhcmQpLCBsZWF2ZXMgaW50ZXJw cmV0YXRpb24gb2YgDQpzdXBlcmlvciBwb2xpY3kgZW50aXJlbHkgdXAgdG8gdGhlIGxvY2FsIHBv bGljeSBkZWNpc2lvbiBmdW5jdGlvbnMgDQood2hlcmUgaXQgYmVsb25ncykgYW5kICJvbmx5IiBy ZXF1aXJlcyByZWFkLW9ubHkgcmVwbGljYXMgb2YgdGhlIA0Kc3VwZXJpb3IgYWRtaW5pc3RyYXRp dmUgcm9vdCBlbnRyeSBhbmQgaXRzIHN1YmVudHJpZXMuICAgDQogDQoKUmVlZCAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBbUGFnZSAzIG9mIDVdIA0KICAgICAgICAg ICAgICAgICAgRXhwaXJlcyBBdWd1c3QgMjEsIDIwMDEgDA0KCgpJTlRFUk5FVCBEUkFGVCAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICBGZWJydWFyeSAyMSwgMjAwMSANCiAgICAgICAgICAg ICBkcmFmdC1pZXRmLWxkdXAtaW5oZXJpdGFuY2UtMDAudHh0IA0KCkJlaW5nICJyZWFkLW9ubHki IHJlcGxpY2FzLCB0aGUgTERVUCBob3VzZSBrZWVwaW5nIGlzIGtlcHQgdG8gYSBtaW5pbXVtIA0K KGJlY2F1c2UgdGhlcmUgd2lsbCBuZXZlciBiZSBjaGFuZ2VzIGZsb3dpbmcgZnJvbSB0aGUgc3Vi b3JkaW5hdGUgY29weSANCnRvIHRoZSBhZG1pbmlzdHJhdGl2ZSBhcmVhIHJvb3QgIm1hc3RlciIg cmVwbGljYSkuICBUaGVyZSB3aWxsIGJlIA0KcmVwbGljYXRpb24gdHJhZmZpYywgd2hpY2ggY2Fu IGJlIHNjaGVkdWxlZCBvciBldmVudCBkcml2ZW4uICBUaGUgDQpzcGFyc2UgcmVwbGljYSByZXBs aWNhdGlvbiBhZ3JlZW1lbnRzIGNhbiBiZSBzZXQgdmlhIGFkbWluaXN0cmF0b3JzIHRvIA0KY29u dHJvbCBob3cgb3Igd2hhdCBzdWJlbnRyaWVzIGFyZSByZXBsaWNhdGVkIChtYXliZSBvbmx5IHRo b3NlIGZsYWdnZWQgDQoiaW5oZXJpdGFibGUiKS4gIEFzIGEgcmVhZC1vbmx5IHJlcGxpY2EsIGl0 IGNhbiBiZSBjb25maWd1cmVkIHZpYSANCnRyYW5zaXRpdmUgc3luY2ggdG8gdGFrZSBpdHMgY2hh bmdlcyBmcm9tIGFub3RoZXIgcmVhZC1vbmx5IHJlcGxpY2Egc28gDQp5b3UgZG9uJ3QgSEFWRSB0 byBoYXZlIHRoZSBzaXR1YXRpb24gd2hlcmUgZXZlcnkgc2VydmVyIGluIHRoZSANCmVudGVycHJp c2UgaXMgYmFuZ2luZyBhd2F5IGF0IHRoZSByb290LW1vc3QgbWFzdGVyIHNlcnZlciBmb3IgcG9s aWN5IA0KaW5mb3JtYXRpb24sIHNvIHdlIHNob3VsZCBiZSBhYmxlIHRvIG1hbmFnZSB0aGUgbmV0 d29yayB0cmFmZmljIHNjYWxpbmcgDQppc3N1ZXMgaW4gbGFyZ2UgdHJlZXMgKHRob3VnaCBpdHMg dHJ1ZSB0aGF0IHVzaW5nIHRyYW5zaXRpdmUgc3luY2ggDQpsZW5ndGhlbnMgdGhlIHRpbWUgaXQg dGFrZXMgZm9yIGNoYW5nZXMgdG8gcHJvcGFnYXRlIHRvIGFsbCBzZXJ2ZXJzKS4gIA0KQW5kLCBp ZiB5b3UgZG9uJ3QgbmVlZCBpdCwgZG9uJ3QgdXNlIGl0LiAgIA0KIA0KVGhpcyBpcyBlZmZlY3Rp dmVseSBob3cgTm92ZWxsIG1hbmFnZXMgc2NoZW1hIHBvbGljeSBwcm9wYWdhdGlvbiANCnRocm91 Z2ggdGhlaXIgdHJlZXMsIGFuZCBbbWF5IJYgRWRpdG9yOiB2ZXJpZnldIGFsc28gaG93IE1pY3Jv c29mdCANCmhhbmRsZXMgc2NoZW1hIHByb3BhZ2F0aW9uIHRocm91Z2ggdGhlaXIgZm9yZXN0cy4g DQogDQpUaGUgY29vbCB0aGluZyBpcyB0aGF0IHRoaXMgYXBwcm9hY2ggd29ya3MgZm9yIGFueSBu dW1iZXIgb2YgDQppbmhlcml0YWJsZSBwb2xpY3kgaW5mb3JtYXRpb24sIGluY2x1ZGluZyBzY2hl bWEsIHBhc3N3b3JkIHBvbGljeSwgZXRjLiANCmFzIHdlbGwgYXMgZm9yIGFjY2VzcyBjb250cm9s IGluZm9ybWF0aW9uLiANCgoKNiAgQ29uY2x1c2lvbiBhbmQgUmVjb21tZW5kYXRpb24gDQoKVGhl IHJlc3VsdCBvZiB0aGUgYmFyIGJvZmYgd2FzIHRoZSBwdWJsaWNhdGlvbiBvZiB0aGlzIG5vdGUu ICAgDQogDQpUaGUgcmVjb21tZW5kYXRpb24gb2YgdGhpcyBub3RlIGlzIHRoYXQgbWVjaGFuaXNt ICM1IGFib3ZlIGJlIHVzZWQgdG8gDQpwcm9wYWdhdGUgcG9saWN5IGluZm9ybWF0aW9uIHVzaW5n IExEVVAgd2hlbiBzdWJvcmRpbmF0ZSBwYXJ0aXRpb25zIG9mIA0KYSBkaXJlY3RvcnkgaW5mb3Jt YXRpb24gdHJlZSBuZWVkIHRvIGtub3cgYWJvdXQgaW5oZXJpdGVkIHBvbGljeSB0aGF0IA0KYWZm ZWN0cyB0aGVtLiAgVGhlIGFwcHJvYWNoIGhhcyB0aGUgYmVuZWZpdHMgb2YgaGF2aW5nIGNvbnNp ZGVyYWJsZSANCm9wZXJhdGlvbmFsIGV4cGVyaWVuY2UgaW4gZW50ZXJwcmlzZS1zY2FsZSBkaXJl Y3RvcnkgZGVwbG95bWVudHMsIHVzZXMgDQpbTERVUF0gaW4gYSBtYW5uZXIgY29uc2lzdGVudCB3 aXRoIGl0cyBpbnRlbmRlZCB1c2FnZSwgYXZvaWRzIHRyeWluZyB0byANCmNyZWF0ZSBhIG5ldyBn ZW5lcmFsaXplZCBkZXNjcmlwdGlvbiBvZiBpbmhlcml0YW5jZSBhZ2dyZWdhdGlvbiAoYW5kIA0K bGVhdmVzIHRoYXQgdG8gdGhlIGFwcGxpY2F0aW9ucyB3aG8gd2lsbCBkZWZpbmUgdGhlaXIgb3du IHJlcXVpcmVkIA0Kc2VtYW50aWNzLCBhbnl3YXkpLCBhbmQgZ2VuZXJhbGx5IGFjY29tcGxpc2hl cyB0aGUgKGxpbWl0ZWQpIG9iamVjdGl2ZXMgDQpzZXQgb3V0IGluIHRoZSByZXF1aXJlbWVudCBz dGF0ZW1lbnQgYWJvdmUuIA0KIA0KCgo3ICBSZWZlcmVuY2VzIA0KCltMRFVQXSByZWZlcnMgdG8g dGhlIGNvbGxlY3Rpb24gb2YgSW50ZXJuZXQgZHJhZnRzIGFuZCBSRkNzIHdoaWNoIA0KZGVzY3Jp YmUgdGhlIHJlcXVpcmVtZW50cywgYXJjaGl0ZWN0dXJlLCBzY2hlbWEsIGNvbmZsaWN0IHJlc29s dXRpb24gDQpwcm9jZWR1cmVzLCBldGMuIHRoYXQgYXJlIGF2YWlsYWJsZSBmcm9tIHRoZSBMRFVQ IGhvbWUgcGFnZTogDQogICAgIGh0dHA6Ly93d3cuaWV0Zi5vcmcvaHRtbC5jaGFydGVycy9sZHVw LWNoYXJ0ZXIuaHRtbCANCgoKOCAgQ29weXJpZ2h0IE5vdGljZSANCgpDb3B5cmlnaHQgKEMpIFRo ZSBJbnRlcm5ldCBTb2NpZXR5ICgyMDAxKS4gQWxsIFJpZ2h0cyBSZXNlcnZlZC4gIA0KIA0KVGhp cyBkb2N1bWVudCBhbmQgdHJhbnNsYXRpb25zIG9mIGl0IG1heSBiZSBjb3BpZWQgYW5kIGZ1cm5p c2hlZCB0byANCm90aGVycywgYW5kIGRlcml2YXRpdmUgd29ya3MgdGhhdCBjb21tZW50IG9uIG9y IG90aGVyd2lzZSBleHBsYWluIGl0IG9yIA0KYXNzaXN0IGluIGl0cyBpbXBsZW1lbnRhdGlvbiBt YXkgYmUgcHJlcGFyZWQsIGNvcGllZCwgcHVibGlzaGVkIGFuZCANCgpSZWVkICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIFtQYWdlIDQgb2YgNV0gDQogICAgICAgICAg ICAgICAgICBFeHBpcmVzIEF1Z3VzdCAyMSwgMjAwMSAMDQoKCklOVEVSTkVUIERSQUZUICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgIEZlYnJ1YXJ5IDIxLCAyMDAxIA0KICAgICAgICAgICAg IGRyYWZ0LWlldGYtbGR1cC1pbmhlcml0YW5jZS0wMC50eHQgDQoKZGlzdHJpYnV0ZWQsIGluIHdo b2xlIG9yIGluIHBhcnQsIHdpdGhvdXQgcmVzdHJpY3Rpb24gb2YgYW55IGtpbmQsIA0KcHJvdmlk ZWQgdGhhdCB0aGUgYWJvdmUgY29weXJpZ2h0IG5vdGljZSBhbmQgdGhpcyBwYXJhZ3JhcGggYXJl IA0KaW5jbHVkZWQgb24gYWxsIHN1Y2ggY29waWVzIGFuZCBkZXJpdmF0aXZlIHdvcmtzLiBIb3dl dmVyLCB0aGlzIA0KZG9jdW1lbnQgaXRzZWxmIG1heSBub3QgYmUgbW9kaWZpZWQgaW4gYW55IHdh eSwgc3VjaCBhcyBieSByZW1vdmluZyB0aGUgDQpjb3B5cmlnaHQgbm90aWNlIG9yIHJlZmVyZW5j ZXMgdG8gdGhlIEludGVybmV0IFNvY2lldHkgb3Igb3RoZXIgDQpJbnRlcm5ldCBvcmdhbml6YXRp b25zLCBleGNlcHQgYXMgbmVlZGVkIGZvciB0aGUgcHVycG9zZSBvZiBkZXZlbG9waW5nIA0KSW50 ZXJuZXQgc3RhbmRhcmRzIGluIHdoaWNoIGNhc2UgdGhlIHByb2NlZHVyZXMgZm9yIGNvcHlyaWdo dHMgZGVmaW5lZCANCmluIHRoZSBJbnRlcm5ldCBTdGFuZGFyZHMgcHJvY2VzcyBtdXN0IGJlIGZv bGxvd2VkLCBvciBhcyByZXF1aXJlZCB0byANCnRyYW5zbGF0ZSBpdCBpbnRvIGxhbmd1YWdlcyBv dGhlciB0aGFuIEVuZ2xpc2guIA0KIA0KVGhlIGxpbWl0ZWQgcGVybWlzc2lvbnMgZ3JhbnRlZCBh Ym92ZSBhcmUgcGVycGV0dWFsIGFuZCB3aWxsIG5vdCBiZSANCnJldm9rZWQgYnkgdGhlIEludGVy bmV0IFNvY2lldHkgb3IgaXRzIHN1Y2Nlc3NvcnMgb3IgYXNzaWducy4gDQogDQpUaGlzIGRvY3Vt ZW50IGFuZCB0aGUgaW5mb3JtYXRpb24gY29udGFpbmVkIGhlcmVpbiBpcyBwcm92aWRlZCBvbiBh biANCiJBUyBJUyIgYmFzaXMgYW5kIFRIRSBJTlRFUk5FVCBTT0NJRVRZIEFORCBUSEUgSU5URVJO RVQgRU5HSU5FRVJJTkcgDQpUQVNLIEZPUkNFIERJU0NMQUlNUyBBTEwgV0FSUkFOVElFUywgRVhQ UkVTUyBPUiBJTVBMSUVELCBJTkNMVURJTkcgQlVUIA0KTk9UIExJTUlURUQgVE8gQU5ZIFdBUlJB TlRZIFRIQVQgVEhFIFVTRSBPRiBUSEUgSU5GT1JNQVRJT04gSEVSRUlOIFdJTEwgDQpOT1QgSU5G UklOR0UgQU5ZIFJJR0hUUyBPUiBBTlkgSU1QTElFRCBXQVJSQU5USUVTIE9GIE1FUkNIQU5UQUJJ TElUWSBPUiANCkZJVE5FU1MgRk9SIEEgUEFSVElDVUxBUiBQVVJQT1NFLiIgDQogDQoKCjkgIEF1 dGhvcpJzIEFkZHJlc3MgDQoKRWR3YXJkcyBFLiBSZWVkIA0KUmVlZC1NYXR0aGV3cywgSW5jLiAN CjEwNjQgRSAxNDAgTm9ydGggDQpMaW5kb24sIFVUICA4NDA0MiANClVTQSANCkUtbWFpbDogZWVy QG9uY2FsbGRiYS5jb20gIA0KICAgICAgDQpMRFVQIE1haWxpbmcgTGlzdDogaWV0Zi1sZHVwQGlt Yy5vcmcgIA0KTERBUEVYVCBNYWlsaW5nIExpc3Q6IGlldGYtbGRhcGV4dEBuZXRzY2FwZS5jb20g DQoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKClJlZWQgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgW1BhZ2UgNSBvZiA1XSANCiAgICAgICAgICAgICAgICAgIEV4cGlyZXMg QXVndXN0IDIxLCAyMDAxIAw= --=_7229D19F.1C7D1182-- From owner-ietf-ldup@mail.imc.org Wed Feb 21 17:12:45 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA12300 for ; Wed, 21 Feb 2001 17:12:44 -0500 (EST) Received: by above.proper.com (8.9.3/8.9.3) id NAA26029 for ietf-ldup-bks; Wed, 21 Feb 2001 13:29:54 -0800 (PST) Received: from pretender.boolean.net (root@router.boolean.net [198.144.206.49]) by above.proper.com (8.9.3/8.9.3) with ESMTP id NAA26024 for ; Wed, 21 Feb 2001 13:29:53 -0800 (PST) Received: from gypsy.OpenLDAP.org (gypsy.boolean.net [10.192.1.2]) by pretender.boolean.net (8.11.1/8.11.1/Boolean/Hub) with ESMTP id f1LLSxD26195; Wed, 21 Feb 2001 21:28:59 GMT (envelope-from Kurt@OpenLDAP.org) Message-Id: <5.0.2.1.0.20010221132250.00ab6c00@router.boolean.net> X-Sender: guru@router.boolean.net X-Mailer: QUALCOMM Windows Eudora Version 5.0.2 Date: Wed, 21 Feb 2001 13:28:58 -0800 To: Richard Huber From: "Kurt D. Zeilenga" Subject: Re: additional comments: draft-ietf-ldup-replica-req-06.txt Cc: ietf-ldup@imc.org In-Reply-To: <3A9430B9.3E6E3416@att.com> References: <5.0.2.1.0.20010219203244.00a90b20@router.boolean.net> 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:18 PM 2/21/01 -0500, Richard Huber wrote: >> > Consistency models 1, 2 and 3 involve the use of prearranged >> > replication agreements among servers. The added complexity of the >> > distributed 2-phase commit required for Model 1 is significant; >> > therefor, model 1 will not be considered at this time. >> >> I would like the above sentence replaced with >> "While Model 1 is required to provide atomicity, the complexity >> of distributed 2-phase commit required for Model 1 is significant >> and, therefor, Model 1 is not to be considered at this time." >> >> or like statement which highlights the lost capabilities of this >> choice. [note, I do not intend to re-discuss the choice, but >> to clarify the pros and cons of the choice]. > >We disagree with this because we don't feel that model 2 can never support >atomicity. For example, in single-master it should be fairly >straightforward. How about: While Model 1 is required to provide atomicity in multiple master replication is used, the complexity of distributed 2-phase commit required for Model 1 is significant and, therefor, Model 1 is not to be considered at this time. From owner-ietf-ldup@mail.imc.org Wed Feb 21 17:13:25 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA12311 for ; Wed, 21 Feb 2001 17:13:24 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.9.3/8.9.3) id NAA25567 for ietf-ldup-bks; Wed, 21 Feb 2001 13:20:09 -0800 (PST) Received: from ckmso1.proxy.att.com (ckmso1.att.com [12.20.58.69]) by above.proper.com (8.9.3/8.9.3) with ESMTP id NAA25563 for ; Wed, 21 Feb 2001 13:20:07 -0800 (PST) Received: from qsun.mt.att.com ([135.16.31.2]) by ckmso1.proxy.att.com (AT&T IPNS/MSO-3.0) with SMTP id f1LLJV107208; Wed, 21 Feb 2001 16:19:32 -0500 (EST) Received: from att.com by qsun.mt.att.com (SMI-8.6/ATTEMS-1.4.1 sol2) id QAA19296; Wed, 21 Feb 2001 16:19:30 -0500 Message-ID: <3A9430B9.3E6E3416@att.com> Date: Wed, 21 Feb 2001 16:18:49 -0500 From: Richard Huber X-Mailer: Mozilla 4.75 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: "Kurt D. Zeilenga" CC: ietf-ldup@imc.org Subject: Re: additional comments: draft-ietf-ldup-replica-req-06.txt References: <5.0.2.1.0.20010219203244.00a90b20@router.boolean.net> 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 Comments are embedded in the copy below. Look for lines that are not quoted with ">" or whatever. Rick Huber "Kurt D. Zeilenga" wrote: > This post provides comments in addition to my past posts. > > draft-ietf-ldup-replica-req-06.txt [trimmed]: > > There are five data consistency models. > > > > Model 1: Transactional Consistency -- Environments that exhibit all > > four of the ACID properties (Atomicity, Concurrency, Independence, > > Durability) [ACID]. > > > > Model 2: Eventual (or Transient) Consistency -- Environments where > > definite knowledge of the topology is provided through predetermined > > replication agreements. Examples include X.500 Directories > > I would like a note added here that X.500 replication model > is single master. OK. We'll add that. > > Consistency models 1, 2 and 3 involve the use of prearranged > > replication agreements among servers. The added complexity of the > > distributed 2-phase commit required for Model 1 is significant; > > therefor, model 1 will not be considered at this time. > > I would like the above sentence replaced with > "While Model 1 is required to provide atomicity, the complexity > of distributed 2-phase commit required for Model 1 is significant > and, therefor, Model 1 is not to be considered at this time." > > or like statement which highlights the lost capabilities of this > choice. [note, I do not intend to re-discuss the choice, but > to clarify the pros and cons of the choice]. We disagree with this because we don't feel that model 2 can never support atomicity. For example, in single-master it should be fairly straightforward. > > Interoperability of replicas between directory servers may be limited > > by servers that implement semantics that go beyond what the LDAP access > > protocol defines. > > Or optional features the protocol defines (such as subtypes). > > > Examples (not an exhaustive list) of such semantics > > include: (1) replication among directory servers with different access > > control systems/semantics may compromise directory security, and (2) > > replication among directory servers with different application trigger > > semantics may compromise directory data integrity. > > I'd like to see knowledge information representation/semantics > added to this non-exhaustive list. The reason we made it clear that this is NOT an exhaustive list is that we were afraid that people would start adding to it. We would strongly prefer to not extend the list at this point. > > 4 Requirements > > I would like a section added discussing RFC 2251 statements > which imply requirements upon replicas. In particular, the > statement regarding access controls constraints and "equally > capable" servers. We have already specified that LDUP must replicate access controls (M4) and have mentioned that security may be impacted if the replicating servers do not share an access control model (sections 3, 5). It's not clear what the proposed change would add to the requirements. > > M2. The replication model MUST support both master-slave and multi- > > master relationships. > > How about mixed relationships? M masters and N slaves? > Is there a minimum number of masters the model must support? > More generally, are there topologies which must be supported? > Are there topologies which need not be supported? Well, since we discuss single-master, the minimum number of masters that must be supported is one (hey, we have to be able to joke about SOMETHING). More seriously, we are not convinced that adding this sort of discussion would change anything. Since the definition of "slave replica" includes "Read-only replicas may occur in both single- and multi-master systems.", mixed systems are clearly supported by the requirements. > > M4. LDAP replication MUST encompass schema definitions, attribute > > names and values, access control information, and name space > > information. > > I suggest adding "knowledge information" to this list. I'd also > think the MUST could be a SHOULD. We feel that M4 MUST remain MUST. Remember, these are requirements for the LDUP model and protocol, not for a particular implementation of that protocol. We could live with adding "knowledge information". From owner-ietf-ldup@mail.imc.org Wed Feb 21 18:10:02 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA13561 for ; Wed, 21 Feb 2001 18:10:01 -0500 (EST) Received: by above.proper.com (8.9.3/8.9.3) id OAA28875 for ietf-ldup-bks; Wed, 21 Feb 2001 14:27:41 -0800 (PST) Received: from DF-INET-1.dogfoodinternet.com (df-inet1.exchange.microsoft.com [131.107.8.8]) by above.proper.com (8.9.3/8.9.3) with ESMTP id OAA28870 for ; Wed, 21 Feb 2001 14:27:40 -0800 (PST) Received: from df-virus2.platinum.corp.microsoft.com ([172.30.236.33]) by DF-INET-1.dogfoodinternet.com with Microsoft SMTPSVC(5.0.2195.2831); Wed, 21 Feb 2001 14:15:30 -0800 Received: from 172.30.236.11 by df-virus2.platinum.corp.microsoft.com (InterScan E-Mail VirusWall NT); Wed, 21 Feb 2001 14:14:37 -0800 (Pacific Standard Time) Received: from DF-BOWWOW.platinum.corp.microsoft.com ([172.30.236.100]) by yuri.dns.microsoft.com with Microsoft SMTPSVC(5.0.2195.2831); Wed, 21 Feb 2001 14:14:37 -0800 Subject: RE: additional comments: draft-ietf-ldup-replica-req-06.txt Date: Wed, 21 Feb 2001 14:14:36 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Message-ID: <5B90AD65A9E8934987DB0C8C0762657404088594@DF-BOWWOW.platinum.corp.microsoft.com> X-MimeOLE: Produced By Microsoft Exchange V6.0.4653.0 content-class: urn:content-classes:message Thread-Topic: additional comments: draft-ietf-ldup-replica-req-06.txt Thread-Index: AcCcUpLIsMSZsvPvRe+Ody/26u6GowAAGWHw From: "Mark Brown (REDMOND)" To: "Kurt D. Zeilenga" , "Richard Huber" Cc: X-OriginalArrivalTime: 21 Feb 2001 22:14:37.0320 (UTC) FILETIME=[AD7C5880:01C09C53] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id OAA28871 Sender: owner-ietf-ldup@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 8bit "the complexity of distributed 2-phase commit required for Model 1 is significant and, therefor, Model 1 is not to be considered at this time." I was suprised to read that the complexity of distributed two-phase commit is what causes it to be excluded. Distributed two-phase commit is in fact a wonderful system simplifier when it applies. I expected to read that the lack of site autonomy inherent in distributed two-phase commit makes it unsuitable. --mark -----Original Message----- From: Kurt D. Zeilenga [mailto:Kurt@OpenLDAP.org] Sent: Wednesday, February 21, 2001 1:29 PM To: Richard Huber Cc: ietf-ldup@imc.org Subject: Re: additional comments: draft-ietf-ldup-replica-req-06.txt At 04:18 PM 2/21/01 -0500, Richard Huber wrote: >> > Consistency models 1, 2 and 3 involve the use of prearranged >> > replication agreements among servers. The added complexity of the >> > distributed 2-phase commit required for Model 1 is significant; >> > therefor, model 1 will not be considered at this time. >> >> I would like the above sentence replaced with >> "While Model 1 is required to provide atomicity, the complexity >> of distributed 2-phase commit required for Model 1 is significant >> and, therefor, Model 1 is not to be considered at this time." >> >> or like statement which highlights the lost capabilities of this >> choice. [note, I do not intend to re-discuss the choice, but >> to clarify the pros and cons of the choice]. > >We disagree with this because we don't feel that model 2 can never support >atomicity. For example, in single-master it should be fairly >straightforward. How about: While Model 1 is required to provide atomicity in multiple master replication is used, the complexity of distributed 2-phase commit required for Model 1 is significant and, therefor, Model 1 is not to be considered at this time. From owner-ietf-ldup@mail.imc.org Thu Feb 22 12:07:12 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA18566 for ; Thu, 22 Feb 2001 12:07:10 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.9.3/8.9.3) id IAA21270 for ietf-ldup-bks; Thu, 22 Feb 2001 08:12:41 -0800 (PST) Received: from kcmso1.proxy.att.com (kcmso1.att.com [192.128.133.69]) by above.proper.com (8.9.3/8.9.3) with ESMTP id IAA21266 for ; Thu, 22 Feb 2001 08:12:39 -0800 (PST) Received: from qsun.mt.att.com ([135.16.30.2]) by kcmso1.proxy.att.com (AT&T IPNS/MSO-3.0) with SMTP id f1MGC7604471; Thu, 22 Feb 2001 11:12:07 -0500 (EST) Received: from att.com by qsun.mt.att.com (SMI-8.6/ATTEMS-1.4.1 sol2) id LAA21841; Thu, 22 Feb 2001 11:12:06 -0500 Message-ID: <3A953A2A.8E9856E0@att.com> Date: Thu, 22 Feb 2001 11:11:23 -0500 From: Richard Huber X-Mailer: Mozilla 4.75 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: steven.legg@adacel.com.au CC: ietf-ldup@imc.org Subject: Re: Comments on draft-ietf-ldup-replica-req-06.txt References: <000201c09aef$533e31a0$b05508cb@osmium.adacel.com.au> 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 Comments are inserted in the text below; look for the lines that are not quoted. The comments represent consensus of the authors. Rick Huber Steven Legg wrote: > Folks, > > Some comments on draft-ietf-ldup-replica-req-06.txt . > > > 2 Terminology > > > Replica - A collection of entries in the DIT, defined by a naming > > context, and including all or some of the depending entries contained > > therein, which divides directory data into a discrete partition whose > > propagation behavior may be independently configured from other > > partitions. Replicas may overlap or be nested. > > The use of "discrete" seems to be at odds with "overlap" and "nested". Agreed. Proposed new text is given as part of our response to the next comment. > > The term "replica" is inconsistently used. Sometimes it is used to mean > a portion of the DIT, i.e. roughly synonymous with area of replication, > while at other times it refers to one of the servers holding a copy of a > particular area of replication. Our intent was the latter (a copy held on one of the servers). We will take a pass over the document to fix this, but if you have pointers to places where the term is not used in this sense they would be helpful. As a result of addressing the first two comments, we propose to reword the definitions of "area of replication: and "replica" as follows: Replica - A instance of an area of replication on a server Area of replication - A whole or portion of a Directory Information Tree (DIT) that makes up a distinct unit of data to be replicated. An area of replication is defined by a naming context and includes all or some of the depending entries contained therein. It divides directory data into partitions whose propagation behavior may be independently configured from other partitions. Areas of replication may overlap or be nested. Areas of replication may also be known as "units of replication". > > > Replica-Ring - The servers that hold a particular replica. A server > > may be part of several replica-rings. > > Here "replica" means a particular area of replication whereas elsewhere > the servers in the replica-ring are referred to as separate replicas. > > I suggest using area of replication to refer to the portion of the DIT > and defining "replica" to mean one instance or copy of that area of > replication held in a directory server. Agreed - see new definitions above. > > > Replication Initiation Conflict - In multi-master replication, a > > Replication Initiation Conflict is a situation where two masters want > > to update the same replica at the same time. > > It isn't just master replicas that can have such a conflict. Read-only > replicas can be forwarding updates from a master upstream. A Replication > Initiation Conflict is a situation where two replicas want to initiate > replication sessions with a third replica at the same time. OK. We'll remove references to masters in the definition. > > > 3 The Models > > > Consistency models 1, 2 and 3 involve the use of prearranged > > replication agreements among servers. The added complexity of the > > distributed 2-phase commit required for Model 1 is significant; > > therefor, model 1 will not be considered at this time. Models 4 and 5 > > involve unregistered replicas that "pull" updates from another > > directory server without that server's knowledge. These models violate > > a directory's security policies. > > It seems to me that any of the five models could violate, or preserve, > a directory's security policies. It all depends on whether the consumer > of the replicated data receives and honours the security information. We feel we have already addressed this with changes to sections 3 and 5 going from draft 05 to 06. We don't feel any additional changes are needed. > > M3. A value shared between replicas in a replica ring must eventually > > converge to the same value on all of its constituent replicas. > > A shared value is almost by definition the same everywhere, otherwise in > what sense can it be said to be shared ? This requirement is really trying > to say that an attribute in an entry must eventually converge to the same > set of values in every replica holding that entry, and is just duplicating > MM6 anyway. It looks like we agree on what the requirement is saying. We don't feel it is duplicating MM6 since MM6 also addresses particular concerns that can arise in multi-master. > > > P2. The supplier MUST track updates sent to the consumer and not > > resend already acknowledged ones, even in the event of recovery from a > > failed replica cycle. > > Not resending acknowledged updates to a consumer requires something like > two-phase commit for the replication session between the supplier and > consumer, which isn't part of the current protocol proposal, and doesn't > need to be since URP absorbs any duplicates. Also, with the Update Vector, > it is the consumer that keeps track of the updates that have been received > rather than the supplier keeping track of the updates that have been sent. > > I imagine there are two things this requirement might really be trying to > say: > > 1) The replication architecture SHOULD avoid sending to a consumer an > update that the consumer has already seen. > > 2) An update received by a consumer more than once MUST NOT produce a > different outcome than if the update were received exactly once. It is trying to say both things. We will replace P2 with Steven's two requirements. > > > P7. The protocol SHOULD NOT preclude support of Transactional > > Consistency (model 1). > > I think this should be more general than just the protocol. > The replication architecture SHOULD NOT preclude ... Agreed. We'll move it to the "General" section. > > > AM6. Access control information (ACI) associated with sensitive data > > MUST be deleted after or simultaneously with the deletion of the > > sensitive data. Likewise, during Adds, ACI MUST be added first or > > simultaneously with the addition of that data. > > This is a requirement on LDAP users rather than the replication > architecture. > The requirement for replication would be that where there are updates > to sensitive data and the ACIs controlling access to those data, the updates > SHOULD/MUST be applied at other replicas in the same order. Agreed. > > > A.6. Consumer Initiated Replication > > > > Again a single mastered replication topology, but the replica initiates > ^^^^^^^ slave > > the replication exchange rather than the master. An example of this is > > a replica that resides on a laptop computer that may run disconnected > > for a period of time. Agreed. > > > A.10. Enterprise Directory Replication Mesh > > > > A Corporation builds a mesh of directory servers within the enterprise > > utilizing LDAP servers from various vendors. Five servers are holding > > the same area of replication. The predetermined replication > > agreement(s) for the enterprise mesh are under a single management, and > > the security domain allows a single predetermined replication agreement > > to manage the 5 servers replication. > > > > The requirements that follow from this scenario are: > > . Predefined replication agreements that manage more than a single area > > of replication that is held on numerous servers. > > The preceding paragraph suggests there is exactly one area of replication. The text is in Appendix A, which contains examples of use. Examples are typically specific versions of more general principles, so we don't see a problem here. The definition of "area of replication" as rewritten above makes it clear that multiple areas of replication are supported. > > > B.5.3. Locking Based on Atomicity of ModifyRequest > > > > There is an entry with distinguished name DN that contains attributes > > X, Y, and Z. The value of X is 1. On replica A, a ModifyRequest is > > processed which includes modifications to change that value of X from 1 > > to 0 and to set the value of Y to "USER1". At the same time, replica B > > process a ModifyRequest which includes modifications to change the > ^^^^^^^ processes OK. > > Regards, > Steven > > ------------------------------------------------------------------------ > Name: winmail.dat > winmail.dat Type: application/ms-tnef > Encoding: base64 From owner-ietf-ldup@mail.imc.org Thu Feb 22 15:56:01 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA27017 for ; Thu, 22 Feb 2001 15:55:50 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.9.3/8.9.3) id MAA01565 for ietf-ldup-bks; Thu, 22 Feb 2001 12:07:40 -0800 (PST) Received: from clmboh1-smtp3.columbus.rr.com (dhcp065-024-000-112.columbus.rr.com [65.24.0.112] (may be forged)) by above.proper.com (8.9.3/8.9.3) with ESMTP id MAA01558 for ; Thu, 22 Feb 2001 12:07:39 -0800 (PST) Received: from willeke.com (dhcp024-166-090-249.neo.rr.com [24.166.90.249]) by clmboh1-smtp3.columbus.rr.com (8.11.2/8.11.2) with ESMTP id f1MK4wc12607; Thu, 22 Feb 2001 15:05:03 -0500 (EST) Message-ID: <3A95717E.5050605@willeke.com> Date: Thu, 22 Feb 2001 15:07:26 -0500 From: Jim Willeke Organization: Integrated Business Solutions User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; 0.8) Gecko/20010215 X-Accept-Language: en MIME-Version: 1.0 CC: steven.legg@adacel.com.au, ietf-ldup@imc.org Subject: Re: Comments on draft-ietf-ldup-replica-req-06.txt References: <000201c09aef$533e31a0$b05508cb@osmium.adacel.com.au> <3A953A2A.8E9856E0@att.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 I do not understand the useage of the term "Replica-Ring" A ring would imply there is some order of going from one to the next on the ring. Would a "replica Group" not be more appropriate? -jim Richard Huber wrote: > Comments are inserted in the text below; look for the lines that are not > quoted. The comments represent consensus of the authors. > > Rick Huber > > Steven Legg wrote: > >> Folks, >> >> Some comments on draft-ietf-ldup-replica-req-06.txt . >> >>> 2 Terminology >> >>> Replica - A collection of entries in the DIT, defined by a naming >>> context, and including all or some of the depending entries contained >>> therein, which divides directory data into a discrete partition whose >>> propagation behavior may be independently configured from other >>> partitions. Replicas may overlap or be nested. >> >> The use of "discrete" seems to be at odds with "overlap" and "nested". > > > Agreed. Proposed new text is given as part of our response to the next comment. > >> The term "replica" is inconsistently used. Sometimes it is used to mean >> a portion of the DIT, i.e. roughly synonymous with area of replication, >> while at other times it refers to one of the servers holding a copy of a >> particular area of replication. > > > Our intent was the latter (a copy held on one of the servers). We will take a > pass over the document to fix this, but if you have pointers to places where the > term is not used in this sense they would be helpful. > > As a result of addressing the first two comments, we propose to reword the > definitions of "area of replication: and "replica" as follows: > > Replica - A instance of an area of replication on a server > > Area of replication - A whole or portion of a Directory Information > Tree (DIT) that makes up a distinct unit of data to be replicated. > An area of replication is defined by a naming context and includes > all or some of the depending entries contained therein. It divides > directory data into partitions whose propagation behavior may be > independently configured from other partitions. Areas of > replication may overlap or be nested. Areas of replication may also > be known as "units of replication". > >>> Replica-Ring - The servers that hold a particular replica. A server >>> may be part of several replica-rings. >> >> Here "replica" means a particular area of replication whereas elsewhere >> the servers in the replica-ring are referred to as separate replicas. >> >> I suggest using area of replication to refer to the portion of the DIT >> and defining "replica" to mean one instance or copy of that area of >> replication held in a directory server. > > > Agreed - see new definitions above. > >>> Replication Initiation Conflict - In multi-master replication, a >>> Replication Initiation Conflict is a situation where two masters want >>> to update the same replica at the same time. >> >> It isn't just master replicas that can have such a conflict. Read-only >> replicas can be forwarding updates from a master upstream. A Replication >> Initiation Conflict is a situation where two replicas want to initiate >> replication sessions with a third replica at the same time. > > > OK. We'll remove references to masters in the definition. > >>> 3 The Models >> >>> Consistency models 1, 2 and 3 involve the use of prearranged >>> replication agreements among servers. The added complexity of the >>> distributed 2-phase commit required for Model 1 is significant; >>> therefor, model 1 will not be considered at this time. Models 4 and 5 >>> involve unregistered replicas that "pull" updates from another >>> directory server without that server's knowledge. These models violate >>> a directory's security policies. >> >> It seems to me that any of the five models could violate, or preserve, >> a directory's security policies. It all depends on whether the consumer >> of the replicated data receives and honours the security information. > > > We feel we have already addressed this with changes to sections 3 and 5 going > from draft 05 to 06. We don't feel any additional changes are needed. > >>> M3. A value shared between replicas in a replica ring must eventually >>> converge to the same value on all of its constituent replicas. >> >> A shared value is almost by definition the same everywhere, otherwise in >> what sense can it be said to be shared ? This requirement is really trying >> to say that an attribute in an entry must eventually converge to the same >> set of values in every replica holding that entry, and is just duplicating >> MM6 anyway. > > > It looks like we agree on what the requirement is saying. We don't feel it is > duplicating MM6 since MM6 also addresses particular concerns that can arise in > multi-master. > >>> P2. The supplier MUST track updates sent to the consumer and not >>> resend already acknowledged ones, even in the event of recovery from a >>> failed replica cycle. >> >> Not resending acknowledged updates to a consumer requires something like >> two-phase commit for the replication session between the supplier and >> consumer, which isn't part of the current protocol proposal, and doesn't >> need to be since URP absorbs any duplicates. Also, with the Update Vector, >> it is the consumer that keeps track of the updates that have been received >> rather than the supplier keeping track of the updates that have been sent. >> >> I imagine there are two things this requirement might really be trying to >> say: >> >> 1) The replication architecture SHOULD avoid sending to a consumer an >> update that the consumer has already seen. >> >> 2) An update received by a consumer more than once MUST NOT produce a >> different outcome than if the update were received exactly once. > > > It is trying to say both things. We will replace P2 with Steven's two > requirements. > >>> P7. The protocol SHOULD NOT preclude support of Transactional >>> Consistency (model 1). >> >> I think this should be more general than just the protocol. >> The replication architecture SHOULD NOT preclude ... > > > Agreed. We'll move it to the "General" section. > >>> AM6. Access control information (ACI) associated with sensitive data >>> MUST be deleted after or simultaneously with the deletion of the >>> sensitive data. Likewise, during Adds, ACI MUST be added first or >>> simultaneously with the addition of that data. >> >> This is a requirement on LDAP users rather than the replication >> architecture. >> The requirement for replication would be that where there are updates >> to sensitive data and the ACIs controlling access to those data, the updates >> SHOULD/MUST be applied at other replicas in the same order. > > > Agreed. > >>> A.6. Consumer Initiated Replication >>> >>> Again a single mastered replication topology, but the replica initiates >> >> ^^^^^^^ slave >> >>> the replication exchange rather than the master. An example of this is >>> a replica that resides on a laptop computer that may run disconnected >>> for a period of time. >> > > Agreed. > >>> A.10. Enterprise Directory Replication Mesh >>> >>> A Corporation builds a mesh of directory servers within the enterprise >>> utilizing LDAP servers from various vendors. Five servers are holding >>> the same area of replication. The predetermined replication >>> agreement(s) for the enterprise mesh are under a single management, and >>> the security domain allows a single predetermined replication agreement >>> to manage the 5 servers replication. >>> >>> The requirements that follow from this scenario are: >>> . Predefined replication agreements that manage more than a single area >>> of replication that is held on numerous servers. >> >> The preceding paragraph suggests there is exactly one area of replication. > > > The text is in Appendix A, which contains examples of use. Examples are > typically specific versions of more general principles, so we don't see a > problem here. The definition of "area of replication" as rewritten above makes > it clear that multiple areas of replication are supported. > >>> B.5.3. Locking Based on Atomicity of ModifyRequest >>> >>> There is an entry with distinguished name DN that contains attributes >>> X, Y, and Z. The value of X is 1. On replica A, a ModifyRequest is >>> processed which includes modifications to change that value of X from 1 >>> to 0 and to set the value of Y to "USER1". At the same time, replica B >>> process a ModifyRequest which includes modifications to change the >> >> ^^^^^^^ processes > > > OK. > >> Regards, >> Steven >> >> ------------------------------------------------------------------------ >> Name: winmail.dat >> winmail.dat Type: application/ms-tnef >> Encoding: base64 > From owner-ietf-ldup@mail.imc.org Thu Feb 22 19:13:50 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA01139 for ; Thu, 22 Feb 2001 19:13:48 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.9.3/8.9.3) id OAA10534 for ietf-ldup-bks; Thu, 22 Feb 2001 14:56:13 -0800 (PST) Received: from ckmso1.proxy.att.com (ckmso1.att.com [12.20.58.69]) by above.proper.com (8.9.3/8.9.3) with ESMTP id OAA10526 for ; Thu, 22 Feb 2001 14:56:10 -0800 (PST) Received: from qsun.mt.att.com ([135.16.31.2]) by ckmso1.proxy.att.com (AT&T IPNS/MSO-3.0) with SMTP id f1MMt8119527; Thu, 22 Feb 2001 17:55:08 -0500 (EST) Received: by qsun.mt.att.com (SMI-8.6/ATTEMS-1.4.1 sol2) id RAA23476; Thu, 22 Feb 2001 17:55:07 -0500 Date: Thu, 22 Feb 2001 17:55:07 -0500 Message-Id: <200102222255.RAA23476@qsun.mt.att.com> From: rvh@qsun.mt.att.com (Richard V Huber) To: internet-drafts@ietf.org Subject: New draft for LDUP Working Group Cc: gfm@qsun.mt.att.com, ietf-ldup@imc.org, rmoats@coreon.com Sender: owner-ietf-ldup@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Drafts editor - Please publish the draft below as draft-ietf-ldup-usage-profile-00.txt LDUP - This is the initial draft of a profiles document. We know it needs a lot more work (remember, in San Diego I only promised an extended outline before the next meeting). We are looking for comments on what should be included/excluded from future versions. I hope that some of the warnings about the consequences of replication that we have been discussing as part of the requirements draft can end up in this draft. This might help us move forward on the requirements. But also, after we finally get all the documents published (who says I'm not an optimist?), people are more likely to look for warnings in a profile document like this than in the requirements. Rick Huber --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- Internet-Draft Richard V. Huber LDAP Duplication/Replication/Update Gerald F. Maziarski Protocols WG AT&T Laboratories Intended Category: TBD Ryan D. Moats Expires: August 2001 Coreon, Inc. February 2001 General Usage Profile for LDAPv3 Replication draft-ietf-ldup-usage-profile-00.txt Status of This Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/lid-abstracts.txt. The list of Internet-Drafts Shadow Directories can be accessed at http://www.ietf.org/shadow.html. Copyright Notice Copyright (C) The Internet Society (2001). All Rights Reserved. Abstract Support for replication in LDAP directory systems is often one of the key factors in the decision to deploy them. But replication brings design constraints along with its benefits. We discuss some of the factors that should be taken into consideration when designing a replicated directory system. Both programming and architectural/operational concerns are addressed. Huber, et al Expires August 2001 [Page 1] Internet-Draft Usage Profiles for LDAPv3 Replication February 2001 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 [RFC2119]. Huber, et al Expires August 2001 [Page 2] Internet-Draft Usage Profiles for LDAPv3 Replication February 2001 Table of Contents 1 Introduction.......................................................4 2 Meta-data Considerations...........................................4 2.1 Schema Considerations...........................................4 2.2 Replication Agreements..........................................5 2.3 Access Control..................................................6 2.4 Change Logs.....................................................7 3 Naming Considerations..............................................7 4 Conflict Resolution Considerations.................................7 4.1 Consistent Access after Changes.................................7 4.2 Conflict Resolution in Single-Master Systems....................8 4.3 Problem Cases...................................................9 4.4 General Principles.............................................10 5 Failover Considerations...........................................11 5.1 Common Issues..................................................11 5.2 Single Master Issues...........................................11 5.3 Multi-Master Issues............................................12 6 Impact of Non-LDAP Changes/Constraints............................12 6.1 Changes Outside of LDAP........................................12 6.2 Application Triggers...........................................13 7 Security Considerations...........................................13 8 Acknowledgements..................................................13 9 References........................................................14 Authors' Addresses...................................................14 Full Copyright Statement.............................................15 Huber, et al Expires August 2001 [Page 3] Internet-Draft Usage Profiles for LDAPv3 Replication February 2001 1 Introduction As LDAP directories become part of critical infrastructure in many applications, the need for extremely high reliability and availability becomes significant. And as directories are more widely used, the load on individual directory servers gets higher. Distributed, replicated directories can reduce the problems of reliability and capacity. But applications that work well with a single, standalone directory will develop problems in a distributed environment unless both the application and the environment are carefully designed. The particular areas of concern depend partly on whether the distributed directory is a single- or multi-master system, but there are many concerns that are common to both. In the remainder of the document, we have flagged some sections as being specific to single- or multi-master directories. Unflagged sections pertain to both. This document addresses general issues. There may be additional drafts in the future that address specific applications. 2 Meta-data Considerations Any LDAP directory contains meta-data as well as the user data in the directory. Examples of this meta-data include descriptions of the data in the directory (e.g. schema), policies for use of the data (e.g. access controls), and configuration/status information (e.g. replication agreements); this is not an exhaustive list. Many types of meta-data are stored in the directory itself; accessible as regular data or as operational attributes. Since meta-data can appear in the directory, issues arise when it is replicated. 2.1 Schema Considerations If the schema of one or more of the copies of a replica differs from the schema of the other replicas, then there exists the possibility of schema mismatch when data is exchanged between them. The extensibility feature of LDAP schema nearly guarantees that replica rings comprised of a heterogeneous mix of systems will not contain homogeneous schema because of directory vendors' built-in extensions. Because a given directory may not utilize its complete schema, not all of the potential Huber, et al Expires August 2001 [Page 4] Internet-Draft Usage Profiles for LDAPv3 Replication February 2001 schema differences in a ring will result in a schema mismatch under replication. Schema mismatch issues are further complicated by the possibility of replicating the "subschemaSubentry" itself. Some directories distribute schema changes through that mechanism. Currently there is no standard for LDAP schema representation. In the absence of such a standard, schema interoperability is not possible in the IETF sense. Designers should establish common schema on all servers holding a replica. It is useful to separate out two classes of schema mismatch: "latent", when the differences do not intersect the collection of data in the ring; and "salient", when they do. Schema mismatches that can cause data corruption in one or more of the replicas must result in meta-data (e.g. log entries) to comply with Requirement MM5 of [ReplicaReq]. However, not all schema differences produce corruption in all circumstances. Some schema differences may have little or nor impact on the proper storage of replicated data. However, any time data is added to the directory it could change a latent mismatch into a salient mismatch. It is therefore recommended that all schema mismatches be removed from, or otherwise rationalized among, the replica ring schemas, if possible. The tool described by requirement AM8 of [ReplicaReq] would help designers detect schema conflicts as early as possible. The other option that can be considered in this situation is the use of fractional replication to replicate only those attributes that do not have differences. Examples of mismatches: 1. Base syntax of an attribute type 2. Structure Rule of an object class 3. Optional vs. Mandatory attribute in an object class 4. Structural vs. Auxiliary in an object class 5. Object class not defined 6. Attribute type not defined 7. Object identifiers differs on an attribute type or on an object class 8. Type and number of attributes defined in a class 9. Multi-valued vs. Single valued attribute types 10. ACL format (and consequently, ACL calculus) 11. Matching rule of an attribute type 12. Naming collisions of attribute type names 13. Attribute name aliasing ("street" vs. "streetAddress") 2.2 Replication Agreements Replication Agreements are central to replication, they allow configuration of most of the aspects of the replication process, Huber, et al Expires August 2001 [Page 5] Internet-Draft Usage Profiles for LDAPv3 Replication February 2001 including the triggers for replica cycles (from Requirement M1 in [ReplicaReq]), critical OID information (from Requirement M6 in [ReplicaReq]), and replication process parameters (Requirement M7 in [ReplicaReq]). Through the use of a standard schema (Requirement S2) it is possible to replicate the replication agreement. If a replication agreement includes replication credentials, the agreement SHOULD be read protected in the directory and transport of the replication agreement SHOULD be encrypted. Further, the directory administrator should consider and understand the possibility of the replication of the agreement impacting replication processes. 2.3 Access Control - Access Control Information (ACI) is treated as though it were stored as attributes in the directory [ACModel] - LDAP declares [RFC2251] that changes resulting from a single LDAP MODIFY are atomic (but see caveats in multi-master case) - ACI affecting a given entry may not be part of that entry (it could be part of a group entry or part of an ancestor of the entry in question) - ACI cannot always be changed atomically with associated data changes - If you aren't careful, you can leave windows where data is unprotected - Access control changes SHOULD be made before adds and after deletes - Access control changes and the associated data changes SHOULD be made on same system. - Life gets interesting when access control policy is inherited from a superior partition, but that is mostly a partitioning issue, not a replication issue (once we figure out how partitioning works we may find out it is also a replication issue). Even when ACL information is faithfully replicated among heterogeneous members of a replica ring that agree on transfer format, there is no guarantee that an ACI change is expressed similarly everywhere in the ring. This caveat is partly due to partitioning effects mentioned above, and partly due to vendor differences with regard to the expression of security policy. The access control mechanisms specified in [ACModel] are neutral with respect to policy inheritance mechanisms, explicit vs. implicit denial, and group nesting; all of which may differ between vendors, and will affect or modify the expression of access control information. Huber, et al Expires August 2001 [Page 6] Internet-Draft Usage Profiles for LDAPv3 Replication February 2001 2.4 Change Logs Requirement G4 of [ReplicaReq] states that meta-data must not grow without bound. Since it is unrealistic to assume that meta-data won't be needed during replication, how and when meta-data can be purged must be considered. Replicas that use connections with intermittent quality SHOULD use explicit replica cycle scheduling. This allows notification of a delayed replica and manual intervention before the meta-data grows without bound. In extreme cases, it may be necessary to remove these replicas from the replication ring and re-add them add once better connectivity is available. Second, it is also possible for a consumer to receive changes that cannot be applied. The replication agreement SHOULD include information for when the consumer should stop deferring the change and declare the changes as inapplicable, thus invoking whatever procedure is in place to comply with requirement MM5 of [ReplicaReq] during multi-master replication. 3 Naming Considerations A number of naming models have been proposed for directories ([RFC1255], [RFC2377], [CIMNames]), and many others have been implemented on an ad hoc basis. Each of these models specifies the naming attributes to be used and provides rules for using them. The naming scheme may also specify containment rules. The naming plan applies to the directory as a whole, not the individual servers holding replicas. In a heterogeneous replicated environment, all of the replicating servers must be capable of supporting all of the rules for the naming plan in use for that directory. Some directory implementations have naming constraints. If one of them is part of a replicated directory, those constraints will have to be observed by all participating directories. If the environment contains implementations with incompatible constraints there is a major problem. This SHOULD be checked as early in the design phase as possible to avoid costly problems. 4 Conflict Resolution Considerations 4.1 Consistent Access after Changes Many operations on a directory are done as a set of steps. For example, a new object may be created in one operation, and its values may be filled in as part of a separate LDAP operation. An Huber, et al Expires August 2001 [Page 7] Internet-Draft Usage Profiles for LDAPv3 Replication February 2001 administrator may add a user to a directory, and that user may then try to log in using the new entry. Replicated LDAP directories provide loose consistency [ReplicaReq]. A new entry or a change to an existing entry will not reach all replicas immediately; there will be some delay before changes are available on all replicas. Changes made (e.g. adding a new user) on one physical system may appear to be "lost" if checked on another physical system before replication is complete. In general, LDAP applications SHOULD be prepared to operate correctly in the face of replication delays. In some cases, this means designing to allow for delay. In the case of the newly created user, it SHOULD be standard practice to ask the user to wait a while before trying to use the entry. In the case where the new object must be filled in, the application SHOULD make appropriate use of LDAP sessions to make sure that the same server is reached for both operations. As a general rule, an LDAP application SHOULD bind once and not unbind until a complete set of related operations have been performed. In the single-master case, all write requests go to one server. If a set of related reads and writes are done, they SHOULD all be done on the master if possible. Ideally, only sets of related operations that can not include a write SHOULD go to one of the slave servers. But load balancing concerns may make this impractical. In some cases, related requests will deal with data in different partitions which are not all available on a single server. In this case, it is safer to keep sessions open to all servers rather than closing the session with one server and opening one with another server. It may not always be obvious to clients that they are using different servers. If a load distribution system is used between the client and the server, the client may find that a change request and a subsequent lookup are directed to different physical servers even though the original requests were sent to the same server name and/or address. Since LDAP is session oriented, any load distribution system used should take sessions into account. Thus, keeping all related read and write requests within a single bind/unbind session SHOULD be the goal in this situation as well. 4.2 Conflict Resolution in Single-Master Systems It is possible that resolution conflicts could occur in a single master replication system. Because requirement SM2 of [ReplicaReq] is a Huber, et al Expires August 2001 [Page 8] Internet-Draft Usage Profiles for LDAPv3 Replication February 2001 SHOULD and not a MUST, it is possible for implementers to reorder changes. If changes are reordered, it is quite possible for a conflict to occur. If schema changes are critical and must be moved to the front of the replication queue, then a schema change that deletes an attribute for some object class that follows some changes that delete values of the soon-to-be-deleted attribute can cause conflict. If the schema change moves to the head of the queue, the consumer servers might have to delete an attribute that still has values, and then receive requests to delete the values of an attribute that is no longer defined. However, directory administrators may have scenarios where re-ordering of replication information is desirable. On a case-by-case basis, the directory administrator should make such decisions. 4.3 Problem Cases 4.3.1 Atomicity The fact that replication does not guarantee the time order arrival of changes at a consumer allows situations where changes that were applied successfully at the supplier may fail in part when an attempt is made to apply the same change at the consumer. Examples appear below. 4.3.1.1 Locking There is an entry with distinguished name DN that contains attributes X, Y, and Z. The value of X is 1. On replica A, a ModifyRequest is processed which includes modifications to change that value of X from 1 to 0 and to set the value of Y to "USER1". At the same time, replica B process a ModifyRequest which includes modifications to change the value of X from 1 to 0 and to set the value of Y to "USER2" and the value of Z to 42. The application in this case is using X as a lock and is depending on the atomic nature of ModifyRequests to provide mutual exclusion for lock access. In the single-server case, the two operations would have occurred sequentially. Since a ModifyRequest is atomic, the entire first operation would succeed. The second ModifyRequest would fail, since the value of X would be 0 when it was attempted, and the modification changing X from 1 to 0 would thus fail. The atomicity rule would cause all other modifications in the ModifyRequest to fail as well. In the multi-master case, it is inevitable that at least some of the changes will be reversed despite the use of the lock. Assuming the changes from A have priority per the conflict resolution algorithm, the value of X should be 0 and the value of Y should be "USER1" The interesting question is the value of Z at the end of the replication Huber, et al Expires August 2001 [Page 9] Internet-Draft Usage Profiles for LDAPv3 Replication February 2001 cycle. If it is 42, the atomicity constraint on the change from B has been violated. But for it to revert to its previous value, grouping information must be retained and it is not clear when that information can be safely discarded. Thus, requirement G6 in [ReplicaReq] may be violated. The utility of locking mechanisms cannot be guaranteed, and therefore are likely to be misleading. Its use in multi-master environments is therefore deprecated. 4.3.1.2 Partitioning Suppose two servers, A and B, are members of Replica-ring X; and servers B and C are members of replica-ring Y. A ModifyRDN operation on server B moves an entry from ring X to ring Y. If the appropriate delete is done on A, the operation may be considered successful even though hidden circumstances on ring Y prevent the move. If on C another change made the modifyRDN that worked on B impossible, because an RDN of a different GUID exists there already, then the change on A is inconsistent and will need to be reversed. Others examples of cases of this class include group membership modification and access control scoping. 4.4 General Principles The examples above discuss some of the most difficult problems that can arise in multi-master replication. While they can be dealt with, dealing with them is difficult and can lead to situations that are quite confusing to the application and to users. The common characteristics of the examples are: . Several directory users/applications are changing the same data . They are changing the data at the same time . They are using different directory servers to make these changes . They are changing data that are parts of a distinguished name or they are using ModifyRequest to both read and write a given attribute value in a single atomic request If any one of these conditions is reversed, the types of problems described above will not occur. There are many useful applications of multi-master directories where at least one of the above conditions Huber, et al Expires August 2001 [Page 10] Internet-Draft Usage Profiles for LDAPv3 Replication February 2001 does not occur. For cases where all four do occur, application designers should be aware of the possible consequences. 5 Failover Considerations One of the major reasons to use directory replication is to improve reliability of the directory system as a whole. Replication permits hot- and warm-standby configurations to be built easily. But there are some issues that must be considered during design. In this situation, single-master systems actually raise more concerns than multi-master. Both are addressed below. 5.1 Common Issues In both the single- and multi-master cases, clients must be able to find an alternate quickly when a server fails. Some possible ways to do this are detailed in [FindingLDAP] and [LDAPinDNS]. If all else fails, a list of possible servers can be built into client applications. Designers should consider how clients are notified that the server is again available. When the failed server comes back up, it is brought back into synchronization with the other servers and is ready to take requests. Note that the process used to bring a failed server back into replication can also be used to add a server to a set of replicating servers. In this case, the new server might be initialized from a backed-up copy of the directory or it may acquire the entire DIB via replication. The former method is usually preferable when the directory is large. 5.2 Single Master Issues In a single-master system, the master is a single point of failure, as all modification has to originate at the master server. When high availability is a requirement, a quick, automated failover process for converting a slave replica to a new master is desirable, as the failover process time becomes a major factor in determining system availability. The considerations in section 5.1 apply here; clients must know how to find the new master or a new slave in case of failure. To aid in promotion of a slave replica, the master could replicate control information and meta-data (included replication credentials) so that this information is available during failover promotion. This data may either be replicated on a single "failover designate" slave (which would become the master in during failover) or it could be Huber, et al Expires August 2001 [Page 11] Internet-Draft Usage Profiles for LDAPv3 Replication February 2001 replicated to all slaves. The first possibility has the advantage of minimizing the amount of extra replication while the second more robustly handles multiple failovers (i.e. failover of the newly promoted master to another slave before the original master has been restored). If this method is followed, data privacy mechanisms SHOULD be used to protect the replication session. In addition, if data privacy mechanisms (e.g. encryption) were used to protect the replication session, the new master MUST have the necessary key information. Further this key information should be independent of the master that is using it (i.e. not tied to the IP address of the master server). Restoration of the failed or broken master can be handled in one of two ways: - It could join the ring and function as a slave. - It could join the ring and negotiate with the new master to synchronize and then take over as master. In either case, clients need a way to know that a new server is available. The slave replicas may also use the replication agreement to filter which master is allowed to submit changes. Such a model allows the slave servers to function correctly when the master server is "broken" and sending out incorrect updates. However, then it is necessary to update the replication agreement during the fail over process so that the slaves will accept updates from the new master. This is the case for both the original failure and the restoration of the restored master if that is how the restored master rejoins the replica ring. 5.3 Multi-Master Issues Typically, a multi-master configuration was used because high availability is required for writes as well as reads in the directory. Multi-master implies that there are multiple active servers prepared to take write requests, so there is no "switchover" time in this case. But clients still need to be able to find an alternate server, so the considerations of Section 5.1 apply here. 6 Impact of Non-LDAP Changes/Constraints 6.1 Changes Outside of LDAP Huber, et al Expires August 2001 [Page 12] Internet-Draft Usage Profiles for LDAPv3 Replication February 2001 LDAP directories are typically built on top of some database or file system. Thus there are ways to change the data that do not go through the normal LDAP change mechanisms (e.g. ModifyRequest). If the data is modified outside of LDAP, the changes will not be checked for schema conformance nor will access controls be checked as the changes are made. Since both integrity and security checks are omitted, security can be adversely affected. Also, many systems use the normal LDAP modification mechanisms to trigger replication. Changes made using non-LDAP mechanisms may not be replicated at all, leading to inconsistencies between replica copies. 6.2 Application Triggers Directory servers commonly integrate one or more specific applications. To achieve this integration the directory server may intercept updates and run application-specific "trigger" code. Such triggers enforce directory invariants that cannot be expressed by the LDAP schema. A simple trigger example is password policy enforcement. A directory server might interpret a request to replace the current value of the userPassword attribute with some new value as a request to first check that the new value conforms to the server's password policy (e.g. the value is sufficiently long and complex) before storing the new value. Using this trigger the directory server voids the security risk associated with passwords that are easy to attack. A more complex trigger example is password hashing. A directory server might interpret a request to replace the current value of the userPassword attribute with some new value as a request to compute one or more secure hashes of the new value and store these hashes in one or more attributes, storing no value in the userPassword attribute. Using this trigger the directory server avoids the security exposure of storing the plaintext password. Replication between directory servers with different application triggers will compromise directory integrity. 7 Security Considerations The document discusses issues that arise in replication. Some of these issues are security related (e.g. replication of access control information) and the security implications are discussed in the relevant sections. 8 Acknowledgements Huber, et al Expires August 2001 [Page 13] Internet-Draft Usage Profiles for LDAPv3 Replication February 2001 The authors would like to thank Mark Brown for identifying the issues discussed in section 6. 9 References [ACModel] E. Stokes, R. Blakeley, D. Rinkevich, R. Byrne, "Access Control Model for LDAPv3", Internet Draft, draft-ietf-ldapext-acl- model-06.txt, July 2000. [CIMNames] Desktop Management Task Force, "Guidelines for CIM-to-LDAP Directory Mappings", DMTF Specification DSP0100, May 2000 (available online at http://www.dmtf.org/spec/DEN/DSP0100.htm). [FindingLDAP] R. Moats, R. Hedberg, "A Taxonomy of Methods for LDAP Clients Finding Servers", Internet Draft, draft-ietf-ldapext-ldap- taxonomy-04.txt, October 2000. [LDAPinDNS] M. Armijo, L. Esibov, P. Leach, R. L. Morgan, "Discovering LDAP Services with DNS", Internet Draft, draft-ietf-ldapext-locate- 04.txt, August 2000. [ReplicaReq] E. Stokes, R. Weiser, R. Moats, R. Huber, "LDAPv3 Replication Requirements", Internet Draft, draft-ietf-ldup-replica-req- 06.txt, January 2001. [RFC1255] The North American Directory Forum, "A Naming Scheme for c=US", RFC 1255, September 1991. [RFC2119] S. Bradner, "Key Words 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. [RFC2377] A. Grimstad, R. Huber, S. Sataluri, M. Wahl, "Naming Plan for Internet Directory-Enabled Applications", RFC 2377, September 1998. Authors' Addresses Richard V. Huber Room C3-3B30 AT&T Laboratories 200 Laurel Avenue South Middletown, NJ 07748 USA E-Mail: rvh@att.com Telephone: +1 732 420 2632 Fax: +1 732 368 1690 Huber, et al Expires August 2001 [Page 14] Internet-Draft Usage Profiles for LDAPv3 Replication February 2001 Gerald F. Maziarski Room C3-3Z01 AT&T Laboratories 200 Laurel Avenue South Middletown, NJ 07748 USA E-Mail: gfm@att.com Telephone: +1 732 420 2162 Fax: +1 732 368 1690 Ryan D. Moats Coreon, Inc. 15621 Drexel Circle Omaha, NE 68135 USA E-Mail: rmoats@coreon.net Telephone: +1 402 894 9456 Full Copyright Statement Copyright (C) The Internet Society (2000). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Acknowledgement Huber, et al Expires August 2001 [Page 15] Internet-Draft Usage Profiles for LDAPv3 Replication February 2001 Funding for the RFC Editor function is currently provided by the Internet Society. Huber, et al Expires August 2001 [Page 16] From owner-ietf-ldup@mail.imc.org Thu Feb 22 20:42:17 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA02688 for ; Thu, 22 Feb 2001 20:42:16 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.9.3/8.9.3) id QAA17586 for ietf-ldup-bks; Thu, 22 Feb 2001 16:59:48 -0800 (PST) Received: from arnie.adacel.com.au (arnie.adacel.com.au [203.36.26.147]) by above.proper.com (8.9.3/8.9.3) with SMTP id QAA17581 for ; Thu, 22 Feb 2001 16:59:46 -0800 (PST) Received: (qmail 18751 invoked from network); 23 Feb 2001 01:03:40 -0000 Received: from unknown (HELO osmium) (203.8.85.176) by arnie.adacel.com.au with SMTP; 23 Feb 2001 01:03:40 -0000 Reply-To: From: "Steven Legg" To: "'Richard Huber'" Cc: Subject: RE: Comments on draft-ietf-ldup-replica-req-06.txt Date: Fri, 23 Feb 2001 12:00:49 +1100 Message-ID: <000701c09d34$17f81b50$b05508cb@osmium.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 In-Reply-To: <3A953A2A.8E9856E0@att.com> Sender: owner-ietf-ldup@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit Rick, > -----Original Message----- > From: owner-ietf-ldup@mail.imc.org > [mailto:owner-ietf-ldup@mail.imc.org]On Behalf Of Richard Huber > Sent: Friday, 23 February 2001 3:11 > To: steven.legg@adacel.com.au > Cc: ietf-ldup@imc.org > Subject: Re: Comments on draft-ietf-ldup-replica-req-06.txt > > > Comments are inserted in the text below; look for the lines > that are not > quoted. The comments represent consensus of the authors. > > Rick Huber > > Steven Legg wrote: > > The term "replica" is inconsistently used. Sometimes it is > used to mean > > a portion of the DIT, i.e. roughly synonymous with area of > replication, > > while at other times it refers to one of the servers > holding a copy of a > > particular area of replication. > > Our intent was the latter (a copy held on one of the > servers). We will take a > pass over the document to fix this, but if you have pointers > to places where the > term is not used in this sense they would be helpful. I found these places. | Naming Context - Suffix of a sub-tree of entries held in a single | server [X.500]. For replication, this is the vertex of a replica. ^^^^^^^ | Replica-Ring - The servers that hold a particular replica. A server ^^^^^^^ | G5. The LDAP replication standard SHOULD NOT limit the size of a | replica. ^^^^^^^ maybe | M8. The replication agreements SHOULD accommodate multiple servers | receiving the same replica under a single predefined agreement. ^^^^^^^ > > > M3. A value shared between replicas in a replica ring > must eventually > > > converge to the same value on all of its constituent replicas. > > > > A shared value is almost by definition the same everywhere, > otherwise in > > what sense can it be said to be shared ? This requirement > is really trying > > to say that an attribute in an entry must eventually > converge to the same > > set of values in every replica holding that entry, and is > just duplicating > > MM6 anyway. > > It looks like we agree on what the requirement is saying. We > don't feel it is > duplicating MM6 since MM6 also addresses particular concerns > that can arise in > multi-master. Okay. Are you going to rephrase M3 though ? > > > A.10. Enterprise Directory Replication Mesh > > > > > > A Corporation builds a mesh of directory servers within the enterprise > > > utilizing LDAP servers from various vendors. Five servers are holding > > > the same area of replication. The predetermined replication > > > agreement(s) for the enterprise mesh are under a single management, and > > > the security domain allows a single predetermined replication agreement > > > to manage the 5 servers replication. > > > > > > The requirements that follow from this scenario are: > > > . Predefined replication agreements that manage more than a single area > > > of replication that is held on numerous servers. > > > > The preceding paragraph suggests there is exactly one area of replication. > > The text is in Appendix A, which contains examples of use. > Examples are > typically specific versions of more general principles, so we > don't see a > problem here. The definition of "area of replication" as > rewritten above makes > it clear that multiple areas of replication are supported. The point I was making was that the first paragraph says "Five servers are holding the SAME area of replication" while the requirement says "agreements that manage MORE THAN A SINGLE area of replication", which doesn't "follow from this scenario". Is it one, or more than one ? A.10 needs to be internally consistent. Regards, Steven From owner-ietf-ldup@mail.imc.org Thu Feb 22 23:50:29 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id XAA08503 for ; Thu, 22 Feb 2001 23:50:28 -0500 (EST) Received: by above.proper.com (8.9.3/8.9.3) id UAA24379 for ietf-ldup-bks; Thu, 22 Feb 2001 20:21:58 -0800 (PST) Received: from pretender.boolean.net (root@router.boolean.net [198.144.206.49]) by above.proper.com (8.9.3/8.9.3) with ESMTP id UAA24375 for ; Thu, 22 Feb 2001 20:21:57 -0800 (PST) Received: from gypsy.OpenLDAP.org (gypsy.boolean.net [10.192.1.2]) by pretender.boolean.net (8.11.1/8.11.1/Boolean/Hub) with ESMTP id f1N4LKD32756 for ; Fri, 23 Feb 2001 04:21:20 GMT (envelope-from Kurt@OpenLDAP.org) Message-Id: <5.0.2.1.0.20010222194540.00a94470@router.boolean.net> X-Sender: guru@router.boolean.net X-Mailer: QUALCOMM Windows Eudora Version 5.0.2 Date: Thu, 22 Feb 2001 20:21:18 -0800 To: From: "Kurt D. Zeilenga" Subject: draft-ietf-ldup-replica-req-06.txt terminology In-Reply-To: <000701c09d34$17f81b50$b05508cb@osmium.adacel.com.au> References: <3A953A2A.8E9856E0@att.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: I find the introduction of LDUP specific terminology quite confusing due to redefinition of many existing LDAP/X.500 terms. I would very much like to see existing LDAP/X.500 terminology where ever possible. In particular, much of the terminology defined in X.525 is directly applicable. If new terms are needed, that's fine... but please don't redefine existing terms. Kurt From owner-ietf-ldup@mail.imc.org Fri Feb 23 07:15:30 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA28600 for ; Fri, 23 Feb 2001 07:15:29 -0500 (EST) Received: by above.proper.com (8.9.3/8.9.3) id DAA05596 for ietf-ldup-bks; Fri, 23 Feb 2001 03:43:36 -0800 (PST) Received: from ietf.org (odin.ietf.org [132.151.1.176]) by above.proper.com (8.9.3/8.9.3) with ESMTP id DAA05592 for ; Fri, 23 Feb 2001 03:43:34 -0800 (PST) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA27164; Fri, 23 Feb 2001 06:43:33 -0500 (EST) Message-Id: <200102231143.GAA27164@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; CC: ietf-ldup@imc.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-reed-ldup-inheritance-00.txt Date: Fri, 23 Feb 2001 06:43:32 -0500 Sender: owner-ietf-ldup@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Policy Inheritance Mechanisms for LDAP Author(s) : E. Reed Filename : draft-reed-ldup-inheritance-00.txt Pages : 5 Date : 22-Feb-01 There are several possible ways to manage inheritance of policy information in a directory service. This document describes several known mechanisms and recommends one for general use that can be implemented using [LDUP]. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-reed-ldup-inheritance-00.txt Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-reed-ldup-inheritance-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-reed-ldup-inheritance-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20010222132914.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-reed-ldup-inheritance-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-reed-ldup-inheritance-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20010222132914.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ietf-ldup@mail.imc.org Fri Feb 23 16:21:10 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA22130 for ; Fri, 23 Feb 2001 16:21:09 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.9.3/8.9.3) id MAA09861 for ietf-ldup-bks; Fri, 23 Feb 2001 12:22:08 -0800 (PST) Received: from relay1.pair.com (relay1.pair.com [209.68.1.20]) by above.proper.com (8.9.3/8.9.3) with SMTP id MAA09853 for ; Fri, 23 Feb 2001 12:22:03 -0800 (PST) Received: (qmail 29472 invoked from network); 23 Feb 2001 20:21:30 -0000 Received: from cpe-144-132-70-18.vic.bigpond.net.au (HELO w98) (144.132.70.18) by relay1.pair.com with SMTP; 23 Feb 2001 20:21:30 -0000 X-pair-Authenticated: 144.132.70.18 Reply-To: From: "Albert Langer" To: "=?iso-8859-1?Q?'Patrik_F=E4ltstr=F6m'?=" , "'John Strassner'" , , "'Chris Apple'" , "'Ned Freed'" Subject: Proposed requirements not met by current architecture and URP proposals - part A - Fatal Show Stoppers Date: Sat, 24 Feb 2001 07:24:36 +1100 Message-ID: <000b01c09dd6$a4a96160$6628a8c0@nowhere.com> 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 CWS, Build 9.0.2416 (9.0.2910.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 In-Reply-To: <001601c09ab5$cb956ea0$6628a8c0@nowhere.com> Importance: Normal Sender: owner-ietf-ldup@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit Albert, if you're this convinced that URP does not meet the requirements document, please elaborate now, rather than later, in a separate thread (since this one is already so long). Thanks. Ok, here goes. I'm also CCing to ADs as advance notice of issues that are likely to be raised formally in a request for review of LDUP WG decisions if they continue unresolved. It will soon be a year since they were first documented. Further discussion may just be to the LDUP list and can be either followed there now or retrieved from the archives later. References marked U are to the last available URP version, draft-ietf-ldup-urp-03.txt, presently "expired". Other references are to the current architecture and requirements drafts (-05 and -06). I have categorized in two dimensions for resolution and severity plus a separate category for "Requirements Problem". Needless to say these categories, like everything else I write, reflect my opinion. Requirements Problem: - The requirement could not or should not be implemented. This is not intended as a catalog of requirements issues, but only those of which it might be said that URP and related parts of the architecture has failed to conform, or that conformance to it provides an explanation for not conforming to another requirement. The requirement should be changed or removed, not the specification. Severity: Show Stopper - Prevents achieving fundamental LDUP goals. Non-compliance - Somebody (else) might argue that the requirement should be changed or removed to accommodate the proposed specification. Resolution: Fatal - Meeting the requirement would need a fundamentally different design approach from that adopted by URP and the architecture. A fix could include work derived from the URP related work (eg for resolving create and rename conflicts), but would negate the core of the current design. These relate to the use of attribute value granularity replication in a directory service where the granularity of operations is at the level of entries and the consequent loss of atomicity information and loss of directory information without any means for even manual recovery. Fixable - Changes to URP and architecture within the current framework could meet the requirement. These mainly relate to the change report propagation mechanism which can be separated from the core aspects of URP and fixed without affecting the integrity of the core design. Some items have been placed in more than one category due to different consequences of the requirement. This is also implicitly a requirements issue as requirements could be separated to avoid that. The URP issues are generally a result of URP complying with the architecture as specified (although I gather those aspects of the architecture are largely a description of URP). Therefore they are also architecture issues. I have not generally considered issues arising only out of the specific text of URP and am strongly opposed to a final call on that text until an architecture has been agreed on. (BTW one that should be easily fixed for any future draft is removal of all references to X.500 DAP and DSP as IETF has no authority over such work and URP was dropped as a work item by those who do, perhaps due to the "Fatal" problems. A follow up on the liaison with ITU specified by the WG charter should be done before further consideration of URP). Some issues involve the *absence* of something in the architecture. Resolution might well involve a separate document from the specifications for conflict resolution. The assertion in these cases is that the design of URP could not integrate with such a specification, not that the specification should have been included within the text of URP when it is not even mentioned in the architecture. * A) Fatal Show Stoppers * 1) Atomicity and information loss First, some background definitions from the requirements draft. Atomic operation - A set of changes to directory data which the LDAP standards guarantee will be treated as a unit; all changes will be made or all the changes will fail. Atomicity Information - Information about atomic operations passed as part of replication. Conflict - A situation that arises when changes are made to the same directory data on different directory servers before replication can synchronize the data on the servers. When the servers do synchronize, they have inconsistent data - a conflict. Conflict resolution - Deterministic procedures used to resolve change information conflicts that may arise during replication. Update Propagation - Protocol-based process by which directory replicas are reconciled. Requirements: P6. The protocol MUST support propagation of atomicity information. MM5. Multi-master replication MUST NOT lose information during replication. If conflict resolution would result in the loss of directory information, the replication process MUST store that information, notify the administrator of the nature of the conflict and the information that was lost, and provide a mechanism for possible override by the administrator. The apparant intention is not to require that replication produce the same results as atomic operations, but to ensure that the information necessary for administrators to manually fix any problems that may result from not doing so is propagated, stored and notified. If an attribute value that would not have been deleted by an atomic operation is in fact deleted as a result of multi-master replication procedures, that clearly constitutes "loss of directory information", and information about that loss must be propagated, stored and notified to administrators so that they can fix any resulting problems. Likewise if information about which user is responsible for modifying an entry is lost. To understand that there are indeed problems, which an administrator would need to fix, consider the following example, a slightly modified version of the example given in B.5.3 of the requirements draft and now in 4.3.3.1 of the new profile draft: draft-ietf-ldup-usage-profile-00.txt. Here is the original example: *** There is an entry with distinguished name DN that contains attributes X, Y, and Z. The value of X is 1. On replica A, a ModifyRequest is processed which includes modifications to change that value of X from 1 to 0 and to set the value of Y to "USER1". At the same time, replica B process[es] a ModifyRequest which includes modifications to change the value of X from 1 to 0 and to set the value of Y to "USER2" and the value of Z to 42. The application in this case is using X as a lock and is depending on the atomic nature of ModifyRequests to provide mutual exclusion for lock access. In the single-server case, the two operations would have occurred sequentially. Since a ModifyRequest is atomic, the entire first operation would succeed. The second ModifyRequest would fail, since the value of X would be 0 when it was attempted, and the modification changing X from 1 to 0 would thus fail. The atomicity rule would cause all other modifications in the ModifyRequest to fail as well. In the multi-master case, it is inevitable that at least some of the changes will be reversed despite the use of the lock. Assuming the changes from A have priority per the conflict resolution algorithm, the value of X should be 0 and the value of Y should be "USER1" The interesting question is the value of Z at the end of the replication cycle. If it is 42, the atomicity constraint on the change from B has been violated. But for it to revert to its previous value, grouping information must be retained and it is not clear when that information can be safely discarded. Thus, requirement G6 may be violated. *** Here is the modified version: There is an entry with distinguished name DN that contains an attribute L, with 3 values X, Y, and Z that was last modified by User C. User A issues a ModifyRequest which includes modifications to change that attribute from X, Y, Z to Y, Z without regard to any other values (leaving them "as is"). Using LDIF notation (RFC 2849): dn: DN changetype: modify delete: L L: X L: Y L: Z - add: L L: Y L: Z - replace: modifiersName modifiersName: A At around the same time, user B issues a ModifyRequest which includes modifications to change the attribute L from X, Y, Z to X, Y again leaving any other values "as is". dn: DN changetype: modify delete: L L: X L: Y L: Z - add: L L: X L: Y - replace: modifiersName modifiersName: B Both operations are relying on the published standards to ensure that "what you read is what you changed". If some other user had removed any of X, Y or Z between the read and write in either case, those published standards guarantee that the entry will not be changed to delete X or to delete Z respectively. Presumably the changes are designed to ensure that Y is associated with either X or Z and does not stand alone regardless of any race condition. If user A's change is processed first, the result will be Y, Z and the change by user B will fail because of the absence of X, which user B had assumed was present when making the change. If user B's change is processed first, the result will be X, Y and the change by user A will fail because of the absence of Z, which user A had assumed was present when making the change. Either way, one of the users will achieve exactly what they intended, the name of that user will be listed as modifiersName and the other user will be safeguarded from achieving a result not intended. With the pre-LDUP use of changelog single master replication, and with the initial installation of LDUP compliant servers in single master mode, for a trial run, everything works as before. But one day a sysadmin turns on multi-master and strange things start to happen. If user A and user B happen to make the changes on the same server, everything works as before. But sometimes they make the changes on different servers (and are unlikely to know this since LDAP is designed to hide which server is being accessed from applications). So sometimes the result is quite different. According to URP a "primitive" to delete X will be replicated with a CSN larger than any existing CSN for X at any replica (and no primitive to add X will be replicated since the only change in state from either of the modify operations did not cause X to be added). Likewise for Z. So both will eventually be deleted at all replicas (with all sorts of possible transient conditions). Regardless of which change is processed first, the final result will be Y and both X and Z will have been deleted. However you look at it, directory information has been lost that would not have been lost if LDUP was not used, or if exactly the same operations had been performed at exactly the same times on a single multi-master server. Responsibility will be arbitrarily assigned to either A or B as modifiersName although neither made the change that actually occurred. No conflict will be notified to an administrator because as far as URP is concerned, no conflict occurred and no conflict resolution procedure was invoked. No atomicity information will be propagated because as far as URP is concerned, the only state changed by either modify operation was the deletion of X or Z, so no other primitives were ever generated and there is no information about the other aspects of this "atomic" operation to replicate. The core design principle of URP is not to treat modify operations as an atomic unit but split them into sub-atomic "primitives", precisely so that each can succeed or fail independently of the others and thus avoid any need for "conflict resolution" and replace it by "update reconciliation". As specified in U4.3: The p-add-attribute-value(uid, csn, type, value) primitive is used to describe the addition of a single attribute value to an entry. The type argument contains the attribute type of the value and the value argument contains the attribute value. The p-remove-attribute-value(uid, csn, type, value) primitive is used to describe the removal of a single attribute value from an entry. The type argument contains the attribute type of the value and the value argument contains the attribute value. [...] These primitives reflect the intended *final* state of an update operation rather than the *specific* changes required to achieve that state. [emphasis added] The architecture draft purports to support the requirements by the following text: *** 10.3 Replication Update Generation The Supplier generates a sequence of Replication Updates to be sent to the consumer. To enforce LDAP Constraint 20.1.6, that the LDAP Modify must be applied atomically, each Replication Update must contain the entire sequence of Update Primitives for all the LDAP Operations for which the Replication Update contains Update Primitives. Stated less formally, for each primitive the update contains, it must also contain all the other primitives that came from the same operation. [...] 10.4 Replication Update Consumption A Consumer will receive Replication Updates, extract the sequence of Update Primitives, and must apply them to the DIB in the order provided. LDAP Constraint 20.1.6 states that the modifications within an LDAP Modify operation must be applied in the sequence provided. Those Update Primitives must be reconciled with the current replica contents and any previously received updates. In short, updates are compared to the state information associated with the item being operated on. If the change has a more recent CSN, then it is applied to the directory contents. If the change has an older CSN it is no longer relevant and its change must not be effected. If the consumer acts as a supplier to other replicas then the updates are retained for forwarding. *** The above text conveys the impression that atomicity information is propagated. Any casual reader would draw that conclusion. Looking closely at the fine print it turns out that these "Update Primitives" which are religiously applied in the same sequence, are not the sequence of modify add, delete and replace components from the original LDAP ModifyRequest operation as would be necessary to propagate the atomicity information specified by 4.6 of RFC 2251. Instead, 10.3.2 specifies that: Each *state* change (entry, attribute, or value - creation, deletion, or update) is mapped onto the equivalent Update Primitive. [emphasis added] The URP introduction elaborates as follows: U3 "Each DAP, LDAP or DSP operation successfully performed by a directory server is subsequently reported to other directory servers with which it has a replication agreement as a set of one or more simple timestamped replication primitives. These primitives reflect the intended *final* state of an update operation rather than the *specific* changes required to achieve that state. [emphasis added] The whole point of this is to split the original atomic operation into "primitives" so that no part of it can affect the outcome of any other part - ie so that it will cease to be atomic. The core design of URP drops all atomicity information and therefore cannot propagate it or notify any administrator about resulting loss of directory information. The entire elaborate exercise of carefully numbering the sequence of modifications and applying them in order is *completely* pointless, achieving absolutely nothing apart from self-deception. The whole point of applying the modifications in sequence as specified by the LDAP standards is so that by deleting a value and then adding it, in the same operation, one can guarantee that the operation will fail if that value had been removed by some other DUA since the entry was read by the DUA that intends to change some related value with another part of the same modify operation. If the components of the modify were applied in the opposite sequence the operation would fail, even if the value was still present because an attempt would be made to add a value that was already present. That and the converse is the only function it serves. This ensures that applications requiring data integrity can avoid a race condition in which some other DUA has made changes to the entry by adding values that the DUA had specified were not there in it's modify operation or deleting values that the DUA had specified were there. It is of course impossible to immediately notify the DUA of the failure in a multi-master context when the conflicting write occurs at another DSA. But it is entirely possible to at least ensure that the final result is the same outcome as would have occurred with single master, by converging to the outcome of only one of the conflicting operations. The requirements draft does not insist on that (although it should and in any case, conformance to the LDAP standards requires it). Neither does the draft explicitly authorize or require the opposite. What it does do is just require that it be possible for administrators to manually fix any problems that may result. Instead of meeting that requirement, the text merely conveys a misleading impression that it does so. 2) Access Control Requirements: M4. LDAP replication MUST encompass schema definitions, attribute names and values, access control information, and name space information. AM6. Access control information (ACI) associated with sensitive data MUST be deleted after or simultaneously with the deletion of the sensitive data. Likewise, during Adds, ACI MUST be added first or simultaneously with the addition of that data. URP does not support the replication of access control at all as a direct consequence of item 1, because access control requires data integrity. In particular any attempt to ensure that ACI is added or deleted simultaneously with associated sensitive data becomes impossible because the only mechanism available for doing so has been broken. Many similar problems also arise but detailed consideration is not necessary since that alone is a Fatal Show Stopper. Consider the example above with attribute L being ldapACI as specified in draft-ietf-ldapext-acl-model-06.txt and X, Y, Z as follows: dn: ou=policy, o=agalaxyfaraway ldapACI: subtree#deny:w#[all]#group:cn=marketing ldapACI: subtree#grant:w#[all]#group:cn=involved ldapACI: subtree#deny:w#[all]#role:cn=madhatter Originally the entry was setup to allow anyone involved to write policy, except for the madhatter. Then a marketing group was setup for convenience in adding others who should not have that permission, but the madhatter was not removed. Eventually all except the madhatter were removed from the excluded group. Then user A notices that the two entries X and Z are redundant since the madhatter is now the only member of the marketing group. A decides to cleanup by deleting X, the redundant deny entry for the marketing group. A does this safely to ensure no possible race condition. Meanwhile user B also notices and decides to cleanup, but makes the opposite decision, deleting Z, the redundant deny entry for the madhatter who is a member of the marketing group anyway. B also does it safely. Result, intended by neither, is that the madhatter is allowed to write policy. From owner-ietf-ldup@mail.imc.org Fri Feb 23 17:47:34 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA25807 for ; Fri, 23 Feb 2001 17:47:34 -0500 (EST) Received: by above.proper.com (8.9.3/8.9.3) id OAA14748 for ietf-ldup-bks; Fri, 23 Feb 2001 14:11:04 -0800 (PST) Received: from cisco.com (nordic.cisco.com [144.254.116.47]) by above.proper.com (8.9.3/8.9.3) with ESMTP id OAA14725 for ; Fri, 23 Feb 2001 14:11:01 -0800 (PST) Received: from [171.70.85.28] (dhcp-2sjc13-85-28.cisco.com [171.70.85.28]) by cisco.com (8.8.8+Sun/8.8.8) with ESMTP id XAA11647; Fri, 23 Feb 2001 23:09:54 +0100 (MET) Mime-Version: 1.0 X-Sender: pfaltstr@nordic.cisco.com Message-Id: In-Reply-To: <000b01c09dd6$a4a96160$6628a8c0@nowhere.com> References: <000b01c09dd6$a4a96160$6628a8c0@nowhere.com> Date: Fri, 23 Feb 2001 14:02:00 -0800 To: "Albert Langer" , "'John Strassner'" , , "'Chris Apple'" , "'Ned Freed'" From: Patrik =?iso-8859-1?Q?F=E4ltstr=F6m?= Subject: Re: Proposed requirements not met by current architecture and URP proposals - part A - Fatal Show Stoppers Content-Type: text/plain; charset="iso-8859-1" ; format="flowed" Sender: owner-ietf-ldup@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: X-MIME-Autoconverted: from 8bit to quoted-printable by above.proper.com id OAA14748 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id RAA25807 At 07.24 +1100 01-02-24, Albert Langer wrote: >Ok, here goes. I'm also CCing to ADs as advance notice of issues that are >likely >to be raised formally in a request for review of LDUP WG decisions if they >continue >unresolved. It will soon be a year since they were first documented. > >Further discussion may just be to the LDUP list and can be either followed >there >now or retrieved from the archives later. FYI, I am on the LDUP list, and get all email. And, yes, LDUP is mine, and not Ned's. I will forward things to Ned if that is needed. If something is to be sent more formally to the AD, it should be sent to me and Ned -- both of us -- and addressed to us. cc:ing is not needed. paf -- Patrik Fältström Internet Engineering Task Force Area Director, Applications Area http://www.ietf.org Phone: (Stockholm) +46-8-4494212 (San Jose) +1-408-525-8509 PGP: 2DFC AAF6 16F0 F276 7843 2DC1 BC79 51D9 7D25 B8DC From owner-ietf-ldup@mail.imc.org Sat Feb 24 00:21:43 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id AAA02671 for ; Sat, 24 Feb 2001 00:21:42 -0500 (EST) Received: by above.proper.com (8.9.3/8.9.3) id UAA03552 for ietf-ldup-bks; Fri, 23 Feb 2001 20:50:07 -0800 (PST) Received: from china.com (TCE-E-7-182-12.bta.net.cn [202.106.182.12]) by above.proper.com (8.9.3/8.9.3) with SMTP id UAA03547 for ; Fri, 23 Feb 2001 20:49:54 -0800 (PST) Received: from china.com([10.1.7.101]) by china.com(JetMail 2.5.3.0) with SMTP id jm453a97a1d2; Sat, 24 Feb 2001 04:42:14 -0000 Received: from loki.ietf.org([132.151.1.177]) by china.com(JetMail 2.5.3.0) with SMTP id jmc3a96b11e; Fri, 23 Feb 2001 13:42:08 -0000 Received: (from adm@localhost) by loki.ietf.org (8.9.1b+Sun/8.9.1) id IAA06364 for ietf-123-outbound.02@ietf.org; Fri, 23 Feb 2001 08:35:00 -0500 (EST) Received: from ietf.org (odin.ietf.org [10.27.2.28]) by loki.ietf.org (8.9.1b+Sun/8.9.1) with ESMTP id GAA05485 for ; Fri, 23 Feb 2001 06:43:35 -0500 (EST) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA27164; Fri, 23 Feb 2001 06:43:33 -0500 (EST) Message-Id: <200102231143.GAA27164@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; CC: ietf-ldup@imc.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-reed-ldup-inheritance-00.txt Date: Fri, 23 Feb 2001 06:43:32 -0500 Sender: owner-ietf-ldup@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Policy Inheritance Mechanisms for LDAP Author(s) : E. Reed Filename : draft-reed-ldup-inheritance-00.txt Pages : 5 Date : 22-Feb-01 There are several possible ways to manage inheritance of policy information in a directory service. This document describes several known mechanisms and recommends one for general use that can be implemented using [LDUP]. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-reed-ldup-inheritance-00.txt Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-reed-ldup-inheritance-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-reed-ldup-inheritance-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20010222132914.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-reed-ldup-inheritance-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-reed-ldup-inheritance-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20010222132914.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ietf-ldup@mail.imc.org Sat Feb 24 19:48:59 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA23877 for ; Sat, 24 Feb 2001 19:48:58 -0500 (EST) Received: by above.proper.com (8.9.3/8.9.3) id QAA19822 for ietf-ldup-bks; Sat, 24 Feb 2001 16:05:59 -0800 (PST) Received: from mail.coreon.net (IDENT:mirapoint@mail.coreon.net [216.74.131.6]) by above.proper.com (8.9.3/8.9.3) with ESMTP id QAA19818 for ; Sat, 24 Feb 2001 16:05:58 -0800 (PST) Received: from rmoats2 (wenjus3.coreon.net [216.74.131.3]) by mail.coreon.net (Mirapoint) with ESMTP id AAA89878 (AUTH rmoats); Sat, 24 Feb 2001 19:04:18 -0500 (EST) From: "Ryan Moats" To: , "'John Strassner'" , , "'Chris Apple'" Subject: RE: Proposed requirements not met by current architecture and URP proposals - part A - Fatal Show Stoppers Date: Sat, 24 Feb 2001 18:09:46 -0600 Message-ID: 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 IMO, Build 9.0.2416 (9.0.2911.0) Importance: Normal In-Reply-To: <000b01c09dd6$a4a96160$6628a8c0@nowhere.com> 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: Content-Transfer-Encoding: 7bit Since the following is a comment about the requirements draft, I'll reply to it... >This ensures that applications requiring data integrity can >avoid a race condition in which some other DUA has made changes to the >entry by adding values that the DUA had specified were not there in it's >modify operation or deleting values that the DUA had specified were there. > >It is of course impossible to immediately notify the DUA of the failure in a >multi-master context when the conflicting write occurs at another DSA. But >it is entirely possible to at least ensure that the final result is the >same outcome as would have occurred with single master, by converging to >the outcome of only one of the conflicting operations. > >The requirements draft does not insist on that (although it should and in >any case, conformance to the LDAP standards requires it). Where precisely does it do this? I see the client needs to recive "notice of the results of the LDAP protocol operation on the server contacted". Any extention to cover changes from replication is architecturally identical to what LCUP is trying to accomplish in terms of notifing clients of changes to directory entries they are interested in. Currently, this requires maintaining open TCP connections to all clients, which has been shown in other situations to not scale. Further, a directory administrator may have an application that does not require this behavior, and if so, why should the directory administrator require it. I think what we state in the requirements is reasonable: The protocol must be able to carry atomicity info in the protocol (directory administrators don't have to use it) and a directory administrator can require notification of replication changes (a la LCUP) if they need it, but that's the directory administrator's requirements, not the WG as a whole. >2) Access Control The example you give for access control is merely a repeat of the first point that you have. I think an independent example would be better or some folks inclination would be to think "ah, AC issues are just a specialization of information loss issues". Ryan From owner-ietf-ldup@mail.imc.org Sun Feb 25 08:53:25 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA09306 for ; Sun, 25 Feb 2001 08:53:24 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.9.3/8.9.3) id FAA07471 for ietf-ldup-bks; Sun, 25 Feb 2001 05:22:23 -0800 (PST) Received: from sj-msg-core-2.cisco.com (sj-msg-core-2.cisco.com [171.69.43.88]) by above.proper.com (8.9.3/8.9.3) with ESMTP id FAA07467 for ; Sun, 25 Feb 2001 05:22:22 -0800 (PST) Received: from mira-sjcm-1.cisco.com (mira-sjcm-1.cisco.com [171.69.43.102]) by sj-msg-core-2.cisco.com (8.9.3/8.9.1) with ESMTP id FAA24736; Sun, 25 Feb 2001 05:22:07 -0800 (PST) Received: from JSTRASSN-W2K1.cisco.com (ams-vpdn-client-409.cisco.com [144.254.47.157]) by mira-sjcm-1.cisco.com (Mirapoint) with ESMTP id AAH05210; Sun, 25 Feb 2001 05:21:38 -0800 (PST) Message-Id: <4.3.2.7.2.20010224220305.00b28ea8@mira-sjcm-1.cisco.com> X-Sender: jstrassn@mira-sjcm-1.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Sun, 25 Feb 2001 05:16:37 -0800 To: ietf-ldup@imc.org From: John Strassner Subject: draft-ietf-ldup-replica-req-06.txt terminology message Cc: johns@cisco.com, capple@ecal.com, paf@cisco.com Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ietf-ldup@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: LDUPers, this is the second memo, summarizing the draft-ietf-ldup-replica-req-06.txt terminology message This memo is written by the WG Co-Chair in order to direct WG members how to move forward. Kurt is objecting to the introduction of LDUP-specific terminology. He's worried that many terms defined in the requirements I-D redefine many existing LDAP/X.500 terms, and wants to see existing LDAP/X.500 terminology used wherever possible. However, the problem is that Kurt has not identified the specific terms that he is objecting to. Actions: 1. Kurt, please delineate the terms that you feel are being redefined. 2. Authors, please respond, indicating how the I-D will change. 3. The WG will evaluate the response. regards, John Strassner Co-Chair, LDUP WG From owner-ietf-ldup@mail.imc.org Sun Feb 25 08:58:45 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA09333 for ; Sun, 25 Feb 2001 08:58:45 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.9.3/8.9.3) id FAA07476 for ietf-ldup-bks; Sun, 25 Feb 2001 05:22:29 -0800 (PST) Received: from sj-msg-core-2.cisco.com (sj-msg-core-2.cisco.com [171.69.43.88]) by above.proper.com (8.9.3/8.9.3) with ESMTP id FAA07472 for ; Sun, 25 Feb 2001 05:22:28 -0800 (PST) Received: from mira-sjcm-1.cisco.com (mira-sjcm-1.cisco.com [171.69.43.102]) by sj-msg-core-2.cisco.com (8.9.3/8.9.1) with ESMTP id FAA24742; Sun, 25 Feb 2001 05:22:14 -0800 (PST) Received: from JSTRASSN-W2K1.cisco.com (ams-vpdn-client-409.cisco.com [144.254.47.157]) by mira-sjcm-1.cisco.com (Mirapoint) with ESMTP id AAH05207; Sun, 25 Feb 2001 05:21:23 -0800 (PST) Message-Id: <4.3.2.7.2.20010224191328.00b3a918@mira-sjcm-1.cisco.com> X-Sender: jstrassn@mira-sjcm-1.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 X-Priority: 1 (Highest) Date: Sat, 24 Feb 2001 19:37:27 -0800 To: ietf-ldup@imc.org From: John Strassner Subject: Procedure for handling Last Call comments on the Requirements I-D Cc: johns@cisco.com, capple@ecal.com, paf@cisco.com Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ietf-ldup@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: LDUPers, thanks for the spirited review of the requirements I-D during the Last Call period. This memo will define the procedure that will be used to respond to the issues raised in the requirements I-D Last Call. It is being written with the WG Chair Hat firmly on. ;-) First, though, I would like to comment that this draft has been out a LONG TIME. While I appreciate people analyzing and commenting on the document, it worries me that most of these issues, which have been there a LONG time, didn't come out until the second week of the last call period. I know that everyone is busy, but please do try and review the next version of this draft in a timely manner. Now, as far as procedure, these are the steps that will be followed. First, I will issue a set of memos, each focused on a specific set of related comments that arose during Last Call. The memos to be issued are summaries and recommendations on the following threads: - RE: WG Last Call on the LDAPv3 Directory Replication I-D - "equally capable" Requirments and Tim Hahn's message - Comments on draft-ietf-ldup-replica-req-06.txt - several counts (Was: WG Last Call on the LDAPv3 Directory Replication I-D) - draft-ietf-ldup-replica-req-06.txt terminology In each pf these five memos, I will summarize the issues, and indicate where I believe we have and do not have WG consensus. On items that we have consensus to change the requirements I-D, to add new requirements, or to clarify existing requirements, I will clearly indicate what is to be done. On all other items, I encourage the authors of the requirements I-D to respond to try and attain closure. While continued discussion can certainly go on, the first goal is to release a new version of the requirements draft asap. It is crucial that, in order to make progress, we accept WG consensus. Therefore, at some point, if discussion continues, I will as Chair ask that the discussion stops. If anyone still has an issue, then I would request those people to talk in private with me and Patrik. The cumulative set of memos issued by me will define a minimum set of changes to make to the requirements I-D. These will result in an update to the current I-D. Once all of my memos are issued, I would like the requirements I-D authors to respond within one week to indicate when they can have an update ready for WG review. In order to maximize time, I fully expect and encourage the WG members to respond to each memo (which I will issue as quickly as possible) as soon as they can. Once the revised I-D hits the repository, we will then have another two weeks to review the new I-D. Assuming that nothing major is discovered, I will announce a second WG Last Call, to last another two weeks. If anyone thinks that this is not enough time, please speak up now and clearly indicate why. You had better have a very good argument. ;-) thanks and kind regards, John Strassner, with Chair hat ON From owner-ietf-ldup@mail.imc.org Sun Feb 25 08:59:26 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA09344 for ; Sun, 25 Feb 2001 08:59:25 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.9.3/8.9.3) id FAA07465 for ietf-ldup-bks; Sun, 25 Feb 2001 05:22:15 -0800 (PST) Received: from sj-msg-core-2.cisco.com (sj-msg-core-2.cisco.com [171.69.43.88]) by above.proper.com (8.9.3/8.9.3) with ESMTP id FAA07461 for ; Sun, 25 Feb 2001 05:22:13 -0800 (PST) Received: from mira-sjcm-1.cisco.com (mira-sjcm-1.cisco.com [171.69.43.102]) by sj-msg-core-2.cisco.com (8.9.3/8.9.1) with ESMTP id FAA24706; Sun, 25 Feb 2001 05:21:53 -0800 (PST) Received: from JSTRASSN-W2K1.cisco.com (ams-vpdn-client-409.cisco.com [144.254.47.157]) by mira-sjcm-1.cisco.com (Mirapoint) with ESMTP id AAH05209; Sun, 25 Feb 2001 05:21:33 -0800 (PST) Message-Id: <4.3.2.7.2.20010224101251.00b64358@mira-sjcm-1.cisco.com> X-Sender: jstrassn@mira-sjcm-1.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Sat, 24 Feb 2001 22:02:26 -0800 To: ietf-ldup@imc.org From: John Strassner Subject: Consolidation of WG Comments on Requirements I-D Last Call Thread Cc: johns@cisco.com, capple@ecal.com, paf@cisco.com Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ietf-ldup@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: LDUPers, this is the first memo, summarizing the thread: RE: WG Last Call on the LDAPv3 Directory Replication I-D. Note that there were a lot of subjects covered in this thread. Only those subjects that directly pertain to the requirements I-D will be discussed here. Other subjects having merit will be discussed later. This memo is written as a summarization by the WG Co-Chair of declaring consensus on discussed items and requesting changes to be made to the current (-06) version of the requirements I-D prior to it being reissued for WG Last Call. Sub-issue 1: text describing objectives (in Section 3), passive store Chair Summary: This was a long thread. The idea was to define the notion of a "passive store" and then to limit LDUP to directory servers which implement a passive store. It also gave several specific examples of functionality that were not passive in nature. I believe that the WG has rejected this notion because of the difficulty in precisely defining a passive store, and also because the examples repeatedly referred to functions that do not exist as LDAP standards yet. While one of the examples, access control, is being handled in LDAPext, the other examples don't even have drafts written for them. As chair, I am unwilling to delay the requirements document any longer, and do not want to hold it hostage to mechanisms that may, one day, be written in a WG. Action: none required in the I-D Sub-issue 2: text describing objectives (in Section 3), clarity of text Some people wondered if the text was clear enough in pointing out that LDUP was providing "...interoperability between directories rather than between their representations". I think that, in order to move on, it would be helpful to have a brief sentence or two added to the draft that clarifies this point. Action: add clarification that when LDUP is used to replicate information that is interpreted by a directory server in ways that are not standardized by LDAP, the results are unpredictable. Sub-issue 3: access control. This draft is being developed in LDAPEXT. A question was raised as to whether the LDUP WG should be responsible for supporting replication of ACI. The answer is NO. There are several reasons why, the most important of which is that unless the original authors in the original WG that wrote the draft write the requirements for LDUP, there will be conflicts. Then, we have a mess, because the LDUP ACM wouldn't agree with the more general LDAPext ACM. The **only** solution to this dilemma is to have the LDAPext authors take on this work. Action: none required in the requirements I-D; LDUP chairs to bring this up with LDAPext chairs and report to the LDUP WG Sub-issue 4: locking Locking is not germane to the requirements draft. It is up to the architecture and other drafts, as required, to address locking. However, several people have suggested that if developers attempt to create their own locking or other similar control mechanisms, the requirements draft should state that they do so at their own peril when operating against directories supporting LDUP. I agree. Action: a brief explanatory note pointing this out should be added to the requirements I-D. Sub-issue 5: defining what types of information should be replicated Several people suggested that we should describe the general class of information that can not be replicated, plus some examples, and stop at the place where enough examples are listed to make the issue clear. Since there was no clear consensus here, I'll state my views. I don't think that this is a good idea. The list that we will come up with will not be complete, and this will confuse people. Second, what's the point? Such information is either being controlled via non-standardized mechanisms, or is handled in application-specific manners. If the mechanism is not standardized, I don't see how it can be replicated. Action: none required in the I-D Sub-issue 6: noting unsuitability of LDUP for environments with "high rate of change" While everyone agrees with this, no one could come up with a reasonable definition of "high rate of change". However, there is consensus that this should not be specified in the requirements draft, but rather in other drafts (architecture and profile are obvious candidates). A suggestion was to change in section B.5.5 from "They are changing the data at the same time" to "They are changing the data before previous changes have replicated". Action: change in section B.5.5 from "They are changing the data at the same time" to "They are changing the data before previous changes have replicated". Sub-issue 7: removal of P6 (atomicity information) We've had one argument and one reply which said "yes it does" without technical justification. The request centered around replicating and converging state, and defined atomicity in an application-specific sense. While I don't believe that the requirements draft was concerned with application-specific atomicity information, I do think that this needs a response, and likely better definition of what, specifically, propagating atomicity information means. Action: This requirement needs to be explained and justified in the I-D. The I-D should answer the question of whether it is propagating end-state or propagating a set of operations required to replicate that end-state, and WHY it is doing so. Sub-issue 8: do the examples need modification? The specific issue was whether the examples bring out sufficiently whether the dominant application of multi-master replication is to facilitate locally improved performance and availability of directory content. First, this WG is not in a position to decide what is or is not a dominant use of directories. Second, I only have one person asserting that the example does not bring out this point. It is fruitless to argue this point, it **is** after all just an example. Action: no action required for the I-D. regards, John Strassner Co-Chair, LDUP WG From owner-ietf-ldup@mail.imc.org Sun Feb 25 09:07:51 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA09438 for ; Sun, 25 Feb 2001 09:07:50 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.9.3/8.9.3) id FAA07759 for ietf-ldup-bks; Sun, 25 Feb 2001 05:34:19 -0800 (PST) Received: from sj-msg-core-1.cisco.com (sj-msg-core-1.cisco.com [171.71.163.11]) by above.proper.com (8.9.3/8.9.3) with ESMTP id FAA07755 for ; Sun, 25 Feb 2001 05:34:18 -0800 (PST) Received: from mira-sjcm-1.cisco.com (mira-sjcm-1.cisco.com [171.69.43.102]) by sj-msg-core-1.cisco.com (8.9.3/8.9.1) with ESMTP id FAA22372; Sun, 25 Feb 2001 05:34:05 -0800 (PST) Received: from JSTRASSN-W2K1.cisco.com (ams-vpdn-client-409.cisco.com [144.254.47.157]) by mira-sjcm-1.cisco.com (Mirapoint) with ESMTP id AAH05250; Sun, 25 Feb 2001 05:33:12 -0800 (PST) Message-Id: <4.3.2.7.2.20010225053140.00b8f918@mira-sjcm-1.cisco.com> X-Sender: jstrassn@mira-sjcm-1.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Sun, 25 Feb 2001 05:33:04 -0800 To: ietf-ldup@imc.org From: John Strassner Subject: Fwd: Procedure for handling Last Call comments on the Requirements I-D Cc: johns@cisco.com, capple@ecal.com, paf@cisco.com Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ietf-ldup@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: LDUPers, sorry, there is a typo in my message. I wrote: - "equally capable" Requirments and Tim Hahn's message but I meant: - "equally capable" Requirments and other comments from Kurt Zeilenga My apologies. regards, John >Date: Sat, 24 Feb 2001 19:37:27 -0800 >To: ietf-ldup@imc.org >From: John Strassner >Subject: Procedure for handling Last Call comments on the Requirements I-D >Cc: johns@cisco.com, capple@ecal.com, paf@cisco.com > >LDUPers, > >thanks for the spirited review of the requirements I-D during the Last >Call period. This memo will define the procedure that will be used to >respond to the issues raised in the requirements I-D Last Call. It is >being written with the WG Chair Hat firmly on. ;-) > >First, though, I would like to comment that this draft has been out a LONG >TIME. While I appreciate people analyzing and commenting on the document, >it worries me that most of these issues, which have been there a LONG >time, didn't come out until the second week of the last call period. I >know that everyone is busy, but please do try and review the next version >of this draft in a timely manner. > >Now, as far as procedure, these are the steps that will be followed. >First, I will issue a set of memos, each focused on a specific set of >related comments that arose during Last Call. The memos to be issued are >summaries and recommendations on the following threads: > > - RE: WG Last Call on the LDAPv3 Directory Replication I-D > - "equally capable" Requirments and Tim Hahn's message > - Comments on draft-ietf-ldup-replica-req-06.txt > - several counts (Was: WG Last Call on the LDAPv3 Directory > Replication I-D) > - draft-ietf-ldup-replica-req-06.txt terminology > >In each pf these five memos, I will summarize the issues, and indicate >where I believe we have and do not have WG consensus. On items that we >have consensus to change the requirements I-D, to add new requirements, or >to clarify existing requirements, I will clearly indicate what is to be >done. On all other items, I encourage the authors of the requirements I-D >to respond to try and attain closure. While continued discussion can >certainly go on, the first goal is to release a new version of the >requirements draft asap. It is crucial that, in order to make progress, we >accept WG consensus. Therefore, at some point, if discussion continues, I >will as Chair ask that the discussion stops. If anyone still has an issue, >then I would request those people to talk in private with me and Patrik. > >The cumulative set of memos issued by me will define a minimum set of >changes to make to the requirements I-D. These will result in an update to >the current I-D. Once all of my memos are issued, I would like the >requirements I-D authors to respond within one week to indicate when they >can have an update ready for WG review. In order to maximize time, I fully >expect and encourage the WG members to respond to each memo (which I will >issue as quickly as possible) as soon as they can. > >Once the revised I-D hits the repository, we will then have another two >weeks to review the new I-D. Assuming that nothing major is discovered, I >will announce a second WG Last Call, to last another two weeks. If anyone >thinks that this is not enough time, please speak up now and clearly >indicate why. You had better have a very good argument. ;-) > >thanks and kind regards, >John Strassner, with Chair hat ON From owner-ietf-ldup@mail.imc.org Sun Feb 25 09:55:46 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA09636 for ; Sun, 25 Feb 2001 09:55:46 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.9.3/8.9.3) id FAA10682 for ietf-ldup-bks; Sun, 25 Feb 2001 05:56:39 -0800 (PST) Received: from relay1.pair.com (relay1.pair.com [209.68.1.20]) by above.proper.com (8.9.3/8.9.3) with SMTP id FAA10673 for ; Sun, 25 Feb 2001 05:56:37 -0800 (PST) Received: (qmail 5852 invoked from network); 25 Feb 2001 13:56:05 -0000 Received: from cpe-144-132-70-18.vic.bigpond.net.au (HELO w98) (144.132.70.18) by relay1.pair.com with SMTP; 25 Feb 2001 13:56:05 -0000 X-pair-Authenticated: 144.132.70.18 Reply-To: From: "Albert Langer" To: "'Ryan Moats'" , Subject: RE: Proposed requirements not met by current architecture and URP proposals - part A - Fatal Show Stoppers Date: Mon, 26 Feb 2001 00:59:51 +1100 Message-ID: <003a01c09f33$39dff160$6628a8c0@nowhere.com> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_003B_01C09F8F.6D506960" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2910.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 In-Reply-To: Importance: Normal 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_003B_01C09F8F.6D506960 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit [Ryan] http://www.imc.org/ietf-ldup/mail-archive/msg00892.html Since the following is a comment about the requirements draft, I'll reply to it... >This ensures that applications requiring data integrity can >avoid a race condition in which some other DUA has made changes to the >entry by adding values that the DUA had specified were not there in it's >modify operation or deleting values that the DUA had specified were there. > >It is of course impossible to immediately notify the DUA of the failure in a >multi-master context when the conflicting write occurs at another DSA. But >it is entirely possible to at least ensure that the final result is the >same outcome as would have occurred with single master, by converging to >the outcome of only one of the conflicting operations. > >The requirements draft does not insist on that (although it should and in >any case, conformance to the LDAP standards requires it). Where precisely does it do this? I see the client needs to recive "notice of the results of the LDAP protocol operation on the server contacted". Any extention to cover changes from replication is architecturally identical to what LCUP is trying to accomplish in terms of notifing clients of changes to directory entries they are interested in. Currently, this requires maintaining open TCP connections to all clients, which has been shown in other situations to not scale. [Albert] BTW, I have also removed Chris and John from CC list in light of Patrik's request, as they can also be assumed to be subscribed. I'm not sure whether we are at cross purposes here. There is now a very clear definition in the requirements draft: "Atomic operation - A set of changes to directory data which the LDAP standards guarantee will be treated as a unit; all changes will be made or all the changes will fail." Once that has been adopted I would respond to anyone claiming that there is no such guarantee in the LDAP standards by simply referring them to what LDUP has formally agreed to as a "rough consensus". I would hope that the WG chairs would insist that we move on and not reopen the clearly settled question of whether the LDAP standards do "guarantee" that all changes will be made or all changes will fail. It will be much easier to move on once the WG actually has adopted something. So if, as an author of that draft you are asking me where "conformance to the LDAP standards requires it" I would refer you to the same place from which you drew the conclusion about the "guarantee". (Presumably section 4.6 of RFC 2251). Meanwhile, I have to assume you are in fact asking about proposals for notifications concerning constraints that were not enforced immediately but are subsequently discovered in the course of conflict resolution, although that is not mentioned in the paragraph you quoted and replied to. The way I see it LDAP standards specify what can be written to the directory so as to determine what can be read from it and thus enable globally deployable directory applications to work with any conformant server and any conformant client using a standardized client server protocol. As part of that they specify *both* what must be the outcome of an update write invoked by a client and what response and error messages must be returned to the client immediately. There is no provision for subsequent notifications to clients in the base standards because the response returned immediately is entirely sufficient in a single server or a single master environment. That environment necessarily provides only "loose consistency" in which inconsistent data may be read from different servers because even single master replication does not happen until *after* the response is returned to the client and even single servers use referrals to other servers in the distributed global directory, with no mechanisms for referential integrity. Strict conformance to the LDAP standards requires conforming to *both* aspects and maintaining that "loose consistency" model. Multi-master inherently *cannot* conform to the second aspect of notifying clients of the results immediately. That is an argument for keeping it "experimental" as Kurt suggested, until such time as operational experience has been acquired, and the impact on existing standards evaluated and any necessary revisions undertaken. Nevertheless, the WG has been explicitly chartered to develop multi-master standards track RFCs as well as single master, so it is safe enough to assume that we have not been chartered to do the impossible and we would be entitled to get quite indignant at any work done here being rejected for not having achieved the impossible. That certainly does not excuse us from meeting the other aspect of the constraints by ensuring that eventual convergence is to the same outcome as the existing data model - not an outcome with loops in which entries can be their own ancestors or mandatory attributes can have no values or entries can have no names or in which any other inconsistent operations will corrupt the integrity of directory information. The only one of those enforced by URP is loops. Remember only inconsistent reads are an issue in single master. Inconsistent update operations are the very essence of what multi-master standards have to deal with. They are dealt with as regards create and rename conflicts, and must also be dealt with as regards other write operation conflicts. The architecture draft explains this quite adequately in section 3.7. I propose that text be moved to the requirements draft as there may be some ongoing confusion within the WG about it and it would certainly be a new concept to other readers: *** In the case of a single-server or single-mastered Replication Context all LDAP Constraints are immediately enforced at the single updateable replica. An error result code is returned to an LDAP Client that presents an operation that would violate the constraints. In the case of a multi-mastered Replication Context not all LDAP Constraints can be immediately enforced at the updateable replica to which the LDAP Update Operation is applied. This loosely consistent replication architecture ensures that at each replica all constraints are imposed, but as updates are replicated constraint violations arise that cannot be reported to the appropriate client. Any constraint violations that occur are repaired by a set of update resolution procedures. Any LDAP client that has been implemented to expect immediate enforcement of all LDAP Constraints may not behave as expected against a multi-mastered Replication Context. *** That to me is a reasonable statement of what LDUP MUST do in order to be acceptable as a standards track protocol consistent with deploying multi-master servers in the same *global* environment as those using existing standards. So how about putting it in the requirements? If, in addition to not being able to enforce the constraints immediately, it is proposed not to enforce any *one* of them at all, that should be stated equally explicitly in the requirements draft and signoff should be obtained from others affected as to whether that is acceptable before proceeding further. Otherwise LDUP would not be consistent with the fundamental data model of the LDAP standards as well as being inherently unable to fully implement the operations model by not being able to enforce the constraints of that data model immediately. Certainly there should be no statement, either in the requiements or the architecture that "any constraint violations that occur are repaired by a set of update resolution procedures" unless that statement is true. One of those constraints, explicitly listed in the architecture draft, but *not* implemented by URP, is atomicity of modifications which is needed to support requirements for data integrity in the fundamental data model. I am not part of any "rough consensus" about the requirements draft because I do not see how adopting it can resolve anything when the same people who endorse it at an IETF meeting also say that URP is ready for final call at the same meeting. To me, adoption of a "rough consensus" decision should *resolve* something, so that we can move on. If the WG has come to the conclusion that it cannot or should not enforce that constraint then it should say so, loud and clear right up front in the requirements draft. No amount of repetition from John and Chris or anyone else about the "room consensus" at IETF meetings can ever substitute for a clear decision by the WG expressed in having actually endorsed an explicit text. My own view is that provision for such notifications is essential in view of the operations model currently expected by clients being incompatible with that which can be provided by multi-master. I believe it should be clearly stated as a requirement so that work on meeting that requirement will begin now, rather than later. However I have agreed with you that discussion can be deferred until after the requirements draft has gone through as there is very clearly no consensus in support of it and the need for it can emerge in discussion of concrete measures to implement what appears to be agreed, about notifications to system administrators. As long as it is *possible* to notify system administrators, then a decision to implement other notifications later would not require fundamental redesign but merely adding something, so the requirement as currently stated is sufficient to avoid being trapped in a wrong architecture later. That is also why I have, at John's request, documented yet again that the current architecture and the URP design does not meet that stated requirement to be able to repair constraint requirement violations, let alone the stronger language in the architecture draft - that constraint violations are actually repaired. As for how to do add notifications. I do not think it is necessary to discuss that during this "last call" on requirements as there is no requirement either to add them or not to do so. However I have already put forward suggestions (not concrete proposals) in MDCR. The only concrete proposal was that only the originator DSA should be responsible for revocation or confirmation notices to the DUA that invoked the original change at that DSA. This is consistent with having separate conformance levels for implementations that do not provide notifications (although I am not convinced that would be desirable). I just referred generally to: Sending notifications would presumably depend on controls the DUAs used in their operations, attributes in the directory entry, perhaps in some other NC, for the DUAs DN (modifiersName) etc. Details should be considered in connection with other work on notifications and transactions as the complete history maintained by these procedures are likely to be relevant to both. My own view is that the "other" (LCUP) work on notifications would meet the harder requirements of the few applications that really need confirmations as soon as possible and that revocation notices by email to the DUA's email address would be adequate for most applications that just need to be told what went wrong before something else dependent on it results in calls to a help desk. After all, multi-master is inherently unsuitable for applications with a high rate of concurrent changes to the same entry anyway. Indeed the directory service itself is designed for relatively static data with a high ratio of reads to writes. So simply firing off an email when something undesirable happens is not a huge burden. Manually dealing with help desk calls from users puzzled about unexpected and unexplained events that were not happening before would be far worse. BTW I believe such notices are needed for create and rename conflicts as well. URP simply renames both entries for double the work. My understanding is that the argument for that is based on the possibility of confusion if somebody applies changes to some other entry thinking it is the entry they have just created or renamed. I believe there is no way around the fact that the name of an entry uniquely specifies *the* entry as far as the whole X.500/LDAP data model and all applications based on it is concerned, and that notifications are a better solution. Again however, that need not be a requirements issue at present as URP clearly *does* preserve the information necessary to correct the problem, so a decision to reduce the sysadmin and helpdesk workload via notifications to applications and their users can be taken later without needing a fundamental redesign. In fact the more I think about it, the more I see advantages in your minimalist approach of just requiring now that the necessary information be propagated and made available to system administrators. That approach is consistent with the architectural principle in RFC 1958: 3.7 In many cases it is better to adopt an almost complete solution now, rather than to wait until a perfect solution can be found. It is also consistent with my referring to details to be considered later, in MDCR and with my not having included notifications among the 3 "key points" in my "Summary of Objections to Requirements Draft" which eventually led to the review by you and Rick: http://www.imc.org/ietf-ldup/mail-archive/msg00635.html BTW I have not raised the third key issue, "modifiersName" as a requirements issue as I gather the non-normative text reflects a likely WG consensus that it should be supported anyway. In giving the example concerning deletion of X by user A and Z by user B, with responsibility for both changes arbitrarily assigned to one of them, I should perhaps have explicitly mentioned that this violates the semantics and frustrates the purpose of modifiersName rather than just referring to it as loss of directory information. If for example A is arbitrarily listed there is no way to tell that it was actually B who deleted Z and solve the mystery as to "who done it" when inspection of the application used by A shows it appears to work safely. With the required semantics you can always be sure that whoever is listed used an application which resulted in a corrupted entry, so fixing that application to ensure "what you changed is what you saw" will solve the problem. With URP all you get is a mystery, further confused by a misleading "modifiersName". [Ryan] Further, a directory administrator may have an application that does not require this behavior, and if so, why should the directory administrator require it. I think what we state in the requirements is reasonable: The protocol must be able to carry atomicity info in the protocol (directory administrators don't have to use it) and a directory administrator can require notification of replication changes (a la LCUP) if they need it, but that's the directory administrator's requirements, not the WG as a whole. [Albert] *Many* applications may not need it. There is some evidence in support of that from the deployment of two non-interoperable multi-master implementations that do not provide it. Presumably they would have fixed the problem if it made things unviable in a closed environment where applications are using vendor APIs rather than LDAP APIs for applications that require data integrity. For example Active Directory uses a single valued attribute for access controls which can only be modified easily through specific proprietary COM APIs and has an elaborate rigmarole for other COM APIs to use "consistency guids" and "child counts" to maintain data integrity. They also provide 3 different kinds of trigger/notifications services for use through COM APIs. Attempting to achieve standards for interoperability among clients and servers using a common protocol with *different* clients in an open environment *does* require that everything necessary for that be fully standardized. Otherwise the directory administrator has to select a single proprietary implementation for all DSAs in a multi-master replication network, simply because *some* applications *do* require data integrity. That negates the point of interoperability - especially considering that one of those applications is access control. BTW It should be emphasized that there can only be one directory administration in a multi-master replication network, since each DSA is equally authoritative. It certainly can't be a matter of each individual DSA deciding what it needs to use. In the event that requirements indicate there is scope for local DSAs that never have DUAs using applications that need data integrity, then a separate conformance level could be defined, without notifications. But unless whatever is required for full interoperability is actually defined by some standard, then it simply cannot be achieved by a directory administration wishing for it. [Ryan] >2) Access Control The example you give for access control is merely a repeat of the first point that you have. I think an independent example would be better or some folks inclination would be to think "ah, AC issues are just a specialization of information loss issues". [Albert] Yes I chose the example to fit precisely with the requirements concerning information loss and illustrate the consequences for access controls. You have certainly demonstrated a better understanding than mine of what "some folks" are inclined to assume and how to get things across to the WG, so by all means feel free to add more suitable examples. Frankly, after nearly a year, I have run out of patience myself. In my view it ought to be sufficient to have merely pointed out that the LDAP data model requires atomicity and URP does not support it, as was done repeatedly by many people before I joined the WG. It should not have been necessary to write a draft explaining that: For the same reasons, URP must inevitably break the semantics of other relationships between attributes values understood only by applications. Among those applications are the management of prescriptive access controls and other policy information, and hence the viability of multi-master replication itself. Nor should it have been necessary to provide a positive solution, showing how the problem can be fixed, as I did nearly a year ago. People competent to take decisions about these matters should be expected to understand that if you break the data model, then applications dependent on that model will break and realize the need for a different approach without tutorials. It should not have been necessary to spell it out in detail, with an example of loss of directory information, as I did more than 6 months ago: *** The problem I was referring to is that URP merges the addition or deletion of different attribute values of a single entry made concurrently by DUA operations at different replicas. That means the set of ACI attribute values which each of two users thought they were establishing, will differ from the set of ACI attribute values that actually result from their concurrent actions. The example below from Alison's document shows the 9 states that could result from concurrent updates to two attributes at one replica with eventual convergence to one of those changes. Exactly the same applies to concurrent changes to two values of a single attribute such as ldapACI. In addition, the eventual convergence can be to a mixture of both changes with some attributes or attribute values changed by one concurrent operation and others changed by the other. If two users delete an attribute value from an attribute with 2 values it ends up empty, and possibly a schema violation, although each thought they were setting it to the single value the other thought they were deleting. *** http://www.imc.org/ietf-ldup/mail-archive/msg00641.html Since John actually *asked* for an elaboration, even though it was mixed in with the usual hallucinations about everything being settled, I have provided it. Here's the pseudo code you would have to deal with to confirm that URP does not detect the loss of directory information and report a schema violation when 2 values are concurrently deleted from a mandatory attribute: 5.3.7 Processing Remove Attribute Value Primitive This section details the algorithm for processing the p-remove- attribute-value (P.uid, P.type, P.value, P.csn) primitive, which describes the removal of a single attribute value. If P.type is the entryUUID attribute type then the primitive MUST be rejected. IF no value deletion record (uid, type, value, csn) exists where (uid = P.uid AND type = P.type AND value = P.value AND csn >= P.csn) AND no attribute deletion record (uid, type, csn) exists where (uid = P.uid AND type = P.type AND csn >= P.csn) AND no entry deletion record (uid, csn) exists where (uid = P.uid AND csn >= P.csn) IF entry, E, with uid = P.uid exists { IF P.csn > E.csn IF attribute value, V, of P.type where V = P.value, exists in E { IF P.csn > V.csn IF V is distinguished IF ProtectDistinguished() V.csn := GenerateNextCSN(P.csn) ELSE { R := E.rdn remove value V CheckUniqueness(E, E.superior, R) StoreValueDeletion (P.uid, P.type, P.value, P.csn) } ELSE { remove value V StoreValueDeletion (P.uid, P.type, P.value, P.csn) } } ELSE StoreValueDeletion (P.uid, P.type, P.value, P.csn) } ELSE StoreValueDeletion (P.uid, P.type, P.value, P.csn) Want some documentation? Sorry folks, those 38 lines *are* the documentation. If you can tell that the above means that URP loses directory information and does not detect schema conflicts, then you have solved the URP puzzle. Although I claim the honour of having done it long ago. On joining the WG I read through the archives and noted that it had become bogged down playing puzzle games in which somebody would suggest something that URP breaks and Steve would either demonstrate that it doesn't or propose another fix. The central point that a protocol design has to be verifiable and comprehensible so that you *know* what will happen when you deploy it, was completely lost. There are good reasons for the IETF requirement of at least 2 interoperable implementations based on a published specification. It just went on and on, even after someone had remarked that aspects were: "...preposterously complex. You seem to be tying yourselves in knots with this..." That was from an X.500 expert - unlikely to be unusually intolerant of preposterously complex specifications. If LDUP WG members enjoy such puzzles, as I do, attached is a slightly shorter one. What is the next number? 1 11 21 1211 111221 Answers by email will be acknowledged. Please do not answer in the list. But note that it *is* a puzzle. Knowing how something works for a few examples does not immediately tell you the principle behind it or how it will work with other examples. For that you need to know the algorithm. But that can be puzzle too, as in the attached python code, slightly shorter than the above URP pseudo code, which likewise doesn't tell you much about what it actually does, although it reproduces that sequence exactly. It is generally understood that *one* example is sufficient to demonstrate that a protocol is broken. There should be no need to provide others. It is up to the proponents to show correctness. But iff you believe further examples would be useful, by all means provide them. Meanwhile I've got to get back to repeating myself on all the other issues that John asked me to elaborate on. In my view a quick glance at URP ought to have been sufficient to reject the idea of an interoperable standard being based on obscure pseudocode. There ought to be requirement that the protocol specifications be be predictable and make some kind of sense to users - as suggested long ago. So that (plus moving the text from the architecture draft) makes two more requirements issues. ------=_NextPart_000_003B_01C09F8F.6D506960 Content-Type: text/plain; name="what_is_the_next_number.py" Content-Disposition: attachment; filename="what_is_the_next_number.py" Content-Transfer-Encoding: quoted-printable #!/usr/bin/env python '''Even python code needs documentation and modularization This is an efficient algorithm for generating the sequence of numbers it = prints. No extraordinary measures have been taken to obfuscate the code or to = use a more complex efficient algorithm. (Efficiency has not actually been = benchmarked against a simpler but assumed slower version). The sequence has a very simple rule, easily described in one short = sentence. People asked "what is the next number" often take a long time to get it = right. When they do they have figured out the rule. Assertion1: It could be quicker for a python programmer to figure out the rule from just looking at the printout than from looking at the code. Assertion2: Even using a debugger may not help much. (Not verified) Assertion3: Printing more numbers from the sequence may help, but not = all that much. It is still difficult to see what the following number would be = (not verified). Assertion4: Even after knowing the rule the actual algorithm used by the = code is still obscure and unmaintainable. (Verified - author finds it = unreadable). Conclusion: Provide adequate documentation and don't reduce modularity = and clarity for efficiency where not essential or without additional documentation. To do: 1. Provide some UI for use as a puzzle (hints etc) and as educational = software (with a properly documented version). 2. Enter into an "obfuscated python" contest if there is one ;-) 3. Do benchmarks. ''' n=3Dlambda s:''.join(map(lambda x: "%s%s" % (len(x),x[0]),map( lambda x, s=3Dmap(int,s): s[x[0]:x[1]], zip( ([0] + map( lambda x: x[0]+1, filter(lambda s: s[1][0] !=3D s[1][1], zip(range(len((len(s) < 2 and []) or zip(s[:-1], = s[1:])) ), (len(s) < 2 and []) or = zip(s[:-1], s[1:]) ) ) ) + [len(s)])[:-1], ([0] + map( lambda x: x[0]+1, filter(lambda s: s[1][0] !=3D s[1][1], zip(range(len((len(s) < 2 and []) or zip(s[:-1], = s[1:])) ), (len(s) < 2 and []) or = zip(s[:-1], s[1:]) ) ) ) + [len(s)])[1:], =20 ) ) )) t =3D '1' for i in range(5): print t t =3D n(t) =20 ------=_NextPart_000_003B_01C09F8F.6D506960-- From owner-ietf-ldup@mail.imc.org Sun Feb 25 10:51:57 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA09922 for ; Sun, 25 Feb 2001 10:51:56 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.9.3/8.9.3) id HAA14792 for ietf-ldup-bks; Sun, 25 Feb 2001 07:20:14 -0800 (PST) Received: from mail.coreon.net (IDENT:mirapoint@mail.coreon.net [216.74.131.6]) by above.proper.com (8.9.3/8.9.3) with ESMTP id HAA14788 for ; Sun, 25 Feb 2001 07:20:12 -0800 (PST) Received: from rmoats2 (wenjus3.coreon.net [216.74.131.3]) by mail.coreon.net (Mirapoint) with ESMTP id AAA90034 (AUTH rmoats); Sun, 25 Feb 2001 10:18:46 -0500 (EST) From: "Ryan Moats" To: , "'Ryan Moats'" , Cc: "Richard Huber" , "Russel F Weiser" , "Ellen Stokes" Subject: RE: Proposed requirements not met by current architecture and URP proposals - part A - Fatal Show Stoppers Date: Sun, 25 Feb 2001 09:24:17 -0600 Message-ID: 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 IMO, Build 9.0.2416 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 In-Reply-To: <003a01c09f33$39dff160$6628a8c0@nowhere.com> Importance: Normal Sender: owner-ietf-ldup@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit See ... below... Ryan P.S. I'm extracting some stuff to shorten the message with [snip...] -----Original Message----- From: Albert Langer [mailto:Albert.Langer@Directory-Designs.org] URP proposals - part A - Fatal Show Stoppers [Ryan] http://www.imc.org/ietf-ldup/mail-archive/msg00892.html Since the following is a comment about the requirements draft, I'll reply to it... [snip...] >It is of course impossible to immediately notify the DUA of the failure in a >multi-master context when the conflicting write occurs at another DSA. But >it is entirely possible to at least ensure that the final result is the >same outcome as would have occurred with single master, by converging to >the outcome of only one of the conflicting operations. > >The requirements draft does not insist on that (although it should and in >any case, conformance to the LDAP standards requires it). Where precisely does it do this? I see the client needs to recive "notice of the results of the LDAP protocol operation on the server contacted". Any extention to cover changes from replication is architecturally identical to what LCUP is trying to accomplish in terms of notifing clients of changes to directory entries they are interested in. Currently, this requires maintaining open TCP connections to all clients, which has been shown in other situations to not scale. [Albert] [snip] Meanwhile, I have to assume you are in fact asking about proposals for notifications concerning constraints that were not enforced immediately but are subsequently discovered in the course of conflict resolution, although that is not mentioned in the paragraph you quoted and replied to. That was my intent, and I thought it was clear The way I see it LDAP standards specify what can be written to the directory so as to determine what can be read from it and thus enable globally deployable directory applications to work with any conformant server and any conformant client using a standardized client server protocol. As part of that they specify *both* what must be the outcome of an update write invoked by a client and what response and error messages must be returned to the client immediately. There is no provision for subsequent notifications to clients in the base standards because the response returned immediately is entirely sufficient in a single server or a single master environment. That environment necessarily provides only "loose consistency" in which inconsistent data may be read from different servers because even single master replication does not happen until *after* the response is returned to the client and even single servers use referrals to other servers in the distributed global directory, with no mechanisms for referential integrity. Strict conformance to the LDAP standards requires conforming to *both* aspects and maintaining that "loose consistency" model. Multi-master inherently *cannot* conform to the second aspect of notifying clients of the results immediately. That is an argument for keeping it "experimental" as Kurt suggested, until such time as operational experience has been acquired, and the impact on existing standards evaluated and any necessary revisions undertaken. Ah, that's where we differ. I feel that once the initial notice is made, "loose consisitency" is being maintained. Nevertheless, the WG has been explicitly chartered to develop multi-master standards track RFCs as well as single master, so it is safe enough to assume that we have not been chartered to do the impossible and we would be entitled to get quite indignant at any work done here being rejected for not having achieved the impossible. That certainly does not excuse us from meeting the other aspect of the constraints by ensuring that eventual convergence is to the same outcome as the existing data model - not an outcome with loops in which entries can be their own ancestors or mandatory attributes can have no values or entries can have no names or in which any other inconsistent operations will corrupt the integrity of directory information. The only one of those enforced by URP is loops. Remember only inconsistent reads are an issue in single master. Inconsistent update operations are the very essence of what multi-master standards have to deal with. They are dealt with as regards create and rename conflicts, and must also be dealt with as regards other write operation conflicts. The architecture draft explains this quite adequately in section 3.7. I propose that text be moved to the requirements draft as there may be some ongoing confusion within the WG about it and it would certainly be a new concept to other readers: *** In the case of a single-server or single-mastered Replication Context all LDAP Constraints are immediately enforced at the single updateable replica. An error result code is returned to an LDAP Client that presents an operation that would violate the constraints. In the case of a multi-mastered Replication Context not all LDAP Constraints can be immediately enforced at the updateable replica to which the LDAP Update Operation is applied. This loosely consistent replication architecture ensures that at each replica all constraints are imposed, but as updates are replicated constraint violations arise that cannot be reported to the appropriate client. Any constraint violations that occur are repaired by a set of update resolution procedures. Any LDAP client that has been implemented to expect immediate enforcement of all LDAP Constraints may not behave as expected against a multi-mastered Replication Context. *** That to me is a reasonable statement of what LDUP MUST do in order to be acceptable as a standards track protocol consistent with deploying multi-master servers in the same *global* environment as those using existing standards. So how about putting it in the requirements? That's a reasonable proposal and we (the authors) will discuss it. I'm not promising we'll put it in, but we WILL discuss it on our next call :-) I admit to still disgesting the rest of the mail and so If I have comments, I'll make them later. [snip] From owner-ietf-ldup@mail.imc.org Sun Feb 25 13:15:24 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA11728 for ; Sun, 25 Feb 2001 13:15:23 -0500 (EST) Received: by above.proper.com (8.9.3/8.9.3) id JAA23345 for ietf-ldup-bks; Sun, 25 Feb 2001 09:45:38 -0800 (PST) Received: from pretender.boolean.net (root@router.boolean.net [198.144.206.49]) by above.proper.com (8.9.3/8.9.3) with ESMTP id JAA23340 for ; Sun, 25 Feb 2001 09:45:37 -0800 (PST) Received: from gypsy.OpenLDAP.org (gypsy.boolean.net [10.192.1.2]) by pretender.boolean.net (8.11.1/8.11.1/Boolean/Hub) with ESMTP id f1PHj7D43681; Sun, 25 Feb 2001 17:45:07 GMT (envelope-from Kurt@OpenLDAP.org) Message-Id: <5.0.2.1.0.20010225074253.00a5bc90@router.boolean.net> X-Sender: guru@router.boolean.net X-Mailer: QUALCOMM Windows Eudora Version 5.0.2 Date: Sun, 25 Feb 2001 09:45:05 -0800 To: John Strassner From: "Kurt D. Zeilenga" Subject: Re: draft-ietf-ldup-replica-req-06.txt terminology message Cc: ietf-ldup@imc.org In-Reply-To: <4.3.2.7.2.20010224220305.00b28ea8@mira-sjcm-1.cisco.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: John asks: > Kurt, please delineate the terms that you feel are being redefined. >Area of replication - A whole or portion of a Directory Information >Tree (DIT) that makes up a distinct unit of data to be replicated. This >may also be known as "unit of replication". X.525: unit of replication:A specification of the information to be shadowed, including (optionally) subordinate knowledge information. These sound the similar, but could be interpreted differently. I rather just use the X.518 definition. I also note that X.525 defines: replicated area:A subtree of the DIT for purposes of shadowing Note that a replicated area (or area of replication) is NOT known also as a replicated area in X.525 terminology. >Naming Context - Suffix of a sub-tree of entries held in a single > server [X.500]. For replication, this is the vertex of a replica. A Naming Context is "A subtree of entries held in a single master DSA" [X.501]. First, note the naming context is not just the vertex, suffix, or the "context prefix" which I-D seems to imply, but a subtree of entries including (optionally) subordinate knowledge information. I note that the X.525 defines the term "replicatation base entry" to refer to the DN of the vertex of the unit of replication. Second, whole or partial naming contexts can be replicated. The vertex of the unit of replication is not necessarily the vertex of the containing Naming Context. I note the I-D drops the word "master" from the specification. This is problematic. Let's say there are two context prefixes "dc=example,dc=net" (mastered on A) and "dc=sub,dc=example,dc=net" (mastered on B). Then define both these contexts as "unit of replications" to be shadowed on C (for read only). C holds shadows of two areas comprising two naming contexts, not one per the I-D terminology. This is inconsistent with LDAP/X.500 naming contexts. If you use however say the Naming Context is "A subtree of entries held in a master server" (note no 'single' qualification), then you have a comparable problem in that if A and B both have agreements to replicate (for read/write) to D, it cannot be said that D holds both contexts. Additionally, like Steven, I find the term 'replica' not use consistently, in particular when used to define other terms. I find it hard to detail X.500 consistency issues with terms depended on the 'replica' term at this time. Once the 'replica' term definition and use is shorted out, I'll then revisit the dependent terms. I also don't see the difference between "Master replica" and "Updatable replica". Also, replica ring implies a particular topology, a ring of servers. I would prefer a term which did not imply a topology. From owner-ietf-ldup@mail.imc.org Sun Feb 25 13:47:35 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA12080 for ; Sun, 25 Feb 2001 13:47:34 -0500 (EST) Received: by above.proper.com (8.9.3/8.9.3) id KAA25765 for ietf-ldup-bks; Sun, 25 Feb 2001 10:25:27 -0800 (PST) Received: from sj-msg-core-1.cisco.com (sj-msg-core-1.cisco.com [171.71.163.11]) by above.proper.com (8.9.3/8.9.3) with ESMTP id KAA25761 for ; Sun, 25 Feb 2001 10:25:27 -0800 (PST) Received: from mira-sjcm-1.cisco.com (mira-sjcm-1.cisco.com [171.69.43.102]) by sj-msg-core-1.cisco.com (8.9.3/8.9.1) with ESMTP id KAA11029; Sun, 25 Feb 2001 10:25:14 -0800 (PST) Received: from JSTRASSN-W2K1.cisco.com (ams-vpdn-client-409.cisco.com [144.254.47.157]) by mira-sjcm-1.cisco.com (Mirapoint) with ESMTP id AAH06103; Sun, 25 Feb 2001 10:23:47 -0800 (PST) Message-Id: <4.3.2.7.2.20010224220025.00b528d0@mira-sjcm-1.cisco.com> X-Sender: jstrassn@mira-sjcm-1.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Sun, 25 Feb 2001 07:00:41 -0800 To: ietf-ldup@imc.org From: John Strassner Subject: Response to the "equally capable" Requirments message Cc: johns@cisco.com, capple@ecal.com, paf@cisco.com Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ietf-ldup@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: LDUPers, this is the third memo, responding to the "equally capable" Requirments message. Kurt raises points in this message. First, Kurt recommends that "...the requirement I-D needs to state that "application-level interoperability" will not be guaranteed by the protocol, but may be resolvable by applicability statements (profiles). In the end, "application interoperability" requires that all replicas implement the same features in the same manner and this, IMO, is beyond the scope of LDUP". Action: this seems very reasonable. Authors, please work with Kurt and incorporate an addition to this effect in the requirements I-D. Second, Kurt notes that the I-D's Security Considerations section says that specific issues are being addressed in RFC 2820 (and the work in progress) when this is clearly not the case. Action: Authors, please work with Kurt and fix this. Finally, Kurt notes that the LDUP specifications can be progressed without a Standard Track ACM. Action: none, this has already been decided. regards, John Strassner Co-Chair, LDUP WG From owner-ietf-ldup@mail.imc.org Sun Feb 25 13:49:51 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA12121 for ; Sun, 25 Feb 2001 13:49:50 -0500 (EST) Received: by above.proper.com (8.9.3/8.9.3) id KAA25688 for ietf-ldup-bks; Sun, 25 Feb 2001 10:24:21 -0800 (PST) Received: from sj-msg-core-1.cisco.com (sj-msg-core-1.cisco.com [171.71.163.11]) by above.proper.com (8.9.3/8.9.3) with ESMTP id KAA25683 for ; Sun, 25 Feb 2001 10:24:20 -0800 (PST) Received: from mira-sjcm-1.cisco.com (mira-sjcm-1.cisco.com [171.69.43.102]) by sj-msg-core-1.cisco.com (8.9.3/8.9.1) with ESMTP id KAA10871; Sun, 25 Feb 2001 10:24:08 -0800 (PST) Received: from JSTRASSN-W2K1.cisco.com (ams-vpdn-client-409.cisco.com [144.254.47.157]) by mira-sjcm-1.cisco.com (Mirapoint) with ESMTP id AAH06102; Sun, 25 Feb 2001 10:23:41 -0800 (PST) Message-Id: <4.3.2.7.2.20010224220300.00b93108@mira-sjcm-1.cisco.com> X-Sender: jstrassn@mira-sjcm-1.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Sun, 25 Feb 2001 10:21:37 -0800 To: ietf-ldup@imc.org From: John Strassner Subject: Consolidation of Comments on draft-ietf-ldup-replica-req-06.txt thread Cc: johns@cisco.com, capple@ecal.com, paf@cisco.com Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ietf-ldup@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: LDUPers, this is the fifth memo, summarizing the thread: Comments on draft-ietf-ldup-replica-req-06.txt. Note that there were a lot of subjects covered in this thread. Only those subjects that directly pertain to the requirements I-D will be discussed here. Other subjects having merit will be discussed later. This memo is written as a summarization by the WG Co-Chair of declaring consensus on discussed items and requesting changes to be made to the current (-06) version of the requirements I-D prior to it being reissued for WG Last Call. There was an exchange of messages between Steven and Richard, where a number of recommendations were made. These were either commented on, explaining why they weren't added, or added. These will not be repeated here; rather, only open issues requiring a comment will be covered. Issue 1: models and atomicity There was disagreement in how to describe this. Kurt thought that the extra functionality that was provided by Model 1 wasn't adequately expressed. But the authors didn't like his wording changes because they thought that model 2 would be able to support atomicity, at least in some limited cases like single-master. Action: I didn't see any other support from the WG, but this does seem reasonable. Therefore, could Kurt please get with the authors and agree to mutually acceptable wording? Issue 2: interoperability Kurt pointed out that interoperability may also be limited by servers that implement semantics that implement optional features which LDAP defines (such as subtypes). Action: this is a good point, please add this to the requirements I-D Issue 3: Kurt wanted to see knowledge information representation/semantics added to the non-exhaustive list. Authors state that they did NOT want the list to grow. Action: none regards, John Strassner Co-Chair, LDUP WG From owner-ietf-ldup@mail.imc.org Sun Feb 25 13:55:26 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA12210 for ; Sun, 25 Feb 2001 13:55:26 -0500 (EST) Received: by above.proper.com (8.9.3/8.9.3) id KAA25680 for ietf-ldup-bks; Sun, 25 Feb 2001 10:24:17 -0800 (PST) Received: from sj-msg-core-2.cisco.com (sj-msg-core-2.cisco.com [171.69.43.88]) by above.proper.com (8.9.3/8.9.3) with ESMTP id KAA25676 for ; Sun, 25 Feb 2001 10:24:16 -0800 (PST) Received: from mira-sjcm-1.cisco.com (mira-sjcm-1.cisco.com [171.69.43.102]) by sj-msg-core-2.cisco.com (8.9.3/8.9.1) with ESMTP id KAA11792; Sun, 25 Feb 2001 10:24:02 -0800 (PST) Received: from JSTRASSN-W2K1.cisco.com (ams-vpdn-client-409.cisco.com [144.254.47.157]) by mira-sjcm-1.cisco.com (Mirapoint) with ESMTP id AAH06101; Sun, 25 Feb 2001 10:23:37 -0800 (PST) Message-Id: <4.3.2.7.2.20010224220303.00b1b6b0@mira-sjcm-1.cisco.com> X-Sender: jstrassn@mira-sjcm-1.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Sun, 25 Feb 2001 08:05:33 -0800 To: ietf-ldup@imc.org From: John Strassner Subject: Consolidation of several counts thread Cc: johns@cisco.com, capple@ecal.com, paf@cisco.com Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ietf-ldup@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: LDUPers, this is the fourth memo, summarizing the thread: RE: Consolidation of several counts thread. Note that there were a lot of subjects covered in this thread. Only those subjects that directly pertain to the requirements I-D will be discussed here. Other subjects having merit will be discussed later. This memo is written as a summarization by the WG Co-Chair of declaring consensus on discussed items and requesting changes to be made to the current (-06) version of the requirements I-D prior to it being reissued for WG Last Call. Issue 1: if we start singling out particular types of information that can or can not be replicated, where do we stop? We've had two different attempts to characterize this issue. One was the (in)famous active vs. passive data, and the other was Kurt explicitly listing several types of attributes with MUST, SHOULD, and MAY support levels. This implies that some members of the WG are trying to define this in more detail. However, I would like to see more detail in what we are recommending. The active vs. passive definition fails due to the lack of familiarity with the precise meanings of the terms. Similarly, listing some but not all attributes to be replicated just raises questions about what to do with the attributes that aren't specified. Action: Kurt to work with the authors to either build a matrix of ALL attributes and whether they should be replicated or not, or the authors convince Kurt that he's wrong ;-) and this doesn't need to be satisfied. Result to be posted to the WG list. Issue 2: stop using the term passive data to describe what can be replicated I'm going to make the decision to stop this discussion. I don't see this discussion being resolved, and Jerry brought up the point that most implementations will have operational attributes modified for even the passive data. Proponents and opponents have still not reached a common ground, and there are many unanswered questions from each side. regards, John Strassner Co-Chair, LDUP WG From owner-ietf-ldup@mail.imc.org Sun Feb 25 17:19:59 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA13637 for ; Sun, 25 Feb 2001 17:19:58 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.9.3/8.9.3) id NAA07179 for ietf-ldup-bks; Sun, 25 Feb 2001 13:42:44 -0800 (PST) Received: from relay1.pair.com (relay1.pair.com [209.68.1.20]) by above.proper.com (8.9.3/8.9.3) with SMTP id NAA07174 for ; Sun, 25 Feb 2001 13:42:42 -0800 (PST) Received: (qmail 7291 invoked from network); 25 Feb 2001 21:42:12 -0000 Received: from cpe-144-132-70-18.vic.bigpond.net.au (HELO w98) (144.132.70.18) by relay1.pair.com with SMTP; 25 Feb 2001 21:42:12 -0000 X-pair-Authenticated: 144.132.70.18 Reply-To: From: "Albert Langer" To: Subject: Proposed requirements not met by current architecture and URP proposals - part 2 (end) Date: Mon, 26 Feb 2001 08:46:07 +1100 Message-ID: <004301c09f74$5cda3180$6628a8c0@nowhere.com> 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 CWS, Build 9.0.2416 (9.0.2910.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 In-Reply-To: <001601c09ab5$cb956ea0$6628a8c0@nowhere.com> Importance: Normal Sender: owner-ietf-ldup@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit Continuing from part 1, which defines the categories used: http://www.imc.org/ietf-ldup/mail-archive/msg00891.html * B) Fixable Show Stopper * 3) Eventual Convergence G1. LDAP Replication MUST support models 2 (Eventual Consistency) and 3 (Limited Effort Eventual Consistency) above. M3. A value shared between replicas in a replica ring must eventually converge to the same value on all of its constituent replicas. MM6. Multi-master replication MUST support convergence of the values of attributes and entries. Convergence may result in an event as described in MM5. Each of these requires "eventual convergence" (the wording and redundancy could be improved - as is true of other items, without further comment below). Achieving that necessarily requires three things. a) All servers that are to converge must have a common view of which servers are within the Replication Set of servers from which updates must be applied and which are excluded from it. Otherwise some servers would be applying updates that others are not, and therefore they cannot converge. b) All servers that are to converge must apply a common update processing algorithm to the updates they receive, that is guaranteed to produce the same results at all of them when no further changes are occurring, provided all of them receive the necessary updates. c) All servers must receive all the update information they need in order for the specified update processing algorithm to converge, regardless of which server generated the original change. The mechanisms specified in the architecture and URP for this look extremely brittle in a world where clocks are not necessarily even monotonic, network connectivity can fluctuate rapidly and servers crash and get restored from backups (not always the right backups). As the intention appears to be to meet the requirement and any actual problems are fixable using a properly layered report propagation protocol, detailed analysis is unecessary at this time. 4) Entry identification SC9. An entry MUST be uniquely identifiable throughout its lifetime. As a consequence of non-atomicity, URP can delete each of 2 components of an RDN due to rename operations at different replicas, leaving the entry without a name. This may in fact be fatal but there are so many bizarre kludge fixes in there I cannot rule out the possibility that one might be feasible for this. * C) Fixable Noncompliance * 5) Schema Replication M4. LDAP replication MUST encompass schema definitions, attribute names and values, access control information, and name space information. Fatal aspects have been referred to elsewhere. There is no provision for replicating schema definitions (which require synchronization etc). That may also be fatal but I have not studied the matter, so have listed it as fixable. 6) System and Network Performance G3. LDAP replication SHOULD have minimal impact on both the system and network performance. MM1. The replication protocol SHOULD NOT saturate the network with redundant or unnecessary entry replication. The main performance impact to be minimized is replication spikes due to full instead of incremental replication. The design maximizes the occasions on which that will be necessary. This may be partly due to MM7 and SM2 discussed in section E. Strict in order transmission of updates between neighbours in a better report propagation protocol to meet eventual convergence requirements robustly would also fix this problem. 7) Missing P1. The replication protocol MUST provide for recovery and rescheduling of a replication session due to replication initiation conflicts (e.g. consumer busy replicating with other servers) and or loss of connection (e.g. supplier cannot reach a replica). P3. The LDAP replication protocol MUST allow for full update to facilitate replica initialization and reset loading utilizing a standardized format such as LDIF [RFC2849] format. AM2. Each copy of a replica MUST maintain audit history information of which servers it has replicated with and which servers have replicated with it. AM5. A mechanism to fix differences between replicas without triggering new replica cycles SHOULD be provided. No mechanisms appear to have been specified. It is unclear what document they should be specified in, but they all involve some interaction with URP. This appears to be an oversight that would not require any special fix beyond just doing it somewhere. Other requirements that do not not appear to have been implemented anywhere may also be relevant to URP, but I haven't checked carefully enough to be sure. * D) Fatal Noncompliance * 8) Single Master Support M2. The replication model MUST support both master-slave and multi- master relationships. SM1. A Single Master system SHOULD provide a fast method of promoting a slave replica to become the master replica. SM2. The master replica in a Single Master system SHOULD send all changes to read-only replicas in the order in which the master applied them. The architecture and URP are designed to compel complete implementation of multi-master protocols rather than providing a migration path for existing implementations. No work whatever has been done on specifically Single Master aspects. 9) Schema Enforcement M10. While different directory implementations can support different/extended schema, schema mismatches between two replicating servers MUST be handled. One way of handling such mismatches might be to raise an error condition. P8. The protocol MUST support a mechanism to report schema mismatches between replicas discovered during a replication session. No means of detecting schema mismatches is provided by URP. It cannot even detect schema violations. (Some aspects may arguably be fixable). * E) Requirements Problem 10) Bizarre Requirement for Non-interoperability "(2) replication among directory servers with different application trigger semantics may compromise directory data integrity." Although not listed in the Requirements section, this clause in section 3 is clearly intended to constrain the protocol standards to *not* require interoperability from implementations with "active" data. URP does not meet this "requirement" as it specifies a perfectly sensible means by which such implementations can interoperate and requires them to implement it: U5.1 "A directory server implementation may also perform implicit updates in response to user update requests, e.g. to maintain the referential integrity of distinguished names. Appropriate CSNs and deletion records for these changes MUST also be generated. A detailed description of the replication processing for these other types of update is beyond the scope of this document." 11) Design constraint on orderinig MM7. Multi-master conflict resolution MUST NOT depend on the in-order arrival of changes at a replica to assure eventual convergence. SM2. The master replica in a Single Master system SHOULD send all changes to read-only replicas in the order in which the master applied them. (Appendix B.2 explains that requirement SM2 is intentionally not a MUST and does not apply to multi-master at all) URP does not meet SM2 for Single Master but does meet MM7, at the expense of conflicting requirements G3 and MM1. Appendix B.2 does justify SM2, although the justification points to MUST and the explanation does not justify not adopting the same for multi-master and simply dropping MM7. Decisions about ordering are a design issue, not requirements. Design constraints should not be included in requirements without a clear reference to corresponding actual requirements. 12) Design constraint on update tracking P2. The supplier MUST track updates sent to the consumer and not resend already acknowledged ones, even in the event of recovery from a failed replica cycle. This is another unecessary design constraint. It is not satisfied by URP and there does not appear to be anything unsound about the URP approach of having the consumer track updates received rather than the supplier tracking updates sent. 13) Transactional Consistency G2. LDAP Replication SHOULD NOT preclude support for model 1 (Transactional Consistency) in the future. P7. The protocol SHOULD NOT preclude support of Transactional Consistency (model 1). Model 1: Transactional Consistency -- Environments that exhibit all four of the ACID properties (Atomicity, Concurrency, Independence, Durability) [ACID]. No multi-master replication system can avoid precluding support for ACID transactions. That is inherent in the definition. Nor does the C stand for Concurrency. Nor does the I usually stand for Independence. http://www.scism.sbu.ac.uk/georgeub/sharenotes/Wk10_Transaction_Concurrency/ tsld003.htm ACID transactions are also impractical in a global distributed directory service even using single master - eg it is unscalable to maintain referential integrity between different servers. That is why they are excluded from the X.500 data model. The whole discussion of models is simply confusing and confused. It should be dropped as adding nothing to either requirements or understanding as demonstrated by the inaccurate definitions and references. Instead definitions of concepts that are not already defined or well understood should be provided - eg granularity of operations, granularity of replication, concurrency, consistency, isolation, durability, serialization, convergence. In particular there is ongoing confusion about the whole concept of "loose consistency" and the fundamental distinction between the data model permitting different servers to have different versions of data with only "eventual" convergence, and changes inconsistent with the constraints of the data model. A meaningful replacement for G2 could then be something like this: "The protocols SHOULD NOT hinder standardization of extending the granularity of LDAP operations beyond a single entry." URP would not meet such a more reasonable requirement since it does not respect the granularity of operations being even at the attribute level, let alone the entry level. Other similar requirements would also be appropriate, eg: "The protocols SHOULD NOT hinder standardization of signed operations" URP would not meet such a requirement because it does not replicate operations at all. In general a review of existing and proposed LDAP extensions should be undertaken as part of requirements analysis to determine what avoidable problems could result from multi-master deployment so that the architecture and design will take those into account and try to minimize their impact. This could best be done by publishing an explanation of the sort of issues likely to arise in an initial requirements document and actively soliciting feedback. 14) Limited Effort Consistency G1. LDAP Replication MUST support models 2 (Eventual Consistency) and 3 (Limited Effort Eventual Consistency) above. URP makes no attempt to support model 3 (any failure in its attempt to support model 2 does not constitute supporting model 3, which is aimed at entirely different design goals completely irrelevant to LDAP directory replication). Discussion of this requirement can be found at: http://www.imc.org/ietf-ldup/mail-archive/msg00738.html According to WG co-chair Chris: *** It would not be listed as a MUST at this stage of revising the requirements document if the authors (some of the top LDAP experts in the world) and many other members of the working group didn't know of a good reason for it being stated as that strong of a requirement. *** That does not constitute a good reason, for anything other than not bothering to argue with Chris. That may also be relevant to John's recent complaint about WG members not having raised issues about the draft earlier. While other statements have not been irrational and anti-rational, none have provided any plausible reason why this WG should undertake such work. Chris evidently does not know of one and I have seen nothing to indicate that anyone else does either. Incidentally the reference given for Xerox Clearinghouse in the description of model 3 is in fact a reference to Bayou - an entirely different system. (If anyone is seriously interested in pursuing model 3, I believe Ed was involved in Xerox Clearinghouse and could provide some background as to its relevance or irrelevance to the work here as well as a more accurate and online reference). Requirements should not amend the WG charter. From owner-ietf-ldup@mail.imc.org Sun Feb 25 19:13:59 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA14094 for ; Sun, 25 Feb 2001 19:13:59 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.9.3/8.9.3) id PAA12787 for ietf-ldup-bks; Sun, 25 Feb 2001 15:41:05 -0800 (PST) Received: from mail.coreon.net (IDENT:mirapoint@mail.coreon.net [216.74.131.6]) by above.proper.com (8.9.3/8.9.3) with ESMTP id PAA12783 for ; Sun, 25 Feb 2001 15:41:04 -0800 (PST) Received: from mail.coreon.net (mail.coreon.net [216.74.131.6]) by mail.coreon.net (Mirapoint) with SMTP id AAA90185; Sun, 25 Feb 2001 18:39:39 -0500 (EST) From: Message-Id: <200102252339.AAA90185@mail.coreon.net> Date: Sun, 25 Feb 2001 18:41:07 -0500 Subject: Re: Proposed requirements not met by current architecture and URP proposals - part 2 (end) To: Albert.Langer@directory-designs.org Cc: ietf-ldup@imc.org 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 What's going on here? I read some of this to be saying "the requirements are wrong" which was not supposed to be the scope of this discussion. Now maybe I'm just misreading, so clarification would help... Again ... and [snip] used to shorten list ---- Original message ---- >Date: Mon, 26 Feb 2001 08:46:07 +1100 > >Continuing from part 1, which defines the categories used: > >http://www.imc.org/ietf-ldup/mail-archive/msg00891.html > >* B) Fixable Show Stopper * > >3) Eventual Convergence > >G1. LDAP Replication MUST support models 2 (Eventual Consistency) and >3 (Limited Effort Eventual Consistency) above. > >M3. A value shared between replicas in a replica ring must eventually >converge to the same value on all of its constituent replicas. > >MM6. Multi-master replication MUST support convergence of the values >of attributes and entries. Convergence may result in an event as >described in MM5. > >Each of these requires "eventual convergence" (the wording and redundancy >could be improved - as is true of other items, without further comment >below). I disagree. The requirements are specific to the part of the discussion taking place. [snip] >6) System and Network Performance > >G3. LDAP replication SHOULD have minimal impact on both the system and >network performance. > >MM1. The replication protocol SHOULD NOT saturate the network with >redundant or unnecessary entry replication. [snip...] but I'm keeping the above to refer to later >7) Missing > >P1. The replication protocol MUST provide for recovery and >rescheduling of a replication session due to replication initiation >conflicts (e.g. consumer busy replicating with other servers) and or >loss of connection (e.g. supplier cannot reach a replica). > >P3. The LDAP replication protocol MUST allow for full update to >facilitate replica initialization and reset loading utilizing a >standardized format such as LDIF [RFC2849] format. > >AM2. Each copy of a replica MUST maintain audit history information of >which servers it has replicated with and which servers have replicated >with it. > >AM5. A mechanism to fix differences between replicas without triggering >new replica cycles SHOULD be provided. > >No mechanisms appear to have been specified. It is unclear what >document they should be specified in, but they all involve some interaction >with URP. The requirement document should not mandate implementation mechanisms. [snip]... >11) Design constraint on orderinig > >MM7. Multi-master conflict resolution MUST NOT depend on the in-order >arrival of changes at a replica to assure eventual convergence. > >SM2. The master replica in a Single Master system SHOULD send all >changes to read-only replicas in the order in which the master applied >them. > >(Appendix B.2 explains that requirement SM2 is intentionally not a >MUST and does not apply to multi-master at all) > >URP does not meet SM2 for Single Master but does meet MM7, at the expense >of conflicting requirements G3 and MM1. Appendix B.2 does justify SM2, >although the justification points to MUST and the explanation does >not justify not adopting the same for multi-master and >simply dropping MM7. > >Decisions about ordering are a design issue, not requirements. >Design constraints should not be included in requirements without >a clear reference to corresponding actual requirements. Uh, you answered this yourself, didn't you? Decisions about ordering are not a design issue in the single master case, but are a design issue in the multi-master case. Therefore, order can be required for single master but not for the multi-master case > >12) Design constraint on update tracking > >P2. The supplier MUST track updates sent to the consumer and not >resend already acknowledged ones, even in the event of recovery from a >failed replica cycle. > >This is another unecessary design constraint. It is not satisfied by >URP and there does not appear to be anything unsound about the URP approach >of >having the consumer track updates received rather than the supplier >tracking updates sent. No, this breaks G3 and MM1 above >13) Transactional Consistency > >G2. LDAP Replication SHOULD NOT preclude support for model 1 >(Transactional Consistency) in the future. > >P7. The protocol SHOULD NOT preclude support of Transactional >Consistency (model 1). > >Model 1: Transactional Consistency -- Environments that exhibit all >four of the ACID properties (Atomicity, Concurrency, Independence, >Durability) [ACID]. > >No multi-master replication system can avoid precluding support >for ACID transactions. That is inherent in the definition. Nor >does the C stand for Concurrency. Nor does the I usually stand >for Independence. > >http://www.scism.sbu.ac.uk/georgeub/sharenotes/Wk10_Transacti on_Concurrency/ >tsld003.htm > >ACID transactions are also impractical in a global distributed >directory service even using single master - eg it is unscalable >to maintain referential integrity between different servers. >That is why they are excluded from the X.500 data model. > >The whole discussion of models is simply confusing and confused. >It should be dropped as adding nothing to either requirements >or understanding as demonstrated by the inaccurate definitions >and references. I thought you were originally arguing for this model being supported. Are you now changing your mind and saying that this should be dropped? >Instead definitions of concepts that are not already defined or well >understood should be provided - eg granularity of operations, granularity of >replication, concurrency, consistency, isolation, durability, >serialization, convergence. In particular there is ongoing confusion about >the >whole concept of "loose consistency" and the fundamental distinction between >the data model permitting different servers to have different versions >of data with only "eventual" convergence, and changes inconsistent with >the constraints of the data model. > >A meaningful replacement for G2 could then be something like this: > >"The protocols SHOULD NOT hinder standardization of extending the >granularity >of LDAP operations beyond a single entry." That sentence is not acceptable to me because (a) I don't see what it has to do with replication and (b) I'm not sure what it really means. > >URP would not meet such a more reasonable requirement since it does >not respect the granularity of operations being even at the >attribute level, let alone the entry level. > >Other similar requirements would also be appropriate, eg: > >"The protocols SHOULD NOT hinder standardization of signed operations" Did I miss signed operations becoming standard (I might have)? I believe its optional even if it is standardized and so would be captured under the item of supporting LDAP options that needs to be added. If it isn't standardized, then it falls into the same bucket as the ACL discussions. >14) Limited Effort Consistency > >G1. LDAP Replication MUST support models 2 (Eventual Consistency) and >3 (Limited Effort Eventual Consistency) above. > >URP makes no attempt to support model 3 (any failure in its attempt to >support model 2 does not constitute supporting model 3, which is >aimed at entirely different design goals completely irrelevant >to LDAP directory replication). If folks want to use LDAP in a Model 3 situation then it should be replicatable by LDUP, right? [snip] From owner-ietf-ldup@mail.imc.org Sun Feb 25 22:04:31 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id WAA15629 for ; Sun, 25 Feb 2001 22:04:30 -0500 (EST) Received: by above.proper.com (8.9.3/8.9.3) id SAA17086 for ietf-ldup-bks; Sun, 25 Feb 2001 18:40:30 -0800 (PST) Received: from pretender.boolean.net (root@router.boolean.net [198.144.206.49]) by above.proper.com (8.9.3/8.9.3) with ESMTP id SAA17081 for ; Sun, 25 Feb 2001 18:40:28 -0800 (PST) Received: from gypsy.OpenLDAP.org (gypsy.boolean.net [10.192.1.2]) by pretender.boolean.net (8.11.1/8.11.1/Boolean/Hub) with ESMTP id f1Q2e2D44898; Mon, 26 Feb 2001 02:40:02 GMT (envelope-from Kurt@OpenLDAP.org) Message-Id: <5.0.2.1.0.20010225180748.00a61730@router.boolean.net> X-Sender: guru@router.boolean.net X-Mailer: QUALCOMM Windows Eudora Version 5.0.2 Date: Sun, 25 Feb 2001 18:40:00 -0800 To: John Strassner From: "Kurt D. Zeilenga" Subject: Re: Consolidation of several counts thread Cc: ietf-ldup@imc.org In-Reply-To: <4.3.2.7.2.20010224220303.00b1b6b0@mira-sjcm-1.cisco.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 08:05 AM 2/25/01 -0800, John Strassner wrote: >Issue 1: if we start singling out particular types of information that can or can not be replicated, where do we stop? > >We've had two different attempts to characterize this issue. One was the (in)famous active vs. passive data, and the other was Kurt explicitly listing several types of attributes with MUST, SHOULD, and MAY support levels. This implies that some members of the WG are trying to define this in more detail. However, I would like to see more detail in what we are recommending. The active vs. passive definition fails due to the lack of familiarity with the precise meanings of the terms. Similarly, listing some but not all attributes to be replicated just raises questions about what to do with the attributes that aren't specified. > >Action: Kurt to work with the authors to either build a matrix of ALL attributes and whether they should be replicated or not, or the authors convince Kurt that he's wrong ;-) and this doesn't need to be satisfied. Result to be posted to the WG list. Instead of a matrix, I suggest: LDUP MUST be capable to replicate all userApplication attribute types. LDUP MUST be capable to replicate all directoryOperation and distributedOperation attribute types defined in the LDAP "core" specification (RFC 2251-2255, 2829-2830). LDUP SHOULD provide general guidelines for replication of directoryOperation and distributedOperation attribute types defined as LDAP extensions. LDUP SHALL NOT support replication of dsaOperation attribute types as such attributes are DSA-specific. I note that certain operational attributes, such as subschemaSubentry, may require special attention. I note there are existing requirements in this area. In addition, LDUP MUST be capable of replicating attribute subtypes. LDUP MUST be capable of replicating attribute description options (including ";binary" and Language Tags). From owner-ietf-ldup@mail.imc.org Mon Feb 26 02:49:27 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id CAA02667 for ; Mon, 26 Feb 2001 02:49:26 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.9.3/8.9.3) id XAA21826 for ietf-ldup-bks; Sun, 25 Feb 2001 23:09:02 -0800 (PST) Received: from arnie.adacel.com.au (arnie.adacel.com.au [203.36.26.147]) by above.proper.com (8.9.3/8.9.3) with SMTP id XAA21820 for ; Sun, 25 Feb 2001 23:08:58 -0800 (PST) Received: (qmail 32667 invoked from network); 26 Feb 2001 07:13:29 -0000 Received: from unknown (HELO osmium) (203.8.85.176) by arnie.adacel.com.au with SMTP; 26 Feb 2001 07:13:29 -0000 Reply-To: From: "Steven Legg" To: Cc: Subject: RE: Proposed requirements not met by current architecture and URP proposals - part A - Fatal Show Stoppers Date: Mon, 26 Feb 2001 18:10:15 +1100 Message-ID: <001601c09fc3$2be87e70$b05508cb@osmium.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: <000b01c09dd6$a4a96160$6628a8c0@nowhere.com> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V4.72.2120.0 Sender: owner-ietf-ldup@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit Albert, Albert Langer wrote: > (BTW one > that should be > easily fixed for any future draft is removal of all > references to X.500 DAP > and DSP as > IETF has no authority over such work and URP was dropped as a > work item by > those who do, > perhaps due to the "Fatal" problems. Multimaster replication was dropped as a work item in the X.500 working group because no one was attending the meetings to progress it. It wasn't a decision based on technical merit. I note however, that LDUP is within the scope of the X.500 group's new work item on LDAP/X.500 alignment. With regard to the references to DAP and DSP in the URP draft, I consider this to be entirely proper. It seems the majority of LDAP server implementations are also X.500 implementations, so when talking about multimaster replication between LDAP directories it is appropriate to consider how X.500 access protocols interact with LDUP. It also provides a model and examples for how other non-LDAP access protocols can be accommodated by LDUP. We're not telling X.500 how to do multimaster replication, we're telling LDAP servers that also implement X.500 access protocols how to do LDAP replication. > * A) Fatal Show Stoppers * > > 1) Atomicity and information loss > Requirements: > > P6. The protocol MUST support propagation of atomicity information. > > MM5. Multi-master replication MUST NOT lose information during > replication. If conflict resolution would result in the loss of > directory information, the replication process MUST store that > information, notify the administrator of the nature of the > conflict and > the information that was lost, and provide a mechanism for possible > override by the administrator. > > The apparant intention is not to require that replication > produce the same results as atomic operations, but to ensure that > the information necessary for administrators to manually fix any > problems that may result from not doing so is propagated, stored > and notified. > > If an attribute value that would not have been deleted by an atomic > operation is in fact deleted as a result of multi-master replication > procedures, that clearly constitutes "loss of directory information", > and information about that loss must be propagated, stored > and notified > to administrators so that they can fix any resulting > problems. Likewise > if information about which user is responsible for modifying an entry > is lost. > > To understand that there are indeed problems, which an administrator > would need to fix, consider the following example, a slightly modified > version of the example given in B.5.3 of the requirements > draft and now > in 4.3.3.1 of the new profile draft: > draft-ietf-ldup-usage-profile-00.txt. > > Here is the original example: > > *** > There is an entry with distinguished name DN that contains attributes > X, Y, and Z. The value of X is 1. On replica A, a ModifyRequest is > processed which includes modifications to change that value > of X from 1 > to 0 and to set the value of Y to "USER1". At the same time, > replica B > process[es] a ModifyRequest which includes modifications to change the > value of X from 1 to 0 and to set the value of Y to "USER2" and the > value of Z to 42. The application in this case is using X as a lock > and is depending on the atomic nature of ModifyRequests to provide > mutual exclusion for lock access. > > In the single-server case, the two operations would have occurred > sequentially. Since a ModifyRequest is atomic, the entire first > operation would succeed. The second ModifyRequest would fail, since > the value of X would be 0 when it was attempted, and the modification > changing X from 1 to 0 would thus fail. The atomicity rule > would cause > all other modifications in the ModifyRequest to fail as well. > > In the multi-master case, it is inevitable that at least some of the > changes will be reversed despite the use of the lock. Assuming the > changes from A have priority per the conflict resolution > algorithm, the > value of X should be 0 and the value of Y should be "USER1" The > interesting question is the value of Z at the end of the replication > cycle. If it is 42, the atomicity constraint on the change from B has > been violated. But for it to revert to its previous value, grouping > information must be retained and it is not clear when that information > can be safely discarded. Thus, requirement G6 may be violated. > *** > > Here is the modified version: > > There is an entry with distinguished name DN that contains an > attribute > L, with 3 values X, Y, and Z that was last modified by User C. > > User A issues a ModifyRequest which includes modifications > to change that attribute from X, Y, Z to Y, Z without regard to any > other values (leaving them "as is"). > > Using LDIF notation (RFC 2849): > > dn: DN > changetype: modify > delete: L > L: X > L: Y > L: Z > - > add: L > L: Y > L: Z > - > replace: modifiersName > modifiersName: A > > At around the same time, user B issues a ModifyRequest which includes > modifications to change the attribute L from X, Y, Z to X, Y again > leaving any other values "as is". > > dn: DN > changetype: modify > delete: L > L: X > L: Y > L: Z > - > add: L > L: X > L: Y > - > replace: modifiersName > modifiersName: B > > Both operations are relying on the published standards to ensure that > "what you read is what you changed". If some other user had removed > any of X, Y or Z between the read and write in either case, those > published standards guarantee that the entry will not be > changed to delete > X or to delete Z respectively. Presumably the changes are designed to > ensure that Y is associated with either X or Z and does not > stand alone > regardless of any race condition. > > If user A's change is processed first, the result will be Y, Z and > the change by user B will fail because of the absence of X, which > user B had assumed was present when making the change. > > If user B's change is processed first, the result will be X, Y and the > change by user A will fail because of the absence of Z, which user A > had assumed was present when making the change. > > Either way, one of the users will achieve exactly what they intended, > the name of that user will be listed as modifiersName and the other > user will be safeguarded from achieving a result not intended. > > With the pre-LDUP use of changelog single master replication, and with > the initial installation of LDUP compliant servers in single master > mode, for a trial run, everything works as before. But one day a > sysadmin turns on multi-master and strange things start to happen. > > If user A and user B happen to make the changes on the same server, > everything works as before. But sometimes they make the changes on > different servers (and are unlikely to know this since LDAP is > designed to hide which server is being accessed from applications). > So sometimes the result is quite different. According to URP a > "primitive" to delete X will be replicated with a CSN larger than > any existing CSN for X at any replica (and no primitive to add > X will be replicated since the only change in state from either > of the modify operations did not cause X to be added). Likewise > for Z. Wrong! - on several counts. According to URP the change from user A will generate a p-remove-attribute-value for each of X, Y and Z, and a p-add-attribute-value for both Y and Z. Additionally, a p-remove-attribute will be generated for the modifiersName attribute, and a p-add-attribute-value for the modifiersName value "A". All primitives generated from this operation are given a CSN with the same time, change count and replica identifier, such that it is greater than any existing CSN on X, Y, Z and modifiersName, among other constraints described in URP. The CSN isn't necessarily larger than any existing CSN for X at any replica. The change from user B will generate a p-remove-attribute-value for each of X, Y and Z, and a p-add-attribute-value for both X and Y. Additionally, a p-remove-attribute will be generated for the modifiersName attribute, and a p-add-attribute-value for the modifiersName value "B". All primitives generated from this operation are given a CSN in the manner described for the update by user A. > So both will eventually be deleted at all replicas (with > all sorts of possible transient conditions). > > Regardless of which change is processed first, the final result will > be Y and both X and Z will have been deleted. However you look at it, > directory information has been lost that would not have been lost > if LDUP was not used, or if exactly the same operations had been > performed at exactly the same times on a single multi-master server. > > Responsibility will be arbitrarily assigned to either A or B as > modifiersName although neither made the change that actually > occurred. The eventual result will depend on which operation was given the higher CSN. If user A's operation has the higher CSN, Y and Z will be present, X will be absent, and the modifiersName will be given as "A". If user B's operation has the higher CSN, X and Y will be present, Z will be absent, and the modifiersName will be given as "B". It will look like either A or B's operation has been performed but not a mixture of both. > The URP introduction elaborates as follows: > > U3 "Each DAP, LDAP or DSP operation successfully performed by > a directory > server is subsequently reported to other directory servers > with which > it has a replication agreement as a set of one or more simple > timestamped replication primitives. These primitives reflect the > intended *final* state of an update operation rather than > the *specific* > changes required to achieve that state. [emphasis added] > > The whole point of this is to split the original atomic operation into > "primitives" so that no part of it can affect the outcome of any other > part - ie so that it will cease to be atomic. Given that the consensus of the working group is to merge changes in conflict rather than later rejecting one of them and posting a recind notification, what would you propose we do instead to merge changes ? > The core design of URP drops all atomicity information and therefore > cannot propagate it or notify any administrator about resulting loss > of directory information. You keep making this allusion to URP being the replication protocol. It's not a protocol, so it doesn't propagate anything. It's a collection of procedures for breaking down updates into simple primitives and for applying said primitives delivered by the replication protocol. If the replication protocol wants to deliver other information, to other replication sub-systems, for other purposes, that need not be a concern for URP. > The entire elaborate exercise of carefully numbering the sequence of > modifications and applying them in order is *completely* pointless, > achieving > absolutely nothing apart from self-deception. > > The whole point of applying the modifications in sequence as > specified by > the LDAP standards is so that by deleting a value and then > adding it, in > the same operation, one can guarantee that the operation will > fail if that > value had been removed by some other DUA since the entry was > read by the DUA > that intends to change some related value with another part > of the same > modify operation. No, the fact that attemping to delete a non-existent value or add an existing value will produce an error result is what guarantees that the operation will fail if that value had been removed by some other DUA since the entry was read by the DUA. The point of having more than one modification is to combine multiple actions into an atomic operation. The point of having an ordered sequence of modifications is to have a deterministic result. We carefully number the sequence of modifications in LDUP so that we get a deterministic result and eventual convergence. > If the components of the modify were applied in the > opposite sequence the operation would fail, even if the value > was still > present because an attempt would be made to add a value that was > already present. That and the converse is the only function it serves. > 2) Access Control > Consider the example above with attribute L being ldapACI as > specified in draft-ietf-ldapext-acl-model-06.txt and X, Y, Z > as follows: > > dn: ou=policy, o=agalaxyfaraway > ldapACI: subtree#deny:w#[all]#group:cn=marketing > > ldapACI: subtree#grant:w#[all]#group:cn=involved > > ldapACI: subtree#deny:w#[all]#role:cn=madhatter > > Originally the entry was setup to allow anyone involved to write > policy, except for the madhatter. > > Then a marketing group was setup for convenience in adding > others who should > not have that permission, but the madhatter was not removed. > > Eventually all except the madhatter were removed from the > excluded group. > > Then user A notices that the two entries X and Z are redundant > since the madhatter is now the only member of the marketing group. > > A decides to cleanup by deleting X, the redundant deny entry for the > marketing group. A does this safely to ensure no possible > race condition. > > Meanwhile user B also notices and decides to cleanup, but > makes the opposite decision, deleting Z, the redundant deny > entry for the madhatter who is a member of the marketing group anyway. > B also does it safely. > > Result, intended by neither, is that the madhatter is allowed > to write policy. If URP is applied correctly, the result is either X or Z is removed, but not both. Exactly what you want. Regards, Steven From owner-ietf-ldup@mail.imc.org Mon Feb 26 04:39:15 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id EAA03181 for ; Mon, 26 Feb 2001 04:39:14 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.9.3/8.9.3) id AAA25148 for ietf-ldup-bks; Mon, 26 Feb 2001 00:59:09 -0800 (PST) Received: from relay1.pair.com (relay1.pair.com [209.68.1.20]) by above.proper.com (8.9.3/8.9.3) with SMTP id AAA25143 for ; Mon, 26 Feb 2001 00:59:08 -0800 (PST) Received: (qmail 17964 invoked from network); 26 Feb 2001 08:58:36 -0000 Received: from cpe-144-132-70-18.vic.bigpond.net.au (HELO w98) (144.132.70.18) by relay1.pair.com with SMTP; 26 Feb 2001 08:58:36 -0000 X-pair-Authenticated: 144.132.70.18 Reply-To: From: "Albert Langer" To: Cc: Subject: RE: Proposed requirements not met by current architecture and URP proposals - part A - Fatal Show Stoppers Date: Mon, 26 Feb 2001 20:01:35 +1100 Message-ID: <000001c09fd2$b9819640$6628a8c0@nowhere.com> 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 CWS, Build 9.0.2416 (9.0.2910.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 In-Reply-To: <001601c09fc3$2be87e70$b05508cb@osmium.adacel.com.au> Importance: Normal Sender: owner-ietf-ldup@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit [Steve] [...] The eventual result will depend on which operation was given the higher CSN. If user A's operation has the higher CSN, Y and Z will be present, X will be absent, and the modifiersName will be given as "A". If user B's operation has the higher CSN, X and Y will be present, Z will be absent, and the modifiersName will be given as "B". It will look like either A or B's operation has been performed but not a mixture of both. [Albert] If that is the case it *completely* refutes my example. I will study your detailed explanation carefully (and defer responding to other matters such as X.500 DAP and DSP until I have done so). Either way, your comment clearly establishes that URP is intended to meet the stated requirement and therefore that requirement can be used in evaluating whether it actually does so, without confusion or misunderstanding. At this stage it appears to me that either I have been under a fundamental misconception about URP all along, or have just chosen a bad example. I might be under a similar misconception about the consequences of the transient inconsistent states described in Alison's consistency discussion and will be reviewing that too. Anything you would like to draw to my attention to about my earlier comments concerning that, either here or via direct email will be welcome. Likewise I might be under a misconception that URP does not respect atomicity when more than one attribute is being changed. Any comments on that would also be welcome. [Steve] Given that the consensus of the working group is to merge changes in conflict rather than later rejecting one of them and posting a recind notification, what would you propose we do instead to merge changes ? [Albert] My preference would be to not merge changes because I do not believe most applications actually do take sufficient precautions to ensure "what you changed is what you saw" as that rarely causes real problems in a single master environment, so they would be taken by surprise when it no longer works with multi-master (despite adequate warnings in standards and documentation). Whereas the failure of such merged changes would not be significantly different from behaviour they are alredy designed to deal with - that some other change can subsequently obliterate theirs, especially if that results in a notification. However I certainly agree that is an issue on which the WG is perfectly entitled to adopt an opposite view and does not involve any kind of "fundamental technical mistake" that would require review elsewhere. If URP is in fact capable of conforming to the LDAP modify operations atomic semantics, I will withdraw my objection. > The core design of URP drops all atomicity information and therefore > cannot propagate it or notify any administrator about resulting loss > of directory information. [Steve] You keep making this allusion to URP being the replication protocol. It's not a protocol, so it doesn't propagate anything. It's a collection of procedures for breaking down updates into simple primitives and for applying said primitives delivered by the replication protocol. If the replication protocol wants to deliver other information, to other replication sub-systems, for other purposes, that need not be a concern for URP. [Albert] If URP does not drop the atomicity information and thereby prevent it from being propagated to other servers I am not concerned about terminology. My point was entirely based on a belief that it does drop the information, which I will now review. [...] [Steve] No, the fact that attemping to delete a non-existent value or add an existing value will produce an error result is what guarantees that the operation will fail if that value had been removed by some other DUA since the entry was read by the DUA. The point of having more than one modification is to combine multiple actions into an atomic operation. The point of having an ordered sequence of modifications is to have a deterministic result. We carefully number the sequence of modifications in LDUP so that we get a deterministic result and eventual convergence. [...] [Albert] If the result is both deterministic (which I have always accepted) and also consistent with ldap modification semantics as you are saying, then you have proved your case and I will withdraw mine. [Steve] If URP is applied correctly, the result is either X or Z is removed, but not both. Exactly what you want. [Albert] Agreed - if that is what it does, also in other related cases, it is exactly what I want. (Which leaves me somewhat perplexed by the repeated statements that what I want is "unreasonable", inappropriate for multi-master etc etc. But I guess at this point you must be equally perplexed as to what I have been objecting about ;-) Will get back to you shortly. From owner-ietf-ldup@mail.imc.org Mon Feb 26 10:20:21 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA12167 for ; Mon, 26 Feb 2001 10:20:18 -0500 (EST) Received: by above.proper.com (8.9.3/8.9.3) id GAA22832 for ietf-ldup-bks; Mon, 26 Feb 2001 06:44:22 -0800 (PST) Received: from mail.coreon.net (IDENT:mirapoint@mail.coreon.net [216.74.131.6]) by above.proper.com (8.9.3/8.9.3) with ESMTP id GAA22828 for ; Mon, 26 Feb 2001 06:44:20 -0800 (PST) Received: from rmoats2 (wenjus3.coreon.net [216.74.131.3]) by mail.coreon.net (Mirapoint) with ESMTP id AAA90662 (AUTH rmoats); Mon, 26 Feb 2001 09:43:55 -0500 (EST) From: "Ryan Moats" To: "Kurt D. Zeilenga" , "John Strassner" Cc: Subject: RE: Consolidation of several counts thread Date: Mon, 26 Feb 2001 08:49:15 -0600 Message-ID: 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 IMO, Build 9.0.2416 (9.0.2911.0) In-Reply-To: <5.0.2.1.0.20010225180748.00a61730@router.boolean.net> Importance: Normal 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: Content-Transfer-Encoding: 7bit I'm certainly in favor of somthing shorter than a matrix. I still have to parse what Kurt is saying below to make sure I agree with it, but I like that approach better than a matrix. Ryan -----Original Message----- From: owner-ietf-ldup@mail.imc.org [mailto:owner-ietf-ldup@mail.imc.org]On Behalf Of Kurt D. Zeilenga Sent: Sunday, February 25, 2001 8:40 PM To: John Strassner Cc: ietf-ldup@imc.org Subject: Re: Consolidation of several counts thread At 08:05 AM 2/25/01 -0800, John Strassner wrote: >Issue 1: if we start singling out particular types of information that can or can not be replicated, where do we stop? > >We've had two different attempts to characterize this issue. One was the (in)famous active vs. passive data, and the other was Kurt explicitly listing several types of attributes with MUST, SHOULD, and MAY support levels. This implies that some members of the WG are trying to define this in more detail. However, I would like to see more detail in what we are recommending. The active vs. passive definition fails due to the lack of familiarity with the precise meanings of the terms. Similarly, listing some but not all attributes to be replicated just raises questions about what to do with the attributes that aren't specified. > >Action: Kurt to work with the authors to either build a matrix of ALL attributes and whether they should be replicated or not, or the authors convince Kurt that he's wrong ;-) and this doesn't need to be satisfied. Result to be posted to the WG list. Instead of a matrix, I suggest: LDUP MUST be capable to replicate all userApplication attribute types. LDUP MUST be capable to replicate all directoryOperation and distributedOperation attribute types defined in the LDAP "core" specification (RFC 2251-2255, 2829-2830). LDUP SHOULD provide general guidelines for replication of directoryOperation and distributedOperation attribute types defined as LDAP extensions. LDUP SHALL NOT support replication of dsaOperation attribute types as such attributes are DSA-specific. I note that certain operational attributes, such as subschemaSubentry, may require special attention. I note there are existing requirements in this area. In addition, LDUP MUST be capable of replicating attribute subtypes. LDUP MUST be capable of replicating attribute description options (including ";binary" and Language Tags). From owner-ietf-ldup@mail.imc.org Mon Feb 26 16:00:56 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA27282 for ; Mon, 26 Feb 2001 16:00:55 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.9.3/8.9.3) id MAA05477 for ietf-ldup-bks; Mon, 26 Feb 2001 12:21:47 -0800 (PST) Received: from relay1.pair.com (relay1.pair.com [209.68.1.20]) by above.proper.com (8.9.3/8.9.3) with SMTP id MAA05473 for ; Mon, 26 Feb 2001 12:21:43 -0800 (PST) Received: (qmail 25425 invoked from network); 26 Feb 2001 20:21:09 -0000 Received: from cpe-144-132-70-18.vic.bigpond.net.au (HELO w98) (144.132.70.18) by relay1.pair.com with SMTP; 26 Feb 2001 20:21:09 -0000 X-pair-Authenticated: 144.132.70.18 Reply-To: From: "Albert Langer" To: Cc: Subject: RE: Proposed requirements not met by current architecture and URP proposals - part A - Fatal Show Stoppers Date: Tue, 27 Feb 2001 01:51:59 +1100 Message-ID: <000301c0a032$147206c0$6628a8c0@nowhere.com> 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 CWS, Build 9.0.2416 (9.0.2910.0) Importance: Normal In-Reply-To: <001601c09fc3$2be87e70$b05508cb@osmium.adacel.com.au> X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Sender: owner-ietf-ldup@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit [Albert] Ok, here's my attempt to work through your explanation. Please point out precisely where I have misunderstood. > There is an entry with distinguished name DN that contains an > attribute > L, with 3 values X, Y, and Z that was last modified by User C. > > User A issues a ModifyRequest which includes modifications > to change that attribute from X, Y, Z to Y, Z without regard to any > other values (leaving them "as is"). > > Using LDIF notation (RFC 2849): > > dn: DN > changetype: modify > delete: L > L: X > L: Y > L: Z > - > add: L > L: Y > L: Z > - > replace: modifiersName > modifiersName: A > > At around the same time, user B issues a ModifyRequest which includes > modifications to change the attribute L from X, Y, Z to X, Y again > leaving any other values "as is". > > dn: DN > changetype: modify > delete: L > L: X > L: Y > L: Z > - > add: L > L: X > L: Y > - > replace: modifiersName > modifiersName: B [...] > So sometimes the result is quite different. According to URP a > "primitive" to delete X will be replicated with a CSN larger than > any existing CSN for X at any replica (and no primitive to add > X will be replicated since the only change in state from either > of the modify operations did not cause X to be added). Likewise > for Z. [Steve] Wrong! - on several counts. According to URP the change from user A will generate a p-remove-attribute-value for each of X, Y and Z, and a p-add-attribute-value for both Y and Z. [...] [Albert] I'm stopping right there. I don't understand this. Here's the text from draft-ietf-ldup-urp-03.txt. 4.3 Replication Primitives Each update operation performed on an entry in a part of the DIT subject to one or more replication agreements MUST be subsequently reported as replication primitives to the replication partner directory servers of those agreements. The collection of primitives sent by a directory server to a replication partner will reflect both the results of locally processed user update requests and also of replicated updates received from other directory servers. A single update operation will decompose into one or more primitives. Common to all update primitives is an entry identifier argument, uid, containing the Unique Identifier of the target entry of the change, and a CSN argument, csn, to indicate the time of the change. In the case of adding a new entry, the Unique Identifier for the entry is allocated by the directory server in the course of processing the operation. Additional arguments are present depending on the type of replication primitive. [...] The p-add-attribute-value(uid, csn, type, value) primitive is used to describe the addition of a single attribute value to an entry. The type argument contains the attribute type of the value and the value argument contains the attribute value. The p-remove-attribute-value(uid, csn, type, value) primitive is used to describe the removal of a single attribute value from an entry. The type argument contains the attribute type of the value and the value argument contains the attribute value. [...] These primitives reflect the intended final state of an update operation rather than the specific changes required to achieve that state. I cannot see any possibility of an implementor not reading the final sentence as a *completely* unambiguous statement that the implementation must *not* do what you say: "the change from user A will generate a p-remove-attribute-value for each of X, Y and Z, and a p-add-attribute-value for both Y and Z." Doing that would be reflecting the "specific changes required to achieve that state" - which is precisely what you have told them *not* to do. Even without the final sentence, one could hardly read the previous two quoted sentences as though they said: The p-add-attribute-value(uid, csn, type, value) primitive is used to describe the addition of a single attribute value to an entry, even if the attribute value was already present.[...] The p-remove-attribute-value(uid, csn, type, value) primitive is used to describe the removal of a single attribute value from an entry, even if the attribute value was not removed.[...] In order to implement your specification the implementor would "reflect the intended final state" by generating a single p-remove-attribute-value for X. The intended final state of the modification was to remove X while leaving all other values of the attribute unchanged. The operation either failed - in which case no changes were made and no primitives were generated, or it succeeded - in which case it succeeded in removing X and the single primitive reflecting that would be generated. There is no ambiguity whatsoever. So I am not continuing with my review of what I might have misunderstood past this point, while awaiting your explanation. It seems to me that: a) You have accepted the current requirements P6 and MM5 and the definitions of "Atomic Operation" (with reference to what "the LDAP standards guarantee") and "Atomicity Information", by not objecting in a "last call" where "silence means consent". b) You have demonstrated a clear understanding of what is required by the "LDAP standards guarantee of atomicity" by saying that URP is intended and designed to resolve conflicts between modify operations with the result that: "It will look like either A or B's operation has been performed but not a mixture of both." If you will confirm my understanding above, I will be quite happy to join in a WG consensus on the requirements draft, as my concern that it won't actually resolve anything is eliminated. If it turns out that the non-atomicity in URP is fixable, that's fine by me. All I want is for the behaviour expected by LDAP applications as a result of what the LDAP standards guarantee, to be provided. Contrary to John's persistent sniping, the only reason I wrote MDCR was to show that an alternative was possible, and I would be just as happy for my objections to not providing what the LDAP standards guarantee to be resolved by URP as by MDCR. From owner-ietf-ldup@mail.imc.org Mon Feb 26 16:42:25 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA28946 for ; Mon, 26 Feb 2001 16:42:23 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.9.3/8.9.3) id MAA06363 for ietf-ldup-bks; Mon, 26 Feb 2001 12:50:42 -0800 (PST) Received: from mail.coreon.net (IDENT:mirapoint@mail.coreon.net [216.74.131.6]) by above.proper.com (8.9.3/8.9.3) with ESMTP id MAA06359 for ; Mon, 26 Feb 2001 12:50:39 -0800 (PST) Received: from rmoats2 (wenjus3.coreon.net [216.74.131.3]) by mail.coreon.net (Mirapoint) with ESMTP id AAA92094 (AUTH rmoats); Mon, 26 Feb 2001 15:49:14 -0500 (EST) From: "Ryan Moats" To: Cc: Subject: RE: Proposed requirements not met by current architecture and URP proposals - part 2 (end) Date: Mon, 26 Feb 2001 14:54:42 -0600 Message-ID: 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 IMO, Build 9.0.2416 (9.0.2911.0) In-Reply-To: <000401c0a032$181c7120$6628a8c0@nowhere.com> Importance: Normal 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: Content-Transfer-Encoding: 7bit Ah... more snipping and ... this time... BTW, these are my views and my coauthors are free to disagree with me :-) -----Original Message----- From: Albert Langer [mailto:Albert.Langer@Directory-Designs.org] Subject: RE: Proposed requirements not met by current architecture and URP proposals - part 2 (end) [snip]... [Albert] Looking forward to your views on this and other issues (whether in this "last call" on requirements context or in relation to URP etc). I'm assuming the editors will be going through all issues raised by anyone whether you (or John) have expressed an opinion about them now or not. I think that's a fair assumption :-) >11) Design constraint on orderinig > >MM7. Multi-master conflict resolution MUST NOT depend on the in-order >arrival of changes at a replica to assure eventual convergence. > >SM2. The master replica in a Single Master system SHOULD send all >changes to read-only replicas in the order in which the master applied >them. > >(Appendix B.2 explains that requirement SM2 is intentionally not a >MUST and does not apply to multi-master at all) > >URP does not meet SM2 for Single Master but does meet MM7, at the expense >of conflicting requirements G3 and MM1. Appendix B.2 does justify SM2, >although the justification points to MUST and the explanation does >not justify not adopting the same for multi-master and >simply dropping MM7. > >Decisions about ordering are a design issue, not requirements. >Design constraints should not be included in requirements without >a clear reference to corresponding actual requirements. Uh, you answered this yourself, didn't you? Decisions about ordering are not a design issue in the single master case, but are a design issue in the multi-master case. Therefore, order can be required for single master but not for the multi-master case [Albert] The way I see it any sensible design for Single Master would maintain strict ordering - both to meet the necessity for some sort of conformance level and migration and coexistance strategy for existing single master implementations implied by the WG charter (which I believe should also be spelled out as a requirement), and also to simplify implementation and meet requirements G2 and MM1 for performance. However the functional requirements are covered by G2, MM1 and the implicit or missing requirement to support Single Master meaningfully. The conclusion that maintaining strict ordering is the best design for meeting such requirements can be drawn in the architecture and does not need to be spelled out as a requirement. I try to be very consistent about this distinction between design choices and requirements. Perhaps I am overly sensitive to it in reaction to John's persistent campaign to present my objections to URP not meeting the requirements as just a cover for my having been so presumptious as to show that an alternative design was possible by submitting MDCR when I initially drew attention to the basic flaws in URP and insisted that the lack of requirements that made it obvious such a design would be unacceptable necessitated review of the allegedly "ready" requirements draft. My items 6 and 8 raise the relevant requirements that URP does not comply with. The design choices that resulted in that are a design problem, not a requirements problem. At any rate I certainly agree with the design choice reflected in SM2, so the comment is essentially editorial and I will not pursue it. Concerning MM7, you seem to be suggesting that it merely does not impose a requirement for strict ordering on the design for multi-master. That could be achieved by simply omitting it and perhaps moving the explanation words elsewhere into a more explicit statement within SM2 that it does not apply to multi-master. Maybe it could be omitted, but SM2 is single master and doesn't apply to multi master, and I (for one) would rather say something then have a void on ordering. The dependence on ordering is very close to making a choice between two general classes of implementation: state-based versus change log and that's something that the WG will not be successful mandating and has explicitly kept open in the past. In fact MM7 explicitly requires that the design for multi-master require consumers to accept out of order changes during a replication session, instead of requiring suppliers to keep them in order. That is very clearly a design choice as to *how* to satisfy requirements for (robust) eventual convergence. I disagree. If you go back through the archives, you will see a lot of discussion of state-based versus change log implementations. Requirement MM7 says that either approach may be used, because the state-based system may never be able to send changes in the correct order. I believe it is a bad design choice which unnecessarily complicates implementation and directly frustrates achieving the performance requirements in G2 and MM1, without adding anything to the robustness of convergence. That may be true, but that should be determined by the marketplace An immediate consequence is that replication sessions have to be restarted from the beginning when the link fails whereas they can continue from where they left of when strict ordering is used (as correctly noted in the architecture). As multi-master is especially useful in situations with weak network connectivity that could be quite a significant impact on performance. It is also much easier for each supplier to maintain a single ordered index of what it is sending to various consumers than for each consumer to have to deal with updates out of order. Any simplification of the supplier (which I doubt exists anyway) is completely negated by the fact that every supplier is also a consumer in multi-master and that such indexing has to be done for slave read only single master servers at the periphery anyway. Again, you are now into implementation and others may not agree with you, so the requirements have to leave other possibilities open I find the "negative consequences" listed in B.2 for out of order replication convincing and the "beneficial" situations unconvincing. The examples given in the "beneficial" section concerning schema and other critical policy information being replicated out of order are the most dangerous things to replicate out of order as immediately pointed out in the "negative consequences". The only remaining example is for pushing a priority update ahead of a bulk reload which refers to Single Master where you then prohibit it. I do not claim to be wiser than every directory administrator in every scenario, so B.2 is worded with that (at least in my mind) [snip...] >12) Design constraint on update tracking > >P2. The supplier MUST track updates sent to the consumer and not >resend already acknowledged ones, even in the event of recovery from a >failed replica cycle. > >This is another unecessary design constraint. It is not satisfied by >URP and there does not appear to be anything unsound about the URP approach >of >having the consumer track updates received rather than the supplier >tracking updates sent. No, this breaks G3 and MM1 above [Albert] I think we might be at cross purposes. I was not supporting Steve's comment on P2: [snip]... I thought that there was mail already agreeing to change P2 to be implementation neutral in response to other comments. http://www.imc.org/ietf-ldup/mail-archive/msg00884.html >13) Transactional Consistency > >G2. LDAP Replication SHOULD NOT preclude support for model 1 >(Transactional Consistency) in the future. > >P7. The protocol SHOULD NOT preclude support of Transactional >Consistency (model 1). > >Model 1: Transactional Consistency -- Environments that exhibit all >four of the ACID properties (Atomicity, Concurrency, Independence, >Durability) [ACID]. > >No multi-master replication system can avoid precluding support >for ACID transactions. That is inherent in the definition. Nor >does the C stand for Concurrency. Nor does the I usually stand >for Independence. > >http://www.scism.sbu.ac.uk/georgeub/sharenotes/Wk10_Transacti on_Concurrency/ >tsld003.htm > >ACID transactions are also impractical in a global distributed >directory service even using single master - eg it is unscalable >to maintain referential integrity between different servers. >That is why they are excluded from the X.500 data model. > >The whole discussion of models is simply confusing and confused. >It should be dropped as adding nothing to either requirements >or understanding as demonstrated by the inaccurate definitions >and references. I thought you were originally arguing for this model being supported. Are you now changing your mind and saying that this should be dropped? I have *always* said that model 2 is the only model relevant to LDUP work and that multi-master cannot possibly support ACID transactions. To understand why one could reject the wording of that requirement in view of the definition given for Transactional Consistency, simply click on the link that was provided. Speaking frankly both the requirement above and the fact that you thought I ever supported it, is entirely due to you, like many other members of the WG, not actually understanding the issue. [snip...] Well, I think that you may have some difficulty in convincing the WG to drop model 1, but now I understand. Also I point out that Model 1 is not required, but that there was sufficient consensus behind not closing the door on it permanently >14) Limited Effort Consistency > >G1. LDAP Replication MUST support models 2 (Eventual Consistency) and >3 (Limited Effort Eventual Consistency) above. > >URP makes no attempt to support model 3 (any failure in its attempt to >support model 2 does not constitute supporting model 3, which is >aimed at entirely different design goals completely irrelevant >to LDAP directory replication). If folks want to use LDAP in a Model 3 situation then it should be replicatable by LDUP, right? [snip] Only if you believe a WG that has not been chartered to do that work, has not done any such work, and knows nothing about the issues involved, should nevertheless be told it MUST do it before having completed work it is supposed to know about. I can only repeat my remarks at the link provided in the message you are replying to: *** Model 3 ("limited effort consistency") is needed for multi-master replication among such a large number of independent nodes that it becomes impossible to maintain globally consistent state information as to which nodes are actually participating at any given time. There may also be other situations in which it is needed (eg nodes that are not "servers" attempting to provide a reliable service to "clients" but just trying to get a better picture of the world around them, without storage capacity for global information). Examples that come to mind with "servers" include the replication of newsgroups and (distributed) email lists. Despite the best efforts of "backbones" it is impractical to ensure that all nodes do receive all updates so the feeds diverge due to batches not being collected within the "limited best effort" criteria for purges. Model 2 is simply not capable of scaling to the size of systems such as Usenet with currently available technology on a multi-master basis. It is inherently confined to situations where a relatively small number of "servers" (hundreds, perhaps thousands, but not millions) are maintaining a common "backbone" for a much larger number of "slave" servers and end user clients - such as for example LDAP directories ;-) Ah, this is your opinion. However, again I believe that I have seen enough WG consensus to keep Model 3 on the books. I think we may have to agree to disagree here. [snip] From owner-ietf-ldup@mail.imc.org Mon Feb 26 16:42:31 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA28962 for ; Mon, 26 Feb 2001 16:42:29 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.9.3/8.9.3) id MAA05485 for ietf-ldup-bks; Mon, 26 Feb 2001 12:21:51 -0800 (PST) Received: from relay1.pair.com (relay1.pair.com [209.68.1.20]) by above.proper.com (8.9.3/8.9.3) with SMTP id MAA05479 for ; Mon, 26 Feb 2001 12:21:47 -0800 (PST) Received: (qmail 25871 invoked from network); 26 Feb 2001 20:21:16 -0000 Received: from cpe-144-132-70-18.vic.bigpond.net.au (HELO w98) (144.132.70.18) by relay1.pair.com with SMTP; 26 Feb 2001 20:21:16 -0000 X-pair-Authenticated: 144.132.70.18 Reply-To: From: "Albert Langer" To: Cc: Subject: RE: Proposed requirements not met by current architecture and URP proposals - part 2 (end) Date: Tue, 27 Feb 2001 07:07:34 +1100 Message-ID: <000401c0a032$181c7120$6628a8c0@nowhere.com> 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 CWS, Build 9.0.2416 (9.0.2910.0) Importance: Normal In-Reply-To: <200102252339.AAA90185@mail.coreon.net> X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Sender: owner-ietf-ldup@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit [Ryan] What's going on here? I read some of this to be saying "the requirements are wrong" which was not supposed to be the scope of this discussion. Now maybe I'm just misreading, so clarification would help... Section E is indeed saying "the requirements are wrong, - so URP should not be required to meet them". Sections A to D are saying "URP does not meet the requirement" with B and D saying "but it could be fixed to do so" whereas A and C are saying "and it's core design prevents it being fixed to do so - a different approach will be necessary if the requirement is adopted". I tried to explain the categories at the start of part 1, as can be seen by clicking on the link provided: >Continuing from part 1, which defines the categories used: > >http://www.imc.org/ietf-ldup/mail-archive/msg00891.html > As you have noticed, there are some passing references to requirements issues elsewhere, but in section E that is the focus: Requirements Problem: - The requirement could not or should not be implemented. This is not intended as a catalog of requirements issues, but only those of which it might be said that URP and related parts of the architecture has failed to conform, or that conformance to it provides an explanation for not conforming to another requirement. The requirement should be changed or removed, not the specification. I was working through the requirements and URP and architecture systematically in response to John's request, looking for requirements that are not met by URP and architecture so that it could not be said later that any of them were adopted without having had notice of their impact on URP. In doing so I came across several that would have to be included in that list, but which I do not believe URP or the architecture should be expected to satisfy because the problem lies in the requirement rather than URP or the architecture. Also at least 1 where they do conform but doing so is unnecessary or undesirable and provides a justification for not meeting other requirements. My focus is still URP and as a result of that I have not had time to deal with non-URP related requirements issues, except incidentally. Basically it seems to me that the requirements have now reached a point where it is possible to take them seriously as potentially being used to evaluate whether other drafts do or do not meet those requirements and there are indications that they will actually be used that way, unlike the version before you and Rick were added to the editorial team - for which you should both be congratulated (and suitably rewarded with various requirements issues to resolve ;-) >* B) Fixable Show Stopper * > >3) Eventual Convergence >Each of these requires "eventual convergence" (the wording and redundancy >could be improved - as is true of other items, without further comment >below). I disagree. The requirements are specific to the part of the discussion taking place. [snip] [Albert] Well the comment is essentially editorial and as you are the editors I see no need to pursue it. >6) System and Network Performance [snip...] but I'm keeping the above to refer to later [Albert] Looking forward to your views on this and other issues (whether in this "last call" on requirements context or in relation to URP etc). I'm assuming the editors will be going through all issues raised by anyone whether you (or John) have expressed an opinion about them now or not. >7) Missing [...] The requirement document should not mandate implementation mechanisms. [snip]... [Albert] Agreed - section E below is where I am suggesting the requirements are problem. All the other items above are saying there is a meaningful requirement which URP and/or the architecture are being required to implement but do not implement - as requested by John. * E) Requirements Problem * (Here beginneth the requirements items ;-) [...] >11) Design constraint on orderinig > >MM7. Multi-master conflict resolution MUST NOT depend on the in-order >arrival of changes at a replica to assure eventual convergence. > >SM2. The master replica in a Single Master system SHOULD send all >changes to read-only replicas in the order in which the master applied >them. > >(Appendix B.2 explains that requirement SM2 is intentionally not a >MUST and does not apply to multi-master at all) > >URP does not meet SM2 for Single Master but does meet MM7, at the expense >of conflicting requirements G3 and MM1. Appendix B.2 does justify SM2, >although the justification points to MUST and the explanation does >not justify not adopting the same for multi-master and >simply dropping MM7. > >Decisions about ordering are a design issue, not requirements. >Design constraints should not be included in requirements without >a clear reference to corresponding actual requirements. Uh, you answered this yourself, didn't you? Decisions about ordering are not a design issue in the single master case, but are a design issue in the multi-master case. Therefore, order can be required for single master but not for the multi-master case [Albert] The way I see it any sensible design for Single Master would maintain strict ordering - both to meet the necessity for some sort of conformance level and migration and coexistance strategy for existing single master implementations implied by the WG charter (which I believe should also be spelled out as a requirement), and also to simplify implementation and meet requirements G2 and MM1 for performance. However the functional requirements are covered by G2, MM1 and the implicit or missing requirement to support Single Master meaningfully. The conclusion that maintaining strict ordering is the best design for meeting such requirements can be drawn in the architecture and does not need to be spelled out as a requirement. I try to be very consistent about this distinction between design choices and requirements. Perhaps I am overly sensitive to it in reaction to John's persistent campaign to present my objections to URP not meeting the requirements as just a cover for my having been so presumptious as to show that an alternative design was possible by submitting MDCR when I initially drew attention to the basic flaws in URP and insisted that the lack of requirements that made it obvious such a design would be unacceptable necessitated review of the allegedly "ready" requirements draft. My items 6 and 8 raise the relevant requirements that URP does not comply with. The design choices that resulted in that are a design problem, not a requirements problem. At any rate I certainly agree with the design choice reflected in SM2, so the comment is essentially editorial and I will not pursue it. Concerning MM2, you seem to be suggesting that it merely does not impose a requirement for strict ordering on the design for multi-master. That could be achieved by simply omitting it and perhaps moving the explanation words elsewhere into a more explicit statement within SM2 that it does not apply to multi-master. In fact MM2 explicitly requires that the design for multi-master require consumers to accept out of order changes during a replication session, instead of requiring suppliers to keep them in order. That is very clearly a design choice as to *how* to satisfy requirements for (robust) eventual convergence. I believe it is a bad design choice which unnecessarily complicates implementation and directly frustrates achieving the performance requirements in G2 and MM1, without adding anything to the robustness of convergence. An immediate consequence is that replication sessions have to be restarted from the beginning when the link fails whereas they can continue from where they left of when strict ordering is used (as correctly noted in the architecture). As multi-master is especially useful in situations with weak network connectivity that could be quite a significant impact on performance. It is also much easier for each supplier to maintain a single ordered index of what it is sending to various consumers than for each consumer to have to deal with updates out of order. Any simplification of the supplier (which I doubt exists anyway) is completely negated by the fact that every supplier is also a consumer in multi-master and that such indexing has to be done for slave read only single master servers at the periphery anyway. I find the "negative consequences" listed in B.2 for out of order replication convincing and the "beneficial" situations unconvincing. The examples given in the "beneficial" section concerning schema and other critical policy information being replicated out of order are the most dangerous things to replicate out of order as immediately pointed out in the "negative consequences". The only remaining example is for pushing a priority update ahead of a bulk reload which refers to Single Master where you then prohibit it. In general I believe priority updates are adequately catered for by simply being able to trigger a replication session and no significant advantage would be obtained by additional priority that could justify the additional complexity and performance loss etc. >12) Design constraint on update tracking > >P2. The supplier MUST track updates sent to the consumer and not >resend already acknowledged ones, even in the event of recovery from a >failed replica cycle. > >This is another unecessary design constraint. It is not satisfied by >URP and there does not appear to be anything unsound about the URP approach >of >having the consumer track updates received rather than the supplier >tracking updates sent. No, this breaks G3 and MM1 above [Albert] I think we might be at cross purposes. I was not supporting Steve's comment on P2: http://www.imc.org/ietf-ldup/mail-archive/msg00846.html The first part of his argument does indeed ignore G3 and MM1: "Not resending acknowledged updates to a consumer requires something like two-phase commit for the replication session between the supplier and consumer, which isn't part of the current protocol proposal, and doesn't need to be since URP absorbs any duplicates." Absorbing duplicates instead of avoiding them obviously does not minimize either system or network resources. But I do agree with his second point: "Also, with the Update Vector, it is the consumer that keeps track of the updates that have been received rather than the supplier keeping track of the updates that have been sent." I have probably given the wrong impression by saying "there is nothing unsound in the URP approach". What I really meant was just the rest of the sentence "of having the consumer track updates received rather than the supplier tracking updates sent". I had already raised the matter of URP not meeting G3 and MM1 as item 6 in the message you are responding to - categorized as "fixable". The bigger problem of course is that replication sessions have to be restarted from scratch. That is imposed by your design constraint on ordering - item 11 above. Your current wording mandates the supplier keeping track of what consumers have received as the *means* to support G3 and MM1. There is no reason why the goals of G3 and MM1 cannot be achieved with the consumers keeping track. The "pull model" where consumers specify an Update Vector and suppliers send only those items the consumer has thereby said they haven't seen looks perfectly sound to me. The requirements G3 and MM1 simply need to be implemented, not reinforced by attempting to specify the design to implement them in a requirements draft. >13) Transactional Consistency > >G2. LDAP Replication SHOULD NOT preclude support for model 1 >(Transactional Consistency) in the future. > >P7. The protocol SHOULD NOT preclude support of Transactional >Consistency (model 1). > >Model 1: Transactional Consistency -- Environments that exhibit all >four of the ACID properties (Atomicity, Concurrency, Independence, >Durability) [ACID]. > >No multi-master replication system can avoid precluding support >for ACID transactions. That is inherent in the definition. Nor >does the C stand for Concurrency. Nor does the I usually stand >for Independence. > >http://www.scism.sbu.ac.uk/georgeub/sharenotes/Wk10_Transacti on_Concurrency/ >tsld003.htm > >ACID transactions are also impractical in a global distributed >directory service even using single master - eg it is unscalable >to maintain referential integrity between different servers. >That is why they are excluded from the X.500 data model. > >The whole discussion of models is simply confusing and confused. >It should be dropped as adding nothing to either requirements >or understanding as demonstrated by the inaccurate definitions >and references. I thought you were originally arguing for this model being supported. Are you now changing your mind and saying that this should be dropped? I have *always* said that model 2 is the only model relevant to LDUP work and that multi-master cannot possibly support ACID transactions. To understand why one could reject the wording of that requirement in view of the definition given for Transactional Consistency, simply click on the link that was provided. Speaking frankly both the requirement above and the fact that you thought I ever supported it, is entirely due to you, like many other members of the WG, not actually understanding the issue. I stated that multi-master replication cannot possibly support ACID transactions as simply as possible in my first positive exchange with you on the list: *** I think something like this should be in a new requirements draft: "Changes to an LDAP directory can be: a) Locally available b) Atomic c) Never revoked by the directory service Pick any two. This draft provides an explanation of why a choice must be made between b) and c) for directory uses that require multi-master replication to achieve a). It explains what sort of directory uses do require a) and explores the implications of the possible choices between b) and c) and various combinations and options for achieving them. Input is requested from other areas as to what requirements they have for existing and future directory applications and operational uses of the directory that should affect the architectural choices now being made by the WG." *** http://www.imc.org/ietf-ldup/mail-archive/msg00573.html I believe there would be substantially less of the obvious confusion on these issues now, if that work had been done then. I have in the past used the word "transactions" loosely to refer to operations affecting more than one entry but certainly never suggested that multi-master could support ACID transactions. When I first joined the WG I took it for granted that it would be understood by anyone working on multi-master replication issues that it is not possible to support all four elements of ACID transactions, and the WG had simply made a wrong choice as to which proper subset to support and what granularity of replication to support. Now that I know better I intend to avoid the use of the word "transactions" myself and am proposing that the the requirement (which is certainly *not* what I ever proposed or supported) be altered to something actually meaningful as below. >Instead definitions of concepts that are not already defined or well >understood should be provided - eg granularity of operations, granularity of >replication, concurrency, consistency, isolation, durability, >serialization, convergence. In particular there is ongoing confusion about >the >whole concept of "loose consistency" and the fundamental distinction between >the data model permitting different servers to have different versions >of data with only "eventual" convergence, and changes inconsistent with >the constraints of the data model. > >A meaningful replacement for G2 could then be something like this: > >"The protocols SHOULD NOT hinder standardization of extending the >granularity >of LDAP operations beyond a single entry." That sentence is not acceptable to me because (a) I don't see what it has to do with replication and (b) I'm not sure what it really means. [Albert] Fair enough. By itself (b) establishes my wording is not clear enough, which I will leave to the editors, to fix. The current wording and definition is not unclear but plain wrong and that is not because I or anyone else has changed their mind about something - it's just wrong. The fundamental data model of the directory treats entries as the granularity of update operations. Leaving aside extensions to delete a subtree etc, there is simply no way to express an LDAP operation to modify two different entries at once. This is a deliberate choice for scalability because the two entries may be distributed to different servers. Likewise, contrary to URP, when you change anything you are changing an entry as a whole, not just a single attribute or attribute value. Applications rely on that model of an entry as a grouping of *related* attributes and values with a common name. Some work is being done on operations that apply a set of related changes, sometimes referred to as "transactions" and sometimes more accurately as "grouped operations". These have a granularity of more than one entry. Just as replication standards could break atomicity and impede access control standards if not done right, replication standards could impede such work if not done right. For a definition of "SHOULD NOT IMPEDE", see my MDCR draft. For more on what replication has to do with it, see: http://www.imc.org/ietf-ldup/mail-archive/msg00569.html > >URP would not meet such a more reasonable requirement since it does >not respect the granularity of operations being even at the >attribute level, let alone the entry level. > >Other similar requirements would also be appropriate, eg: > >"The protocols SHOULD NOT hinder standardization of signed operations" Did I miss signed operations becoming standard (I might have)? I believe its optional even if it is standardized and so would be captured under the item of supporting LDAP options that needs to be added. If it isn't standardized, then it falls into the same bucket as the ACL discussions. [Albert] I'm not sure what bucket ACL discussions will fall into, though I am sure about what hole a directory replication protocol that cannot support standardized ACLs will fall into. My comment is not limited to things that *have* been standardized. It is based on a general attitude of "first, do no harm". As suggested, it may well belong with a wider item: "In general a review of existing and proposed LDAP extensions should be undertaken as part of requirements analysis to determine what avoidable problems could result from multi-master deployment so that the architecture and design will take those into account and try to minimize their impact. This could best be done by publishing an explanation of the sort of issues likely to arise in an initial requirements document and actively soliciting feedback." >14) Limited Effort Consistency > >G1. LDAP Replication MUST support models 2 (Eventual Consistency) and >3 (Limited Effort Eventual Consistency) above. > >URP makes no attempt to support model 3 (any failure in its attempt to >support model 2 does not constitute supporting model 3, which is >aimed at entirely different design goals completely irrelevant >to LDAP directory replication). If folks want to use LDAP in a Model 3 situation then it should be replicatable by LDUP, right? [snip] Only if you believe a WG that has not been chartered to do that work, has not done any such work, and knows nothing about the issues involved, should nevertheless be told it MUST do it before having completed work it is supposed to know about. I can only repeat my remarks at the link provided in the message you are replying to: *** Model 3 ("limited effort consistency") is needed for multi-master replication among such a large number of independent nodes that it becomes impossible to maintain globally consistent state information as to which nodes are actually participating at any given time. There may also be other situations in which it is needed (eg nodes that are not "servers" attempting to provide a reliable service to "clients" but just trying to get a better picture of the world around them, without storage capacity for global information). Examples that come to mind with "servers" include the replication of newsgroups and (distributed) email lists. Despite the best efforts of "backbones" it is impractical to ensure that all nodes do receive all updates so the feeds diverge due to batches not being collected within the "limited best effort" criteria for purges. Model 2 is simply not capable of scaling to the size of systems such as Usenet with currently available technology on a multi-master basis. It is inherently confined to situations where a relatively small number of "servers" (hundreds, perhaps thousands, but not millions) are maintaining a common "backbone" for a much larger number of "slave" servers and end user clients - such as for example LDAP directories ;-) For example the current LDUP architecture requires each node to maintain and exchange information about the state of all other nodes, which adds a very significant overhead to each replication session and severely limits scalability. Perhaps that could be improved on within the scope of model 2, but it is a non-trivial problem for which nobody in LDUP has come up with a suggestion. I believe there will be a growing demand for improved protocols meeting requirements for "model 3" as the return to understanding the internet as a "peer to peer" network gathers pace. Examples include "Freenet" and "Groove", which could easily point to future peer to peer replication systems reaching millions of replicating nodes but could not hope to maintain more than "best effort" guarantees. Some may well involve the use of LDAP clients and even exchange information analagous to directory entries, though I cannot think of any example of work in that area. But if and when they do, that is *all* they will have in common with LDUP work. The design issues for "model 3" replication protocols has virtually nothing in common with those for "model 2" that actually relates to replication. LDUP has not been chartered to do that work, has not done any such work, and knows nothing about the issues involved. We have to provide a viable solution for replication of LDAP directories. They clearly require eventual convergence and would be useless with "limited effort" convergence since the inevitable divergence would negate the benefits desired from actual needs for LDAP directories. *** Chris commented that "And you point out one of those good reasons in the next paragraph that you wrote...." [see above] Perhaps I was not sufficiently clear in saying "LDUP has not been chartered to do that work, has not done any such work, and knows nothing about the issues involved." But any further clarification would require going beyond merely being blunt. From owner-ietf-ldup@mail.imc.org Mon Feb 26 23:29:10 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id XAA14031 for ; Mon, 26 Feb 2001 23:29:10 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.9.3/8.9.3) id TAA19105 for ietf-ldup-bks; Mon, 26 Feb 2001 19:34:50 -0800 (PST) Received: from relay1.pair.com (relay1.pair.com [209.68.1.20]) by above.proper.com (8.9.3/8.9.3) with SMTP id TAA19100 for ; Mon, 26 Feb 2001 19:34:47 -0800 (PST) Received: (qmail 25570 invoked from network); 27 Feb 2001 03:34:19 -0000 Received: from cpe-144-132-70-18.vic.bigpond.net.au (HELO w98) (144.132.70.18) by relay1.pair.com with SMTP; 27 Feb 2001 03:34:19 -0000 X-pair-Authenticated: 144.132.70.18 Reply-To: From: "Albert Langer" To: "'Paul Leach'" , "'John Strassner'" , "'Ed Reed'" Cc: , Subject: RE: WG Last Call on the LDAPv3 Directory Replication I-D Date: Tue, 27 Feb 2001 14:37:28 +1100 Message-ID: <000901c0a06e$9bac9740$6628a8c0@nowhere.com> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_000A_01C0A0CA.CF1D0F40" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2910.0) Importance: Normal In-Reply-To: <5B90AD65A9E8934987DB0C8C0762657406005A07@DF-BOWWOW.platinum.corp.microsoft.com> X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 X-MS-TNEF-Correlator: 000000003893B2F86024D41184F100E0296560F7A424A100 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_000A_01C0A0CA.CF1D0F40 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit [Paul] Very roughly, if there are N replicas, and each can tolerate an update rate (if it were the only replica) of R, then the total update rate supportable by the replicated directory would be R/N. I do not believe that the replication frequency has much to do with it, unless a low-ish frequency causes many updates to be transferred per replication interval and thereby leads to increased efficiency (due to some batching effect or other). [Albert] I don't understand that and am worried that as I have no implementation experience and each of Paul and Ed are or have been involved with a major vendor with a large deployment of multi-master servers, I may have missed something fundamental about deployment issues. The original below was about unsuitably high rates of concurrent changes to the same entry. Paul's formula S ~ R/N indicates that the "very rough" approximation of the supportable total update rate S, decreases as the number of replicas increases. That is consistent with my understanding that the more opportunities for concurrency there are, the more problems. If there was only 1 replica, there would be no problems arising from conflicts. If every DUA was a DSA, there would be a lot. But for exactly the same reason I would agree with the implication of Ed's comment that S decreases as the diameter of the replication network increases - ie that replication frequency has just as much to do with it, contrary to Paul's statement that frequency has little to do with it. Paul's response seems to be sliding from estimating S in the light of conflict problems in the first paragraph to the quite separate question of estimating what total update rate, R, can be handled at all in the second. On that issue I would have thought that "very roughly" R is independent of N, with no gain and only a small loss from increasing N by adding more replicas. My assumption is that R is primarily limited by whichever of the various constraints such as disk seek times, CPU processing (mainly crypto), and network bandwidth is actually a "tight" or "binding" constraint rather than being slack. Of these, there has to be enough bandwidth available for the peak traffic to at least trickle through in the offpeak periods. Therefore any constraint on bandwidth would primarily affect the replication diameter by pushing more traffic into offpeak periods in order to carry it at all, thereby delaying it. Likewise limitations arising from the number of disk spindles available would primarily have the same effect - forcing you to spread the traffic over a broader peak by splitting the available disk spindles over a larger number of replicas, at the cost of delaying it and thus increasing conflict problems. In that context load sharing strategies just to handle the write volume don't make much sense to me given that you still have to write the update to disk on every replica. You would need to be faced with peaks so sharply spiked and rates so intense that the cost of writing *both* to a logging spindle that is not limited by disk seek times *and* to the random access spindles that are, for *every* replica on *every* update, is offset by the gains from spreading out those peaks a bit by having to handle only R/N of the traffic immediately at each replica and being able to delay (but not avoid) handling the remainder by pushing it outside the peak spikes via logging spindles and replication delays. Those would have to be very sharp spikes indeed! Thus I am puzzled by Ed's earlier anecdote about load sharing of updates. Why would anyone want to do that? To me one needs multi-master for local availability and cheaper failover, not for load sharing on updates. The remaining possibly binding constraint, from CPU crypto processing, seems to me highly dependendent on batching effects due to startup costs initiating a secure association for each replication session and the overhead of update vectors for each such session. Any comments? PS I certainly agree with Rick that no attempt to quantify any of this should be made in the requirements draft. > -----Original Message----- > From: John Strassner [mailto:jstrassn@cisco.com] > Sent: Tuesday, February 20, 2001 8:21 AM > To: Ed Reed > Cc: Albert.Langer@directory-designs.org; Kurt@OpenLDAP.org; > ietf-ldup@imc.org > Subject: RE: WG Last Call on the LDAPv3 Directory Replication I-D > > > This seems reasonable, but I would suggest that we quantify > this, perhaps > in terms relative to the (average) replication frequency of > the system. > Thoughts? > > regards, > John > > At 08:41 AM 2/20/2001 -0700, Ed Reed wrote: > >Hmmm...I've found a point of agreement with Albert ;-)... see [eer] > > > >================= > >Ed Reed > >Reed-Matthews, Inc. > >+1 801 796 7065 > >http://www.Reed-Matthews.COM > > > > >>> "Albert Langer" 02/17/01 > > 01:30PM >>> > >[Kurt] > >At 04:39 PM 2/17/01 +1100, Albert Langer wrote: > > >Put succinctly: LDUP directories won't interoperate. Period. > > > >I would say that two LDUP peers could interoperate (from > >a protocol perspective) but that this, in itself, does > >not: > > 1) preserve LDAP/X.500 semantics nor > > 2) provide "equally capable" replicas. > > > >The former issue can not be resolved unless one requires > >transactional consistency in multiple master replication. > >The latter issue can be tackled by writing a very tight > >applicability statements. > > > >[Albert] > > > >...snip... > > > >A necessary consequence of multi-master, as opposed to single master, > >is that in addition to transient inconsitencies between data > read from > >different directory servers there will also be problems with > data read > >from a single server. There are 2 options possible for multi-master: > > > >1) Conflicting updates to the same entry are prioritized so that only > >one succeeds and the others are rolled back. That necessarily results > >in different behaviour to single master directories but is not > >fundamentally inconsistent with LDAP semantics and does not prevent > >interoperability. Problems arising can be resolved by users > rather than > >sysadmins by notifying them of lost updates (whether due to > name conflicts > >or > >other conflicts). An applicability statement should clearly indicate > >that multi-master is unsuitable in any situation with a high rate of > >concurrent changes to the same entries. > > > >[eer] I certainly agree that we should make clear (if we have not > >already), that multi-master is unsuitable in any situation with a > >high rate (say, frequently faster than the time it takes for a change > >to fully propagate to all registered replicas) of concurrent changes > >to the same entries at different master replicas. > > > >The "frequently..." qualifier represents my own bias as to what > >is "reasonable" and might be changed to simply say "faster than...". > > > >[/eer] > ------=_NextPart_000_000A_01C0A0CA.CF1D0F40 Content-Type: application/ms-tnef; name="winmail.dat" Content-Disposition: attachment; filename="winmail.dat" Content-Transfer-Encoding: base64 eJ8+IhwDAQaQCAAEAAAAAAABAAEAAQeQBgAIAAAA5AQAAAAAAADoAAEIgAcAGAAAAElQTS5NaWNy b3NvZnQgTWFpbC5Ob3RlADEIAQ2ABAACAAAAAgACAAEGgAMADgAAANEHAgAbAA4AJQAAAAIAKgEB A5AGAAQVAAAoAAAACwACAAEAAAALACMAAAAAAAMAJgAAAAAACwApAAAAAAADAC4AAAAAAAMANgAA AAAAHgBwAAEAAAA1AAAAV0cgTGFzdCBDYWxsIG9uIHRoZSBMREFQdjMgRGlyZWN0b3J5IFJlcGxp Y2F0aW9uIEktRAAAAAACAXEAAQAAABYAAAABwKBum2DB35RvDIAR1YTzAOApZWD3AAACAR0MAQAA ACkAAABTTVRQOkFMQkVSVC5MQU5HRVJARElSRUNUT1JZLURFU0lHTlMuT1JHAAAAAAsAAQ4AAAAA QAAGDgDWr4puoMABAgEKDgEAAAAYAAAAAAAAADiTsvhgJNQRhPEA4CllYPfCgAAAAwAUDgEAAAAL AB8OAQAAAAIBCRABAAAAJBAAACAQAABzHwAATFpGdVTDq+sDAAoAcmNwZzEyNeIyA0N0ZXgFQQED Aff/CoACpAPkBxMCgA/zAFAEVj8IVQeyESUOUQMBAgBjaOEKwHNldDIGAAbDESX2MwRGE7cwEiwR MwjvCfe2OxgfDjA1ESIMYGMAUDMLCQFkMzYWUAumIFtgUGF1bF0KogqAVgkEkHkgA2B1Z2hsiHks IAaQIHRoBJCsZSAKwB8ATh3wZQtQGQ3gYXMecABwZCBl2QDQaCAf0AOgdAbwBJCGYQ6wIBEgdXBk IUGrHVQhMygekWkFQHce4t0ewSACIB5QH3YpI7AeoP5SHnAewSDRI5Eg8AGQAyDXIbQd8CHncyGw cBfBAaD5IRAgYh3gI4IfhQ6wIEC0ZGkYIGMg8B3RdwhgCmwgQGIfAFIvTi6LHVQdVEko0G8gbiWg cynRH7BldiNiIUAn62klAiAgA1BlcQpQbmP3HeAT4AQgbRrQIJAg8Csi1wPwHsAi8SwdVHUj0AeQ yQQgYSAXsHctBAAgkPsteB/QdRQQLjEAcB3gIbS3BCAuoSnhdCEwAIBmBJD5GCEgcASQIhUsyQuA DrB8cnYlwSAiHsMnwSEQYf5kMrMLgAUAIGAUECBBASDnDeAIkC3SKGQKUCDhJqXfA3AnoSFAE9AL gGc3sikRLyOwBcAloB7RKSpLW0GebCngACAdRSsSbicFQHsv4ASBcwGQNeMsQSAiYf5tKXEzoAiQ PeYEICsQE+DXK/ErYB6AbQtQZQeAAjD/LRMdVA7AM/E4EiFiIEUkofsdAiATRT5xHvEFsT/jKeD7 JSELgHYG8CvwIEAvAzBQ/QDAagWwHVQr8CAwBbFFdbkLYHJnHwABAAtQbwbA10DBJJIuUGwtIC0A wD2g/xKBFBA1gD2BHnArEADALfL7K/AdVG0EASixOUIewDnivmY9UT6QQMI1sQbgdQVA10fZBAEK UHMqS1QjkgUQ/mcLgCXBK6EwgCMgLiFM5P8v4CcAIwAncS3xT4AgkCEy/wQgJKEFoC3QCHAYIAIw HVTvE9E58DKkI4JzTGEgUAIwtR3QLkMDJwQgAhBySLF7MFAF8H4qAjUxKOAognPbHVQsJyJJsR3l Ih8QJyD9A2B4B3AtFCShVDMnGSWf/R1UUx5wBYE3UzAxMrEjkfxudQbQEoEkoR+GNxdOQP4gTyAs QQQAUnIAkEkxUwb9LwNtMjE9ZzniLCcEYEPi/ycjL+AjAAiQVYNSeC3gVzZfHuUk42L0WREngW1f YUn3HqZQUiPDMR92JOMYIGC1/ymWQDFmxh8RBABL4wNhUnI6Zh+xdGc0K+Ed0URV5kFQRG0wU0Ev dWeVKZb1MFJ0KktCTRFkMg7AANB+dCPhVDc3Ui1BKxAphGH/CcIu9COCQGIs9R1UJKFDoPtVcQWg bUgzLCMF8FyvKODfTGFJQlnVLLkdVG4UID7B8mte2CAtHoAsBSy/Lcf+ajGwP3MuUlc1LrtScjMx /x3RLqFVNT2hDrB1yC17HVR/H7ACQFrTLskqS1U1GCBzvycwAIBUUQngawEy1HMfsP9iI2uzB5B7 0FliOfEF8AuA/yNzH7AeMFMVUlRsM2qYh9X/N+A9kTPgCsBzEVjwLoMjgv8toCMAhVKLEiH2LaGH EVmk/YcJdywzWx4ecCTRILIp4b1TkWQhEAsxHXI+ImwDINeH1RQQUoFkKktPJTJfs/9OEXKHP+Me wB4SdfVYKR5Q/VjQUk3hHVRWoR+QRqFIRe5OHnAvA0AxZwtxIBMjw/0wUHMAwJIBF7AEEQNSl4b/ N0M54h9gJ8E2sGIjYwMfhv0qS02aQU4BQHA09F1SLEH/l0JmsVlRBRAj4R+wSxAoon8nwY7QDeAe 0EmxJJFlJyD/NZAFEAhgX/QzMTVBgCEuYvsuISjgc3oAhXF6AIchB5DxHnBDUFUdVFkRQiAEEL05 4igAwAuAI+EFAHkFMHxvKSAEeaY5kCAwA/Bkbx7Al4UwMSkgdZHxmkIiz3vQiGFY0AWxImJWojnw /1jQo8gmUh7RVzeQojnihjD9ANBrkwweoxQQaRUuAzLU/wnwHhKpGB8QNZADECdzVaH7oqgz8GGl gSEwN9IukixBrzaRfSEzMA3ga1rSaB4D+4fGJKBms6KmRQZxBHBfY/8e4VWhIWIxcaxYe/GxmCmE v6CXkWU6NCx+d5cnwXAxsP8502MDs/Y1QTjVtqUz4rei/4fCBbAEgS6SH9AzoB3gIwG/kcRpFSfA HVQBAAtgeTni8YONTGlrB9AEAIgioVHve8NrHV18pQRwVqEwAZFl/7JHum2VJlRWOjR6wFWhOAD9 OfF5CGB9x4UAN1E187Pn9m+iQjBQYgNgNrASgbOj/yfBhQCCYmI0IgWyOMf7zpb/R3MFwF2/H/CR ZyOCBaB9If/HwsOINcWjkZvZbAamR2b2/5PlfxIOwhewzbEwwGsxrjL/MzEOsE+QB5F9Ay6hkPSi qP53BRAhUUUB07BHsT0DAMD/xRAuRBQQhTIuoTlhT5BGkf8sFMyxgDEDEBgAHWOVNC7h/92zI4Jb ZS6ipRJ78WzkH4V9VRBZ4PEpg3lGPxIy42b/ANBFRrOigCHNURPhC1DP8v/FAT5xIDFR9DlAl4Zg cd+ibyw21abdojniKgbgHsAq+7RjMGFnT5GuQchUVzlf4f8rYqE5pQ3r8CAh7FMn8yAhf5tWANCm 0tIoPgRl8mQyKv9s4+xQH4W5gvP1L4Uhwx5x/1IyA9AUICe2mYKbFM1lOeL/TQKVgRQQtxbncs7x IwEnwf8/4WIz3IYjtFZiWdWz9ZeF/3Wxd5EOsJoyBUAgY/R2ICLPrgRatdYUcDQoYk0RK2L9P/Bv hlAkgJDz0HUfcadi/8EivbkjAHS1TRAN0A8QI3P/s6PoY22g+tDsr22hIDA0L//WFF9j+TGUyzLj WDPn4yal9wXkl+IYMCFObKORKxA+kXm94Hp6kTEnsnVDIGBy9yvBztF5oGMrMCFSTPPaop8mpdsF JKEyVVUQV2gpZr+4ofTwZ9J14i6zLCI/TsX/3+MTMuXyLjJI2fOymuAf0P9MwbJE0XAjALtGIDGi EVjw/xZyslHOoh5wK2IWpNrJ9PH/EdZObgL0OeInMKbxUWKrtf+jufORa8KmF6fUZrKm1fZQ/4V3 OWFRoiPhmAaYUnS1uaLfObuk4TiTgDJjkXDVk17C/2PRh1ORZZKSZLBlwTAgpsD/JmJ78nDi/pl7 0zHBBPBBJv811c6TGLGZ8RG2CsEkkGRAv2QUQpOkgjjlKdTEK0G4s/11s3MUZYQVdmA80EIgWpH7 p4NzGVK1UeCEmVGPsIBxz59gOLeBYBOBaWaaQbix/1nTX+ERIG72p2AFEYfUB8a/jCEC8S+y44C0 AW+8PnqwtTlCT092TfJBcxBlOUMFOMZGa8E6IEpvaL2ZsFN/QZsAeaDO0FunYbFI0G86aqPyPFFA zGCqc9WgLnWRXTjGU0DBrTugVE4hTFB59lBGwuBmcqpwCvEyMPZQQGAwkWiAODoyaIBBTTjGNxTQ O6BDoVLmATjGQ2NZO6BBbF3hb7BMU6JyzkDjkHMwLGJ5LQBwBPAKZ2AwLmRAZzsgSxFksHRAT5gh TERBjlBFQzjGY/B0Zi1vEDUR0EClsGNFQj5ndWImaiSBO6BSRTugV0f2IEPAfSFDkfL08QVCRjI8 djNtMERGQkEISEkt/kQ4xkzuX5A1UoWDciTRkn/2UAEycpZaQOzghwHghHd/jAI0VTjGNTL2UMBR fMBw/22gRseH4WHATuPTMHvQ4fTtBUIoytGLMWUCAHtvfHP/iPFSKHGxCSCAcV9wTeiVo/8v5k1I czCZgMEQ1LY5IDvC1UzuQZYwMEDwNEEiQFCOL0BgXiFAwS0wN0CwL/ZQQiXdkQ/hOjjGPkjndbBY 0GDQSSfK4fOwY7D/6LEdUblTZ3BzE3XDfoNDVPAgOy0pYNGFYjygc0Dqcj5XPmAHPWXuYAdCLbI+ QlItTTMxsDB3peE32aBIAGAHK0DRQME3OWI2aqAwNjVgB4hwdKBwOi8vd2wwLmiL+C5DT0FXZUhg cG6wq5C3Y1VDxKwgPENfRG9nOSDiMF4QMTcvQMFuGEDAcDozMFBd8G6xYAdb10WiZLhdUjRzoDl/ wF3ye3KEakAxXuJvC1+eYHBQfxBRpIHMYSSQuzA7oEYwVf5Q44FxBNvilNDekunytdD3wFGPsbfg UMBjaahgB1AX/z+Q6mWU0HpEwFBwMKOiEsL/e8qnQJs4YGFhsV+xpsDeEP/AQoUAy9HgQQIAATLq dVLC55mhxADFUGxm9lAT8Mim72BhGcF4mYcGMQIAzYHFUIZyyuFGMi9YLjVAsHcpsadgNGFj7nKt RYbaMveHos6gBQIiVxGqg9SQOHD/0aGsIJ2dZSocgvOx3kDO0P+UVNSQmbAZwrDxh9HeEMrg/5UQ YXAHUfaBE0E3NYWYPVH/uQCqQVaxFxG44o8g6hFXYf+ZoRXT/vA2AhZTCClpqByC/1SxvXKPKLDx MUC1YqGU65XvqtDkI6sDgbhw/vMXpCUy/zNRN7KNT3ShcARkv2BwYNH/PZCUkGDRnd91oBVhptJA Iv+44lcUtoIVy6hB9oGasPkx7+YjxnKUt1uHPqoR7hS5oP82MOOQVqPw4pKS2+C5Yddx/5Nyk8Lb 4rDwf0DmAL0B4yD/qtBamCtxgXvjkMuxYoC5Yf9w5ymxiBEskbAk5wBKQUow/+exsPHZBmL0OMap E82SYAf/9+MnIaQ0rES35fNSXgCjYX/F5B1ljpMVy1/4YAeHkUP/2DUkEhHV8NbLVNpACvGyMve6 wXsBVqB65hHnseCT+8L/YAcTMnmSFYMql6zCxiIC0f/eEA5TmDEJQjLSoOXKgofR/xXhhZiEsasI 5nD6shBAztD/o/56mwEy7mSv6GFxy2HaQP+L46elk7Ji5UYyiPn/UoVi/xmzzYHgUZoIe8gXpHyB rgb/EUHX1JfEkDeYoQPQf/Jal+/jIKzR4IJcRz5YgStw7vD/97GYoRnBNIECdR9g1fEZUPNJ8bbG KHes0M0jJNU4xv9PYN5B2CaFmIm5vAPSyGPg30EwpiGav2KkNYVjB1APIf+UAuOQTEH5VZJS8yIV 2+5h/2Fwj0AEQP/zphIvQafxi9D/VqPnA6lAIgLpA8/xYAcecf8nYatTI/BwgrcvexKfj3Sh/2SC MO/qVVFhNYXGcOiQ19R/VYA0gFFSCiPDSkowr6J5/in2UNl/2o/bn9yiazjdB/4ofrEfElcTegEZ ERZTzXL//HTwMQQxmBEMAvOyqUDe9P+R+CBgxACL8iCBOHD3gCwR//shSjJbEZOiYoAKAIzGg6D/ 0AHeT5Hp34/6AauCqyaU7Pvgn45FIuwYYNGMoIvCNICvD1L3QYfSN8JtV3F3I6G/BlDG0SGD0RAs AKUKIk8Y/4ygGGLOkJnhNeLe9KPVM3B/MYF+svkw7Nj54vfPdKEvC2SKOMR9BCAeAEIQAQAAAFEA AAA8NUI5MEFENjVBOUU4OTM0OTg3REIwQzhDMDc2MjY1NzQwNjAwNUEwN0BERi1CT1dXT1cucGxh dGludW0uY29ycC5taWNyb3NvZnQuY29tPgAAAAADAAlZAQAAAAsAAIAIIAYAAAAAAMAAAAAAAABG AAAAAAOFAAAAAAAAAwACgAggBgAAAAAAwAAAAAAAAEYAAAAAEIUAAAAAAAADAA6ACCAGAAAAAADA AAAAAAAARgAAAAABhQAAAAAAAAMAHYAIIAYAAAAAAMAAAAAAAABGAAAAAFKFAAAnagEAHgAegAgg BgAAAAAAwAAAAAAAAEYAAAAAVIUAAAEAAAAEAAAAOS4wAAsAH4AIIAYAAAAAAMAAAAAAAABGAAAA AAaFAAAAAAAACwAjgAggBgAAAAAAwAAAAAAAAEYAAAAADoUAAAAAAAADACSACCAGAAAAAADAAAAA AAAARgAAAAARhQAAAAAAAAMAJoAIIAYAAAAAAMAAAAAAAABGAAAAABiFAAAAAAAAHgA1gAggBgAA AAAAwAAAAAAAAEYAAAAANoUAAAEAAAABAAAAAAAAAB4ANoAIIAYAAAAAAMAAAAAAAABGAAAAADeF AAABAAAAAQAAAAAAAAAeADeACCAGAAAAAADAAAAAAAAARgAAAAA4hQAAAQAAAAEAAAAAAAAAAgH4 DwEAAAAQAAAAOJOy+GAk1BGE8QDgKWVg9wIB+g8BAAAAEAAAADiTsvhgJNQRhPEA4CllYPcCAfsP AQAAAIgAAAAAAAAAOKG7EAXlEBqhuwgAKypWwgAAbXNwc3QuZGxsAAAAAABOSVRB+b+4AQCqADfZ bgAAAEM6XFdJTkRPV1NcTG9jYWwgU2V0dGluZ3NcQXBwbGljYXRpb24gRGF0YVxNaWNyb3NvZnRc T3V0bG9va1xEaXJlY3RvcnktRGVzaWducy5wc3QAAwD+DwUAAAADAA00/TcAAAIBfwABAAAAMQAA ADAwMDAwMDAwMzg5M0IyRjg2MDI0RDQxMTg0RjEwMEUwMjk2NTYwRjdBNDI0QTEwMAAAAAADAAYQ 3qaQYQMABxB4FQAAAwAQEAEAAAADABEQAgAAAB4ACBABAAAAZQAAAFBBVUxWRVJZUk9VR0hMWSxJ RlRIRVJFQVJFTlJFUExJQ0FTLEFOREVBQ0hDQU5UT0xFUkFURUFOVVBEQVRFUkFURShJRklUV0VS RVRIRU9OTFlSRVBMSUNBKU9GUixUSEVOVEgAAAAAat0= ------=_NextPart_000_000A_01C0A0CA.CF1D0F40-- From owner-ietf-ldup@mail.imc.org Tue Feb 27 03:20:27 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id DAA01472 for ; Tue, 27 Feb 2001 03:20:27 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.9.3/8.9.3) id XAA09759 for ietf-ldup-bks; Mon, 26 Feb 2001 23:45:00 -0800 (PST) Received: from relay1.pair.com (relay1.pair.com [209.68.1.20]) by above.proper.com (8.9.3/8.9.3) with SMTP id XAA09738 for ; Mon, 26 Feb 2001 23:44:57 -0800 (PST) Received: (qmail 26748 invoked from network); 27 Feb 2001 07:44:25 -0000 Received: from cpe-144-132-70-18.vic.bigpond.net.au (HELO w98) (144.132.70.18) by relay1.pair.com with SMTP; 27 Feb 2001 07:44:25 -0000 X-pair-Authenticated: 144.132.70.18 Reply-To: From: "Albert Langer" To: "'Jerry Combs'" , "'John Strassner'" , "'Paul Leach'" Cc: "'Kurt D. Zeilenga'" , Subject: RE: WG Last Call on the LDAPv3 Directory Replication I-D Date: Tue, 27 Feb 2001 18:47:35 +1100 Message-ID: <001101c0a091$8d453900$6628a8c0@nowhere.com> 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 CWS, Build 9.0.2416 (9.0.2910.0) Importance: Normal In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Sender: owner-ietf-ldup@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit [Jerry] http://www.imc.org/ietf-ldup/mail-archive/msg00870.html I think the following item should be removed from the requirements doc. >>>P6. The protocol MUST support propagation of atomicity information. [Context re application integrity omitted as I want to focus on example below. See link above - AL] As an example, suppose you have a replica with a replication interval of 5 minutes. On this replica you modify an attribute 10 times during the 5 minute interval. When it is time to begin the replication the attribute has a specific state. Should all ten "transactions" be replicated or should only the current state be replicated? I contend that the replication mechanism should only guarantee the replication of the current state. This reduces the amount of replication traffic dramatically. Note that attributes that are high priority could be replicated immediately and would therefore replicate each state change. Both methods should supported. [Albert] As far as I understand the context (omitted) this "example" is in fact the *reason* you are giving for not needing to propagate atomicity information - ie unless I have misunderstood, you are not claiming that some actual *harm* could result from implementing the current draft requirement, other than the impact on performance. The harm done by the requirement and the benefit from removing it is then a claimed "dramatically" reduced amount of replication traffic to be achieved by removing it. But the *only* reduction in traffic possible from your proposal is the updates made concurrently at each replica between replication sessions. Those are *precisely* the updates that may result in conflicts for which the propagation of atomicity information is required in support of requirement MM5 to be able to fix any problems that do turn out to arise. So you are asking for a trade off between safety and performance. For such a trade off to be justified the performance would *have* to be "dramatically" improved, as indeed you claim. Several people have now indicated that they support including some kind of warning that multi-master replication is unsuitable for applications with a high rate of concurrent changes - ie a high rate of changes to the same entry at *any* replica between replications - never mind such a high rate that there is also a high rate of changes to the entry at any *single* replica between replication sessions. Your example of 10 changes to a single entry at a single replica between replications would necessarily imply a high rate of concurrent changes to the same entry at other replicas. I haven't done the calculations, but taking into account the birthday paradox etc I suspect it would imply that *most* entries are experiencing concurrent changes between replications. I don't see how you could get up to 10 happening to any significant enough number at a single replica for "dramatically" reduced traffic, without at least 1 concurrent change for most entries. It would of course be possible to summarize the 10 modifications, but you are proposing to optimize for *precisely* the situation that others are saying is unsuitable for use of multi-master. You would need to show they are wrong about that first. In the thread where that discussion took place, you wrote, concerning Paul's R/N formula: [Jerry] http://www.imc.org/ietf-ldup/mail-archive/msg00856.html This assumes that replication is implemented as a 1 to N function. If transitive replication was implemented instead, each replicas efficiency could be maintained by limiting the number of replicas that it communicates to directly. While at low update rates transitive synchronization lengthens the update interval, at high update rates it is vastly more efficient. Lack of transitive synchronization will limit LDUP scalability. Transitive synch also allows you to minimize the impact of slow communication links. [Albert] There was no such assumption and all work in this WG has assumed transitive replication (for good reasons including scalability and connectivity though I don't understand your point about efficiency and slow communications links at all). I do not read that as a response to the claims in that thread that multi-master is unsuitable for high concurrency situations and am not aware of any other argument you have presented that might be relevant to that issue. So I am assuming you have not justified your claim that "dramatically" reduced replication traffic could result from your proposal and that therefore you have not justified the proposal. If anyone reading this finds themselves surprised to be agreeing with me, please pause and check back above to make sure you haven't been agreeing with something I haven't actually been saying. PAUSE ================================================================== ================================================================== Likewise of course I do not regard the URP design as acceptable because the whole point of it is to achieve *exactly* what Jerry has in mind. The design choice it makes is to summarize changes to a single entry between replication sessions, which can only be a useful optimization for the reasons Jerry gave, but has not justified. From owner-ietf-ldup@mail.imc.org Tue Feb 27 07:32:38 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA05407 for ; Tue, 27 Feb 2001 07:32:37 -0500 (EST) Received: by above.proper.com (8.9.3/8.9.3) id DAA21130 for ietf-ldup-bks; Tue, 27 Feb 2001 03:53:50 -0800 (PST) Received: from ietf.org (odin.ietf.org [132.151.1.176]) by above.proper.com (8.9.3/8.9.3) with ESMTP id DAA21125 for ; Tue, 27 Feb 2001 03:53:48 -0800 (PST) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA04410; Tue, 27 Feb 2001 06:53:47 -0500 (EST) Message-Id: <200102271153.GAA04410@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: ietf-ldup@imc.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-ldup-usage-profile-00.txt Date: Tue, 27 Feb 2001 06:53:47 -0500 Sender: owner-ietf-ldup@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the LDAP Duplication/Replication/Update Protocols Working Group of the IETF. Title : General Usage Profile for LDAPv3 Replication Author(s) : R. Huber et al. Filename : draft-ietf-ldup-usage-profile-00.txt Pages : 16 Date : 26-Feb-01 Support for replication in LDAP directory systems is often one of the key factors in the decision to deploy them. But replication brings design constraints along with its benefits. We discuss some of the factors that should be taken into consideration when designing a replicated directory system. Both programming and architectural/operational concerns are addressed. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ldup-usage-profile-00.txt Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-ldup-usage-profile-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-ldup-usage-profile-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20010226143722.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ldup-usage-profile-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ldup-usage-profile-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20010226143722.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ietf-ldup@mail.imc.org Tue Feb 27 10:42:48 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA13239 for ; Tue, 27 Feb 2001 10:42:48 -0500 (EST) Received: by above.proper.com (8.9.3/8.9.3) id HAA18230 for ietf-ldup-bks; Tue, 27 Feb 2001 07:06:10 -0800 (PST) Received: from relay1.pair.com (relay1.pair.com [209.68.1.20]) by above.proper.com (8.9.3/8.9.3) with SMTP id HAA18224 for ; Tue, 27 Feb 2001 07:06:09 -0800 (PST) Received: (qmail 12077 invoked from network); 27 Feb 2001 15:05:36 -0000 Received: from cpe-144-132-70-18.vic.bigpond.net.au (HELO w98) (144.132.70.18) by relay1.pair.com with SMTP; 27 Feb 2001 15:05:36 -0000 X-pair-Authenticated: 144.132.70.18 Reply-To: From: "Albert Langer" To: "'Richard V Huber'" , Cc: , , Subject: RE: New draft for LDUP Working Group Date: Wed, 28 Feb 2001 02:08:55 +1100 Message-ID: <002001c0a0cf$347f3440$6628a8c0@nowhere.com> 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 CWS, Build 9.0.2416 (9.0.2910.0) Importance: Normal In-Reply-To: <200102222255.RAA23476@qsun.mt.att.com> X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Sender: owner-ietf-ldup@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit [Rick] [...draft-ietf-ldup-usage-profile-00.txt...] This is the initial draft of a profiles document. We know it needs a lot more work (remember, in San Diego I only promised an extended outline before the next meeting). We are looking for comments on what should be included/excluded from future versions. [Albert] Looks like an *excellent* start. If only something like that had been produced earlier on... Are you looking for discussion in the list now, or just announcing for discussion after requirements and/or IETF meeting? [Rick] I hope that some of the warnings about the consequences of replication that we have been discussing as part of the requirements draft can end up in this draft. This might help us move forward on the requirements. But also, after we finally get all the documents published (who says I'm not an optimist?), people are more likely to look for warnings in a profile document like this than in the requirements. [Albert] I noticed that some of the text I find unsatisfactory in appendix B is repeated in the profile, together with lots of new stuff that certainly does bring out various issues that people should be aware of with multi-master (though I keep wondering whether they are really directed at users or at protocol designers ;-) Now that there really is such a draft, I suggest removing the repeated text from the requirements entirely, leaving it as far as possible as simple numbered requirements. Replace with a paragraph stating unequivocally that there are many significant issues concerning multi-master that cannot be understood from the requirements document alone and that readers should refer to the separate "work in progress". Plus an explicit request also in the requirements introduction, for people to review it together with the "work in progress" and provide feedback to the WG concerning applications that might be affected by the deployment of multi-master and measures that could be taken to meet user needs for it. That would meet several of my problems with the whole process and help achieve your hope that the profile could assist in moving forward on requirements. From owner-ietf-ldup@mail.imc.org Tue Feb 27 14:10:01 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA24419 for ; Tue, 27 Feb 2001 14:10:01 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.9.3/8.9.3) id KAA06573 for ietf-ldup-bks; Tue, 27 Feb 2001 10:10:45 -0800 (PST) Received: from relay1.pair.com (relay1.pair.com [209.68.1.20]) by above.proper.com (8.9.3/8.9.3) with SMTP id KAA06565 for ; Tue, 27 Feb 2001 10:10:41 -0800 (PST) Received: (qmail 11425 invoked from network); 27 Feb 2001 18:10:09 -0000 Received: from cpe-144-132-70-18.vic.bigpond.net.au (HELO w98) (144.132.70.18) by relay1.pair.com with SMTP; 27 Feb 2001 18:10:09 -0000 X-pair-Authenticated: 144.132.70.18 Reply-To: From: "Albert Langer" To: "'Ryan Moats'" Cc: Subject: RE: Proposed requirements not met by current architecture and URP proposals - part 2 (end) Date: Wed, 28 Feb 2001 04:52:36 +1100 Message-ID: <002401c0a0e8$fe4eae40$6628a8c0@nowhere.com> 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 CWS, Build 9.0.2416 (9.0.2910.0) Importance: Normal In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Sender: owner-ietf-ldup@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit [Albert] >11) Design constraint on orderinig > >MM7. Multi-master conflict resolution MUST NOT depend on the in-order >arrival of changes at a replica to assure eventual convergence. > [...] Concerning MM7, you seem to be suggesting that it merely does not impose a requirement for strict ordering on the design for multi-master. That could be achieved by simply omitting it and perhaps moving the explanation words elsewhere into a more explicit statement within SM2 that it does not apply to multi-master. Maybe it could be omitted, but SM2 is single master and doesn't apply to multi master, and I (for one) would rather say something then have a void on ordering. The dependence on ordering is very close to making a choice between two general classes of implementation: state-based versus change log and that's something that the WG will not be successful mandating and has explicitly kept open in the past. [...] I disagree. If you go back through the archives, you will see a lot of discussion of state-based versus change log implementations. Requirement MM7 says that either approach may be used, because the state-based system may never be able to send changes in the correct order. [Albert] I noticed that when I went through the archives on first joining the WG and have just taken another look. This has heightened my concern that MM7 be removed or replaced with something more neutral. There are 3 plausible design choices that the *architecture* can adopt for implementations conforming to multi-master standards. a) Consumers MUST accept out of order changes from suppliers. b) Suppliers MUST send changes in order to consumers. c) Both of the above. There are no other plausible options for interoperability such as "leave it to the administrator" - that is merely a restatement of c). Otherwise no interoperability is possible. The current wording of MM7 clearly mandates option a) or c) and prohibits adoption of the simpler option b) alone. "MM7. Multi-master conflict resolution MUST NOT depend on the in-order arrival of changes at a replica to assure eventual convergence." That is consistent with the design choice made in the current architecture draft and may well be the final outcome. But it is clearly a design choice, not a requirement. The reason for it you mention, "because the state-based system may never be able to send changes in the correct order" could well reflect a valid non-functional requirement such as: "Design choices MUST reasonably balance the convenience of implementation for state based and log based systems". I'm not sure whether that should be described as a "resource constraint", "architectural constraint", "policy constraint" or what, but I'm not disputing it's a practical reality for the WG. Making that explicit would also cover your related remark: "The dependence on ordering is very close to making a choice between two general classes of implementation: state-based versus change log and that's something that the WG will not be successful mandating and has explicitly kept open in the past." But even without such an explicit additional requirement, the arguments you mention could certainly be legitimately raised in discussing the architecture and would undoubtedly prove decisive if they stand up to scrutiny. What I noticed when reading the discussions the first time, and have confirmed again, is that these arguments *were* decisive, but were *not* subjected to much scrutiny. Every other argument pointed to a significantly more efficient and simpler design with mandatory ordering. In particular MM7 essentially achieves the exact opposite of G2 and MM1 by requiring a restart for any interrupted replication session and also far more frequent complete resynchronizations. In my view it is quite clear that state based implementations would not be inconvenienced *at all* by adopting option b). All they need is a simple index in CSN order and they will have to maintain that index anyway to support SM2 or an equivalent design choice not expressed as a requirement. The evidence for that is Active Directory, which is clearly a state based implementation and does use option b) with a simple index. AD appears to be substantially more efficient than Novell's implementation. Unfortunately Microsoft has not actively participated in working out a design for interoperability. So they have not challenged any of the bad design choices in LDUP, although they certainly know better, or at least hold an opposite opinion as to which design choice is better than the choice which has prevailed in LDUP so far on this issue, but have never argued for it. [...] That may be true, but that should be determined by the marketplace [...] LDUP has no option but to make a choice between a), b) and c). Even listing c) is stretching a point simply because it is a logically possible choice. Ultimately the real choice comes down to a) or b) and adding administrator options to a protocol like this conflicts with well known internet architectural principles. But that of course is a design issue. [...] Again, you are now into implementation and others may not agree with you, so the requirements have to leave other possibilities open Exactly my point. Anything I say about this is an argument about design, not requirements. Please try very hard to find a wording that enables such discussion to be deferred until design documents are being considered in the light of requirements, rather than making it essential to settle the issue during the next "final" call on requirements by putting a design choice in a requirements document. [...] >12) Design constraint on update tracking > >P2. The supplier MUST track updates sent to the consumer and not >resend already acknowledged ones, even in the event of recovery from a >failed replica cycle. > >This is another unecessary design constraint. It is not satisfied by >URP and there does not appear to be anything unsound about the URP approach >of >having the consumer track updates received rather than the supplier >tracking updates sent. No, this breaks G3 and MM1 above [Albert] I think we might be at cross purposes.[...] [snip]... I thought that there was mail already agreeing to change P2 to be implementation neutral in response to other comments. http://www.imc.org/ietf-ldup/mail-archive/msg00884.html [Albert] We were indeed at cross purposes. You appeared to be explicitly arguing for the current text above. I am quite happy with Steve's proposal (although simple deletion would be better): *** 1) The replication architecture SHOULD avoid sending to a consumer an update that the consumer has already seen. 2) An update received by a consumer more than once MUST NOT produce a different outcome than if the update were received exactly once. *** The weakening to SHOULD in 1) does not authorize just deciding to send duplicates anyway if a better approach is available, but permits balancing the undesirability of that against other valid design considerations that can be justified, rather than imposing the method for meeting performance goals in the requirements document. Essentially it leaves it up to the design to meet the other requirements while demanding an explanation if the choices made result in any duplicates at all. That seems unecessary to me, but it doesn't really matter. The MUST NOT in 2) adds nothing but also does no harm. Note that these two are consistent with a design change to eliminate duplicates completely (which almost necessarily requires sending in strict order), although not requiring such a change. But any such design change *would* be prohibited by MM7. >13) Transactional Consistency > >G2. LDAP Replication SHOULD NOT preclude support for model 1 >(Transactional Consistency) in the future. > >P7. The protocol SHOULD NOT preclude support of Transactional >Consistency (model 1). > >Model 1: Transactional Consistency -- Environments that exhibit all >four of the ACID properties (Atomicity, Concurrency, Independence, >Durability) [ACID]. > [snip...] Well, I think that you may have some difficulty in convincing the WG to drop model 1, but now I understand. Also I point out that Model 1 is not required, but that there was sufficient consensus behind not closing the door on it permanently [...] >14) Limited Effort Consistency > >G1. LDAP Replication MUST support models 2 (Eventual Consistency) and >3 (Limited Effort Eventual Consistency) above. [...] Ah, this is your opinion. However, again I believe that I have seen enough WG consensus to keep Model 3 on the books. I think we may have to agree to disagree here. [snip] [Albert] Agreeing to disagree is fine. Problem is that you are "agreeing to agree", which has no place in a standards process. Unlike others that may be unnecessary, these 2 are simply meaningless. I'm not going to be the one in difficulty convincing anybody about anything. You're the bunny that committed to: If URP goes to last call without (at least for me) acceptible statements as to why it doesn't meet certain requirements, I'll try to be first in line saying "uh, I don't see that you've met requirement nor do I see a statement as to why", that's all. http://www.imc.org/ietf-ldup/mail-archive/msg00838.html So what answer is any author supposed to give as to *why* they haven't made any attempt to not preclude support for model 1 and have provided no support for model 3? There is nothing surprising about agreeable people agreeing to agree and so reaching "consensus" not to drop something without any intention of actually doing anything about it. But that isn't part of producing a standards track protocol for it. If you are editor of a requirements document in a standards process, it is your job to keep such "agreeableness" out of it and make sure it consists only of operationally meaningful requirements that can be applied to determine whether or not those requirements have been satisfied. I'm very impressed with the fact that you and Rick have been able to turn a document that was largely meaningless into one which *can* be used to ask such questions. I wouldn't have thought it was possible, given the starting point and environment. It's a shame to spoil that by undermining the effect of those questions with 2 questions that are meaningless. "Consensus" is no excuse. You are the guys that are supposed to report back and point it out when a supposed consensus does not actually mean anything. If you get instructed to insert or remove something by a WG decision, after having advised against it, that's a different matter. No such instruction can be given to you as editors, without putting it to the WG mailing list (not a meeting or a memo from John without having actually *asked* the WG), and a public determination reached by the co-chairs that a "rough consensus" does exist, after giving you the opportunity to justify your recommendation and others the opportunity to comment and record their views on the specific issue that the WG is taking a decision about. This mailing list is part of the public record of the IETF standards making process. It is an engineering process for producing actual internet protocols. "Rough consensus" is the means by which it takes decisions between mutually exclusive alternatives, not a means for avoiding them, or for recording Johns views on various subjects from day to day, or rubber stamping the "room consensus" at a meeting. No such WG instruction has been given to you on this or any other matter. The point is you haven't advised against it so you are clearly identified as the authors of 2 "requirements" that you know, or ought to know, are meaningless. Having said that, I agree to disagree ;-) From owner-ietf-ldup@mail.imc.org Tue Feb 27 14:13:39 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA24628 for ; Tue, 27 Feb 2001 14:13:38 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.9.3/8.9.3) id KAA08215 for ietf-ldup-bks; Tue, 27 Feb 2001 10:34:48 -0800 (PST) Received: from mail.coreon.net (IDENT:mirapoint@mail.coreon.net [216.74.131.6]) by above.proper.com (8.9.3/8.9.3) with ESMTP id KAA08210 for ; Tue, 27 Feb 2001 10:34:46 -0800 (PST) Received: from rmoats2 (wenjus3.coreon.net [216.74.131.3]) by mail.coreon.net (Mirapoint) with ESMTP id AAA94680 (AUTH rmoats); Tue, 27 Feb 2001 13:33:21 -0500 (EST) From: "Ryan Moats" To: , "'Ryan Moats'" Cc: Subject: RE: Proposed requirements not met by current architecture and URP proposals - part 2 (end) Date: Tue, 27 Feb 2001 12:39:08 -0600 Message-ID: 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 IMO, Build 9.0.2416 (9.0.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 In-Reply-To: <002401c0a0e8$fe4eae40$6628a8c0@nowhere.com> Sender: owner-ietf-ldup@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit This time -----Original Message----- From: Albert Langer [mailto:Albert.Langer@Directory-Designs.org] Subject: RE: Proposed requirements not met by current architecture and URP proposals - part 2 (end) [Albert] >11) Design constraint on orderinig > >MM7. Multi-master conflict resolution MUST NOT depend on the in-order >arrival of changes at a replica to assure eventual convergence. > [...] Concerning MM7, you seem to be suggesting that it merely does not impose a requirement for strict ordering on the design for multi-master. That could be achieved by simply omitting it and perhaps moving the explanation words elsewhere into a more explicit statement within SM2 that it does not apply to multi-master. Maybe it could be omitted, but SM2 is single master and doesn't apply to multi master, and I (for one) would rather say something then have a void on ordering. The dependence on ordering is very close to making a choice between two general classes of implementation: state-based versus change log and that's something that the WG will not be successful mandating and has explicitly kept open in the past. [...] I disagree. If you go back through the archives, you will see a lot of discussion of state-based versus change log implementations. Requirement MM7 says that either approach may be used, because the state-based system may never be able to send changes in the correct order. [Albert] I noticed that when I went through the archives on first joining the WG and have just taken another look. This has heightened my concern that MM7 be removed or replaced with something more neutral. There are 3 plausible design choices that the *architecture* can adopt for implementations conforming to multi-master standards. a) Consumers MUST accept out of order changes from suppliers. b) Suppliers MUST send changes in order to consumers. c) Both of the above. There are no other plausible options for interoperability such as "leave it to the administrator" - that is merely a restatement of c). Otherwise no interoperability is possible. The current wording of MM7 clearly mandates option a) or c) and prohibits adoption of the simpler option b) alone. Actually, I don't see (b) being precluded by MM7. In fact (b) has always been assumed at least by me and so I was aiming for (c) in the sense that while servers MUST send changes in order, it is quite possible due to topology that a client will receive changes in a different order ("in order arrival"). If you are assuming that (b) guarantees that (a) will never occur, you'll have a task convincing me. Again, you are now into implementation and others may not agree with you, so the requirements have to leave other possibilities open Exactly my point. Anything I say about this is an argument about design, not requirements. Please try very hard to find a wording that enables such discussion to be deferred until design documents are being considered in the light of requirements, rather than making it essential to settle the issue during the next "final" call on requirements by putting a design choice in a requirements document. I think we had done that. Obviously, you disagree {...} Note that these two are consistent with a design change to eliminate duplicates completely (which almost necessarily requires sending in strict order), although not requiring such a change. But any such design change *would* be prohibited by MM7. Well, that's not my reading of MM7, but I'll think about it some more [Albert] Agreeing to disagree is fine. Problem is that you are "agreeing to agree", which has no place in a standards process. Unlike others that may be unnecessary, these 2 are simply meaningless. I'm not going to be the one in difficulty convincing anybody about anything. You're the bunny that committed to: If URP goes to last call without (at least for me) acceptible statements as to why it doesn't meet certain requirements, I'll try to be first in line saying "uh, I don't see that you've met requirement nor do I see a statement as to why", that's all. http://www.imc.org/ietf-ldup/mail-archive/msg00838.html So what answer is any author supposed to give as to *why* they haven't made any attempt to not preclude support for model 1 and have provided no support for model 3? Sorry, you aren't going to tie me in knots. That's for the to answer, when they go to last call. I'm not going to burn brain cells worrying about it :-) There is nothing surprising about agreeable people agreeing to agree and so reaching "consensus" not to drop something without any intention of actually doing anything about it. But that isn't part of producing a standards track protocol for it. If you are editor of a requirements document in a standards process, it is your job to keep such "agreeableness" out of it and make sure it consists only of operationally meaningful requirements that can be applied to determine whether or not those requirements have been satisfied. Having said that, I agree to disagree ;-) It is necessary to "agree to agree". This goes on at all levels (i.e. between the editors, inside the WG, inside the IETF). My point is that, just because I can't see how something can be done, doesn't mean that there somebody out there isn't smarter than I am and can solve the problem and so MHO is that the door should remain open. If the WG consensus changes (and I don't think it has), then you are right that it should change. Further, if the collective folks doing the architecture or protocol or some other *standards* track document decide they can't do it, they have to say why they can't do it. I may not like the reason for why they can't do it, but if the WG consensus is that the reason is acceptable, I have to accept it. From owner-ietf-ldup@mail.imc.org Tue Feb 27 14:41:31 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA25943 for ; Tue, 27 Feb 2001 14:41:31 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.9.3/8.9.3) id LAA11654 for ietf-ldup-bks; Tue, 27 Feb 2001 11:04:35 -0800 (PST) Received: from sj-msg-core-2.cisco.com (sj-msg-core-2.cisco.com [171.69.43.88]) by above.proper.com (8.9.3/8.9.3) with ESMTP id LAA11647 for ; Tue, 27 Feb 2001 11:04:34 -0800 (PST) Received: from mira-sjcm-1.cisco.com (mira-sjcm-1.cisco.com [171.69.43.102]) by sj-msg-core-2.cisco.com (8.9.3/8.9.1) with ESMTP id LAA29744; Tue, 27 Feb 2001 11:04:23 -0800 (PST) Received: from JSTRASSN-W2K1.cisco.com (ams-vpdn-client-376.cisco.com [144.254.47.124]) by mira-sjcm-1.cisco.com (Mirapoint) with ESMTP id AAX00222; Tue, 27 Feb 2001 11:03:59 -0800 (PST) Message-Id: <4.3.2.7.2.20010227014557.038636f8@mira-sjcm-1.cisco.com> X-Sender: jstrassn@mira-sjcm-1.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Tue, 27 Feb 2001 01:50:50 -0800 To: "Ryan Moats" From: John Strassner Subject: RE: Consolidation of several counts thread Cc: "Kurt D. Zeilenga" , "John Strassner" , In-Reply-To: References: <5.0.2.1.0.20010225180748.00a61730@router.boolean.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ietf-ldup@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: My only problem with not having a matrix is that it begs the question, what about attributes that are not specifically covered? Plus, it still makes me uncomfortable that we are in effect saying that some attributes are more equal than others with respect to replication. Maybe we could call this LDUP-1984. ;-) If you **really** want to do it this way, fine. But as a compromise, please consider adding a short justification as to WHY each attribute is being included as a MUST, SHOULD, or MAY (or NOT, as appropriate). And please consider changing the approach to instead say that all attributes MAY be replicated with the following exceptions. regards, John At 08:49 AM 2/26/2001 -0600, Ryan Moats wrote: >I'm certainly in favor of somthing shorter than a matrix. I still >have to parse what Kurt is saying below to make sure I agree with >it, but I like that approach better than a matrix. > >Ryan > >-----Original Message----- >From: owner-ietf-ldup@mail.imc.org >[mailto:owner-ietf-ldup@mail.imc.org]On Behalf Of Kurt D. Zeilenga >Sent: Sunday, February 25, 2001 8:40 PM >To: John Strassner >Cc: ietf-ldup@imc.org >Subject: Re: Consolidation of several counts thread > > >At 08:05 AM 2/25/01 -0800, John Strassner wrote: > >Issue 1: if we start singling out particular types of information that can >or can not be replicated, where do we stop? > > > >We've had two different attempts to characterize this issue. One was the >(in)famous active vs. passive data, and the other was Kurt explicitly >listing several types of attributes with MUST, SHOULD, and MAY support >levels. This implies that some members of the WG are trying to define this >in more detail. However, I would like to see more detail in what we are >recommending. The active vs. passive definition fails due to the lack of >familiarity with the precise meanings of the terms. Similarly, listing some >but not all attributes to be replicated just raises questions about what to >do with the attributes that aren't specified. > > > >Action: Kurt to work with the authors to either build a matrix of ALL >attributes and whether they should be replicated or not, or the authors >convince Kurt that he's wrong ;-) and this doesn't need to be satisfied. >Result to be posted to the WG list. > >Instead of a matrix, I suggest: > > LDUP MUST be capable to replicate all userApplication > attribute types. LDUP MUST be capable to replicate all > directoryOperation and distributedOperation attribute > types defined in the LDAP "core" specification (RFC 2251-2255, > 2829-2830). LDUP SHOULD provide general guidelines for > replication of directoryOperation and distributedOperation > attribute types defined as LDAP extensions. LDUP > SHALL NOT support replication of dsaOperation attribute > types as such attributes are DSA-specific. > >I note that certain operational attributes, such as >subschemaSubentry, may require special attention. I note >there are existing requirements in this area. > >In addition, > LDUP MUST be capable of replicating attribute subtypes. > LDUP MUST be capable of replicating attribute description > options (including ";binary" and Language Tags). From owner-ietf-ldup@mail.imc.org Wed Feb 28 06:54:19 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id GAA01982 for ; Wed, 28 Feb 2001 06:54:18 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.9.3/8.9.3) id DAA14830 for ietf-ldup-bks; Wed, 28 Feb 2001 03:08:25 -0800 (PST) Received: from relay1.pair.com (relay1.pair.com [209.68.1.20]) by above.proper.com (8.9.3/8.9.3) with SMTP id DAA14795 for ; Wed, 28 Feb 2001 03:08:12 -0800 (PST) Received: (qmail 15348 invoked from network); 28 Feb 2001 11:07:39 -0000 Received: from cpe-144-132-70-18.vic.bigpond.net.au (HELO w98) (144.132.70.18) by relay1.pair.com with SMTP; 28 Feb 2001 11:07:39 -0000 X-pair-Authenticated: 144.132.70.18 Reply-To: From: "Albert Langer" To: "'Ryan Moats'" Cc: Subject: Design constraints and models Date: Wed, 28 Feb 2001 22:11:09 +1100 Message-ID: <002701c0a177$27791240$6628a8c0@nowhere.com> 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 CWS, Build 9.0.2416 (9.0.2910.0) Importance: Normal In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Sender: owner-ietf-ldup@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit [Albert] (continuing discussion from: "RE: Proposed requirements not met by current architecture and URP proposals - part 2 (end)" http://www.imc.org/ietf-ldup/mail-archive/msg00916.html) >11) Design constraint on orderinig > >MM7. Multi-master conflict resolution MUST NOT depend on the in-order >arrival of changes at a replica to assure eventual convergence. > [...] There are 3 plausible design choices that the *architecture* can adopt for implementations conforming to multi-master standards. a) Consumers MUST accept out of order changes from suppliers. b) Suppliers MUST send changes in order to consumers. c) Both of the above. There are no other plausible options for interoperability such as "leave it to the administrator" - that is merely a restatement of c). Otherwise no interoperability is possible. The current wording of MM7 clearly mandates option a) or c) and prohibits adoption of the simpler option b) alone. Actually, I don't see (b) being precluded by MM7. In fact (b) has always been assumed at least by me and so I was aiming for (c) in the sense that while servers MUST send changes in order, it is quite possible due to topology that a client will receive changes in a different order ("in order arrival"). If you are assuming that (b) guarantees that (a) will never occur, you'll have a task convincing me. [Albert] 1. Your assumption that (b) could be taken for granted is natural. We are of course talking about a single replication session in a context where it is well understood that globally throughout the replication network, changes from different originator DSAs will arrive at particular replicas interleaved arbitrarily due to transitive replication with bilateral rather than globally imposed schedules and arbitrary dynamic changes to the actual links connecting DSAs as a replication network. It is necessary to design for that even for an enterprise level, let alone global internet level replication standard. The architecture is designed for that, and the fundamental approach used with Update Vectors and Purge Vectors looks sound. Perhaps that should be noted as a real achievement of the LDUP WG, that is likely to be "won and recorded" when we do get to architecture and verify that this fundamental architecture is indeed capable of meeting the relevant requirements. Within that fundamental framework 3 major design issues for propagation of changes arise: 1.1 Should the layer responsible for propagating reports about changes from originator DSAs for eventual convergence of the entire replication set via the replication network deliver every report to every DSA, so that each applies the same deterministic procedures to the same reports (necessarily interleaved) and can easily arrive at eventual convergence so long as those procedures are able to cope with the interleaving, or should it be mixed together with the layer responsible for conflict resolution within each DSA in order to achieve some performance benefit with deterministic procedures that do not need to see all the reports and may generate new reports summarizing reports discarded during transitive propagation. A natural assumption is that one would choose a layered approach in line with commonly accepted architectural principles. Nevertheless, the current draft does not, and I will be raising that as a design issue. It is not a requirements issue because it is sometimes appropriate to mix layers in order to better meet specific performance requirements. (A requirement not to create transient visible directory states that are not the result of any DUA operation could be appropriate but seems to be covered by other requirements and any sound approach to meeting them). 1.2 Should the report propagation mechanism ensure that the reports from each originator DSA are delivered to every other DSA in the same sequence that they were generated by each originator (interleaved of course with the sequences from other originators). A natural assumption is that it should, since that fits naturally with the purge vector mechanism for preventing the unbounded growth of meta-data and generally simplifies things. Nevertheless, the current architecture does not. Again it is a design issue, not requirements. 1.3 Should the protocol between each pair of DSAs that have a replication agreement in either direction transmit reports from the supplier to the consumer in the same sequence that they were received or originated by the supplier. A natural assumption is that it should. I have never heard before of an application protocol that takes a strictly or partially ordered batch of messages that it has to deliver all of, and allows them to be delivered in arbitrary order on a simple link between two nodes. Nevertheless, what you took for granted is not in fact the case and will be raised as a design issue, because it is not a requirements issue. Incidentally, considerable progress was made towards resolving these issues in discussions between Steve, Zachary and me in the thread on "10 Report Propagation Sequence", as can be seen from this comment by Steve: *** There would seem to be four choices: 1) unordered within session, 2) ordered on CSN per replica ID, 3) ordered on CSN, 4) ordered on supplier receipt order. Those vendors wanting unordered transmission should speak up now. I'm happy with 1, 2 or 3. *** http://www.imc.org/ietf-ldup/mail-archive/msg00693.html Nobody has spoken up wanting unordered transmission but neither have either the architecture or URP drafts changed from currently permitting unordered transmission. Nor have the WG chairs done anything to put that issue to the WG for a decision. So contrary to your assumption, MM7 was not viewed by authors of architecture and URP drafts, (who have raised no objection to it), as implying c) rather than a). 2. Your concern that b) alone does not guarantee a) will never occur is adequately covered by the requirement for eventual convergence repeated 3 times and further reinforced by the editors consensus to replace P2 with two requirements that include: *** 2) An update received by a consumer more than once MUST NOT produce a different outcome than if the update were received exactly once. *** What more can you possibly need to ensure that your concern MUST be met by any proposal in design discussions for b) alone? What can you achieve by forcing such discussion to take place in the next final call on requirements? I think we had done that. Obviously, you disagree {...} Note that these two are consistent with a design change to eliminate duplicates completely (which almost necessarily requires sending in strict order), although not requiring such a change. But any such design change *would* be prohibited by MM7. Well, that's not my reading of MM7, but I'll think about it some more [Albert] Fine. When thinking about it, please think in terms of other peoples assumptions and the way it might be read by others rather than the way you read it. BTW that {...} above was a suberb piece of editing to avoid my coat-trailing about review of WG progress and IETF procedures from intruding into the discussion you want to have now on requirements ;-) Similar editing of your own text such as MM7 can ensure design issues do not delay finalizing requirements. [...] * Model 1 and Model 3 * [...] So what answer is any author supposed to give as to *why* they haven't made any attempt to not preclude support for model 1 and have provided no support for model 3? Sorry, you aren't going to tie me in knots. That's for the[m] to answer, when they go to last call. I'm not going to burn brain cells worrying about it :-) Fair enough. But you already mentioned you thought I supported the requirement not to impede model 1. By stating a requirement to not impede ACID transactions that is logically impossible for multi-master you are obscuring real concerns that can be expressed as real requirements that people don't have to burn up brain cells about. Simply add, even if you won't replace: a) For single master environments, replication standards SHOULD NOT impede future work on ACID transactions. (That seems to be Kurt's concern, though I'm still not sure) b) For both single master and multi-master environments, replication standards SHOULD NOT impede future work on grouped operations affecting more than 1 entry. * Agreeing to Agree * There is nothing surprising about agreeable people agreeing to agree and so reaching "consensus" not to drop something without any intention of actually doing anything about it. But that isn't part of producing a standards track protocol for it. If you are editor of a requirements document in a standards process, it is your job to keep such "agreeableness" out of it and make sure it consists only of operationally meaningful requirements that can be applied to determine whether or not those requirements have been satisfied. Having said that, I agree to disagree ;-) It is necessary to "agree to agree". This goes on at all levels (i.e. between the editors, inside the WG, inside the IETF). My point is that, just because I can't see how something can be done, doesn't mean that there somebody out there isn't smarter than I am and can solve the problem and so MHO is that the door should remain open. If the WG consensus changes (and I don't think it has), then you are right that it should change. Further, if the collective folks doing the architecture or protocol or some other *standards* track document decide they can't do it, they have to say why they can't do it. I may not like the reason for why they can't do it, but if the WG consensus is that the reason is acceptable, I have to accept it. I agree with all of that. The normal process involves a continuous give and take with the smaller teams responsible for editing particular documents as an integral whole, submitting their drafts for regular review in which outstanding issues can either get resolved by WG decisions or left for resolution later. By actually reviewing comments and responding to them seriously, either in the list or in new drafts, you and Rick are now moving the WG towards resolution on requirements. When others follow that example, or the chairs start putting unresolved issues that have been debated enough up for WG decision in the list, similar progress will be made on other drafts. BTW please consider your point about "just because I can't see how something can be done", in relation to MM7 ;-) But on the issue of whether we are working on the X.500/LDAP model ("model 2"), or something else, that ought to have been resolved by the WG charter in the first place. Sure the editors working on architecture and other drafts ought to have responded that they can't do it re model 1 and ought to have asked what you are asking them to do re model 3. But you are the authors of a document requiring that they MUST support model 2, with a reference to Xerox Clearinghouse that isn't about it at all, and *you* need to be able to explain why anyone MUST do that. Chris wrote: *** It would not be listed as a MUST at this stage of revising the requirements document if the authors (some of the top LDAP experts in the world) and many other members of the working group didn't know of a good reason for it being stated as that strong of a requirement. *** http://www.imc.org/ietf-ldup/mail-archive/msg00738.html As he is a WG co-chair (or was - I haven't seen any sign of him for quite a while) I took the trouble of spending some time looking for information about Xerox Clearinghouse before deciding that it would not be useful to respond to such messages from Chris. I was already aware that the paper actually referenced by the authors, about Bayou, was relevant to model 2, not model 3, since Bayou supports "eventual consistency" (though with all the extra complications for application semantics that are avoided by the much "lighter" atomicity requirement in LDAP). The "many other members of the WG" who are supposed to know why we MUST work on model 3 are under no obligation to respond. But the authors of the requirements draft have been cited by a WG co-chair as people who "know of a good reason for it". You are one of those authors, and this is a WG last call on a requirement *you* have proposed. Before expecting anyone *else* to "burn brain cells" explaining why they haven't done it, *you* (ie the editors) have some obligation to explain why *you* say they MUST do it. I've said all I want to say about these issues for now. It's up to the editors whether further discussion is needed in the next "final" call. I suggest putting any further explanations in the accompanying material for the next draft, rather than continuing this now. From owner-ietf-ldup@mail.imc.org Wed Feb 28 20:52:47 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA05138 for ; Wed, 28 Feb 2001 20:52:46 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.9.3/8.9.3) id RAA12821 for ietf-ldup-bks; Wed, 28 Feb 2001 17:21:01 -0800 (PST) Received: from relay1.pair.com (relay1.pair.com [209.68.1.20]) by above.proper.com (8.9.3/8.9.3) with SMTP id RAA12814 for ; Wed, 28 Feb 2001 17:20:54 -0800 (PST) Received: (qmail 16953 invoked from network); 1 Mar 2001 01:20:26 -0000 Received: from cpe-144-132-70-18.vic.bigpond.net.au (HELO w98) (144.132.70.18) by relay1.pair.com with SMTP; 1 Mar 2001 01:20:26 -0000 X-pair-Authenticated: 144.132.70.18 Reply-To: From: "Albert Langer" To: Subject: Clear explicit recommendation for corrective action Date: Thu, 1 Mar 2001 12:24:08 +1100 Message-ID: <003101c0a1ee$5094eec0$6628a8c0@nowhere.com> 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 CWS, Build 9.0.2416 (9.0.2910.0) Importance: Normal In-Reply-To: <4.3.2.7.2.20010219100603.00b4bab0@mira-sjcm-1.cisco.com> X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Sender: owner-ietf-ldup@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit [Albert] I do not believe it would be useful for me to respond to the large number of questions and comments that John specifically directed to me recently. I am responding below to only 1 of them, but I will respond to the rest if John insists, as he is a WG co-chair. I do have a clear explicit recommendation for corrective action to fix a problem, which follows the chronological documentation of the problem. >An applicability statement should clearly indicate >that multi-master is unsuitable in any situation with a high rate of >concurrent changes to the same entries. Again, the wg doesn't concur. Plus, I'm confused why you would make this statement, as you positioned your proposal as solving these problems. We have figured out that you don't agree with the design. ;-) The bottom line is that as chair, I need positive comments detailing how to fix a problem. We've had enough complaints through these threads, so I'm asking you to please contain your commentary to clear, explicit corrective action. [Albert 20 June 2000] (discussing MDCR conflict resolution tree with Ryan 8 months ago and referring to the original requirements draft) I don't see a large tree as an implementation problem in itself - the overhead is only about 12 bytes of RAM per conflicting change. However a large tree would indicate an inappropriate use of multi-master replication in situations where conflicting changes are common relative to the replication interval. The directory model of loose consistency is intended only for situations with a high ratio of reads to writes and therefore a low proportion of conflicts relative to the replication interval. This is completely obscured in the requirements draft which treats multi-master as solving all sorts of problems it has no relevance to whatever, while ignoring its primary importance for enabling local availability of changeable entries and not explaining that conflicting changes to the same entry are an unavoidable consequence of that rather than a useful feature. Entries should be re-structured as families of entries for different sets of attributes or attribute values where local availability of changes is required with a ratio of conflicting changes high relative to the replication interval (eg for maintaining distribution lists). If that is not possible, multi-master replication should not be used at all. (Or equivalently, a "primary replica" used for writes). If a high rate of conflicts and therefore large trees is due to coordinated transactions, these should use a database designed for that rather than a directory. They will not work well when "sporadically-connected" however one does it. The conflicts form a tree in reality, whether it is recognized or not. If that tree becomes large then URP would produce a high rate of "Extraordinary States" and "Transient Extraordinary States" while MDCR would produce a high rate of revocation notices because it has at least recognized the reality. Neither is appropriate for directory applications. (In my view even an extremely low rate of "Extraordinary States" without any means except manual administration to recover from them is completely unacceptable). ============================================================================ Eight months later ============================================================================ [Albert 18 Feb 2001] An applicability statement should clearly indicate that multi-master is unsuitable in any situation with a high rate of concurrent changes to the same entries. [John 20 Feb] Again, the wg doesn't concur. Plus, I'm confused why you would make this statement, as you positioned your proposal as solving these problems. We have figured out that you don't agree with the design. ;-) The bottom line is that as chair, I need positive comments detailing how to fix a problem. We've had enough complaints through these threads, so I'm asking you to please contain your commentary to clear, explicit corrective action. [Ed 21 Feb] I certainly agree that we should make clear (if we have not already), that multi-master is unsuitable in any situation with a high rate (say, frequently faster than the time it takes for a change to fully propagate to all registered replicas) of concurrent changes to the same entries at different master replicas. The "frequently..." qualifier represents my own bias as to what is "reasonable" and might be changed to simply say "faster than... [John 21 Feb] This seems reasonable, but I would suggest that we quantify this, perhaps in terms relative to the (average) replication frequency of the system. Thoughts? [Paul 21 Feb] Very roughly, if there are N replicas, and each can tolerate an update rate (if it were the only replica) of R, then the total update rate supportable by the replicated directory would be R/N. I do not believe that the replication frequency has much to do with it, unless a low-ish frequency causes many updates to be transferred per replication interval and thereby leads to increased efficiency (due to some batching effect or other). [Rick 21 Feb] John, I really don't think the requirements document is the place to quantify this. If the list really thinks we need to quantify it, let's do it in the profile document (though it probably won't make the -00 draft which needs to get in by Friday). As for Albert's/Ed's original point, I agree. The requirements already note in B.5.5 that having multiple users/applications changing the same data at the same time is a way to get into trouble. I suppose we could change "at the same time" to "before previous changes have replicated" if that makes it clearer. [John 25 Feb] This memo is written as a summarization by the WG Co-Chair of declaring consensus on discussed items and requesting changes to be made to the current (-06) version of the requirements I-D prior to it being reissued for WG Last Call. [...] Sub-issue 6: noting unsuitability of LDUP for environments with "high rate of change" While everyone agrees with this, no one could come up with a reasonable definition of "high rate of change". However, there is consensus that this should not be specified in the requirements draft, but rather in other drafts (architecture and profile are obvious candidates). A suggestion was to change in section B.5.5 from "They are changing the data at the same time" to "They are changing the data before previous changes have replicated". Action: change in section B.5.5 from "They are changing the data at the same time" to "They are changing the data before previous changes have replicated". ======================================================================= [Albert] The problem I see is that John believes the WG has reached a conclusion when he forms an opinion, or even when he is merely "confused", that everyone has agreed when he has changed his mind, and that no one could come up with a reasonable answer to a question that has not been asked. Unlike normal WG technical business I do not believe this problem can best be resolved through email discussions and I am not calling for such a discussion now. It is better suited to face to face meetings. The corrective action I recommend is that during the coming IETF meeting people try to convince John that the business of an IETF WG is primarily conducted through the email list and that the only way to find out what the WG thinks about an issue is to *ask* it by putting that issue to the list for a decision, not by telling us what we think. If that fails, find a replacement. "IETFers are fiercely independent. It's safe to question opinions and offer alternatives, but don't expect an IETFer to follow orders." http://www.ietf.org/tao.html