From owner-ietf-ldup@mail.imc.org Thu Jan 3 13:29:48 2002 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA07636 for ; Thu, 3 Jan 2002 13:29:47 -0500 (EST) Received: by above.proper.com (8.11.6/8.11.3) id g03IBNK19226 for ietf-ldup-bks; Thu, 3 Jan 2002 10:11:23 -0800 (PST) Received: from out002pub.verizon.net (out002pub.verizon.net [206.46.170.102]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g03IBJ319222 for ; Thu, 3 Jan 2002 10:11:19 -0800 (PST) Received: from D7ST2111 (pool-141-151-12-80.phil.east.verizon.net [141.151.12.80]) by out002pub.verizon.net with ESMTP for ; id g03IBDd07308 Thu, 3 Jan 2002 12:11:13 -0600 (CST) Reply-To: From: "Chris Apple" To: Subject: Last call for slides Date: Thu, 3 Jan 2002 13:09:52 -0600 Message-ID: <001401c1948a$39868740$0200a8c0@D7ST2111> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_0015_01C19457.EEEC1740" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.3311 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Importance: Normal Sender: owner-ietf-ldup@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multi-part message in MIME format. ------=_NextPart_000_0015_01C19457.EEEC1740 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit I have seen slides posted to the list from all presenters except Stephen Legg. If anyone has detailed notes about the document changes he presented, kindly post them to the WG mailing list so I can incorporate into the minutes. Minutes will be due to the Secretariat at end of day on January 7th, 2002. I'll post a draft of them tomorrow to the list. Chris Apple christopher.apple@verizon.net ------=_NextPart_000_0015_01C19457.EEEC1740 Content-Type: text/x-vcard; name="Chris Apple (christopher.apple@verizon.net).vcf" Content-Disposition: attachment; filename="Chris Apple (christopher.apple@verizon.net).vcf" Content-Transfer-Encoding: quoted-printable BEGIN:VCARD VERSION:2.1 N:Apple;Christopher FN:Chris Apple (christopher.apple@verizon.net) TEL;HOME;VOICE:(215) 873-0850 TEL;CELL;VOICE:(610) 585-4241 ADR;WORK:;;214 New Street, Apt 4-N;Philadelphia;PA;19106;United States = of America LABEL;WORK;ENCODING=3DQUOTED-PRINTABLE:214 New Street, Apt = 4-N=3D0D=3D0APhiladelphia, PA 19106=3D0D=3D0AUnited States of Am=3D erica EMAIL;PREF;INTERNET:christopher.apple@verizon.net REV:20011217T233830Z END:VCARD ------=_NextPart_000_0015_01C19457.EEEC1740-- From owner-ietf-ldup@mail.imc.org Sat Jan 5 01:30:57 2002 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA23417 for ; Sat, 5 Jan 2002 01:30:56 -0500 (EST) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g0569OD00139 for ietf-ldup-bks; Fri, 4 Jan 2002 22:09:24 -0800 (PST) Received: from out007pub.verizon.net (out007pub.verizon.net [206.46.170.107]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g0569N300135 for ; Fri, 4 Jan 2002 22:09:23 -0800 (PST) Received: from D7ST2111 (pool-141-151-11-219.phil.east.verizon.net [141.151.11.219]) by out007pub.verizon.net with ESMTP ; id g05695D29538 Sat, 5 Jan 2002 00:09:05 -0600 (CST) Reply-To: From: "Chris Apple" To: Cc: "Chris Apple" , "'John Strassner'" Subject: LDUP WG Meeting Minutes Date: Sat, 5 Jan 2002 01:07:43 -0600 Message-ID: <000301c195b7$ac0be8e0$0200a8c0@D7ST2111> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_0004_01C19585.617178E0" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.3416 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Importance: Normal Sender: owner-ietf-ldup@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multi-part message in MIME format. ------=_NextPart_000_0004_01C19585.617178E0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Please send comments/corrections/etc. to the mailing list and to the Co-Chairs directly. The minutes are due to the secretariat on January 7, 2002. Please send comments and corrections prior to that date. Meeting Minutes LDAP Duplication/Replication/Update Protocols WG (ldup) Thursday, December 13 at 1530-1730 =================================== CHAIRS: Chris Apple John Strassner 0) Agenda Bashing No changes were made to the agenda. 1) LDUP Update Reconciliation Procedures http://www.ietf.org/internet-drafts/draft-ietf-ldup-urp-05.txt A new version was issued several weeks prior to the WG Meeting. Specific changes to the document are listed at the end of the draft. Some editorial changes were made. Other changes to be made in a future document revision will include the addition of other reference documents. 2) LDAPv3 Replication Requirements http://www.ietf.org/internet-drafts/draft-ietf-ldup-replica-req-10.txt This document has passed WG Last Call. Comments recently posted to the list after the conclusion of the WG Last Call period will be handled as a part of IETF Last Call. Co-Chairs have an action item to follow up with the Applications Area ADs to find out when the document will be included in the IESG queue for consideration. 3) LDAP Replication Architecture http://www.ietf.org/internet-drafts/draft-ietf-ldup-model-06.txt A requirements coverage matrix has been posted to the WG mailing list. This posting indicates that the architecture model document lags other WG documents somewhat and needs to be revised. Some requirements are defined in the requirements document that the architecture document doesn't address. Requirements related to state-based systems are not covered. Log-based replication requirements are not adequately addressed. It was pointed out by Ed Reed that this requirements coverage matrix will also help to identify holes in information model document. 4) LDUP Replication Information Model http://www.ietf.org/internet-drafts/draft-ietf-ldup-infomod-04.txt A new revision was submitted shortly before the IETF meeting deadline. No comments on this document revision had been posted to the list as of the WG meeting date. Slides were presented covering the changes made to the document. These slides have been posted to the WG mailing list. 5) LDAP Subentry Schema http://www.ietf.org/internet-drafts/draft-ietf-ldup-subentry-08.txt Discussion via e-mail between the document editors and Kurt Zeilenga have led to WG consensus that the original proposal in this document should not be used. An individual alternative was published by Kurt Zeilenga. The document will be considered by the WG as a proposal on the list. The X.500 committee has agreed to consider changes to the X.500 subentry specification to foster compatibility between LDAP and X.500 provided that we publish rationale and requirements for their consideration. There was some discussion about adoption of the individual proposal from Kurt Zeilenga as a WG deliverable that would replace the existing WG deliverable. This discussion was deferred until such time as the next WG Charter revision proposal is posted to the WG mailing list. 6) The LDUP Replication Update Protocol http://www.ietf.org/internet-drafts/draft-ietf-ldup-protocol-03.txt A revision was submitted shortly before the IETF meeting deadline. Several changes were made since the -02 version. These changes are documented in slides that were posted to the WG mailing list. It is likely that this document will need to be revised at least once more prior to considering WG Last Call. 7) General Usage Profile for LDAPv3 Replication http://www.ietf.org/internet-drafts/draft-ietf-ldup-usage-profile-02.txt The document editors were unable to attend the WG meeting but submitted a slide to the Co-Chairs for presentation at the meeting. This slide was posted to the mailing list. It is likely that this document will need to be revised again after several other WG documents have been revised. 8) LDAP Client Update Protocol http://www.ietf.org/internet-drafts/draft-ietf-ldup-lcup-02.txt Based on mailing list discussion, this document is close to being ready for WG Last Call. The changes made to the document since the -01 revision are included in the document. There is one major issue that requires more mailing list discussion. The issue is whether or not a discovery mechanism enabling client/server implementations to determine what cookie schemes are supported may be overkill. There was some general agreement in the room that this might indeed be overkill and that it should be discussed on the WG mailing list. Once this issue is resolved by the WG, the document should be ready for WG Last Call. 9) Profile for Framing LDAPv3 Operations http://www.ietf.org/internet-drafts/draft-ietf-ldup-framing-profile-00.t xt Grouping technical specification will subsume needed text from 10) Mandatory LDAP Replica Management http://www.ietf.org/internet-drafts/draft-ietf-ldup-mrm-00.txt This document was published by the editors as a very rough draft. The Co-Chairs encouraged members of the WG to review this document with this in mind. Kurt Zeilenga asked if the word mandatory in the title carried its traditional weight as it does when included in requirements language in the body of a document. The general answer given by the Co-Chairs was "not quite" but agreed that the WG should consider an alternate title for the document to clear up confusion if it indeed shouldn't carry its traditional weight. 11) LDAPv3 Access Control - Options to Consider a) Adding it to LDUP? b) Forming a WG Solely to Address Access Control for LDAPv3? c) Handling the Access Control problem by (potentially competing) individual contributions? d) Do nothing and let the work go on outside of the IETF? e) Other options? Discussion about this topic indicates that it is generally accepted that LDUP will not have successfully concluded if it publishes deliverables which do not support and actively address interoperable, secure replication of information between LDAP servers. Room belief is that it belongs in a WG.The pending conclusion of the LDAPEXT WG prior to completion of the LDAP Access Control Model work creates an issue that the LDUP WG needs to resolve. When the questions above were posed to the WG members in attendance, they clearly expressed a belief that a general LDAP Access Control model should not become an LDUP deliverable. However, there was also a strong belief among those in attendance that such work does belong in a working group. After much discussion of possible paths to successful WG conclusion, it was proposed that consensus on an access control model applicable only within the context of LDUP specifications might be achieved by using X.500 basic or a profile thereof - or some even simpler proposal. An Engineering Team needs to be convened to draft a list of the minimally required factors needed in an access control model for LDUP. It was pointed out by Kurt Zeilenga that identity to authentication credential mapping will have to be addressed by any access control model for LDUP implementations to use it effectively. 12) Broader WG Charter Discussion The most recent WG Charter proposal posted to the WG mailing list will be revised to remove present wording related to LDUP adoption of the LDAPEXT Access Control Model work. This charter content and associated deliverables will be replaced with content consistent with the discussion that took place during the WG meeting. Chris Apple christopher.apple@verizon.net ------=_NextPart_000_0004_01C19585.617178E0 Content-Type: text/x-vcard; name="Chris Apple (christopher.apple@verizon.net).vcf" Content-Disposition: attachment; filename="Chris Apple (christopher.apple@verizon.net).vcf" Content-Transfer-Encoding: quoted-printable BEGIN:VCARD VERSION:2.1 N:Apple;Christopher FN:Chris Apple (christopher.apple@verizon.net) TEL;HOME;VOICE:(215) 873-0850 TEL;CELL;VOICE:(610) 585-4241 ADR;WORK:;;214 New Street, Apt 4-N;Philadelphia;PA;19106;United States = of America LABEL;WORK;ENCODING=3DQUOTED-PRINTABLE:214 New Street, Apt = 4-N=3D0D=3D0APhiladelphia, PA 19106=3D0D=3D0AUnited States of Am=3D erica EMAIL;PREF;INTERNET:christopher.apple@verizon.net REV:20011217T233830Z END:VCARD ------=_NextPart_000_0004_01C19585.617178E0-- From owner-ietf-ldup@mail.imc.org Mon Jan 7 09:56:28 2002 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA16193 for ; Mon, 7 Jan 2002 09:56:28 -0500 (EST) Received: by above.proper.com (8.11.6/8.11.3) id g07EeLW22139 for ietf-ldup-bks; Mon, 7 Jan 2002 06:40:21 -0800 (PST) Received: from e2.ny.us.ibm.com (e2.ny.us.ibm.com [32.97.182.102]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g07EeK322135 for ; Mon, 7 Jan 2002 06:40:20 -0800 (PST) Received: from northrelay01.pok.ibm.com (northrelay01.pok.ibm.com [9.117.200.21]) by e2.ny.us.ibm.com (8.9.3/8.9.3) with ESMTP id JAA132630 for ; Mon, 7 Jan 2002 09:37:13 -0500 Received: from d01mlc96.pok.ibm.com (d01mlc96.pok.ibm.com [9.117.250.33]) by northrelay01.pok.ibm.com (8.11.1m3/NCO v5.01) with ESMTP id g07Ee3W125554 for ; Mon, 7 Jan 2002 09:40:03 -0500 To: ietf-ldup@imc.org MIME-Version: 1.0 Subject: LDUP Engineering Group on Access Control X-Mailer: Lotus Notes Release 5.0.7 March 21, 2001 From: "Timothy Hahn" Message-ID: Date: Mon, 7 Jan 2002 09:28:51 -0500 X-MIMETrack: Serialize by Router on D01MLC96/01/M/IBM(Release 5.0.9 |November 26, 2001) at 01/07/2002 09:40:03 AM, Serialize complete at 01/07/2002 09:40:03 AM Content-Type: multipart/alternative; boundary="=_alternative 004EB87085256B3A_=" Sender: owner-ietf-ldup@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multipart message in MIME format. --=_alternative 004EB87085256B3A_= Content-Type: text/plain; charset="us-ascii" Hello all, The LDUP WG minutes remind us that an engineering group needs to be established to come up with a proposal for creating some "minimum interoperable access control" such that Secure replication can be established across multiple independent implementations. I don't recall a set of people assigned/volunteered for such a an engineering group yet. Have they been? If so, can the group re-identify itself to the list? If not, I'll volunteer to be one member of the group - are there any other victims/volunteers? Thanks in advance, Tim Hahn Internet: hahnt@us.ibm.com Internal: Timothy Hahn/Endicott/IBM@IBMUS or IBMUSM00(HAHNT) phone: 607.752.6388 tie-line: 8/852.6388 fax: 607.752.3681 --=_alternative 004EB87085256B3A_= Content-Type: text/html; charset="us-ascii"
Hello all,

The LDUP WG minutes remind us that an engineering group needs to be established to come up with a proposal for creating some "minimum interoperable access control" such that Secure replication can be established across multiple independent implementations.

I don't recall a set of people assigned/volunteered for such a an engineering group yet.  Have they been?  If so, can the group re-identify itself to the list?  If not, I'll volunteer to be one member of the group - are there any other victims/volunteers?

Thanks in advance,
Tim Hahn

Internet: hahnt@us.ibm.com
Internal: Timothy Hahn/Endicott/IBM@IBMUS or IBMUSM00(HAHNT)
phone: 607.752.6388     tie-line: 8/852.6388
fax: 607.752.3681
 --=_alternative 004EB87085256B3A_=-- From owner-ietf-ldup@mail.imc.org Mon Jan 7 09:56:30 2002 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA16206 for ; Mon, 7 Jan 2002 09:56:30 -0500 (EST) Received: by above.proper.com (8.11.6/8.11.3) id g07EeDK22132 for ietf-ldup-bks; Mon, 7 Jan 2002 06:40:13 -0800 (PST) Received: from e2.ny.us.ibm.com (e2.ny.us.ibm.com [32.97.182.102]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g07EeB322128 for ; Mon, 7 Jan 2002 06:40:12 -0800 (PST) Received: from northrelay01.pok.ibm.com (northrelay01.pok.ibm.com [9.117.200.21]) by e2.ny.us.ibm.com (8.9.3/8.9.3) with ESMTP id JAA82068 for ; Mon, 7 Jan 2002 09:37:06 -0500 Received: from d01mlc96.pok.ibm.com (d01mlc96.pok.ibm.com [9.117.250.33]) by northrelay01.pok.ibm.com (8.11.1m3/NCO v5.01) with ESMTP id g07Ee2W125552 for ; Mon, 7 Jan 2002 09:40:02 -0500 To: ietf-ldup@imc.org MIME-Version: 1.0 Subject: Re: LDUP WG Meeting Minutes X-Mailer: Lotus Notes Release 5.0.7 March 21, 2001 From: "Timothy Hahn" Message-ID: Date: Mon, 7 Jan 2002 09:28:51 -0500 X-MIMETrack: Serialize by Router on D01MLC96/01/M/IBM(Release 5.0.9 |November 26, 2001) at 01/07/2002 09:40:02 AM, Serialize complete at 01/07/2002 09:40:02 AM Content-Type: multipart/alternative; boundary="=_alternative 004E591585256B3A_=" Sender: owner-ietf-ldup@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multipart message in MIME format. --=_alternative 004E591585256B3A_= Content-Type: text/plain; charset="us-ascii" Chris, With respect to the minutes, I have only one comment. Under section 9 it looked like some words were cut off (see below)? 9) Profile for Framing LDAPv3 Operations http://www.ietf.org/internet-drafts/draft-ietf-ldup-framing-profile-00.t xt Grouping technical specification will subsume needed text from (Was there an end to this sentence?) Regards, Tim Hahn Internet: hahnt@us.ibm.com Internal: Timothy Hahn/Endicott/IBM@IBMUS or IBMUSM00(HAHNT) phone: 607.752.6388 tie-line: 8/852.6388 fax: 607.752.3681 --=_alternative 004E591585256B3A_= Content-Type: text/html; charset="us-ascii"
Chris,

With respect to the minutes, I have only one comment.  Under section 9 it looked like some words were cut off (see below)?

9) Profile for Framing LDAPv3 Operations


http://www.ietf.org/internet-drafts/draft-ietf-ldup-framing-profile-00.t
xt

Grouping technical specification will subsume needed text from

(Was there an end to this sentence?)
Regards,
Tim Hahn

Internet: hahnt@us.ibm.com
Internal: Timothy Hahn/Endicott/IBM@IBMUS or IBMUSM00(HAHNT)
phone: 607.752.6388     tie-line: 8/852.6388
fax: 607.752.3681
 --=_alternative 004E591585256B3A_=-- From owner-ietf-ldup@mail.imc.org Mon Jan 7 11:30:59 2002 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA19471 for ; Mon, 7 Jan 2002 11:30:58 -0500 (EST) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g07GCQ827061 for ietf-ldup-bks; Mon, 7 Jan 2002 08:12:26 -0800 (PST) Received: from ssymexc.anassoc.com (anai.dslwan.toad.net [162.33.140.194]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g07GCJ327043 for ; Mon, 7 Jan 2002 08:12:20 -0800 (PST) X-MimeOLE: Produced By Microsoft Exchange V6.0.4712.0 content-class: urn:content-classes:message Subject: RE: LDUP Engineering Group on Access Control MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----_=_NextPart_001_01C19796.0C77D995" Date: Mon, 7 Jan 2002 11:12:05 -0500 Message-ID: X-MS-TNEF-Correlator: Thread-Topic: LDUP Engineering Group on Access Control Thread-Index: AcGXjnJxbLVQVck2Rvyflxcgg2HBBgABzxwI From: "Matt Hirsch" To: "Timothy Hahn" , 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_001_01C19796.0C77D995 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 VGltLA0KIA0KSSBrbm93IGZvciBhIGZhY3QgdGhhdCBOU0EgaXMgaW50ZXJlc3RlZCBpbiBwYXJ0 aWNpcGF0aW5nIGluIHRoaXMgZ3JvdXANCmlmIGl0IGV4aXN0cyBvciBpcyBnb2luZyB0byBleGlz dC4gIEkgYW0gc3VyZSBTYW5keSBSb2RkeSBhcyB3ZWxsIGFzDQpteXNlbGYgYXJlIGludGVyZXN0 ZWQgaW4gcGFydGljaXBhdGluZyBvbiBiZWhhbGYgb2YgTlNBLg0KUmVnYXJkcywNCi1NYXR0IEgu DQpBJk4gQXNzb2NpYXRlcyBJbmMuDQpNYW5hZ2VtZW50ICYgVGVjaG5vbG9neSBDb25zdWx0aW5n DQo0MTAtNzcyLTUwNjAgZXh0IDIyDQoNCgktLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLSANCglG cm9tOiBUaW1vdGh5IEhhaG4gDQoJU2VudDogTW9uIDEvNy8yMDAyIDk6MjggQU0gDQoJVG86IGll dGYtbGR1cEBpbWMub3JnIA0KCUNjOiANCglTdWJqZWN0OiBMRFVQIEVuZ2luZWVyaW5nIEdyb3Vw IG9uIEFjY2VzcyBDb250cm9sDQoJDQoJDQoNCglIZWxsbyBhbGwsIA0KCQ0KCVRoZSBMRFVQIFdH IG1pbnV0ZXMgcmVtaW5kIHVzIHRoYXQgYW4gZW5naW5lZXJpbmcgZ3JvdXAgbmVlZHMgdG8NCmJl IGVzdGFibGlzaGVkIHRvIGNvbWUgdXAgd2l0aCBhIHByb3Bvc2FsIGZvciBjcmVhdGluZyBzb21l ICJtaW5pbXVtDQppbnRlcm9wZXJhYmxlIGFjY2VzcyBjb250cm9sIiBzdWNoIHRoYXQgU2VjdXJl IHJlcGxpY2F0aW9uIGNhbiBiZQ0KZXN0YWJsaXNoZWQgYWNyb3NzIG11bHRpcGxlIGluZGVwZW5k ZW50IGltcGxlbWVudGF0aW9ucy4gDQoJDQoJSSBkb24ndCByZWNhbGwgYSBzZXQgb2YgcGVvcGxl IGFzc2lnbmVkL3ZvbHVudGVlcmVkIGZvciBzdWNoIGENCmFuIGVuZ2luZWVyaW5nIGdyb3VwIHll dC4gIEhhdmUgdGhleSBiZWVuPyAgSWYgc28sIGNhbiB0aGUgZ3JvdXANCnJlLWlkZW50aWZ5IGl0 c2VsZiB0byB0aGUgbGlzdD8gIElmIG5vdCwgSSdsbCB2b2x1bnRlZXIgdG8gYmUgb25lIG1lbWJl cg0Kb2YgdGhlIGdyb3VwIC0gYXJlIHRoZXJlIGFueSBvdGhlciB2aWN0aW1zL3ZvbHVudGVlcnM/ IA0KCQ0KCVRoYW5rcyBpbiBhZHZhbmNlLCANCglUaW0gSGFobg0KCQ0KCUludGVybmV0OiBoYWhu dEB1cy5pYm0uY29tDQoJSW50ZXJuYWw6IFRpbW90aHkgSGFobi9FbmRpY290dC9JQk1ASUJNVVMg b3IgSUJNVVNNMDAoSEFITlQpDQoJcGhvbmU6IDYwNy43NTIuNjM4OCAgICAgdGllLWxpbmU6IDgv ODUyLjYzODgNCglmYXg6IDYwNy43NTIuMzY4MQ0KCQ0KDQo= ------_=_NextPart_001_01C19796.0C77D995 Content-Type: application/ms-tnef; name="winmail.dat" Content-Transfer-Encoding: base64 eJ8+IgcQAQaQCAAEAAAAAAABAAEAAQeQBgAIAAAA5AQAAAAAAADoAAENgAQAAgAAAAIAAgABBYAD AA4AAADSBwEABwALAAwABQABAP4AASCAAwAOAAAA0gcBAAcACwAMAAUAAQD+AAEJgAEAIQAAADA1 M0Y5OThFNTUwNkZGNDQ5MzA1QTZGM0MzOTdGMTIyABMHAQOQBgAUEQAAOAAAAB8AGgABAAAAEgAA AEkAUABNAC4ATgBvAHQAZQAAAAAAAwA2AAAAAAAfADcAAQAAAFoAAABSAEUAOgAgAEwARABVAFAA IABFAG4AZwBpAG4AZQBlAHIAaQBuAGcAIABHAHIAbwB1AHAAIABvAG4AIABBAGMAYwBlAHMAcwAg AEMAbwBuAHQAcgBvAGwAAAAAAEAAOQCV2XcMlpfBAR8APQABAAAACgAAAFIARQA6ACAAAAAAAAIB RwABAAAANwAAAGM9dXM7YT0gO3A9QSBOIEFzc29jaWF0ZXM7bD1TU1lNRVhDLTAyMDEwNzE2MTIw NVotMTc1NAAAHwBJAAEAAABSAAAATABEAFUAUAAgAEUAbgBnAGkAbgBlAGUAcgBpAG4AZwAgAEcA cgBvAHUAcAAgAG8AbgAgAEEAYwBjAGUAcwBzACAAQwBvAG4AdAByAG8AbAAAAAAAQABOAIBTXqCH l8EBHwBaAAEAAAAaAAAAVABpAG0AbwB0AGgAeQAgAEgAYQBoAG4AAAAAAAIBWwABAAAAOwAAAAAA AACBKx+kvqMQGZ1uAN0BD1QCAAAAAFRpbW90aHkgSGFobgBTTVRQAGhhaG50QHVzLmlibS5jb20A AAIBXAABAAAAFgAAAFNNVFA6SEFITlRAVVMuSUJNLkNPTQAAAB8AXQABAAAAGgAAAFQAaQBtAG8A dABoAHkAIABIAGEAaABuAAAAAAACAV4AAQAAADsAAAAAAAAAgSsfpL6jEBmdbgDdAQ9UAgAAAABU aW1vdGh5IEhhaG4AU01UUABoYWhudEB1cy5pYm0uY29tAAACAV8AAQAAABYAAABTTVRQOkhBSE5U QFVTLklCTS5DT00AAAAfAGYAAQAAAAoAAABTAE0AVABQAAAAAAAfAGcAAQAAACIAAABoAGEAaABu AHQAQAB1AHMALgBpAGIAbQAuAGMAbwBtAAAAAAAfAGgAAQAAAAoAAABTAE0AVABQAAAAAAAfAGkA AQAAACIAAABoAGEAaABuAHQAQAB1AHMALgBpAGIAbQAuAGMAbwBtAAAAAAAfAHAAAQAAAFIAAABM AEQAVQBQACAARQBuAGcAaQBuAGUAZQByAGkAbgBnACAARwByAG8AdQBwACAAbwBuACAAQQBjAGMA ZQBzAHMAIABDAG8AbgB0AHIAbwBsAAAAAAACAXEAAQAAABsAAAABwZeOcnFstVBVyTZG/J+XFyCD YcEGAAHPHAgAHwB0AAEAAAAkAAAAaQBlAHQAZgAtAGwAZAB1AHAAQABpAG0AYwAuAG8AcgBnAAAA HwAaDAEAAAAYAAAATQBhAHQAdAAgAEgAaQByAHMAYwBoAAAAHwAdDgEAAABSAAAATABEAFUAUAAg AEUAbgBnAGkAbgBlAGUAcgBpAG4AZwAgAEcAcgBvAHUAcAAgAG8AbgAgAEEAYwBjAGUAcwBzACAA QwBvAG4AdAByAG8AbAAAAAAAAgEJEAEAAAByCAAAbggAACgbAABMWkZ1+JsqcgMACgByY3BnMTI1 gjIDQ2h0bWwxAzA/AQMB9wqAAqQD4wIAY2jBCsBzZXQwIAcTAoD/EAMAUARWCFUHshHVDlEDAd0Q 1zIGAAbDEdUzBEYQ2UkS72Y0EG8gcwBxLb8RMAaBAoAR4wjvCfc7Gw/tDjA1EdIMYGMAUAsJAWRM MzYRYAulNCAQAioWXA6yAZBnH7AzIDwAIURPQ1RZUEUAIEhUTUwgUFUAQkxJQyAiLS8QL1czQyJw RFRESSGENC4RYFRyAHJ0DmkCIAdAInBFTiI+nxHjICcg0AqjJNwxOSDgjyGSJM4fwCcwRUFEJM0X DvEl7w4QNg7wPE1FOFRBIAWgAjAJ8HQ9BiIF4CGTNS41MC4UNDEocC4fIDAiIBMkQAeAPUckkEVS QbhUT1IkzS0gIOAvKL8fIJEp/yCBLPAg4EJPREBZIGRpcj0gcHKfJMAgMwAhAzAzMWRvAODzMzEK sVxxGvAzMRDwAzAfM5URYB/rHzExT2c5NvEg4ERJVjNpAAA1pyAJ3DY0ON818gdhLCAJAcDfM3cK ojN3CnEmPDAogSLQ/zirPig2Lzc/OE85XzpvRMsFH+s4H8AmbmJzcPMCgDOIJ2EBQEUPPQ8+H/8/ L0A/R19CX0NvRp9Fj1KPwCBJIGtubwfgAhDdBcBhViAA0AVAdBEABUB8TlMrsAQAV2Ar8RsQc7Us AGRXkSAKsSQQYwUg+1cAC4BnWEJW4FdxCcAIYD5wV2Az8C7MUJUkACBlungEAHQEIAWxWbJvWSL0 dG9b5C5Hv0jPSdpVsZct0BlgCHBlBgJkeQfximRhcWEEIHdlbAMg6WIBbXkRMGxaX1CkCsCPYSBX r1i5AiAgYmURAO1i8W8z8FcxLkqfS69Mv/9Nz07fT+9Q/1IPUx9UL2wX6FJlZwsRczx/aI9pn/9q r2u/bM9t327vb/9xD3e47C1NVwAFQEhnf3Q/dU//dl93b3h/eY96n3uvfL+DaK5BXb8t0F76JoNo ThFwHwQQNGAHMCwABCBJbmP/ft9/74D/gg+DH4QvhT+GT5+HX4hvklh+cCRAZ2UHgK8CMEeviy9g CFQFkGhV8N0aoGdhgAhQAIB1IHBZIf+N347vj/+RD5Ifky+UP5VPj5Zfl2+iRy0gMC03AcCeLSzw HyFb8AVAMjKdv3+ez5/foO+h/6MPpB8ykEzBISBLUVVPVCFwMvUxGWB0eWwt8CxQQVKAR0lOLVJJ RyGQ4DogMHB4JLEziAqx/xACNJU1MzTxNY+vnyALYHG/sG+lH6Yvpz+2iDQQaR8SCSY8NDgg4EZP TlTpGWBpei3wMrr7C+K2eeotwnJPBRBnC4AHQAXQ/weQGXCZQMJzvt0rMDKBLpH7M4kLgGUKgbaf XjYykLr76mK2eUYDYTq5vBTwL8A3yDquiTwyb1bgYYBIYf+ckGMfuC9ecrmOxP/GD8cff8gv0ngG YAIwyh/LL2AXTaFmcTEvNy8B0DAU8Mg5OjK/0EFNxB/RH+/SL9M/1E871m/WD9cfYBejCJAAMC1s ZFoQQAdw/42wBbBZQM2fzq/Pv9q/28/n3N/d78kaQ2Pf3+DvYBc/5i/nP+hP6V/qb9VldWIeagWQ 1f/s/2AITERVeFAgRVkw8LEGcVkxR+NZ82ZxQWNjw2Hjn+Sv/+W1nREzQAbw7q/vv/DP/K/X/b/+ zyaWNbqRL8AC9g//Sk+q36vvrP8EH/9f9bEAnP+1EwSvvM+9377vv/RWkS3w3xl4wE/BUltBwY1I YkFdMPlm0GwsAn8Dj+3v+d/67//mHwB/AY8a3xvvHP8QPxFPNxJfE288A2hhIPdzV0d7YqDDAHWN UmTwJkFlQHX/XKBW45kQGC8ZPxpFmXD36H9Z5PgBcwBdEmagW+BlEGG6Yg+AcyWQZUBdIWPJ8Lth IFoRd1vANXBWcHBZ8Pxwb8OAtmBWMifvKP8aVN5jZPBZBI0ALVEiJkE8UP51YNBksy5A+CAscWEg VqD3+TMtMPwjImDhnIBW1NXAvmNhAi7/MA8aVGTwcA+A/mNZAdjBOKBmgiw7VqBZ8N/5UTKgnWE4 cGSSZDhgmXD/O2CZjjavGhjjIDsBmWI4s/5zXawWLxc/Hc8e3x/vQq9/Q79EzyEvIj8jTyRfVaJk /djAJ5mQZPA4oGJSO/89D/8aRWLQmZBnETNALkAzksNwo8LgR4BkL3acsHVkwX9k4WVAVjI0w1Zw J7EqbyD6eeKQLk4/T08aT15fX2/ZFJFhdmEgNRBlnPBmoF07wD/xn1jPX8tJSrFvniw5A1rxKxVk 8C1pO7L/SqCc8C3AYtMr4V8yVU9WX3tXZCyRdFuPXJ9dr5ygdPle0EknTfFSNyvV2MAzoP2ZYG0s ELKgUQFfOMQADHD/WtM1r2JfVzeZEJzwzPFocSZ2OJBgQG1zUihzP/8/j0CfQa9Fv0bPR99y/3QP /3UfSR9KKWwz91BK30vvJUSdmRBrOpDDAC3wZHaZEP/5MBVPcJ9xr3W/ds9333jv/0nve398j9+R 4yBrP2xPV1V/zUKBv4LPg9+Mv43PjtlJNzLyjqD0sCA1IM1gdEDBJzAuaWJtLi0xj4//kJ+Rr5Kx TeCz8MzGic+K3x2L6C/3wLJALTB0dC+QSUJNQJuhVVP40AuyoJvjTdlAKEhBSJ3AICmUL5U/jqxw aGkBA7PwqYA3Ljc1Mi74NjM4v9BkX2VvWeqYP/+ZT1dfok+jX/dBYEDDsI6C8bPwOC84oSWdb55/ jqx9hiB4s/Ckn6WioNYPoDj+MatPrF+Or38PgB8M3wXfAwbvB/xCTE9DS1FwVU9URbUbDG242zVj v9H14E9EWbHguNsyQjf1wUhUTUyx4H0Bv3AAAB8ANRABAAAAegAAADwAQQA4AEEAMQBEADYANQA5 ADQAMQBDADMARAA5ADQAQgA4ADkANgBBAEQANgA3AEQAMQA1ADQAQwA1ADMAQQBCADAANgA1AEQA NgA2AEAAcwBzAHkAbQBlAHgAYwAuAGEAbgBhAHMAcwBvAGMALgBjAG8AbQA+AAAAAAAfAEcQAQAA AB4AAABtAGUAcwBzAGEAZwBlAC8AcgBmAGMAOAAyADIAAAAAAAsA8hABAAAAHwDzEAEAAABmAAAA UgBFACUAMwBBACAATABEAFUAUAAgAEUAbgBnAGkAbgBlAGUAcgBpAG4AZwAgAEcAcgBvAHUAcAAg AG8AbgAgAEEAYwBjAGUAcwBzACAAQwBvAG4AdAByAG8AbAAuAEUATQBMAAAAAAALAPYQAAAAAEAA BzB+oOGulZfBAUAACDAA2JYMlpfBAQMA3j/p/QAAAwDxPwkEAAAfAPg/AQAAABgAAABNAGEAdAB0 ACAASABpAHIAcwBjAGgAAAACAfk/AQAAAGUAAAAAAAAA3KdAyMBCEBq0uQgAKy/hggEAAAAAAAAA L089QSBOIEFTU09DSUFURVMvT1U9RklSU1QgQURNSU5JU1RSQVRJVkUgR1JPVVAvQ049UkVDSVBJ RU5UUy9DTj1NSElSU0NIAAAAAB8A+j8BAAAAKgAAAFMAeQBzAHQAZQBtACAAQQBkAG0AaQBuAGkA cwB0AHIAYQB0AG8AcgAAAAAAAgH7PwEAAAAeAAAAAAAAANynQMjAQhAatLkIACsv4YIBAAAAAAAA AC4AAAADAP0/5AQAAAMAGUAAAAAAAwAaQAAAAAADAB1AAAAAAAMAHkAAAAAAHwAwQAEAAAAQAAAA TQBIAEkAUgBTAEMASAAAAB8AMUABAAAAEAAAAE0ASABJAFIAUwBDAEgAAAAfADJAAQAAACIAAABo AGEAaABuAHQAQAB1AHMALgBpAGIAbQAuAGMAbwBtAAAAAAAfADNAAQAAACIAAABoAGEAaABuAHQA QAB1AHMALgBpAGIAbQAuAGMAbwBtAAAAAAAfADhAAQAAABAAAABNAEgASQBSAFMAQwBIAAAAHwA5 QAEAAAAEAAAALgAAAAsAKQAAAAAACwAjAAAAAAADAAYQuAJKRAMABxC0AwAAAwAQEAAAAAADABEQ AAAAAB4ACBABAAAAZQAAAFRJTSxJS05PV0ZPUkFGQUNUVEhBVE5TQUlTSU5URVJFU1RFRElOUEFS VElDSVBBVElOR0lOVEhJU0dST1VQSUZJVEVYSVNUU09SSVNHT0lOR1RPRVhJU1RJQU1TVVJFU0FO RFkAAAAAAgF/AAEAAAA9AAAAPEE4QTFENjU5NDFDM0Q5NEI4OTZBRDY3RDE1NEM1M0FCMDY1RDY2 QHNzeW1leGMuYW5hc3NvYy5jb20+AAAAAA37 ------_=_NextPart_001_01C19796.0C77D995-- From owner-ietf-ldup@mail.imc.org Mon Jan 7 12:00:15 2002 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA20585 for ; Mon, 7 Jan 2002 12:00:14 -0500 (EST) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g07Ggfo28759 for ietf-ldup-bks; Mon, 7 Jan 2002 08:42:41 -0800 (PST) Received: from femail37.sdc1.sfba.home.com (femail37.sdc1.sfba.home.com [24.254.60.31]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g07Gge328755 for ; Mon, 7 Jan 2002 08:42:40 -0800 (PST) Received: from stan ([24.112.130.97]) by femail37.sdc1.sfba.home.com (InterMail vM.4.01.03.20 201-229-121-120-20010223) with SMTP id <20020107164242.RFTX25077.femail37.sdc1.sfba.home.com@stan>; Mon, 7 Jan 2002 08:42:42 -0800 From: "James Benedict" To: "Matt Hirsch" , "Timothy Hahn" , Subject: RE: LDUP Engineering Group on Access Control Date: Mon, 7 Jan 2002 11:39:51 -0500 Message-ID: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_0006_01C19770.0508D200" 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 V6.00.2600.0000 X-MS-TNEF-Correlator: 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_0006_01C19770.0508D200 Content-Type: multipart/alternative; boundary="----=_NextPart_001_0007_01C19770.050B4300" ------=_NextPart_001_0007_01C19770.050B4300 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Sign me up as well... ACI standards have always been a peeve of mine ;-) --James Benedict -----Original Message----- From: Matt Hirsch [mailto:owner-ietf-ldup@mail.imc.org]On Behalf Of = Matt Hirsch Sent: Monday, January 07, 2002 11:12 AM To: Timothy Hahn; ietf-ldup@imc.org Subject: RE: LDUP Engineering Group on Access Control Tim, I know for a fact that NSA is interested in participating in this = group if it exists or is going to exist. I am sure Sandy Roddy as well = as myself are interested in participating on behalf of NSA. Regards, -Matt H. A&N Associates Inc. Management & Technology Consulting 410-772-5060 ext 22 -----Original Message-----=20 From: Timothy Hahn=20 Sent: Mon 1/7/2002 9:28 AM=20 To: ietf-ldup@imc.org=20 Cc:=20 Subject: LDUP Engineering Group on Access Control Hello all,=20 The LDUP WG minutes remind us that an engineering group needs to be = established to come up with a proposal for creating some "minimum = interoperable access control" such that Secure replication can be = established across multiple independent implementations.=20 I don't recall a set of people assigned/volunteered for such a an = engineering group yet. Have they been? If so, can the group = re-identify itself to the list? If not, I'll volunteer to be one member = of the group - are there any other victims/volunteers?=20 Thanks in advance,=20 Tim Hahn Internet: hahnt@us.ibm.com Internal: Timothy Hahn/Endicott/IBM@IBMUS or IBMUSM00(HAHNT) phone: 607.752.6388 tie-line: 8/852.6388 fax: 607.752.3681 ------=_NextPart_001_0007_01C19770.050B4300 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable =EF=BB=BF
Sign=20 me up as well... ACI standards have always been a peeve of mine=20 ;-)
 
--James Benedict
-----Original Message-----
From: Matt Hirsch=20 [mailto:owner-ietf-ldup@mail.imc.org]On Behalf Of Matt=20 Hirsch
Sent: Monday, January 07, 2002 11:12 AM
To: = Timothy=20 Hahn; ietf-ldup@imc.org
Subject: RE: LDUP Engineering Group = on=20 Access Control

Tim,
 
I know for a fact that NSA is interested in participating in this = group=20 if it exists or is going to exist.  I am sure Sandy Roddy as well = as=20 myself are interested in participating on behalf of NSA.
Regards,
-Matt H.
A&N Associates Inc.
Management & Technology Consulting
410-772-5060 ext 22
-----Original Message-----
From: = Timothy Hahn=20
Sent: Mon 1/7/2002 9:28 AM
To: = ietf-ldup@imc.org=20
Cc:
Subject: LDUP Engineering Group on Access=20 Control


Hello=20 all,

The LDUP WG = minutes remind=20 us that an engineering group needs to be established to come up with = a=20 proposal for creating some "minimum interoperable access control" = such that=20 Secure replication can be established across multiple independent=20 implementations.

I = don't recall=20 a set of people assigned/volunteered for such a an engineering group = yet.=20  Have they been?  If so, can the group re-identify itself = to the=20 list?  If not, I'll volunteer to be one member of the group - = are there=20 any other victims/volunteers?

Thanks in advance,
Tim=20 Hahn

Internet: hahnt@us.ibm.com
Internal: Timothy=20 Hahn/Endicott/IBM@IBMUS or IBMUSM00(HAHNT)
phone: 607.752.6388 =  =20   tie-line: 8/852.6388
fax:=20 607.752.3681
------=_NextPart_001_0007_01C19770.050B4300-- ------=_NextPart_000_0006_01C19770.0508D200 Content-Type: application/ms-tnef; name="winmail.dat" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="winmail.dat" Content-Transfer-Encoding: base64 eJ8+IjMQAQaQCAAEAAAAAAABAAEAAQeQBgAIAAAA5AQAAAAAAADoAAEIgAcAGAAAAElQTS5NaWNy b3NvZnQgTWFpbC5Ob3RlADEIAQ2ABAACAAAAAgACAAEGgAMADgAAANIHAQAHAAsAJwAAAAEAFAEB A5AGAAAEAAAeAAAACwACAAEAAAALACMAAAAAAAMAJgAAAAAACwApAAAAAAADAC4AAAAAAAMANgAA AAAAHgBwAAEAAAApAAAATERVUCBFbmdpbmVlcmluZyBHcm91cCBvbiBBY2Nlc3MgQ29udHJvbAAA AAACAXEAAQAAACAAAAABwZeOcnFstVBVyTZG/J+XFyCDYcEGAAHPHAgAAQnlcAIBHQwBAAAAHQAA AFNNVFA6SkFNRVMuQkVORURJQ1RASE9NRS5DT00AAAAACwABDgAAAABAAAYOACrlzpmXwQECAQoO AQAAABgAAAAAAAAAkczAGTyi/0qWfDq4B/oXe8KAAAAeAEIQAQAAAD0AAAA8QThBMUQ2NTk0MUMz RDk0Qjg5NkFENjdEMTU0QzUzQUIwNjVENjZAc3N5bWV4Yy5hbmFzc29jLmNvbT4AAAAACwABgAgg BgAAAAAAwAAAAAAAAEYAAAAAA4UAAAAAAAADAAOACCAGAAAAAADAAAAAAAAARgAAAAAQhQAAAAAA AAMAB4AIIAYAAAAAAMAAAAAAAABGAAAAAFKFAAC2dAEAHgAJgAggBgAAAAAAwAAAAAAAAEYAAAAA VIUAAAEAAAAEAAAAOS4wAAsADYAIIAYAAAAAAMAAAAAAAABGAAAAAIKFAAABAAAAHgAOgAggBgAA AAAAwAAAAAAAAEYAAAAAg4UAAAEAAAATAAAANjg3MTIzOTE2LTA3MDEyMDAyAAALADqACCAGAAAA AADAAAAAAAAARgAAAAAOhQAAAAAAAAMAPIAIIAYAAAAAAMAAAAAAAABGAAAAABGFAAAAAAAAAwA9 gAggBgAAAAAAwAAAAAAAAEYAAAAAGIUAAAAAAAALAFKACCAGAAAAAADAAAAAAAAARgAAAAAGhQAA AAAAAAMAU4AIIAYAAAAAAMAAAAAAAABGAAAAAAGFAAAAAAAAAgH4DwEAAAAQAAAAkczAGTyi/0qW fDq4B/oXewIB+g8BAAAAEAAAAJHMwBk8ov9Klnw6uAf6F3sCAfsPAQAAAJ8AAAAAAAAAOKG7EAXl EBqhuwgAKypWwgAAUFNUUFJYLkRMTAAAAAAAAAAATklUQfm/uAEAqgA32W4AAABDOlxEb2N1bWVu dHMgYW5kIFNldHRpbmdzXEFkbWluaXN0cmF0b3JcTG9jYWwgU2V0dGluZ3NcQXBwbGljYXRpb24g RGF0YVxNaWNyb3NvZnRcT3V0bG9va1xvdXRsb29rLnBzdAAAAwD+DwUAAAADAA00/TcAAAIBfwAB AAAANwAAADxQUEVLSkdITUtMSEVNSE9EQ0xOSkVFSkZDQUFBLmphbWVzLmJlbmVkaWN0QGhvbWUu Y29tPgAAZMQ= ------=_NextPart_000_0006_01C19770.0508D200-- From owner-ietf-ldup@mail.imc.org Mon Jan 7 13:40:39 2002 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA23998 for ; Mon, 7 Jan 2002 13:40:38 -0500 (EST) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g07IO7W01847 for ietf-ldup-bks; Mon, 7 Jan 2002 10:24:07 -0800 (PST) Received: from out002pub.verizon.net (out002pub.verizon.net [206.46.170.102]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g07IO6301843 for ; Mon, 7 Jan 2002 10:24:06 -0800 (PST) Received: from D7ST2111 (pool-141-151-17-53.phil.east.verizon.net [141.151.17.53]) by out002pub.verizon.net with ESMTP for ; id g07INwd04415 Mon, 7 Jan 2002 12:23:58 -0600 (CST) Reply-To: From: "Chris Apple" To: Subject: RE: LDUP Engineering Group on Access Control Date: Mon, 7 Jan 2002 13:22:32 -0600 Message-ID: <002601c197b0$a7fa94e0$0200a8c0@D7ST2111> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_0027_01C1977E.5D6024E0" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.3416 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 In-reply-to: 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_0027_01C1977E.5D6024E0 Content-Type: multipart/alternative; boundary="----=_NextPart_001_0028_01C1977E.5D6024E0" ------=_NextPart_001_0028_01C1977E.5D6024E0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Thanks to Tim and Steven for pointing this out. The text for item 9 on the agenda was missing/cut-off somehow. Its included in place below. Chris Apple christopher.apple@verizon.net Meeting Minutes LDAP Duplication/Replication/Update Protocols WG (ldup) Thursday, December 13 at 1530-1730 =================================== CHAIRS: Chris Apple John Strassner 0) Agenda Bashing No changes were made to the agenda. 1) LDUP Update Reconciliation Procedures http://www.ietf.org/internet-drafts/draft-ietf-ldup-urp-05.txt A new version was issued several weeks prior to the WG Meeting. Specific changes to the document are listed at the end of the draft. Some editorial changes were made. Other changes to be made in a future document revision will include the addition of other reference documents. 2) LDAPv3 Replication Requirements http://www.ietf.org/internet-drafts/draft-ietf-ldup-replica-req-10.txt This document has passed WG Last Call. Comments recently posted to the list after the conclusion of the WG Last Call period will be handled as a part of IETF Last Call. Co-Chairs have an action item to follow up with the Applications Area ADs to find out when the document will be included in the IESG queue for consideration. 3) LDAP Replication Architecture http://www.ietf.org/internet-drafts/draft-ietf-ldup-model-06.txt A requirements coverage matrix has been posted to the WG mailing list. This posting indicates that the architecture model document lags other WG documents somewhat and needs to be revised. Some requirements are defined in the requirements document that the architecture document doesn't address. Requirements related to state-based systems are not covered. Log-based replication requirements are not adequately addressed. It was pointed out by Ed Reed that this requirements coverage matrix will also help to identify holes in information model document. 4) LDUP Replication Information Model http://www.ietf.org/internet-drafts/draft-ietf-ldup-infomod-04.txt A new revision was submitted shortly before the IETF meeting deadline. No comments on this document revision had been posted to the list as of the WG meeting date. Slides were presented covering the changes made to the document. These slides have been posted to the WG mailing list. 5) LDAP Subentry Schema http://www.ietf.org/internet-drafts/draft-ietf-ldup-subentry-08.txt Discussion via e-mail between the document editors and Kurt Zeilenga have led to WG consensus that the original proposal in this document should not be used. An individual alternative was published by Kurt Zeilenga. The document will be considered by the WG as a proposal on the list. The X.500 committee has agreed to consider changes to the X.500 subentry specification to foster compatibility between LDAP and X.500 provided that we publish rationale and requirements for their consideration. There was some discussion about adoption of the individual proposal from Kurt Zeilenga as a WG deliverable that would replace the existing WG deliverable. This discussion was deferred until such time as the next WG Charter revision proposal is posted to the WG mailing list. 6) The LDUP Replication Update Protocol http://www.ietf.org/internet-drafts/draft-ietf-ldup-protocol-03.txt A revision was submitted shortly before the IETF meeting deadline. Several changes were made since the -02 version. These changes are documented in slides that were posted to the WG mailing list. It is likely that this document will need to be revised at least once more prior to considering WG Last Call. 7) General Usage Profile for LDAPv3 Replication http://www.ietf.org/internet-drafts/draft-ietf-ldup-usage-profile-02.txt The document editors were unable to attend the WG meeting but submitted a slide to the Co-Chairs for presentation at the meeting. This slide was posted to the mailing list. It is likely that this document will need to be revised again after several other WG documents have been revised. 8) LDAP Client Update Protocol http://www.ietf.org/internet-drafts/draft-ietf-ldup-lcup-02.txt Based on mailing list discussion, this document is close to being ready for WG Last Call. The changes made to the document since the -01 revision are included in the document. There is one major issue that requires more mailing list discussion. The issue is whether or not a discovery mechanism enabling client/server implementations to determine what cookie schemes are supported may be overkill. There was some general agreement in the room that this might indeed be overkill and that it should be discussed on the WG mailing list. Once this issue is resolved by the WG, the document should be ready for WG Last Call. 9) Profile for Framing LDAPv3 Operations http://www.ietf.org/internet-drafts/draft-ietf-ldup-framing-profile-00.t xt There was discussion about the possibility of relaxing the framing constraints on LDAPv3 operations in the context of LDUP. Appropriate text from this document should be included in a revised grouping document. The Co-Chair requested that this topic be aired on the list a bit more as there were concerns about having a WG document subsumed by a non-WG document without adopting the subsequent document as a WG deliverable. This topic will be discussed further once a post-Salt Lake City WG charter proposal is posted to the list. 10) Mandatory LDAP Replica Management http://www.ietf.org/internet-drafts/draft-ietf-ldup-mrm-00.txt This document was published by the editors as a very rough draft. The Co-Chairs encouraged members of the WG to review this document with this in mind. Kurt Zeilenga asked if the word mandatory in the title carried its traditional weight as it does when included in requirements language in the body of a document. The general answer given by the Co-Chairs was "not quite" but agreed that the WG should consider an alternate title for the document to clear up confusion if it indeed shouldn't carry its traditional weight. 11) LDAPv3 Access Control - Options to Consider a) Adding it to LDUP? b) Forming a WG Solely to Address Access Control for LDAPv3? c) Handling the Access Control problem by (potentially competing) individual contributions? d) Do nothing and let the work go on outside of the IETF? e) Other options? Discussion about this topic indicates that it is generally accepted that LDUP will not have successfully concluded if it publishes deliverables which do not support and actively address interoperable, secure replication of information between LDAP servers. Room belief is that it belongs in a WG.The pending conclusion of the LDAPEXT WG prior to completion of the LDAP Access Control Model work creates an issue that the LDUP WG needs to resolve. When the questions above were posed to the WG members in attendance, they clearly expressed a belief that a general LDAP Access Control model should not become an LDUP deliverable. However, there was also a strong belief among those in attendance that such work does belong in a working group. After much discussion of possible paths to successful WG conclusion, it was proposed that concensus on an access control model applicable only within the context of LDUP specifications might be achieved by using X.500 basic or a profile thereof - or some even simpler proposal. An Engineering Team needs to be convened to draft a list of the minimally required factors needed in an access control model for LDUP. It was pointed out by Kurt Zeilenga that identity to authentication credential mapping will have to be addressed by any access control model for LDUP implementations to use it effectively. 12) Broader WG Charter Discussion The most recent WG Charter proposal posted to the WG mailing list will be revised to remove present wording related to LDUP adoption of the LDAPEXT Access Control Model work. This charter content and associated deliverables will be replaced with content consistent with the discussion that took place during the WG meeting. ------=_NextPart_001_0028_01C1977E.5D6024E0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Message
Thanks=20 to Tim and Steven for pointing this out. The text for item 9 on the=20 agenda
was=20 missing/cut-off somehow.
 
Its=20 included in place below.
 

Chris Apple

christopher.apple@verizon.n= et=20

Meeting = Minutes

LDAP = Duplication/Replication/Update=20 Protocols WG (ldup)

Thursday, December 13 at = 1530-1730=20
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

CHAIRS: Chris Apple = <christopher.apple@verizon.n= et>
 John=20 Strassner <john.strassner@intelliden.c= om>


0) Agenda = Bashing

No changes were made to = the=20 agenda.

1) LDUP Update = Reconciliation=20 Procedures

    = <= FONT=20 face=3DArial=20 size=3D2>http://www.ietf.org/internet-drafts/draft-ietf-ldup-urp-05.txt

A new version was issued = several weeks=20 prior to the WG Meeting.

Specific changes to the = document are=20 listed at the end of the draft.
Some editorial changes were made. = Other=20 changes to be made in a future
document revision will include the = addition of=20 other reference documents.


2) LDAPv3 Replication = Requirements

    = http://www.ietf.org/internet-drafts/draft-ietf-ldup-replica-req-= 10.txt

This document has passed = WG Last Call.=20 Comments recently posted to the list
after the conclusion of the WG = Last Call=20 period will be handled as a part
of IETF Last Call. Co-Chairs have an = action=20 item to follow up with the
Applications Area ADs to find out when the = document will be included in the
IESG queue for = consideration.

3) LDAP Replication=20 Architecture

    = http://www.ietf.org/internet-drafts/draft-ietf-ldup-model-06.txt=

A requirements coverage = matrix has been=20 posted to the WG mailing list.
This posting indicates that the = architecture=20 model document lags other
WG documents somewhat and needs to be = revised. Some=20 requirements are defined
in the requirements document that the = architecture=20 document doesn't address.
Requirements related to state-based systems = are not=20 covered. Log-based
replication requirements are not adequately=20 addressed.

It was pointed out by Ed = Reed that this=20 requirements coverage matrix
will also help to identify holes in = information=20 model document.

4) LDUP Replication = Information=20 Model

    = http://www.ietf.org/internet-drafts/draft-ietf-ldup-infomod-04.t= xt

A new revision was = submitted shortly=20 before the IETF meeting deadline.
No comments on this document = revision had=20 been posted to the list as of
the WG meeting date. Slides were = presented=20 covering the changes made to
the document. These slides have been = posted to=20 the WG mailing list.

5) LDAP Subentry = Schema

    = http://www.ietf.org/internet-drafts/draft-ietf-ldup-subentry-08.= txt

Discussion via e-mail = between the=20 document editors and Kurt Zeilenga have led to
WG consensus that the = original=20 proposal in this document should not be used. An
individual = alternative was=20 published by Kurt Zeilenga. The document will be
considered by the WG = as a=20 proposal on the list. The X.500 committee has agreed
to consider = changes to=20 the X.500 subentry specification to foster compatibility
between LDAP = and=20 X.500 provided that we publish rationale and requirements for
their=20 consideration. There was some discussion about adoption of the=20 individual
proposal from Kurt Zeilenga as a WG deliverable that would = replace=20 the existing
WG deliverable. This discussion was deferred until such = time as=20 the next WG Charter
revision proposal is posted to the WG mailing=20 list.

6) The LDUP Replication = Update=20 Protocol

    = http://www.ietf.org/internet-drafts/draft-ietf-ldup-protocol-03.= txt

A revision was submitted = shortly before=20 the IETF meeting deadline. Several
changes were made since the -02 = version.=20 These changes are documented in slides
that were posted to the WG = mailing=20 list. It is likely that this document will
need to be revised at = least once=20 more prior to considering WG Last Call.

7) General Usage Profile = for LDAPv3=20 Replication

    = http://www.ietf.org/internet-drafts/draft-ietf-ldup-usage-profil= e-02.txt

The document editors were = unable to=20 attend the WG meeting but submitted a
slide to the Co-Chairs for = presentation=20 at the meeting. This slide was posted
to the mailing list. It is = likely that=20 this document will need to be revised
again after several other WG = documents=20 have been revised.

8) LDAP Client Update=20 Protocol

    = = http://www.ietf.org/internet-drafts/draft-ietf-ldup-lcup-02.txt<= /FONT>

Based on mailing list = discussion, this=20 document is close to being ready for WG Last Call.
The changes made = to the=20 document since the -01 revision are included in the document.
There = is one=20 major issue that requires more mailing list discussion. The issue = is
whether=20 or not a discovery mechanism enabling client/server implementations=20 to
determine what cookie schemes are supported may be overkill. There = was=20 some general
agreement in the room that this might indeed be overkill = and=20 that it should be discussed
on the WG mailing list. Once this issue = is=20 resolved by the WG, the document should be
ready for WG Last = Call.

9) Profile for Framing = LDAPv3=20 Operations

    = http://www.ietf.org/internet-drafts/draft-ietf-ldup-framing-prof= ile-00.txt

There was discussion = about the=20 possibility of relaxing the framing constraints
on LDAPv3 operations = in the=20 context of LDUP. Appropriate text from this document
should be = included in a=20 revised grouping document. The Co-Chair requested
that this topic be = aired on=20 the list a bit more as there were concerns
about having a WG document = subsumed by a non-WG = document without=20 adopting the
subsequent document as a WG deliverable. This topic will = be=20 discussed further
once a post-Salt Lake City WG charter proposal is = posted to=20 the list.

10) Mandatory LDAP = Replica=20 Management

     =20 <= FONT=20 face=3DArial=20 size=3D2>http://www.ietf.org/internet-drafts/draft-ietf-ldup-mrm-00.txt

This document was = published by the=20 editors as a very rough draft. The Co-Chairs
encouraged members of = the WG to=20 review this document with this in mind.

Kurt Zeilenga asked if = the word=20 mandatory in the title carried its traditional
weight as it does when = included in requirements language in the body of a document.
The = general=20 answer given by the Co-Chairs was "not quite" but agreed that the
WG = should=20 consider an alternate title for the document to clear up confusion = if
it=20 indeed shouldn't carry its traditional weight.

11) LDAPv3 Access Control = - Options to=20 Consider

 a) Adding it to = LDUP?
 b)=20 Forming a WG Solely to Address Access Control for LDAPv3?
 c) = Handling=20 the Access Control problem by (potentially=20 competing)
          = ;=20 individual contributions?
        = d) Do=20 nothing and let the work go on outside of the IETF?
 e) Other=20 options?

Discussion about this = topic indicates=20 that it is generally accepted that LDUP will not have

successfully concluded if = it publishes=20 deliverables which do not support and actively address

interoperable, secure = replication of=20 information between LDAP servers. Room belief is that it

belongs in a WG.The = pending conclusion=20 of the LDAPEXT WG prior to completion of the LDAP Access

Control Model work = creates an issue=20 that the LDUP WG needs to resolve. When the questions above

were posed to the WG = members in=20 attendance, they clearly expressed a belief that a general LDAP =

Access Control model = should not become=20 an LDUP deliverable. However, there was also a strong

belief among those in = attendance that=20 such work does belong in a working group.

After much discussion of = possible paths=20 to successful WG conclusion, it was proposed that

concensus on an access = control model=20 applicable only within the context of LDUP
specifications might be = achieved=20 by using X.500 basic or a profile thereof - or some
even simpler=20 proposal.

An Engineering Team needs = to be=20 convened to draft a list of the minimally required factors

needed in an access = control model for=20 LDUP.

It was pointed out by = Kurt Zeilenga=20 that identity to authentication credential mapping will

have to be addressed by = any access=20 control model for LDUP implementations to use it

effectively.

12) Broader WG Charter=20 Discussion

The most recent WG = Charter proposal=20 posted to the WG mailing list will be revised to
remove present = wording=20 related to LDUP adoption of the LDAPEXT Access Control Model = work.
This=20 charter content and associated deliverables will be replaced with = content=20 consistent
with the discussion that took place during the WG=20 meeting.

 

------=_NextPart_001_0028_01C1977E.5D6024E0-- ------=_NextPart_000_0027_01C1977E.5D6024E0 Content-Type: text/x-vcard; name="Chris Apple (christopher.apple@verizon.net).vcf" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="Chris Apple (christopher.apple@verizon.net).vcf" Content-Transfer-Encoding: quoted-printable BEGIN:VCARD VERSION:2.1 N:Apple;Christopher FN:Chris Apple (christopher.apple@verizon.net) TEL;HOME;VOICE:(215) 873-0850 TEL;CELL;VOICE:(610) 585-4241 ADR;WORK:;;214 New Street, Apt 4-N;Philadelphia;PA;19106;United States = of America LABEL;WORK;ENCODING=3DQUOTED-PRINTABLE:214 New Street, Apt = 4-N=3D0D=3D0APhiladelphia, PA 19106=3D0D=3D0AUnited States of Am=3D erica EMAIL;PREF;INTERNET:christopher.apple@verizon.net REV:20011217T233830Z END:VCARD ------=_NextPart_000_0027_01C1977E.5D6024E0-- From owner-ietf-ldup@mail.imc.org Mon Jan 7 14:34:33 2002 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA25695 for ; Mon, 7 Jan 2002 14:34:32 -0500 (EST) Received: by above.proper.com (8.11.6/8.11.3) id g07JHwN03077 for ietf-ldup-bks; Mon, 7 Jan 2002 11:17:58 -0800 (PST) Received: from e1.ny.us.ibm.com (e1.ny.us.ibm.com [32.97.182.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g07JHv303073 for ; Mon, 7 Jan 2002 11:17:57 -0800 (PST) Received: from northrelay01.pok.ibm.com (northrelay01.pok.ibm.com [9.117.200.21]) by e1.ny.us.ibm.com (8.9.3/8.9.3) with ESMTP id OAA223592 for ; Mon, 7 Jan 2002 14:14:35 -0500 Received: from d01mlc96.pok.ibm.com (d01mlc96.pok.ibm.com [9.117.250.33]) by northrelay01.pok.ibm.com (8.11.1m3/NCO v5.01) with ESMTP id g07JHSW136144 for ; Mon, 7 Jan 2002 14:17:28 -0500 To: ietf-ldup@imc.org MIME-Version: 1.0 Subject: RE: LDUP Engineering Group on Access Control X-Mailer: Lotus Notes Release 5.0.7 March 21, 2001 From: "Timothy Hahn" Message-ID: Date: Mon, 7 Jan 2002 14:17:24 -0500 X-MIMETrack: Serialize by Router on D01MLC96/01/M/IBM(Release 5.0.9 |November 26, 2001) at 01/07/2002 02:17:29 PM, Serialize complete at 01/07/2002 02:17:29 PM Content-Type: multipart/alternative; boundary="=_alternative 0068DC7E85256B3A_=" Sender: owner-ietf-ldup@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multipart message in MIME format. --=_alternative 0068DC7E85256B3A_= Content-Type: text/plain; charset="us-ascii" Chriss, The minutes now look OK to me. Regards, Tim Hahn Internet: hahnt@us.ibm.com Internal: Timothy Hahn/Endicott/IBM@IBMUS or IBMUSM00(HAHNT) phone: 607.752.6388 tie-line: 8/852.6388 fax: 607.752.3681 --=_alternative 0068DC7E85256B3A_= Content-Type: text/html; charset="us-ascii"
Chriss,

The minutes now look OK to me.
Regards,
Tim Hahn

Internet: hahnt@us.ibm.com
Internal: Timothy Hahn/Endicott/IBM@IBMUS or IBMUSM00(HAHNT)
phone: 607.752.6388     tie-line: 8/852.6388
fax: 607.752.3681
 --=_alternative 0068DC7E85256B3A_=-- From owner-ietf-ldup@mail.imc.org Mon Jan 7 15:57:03 2002 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA27828 for ; Mon, 7 Jan 2002 15:57:02 -0500 (EST) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g07KeAN05585 for ietf-ldup-bks; Mon, 7 Jan 2002 12:40:10 -0800 (PST) Received: from out004pub.verizon.net (out004pub.verizon.net [206.46.170.104]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g07Ke4305581 for ; Mon, 7 Jan 2002 12:40:04 -0800 (PST) Received: from D7ST2111 (pool-141-151-17-53.phil.east.verizon.net [141.151.17.53]) by out004pub.verizon.net with ESMTP for ; id g07KdtC16329 Mon, 7 Jan 2002 14:39:55 -0600 (CST) Reply-To: From: "Chris Apple" To: Subject: Revised meeting minutes Date: Mon, 7 Jan 2002 15:38:26 -0600 Message-ID: <003c01c197c3$a4570db0$0200a8c0@D7ST2111> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_003D_01C19791.59BC9DB0" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.3416 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 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_003D_01C19791.59BC9DB0 Content-Type: multipart/alternative; boundary="----=_NextPart_001_003E_01C19791.59BC9DB0" ------=_NextPart_001_003E_01C19791.59BC9DB0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Somehow, the subject line was mixed up before.... Chris Apple christopher.apple@verizon.net -----Original Message----- From: owner-ietf-ldup@mail.imc.org [mailto:owner-ietf-ldup@mail.imc.org] On Behalf Of Chris Apple Sent: Monday, January 07, 2002 1:23 PM To: ietf-ldup@imc.org Subject: RE: LDUP Engineering Group on Access Control Thanks to Tim and Steven for pointing this out. The text for item 9 on the agenda was missing/cut-off somehow. Its included in place below. Chris Apple christopher.apple@verizon.net Meeting Minutes LDAP Duplication/Replication/Update Protocols WG (ldup) Thursday, December 13 at 1530-1730 =================================== CHAIRS: Chris Apple John Strassner 0) Agenda Bashing No changes were made to the agenda. 1) LDUP Update Reconciliation Procedures http://www.ietf.org/internet-drafts/draft-ietf-ldup-urp-05.txt A new version was issued several weeks prior to the WG Meeting. Specific changes to the document are listed at the end of the draft. Some editorial changes were made. Other changes to be made in a future document revision will include the addition of other reference documents. 2) LDAPv3 Replication Requirements http://www.ietf.org/internet-drafts/draft-ietf-ldup-replica-req-10.txt This document has passed WG Last Call. Comments recently posted to the list after the conclusion of the WG Last Call period will be handled as a part of IETF Last Call. Co-Chairs have an action item to follow up with the Applications Area ADs to find out when the document will be included in the IESG queue for consideration. 3) LDAP Replication Architecture http://www.ietf.org/internet-drafts/draft-ietf-ldup-model-06.txt A requirements coverage matrix has been posted to the WG mailing list. This posting indicates that the architecture model document lags other WG documents somewhat and needs to be revised. Some requirements are defined in the requirements document that the architecture document doesn't address. Requirements related to state-based systems are not covered. Log-based replication requirements are not adequately addressed. It was pointed out by Ed Reed that this requirements coverage matrix will also help to identify holes in information model document. 4) LDUP Replication Information Model http://www.ietf.org/internet-drafts/draft-ietf-ldup-infomod-04.txt A new revision was submitted shortly before the IETF meeting deadline. No comments on this document revision had been posted to the list as of the WG meeting date. Slides were presented covering the changes made to the document. These slides have been posted to the WG mailing list. 5) LDAP Subentry Schema http://www.ietf.org/internet-drafts/draft-ietf-ldup-subentry-08.txt Discussion via e-mail between the document editors and Kurt Zeilenga have led to WG consensus that the original proposal in this document should not be used. An individual alternative was published by Kurt Zeilenga. The document will be considered by the WG as a proposal on the list. The X.500 committee has agreed to consider changes to the X.500 subentry specification to foster compatibility between LDAP and X.500 provided that we publish rationale and requirements for their consideration. There was some discussion about adoption of the individual proposal from Kurt Zeilenga as a WG deliverable that would replace the existing WG deliverable. This discussion was deferred until such time as the next WG Charter revision proposal is posted to the WG mailing list. 6) The LDUP Replication Update Protocol http://www.ietf.org/internet-drafts/draft-ietf-ldup-protocol-03.txt A revision was submitted shortly before the IETF meeting deadline. Several changes were made since the -02 version. These changes are documented in slides that were posted to the WG mailing list. It is likely that this document will need to be revised at least once more prior to considering WG Last Call. 7) General Usage Profile for LDAPv3 Replication http://www.ietf.org/internet-drafts/draft-ietf-ldup-usage-profile-02.txt The document editors were unable to attend the WG meeting but submitted a slide to the Co-Chairs for presentation at the meeting. This slide was posted to the mailing list. It is likely that this document will need to be revised again after several other WG documents have been revised. 8) LDAP Client Update Protocol http://www.ietf.org/internet-drafts/draft-ietf-ldup-lcup-02.txt Based on mailing list discussion, this document is close to being ready for WG Last Call. The changes made to the document since the -01 revision are included in the document. There is one major issue that requires more mailing list discussion. The issue is whether or not a discovery mechanism enabling client/server implementations to determine what cookie schemes are supported may be overkill. There was some general agreement in the room that this might indeed be overkill and that it should be discussed on the WG mailing list. Once this issue is resolved by the WG, the document should be ready for WG Last Call. 9) Profile for Framing LDAPv3 Operations http://www.ietf.org/internet-drafts/draft-ietf-ldup-framing-profile-00.t xt There was discussion about the possibility of relaxing the framing constraints on LDAPv3 operations in the context of LDUP. Appropriate text from this document should be included in a revised grouping document. The Co-Chair requested that this topic be aired on the list a bit more as there were concerns about having a WG document subsumed by a non-WG document without adopting the subsequent document as a WG deliverable. This topic will be discussed further once a post-Salt Lake City WG charter proposal is posted to the list. 10) Mandatory LDAP Replica Management http://www.ietf.org/internet-drafts/draft-ietf-ldup-mrm-00.txt This document was published by the editors as a very rough draft. The Co-Chairs encouraged members of the WG to review this document with this in mind. Kurt Zeilenga asked if the word mandatory in the title carried its traditional weight as it does when included in requirements language in the body of a document. The general answer given by the Co-Chairs was "not quite" but agreed that the WG should consider an alternate title for the document to clear up confusion if it indeed shouldn't carry its traditional weight. 11) LDAPv3 Access Control - Options to Consider a) Adding it to LDUP? b) Forming a WG Solely to Address Access Control for LDAPv3? c) Handling the Access Control problem by (potentially competing) individual contributions? d) Do nothing and let the work go on outside of the IETF? e) Other options? Discussion about this topic indicates that it is generally accepted that LDUP will not have successfully concluded if it publishes deliverables which do not support and actively address interoperable, secure replication of information between LDAP servers. Room belief is that it belongs in a WG.The pending conclusion of the LDAPEXT WG prior to completion of the LDAP Access Control Model work creates an issue that the LDUP WG needs to resolve. When the questions above were posed to the WG members in attendance, they clearly expressed a belief that a general LDAP Access Control model should not become an LDUP deliverable. However, there was also a strong belief among those in attendance that such work does belong in a working group. After much discussion of possible paths to successful WG conclusion, it was proposed that concensus on an access control model applicable only within the context of LDUP specifications might be achieved by using X.500 basic or a profile thereof - or some even simpler proposal. An Engineering Team needs to be convened to draft a list of the minimally required factors needed in an access control model for LDUP. It was pointed out by Kurt Zeilenga that identity to authentication credential mapping will have to be addressed by any access control model for LDUP implementations to use it effectively. 12) Broader WG Charter Discussion The most recent WG Charter proposal posted to the WG mailing list will be revised to remove present wording related to LDUP adoption of the LDAPEXT Access Control Model work. This charter content and associated deliverables will be replaced with content consistent with the discussion that took place during the WG meeting. ------=_NextPart_001_003E_01C19791.59BC9DB0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Message
Somehow, the subject line was mixed up=20 before....
 
 

Chris = Apple

christopher.apple@verizon.net

-----Original Message-----
From: = owner-ietf-ldup@mail.imc.org=20 [mailto:owner-ietf-ldup@mail.imc.org] On Behalf Of Chris=20 Apple
Sent: Monday, January 07, 2002 1:23 PM
To:=20 ietf-ldup@imc.org
Subject: RE: LDUP Engineering Group on = Access=20 Control

Thanks=20 to Tim and Steven for pointing this out. The text for item 9 on the=20 agenda
was=20 missing/cut-off somehow.
 
Its=20 included in place below.
 

Chris Apple

christopher.apple@verizon.n= et=20

Meeting = Minutes

LDAP = Duplication/Replication/Update=20 Protocols WG (ldup)

Thursday, December 13 at = 1530-1730=20
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

CHAIRS: Chris Apple = <christopher.apple@verizon.n= et>
 John=20 Strassner <john.strassner@intelliden.c= om>


0) Agenda = Bashing

No changes were made to = the=20 agenda.

1) LDUP Update = Reconciliation=20 Procedures

    = <= FONT=20 face=3DArial=20 size=3D2>http://www.ietf.org/internet-drafts/draft-ietf-ldup-urp-05.txt

A new version was issued = several weeks=20 prior to the WG Meeting.

Specific changes to the = document are=20 listed at the end of the draft.
Some editorial changes were made. = Other=20 changes to be made in a future
document revision will include the = addition of=20 other reference documents.


2) LDAPv3 Replication = Requirements

    = http://www.ietf.org/internet-drafts/draft-ietf-ldup-replica-req-= 10.txt

This document has passed = WG Last Call.=20 Comments recently posted to the list
after the conclusion of the WG = Last Call=20 period will be handled as a part
of IETF Last Call. Co-Chairs have an = action=20 item to follow up with the
Applications Area ADs to find out when the = document will be included in the
IESG queue for = consideration.

3) LDAP Replication=20 Architecture

    = http://www.ietf.org/internet-drafts/draft-ietf-ldup-model-06.txt=

A requirements coverage = matrix has been=20 posted to the WG mailing list.
This posting indicates that the = architecture=20 model document lags other
WG documents somewhat and needs to be = revised. Some=20 requirements are defined
in the requirements document that the = architecture=20 document doesn't address.
Requirements related to state-based systems = are not=20 covered. Log-based
replication requirements are not adequately=20 addressed.

It was pointed out by Ed = Reed that this=20 requirements coverage matrix
will also help to identify holes in = information=20 model document.

4) LDUP Replication = Information=20 Model

    = http://www.ietf.org/internet-drafts/draft-ietf-ldup-infomod-04.t= xt

A new revision was = submitted shortly=20 before the IETF meeting deadline.
No comments on this document = revision had=20 been posted to the list as of
the WG meeting date. Slides were = presented=20 covering the changes made to
the document. These slides have been = posted to=20 the WG mailing list.

5) LDAP Subentry = Schema

    = http://www.ietf.org/internet-drafts/draft-ietf-ldup-subentry-08.= txt

Discussion via e-mail = between the=20 document editors and Kurt Zeilenga have led to
WG consensus that the = original=20 proposal in this document should not be used. An
individual = alternative was=20 published by Kurt Zeilenga. The document will be
considered by the WG = as a=20 proposal on the list. The X.500 committee has agreed
to consider = changes to=20 the X.500 subentry specification to foster compatibility
between LDAP = and=20 X.500 provided that we publish rationale and requirements for
their=20 consideration. There was some discussion about adoption of the=20 individual
proposal from Kurt Zeilenga as a WG deliverable that would = replace=20 the existing
WG deliverable. This discussion was deferred until such = time as=20 the next WG Charter
revision proposal is posted to the WG mailing=20 list.

6) The LDUP Replication = Update=20 Protocol

    = http://www.ietf.org/internet-drafts/draft-ietf-ldup-protocol-03.= txt

A revision was submitted = shortly before=20 the IETF meeting deadline. Several
changes were made since the -02 = version.=20 These changes are documented in slides
that were posted to the WG = mailing=20 list. It is likely that this document will
need to be revised at = least once=20 more prior to considering WG Last Call.

7) General Usage Profile = for LDAPv3=20 Replication

    = http://www.ietf.org/internet-drafts/draft-ietf-ldup-usage-profil= e-02.txt

The document editors were = unable to=20 attend the WG meeting but submitted a
slide to the Co-Chairs for = presentation=20 at the meeting. This slide was posted
to the mailing list. It is = likely that=20 this document will need to be revised
again after several other WG = documents=20 have been revised.

8) LDAP Client Update=20 Protocol

    = = http://www.ietf.org/internet-drafts/draft-ietf-ldup-lcup-02.txt<= /FONT>

Based on mailing list = discussion, this=20 document is close to being ready for WG Last Call.
The changes made = to the=20 document since the -01 revision are included in the document.
There = is one=20 major issue that requires more mailing list discussion. The issue = is
whether=20 or not a discovery mechanism enabling client/server implementations=20 to
determine what cookie schemes are supported may be overkill. There = was=20 some general
agreement in the room that this might indeed be overkill = and=20 that it should be discussed
on the WG mailing list. Once this issue = is=20 resolved by the WG, the document should be
ready for WG Last = Call.

9) Profile for Framing = LDAPv3=20 Operations

    = http://www.ietf.org/internet-drafts/draft-ietf-ldup-framing-prof= ile-00.txt

There was discussion = about the=20 possibility of relaxing the framing constraints
on LDAPv3 operations = in the=20 context of LDUP. Appropriate text from this document
should be = included in a=20 revised grouping document. The Co-Chair requested
that this topic be = aired on=20 the list a bit more as there were concerns
about having a WG document = subsumed by a non-WG = document without=20 adopting the
subsequent document as a WG deliverable. This topic will = be=20 discussed further
once a post-Salt Lake City WG charter proposal is = posted to=20 the list.

10) Mandatory LDAP = Replica=20 Management

     =20 <= FONT=20 face=3DArial=20 size=3D2>http://www.ietf.org/internet-drafts/draft-ietf-ldup-mrm-00.txt

This document was = published by the=20 editors as a very rough draft. The Co-Chairs
encouraged members of = the WG to=20 review this document with this in mind.

Kurt Zeilenga asked if = the word=20 mandatory in the title carried its traditional
weight as it does when = included in requirements language in the body of a document.
The = general=20 answer given by the Co-Chairs was "not quite" but agreed that the
WG = should=20 consider an alternate title for the document to clear up confusion = if
it=20 indeed shouldn't carry its traditional weight.

11) LDAPv3 Access Control = - Options to=20 Consider

 a) Adding it to = LDUP?
 b)=20 Forming a WG Solely to Address Access Control for LDAPv3?
 c) = Handling=20 the Access Control problem by (potentially=20 competing)
          = ;=20 individual contributions?
        = d) Do=20 nothing and let the work go on outside of the IETF?
 e) Other=20 options?

Discussion about this = topic indicates=20 that it is generally accepted that LDUP will not have

successfully concluded if = it publishes=20 deliverables which do not support and actively address

interoperable, secure = replication of=20 information between LDAP servers. Room belief is that it

belongs in a WG.The = pending conclusion=20 of the LDAPEXT WG prior to completion of the LDAP Access

Control Model work = creates an issue=20 that the LDUP WG needs to resolve. When the questions above

were posed to the WG = members in=20 attendance, they clearly expressed a belief that a general LDAP =

Access Control model = should not become=20 an LDUP deliverable. However, there was also a strong

belief among those in = attendance that=20 such work does belong in a working group.

After much discussion of = possible paths=20 to successful WG conclusion, it was proposed that

concensus on an access = control model=20 applicable only within the context of LDUP
specifications might be = achieved=20 by using X.500 basic or a profile thereof - or some
even simpler=20 proposal.

An Engineering Team needs = to be=20 convened to draft a list of the minimally required factors

needed in an access = control model for=20 LDUP.

It was pointed out by = Kurt Zeilenga=20 that identity to authentication credential mapping will

have to be addressed by = any access=20 control model for LDUP implementations to use it

effectively.

12) Broader WG Charter=20 Discussion

The most recent WG = Charter proposal=20 posted to the WG mailing list will be revised to
remove present = wording=20 related to LDUP adoption of the LDAPEXT Access Control Model = work.
This=20 charter content and associated deliverables will be replaced with = content=20 consistent
with the discussion that took place during the WG=20 meeting.

 

------=_NextPart_001_003E_01C19791.59BC9DB0-- ------=_NextPart_000_003D_01C19791.59BC9DB0 Content-Type: text/x-vcard; name="Chris Apple (christopher.apple@verizon.net).vcf" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="Chris Apple (christopher.apple@verizon.net).vcf" Content-Transfer-Encoding: quoted-printable BEGIN:VCARD VERSION:2.1 N:Apple;Christopher FN:Chris Apple (christopher.apple@verizon.net) TEL;HOME;VOICE:(215) 873-0850 TEL;CELL;VOICE:(610) 585-4241 ADR;WORK:;;214 New Street, Apt 4-N;Philadelphia;PA;19106;United States = of America LABEL;WORK;ENCODING=3DQUOTED-PRINTABLE:214 New Street, Apt = 4-N=3D0D=3D0APhiladelphia, PA 19106=3D0D=3D0AUnited States of Am=3D erica EMAIL;PREF;INTERNET:christopher.apple@verizon.net REV:20011217T233830Z END:VCARD ------=_NextPart_000_003D_01C19791.59BC9DB0-- From subs-reminder@imc.org Mon Jan 7 19:27:03 2002 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA01695 for ; Mon, 7 Jan 2002 19:27:02 -0500 (EST) From: subs-reminder@imc.org Received: by above.proper.com (8.11.6/8.11.3) id g080R0J22120; Mon, 7 Jan 2002 16:27:00 -0800 (PST) Date: Mon, 7 Jan 2002 16:27:00 -0800 (PST) Message-Id: <200201080027.g080R0J22120@above.proper.com> To: ldup-archive@ietf.org Subject: [[471168459]] Subscription to ietf-ldup for ldup-archive@lists.ietf.org Greetings. This message is a periodic reminder that ldup-archive@lists.ietf.org is subscribed to the ietf-ldup mailing list. There are two purposes for this message: - If this message is bounced by your mail server, I can remove you from the mailing list and reduce waste of bandwidth and resources. (If you are reading this message, it clearly didn't get bounced!) - Some people stay subscribed to mailing lists even though they do not want to because they do not know how to unsubscribe. If you want to stay subscribed to the ietf-ldup mailing list, you do not need to do anything. On the other hand, if you want to unsubscribe from this list, go to the following link: You can also unsubscribe by email. To do so, you can respond to this message and I will unsubscribe you by hand in the next few days. Alternatively, you can send a plain-text message to: ietf-ldup-request@imc.org with the single word unsubscribe in the body of the message. This last method assumes that the "From:" address in your mail is "ldup-archive@lists.ietf.org". If you have any questions, feel free to contact me. --Paul Hoffman, list administrator From subs-reminder@imc.org Mon Jan 7 19:28:41 2002 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA01719 for ; Mon, 7 Jan 2002 19:28:41 -0500 (EST) From: subs-reminder@imc.org Received: by above.proper.com (8.11.6/8.11.3) id g080SdP22620; Mon, 7 Jan 2002 16:28:39 -0800 (PST) Date: Mon, 7 Jan 2002 16:28:39 -0800 (PST) Message-Id: <200201080028.g080SdP22620@above.proper.com> To: ldup-archive@ietf.org Subject: [[723712766]] Subscription to ietf-ldup for ldup-archive@lists.ietf.org Greetings. This message is a periodic reminder that ldup-archive@lists.ietf.org is subscribed to the ietf-ldup mailing list. There are two purposes for this message: - If this message is bounced by your mail server, I can remove you from the mailing list and reduce waste of bandwidth and resources. (If you are reading this message, it clearly didn't get bounced!) - Some people stay subscribed to mailing lists even though they do not want to because they do not know how to unsubscribe. If you want to stay subscribed to the ietf-ldup mailing list, you do not need to do anything. On the other hand, if you want to unsubscribe from this list, go to the following link: You can also unsubscribe by email. To do so, you can respond to this message and I will unsubscribe you by hand in the next few days. Alternatively, you can send a plain-text message to: ietf-ldup-request@imc.org with the single word unsubscribe in the body of the message. This last method assumes that the "From:" address in your mail is "ldup-archive@lists.ietf.org". If you have any questions, feel free to contact me. --Paul Hoffman, list administrator From owner-ietf-ldup@mail.imc.org Tue Jan 8 17:40:47 2002 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA12650 for ; Tue, 8 Jan 2002 17:40:46 -0500 (EST) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g08MMkU21510 for ietf-ldup-bks; Tue, 8 Jan 2002 14:22:46 -0800 (PST) Received: from nexus.adacel.com (shelob.adacel.com.au [203.36.26.146] (may be forged)) by above.proper.com (8.11.6/8.11.3) with SMTP id g08MMh321506 for ; Tue, 8 Jan 2002 14:22:43 -0800 (PST) Received: (qmail 2828 invoked from network); 8 Jan 2002 22:14:24 -0000 Received: from unknown (HELO osmium) (10.32.24.165) by nexus.adacel.com with SMTP; 8 Jan 2002 22:14:24 -0000 Reply-To: From: "Steven Legg" To: "'John McMeeking'" Cc: Subject: RE: Supporting Partial Replication Date: Wed, 9 Jan 2002 09:22:11 +1100 Message-ID: <005701c19892$eb195e40$a518200a@osmium.mtwav.adacel.com.au> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook 8.5, Build 4.71.2377.0 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V4.72.2120.0 In-Reply-To: Sender: owner-ietf-ldup@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit John, John McMeeking wrote: > > Updated to add some thoughts on overlapping replication contexts... > > John McMeeking > > > Before I go on vacation too... > > We seem to be operating on different understandings of LDUP with respect to > areas of replication, replication contexts, and update vectors. > > You mention a "fourth option", being to maintain "an update vector per > replication area in a replication context and use the cascade rule to > maintain the update vectors." As I understand LDUP: an area of replication > and a replication context are the same thing, with replication context being > the current LDUP terminology. The replication architecture document doesn't define what an area of replication (or replication area is). The requirements document does define "area of replication" as the unit of data to be replicated, and allows these areas to overlap or be nested. Replication contexts are necessarily non-overlapping, so to my mind a replication context cannot be the same thing as an area of replication. I have assumed an area of replication (or replication area) can be the whole of a replication context or a sparse and/or fractional portion of a replication context. > They identify an area of the DIT that is > replicated -- a replication context has a single root entry and is bounded > by subordinate replication contexts (ldup-model 3.5 - Terms and Definitions). > LDUP already defines a separate update vector per replication context (per > replica). On the surface at least, your "fourth option" appears to be LDUP > as currently defined. > > For a server to participate in a cycle (which ldup-replica-req now refers to > as a "replica group" precisely because of the misunderstanding I had about > your use of cyle), the server must hold a copy of the replication context. We still appear to be on different wavelengths. By inspecting the replication agreements between servers in a replica group for a specific replication context, one can construct an undirected graph to represent the replication topology, where the vertices are servers and the arcs are replication agreements. The cycles I'm talking about are cycles in that graph. The replication topology for a particular replica group and replication context may have zero, one or more cycles. The update vector propagation mechanism fails if the replication agreements corresponding to arcs making a cycle in the replication topology are not all replicating the same information (the same area of replication, by my interpretation). Or, to put it another way, updates are correctly propagated only if none of the replication agreements corresponding to arcs making a cycle in the replication topology are sparse or fractional, or if they all use exactly the same sparse or fractional specification. Many interesting and useful replication topologies that I can support in X.500 replication don't meet these criteria. > And just to make sure my assumptions about what this means are clear: > - a replica group is defined in the context of a replication context. It is > the servers that hold instances of a particular area of replication. A server > may be part of several replica-groups. > - replication agreements are defined in the context of a replication context. > > In your example, with three servers and two replication contexts, agreements > between all the servers implies that there are two sets of agreements > between each server -- a set for each replication context. The existance of > a replication agreement in one replication context does not imply a > corresponding agreement in other replication contexts. In my example there are three servers and one replication context. There are two areas of replication within that replication context but these are not explicitly represented (I think we would be better off if they were) within the current LDUP model. They are implicit in the replication agreements. S1 has a replication agreement to replicate the whole of the replication context to S2, and vice versa. I have described the information within the scope of these two replication agreements as the replication area R1. Assume that S1 has a fractional replication agreement to replicate only some of the attributes to S3 and that S3 has an agreement to replicate the same set of attributes to S1. S2 has an equivalent arrangement with S3. Therefore S3 holds a fractional replica of the replication context. I have described the information in that fractional replica as the replication area R2. R2 is a subset (but not a subtree) of the information in R1. > > I'm going to go out on a limb, and guess that part of our misunderstandings > has to do with "overlapping" replication contexts -- you mentioned > replicating ACL via sparse or fractional replication, while having a full > replica of some subtree). This may be required by ldup-replica-req > (mentioned in terminology, but not in specific requirements), but is > currently listed as a non-objective of ldup-model (section 3.3e). Would it > be fair to state that you think ldup-model (and friends) needs to address > overlapping replication contexts? To be at least as capable as X.500 at single master replication LDUP needs to deal with overlapping replicated portions of the DIT. Replication contexts, as a generalization of naming contexts in a multi-master environment, are fine as they are. I prefer to think of servers replicating portions of disjoint replication contexts (by analogy with X.500 where servers replicate portions of disjoint naming contexts) but it is these portions (i.e. areas of replication) that potentially overlap. > My responses have been in the context of > what ldup-model claims to support, and in that context I seem to be having > a problem understanding your concerns and properly communicating my > understanding. And I find that what the LDUP model currently supports is inadequate so I'm looking at solutions for improving on it. > After thinking about overlapping replication contexts a bit more, IF we are > going to tackle it, I think we need to address the following: > 1. How do we define the bounds of a replication context that is not bounded > by nested replication contexts? Kurt Zielenga's ldap-subentry draft would > be useful here (subtree specification). It is easier to leave the replication contexts as they are and assume that replication areas are what we are replicating and that they are bounded by the replication context within which they are contained. X.500 uses SubtreeSpecification to describe sparse replicated areas in a naming context. Subtree specifications are already available in the current LDUP model for us to use in describing sparse portions of a replication context since the replica and replica agreement subentries now include the subtreeSpecification operational attribute. The LDUP model already has the means the specify fractional areas of replication. However I suggest that areas of replication be explicitly represented by their own subentries which replica and replica agreement subentries can simply reference (or be subordinate to). > 2. If a client update falls within multiple replication contexts, how should > LDUP behave? I addressed this in my example (where a client update falls within multiple areas of replication), with an update vector and replica ID per area of replication, and the cascade rule. > Let's start with replicating changes under all appropriate > replication contexts, meaning that the same update will be sent multiple > times under different replication sessions (they are idempotent, so this > should be okay). It will work if each session obtains a different consumer update vector. However, the cascade rule avoids much of the update duplication. > This should keep update vectors in the correct state, as an > update under one replication context may be replicated before earlier > updates (by CSN) that fall within other overlapping replication contexts. > 3. Do we allow multiple replication contexts with different bounds to have > the same root? I'd like to withdraw the question, because I'm sure that once > asked, the answer will be "YES!" This makes my head hurt more than I need > just before Christmas, so I'll leave that for others to gnaw on. The solution I presented previously works regardless of how areas of replication overlap or nest. Two areas of replication that have the same root but different bounds is just one of many ways two areas can overlap. > > > John McMeeking Regards, Steven From owner-ietf-ldup@mail.imc.org Tue Jan 8 17:44:26 2002 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA12753 for ; Tue, 8 Jan 2002 17:44:25 -0500 (EST) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g08MNIo21519 for ietf-ldup-bks; Tue, 8 Jan 2002 14:23:18 -0800 (PST) Received: from nexus.adacel.com (shelob.adacel.com.au [203.36.26.146] (may be forged)) by above.proper.com (8.11.6/8.11.3) with SMTP id g08MND321515 for ; Tue, 8 Jan 2002 14:23:13 -0800 (PST) Received: (qmail 2848 invoked from network); 8 Jan 2002 22:15:01 -0000 Received: from unknown (HELO osmium) (10.32.24.165) by nexus.adacel.com with SMTP; 8 Jan 2002 22:15:01 -0000 Reply-To: From: "Steven Legg" To: "'Ed Reed'" Cc: Subject: RE: Supporting Partial Replication Date: Wed, 9 Jan 2002 09:22:48 +1100 Message-ID: <005801c19893$014c32f0$a518200a@osmium.mtwav.adacel.com.au> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook 8.5, Build 4.71.2377.0 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V4.72.2120.0 In-Reply-To: Sender: owner-ietf-ldup@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit Ed, Ed Reed wrote: > John - I think you're onto the right track in determining > where the disconnect > exists. > > To begin, note that the model only talks about fractional, > and not sparse, > replicas. > > Fractional replicas are those that hold entries having a subset > of all the attributes defined on compete replicas holding > those entries. All > entries of a replication context are present in a fractional > replica, but not > all of their attributes are there. It is the entries which > are fractional. > > Sparse replicas, we agreed, are those where not every entry of the > replication context are held on the sparse replica. But every entry > that IS held is complete. It is the namespace that is sparse. > > A Sparse and/or Fractional replica (an incomplete replica, in > earlier drafts > of the model) hold some of the entries of the replication > context, and they > may or may not be complete (ie, some entries may be > fractional entries). > In other words, the namespace is sparse and the entries held may be > fractional. > > We dropped sparse replicas from the Arch Model when we couldn't > persuade ourselves that we knew how to deal with update vectors and > purge vectors for sparse replicas. That's one of the questions I'm now addressing. It turns out that fractional replicas (already in the model) and sparse replicas (not yet in the model) have the same issues with respect to update vectors, and the same solution. > > Now, I've never contemplated a scenario in which a server holds two > replicas of same replication context. There may be utility in > such a scenario, but it has never occured to me. Thus, there is one > update vector for the replication context, on the replicaSubentry. > > The LDUP model in my mind partitions naming contexts with replication > contexts. Note that both naming contexts and replication contexts are > subjects of the DIT, not of any particular DIB. A replica is a set of > entries from a naming context held in a particular DIB by a particular > LDAP server. There may be multiple replicas of any > replication context. > > But as I said, it had never occured to me to consider a DSA holding > multiple replicas of the same replication context in its DIB. > > Rather, I assumed that a DSA would be considered to hold in its DIB > all the entries from a replication context that it needed for its own > purposes, and for the purposes of forwarding updates to other servers > that it supplies updates to, if any. I trust that you understand that in advocating an update vector and replica ID for each area of replication (by which I mean a full or sparse and/or fractional portion of a replication context) I'm not suggesting that the data in overlapping areas of replication should be duplicated. An entry and its attributes are represented only once in a server even though that entry, or parts of it, may fall within the scope of more than one area of replication. > > So, subordinate to the replicaSubentry representing the replica in the > DIB of a DSA, there could be several replicationAgreements - some > of which place no additional filters on the updates being sent, and > some that DO further restrict which attributes (for > fractional entries) > are to be forwarded to the specific other DSA replica pointed to by > each replicationAgreementSubentry. > > Thus - a replicaSubentry documents the entries held by the DSA and > whether there are any limits on the attributes held for those entries, > and replicationAgreementSubentries documents the flow of > entries (and their attributes, possibly filtered) between a replica > and another. There is a degree of redundancy, and therefore scope for consistency errors, in describing a fractional replica. The same attribute filters are specified in the replicaSubentry for the fractional replica and in the replicaAgreementSubentry for propagating updates from the full replica to the fractional replica. If updateable fractional replicas are to be allowed then there will also be a replicaAgreementSubentry for propagating changes from the fractional replica to the full replica, with the same attribute filters. There would be similar redundancy for sparse replica specifications. This redundancy would be removed if areas of replication were explicitly represented by subentries in a replication context. A replicaSubentry subordinate to an area of replication subentry indicates that the server holds the information in that area of replication, and replicaAgreementSubentries subordinate to the replicaSubentry are assumed to propagate only changes to the same information. The area of information subentry is the only place where sparse-ness and fractional-ness needs to be specified. > > If the set of entries in replication area A held by replica 1 is > designated A1 on Server S1, and there is a subset of A held on another > server S2 designated A2, A1 is a complete replica and A2 is an > incomplete replica. It would be redundant to say that A2 and A1 > are both held by S1, though they are, because all the entries of A2 > (being a subset of A) are in A1 (the full set of A). > > Now, A1 on S1 might very well have a replicationAgreement with A2 > on S2 such that A1 only sends what A2 needs because of the filters > on the replication agreement, or even because of filters on the > replicaSubentry for A2. > > But the notion that both A1 and A2 would be considered to both > be on a single server is simply not something I have ever considered. > I don't know if the model could work in such a scenario or not. > > Ed Regards, Steven From owner-ietf-ldup@mail.imc.org Fri Jan 18 00:46:32 2002 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA23385 for ; Fri, 18 Jan 2002 00:46:32 -0500 (EST) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g0I5VIE10590 for ietf-ldup-bks; Thu, 17 Jan 2002 21:31:18 -0800 (PST) Received: from nexus.adacel.com (shelob.adacel.com.au [203.36.26.146] (may be forged)) by above.proper.com (8.11.6/8.11.3) with SMTP id g0I5VA310585 for ; Thu, 17 Jan 2002 21:31:10 -0800 (PST) Received: (qmail 11948 invoked from network); 18 Jan 2002 05:21:50 -0000 Received: from unknown (HELO osmium) (10.32.24.165) by nexus.adacel.com with SMTP; 18 Jan 2002 05:21:50 -0000 Reply-To: From: "Steven Legg" To: "'Ed Reed'" Cc: Subject: RE: Is State-based LDUP needed? Date: Fri, 18 Jan 2002 16:30:23 +1100 Message-ID: <000001c19fe1$3ad99300$a518200a@osmium.mtwav.adacel.com.au> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook 8.5, Build 4.71.2377.0 X-MimeOLE: Produced By Microsoft MimeOLE V4.72.2120.0 Importance: Normal In-Reply-To: Sender: owner-ietf-ldup@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit Ed, Ed Reed wrote: > I asked this question at the ldup meeting on Thursday, and agreed to post > the question to the distribution list. > > Is anyone planning to implement state-based ldup? If not - that is, if there > are not going to be at least two interoperable implementations of the > proposed specification, should we not remove it from the ldup design now, > rather than later? For the most part I see the choice between a state-based implementation and a log-based implementation as an internal implementation choice and as such is out of scope for a protocol specification. To the fullest extent possible we should remove the distinction and concentrate on the externally visible behaviour of the LDUP servers. I regard it as an internal choice because about the only place where the choice of implementation manifests a difference in the external behaviour of the server is in the ordering of changes in a replication session. I have more to say about that below. > The protocol will support it, but there are certainly places in the > architecture and other documents where the different handling of change > information required by the state-based scheme adds unnecessary text if > noone is actually going to use it. I couldn't find much text in draft-ietf-ldup-model-06.txt that related specifically to log-based versus state-based implementation, and none that needed to be in the document in any case. Section 3.4 isn't needed at all. It doesn't add to the LDUP specification in any way. Regarding the last paragraph in 4.5.3: "The modifications that made up an LDAP Modify operation are presented in a sequence. This must be preserved when the resultant changes of this operation are replicated." This paragraph can be dropped, along with sections 4.5.3.1 and 4.5.3.2. URP describes how the CSNs are to be assigned such that the net effect is preserved even if the primitives for the modifications get out of order. Sections 10.3.1 (except the last paragraph) and 10.3.2 can be dropped. URP describes these two cases more precisely and more completely. > This is a pragmatic decision - I personally like state based schemes, even > though there are things (like transaction replication) that I doubt they'll > ever be able to handle well. Also, all the implementers I know are focused > on the log-based scheme, instead. It seems easier for them to get their > heads around, for some reason... > > So - I don't think it's appropriate for me to be the only one championing it, > and have reached the conclusion that if we can't find even two implementers > to build it, we should not bother including it in further work. I agree with Tim here. The requirement is to have two interoperable implementations of each of the options in the protocol. The internal details of how an each implementation supports the protocol is irrelevant. We don't necessarily need two state-based implementation to meet the interoperabiliy requirements. Aside from the ordering issue I'm not sure there is anything in the current LDUP specifications that is exclusive to state-based implementations or exclusive to log-based implementations. > > If you're planning to build it, speak up. If not, silence may well be taken > as assent to remove references to it from the various protocol documents. > > Best regards, > Ed Now for something not so completely different ... In looking over your coverage matrix I found three cases of perceived fundamental differences between log-based and state-based implementations. First of all it is important to recognize that the update vector based method of update propagation imposes certain unstated, but unavoidable constraints on the behaviour of state-based implementations, otherwise eventual consistency cannot be guaranteed. A state-based implementation is not free to send updates in a totally random order. For example, if a supplier sends updates with CSNs t1 and t3, but doesn't yet send an update with CSN t2, the consumer will nonetheless revise its update vector to the highest CSN seen, i.e. t3, and consequently will never receive the update with CSN t2. Whether the LDUP architecture says it or not, with respect to any particular replica ID, a state-based implementation is obliged to send during a replication session *all* the updates between the sent update with the least CSN and the sent update with the highest CSN. Every update sent must have a CSN greater than the highest CSN of the previous successful session and less than the least CSN of the next successful session. However, the update vector propagation method doesn't implicitly constrain implementations to send updates in CSN order within a replication session since there are at least three ways to implement a consumer such that eventual consistency is still guaranteed, even if the updates within a replication session aren't necessarily in CSN order. This applies regardless of whether the consumer is state-based or log based. The three ways are: 1) The consumer puts the incoming updates from the supplier into temporary storage without applying them or revising its update vector. Once the final update in the session has been received, the consumer sorts the updates into CSN order and then applies them in that order, revising its update vector along the way. It doesn't matter if there is a service failure during either the collect/sort phase or in the application phase. Note: as far as the ordering is concerned, it is only necessary for the updates to be in CSN order with respect to each replica ID. Updates originating from different replicas can be freely intermixed. 2) The consumer processes the entire set of updates from the session as a single atomic transaction on its internal database. That is, either all of the updates are applied and the update vector revised accordingly, or, in the event of some failure during the course of the replication session, none of the updates are applied and the update vector is not revised, i.e. all the changes are rolled back. URP ensures that the end result is the same as if the consumer applied the changes in CSN order. 3) The consumer applies updates as they are received but defers revising its update vector until the end of the replication session. In this case the consumer must make sure that it does NOT propagate to any other server any update it knows about which has a more recent CSN than the relevant CSN in its update vector. Such an update belongs to an incomplete set of changes from a failed replication session. On the other hand, if the updates in a replication session are always guaranteed to be in CSN order then the consumer can just apply them as they are received. A state-based implementation can readily provide updates in CSN order by sorting them in temporary storage before sending them to the consumer. The way I see it, it is not that state-based implementations can't meet certain requirements but rather it comes down to a question of who has to do the work (e.g. collation) so that the requirements are met. If we believe that log-based implementations will be more prevalent than state-based ones then it makes sense to put the load of collating the updates onto state-based implementations by insisting that updates are always sent in CSN order with respect to each replica ID. Now to the coverage matrix ... ------------------------------------------------------------------------ Requirement 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. Comment: Supported for log-based systems, but not state-based systems, by definition. ------------------------------------------------------------------------ If state-base suppliers always sort updates before sending them then they will satisfy SM2 directly. If consumers sort incoming replication updates before applying them, or apply them in one atomic transaction, then SM2 is effectively satisfied, whether the supplier is state-based or not. However if consumers defer revising the update vector until the end of the session then a failure part way through potentially leaves them holding some later updates without the earlier updates. The choice to implement a consumer this way is independent of whether the consumer is state-based or log-based so whether requirement SM2 is satisfied depends on how the consumer processing is implemented, rather than whether it is state-based or log-based. Disallowing 3) above or insisting that updates are always sent in CSN order with respect to each replica ID solves that problem. ------------------------------------------------------------------------ Requirement AM6: The sequence of updates to access control information (ACI) and the data controlled by that ACI MUST be maintained by replication. Comment: Not supported for State Based replication ------------------------------------------------------------------------ The arguments that apply to SM2 apply to AM6 as well. ------------------------------------------------------------------------ Requirement G2: LDAP Replication SHOULD NOT preclude support for model 1 (Transactional Consistency) in the future. Comment: ... the authors believe that there is a good chance that at least the log-based mechanism described in the architecture will be able to be extended to support replication of transactional information. We do have our doubts about the ability of any state-based replication scheme to do so, though. ------------------------------------------------------------------------ Unless people are contemplating a radical departure from the processing model described in the URP document, the essential difference between a state-based implementation and a log-based implementation is whether incoming replication primitives are saved as-is to be propagated later to other servers, or reconstructed on demand from the state information on directory data, i.e. the CSNs on entries and values, and deletion records. Note that this same state information is present even in a log-based implementation. We can think of a state-based implementation as having an effective log which is notionally constructed from this state information. The effective log becomes realized either in the supplier or the consumer depending on whether we require the supplier to do the collation of the updates. An effective log differs from a real log in two ways: 1) It contains no superseded primitives. Note that this does not make an effective log unique since a log-based supplier is permitted to strip out superseded primitives. A state-based implementation just can't avoid stripping them out. 2) It cannot preserve the exact order in which the supplier itself received the update primitives. Note that it is not necessarily the case that a log-based implementation will preserve the order either, e.g. it might have a separate log for each replica ID. The information in the logs, i.e. the set of replication primitives, is otherwise the same. Any future extension to LDUP will work for both state-based and log-based implementations if it does not rely on preservation of superseded primitives or supplier receipt order. Any mechanism that relies on receipt order is probably broken for log-based implementations anyway since multiple master servers will inevitably receive the same changes in different orders (sorted on CSN per replica ID, but not necessarily globally sorted on CSN). I have previously sketched out separate solutions for providing transactional consistency on top of LDUP, and for identifying transaction inconsistencies in the absence of support for the former. These solutions apply equally well to log-based or state-based implementations since neither depends on supplier receipt order or preservation of superseded primitives. Regards, Steven From owner-ietf-ldup@mail.imc.org Fri Jan 18 06:59:22 2002 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA07470 for ; Fri, 18 Jan 2002 06:59:21 -0500 (EST) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g0IBen916542 for ietf-ldup-bks; Fri, 18 Jan 2002 03:40:49 -0800 (PST) Received: from e1.ny.us.ibm.com (e1.ny.us.ibm.com [32.97.182.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g0IBel316538 for ; Fri, 18 Jan 2002 03:40:48 -0800 (PST) Received: from northrelay02.pok.ibm.com (northrelay02.pok.ibm.com [9.117.200.22]) by e1.ny.us.ibm.com (8.9.3/8.9.3) with ESMTP id GAA413912 for ; Fri, 18 Jan 2002 06:37:39 -0500 Received: from d01mlc96.pok.ibm.com (d01mlc96.pok.ibm.com [9.117.250.33]) by northrelay02.pok.ibm.com (8.11.1m3/NCO v5.01) with ESMTP id g0IBeeg142364 for ; Fri, 18 Jan 2002 06:40:40 -0500 To: ietf-ldup@imc.org MIME-Version: 1.0 Subject: RE: Is State-based LDUP needed? X-Mailer: Lotus Notes Release 5.0.7 March 21, 2001 From: "Timothy Hahn" Message-ID: Date: Fri, 18 Jan 2002 06:40:38 -0500 X-MIMETrack: Serialize by Router on D01MLC96/01/M/IBM(Release 5.0.9 |November 26, 2001) at 01/18/2002 06:40:40 AM, Serialize complete at 01/18/2002 06:40:40 AM Content-Type: multipart/alternative; boundary="=_alternative 003F750285256B45_=" Sender: owner-ietf-ldup@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multipart message in MIME format. --=_alternative 003F750285256B45_= Content-Type: text/plain; charset="us-ascii" Steven, I followed you all the way until the end of your note. I am of the opinion that updates sent during a replication session be sent in CSN order. While this may cause "up-front" work for "state-based" implementations, I believe that it allows consumer servers to make the most progress possible - even if the communications link is lost before the replication session can complete. URP will take care of the cases where the consumer sees a CSN in an update that is "older" when sent by a different path through the network. I couldn't tell in your last two paragraphs what you were asserting be done with respect to update send (and thus expected receive) order. Regards, Tim Hahn Internet: hahnt@us.ibm.com Internal: Timothy Hahn/Endicott/IBM@IBMUS or IBMUSM00(HAHNT) phone: 607.752.6388 tie-line: 8/852.6388 fax: 607.752.3681 "Steven Legg" Sent by: owner-ietf-ldup@mail.imc.org 01/18/2002 12:30 AM Please respond to steven.legg To: "'Ed Reed'" cc: Subject: RE: Is State-based LDUP needed? Ed, Ed Reed wrote: > I asked this question at the ldup meeting on Thursday, and agreed to post > the question to the distribution list. > > Is anyone planning to implement state-based ldup? If not - that is, if there > are not going to be at least two interoperable implementations of the > proposed specification, should we not remove it from the ldup design now, > rather than later? For the most part I see the choice between a state-based implementation and a log-based implementation as an internal implementation choice and as such is out of scope for a protocol specification. To the fullest extent possible we should remove the distinction and concentrate on the externally visible behaviour of the LDUP servers. I regard it as an internal choice because about the only place where the choice of implementation manifests a difference in the external behaviour of the server is in the ordering of changes in a replication session. I have more to say about that below. > The protocol will support it, but there are certainly places in the > architecture and other documents where the different handling of change > information required by the state-based scheme adds unnecessary text if > noone is actually going to use it. I couldn't find much text in draft-ietf-ldup-model-06.txt that related specifically to log-based versus state-based implementation, and none that needed to be in the document in any case. Section 3.4 isn't needed at all. It doesn't add to the LDUP specification in any way. Regarding the last paragraph in 4.5.3: "The modifications that made up an LDAP Modify operation are presented in a sequence. This must be preserved when the resultant changes of this operation are replicated." This paragraph can be dropped, along with sections 4.5.3.1 and 4.5.3.2. URP describes how the CSNs are to be assigned such that the net effect is preserved even if the primitives for the modifications get out of order. Sections 10.3.1 (except the last paragraph) and 10.3.2 can be dropped. URP describes these two cases more precisely and more completely. > This is a pragmatic decision - I personally like state based schemes, even > though there are things (like transaction replication) that I doubt they'll > ever be able to handle well. Also, all the implementers I know are focused > on the log-based scheme, instead. It seems easier for them to get their > heads around, for some reason... > > So - I don't think it's appropriate for me to be the only one championing it, > and have reached the conclusion that if we can't find even two implementers > to build it, we should not bother including it in further work. I agree with Tim here. The requirement is to have two interoperable implementations of each of the options in the protocol. The internal details of how an each implementation supports the protocol is irrelevant. We don't necessarily need two state-based implementation to meet the interoperabiliy requirements. Aside from the ordering issue I'm not sure there is anything in the current LDUP specifications that is exclusive to state-based implementations or exclusive to log-based implementations. > > If you're planning to build it, speak up. If not, silence may well be taken > as assent to remove references to it from the various protocol documents. > > Best regards, > Ed Now for something not so completely different ... In looking over your coverage matrix I found three cases of perceived fundamental differences between log-based and state-based implementations. First of all it is important to recognize that the update vector based method of update propagation imposes certain unstated, but unavoidable constraints on the behaviour of state-based implementations, otherwise eventual consistency cannot be guaranteed. A state-based implementation is not free to send updates in a totally random order. For example, if a supplier sends updates with CSNs t1 and t3, but doesn't yet send an update with CSN t2, the consumer will nonetheless revise its update vector to the highest CSN seen, i.e. t3, and consequently will never receive the update with CSN t2. Whether the LDUP architecture says it or not, with respect to any particular replica ID, a state-based implementation is obliged to send during a replication session *all* the updates between the sent update with the least CSN and the sent update with the highest CSN. Every update sent must have a CSN greater than the highest CSN of the previous successful session and less than the least CSN of the next successful session. However, the update vector propagation method doesn't implicitly constrain implementations to send updates in CSN order within a replication session since there are at least three ways to implement a consumer such that eventual consistency is still guaranteed, even if the updates within a replication session aren't necessarily in CSN order. This applies regardless of whether the consumer is state-based or log based. The three ways are: 1) The consumer puts the incoming updates from the supplier into temporary storage without applying them or revising its update vector. Once the final update in the session has been received, the consumer sorts the updates into CSN order and then applies them in that order, revising its update vector along the way. It doesn't matter if there is a service failure during either the collect/sort phase or in the application phase. Note: as far as the ordering is concerned, it is only necessary for the updates to be in CSN order with respect to each replica ID. Updates originating from different replicas can be freely intermixed. 2) The consumer processes the entire set of updates from the session as a single atomic transaction on its internal database. That is, either all of the updates are applied and the update vector revised accordingly, or, in the event of some failure during the course of the replication session, none of the updates are applied and the update vector is not revised, i.e. all the changes are rolled back. URP ensures that the end result is the same as if the consumer applied the changes in CSN order. 3) The consumer applies updates as they are received but defers revising its update vector until the end of the replication session. In this case the consumer must make sure that it does NOT propagate to any other server any update it knows about which has a more recent CSN than the relevant CSN in its update vector. Such an update belongs to an incomplete set of changes from a failed replication session. On the other hand, if the updates in a replication session are always guaranteed to be in CSN order then the consumer can just apply them as they are received. A state-based implementation can readily provide updates in CSN order by sorting them in temporary storage before sending them to the consumer. The way I see it, it is not that state-based implementations can't meet certain requirements but rather it comes down to a question of who has to do the work (e.g. collation) so that the requirements are met. If we believe that log-based implementations will be more prevalent than state-based ones then it makes sense to put the load of collating the updates onto state-based implementations by insisting that updates are always sent in CSN order with respect to each replica ID. Now to the coverage matrix ... ------------------------------------------------------------------------ Requirement 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. Comment: Supported for log-based systems, but not state-based systems, by definition. ------------------------------------------------------------------------ If state-base suppliers always sort updates before sending them then they will satisfy SM2 directly. If consumers sort incoming replication updates before applying them, or apply them in one atomic transaction, then SM2 is effectively satisfied, whether the supplier is state-based or not. However if consumers defer revising the update vector until the end of the session then a failure part way through potentially leaves them holding some later updates without the earlier updates. The choice to implement a consumer this way is independent of whether the consumer is state-based or log-based so whether requirement SM2 is satisfied depends on how the consumer processing is implemented, rather than whether it is state-based or log-based. Disallowing 3) above or insisting that updates are always sent in CSN order with respect to each replica ID solves that problem. ------------------------------------------------------------------------ Requirement AM6: The sequence of updates to access control information (ACI) and the data controlled by that ACI MUST be maintained by replication. Comment: Not supported for State Based replication ------------------------------------------------------------------------ The arguments that apply to SM2 apply to AM6 as well. ------------------------------------------------------------------------ Requirement G2: LDAP Replication SHOULD NOT preclude support for model 1 (Transactional Consistency) in the future. Comment: ... the authors believe that there is a good chance that at least the log-based mechanism described in the architecture will be able to be extended to support replication of transactional information. We do have our doubts about the ability of any state-based replication scheme to do so, though. ------------------------------------------------------------------------ Unless people are contemplating a radical departure from the processing model described in the URP document, the essential difference between a state-based implementation and a log-based implementation is whether incoming replication primitives are saved as-is to be propagated later to other servers, or reconstructed on demand from the state information on directory data, i.e. the CSNs on entries and values, and deletion records. Note that this same state information is present even in a log-based implementation. We can think of a state-based implementation as having an effective log which is notionally constructed from this state information. The effective log becomes realized either in the supplier or the consumer depending on whether we require the supplier to do the collation of the updates. An effective log differs from a real log in two ways: 1) It contains no superseded primitives. Note that this does not make an effective log unique since a log-based supplier is permitted to strip out superseded primitives. A state-based implementation just can't avoid stripping them out. 2) It cannot preserve the exact order in which the supplier itself received the update primitives. Note that it is not necessarily the case that a log-based implementation will preserve the order either, e.g. it might have a separate log for each replica ID. The information in the logs, i.e. the set of replication primitives, is otherwise the same. Any future extension to LDUP will work for both state-based and log-based implementations if it does not rely on preservation of superseded primitives or supplier receipt order. Any mechanism that relies on receipt order is probably broken for log-based implementations anyway since multiple master servers will inevitably receive the same changes in different orders (sorted on CSN per replica ID, but not necessarily globally sorted on CSN). I have previously sketched out separate solutions for providing transactional consistency on top of LDUP, and for identifying transaction inconsistencies in the absence of support for the former. These solutions apply equally well to log-based or state-based implementations since neither depends on supplier receipt order or preservation of superseded primitives. Regards, Steven --=_alternative 003F750285256B45_= Content-Type: text/html; charset="us-ascii"
Steven,

I followed you all the way until the end of your note.

I am of the opinion that updates sent during a replication session be sent in CSN order.  While this may cause "up-front" work for "state-based" implementations, I believe that it allows consumer servers to make the most progress possible - even if the communications link is lost before the replication session can complete.  URP will take care of the cases where the consumer sees a CSN in an update that is "older" when sent by a different path through the network.

I couldn't tell in your last two paragraphs what you were asserting be done with respect to update send (and thus expected receive) order.
Regards,
Tim Hahn

Internet: hahnt@us.ibm.com
Internal: Timothy Hahn/Endicott/IBM@IBMUS or IBMUSM00(HAHNT)
phone: 607.752.6388     tie-line: 8/852.6388
fax: 607.752.3681


"Steven Legg" <steven.legg@adacel.com.au>
Sent by: owner-ietf-ldup@mail.imc.org

01/18/2002 12:30 AM
Please respond to steven.legg

       
        To:        "'Ed Reed'" <eer@OnCallDBA.COM>
        cc:        <ietf-ldup@imc.org>
        Subject:        RE: Is State-based LDUP needed?

       




Ed,

Ed Reed wrote:
> I asked this question at the ldup meeting on Thursday, and agreed to post
> the question to the distribution list.
>
> Is anyone planning to implement state-based ldup?  If not - that is, if
there
> are not going to be at least two interoperable implementations of the
> proposed specification, should we not remove it from the ldup design now,
> rather than later?

For the most part I see the choice between a state-based implementation
and a log-based implementation as an internal implementation choice and
as such is out of scope for a protocol specification. To the fullest
extent possible we should remove the distinction and concentrate on the
externally visible behaviour of the LDUP servers.

I regard it as an internal choice because about the only place where the
choice of implementation manifests a difference in the external behaviour
of the server is in the ordering of changes in a replication session.
I have more to say about that below.


> The protocol will support it, but there are certainly places in the
> architecture and other documents where the different handling of change
> information required by the state-based scheme adds unnecessary text if
> noone is actually going to use it.

I couldn't find much text in draft-ietf-ldup-model-06.txt that related
specifically to log-based versus state-based implementation, and none
that needed to be in the document in any case.

Section 3.4 isn't needed at all. It doesn't add to the LDUP specification
in any way.

Regarding the last paragraph in 4.5.3:

  "The modifications that made up an LDAP Modify operation are
  presented in a sequence. This must be preserved when the
  resultant changes of this operation are replicated."

This paragraph can be dropped, along with sections 4.5.3.1 and 4.5.3.2.
URP describes how the CSNs are to be assigned such that the net effect
is preserved even if the primitives for the modifications get out of order.

Sections 10.3.1 (except the last paragraph) and 10.3.2 can be dropped.
URP describes these two cases more precisely and more completely.


> This is a pragmatic decision - I personally like state based schemes, even
> though there are things (like transaction replication) that I doubt
they'll
> ever be able to handle well.  Also, all the implementers I know are
focused
> on the log-based scheme, instead.  It seems easier for them to get their
> heads around, for some reason...
>
> So - I don't think it's appropriate for me to be the only one championing
it,
> and have reached the conclusion that if we can't find even two
implementers
> to build it, we should not bother including it in further work.

I agree with Tim here. The requirement is to have two interoperable
implementations of each of the options in the protocol. The internal details
of how an each implementation supports the protocol is irrelevant. We don't
necessarily need two state-based implementation to meet the interoperabiliy
requirements. Aside from the ordering issue I'm not sure there is anything
in the current LDUP specifications that is exclusive to state-based
implementations or exclusive to log-based implementations.
>
> If you're planning to build it, speak up.  If not, silence may well be
taken
> as assent to remove references to it from the various protocol documents.
>
> Best regards,
> Ed

Now for something not so completely different ...

In looking over your coverage matrix I found three cases of perceived
fundamental differences between log-based and state-based implementations.

First of all it is important to recognize that the update vector based
method of update propagation imposes certain unstated, but unavoidable
constraints on the behaviour of state-based implementations, otherwise
eventual consistency cannot be guaranteed.

A state-based implementation is not free to send updates in a totally
random order. For example, if a supplier sends updates with CSNs t1 and
t3, but doesn't yet send an update with CSN t2, the consumer will
nonetheless revise its update vector to the highest CSN seen, i.e. t3,
and consequently will never receive the update with CSN t2. Whether the
LDUP architecture says it or not, with respect to any particular
replica ID, a state-based implementation is obliged to send during a
replication session *all* the updates between the sent update with the
least CSN and the sent update with the highest CSN. Every update sent
must have a CSN greater than the highest CSN of the previous successful
session and less than the least CSN of the next successful session.

However, the update vector propagation method doesn't implicitly constrain
implementations to send updates in CSN order within a replication session
since there are at least three ways to implement a consumer such that
eventual
consistency is still guaranteed, even if the updates within a replication
session aren't necessarily in CSN order. This applies regardless of whether
the consumer is state-based or log based.

The three ways are:

1) The consumer puts the incoming updates from the supplier into temporary
storage without applying them or revising its update vector. Once the final
update in the session has been received, the consumer sorts the updates
into CSN order and then applies them in that order, revising its update
vector along the way. It doesn't matter if there is a service failure
during either the collect/sort phase or in the application phase.

Note: as far as the ordering is concerned, it is only necessary for the
updates
to be in CSN order with respect to each replica ID. Updates originating
from different replicas can be freely intermixed.

2) The consumer processes the entire set of updates from the session as
a single atomic transaction on its internal database. That is, either all
of the updates are applied and the update vector revised accordingly, or,
in the event of some failure during the course of the replication session,
none of the updates are applied and the update vector is not revised,
i.e. all the changes are rolled back. URP ensures that the end result is
the same as if the consumer applied the changes in CSN order.

3) The consumer applies updates as they are received but defers revising
its update vector until the end of the replication session. In this case
the consumer must make sure that it does NOT propagate to any other server
any update it knows about which has a more recent CSN than the relevant
CSN in its update vector. Such an update belongs to an incomplete set of
changes from a failed replication session.

On the other hand, if the updates in a replication session are always
guaranteed to be in CSN order then the consumer can just apply them as
they are received. A state-based implementation can readily provide updates
in CSN order by sorting them in temporary storage before sending them to
the consumer.

The way I see it, it is not that state-based implementations can't meet
certain requirements but rather it comes down to a question of who has
to do the work (e.g. collation) so that the requirements are met.
If we believe that log-based implementations will be more prevalent than
state-based ones then it makes sense to put the load of collating the
updates onto state-based implementations by insisting that updates are
always sent in CSN order with respect to each replica ID.

Now to the coverage matrix ...

------------------------------------------------------------------------
Requirement 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.

Comment: Supported for log-based systems, but not state-based systems,
by definition.
------------------------------------------------------------------------

If state-base suppliers always sort updates before sending them then they
will satisfy SM2 directly.

If consumers sort incoming replication updates before applying them,
or apply them in one atomic transaction, then SM2 is effectively satisfied,
whether the supplier is state-based or not.

However if consumers defer revising the update vector until the end
of the session then a failure part way through potentially leaves them
holding some later updates without the earlier updates. The choice to
implement a consumer this way is independent of whether the consumer
is state-based or log-based so whether requirement SM2 is satisfied
depends on how the consumer processing is implemented, rather than
whether it is state-based or log-based.

Disallowing 3) above or insisting that updates are always sent in CSN order
with respect to each replica ID solves that problem.

------------------------------------------------------------------------
Requirement AM6: The sequence of updates to access control information
(ACI) and the data controlled by that ACI MUST be maintained by replication.

Comment: Not supported for State Based replication
------------------------------------------------------------------------

The arguments that apply to SM2 apply to AM6 as well.

------------------------------------------------------------------------
Requirement G2: LDAP Replication SHOULD NOT preclude support for model 1
(Transactional Consistency) in the future.

Comment: ... the authors believe that there is a good chance that at
least the log-based mechanism described in the architecture will be able
to be extended to support replication of transactional information.
We do have our doubts about the ability of any state-based replication
scheme to do so, though.
------------------------------------------------------------------------

Unless people are contemplating a radical departure from the processing
model described in the URP document, the essential difference between
a state-based implementation and a log-based implementation is whether
incoming replication primitives are saved as-is to be propagated later
to other servers, or reconstructed on demand from the state information
on directory data, i.e. the CSNs on entries and values, and deletion
records.
Note that this same state information is present even in a log-based
implementation.

We can think of a state-based implementation as having an effective log
which is notionally constructed from this state information. The effective
log becomes realized either in the supplier or the consumer depending on
whether we require the supplier to do the collation of the updates.

An effective log differs from a real log in two ways:

1) It contains no superseded primitives. Note that this does not make an
effective log unique since a log-based supplier is permitted to strip out
superseded primitives. A state-based implementation just can't avoid
stripping them out.

2) It cannot preserve the exact order in which the supplier itself
received the update primitives. Note that it is not necessarily the case
that a log-based implementation will preserve the order either, e.g. it
might have a separate log for each replica ID.

The information in the logs, i.e. the set of replication primitives,
is otherwise the same.

Any future extension to LDUP will work for both state-based and log-based
implementations if it does not rely on preservation of superseded primitives
or supplier receipt order. Any mechanism that relies on receipt order is
probably broken for log-based implementations anyway since multiple master
servers will inevitably receive the same changes in different orders
(sorted on CSN per replica ID, but not necessarily globally sorted on CSN).

I have previously sketched out separate solutions for providing
transactional
consistency on top of LDUP, and for identifying transaction inconsistencies
in the absence of support for the former. These solutions apply equally well
to log-based or state-based implementations since neither depends on
supplier receipt order or preservation of superseded primitives.

Regards,
Steven

--=_alternative 003F750285256B45_=-- From owner-ietf-ldup@mail.imc.org Sun Jan 20 18:42:13 2002 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA17518 for ; Sun, 20 Jan 2002 18:42:13 -0500 (EST) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g0KNQja03724 for ietf-ldup-bks; Sun, 20 Jan 2002 15:26:45 -0800 (PST) Received: from nexus.adacel.com (shelob.adacel.com.au [203.36.26.146] (may be forged)) by above.proper.com (8.11.6/8.11.3) with SMTP id g0KNQg303719 for ; Sun, 20 Jan 2002 15:26:42 -0800 (PST) Received: (qmail 9019 invoked from network); 20 Jan 2002 23:17:06 -0000 Received: from unknown (HELO osmium) (10.32.24.165) by nexus.adacel.com with SMTP; 20 Jan 2002 23:17:06 -0000 Reply-To: From: "Steven Legg" To: "'Timothy Hahn'" Cc: Subject: RE: Is State-based LDUP needed? Date: Mon, 21 Jan 2002 10:25:52 +1100 Message-ID: <003401c1a209$cdafcb20$a518200a@osmium.mtwav.adacel.com.au> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook 8.5, Build 4.71.2377.0 X-MimeOLE: Produced By Microsoft MimeOLE V4.72.2120.0 Importance: Normal In-Reply-To: Sender: owner-ietf-ldup@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit Hi Tim, Timothy Hahn wrote: > Steven, > > I followed you all the way until the end of your note. > > I am of the opinion that updates sent during a replication session be sent > in CSN order. While this may cause "up-front" work for "state-based" > implementations, I believe that it allows consumer servers to make the most > progress possible - even if the communications link is lost before the > replication session can complete. URP will take care of the cases where > the consumer sees a CSN in an update that is "older" when sent by a > different path through the network. > > I couldn't tell in your last two paragraphs what you were asserting be > done with respect to update send (and thus expected receive) order. I wasn't so much making a specific proposal as pointing out the technical issues. Given that there will be few or no state-based implementations then I am of the opinion that we should make life easier all round by requiring that, with respect to each replica ID, updates must be sent in CSN order. We don't want to require that updates be sent in global CSN order since that would require even the log-based implementations to sort updates before sending them. Regards, Steven > > Regards, > Tim Hahn > > Internet: hahnt@us.ibm.com > Internal: Timothy Hahn/Endicott/IBM@IBMUS or IBMUSM00(HAHNT) > phone: 607.752.6388 tie-line: 8/852.6388 > fax: 607.752.3681 > > > > "Steven Legg" > Sent by: owner-ietf-ldup@mail.imc.org > 01/18/2002 12:30 AM > Please respond to steven.legg > > To: "'Ed Reed'" > cc: > Subject: RE: Is State-based LDUP needed? > > > > > > > Ed, > > Ed Reed wrote: > > I asked this question at the ldup meeting on Thursday, and agreed to post > > the question to the distribution list. > > > > Is anyone planning to implement state-based ldup? If not - that is, if > there > > are not going to be at least two interoperable implementations of the > > proposed specification, should we not remove it from the ldup design now, > > rather than later? > > For the most part I see the choice between a state-based implementation > and a log-based implementation as an internal implementation choice and > as such is out of scope for a protocol specification. To the fullest > extent possible we should remove the distinction and concentrate on the > externally visible behaviour of the LDUP servers. > > I regard it as an internal choice because about the only place where the > choice of implementation manifests a difference in the external behaviour > of the server is in the ordering of changes in a replication session. > I have more to say about that below. > > > > The protocol will support it, but there are certainly places in the > > architecture and other documents where the different handling of change > > information required by the state-based scheme adds unnecessary text if > > noone is actually going to use it. > > I couldn't find much text in draft-ietf-ldup-model-06.txt that related > specifically to log-based versus state-based implementation, and none > that needed to be in the document in any case. > > Section 3.4 isn't needed at all. It doesn't add to the LDUP specification > in any way. > > Regarding the last paragraph in 4.5.3: > > "The modifications that made up an LDAP Modify operation are > presented in a sequence. This must be preserved when the > resultant changes of this operation are replicated." > > This paragraph can be dropped, along with sections 4.5.3.1 and 4.5.3.2. > URP describes how the CSNs are to be assigned such that the net effect > is preserved even if the primitives for the modifications get out of order. > > Sections 10.3.1 (except the last paragraph) and 10.3.2 can be dropped. > URP describes these two cases more precisely and more completely. > > > > This is a pragmatic decision - I personally like state based schemes, even > > though there are things (like transaction replication) that I doubt > they'll > > ever be able to handle well. Also, all the implementers I know are > focused > > on the log-based scheme, instead. It seems easier for them to get their > > heads around, for some reason... > > > > So - I don't think it's appropriate for me to be the only one championing > it, > > and have reached the conclusion that if we can't find even two > implementers > > to build it, we should not bother including it in further work. > > I agree with Tim here. The requirement is to have two interoperable > implementations of each of the options in the protocol. The internal details > of how an each implementation supports the protocol is irrelevant. We don't > necessarily need two state-based implementation to meet the interoperabiliy > requirements. Aside from the ordering issue I'm not sure there is anything > in the current LDUP specifications that is exclusive to state-based > implementations or exclusive to log-based implementations. > > > > > If you're planning to build it, speak up. If not, silence may well be > taken > > as assent to remove references to it from the various protocol documents. > > > > Best regards, > > Ed > > Now for something not so completely different ... > > In looking over your coverage matrix I found three cases of perceived > fundamental differences between log-based and state-based implementations. > > First of all it is important to recognize that the update vector based > method of update propagation imposes certain unstated, but unavoidable > constraints on the behaviour of state-based implementations, otherwise > eventual consistency cannot be guaranteed. > > A state-based implementation is not free to send updates in a totally > random order. For example, if a supplier sends updates with CSNs t1 and > t3, but doesn't yet send an update with CSN t2, the consumer will > nonetheless revise its update vector to the highest CSN seen, i.e. t3, > and consequently will never receive the update with CSN t2. Whether the > LDUP architecture says it or not, with respect to any particular > replica ID, a state-based implementation is obliged to send during a > replication session *all* the updates between the sent update with the > least CSN and the sent update with the highest CSN. Every update sent > must have a CSN greater than the highest CSN of the previous successful > session and less than the least CSN of the next successful session. > > However, the update vector propagation method doesn't implicitly constrain > implementations to send updates in CSN order within a replication session > since there are at least three ways to implement a consumer such that > eventual > consistency is still guaranteed, even if the updates within a replication > session aren't necessarily in CSN order. This applies regardless of whether > the consumer is state-based or log based. > > The three ways are: > > 1) The consumer puts the incoming updates from the supplier into temporary > storage without applying them or revising its update vector. Once the final > update in the session has been received, the consumer sorts the updates > into CSN order and then applies them in that order, revising its update > vector along the way. It doesn't matter if there is a service failure > during either the collect/sort phase or in the application phase. > > Note: as far as the ordering is concerned, it is only necessary for the > updates > to be in CSN order with respect to each replica ID. Updates originating > from different replicas can be freely intermixed. > > 2) The consumer processes the entire set of updates from the session as > a single atomic transaction on its internal database. That is, either all > of the updates are applied and the update vector revised accordingly, or, > in the event of some failure during the course of the replication session, > none of the updates are applied and the update vector is not revised, > i.e. all the changes are rolled back. URP ensures that the end result is > the same as if the consumer applied the changes in CSN order. > > 3) The consumer applies updates as they are received but defers revising > its update vector until the end of the replication session. In this case > the consumer must make sure that it does NOT propagate to any other server > any update it knows about which has a more recent CSN than the relevant > CSN in its update vector. Such an update belongs to an incomplete set of > changes from a failed replication session. > > On the other hand, if the updates in a replication session are always > guaranteed to be in CSN order then the consumer can just apply them as > they are received. A state-based implementation can readily provide updates > in CSN order by sorting them in temporary storage before sending them to > the consumer. > > The way I see it, it is not that state-based implementations can't meet > certain requirements but rather it comes down to a question of who has > to do the work (e.g. collation) so that the requirements are met. > If we believe that log-based implementations will be more prevalent than > state-based ones then it makes sense to put the load of collating the > updates onto state-based implementations by insisting that updates are > always sent in CSN order with respect to each replica ID. > > Now to the coverage matrix ... > > ------------------------------------------------------------------------ > Requirement 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. > > Comment: Supported for log-based systems, but not state-based systems, > by definition. > ------------------------------------------------------------------------ > > If state-base suppliers always sort updates before sending them then they > will satisfy SM2 directly. > > If consumers sort incoming replication updates before applying them, > or apply them in one atomic transaction, then SM2 is effectively satisfied, > whether the supplier is state-based or not. > > However if consumers defer revising the update vector until the end > of the session then a failure part way through potentially leaves them > holding some later updates without the earlier updates. The choice to > implement a consumer this way is independent of whether the consumer > is state-based or log-based so whether requirement SM2 is satisfied > depends on how the consumer processing is implemented, rather than > whether it is state-based or log-based. > > Disallowing 3) above or insisting that updates are always sent in CSN order > with respect to each replica ID solves that problem. > > ------------------------------------------------------------------------ > Requirement AM6: The sequence of updates to access control information > (ACI) and the data controlled by that ACI MUST be maintained by replication. > > Comment: Not supported for State Based replication > ------------------------------------------------------------------------ > > The arguments that apply to SM2 apply to AM6 as well. > > ------------------------------------------------------------------------ > Requirement G2: LDAP Replication SHOULD NOT preclude support for model 1 > (Transactional Consistency) in the future. > > Comment: ... the authors believe that there is a good chance that at > least the log-based mechanism described in the architecture will be able > to be extended to support replication of transactional information. > We do have our doubts about the ability of any state-based replication > scheme to do so, though. > ------------------------------------------------------------------------ > > Unless people are contemplating a radical departure from the processing > model described in the URP document, the essential difference between > a state-based implementation and a log-based implementation is whether > incoming replication primitives are saved as-is to be propagated later > to other servers, or reconstructed on demand from the state information > on directory data, i.e. the CSNs on entries and values, and deletion > records. > Note that this same state information is present even in a log-based > implementation. > > We can think of a state-based implementation as having an effective log > which is notionally constructed from this state information. The effective > log becomes realized either in the supplier or the consumer depending on > whether we require the supplier to do the collation of the updates. > > An effective log differs from a real log in two ways: > > 1) It contains no superseded primitives. Note that this does not make an > effective log unique since a log-based supplier is permitted to strip out > superseded primitives. A state-based implementation just can't avoid > stripping them out. > > 2) It cannot preserve the exact order in which the supplier itself > received the update primitives. Note that it is not necessarily the case > that a log-based implementation will preserve the order either, e.g. it > might have a separate log for each replica ID. > > The information in the logs, i.e. the set of replication primitives, > is otherwise the same. > > Any future extension to LDUP will work for both state-based and log-based > implementations if it does not rely on preservation of superseded primitives > or supplier receipt order. Any mechanism that relies on receipt order is > probably broken for log-based implementations anyway since multiple master > servers will inevitably receive the same changes in different orders > (sorted on CSN per replica ID, but not necessarily globally sorted on CSN). > > I have previously sketched out separate solutions for providing > transactional > consistency on top of LDUP, and for identifying transaction inconsistencies > in the absence of support for the former. These solutions apply equally well > to log-based or state-based implementations since neither depends on > supplier receipt order or preservation of superseded primitives. > > Regards, > Steven From owner-ietf-ldup@mail.imc.org Mon Jan 21 06:52:48 2002 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA06259 for ; Mon, 21 Jan 2002 06:52:48 -0500 (EST) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g0LBaX521600 for ietf-ldup-bks; Mon, 21 Jan 2002 03:36:33 -0800 (PST) Received: from e1.ny.us.ibm.com (e1.ny.us.ibm.com [32.97.182.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g0LBaW321592 for ; Mon, 21 Jan 2002 03:36:32 -0800 (PST) Received: from northrelay01.pok.ibm.com (northrelay01.pok.ibm.com [9.117.200.21]) by e1.ny.us.ibm.com (8.9.3/8.9.3) with ESMTP id GAA303190 for ; Mon, 21 Jan 2002 06:33:24 -0500 Received: from d01mlc96.pok.ibm.com (d01mlc96.pok.ibm.com [9.117.250.33]) by northrelay01.pok.ibm.com (8.11.1m3/NCO v5.01) with ESMTP id g0LBaPh10972 for ; Mon, 21 Jan 2002 06:36:25 -0500 To: ietf-ldup@imc.org MIME-Version: 1.0 Subject: RE: Is State-based LDUP needed? X-Mailer: Lotus Notes Release 5.0.7 March 21, 2001 From: "Timothy Hahn" Message-ID: Date: Mon, 21 Jan 2002 06:36:13 -0500 X-MIMETrack: Serialize by Router on D01MLC96/01/M/IBM(Release 5.0.9 |November 26, 2001) at 01/21/2002 06:36:26 AM, Serialize complete at 01/21/2002 06:36:26 AM Content-Type: multipart/alternative; boundary="=_alternative 003EFA1D85256B48_=" Sender: owner-ietf-ldup@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multipart message in MIME format. --=_alternative 003EFA1D85256B48_= Content-Type: text/plain; charset="us-ascii" Steven, We're in agreement then. Regards, Tim Hahn Internet: hahnt@us.ibm.com Internal: Timothy Hahn/Endicott/IBM@IBMUS or IBMUSM00(HAHNT) phone: 607.752.6388 tie-line: 8/852.6388 fax: 607.752.3681 "Steven Legg" 01/20/2002 06:25 PM Please respond to steven.legg To: Timothy Hahn/Endicott/IBM@IBMUS cc: Subject: RE: Is State-based LDUP needed? Hi Tim, Timothy Hahn wrote: > Steven, > > I followed you all the way until the end of your note. > > I am of the opinion that updates sent during a replication session be sent > in CSN order. While this may cause "up-front" work for "state-based" > implementations, I believe that it allows consumer servers to make the most > progress possible - even if the communications link is lost before the > replication session can complete. URP will take care of the cases where > the consumer sees a CSN in an update that is "older" when sent by a > different path through the network. > > I couldn't tell in your last two paragraphs what you were asserting be > done with respect to update send (and thus expected receive) order. I wasn't so much making a specific proposal as pointing out the technical issues. Given that there will be few or no state-based implementations then I am of the opinion that we should make life easier all round by requiring that, with respect to each replica ID, updates must be sent in CSN order. We don't want to require that updates be sent in global CSN order since that would require even the log-based implementations to sort updates before sending them. Regards, Steven --=_alternative 003EFA1D85256B48_= Content-Type: text/html; charset="us-ascii"
Steven,

We're in agreement then.
Regards,
Tim Hahn

Internet: hahnt@us.ibm.com
Internal: Timothy Hahn/Endicott/IBM@IBMUS or IBMUSM00(HAHNT)
phone: 607.752.6388     tie-line: 8/852.6388
fax: 607.752.3681



"Steven Legg" <steven.legg@adacel.com.au>

01/20/2002 06:25 PM
Please respond to steven.legg

       
        To:        Timothy Hahn/Endicott/IBM@IBMUS
        cc:        <ietf-ldup@imc.org>
        Subject:        RE: Is State-based LDUP needed?

       



Hi Tim,

Timothy Hahn wrote:
> Steven,
>
> I followed you all the way until the end of your note.
>
> I am of the opinion that updates sent during a replication session be sent
> in CSN order.  While this may cause "up-front" work for "state-based"
> implementations, I believe that it allows consumer servers to make the
most
> progress possible - even if the communications link is lost before the
> replication session can complete.  URP will take care of the cases where
> the consumer sees a CSN in an update that is "older" when sent by a
> different path through the network.
>
> I couldn't tell in your last two paragraphs what you were asserting be
> done with respect to update send (and thus expected receive) order.

I wasn't so much making a specific proposal as pointing out the technical
issues. Given that there will be few or no state-based implementations
then I am of the opinion that we should make life easier all round by
requiring that, with respect to each replica ID, updates must be sent
in CSN order.

We don't want to require that updates be sent in global CSN order since
that would require even the log-based implementations to sort updates
before sending them.

Regards,
Steven

--=_alternative 003EFA1D85256B48_=-- From owner-ietf-ldup@mail.imc.org Wed Jan 23 16:01:40 2002 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA25255 for ; Wed, 23 Jan 2002 16:01:39 -0500 (EST) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g0NKYML10763 for ietf-ldup-bks; Wed, 23 Jan 2002 12:34:22 -0800 (PST) Received: from almso1.proxy.att.com (almso1.att.com [192.128.167.69]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g0NKYJ310759 for ; Wed, 23 Jan 2002 12:34:20 -0800 (PST) Received: from qsun.mt.att.com ([135.16.12.1]) by almso1.proxy.att.com (AT&T IPNS/MSO-3.0) with SMTP id g0NKWlW14478; Wed, 23 Jan 2002 15:32:48 -0500 (EST) Received: by qsun.mt.att.com (SMI-8.6/ATTEMS-1.4.1 sol2) id PAA24935; Wed, 23 Jan 2002 15:32:40 -0500 Date: Wed, 23 Jan 2002 15:32:40 -0500 Message-Id: <200201232032.PAA24935@qsun.mt.att.com> From: rvh@qsun.mt.att.com (Richard V Huber) To: ietf-ldup@imc.org Subject: Replica Management - high-level state of a replica Cc: eer@OnCallDBA.COM, hahnt@us.ibm.com, jmcmeek@us.ibm.com, rmoats@lemurnetworks.net, rvh@qsun.mt.att.com (Richard V Huber), usriniva@us.oracle.com Sender: owner-ietf-ldup@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: As we work on the next draft of MRM, we have a number of questions we would like to ask the WG and the authors of the other drafts (particularly the Architecture and InfoMod drafts). There will be a set of emails dealing with different issues coming out at odd intervals - we want to get questions on the table as soon as we can rather than wait for the one grand summary email that covers everything. So here is the first issue - it has to do with the major states of replication and how we switch among them. We see three major states that can exist: 1 - A particular instance of a directory is NOT PARTICIPATING in replication for a given area of replication and a given second instance. In this state the instance need not record change information for changes made in the context. 2 - A particular instance of a directory is PARTICIPATING but NOT ONLINE for a given area of replication and second instance. In this case changes are recorded and will be sent when the instance goes ONLINE. 3 - A particular instance is PARTICIPATING and ONLINE for a given area of replication and second instance. In this case changes are being exchanged (subject to replication schedules, etc.). It is possible for a given server to be ONLINE with some of the other servers in the replica group and NOT ONLINE with others. The fourth case (ONLINE and NOT PARTICIPATING) cannot occur. If we accept these major states, we also have to know what events trigger changes among the states. We propose the following: - A directory instance starts PARTICIPATING with a given second instance when the replicaSubentry with its replicaURI pointing to the second instance is created in the first instance. It stops PARTICIPATING when this replicaSubentry is removed. - Per InfoMod, each instance of a replica has a replicaSubentry object representing each of the replicas - one for itself and one for each of the other replicas. Each of these replicaSubentry objects contains a replicaOnline attribute. To allow control of the replication process, we propose that the replicaOnline attribute DOES NOT REPLICATE (e.g. it is a DSA-specific attribute). A directory instance A is ONLINE with a second instance B when ALL of conditions a-d below are met: a - Instance A's replicaOnline attribute for instance A is TRUE b - Instance A's replicaOnline attribute for instance B is TRUE c - Instance B's replicaOnline attribute for instance B is TRUE d - Instance B's replicaOnline attribute for instance A is TRUE So if an instance's own replicaOnline attribute is FALSE, it is NOT ONLINE with any other instance in that area of replication. Also, both participants in a replication session must agree that they are ONLINE for the session to proceed. - Since an instance starts PARTICIPATING when the replicaSubentry is created and since the replicaOnline attribute is in the replicaSubentry, it is impossible for an instance to be set ONLINE if it is NOT PARTICIPATING. Any comments? :-) A related question: - InfoMod specifies that servers MUST automatically add and delete values from the root DSE attribute replicaContextRoots. For the root DSE attribute replicaSubentries, InfoMod says that values must be automatically deleted but says nothing about automatically adding values. We hope this is a typo and would like to see entries automatically added as well as deleted. One reason this is important is that we want to allow for overlapping areas of replication per the Requirements. Since this means that a given replica context root may be the root of more than one area of replication, we feel that the area of replication is really defined by the replicaSubentry, Rick Huber John McMeeking Ryan Moats From owner-ietf-ldup@mail.imc.org Wed Jan 23 20:42:11 2002 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA01046 for ; Wed, 23 Jan 2002 20:42:11 -0500 (EST) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g0O1RbN17582 for ietf-ldup-bks; Wed, 23 Jan 2002 17:27:37 -0800 (PST) Received: from almso1.proxy.att.com (almso1.att.com [192.128.167.69]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g0O1RZ317577 for ; Wed, 23 Jan 2002 17:27:35 -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 g0O1R4W01736; Wed, 23 Jan 2002 20:27:05 -0500 (EST) Received: by qsun.mt.att.com (SMI-8.6/ATTEMS-1.4.1 sol2) id UAA17089; Wed, 23 Jan 2002 20:27:03 -0500 Date: Wed, 23 Jan 2002 20:27:03 -0500 Message-Id: <200201240127.UAA17089@qsun.mt.att.com> From: rvh@qsun.mt.att.com (Richard V Huber) To: ietf-ldup@imc.org Subject: Replica Management - subtreespecification attribute Cc: Kurt@OpenLDAP.org, eer@OnCallDBA.COM, hahnt@us.ibm.com, jmcmeek@us.ibm.com, rmoats@lemurnetworks.net, rvh@qsun.mt.att.com (Richard V Huber) Sender: owner-ietf-ldup@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: We noted in a previous email that, to allow overlapping areas of replication, we feel that an area of replication is defined by a replicaSubentry. The replicaSubentry defines the boundary of the area via the subtreespecification attribute. This attribute is inherited from the subentry objectclass defined in draft-zeilenga-ldap-subentry-00.txt. Because a subtreespecification may need to be shared across a number of subentries (e.g. all the replicaSubentries that refer to a common area of replication), we would like to have a single subtreespecification that can be referenced from multiple subentries. Accordingly, we would like to change the subentry objectclass to use subtreeSpecificationDN and allow the subtree specification to be stored as a separate entry which can be referenced as needed. This may be useful in other cases where a single subtreespecification needs to be used consistently in several places. Rick Huber John McMeeking Ryan Moats From owner-ietf-ldup@mail.imc.org Thu Jan 24 00:07:43 2002 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA06486 for ; Thu, 24 Jan 2002 00:07:42 -0500 (EST) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g0O4rR822486 for ietf-ldup-bks; Wed, 23 Jan 2002 20:53:27 -0800 (PST) Received: from kcmso1.proxy.att.com (kcmso1.att.com [192.128.133.69]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g0O4rP322481 for ; Wed, 23 Jan 2002 20:53:25 -0800 (PST) Received: from qsun.mt.att.com ([135.16.157.16]) by kcmso1.proxy.att.com (AT&T IPNS/MSO-3.0) with SMTP id g0O4qpn12324; Wed, 23 Jan 2002 23:52:52 -0500 (EST) Received: by qsun.mt.att.com (SMI-8.6/ATTEMS-1.4.1 sol2) id XAA28281; Wed, 23 Jan 2002 23:52:49 -0500 Date: Wed, 23 Jan 2002 23:52:49 -0500 Message-Id: <200201240452.XAA28281@qsun.mt.att.com> From: rvh@qsun.mt.att.com (Richard V Huber) To: ietf-ldup@imc.org Subject: Replication Management - Some questions on the Information Model Cc: eer@OnCallDBA.COM, hahnt@us.ibm.com, jmcmeek@us.ibm.com, rmoats@lemurnetworks.net, rvh@qsun.mt.att.com Sender: owner-ietf-ldup@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: A few questions on InfoMod (draft -04). 1. In Section 8.3.3 (definition of the replicaAgreementSubentry objectclass), why is replicaDN a MAY rather than a MUST? The replication agreement is useless without a replicaDN, and the text states that the replicaAgreementSubentry is ignored if the replicaDN is missing, so why not just require that it be there? 2. There are a number of attributes listed as NO-USER-MODIFICATION. They are (with section number where they are defined): attributeExclusionFilter (Section 8.2.4) attributeInclusionFilter (Section 8.2.5) replicationStatus (Section 8.2.7) replicaType (Section 8.2.8) updateVector (Section 8.2.9) secondsToWaitDefault (Section 8.2.18) secondsToWait1 (Section 8.2.19) secondsToWait2 (Section 8.2.21) Do all of these attributes really need to be unmodifiable? For adminstrative purposes, we can see some cases where replicaType or updateVector need to be changed (though only by administrators). And it's not clear to us why the filter and secondsToWait attributes need to be unmodifiable in any case. Would availability of access controls make some of these questions moot? Are some of these attributes marked NO-USER-MODIFICATION because they should only be changed by administrators? 3. The replicationStatus attribute is in the replicaAgreementSubentry. The attribute is optional and the replicationAgreementSubentry itself is optional. This means that there is no standard place where replication status can be found. Shouldn't there be some known place to check for status? Should we move replicationStatus to the replicaSubentry and make it a MUST instead of a MAY? Or do we need to define some other place where status can always be checked? 4. The replicationAgreementSubentry is optional. But the replicationCredentialsDN is in the replicationAgreementSubentry. This means that in the simple case described in Section 9, replication is unauthenticated. Is that really what we want? Rick Huber John McMeeking Ryan Moats From owner-ietf-ldup@mail.imc.org Sat Jan 26 12:04:59 2002 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA08896 for ; Sat, 26 Jan 2002 12:04:59 -0500 (EST) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g0QGk6822290 for ietf-ldup-bks; Sat, 26 Jan 2002 08:46:06 -0800 (PST) Received: from smtp.oncalldba.com (roc-24-169-98-153.rochester.rr.com [24.169.98.153]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g0QGk4322286 for ; Sat, 26 Jan 2002 08:46:04 -0800 (PST) Received: from RMINC_DOM-MTA by smtp.oncalldba.com with Novell_GroupWise; Sat, 26 Jan 2002 11:45:32 -0700 Message-Id: X-Mailer: Novell GroupWise Internet Agent 6.0 Date: Sat, 26 Jan 2002 11:45:13 -0700 From: "Ed Reed" To: Cc: Subject: RE: Is State-based LDUP needed? 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 g0QGk5322287 Sender: owner-ietf-ldup@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 8bit Hi Steven - Thanks for the lucid response. It's quite helpful to me. The gist of my comments below are that I think your 3rd way doesn't work for state-based systems that transmit updates in CSN sequence (reasons below), but it works fine for log-based systems (which I think are all anyone is planning to build, anyway). So my base question remains - why bother making a distinction at all - let's drop state-based discussion all together and concentrate on the log based system, instead. ============= I think that the crux of this difference is that I've not been thinking that statebased systems transmitted changes in strictly increasing CSN order (within some other constraints, like sending schema changes first), and I see that you MIGHT manage to do so. The statebased systems with which I am familiar (Clearinghouse, NDS) send for each entry it holds for which there are CSNs for values that indicate, by the update vector held by the supplier for the consumer, the primatives needed to bring the consumer copy of that entry "up to date" to the supplier's copy of that entry. The consumer provides the supplier a fresh snapshot of the consumer's ACTUAL update vector at the beginning of the replication session so the supplier knows if the consumer has gotten updates from others. But the sequence of changes is For each entry set of primatives end so that changes for entry A are sent together, meaning that if applied, entry A will be fully up to date and internally consistent. But that's not the fully ordered CSN sequence that a log based system will use, nor one that a statebased system trying to maintain CSN sequence will use. They will send something more like sequence of primatives in time sequence And, since the "current state" of an entry may very well have CSNs from multiple replicaIDs. In this case, if all primatives of each change have been preserved (as with a log based system), they can be applied as received and each entry will be "consistent" if not "up to date" (there may be more primatives that would have been sent "later" in the session had it not terminated. But if all primatives of each change have NOT been preserved, and the session is terminated, the consumer had better not applied ANY of the changes because to do so would have left it with SOME changes to the entry but not ALL changes to the entry (later primatives not-yet-sent which overrode unpreserved primatives may be needed to preserve entry integrity). So - I agree that there's no difference in log and state based implementations behavior in the protocol as long as the statebased system sends primatives in CSN sequence AND consumers know that they MUST NOT apply the changes unless ALL the changes in the session can be applied. If the session is interrupted, NO changes should be applied to the consumer, from the incomplete set received from the statebased supplier, because to do so could leave entries with inconsistent states. The particular case I'm worried about is this one where 3 replicas exist on 3 different servers of the same replicationArea: Server 1 (S1) creates entry A, setting two MUST attributes with correct values Server 2 (S2) receives entry A with the two values S2 modifies one of the entry A MUST values, but not the other S2 begins replication session to S3 sends the creation of A with the first MUST attribute but not the second (which has a later CSN) sends other changes aborts the transfer without having gotten to the second MUST change for A S3 now holds an invalid copy of A - it has only one MUST attribute instead of two (the second would have come if the session had been completed). S3 MUST NOT create the invalid entry A. It either needs to hold the changes from the session in suspense until it can complete the session and get the rest of the primatives, or it must forget the whole thing. Your statement "On the other hand, if the updates in a replication session are always guaranteed to be in CSN order then the consumer can just apply them as they are received. A state-based implementation can readily provide updates in CSN order by sorting them in temporary storage before sending them to the consumer." only applies if ALL the updates that apply to each entry are transmitted (not just those that have not been "masked" by subsequent updates). In your set of three approaches below, I agree that 1 and 2 work, but not 3. The statebased system can order updates in CSN order, but it can't recover the masked changes (if it could, it would be a log based system). Now - someone may have figured out how to provide for a resumption of replication sessions with statebased systems, but I don't know how it works. BUT - the real question was, if no one's doing it, why bother worring about that 3rd option - it works fine for log-based sytems, and if everyone is doing log based systems, then there's no sweat. Ed ================= Ed Reed Reed-Matthews, Inc. +1 585 624 2402 http://www.Reed-Matthews.COM Note: Area code is 585 >>> "Steven Legg" 01/18/02 12:30AM >>> Ed, Ed Reed wrote: > I asked this question at the ldup meeting on Thursday, and agreed to post > the question to the distribution list. > > Is anyone planning to implement state-based ldup? If not - that is, if there > are not going to be at least two interoperable implementations of the > proposed specification, should we not remove it from the ldup design now, > rather than later? For the most part I see the choice between a state-based implementation and a log-based implementation as an internal implementation choice and as such is out of scope for a protocol specification. To the fullest extent possible we should remove the distinction and concentrate on the externally visible behaviour of the LDUP servers. I regard it as an internal choice because about the only place where the choice of implementation manifests a difference in the external behaviour of the server is in the ordering of changes in a replication session. I have more to say about that below. > The protocol will support it, but there are certainly places in the > architecture and other documents where the different handling of change > information required by the state-based scheme adds unnecessary text if > noone is actually going to use it. I couldn't find much text in draft-ietf-ldup-model-06.txt that related specifically to log-based versus state-based implementation, and none that needed to be in the document in any case. Section 3.4 isn't needed at all. It doesn't add to the LDUP specification in any way. Regarding the last paragraph in 4.5.3: "The modifications that made up an LDAP Modify operation are presented in a sequence. This must be preserved when the resultant changes of this operation are replicated." This paragraph can be dropped, along with sections 4.5.3.1 and 4.5.3.2. URP describes how the CSNs are to be assigned such that the net effect is preserved even if the primitives for the modifications get out of order. Sections 10.3.1 (except the last paragraph) and 10.3.2 can be dropped. URP describes these two cases more precisely and more completely. > This is a pragmatic decision - I personally like state based schemes, even > though there are things (like transaction replication) that I doubt they'll > ever be able to handle well. Also, all the implementers I know are focused > on the log-based scheme, instead. It seems easier for them to get their > heads around, for some reason... > > So - I don't think it's appropriate for me to be the only one championing it, > and have reached the conclusion that if we can't find even two implementers > to build it, we should not bother including it in further work. I agree with Tim here. The requirement is to have two interoperable implementations of each of the options in the protocol. The internal details of how an each implementation supports the protocol is irrelevant. We don't necessarily need two state-based implementation to meet the interoperabiliy requirements. Aside from the ordering issue I'm not sure there is anything in the current LDUP specifications that is exclusive to state-based implementations or exclusive to log-based implementations. > > If you're planning to build it, speak up. If not, silence may well be taken > as assent to remove references to it from the various protocol documents. > > Best regards, > Ed Now for something not so completely different ... In looking over your coverage matrix I found three cases of perceived fundamental differences between log-based and state-based implementations. First of all it is important to recognize that the update vector based method of update propagation imposes certain unstated, but unavoidable constraints on the behaviour of state-based implementations, otherwise eventual consistency cannot be guaranteed. A state-based implementation is not free to send updates in a totally random order. For example, if a supplier sends updates with CSNs t1 and t3, but doesn't yet send an update with CSN t2, the consumer will nonetheless revise its update vector to the highest CSN seen, i.e. t3, and consequently will never receive the update with CSN t2. Whether the LDUP architecture says it or not, with respect to any particular replica ID, a state-based implementation is obliged to send during a replication session *all* the updates between the sent update with the least CSN and the sent update with the highest CSN. Every update sent must have a CSN greater than the highest CSN of the previous successful session and less than the least CSN of the next successful session. However, the update vector propagation method doesn't implicitly constrain implementations to send updates in CSN order within a replication session since there are at least three ways to implement a consumer such that eventual consistency is still guaranteed, even if the updates within a replication session aren't necessarily in CSN order. This applies regardless of whether the consumer is state-based or log based. The three ways are: 1) The consumer puts the incoming updates from the supplier into temporary storage without applying them or revising its update vector. Once the final update in the session has been received, the consumer sorts the updates into CSN order and then applies them in that order, revising its update vector along the way. It doesn't matter if there is a service failure during either the collect/sort phase or in the application phase. Note: as far as the ordering is concerned, it is only necessary for the updates to be in CSN order with respect to each replica ID. Updates originating from different replicas can be freely intermixed. 2) The consumer processes the entire set of updates from the session as a single atomic transaction on its internal database. That is, either all of the updates are applied and the update vector revised accordingly, or, in the event of some failure during the course of the replication session, none of the updates are applied and the update vector is not revised, i.e. all the changes are rolled back. URP ensures that the end result is the same as if the consumer applied the changes in CSN order. 3) The consumer applies updates as they are received but defers revising its update vector until the end of the replication session. In this case the consumer must make sure that it does NOT propagate to any other server any update it knows about which has a more recent CSN than the relevant CSN in its update vector. Such an update belongs to an incomplete set of changes from a failed replication session. On the other hand, if the updates in a replication session are always guaranteed to be in CSN order then the consumer can just apply them as they are received. A state-based implementation can readily provide updates in CSN order by sorting them in temporary storage before sending them to the consumer. The way I see it, it is not that state-based implementations can't meet certain requirements but rather it comes down to a question of who has to do the work (e.g. collation) so that the requirements are met. If we believe that log-based implementations will be more prevalent than state-based ones then it makes sense to put the load of collating the updates onto state-based implementations by insisting that updates are always sent in CSN order with respect to each replica ID. Now to the coverage matrix ... ------------------------------------------------------------------------ Requirement 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. Comment: Supported for log-based systems, but not state-based systems, by definition. ------------------------------------------------------------------------ If state-base suppliers always sort updates before sending them then they will satisfy SM2 directly. If consumers sort incoming replication updates before applying them, or apply them in one atomic transaction, then SM2 is effectively satisfied, whether the supplier is state-based or not. However if consumers defer revising the update vector until the end of the session then a failure part way through potentially leaves them holding some later updates without the earlier updates. The choice to implement a consumer this way is independent of whether the consumer is state-based or log-based so whether requirement SM2 is satisfied depends on how the consumer processing is implemented, rather than whether it is state-based or log-based. Disallowing 3) above or insisting that updates are always sent in CSN order with respect to each replica ID solves that problem. ------------------------------------------------------------------------ Requirement AM6: The sequence of updates to access control information (ACI) and the data controlled by that ACI MUST be maintained by replication. Comment: Not supported for State Based replication ------------------------------------------------------------------------ The arguments that apply to SM2 apply to AM6 as well. ------------------------------------------------------------------------ Requirement G2: LDAP Replication SHOULD NOT preclude support for model 1 (Transactional Consistency) in the future. Comment: ... the authors believe that there is a good chance that at least the log-based mechanism described in the architecture will be able to be extended to support replication of transactional information. We do have our doubts about the ability of any state-based replication scheme to do so, though. ------------------------------------------------------------------------ Unless people are contemplating a radical departure from the processing model described in the URP document, the essential difference between a state-based implementation and a log-based implementation is whether incoming replication primitives are saved as-is to be propagated later to other servers, or reconstructed on demand from the state information on directory data, i.e. the CSNs on entries and values, and deletion records. Note that this same state information is present even in a log-based implementation. We can think of a state-based implementation as having an effective log which is notionally constructed from this state information. The effective log becomes realized either in the supplier or the consumer depending on whether we require the supplier to do the collation of the updates. An effective log differs from a real log in two ways: 1) It contains no superseded primitives. Note that this does not make an effective log unique since a log-based supplier is permitted to strip out superseded primitives. A state-based implementation just can't avoid stripping them out. 2) It cannot preserve the exact order in which the supplier itself received the update primitives. Note that it is not necessarily the case that a log-based implementation will preserve the order either, e.g. it might have a separate log for each replica ID. The information in the logs, i.e. the set of replication primitives, is otherwise the same. Any future extension to LDUP will work for both state-based and log-based implementations if it does not rely on preservation of superseded primitives or supplier receipt order. Any mechanism that relies on receipt order is probably broken for log-based implementations anyway since multiple master servers will inevitably receive the same changes in different orders (sorted on CSN per replica ID, but not necessarily globally sorted on CSN). I have previously sketched out separate solutions for providing transactional consistency on top of LDUP, and for identifying transaction inconsistencies in the absence of support for the former. These solutions apply equally well to log-based or state-based implementations since neither depends on supplier receipt order or preservation of superseded primitives. Regards, Steven From owner-ietf-ldup@mail.imc.org Mon Jan 28 16:53:25 2002 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA09739 for ; Mon, 28 Jan 2002 16:53:24 -0500 (EST) Received: by above.proper.com (8.11.6/8.11.3) id g0SLTGa19547 for ietf-ldup-bks; Mon, 28 Jan 2002 13:29:16 -0800 (PST) Received: from pretender.boolean.net (root@router.boolean.net [198.144.206.49]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g0SLTB319541 for ; Mon, 28 Jan 2002 13:29:15 -0800 (PST) Received: from nomad.OpenLDAP.org (root@localhost [127.0.0.1]) by pretender.boolean.net (8.11.3/8.11.1/Boolean/Hub) with ESMTP id g0SLT5C89539; Mon, 28 Jan 2002 21:29:05 GMT (envelope-from Kurt@OpenLDAP.org) Message-Id: <5.1.0.14.0.20020124080630.016e5560@127.0.0.1> X-Sender: kurt@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Mon, 28 Jan 2002 13:29:31 -0800 To: rvh@qsun.mt.att.com (Richard V Huber) From: "Kurt D. Zeilenga" Subject: Re: Replica Management - subtreespecification attribute Cc: ietf-ldup@imc.org, eer@OnCallDBA.COM, hahnt@us.ibm.com, jmcmeek@us.ibm.com, rmoats@lemurnetworks.net, rvh@qsun.mt.att.com (Richard V Huber) In-Reply-To: <200201240127.UAA17089@qsun.mt.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: At 05:27 PM 2002-01-23, Richard V Huber wrote: >This attribute is inherited from the subentry objectclass defined in >draft-zeilenga-ldap-subentry-00.txt. The subentry object class is defined in X.501. The draft-zeilenga-ldap-subentry-xx.txt details how X.500 can be accessed using LDAP. While the syntaxes used in LDAP differ from those used in DAP, the semantics are basically the same. It is the authors' intent to only to define how to access the this portion of the X.500 administrative model using LDAP. Changes to the actual administrative model are, in our view, beyond the scope of this I-D. Discussion regarding such changes and/or extensions of the model should be directed to the appropriate ITU SG as the ITU has change control over X.501. I also note that X.500 administrative model allows for role specific semantics to be associated with certain aspects of the model. It might be possible, though not necessarily appropriate, to associate the desired semantics with the replication subentry object class. Kurt From owner-ietf-ldup@mail.imc.org Mon Jan 28 23:09:54 2002 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA16718 for ; Mon, 28 Jan 2002 23:09:53 -0500 (EST) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g0T3pgD29294 for ietf-ldup-bks; Mon, 28 Jan 2002 19:51:42 -0800 (PST) Received: from nexus.adacel.com (shelob.adacel.com.au [203.36.26.146] (may be forged)) by above.proper.com (8.11.6/8.11.3) with SMTP id g0T3pc329290 for ; Mon, 28 Jan 2002 19:51:38 -0800 (PST) Received: (qmail 2289 invoked from network); 29 Jan 2002 03:41:16 -0000 Received: from unknown (HELO osmium) (10.32.24.165) by nexus.adacel.com with SMTP; 29 Jan 2002 03:41:16 -0000 Reply-To: From: "Steven Legg" To: "'Ed Reed'" Cc: Subject: RE: Is State-based LDUP needed? Date: Tue, 29 Jan 2002 14:50:46 +1100 Message-ID: <004901c1a878$22d94210$a518200a@osmium.mtwav.adacel.com.au> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook 8.5, Build 4.71.2377.0 X-MimeOLE: Produced By Microsoft MimeOLE V4.72.2120.0 Importance: Normal In-Reply-To: Sender: owner-ietf-ldup@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit Ed, Ed Reed wrote: > The gist of my comments below are that I think your 3rd way > doesn't work for state-based systems that transmit updates > in CSN sequence (reasons below), but it works fine for log-based > systems (which I think are all anyone is planning to build, anyway). It depends on what we mean by "works". Detailed comments below. > > So my base question remains - why bother making a distinction at > all - let's drop state-based discussion all together and concentrate > on the log based system, instead. I think a distinction should be drawn as little as possible in the LDUP documents. It is mostly an internal implementation issue that rarely needs to be mentioned (URP is the only place where it is a practical necessity). The external behaviour that we impose on LDUP implementations does have fundamental consequences on the style of implementation and we need to consider and reach consensus on what that behaviour is to be, but most of the current state-based versus log-based text can be dropped regardless of the outcome of these discussions. In the end we just say what LDUP implementations must do, not what log-based or state-based implementations must do, and if, after due consideration of the issues, that happens to be hard or impossible for a state-based approach to achieve then so be it. More below. > > ============= > > I think that the crux of this difference is that I've not > been thinking that > statebased systems transmitted changes in strictly increasing CSN > order (within some other constraints, like sending schema > changes first), > and I see that you MIGHT manage to do so. > > The statebased systems with which I am familiar (Clearinghouse, NDS) > send for each entry it holds for which there are CSNs for values that > indicate, by the update vector held by the supplier for the consumer, > the primatives needed to bring the consumer copy of that > entry "up to date" > to the supplier's copy of that entry. The consumer provides the > supplier a fresh snapshot of the consumer's ACTUAL update vector > at the beginning of the replication session so the supplier knows if > the consumer has gotten updates from others. But the sequence > of changes is > For each entry > set of primatives > end > > so that changes for entry A are sent together, meaning that > if applied, entry A will > be fully up to date and internally consistent. > > But that's not the fully ordered CSN sequence that a log > based system will use, > nor one that a statebased system trying to maintain CSN > sequence will use. > They will send something more like > > sequence of primatives in time sequence > > And, since the "current state" of an entry may very well have > CSNs from > multiple replicaIDs. In this case, if all primatives of each > change have > been preserved (as with a log based system), they can be applied > as received and each entry will be "consistent" if not "up to > date" (there > may be more primatives that would have been sent "later" in > the session > had it not terminated. But if all primatives of each change > have NOT been > preserved, and the session is terminated, the consumer had better not > applied ANY of the changes because to do so would have left it with > SOME changes to the entry but not ALL changes to the entry (later > primatives not-yet-sent which overrode unpreserved primatives > may be needed to preserve entry integrity). > > So - I agree that there's no difference in log and state > based implementations > behavior in the protocol as long as the statebased system > sends primatives > in CSN sequence AND consumers know that they MUST NOT apply the > changes unless ALL the changes in the session can be applied. If the > session is interrupted, NO changes should be applied to the > consumer, from > the incomplete set received from the statebased supplier, because to > do so could leave entries with inconsistent states. > > The particular case I'm worried about is this one where 3 > replicas exist > on 3 different servers of the same replicationArea: > > Server 1 (S1) creates entry A, setting two MUST attributes > with correct values > Server 2 (S2) receives entry A with the two values > S2 modifies one of the entry A MUST values, but not the other > S2 begins replication session to S3 > sends the creation of A with the first MUST attribute but > not the second (which > has a later CSN) > sends other changes > aborts the transfer without having gotten to the second > MUST change for A > > S3 now holds an invalid copy of A - it has only one MUST > attribute instead of > two (the second would have come if the session had been completed). I recognize the problem, but characterize it differently. Inconsistencies of this kind are a result of superseded primitives being removed from the set of propagated changes. A pure state-based implementation cannot avoid removing the superseded primitives, however the current LDUP documents allow the log-based implementations to remove superseded primitives as well. Thus I see it as a question of whether we want to require that superseded primitives will always be sent. Removing superseded primitives has the advantage of reducing both the amount of data sent in replication sessions and the workload on the consumer. However I don't regard this advantage as compelling since I expect to be using on-change replication agreements most of the time, which leaves few opportunities for primitives to become superseded before they are fully propagated. The disadvantage is that entry internal inconsistencies of the type you describe can arise, though I don't lose sleep over them since they are transient and occur only in abnormal situations, e.g. communications failure. The inconsistencies that arise because we want to allow independent updates at multiple master servers are more significant, more prevalent, and unavoidable. > > S3 MUST NOT create the invalid entry A. It either needs to > hold the changes > from the session in suspense until it can complete the > session and get the > rest of the primatives, or it must forget the whole thing. > > Your statement "On the other hand, if the updates in a > replication session are always > guaranteed to be in CSN order then the consumer can just apply them as > they are received. A state-based implementation can readily > provide updates > in CSN order by sorting them in temporary storage before > sending them to > the consumer." > > only applies if ALL the updates that apply to each entry are > transmitted (not > just those that have not been "masked" by subsequent updates). It works in the sense that eventual consistency is achieved, but carries the risk of temporary entry inconsistencies. > > In your set of three approaches below, I agree that 1 and 2 > work, but not > 3. Note that implementation strategy (1) for consumers has exactly the same effects and consequences as requiring updates to be sent in CSN order. A supplier that is interrupted part way through sending an ordered series of changes, minus the superseded primitives, produces the same effect as a consumer using strategy (1) that fails part way through applying the same changes that it has sorted for itself first. Note, I'm assuming that the sorted list is lost when the consumer fails. Therefore if requiring updates to the sent in CSN order does not work (in the sense of not causing temporary entry internal inconsistencies) then strategy (1) does not work either. This leaves strategy (2) as the only one that "works", but I would rather live with the temporary inconsistencies, or always propagate superseded primitives, than require the whole replication session to be processed as a single transaction, as per strategy (2). > The statebased system can order updates in CSN order, but it can't > recover the masked changes (if it could, it would be a log > based system). Agreed. If we insist that superseded primitives shall always be propagated then we essentially prohibit a state-based implementation of LDUP. > > Now - someone may have figured out how to provide for a resumption of > replication sessions with statebased systems, but I don't > know how it works. I don't know how current state-based implementations do it. I'm curious to know. > > BUT - the real question was, if no one's doing it, why bother > worring about > that 3rd option - it works fine for log-based sytems, and if > everyone is > doing log based systems, then there's no sweat. I think it boils down to two questions. Q1: Do we insist that replication primitives are always sent in CSN order per replica ID ? Q2: Do we insist that superseded primitives are propagated anyway ? A "yes" answer to Q1 puts the burden of collation only on state-based supplier implementations while "no" puts the burden on every consumer implementation, whether state-based or log-based. I vote "yes" to Q1. A "yes" answer to Q2 effectively prohibits state-based implementations while "no" means that temporary entry internal inconsistencies can occur, if consumers don't process the whole replication session as a single transaction. I'm not strongly for or against, but if I have to vote it is "yes". Regards, Steven > > Ed > > > ================= > Ed Reed > Reed-Matthews, Inc. > +1 585 624 2402 > http://www.Reed-Matthews.COM > Note: Area code is 585 > > >>> "Steven Legg" 01/18/02 12:30AM >>> > > Ed, > > Ed Reed wrote: > > I asked this question at the ldup meeting on Thursday, and > agreed to post > > the question to the distribution list. > > > > Is anyone planning to implement state-based ldup? If not - > that is, if > there > > are not going to be at least two interoperable > implementations of the > > proposed specification, should we not remove it from the > ldup design now, > > rather than later? > > For the most part I see the choice between a state-based > implementation > and a log-based implementation as an internal implementation > choice and > as such is out of scope for a protocol specification. To the fullest > extent possible we should remove the distinction and > concentrate on the > externally visible behaviour of the LDUP servers. > > I regard it as an internal choice because about the only > place where the > choice of implementation manifests a difference in the > external behaviour > of the server is in the ordering of changes in a replication session. > I have more to say about that below. > > > > The protocol will support it, but there are certainly places in the > > architecture and other documents where the different > handling of change > > information required by the state-based scheme adds > unnecessary text if > > noone is actually going to use it. > > I couldn't find much text in draft-ietf-ldup-model-06.txt that related > specifically to log-based versus state-based implementation, and none > that needed to be in the document in any case. > > Section 3.4 isn't needed at all. It doesn't add to the LDUP > specification > in any way. > > Regarding the last paragraph in 4.5.3: > > "The modifications that made up an LDAP Modify operation are > presented in a sequence. This must be preserved when the > resultant changes of this operation are replicated." > > This paragraph can be dropped, along with sections 4.5.3.1 > and 4.5.3.2. > URP describes how the CSNs are to be assigned such that the net effect > is preserved even if the primitives for the modifications get > out of order. > > Sections 10.3.1 (except the last paragraph) and 10.3.2 can be dropped. > URP describes these two cases more precisely and more completely. > > > > This is a pragmatic decision - I personally like state > based schemes, even > > though there are things (like transaction replication) that I doubt > they'll > > ever be able to handle well. Also, all the implementers I know are > focused > > on the log-based scheme, instead. It seems easier for them > to get their > > heads around, for some reason... > > > > So - I don't think it's appropriate for me to be the only > one championing > it, > > and have reached the conclusion that if we can't find even two > implementers > > to build it, we should not bother including it in further work. > > I agree with Tim here. The requirement is to have two interoperable > implementations of each of the options in the protocol. The > internal details > of how an each implementation supports the protocol is > irrelevant. We don't > necessarily need two state-based implementation to meet the > interoperabiliy > requirements. Aside from the ordering issue I'm not sure > there is anything > in the current LDUP specifications that is exclusive to state-based > implementations or exclusive to log-based implementations. > > > > > If you're planning to build it, speak up. If not, silence > may well be > taken > > as assent to remove references to it from the various > protocol documents. > > > > Best regards, > > Ed > > Now for something not so completely different ... > > In looking over your coverage matrix I found three cases of perceived > fundamental differences between log-based and state-based > implementations. > > First of all it is important to recognize that the update vector based > method of update propagation imposes certain unstated, but unavoidable > constraints on the behaviour of state-based implementations, otherwise > eventual consistency cannot be guaranteed. > > A state-based implementation is not free to send updates in a totally > random order. For example, if a supplier sends updates with > CSNs t1 and > t3, but doesn't yet send an update with CSN t2, the consumer will > nonetheless revise its update vector to the highest CSN seen, i.e. t3, > and consequently will never receive the update with CSN t2. > Whether the > LDUP architecture says it or not, with respect to any particular > replica ID, a state-based implementation is obliged to send during a > replication session *all* the updates between the sent update with the > least CSN and the sent update with the highest CSN. Every update sent > must have a CSN greater than the highest CSN of the previous > successful > session and less than the least CSN of the next successful session. > > However, the update vector propagation method doesn't > implicitly constrain > implementations to send updates in CSN order within a > replication session > since there are at least three ways to implement a consumer such that > eventual > consistency is still guaranteed, even if the updates within a > replication > session aren't necessarily in CSN order. This applies > regardless of whether > the consumer is state-based or log based. > > The three ways are: > > 1) The consumer puts the incoming updates from the supplier > into temporary > storage without applying them or revising its update vector. > Once the final > update in the session has been received, the consumer sorts > the updates > into CSN order and then applies them in that order, revising > its update > vector along the way. It doesn't matter if there is a service failure > during either the collect/sort phase or in the application phase. > > Note: as far as the ordering is concerned, it is only > necessary for the > updates > to be in CSN order with respect to each replica ID. Updates > originating > from different replicas can be freely intermixed. > > 2) The consumer processes the entire set of updates from the > session as > a single atomic transaction on its internal database. That > is, either all > of the updates are applied and the update vector revised > accordingly, or, > in the event of some failure during the course of the > replication session, > none of the updates are applied and the update vector is not revised, > i.e. all the changes are rolled back. URP ensures that the > end result is > the same as if the consumer applied the changes in CSN order. > > 3) The consumer applies updates as they are received but > defers revising > its update vector until the end of the replication session. > In this case > the consumer must make sure that it does NOT propagate to any > other server > any update it knows about which has a more recent CSN than > the relevant > CSN in its update vector. Such an update belongs to an > incomplete set of > changes from a failed replication session. > > On the other hand, if the updates in a replication session are always > guaranteed to be in CSN order then the consumer can just apply them as > they are received. A state-based implementation can readily > provide updates > in CSN order by sorting them in temporary storage before > sending them to > the consumer. > > The way I see it, it is not that state-based implementations > can't meet > certain requirements but rather it comes down to a question of who has > to do the work (e.g. collation) so that the requirements are met. > If we believe that log-based implementations will be more > prevalent than > state-based ones then it makes sense to put the load of collating the > updates onto state-based implementations by insisting that updates are > always sent in CSN order with respect to each replica ID. > > Now to the coverage matrix ... > > -------------------------------------------------------------- > ---------- > Requirement 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. > > Comment: Supported for log-based systems, but not state-based systems, > by definition. > -------------------------------------------------------------- > ---------- > > If state-base suppliers always sort updates before sending > them then they > will satisfy SM2 directly. > > If consumers sort incoming replication updates before applying them, > or apply them in one atomic transaction, then SM2 is > effectively satisfied, > whether the supplier is state-based or not. > > However if consumers defer revising the update vector until the end > of the session then a failure part way through potentially leaves them > holding some later updates without the earlier updates. The choice to > implement a consumer this way is independent of whether the consumer > is state-based or log-based so whether requirement SM2 is satisfied > depends on how the consumer processing is implemented, rather than > whether it is state-based or log-based. > > Disallowing 3) above or insisting that updates are always > sent in CSN order > with respect to each replica ID solves that problem. > > -------------------------------------------------------------- > ---------- > Requirement AM6: The sequence of updates to access control information > (ACI) and the data controlled by that ACI MUST be maintained > by replication. > > Comment: Not supported for State Based replication > -------------------------------------------------------------- > ---------- > > The arguments that apply to SM2 apply to AM6 as well. > > -------------------------------------------------------------- > ---------- > Requirement G2: LDAP Replication SHOULD NOT preclude support > for model 1 > (Transactional Consistency) in the future. > > Comment: ... the authors believe that there is a good chance that at > least the log-based mechanism described in the architecture > will be able > to be extended to support replication of transactional information. > We do have our doubts about the ability of any state-based replication > scheme to do so, though. > -------------------------------------------------------------- > ---------- > > Unless people are contemplating a radical departure from the > processing > model described in the URP document, the essential difference between > a state-based implementation and a log-based implementation is whether > incoming replication primitives are saved as-is to be propagated later > to other servers, or reconstructed on demand from the state > information > on directory data, i.e. the CSNs on entries and values, and deletion > records. > Note that this same state information is present even in a log-based > implementation. > > We can think of a state-based implementation as having an > effective log > which is notionally constructed from this state information. > The effective > log becomes realized either in the supplier or the consumer > depending on > whether we require the supplier to do the collation of the updates. > > An effective log differs from a real log in two ways: > > 1) It contains no superseded primitives. Note that this does > not make an > effective log unique since a log-based supplier is permitted > to strip out > superseded primitives. A state-based implementation just can't avoid > stripping them out. > > 2) It cannot preserve the exact order in which the supplier itself > received the update primitives. Note that it is not > necessarily the case > that a log-based implementation will preserve the order > either, e.g. it > might have a separate log for each replica ID. > > The information in the logs, i.e. the set of replication primitives, > is otherwise the same. > > Any future extension to LDUP will work for both state-based > and log-based > implementations if it does not rely on preservation of > superseded primitives > or supplier receipt order. Any mechanism that relies on > receipt order is > probably broken for log-based implementations anyway since > multiple master > servers will inevitably receive the same changes in different orders > (sorted on CSN per replica ID, but not necessarily globally > sorted on CSN). > > I have previously sketched out separate solutions for providing > transactional > consistency on top of LDUP, and for identifying transaction > inconsistencies > in the absence of support for the former. These solutions > apply equally well > to log-based or state-based implementations since neither depends on > supplier receipt order or preservation of superseded primitives. > > Regards, > Steven > > From owner-ietf-ldup@mail.imc.org Tue Jan 29 00:03:00 2002 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA17589 for ; Tue, 29 Jan 2002 00:02:59 -0500 (EST) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g0T4kSd00715 for ietf-ldup-bks; Mon, 28 Jan 2002 20:46:28 -0800 (PST) Received: from nexus.adacel.com (shelob.adacel.com.au [203.36.26.146] (may be forged)) by above.proper.com (8.11.6/8.11.3) with SMTP id g0T4kQ300711 for ; Mon, 28 Jan 2002 20:46:26 -0800 (PST) Received: (qmail 6087 invoked from network); 29 Jan 2002 04:36:08 -0000 Received: from unknown (HELO osmium) (10.32.24.165) by nexus.adacel.com with SMTP; 29 Jan 2002 04:36:08 -0000 Reply-To: From: "Steven Legg" To: "'Richard V Huber'" Cc: Subject: RE: Replica Management - subtreespecification attribute Date: Tue, 29 Jan 2002 15:45:38 +1100 Message-ID: <004a01c1a87f$ccef1ca0$a518200a@osmium.mtwav.adacel.com.au> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook 8.5, Build 4.71.2377.0 X-MimeOLE: Produced By Microsoft MimeOLE V4.72.2120.0 Importance: Normal In-Reply-To: <200201240127.UAA17089@qsun.mt.att.com> Sender: owner-ietf-ldup@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit Rick, Richard V Huber wrote: > We noted in a previous email that, to allow overlapping areas of > replication, we feel that an area of replication is defined by a > replicaSubentry. The replicaSubentry defines the boundary of the area > via the subtreespecification attribute. Note that a subtree specification identifies a collection of entries, but not a subset of the attributes within them. That is, it specifies the sparseness of a partial replica. Something else in addition to the subtree specification is required to specify the fractionalness of a partial replica, i.e. the attributeExclusionFilter and attributeInclusionFilter attributes. Regarding terminology, you appear to be using "area of replication" to mean some part, possibly but not necessarily all, of the information in a replication context. Thus a single replication context can have more than one area of replication within its scope. This is what I assume it means, however areas of replication (a.k.a replication areas) are not defined in the architecture and model drafts and tend to be used as synonyms for "replication context". > Because a subtreespecification may need to be shared across a > number of > subentries (e.g. all the replicaSubentries that refer to a common area > of replication), we would like to have a single subtreespecification > that can be referenced from multiple subentries. Accordingly, we > would like to change the subentry objectclass to use > subtreeSpecificationDN and allow the subtree specification to > be stored > as a separate entry which can be referenced as needed. This separate (sub?)entry would contain the attributeExclusionFilter and attributeInclusionFilter attributes as well. An alternative to a subtreeSpecificationDN attribute would be to place the replica subentries subordinate to the (sub)entry describing their area of replication. Either way, I would support making such a change to the information model. Regards, Steven > > This may be useful in other cases where a single subtreespecification > needs to be used consistently in several places. > > Rick Huber > John McMeeking > Ryan Moats > From owner-ietf-ldup@mail.imc.org Tue Jan 29 08:48:38 2002 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA02911 for ; Tue, 29 Jan 2002 08:48:38 -0500 (EST) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g0TDYTH15354 for ietf-ldup-bks; Tue, 29 Jan 2002 05:34:29 -0800 (PST) Received: from e1.ny.us.ibm.com (e1.ny.us.ibm.com [32.97.182.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g0TDYS315346 for ; Tue, 29 Jan 2002 05:34:28 -0800 (PST) Received: from northrelay02.pok.ibm.com (northrelay02.pok.ibm.com [9.117.200.22]) by e1.ny.us.ibm.com (8.9.3/8.9.3) with ESMTP id IAA303714 for ; Tue, 29 Jan 2002 08:30:55 -0500 Received: from d01mlc96.pok.ibm.com (d01mlc96.pok.ibm.com [9.117.250.33]) by northrelay02.pok.ibm.com (8.11.1m3/NCO v5.01) with ESMTP id g0TDXvZ75992 for ; Tue, 29 Jan 2002 08:33:58 -0500 To: ietf-ldup@imc.org MIME-Version: 1.0 Subject: RE: Replica Management - subtreespecification attribute X-Mailer: Lotus Notes Release 5.0.7 March 21, 2001 From: "Timothy Hahn" Message-ID: Date: Tue, 29 Jan 2002 08:33:55 -0500 X-MIMETrack: Serialize by Router on D01MLC96/01/M/IBM(Release 5.0.9 |November 26, 2001) at 01/29/2002 08:33:58 AM, Serialize complete at 01/29/2002 08:33:58 AM Content-Type: multipart/alternative; boundary="=_alternative 0049C12385256B50_=" Sender: owner-ietf-ldup@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multipart message in MIME format. --=_alternative 0049C12385256B50_= Content-Type: text/plain; charset="us-ascii" Hi all, With respect to "area of replication" terminology used in the infomodel draft, I meant it to be synonymous with "replication context", i.e. the set of entries in the directory (or "area" in the directory) that is "covered" by the replication agreement(s) and replica subentries defined. With respect to subtreespecification, I had expected that the subtreespecification of the replicaSubentry would be the value that is used and that the value would be FORCED to be identical across all replicaSubEntry entries that have the same parent (that parent being the "root" of the replication context). I expected that each replicationAgreement would potentially have a DIFFERENT set of attributeInclusion and attributeExclusion values (or none at all) and thus allow different replicas to have different fractional characteristics. I also expected that the subtreespecification value in replicaAgreement sub entries would be IGNORED (preferably set to a zero-length value), but ignored regardless. These statements are not explicit in the infomodel draft today, thus the confusion. What is the working group's concensus on handling them? Regards, Tim Hahn Internet: hahnt@us.ibm.com Internal: Timothy Hahn/Endicott/IBM@IBMUS or IBMUSM00(HAHNT) phone: 607.752.6388 tie-line: 8/852.6388 fax: 607.752.3681 "Steven Legg" Sent by: owner-ietf-ldup@mail.imc.org 01/28/2002 11:45 PM Please respond to steven.legg To: "'Richard V Huber'" cc: Subject: RE: Replica Management - subtreespecification attribute Rick, Richard V Huber wrote: > We noted in a previous email that, to allow overlapping areas of > replication, we feel that an area of replication is defined by a > replicaSubentry. The replicaSubentry defines the boundary of the area > via the subtreespecification attribute. Note that a subtree specification identifies a collection of entries, but not a subset of the attributes within them. That is, it specifies the sparseness of a partial replica. Something else in addition to the subtree specification is required to specify the fractionalness of a partial replica, i.e. the attributeExclusionFilter and attributeInclusionFilter attributes. Regarding terminology, you appear to be using "area of replication" to mean some part, possibly but not necessarily all, of the information in a replication context. Thus a single replication context can have more than one area of replication within its scope. This is what I assume it means, however areas of replication (a.k.a replication areas) are not defined in the architecture and model drafts and tend to be used as synonyms for "replication context". > Because a subtreespecification may need to be shared across a > number of > subentries (e.g. all the replicaSubentries that refer to a common area > of replication), we would like to have a single subtreespecification > that can be referenced from multiple subentries. Accordingly, we > would like to change the subentry objectclass to use > subtreeSpecificationDN and allow the subtree specification to > be stored > as a separate entry which can be referenced as needed. This separate (sub?)entry would contain the attributeExclusionFilter and attributeInclusionFilter attributes as well. An alternative to a subtreeSpecificationDN attribute would be to place the replica subentries subordinate to the (sub)entry describing their area of replication. Either way, I would support making such a change to the information model. Regards, Steven > > This may be useful in other cases where a single subtreespecification > needs to be used consistently in several places. > > Rick Huber > John McMeeking > Ryan Moats > --=_alternative 0049C12385256B50_= Content-Type: text/html; charset="us-ascii"
Hi all,

With respect to "area of replication" terminology used in the infomodel draft, I meant it to be synonymous with "replication context", i.e. the set of entries in the directory (or "area" in the directory) that is "covered" by the replication agreement(s) and replica subentries defined.

With respect to subtreespecification, I had expected that the subtreespecification of the replicaSubentry would be the value that is used and that the value would be FORCED to be identical across all replicaSubEntry entries that have the same parent (that parent being the "root" of the replication context).

I expected that each replicationAgreement would potentially have a DIFFERENT set of attributeInclusion and attributeExclusion values (or none at all) and thus allow different replicas to have different fractional characteristics.  I also expected that the subtreespecification value in replicaAgreement sub entries would be IGNORED (preferably set to a zero-length value), but ignored regardless.

These statements are not explicit in the infomodel draft today, thus the confusion.

What is the working group's concensus on handling them?
Regards,
Tim Hahn

Internet: hahnt@us.ibm.com
Internal: Timothy Hahn/Endicott/IBM@IBMUS or IBMUSM00(HAHNT)
phone: 607.752.6388     tie-line: 8/852.6388
fax: 607.752.3681


"Steven Legg" <steven.legg@adacel.com.au>
Sent by: owner-ietf-ldup@mail.imc.org

01/28/2002 11:45 PM
Please respond to steven.legg

       
        To:        "'Richard V Huber'" <rvh@qsun.mt.att.com>
        cc:        <ietf-ldup@imc.org>
        Subject:        RE: Replica Management - subtreespecification attribute

       




Rick,

Richard V Huber wrote:
> We noted in a previous email that, to allow overlapping areas of
> replication, we feel that an area of replication is defined by a
> replicaSubentry.  The replicaSubentry defines the boundary of the area
> via the subtreespecification attribute.

Note that a subtree specification identifies a collection of entries,
but not a subset of the attributes within them. That is, it specifies the
sparseness of a partial replica. Something else in addition to the subtree
specification is required to specify the fractionalness of a partial
replica,
i.e. the attributeExclusionFilter and attributeInclusionFilter attributes.

Regarding terminology, you appear to be using "area of replication" to mean
some part, possibly but not necessarily all, of the information in a
replication
context. Thus a single replication context can have more than one area
of replication within its scope. This is what I assume it means, however
areas of replication (a.k.a replication areas) are not defined in the
architecture and model drafts and tend to be used as synonyms for
"replication context".


> Because a subtreespecification may need to be shared across a
> number of
> subentries (e.g. all the replicaSubentries that refer to a common area
> of replication), we would like to have a single subtreespecification
> that can be referenced from multiple subentries.  Accordingly, we
> would like to change the subentry objectclass to use
> subtreeSpecificationDN and allow the subtree specification to
> be stored
> as a separate entry which can be referenced as needed.

This separate (sub?)entry would contain the attributeExclusionFilter and
attributeInclusionFilter attributes as well.

An alternative to a subtreeSpecificationDN attribute would be to place
the replica subentries subordinate to the (sub)entry describing their
area of replication.

Either way, I would support making such a change to the information model.

Regards,
Steven

>
> This may be useful in other cases where a single subtreespecification
> needs to be used consistently in several places.
>
> Rick Huber
> John McMeeking
> Ryan Moats
>

--=_alternative 0049C12385256B50_=-- From owner-ietf-ldup@mail.imc.org Tue Jan 29 09:03:37 2002 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA03368 for ; Tue, 29 Jan 2002 09:03:36 -0500 (EST) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g0TDnV716998 for ietf-ldup-bks; Tue, 29 Jan 2002 05:49:31 -0800 (PST) Received: from e1.ny.us.ibm.com (e1.ny.us.ibm.com [32.97.182.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g0TDnT316990 for ; Tue, 29 Jan 2002 05:49:29 -0800 (PST) Received: from northrelay03.pok.ibm.com (northrelay03.pok.ibm.com [9.117.200.23]) by e1.ny.us.ibm.com (8.9.3/8.9.3) with ESMTP id IAA26440 for ; Tue, 29 Jan 2002 08:46:16 -0500 Received: from d01mlc96.pok.ibm.com (d01mlc96.pok.ibm.com [9.117.250.33]) by northrelay03.pok.ibm.com (8.11.1m3/NCO v5.01) with ESMTP id g0TDnII138482 for ; Tue, 29 Jan 2002 08:49:18 -0500 To: MIME-Version: 1.0 Subject: RE: Is State-based LDUP needed? X-Mailer: Lotus Notes Release 5.0.7 March 21, 2001 From: "Timothy Hahn" Message-ID: Date: Tue, 29 Jan 2002 08:49:07 -0500 X-MIMETrack: Serialize by Router on D01MLC96/01/M/IBM(Release 5.0.9 |November 26, 2001) at 01/29/2002 08:49:19 AM, Serialize complete at 01/29/2002 08:49:19 AM Content-Type: multipart/alternative; boundary="=_alternative 004A4DE385256B50_=" Sender: owner-ietf-ldup@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multipart message in MIME format. --=_alternative 004A4DE385256B50_= Content-Type: text/plain; charset="us-ascii" Hi all, Steven Legg wrote: I think it boils down to two questions. Q1: Do we insist that replication primitives are always sent in CSN order per replica ID ? Q2: Do we insist that superseded primitives are propagated anyway ? My opinion on these two questions are: Q1: I vote "yes" to this one. Q2: I could go either way on this. It would seem we would be "more correct, more of the time" if we insisted that superseded primitives are propagated - at the expense of a little more information being sent during replication sessions. However, it would appear that LDUP will work either way (after all, "eventual consistency" is what is required). Thus, I would allow this as an implementation choice - i.e. superseded primitives MAY (or MAY NOT) be propagated. I also think that it is in the best interests of all involved if the update reconciliation procedures draft (or the update replication protocol draft) points out the issues involved if superseded primitives are NOT sent. (It seems a shame that this analysis would only be documented in the mailing list archives). Regards, Tim Hahn Internet: hahnt@us.ibm.com Internal: Timothy Hahn/Endicott/IBM@IBMUS or IBMUSM00(HAHNT) phone: 607.752.6388 tie-line: 8/852.6388 fax: 607.752.3681 --=_alternative 004A4DE385256B50_= Content-Type: text/html; charset="us-ascii"
Hi all,

Steven Legg wrote:

I think it boils down to two questions.

Q1: Do we insist that replication primitives are always sent in
CSN order per replica ID ?

Q2: Do we insist that superseded primitives are propagated anyway ?
My opinion on these two questions are:

Q1: I vote "yes" to this one.

Q2: I could go either way on this.  It would seem we would be "more correct, more of the time" if we insisted that superseded primitives are propagated - at the expense of a little more information being sent during replication sessions.  However, it would appear that LDUP will work either way (after all, "eventual consistency" is what is required).  Thus, I would allow this as an implementation choice - i.e. superseded primitives MAY (or MAY NOT) be propagated.  I also think that it is in the best interests of all involved if the update reconciliation procedures draft (or the update replication protocol draft) points out the issues involved if superseded primitives are NOT sent.  (It seems a shame that this analysis would only be documented in the mailing list archives).

Regards,
Tim Hahn

Internet: hahnt@us.ibm.com
Internal: Timothy Hahn/Endicott/IBM@IBMUS or IBMUSM00(HAHNT)
phone: 607.752.6388     tie-line: 8/852.6388
fax: 607.752.3681
 --=_alternative 004A4DE385256B50_=-- From owner-ietf-ldup@mail.imc.org Tue Jan 29 17:45:49 2002 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA23461 for ; Tue, 29 Jan 2002 17:45:49 -0500 (EST) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g0TMTPb05064 for ietf-ldup-bks; Tue, 29 Jan 2002 14:29:25 -0800 (PST) Received: from nexus.adacel.com (shelob.adacel.com.au [203.36.26.146] (may be forged)) by above.proper.com (8.11.6/8.11.3) with SMTP id g0TMTG305060 for ; Tue, 29 Jan 2002 14:29:18 -0800 (PST) Received: (qmail 6242 invoked from network); 29 Jan 2002 22:18:47 -0000 Received: from unknown (HELO osmium) (10.32.24.165) by nexus.adacel.com with SMTP; 29 Jan 2002 22:18:47 -0000 Reply-To: From: "Steven Legg" To: "'Timothy Hahn'" , Subject: RE: Is State-based LDUP needed? Date: Wed, 30 Jan 2002 09:28:22 +1100 Message-ID: <002301c1a914$4350e6a0$a518200a@osmium.mtwav.adacel.com.au> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook 8.5, Build 4.71.2377.0 In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V4.72.2120.0 Importance: Normal Sender: owner-ietf-ldup@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit Tim, Timothy Hahn wrote: > Hi all, > > Steven Legg wrote: >> >> I think it boils down to two questions. >> >> Q1: Do we insist that replication primitives are always sent in >> CSN order per replica ID ? >> >> Q2: Do we insist that superseded primitives are propagated anyway ? > > My opinion on these two questions are: > > Q1: I vote "yes" to this one. > > Q2: I could go either way on this. It would seem we would be "more correct, > more of the time" if we insisted that superseded primitives are propagated - > at the expense of a little more information being sent during replication > sessions. However, it would appear that LDUP will work either way (after > all, "eventual consistency" is what is required). Thus, I would allow this > as an implementation choice - i.e. superseded primitives MAY (or MAY NOT) be > propagated. I also think that it is in the best interests of all involved if > the update reconciliation procedures draft (or the update replication > protocol draft) points out the issues involved if superseded primitives are > NOT sent. (It seems a shame that this analysis would only be documented in > the mailing list archives). I can expand the section in URP on superseded primitives to point out the issues if the consensus on Q2 is "no". If the consensus is "yes" then I will instead be taking out all the provisions for state-based implementations. Regards, Steven From owner-ietf-ldup@mail.imc.org Wed Jan 30 13:11:08 2002 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA27801 for ; Wed, 30 Jan 2002 13:11:07 -0500 (EST) Received: by above.proper.com (8.11.6/8.11.3) id g0UHunb05954 for ietf-ldup-bks; Wed, 30 Jan 2002 09:56:49 -0800 (PST) Received: from smtp.oncalldba.com (roc-24-169-98-153.rochester.rr.com [24.169.98.153]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g0UHum305950 for ; Wed, 30 Jan 2002 09:56:48 -0800 (PST) Received: from RMINC_DOM-MTA by smtp.oncalldba.com with Novell_GroupWise; Wed, 30 Jan 2002 12:56:44 -0700 Message-Id: X-Mailer: Novell GroupWise Internet Agent 6.0 Date: Wed, 30 Jan 2002 12:56:23 -0700 From: "Ed Reed" To: , , Subject: RE: Is State-based LDUP needed? 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 g0UHum305951 Sender: owner-ietf-ldup@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 8bit I'm okay with answering it "yes" to both your questions, and in so doing relegating all references state-based replication to the dust bin. I would further assert that unless at least two directory service implementors object, that the current "concensus" of "yes" to both will prevail. I don't think the plans of only one party to implement the option should result it retaining it in the face of the (a) added complexity, and (b) transient inconsistencies that would result. Ed ================= Ed Reed Reed-Matthews, Inc. +1 585 624 2402 http://www.Reed-Matthews.COM Note: Area code is 585 >>> "Steven Legg" 01/29/02 05:28PM >>> Tim, Timothy Hahn wrote: > Hi all, > > Steven Legg wrote: >> >> I think it boils down to two questions. >> >> Q1: Do we insist that replication primitives are always sent in >> CSN order per replica ID ? >> >> Q2: Do we insist that superseded primitives are propagated anyway ? > > My opinion on these two questions are: > > Q1: I vote "yes" to this one. > > Q2: I could go either way on this. It would seem we would be "more correct, > more of the time" if we insisted that superseded primitives are propagated - > at the expense of a little more information being sent during replication > sessions. However, it would appear that LDUP will work either way (after > all, "eventual consistency" is what is required). Thus, I would allow this > as an implementation choice - i.e. superseded primitives MAY (or MAY NOT) be > propagated. I also think that it is in the best interests of all involved if > the update reconciliation procedures draft (or the update replication > protocol draft) points out the issues involved if superseded primitives are > NOT sent. (It seems a shame that this analysis would only be documented in > the mailing list archives). I can expand the section in URP on superseded primitives to point out the issues if the consensus on Q2 is "no". If the consensus is "yes" then I will instead be taking out all the provisions for state-based implementations. Regards, Steven From owner-ietf-ldup@mail.imc.org Wed Jan 30 13:34:53 2002 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA28450 for ; Wed, 30 Jan 2002 13:34:53 -0500 (EST) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g0UII3i06643 for ietf-ldup-bks; Wed, 30 Jan 2002 10:18:03 -0800 (PST) Received: from smtp.oncalldba.com (roc-24-169-98-153.rochester.rr.com [24.169.98.153]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g0UII2306638 for ; Wed, 30 Jan 2002 10:18:02 -0800 (PST) Received: from RMINC_DOM-MTA by smtp.oncalldba.com with Novell_GroupWise; Wed, 30 Jan 2002 13:17:59 -0700 Message-Id: X-Mailer: Novell GroupWise Internet Agent 6.0 Date: Wed, 30 Jan 2002 13:17:48 -0700 From: "Ed Reed" To: , Subject: RE: Replica Management - subtreespecification attribute 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 g0UII2306640 Sender: owner-ietf-ldup@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 8bit remarks ================= Ed Reed Reed-Matthews, Inc. +1 585 624 2402 http://www.Reed-Matthews.COM Note: Area code is 585 >>> "Timothy Hahn" 01/29/02 08:33AM >>> Hi all, With respect to "area of replication" terminology used in the infomodel draft, I meant it to be synonymous with "replication context", i.e. the set of entries in the directory (or "area" in the directory) that is "covered" by the replication agreement(s) and replica subentries defined. Agreed. I think. But see below. With respect to subtreespecification, I had expected that the subtreespecification of the replicaSubentry would be the value that is used and that the value would be FORCED to be identical across all replicaSubEntry entries that have the same parent (that parent being the "root" of the replication context). My vision is subtly different, but depends on the authority of the "primary" master. I would treat the subtreespecification on the "primary" master replicaSubentry to be "authoritative" for the replication context, and that the subtreespecifications on other replicaSutentries for other replicas might SUBSET the one on the "primary" master, but not SUPERSET it. More naturally, it might have been easier to put a subtreespecification on the root of the replication area itself as part of an auxilliary class that designates that entry as the root of the area...but I consider that approach now depreciated in favor of using subentries... So...in the absence of a "primary" master to treat as authoritative, it would make sense that there be a possibly new subentry specifically to document the shape, extent, and scope of the replication area. Then one would look to each of the replicaSubentries to find what SUBSET of the whole replication area they held. And to the replicationAgreement subtreespecifications to find what SUBSET of the entries held by the replicas using that replication agreement are to be transmitted under the auspices of that agreement. This process of iterative refinement should keep replicas from ADDING data to the replication area, but allow them to reduce the set of data they hold from all available data. Note that if you allow each master to SUPERSET the definitions, you're implicitly providing a way to create local islands of private data...an interesting notion, but not one I'd like to experiment with, here. I have fixed clearly in my own head that there is a server somewhere that holds all the data for all the entries in the replication area. There are very interesting problems that might be solved in the area of data ownership, for instance, where that would not be the case. But I lack operational experience (or even theoretical insight) as to how to make sure that such an environment works "correctly" for some definition of "correct". I expected that each replicationAgreement would potentially have a DIFFERENT set of attributeInclusion and attributeExclusion values (or none at all) and thus allow different replicas to have different fractional characteristics. I also expected that the subtreespecification value in replicaAgreement sub entries would be IGNORED (preferably set to a zero-length value), but ignored regardless. Not ignored, but used as a scoping operator on what the replication agreements said should be included...UNLESS you allow SUPERSETTING of the subtreespecifications. I don't know how to create a coherant description of data ownership and authority where there are supersets allowed by subordinates. In my scenario, it would be as though you took a logical AND of each of the subtreespecifications involved - what you'll send on the replicationAgreement, what you hold on your replicaSubentry, what the receiver holds on their replicaSubentry, and what is defined in the authoritative subtreeSpecification for the replication area. These statements are not explicit in the infomodel draft today, thus the confusion. What is the working group's concensus on handling them? Regards, Tim Hahn Internet: hahnt@us.ibm.com Internal: Timothy Hahn/Endicott/IBM@IBMUS or IBMUSM00(HAHNT) phone: 607.752.6388 tie-line: 8/852.6388 fax: 607.752.3681 "Steven Legg" Sent by: owner-ietf-ldup@mail.imc.org 01/28/2002 11:45 PM Please respond to steven.legg To: "'Richard V Huber'" cc: Subject: RE: Replica Management - subtreespecification attribute Rick, Richard V Huber wrote: > We noted in a previous email that, to allow overlapping areas of > replication, we feel that an area of replication is defined by a > replicaSubentry. The replicaSubentry defines the boundary of the area > via the subtreespecification attribute. Note that a subtree specification identifies a collection of entries, but not a subset of the attributes within them. That is, it specifies the sparseness of a partial replica. Something else in addition to the subtree specification is required to specify the fractionalness of a partial replica, i.e. the attributeExclusionFilter and attributeInclusionFilter attributes. Regarding terminology, you appear to be using "area of replication" to mean some part, possibly but not necessarily all, of the information in a replication context. Thus a single replication context can have more than one area of replication within its scope. This is what I assume it means, however areas of replication (a.k.a replication areas) are not defined in the architecture and model drafts and tend to be used as synonyms for "replication context". > Because a subtreespecification may need to be shared across a > number of > subentries (e.g. all the replicaSubentries that refer to a common area > of replication), we would like to have a single subtreespecification > that can be referenced from multiple subentries. Accordingly, we > would like to change the subentry objectclass to use > subtreeSpecificationDN and allow the subtree specification to > be stored > as a separate entry which can be referenced as needed. This separate (sub?)entry would contain the attributeExclusionFilter and attributeInclusionFilter attributes as well. An alternative to a subtreeSpecificationDN attribute would be to place the replica subentries subordinate to the (sub)entry describing their area of replication. Either way, I would support making such a change to the information model. Regards, Steven > > This may be useful in other cases where a single subtreespecification > needs to be used consistently in several places. > > Rick Huber > John McMeeking > Ryan Moats > From owner-ietf-ldup@mail.imc.org Wed Jan 30 18:21:38 2002 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA04672 for ; Wed, 30 Jan 2002 18:21:37 -0500 (EST) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g0UN6S413307 for ietf-ldup-bks; Wed, 30 Jan 2002 15:06:28 -0800 (PST) Received: from nexus.adacel.com (shelob.adacel.com.au [203.36.26.146] (may be forged)) by above.proper.com (8.11.6/8.11.3) with SMTP id g0UN6Q313302 for ; Wed, 30 Jan 2002 15:06:26 -0800 (PST) Received: (qmail 2888 invoked from network); 30 Jan 2002 22:55:49 -0000 Received: from unknown (HELO osmium) (10.32.24.165) by nexus.adacel.com with SMTP; 30 Jan 2002 22:55:49 -0000 Reply-To: From: "Steven Legg" To: "'Ed Reed'" Cc: Subject: RE: Is State-based LDUP needed? Date: Thu, 31 Jan 2002 10:05:30 +1100 Message-ID: <002701c1a9e2$9dbb85e0$a518200a@osmium.mtwav.adacel.com.au> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook 8.5, Build 4.71.2377.0 X-MimeOLE: Produced By Microsoft MimeOLE V4.72.2120.0 In-Reply-To: Importance: Normal Sender: owner-ietf-ldup@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit Ed, Ed Reed wrote: > I'm okay with answering it "yes" to both your questions, and > in so doing > relegating all references state-based replication to the dust bin. > > I would further assert that unless at least two directory > service implementors > object, that the current "concensus" of "yes" to both will > prevail. I don't think > the plans of only one party to implement the option should > result it retaining > it in the face of the (a) added complexity, and (b) transient > inconsistencies > that would result. Okay with me. I will wait a week to see if there is any dissent, and if not, I'll rip out all the references to state-based implementations from URP. Cheers, Steven > > Ed > > ================= > Ed Reed > Reed-Matthews, Inc. > +1 585 624 2402 > http://www.Reed-Matthews.COM > Note: Area code is 585 > > >>> "Steven Legg" 01/29/02 05:28PM >>> > > > Tim, > > Timothy Hahn wrote: > > Hi all, > > > > Steven Legg wrote: > >> > >> I think it boils down to two questions. > >> > >> Q1: Do we insist that replication primitives are always sent in > >> CSN order per replica ID ? > >> > >> Q2: Do we insist that superseded primitives are propagated anyway ? > > > > My opinion on these two questions are: > > > > Q1: I vote "yes" to this one. > > > > Q2: I could go either way on this. It would seem we would be "more > correct, > > more of the time" if we insisted that superseded primitives are > propagated - > > at the expense of a little more information being sent > during replication > > sessions. However, it would appear that LDUP will work > either way (after > > all, "eventual consistency" is what is required). Thus, I > would allow > this > > as an implementation choice - i.e. superseded primitives > MAY (or MAY NOT) > be > > propagated. I also think that it is in the best interests > of all involved > if > > the update reconciliation procedures draft (or the update > replication > > protocol draft) points out the issues involved if > superseded primitives > are > > NOT sent. (It seems a shame that this analysis would only > be documented > in > > the mailing list archives). > > I can expand the section in URP on superseded primitives to > point out the > issues if the consensus on Q2 is "no". If the consensus is > "yes" then I > will instead be taking out all the provisions for state-based > implementations. > > Regards, > Steven > > > From owner-ietf-ldup@mail.imc.org Wed Jan 30 18:46:58 2002 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA04910 for ; Wed, 30 Jan 2002 18:46:58 -0500 (EST) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g0UNXfa13879 for ietf-ldup-bks; Wed, 30 Jan 2002 15:33:41 -0800 (PST) Received: from e1.ny.us.ibm.com (e1.ny.us.ibm.com [32.97.182.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g0UNXe313875 for ; Wed, 30 Jan 2002 15:33:40 -0800 (PST) Received: from northrelay01.pok.ibm.com (northrelay01.pok.ibm.com [9.117.200.21]) by e1.ny.us.ibm.com (8.9.3/8.9.3) with ESMTP id SAA421552 for ; Wed, 30 Jan 2002 18:30:30 -0500 Received: from d01mlc96.pok.ibm.com (d01mlc96.pok.ibm.com [9.117.250.33]) by northrelay01.pok.ibm.com (8.11.1m3/NCO v5.01) with ESMTP id g0UNXYn27560 for ; Wed, 30 Jan 2002 18:33:34 -0500 To: ietf-ldup@imc.org MIME-Version: 1.0 Subject: RE: Is State-based LDUP needed? X-Mailer: Lotus Notes Release 5.0.7 March 21, 2001 From: "Timothy Hahn" Message-ID: Date: Wed, 30 Jan 2002 18:33:35 -0500 X-MIMETrack: Serialize by Router on D01MLC96/01/M/IBM(Release 5.0.9 |November 26, 2001) at 01/30/2002 06:33:36 PM, Serialize complete at 01/30/2002 06:33:36 PM Content-Type: multipart/alternative; boundary="=_alternative 0081103C05256B51_=" Sender: owner-ietf-ldup@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multipart message in MIME format. --=_alternative 0081103C05256B51_= Content-Type: text/plain; charset="us-ascii" Hi all, I, as well, have no objections to answers of "yes" to both questions. Regards, Tim Hahn Internet: hahnt@us.ibm.com Internal: Timothy Hahn/Endicott/IBM@IBMUS or IBMUSM00(HAHNT) phone: 607.752.6388 tie-line: 8/852.6388 fax: 607.752.3681 "Steven Legg" Sent by: owner-ietf-ldup@mail.imc.org 01/30/2002 06:05 PM Please respond to steven.legg To: "'Ed Reed'" cc: Subject: RE: Is State-based LDUP needed? Ed, Ed Reed wrote: > I'm okay with answering it "yes" to both your questions, and > in so doing > relegating all references state-based replication to the dust bin. > > I would further assert that unless at least two directory > service implementors > object, that the current "concensus" of "yes" to both will > prevail. I don't think > the plans of only one party to implement the option should > result it retaining > it in the face of the (a) added complexity, and (b) transient > inconsistencies > that would result. Okay with me. I will wait a week to see if there is any dissent, and if not, I'll rip out all the references to state-based implementations from URP. Cheers, Steven > > Ed > > ================= > Ed Reed > Reed-Matthews, Inc. > +1 585 624 2402 > http://www.Reed-Matthews.COM > Note: Area code is 585 > > >>> "Steven Legg" 01/29/02 05:28PM >>> > > > Tim, > > Timothy Hahn wrote: > > Hi all, > > > > Steven Legg wrote: > >> > >> I think it boils down to two questions. > >> > >> Q1: Do we insist that replication primitives are always sent in > >> CSN order per replica ID ? > >> > >> Q2: Do we insist that superseded primitives are propagated anyway ? > > > > My opinion on these two questions are: > > > > Q1: I vote "yes" to this one. > > > > Q2: I could go either way on this. It would seem we would be "more > correct, > > more of the time" if we insisted that superseded primitives are > propagated - > > at the expense of a little more information being sent > during replication > > sessions. However, it would appear that LDUP will work > either way (after > > all, "eventual consistency" is what is required). Thus, I > would allow > this > > as an implementation choice - i.e. superseded primitives > MAY (or MAY NOT) > be > > propagated. I also think that it is in the best interests > of all involved > if > > the update reconciliation procedures draft (or the update > replication > > protocol draft) points out the issues involved if > superseded primitives > are > > NOT sent. (It seems a shame that this analysis would only > be documented > in > > the mailing list archives). > > I can expand the section in URP on superseded primitives to > point out the > issues if the consensus on Q2 is "no". If the consensus is > "yes" then I > will instead be taking out all the provisions for state-based > implementations. > > Regards, > Steven > > > --=_alternative 0081103C05256B51_= Content-Type: text/html; charset="us-ascii"
Hi all,

I, as well, have no objections to answers of "yes" to both questions.
Regards,
Tim Hahn

Internet: hahnt@us.ibm.com
Internal: Timothy Hahn/Endicott/IBM@IBMUS or IBMUSM00(HAHNT)
phone: 607.752.6388     tie-line: 8/852.6388
fax: 607.752.3681


"Steven Legg" <steven.legg@adacel.com.au>
Sent by: owner-ietf-ldup@mail.imc.org

01/30/2002 06:05 PM
Please respond to steven.legg

       
        To:        "'Ed Reed'" <eer@OnCallDBA.COM>
        cc:        <ietf-ldup@imc.org>
        Subject:        RE: Is State-based LDUP needed?

       




Ed,

Ed Reed wrote:
> I'm okay with answering it "yes" to both your questions, and
> in so doing
> relegating all references state-based replication to the dust bin.
>
> I would further assert that unless at least two directory
> service implementors
> object, that the current "concensus" of "yes" to both will
> prevail.  I don't think
> the plans of only one party to implement the option should
> result it retaining
> it in the face of the (a) added complexity, and (b) transient
> inconsistencies
> that would result.

Okay with me. I will wait a week to see if there is any dissent, and
if not, I'll rip out all the references to state-based implementations
from URP.

Cheers,
Steven

>
> Ed
>
> =================
> Ed Reed
> Reed-Matthews, Inc.
> +1 585 624 2402
> http://www.Reed-Matthews.COM
> Note:  Area code is 585
>
> >>> "Steven Legg" <steven.legg@adacel.com.au> 01/29/02 05:28PM >>>
>
>
> Tim,
>
> Timothy Hahn wrote:
> > Hi all,
> >
> > Steven Legg wrote:
> >>
> >> I think it boils down to two questions.
> >>
> >> Q1: Do we insist that replication primitives are always sent in
> >> CSN order per replica ID ?
> >>
> >> Q2: Do we insist that superseded primitives are propagated anyway ?
> >
> > My opinion on these two questions are:
> >
> > Q1: I vote "yes" to this one.
> >
> > Q2: I could go either way on this.  It would seem we would be "more
> correct,
> > more of the time" if we insisted that superseded primitives are
> propagated -
> > at the expense of a little more information being sent
> during replication
> > sessions.  However, it would appear that LDUP will work
> either way (after
> > all, "eventual consistency" is what is required).  Thus, I
> would allow
> this
> > as an implementation choice - i.e. superseded primitives
> MAY (or MAY NOT)
> be
> > propagated.  I also think that it is in the best interests
> of all involved
> if
> > the update reconciliation procedures draft (or the update
> replication
> > protocol draft) points out the issues involved if
> superseded primitives
> are
> > NOT sent.  (It seems a shame that this analysis would only
> be documented
> in
> > the mailing list archives).
>
> I can expand the section in URP on superseded primitives to
> point out the
> issues if the consensus on Q2 is "no". If the consensus is
> "yes" then I
> will instead be taking out all the provisions for state-based
> implementations.
>
> Regards,
> Steven
>
>
>


--=_alternative 0081103C05256B51_=--