From owner-ietf-ldup@mail.imc.org Thu Jul 5 17:41:24 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA28149 for ; Thu, 5 Jul 2001 17:41:23 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.3/8.11.3) id f65LN0e24911 for ietf-ldup-bks; Thu, 5 Jul 2001 14:23:00 -0700 (PDT) Received: from hawk.ummail.com (hawk.ummail.com [64.58.86.21]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f65LMwm24906 for ; Thu, 5 Jul 2001 14:22:59 -0700 (PDT) Received: from ex01.ummail.com [216.33.108.253:25] by hawk.ummail.com with SMTP id J0705-1722-25dc00; Thu, 5 Jul 2001 21:22:15 GMT Received: by ex01.ummail.com with Internet Mail Service (5.5.2650.21) id ; Thu, 5 Jul 2001 17:20:30 -0400 Message-ID: From: Christopher Apple To: "'Kurt D. Zeilenga'" , Christopher Apple , john.strassner@intelliden.com Cc: ietf-ldup@imc.org Subject: RE: Correction to Last Call posting Date: Thu, 5 Jul 2001 17:20:29 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) MIME-Version: 1.0 Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_0095_01C10576.C4A14E30" X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: owner-ietf-ldup@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multi-part message in MIME format. ------=_NextPart_000_0095_01C10576.C4A14E30 Content-Type: multipart/mixed; boundary="----=_NextPart_001_0096_01C10576.C4A14E30" ------=_NextPart_001_0096_01C10576.C4A14E30 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit These are the only comments we've received on this document. Because they are relatively minor and because WG consensus has already been established to not explicitly address at least one of the previously made comments, after they are all resolved - we will recommend that the IESG consider this document for publication as an Informational document without an additional WG Last Call. Comments/responses below... Chris Apple Program Manager - Directory Services United Messaging Inc. (V) 610-425-2860 >-----Original Message----- >From: Kurt D. Zeilenga [mailto:Kurt@OpenLDAP.org] >Sent: Wednesday, June 27, 2001 7:41 PM >To: Christopher Apple; john.strassner@intelliden.com >Cc: ietf-ldup@imc.org >Subject: Re: Correction to Last Call posting > > >This message mostly reiterates previously raised issues. > >Section 3: > Interoperability among directories using LDUP replication may be > limited for implementations that add semantics beyond >those specified > by the LDAP core documents (RFC 2251-2256, 2829, 2830). > >I note that Interoperability among directories using LDUP >replication >may also be limited for implementations which implement different >subsets of the semantics defined in the LDAP "core" specification. >For example, one implementation may support subtyping another not. >Another may require ;binary for some standard track attribute >while another disallows ;binary for same. As an alternative to >adding a clarification to the statement (as I would prefer), >removing the statement (as it doesn't place a requirement upon >LDUP) would be acceptable. Please propose full replacement text for the statement you are commenting on. I can't determine exactly what you are proposing to add as clarifying text based on what you wrote. This comment is unresolved. > >G9. Sentence 1. > LDAP replication SHOULD support replication of > directoryOperation and distributedOperation attribute > types defined in standards track LDAP extensions. > >I note that Dynamic Directory Services Extensions >(RFC 2589) standard track may be quite difficult to >support. No change needs to be made to the document to accommodate or account for this comment. The requirement has a force of SHOULD. This means that, provided there are good reasons for doing so, implementers wouldn't be required to support ALL such attribute types. If the words "quite difficult" turn out to mean that supporting the DDS extensions means that you can't possibly guarantee any level of replicated DIB consistency from master to slave copies - that would be a good reason not to support those extensions. The existing requirement force already allows for that sort of exception you are seeking to accommodate. I consider that comment to be resolved because no changes are needed to accommodate Kurt's concerns. > >G9. Sentence 2. > Future standards track specifications SHOULD include > a "Replication Considerations" section which indicates > how and whether the new feature operates in a replicated > environment. > >I note that this is not a requirement upon LDUP but a >requirement upon future standard track specifications >to detail how to operate in yet specified replicated >environment. I believe this should be reworded without >use of a RFC 2119 imperative or other wording implying >this is a requirement which future specifications need >to consider. If such a requirement were needed to be >stated, it should be stated in a document (BCP?) >detailing guidelines to developers of LDAP extensions. >I note that such a guideline is under development. WG Consensus was that this requirement be left in the document. Our Co-ADs are aware of the discussion and will most likely make a recommendation about where this sort of requirement belongs during their review of the document over the next few weeks. I'm not even saying that I personally disagree with Kurt's position of moving it into a different type of document. However, WG consensus indicates that it should remain in the document for now. So it will. I consider this one to be resolved with respect to the WG Last Call process because it was resolved prior to initiating the most recent one. > >M5. LDAP replication MUST NOT require all copies of the replicated >information to be complete copies of the replicated object. > The model >MUST support Partial Replicas. > >I assume this applies to copies, not to the original. >That is, I assume that LDAP replication MAY require >some master (if not all masters) to hold a complete >instance of the object. Some clarification here may >be appropriate. Please propose clarifying text explicitly so the WG can evaluate it. I can't tell quite what to suggest as clarifying text based on your comment. This issue is unresolved. > >Security Considerations: > "As noted in Section 3, security may be impacted..." > >Section 3 makes no statement about security. It makes a >statement about interoperability. Current Text: This document includes security requirements (listed in section 4.8 above) for the replication model and protocol. As noted in Section 3, security may be impacted when replicating among servers that implement non-standard extensions to basic LDAP semantics. Access control is one common case which affects security; work to address this issue is going on in LDAPEXT as documented in RFC 2820 [RFC2820]. Proposed Text to clarify the section based on Kurt's comment: This document includes security requirements (listed in section 4.8 above) for the replication model and protocol. As noted in Section 3, interoperability may be impacted when replicating among servers that implement non-standard extensions to basic LDAP semantics. Since LDAPv3 access control work is being treated as a set of standards-based extensions, security-related and even general LDUP interoperability will be significantly impacted by the degree of consistency with which LDUP implementations support the LDAPv3 access control requirements documented in RFC 2820 [RFC2820]. This issue is unresolved until we hear from at least the document editors about whether or not this proposed text fits or not. Also need some reaction from Kurt about whether this clarifies the text based on his perspective. If not, I think it would be reasonable for us to expect to see an explicit proposal for the text to be contained in the section. > >Editorial comments: > The RFC 2119 paragraph should be moved from the Abstract > to end of section 1 or added to section 2, which details > terminology used. I see no harm in moving this text. To avoid unnecessary work for the editors, I believe its most appropriate to simply move the paragraph to the end of section 1 and be done with it. I consider this issue to be resolved because it is purely editorial in nature and won't require significant work to implement in the document itself. > > "privacy" (S6,S7) should be replaced with "confidentiality". > I believe Kurt's comment is consistent with the security glossary documented in RFC 2828 - not quite sure how this was missed during similar discussions about other passages in the document. The word substitutions should be made to S6 and S7. I consider this issue to be resolved. ------=_NextPart_001_0096_01C10576.C4A14E30 Content-Type: text/x-vcard; name="Chris Apple (E-mail).vcf" Content-Disposition: attachment; filename="Chris Apple (E-mail).vcf" Content-Transfer-Encoding: quoted-printable BEGIN:VCARD VERSION:2.1 N:Apple;Chris FN:Chris Apple (E-mail) ORG:UMI TITLE:Program Manager TEL;WORK;VOICE:(610) 425-2860 TEL;HOME;VOICE:(215) 873-0850 TEL;CELL;VOICE:(610) 585-4241 TEL;WORK;FAX:(610) 425-6501 ADR;WORK:;;1161 McDermott Drive;West Chester;Pa.;19380;United States of = America LABEL;WORK;ENCODING=3DQUOTED-PRINTABLE:1161 McDermott = Drive=3D0D=3D0AWest Chester, Pa. 19380=3D0D=3D0AUnited States of Amer=3D ica EMAIL;PREF;INTERNET:christopher.apple@unitedmessaging.com REV:20010621T205341Z END:VCARD ------=_NextPart_001_0096_01C10576.C4A14E30-- ------=_NextPart_000_0095_01C10576.C4A14E30 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIF1TCCAqQw ggINoAMCAQICAwT8XjANBgkqhkiG9w0BAQQFADCBkjELMAkGA1UEBhMCWkExFTATBgNVBAgTDFdl c3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3duMQ8wDQYDVQQKEwZUaGF3dGUxHTAbBgNVBAsT FENlcnRpZmljYXRlIFNlcnZpY2VzMSgwJgYDVQQDEx9QZXJzb25hbCBGcmVlbWFpbCBSU0EgMjAw MC44LjMwMB4XDTAxMDYwODE1NDgwOVoXDTAyMDYwODE1NDgwOVowVzEfMB0GA1UEAxMWVGhhd3Rl IEZyZWVtYWlsIE1lbWJlcjE0MDIGCSqGSIb3DQEJARYlY2hyaXN0b3BoZXIuYXBwbGVAdW5pdGVk bWVzc2FnaW5nLm5ldDCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEA0wb7dpXj0lZuRfGhErPC qQTyvOGL3DHONyKLfJEfbD3A/0zqEnkjKamgGiD7PVFc0Gwok9x/2Jl/mQO52ArIPO0AkSYY/KaZ mWKaFXxh1LedYLyNb5PRe1kN6y0EAva1D4nwyZmToJMBUqLNsvMGjPmLUuBwdbHLEdAAVo7Gp6kC AwEAAaNCMEAwMAYDVR0RBCkwJ4ElY2hyaXN0b3BoZXIuYXBwbGVAdW5pdGVkbWVzc2FnaW5nLm5l dDAMBgNVHRMBAf8EAjAAMA0GCSqGSIb3DQEBBAUAA4GBAIqkT3GDgyKLYOzIJ9h/OsiFbiefYTbc ALptWnwegAeXbfjhq+BUJN2ICWxfQtTCupvAG6mW4J2qI422TLc31Gf7uu5r93ppFDrCGYAM2mgH tqKgztYQmAsGPf2TijDOeE7JRbQ7dZJu4BJvuE3SY9PdI/umjiOh/WG/gaZNdl0bMIIDKTCCApKg AwIBAgIBDDANBgkqhkiG9w0BAQQFADCB0TELMAkGA1UEBhMCWkExFTATBgNVBAgTDFdlc3Rlcm4g Q2FwZTESMBAGA1UEBxMJQ2FwZSBUb3duMRowGAYDVQQKExFUaGF3dGUgQ29uc3VsdGluZzEoMCYG A1UECxMfQ2VydGlmaWNhdGlvbiBTZXJ2aWNlcyBEaXZpc2lvbjEkMCIGA1UEAxMbVGhhd3RlIFBl cnNvbmFsIEZyZWVtYWlsIENBMSswKQYJKoZIhvcNAQkBFhxwZXJzb25hbC1mcmVlbWFpbEB0aGF3 dGUuY29tMB4XDTAwMDgzMDAwMDAwMFoXDTAyMDgyOTIzNTk1OVowgZIxCzAJBgNVBAYTAlpBMRUw EwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEPMA0GA1UEChMGVGhhd3Rl MR0wGwYDVQQLExRDZXJ0aWZpY2F0ZSBTZXJ2aWNlczEoMCYGA1UEAxMfUGVyc29uYWwgRnJlZW1h aWwgUlNBIDIwMDAuOC4zMDCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEA3jMypmPHCSVFPtJu eCdngcXaiBmClw7jRCmKYzUqbXA8+tyu9+50bzC8M5B/+TRxoKNtmPHDT6Jl2w36S/HW3WGl+YXN VZo1Gp2Sdagnrthy+boC9tewkd4c6avgGAOofENCUFGHgzzwObSbVIoTh/+zm51JZgAtCYnslGvp oWkCAwEAAaNOMEwwKQYDVR0RBCIwIKQeMBwxGjAYBgNVBAMTEVByaXZhdGVMYWJlbDEtMjk3MBIG A1UdEwEB/wQIMAYBAf8CAQAwCwYDVR0PBAQDAgEGMA0GCSqGSIb3DQEBBAUAA4GBAHMbbyZli/8V NEtZYortRL5Jx+gNu4+5DWomKmKEH7iHY3QcbbfPGlORS+HN5jjZ7VD0Omw0kqzmkpxuwSMBwgmn 70uuct0GZ/VQby5YuLYLwVBXtewc1+8XttWIm7eiiBrtOVs5fTT8tpYYJU1q9J3Fw5EvqZa4BTxS /N3pYgNIMYICqjCCAqYCAQEwgZowgZIxCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENh cGUxEjAQBgNVBAcTCUNhcGUgVG93bjEPMA0GA1UEChMGVGhhd3RlMR0wGwYDVQQLExRDZXJ0aWZp Y2F0ZSBTZXJ2aWNlczEoMCYGA1UEAxMfUGVyc29uYWwgRnJlZW1haWwgUlNBIDIwMDAuOC4zMAID BPxeMAkGBSsOAwIaBQCgggFlMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkF MQ8XDTAxMDcwNTIxMjAyMFowIwYJKoZIhvcNAQkEMRYEFFDzPO9TRRqBo3Du9N3B6gKOAjWUMFgG CSqGSIb3DQEJDzFLMEkwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwICAgCAMAcGBSsOAwIHMA0GCCqG SIb3DQMCAgEoMAcGBSsOAwIaMAoGCCqGSIb3DQIFMIGrBgkrBgEEAYI3EAQxgZ0wgZowgZIxCzAJ BgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEPMA0G A1UEChMGVGhhd3RlMR0wGwYDVQQLExRDZXJ0aWZpY2F0ZSBTZXJ2aWNlczEoMCYGA1UEAxMfUGVy c29uYWwgRnJlZW1haWwgUlNBIDIwMDAuOC4zMAIDBPxeMA0GCSqGSIb3DQEBAQUABIGAjQUp7aIK QAZuP7/ajablEnMivdrZfu0G2MfHOcS8yySIql8xSqPY7jLOgcPm2T6T0v+6ExxYjQ6lCIV3nzbF kKegbeOWnGBFLeCh2K5JJlqaKkLydUOojbup0UcGFJFHqwFrIZvdtcIuLj9Jc1tYlNoJ9AUx4qYH yhwWkgpueM4AAAAAAAA= ------=_NextPart_000_0095_01C10576.C4A14E30-- From owner-ietf-ldup@mail.imc.org Thu Jul 5 20:03:19 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA01004 for ; Thu, 5 Jul 2001 20:03:18 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.3/8.11.3) id f65NbvM27904 for ietf-ldup-bks; Thu, 5 Jul 2001 16:37:57 -0700 (PDT) Received: from pretender.boolean.net (root@router.boolean.net [198.144.206.49]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f65Nbtm27900 for ; Thu, 5 Jul 2001 16:37:55 -0700 (PDT) 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 f65NZ3A75367; Thu, 5 Jul 2001 23:35:03 GMT (envelope-from Kurt@OpenLDAP.org) Message-Id: <5.1.0.14.0.20010705154629.035af9e8@127.0.0.1> X-Sender: kurt@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Thu, 05 Jul 2001 16:34:12 -0700 To: From: "Kurt D. Zeilenga" Subject: Re: Shouls LCUP support replication? Cc: "Christopher Apple" , "'Richard Huber'" , , In-Reply-To: References: <5.1.0.14.0.20010612105554.00adec00@127.0.0.1> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-ldup@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: At 01:00 PM 6/12/2001, John Strassner wrote: >Now that we've split these into two topics, please tell me why you think >that LCUP supporting replicated environments is out of scope. There are a number of reasons why I believe LCUP need not detail support for a client updating from any replica hold a context. First and foremost is that I'd like to see LCUP work completed soon. Adding support for replicated environments will require significant more work and likely require a normative reference upon a technical specification detailing LDAP replicated environments. > If it is, then at the minimum we shouldn't have it in LDUP, That may be true. > which we all agreed many moons ago was the most appropriate wg > for this work to be in. What we agreed to a few moons ago was to engineer: A protocol that enables an LDAP client to synchronize with the content of a directory information tree (DIT) stored by an LDAP server and to be notified about the changes to that content [LDUP WG Charter]. That does imply a requirement that LCUP support replicated environments. And I do not recall any discussions regarding the need to support LDAP replication prior to the recent cookie thread. Kurt From owner-ietf-ldup@mail.imc.org Fri Jul 6 00:30:07 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id AAA06990 for ; Fri, 6 Jul 2001 00:30:06 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.3/8.11.3) id f66472u02212 for ietf-ldup-bks; Thu, 5 Jul 2001 21:07:02 -0700 (PDT) Received: from pretender.boolean.net (root@router.boolean.net [198.144.206.49]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f66470m02208 for ; Thu, 5 Jul 2001 21:07:00 -0700 (PDT) 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 f66449A76435; Fri, 6 Jul 2001 04:04:09 GMT (envelope-from Kurt@OpenLDAP.org) Message-Id: <5.1.0.14.0.20010705205725.00af1278@127.0.0.1> X-Sender: kurt@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Thu, 05 Jul 2001 21:03:13 -0700 To: From: "Kurt D. Zeilenga" Subject: Re: Separate LCUP cookie vs replication - was RE: Comments on LCUP draft - opaque cookie Cc: "Christopher Apple" , "'Richard Huber'" , , In-Reply-To: References: <5.1.0.14.0.20010612105554.00adec00@127.0.0.1> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-ldup@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: At 12:55 PM 6/12/2001, John Strassner wrote: >if you agree that the format of the cookie isn't the real issue, then >let's please separate that into two discussions: > > 1) the format of the cookie > 2) whether LCUP will support replicated environments In the absence of support for replicated environments, is there a reason to specify the format of the cookie? Kurt From owner-ietf-ldup@mail.imc.org Fri Jul 6 10:51:09 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA05361 for ; Fri, 6 Jul 2001 10:51:08 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.3/8.11.3) id f66EQUv03350 for ietf-ldup-bks; Fri, 6 Jul 2001 07:26:30 -0700 (PDT) Received: from hawk.ummail.com (hawk.ummail.com [64.58.86.57]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f66EQTm03346 for ; Fri, 6 Jul 2001 07:26:29 -0700 (PDT) Received: from ex01.ummail.com [216.33.108.253:25] by hawk.ummail.com with SMTP id I0706-1025-5e5a00; Fri, 6 Jul 2001 14:25:45 GMT Received: by ex01.ummail.com with Internet Mail Service (5.5.2650.21) id ; Fri, 6 Jul 2001 10:23:59 -0400 Message-ID: From: Christopher Apple To: "'Kurt D. Zeilenga'" , john.strassner@intelliden.com Cc: Christopher Apple , "'Richard Huber'" , ietf-ldup@imc.org, richm@iplanet.com Subject: RE: Separate LCUP cookie vs replication - was RE: Comments on LCU P draft - opaque cookie Date: Fri, 6 Jul 2001 10:23:57 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) MIME-Version: 1.0 Content-Type: multipart/signed; micalg=SHA1; boundary="----=_NextPart_000_0021_01C10605.BC7D5CA0"; protocol="application/x-pkcs7-signature" X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: owner-ietf-ldup@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multi-part message in MIME format. ------=_NextPart_000_0021_01C10605.BC7D5CA0 Content-Type: multipart/mixed; boundary="----=_NextPart_001_0022_01C10605.BC7D5CA0" ------=_NextPart_001_0022_01C10605.BC7D5CA0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit >-----Original Message----- >From: Kurt D. Zeilenga [mailto:Kurt@OpenLDAP.org] >Sent: Friday, July 06, 2001 12:03 AM >To: john.strassner@intelliden.com >Cc: Christopher Apple; 'Richard Huber'; ietf-ldup@imc.org; >richm@iplanet.com >Subject: Re: Separate LCUP cookie vs replication - was RE: >Comments on >LCUP draft - opaque cookie > > >At 12:55 PM 6/12/2001, John Strassner wrote: >>if you agree that the format of the cookie isn't the real >issue, then >>let's please separate that into two discussions: >> >> 1) the format of the cookie >> 2) whether LCUP will support replicated environments > >In the absence of support for replicated environments, >is there a reason to specify the format of the cookie? > >Kurt > See my posting related to interoperability concerns that don't necessarily have anything to do with a replicated environment: http://www.imc.org/ietf-ldup/mail-archive/msg01067.html The general answer to your question is that not specifying at least one standards-track cookie format means that LCUP interoperability will only be achieved if a few implementers decide to cooperate to make it happen. Even *if* that happens, it may or may not last beyond version 1.0 of the implementations themselves... As a WG Co-Chair, that's a situation I can't justify letting us get into without some very compelling reasons. So far, I've heard no arguments that I consider compelling enough to outweigh the risk to interoperability that an opaque cookie poses. I am definitely OK with the approach of specifying a high-level cookie structure of "-" in the LCUP spec itself and dealing with the issue of publishing one or more OIDs with associated payload syntaxes that are standards track. This approach is outlined here: http://www.imc.org/ietf-ldup/mail-archive/msg01079.html Chris Apple Program Manager - Directory Services United Messaging Inc. (V) 610-425-2860 ------=_NextPart_001_0022_01C10605.BC7D5CA0 Content-Type: text/x-vcard; name="Chris Apple (E-mail).vcf" Content-Disposition: attachment; filename="Chris Apple (E-mail).vcf" Content-Transfer-Encoding: quoted-printable BEGIN:VCARD VERSION:2.1 N:Apple;Chris FN:Chris Apple (E-mail) ORG:UMI TITLE:Program Manager TEL;WORK;VOICE:(610) 425-2860 TEL;HOME;VOICE:(215) 873-0850 TEL;CELL;VOICE:(610) 585-4241 TEL;WORK;FAX:(610) 425-6501 ADR;WORK:;;1161 McDermott Drive;West Chester;Pa.;19380;United States of = America LABEL;WORK;ENCODING=3DQUOTED-PRINTABLE:1161 McDermott = Drive=3D0D=3D0AWest Chester, Pa. 19380=3D0D=3D0AUnited States of Amer=3D ica EMAIL;PREF;INTERNET:christopher.apple@unitedmessaging.com REV:20010621T205341Z END:VCARD ------=_NextPart_001_0022_01C10605.BC7D5CA0-- ------=_NextPart_000_0021_01C10605.BC7D5CA0 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIF1TCCAqQw ggINoAMCAQICAwT8XjANBgkqhkiG9w0BAQQFADCBkjELMAkGA1UEBhMCWkExFTATBgNVBAgTDFdl c3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3duMQ8wDQYDVQQKEwZUaGF3dGUxHTAbBgNVBAsT FENlcnRpZmljYXRlIFNlcnZpY2VzMSgwJgYDVQQDEx9QZXJzb25hbCBGcmVlbWFpbCBSU0EgMjAw MC44LjMwMB4XDTAxMDYwODE1NDgwOVoXDTAyMDYwODE1NDgwOVowVzEfMB0GA1UEAxMWVGhhd3Rl IEZyZWVtYWlsIE1lbWJlcjE0MDIGCSqGSIb3DQEJARYlY2hyaXN0b3BoZXIuYXBwbGVAdW5pdGVk bWVzc2FnaW5nLm5ldDCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEA0wb7dpXj0lZuRfGhErPC qQTyvOGL3DHONyKLfJEfbD3A/0zqEnkjKamgGiD7PVFc0Gwok9x/2Jl/mQO52ArIPO0AkSYY/KaZ mWKaFXxh1LedYLyNb5PRe1kN6y0EAva1D4nwyZmToJMBUqLNsvMGjPmLUuBwdbHLEdAAVo7Gp6kC AwEAAaNCMEAwMAYDVR0RBCkwJ4ElY2hyaXN0b3BoZXIuYXBwbGVAdW5pdGVkbWVzc2FnaW5nLm5l dDAMBgNVHRMBAf8EAjAAMA0GCSqGSIb3DQEBBAUAA4GBAIqkT3GDgyKLYOzIJ9h/OsiFbiefYTbc ALptWnwegAeXbfjhq+BUJN2ICWxfQtTCupvAG6mW4J2qI422TLc31Gf7uu5r93ppFDrCGYAM2mgH tqKgztYQmAsGPf2TijDOeE7JRbQ7dZJu4BJvuE3SY9PdI/umjiOh/WG/gaZNdl0bMIIDKTCCApKg AwIBAgIBDDANBgkqhkiG9w0BAQQFADCB0TELMAkGA1UEBhMCWkExFTATBgNVBAgTDFdlc3Rlcm4g Q2FwZTESMBAGA1UEBxMJQ2FwZSBUb3duMRowGAYDVQQKExFUaGF3dGUgQ29uc3VsdGluZzEoMCYG A1UECxMfQ2VydGlmaWNhdGlvbiBTZXJ2aWNlcyBEaXZpc2lvbjEkMCIGA1UEAxMbVGhhd3RlIFBl cnNvbmFsIEZyZWVtYWlsIENBMSswKQYJKoZIhvcNAQkBFhxwZXJzb25hbC1mcmVlbWFpbEB0aGF3 dGUuY29tMB4XDTAwMDgzMDAwMDAwMFoXDTAyMDgyOTIzNTk1OVowgZIxCzAJBgNVBAYTAlpBMRUw EwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEPMA0GA1UEChMGVGhhd3Rl MR0wGwYDVQQLExRDZXJ0aWZpY2F0ZSBTZXJ2aWNlczEoMCYGA1UEAxMfUGVyc29uYWwgRnJlZW1h aWwgUlNBIDIwMDAuOC4zMDCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEA3jMypmPHCSVFPtJu eCdngcXaiBmClw7jRCmKYzUqbXA8+tyu9+50bzC8M5B/+TRxoKNtmPHDT6Jl2w36S/HW3WGl+YXN VZo1Gp2Sdagnrthy+boC9tewkd4c6avgGAOofENCUFGHgzzwObSbVIoTh/+zm51JZgAtCYnslGvp oWkCAwEAAaNOMEwwKQYDVR0RBCIwIKQeMBwxGjAYBgNVBAMTEVByaXZhdGVMYWJlbDEtMjk3MBIG A1UdEwEB/wQIMAYBAf8CAQAwCwYDVR0PBAQDAgEGMA0GCSqGSIb3DQEBBAUAA4GBAHMbbyZli/8V NEtZYortRL5Jx+gNu4+5DWomKmKEH7iHY3QcbbfPGlORS+HN5jjZ7VD0Omw0kqzmkpxuwSMBwgmn 70uuct0GZ/VQby5YuLYLwVBXtewc1+8XttWIm7eiiBrtOVs5fTT8tpYYJU1q9J3Fw5EvqZa4BTxS /N3pYgNIMYICqjCCAqYCAQEwgZowgZIxCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENh cGUxEjAQBgNVBAcTCUNhcGUgVG93bjEPMA0GA1UEChMGVGhhd3RlMR0wGwYDVQQLExRDZXJ0aWZp Y2F0ZSBTZXJ2aWNlczEoMCYGA1UEAxMfUGVyc29uYWwgRnJlZW1haWwgUlNBIDIwMDAuOC4zMAID BPxeMAkGBSsOAwIaBQCgggFlMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkF MQ8XDTAxMDcwNjE0MjM0NFowIwYJKoZIhvcNAQkEMRYEFNnfM/iLjA6G0zZmOMov23zxHejuMFgG CSqGSIb3DQEJDzFLMEkwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwICAgCAMAcGBSsOAwIHMA0GCCqG SIb3DQMCAgEoMAcGBSsOAwIaMAoGCCqGSIb3DQIFMIGrBgkrBgEEAYI3EAQxgZ0wgZowgZIxCzAJ BgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEPMA0G A1UEChMGVGhhd3RlMR0wGwYDVQQLExRDZXJ0aWZpY2F0ZSBTZXJ2aWNlczEoMCYGA1UEAxMfUGVy c29uYWwgRnJlZW1haWwgUlNBIDIwMDAuOC4zMAIDBPxeMA0GCSqGSIb3DQEBAQUABIGAHHGWg6mO XCS72oWgg36IXVakfrMzUZCAu1ZWIjMyWuR1a/Rdpnagxu3BZ06aEABcnHLcMF9d8J01AMYr6lkn YzSIGqaqVmbch3Yqz3zPoVsxA7rncJYLQ3Bas7LbbTBa+onAi+cMJ/nk9WfwgMNrGAaUJFEz5wBM aluutx6qtUsAAAAAAAA= ------=_NextPart_000_0021_01C10605.BC7D5CA0-- From owner-ietf-ldup@mail.imc.org Fri Jul 6 11:31:51 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA08400 for ; Fri, 6 Jul 2001 11:31:50 -0400 (EDT) Received: by above.proper.com (8.11.3/8.11.3) id f66FF8I04551 for ietf-ldup-bks; Fri, 6 Jul 2001 08:15:08 -0700 (PDT) Received: from netscape.com (c3po.netscape.com [205.217.237.46]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f66FF6m04547 for ; Fri, 6 Jul 2001 08:15:06 -0700 (PDT) Received: from judge.mcom.com (judge.mcom.com [205.217.237.53]) by netscape.com (8.10.0/8.10.0) with ESMTP id f66FF1Y18183 for ; Fri, 6 Jul 2001 08:15:01 -0700 (PDT) Received: from netscape.com ([207.1.144.19]) by judge.mcom.com (Netscape Messaging Server 4.15) with ESMTP id GG251102.RUX; Fri, 6 Jul 2001 08:15:01 -0700 Message-ID: <3B45D5F3.B4186562@netscape.com> Date: Fri, 06 Jul 2001 11:14:59 -0400 From: mcs@netscape.com (Mark C Smith) Organization: iPlanet E-Commerce Solutions X-Mailer: Mozilla 4.77 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Christopher Apple CC: "'Kurt D. Zeilenga'" , john.strassner@intelliden.com, "'Richard Huber'" , ietf-ldup@imc.org, richm@iplanet.com Subject: Re: Separate LCUP cookie vs replication - was RE: Comments on LCUP draft - opaque cookie References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-ldup@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit Christopher Apple wrote: > > The general answer to your question is that not specifying > at least one standards-track cookie format means that > LCUP interoperability will only be achieved if a few > implementers decide to cooperate to make it happen. Even > *if* that happens, it may or may not last beyond > version 1.0 of the implementations themselves... > > As a WG Co-Chair, that's a situation I can't justify > letting us get into without some very compelling reasons. > > So far, I've heard no arguments that I consider compelling > enough to outweigh the risk to interoperability that > an opaque cookie poses. Consider these two scenarios: 1) Vendor A's LCUP client synchronizes (perhaps repeatedly) with vendor B's LCUP server implementation. Interoperability is achieved if the cookie format is opaque or if the client and the server both implement a common cookie format. 2) Vendor A's LCUP client synchronizes with vendor B's LCUP server. Later, the same client tries to synchronize using the same search criteria with vendor C's LCUP server (presumably vendor C's server holds a replica of the content). If server B and C both support the same cookie format, the LCUP session with server C will ideally be an incremental synchronization. If a common cookie format is not supported or used by the two servers, the synchronization session with server C will have to be a full synchronization. Note that scenario 1 argues for defining an opaque cookie format while scenario 2 argues for exposing the contents of the cookie format (likely based on the replication model used by the two servers, e.g., LDUP). > I am definitely OK with the approach of specifying a high-level > cookie structure of "-" in the LCUP spec itself > and dealing with the issue of publishing one or more OIDs with > associated payload syntaxes that are standards track. > > This approach is outlined here: > > http://www.imc.org/ietf-ldup/mail-archive/msg01079.html This approach has been adopted by the LCUP document authors. A new I-D will be published very soon. -Mark Smith Netscape From owner-ietf-ldup@mail.imc.org Fri Jul 6 11:42:39 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA08976 for ; Fri, 6 Jul 2001 11:42:38 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.3/8.11.3) id f66FMx204723 for ietf-ldup-bks; Fri, 6 Jul 2001 08:22:59 -0700 (PDT) Received: from pretender.boolean.net (root@router.boolean.net [198.144.206.49]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f66FMvm04719 for ; Fri, 6 Jul 2001 08:22:57 -0700 (PDT) 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 f66FK5A78035; Fri, 6 Jul 2001 15:20:05 GMT (envelope-from Kurt@OpenLDAP.org) Message-Id: <5.1.0.14.0.20010706081015.0316d098@127.0.0.1> X-Sender: kurt@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Fri, 06 Jul 2001 08:19:07 -0700 To: Christopher Apple From: "Kurt D. Zeilenga" Subject: RE: Separate LCUP cookie vs replication - was RE: Comments on LCU P draft - opaque cookie Cc: john.strassner@intelliden.com, Christopher Apple , "'Richard Huber'" , ietf-ldup@imc.org, richm@iplanet.com In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-ldup@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Well, my concern is that by labeling a value (the cookie) which the client should not care about will lead to interoperability problems as clients will start caring about a label which shouldn't matter. As the value of the cookie matters to the protocol peer which generated it, the label seems quite pointless to me. However, as long as there is language added to the text stating that the label is irrelevant to the clients implementing this specification, I can live with it. Kurt From owner-ietf-ldup@mail.imc.org Fri Jul 6 11:45:33 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA09084 for ; Fri, 6 Jul 2001 11:45:32 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.3/8.11.3) id f66FR1105052 for ietf-ldup-bks; Fri, 6 Jul 2001 08:27:01 -0700 (PDT) Received: from netscape.com (r2d2.netscape.com [205.217.237.47]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f66FQxm05045 for ; Fri, 6 Jul 2001 08:26:59 -0700 (PDT) Received: from dredd.mcom.com (dredd.mcom.com [205.217.237.54]) by netscape.com (8.10.0/8.10.0) with ESMTP id f66FQsr26934 for ; Fri, 6 Jul 2001 08:26:54 -0700 (PDT) Received: from netscape.com ([205.217.229.100]) by dredd.mcom.com (Netscape Messaging Server 4.15) with ESMTP id GG25KT00.GLN; Fri, 6 Jul 2001 08:26:53 -0700 Message-ID: <3B45D841.902BFE46@netscape.com> Date: Fri, 06 Jul 2001 09:24:49 -0600 From: richm@netscape.com (Rich Megginson) Reply-To: richm@iplanet.com Organization: iPlanet - Directory Server X-Mailer: Mozilla 4.76 [en] (WinNT; U) X-Accept-Language: en,pdf MIME-Version: 1.0 To: "Kurt D. Zeilenga" CC: Christopher Apple , john.strassner@intelliden.com, "'Richard Huber'" , ietf-ldup@imc.org, richm@iplanet.com Subject: Re: Separate LCUP cookie vs replication - was RE: Comments onLCU P draft - opaque cookie References: <5.1.0.14.0.20010706081015.0316d098@127.0.0.1> Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms3FDD51728499975EBE137C8C" Sender: owner-ietf-ldup@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a cryptographically signed message in MIME format. --------------ms3FDD51728499975EBE137C8C Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit I think the language in our (the LCUP authors') working version of the draft is sufficient. As Mark said, the new version will be out shortly. "Kurt D. Zeilenga" wrote: > Well, my concern is that by labeling a value (the cookie) > which the client should not care about will lead to > interoperability problems as clients will start caring > about a label which shouldn't matter. As the value of > the cookie matters to the protocol peer which generated > it, the label seems quite pointless to me. However, as > long as there is language added to the text stating that > the label is irrelevant to the clients implementing this > specification, I can live with it. > > Kurt --------------ms3FDD51728499975EBE137C8C Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature Content-Transfer-Encoding: base64 MIIJFwYJKoZIhvcNAQcCoIIJCDCCCQQCAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3DQEHAaCC BuowggMMMIICdaADAgECAgI4bjANBgkqhkiG9w0BAQQFADCBkzELMAkGA1UEBhMCVVMxCzAJ BgNVBAgTAkNBMRYwFAYDVQQHEw1Nb3VudGFpbiBWaWV3MRswGQYDVQQKExJBbWVyaWNhIE9u bGluZSBJbmMxGTAXBgNVBAsTEEFPTCBUZWNobm9sb2dpZXMxJzAlBgNVBAMTHkludHJhbmV0 IENlcnRpZmljYXRlIEF1dGhvcml0eTAeFw0wMTA2MDQxMzIzNTlaFw0wMTEyMDExMzIzNTla MIGCMRMwEQYKCZImiZPyLGQBGRYDY29tMRgwFgYKCZImiZPyLGQBGRYIbmV0c2NhcGUxITAf BgkqhkiG9w0BCQEWEnJpY2htQG5ldHNjYXBlLmNvbTEXMBUGA1UEAxMOUmljaCBNZWdnaW5z b24xFTATBgoJkiaJk/IsZAEBEwVyaWNobTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEA vzzOOuvTS4h7GhcAGzqVeimRSAAhcKDPG9I3nBzbjyhahyg1l+9jL3aWxzjZTeUc3mAvWuoK 3NsNsI6N4MV9kH2NDUEEw3GsSweDEU6MFBwPA2YCxa8Ct0NkR+VRWG/YfUalO/OqROKZ5KBY tiJCR31RQ5Iiwxe4ZgPVfrYoVzUCAwEAAaN+MHwwEQYJYIZIAYb4QgEBBAQDAgWgMA4GA1Ud DwEB/wQEAwIF4DA2BggrBgEFBQcBAQQqMCgwJgYIKwYBBQUHMAGGGmh0dHA6Ly9uc29jc3Au bmV0c2NhcGUuY29tMB8GA1UdIwQYMBaAFCnbsi2Dfn+LI7vCzGa5Oegp8wKGMA0GCSqGSIb3 DQEBBAUAA4GBAMkxCPa1hNJmPODo+PvjDyGxRdXIKlgcbWMDuoBVZ7OulY006Jg02nnvwNnq q8wLIciyyjVP1rTpHsBApNCGxkRa5Oc5sCetbnyP5ZIOBCaOe0Bh/IWDDTHl3y9HTWmNxX8b OPkzNkWGigfW45m2Xr3lTjnUhXdFgt4QU57EbizQMIID1jCCAz+gAwIBAgIEAgAB5jANBgkq hkiG9w0BAQUFADBFMQswCQYDVQQGEwJVUzEYMBYGA1UEChMPR1RFIENvcnBvcmF0aW9uMRww GgYDVQQDExNHVEUgQ3liZXJUcnVzdCBSb290MB4XDTAxMDYwMTEyNDcwMFoXDTA0MDYwMTIz NTkwMFowgZMxCzAJBgNVBAYTAlVTMQswCQYDVQQIEwJDQTEWMBQGA1UEBxMNTW91bnRhaW4g VmlldzEbMBkGA1UEChMSQW1lcmljYSBPbmxpbmUgSW5jMRkwFwYDVQQLExBBT0wgVGVjaG5v bG9naWVzMScwJQYDVQQDEx5JbnRyYW5ldCBDZXJ0aWZpY2F0ZSBBdXRob3JpdHkwgZ8wDQYJ KoZIhvcNAQEBBQADgY0AMIGJAoGBAOLvXyx2Q4lLGl+z5fiqb4svgU1n/71KD2MuxNyF9p4s SSYg/wAX5IiIad79g1fgoxEZEarW3Lzvs9IVLlTGbny/2bnDRtMJBYTlU1xI7YSFmg47PRYH XPCzeauaEKW8waTReEwG5WRB/AUlYybr7wzHblShjM5UV7YfktqyEkuNAgMBAAGjggGCMIIB fjBNBgNVHR8ERjBEMEKgQKA+hjxodHRwOi8vd3d3MS51cy1ob3N0aW5nLmJhbHRpbW9yZS5j b20vY2dpLWJpbi9DUkwvR1RFUm9vdC5jZ2kwHQYDVR0OBBYEFCnbsi2Dfn+LI7vCzGa5Oegp 8wKGMGYGA1UdIARfMF0wRgYKKoZIhvhjAQIBBTA4MDYGCCsGAQUFBwIBFipodHRwOi8vd3d3 LmJhbHRpbW9yZS5jb20vQ1BTL09tbmlSb290Lmh0bWwwEwYDKgMEMAwwCgYIKwYBBQUHAgEw WAYDVR0jBFEwT6FJpEcwRTELMAkGA1UEBhMCVVMxGDAWBgNVBAoTD0dURSBDb3Jwb3JhdGlv bjEcMBoGA1UEAxMTR1RFIEN5YmVyVHJ1c3QgUm9vdIICAaMwKwYDVR0QBCQwIoAPMjAwMTA2 MDExMjQ3MzBagQ8yMDAzMDkwMTIzNTkwMFowDgYDVR0PAQH/BAQDAgEGMA8GA1UdEwQIMAYB Af8CAQEwDQYJKoZIhvcNAQEFBQADgYEASmIO2fpGdwQKbA3d/tIiOZkQCq6ILYY9V4TmEiQ3 aftZXuIRsPmfpFeGimkfBmPRfe4zNkkQIA8flxcsJ2w9bDkEe+JF6IcbVLZgQW0drgXznfk6 NJrje2tMcfjrqCuDsDWQTBloce3wYyJewlvsIHq1sFFz6QfugWd2eVP3ldQxggH1MIIB8QIB ATCBmjCBkzELMAkGA1UEBhMCVVMxCzAJBgNVBAgTAkNBMRYwFAYDVQQHEw1Nb3VudGFpbiBW aWV3MRswGQYDVQQKExJBbWVyaWNhIE9ubGluZSBJbmMxGTAXBgNVBAsTEEFPTCBUZWNobm9s b2dpZXMxJzAlBgNVBAMTHkludHJhbmV0IENlcnRpZmljYXRlIEF1dGhvcml0eQICOG4wCQYF Kw4DAhoFAKCBsTAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0w MTA3MDYxNTI0NDlaMCMGCSqGSIb3DQEJBDEWBBSj+EX84SjBoUS6/ZdgxSpiR62hBzBSBgkq hkiG9w0BCQ8xRTBDMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDAHBgUrDgMCBzANBggq hkiG9w0DAgIBQDANBggqhkiG9w0DAgIBKDANBgkqhkiG9w0BAQEFAASBgK3xjzXznDPnyH9m ZIQQXXdfmn9nXAREbr/Am327ZfaMEOCYRiFEGF18XzNwIetN+sske15OHK8PFZ8XxMvxzdLm 9mKDdKiZ78blxYQPAjuis0KnKFbHCK+kusmut0Qe8E8SvEQ0SiXovd+MC4U+g124khL9Xozp ZlgdlsqNDqCp --------------ms3FDD51728499975EBE137C8C-- From owner-ietf-ldup@mail.imc.org Fri Jul 6 12:37:41 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA11939 for ; Fri, 6 Jul 2001 12:37:40 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.3/8.11.3) id f66GE3D09740 for ietf-ldup-bks; Fri, 6 Jul 2001 09:14:03 -0700 (PDT) Received: from hawk.ummail.com (hawk.ummail.com [64.58.86.58]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f66GE2m09736 for ; Fri, 6 Jul 2001 09:14:02 -0700 (PDT) Received: from ex01.ummail.com [216.33.108.253:25] by hawk.ummail.com with SMTP id B0706-1213-64a300; Fri, 6 Jul 2001 16:13:15 GMT Received: by ex01.ummail.com with Internet Mail Service (5.5.2650.21) id ; Fri, 6 Jul 2001 12:11:29 -0400 Message-ID: From: Christopher Apple To: "'richm@iplanet.com'" , "Kurt D. Zeilenga" Cc: Christopher Apple , john.strassner@intelliden.com, "'Richard Huber'" , ietf-ldup@imc.org Subject: RE: Separate LCUP cookie vs replication - was RE: Comments onLCU P draft - opaque cookie Date: Fri, 6 Jul 2001 12:11:20 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) MIME-Version: 1.0 Content-Type: multipart/signed; micalg=SHA1; boundary="----=_NextPart_000_004C_01C10614.BCC2A530"; protocol="application/x-pkcs7-signature" X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: owner-ietf-ldup@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multi-part message in MIME format. ------=_NextPart_000_004C_01C10614.BCC2A530 Content-Type: multipart/mixed; boundary="----=_NextPart_001_004D_01C10614.BCC5B270" ------=_NextPart_001_004D_01C10614.BCC5B270 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit The guidelines I recommended for modifying the document have been adopted by the document editors. Specifically about the label/OID, these guidelines indicate that the document should describe how implementations are to respond when they encounter labels/OIDs that they do not natively support or understand. That is quite different than stating formally in the spec that the labels are irrelevant. As a co-chair, I wouldn't recommend that a WG document be considered for IESG Last Call if it had features explicitly specified, but specified as irrelevant. Chris Apple Program Manager - Directory Services United Messaging Inc. (V) 610-425-2860 >-----Original Message----- >From: richm@netscape.com [mailto:richm@netscape.com] >Sent: Friday, July 06, 2001 11:25 AM >To: Kurt D. Zeilenga >Cc: Christopher Apple; john.strassner@intelliden.com; >'Richard Huber'; >ietf-ldup@imc.org; richm@iplanet.com >Subject: Re: Separate LCUP cookie vs replication - was RE: Comments >onLCU P draft - opaque cookie > > >I think the language in our (the LCUP authors') working >version of the draft is sufficient. As Mark said, the new >version will be >out shortly. > >"Kurt D. Zeilenga" wrote: > >> Well, my concern is that by labeling a value (the cookie) >> which the client should not care about will lead to >> interoperability problems as clients will start caring >> about a label which shouldn't matter. As the value of >> the cookie matters to the protocol peer which generated >> it, the label seems quite pointless to me. However, as >> long as there is language added to the text stating that >> the label is irrelevant to the clients implementing this >> specification, I can live with it. >> >> Kurt > ------=_NextPart_001_004D_01C10614.BCC5B270 Content-Type: text/x-vcard; name="Chris Apple (E-mail).vcf" Content-Disposition: attachment; filename="Chris Apple (E-mail).vcf" Content-Transfer-Encoding: quoted-printable BEGIN:VCARD VERSION:2.1 N:Apple;Chris FN:Chris Apple (E-mail) ORG:UMI TITLE:Program Manager TEL;WORK;VOICE:(610) 425-2860 TEL;HOME;VOICE:(215) 873-0850 TEL;CELL;VOICE:(610) 585-4241 TEL;WORK;FAX:(610) 425-6501 ADR;WORK:;;1161 McDermott Drive;West Chester;Pa.;19380;United States of = America LABEL;WORK;ENCODING=3DQUOTED-PRINTABLE:1161 McDermott = Drive=3D0D=3D0AWest Chester, Pa. 19380=3D0D=3D0AUnited States of Amer=3D ica EMAIL;PREF;INTERNET:christopher.apple@unitedmessaging.com REV:20010621T205341Z END:VCARD ------=_NextPart_001_004D_01C10614.BCC5B270-- ------=_NextPart_000_004C_01C10614.BCC2A530 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIF1TCCAqQw ggINoAMCAQICAwT8XjANBgkqhkiG9w0BAQQFADCBkjELMAkGA1UEBhMCWkExFTATBgNVBAgTDFdl c3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3duMQ8wDQYDVQQKEwZUaGF3dGUxHTAbBgNVBAsT FENlcnRpZmljYXRlIFNlcnZpY2VzMSgwJgYDVQQDEx9QZXJzb25hbCBGcmVlbWFpbCBSU0EgMjAw MC44LjMwMB4XDTAxMDYwODE1NDgwOVoXDTAyMDYwODE1NDgwOVowVzEfMB0GA1UEAxMWVGhhd3Rl IEZyZWVtYWlsIE1lbWJlcjE0MDIGCSqGSIb3DQEJARYlY2hyaXN0b3BoZXIuYXBwbGVAdW5pdGVk bWVzc2FnaW5nLm5ldDCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEA0wb7dpXj0lZuRfGhErPC qQTyvOGL3DHONyKLfJEfbD3A/0zqEnkjKamgGiD7PVFc0Gwok9x/2Jl/mQO52ArIPO0AkSYY/KaZ mWKaFXxh1LedYLyNb5PRe1kN6y0EAva1D4nwyZmToJMBUqLNsvMGjPmLUuBwdbHLEdAAVo7Gp6kC AwEAAaNCMEAwMAYDVR0RBCkwJ4ElY2hyaXN0b3BoZXIuYXBwbGVAdW5pdGVkbWVzc2FnaW5nLm5l dDAMBgNVHRMBAf8EAjAAMA0GCSqGSIb3DQEBBAUAA4GBAIqkT3GDgyKLYOzIJ9h/OsiFbiefYTbc ALptWnwegAeXbfjhq+BUJN2ICWxfQtTCupvAG6mW4J2qI422TLc31Gf7uu5r93ppFDrCGYAM2mgH tqKgztYQmAsGPf2TijDOeE7JRbQ7dZJu4BJvuE3SY9PdI/umjiOh/WG/gaZNdl0bMIIDKTCCApKg AwIBAgIBDDANBgkqhkiG9w0BAQQFADCB0TELMAkGA1UEBhMCWkExFTATBgNVBAgTDFdlc3Rlcm4g Q2FwZTESMBAGA1UEBxMJQ2FwZSBUb3duMRowGAYDVQQKExFUaGF3dGUgQ29uc3VsdGluZzEoMCYG A1UECxMfQ2VydGlmaWNhdGlvbiBTZXJ2aWNlcyBEaXZpc2lvbjEkMCIGA1UEAxMbVGhhd3RlIFBl cnNvbmFsIEZyZWVtYWlsIENBMSswKQYJKoZIhvcNAQkBFhxwZXJzb25hbC1mcmVlbWFpbEB0aGF3 dGUuY29tMB4XDTAwMDgzMDAwMDAwMFoXDTAyMDgyOTIzNTk1OVowgZIxCzAJBgNVBAYTAlpBMRUw EwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEPMA0GA1UEChMGVGhhd3Rl MR0wGwYDVQQLExRDZXJ0aWZpY2F0ZSBTZXJ2aWNlczEoMCYGA1UEAxMfUGVyc29uYWwgRnJlZW1h aWwgUlNBIDIwMDAuOC4zMDCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEA3jMypmPHCSVFPtJu eCdngcXaiBmClw7jRCmKYzUqbXA8+tyu9+50bzC8M5B/+TRxoKNtmPHDT6Jl2w36S/HW3WGl+YXN VZo1Gp2Sdagnrthy+boC9tewkd4c6avgGAOofENCUFGHgzzwObSbVIoTh/+zm51JZgAtCYnslGvp oWkCAwEAAaNOMEwwKQYDVR0RBCIwIKQeMBwxGjAYBgNVBAMTEVByaXZhdGVMYWJlbDEtMjk3MBIG A1UdEwEB/wQIMAYBAf8CAQAwCwYDVR0PBAQDAgEGMA0GCSqGSIb3DQEBBAUAA4GBAHMbbyZli/8V NEtZYortRL5Jx+gNu4+5DWomKmKEH7iHY3QcbbfPGlORS+HN5jjZ7VD0Omw0kqzmkpxuwSMBwgmn 70uuct0GZ/VQby5YuLYLwVBXtewc1+8XttWIm7eiiBrtOVs5fTT8tpYYJU1q9J3Fw5EvqZa4BTxS /N3pYgNIMYICqjCCAqYCAQEwgZowgZIxCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENh cGUxEjAQBgNVBAcTCUNhcGUgVG93bjEPMA0GA1UEChMGVGhhd3RlMR0wGwYDVQQLExRDZXJ0aWZp Y2F0ZSBTZXJ2aWNlczEoMCYGA1UEAxMfUGVyc29uYWwgRnJlZW1haWwgUlNBIDIwMDAuOC4zMAID BPxeMAkGBSsOAwIaBQCgggFlMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkF MQ8XDTAxMDcwNjE2MTEwN1owIwYJKoZIhvcNAQkEMRYEFEwqLSkPAZGg7Mdjg57Itz+FwFs9MFgG CSqGSIb3DQEJDzFLMEkwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwICAgCAMAcGBSsOAwIHMA0GCCqG SIb3DQMCAgEoMAcGBSsOAwIaMAoGCCqGSIb3DQIFMIGrBgkrBgEEAYI3EAQxgZ0wgZowgZIxCzAJ BgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEPMA0G A1UEChMGVGhhd3RlMR0wGwYDVQQLExRDZXJ0aWZpY2F0ZSBTZXJ2aWNlczEoMCYGA1UEAxMfUGVy c29uYWwgRnJlZW1haWwgUlNBIDIwMDAuOC4zMAIDBPxeMA0GCSqGSIb3DQEBAQUABIGAwiGqDmFm NPfR8vWLPMsniFkkr/zSu/eBwZ8Y2sXdRzTpJVpu6XwBUA4oMz5y0hxuAG3+YWrqyo4/KbcZvJyx kT2+GM/KEsArOmycZ/2E5VMsIBITPyYnGN2f1kuw1PkPWTawYMz76X/1UK02l6Q+/2vQ0WcZxLyq NAlPgiYoeBEAAAAAAAA= ------=_NextPart_000_004C_01C10614.BCC2A530-- From owner-ietf-ldup@mail.imc.org Fri Jul 6 13:24:30 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA13327 for ; Fri, 6 Jul 2001 13:24:30 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.3/8.11.3) id f66H3Bv10656 for ietf-ldup-bks; Fri, 6 Jul 2001 10:03:11 -0700 (PDT) Received: from pretender.boolean.net (root@router.boolean.net [198.144.206.49]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f66H3Am10652 for ; Fri, 6 Jul 2001 10:03:10 -0700 (PDT) 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 f66H0LA78336; Fri, 6 Jul 2001 17:00:21 GMT (envelope-from Kurt@OpenLDAP.org) Message-Id: <5.1.0.14.0.20010706095037.031a3448@127.0.0.1> X-Sender: kurt@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Fri, 06 Jul 2001 09:59:25 -0700 To: Christopher Apple From: "Kurt D. Zeilenga" Subject: RE: Separate LCUP cookie vs replication - was RE: Comments onLCU P draft - opaque cookie Cc: "'richm@iplanet.com'" , Christopher Apple , john.strassner@intelliden.com, "'Richard Huber'" , ietf-ldup@imc.org In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-ldup@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: At 09:11 AM 7/6/2001, Christopher Apple wrote: >The guidelines I recommended for modifying the document >have been adopted by the document editors. Specifically >about the label/OID, these guidelines indicate that the >document should describe how implementations are to >respond when they encounter labels/OIDs that they do not >natively support or understand. My point is that a client should not care what the labels/OIDs are. It should just return the cookie to the server. A client which cares will cease to interoperate with servers providing other labels/OIDs. Kurt From owner-ietf-ldup@mail.imc.org Fri Jul 6 16:18:38 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA18549 for ; Fri, 6 Jul 2001 16:18:37 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.3/8.11.3) id f66JqSS14569 for ietf-ldup-bks; Fri, 6 Jul 2001 12:52:28 -0700 (PDT) Received: from pretender.boolean.net (root@router.boolean.net [198.144.206.49]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f66JqQm14565 for ; Fri, 6 Jul 2001 12:52:26 -0700 (PDT) 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 f66JneA78926; Fri, 6 Jul 2001 19:49:40 GMT (envelope-from Kurt@OpenLDAP.org) Message-Id: <5.1.0.14.0.20010706114919.03196028@127.0.0.1> X-Sender: kurt@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Fri, 06 Jul 2001 12:48:44 -0700 To: Christopher Apple From: "Kurt D. Zeilenga" Subject: RE: Correction to Last Call posting Cc: Christopher Apple , john.strassner@intelliden.com, ietf-ldup@imc.org In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-ldup@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: I've restricted my comments to just those issues in which you explicitly requested further comment. In regards to my other comments, I believe the WG has adequately addressed my concerns (not necessarily to my liking) and hence I support (with previously stated reservations) the progression of this document after these remaining issues are addressed (not necessarily to my liking). Kurt At 02:20 PM 7/5/2001, Christopher Apple wrote: > >-----Original Message----- > >From: Kurt D. Zeilenga [mailto:Kurt@OpenLDAP.org] > >Sent: Wednesday, June 27, 2001 7:41 PM > >To: Christopher Apple; john.strassner@intelliden.com > >Cc: ietf-ldup@imc.org > >Subject: Re: Correction to Last Call posting > > > > > >This message mostly reiterates previously raised issues. > > > >Section 3: > > Interoperability among directories using LDUP replication may be > > limited for implementations that add semantics beyond > >those specified > > by the LDAP core documents (RFC 2251-2256, 2829, 2830). > > > >I note that Interoperability among directories using LDUP > >replication > >may also be limited for implementations which implement different > >subsets of the semantics defined in the LDAP "core" specification. > >For example, one implementation may support subtyping another not. > >Another may require ;binary for some standard track attribute > >while another disallows ;binary for same. As an alternative to > >adding a clarification to the statement (as I would prefer), > >removing the statement (as it doesn't place a requirement upon > >LDUP) would be acceptable. > >Please propose full replacement text for the statement you >are commenting on. I can't determine exactly what you are >proposing to add as clarifying text based on what you wrote. As LDAP "core" specification includes numerous features which are not mandatory-to-implement (e.g. RECOMMENDED or OPTIONAL) as well supports elective extensions, interoperability between independent implementations of LDAP and the LDUP replication extension may be limited. Use of applicability statements to improve interoperability in particular application spaces is RECOMMENDED. My point is not that this LDAP Replication issue is not limited just by "semantics beyond" the core specification, but to non-mandatory semantics within the core specification and "semantics beyond". And, I believe both can be addressed through use of applicability statements (which narrows the applicable specifications). > >M5. LDAP replication MUST NOT require all copies of the replicated > >information to be complete copies of the replicated object. > > The model > >MUST support Partial Replicas. > > > >I assume this applies to copies, not to the original. > >That is, I assume that LDAP replication MAY require > >some master (if not all masters) to hold a complete > >instance of the object. Some clarification here may > >be appropriate. > >Please propose clarifying text explicitly so the WG can >evaluate it. I can't tell quite what to suggest as clarifying >text based on your comment. LDAP replication MUST NOT require all copies of the replicated information to be complete copies of the replicated object but MAY require that a complete copy to be held by at least one replica. The model MUST support Partial Replicas. >This issue is unresolved. > > > > >Security Considerations: > > "As noted in Section 3, security may be impacted..." > > > >Section 3 makes no statement about security. It makes a > >statement about interoperability. > >Current Text: > >This document includes security requirements (listed in section 4.8 >above) for the replication model and protocol. As noted in Section 3, >security may be impacted when replicating among servers that implement >non-standard extensions to basic LDAP semantics. Access control is one >common case which affects security; work to address this issue is going >on in LDAPEXT as documented in RFC 2820 [RFC2820]. > >Proposed Text to clarify the section based on Kurt's comment: > >This document includes security requirements (listed in section 4.8 >above) for the replication model and protocol. > >As noted in Section 3, interoperability may be impacted when >replicating among servers that implement non-standard extensions >to basic LDAP semantics. Since LDAPv3 access control work is being >treated as a set of standards-based extensions, security-related >and even general LDUP interoperability will be significantly >impacted by the degree of consistency with which LDUP >implementations support the LDAPv3 access control requirements >documented in RFC 2820 [RFC2820]. > >This issue is unresolved until we hear from at least the >document editors about whether or not this proposed text >fits or not. Also need some reaction from Kurt about whether >this clarifies the text based on his perspective. If not, >I think it would be reasonable for us to expect to see >an explicit proposal for the text to be contained in the >section. The suggested text addresses my concerns. From owner-ietf-ldup@mail.imc.org Fri Jul 6 16:28:06 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA18844 for ; Fri, 6 Jul 2001 16:28:04 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.3/8.11.3) id f66K7XH14948 for ietf-ldup-bks; Fri, 6 Jul 2001 13:07:33 -0700 (PDT) Received: from hawk.ummail.com (hawk.ummail.com [216.33.108.203]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f66K7Wm14944 for ; Fri, 6 Jul 2001 13:07:32 -0700 (PDT) Received: from ex01.ummail.com [216.33.108.253:25] by hawk.ummail.com with SMTP id E0706-1607-46d100; Fri, 6 Jul 2001 20:07:20 GMT Received: by ex01.ummail.com with Internet Mail Service (5.5.2650.21) id ; Fri, 6 Jul 2001 16:05:34 -0400 Message-ID: From: Christopher Apple To: "'Kurt D. Zeilenga'" , Christopher Apple Cc: Christopher Apple , john.strassner@intelliden.com, ietf-ldup@imc.org Subject: RE: Correction to Last Call posting Date: Fri, 6 Jul 2001 16:05:30 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) MIME-Version: 1.0 Content-Type: multipart/signed; micalg=SHA1; boundary="----=_NextPart_000_008A_01C10635.7353F540"; protocol="application/x-pkcs7-signature" X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: owner-ietf-ldup@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multi-part message in MIME format. ------=_NextPart_000_008A_01C10635.7353F540 Content-Type: multipart/mixed; boundary="----=_NextPart_001_008B_01C10635.7353F540" ------=_NextPart_001_008B_01C10635.7353F540 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Thanks. What do the document editors think about the proposed text changes? Other WG members? Chris Apple Program Manager - Directory Services United Messaging Inc. (V) 610-425-2860 >-----Original Message----- >From: Kurt D. Zeilenga [mailto:Kurt@OpenLDAP.org] >Sent: Friday, July 06, 2001 3:49 PM >To: Christopher Apple >Cc: Christopher Apple; john.strassner@intelliden.com; >ietf-ldup@imc.org >Subject: RE: Correction to Last Call posting > > >I've restricted my comments to just those issues in which >you explicitly requested further comment. In regards to >my other comments, I believe the WG has adequately >addressed my concerns (not necessarily to my liking) and >hence I support (with previously stated reservations) >the progression of this document after these remaining >issues are addressed (not necessarily to my liking). > >Kurt > >At 02:20 PM 7/5/2001, Christopher Apple wrote: >> >-----Original Message----- >> >From: Kurt D. Zeilenga [mailto:Kurt@OpenLDAP.org] >> >Sent: Wednesday, June 27, 2001 7:41 PM >> >To: Christopher Apple; john.strassner@intelliden.com >> >Cc: ietf-ldup@imc.org >> >Subject: Re: Correction to Last Call posting >> > >> > >> >This message mostly reiterates previously raised issues. >> > >> >Section 3: >> > Interoperability among directories using LDUP >replication may be >> > limited for implementations that add semantics beyond >> >those specified >> > by the LDAP core documents (RFC 2251-2256, 2829, 2830). >> > >> >I note that Interoperability among directories using LDUP >> >replication >> >may also be limited for implementations which >implement different >> >subsets of the semantics defined in the LDAP "core" >specification. >> >For example, one implementation may support subtyping >another not. >> >Another may require ;binary for some standard track attribute >> >while another disallows ;binary for same. As an alternative to >> >adding a clarification to the statement (as I would prefer), >> >removing the statement (as it doesn't place a requirement upon >> >LDUP) would be acceptable. >> >>Please propose full replacement text for the statement you >>are commenting on. I can't determine exactly what you are >>proposing to add as clarifying text based on what you wrote. > > As LDAP "core" specification includes numerous features > which are not mandatory-to-implement (e.g. RECOMMENDED > or OPTIONAL) as well supports elective extensions, > interoperability between independent implementations of > LDAP and the LDUP replication extension may be limited. > Use of applicability statements to improve interoperability > in particular application spaces is RECOMMENDED. > >My point is not that this LDAP Replication issue is not limited >just by "semantics beyond" the core specification, but to >non-mandatory semantics within the core specification and >"semantics beyond". And, I believe both can be addressed >through use of applicability statements (which narrows the >applicable specifications). > >> >M5. LDAP replication MUST NOT require all copies of >the replicated >> >information to be complete copies of the replicated object. >> > The model >> >MUST support Partial Replicas. >> > >> >I assume this applies to copies, not to the original. >> >That is, I assume that LDAP replication MAY require >> >some master (if not all masters) to hold a complete >> >instance of the object. Some clarification here may >> >be appropriate. >> >>Please propose clarifying text explicitly so the WG can >>evaluate it. I can't tell quite what to suggest as clarifying >>text based on your comment. > >LDAP replication MUST NOT require all copies of the replicated >information to be complete copies of the replicated object >but MAY require that a complete copy to be held by at least >one replica. The model MUST support Partial Replicas. > > >>This issue is unresolved. >> >> > >> >Security Considerations: >> > "As noted in Section 3, security may be impacted..." >> > >> >Section 3 makes no statement about security. It makes a >> >statement about interoperability. >> >>Current Text: >> >>This document includes security requirements (listed in section 4.8 >>above) for the replication model and protocol. As noted in >Section 3, >>security may be impacted when replicating among servers >that implement >>non-standard extensions to basic LDAP semantics. Access >control is one >>common case which affects security; work to address this >issue is going >>on in LDAPEXT as documented in RFC 2820 [RFC2820]. >> >>Proposed Text to clarify the section based on Kurt's comment: >> >>This document includes security requirements (listed in section 4.8 >>above) for the replication model and protocol. >> >>As noted in Section 3, interoperability may be impacted when >>replicating among servers that implement non-standard extensions >>to basic LDAP semantics. Since LDAPv3 access control work is being >>treated as a set of standards-based extensions, security-related >>and even general LDUP interoperability will be significantly >>impacted by the degree of consistency with which LDUP >>implementations support the LDAPv3 access control requirements >>documented in RFC 2820 [RFC2820]. >> >>This issue is unresolved until we hear from at least the >>document editors about whether or not this proposed text >>fits or not. Also need some reaction from Kurt about whether >>this clarifies the text based on his perspective. If not, >>I think it would be reasonable for us to expect to see >>an explicit proposal for the text to be contained in the >>section. > >The suggested text addresses my concerns. > ------=_NextPart_001_008B_01C10635.7353F540 Content-Type: text/x-vcard; name="Chris Apple (E-mail).vcf" Content-Disposition: attachment; filename="Chris Apple (E-mail).vcf" Content-Transfer-Encoding: quoted-printable BEGIN:VCARD VERSION:2.1 N:Apple;Chris FN:Chris Apple (E-mail) ORG:UMI TITLE:Program Manager TEL;WORK;VOICE:(610) 425-2860 TEL;HOME;VOICE:(215) 873-0850 TEL;CELL;VOICE:(610) 585-4241 TEL;WORK;FAX:(610) 425-6501 ADR;WORK:;;1161 McDermott Drive;West Chester;Pa.;19380;United States of = America LABEL;WORK;ENCODING=3DQUOTED-PRINTABLE:1161 McDermott = Drive=3D0D=3D0AWest Chester, Pa. 19380=3D0D=3D0AUnited States of Amer=3D ica EMAIL;PREF;INTERNET:christopher.apple@unitedmessaging.com REV:20010621T205341Z END:VCARD ------=_NextPart_001_008B_01C10635.7353F540-- ------=_NextPart_000_008A_01C10635.7353F540 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIF1TCCAqQw ggINoAMCAQICAwT8XjANBgkqhkiG9w0BAQQFADCBkjELMAkGA1UEBhMCWkExFTATBgNVBAgTDFdl c3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3duMQ8wDQYDVQQKEwZUaGF3dGUxHTAbBgNVBAsT FENlcnRpZmljYXRlIFNlcnZpY2VzMSgwJgYDVQQDEx9QZXJzb25hbCBGcmVlbWFpbCBSU0EgMjAw MC44LjMwMB4XDTAxMDYwODE1NDgwOVoXDTAyMDYwODE1NDgwOVowVzEfMB0GA1UEAxMWVGhhd3Rl IEZyZWVtYWlsIE1lbWJlcjE0MDIGCSqGSIb3DQEJARYlY2hyaXN0b3BoZXIuYXBwbGVAdW5pdGVk bWVzc2FnaW5nLm5ldDCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEA0wb7dpXj0lZuRfGhErPC qQTyvOGL3DHONyKLfJEfbD3A/0zqEnkjKamgGiD7PVFc0Gwok9x/2Jl/mQO52ArIPO0AkSYY/KaZ mWKaFXxh1LedYLyNb5PRe1kN6y0EAva1D4nwyZmToJMBUqLNsvMGjPmLUuBwdbHLEdAAVo7Gp6kC AwEAAaNCMEAwMAYDVR0RBCkwJ4ElY2hyaXN0b3BoZXIuYXBwbGVAdW5pdGVkbWVzc2FnaW5nLm5l dDAMBgNVHRMBAf8EAjAAMA0GCSqGSIb3DQEBBAUAA4GBAIqkT3GDgyKLYOzIJ9h/OsiFbiefYTbc ALptWnwegAeXbfjhq+BUJN2ICWxfQtTCupvAG6mW4J2qI422TLc31Gf7uu5r93ppFDrCGYAM2mgH tqKgztYQmAsGPf2TijDOeE7JRbQ7dZJu4BJvuE3SY9PdI/umjiOh/WG/gaZNdl0bMIIDKTCCApKg AwIBAgIBDDANBgkqhkiG9w0BAQQFADCB0TELMAkGA1UEBhMCWkExFTATBgNVBAgTDFdlc3Rlcm4g Q2FwZTESMBAGA1UEBxMJQ2FwZSBUb3duMRowGAYDVQQKExFUaGF3dGUgQ29uc3VsdGluZzEoMCYG A1UECxMfQ2VydGlmaWNhdGlvbiBTZXJ2aWNlcyBEaXZpc2lvbjEkMCIGA1UEAxMbVGhhd3RlIFBl cnNvbmFsIEZyZWVtYWlsIENBMSswKQYJKoZIhvcNAQkBFhxwZXJzb25hbC1mcmVlbWFpbEB0aGF3 dGUuY29tMB4XDTAwMDgzMDAwMDAwMFoXDTAyMDgyOTIzNTk1OVowgZIxCzAJBgNVBAYTAlpBMRUw EwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEPMA0GA1UEChMGVGhhd3Rl MR0wGwYDVQQLExRDZXJ0aWZpY2F0ZSBTZXJ2aWNlczEoMCYGA1UEAxMfUGVyc29uYWwgRnJlZW1h aWwgUlNBIDIwMDAuOC4zMDCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEA3jMypmPHCSVFPtJu eCdngcXaiBmClw7jRCmKYzUqbXA8+tyu9+50bzC8M5B/+TRxoKNtmPHDT6Jl2w36S/HW3WGl+YXN VZo1Gp2Sdagnrthy+boC9tewkd4c6avgGAOofENCUFGHgzzwObSbVIoTh/+zm51JZgAtCYnslGvp oWkCAwEAAaNOMEwwKQYDVR0RBCIwIKQeMBwxGjAYBgNVBAMTEVByaXZhdGVMYWJlbDEtMjk3MBIG A1UdEwEB/wQIMAYBAf8CAQAwCwYDVR0PBAQDAgEGMA0GCSqGSIb3DQEBBAUAA4GBAHMbbyZli/8V NEtZYortRL5Jx+gNu4+5DWomKmKEH7iHY3QcbbfPGlORS+HN5jjZ7VD0Omw0kqzmkpxuwSMBwgmn 70uuct0GZ/VQby5YuLYLwVBXtewc1+8XttWIm7eiiBrtOVs5fTT8tpYYJU1q9J3Fw5EvqZa4BTxS /N3pYgNIMYICqjCCAqYCAQEwgZowgZIxCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENh cGUxEjAQBgNVBAcTCUNhcGUgVG93bjEPMA0GA1UEChMGVGhhd3RlMR0wGwYDVQQLExRDZXJ0aWZp Y2F0ZSBTZXJ2aWNlczEoMCYGA1UEAxMfUGVyc29uYWwgRnJlZW1haWwgUlNBIDIwMDAuOC4zMAID BPxeMAkGBSsOAwIaBQCgggFlMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkF MQ8XDTAxMDcwNjIwMDUxOFowIwYJKoZIhvcNAQkEMRYEFPmn2KJR36lx0uqE9rjBhLzLIXUYMFgG CSqGSIb3DQEJDzFLMEkwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwICAgCAMAcGBSsOAwIHMA0GCCqG SIb3DQMCAgEoMAcGBSsOAwIaMAoGCCqGSIb3DQIFMIGrBgkrBgEEAYI3EAQxgZ0wgZowgZIxCzAJ BgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEPMA0G A1UEChMGVGhhd3RlMR0wGwYDVQQLExRDZXJ0aWZpY2F0ZSBTZXJ2aWNlczEoMCYGA1UEAxMfUGVy c29uYWwgRnJlZW1haWwgUlNBIDIwMDAuOC4zMAIDBPxeMA0GCSqGSIb3DQEBAQUABIGAKVIAIv3m FXRNXWTpAIwUKUMTxG7HQOnOuxEWRTfW5+2q7wZJx7lm+Hg3OYFSgvm526m2C2GcF2ZWfOfZEMTF WvwVAOWHzMCvmTbJJpXdkkAqbotk7slFw15T/otfmrP243+XtPPlCqDWUhIAh/tQHM/lAX76tRxY TWOdb2cCQ5sAAAAAAAA= ------=_NextPart_000_008A_01C10635.7353F540-- From owner-ietf-ldup@mail.imc.org Fri Jul 6 16:29:04 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA18860 for ; Fri, 6 Jul 2001 16:29:03 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.3/8.11.3) id f66K4rS14848 for ietf-ldup-bks; Fri, 6 Jul 2001 13:04:53 -0700 (PDT) Received: from hawk.ummail.com (hawk.ummail.com [216.33.108.202]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f66K4qm14844 for ; Fri, 6 Jul 2001 13:04:52 -0700 (PDT) Received: from ex01.ummail.com [216.33.108.253:25] by hawk.ummail.com with SMTP id W0706-1604-6c8500; Fri, 6 Jul 2001 20:04:30 GMT Received: by ex01.ummail.com with Internet Mail Service (5.5.2650.21) id ; Fri, 6 Jul 2001 16:02:44 -0400 Message-ID: From: Christopher Apple To: "'Kurt D. Zeilenga'" Cc: "'richm@iplanet.com'" , john.strassner@intelliden.com, "'Richard Huber'" , ietf-ldup@imc.org Subject: RE: Separate LCUP cookie vs replication - was RE: Comments onLCU P draft - opaque cookie Date: Fri, 6 Jul 2001 16:02:39 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) MIME-Version: 1.0 Content-Type: multipart/signed; micalg=SHA1; boundary="----=_NextPart_000_0084_01C10635.0D5BD500"; protocol="application/x-pkcs7-signature" X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: owner-ietf-ldup@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multi-part message in MIME format. ------=_NextPart_000_0084_01C10635.0D5BD500 Content-Type: multipart/mixed; boundary="----=_NextPart_001_0085_01C10635.0D5BD500" ------=_NextPart_001_0085_01C10635.0D5BD500 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Kurt, This problem can solved by having one or more standards-track OID/payload pairs that clients and servers can support. Just having the clients pay attention and react appropriately to OID/payload pairs doesn't constitute an interoperability problem - it actually constitutes one way of supporting a minimum level of interoperability between a client from one implementer and a server from another. That's the essence of the guidelines that the authors have adopted with respect to this topic. The guidelines make no definitive statement about the details of how clients are expected to behave in the event that they encounter unknown/unsupported OIDs. I suspect that where we will end up is having the LCUP document as revised by its editors plus one or more standards-track OID/payload documents. Its been pointed out that this is not the only way of supporting client-server interoperability. That is a true statement. Its also been pointed out that having standards-track OID/payload pairs is a more assured path to being able to interoperate between LCUP-compliant implementations than relying on market forces decide if and when such implementations should interoperate. Going down the latter path would mean that LCUP doesn't really belong in an IETF WG at all and would be better off in a closed industry consortia group. And no, I'm NOT suggesting that the document should be removed from the LDUP charter at this point. We need to see the next version of it and discuss the possibility of and obtain a few informal proposals from WG members on standards-track OID/payload pairs that are useful. If I understand your position correctly, you do not believe that there are any OID/payload pairs that would be useful for clients to be capable of understanding and reacting to in a way more intelligently than simply passing back a cookie previously set by a server. Or am I reading too much into what you have said so far? No judgment implied at all - just trying to understand your position. Keep in mind that there would be nothing wrong with having certain OID/payload pairs be opaque to clients but exposed to servers from any implementer because they are standards-track; whereas other OID/payload pairs could be exposed to both clients and servers from any implementer. Chris Apple Program Manager - Directory Services United Messaging Inc. (V) 610-425-2860 >-----Original Message----- >From: Kurt D. Zeilenga [mailto:Kurt@OpenLDAP.org] >Sent: Friday, July 06, 2001 12:59 PM >To: Christopher Apple >Cc: 'richm@iplanet.com'; Christopher Apple; >john.strassner@intelliden.com; 'Richard Huber'; ietf-ldup@imc.org >Subject: RE: Separate LCUP cookie vs replication - was RE: Comments >onLCU P draft - opaque cookie > > >At 09:11 AM 7/6/2001, Christopher Apple wrote: >>The guidelines I recommended for modifying the document >>have been adopted by the document editors. Specifically >>about the label/OID, these guidelines indicate that the >>document should describe how implementations are to >>respond when they encounter labels/OIDs that they do not >>natively support or understand. > >My point is that a client should not care what the >labels/OIDs are. It should just return the cookie to >the server. A client which cares will cease to >interoperate with servers providing other labels/OIDs. > >Kurt > ------=_NextPart_001_0085_01C10635.0D5BD500 Content-Type: text/x-vcard; name="Chris Apple (E-mail).vcf" Content-Disposition: attachment; filename="Chris Apple (E-mail).vcf" Content-Transfer-Encoding: quoted-printable BEGIN:VCARD VERSION:2.1 N:Apple;Chris FN:Chris Apple (E-mail) ORG:UMI TITLE:Program Manager TEL;WORK;VOICE:(610) 425-2860 TEL;HOME;VOICE:(215) 873-0850 TEL;CELL;VOICE:(610) 585-4241 TEL;WORK;FAX:(610) 425-6501 ADR;WORK:;;1161 McDermott Drive;West Chester;Pa.;19380;United States of = America LABEL;WORK;ENCODING=3DQUOTED-PRINTABLE:1161 McDermott = Drive=3D0D=3D0AWest Chester, Pa. 19380=3D0D=3D0AUnited States of Amer=3D ica EMAIL;PREF;INTERNET:christopher.apple@unitedmessaging.com REV:20010621T205341Z END:VCARD ------=_NextPart_001_0085_01C10635.0D5BD500-- ------=_NextPart_000_0084_01C10635.0D5BD500 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIF1TCCAqQw ggINoAMCAQICAwT8XjANBgkqhkiG9w0BAQQFADCBkjELMAkGA1UEBhMCWkExFTATBgNVBAgTDFdl c3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3duMQ8wDQYDVQQKEwZUaGF3dGUxHTAbBgNVBAsT FENlcnRpZmljYXRlIFNlcnZpY2VzMSgwJgYDVQQDEx9QZXJzb25hbCBGcmVlbWFpbCBSU0EgMjAw MC44LjMwMB4XDTAxMDYwODE1NDgwOVoXDTAyMDYwODE1NDgwOVowVzEfMB0GA1UEAxMWVGhhd3Rl IEZyZWVtYWlsIE1lbWJlcjE0MDIGCSqGSIb3DQEJARYlY2hyaXN0b3BoZXIuYXBwbGVAdW5pdGVk bWVzc2FnaW5nLm5ldDCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEA0wb7dpXj0lZuRfGhErPC qQTyvOGL3DHONyKLfJEfbD3A/0zqEnkjKamgGiD7PVFc0Gwok9x/2Jl/mQO52ArIPO0AkSYY/KaZ mWKaFXxh1LedYLyNb5PRe1kN6y0EAva1D4nwyZmToJMBUqLNsvMGjPmLUuBwdbHLEdAAVo7Gp6kC AwEAAaNCMEAwMAYDVR0RBCkwJ4ElY2hyaXN0b3BoZXIuYXBwbGVAdW5pdGVkbWVzc2FnaW5nLm5l dDAMBgNVHRMBAf8EAjAAMA0GCSqGSIb3DQEBBAUAA4GBAIqkT3GDgyKLYOzIJ9h/OsiFbiefYTbc ALptWnwegAeXbfjhq+BUJN2ICWxfQtTCupvAG6mW4J2qI422TLc31Gf7uu5r93ppFDrCGYAM2mgH tqKgztYQmAsGPf2TijDOeE7JRbQ7dZJu4BJvuE3SY9PdI/umjiOh/WG/gaZNdl0bMIIDKTCCApKg AwIBAgIBDDANBgkqhkiG9w0BAQQFADCB0TELMAkGA1UEBhMCWkExFTATBgNVBAgTDFdlc3Rlcm4g Q2FwZTESMBAGA1UEBxMJQ2FwZSBUb3duMRowGAYDVQQKExFUaGF3dGUgQ29uc3VsdGluZzEoMCYG A1UECxMfQ2VydGlmaWNhdGlvbiBTZXJ2aWNlcyBEaXZpc2lvbjEkMCIGA1UEAxMbVGhhd3RlIFBl cnNvbmFsIEZyZWVtYWlsIENBMSswKQYJKoZIhvcNAQkBFhxwZXJzb25hbC1mcmVlbWFpbEB0aGF3 dGUuY29tMB4XDTAwMDgzMDAwMDAwMFoXDTAyMDgyOTIzNTk1OVowgZIxCzAJBgNVBAYTAlpBMRUw EwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEPMA0GA1UEChMGVGhhd3Rl MR0wGwYDVQQLExRDZXJ0aWZpY2F0ZSBTZXJ2aWNlczEoMCYGA1UEAxMfUGVyc29uYWwgRnJlZW1h aWwgUlNBIDIwMDAuOC4zMDCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEA3jMypmPHCSVFPtJu eCdngcXaiBmClw7jRCmKYzUqbXA8+tyu9+50bzC8M5B/+TRxoKNtmPHDT6Jl2w36S/HW3WGl+YXN VZo1Gp2Sdagnrthy+boC9tewkd4c6avgGAOofENCUFGHgzzwObSbVIoTh/+zm51JZgAtCYnslGvp oWkCAwEAAaNOMEwwKQYDVR0RBCIwIKQeMBwxGjAYBgNVBAMTEVByaXZhdGVMYWJlbDEtMjk3MBIG A1UdEwEB/wQIMAYBAf8CAQAwCwYDVR0PBAQDAgEGMA0GCSqGSIb3DQEBBAUAA4GBAHMbbyZli/8V NEtZYortRL5Jx+gNu4+5DWomKmKEH7iHY3QcbbfPGlORS+HN5jjZ7VD0Omw0kqzmkpxuwSMBwgmn 70uuct0GZ/VQby5YuLYLwVBXtewc1+8XttWIm7eiiBrtOVs5fTT8tpYYJU1q9J3Fw5EvqZa4BTxS /N3pYgNIMYICqjCCAqYCAQEwgZowgZIxCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENh cGUxEjAQBgNVBAcTCUNhcGUgVG93bjEPMA0GA1UEChMGVGhhd3RlMR0wGwYDVQQLExRDZXJ0aWZp Y2F0ZSBTZXJ2aWNlczEoMCYGA1UEAxMfUGVyc29uYWwgRnJlZW1haWwgUlNBIDIwMDAuOC4zMAID BPxeMAkGBSsOAwIaBQCgggFlMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkF MQ8XDTAxMDcwNjIwMDIyN1owIwYJKoZIhvcNAQkEMRYEFF8Wof5E3VK8vfnVDInRO5fLWMW7MFgG CSqGSIb3DQEJDzFLMEkwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwICAgCAMAcGBSsOAwIHMA0GCCqG SIb3DQMCAgEoMAcGBSsOAwIaMAoGCCqGSIb3DQIFMIGrBgkrBgEEAYI3EAQxgZ0wgZowgZIxCzAJ BgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEPMA0G A1UEChMGVGhhd3RlMR0wGwYDVQQLExRDZXJ0aWZpY2F0ZSBTZXJ2aWNlczEoMCYGA1UEAxMfUGVy c29uYWwgRnJlZW1haWwgUlNBIDIwMDAuOC4zMAIDBPxeMA0GCSqGSIb3DQEBAQUABIGAYAMIDGJB Y401/PZow2HV30ITT/Q8x2yfyuJg/fIatoidb3w/g3XmjCOZP4TVZVyPW2KPgZCPB9iNUMR1ubJM vsFkIJYUmBtLRRYHEDENCIT8IMcRv84gVs8KvncpQLlNI9d3ebFj9R3WWrl5kTHZiaeb3RNEjBdB ZNjylnmMSVsAAAAAAAA= ------=_NextPart_000_0084_01C10635.0D5BD500-- From owner-ietf-ldup@mail.imc.org Fri Jul 6 17:38:35 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA20736 for ; Fri, 6 Jul 2001 17:38:34 -0400 (EDT) Received: by above.proper.com (8.11.3/8.11.3) id f66LCsW16317 for ietf-ldup-bks; Fri, 6 Jul 2001 14:12:54 -0700 (PDT) Received: from pretender.boolean.net (root@router.boolean.net [198.144.206.49]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f66LCrm16313 for ; Fri, 6 Jul 2001 14:12:53 -0700 (PDT) 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 f66LA5A79151; Fri, 6 Jul 2001 21:10:05 GMT (envelope-from Kurt@OpenLDAP.org) Message-Id: <5.1.0.14.0.20010706133321.031c5488@127.0.0.1> X-Sender: kurt@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Fri, 06 Jul 2001 14:09:09 -0700 To: Christopher Apple From: "Kurt D. Zeilenga" Subject: RE: Separate LCUP cookie vs replication - was RE: Comments onLCU P draft - opaque cookie Cc: "'richm@iplanet.com'" , john.strassner@intelliden.com, "'Richard Huber'" , ietf-ldup@imc.org In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-ldup@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: > No judgment implied at all - just trying to understand > your position. My primary concern is that LCUP peers while fail to interoperate because the client cared too much about the contents of something it really should treat as as an opaque. Now, I do concede the point that to support future extension of LCUP (for example, to support LDAP Replication) may require specification of the cookie to be exchanged by those supporting that extension. The authors have stated that their next revision would include 'sufficient' language to address the above interoperability concern. While you may not yet fully understand my concerns (and I don't fully understand yours), I think the authors have a decent enough grasp of our concerns (based upon MarkS's and RichM comments) for them to take a stab at addressing both of our concerns. Kurt From owner-ietf-ldup@mail.imc.org Mon Jul 9 01:57:12 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id BAA24089 for ; Mon, 9 Jul 2001 01:57:11 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.3/8.11.3) id f695cNR15148 for ietf-ldup-bks; Sun, 8 Jul 2001 22:38:23 -0700 (PDT) Received: from falcon.mail.pas.earthlink.net (falcon.mail.pas.earthlink.net [207.217.120.74]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f695cMm15144 for ; Sun, 8 Jul 2001 22:38:22 -0700 (PDT) Received: from FARILJCS (sdn-ar-004cocsprP269.dialsprint.net [158.252.164.71]) by falcon.mail.pas.earthlink.net (EL-8_9_3_3/8.9.3) with SMTP id WAA11096; Sun, 8 Jul 2001 22:38:14 -0700 (PDT) Reply-To: From: "John Strassner" To: "Christopher Apple" , "'Kurt D. Zeilenga'" Cc: Subject: RE: Correction to Last Call posting Date: Sun, 8 Jul 2001 22:38:14 -0700 MIME-Version: 1.0 Message-ID: Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_007E_01C107CC.CCA43180" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 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_007E_01C107CC.CCA43180 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit With co-chair hat off, I agree with these modifications. Note that some minor wordsmithing needs to make better formed sentences in a couple of cases, but these are minor and can be worked with the editor of the draft. regards, John -----Original Message----- From: owner-ietf-ldup@mail.imc.org [mailto:owner-ietf-ldup@mail.imc.org]On Behalf Of Christopher Apple Sent: Friday, July 06, 2001 1:06 PM To: 'Kurt D. Zeilenga'; Christopher Apple Cc: Christopher Apple; john.strassner@intelliden.com; ietf-ldup@imc.org Subject: RE: Correction to Last Call posting Thanks. What do the document editors think about the proposed text changes? Other WG members? Chris Apple Program Manager - Directory Services United Messaging Inc. (V) 610-425-2860 >-----Original Message----- >From: Kurt D. Zeilenga [mailto:Kurt@OpenLDAP.org] >Sent: Friday, July 06, 2001 3:49 PM >To: Christopher Apple >Cc: Christopher Apple; john.strassner@intelliden.com; >ietf-ldup@imc.org >Subject: RE: Correction to Last Call posting > > >I've restricted my comments to just those issues in which >you explicitly requested further comment. In regards to >my other comments, I believe the WG has adequately >addressed my concerns (not necessarily to my liking) and >hence I support (with previously stated reservations) >the progression of this document after these remaining >issues are addressed (not necessarily to my liking). > >Kurt > >At 02:20 PM 7/5/2001, Christopher Apple wrote: >> >-----Original Message----- >> >From: Kurt D. Zeilenga [mailto:Kurt@OpenLDAP.org] >> >Sent: Wednesday, June 27, 2001 7:41 PM >> >To: Christopher Apple; john.strassner@intelliden.com >> >Cc: ietf-ldup@imc.org >> >Subject: Re: Correction to Last Call posting >> > >> > >> >This message mostly reiterates previously raised issues. >> > >> >Section 3: >> > Interoperability among directories using LDUP >replication may be >> > limited for implementations that add semantics beyond >> >those specified >> > by the LDAP core documents (RFC 2251-2256, 2829, 2830). >> > >> >I note that Interoperability among directories using LDUP >> >replication >> >may also be limited for implementations which >implement different >> >subsets of the semantics defined in the LDAP "core" >specification. >> >For example, one implementation may support subtyping >another not. >> >Another may require ;binary for some standard track attribute >> >while another disallows ;binary for same. As an alternative to >> >adding a clarification to the statement (as I would prefer), >> >removing the statement (as it doesn't place a requirement upon >> >LDUP) would be acceptable. >> >>Please propose full replacement text for the statement you >>are commenting on. I can't determine exactly what you are >>proposing to add as clarifying text based on what you wrote. > > As LDAP "core" specification includes numerous features > which are not mandatory-to-implement (e.g. RECOMMENDED > or OPTIONAL) as well supports elective extensions, > interoperability between independent implementations of > LDAP and the LDUP replication extension may be limited. > Use of applicability statements to improve interoperability > in particular application spaces is RECOMMENDED. > >My point is not that this LDAP Replication issue is not limited >just by "semantics beyond" the core specification, but to >non-mandatory semantics within the core specification and >"semantics beyond". And, I believe both can be addressed >through use of applicability statements (which narrows the >applicable specifications). > >> >M5. LDAP replication MUST NOT require all copies of >the replicated >> >information to be complete copies of the replicated object. >> > The model >> >MUST support Partial Replicas. >> > >> >I assume this applies to copies, not to the original. >> >That is, I assume that LDAP replication MAY require >> >some master (if not all masters) to hold a complete >> >instance of the object. Some clarification here may >> >be appropriate. >> >>Please propose clarifying text explicitly so the WG can >>evaluate it. I can't tell quite what to suggest as clarifying >>text based on your comment. > >LDAP replication MUST NOT require all copies of the replicated >information to be complete copies of the replicated object >but MAY require that a complete copy to be held by at least >one replica. The model MUST support Partial Replicas. > > >>This issue is unresolved. >> >> > >> >Security Considerations: >> > "As noted in Section 3, security may be impacted..." >> > >> >Section 3 makes no statement about security. It makes a >> >statement about interoperability. >> >>Current Text: >> >>This document includes security requirements (listed in section 4.8 >>above) for the replication model and protocol. As noted in >Section 3, >>security may be impacted when replicating among servers >that implement >>non-standard extensions to basic LDAP semantics. Access >control is one >>common case which affects security; work to address this >issue is going >>on in LDAPEXT as documented in RFC 2820 [RFC2820]. >> >>Proposed Text to clarify the section based on Kurt's comment: >> >>This document includes security requirements (listed in section 4.8 >>above) for the replication model and protocol. >> >>As noted in Section 3, interoperability may be impacted when >>replicating among servers that implement non-standard extensions >>to basic LDAP semantics. Since LDAPv3 access control work is being >>treated as a set of standards-based extensions, security-related >>and even general LDUP interoperability will be significantly >>impacted by the degree of consistency with which LDUP >>implementations support the LDAPv3 access control requirements >>documented in RFC 2820 [RFC2820]. >> >>This issue is unresolved until we hear from at least the >>document editors about whether or not this proposed text >>fits or not. Also need some reaction from Kurt about whether >>this clarifies the text based on his perspective. If not, >>I think it would be reasonable for us to expect to see >>an explicit proposal for the text to be contained in the >>section. > >The suggested text addresses my concerns. > ------=_NextPart_000_007E_01C107CC.CCA43180 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Disposition: attachment; filename="smime.p7s" Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIII9jCCApQw ggH9oAMCAQICAwSkbzANBgkqhkiG9w0BAQQFADCBkjELMAkGA1UEBhMCWkExFTATBgNVBAgTDFdl c3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3duMQ8wDQYDVQQKEwZUaGF3dGUxHTAbBgNVBAsT FENlcnRpZmljYXRlIFNlcnZpY2VzMSgwJgYDVQQDEx9QZXJzb25hbCBGcmVlbWFpbCBSU0EgMjAw MC44LjMwMB4XDTAxMDQxOTE5MjY0NFoXDTAyMDQxOTE5MjY0NFowTzEfMB0GA1UEAxMWVGhhd3Rl IEZyZWVtYWlsIE1lbWJlcjEsMCoGCSqGSIb3DQEJARYdam9obi5zdHJhc3NuZXJAaW50ZWxsaWRl bi5jb20wgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBAKOQF9xvr2IzkspSZ5NHATzu64yNJl1D NVVu08Upy0q/Dvfm0/dWVRc/sg09Tr1seHcVLIjAlY6QWFJsPf5tuglzSuMPy+6bGj/mI3KSXpte dhD5o33qc0oBnIOyn+PuqW7fpWjIJwM2MNCLr7gG1IjrchggMput4b5jq2M3zXxJAgMBAAGjOjA4 MCgGA1UdEQQhMB+BHWpvaG4uc3RyYXNzbmVyQGludGVsbGlkZW4uY29tMAwGA1UdEwEB/wQCMAAw DQYJKoZIhvcNAQEEBQADgYEAtHVVEjLYbfAxqW9D1GxSpZYh7kWX/em+JcgXrxFom6kU3wgCrluP F0Ce97vS4VX/TTs9x9b9YUONsEi8kqN5XLY3995FwnFgT+s2ZVljKNFoCgk4COQJ3OS2l/bZWFRc xgR4auC8sLZmE2oxtOm1cigZMhbT8ZnKvWuBN/8q2tUwggMpMIICkqADAgECAgEMMA0GCSqGSIb3 DQEBBAUAMIHRMQswCQYDVQQGEwJaQTEVMBMGA1UECBMMV2VzdGVybiBDYXBlMRIwEAYDVQQHEwlD YXBlIFRvd24xGjAYBgNVBAoTEVRoYXd0ZSBDb25zdWx0aW5nMSgwJgYDVQQLEx9DZXJ0aWZpY2F0 aW9uIFNlcnZpY2VzIERpdmlzaW9uMSQwIgYDVQQDExtUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwg Q0ExKzApBgkqhkiG9w0BCQEWHHBlcnNvbmFsLWZyZWVtYWlsQHRoYXd0ZS5jb20wHhcNMDAwODMw MDAwMDAwWhcNMDIwODI5MjM1OTU5WjCBkjELMAkGA1UEBhMCWkExFTATBgNVBAgTDFdlc3Rlcm4g Q2FwZTESMBAGA1UEBxMJQ2FwZSBUb3duMQ8wDQYDVQQKEwZUaGF3dGUxHTAbBgNVBAsTFENlcnRp ZmljYXRlIFNlcnZpY2VzMSgwJgYDVQQDEx9QZXJzb25hbCBGcmVlbWFpbCBSU0EgMjAwMC44LjMw MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDeMzKmY8cJJUU+0m54J2eBxdqIGYKXDuNEKYpj NSptcDz63K737nRvMLwzkH/5NHGgo22Y8cNPomXbDfpL8dbdYaX5hc1VmjUanZJ1qCeu2HL5ugL2 17CR3hzpq+AYA6h8Q0JQUYeDPPA5tJtUihOH/7ObnUlmAC0JieyUa+mhaQIDAQABo04wTDApBgNV HREEIjAgpB4wHDEaMBgGA1UEAxMRUHJpdmF0ZUxhYmVsMS0yOTcwEgYDVR0TAQH/BAgwBgEB/wIB ADALBgNVHQ8EBAMCAQYwDQYJKoZIhvcNAQEEBQADgYEAcxtvJmWL/xU0S1liiu1EvknH6A27j7kN aiYqYoQfuIdjdBxtt88aU5FL4c3mONntUPQ6bDSSrOaSnG7BIwHCCafvS65y3QZn9VBvLli4tgvB UFe17BzX7xe21Yibt6KIGu05Wzl9NPy2lhglTWr0ncXDkS+plrgFPFL83eliA0gwggMtMIIClqAD AgECAgEAMA0GCSqGSIb3DQEBBAUAMIHRMQswCQYDVQQGEwJaQTEVMBMGA1UECBMMV2VzdGVybiBD YXBlMRIwEAYDVQQHEwlDYXBlIFRvd24xGjAYBgNVBAoTEVRoYXd0ZSBDb25zdWx0aW5nMSgwJgYD VQQLEx9DZXJ0aWZpY2F0aW9uIFNlcnZpY2VzIERpdmlzaW9uMSQwIgYDVQQDExtUaGF3dGUgUGVy c29uYWwgRnJlZW1haWwgQ0ExKzApBgkqhkiG9w0BCQEWHHBlcnNvbmFsLWZyZWVtYWlsQHRoYXd0 ZS5jb20wHhcNOTYwMTAxMDAwMDAwWhcNMjAxMjMxMjM1OTU5WjCB0TELMAkGA1UEBhMCWkExFTAT BgNVBAgTDFdlc3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3duMRowGAYDVQQKExFUaGF3dGUg Q29uc3VsdGluZzEoMCYGA1UECxMfQ2VydGlmaWNhdGlvbiBTZXJ2aWNlcyBEaXZpc2lvbjEkMCIG A1UEAxMbVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIENBMSswKQYJKoZIhvcNAQkBFhxwZXJzb25h bC1mcmVlbWFpbEB0aGF3dGUuY29tMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDUadfUsJRk W3HpR9gMUbbqcpGwhF59LQ2PexLfhSV1KHQ6QixjJ5+Ve0vvfhmHHYbqo925zpZkGsIUbkSsfOaP 6E0PcR9AOKYAo4d49vmUhl6t6sBeduvZFKNdbnp8DKVLVX8GGSl/npom1Wq7OCQIapjHsdqjmJH9 edvlWsQcuQIDAQABoxMwETAPBgNVHRMBAf8EBTADAQH/MA0GCSqGSIb3DQEBBAUAA4GBAMfskn5O +PWWpWdiKqTwTRFg0G+NYFhhrCa7UjVcCM8w+6hKloofYkIjjBcP9LpknBesRynfnZhe0mxgcVyi rNx54+duAEcftQ0o6AKd5Jr9E/Sm2Xyx+NxfIyYJkYBz0BQb3kOpgyXy5pwvFcr+pquKB3WLDN1R hGvk+NHOd6KBMYICqjCCAqYCAQEwgZowgZIxCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJu IENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEPMA0GA1UEChMGVGhhd3RlMR0wGwYDVQQLExRDZXJ0 aWZpY2F0ZSBTZXJ2aWNlczEoMCYGA1UEAxMfUGVyc29uYWwgRnJlZW1haWwgUlNBIDIwMDAuOC4z MAIDBKRvMAkGBSsOAwIaBQCgggFlMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcN AQkFMQ8XDTAxMDcwODIzNDExM1owIwYJKoZIhvcNAQkEMRYEFO03rAfWEYTUyUU6IR/1CNt8zwni MFgGCSqGSIb3DQEJDzFLMEkwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwICAgCAMAcGBSsOAwIHMA0G CCqGSIb3DQMCAgEoMAcGBSsOAwIaMAoGCCqGSIb3DQIFMIGrBgkrBgEEAYI3EAQxgZ0wgZowgZIx CzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEP MA0GA1UEChMGVGhhd3RlMR0wGwYDVQQLExRDZXJ0aWZpY2F0ZSBTZXJ2aWNlczEoMCYGA1UEAxMf UGVyc29uYWwgRnJlZW1haWwgUlNBIDIwMDAuOC4zMAIDBKRvMA0GCSqGSIb3DQEBAQUABIGAHGvD k+rrHtnw1g7zpMklUQ2jKewBPxcQyUY2NnniTrQU2cPGZ4QkaHrau3pVX5M/KAjed9kkJ3ljI7n0 P87kPvluJl+s7f0mlw//w0HzAqAkUp0+I0gGKTRCZP1q/Pj7J7vWH/Xem2VC24X3ujBBzMjwtJwc ko1hN9WVnAxwdYwAAAAAAAA= ------=_NextPart_000_007E_01C107CC.CCA43180-- From owner-ietf-ldup@mail.imc.org Tue Jul 10 17:43:10 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA25917 for ; Tue, 10 Jul 2001 17:43:08 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.3/8.11.3) id f6ALNMc06058 for ietf-ldup-bks; Tue, 10 Jul 2001 14:23:22 -0700 (PDT) Received: from almso1.proxy.att.com (almso1.att.com [192.128.167.69]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f6ALNKm06054 for ; Tue, 10 Jul 2001 14:23:20 -0700 (PDT) Received: from qsun.mt.att.com ([135.16.12.1]) by almso1.proxy.att.com (AT&T IPNS/MSO-3.0) with SMTP id f6ALNAW17521; Tue, 10 Jul 2001 17:23:14 -0400 (EDT) Received: from att.com by qsun.mt.att.com (SMI-8.6/ATTEMS-1.4.1 sol2) id RAA18819; Tue, 10 Jul 2001 17:23:08 -0400 Message-ID: <3B4B71F3.C31AB64A@att.com> Date: Tue, 10 Jul 2001 17:21:55 -0400 From: Richard Huber X-Mailer: Mozilla 4.75 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Christopher Apple CC: "'Kurt D. Zeilenga'" , john.strassner@intelliden.com, ietf-ldup@imc.org Subject: Re: Correction to Last Call posting References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-ldup@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit We basically agree with the three proposed changes, but we did make some edits. For the first change (to the last paragraph of Section 3), we propose this wording: "Interoperability among directories using LDAP replication may be limited for implementations that add semantics beyond those specified by the LDAP core documents (RFC 2251-2256, 2829, 2830). In addition, the "core" specifications include numerous features which are not mandatory-to-implement (e.g. RECOMMENDED or OPTIONAL). There are also numerous elective extensions. Thus LDAP replication interoperability between independent implementations of LDAP which support different options may be limited. Use of applicability statements to improve interoperability in particular application spaces is RECOMMENDED." We agree with Kurt's comment, but we also want to retain the point of the original version of the paragraph, which we feel is still valid. For requirement M5, we propose: "M5. LDAP replication MUST NOT require that all copies of the replicated information be complete, but MAY require that at least one copy be complete. The model MUST support Partial Replicas." We agree with Kurt's point and we think this wording captures it. For Section 5 (Security Considerations) we propose: "This document includes security requirements (listed in section 4.8 above) for the replication model and protocol. As noted in Section 3, interoperability may be impacted when replicating among servers that implement non-standard extensions to basic LDAP semantics. Since LDAPv3 access control is a set of standards-based extensions, security-related and even general LDAP interoperability will be significantly impacted by the degree of consistency with which LDAP implementations support the access control model [ACModel]." [ACModel] is the current Access Control Model draft (draft-ietf-ldapext-acl-model-08.txt); it will be added to the references. If these changes are acceptable to the list, we will resubmit the draft. Since these are relatively minor changes resulting from WG last call, we assume the new draft would go to the IESG. Rick Huber (for the editors) Christopher Apple wrote: > Thanks. What do the document editors think about > the proposed text changes? Other WG members? > > Chris Apple > Program Manager - Directory Services > United Messaging Inc. > > > (V) 610-425-2860 > > >-----Original Message----- > >From: Kurt D. Zeilenga [mailto:Kurt@OpenLDAP.org] > >Sent: Friday, July 06, 2001 3:49 PM > >To: Christopher Apple > >Cc: Christopher Apple; john.strassner@intelliden.com; > >ietf-ldup@imc.org > >Subject: RE: Correction to Last Call posting > > > > > >I've restricted my comments to just those issues in which > >you explicitly requested further comment. In regards to > >my other comments, I believe the WG has adequately > >addressed my concerns (not necessarily to my liking) and > >hence I support (with previously stated reservations) > >the progression of this document after these remaining > >issues are addressed (not necessarily to my liking). > > > >Kurt > > > >At 02:20 PM 7/5/2001, Christopher Apple wrote: > >> >-----Original Message----- > >> >From: Kurt D. Zeilenga [mailto:Kurt@OpenLDAP.org] > >> >Sent: Wednesday, June 27, 2001 7:41 PM > >> >To: Christopher Apple; john.strassner@intelliden.com > >> >Cc: ietf-ldup@imc.org > >> >Subject: Re: Correction to Last Call posting > >> > > >> > > >> >This message mostly reiterates previously raised issues. > >> > > >> >Section 3: > >> > Interoperability among directories using LDUP > >replication may be > >> > limited for implementations that add semantics beyond > >> >those specified > >> > by the LDAP core documents (RFC 2251-2256, 2829, 2830). > >> > > >> >I note that Interoperability among directories using LDUP > >> >replication > >> >may also be limited for implementations which > >implement different > >> >subsets of the semantics defined in the LDAP "core" > >specification. > >> >For example, one implementation may support subtyping > >another not. > >> >Another may require ;binary for some standard track attribute > >> >while another disallows ;binary for same. As an alternative to > >> >adding a clarification to the statement (as I would prefer), > >> >removing the statement (as it doesn't place a requirement upon > >> >LDUP) would be acceptable. > >> > >>Please propose full replacement text for the statement you > >>are commenting on. I can't determine exactly what you are > >>proposing to add as clarifying text based on what you wrote. > > > > As LDAP "core" specification includes numerous features > > which are not mandatory-to-implement (e.g. RECOMMENDED > > or OPTIONAL) as well supports elective extensions, > > interoperability between independent implementations of > > LDAP and the LDUP replication extension may be limited. > > Use of applicability statements to improve interoperability > > in particular application spaces is RECOMMENDED. > > > >My point is not that this LDAP Replication issue is not limited > >just by "semantics beyond" the core specification, but to > >non-mandatory semantics within the core specification and > >"semantics beyond". And, I believe both can be addressed > >through use of applicability statements (which narrows the > >applicable specifications). > > > >> >M5. LDAP replication MUST NOT require all copies of > >the replicated > >> >information to be complete copies of the replicated object. > >> > The model > >> >MUST support Partial Replicas. > >> > > >> >I assume this applies to copies, not to the original. > >> >That is, I assume that LDAP replication MAY require > >> >some master (if not all masters) to hold a complete > >> >instance of the object. Some clarification here may > >> >be appropriate. > >> > >>Please propose clarifying text explicitly so the WG can > >>evaluate it. I can't tell quite what to suggest as clarifying > >>text based on your comment. > > > >LDAP replication MUST NOT require all copies of the replicated > >information to be complete copies of the replicated object > >but MAY require that a complete copy to be held by at least > >one replica. The model MUST support Partial Replicas. > > > > > >>This issue is unresolved. > >> > >> > > >> >Security Considerations: > >> > "As noted in Section 3, security may be impacted..." > >> > > >> >Section 3 makes no statement about security. It makes a > >> >statement about interoperability. > >> > >>Current Text: > >> > >>This document includes security requirements (listed in section 4.8 > >>above) for the replication model and protocol. As noted in > >Section 3, > >>security may be impacted when replicating among servers > >that implement > >>non-standard extensions to basic LDAP semantics. Access > >control is one > >>common case which affects security; work to address this > >issue is going > >>on in LDAPEXT as documented in RFC 2820 [RFC2820]. > >> > >>Proposed Text to clarify the section based on Kurt's comment: > >> > >>This document includes security requirements (listed in section 4.8 > >>above) for the replication model and protocol. > >> > >>As noted in Section 3, interoperability may be impacted when > >>replicating among servers that implement non-standard extensions > >>to basic LDAP semantics. Since LDAPv3 access control work is being > >>treated as a set of standards-based extensions, security-related > >>and even general LDUP interoperability will be significantly > >>impacted by the degree of consistency with which LDUP > >>implementations support the LDAPv3 access control requirements > >>documented in RFC 2820 [RFC2820]. > >> > >>This issue is unresolved until we hear from at least the > >>document editors about whether or not this proposed text > >>fits or not. Also need some reaction from Kurt about whether > >>this clarifies the text based on his perspective. If not, > >>I think it would be reasonable for us to expect to see > >>an explicit proposal for the text to be contained in the > >>section. > > > >The suggested text addresses my concerns. > > From owner-ietf-ldup@mail.imc.org Tue Jul 10 18:12:24 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA26998 for ; Tue, 10 Jul 2001 18:12:23 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.3/8.11.3) id f6ALv4706807 for ietf-ldup-bks; Tue, 10 Jul 2001 14:57:04 -0700 (PDT) Received: from hawk.ummail.com (hawk.ummail.com [216.33.108.203]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f6ALv3m06803 for ; Tue, 10 Jul 2001 14:57:03 -0700 (PDT) Received: from ex01.ummail.com [216.33.108.253:25] by hawk.ummail.com with SMTP id W0710-1756-669400; Tue, 10 Jul 2001 21:56:48 GMT Received: by ex01.ummail.com with Internet Mail Service (5.5.2650.21) id ; Tue, 10 Jul 2001 17:54:56 -0400 Message-ID: From: Christopher Apple To: "'Richard Huber'" Cc: "'Kurt D. Zeilenga'" , john.strassner@intelliden.com, ietf-ldup@imc.org Subject: RE: Correction to Last Call posting Date: Tue, 10 Jul 2001 17:54:48 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) MIME-Version: 1.0 Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_00E0_01C10969.5C04D080" X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: owner-ietf-ldup@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multi-part message in MIME format. ------=_NextPart_000_00E0_01C10969.5C04D080 Content-Type: multipart/mixed; boundary="----=_NextPart_001_00E1_01C10969.5C04D080" ------=_NextPart_001_00E1_01C10969.5C04D080 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit >-----Original Message----- >From: Richard Huber [mailto:rvh@att.com] >Sent: Tuesday, July 10, 2001 5:22 PM >To: Christopher Apple >Cc: 'Kurt D. Zeilenga'; john.strassner@intelliden.com; >ietf-ldup@imc.org >Subject: Re: Correction to Last Call posting > > >We basically agree with the three proposed changes, but we >did make some >edits. For the first change (to the last paragraph of >Section 3), we >propose this wording: > >"Interoperability among directories using LDAP replication >may be limited >for implementations that add semantics beyond those >specified by the LDAP >core documents (RFC 2251-2256, 2829, 2830). In addition, the "core" >specifications include numerous features which are not >mandatory-to-implement (e.g. RECOMMENDED or OPTIONAL). >There are also >numerous elective extensions. Thus LDAP replication >interoperability >between independent implementations of LDAP which support >different options >may be limited. Use of applicability statements to improve >interoperability >in particular application spaces is RECOMMENDED." > >We agree with Kurt's comment, but we also want to retain >the point of the >original version of the paragraph, which we feel is still valid. > >For requirement M5, we propose: > >"M5. LDAP replication MUST NOT require that all copies of >the replicated >information be complete, but MAY require that at least one copy be >complete. The model MUST support Partial Replicas." > >We agree with Kurt's point and we think this wording captures it. > >For Section 5 (Security Considerations) we propose: > >"This document includes security requirements (listed in >section 4.8 above) >for the replication model and protocol. As noted in Section 3, >interoperability may be impacted when replicating among servers that >implement non-standard extensions to basic LDAP semantics. >Since LDAPv3 >access control is a set of standards-based extensions, >security-related and >even general LDAP interoperability will be significantly >impacted by the >degree of consistency with which LDAP implementations >support the access >control model [ACModel]." > >[ACModel] is the current Access Control Model draft >(draft-ietf-ldapext-acl-model-08.txt); it will be added to >the references. > >If these changes are acceptable to the list, we will >resubmit the draft. >Since these are relatively minor changes resulting from WG >last call, we >assume the new draft would go to the IESG. Count on it. > >Rick Huber (for the editors) Chris Apple Program Manager - Directory Services United Messaging Inc. (V) 610-425-2860 ------=_NextPart_001_00E1_01C10969.5C04D080 Content-Type: text/x-vcard; name="Chris Apple (E-mail).vcf" Content-Disposition: attachment; filename="Chris Apple (E-mail).vcf" Content-Transfer-Encoding: quoted-printable BEGIN:VCARD VERSION:2.1 N:Apple;Chris FN:Chris Apple (E-mail) ORG:UMI TITLE:Program Manager TEL;WORK;VOICE:(610) 425-2860 TEL;HOME;VOICE:(215) 873-0850 TEL;CELL;VOICE:(610) 585-4241 TEL;WORK;FAX:(610) 425-6501 ADR;WORK:;;1161 McDermott Drive;West Chester;Pa.;19380;United States of = America LABEL;WORK;ENCODING=3DQUOTED-PRINTABLE:1161 McDermott = Drive=3D0D=3D0AWest Chester, Pa. 19380=3D0D=3D0AUnited States of Amer=3D ica EMAIL;PREF;INTERNET:christopher.apple@unitedmessaging.com REV:20010621T205341Z END:VCARD ------=_NextPart_001_00E1_01C10969.5C04D080-- ------=_NextPart_000_00E0_01C10969.5C04D080 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIF1TCCAqQw ggINoAMCAQICAwT8XjANBgkqhkiG9w0BAQQFADCBkjELMAkGA1UEBhMCWkExFTATBgNVBAgTDFdl c3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3duMQ8wDQYDVQQKEwZUaGF3dGUxHTAbBgNVBAsT FENlcnRpZmljYXRlIFNlcnZpY2VzMSgwJgYDVQQDEx9QZXJzb25hbCBGcmVlbWFpbCBSU0EgMjAw MC44LjMwMB4XDTAxMDYwODE1NDgwOVoXDTAyMDYwODE1NDgwOVowVzEfMB0GA1UEAxMWVGhhd3Rl IEZyZWVtYWlsIE1lbWJlcjE0MDIGCSqGSIb3DQEJARYlY2hyaXN0b3BoZXIuYXBwbGVAdW5pdGVk bWVzc2FnaW5nLm5ldDCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEA0wb7dpXj0lZuRfGhErPC qQTyvOGL3DHONyKLfJEfbD3A/0zqEnkjKamgGiD7PVFc0Gwok9x/2Jl/mQO52ArIPO0AkSYY/KaZ mWKaFXxh1LedYLyNb5PRe1kN6y0EAva1D4nwyZmToJMBUqLNsvMGjPmLUuBwdbHLEdAAVo7Gp6kC AwEAAaNCMEAwMAYDVR0RBCkwJ4ElY2hyaXN0b3BoZXIuYXBwbGVAdW5pdGVkbWVzc2FnaW5nLm5l dDAMBgNVHRMBAf8EAjAAMA0GCSqGSIb3DQEBBAUAA4GBAIqkT3GDgyKLYOzIJ9h/OsiFbiefYTbc ALptWnwegAeXbfjhq+BUJN2ICWxfQtTCupvAG6mW4J2qI422TLc31Gf7uu5r93ppFDrCGYAM2mgH tqKgztYQmAsGPf2TijDOeE7JRbQ7dZJu4BJvuE3SY9PdI/umjiOh/WG/gaZNdl0bMIIDKTCCApKg AwIBAgIBDDANBgkqhkiG9w0BAQQFADCB0TELMAkGA1UEBhMCWkExFTATBgNVBAgTDFdlc3Rlcm4g Q2FwZTESMBAGA1UEBxMJQ2FwZSBUb3duMRowGAYDVQQKExFUaGF3dGUgQ29uc3VsdGluZzEoMCYG A1UECxMfQ2VydGlmaWNhdGlvbiBTZXJ2aWNlcyBEaXZpc2lvbjEkMCIGA1UEAxMbVGhhd3RlIFBl cnNvbmFsIEZyZWVtYWlsIENBMSswKQYJKoZIhvcNAQkBFhxwZXJzb25hbC1mcmVlbWFpbEB0aGF3 dGUuY29tMB4XDTAwMDgzMDAwMDAwMFoXDTAyMDgyOTIzNTk1OVowgZIxCzAJBgNVBAYTAlpBMRUw EwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEPMA0GA1UEChMGVGhhd3Rl MR0wGwYDVQQLExRDZXJ0aWZpY2F0ZSBTZXJ2aWNlczEoMCYGA1UEAxMfUGVyc29uYWwgRnJlZW1h aWwgUlNBIDIwMDAuOC4zMDCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEA3jMypmPHCSVFPtJu eCdngcXaiBmClw7jRCmKYzUqbXA8+tyu9+50bzC8M5B/+TRxoKNtmPHDT6Jl2w36S/HW3WGl+YXN VZo1Gp2Sdagnrthy+boC9tewkd4c6avgGAOofENCUFGHgzzwObSbVIoTh/+zm51JZgAtCYnslGvp oWkCAwEAAaNOMEwwKQYDVR0RBCIwIKQeMBwxGjAYBgNVBAMTEVByaXZhdGVMYWJlbDEtMjk3MBIG A1UdEwEB/wQIMAYBAf8CAQAwCwYDVR0PBAQDAgEGMA0GCSqGSIb3DQEBBAUAA4GBAHMbbyZli/8V NEtZYortRL5Jx+gNu4+5DWomKmKEH7iHY3QcbbfPGlORS+HN5jjZ7VD0Omw0kqzmkpxuwSMBwgmn 70uuct0GZ/VQby5YuLYLwVBXtewc1+8XttWIm7eiiBrtOVs5fTT8tpYYJU1q9J3Fw5EvqZa4BTxS /N3pYgNIMYICqjCCAqYCAQEwgZowgZIxCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENh cGUxEjAQBgNVBAcTCUNhcGUgVG93bjEPMA0GA1UEChMGVGhhd3RlMR0wGwYDVQQLExRDZXJ0aWZp Y2F0ZSBTZXJ2aWNlczEoMCYGA1UEAxMfUGVyc29uYWwgRnJlZW1haWwgUlNBIDIwMDAuOC4zMAID BPxeMAkGBSsOAwIaBQCgggFlMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkF MQ8XDTAxMDcxMDIxNTQyM1owIwYJKoZIhvcNAQkEMRYEFJ2eABqDkZo7/LxL1srosinR2Hu/MFgG CSqGSIb3DQEJDzFLMEkwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwICAgCAMAcGBSsOAwIHMA0GCCqG SIb3DQMCAgEoMAcGBSsOAwIaMAoGCCqGSIb3DQIFMIGrBgkrBgEEAYI3EAQxgZ0wgZowgZIxCzAJ BgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEPMA0G A1UEChMGVGhhd3RlMR0wGwYDVQQLExRDZXJ0aWZpY2F0ZSBTZXJ2aWNlczEoMCYGA1UEAxMfUGVy c29uYWwgRnJlZW1haWwgUlNBIDIwMDAuOC4zMAIDBPxeMA0GCSqGSIb3DQEBAQUABIGAhc7KS6Lq rqqs8c3bHQw8EltDyElrWgd5T/dTAkKsFxEuOV8R+uig1iItNyXDEYXTagjdblgRe2FiBvQxBGXZ aIHCFpm2QTZAk1G2A6KBBCzReS8wggYN3CU1ExyjAQnlkeE3J+uuBuRs7+CnDYyxnO1rxZHGECzO LJaQgxdECcsAAAAAAAA= ------=_NextPart_000_00E0_01C10969.5C04D080-- From owner-ietf-ldup@mail.imc.org Tue Jul 10 22:49:55 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id WAA06267 for ; Tue, 10 Jul 2001 22:49:54 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.3/8.11.3) id f6B2XSo13067 for ietf-ldup-bks; Tue, 10 Jul 2001 19:33:28 -0700 (PDT) Received: from pretender.boolean.net (root@router.boolean.net [198.144.206.49]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f6B2XRm13063 for ; Tue, 10 Jul 2001 19:33:27 -0700 (PDT) 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 f6B2T9C15680; Wed, 11 Jul 2001 02:29:10 GMT (envelope-from Kurt@OpenLDAP.org) Message-Id: <5.1.0.14.0.20010710192335.02a602a8@127.0.0.1> X-Sender: kurt@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Tue, 10 Jul 2001 19:29:09 -0700 To: Richard Huber From: "Kurt D. Zeilenga" Subject: Re: Correction to Last Call posting Cc: Christopher Apple , john.strassner@intelliden.com, ietf-ldup@imc.org In-Reply-To: <3B4B71F3.C31AB64A@att.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-ldup@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: At 02:21 PM 7/10/2001, Richard Huber wrote: >We basically agree with the three proposed changes, but we did make some >edits. Theses changes adequate address my concerns in these particular areas. While I have other reservations (as previously noted), I concur that the revised document can be progressed as representing WG consensus. Kurt From owner-ietf-ldup@mail.imc.org Fri Jul 13 09:08:21 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA03719 for ; Fri, 13 Jul 2001 09:08:19 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.3/8.11.3) id f6DCfDe17815 for ietf-ldup-bks; Fri, 13 Jul 2001 05:41:13 -0700 (PDT) Received: from e1.ny.us.ibm.com (e1.ny.us.ibm.com [32.97.182.101]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f6DCfBq17811 for ; Fri, 13 Jul 2001 05:41:11 -0700 (PDT) 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 IAA400116; Fri, 13 Jul 2001 08:39:06 -0400 Received: from d01mlc96.pok.ibm.com (d01mlc96.pok.ibm.com [9.117.250.33]) by northrelay02.pok.ibm.com (8.11.1m3/NCO v4.96.1.0) with ESMTP id f6DCYk9195638; Fri, 13 Jul 2001 08:34:46 -0400 To: internet-drafts@ietf.org Cc: ietf-ldup@imc.org, john.strassner@intelliden.com, christopher.apple@unitedmessaging.com X-Mailer: Lotus Notes Release 5.0.5 September 22, 2000 From: "Timothy Hahn" Message-ID: Date: Fri, 13 Jul 2001 08:40:54 -0400 Subject: new LDUP information model internet draft X-MIMETrack: Serialize by Router on D01MLC96/01/M/IBM(Release 5.0.8 SPR #MIAS4UTJ8H |June 21, 2001) at 07/13/2001 08:41:01 AM MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="=_mixed 004558AC85256A88_=" Sender: owner-ietf-ldup@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: --=_mixed 004558AC85256A88_= Content-Type: multipart/alternative; boundary="=_alternative 004558B185256A88_=" --=_alternative 004558B185256A88_= Content-Type: text/plain; charset="us-ascii" Greetings, Internet Drafts publisher: please publish this as a submission in support of the LDUP work group in the applications area. This internet draft replaces the now expired darft-ietf-ldup-infomod-02.txt internet draft. LDAP-LDUP members: I welcome your comments on this submission. 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 004558B185256A88_= Content-Type: text/html; charset="us-ascii"
Greetings,

Internet Drafts publisher: please publish this as a submission in support of the LDUP work group in the applications area.  This internet draft replaces the now expired darft-ietf-ldup-infomod-02.txt internet draft.

LDAP-LDUP members: I welcome your comments on this submission.



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 004558B185256A88_=-- --=_mixed 004558AC85256A88_= Content-Type: text/plain; name="draft-ietf-ldup-infomod2-00.txt" Content-Disposition: attachment; filename="draft-ietf-ldup-infomod2-00.txt" Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable =20 Internet Draft Ed Reed=20 Document: draft-ietf-ldup-infomod2-00.txt Reed-Matthews, Inc=20 Expires: January 2002 T. Hahn=20 IBM=20 July 2001=20 =20 LDUP Replication Information Model=20 =20 =20 =20 1. Status of this Memo=20 =20 This document is an Internet-Draft and is in full conformance=20 with all provisions of Section 10 of RFC2026.=20 =20 =20 Internet-Drafts are working documents of the Internet Engineering=20 Task Force (IETF), its areas, and its working groups. Note that =20 other groups may also distribute working documents as Internet- Drafts.=20 =20 Internet-Drafts are draft documents valid for a maximum of six=20 months and may be updated, replaced, or obsoleted by other documents=20 at any time. It is inappropriate to use Internet-Drafts as=20 reference material or to cite them other than as "work in progress."=20 =20 The list of current Internet-Drafts can be accessed at=20 http://www.ietf.org/ietf/1id-abstracts.txt=20 =20 The list of Internet-Draft Shadow Directories can be accessed at=20 http://www.ietf.org/shadow.html.=20 =20 This Internet-Draft expires January, 2002.=20 =20 =20 2. Abstract=20 =20 [LDUP Model] describes the architectural approach to replication of=20 LDAP directory contents. This document describes the information=20 model and schema elements which support LDAP Replication Services=20 which conform to [LDUP Model].=20 =20 Directory schema is extended to provide object classes, subentries,=20 and attributes to describe areas of the namespace which are under=20 common administrative authority, units of replication (ie, subtrees,=20 or partitions of the namespace, which are replicated), servers which=20 hold replicas of various types for the various partitions of the=20 namespace, which namespaces are held on given servers, and the=20 progress of various namespace management and replication operations. =20 Among other things, this knowledge of where directory content is=20 located will provide the basis for dynamic generation of LDAP=20 referrals for clients who can follow them.=20 =20 =20 Reed Standards Track - Expires January 2002 [Page 1] =0C LDUP Information Model =20 The controlling framework by which the relationships, types, and=20 health of replicas of the directory content will be defined so that,=20 as much as possible, directory content is itself used to monitor and=20 control the environment.=20 =20 Security information, including access control policy identifiers=20 and information will be treated as directory content by the=20 replication protocols when specified by the LDAPEXT group. =20 =20 The information model will describe required and optional house- keeping duties for compliant systems to implement, such as garbage=20 collection of deleted objects, reconciliation of moved and renamed=20 objects, update sequencing and transaction bracketing of changes,=20 etc.=20 =20 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",=20 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in=20 this document are to be interpreted as described in RFC 2119=20 [RFC2119]. The sections below reiterate these definitions and=20 include some additional ones.=20 =20 Reed Standards Track - Expires January 2002 [Page 2] =0C LDUP Information Model =20 =20 3. Table of Contents=20 =20 =20 1. Status of this Memo............................................1=20 2. Abstract.......................................................1=20 3. Table of Contents..............................................3=20 4. Recent document changes........................................5=20 5. Introduction...................................................7=20 5.1. Scope.......................................................7=20 5.2. Terms and Definitions.......................................7=20 6. Data design....................................................7=20 7. Directory Knowledge............................................7=20 8. Schema.........................................................8=20 8.1. Data Structure Definitions..................................8=20 8.1.1. LdapChangeSequenceNumber..................................9=20 8.2. Attribute Definitions......................................10=20 8.2.1. supportedReplicationProtocols............................10=20 8.2.2. replicaContextRoots......................................10=20 8.2.3. replicaSubentries........................................11=20 8.2.4. attributeExclusionFilter.................................11=20 8.2.5. attributeInclusionFilter.................................11=20 8.2.6. replicaURI...............................................12=20 8.2.7. replicationStatus........................................12=20 8.2.8. replicaType..............................................13=20 8.2.9. updateVector.............................................14=20 8.2.10. replicaSecondaryURI......................................14=20 8.2.11. lostAndFoundEntryDN......................................14=20 8.2.12. replicaOnline............................................15=20 8.2.13. replicaDN................................................15=20 8.2.14. replicationMechanismOID..................................15=20 8.2.15. replicationCredentialsDN.................................16=20 8.2.16. replicationScheduleDN....................................16=20 8.2.17. updateVectorTrigger......................................16=20 8.2.18. secondsToWaitDefault.....................................17=20 8.2.19. secondsToWait1...........................................17=20 8.2.20. attrs1...................................................18=20 8.2.21. secondsToWait2...........................................18=20 8.2.22. attrs2...................................................18=20 8.2.23. scheduleTimePeriod.......................................19=20 8.2.24. scheduleMonthOfYearMask..................................19=20 8.2.25. scheduleDayOfMonthMask...................................19=20 8.2.26. scheduleDayOfWeekMask....................................19=20 8.2.27. scheduleTimeOfDayMask....................................20=20 8.2.28. scheduleLocalOrUtcTime...................................20=20 8.3. Class Definitions..........................................20=20 8.3.1. ReplicationContext.......................................20=20 8.3.2. replicaSubentry..........................................21=20 =20 Reed Standards Track - Expires January 2002 [Page 3] =0C LDUP Information Model =20 8.3.3. replicaAgreementSubentry.................................22=20 8.3.4. replicaEventSchedule.....................................23=20 8.3.5. replicaTimeSchedule......................................24=20 9. Semantics of the information model............................25=20 10. Object Identifier Assignments...............................28=20 11. Security Considerations.....................................29=20 12. Copyright Notice............................................30=20 13. Acknowledgements............................................31=20 14. Authors=92 Addresses..........................................31=20 =20 =20 Reed Standards Track - Expires January 2002 [Page 4] =0C LDUP Information Model =20 =20 4. Recent document changes=20 =20 Changes in this version=20 =20 =AD Made obsolete replicaSubEntry and replicaAgreementSubentry=20 object classes=20 =AD Defined replacement object classes replicaSubEntry2 and=20 replicaAgreementSubentry2=20 =AD Defined replicaEventSchedule and replicaTimeSchedule object=20 classes and associated attributes=20 =AD Defined attributes that must appear in the server=92s root DSE=20 entry as part of the LDUP information model=20 =AD Many editorial fixes=20 =AD Clarified the notion that the updateVector is a replicated=20 attribute and thus, itself, has CSN information for its=20 attribute values=20 =AD Introduced the notion that replicaAgreementSubentry entries=20 represent constraints to what is, by default, =93immediate=94=20 replication session initiation=20 =20 Changes made to previous revisions=20 =20 =AD LDAP Schedule Subentry definition is defined.=20 =AD LDAP Access Point removed in favor of just using the DN of the=20 server holding the replica (so a new syntax isn=92t required).=20 =AD LDAP Change Sequence Number syntax eleminated in favor of just=20 calling it a CaseIgnoreString, so new comparison rules aren=92t=20 required.=20 =AD Deleted ldapSearchFilter definition from here. Sparse replicas=20 is deferred. Might sparse be supported for single-master=20 configurations (read-only, of course). =20 =AD Fractional are okay in multi-master configurations, but again,=20 only on read-only replicas.=20 =AD Changed the naming convention upper-lower case usage to look=20 less weird.=20 =AD Note:=20 =AD Consistency discussion=20 =AD Schema document must clearly indicate that clients can and=20 should inspect the replica subentries to understand the single- master/multi-master nature of the naming context to which=20 they=92re talking.=20 =AD The paradigm change, to distributed data, needs to be=20 exhaustively discussed in the profile documents. How old=20 applications which assume single-master behave or misbehave in=20 a multi-master environment is critical to make clear. Draw=20 examples from SMP pre-emptive programming practices, from DNS=20 vs host file models, etc.=20 =20 Decisions from wash ietf=85=20 =20 =AD define two simple schema classes =96 event driven histeresis=20 buckets, and cron-like thing. Then, the replica has a single=20 =20 Reed Standards Track - Expires January 2002 [Page 5] =0C LDUP Information Model =20 value pointer to a schedule. More schedule things can be=20 defined in the future.=20 =AD Create attribute ReplicaURI to provide service access point for=20 that replica. No DSA entry requirement.=20 =AD Replica id table discussion should move to protocol spec.=20 =AD Decisions from Adelaide=20 =AD Followup with Chris Harding about GUID=20 =AD Forget trying to define a schedule class, and just define a dn=20 reference to the policy, and leave the policy element itself to=20 implementations and future documentation=20 =20 To do:=20 =20 =AD verify LDUP OID number(s) with Novell=20 =AD verify all OIDs assigned=20 =AD verify all OIDs documented at the end of the document=20 =20 =20 Reed Standards Track - Expires January 2002 [Page 6] =0C LDUP Information Model =20 5. Introduction=20 =20 5.1. Scope=20 =20 This document describes schema of subentries representing replicas,=20 replication agreements and their dependencies.=20 =20 Management and status schema elements may be defined if there is=20 sufficient consensus.=20 =20 Semantic interpretation of schema elements, including any special=20 handling expectations are to be provided here.=20 =20 5.2. Terms and Definitions=20 =20 Definitions are provided in [LDUP Requirements], and may be=20 reproduced here for the convenience of the reader.=20 =20 6. Data design=20 =20 As described in [LDUP Model], knowledge of replicated portions of=20 the directory information tree (DIT) is stored in the directory=20 itself.=20 =20 An auxiliary class is defined to designate containers, or nodes, in=20 the DIT which are the root-most, or base, of replication contexts. =20 Directory subentries [LDAP Subentry] are used to hold information=20 about replicas and replica agreements.=20 =20 In defining the replication agreement data model, describing the=20 constraints under which replication between two replicas will occur,=20 this document describes only the least set of information necessary=20 to ensure interoperability between implementations. The=20 specification of complex replication agreements and constraints is=20 better served by usage of the emerging =93policy model=94 [Policy=20 schema]. Interoperable policies for replication agreements is left=20 as a follow-on work effort.=20 =20 7. Directory Knowledge=20 =20 Information about what replicas exist, what they contain, their=20 types, where they are stored, and how they may be contacted=20 inevitably provides the basis for distributed directory knowledge. =20 As namespaces from stand-alone servers are inter-connected with one=20 another, this replica information can and will be used by name=20 resolution operations to locate servers holding copies of specific=20 objects, and to optimize distributed searches which span multiple=20 Naming Contexts.=20 =20 However, the focus of this document is NOT to fully enable such=20 distributed directory uses. Instead, we are focused on how portions=20 of the namespace (Directory Information Tree - DIT) may be=20 replicated, and how those replicas are configured and related to one=20 another via Replication Agreements.=20 =20 Reed Standards Track - Expires January 2002 [Page 7] =0C LDUP Information Model =20 =20 As such, the following high level description (from [LDUP Model])of=20 the information model envisioned is provided as reference for the=20 reader before presenting the detailed specifications.=20 =20 Generally, the DSE Naming Context attribute of an LDAPv3 server=20 names the Naming Contexts for which there are replicas on that=20 server.=20 =20 The Replication Context Auxiliary Class (replicationContext) is=20 added to container objects which may have separately defined=20 replication policy.=20 =20 Immediately subordinate to a Replication Context object are the=20 Replica Subentry containers which identify where the identified=20 replica resides (ie, its LDAP Access Point), its type (Primary,=20 Updateable, ReadOnly), if it is sparse, the LDAP search filter which=20 defines what object classes it holds, and if it is fractional, the=20 attributes it does or does not hold.=20 =20 Immediately subordinate in the namespace to a Replica Subentry are=20 Replication Agreement leaf entries which each identify another=20 Replica, the scheduling policy for replication operations (including=20 times when replication is to be performed, when it is not to be=20 performed, or the policies governing event-driven replication=20 initiation). These Replication Agreement subentries are used to=20 specify constraints on when the replica will supply what changes to=20 the =93pointed to=94 other replica, as either the replication initiator = or responder.=20 =20 Replication Agreement subentries are not defined to cover the=20 following advanced policy characteristics:=20 =20 - when a replica would allow consumers to request a replication=20 session=20 - when a replica would allow suppliers to start a replication=20 session=20 - when a replica would request a replication session from a=20 supplier.=20 =20 These advanced policy specifications imply the specification of=20 complex replication agreements and constraints. This is better=20 served by usage of the emerging =93policy model=94 [Policy schema]. =20 Interoperable policies for replication agreements is left as a=20 follow-on work effort.=20 =20 =20 8. Schema=20 =20 8.1. Data Structure Definitions=20 =20 For the purposes of defining the encoding rules for attribute=20 structures, the BNF definitions in section 4.1 of [RFC2252] will be=20 used. They are based on the BNF styles of [RFC822].=20 =20 Reed Standards Track - Expires January 2002 [Page 8] =0C LDUP Information Model =20 =20 To avoid requiring new syntax support to be added unnecessarily to=20 existing LDAPv3 directory service implementations (and the=20 accompanying matching rules, etc. they would entail), a string=20 encoding is defined for ldapChangeSequenceNumber which can use=20 CaseIgnoreString matching rules for ordering and equality.=20 =20 8.1.1. LdapChangeSequenceNumber=20 =20 ( 1.3.6.1.4.1.1466.115.121.1.TBD=20 DESC 'LDAP Change Sequence Number' )=20 =20 Values in this syntax are encoded according to the following BNF. =20 Note there MUST NOT be any whitespace separators, unless they are in=20 replicaID, which must be encoded according to the instructions=20 below.=20 =20 This encoding is specified so that the CaseIgnoreString equality and=20 ordering rules will work correctly when replicaNumber is used.=20 When replicaID is used, CaseIgnoreString comparison rules will not=20 work unless each replicaID is exactly the same length with no padded=20 white spaces (because CaseIgnoreString suppresses duplicate adjacent=20 white space when it compares two strings).=20 =20 LDAPChangeSequenceNumber =3D GeneralizedZTime "#" \=20 S1 "#" replicaID "#" S2=20 =20 GeneralizedZTime =3D yyyy | mm | dd | hh | mi | ss | "Z"=20 =20 yyyy =3D dddd =20 =20 mm =3D dd =20 =20 dd =3D dd =20 =20 hh =3D dd =20 =20 mi =3D dd =20 =20 ss =3D dd =20 =20 replicaID =3D dstring =20 =20 S1, S2 =3D numericstring=20 =20 The GeneralizedTime is used as described (cf. [X680] section 39.3=20 case b) without separators or whitespace, and representing a=20 coordinated universal time (i.e., Greenwich Mean Time, or GMT). All=20 times referenced by this syntax MUST be normalized to GMT - no local=20 times, nor time zone offsets are permitted. To simplify comparisons=20 of two CSNs, the "Z" MUST be the UTF-8 capital-Z character.=20 =20 The ReplicaID represents the specific Replica of this Naming Context=20 where the event associated with this LDAPChangeSequenceNumber=20 =20 Reed Standards Track - Expires January 2002 [Page 9] =0C LDUP Information Model =20 occurred. Note that in actual transfer, the ReplicaID MAY be=20 represented by a number (see the specification of the=20 replicaLookupTable, above).=20 =20 S1 and S2 are sequence numbers which are used to order two events=20 with the same Generalized Time and ReplicaID. In order to use=20 string matching rules for equality and ordering with values with=20 this encoding, the length of each field must be consistent. Thus,=20 all instances of S1 MUST be represented with the same number of=20 digits, using leading zeros as necessary. The same with S2 and=20 replicaID.=20 =20 8.2. Attribute Definitions=20 =20 8.2.1. supportedReplicationProtocols=20 =20 ( 2.16.840.1.113719.142.4.x NAME =91supportedReplicationProtocols=92=20 SYNTAX 1.3.6.1.4.1.1466.115.121.1.26=20 EQUALITY caseIgnoreMatch=20 DESC =91set of OIDs which represent the (set of) protocols=20 supported by this server=92 )=20 =20 This attribute is added to the root DSE entry of servers which=20 support replication as defined by [LDUP Model].=20 =20 8.2.2. replicaContextRoots=20 =20 ( 2.16.840.1.113719.142.4.x NAME =91replicaContextRoots=92=20 SYNTAX 1.3.6.1.4.1.1466.115.121.1.12=20 EQUALITY distinguishedNameMatch=20 DESC =91names of the roots of all replicated areas (replication=20 contexts that are held on this server.=92 )=20 =20 This attribute is added to the root DSE of the servers which support=20 replication as defined by [LDUP Model]. For every replication=20 context defined on this server, a value is found for this attribute=20 in the root DSE.=20 =20 The replicaContextRootss attribute is multi-valued of syntax=20 distinguished name (DN) which indicates to readers that a server=20 holds a copy (replica) of the Replication Context named. =20 =20 Servers implementing this specification MUST include this attribute=20 in their root DSE, and populate the attribute with the distinguished=20 names of the base entries of each Replication Context held on that=20 server. When replicas are added to a server, servers MUST add the=20 name of the new Replication Context base entry to this root DSE=20 attribute.=20 =20 Clients wishing to know what replicas a server holds may read this=20 root DSE attribute for a complete list of local replicas.=20 =20 When replicas are removed from the server, servers MUST remove the=20 name of the unavailable replica from this root DSE attribute.=20 =20 Reed Standards Track - Expires January 2002 [Page 10] =0C LDUP Information Model =20 =20 8.2.3. replicaSubentries=20 =20 ( 2.16.840.1.113719.142.4.x NAME =91replicaSubentries=92=20 SYNTAX 1.3.6.1.4.1.1466.115.121.1.12=20 EQUALITY distinguishedNameMatch=20 DESC =91names of all replicaSubEntry entries that correspond=20 to the replicas on this server. This is contrasted=20 with the replicaContextRoots which notes the replication=20 contexts, but not the replicaSubEntry sub-entries=20 for this server within the replication context=92 )=20 =20 This attribute in the root DSE entry names the replicaSubEntry=20 entries that correspond to the replicas that are held on =93this=94=20 server. This is slightly different than the replicaContextRoots=20 root DSE entry attribute which lists the replication contexts held=20 on this server. The replicaSubentries attribute indicates =93this=94=20 server=92s replicaSubentry entry within each replication context.=20 =20 8.2.4. attributeExclusionFilter=20 =20 ( 2.16.840.1.113719.142.4.1 NAME 'attributeExclusionFilter'=20 SYNTAX 1.3.6.1.4.1.1466.115.121.1.40=20 SINGLE-VALUE=20 NO-USER-MODIFICATION=20 USAGE dSAOperation )=20 =20 The attributeExclusionFilter is intended to contain a list of=20 attributes in the form of an AttributeDescriptionList as described=20 in section 4.5.1. Search Request of [RFC2251] with the following=20 interpretation: an empty attributeExclusionFilter means that no=20 attributes are excluded; the special values "*" and "1.1" mean that=20 ALL attributes are excluded.=20 =20 A non-empty attributeExclusionFilter attribute on a replica subEntry=20 describes the attributes NOT PRESENT on entries held by that=20 replica. Replicas MUST NOT accept changes for attributes they're=20 not permitted to hold, per the attributeInclusionFilter and=20 attributeExclusionFilter attributes on their replica subEntry.=20 =20 A non-empty attributeExclusionFilter attribute on a=20 replicationAgreement subEntry describes which additional attributes=20 are to be excluded from the updates to be sent from the supplier=20 replica to the consumer replica.=20 =20 8.2.5. attributeInclusionFilter=20 =20 ( 2.16.840.1.113719.142.4.2 NAME 'attributeInclusionFilter'=20 SYNTAX 1.3.6.1.4.1.1466.115.121.1.40=20 SINGLE-VALUE=20 NO-USER-MODIFICATION=20 USAGE dSAOperation )=20 =20 =20 Reed Standards Track - Expires January 2002 [Page 11] =0C LDUP Information Model =20 The attributeInclusionFilter is intended to contain a list of=20 attributes in the form of an AttributeDescriptionList as described=20 in section 4.5.1. Search Request of [RFC2251] with the following=20 interpretation: an empty attributeInclusionFilter means that all=20 attributes are included; the special value "*" means that ALL=20 attributes are included; the special value "1.1" is meaningless and=20 is ignored in this usage.=20 =20 A non-empty attributeInclusionFilter attribute on a replica subEntry=20 describes the attributes that may be PRESENT on entries held by that=20 replica. Replicas MUST NOT accept changes for attributes they're=20 not permitted to hold, per the attributeIncludionFilter and=20 attributeExclusionFilter attributes on their replica subEntry.=20 =20 8.2.6. replicaURI=20 =20 ( 2.16.840.1.113719.142.4.x NAME =91replicaURI=92=20 DESC =91LDAP URLs which indicate how to connect to this replica=92=20 SYNTAX 1.3.6.1.4.1.1466.115.121.1.15=20 EQUALITY caseExactMatch=20 USAGE dSAOperation )=20 =20 The replicaURI attribute is a multi-valued attribute used to list=20 the set of LDAP URLs that should be used to contact the replica for=20 replication sessions. If all URLs in the replicaURL attribute are=20 not contactable, the replicaSecondaryURL attribute values should be=20 used to establish a replication session with the replica.=20 =20 8.2.7. replicationStatus=20 =20 (2.16.840.1.113719.142.4.3 NAME 'replicationStatus'=20 DESC 'human readable status of last replication attempt'=20 SYNTAX 1.3.6.1.4.1.1466.115.121.1.15=20 SINGLE-VALUE=20 NO-USER-MODIFICATION=20 USAGE dSAOperation )=20 =20 The replicationStatus attribute MAY be used to hold a human readable=20 message describing the most recent replication session attempt for a=20 replicationAgreement.=20 =20 For example, such a messages might include =20 =20 1) 9980805162203Z # Success #=20 =20 2) 19980805162322Z # Failure # Server too busy, try again=20 =20 3) 19980805170215Z # Failure # Unable to connect to DSA=20 =20 4) 19980806002301Z # Failure # Authentication failed=20 =20 5) 19980806003201Z # Failure # lost connection, reset by peer=20 =20 =20 Reed Standards Track - Expires January 2002 [Page 12] =0C LDUP Information Model =20 It is suggested, but not required, that the time of a replication=20 attempt (completion, if successful or failure, if not), the result=20 of the attempt, and any additional information about a failure be=20 included in the string message.=20 =20 It is suggested, but not required, that the messages be stored with=20 language tags (English, French, German, Japanese, Chinese, per [LANG=20 TAG]) particularly if multiple translations of the error messages=20 are available to the DSA implementers.=20 =20 Note that this is a single-valued attribute. Sequences of status=20 entries SHOULD be written to log files or other persistent storage,=20 or in multi-valued replication history attributes, but are not=20 specified here.=20 =20 8.2.8. replicaType=20 =20 (2.16.840.1.113719.142.4.4 NAME 'replicaType'=20 DESC 'Enum: 0-reserved, 1-Primary, 2-Updateable,=20 3-ReadOnly, all others reserved'=20 SYNTAX 1.3.6.1.4.1.1466.115.121.1.27=20 EQUALITY integerMatch=20 SINGLE-VALUE=20 NO-USER-MODIFICATION=20 USAGE dSAOperation )=20 =20 ReplicaType is a simple enumeration, used to identify what kind of=20 replica is being described in a Replica object entry.=20 =20 A ReadOnly replica only accepts LDAP Search operations (to Read=20 entries, list containers, and search for entries). Because no=20 updates ever originate from ReadOnly replicas, they never have=20 changes to send to another replica. However, a ReadOnly replica may=20 be designated a supplier DSA in a replica agreement, if it is simply=20 passing along information it receives from other Updateable replicas=20 about entries and their changes.=20 =20 ReadOnly replicas may be incomplete replicas.=20 =20 An Updateable replica may accept both LDAP Search operations (to=20 read, list, or search entries), as well as modification operations=20 (to add, modify, or delete entries). =20 =20 The consequences of having incomplete updateable replicas are not=20 fully understood. LDAP DSAs MAY require updateable replicas to be=20 complete replicas.=20 =20 A Primary replica is an Updateable replica, but it is "more special"=20 than other Updateable replicas. When LDAP application want to=20 direct their operations to a single replica, so that the application=20 can be sure that all application LDAP modification (add, delete,=20 modify) operations will be immediately visible to application=20 readers, the Primary replica is a good choice. Such a use would be=20 consistent with High Confidence DAP option [X518]. One such=20 =20 Reed Standards Track - Expires January 2002 [Page 13] =0C LDUP Information Model =20 application might be a management application which creates new=20 naming contexts or joins two naming contexts into a single naming=20 context. Another application might be one which creates new=20 replicas, or replication agreements.=20 =20 There SHOULD be only one Primary replica defined for a naming=20 context at any time. If applications, expecting there to be a=20 Primary replica discover, by search or inspection of ReplicaType=20 attributes of the defined Replicas of a naming context, find more=20 than one =96 they should realize that something is wrong. =20 =20 There MAY be NO primary replica defined for a naming context. =20 Primary replicas MAY NOT be incomplete replicas.=20 =20 The way in which replicas change their type, as from ReadOnly to=20 Updateable, or Updateable to Primary is outside the scope of this=20 document.=20 =20 Section 5.1 "Replica Type" of [LDUP MODEL] details the permissible=20 combinations of replica types and sparse/fractional replicas.=20 =20 8.2.9. updateVector=20 =20 ( 2.16.840.1.113719.142.4.6 NAME 'updateVector'=20 SYNTAX 1.3.6.1.4.1.1466.115.121.1.TBD=20 EQUALITY caseIgnoreMatch=20 ORDERING caseIgnoreOrderingMatch=20 NO-USER-MODIFICATION=20 USAGE dSAOperation )=20 =20 The attribute updateVector is a multi-valued attribute which=20 contains information for a replica describing the latest changes=20 received by the replica from other replicas.=20 =20 There may be only one ldapChangeSequenceNumber entry from each=20 replica in the updateVector. That is to say, there is a unique=20 value constraint on the ReplicaID component of entries in the list.=20 =20 8.2.10. replicaSecondaryURI=20 =20 ( 2.16.840.1.113719.142.4.x NAME =91replicaSecondaryURI=92=20 DESC =91LDAP URLs which indicate how to connect to this replica=92=20 SYNTAX 1.3.6.1.4.1.1466.115.121.1.15=20 EQUALITY caseExactMatch=20 USAGE dSAOperation )=20 =20 The replicaSecondaryURI attribute is a multi-valued attribute used=20 to list the set of LDAP URLs that should be used to contact the=20 replica for replication sessions if all LDAP URLs in the replicaURL=20 attribute are not contactable. =20 =20 8.2.11. lostAndFoundEntryDN=20 =20 ( 2.16.840.1.113719.142.4.x NAME =91lostAndFoundEntryDN=92=20 =20 Reed Standards Track - Expires January 2002 [Page 14] =0C LDUP Information Model =20 SYNTAX 1.3.6.1.4.1.1466.115.121.1.12=20 EQUALITY distinguishedNameMatch=20 SINGLE-VALUE=20 DESC =91name of the entry under which orphaned entries will=20 be moved during replication update processing by this=20 replica.=92 )=20 =20 This attribute indicates the location under which the replica will=20 move orphaned entries that are encountered while performing=20 replication updates. The attribute is single-valued and is specific=20 to each replica.=20 =20 8.2.12. replicaOnline=20 =20 ( 2.16.840.1.113719.142.4.x NAME =91replicaOnline=92=20 SYNTAX 1.3.6.1.4.1.1466.115.121.1.7=20 EQUALITY booleanMatch=20 SINGLE-VALUE=20 DESC =91indicates whether or not the replica will=20 will initiate and/or respond to replication=20 session start requests.=92 )=20 =20 This attribute indicates whether the replica is ready and willing to=20 participate in replication sessions with other replicas that are=20 defined as holding the replication context.=20 =20 8.2.13. replicaDN=20 =20 ( 2.16.840.1.113719.142.4.x NAME =91replicaDN=92=20 SYNTAX 1.3.6.1.4.1.1466.115.121.1.12=20 EQUALITY distinguishedNameMatch=20 SINGLE-VALUE=20 DESC =91name of the consumer replicaSubentry entry that the=20 replicaAgreementSubentry links to.=92 )=20 =20 This attribute is used to link a replicaAgreementSubentry entry=20 (associated with a supplier of replication update information) to=20 the consumer replica that will be contacted by replication sessions=20 contrained by the replicaAgreementSubentry.=20 =20 8.2.14. replicationMechanismOID=20 =20 ( 2.16.840.1.113719.142.4.x NAME =91replicationMechanismOID=92=20 SYNTAX 1.3.6.1.4.1.1466.115.121.1.26=20 EQUALITY caseIgnoreMatch=20 SINGLE-VALUE=20 DESC =91the OID which represents the specific =20 replication protocol used for replication=20 sessions between the identified supplier and=20 consumer replicas.=92 )=20 =20 This attribute identifies the specific replication protocol used for=20 replication sessions between the supplier and consumer replicas=20 associated by the replicaAgreementSubentry entry. This attribute=20 =20 Reed Standards Track - Expires January 2002 [Page 15] =0C LDUP Information Model =20 must be a value that is within the set of attribute values for the=20 supportedReplicationProtocols attribute in the root DSE entry.=20 =20 8.2.15. replicationCredentialsDN=20 =20 ( 2.16.840.1.113719.142.4.x NAME =91replicationCredentialsDN=92=20 SYNTAX 1.3.6.1.4.1.1466.115.121.1.12=20 EQUALITY distinguishedNameMatch=20 SINGLE-VALUE=20 DESC =91name of a separate entry in the directory tree which=20 contains the credentials information used in identifying=20 the supplier replica to the consumer replica when=20 initiating a replication session.=92 )=20 =20 This attribute is used to establish a separate entry in the=20 directory tree that will hold the credentials information that is=20 used to establish the supplier=92s identity at the consumer when=20 starting a replication session. By placing credentials information=20 in a separate entry, =93pointed to=94 with this attribute, credentials=20 information can be placed in a portion of the directory tree that is=20 not replicated across multiple replicas.=20 =20 8.2.16. replicationScheduleDN=20 =20 ( 2.16.840.1.113719.142.4.x NAME =91replicationScheduleDN=92=20 SYNTAX 1.3.6.1.4.1.1466.115.121.1.12=20 EQUALITY distinguishedNameMatch=20 SINGLE-VALUE=20 DESC =91name of an entry which contains the specific=20 information used to establish when replication=20 sessions will be initiated by this replica=20 supplier.=92 )=20 =20 This attribute is used to =93point to=94 either a replicaEventSchedule=20 or replicaTimeSchedule entry which describes when replication=20 sessions should be initiated by a replica supplier. If not=20 specified, a default schedule is assumed. See the section=20 describing the replicaAgreementSubentry for more details.=20 =20 8.2.17. updateVectorTrigger=20 =20 ( 2.16.840.1.113719.142.4.x NAME =91updateVectorTrigger=92=20 SYNTAX 1.3.6.1.4.1.1466.115.121.1.7=20 EQUALITY booleanMatch=20 SINGLE-VALUE=20 DESC =91indicates whether or not updates made to the=20 replica=92s updateVector should be treated as=20 updates that cause the secondsToWaitDefault=20 attribute value to be used in determining=20 when to initiate a replication session.=92 )=20 =20 This attribute is used to indicate whether or not changes to the=20 replica=92s updateVector should be included as updates that cause the=20 =20 Reed Standards Track - Expires January 2002 [Page 16] =0C LDUP Information Model =20 secondsToWaitDefault attribute value to be used when determining=20 when to initiate replication sessions.=20 =20 If updateVectorTrigger is set to FALSE, then secondsToWaitDefault=20 will not be used when the replica=92s updateVector is updated. This=20 implies that some other update will need to be performed to the=20 replica before the updated updateVector will be sent via a=20 replication session.=20 =20 If upateVectorTrigger is set to TRUE, then updates to the=20 updateVector will be used in determining when replication sessions=20 should be initiated.=20 =20 Note that setting secondsToWaitDefault to 0 coupled with=20 updateVectorTrigger to TRUE would cause replication sessions to=20 continually =93chase themselves=94, potentially clogging networks with=20 an infinite loop of replication sessions. This combination SHOULD=20 be prevented in implementations.=20 =20 If not specified, the value for updateVectorTrigger is assumed to be=20 FALSE.=20 =20 8.2.18. secondsToWaitDefault=20 =20 (2.16.840.1.113719.142.4.x NAME 'secondsToWaitDefault'=20 SYNTAX 1.3.6.1.4.1.1466.115.121.1.27=20 EQUALITY integerMatch=20 SINGLE-VALUE=20 DESC =91The number of seconds to wait after an update=20 is made to the replica before initiating a=20 replication session.'=20 NO-USER-MODIFICATION=20 USAGE dSAOperation )=20 =20 This attribute indicates the number of seconds that a replica should=20 wait after an update is made to the replica before initiating a=20 replication session. If not specified, the value is assumed to be=20 0. This attribute value is used for updates to all attributes that=20 are NOT specified by either the attrs1 or attrs2 attributes.=20 =20 This attribute is always used for updates made to the replica=92s=20 updateVector if the updateVectorTrigger attribute is set to TRUE.=20 =20 8.2.19. secondsToWait1=20 =20 =20 (2.16.840.1.113719.142.4.x NAME 'secondsToWait1'=20 SYNTAX 1.3.6.1.4.1.1466.115.121.1.27=20 EQUALITY integerMatch=20 SINGLE-VALUE=20 DESC =91The number of seconds to wait after an update=20 is made to any attributes named in the attrs1=20 attribute before initiating a replication session.'=20 =20 Reed Standards Track - Expires January 2002 [Page 17] =0C LDUP Information Model =20 NO-USER-MODIFICATION=20 USAGE dSAOperation )=20 =20 This attribute is similar to the secondsToWaitDefault attribute in=20 how it is used. This attribute, however, is used to apply only to=20 the attributes listed in the attrs1 attribute. This allows updates=20 to different attributes to cause replication sessions to be=20 initiated either sooner or later than updates made to other=20 attributes.=20 =20 8.2.20. attrs1=20 =20 ( 2.16.840.1.113719.142.4.x NAME =91attrs1=92=20 SYNTAX 1.3.6.1.4.1.1466.115.121.1.26=20 EQUALITY caseIgnoreMatch=20 DESC =91the set of attributes that are associated with=20 the secondsToWait1 attribute. When updates are=20 made to any of these attributes on the replica,=20 a replication session will be delayed until=20 after secondsToWait1 seconds have passed.=92 )=20 =20 This attribute identifies a set of attributes that are associated=20 with the secondsToWait1 attribute. When secondsToWait1 seconds have=20 passed since an update to any attribute identified in the attrs1=20 attribute, a relication session will be initiated.=20 =20 8.2.21. secondsToWait2=20 =20 (2.16.840.1.113719.142.4.x NAME 'secondsToWait2'=20 SYNTAX 1.3.6.1.4.1.1466.115.121.1.27=20 EQUALITY integerMatch=20 SINGLE-VALUE=20 DESC =91The number of seconds to wait after an update=20 is made to any attributes named in the attrs2=20 attribute before initiating a replication session.'=20 NO-USER-MODIFICATION=20 USAGE dSAOperation )=20 =20 This attribute is similar to the secondsToWaitDefault attribute in=20 how it is used. This attribute, however, is used to apply only to=20 the attributes listed in the attrs2 attribute. This allows updates=20 to different attributes to cause replication sessions to be=20 initiated either sooner or later than updates made to other=20 attributes.=20 =20 8.2.22. attrs2=20 =20 ( 2.16.840.1.113719.142.4.x NAME =91attrs2=92=20 SYNTAX 1.3.6.1.4.1.1466.115.121.1.26=20 EQUALITY caseIgnoreMatch=20 DESC =91the set of attributes that are associated with=20 the secondsToWait2 attribute. When updates are=20 made to any of these attributes on the replica,=20 =20 Reed Standards Track - Expires January 2002 [Page 18] =0C LDUP Information Model =20 a replication session will be delayed until=20 after secondsToWait2 seconds have passed.=92 )=20 =20 This attribute identifies a set of attributes that are associated=20 with the secondsToWait2 attribute. When secondsToWait2 seconds have=20 passed since an update to any attribute identified in the attrs2=20 attribute, a relication session will be initiated.=20 =20 8.2.23. scheduleTimePeriod=20 =20 ( 2.16.840.1.113719.142.4.x NAME =91scheduleTimePeriod=92=20 SYNTAX 1.3.6.1.4.1.1466.115.121.1.44=20 EQUALITY caseIgnoreMatch=20 SINGLE-VALUE=20 DESC =91the absolute time range over which this time=20 specification is valid.=92 )=20 =20 This attribute is patterned after the TimePeriod property identified=20 in RFC 3060 [RFC3060] and [Policy Schema]. Refer to these=20 references for details on the format and interpretation of this=20 attribute.=20 =20 8.2.24. scheduleMonthOfYearMask=20 =20 ( 2.16.840.1.113719.142.4.x NAME =91scheduleMonthOfYearMask=92=20 SYNTAX 1.3.6.1.4.1.1466.115.121.1.6=20 SINGLE-VALUE=20 DESC =91mask identifying the months of the year during=20 which replication sessions should be performed.=92 )=20 =20 This attribute is patterned after the MonthOfYearMask property=20 identified in RFC 3060 [RFC3060] and [Policy Schema]. Refer to=20 these references for details on the format and interpretation of=20 this attribute.=20 =20 8.2.25. scheduleDayOfMonthMask=20 =20 ( 2.16.840.1.113719.142.4.x NAME =91scheduleDayOfMonthMask=92=20 SYNTAX 1.3.6.1.4.1.1466.115.121.1.6=20 SINGLE-VALUE=20 DESC =91mask identifying the days of the month during=20 which replication sessions should be performed.=92 )=20 =20 This attribute is patterned after the DayOfMonthMask property=20 identified in RFC 3060 [RFC3060] and [Policy Schema]. Refer to=20 these references for details on the format and interpretation of=20 this attribute.=20 =20 8.2.26. scheduleDayOfWeekMask=20 =20 ( 2.16.840.1.113719.142.4.x NAME =91scheduleDayOfWeekMask=92=20 SYNTAX 1.3.6.1.4.1.1466.115.121.1.6=20 SINGLE-VALUE=20 =20 Reed Standards Track - Expires January 2002 [Page 19] =0C LDUP Information Model =20 DESC =91mask identifying the days of the week during=20 which replication sessions should be performed.=92 )=20 =20 This attribute is patterned after the DayOfWeekMask property=20 identified in RFC 3060 [RFC3060] and [Policy Schema]. Refer to=20 these references for details on the format and interpretation of=20 this attribute.=20 =20 8.2.27. scheduleTimeOfDayMask=20 =20 ( 2.16.840.1.113719.142.4.x NAME =91scheduleTimeOfDayMask=92=20 SYNTAX 1.3.6.1.4.1.1466.115.121.1.44=20 EQUALITY caseIgnoreMatch=20 DESC =91mask identifying the times during the day when=20 replication sessions should be initiated.=92 )=20 =20 This attribute is patterned after the TimeOfDayMask property=20 identified in RFC 3060 [RFC3060] and [Policy Schema]. Refer to=20 these references for details on the format and interpretation of=20 this attribute.=20 =20 8.2.28. scheduleLocalOrUtcTime=20 =20 ( 2.16.840.1.113719.142.4.x NAME =91scheduleTimeOfDayMask=92=20 SYNTAX 1.3.6.1.4.1.1466.115.121.1.27=20 EQUALITY integerMatch=20 SINGLE-VALUE=20 DESC =91flag indicating whether or not times in the=20 scheduleTimeOfDayMask are in UTC time or=20 local time.=92 )=20 =20 This attribute is patterned after the LocaOrUtcTime property=20 identified in RFC 3060 [RFC3060] and [Policy Schema]. Refer to=20 these references for details on the format and interpretation of=20 this attribute.=20 =20 8.3. Class Definitions=20 =20 8.3.1. ReplicationContext=20 =20 ( 2.16.840.1.113719.142.6.2.2 NAME 'replicationContext'=20 SUP top=20 AUXILIARY )=20 =20 The replicationContext auxiliary class, when present on an object,=20 indicates the beginning, or root, of a naming context. The naming=20 context is said to be rooted at the entry with the=20 replicationContext auxiliary class in its list of object classes. =20 The root-most entry of a naming context is the entry with the=20 replicationContext auxiliary class in its list of object classes.=20 =20 Characteristics of the replication topology of a naming context are=20 defined in the replicaSubentry sub-entries associated with the=20 naming context.=20 =20 Reed Standards Track - Expires January 2002 [Page 20] =0C LDUP Information Model =20 =20 The attribute accessControlPolicyOID has been removed from here, and=20 should be published as an ldapSubEntry subordinate to the=20 replicationContext, instead.=20 =20 The attribute nameContextCreationTimestamp used here in previous=20 drafts has been eliminated as redundant. The=20 ldapChangeSequenceNumber associated with the replicationContext=20 value in the list of objectClasses attribute serves the same=20 purpose.=20 =20 8.3.2. replicaSubentry=20 =20 ( 2.16.840.1.113719.142.6.3.2 NAME 'replicaSubentry-2'=20 SUP ldapSubEntry=20 AUXILIARY=20 MUST ( cn $=20 replicaURI $=20 replicaType $=20 lostAndFoundEntryDN $=20 replicaOnline )=20 MAY ( attributeExclusionFilter $=20 attributeInclusionFilter $=20 replicaSecondaryURI $=20 description $=20 updateVector ) )=20 =20 Entries of type replicaSubentry MAY be named by their cn attribute.=20 As an AUXILIARY class, the replicaSubentry MAY share a structural=20 subentry with other AUXILIARY classes.=20 =20 The attributes attributeExclusionFilter and=20 attributeInclusionFilter, if present, govern which entries and=20 attributes from the local naming context are to be sent (or not=20 sent) to the replica named in replicaDN of replica agreements for=20 this replica. The attributeExclusionFilter names attributes which=20 SHOULD NOT be sent. The attributeInclusionFilter names attributes=20 which SHOULD be sent.=20 =20 The attribute replicaURI contains information in ldapURI format that=20 can be used to contact (ie, open a connection to) this replica. The=20 replicaSecondaryURI contains the set of ldapURI format addresses=20 that can be used as backup addresses if the replicaURI values cannot=20 be used.=20 =20 The lostAndFoundEntryDN attribute is single-valued attribute that=20 contains the distinguished name of the lost and found entry under=20 which orphaned entries are placed.=20 =20 The replicaOnline attribute is a Boolean attribute which indicates=20 whether or not this replica will supply and/or accept replication=20 sessions. This attribute can be used to prevent replication=20 sessions from being started before replicaAgreementSubentry entries=20 have been defined.=20 =20 Reed Standards Track - Expires January 2002 [Page 21] =0C LDUP Information Model =20 =20 The attribute description contains a human-readable description of=20 the sub-entry. =20 =20 The attribute updateVector contains a set of=20 ldapChangeSequenceNumbers, one for each of the other replicas for=20 this naming context, which records, from this replicas perspective,=20 the last change event received from the other indicated replica.=20 =20 8.3.3. replicaAgreementSubentry=20 =20 ( 2.16.840.1.113719.142.6.4.2 NAME 'replicaAgreementSubentry-2' =20 SUP ldapSubEntry=20 AUXILIARY=20 MUST ( cn )=20 MAY ( attributeExclusionFilter $=20 description $=20 replicaDN $=20 replicationMechanismOID $=20 replicationStatus $=20 replicationCredentialsDN $=20 replicationScheduleDN ) ) =20 =20 Entries of type replicaAgreementSubentry MAY be named by their cn=20 attribute. As an AUXILIARY class, a replicaAgreementSubentry MAY be=20 applied to a STRUCTURAL subentry, along with other AUXILIARY=20 classes. A replicaAgreementSubentry MAY NOT decorate the same=20 subentry as the replicaSubentry to which it is subordinate.=20 =20 Name subordination is used to associate a replicaAgreementSubentry=20 with the replicaSubentry representing the supplier of changes for=20 all subordinate replicaAgreements.=20 =20 The attribute attributeExclusionFilter governs which attributes from=20 the local naming context are to be sent (or not sent) to the replica=20 named in replicaDN. The attributeExclusionFilter names attributes=20 SHOULD NOT be sent. Note there is no attributeInclusionFilter,=20 because the list of attributes that may be sent may not be extended=20 beyond those documented in the attributeInclusionFilter on the=20 replicaSubentry.=20 =20 Processing of allowable changes to be sent is as follows:=20 =20 1) the attributeInclusionFilter from the replica subentry defines a=20 set of attributes which SHOULD be sent, less exclusions;=20 =20 2) the union of attributes excluded by the attributeExclusionFilter=20 from the replicasubentry and the attributeExclusionFilter from the=20 replicaAgreementSubentry defines a set of attributes which SHOULD=20 NOT be sent;=20 =20 3) the subtraction of attributes which SHOULD NOT be sent by (2)=20 from the attributes which SHOULD be sent by (1) constitute the set=20 of attributes for which changes MAY be sent.=20 =20 Reed Standards Track - Expires January 2002 [Page 22] =0C LDUP Information Model =20 =20 The attribute description contains a human-readable description of=20 the sub-entry.=20 =20 The attribute replicaDN of syntax distinguishedName names another=20 sub-entry of type replicaSubentry to whom changes are to be sent. =20 If there is no value for the replicaDN attribute on a=20 replicaAgreementSubentry, the replicaAgreementSubentry is ignored. =20 Absence of a value may occur briefly when replicas and replica=20 agreements are first being created, or when the replica to which a=20 replica agreement applies is being deleted.=20 =20 The attribute replicationMechanismOID is used to indicate the type=20 of replication protocol that is used between the supplier and=20 consumer. If not specified, the default replication protocol=20 defined in [LDUP Update Replication Protocol] is assumed.=20 =20 The attribute replicationStatus MAY be used to record the most=20 recent result of an attempt to send changes to the replica named in=20 replicaDN, whether success, or if failure, the nature of the problem=20 encountered.=20 =20 The attribute replicationCredentialsDN, if present, names an entry=20 which contains information used to initialize authenticated the LDAP=20 connection between the supplier and consumer. Separating the=20 credentials information from the replicaAgreementSubentry itself=20 allows for this information to be placed outside of the replication=20 context. =20 =20 The attribute replicationScheduleDN, if present, names an entry=20 which governs the schedule for replication attempts. If not=20 present, replication MUST be attempted when there are changes to be=20 sent (i.e. a default replica schedule of type replicaEventSchedule=20 is assumed with secondsToWaitDefault=3D0 and=20 updateVectorTrigger=3DFALSE). See Section on replicaEventSchedule for=20 more information about these attributes and their meaning.=20 =20 8.3.4. replicaEventSchedule=20 =20 ( 2.16.840.1.113719.142.6.x.1 NAME 'replicaEventSchedule' =20 SUP ldapSubEntry=20 AUXILIARY=20 MUST ( cn )=20 MAY ( description $=20 updateVectorTrigger $=20 secondsToWaitDefault $=20 secondsToWait1 $=20 attrs1 $=20 secondsToWait2 $=20 attrs2 ) )=20 =20 The replicaEventSchedule object class is used to specify when to=20 initiate replication sessions in terms of the time to wait after an=20 update is made to the supplier replica.=20 =20 Reed Standards Track - Expires January 2002 [Page 23] =0C LDUP Information Model =20 =20 The attribute cn is used as the naming attribute for the=20 replicaEventSchedule object class. It is thought that=20 replicaEventSchedule entries would be placed below=20 replicaAgreementSubentry entries but this is not required.=20 =20 The attribute description contains a human-readable description of=20 the sub-entry.=20 =20 The attribute updateVectorTrigger is a Boolean attribute which=20 indicates whether or not the update of the supplier=92s updateVector=20 attribute should, itself, be used to trigger replication sessions. =20 Since the updateVector is, itself, an attribute, it has CSNs=20 associated with each of its values. Note that these CSNs may be=20 different from the CSNs that are in the attribute values themselves. =20 Thus, it is possible that the update to the updateVector would,=20 itself, need to be treated as an update to be replicated. Indeed,=20 this is necessary in order for =93transitive replication=94 to work.=20 =20 The secondsToWaitDefault attribute is a non-negative integer value. =20 This value indicates the number of seconds to wait after an update=20 is made before starting a replication session. This value is used=20 for all attributes other than those noted in the attrs1 and attrs2=20 attributes.=20 =20 The secondsToWait1 attribute is similar to the secondsToWaitDefault=20 attribute. This non-negative integer value is used whenever any=20 attribute listed in the attrs1 attribute is updated.=20 =20 The secondsToWait2 attribute is similar to the secondsToWait1=20 attribute but is associated with the attrs2 attribute.=20 =20 Note that whenever any of these seconds-to-wait time periods has=20 expired, a replication session should be initiated and the full set=20 of information that needs to be replicated should be sent to the=20 consumer replica. This implies that some information would be=20 replicated before its associated seconds-to-wait time period had=20 expired.=20 =20 8.3.5. replicaTimeSchedule=20 =20 ( 2.16.840.1.113719.142.6.x.1 NAME 'replicaTimeSchedule' =20 SUP ldapSubEntry=20 AUXILIARY=20 MUST ( cn )=20 MAY ( description $=20 scheduleTimePeriod $=20 scheduleMonthOfYearMask $=20 scheduleDayOfMonthMask $=20 scheduleDayOfWeekMask $=20 scheduleTimeOfDayMask $=20 scheduleLocalOrUtcTime ) )=20 =20 =20 Reed Standards Track - Expires January 2002 [Page 24] =0C LDUP Information Model =20 The replicaTimeSchedule object class is used to specify when to=20 initiate replication sessions based on a scheduled time basis rather=20 than in relation to when updates are made to the supplier replica.=20 =20 The attribute cn is used as the naming attribute for the=20 replicaTimechedule object class. It is thought that=20 replicaTimeSchedule entries would be placed below=20 replicaAgreementSubentry entries but this is not required.=20 =20 The attribute description contains a human-readable description of=20 the sub-entry.=20 =20 The remaining attributes in this object class are patterned after=20 the attributes defined for the policyTimePeriodCondition construct=20 defined in the Policy Core Information Model [RFC3060]. Because the=20 LDAP schema mapping for this portion of the CIM model is not=20 complete at this time, these attributes are defined specifically for=20 this LDUP-related object class. Refer to RFC 3060 for details of=20 the formats for the scheduleTimePeriod, scheduleMonthOfYearMask,=20 scheduleDayOfMonthMask, scheduleDayOfWeekMask,=20 scheduleTimeOfDayMask, and scheduleLocalOrUtcTime attributes.=20 =20 9. Semantics of the information model=20 =20 The intent of this information model is to allow for useful and=20 expected operation while requiring a minimum amount of data to be=20 specified. In this spirit, replicaAgreementSubentry entries are=20 treated as =93constraints=94 on when to initiate replication sessions,=20 not =93requirements=94 on being able to initiate replication sessions.=20 =20 To clarify this concept, two examples are provided in this section.=20 =20 The first example shows the minimal set of information required to=20 get replication going between three replicas:=20 =20 dn: ou=3Daccounting, o=3Dyour company=20 objectclass: organizationalUnit=20 objectclass: replicationContext=20 ou: accounting=20 =20 dn: cn=3Dreplica1, ou=3Daccounting, o=3Dyour company=20 objectclass: ldapSubentry=20 objectclass: replicaSubentry-2=20 cn: replica1=20 description: replica in location 1=20 replicaURI: ldap://sys1.yourcompany.com=20 replicaType: 2=20 lostAndFoundEntryDN: cn=3DlostAndFound1, o=3Dyour company=20 replicaOnline: TRUE=20 =20 dn: cn=3Dreplica2, ou=3Daccounting, o=3Dyour company=20 objectclass: ldapSubentry=20 objectclass: replicaSubentry-2=20 cn: replica2=20 =20 Reed Standards Track - Expires January 2002 [Page 25] =0C LDUP Information Model =20 description: replica in location 2=20 replicaURI: ldap://sys2.yourcompany.com=20 replicaType: 2=20 lostAndFoundEntryDN: cn=3DlostAndFound2, o=3Dyour company=20 replicaOnline: TRUE=20 =20 dn: cn=3Dreplica3, ou=3Daccounting, o=3Dyour company=20 objectclass: ldapSubentry=20 objectclass: replicaSubentry-2=20 cn: replica3=20 description: replica in location 3=20 replicaURI: ldap://sys2.yourcompany.com=20 replicaType: 2=20 lostAndFoundEntryDN: cn=3DlostAndFound3, o=3Dyour company=20 replicaOnline: TRUE=20 =20 With replicaSubentry entries defined as shown in this first example,=20 replication sessions will be initiated by all replicas whenever an=20 update is made to any attribute within any entries in the=20 replicationContext. The default event schedule will be used which=20 indicates that a replication session is initiated immediately after=20 an update is made to a replica. Further, replication sessions would=20 be initiated to ALL OTHER replicas. As this shows, maximal=20 replication is defined using a minimal amount of configuration.=20 =20 The second example shows how replication sessions can be constrained=20 by replicaAgreementSubentry entries. This example builds on the=20 data shown in the first example. Assume that the following entries=20 are added to the entries defined in the first example:=20 =20 dn: cn=3Dagreement1->2, cn=3Dreplica1, ou=3Daccounting, o=3Dyour company= =20 objectclass: ldapSubentry=20 objectclass: replicaAgreementSubentry-2=20 cn: agreement1->2=20 description: Replica agreement constraining replication sessions=20 from replica 1 to replica 2.=20 replicationScheduleDN: cn=3Dschedule1, cn=3Dreplica1,=20 ou=3Daccounting, o=3Dyour company=20 =20 dn: cn=3Dagreement1->3, cn=3Dreplica1, ou=3Daccounting, o=3Dyour company= =20 objectclass: ldapSubentry=20 objectclass: replicaAgreementSubentry-2=20 cn: agreement1->3=20 description: Replica agreement constraining replication sessions=20 from replica 1 to replica 3.=20 replicationScheduleDN: cn=3Dschedule1, cn=3Dreplica1,=20 ou=3Daccounting, o=3Dyour company=20 =20 dn: cn=3Dschedule1, cn=3Dreplica1, ou=3Daccounting, o=3Dyour company=20 objectclass: ldapSubentry=20 objectclass: replicaEventSchedule=20 cn: schedule1=20 description: schedule that initiates replication one minute=20 after any update (including to the updateVector) is made=20 =20 Reed Standards Track - Expires January 2002 [Page 26] =0C LDUP Information Model =20 to the replica.=20 secondsToWaitDefault: 60=20 updateVectorTrigger: TRUE=20 =20 dn: cn=3Dagreement2->1, cn=3Dreplica2, ou=3Daccounting, o=3Dyour company= =20 objectclass: ldapSubentry=20 objectclass: replicaAgreementSubentry-2=20 cn: agreement2->1=20 description: Replica agreement constraining replication sessions=20 from replica 2 to replica 1.=20 replicationScheduleDN: cn=3Dschedule2, cn=3Dreplica2,=20 ou=3Daccounting, o=3Dyour company=20 =20 dn: cn=3Dagreement2->3, cn=3Dreplica2, ou=3Daccounting, o=3Dyour company= =20 objectclass: ldapSubentry=20 objectclass: replicaAgreementSubentry-2=20 cn: agreement2->3=20 description: Replica agreement constraining replication sessions=20 from replica 2 to replica 3.=20 replicationScheduleDN: cn=3Dschedule2, cn=3Dreplica2,=20 ou=3Daccounting, o=3Dyour company=20 =20 dn: cn=3Dschedule2, cn=3Dreplica2, ou=3Daccounting, o=3Dyour company=20 objectclass: ldapSubentry=20 objectclass: replicaEventSchedule=20 cn: schedule2=20 description: schedule that initiates replication two minutes=20 after any update (including to the updateVector) is made=20 to the replica.=20 secondsToWaitDefault: 120=20 updateVectorTrigger: TRUE=20 =20 dn: cn=3Dagreement3->1, cn=3Dreplica3, ou=3Daccounting, o=3Dyour company= =20 objectclass: ldapSubentry=20 objectclass: replicaAgreementSubentry-2=20 cn: agreement3->1=20 description: Replica agreement constraining replication sessions=20 from replica 3 to replica 1.=20 replicationScheduleDN: cn=3Dschedule3, cn=3Dreplica3,=20 ou=3Daccounting, o=3Dyour company=20 =20 dn: cn=3Dagreement3->2, cn=3Dreplica3, ou=3Daccounting, o=3Dyour company= =20 objectclass: ldapSubentry=20 objectclass: replicaAgreementSubentry-2=20 cn: agreement3->2=20 description: Replica agreement constraining replication sessions=20 from replica 3 to replica 2.=20 replicationScheduleDN: cn=3Dschedule3, cn=3Dreplica3,=20 ou=3Daccounting, o=3Dyour company=20 =20 dn: cn=3Dschedule3, cn=3Dreplica3, ou=3Daccounting, o=3Dyour company=20 objectclass: ldapSubentry=20 objectclass: replicaEventSchedule=20 cn: schedule3=20 =20 Reed Standards Track - Expires January 2002 [Page 27] =0C LDUP Information Model =20 description: schedule that initiates replication one minute=20 after any update (including to the updateVector) is made=20 to the replica.=20 secondsToWaitDefault: 60=20 updateVectorTrigger: TRUE=20 =20 In this example, replication sessions are limited such that they=20 will begin one or two minutes after an update is made to any one=20 replica, depending on the replica on which the update was made. =20 This =93contrains=94 the replication session initiation from the default= =20 of =93immediate replication=94 of updates.=20 =20 There are many ways in which the constraints around when to initiate=20 and/or accept replication sessions between two replicas. The=20 information model defined here provides a small set of options. =20 More elaborate policies can be defined and this is left as a future=20 exercise. It is hoped that the work from the Policy workgroup can=20 offer schema that would support the creation of these complex=20 policies.=20 =20 =20 10. Object Identifier Assignments=20 =20 The LDUP OID prefix is =20 =20 ID ::=3D OBJECT IDENTIFIER=20 =20 ldup ID ::=3D { joint-iso-ccitt(2) country(16) us(840)=20 organization(1) novell(113719) ldup(142) }=20 =20 The OID assignments defined in this document are:=20 =20 Attributes:=20 =20 AttributeExclusionFilter ID ::=3D 2.16.840.1.113719.142.4.1=20 AttributeInclusionFilter ID ::=3D 2.16.840.1.113719.142.4.2=20 replicationStatus ID ::=3D 2.16.840.1.113719.142.4.3=20 replicaType ID ::=3D 2.16.840.1.113719.142.4.4=20 updateVector ID ::=3D 2.16.840.1.113719.142.4.6=20 replicaURI ID ::=3D 2.16.840.1.113719.142.4.x=20 replicaSecondaryURI ID ::=3D 2.16.840.1.113719.142.4.x=20 lostAndFoundEntryDN ID ::=3D 2.16.840.1.113719.142.4.x=20 replicaOnline ID ::=3D 2.16.840.1.113719.142.4.x=20 replicaDN ID ::=3D 2.16.840.1.113719.142.4.x=20 replicationMechanismOID ID ::=3D 2.16.840.1.113719.142.4.x=20 replicationCredentialsDN ID ::=3D 2.16.840.1.113719.142.4.x=20 replicationScheduleDN ID ::=3D 2.16.840.1.113719.142.4.x=20 updateVectorTrigger ID ::=3D 2.16.840.1.113719.142.4.x=20 secondsToWaitDefault ID ::=3D 2.16.840.1.113719.142.4.x=20 secondsToWait1 ID ::=3D 2.16.840.1.113719.142.4.x=20 attrs1 ID ::=3D 2.16.840.1.113719.142.4.x=20 secondsToWait2 ID ::=3D 2.16.840.1.113719.142.4.x=20 attrs2 ID ::=3D 2.16.840.1.113719.142.4.x=20 scheduleTimePeriod ID ::=3D 2.16.840.1.113719.142.4.x=20 =20 Reed Standards Track - Expires January 2002 [Page 28] =0C LDUP Information Model =20 scheduleMonthOfYearMask ID ::=3D 2.16.840.1.113719.142.4.x=20 scheduleDayOfMonthMask ID ::=3D 2.16.840.1.113719.142.4.x=20 scheduleDayOfWeekMask ID ::=3D 2.16.840.1.113719.142.4.x=20 scheduleTimeOfDayMask ID ::=3D 2.16.840.1.113719.142.4.x=20 scheduleLocalOrUtcTime ID ::=3D 2.16.840.1.113719.142.4.x=20 supportedReplicationProtocols ID ::=3D 2.16.840.1.113719.142.4.x=20 replicaContextRoots ID ::=3D 2.16.840.1.113719.142.4.x=20 replicaSubentries ID ::=3D 2.16.840.1.113719.142.4.x=20 =20 Object Classes:=20 =20 nameContext ID ::=3D 2.16.840.1.113719.142.6.2.1 -=20 OBSOLETE=20 replicaSubentry ID ::=3D 2.16.840.1.113719.142.6.3.1 -=20 OBSOLETE=20 replicaAgreementSubentry ID ::=3D 2.16.840.1.113719.142.6.4.1 =96=20 OBSOLETE=20 replicationContext ID ::=3D 2.16.840.1.113719.142.6.2.2=20 replicaSubEntry-2 ID ::=3D 2.16.840.1.113719.142.6.3.2=20 replicaAgreementSubEntry-2 ID ::=3D 2.16.840.1.113719.142.6.4.2=20 replicaEventSchedule ID ::=3D 2.16.840.1.113719.142.6.x.1=20 replicaTimeSchedule ID ::=3D 2.16.840.1.113719.142.6.x.1=20 =20 Note: Object Class OIDs have version numbers, Attribute OIDs don=92t.=20 =20 11. Security Considerations=20 =20 Many of the attributes and object classes described in this document=20 should be considered =93security sensitive=94, and protected from=20 unintended modification by LDAP servers. Generally, creating Naming=20 Contexts, Replicas and Replica Agreement entries should only be=20 allowed by directory administrators who are authorized to do so.=20 =20 The values of attributes defined here are intended to control the=20 behavior of the directory service agents, themselves. Unintended=20 modification of their values may result in incomplete replication of=20 data (if ldapSearchFilter or attributeExclusionFilter are changed),=20 inappropriate disclosure of information (if attributeInclusionFilter=20 is changed), or updates may be lost (if updateVector is changed).=20 =20 To avoid depending to much on the ldapAccessPoint values for other=20 replicas, connections between LDAP servers for the purpose of=20 replication MUST ALWAYS be authenticated using an authentication=20 mechanism appropriate for the nature of information to be exchanged.=20 =20 References=20 =20 [LDUP Model] - J. Merrells, E. Reed, U. Srinivisan, =93An Abstract=20 Model of LDAP Replication=94, Internet draft, draft-merrells-ldup- model-01.txt=20 =20 [LDUP Requirements] - R. Weiser, E. Stokes =93LDAP Replication=20 Requirements=94, Internet draft, draft-weiser-replica-req-02.txt,=20 April 1998=20 =20 Reed Standards Track - Expires January 2002 [Page 29] =0C LDUP Information Model =20 =20 [LDAP Subentry] =96 E. Reed, =93LDAP Subentry Schema=94, Internet draft,= =20 draft-ietf-ldup-subentry-08.txt=20 =20 [LDUP Update Protocol] =96 E. Stokes, G. Good, R. Harrison, =93The LDUP = Replication Update Protocol=94, Internet Draft, draft-ietf-ldup- protocol-03.txt=20 =20 [Policy Schema] - J. Strassner, A. Westerinen, E. Ellesson, B.=20 Moore, R. Moats, =93Policy Core LDAP Schema=94, Internet draft, draft- ietf-policy-core-schema-11.txt, May 2001.=20 =20 [RFC822] =96 D. Crocker, =93STANDARD FOR THE FORMAT OF ARPA INTERNET=20 TEXT MESSAGES=94, August 1982, RFC 822=20 =20 [RFC2251] =96 M. Wahl, T. Howes, S. Kille, =93Lightweight Directory=20 Access Protocol (v3)=94, December 1997, RFC 2251=20 =20 [RFC2252] =96 M. Wahl, A. Coulbeck, T. Howes, S. Kille, =93Lightweight=20 Directory Access Protocol (v3): Attribute Syntax Definitions=94,=20 December 1997, RFC 2252=20 =20 [RFC3060] =96 B. Moore, E. Ellesson, J. Strassner, A. Westerinen,=20 =93Policy Core Information Model =96 Version 1 Specification=94, Februar= y=20 2001, RFC 3060=20 =20 [X518] - ITU-T Recommendation X.518 (1997) | ISO/IEC 9594-4:1998,=20 Information Technology =96 Open Systems Interconnection =96 The=20 Directory: Procedures for Distributed Operation=20 =20 [X680] - ITU-T Recommendation X.680 (1994) | ISO/IEC 8824-1:1995,=20 Information technology =96 Abstract Syntax Notation One (ASN.1):=20 Specification of Basic Notation=20 =20 12. Copyright Notice=20 =20 Copyright (C) The Internet Society (1999). All Rights Reserved. =20 =20 This document and translations of it may be copied and furnished to=20 others, and derivative works that comment on or otherwise explain it=20 or assist in its implmentation may be prepared, copied, published=20 and distributed, in whole or in part, without restriction of any=20 kind, provided that the above copyright notice and this paragraph=20 are included on all such copies and derivative works. However, this=20 document itself may not be modified in any way, such as by removing=20 the copyright notice or references to the Internet Society or other=20 Internet organizations, except as needed for the purpose of=20 developing Internet standards in which case the procedures for=20 copyrights defined in the Internet Standards process must be=20 followed, or as required to translate it into languages other than=20 English.=20 =20 The limited permissions granted above are perpetual and will not be=20 revoked by the Internet Society or its successors or assigns.=20 =20 Reed Standards Track - Expires January 2002 [Page 30] =0C LDUP Information Model =20 =20 This document and the information contained herein is provided on an=20 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING=20 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING=20 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION=20 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF=20 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE."=20 =20 13. Acknowledgements=20 =20 The use of subEntry object class to store Replica and Replication=20 Agreement information is due primarily to the lucid explanation by=20 Mark Wahl, Innosoft, of how they could be used and extended.=20 =20 The IETF takes no position regarding the validity or scope of any=20 intellectual property or other rights that might be claimed to=20 pertain to the implementation or use of the technology described in=20 this document or the extent to which any license under such rights=20 might or might not be available; neither does it represent that it=20 has made any effort to identify any such rights. Information on the=20 IETF's procedures with respect to rights in standards-track and=20 standards-related documentation can be found in BCP-11. Copies of=20 claims of rights made available for publication and any assurances=20 of licenses to be made available, or the result of an attempt made=20 to obtain a general license or permission for the use of such=20 proprietary rights by implementors or users of this specification=20 can be obtained from the IETF Secretariat.=20 =20 The IETF invites any interested party to bring to its attention any=20 copyrights, patents or patent applications, or other proprietary=20 rights which may cover technology that may be required to practice=20 this standard. Please address the information to the IETF Executive=20 Director.=20 =20 14. Authors=92 Addresses=20 =20 Edward E. Reed=20 Reed-Matthews, Inc.=20 1064 East 140 North=20 Lindon, UT 84042=20 USA=20 E-mail: eer@oncalldba.com =20 =20 Tim Hahn=20 IBM=20 Bldg 256-2, Dept. C8NG=20 1701 North St.=20 Endicott, NY 13760 USA=20 E-mail: hahnt@us.ibm.com=20 =20 LDUP Mailing List: ietf-ldup@idc.org=20 =20 =20 Reed Standards Track - Expires January 2002 [Page 31] =0C= --=_mixed 004558AC85256A88_=-- From owner-ietf-ldup@mail.imc.org Mon Jul 16 14:59:33 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA17114 for ; Mon, 16 Jul 2001 14:59:32 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.3/8.11.3) id f6GIULf23251 for ietf-ldup-bks; Mon, 16 Jul 2001 11:30:21 -0700 (PDT) Received: from ckmso1.proxy.att.com (ckmso1.att.com [12.20.58.69]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f6GIUEq23246 for ; Mon, 16 Jul 2001 11:30:14 -0700 (PDT) Received: from qsun.mt.att.com ([135.16.157.16]) by ckmso1.proxy.att.com (AT&T IPNS/MSO-3.0) with SMTP id f6GIU8g27234; Mon, 16 Jul 2001 14:30:08 -0400 (EDT) Received: from att.com by qsun.mt.att.com (SMI-8.6/ATTEMS-1.4.1 sol2) id OAA12122; Mon, 16 Jul 2001 14:30:05 -0400 Message-ID: <3B533263.AD0244E0@att.com> Date: Mon, 16 Jul 2001 14:28:51 -0400 From: Richard Huber X-Mailer: Mozilla 4.75 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: internet-drafts@ietf.org, ietf-ldup@imc.org Subject: New Requirements draft (-10) Content-Type: multipart/mixed; boundary="------------1AD09966D93511DF63618EC2" Sender: owner-ietf-ldup@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multi-part message in MIME format. --------------1AD09966D93511DF63618EC2 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Internet Drafts Editor - Please publish the attached draft as draft-ietf-ldup-replica-req-10.txt LDUPers - Draft -10 is attached. It includes the three changes recently discussed on the list (http://www.imc.org/ietf-ldup/mail-archive/msg01098.html) plus a few typo fixes and changes to author contact info. As previously noted, since these changes handle the last comments from the WG last call, we propose that the document go to the IESG. Rick Huber --------------1AD09966D93511DF63618EC2 Content-Type: text/plain; charset=us-ascii; name="draft-ietf-ldup-replica-req-10.txt" Content-Disposition: inline; filename="draft-ietf-ldup-replica-req-10.txt" Content-Transfer-Encoding: 7bit Internet-Draft Ellen J. Stokes LDAP Duplication/Replication/Update Tivoli Systems Protocols WG Russel F. Weiser Intended Category: Informational Digital Signature Trust Expires: January 2002 Ryan D. Moats Lemur Networks Richard V. Huber AT&T Laboratories July 2001 LDAPv3 Replication Requirements draft-ietf-ldup-replica-req-10.txt Status of This Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/lid-abstracts.txt. The list of Internet-Drafts Shadow Directories can be accessed at http://www.ietf.org/shadow.html. Copyright Notice Copyright (C) The Internet Society (2000). All Rights Reserved. Abstract This document discusses the fundamental requirements for replication of data accessible via the LDAPv3 [RFC2251] protocol. It is intended to be a gathering place for general replication requirements needed to provide interoperability between informational directories. Stokes, et al Expires January 2002 [Page 1] Internet-Draft LDAPv3 Replication Requirements July 2001 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119]. Stokes, et al Expires January 2002 [Page 2] Internet-Draft LDAPv3 Replication Requirements July 2001 Table of Contents 1 Introduction.......................................................4 2 Terminology........................................................4 3 The Models.........................................................7 4 Requirements.......................................................8 4.1 General.........................................................8 4.2 Model...........................................................9 4.3 Protocol.......................................................10 4.4 Schema.........................................................11 4.5 Single Master..................................................11 4.6 Multi-Master...................................................12 4.7 Administration and Management..................................12 4.8 Security.......................................................13 5 Security Considerations...........................................14 6 Acknowledgements..................................................14 7 References........................................................14 A.APPENDIX A - Usage Scenarios......................................15 A.1.Extranet Example...............................................15 A.2.Consolidation Example..........................................16 A.3.Replication Heterogeneous Deployment Example...................16 A.4.Shared Name Space Example......................................17 A.5.Supplier Initiated Replication.................................17 A.6.Consumer Initiated Replication.................................17 A.7.Prioritized attribute replication..............................17 A.8.Bandwidth issues...............................................18 A.9.Interoperable Administration and Management....................18 A.10.Enterprise Directory Replication Mesh.........................19 A.11.Failure of the Master in a Master-Slave Replicated Directory..19 A.12.Failure of a Directory Holding Critical Service Information...19 B.APPENDIX B - Rationale............................................20 B.1.Meta-Data Implications.........................................20 B.2.Order of Transfer for Replicating Data.........................20 B.3.Schema Mismatches and Replication..............................21 B.4.Detecting and Repairing Inconsistencies Among Replicas.........22 B.5.Some Test Cases for Conflict Resolution in Multi-Master Replication....................................................23 B.6.Data Confidentiality and Data Integrity During Replication.....26 B.7.Failover in Single-Master Systems..............................27 B.8.Including Operational Attributes in Atomic Operations..........28 Authors' Addresses..................................................28 Full Copyright Statement............................................29 Stokes, et al Expires January 2002 [Page 3] Internet-Draft LDAPv3 Replication Requirements July 2001 1 Introduction Distributing directory information throughout the network provides a two-fold benefit: (1) it increases the reliability of the directory through fault tolerance, and (2) it brings the directory content closer to the clients using the data. LDAP's success as an access protocol for directory information is driving the need to distribute LDAP directory content within the enterprise and Internet. Currently, LDAP does not define a replication mechanism, and mentions LDAP shadow servers (see [RFC2251]) in passing. A standard mechanism for directory replication in a multi-vendor environment is critical to the continued success of LDAP in the market place. This document sets out the requirements for replication between multiple LDAP servers. While RFC 2251 and RFC 2252 [RFC2252] set forth the standards for communication between LDAP clients and servers there are additional requirements for server-to-server communication. Some of these are covered here. This document first introduces the terminology to be used, then presents the different replication models being considered. Requirements follow, along with security considerations. The reasoning that leads to the requirements is presented in the Appendices. This was done to provide a clean separation of the requirements from their justification. 2 Terminology The following terms are used in this document: Anonymous Replication - Replication where the endpoints are identified to each other but not authenticated. Area of replication - A whole or portion of a Directory Information Tree (DIT) that makes up a distinct unit of data to be replicated. An area of replication is defined by a replication base entry and includes all or some of the depending entries contained therein on a single server. It divides directory data into partitions whose propagation behavior may be independently configured from other partitions. Areas of replication may overlap or be nested. This is a subset of the definition of a "replicated area" in X.525 [X.525]. Atomic operation - A set of changes to directory data which the LDAP standards guarantee will be treated as a unit; all changes will be made or all the changes will fail. Stokes, et al Expires January 2002 [Page 4] Internet-Draft LDAPv3 Replication Requirements July 2001 Atomicity Information - Information about atomic operations passed as part of replication. Conflict - A situation that arises when changes are made to the same directory data on different directory servers before replication can synchronize the data on the servers. When the servers do synchronize, they have inconsistent data - a conflict. Conflict resolution - Deterministic procedures used to resolve change information conflicts that may arise during replication. Critical OID - Attributes or object classes defined in the replication agreement as being critical to the operation of the system. Changes affecting critical OIDs cause immediate initiation of a replica cycle. An example of a critical OID might be a password or certificate. Fractional replication - The capability to filter a subset of attributes for replication. Incremental Update - An update that contains only those attributes or entries that have changed. Master Replica - A replica that may be directly updated via LDAP operations. In a Master-Slave Replication system, the Master Replica is the only directly updateable replica in the replica-group. Master-Slave, or Single Master Replication - A replication model that assumes only one server, the master, allows LDAP write access to the replicated data. Note that Master-Slave replication can be considered a proper subset of multi-master replication. Meta-Data - Data collected by the replication system that describes the status/state of replication. Multi-Master Replication - A replication model where entries can be written and updated on any of several master replica copies without requiring communication with other master replicas before the write or update is performed. One-way Replication - The process of synchronization in a single direction where the authoritative source information is provided to a replica. Partial Replication - Partial Replication is Fractional Replication, Sparse Replication, or both. Stokes, et al Expires January 2002 [Page 5] Internet-Draft LDAPv3 Replication Requirements July 2001 Propagation Behavior - The behavior of the synchronization process between a consumer and a supplier. Replica - An instance of an area of replication on a server. Replica-Group - The servers that hold instances of a particular area of replication. A server may be part of several replica-groups. Replica (or Replication) Cycle - The interval during which update information is exchanged between two or more replicas. It begins during an attempt to push data to, or pull data from, another replica or set of replicas, and ends when the data has successfully been exchanged or an error is encountered. Replication - The process of synchronizing data distributed across directory servers and rectifying update conflicts. Replication Agreement - A collection of information describing the parameters of replication between two or more servers in a replica- group. Replication Base Entry - The distinguished name of the root vertex of a replicated area. Replication Initiation Conflict - A Replication Initiation Conflict is a situation where two sources want to update the same replica at the same time. Replication Session - A session set up between two servers in a replica-group to pass update information as part of a replica cycle. Slave (or Read-Only) Replica - A replica that cannot be directly updated via LDAP requests. Changes may only be made via replication from a master replica. Read-only replicas may occur in both single- and multi-master systems. Sparse Replication - The capability to filter some subset of entries (other than a complete collection) of a replication base entry for replication. Topology - The shape of the directed graph describing the relationships between replicas. Two-way Replication - The process of synchronization where change information flows bi-directionally between two replicas. Update Propagation - Protocol-based process by which directory replicas are reconciled. Stokes, et al Expires January 2002 [Page 6] Internet-Draft LDAPv3 Replication Requirements July 2001 3 The Models The objective is to provide an interoperable, LDAP v3 directory synchronization protocol that is simple, efficient and flexible; supporting both multi-master and master-slave replication. The protocol must meet the needs of both the Internet and enterprise environments. There are five data consistency models. Model 1: Transactional Consistency -- Environments that exhibit all four of the ACID properties (Atomicity, Consistency, Isolation, Durability) [ACID]. Model 2: Eventual (or Transient) Consistency -- Environments where definite knowledge of the topology is provided through predetermined replication agreements. Examples include X.500 Directories (the X.500 model is single-master only) [X.501, X.525], Bayou [XEROX], and NDS (Novell Directory Services) [NDS]. In this model, every update propagates to every replica that it can reach via a path of stepwise eventual connectivity. Model 3: Limited Effort Eventual (or Probabilistic) Consistency -- Environments that provide a statistical probability of convergence with knowledge of topology. An example is the Xerox Clearinghouse [XEROX2]. This model is similar to "Eventual Consistency", except where replicas may purge updates. Purging drops propagation changes when some replica time boundary is exceeded, thus leaving some changes replicated to only a portion of the topology. Transactional consistency is not preserved, though some weaker constraints on consistency are available. Model 4: Loosest Consistency -- Environments where information is provided from an opportunistic or simple cache until stale. Complete knowledge of topology may not be shared among all replicas. Model 5: Ad hoc -- A copy of a data store where no follow up checks are made for the accuracy/freshness of the data. Consistency models 1, 2 and 3 involve the use of prearranged replication agreements among servers. While model 1 may simplify support for atomicity in multi-master systems, the added complexity of the distributed 2-phase commit required for Model 1 is significant; therefor, model 1 will not be considered at this time. Models 4 and 5 involve unregistered replicas that "pull" updates from another directory server without that server's knowledge. These models violate a directory's security policies. Stokes, et al Expires January 2002 [Page 7] Internet-Draft LDAPv3 Replication Requirements July 2001 Models 2 and 3 illustrate two replication scenarios that must be handled: policy configuration through security management parameters (model 2), and hosting relatively static data and address information as in white-pages applications (model 3). Therefore, replication requirements are presented for models 2 and 3. Interoperability among directories using LDAP replication may be limited for implementations that add semantics beyond those specified by the LDAP core documents (RFC 2251-2256, 2829, 2830). In addition, the "core" specifications include numerous features which are not mandatory-to-implement (e.g. RECOMMENDED or OPTIONAL). There are also numerous elective extensions. Thus LDAP replication interoperability between independent implementations of LDAP which support different options may be limited. Use of applicability statements to improve interoperability in particular application spaces is RECOMMENDED. 4 Requirements 4.1 General G1. LDAP Replication MUST support models 2 (Eventual Consistency) and 3 (Limited Effort Eventual Consistency) above. G2. LDAP Replication SHOULD NOT preclude support for model 1 (Transactional Consistency) in the future. G3. LDAP replication SHOULD have minimal impact on both the system and network performance. G4. The LDAP Replication Standard SHOULD NOT limit the replication transaction rate. G5. The LDAP replication standard SHOULD NOT limit the size of an area of replication or a replica. G6. Meta-data collected by the LDAP replication mechanism MUST NOT grow without bound. G7. All policy and state data pertaining to replication MUST be accessible via LDAP. G8. LDAP replication MUST be capable of replicating the following: - all userApplication attribute types Stokes, et al Expires January 2002 [Page 8] Internet-Draft LDAPv3 Replication Requirements July 2001 - all directoryOperation and distributedOperation attribute types defined in the LDAP "core" specifications (RFC 2251- 2256, 2829-2830) - attribute subtypes - attribute description options (e.g. ";binary" and Language Tags) G9. LDAP replication SHOULD support replication of directoryOperation and distributedOperation attribute types defined in standards track LDAP extensions. Future standards track specifications SHOULD include a "Replication Considerations" section which indicates how and whether the new feature operates in a replicated environment. G10. LDAP replication MUST NOT support replication of dsaOperation attribute types as such attributes are DSA-specific. 4.2 Model M1. The model MUST support the following triggers for initiation of a replica cycle: a) A configurable set of scheduled times b) Periodically, with a configurable period between replica cycles c) A configurable maximum amount of time between replica cycles d) A configurable number of accumulated changes e) Change in the value of a critical OID f) As the result of an automatic rescheduling after a replication initiation conflict g) A manual request for immediate replication With the exception of manual request, the specific trigger(s) and related parameters for a given server MUST be identified in a well- known place defined by the standard, e.g. the Replication Agreement(s). M2. The replication model MUST support both master-slave and multi- master relationships. M3. An attribute in an entry must eventually converge to the same set of values in every replica holding that entry. M4. LDAP replication MUST encompass schema definitions, attribute names and values, access control information, knowledge information, and name space information. M5. LDAP replication MUST NOT require that all copies of the replicated information be complete, but MAY require that at least one copy be complete. The model MUST support Partial Replicas. Stokes, et al Expires January 2002 [Page 9] Internet-Draft LDAPv3 Replication Requirements July 2001 M6. The determination of which OIDs are critical MUST be configurable in the replication agreement. M7. The parameters of the replication process among the members of the replica-group, including access parameters, necessary authentication credentials, assurances of confidentiality (encryption), and area(s) of replication MUST be defined in a standard location (e.g. the replication agreements). M8. The replication agreements SHOULD accommodate multiple servers receiving the same area of replication under a single predefined agreement. M9. LDAP replication MUST provide scalability to both enterprise and Internet environments, e.g. an LDAP server must be able to provide replication services to replicas within an enterprise as well as across the Internet. M10. While different directory implementations can support different/extended schema, schema mismatches between two replicating servers MUST be handled. One way of handling such mismatches might be to raise an error condition. M11. There MUST be a facility that can update, or totally refresh, a replica-group from a standard data format, such as LDIF format [RFC2849]. M12. An update received by a consumer more than once MUST NOT produce a different outcome than if the update were received only once. 4.3 Protocol P1. The replication protocol MUST provide for recovery and rescheduling of a replication session due to replication initiation conflicts (e.g. consumer busy replicating with other servers) and or loss of connection (e.g. supplier cannot reach a replica). P2. LDUP replication SHOULD NOT send an update to a consumer if the consumer has previously acknowledged that update. P3. The LDAP replication protocol MUST allow for full update to facilitate replica initialization and reset loading utilizing a standardized format such as LDIF [RFC2849] format. P4. Incremental replication MUST be allowed. Stokes, et al Expires January 2002 [Page 10] Internet-Draft LDAPv3 Replication Requirements July 2001 P5. The replication protocol MUST allow either a master or slave replica to initiate the replication process. P6. The protocol MUST preserve atomicity of LDAP operations as defined in RFC2251 [RFC2251]. In a multi-master environment this may lead to an unresolvable conflict. MM5 and MM6 discuss how to handle this situation. P7. The protocol MUST support a mechanism to report schema mismatches between replicas discovered during a replication session. 4.4 Schema SC1. A standard way to determine what replicas are held on a server MUST be defined. SC2. A standard schema for representing replication agreements MUST be defined. SC3. The semantics associated with modifying the attributes of replication agreements MUST be defined. SC4. A standard method for determining the location of replication agreements MUST be defined. SC5. A standard schema for publishing state information about a given replica MUST be defined. SC6. A standard method for determining the location of replica state information MUST be defined. SC7. It MUST be possible for appropriately authorized administrators, regardless of their network location, to access replication agreements in the DIT. SC8. Replication agreements of all servers containing replicated information MUST be accessible via LDAP. SC9. An entry MUST be uniquely identifiable throughout its lifetime. 4.5 Single Master SM1. A Single Master system SHOULD provide a fast method of promoting a slave replica to become the master replica. Stokes, et al Expires January 2002 [Page 11] Internet-Draft LDAPv3 Replication Requirements July 2001 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. 4.6 Multi-Master MM1. The replication protocol SHOULD NOT saturate the network with redundant or unnecessary entry replication. MM2. The initiator MUST be allowed to determine whether it will become a consumer or supplier during the synchronization startup process. MM3. During a replica cycle, it MUST be possible for the two servers to switch between the consumer and supplier roles. MM4. When multiple master replicas want to start a replica cycle with the same replica at the same time, the model MUST have an automatic and deterministic mechanism for resolving or avoiding replication initiation conflict. MM5. Multi-master replication MUST NOT lose information during replication. If conflict resolution would result in the loss of directory information, the replication process MUST store that information, notify the administrator of the nature of the conflict and the information that was lost, and provide a mechanism for possible override by the administrator. MM6. Multi-master replication MUST support convergence of the values of attributes and entries. Convergence may result in an event as described in MM5. MM7. Multi-master conflict resolution MUST NOT depend on the in-order arrival of changes at a replica to assure eventual convergence. 4.7 Administration and Management AM1. Replication agreements MUST allow the initiation of a replica cycle to be administratively postponed to a more convenient period. AM2. Each copy of a replica MUST maintain audit history information of which servers it has replicated with and which servers have replicated with it. AM3. Access to replication agreements, topologies, and policy attributes MUST be provided through LDAP. Stokes, et al Expires January 2002 [Page 12] Internet-Draft LDAPv3 Replication Requirements July 2001 AM4. The capability to check the differences between two replicas for the same information SHOULD be provided. AM5. A mechanism to fix differences between replicas without triggering new replica cycles SHOULD be provided. AM6. The sequence of updates to access control information (ACI) and the data controlled by that ACI MUST be maintained by replication. AM7. It MUST be possible to add a 'blank' replica to a replica-group, and force a full update from (one of) the Master(s), for the purpose of adding a new directory server to the system. AM8. Vendors SHOULD provide tools to audit schema compatibility within a potential replica-group. 4.8 Security The terms "data confidentiality" and "data integrity" are defined in the Internet Security Glossary [RFC2828]. S1. The protocol MUST support mutual authentication of the source and the replica directories during initialization of a replication session. S2. The protocol MUST support mutual verification of authorization of the source to send and the replica to receive replicated data during initialization of a replication session. S3. The protocol MUST also support the initialization of anonymous replication sessions. S4. The replication protocol MUST support transfer of data with data integrity and data confidentiality. S5. The replication protocol MUST support the ability during initialization of a replication session for an authenticated source and replica to mutually decide to disable data integrity and data confidentiality within the context of and for the duration of that particular replication session. S6. To promote interoperability, there MUST be a mandatory-to- implement data privacy mechanism. S7. The transport for administrative access MUST permit assurance of the integrity and privacy of all data transferred. Stokes, et al Expires January 2002 [Page 13] Internet-Draft LDAPv3 Replication Requirements July 2001 5 Security Considerations This document includes security requirements (listed in section 4.8 above) for the replication model and protocol. As noted in Section 3, interoperability may be impacted when replicating among servers that implement non-standard extensions to basic LDAP semantics. Since LDAPv3 access control is a set of standards-based extensions, security- related and even general LDAP interoperability will be significantly impacted by the degree of consistency with which LDAP implementations support the access control model [ACModel]. 6 Acknowledgements This document is based on input from IETF members interested in LDUP Replication. 7 References [ACID] T. Haerder, A. Reuter, "Principles of Transaction-Oriented Database Recovery", Computing Surveys, Vol. 15, No. 4 (December 1983), pp. 287-317. [ACModel] E. Stokes, R. Blakeley, R. Byrne, R. Huber, D. Rinkevich, "Access Control Model for LDAPv3", Internet Draft, draft-ietf-ldapext- acl-model-08.txt, June 2001. [NDS] Novell, "NDS Technical Overview", 104-000223-001, http://developer.novell.com/ndk/doc/ndslib/dsov_enu/data/h6tvg4z7.html, September, 2000. [RFC2119] S. Bradner, "Key Words for Use in RFCs to Indicate Requirement Levels", RFC 2119, March 1997. [RFC2251] M. Wahl, T. Howes, S. Kille, "Lightweight Directory Access Protocol", RFC 2251, December 1997. [RFC2252] M. Wahl, A. Coulbeck, T. Howes, S. Kille, "Lightweight Directory Access Protocol (v3): Attribute Syntax Definitions", RFC 2252, December 1997. [RFC2253] S. Kille, M. Wahl, and T. Howes, "Lightweight Directory Access Protocol (v3): UTF-8 String Representation of Distinguished Names", RFC 2253, December 1997. [RFC2254] T. Howes, "The String Representation of LDAP Search Filters", RFC 2254, December 1997. Stokes, et al Expires January 2002 [Page 14] Internet-Draft LDAPv3 Replication Requirements July 2001 [RFC2255] T. Howes, M. Smith, "The LDAP URL Format", RFC 2255, December 1997. [RFC2256] M. Wahl, "A Summary of the X.500(96) User Schema for use with LDAPv3", RFC 2256, December 1997. [RFC2828] R. Shirey, "Internet Security Glossary", RFC2828, May 2000. [RFC2829] M. Wahl, H. Alvestrand, J. Hodges, R. Morgan. "Authentication Methods for LDAP", RFC 2829, May 2000. [RFC2830] J. Hodges, R. Morgan, M. Wahl, "Lightweight Directory Access Protocol (v3): Extension for Transport Layer Security", RFC 2830, May 2000. [RFC2849] Gordon Good, "The LDAP Data Interchange Format (LDIF)", RFC 2849, June 2000. [X.501] ITU-T Recommendation X.501 (1993), | ISO/IEC 9594-2: 1993, Information Technology - Open Systems Interconnection - The Directory: Models. [X.525] ITU-T Recommendation X.525 (1997), | ISO/IEC 9594-9: 1997, Information Technology - Open Systems Interconnection - The Directory: Replication. [XEROX] C. Hauser, "Managing update conflicts in Bayou, a weakly connected replicated storage system". Palo Alto, CA: Xerox PARC, Computer Science Laboratory; 1995 August; CSL-95-4. [CSL-95-04] [XEROX2] Alan D. Demers, Mark Gealy, Daniel Greene, Carl Hauser, Wesley Irish, John Larson, Sue Manning, Scott Shenker, Howard Sturgis, Daniel Swinehart, Douglas Terry, Don Woods, "Epidemic Algorithms for Replicated Database Maintenance". Palo Alto, CA, Xerox PARC, January 1989. A. APPENDIX A - Usage Scenarios The following directory deployment examples are intended to validate our replication requirements. A heterogeneous set of directory implementations is assumed for all the cases below. This material is intended as background; no requirements are presented in this Appendix. A.1. Extranet Example Stokes, et al Expires January 2002 [Page 15] Internet-Draft LDAPv3 Replication Requirements July 2001 A company has a trading partner with whom it wishes to share directory information. This information may be as simple as a corporate telephone directory, or as complex as an extranet workflow application. For performance reasons, the company wishes to place a replica of its directory within the Partner Company, rather than exposing its directory beyond its firewall. The requirements that follow from this scenario are: - One-way replication, single mastered. - Authentication of clients. - Common access control and access control identification. - Secure transmission of updates. - Selective attribute replication (Fractional Replication), so that only partial entries can be replicated. A.2. Consolidation Example Company A acquires company B. Each company has an existing directory. During the transition period, as the organizations are merged, both directory services must coexist. Company A may wish to attach company B's directory to its own. The requirements that follow from this scenario are: - Multi-Master replication. - Common access control model. Access control model identification. - Secure transmission of updates. - Replication between DITs with potentially differing schema. A.3. Replication Heterogeneous Deployment Example An organization may choose to deploy directory implementations from multiple vendors, to enjoy the distinguishing benefits of each. In this case, multi-master replication is required to ensure that the multiple replicas of the DIT are synchronized. Some vendors may provide directory clients, which are tied to their own directory service. The requirements that follow from this scenario are: - Multi-Master replication - Common access control model and Access control model identification. - Secure transmission of updates. - Replication among DITs with potentially differing schemas. Stokes, et al Expires January 2002 [Page 16] Internet-Draft LDAPv3 Replication Requirements July 2001 A.4. Shared Name Space Example Two organizations may choose to cooperate on some venture and need a shared name space to manage their operation. Both organizations will require administrative rights over the shared name space. The requirements that follow from this scenario are: - Multi-Master replication. - Common access control model and Access control model identification. - Secure transmission of updates. A.5. Supplier Initiated Replication This is a single master environment that maintains a number of replicas of the DIT by pushing changes based on a defined schedule. The requirements that follow from this scenario are: - Single-master environment. - Supplier-initiated replication. - Secure transmission of updates. A.6. Consumer Initiated Replication Again a single mastered replication topology, but the slave replica initiates the replication exchange rather than the master. An example of this is a replica that resides on a laptop computer that may run disconnected for a period of time. The requirements that follow from this scenario are: - Single-master environment. - Consumer initiated replication. - Open scheduling (anytime). A.7. Prioritized attribute replication The password attribute can provide an example of the requirement for prioritized attribute replication. A user is working in Utah and the administrator resides in California. The user has forgotten his password. So the user calls or emails the administrator to request a new password. The administrator provides the updated password (a change). Under normal conditions, the directory replicates to a number of different locations overnight. But corporate security policy states that passwords are critical and the new value must be available Stokes, et al Expires January 2002 [Page 17] Internet-Draft LDAPv3 Replication Requirements July 2001 immediately (e.g. shortly) after any change. Replication needs to occur immediately for critical attributes/entries. The requirements that follow from this scenario are: - Incremental replication of changes. - Immediate replication on change of certain attributes. - Replicate based on time/attribute semantics. A.8. Bandwidth issues The replication of Server (A) R/W replica (a) in Kathmandu is handled via a dial up phone link to Paris where server (B) R/W replica of (a) resides. Server (C) R/W replica of (a) is connected by a T1 connection to server (B). Each connection has a different performance characteristic. The requirements that follow from this scenario are: - Minimize repetitive updates when replicating from multiple replication paths. - Incremental replication of changes. - Provide replication cycles to delay and/or retry when connections cannot be reached. - Allowances for consumer initiated or supplier initiated replication. A.9. Interoperable Administration and Management The administrator with administrative authority of the corporate directory which is replicated by numerous geographically dispersed LDAP servers from different vendors notices that the replication process is not completing correctly as the change log is continuing to grow and/or error message informs him. The administrator uses his $19.95 RepCo LDAP directory replication diagnostics tools to look at Root DSE replica knowledge on server 17 and determines that server 42 made by LDAP'RUS Inc. is not replicating properly due to an Object conflict. Using his Repco Remote repair tools he connects to server 42 and resolves the conflict on the remote server. The requirements that follow from this scenario are: - Provides replication audit history. - Provisions for managing conflict resolution. - Provide LDAP access to predetermined agreements, topology and policy attributes. - Provide operations for comparing replica's content for validity. - Provide LDAP access to status and audit information. Stokes, et al Expires January 2002 [Page 18] Internet-Draft LDAPv3 Replication Requirements July 2001 A.10. Enterprise Directory Replication Mesh A Corporation builds a mesh of directory servers within the enterprise utilizing LDAP servers from various vendors. Five servers are holding the same area of replication. The predetermined replication agreement(s) for the enterprise mesh are under a single management, and the security domain allows a single predetermined replication agreement to manage the 5 servers' replication. The requirements that follow from this scenario are: - One predefined replication agreement that manages a single area of replication that is held on numerous servers. - Common support of replication management knowledge across vendor implementation. - Rescheduling and continuation of a replication cycle when one server in a replica-group is busy and/or unavailable. A.11. Failure of the Master in a Master-Slave Replicated Directory A company has a corporate directory that is used by the corporate email system. The directory is held on a mesh of servers from several vendors. A corporate relocation results in the closing of the location where the master copy of the directory is located. Employee information (such as mailbox locations and employee certificate information) must be kept up to date or mail cannot be delivered. The requirements that follow from this scenario are: - An existing slave replica must be "promote-able" to become the new master. - The "promotion" must be done without significant downtime, since updates to the directory will continue. A.12. Failure of a Directory Holding Critical Service Information An ISP uses a policy management system that uses a directory as the policy data repository. The directory is replicated in several different sites on different vendors' products to avoid single points of failure. It is imperative that the directory be available and be updateable even if one site is disconnected from the network. Changes to the data must be traceable, and it must be possible to determine how changes made from different sites interacted. The requirements that follow from this scenario are: - Multi-master replication - Ability to reschedule replication sessions Stokes, et al Expires January 2002 [Page 19] Internet-Draft LDAPv3 Replication Requirements July 2001 - Support for manual review and override of replication conflict resolution B. APPENDIX B - Rationale This Appendix gives some of the background behind the requirements. It is included to help the protocol designers understand the thinking behind some of the requirements and to present some of the issues that should be considered during design. With the exception of section B.8, which contains a suggested requirement for the update to RFC 2251, this Appendix does not state any formal requirements. B.1. Meta-Data Implications Requirement G4 states that meta-data must not grow without bound. This implies that meta-data must, at some point, be purged from the system. This, in turn, raises concerns about stability. Purging meta-data before all replicas have been updated may lead to incomplete replication of change information and inconsistencies among replicas. Therefore, care must be taken setting up the rules for purging meta- data from the system while still ensuring that meta-data will not grow forever. B.2. Order of Transfer for Replicating Data Situations may arise where it would be beneficial to replicate data out-of-order (e.g. send data to consumer replicas in a different order than it was processed at the supplier replica). One such case might occur if a large bulk load was done on the master server in a single- master environment and then a single change to a critical OID (a password change, for example) was then made. Rather than wait for all the bulk data to be sent to the replicas, the password change might be moved to the head of the queue and be sent before all the bulk data was transferred. Other cases where this might be considered are schema changes or changes to critical policy data stored in the directory. While there are practical benefits to allowing out-of-order transfer, there are some negative consequences as well. Once out-of-order transfers are permitted, all receiving replicas must be prepared to deal with data and schema conflicts that might arise. As an example, assume that schema changes are critical and must be moved to the front of the replication queue. Now assume that a schema change deletes an attribute for some object class. It is possible that some of the operations ahead of the schema change in the queue are operations to delete values of the soon-to-be-deleted attribute so that the schema change can be done with no problems. If the schema change Stokes, et al Expires January 2002 [Page 20] Internet-Draft LDAPv3 Replication Requirements July 2001 moves to the head of the queue, the consumer servers might have to delete an attribute that still has values, and then receive requests to delete the values of an attribute that is no longer defined. In the multi-master case, similar situations can arise when simultaneous changes are made to different replicas. Thus, multi- master systems must have conflict resolution algorithms in place to handle such situations. But in the single-master case conflict resolution is not needed unless the master is allowed to send data out- of-order. This is the reasoning behind requirement SM2, which recommends that data always be sent in order in single-master replication. Note that even with this restriction, the concept of a critical OID is still useful in single-master replication. An example of its utility can be found in section A.7. B.3. Schema Mismatches and Replication Multi-vendor environments are the primary area of interest for LDAP replication standards. Some attention must thus be paid to the issue of schema mismatches, since they can easily arise when vendors deliver slightly different base schema with their directory products. Even when both products meet the requirements of the standards [RFC2252], the vendors may have included additional attributes or object classes with their products. When two different vendor's products attempt to replicate, these additions can cause schema mismatches. Another potential cause of schema mismatches is discussed in section A.3. There are only a few possible responses when a mismatch is discovered. - Raise an error condition and ignore the data. This should always be allowed and is the basis for requirement P8 and the comment on M10. - Map/convert the data to the form required by the consuming replica. A system may choose this course; requirement M10 is intended to allow this option. The extent of the conversion is up to the implementation; in the extreme it could support use of the replication protocol in meta-directories. - Quietly ignore (do not store on the consumer replica and do not raise an error condition) any data that does not conform to the schema at the consumer. Requirement M10 is intended to exclude the last option. Requirement AM8 suggests that vendors should provide tools to help discover schema mismatches when replication is being set up. But schema will change after the initial setup, so the replication system must be prepared to handle unexpected mismatches. Stokes, et al Expires January 2002 [Page 21] Internet-Draft LDAPv3 Replication Requirements July 2001 Normal IETF practice in protocol implementation suggests that one be strict in what one sends and be flexible in what one receives. The parallel in this case is that a supplier should be prepared to receive an error notification for any schema mismatch, but a consumer may choose to do a conversion instead. The other option that can be considered in this situation is the use of fractional replication. If replication is set up so only the common attributes are replicated, mismatches can be avoided. One additional consideration here is replication of the schema itself. M4 requires that it be possible to replicate schema. If a consumer replica is doing conversion, extreme care should be taken if schema elements are replicated since some attributes are intended to have different definitions on different replicas. For fractional replication, the protocol designers and implementors should give careful consideration to the way they handle schema replication. Some options for schema replication include: - All schema elements are replicated. - Schema elements are replicated only if they are used by attributes that are being replicated. - Schema are manually configured on the servers involved in fractional replication; schema elements are not replicated via the protocol. B.4. Detecting and Repairing Inconsistencies Among Replicas Despite the best efforts of designers, implementors, and operators, inconsistencies will occasionally crop up among replicas in production directories. Tools will be needed to detect and to correct these inconsistencies. A special client may accomplish detection through periodic comparisons of replicas. This client would typically read two replicas of the same replication base entry and compare the answers, possibly by BINDing to each of the two replicas to be compared and reading them both. In cases where the directory automatically reroutes some requests (e.g. chaining), mechanisms to force access to a particular replica should be supplied. Alternatively, the server could support a special request to handle this situation. A client would invoke an operation at some server. It would cause that server to extract the contents from some other server it has a replication agreement with and report the differences back to the client as the result Stokes, et al Expires January 2002 [Page 22] Internet-Draft LDAPv3 Replication Requirements July 2001 If an inconsistency is found, it needs to be repaired. To determine the appropriate repair, the administrator will need access to the replication history to figure out how the inconsistency occurred and what the correct repair should be. When a repair is made, it should be restricted to the replica that needs to be fixed; the repair should not cause new replication events to be started. This may require special tools to change the local data store without triggering replication. Requirements AM2, AM4, and AM5 address these needs. B.5. Some Test Cases for Conflict Resolution in Multi-Master Replication Use of multi-master replication inevitably leads to the possibility that incompatible changes will be made simultaneously on different servers. In such cases, conflict resolution algorithms must be applied. As a guiding principle, conflict resolution should avoid surprising the user. One way to do this is to adopt the principle that, to the extent possible, conflict resolution should mimic the situation that would happen if there were a single server where all the requests were handled. While this is a useful guideline, there are some situations where it is impossible to implement. Some of these cases are examined in this section. In particular, there are some cases where data will be "lost" in multi-master replication that would not be lost in a single-server configuration. In the examples below, assume that there are three replicas, A, B, and C. All three replicas are updateable. Changes are made to replicas A and B before replication allows either replica to see the change made on the other. In discussion of the multi-master cases, we assume that the change to A takes precedence using whatever rules are in force for conflict resolution. B.5.1. Create-Create A user creates a new entry with distinguished name DN on A. At the same time, a different user adds an entry with the same distinguished name on B. In the single-server case, one of the create operations would have occurred before the other, and the second request would have failed. Stokes, et al Expires January 2002 [Page 23] Internet-Draft LDAPv3 Replication Requirements July 2001 In the multi-master case, each create was successful on its originating server. The problem is not detected until replication takes place. When a replication request to create a DN that already exists arrives at one of the servers, conflict resolution is invoked. (Note that the two requests can be distinguished even though they have the same DN because every entry has some sort of unique identifier per requirement SC9.) As noted above, in these discussions we assume that the change from replica A has priority based on the conflict resolution algorithm. Whichever change arrives first, requirement MM6 says that the values from replica A must be those in place on all replicas at the end of the replication cycle. Requirement MM5 states that the system cannot quietly ignore the values from replica B. The values from replica B might be logged with some notice to the administrators, or they might be added to the DIT with a machine generated DN (again with notice to the administrators). If they are stored with a machine generated DN, the same DN must be used on all servers in the replica-group (otherwise requirement M3 would be violated). Note that in the case where the entry in question is a container, storage with a machine generated DN provides a place where descendent entries may be stored if any descendents were generated before the replication cycle was completed. In any case, some mechanism must be provided to allow the administrator to reverse the conflict resolution algorithm and force the values originally created on B into place on all replicas if desired. B.5.2. Rename-Rename On replica A, an entry with distinguished name DN1 is renamed to DN. At the same time on replica B, an entry with distinguished name DN2 is renamed to DN. In the single-server case, one rename operation would occur before the other and the second would fail since the target name already exists. In the multi-master case, each rename was successful on its originating server. Assuming that the change on A has priority in the conflict resolution sense, DN will be left with the values from DN1 in all replicas and DN1 will no longer exist in any replica. The question is what happens to DN2 and its original values. Requirement MM5 states that these values must be stored somewhere. They might be logged, they might be left in the DIT as the values of DN2, or they might be left in the DIT as the values of some machine generated DN. Leaving them as the values of DN2 is attractive since it Stokes, et al Expires January 2002 [Page 24] Internet-Draft LDAPv3 Replication Requirements July 2001 is the same as the single-server case, but if a new DN2 has already been created before the replica cycle finishes, there are some very complex cases to resolve. Any of the solutions described in this paragraph would be consistent with requirement MM5. B.5.3. Locking Based on Atomicity of ModifyRequest There is an entry with distinguished name DN that contains attributes X, Y, and Z. The value of X is 1. On replica A, a ModifyRequest is processed which includes modifications to change that value of X from 1 to 0 and to set the value of Y to "USER1". At the same time, replica B processes a ModifyRequest which includes modifications to change the value of X from 1 to 0 and to set the value of Y to "USER2" and the value of Z to 42. The application in this case is using X as a lock and is depending on the atomic nature of ModifyRequests to provide mutual exclusion for lock access. In the single-server case, the two operations would have occurred sequentially. Since a ModifyRequest is atomic, the entire first operation would succeed. The second ModifyRequest would fail, since the value of X would be 0 when it was attempted, and the modification changing X from 1 to 0 would thus fail. The atomicity rule would cause all other modifications in the ModifyRequest to fail as well. In the multi-master case, it is inevitable that at least some of the changes will be reversed despite the use of the lock. Assuming the changes from A have priority per the conflict resolution algorithm, the value of X should be 0 and the value of Y should be "USER1" The interesting question is the value of Z at the end of the replication cycle. If it is 42, the atomicity constraint on the change from B has been violated. But for it to revert to its previous value, grouping information must be retained and it is not clear when that information can be safely discarded. Thus, requirement G6 may be violated. B.5.4. General Principles With multi-master replication there are a number of cases where a user or application will complete a sequence of operations with a server but those actions are later "undone" because someone else completed a conflicting set of operations at another server. To some extent, this can happen in any multi-user system. If a user changes the value of an attribute and later reads it back, intervening operations by another user may have changed the value. In the multi- master case, the problem is worsened, since techniques used to resolve the problem in the single-server case won't work as shown in the examples above. Stokes, et al Expires January 2002 [Page 25] Internet-Draft LDAPv3 Replication Requirements July 2001 The major question here is one of intended use. In LDAP standards work, it has long been said that replication provides "loose consistency" among replicas. At several IETF meetings and on the mailing list, usage examples from finance where locking is required have been declared poor uses for LDAP. Requirement G1 is consistent with this history. But if loose consistency is the goal, the locking example above is an inappropriate use of LDAP, at least in a replicated environment. B.5.5. Avoiding the Problem The examples above discuss some of the most difficult problems that can arise in multi-master replication. While they can be dealt with, dealing with them is difficult and can lead to situations that are quite confusing to the application and to users. The common characteristics of the examples are: - Several directory users/applications are changing the same data. - They are changing the data before previous changes have replicated. - They are using different directory servers to make these changes. - They are changing data that are parts of a distinguished name or they are using ModifyRequest to both read and write a given attribute value in a single atomic request. If any one of these conditions is reversed, the types of problems described above will not occur. There are many useful applications of multi-master directories where at least one of the above conditions does not occur. For cases where all four do occur, application designers should be aware of the possible consequences. B.6. Data Confidentiality and Data Integrity During Replication Directories will frequently hold proprietary information. Policy information, name and address information, and customer lists can be quite proprietary and are likely to be stored in directories. Such data must be protected against intercept or modification during replication. In some cases, the network environment (e.g. a private network) may provide sufficient data confidentiality and integrity for the application. In other cases, the data in the directory may be public and not require protection. For these reasons data confidentiality and integrity were not made requirements for all replication sessions. But there are a substantial number of applications that will need data confidentiality and integrity for replication, so there is a requirement (S4) that the protocol allow for data confidentiality and Stokes, et al Expires January 2002 [Page 26] Internet-Draft LDAPv3 Replication Requirements July 2001 integrity in those cases where they are needed. Typically, the policy on the use of confidentiality and integrity measures would be held in the replication agreement per requirement M7. This leaves the question of what mechanism(s) to use. While this is ultimately a design/implementation decision, replication across different vendors' directory products is an important goal of the LDAP replication work at the IETF. If different vendors choose to support different data confidentiality and integrity mechanisms, the advantages of a standard replication protocol would be lost. Thus there is a requirement (S6) for mandatory-to-implement data confidentiality and integrity mechanisms. Anonymous replication (requirement S3) is supported since it may be useful in the same sorts of situations where data integrity and data confidentiality protection are not needed. B.7. Failover in Single-Master Systems In a single-master system, all modifications must originate at the master. The master is therefore a single point of failure for modifications. This can cause concern when high availability is a requirement for the directory system. One way to reduce the problem is to provide a failover process that converts a slave replica to master when the original master fails. The time required to execute the failover process then becomes a major factor in availability of the system as a whole. Factors that designers and implementors should consider when working on failover include: - If the master replica contains control information or meta-data that is not part of the slave replica(s), this information will have to be inserted into the slave that is being "promoted" to master as part of the failover process. Since the old master is presumably unavailable at this point, it may be difficult to obtain this data. For example, if the master holds the status information of all replicas, but each slave replica only holds its own status information, failover would require that the new master get the status of all existing replicas, presumably from those replicas. Similar issues could arise for replication agreements if the master is the only system that holds a complete set. - If data privacy mechanisms (e.g. encryption) are in use during replication, the new master would need to have the necessary key information to talk to all of the slave replicas. Stokes, et al Expires January 2002 [Page 27] Internet-Draft LDAPv3 Replication Requirements July 2001 - It is not only the new master that needs to be reconfigured. The slaves also need to have their configurations updated so they know where updates should come from and where they should refer modifications. - The failover mechanism should be able to handle a situation where the old master is "broken" but not "dead". The slave replicas should ignore updates from the old master after failover is initiated. - The old master will eventually be repaired and returned to the replica-group. It might join the group as a slave and pick up the changes it has "missed" from the new master, or there might be some mechanism to bring it into sync with the new master and then let it take over as master. Some resynchronization mechanism will be needed. - Availability would be maximized if the whole failover process could be automated (e.g. failover is initiated by an external system when it determines that the original master is not functioning properly). B.8. Including Operational Attributes in Atomic Operations LDAPv3 [RFC2251] declares that some operations are atomic (e.g. all of the modifications in a single ModifyRequest). It also defines several operational attributes that store information about when changes are made to the directory (createTimestamp, etc.) and which ID was responsible for a given change (modifiersName, etc.). Currently, there is no statement in RFC2251 requiring that changes to these operational attributes be atomic with the changes to the data. It is RECOMMENDED that this requirement be added during the revision of RFC2251. In the interim, replication SHOULD treat these operations as though such a requirement were in place. Authors' Addresses Russel F. Weiser Digital Signature Trust Co. 1095 East 2100 South Suite #201 Salt Lake City, Utah 84106 USA E-mail: rweiser@trustdst.com Telephone: +1 801 326 5421 Ellen J. Stokes Stokes, et al Expires January 2002 [Page 28] Internet-Draft LDAPv3 Replication Requirements July 2001 Tivoli Systems 9442 Capital of Texas Hwy N Austin, TX 78759 USA E-mail: estokes@tivoli.com Telephone: +1 512 436 9098 Fax: +1 512 436 1190 Ryan D. Moats Lemur Networks 15621 Drexel Circle Omaha, NE 68135 USA E-Mail: rmoats@lemurnetworks.net Telephone: +1 402 894 9456 Richard V. Huber Room C3-3B30 AT&T Laboratories 200 Laurel Avenue South Middletown, NJ 07748 USA E-Mail: rvh@att.com Telephone: +1 732 420 2632 Fax: +1 732 368 1690 Full Copyright Statement Copyright (C) The Internet Society (2000). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. Stokes, et al Expires January 2002 [Page 29] Internet-Draft LDAPv3 Replication Requirements July 2001 This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Acknowledgement Funding for the RFC Editor function is currently provided by the Internet Society. Stokes, et al Expires January 2002 [Page 30] --------------1AD09966D93511DF63618EC2-- From owner-ietf-ldup@mail.imc.org Mon Jul 16 15:43:21 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA25776 for ; Mon, 16 Jul 2001 15:43:21 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.3/8.11.3) id f6GJOln24555 for ietf-ldup-bks; Mon, 16 Jul 2001 12:24:47 -0700 (PDT) Received: from ns.oncalldba.com (cpe-66-1-184-87.ut.sprintbbd.net [66.1.184.87]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f6GJOfq24550 for ; Mon, 16 Jul 2001 12:24:42 -0700 (PDT) Received: from reed.oncalldba.com (reed.OnCallDBA.COM [192.168.1.3]) by ns.oncalldba.com (8.11.0/8.11.0) with SMTP id f6GJObB25449 for ; Mon, 16 Jul 2001 13:24:37 -0600 Received: from RMINC_DOM-Message_Server by reed.oncalldba.com with Novell_GroupWise; Mon, 16 Jul 2001 13:25:01 -0600 Message-Id: X-Mailer: Novell GroupWise Internet Agent 5.5.2.1 Date: Mon, 16 Jul 2001 13:24:50 -0600 From: "Ed Reed" To: , , , Cc: , , "Ed Reed" Subject: LDAPSubentries comments review and request for last call by LDAPEXT and LDUP working groups 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 f6GJOlq24552 Sender: owner-ietf-ldup@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 8bit First version was published as an ldup working group document on 15 August 1999 with agreement of both the LDAPEXT and LDUP working group chairs that the document would be subject to a joint working group last call, but would be "worked" in the LDUP working group, due to LDAPEXT wg work load. 1) David Chadwick commented, on 25 Oct 1999 that the two attributes, "cn" and "subtreeSpec", serve different purposes. In particular, that because the LDAPSubentry definition is a subset of the X.500 subentries, "cn" used to name the subentry and "subtreeSpec" used to refine the scope of the subentry to possibly include fewer than all entries than the full subtree in which it's defined. Response: True. That is the intent of defining the LDAPSubentry - to make explicit that the scope is as though an empy subtreeSpec is defined for the LDAPSubentry. Arguably, we could say that LDAP will use the X.501 subentry definition, but then implementations would all have to "grok" the subtreeSpec attribute syntax and semantics, and the goal of creating the LDAPSubentry is to eliminate that requirement. 2) Kurt Zeilenga commented on 18 Nov 1999 that he didn't want to be required to name LDAPSubentries with cn, but wanted to be able to use other naming attributes instead that wouldn't introduce conflicts with non-subentries named with "cn". He suggested making LDAPSubentry be an abstract class with no naming attribute defined, and then subclassing another class that used "cn" as its naming attribute. Response: Naming rules are funny things in LDAP...following more discussion, Kurt suggested on 25 April 2000 that we make "cn" MUST, but state that naming with attributes other than CN is allowed. Agreed. 3) Steven Legg, on 30 March 2000 asked that we not leave naming up to developers, but clearly define what's to be expected. Response: Each application developer that defines a use of the LDAPsubentry class with a derived class (by which alternative naming attributes could be added - I presume that alternative naming attributes may NOT be added via adding Auxilliary classes) will be so defining the semantics of the new class (including the naming rules for the new class) that applications will need to know those semantics to make sense of the new subentry type, anyway. Browsers and applications will need to either know the semantics of the new class, or be schema aware enough to read and interpret naming rules that apply to the new class. The definition sets the expectation that "cn" will be used, but that other attributes MAY be used instead or as well (subject to the naming rules defined for the new class). My heart's with Steven, but I'm trying to accomodate Kurt, too. Came down on Kurt's side on this one. 4) David Chadwick on 15 March 2000 opined that if, in the future, LDAP wants to limit the portion of a naming context to which a subentry applies, we can simply re-invent subtreeSpecification at that time. Response - agreed, or even simply use the X.500 definition of subentry, if that will work for the application (ie, if the application doesn't need subentries to contain other subentries in a tree of subentries, and if X.500's family of entries won't work to reproduce the LDAPSubentry containment rules allowing subentries to contain other subentries). 5) Kurt Zeilenga on 3 July 2000 opined that LDAPSubentry should be abandoned in favor of just doing X.500 subentries, including subtreeSpecification, and be visible on the basis of a control. He made these suggestions so they'd be more useful within LDAP and for the Access Control Model, in particular. Response: After considerable discussion, we agreed on the list to use a control to make LDAPSubentries visible instead of the search filter mechanism, because the filter mechanism adds significant logic predicate complexity to developers whose applications already use complex search filters. The filter makes things simple and more importantly provides equivalent functionality to the X.500 subentries visibility mechanism. With regard to "just doing X.500", Mark Smith wrote on 7 July 2000 that "The X.500 subtree specifier is rich and therefore fairly complex to implement. That doesn't mean we shouldn't adopt it, but id does mean we should consider the impact." Kurt replied that we also need to consider the impact of making changes, possibly incompatible ones, to X.500 elements, like making them hierarchical instead of flat, and limiting their utility by dropping the subtreeSpecification. The author (me, Ed Reed) replied to Kurt's proposal to "just do X.500" with the following reasons for omitting the subtree specifier: a) it introduces what seems to be a lot of complexity to determining which entries a subentry would refer to, b) it introduces what seems to be a lot of complexity to determining which subentries apply to a particular entry, c) it introduces what seems to be a lot of complex thinking for administrators who want to understand how to tell their system to do something, and to understand what their system is trying to do d) the author (me) has not been exposed to many (any) real-world problems solved by the subtree specifier which are not or can not be as well handled in some other fashion. 6) There followed a discussion between Alan Lloyd, Albert Langer, Rob Byrne and Ron Ramsay about the relative merits of using subentries to hold access control information, particularly in distributed environments. 7) Last Call attempted on 14 July 2000, but Kurt immediately objected...to inadequate clarity of scoping specification and semantics, and to continued use of search filter to control visibility. Response: following additional remarks by others about semantics and administrative models, a section describing the X.501 administrative model and a proposed LDAP subset using LDAPsubentries was added. Additional language was added to try to pin down the semantics relating to containment/structure rules governing LDAPsubentries and their scope. The search filter visibility mechanism was eliminated in favor of a control. 8) Once the decision was made to use a control, the question of what kind of control was discussed: one corresponding to the subentries bit of the ServiceControls argument in X.511, or one corresponding to the whole ServiceControls argument (including the subentries bit). Response: concensus of the group appears to support the simpler control - representing just the subentries bit of the ServiceControl argument. It's simpler and doesn't introduce a lot of unresolved design issues that having the whole ServiceControls argument would create. 9) Compatibility issues for clients using RFC2215 to read LDAP subschema subentries (via search filter instead of a control) was raised, and Kurt offered to address them in LDAPbis. Response: Kurt to address in LDAPbis. 10) A discussion ensued over the behavior of the LDAPSubentriesControl to searches with scope of base entries (not an issue for X.500, since X.500 has READ as well as SEARCH). Respons: visibility was specified to be implicitly TRUE when a base entry search or a subtree search is made where the base of the search is an LDAPSubentry. So, even if the control is absent, if you base a search on an LDAPSubEntry it's obvious that you DO want the LDAPSubentry, so pretend the control is present even if it's not. 11) On 4 November 2000 I recounted the discussion from the working group about administrative areas and subentries. Issues raised in the discussion had to do with problems of partitioning administrative areas, dealing with various inheritance models of policy across multiple partitions of an administrative area, and so on. Response: Following that discussion, and the one at the spring IETF, I published a "light weight" administrative model designed as a subset of the X.500 model for comments, and then added them to the latest (-08.txt) draft. 12) On 6 Nov 2000 Rick Huber submitted several editorial corrections to the draft -04.txt, which were incorporated into later drafts. Ditto the -06 draft. 13) In the -07.txt draft published 1 March 2001 I removed the whole discussion of inheritance and the inheritableLdapSubentry object class specification and its attributes from the text. At bar boff convened to discuss the issue, we found that no "down-tree" inheritance replication mechanism was needed if servers hold sparse/fractional replicas of superior administrative areas that have LDAPsubentries relevant to the replication areas they hold. A separate internet draft, due to expire shortly, was written to describe that scheme. 14) The -08.txt draft published 6 April 2001 includes the candidate administration model originally circulated for comment on 22 March 2001. There have been two comments - one saying "it looks reasonable at first glance", and the other opposing the adoption of an administration model subsetted from X.500 without careful analysis and consideration. The comment in opposition also expressed the desire to see both LDAPEXT and LDUP involved in the decision, which both are (this being an output of both working groups and subject to last call in both groups). Response: The need for subentries to be understood within the context of an administrative model seems to be generally agreed to across the working group participants who have commented. The need to understand how administrative areas will work in a multi-master environment, and how policy is projected from an administrative point through a subtree needs to be understood. I've chosen in the model to leave some of the thornier issues of how administrative areas span specific administration areas, and in particular replication areas until more work is done on LDAP distributed operations. I'm generally in agreement that the X.500 model of Directory Specific Entries, distributed chaining operations, and even the use of subtreeSpecifications (for defining sparse and fractional replicas) probably do make sense - but that they need to be adapted to deal with the kind of multi-master, loosely consistent replication provided by LDUP. I think the administrative model subset I've ! proposed keeps us moving in the right direction - towards accreting more and more of X.500 into LDAP - without forcing us to lunge all the way into the pool at once. So - I'd like more comments on the administrative model. Does it work for ACI as LDAPEXT is defining it? Other applications than just LDUP? I think it DOES work for LDUP (ie, managing replication areas). With that, said, I'd like to ask the working group chairs of LDAPEXT and LDUP to jointly or severally issue last call on draft-ietf-ldup-subentry-08.txt. Regards, Ed Reed ================= Ed Reed Reed-Matthews, Inc. +1 801 796 7065 http://www.Reed-Matthews.COM From owner-ietf-ldup@mail.imc.org Tue Jul 17 07:11:59 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA12682 for ; Tue, 17 Jul 2001 07:11:59 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.3/8.11.3) id f6HAskQ05463 for ietf-ldup-bks; Tue, 17 Jul 2001 03:54:46 -0700 (PDT) Received: from ietf.org (odin.ietf.org [132.151.1.176]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f6HAsjq05458 for ; Tue, 17 Jul 2001 03:54:45 -0700 (PDT) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA10688; Tue, 17 Jul 2001 06:53:51 -0400 (EDT) Message-Id: <200107171053.GAA10688@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: ietf-ldup@imc.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-ldup-infomod-03.txt Date: Tue, 17 Jul 2001 06:53:51 -0400 Sender: owner-ietf-ldup@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the LDAP Duplication/Replication/Update Protocols Working Group of the IETF. Title : LDUP Replication Information Model Author(s) : E. Reed, T. Hahn Filename : draft-ietf-ldup-infomod-03.txt Pages : 31 Date : 16-Jul-01 [LDUP Model] describes the architectural approach to replication of LDAP directory contents. This document describes the information model and schema elements which support LDAP Replication Services which conform to [LDUP Model]. Directory schema is extended to provide object classes, subentries, and attributes to describe areas of the namespace which are under common administrative authority, units of replication (ie, subtrees, or partitions of the namespace, which are replicated), servers which hold replicas of various types for the various partitions of the namespace, which namespaces are held on given servers, and the progress of various namespace management and replication operations. Among other things, this knowledge of where directory content is located will provide the basis for dynamic generation of LDAP referrals for clients who can follow them. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ldup-infomod-03.txt Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-ldup-infomod-03.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-ldup-infomod-03.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20010716153917.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ldup-infomod-03.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ldup-infomod-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20010716153917.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ietf-ldup@mail.imc.org Tue Jul 17 10:45:36 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA20485 for ; Tue, 17 Jul 2001 10:45:36 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.3/8.11.3) id f6HEPVs09303 for ietf-ldup-bks; Tue, 17 Jul 2001 07:25:31 -0700 (PDT) Received: from hawk.ummail.com (hawk.ummail.com [64.58.86.20]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f6HEPUq09299 for ; Tue, 17 Jul 2001 07:25:30 -0700 (PDT) Received: from ex01.ummail.com (ex01.ummail.com [216.33.108.253:25]) by hawk.ummail.com with ESMTP id N0717-1025-625900; Tue, 17 Jul 2001 14:25:17 GMT Received: by ex01.ummail.com with Internet Mail Service (5.5.2650.21) id <392HCV1P>; Tue, 17 Jul 2001 10:23:15 -0400 Message-ID: From: Christopher Apple To: "'Richard Huber'" , ietf-ldup@imc.org Subject: RE: New Requirements draft (-10) Date: Tue, 17 Jul 2001 10:23:14 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) MIME-Version: 1.0 Content-Type: multipart/signed; micalg=SHA1; boundary="----=_NextPart_000_001B_01C10EAA.64357A20"; protocol="application/x-pkcs7-signature" X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: owner-ietf-ldup@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multi-part message in MIME format. ------=_NextPart_000_001B_01C10EAA.64357A20 Content-Type: multipart/mixed; boundary="----=_NextPart_001_001C_01C10EAA.64357A20" ------=_NextPart_001_001C_01C10EAA.64357A20 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit John and I will send the -10 revision of this document to Patrik and Ned with a request for IESG Review once it is published by the I-D Editor. Chris Apple Program Manager - Directory Services United Messaging Inc. (V) 610-425-2860 >-----Original Message----- >From: Richard Huber [mailto:rvh@att.com] >Sent: Monday, July 16, 2001 2:29 PM >To: internet-drafts@ietf.org; ietf-ldup@imc.org >Subject: New Requirements draft (-10) > > >Internet Drafts Editor - > >Please publish the attached draft as >draft-ietf-ldup-replica-req-10.txt > >LDUPers - > >Draft -10 is attached. It includes the three changes >recently discussed >on the list >(http://www.imc.org/ietf-ldup/mail-archive/msg01098.html) >plus a few typo fixes and changes to author contact info. > >As previously noted, since these changes handle the last >comments from >the WG last call, we propose that the document go to the IESG. > >Rick Huber > ------=_NextPart_001_001C_01C10EAA.64357A20 Content-Type: text/x-vcard; name="Chris Apple (E-mail).vcf" Content-Disposition: attachment; filename="Chris Apple (E-mail).vcf" Content-Transfer-Encoding: quoted-printable BEGIN:VCARD VERSION:2.1 N:Apple;Chris FN:Chris Apple (E-mail) ORG:UMI TITLE:Program Manager TEL;WORK;VOICE:(610) 425-2860 TEL;HOME;VOICE:(215) 873-0850 TEL;CELL;VOICE:(610) 585-4241 TEL;WORK;FAX:(610) 425-6501 ADR;WORK:;;1161 McDermott Drive;West Chester;Pa.;19380;United States of = America LABEL;WORK;ENCODING=3DQUOTED-PRINTABLE:1161 McDermott = Drive=3D0D=3D0AWest Chester, Pa. 19380=3D0D=3D0AUnited States of Amer=3D ica EMAIL;PREF;INTERNET:christopher.apple@unitedmessaging.com REV:20010621T205341Z END:VCARD ------=_NextPart_001_001C_01C10EAA.64357A20-- ------=_NextPart_000_001B_01C10EAA.64357A20 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIF1TCCAqQw ggINoAMCAQICAwT8XjANBgkqhkiG9w0BAQQFADCBkjELMAkGA1UEBhMCWkExFTATBgNVBAgTDFdl c3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3duMQ8wDQYDVQQKEwZUaGF3dGUxHTAbBgNVBAsT FENlcnRpZmljYXRlIFNlcnZpY2VzMSgwJgYDVQQDEx9QZXJzb25hbCBGcmVlbWFpbCBSU0EgMjAw MC44LjMwMB4XDTAxMDYwODE1NDgwOVoXDTAyMDYwODE1NDgwOVowVzEfMB0GA1UEAxMWVGhhd3Rl IEZyZWVtYWlsIE1lbWJlcjE0MDIGCSqGSIb3DQEJARYlY2hyaXN0b3BoZXIuYXBwbGVAdW5pdGVk bWVzc2FnaW5nLm5ldDCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEA0wb7dpXj0lZuRfGhErPC qQTyvOGL3DHONyKLfJEfbD3A/0zqEnkjKamgGiD7PVFc0Gwok9x/2Jl/mQO52ArIPO0AkSYY/KaZ mWKaFXxh1LedYLyNb5PRe1kN6y0EAva1D4nwyZmToJMBUqLNsvMGjPmLUuBwdbHLEdAAVo7Gp6kC AwEAAaNCMEAwMAYDVR0RBCkwJ4ElY2hyaXN0b3BoZXIuYXBwbGVAdW5pdGVkbWVzc2FnaW5nLm5l dDAMBgNVHRMBAf8EAjAAMA0GCSqGSIb3DQEBBAUAA4GBAIqkT3GDgyKLYOzIJ9h/OsiFbiefYTbc ALptWnwegAeXbfjhq+BUJN2ICWxfQtTCupvAG6mW4J2qI422TLc31Gf7uu5r93ppFDrCGYAM2mgH tqKgztYQmAsGPf2TijDOeE7JRbQ7dZJu4BJvuE3SY9PdI/umjiOh/WG/gaZNdl0bMIIDKTCCApKg AwIBAgIBDDANBgkqhkiG9w0BAQQFADCB0TELMAkGA1UEBhMCWkExFTATBgNVBAgTDFdlc3Rlcm4g Q2FwZTESMBAGA1UEBxMJQ2FwZSBUb3duMRowGAYDVQQKExFUaGF3dGUgQ29uc3VsdGluZzEoMCYG A1UECxMfQ2VydGlmaWNhdGlvbiBTZXJ2aWNlcyBEaXZpc2lvbjEkMCIGA1UEAxMbVGhhd3RlIFBl cnNvbmFsIEZyZWVtYWlsIENBMSswKQYJKoZIhvcNAQkBFhxwZXJzb25hbC1mcmVlbWFpbEB0aGF3 dGUuY29tMB4XDTAwMDgzMDAwMDAwMFoXDTAyMDgyOTIzNTk1OVowgZIxCzAJBgNVBAYTAlpBMRUw EwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEPMA0GA1UEChMGVGhhd3Rl MR0wGwYDVQQLExRDZXJ0aWZpY2F0ZSBTZXJ2aWNlczEoMCYGA1UEAxMfUGVyc29uYWwgRnJlZW1h aWwgUlNBIDIwMDAuOC4zMDCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEA3jMypmPHCSVFPtJu eCdngcXaiBmClw7jRCmKYzUqbXA8+tyu9+50bzC8M5B/+TRxoKNtmPHDT6Jl2w36S/HW3WGl+YXN VZo1Gp2Sdagnrthy+boC9tewkd4c6avgGAOofENCUFGHgzzwObSbVIoTh/+zm51JZgAtCYnslGvp oWkCAwEAAaNOMEwwKQYDVR0RBCIwIKQeMBwxGjAYBgNVBAMTEVByaXZhdGVMYWJlbDEtMjk3MBIG A1UdEwEB/wQIMAYBAf8CAQAwCwYDVR0PBAQDAgEGMA0GCSqGSIb3DQEBBAUAA4GBAHMbbyZli/8V NEtZYortRL5Jx+gNu4+5DWomKmKEH7iHY3QcbbfPGlORS+HN5jjZ7VD0Omw0kqzmkpxuwSMBwgmn 70uuct0GZ/VQby5YuLYLwVBXtewc1+8XttWIm7eiiBrtOVs5fTT8tpYYJU1q9J3Fw5EvqZa4BTxS /N3pYgNIMYICqjCCAqYCAQEwgZowgZIxCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENh cGUxEjAQBgNVBAcTCUNhcGUgVG93bjEPMA0GA1UEChMGVGhhd3RlMR0wGwYDVQQLExRDZXJ0aWZp Y2F0ZSBTZXJ2aWNlczEoMCYGA1UEAxMfUGVyc29uYWwgRnJlZW1haWwgUlNBIDIwMDAuOC4zMAID BPxeMAkGBSsOAwIaBQCgggFlMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkF MQ8XDTAxMDcxNzE0MjIzM1owIwYJKoZIhvcNAQkEMRYEFP+Ymt1ZW0a23gsX4iacgCmuW4vUMFgG CSqGSIb3DQEJDzFLMEkwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwICAgCAMAcGBSsOAwIHMA0GCCqG SIb3DQMCAgEoMAcGBSsOAwIaMAoGCCqGSIb3DQIFMIGrBgkrBgEEAYI3EAQxgZ0wgZowgZIxCzAJ BgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEPMA0G A1UEChMGVGhhd3RlMR0wGwYDVQQLExRDZXJ0aWZpY2F0ZSBTZXJ2aWNlczEoMCYGA1UEAxMfUGVy c29uYWwgRnJlZW1haWwgUlNBIDIwMDAuOC4zMAIDBPxeMA0GCSqGSIb3DQEBAQUABIGAuoqjPrbk cn244UrTdHrJ5PKRoo/wTCBBWlkBu/SXeyokXehXnAkw00D4Fg9c/YDVuwkDrTau4s7FqlOoR2lO Xk72+7xbbAv1LAEEWo+HKLBqbF3Xh15anRJv+YeSGuEOw9sHMb8zAdM3LBjnFeO7FATZbdaGsiPE O4Z2qzjkwp4AAAAAAAA= ------=_NextPart_000_001B_01C10EAA.64357A20-- From owner-ietf-ldup@mail.imc.org Wed Jul 18 18:14:17 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA18349 for ; Wed, 18 Jul 2001 18:14:15 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.3/8.11.3) id f6ILn5R16666 for ietf-ldup-bks; Wed, 18 Jul 2001 14:49:05 -0700 (PDT) Received: from almso1.proxy.att.com (almso1.att.com [192.128.167.69]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f6ILn3q16657 for ; Wed, 18 Jul 2001 14:49:03 -0700 (PDT) Received: from qsun.mt.att.com ([135.16.31.2]) by almso1.proxy.att.com (AT&T IPNS/MSO-3.0) with SMTP id f6ILmSp11056; Wed, 18 Jul 2001 17:48:29 -0400 (EDT) Received: by qsun.mt.att.com (SMI-8.6/ATTEMS-1.4.1 sol2) id RAA03894; Wed, 18 Jul 2001 17:48:27 -0400 Date: Wed, 18 Jul 2001 17:48:27 -0400 Message-Id: <200107182148.RAA03894@qsun.mt.att.com> From: rvh@qsun.mt.att.com (Richard V Huber) To: internet-drafts@ietf.org Subject: Revised "Profile" draft Cc: ietf-ldup@imc.org Sender: owner-ietf-ldup@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Internet Drafts Editor - Please publish the ID below as draft-ietf-ldup-usage-profile-01.txt. LDUPers - The draft below is an updated version of the General Usage Profile. We did a general editing pass and updated some sections heavily. In addition, all the material in Section 6 is new since draft -00. There will be future revisions, since some of the work we are referencing is not yet complete. Please send comments to the list. Rick Huber, et al --- --- --- --- --- --- --- --- --- --- --- --- Internet-Draft Richard V. Huber LDAP Duplication/Replication/Update Gerald F. Maziarski Protocols WG AT&T Laboratories Intended Category: Informational Ryan D. Moats Expires: January 2002 Lemur Networks July 2001 General Usage Profile for LDAPv3 Replication draft-ietf-ldup-usage-profile-01.txt Status of This Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/lid-abstracts.txt. The list of Internet-Drafts Shadow Directories can be accessed at http://www.ietf.org/shadow.html. Copyright Notice Copyright (C) The Internet Society (2001). All Rights Reserved. Abstract Support for replication in LDAP directory systems is often one of the key factors in the decision to deploy them. But replication brings design constraints along with its benefits. We discuss some of the factors that should be taken into consideration when designing a replicated directory system. Both programming and architectural/operational concerns are addressed. Huber, et al Expires January 2002 [Page 1] Internet-Draft Usage Profiles for LDAPv3 Replication July 2001 Table of Contents 1 Introduction.......................................................3 2 Meta-data Considerations...........................................3 2.1 Schema Considerations...........................................3 2.2 Replication Agreements..........................................4 2.3 Access Control..................................................5 2.4 Change Logs.....................................................6 3 Naming Considerations..............................................6 4 Conflict Resolution Considerations.................................7 4.1 Consistent Access after Changes.................................7 4.2 Conflict Resolution in Single-Master Systems....................8 4.3 Problem Cases...................................................8 4.4 General Principles.............................................10 5 Failover Considerations...........................................10 5.1 Common Issues..................................................10 5.2 Single Master Issues...........................................11 5.3 Multi-Master Issues............................................12 6 Other Issues......................................................12 6.1 Locking........................................................12 6.2 Backup and Restore.............................................13 7 Impact of Non-LDAP Changes/Constraints............................14 7.1 Changes Outside of LDAP........................................14 7.2 Application Triggers...........................................14 7.3 Policy Conflicts Across Servers................................15 8 Security Considerations...........................................15 9 Acknowledgements..................................................16 10 References......................................................16 Authors' Addresses..................................................16 Full Copyright Statement............................................17 Huber, et al Expires January 2002 [Page 2] Internet-Draft Usage Profiles for LDAPv3 Replication July 2001 1 Introduction As LDAP directories become part of critical infrastructure in many applications, the need for extremely high reliability and availability becomes significant. And as directories are more widely used, the load on individual directory servers gets higher. Distributed, replicated directories can reduce the problems of reliability and capacity. But applications that work well with a single, standalone directory will develop problems in a distributed environment unless both the application and the environment are carefully designed. The particular areas of concern depend partly on whether the distributed directory is a single- or multi-master system, but there are many concerns that are common to both. In the remainder of the document, we have flagged some sections as being specific to single- or multi-master directories. Unflagged sections pertain to both. This document addresses general issues. There may be additional drafts in the future that address specific applications. 2 Meta-data Considerations Any LDAP directory contains meta-data as well as the user data in the directory. Examples of this meta-data include descriptions of the data in the directory (e.g. schema), policies for use of the data (e.g. access controls), and configuration/status information (e.g. replication agreements); this is not an exhaustive list. Many types of meta-data are stored in the directory itself, accessible as regular data or as operational attributes. Since meta-data can appear in the directory, issues arise when it is replicated. Different issues arise if it is not replicated. 2.1 Schema Considerations If the schema of one or more of the copies of a replica differs from the schema of the other replicas, then there exists the possibility of schema mismatch when data is exchanged between them. The extensibility feature of LDAP schema nearly guarantees that replica rings comprised of a heterogeneous mix of systems will not contain homogeneous schema because of directory vendors' built-in extensions. Because a given directory may not utilize its complete schema, not all of the potential Huber, et al Expires January 2002 [Page 3] Internet-Draft Usage Profiles for LDAPv3 Replication July 2001 schema differences in a ring will result in a schema mismatch under replication. Schema mismatch issues are further complicated by the possibility of replicating the "subschemaSubentry" itself. Some directories distribute schema changes through that mechanism. Currently there is no standard for LDAP schema representation. In the absence of such a standard, schema interoperability is not possible in the IETF sense. Designers should establish common schema on all servers holding a replica. The following is a partial example list of schema mismatches: 1. Base syntax of an attribute type 2. Structure Rule of an object class 3. Optional vs. Mandatory attribute in an object class 4. Structural vs. Auxiliary in an object class 5. Object class not defined 6. Attribute type not defined 7. Object identifiers differs on an attribute type or on an object class 8. Type and number of attributes defined in a class 9. Multi-valued vs. Single valued attribute types 10. ACL format (and consequently, ACL calculus) 11. Matching rule of an attribute type 12. Naming collisions of attribute type names 13. Attribute name aliasing ("street" vs. "streetAddress" vs. "Strasse") Schema mismatches that can cause data corruption in one or more of the replicas must result in meta-data (e.g. log entries) to comply with Requirement MM5 of [ReplicaReq]. However, not all schema differences produce corruption in all circumstances. Some schema differences may have little or no impact on the proper storage of replicated data. However, any time data is added to the directory replication may result in data corruption due to a schema mismatch. It is therefore recommended that all schema mismatches be removed from, or otherwise rationalized among, the replica-group, if possible. The tool described by requirement AM8 of [ReplicaReq] would help designers detect schema conflicts as early as possible. The other option that can be considered in this situation is the use of fractional replication to replicate only those attributes that do not have differences. 2.2 Replication Agreements Replication Agreements are central to replication, as they allow configuration of most of the aspects of the replication process, including the triggers for replica cycles (from Requirement M1 in Huber, et al Expires January 2002 [Page 4] Internet-Draft Usage Profiles for LDAPv3 Replication July 2001 [ReplicaReq]), critical OID information (from Requirement M6 in [ReplicaReq]), and replication process parameters (Requirement M7 in [ReplicaReq]). Through the use of a standard schema (Requirement SC2) it is possible to replicate the replication agreement. If a replication agreement includes replication credentials, the agreement should be read protected in the directory and transport of the replication agreement should be encrypted. Replication agreements are themselves distributed through the LDUP. They are therefore subject to same "loose consistency" problems caused by replication delay and deferred conflict resolution as other data. Even a temporary inconsistency among replication agreements may cause unbalanced replication and further inconsistency. As "multi-mastering" complicates "loose consistency" issues, avoidance of these issues by making all replication agreement changes through the same master (see Sections 4 and 5) is strongly advised. 2.3 Access Control The following considerations complicate replication of Access Control Information: - Access Control Information (ACI) is treated as though it were stored as attributes in the directory [ACModel] - LDAP [RFC2251] declares that changes resulting from a single LDAP MODIFY are atomic (but see caveats for multi-master replication in Sections 4 and 5) - The ACI affecting a given entry may not be part of that entry (it could be part of a group entry or part of an ancestor of the entry in question) - The ACI cannot always be changed atomically with associated data changes - The interaction of replication and partitioning is still unclear (i.e. what happens when access control policy is inherited from a superior partition [Inherit]). - Thus, if you aren't careful, you can leave windows where data is unprotected To reduce risk: - In all environments, access control changes should be made before adds and after deletes - In multi-master environments, access control changes and the associated data changes should be made on same system. Even when ACI is faithfully replicated (with the same transfer format) among heterogeneous members of a replica ring, there is no guarantee that an ACI change is expressed similarly everywhere in the ring. This Huber, et al Expires January 2002 [Page 5] Internet-Draft Usage Profiles for LDAPv3 Replication July 2001 caveat is partly due to the open issues with respect to partitioning mentioned above, and partly due to vendor differences with regard to the expression of security policy. 2.4 Change Logs Requirement G4 of [ReplicaReq] states that meta-data must not grow without bound. Since it is unrealistic to assume that meta-data won't be needed during replication, designers must consider how and when meta-data can be purged. Replicas that use connections with intermittent quality should use explicit replica cycle scheduling. Since the systems know when replication should have occurred, delayed replication can be detected and manual intervention initiated before the meta-data grows without bound. In extreme cases, it may be necessary to remove a replica from the replication ring and re-add them once better connectivity is available. In a multi-master system, it is possible for a consumer to receive changes that cannot be applied. For example, a modify request for an entry may arrive before the add request that creates that entry. The replication system will typically queue this change and wait for additional changes. 3 Naming Considerations A number of naming models have been proposed for directories ([RFC1255], [RFC2377], [CIMNames]), and many others have been implemented on an ad hoc basis. Each of these models specifies the naming attributes to be used and provides rules for using them. The naming scheme may also specify containment rules. The naming plan applies to the directory as a whole, not the individual servers holding replicas. In a heterogeneous replicated environment, all of the replicating servers must be capable of supporting all of the rules for the naming plan in use for that directory. Some directory implementations have naming constraints (e.g. containment rules, restrictions on attributes that can be used for naming). If such an implementation is part of a replicated directory, those constraints will have to be observed by all participating directories. If the environment contains implementations with incompatible constraints there is a major problem. This should be checked as early in the design phase as possible to avoid problems. Applications often have their own requirements on naming. If two independent applications start sharing previously separate directory Huber, et al Expires January 2002 [Page 6] Internet-Draft Usage Profiles for LDAPv3 Replication July 2001 information, care should be taken that the naming is consistent across the applications. A difference in name form may be accepted through LDUP without constraint violation, but nevertheless result in unexpected behavior from a cross-application perspective. Consistent naming is not only important to the directory, but to the applications that consume directory information as well. Shared application access often mandates shared naming in the directory. 4 Conflict Resolution Considerations 4.1 Consistent Access after Changes Many operations on a directory are done as a set of steps. For example, a new object may be created by one operation, and its values may be filled in as part of a separate LDAP operation. An administrator may add a user to a directory, and that user may then try to log in using the new entry. Replicated LDAP directories provide loose consistency [ReplicaReq]. A new entry or a change to an existing entry will not reach all replicas immediately; there will be some delay before changes are available on all replicas. Changes made (e.g. adding a new user) on one physical system may appear to be "lost" if checked on another physical system before replication is complete. In general, LDAP applications should be prepared to operate correctly in the face of replication delays. In some cases, this means designing to allow for delay. In the case of the newly created user, it should be standard practice to ask the user to wait a while before trying to use the entry. In the case where the new object must be filled in, the application should make appropriate use of LDAP sessions to make sure that the same server is reached for both operations. As a general rule, an LDAP application should bind once and not unbind until a complete set of related operations have been performed. To achieve load balancing of write operations in a multi-master environment, balancing the write-enabled connections is recommended over balancing LDAP write operations. In the single-master case, all write requests go to one server. If a set of related reads and writes are done, they should all be done on the master if possible. Ideally, only sets of related operations that cannot include a write should go to one of the slave servers. But load balancing concerns may make this impractical. In some cases, related requests will deal with data in different partitions that are not all available on a single server. In this case, it is safer to keep sessions open to all servers rather than Huber, et al Expires January 2002 [Page 7] Internet-Draft Usage Profiles for LDAPv3 Replication July 2001 closing the session with one server and opening one with another server. It may not always be obvious to clients that they are using different servers. If a load distribution system is used between the client and the server, the client may find that a change request and a subsequent lookup are directed to different physical servers even though the original requests were sent to the same server name and/or address. Since LDAP is session oriented, any load distribution system used should take sessions into account. Thus, keeping all related read and write requests within a single bind/unbind session should be the goal in this situation as well. 4.2 Conflict Resolution in Single-Master Systems It is possible that resolution conflicts could occur in a single master replication system. Because requirement SM2 of [ReplicaReq] is a "SHOULD" and not a "MUST", it is possible for implementers to reorder changes. If changes are reordered, it is quite possible for a conflict to occur. Consider a case where schema changes are declared critical and must be moved to the front of the replication queue. Then the consumer servers might have to delete an attribute that still has values, and later process requests to delete the values of that attribute. However, directory administrators may have scenarios where re-ordering of replication information is desirable. On a case-by-case basis, the directory administrator should make such decisions. Many vendors may not implement conflict resolution for single-master replication. If such a system receives out-of-order changes from a system that does support them, replication errors will almost certainly occur. Designers should be aware that mismatches in the capabilities of replicating single-master directories could cause problems. Designs should not permit the master to re-order changes unless all slave copies are known to handle the situation correctly. 4.3 Problem Cases 4.3.1 Atomicity The fact that replication does not guarantee the time order arrival of changes at a consumer allows situations where changes that were applied successfully at the supplier may fail in part when an attempt is made to apply the same change at the consumer. Examples appear below. Huber, et al Expires January 2002 [Page 8] Internet-Draft Usage Profiles for LDAPv3 Replication July 2001 4.3.1.1 Locking There is an entry with distinguished name DN that contains attributes X, Y, and Z. The value of X is 1. On replica A, a ModifyRequest is processed which includes modifications to change that value of X from 1 to 0 and to set the value of Y to "USER1". At the same time, replica B process a ModifyRequest which includes modifications to change the value of X from 1 to 0 and to set the value of Y to "USER2" and the value of Z to 42. The application in this case is using X as a lock and is depending on the atomic nature of ModifyRequests to provide mutual exclusion for lock access. In the single-server case, the two operations would have occurred sequentially. Since a ModifyRequest is atomic, the entire first operation would succeed. The second ModifyRequest would fail, since the value of X would be 0 when it was attempted, and the modification changing X from 1 to 0 would thus fail. The atomicity rule would cause all other modifications in the ModifyRequest to fail as well. In the multi-master case, it is inevitable that at least some of the changes will be reversed despite the use of the lock. Assuming the changes from A have priority per the conflict resolution algorithm, the value of X should be 0 and the value of Y should be "USER1" The interesting question is the value of Z at the end of the replication cycle. If it is 42, the atomicity constraint on the change from B has been violated. But for it to revert to its previous value, grouping information must be retained and it is not clear when that information can be safely discarded. Thus, requirement G6 in [ReplicaReq] may be violated. The utility of locking mechanisms cannot be guaranteed with multi- master replication, and therefore results are likely to be misleading. As discussed further in section 6.1 below, its use in multi-master environments should be deprecated. 4.3.1.2 Partitioning Partitioning also adds complexity. For example, suppose two servers, A and B, are members of Replica-ring X while servers B and C are members of replica-ring Y. It is possible to issue a ModifyRDN operation on server B that moves an entry from ring X to ring Y. Replication in ring X would delete the entry on server A while replication in ring Y would add the entry to server C. However, if another change on server C prevented the add operation from working (e.g. an RDN of a different GUID exists there already), then the change on server A is inconsistent and will need to be reversed. Other examples of cases of this class include group membership modification and access control scoping. Huber, et al Expires January 2002 [Page 9] Internet-Draft Usage Profiles for LDAPv3 Replication July 2001 4.4 General Principles The examples above discuss some of the most difficult problems that can arise in multi-master replication. Dealing with them is difficult and can lead to situations that are quite confusing to the application and to users. The common characteristics of the examples are: - Several directory users/applications are changing the same data - They are changing the data at the same time - They are using different directory servers to make these changes - They are changing data that are parts of a distinguished name or they are using ModifyRequest to both read and write a given attribute value in a single atomic request If any one of these conditions is reversed, the types of problems described above will not occur. There are many useful applications of multi-master directories where at least one of the above conditions does not occur. For cases where all four do occur, application designers should be aware of the possible consequences. 5 Failover Considerations One of the major reasons to use directory replication is to improve reliability of the directory system as a whole. Replication permits hot- and warm-standby configurations to be built easily. But there are some issues that must be considered during design. In this situation, single-master systems actually raise more concerns than multi-master. Both are addressed below. 5.1 Common Issues In both the single- and multi-master cases, clients must be able to find an alternate quickly when a server fails. Some possible ways to do this are detailed in [FindingLDAP] and [LDAPinDNS]. If all else fails, a list of possible servers can be built into client applications. Designers should consider how clients are notified that the server is again available. When the failed server comes back up, it is brought back into synchronization with the other servers and is ready to take requests. It is always possible that the failed server, if it was acting as a supplier, was unable to completely distribute its pending changes before removal from service, leaving its consumers in an inconsistent state. During the period between its removal from service and its eventual return, the inconsistency may have been compounded by further Huber, et al Expires January 2002 [Page 10] Internet-Draft Usage Profiles for LDAPv3 Replication July 2001 application activity. As there is no current automatic mechanism to rectify the problem, the administrator should use whatever mechanism is available to compare the replicas for consistency as soon after the event as is reasonable. Note that the process used to bring a failed server back into replication can also be used to add a server to a set of replicating servers. In this case, the new server might be initialized from a backed-up copy of the directory or it may acquire the entire DIB via replication. The former method is usually preferable when the directory is large. 5.2 Single Master Issues In a single-master system, the master is a single point of failure, as all modification has to originate at the master server. When high availability is a requirement, a quick, automated failover process for converting a slave replica to a new master is desirable, as the failover time becomes a major factor in determining system availability. The considerations in section 5.1 apply here; clients must know how to find the new master or a new slave in case of failure. To aid in promotion of a slave replica, the master could replicate control information and meta-data (including replication credentials) so that this information is available during failover promotion. This data may either be replicated on a single "failover designate" slave (which would become the master in during failover) or it could be replicated to all slaves. The first possibility has the advantage of minimizing the amount of extra replication while the second more robustly handles multiple failovers (i.e. failover of the newly promoted master to another slave before the original master has been restored). If this method is followed, data privacy mechanisms should be used to protect the replication session. If data privacy mechanisms (e.g. encryption) are used to protect the replication session, the new master must have the necessary key information. Further this key information should be independent of the master that is using it (i.e. not tied to the IP address of the master server). If it is not independent, slave replicas could be pre- configured with the keys for all possible masters to reduce failover time. Restoration of the failed or broken master can be handled in one of two ways: - It could join the ring and function as a slave. - It could join the ring and negotiate with the new master to synchronize and then take over as master. Huber, et al Expires January 2002 [Page 11] Internet-Draft Usage Profiles for LDAPv3 Replication July 2001 In either case, clients need a way to know that a new server is available. If the broken master is returned to service as a slave, then the administrator must, external to LDUP, distribute and resolve whatever pending changes remained undistributed and unresolved from the time immediately before it was removed from service. If the broken master is returned as a new master, then care must be taken with its replacement master to ensure that all of its pending changes are distributed and resolved before it is returned to duty as a slave. The slave replicas may also use the replication agreement to filter which master is allowed to submit changes. Such a model allows the slave servers to function correctly when the master server is "broken" and sending out incorrect updates. However, then it is necessary to update the replication agreement during the fail over process so that the slaves will accept updates from the new master. This is the case for both the original failure and the restoration of the restored master if that is how the restored master rejoins the replica ring. 5.3 Multi-Master Issues Typically, a multi-master configuration is used when high availability is required for writes as well as reads in the directory. Because there are multiple active servers prepared to take write requests, there is no "switchover" time in this case. But clients still need to be able to find an alternate server, so the considerations of Section 5.1 apply here. 6 Other Issues 6.1 Locking Section 4.3.1.1 discussed the problems that can arise when the "modify" command in LDAP is used for locking in a multi-master environment. There are more general principles at work there. LDAP is a distributed and replicated directory service that is typically described as "loosely consistent". In loose consistency, the data should eventually converge among the replicas, but at any given instant, replicas may be in disagreement. This stipulation is the general result of: 1. the delay due to replication or extended replication intervals 2. the out of natural time order arrival of data at a replica 3. the temporary isolation of distributed systems from one another Huber, et al Expires January 2002 [Page 12] Internet-Draft Usage Profiles for LDAPv3 Replication July 2001 4. failure to accept a change due to conflict resolution failure on a replica Because of loose consistency, data preconditions to an LDAP operation may differ among replicas. Multi-mastering may exacerbate this situation, but single-mastering will not totally eliminate it if out- of-order replication is allowed (see Section 4.2). One must carefully assess the effect of loose consistency when evaluating operations that place specific preconditions on data to work correctly. Applications which depend on such operations may be better suited for transactional models and/or non-distributed data. Distributed locking is one operation that depends on strict data preconditions. When data preconditions cannot be guaranteed, the lock is moot. The same principles hold for "atomic operations", defined here as any mix of allowable operations contained within the same LDAP PDU. RFC2251 requires that they either all fail or are applied as a unit. If strict data preconditions cannot be guaranteed, then the atomic operation may itself result in a further inconsistency requiring human intervention at one of the consumers. 6.2 Backup and Restore Backup of a directory server should have the following goals: (1) It can be unambiguously and faithfully restored. (2) It is an internally consistent snapshot of an entire replica during the time interval it took to make it. This can only be achieved if the server is quiescent. (3) Replication can resume on a machine restored from that backup without information loss. Backup and restore of a single, operating directory server (rather than the entire directory system) presents its own challenges. "Loose consistency" works against the probability of achieving a loss-free copy of all the data in the directory, except under ideal conditions. Backup and restore of distributed directories is a decidedly easier task when the constraint of continuous availability is removed. In most cases, the removal of entire directory systems from write service is impossible, even for small periods of time. It is more practical to remove a single directory server from service to achieve a condition of quiescence. Once the write load on a server is removed, albeit from replication or an application, an internally consistent copy of the data may be obtained. Replicas that have suffered catastrophic data loss may be restored from backups of working servers temporarily removed from service Huber, et al Expires January 2002 [Page 13] Internet-Draft Usage Profiles for LDAPv3 Replication July 2001 specifically to make a copy. This scenario illustrates the benefit of having three or more replicas in the system: no single point of write failure in the event that one of the replicas must be restored from a copy of another. The M11 requirement from [ReplicaReq] allows an empty replica to be brought up to date through replication. This feature duplicates, but does not make entirely unnecessary, backup procedures on directory servers. Backups are still needed to recover data that has been lost to all replicas, either through normal LDAP updates or through some catastrophic event. 7 Impact of Non-LDAP Changes/Constraints 7.1 Changes Outside of LDAP LDAP directories are typically built on top of some database or file system. Thus there are ways to change the data that do not go through the normal LDAP change mechanisms (e.g. ModifyRequest). If the data is modified outside of LDAP, the changes will not be checked for schema conformance nor will access controls be checked as the changes are made. Since both integrity and security checks are omitted, security can be adversely affected. Also, many systems use the normal LDAP modification mechanisms to trigger replication. Changes made using non-LDAP mechanisms may not be replicated at all, leading to inconsistencies between replica copies. 7.2 Application Triggers Directory servers commonly integrate one or more specific applications. To achieve this integration the directory server may intercept updates and run application-specific "trigger" code. Such triggers enforce directory invariants that cannot be expressed by the LDAP schema. A simple trigger example is password policy enforcement. A directory server might interpret a request to replace the current value of the userPassword attribute with some new value as a request to first check that the new value conforms to the server's password policy (e.g. the value is sufficiently long and complex) before storing the new value. Using this trigger the directory server voids the security risk associated with passwords that are easy to attack. A more complex trigger example is password hashing. A directory server might interpret a request to replace the current value of the userPassword attribute with some new value as a request to compute one Huber, et al Expires January 2002 [Page 14] Internet-Draft Usage Profiles for LDAPv3 Replication July 2001 or more secure hashes of the new value and store these hashes in one or more attributes, storing no value in the userPassword attribute. Using this trigger the directory server avoids the security exposure of storing the plaintext password. Replication between directory servers with different application triggers will compromise directory integrity. 7.3 Policy Conflicts Across Servers In addition to the discussions of ACI in Section 2.3 and triggering in section 7.2, LDUP replication can not (by its definition) handle replication of information that makes use of policy not expressible in the LDAP protocol. A prime example of this is security encoding of attributes (e.g. userPassword). This encoding is typically implementation specific and is not easily expressible via the LDAP protocol. Therefore replication of userPassword attributes between directory servers that use different encoding schemes will impede replication in a way that is not describable as schema or syntax mismatch. This is because of the bind-time policy semantics that are the true point of conflict. Another case arises from the use of authentication levels in the Access Control Model [ACModel]. The authentication levels represent the strength of various forms of authentication rather than specific authentication mechanisms; the association between levels and mechanisms is left for administrators though some guidance may be provided [AuthMap]. In a replicated environment, administrators must be sure that the mappings of all replicating systems are compatible. If they are not compatible, access controls may have different effects on different replicas of a partition. In general, any attribute with semantics that are outside the scope of what is expressible by the LDAP protocol could result in strange replication errors. Therefore, distributed directory implementers should (in the absence of a way to express such semantics) either strive for a homogeneous set of servers or ensure during acceptance testing that a new server can support the existing semantics of their directory. 8 Security Considerations The document discusses issues that arise in replication. Some of these issues are security related (e.g. replication of access control information) and the security implications are discussed in the relevant sections. Huber, et al Expires January 2002 [Page 15] Internet-Draft Usage Profiles for LDAPv3 Replication July 2001 9 Acknowledgements This document owes a lot to discussions on the LDUP mailing list. In particular, the authors would like to thank Ed Reed, whose email to the mailing list drove much of section 6.1, and Mark Brown for identifying and generating text on the issues discussed in section 7. 10 References [ACModel] E. Stokes, R. Blakeley, R. Byrne, R. Huber, D. Rinkevich, "Access Control Model for LDAPv3", Internet Draft, draft-ietf-ldapext- acl-model-08.txt, June 2001. [AuthMap] K. Zeilenga, "Authentication Mechanisms Levels", Internet Draft, draft-zeilenga-auth-lvl-01.txt, April 2001. [CIMNames] Desktop Management Task Force, "Guidelines for CIM-to-LDAP Directory Mappings", DMTF Specification DSP0100, May 2000 (available online at http://www.dmtf.org/spec/DEN/DSP0100.htm). [FindingLDAP] R. Moats, R. Hedberg, "A Taxonomy of Methods for LDAP Clients Finding Servers", Internet Draft, draft-ietf-ldapext-ldap- taxonomy-05.txt, July 2001. [Inherit] E. Reed, "Policy Inheritance Mechanisms for LDAP", Internet Draft, draft-reed-ldup-inheritance-00.txt, February 2001. [LDAPinDNS] M. Armijo, L. Esibov, P. Leach, R. L. Morgan, "Discovering LDAP Services with DNS", Internet Draft, draft-ietf-ldapext-locate- 05.txt, March 2001. [ReplicaReq] E. Stokes, R. Weiser, R. Moats, R. Huber, "LDAPv3 Replication Requirements", Internet Draft, draft-ietf-ldup-replica-req- 08.txt, March 2001. [RFC1255] The North American Directory Forum, "A Naming Scheme for c=US", RFC 1255, September 1991. [RFC2251] M. Wahl, T. Howes, S. Kille, "Lightweight Directory Access Protocol", RFC 2251, December 1997. [RFC2377] A. Grimstad, R. Huber, S. Sataluri, M. Wahl, "Naming Plan for Internet Directory-Enabled Applications", RFC 2377, September 1998. Authors' Addresses Richard V. Huber Room C3-3B30 Huber, et al Expires January 2002 [Page 16] Internet-Draft Usage Profiles for LDAPv3 Replication July 2001 AT&T Laboratories 200 Laurel Avenue South Middletown, NJ 07748 USA E-Mail: rvh@att.com Telephone: +1 732 420 2632 Fax: +1 732 368 1690 Gerald F. Maziarski Room C3-3Z01 AT&T Laboratories 200 Laurel Avenue South Middletown, NJ 07748 USA E-Mail: gfm@att.com Telephone: +1 732 420 2162 Fax: +1 732 368 1690 Ryan D. Moats Lemur Networks 15621 Drexel Circle Omaha, NE 68135 USA E-Mail: rmoats@lemurnetworks.net Telephone: +1 402 894 9456 Full Copyright Statement Copyright (C) The Internet Society (2000). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING Huber, et al Expires January 2002 [Page 17] Internet-Draft Usage Profiles for LDAPv3 Replication July 2001 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Acknowledgement Funding for the RFC Editor function is currently provided by the Internet Society. Huber, et al Expires January 2002 [Page 18] From owner-ietf-ldup@mail.imc.org Thu Jul 19 01:19:55 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id BAA13913 for ; Thu, 19 Jul 2001 01:19:54 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.3/8.11.3) id f6J4vSN01297 for ietf-ldup-bks; Wed, 18 Jul 2001 21:57:28 -0700 (PDT) Received: from pretender.boolean.net (root@router.boolean.net [198.144.206.49]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f6J4vQq01293 for ; Wed, 18 Jul 2001 21:57:26 -0700 (PDT) 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 f6J4reC49102; Thu, 19 Jul 2001 04:53:48 GMT (envelope-from Kurt@OpenLDAP.org) Message-Id: <5.1.0.14.0.20010718205248.00af8be8@127.0.0.1> X-Sender: kurt@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Wed, 18 Jul 2001 21:53:02 -0700 To: "Ed Reed" From: "Kurt D. Zeilenga" Subject: Re: LDAPSubentries comments review and request for last call by LDAPEXT and LDUP working groups Cc: , In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-ldup@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: At 12:24 PM 7/16/2001, Ed Reed wrote: >So - I'd like more comments on the administrative model. Does it work for ACI as LDAPEXT is defining it? Other applications than just LDUP? I think it DOES work for LDUP (ie, managing replication areas). I don't think it works for access controls, subschema, collective attributes, and likely not for LDUP (consider sparse replica). Of course, my definition of "works" may be quite different than yours. ldapSubentry can only hold information associated with a subtree. ldapSubentry, by design, cannot hold information associated with a subtree refinement [X.501]. Consider a case where the administrator wishes to hold a set of shared attributes for the collection of entries which are immediately subordinate to a particular entry (but not the particular entry). This cannot be done using LDAPsubentries as LDAPsubentries requires that each subordinate have a separate subentry to hold the attributes. As these attributes are held in different subentries, they are not shared. And further subentries need to be created to break the inheritance (as the information was to be shared between the immediate subordinates). And, of course, needed subordinates are not automatically created/deleted upon add, delete, and rename. I believe there is good operational experience from the X.500 community that a subentry subtree refinement mechanism is needed to allow for effective administration of the Directory. I recommend we adapt X.500 subentries, including the subtree specification mechanism, for use with LDAP. Kurt From owner-ietf-ldup@mail.imc.org Thu Jul 19 10:43:08 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA13946 for ; Thu, 19 Jul 2001 10:43:08 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.3/8.11.3) id f6JEHOZ13419 for ietf-ldup-bks; Thu, 19 Jul 2001 07:17:24 -0700 (PDT) Received: from hawk.ummail.com (hawk.ummail.com [64.58.86.20]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f6JEHMq13415 for ; Thu, 19 Jul 2001 07:17:23 -0700 (PDT) Received: from ex01.ummail.com (ex01.ummail.com [216.33.108.253:25]) by hawk.ummail.com with ESMTP id Q0719-1017-306d00; Thu, 19 Jul 2001 14:17:04 GMT Received: by ex01.ummail.com with Internet Mail Service (5.5.2650.21) id <392HCW6L>; Thu, 19 Jul 2001 10:14:58 -0400 Message-ID: From: Christopher Apple To: "'ietf-ldup@imc.org'" Subject: I-D Cut-Off Reminder Date: Thu, 19 Jul 2001 10:14:54 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) MIME-Version: 1.0 Content-Type: multipart/signed; micalg=SHA1; boundary="----=_NextPart_000_001E_01C1103B.899283C0"; protocol="application/x-pkcs7-signature" X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: owner-ietf-ldup@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multi-part message in MIME format. ------=_NextPart_000_001E_01C1103B.899283C0 Content-Type: multipart/mixed; boundary="----=_NextPart_001_001F_01C1103B.899283C0" ------=_NextPart_001_001F_01C1103B.899283C0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit The Cut-Off for I-Ds for the London IETF is 1700 ET, Friday, July 20, 2001. (Hopefully the revised LCUP draft will make it into the I-D Editor by then?) Chris Apple Program Manager - Directory Services United Messaging Inc. (V) 610-425-2860 ------=_NextPart_001_001F_01C1103B.899283C0 Content-Type: text/x-vcard; name="Chris Apple (E-mail).vcf" Content-Disposition: attachment; filename="Chris Apple (E-mail).vcf" Content-Transfer-Encoding: quoted-printable BEGIN:VCARD VERSION:2.1 N:Apple;Chris FN:Chris Apple (E-mail) ORG:UMI TITLE:Program Manager TEL;WORK;VOICE:(610) 425-2860 TEL;HOME;VOICE:(215) 873-0850 TEL;CELL;VOICE:(610) 585-4241 TEL;WORK;FAX:(610) 425-6501 ADR;WORK:;;1161 McDermott Drive;West Chester;Pa.;19380;United States of = America LABEL;WORK;ENCODING=3DQUOTED-PRINTABLE:1161 McDermott = Drive=3D0D=3D0AWest Chester, Pa. 19380=3D0D=3D0AUnited States of Amer=3D ica EMAIL;PREF;INTERNET:christopher.apple@unitedmessaging.com REV:20010621T205341Z END:VCARD ------=_NextPart_001_001F_01C1103B.899283C0-- ------=_NextPart_000_001E_01C1103B.899283C0 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIF1TCCAqQw ggINoAMCAQICAwT8XjANBgkqhkiG9w0BAQQFADCBkjELMAkGA1UEBhMCWkExFTATBgNVBAgTDFdl c3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3duMQ8wDQYDVQQKEwZUaGF3dGUxHTAbBgNVBAsT FENlcnRpZmljYXRlIFNlcnZpY2VzMSgwJgYDVQQDEx9QZXJzb25hbCBGcmVlbWFpbCBSU0EgMjAw MC44LjMwMB4XDTAxMDYwODE1NDgwOVoXDTAyMDYwODE1NDgwOVowVzEfMB0GA1UEAxMWVGhhd3Rl IEZyZWVtYWlsIE1lbWJlcjE0MDIGCSqGSIb3DQEJARYlY2hyaXN0b3BoZXIuYXBwbGVAdW5pdGVk bWVzc2FnaW5nLm5ldDCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEA0wb7dpXj0lZuRfGhErPC qQTyvOGL3DHONyKLfJEfbD3A/0zqEnkjKamgGiD7PVFc0Gwok9x/2Jl/mQO52ArIPO0AkSYY/KaZ mWKaFXxh1LedYLyNb5PRe1kN6y0EAva1D4nwyZmToJMBUqLNsvMGjPmLUuBwdbHLEdAAVo7Gp6kC AwEAAaNCMEAwMAYDVR0RBCkwJ4ElY2hyaXN0b3BoZXIuYXBwbGVAdW5pdGVkbWVzc2FnaW5nLm5l dDAMBgNVHRMBAf8EAjAAMA0GCSqGSIb3DQEBBAUAA4GBAIqkT3GDgyKLYOzIJ9h/OsiFbiefYTbc ALptWnwegAeXbfjhq+BUJN2ICWxfQtTCupvAG6mW4J2qI422TLc31Gf7uu5r93ppFDrCGYAM2mgH tqKgztYQmAsGPf2TijDOeE7JRbQ7dZJu4BJvuE3SY9PdI/umjiOh/WG/gaZNdl0bMIIDKTCCApKg AwIBAgIBDDANBgkqhkiG9w0BAQQFADCB0TELMAkGA1UEBhMCWkExFTATBgNVBAgTDFdlc3Rlcm4g Q2FwZTESMBAGA1UEBxMJQ2FwZSBUb3duMRowGAYDVQQKExFUaGF3dGUgQ29uc3VsdGluZzEoMCYG A1UECxMfQ2VydGlmaWNhdGlvbiBTZXJ2aWNlcyBEaXZpc2lvbjEkMCIGA1UEAxMbVGhhd3RlIFBl cnNvbmFsIEZyZWVtYWlsIENBMSswKQYJKoZIhvcNAQkBFhxwZXJzb25hbC1mcmVlbWFpbEB0aGF3 dGUuY29tMB4XDTAwMDgzMDAwMDAwMFoXDTAyMDgyOTIzNTk1OVowgZIxCzAJBgNVBAYTAlpBMRUw EwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEPMA0GA1UEChMGVGhhd3Rl MR0wGwYDVQQLExRDZXJ0aWZpY2F0ZSBTZXJ2aWNlczEoMCYGA1UEAxMfUGVyc29uYWwgRnJlZW1h aWwgUlNBIDIwMDAuOC4zMDCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEA3jMypmPHCSVFPtJu eCdngcXaiBmClw7jRCmKYzUqbXA8+tyu9+50bzC8M5B/+TRxoKNtmPHDT6Jl2w36S/HW3WGl+YXN VZo1Gp2Sdagnrthy+boC9tewkd4c6avgGAOofENCUFGHgzzwObSbVIoTh/+zm51JZgAtCYnslGvp oWkCAwEAAaNOMEwwKQYDVR0RBCIwIKQeMBwxGjAYBgNVBAMTEVByaXZhdGVMYWJlbDEtMjk3MBIG A1UdEwEB/wQIMAYBAf8CAQAwCwYDVR0PBAQDAgEGMA0GCSqGSIb3DQEBBAUAA4GBAHMbbyZli/8V NEtZYortRL5Jx+gNu4+5DWomKmKEH7iHY3QcbbfPGlORS+HN5jjZ7VD0Omw0kqzmkpxuwSMBwgmn 70uuct0GZ/VQby5YuLYLwVBXtewc1+8XttWIm7eiiBrtOVs5fTT8tpYYJU1q9J3Fw5EvqZa4BTxS /N3pYgNIMYICqjCCAqYCAQEwgZowgZIxCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENh cGUxEjAQBgNVBAcTCUNhcGUgVG93bjEPMA0GA1UEChMGVGhhd3RlMR0wGwYDVQQLExRDZXJ0aWZp Y2F0ZSBTZXJ2aWNlczEoMCYGA1UEAxMfUGVyc29uYWwgRnJlZW1haWwgUlNBIDIwMDAuOC4zMAID BPxeMAkGBSsOAwIaBQCgggFlMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkF MQ8XDTAxMDcxOTE0MTQwMVowIwYJKoZIhvcNAQkEMRYEFAligkLlk7lFBQGAWgzJUwwLTUS8MFgG CSqGSIb3DQEJDzFLMEkwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwICAgCAMAcGBSsOAwIHMA0GCCqG SIb3DQMCAgEoMAcGBSsOAwIaMAoGCCqGSIb3DQIFMIGrBgkrBgEEAYI3EAQxgZ0wgZowgZIxCzAJ BgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEPMA0G A1UEChMGVGhhd3RlMR0wGwYDVQQLExRDZXJ0aWZpY2F0ZSBTZXJ2aWNlczEoMCYGA1UEAxMfUGVy c29uYWwgRnJlZW1haWwgUlNBIDIwMDAuOC4zMAIDBPxeMA0GCSqGSIb3DQEBAQUABIGAP4833tMh 64HACQrjwJ5PduP/crN33iIocXPrFGz/Ew6lBEKc/M5nNK+XIG6sDmZbhSG3zcAi/Hv8AKA0TZWN ZMkgzRri8YsgszI3XPs6acHEIEG5Io/160p6EG9UyBf10YiMv9EtYHy378OivFp9r9LC/kwmtH3r AgmYv+8uEfYAAAAAAAA= ------=_NextPart_000_001E_01C1103B.899283C0-- From owner-ietf-ldup@mail.imc.org Thu Jul 19 10:47:20 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA14538 for ; Thu, 19 Jul 2001 10:47:20 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.3/8.11.3) id f6JEXBu14192 for ietf-ldup-bks; Thu, 19 Jul 2001 07:33:11 -0700 (PDT) Received: from hawk.ummail.com (hawk.ummail.com [216.33.108.202]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f6JEXAq14188 for ; Thu, 19 Jul 2001 07:33:10 -0700 (PDT) Received: from ex01.ummail.com (ex01.ummail.com [216.33.108.253:25]) by hawk.ummail.com with ESMTP id S0719-1033-669e00; Thu, 19 Jul 2001 14:33:05 GMT Received: by ex01.ummail.com with Internet Mail Service (5.5.2650.21) id <392HCW6R>; Thu, 19 Jul 2001 10:30:58 -0400 Message-ID: From: Christopher Apple To: "'ietf-ldup@imc.org'" Cc: "John Strassner (E-mail)" Subject: LDUP WG Agenda Date: Thu, 19 Jul 2001 10:30:54 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) MIME-Version: 1.0 Content-Type: multipart/signed; micalg=SHA1; boundary="----=_NextPart_000_0024_01C1103D.C7C6D270"; protocol="application/x-pkcs7-signature" X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: owner-ietf-ldup@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multi-part message in MIME format. ------=_NextPart_000_0024_01C1103D.C7C6D270 Content-Type: multipart/mixed; boundary="----=_NextPart_001_0025_01C1103D.C7C6D270" ------=_NextPart_001_0025_01C1103D.C7C6D270 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Here's a proposed Agenda for the LDUP WG Sessions in London. Comments are welcome as are suggestions/requests for additional agenda items. 1) LDAPv3 Replication Requirements http://www.ietf.org/internet-drafts/draft-ietf-ldup-replica-req-09.txt - passed WG Last Call -10.txt revision should be published by I-D Editor soon - will send to ADs with request for IESG Review/IETF Last Call once published by I-D Editor 2) LDUP Update Reconciliation Procedures http://www.ietf.org/internet-drafts/draft-ietf-ldup-urp-04.txt 3) LDAP Replication Architecture http://www.ietf.org/internet-drafts/draft-ietf-ldup-model-06.txt 4) LDUP Replication Information Model http://www.ietf.org/internet-drafts/draft-ietf-ldup-infomod-03.txt 5) LDAP Subentry Schema http://www.ietf.org/internet-drafts/draft-ietf-ldup-subentry-08.txt 6) General Usage Profile for LDAPv3 Replication http://www.ietf.org/internet-drafts/draft-ietf-ldup-usage-profile-00.txt -01.txt revision should be published by I-D Editor soon 7) LDAP Client Update Protocol http://www.ietf.org/internet-drafts/draft-ietf-ldup-lcup-00.txt - hope to be able to discuss -01.txt revision 8) Adding LCUP Cookie Scheme(s) to LDUP WG Charter as Deliverables? 9) LDAP Access Control Model Work 10) General Charter Review Chris Apple Program Manager - Directory Services United Messaging Inc. (V) 610-425-2860 ------=_NextPart_001_0025_01C1103D.C7C6D270 Content-Type: text/x-vcard; name="Chris Apple (E-mail).vcf" Content-Disposition: attachment; filename="Chris Apple (E-mail).vcf" Content-Transfer-Encoding: quoted-printable BEGIN:VCARD VERSION:2.1 N:Apple;Chris FN:Chris Apple (E-mail) ORG:UMI TITLE:Program Manager TEL;WORK;VOICE:(610) 425-2860 TEL;HOME;VOICE:(215) 873-0850 TEL;CELL;VOICE:(610) 585-4241 TEL;WORK;FAX:(610) 425-6501 ADR;WORK:;;1161 McDermott Drive;West Chester;Pa.;19380;United States of = America LABEL;WORK;ENCODING=3DQUOTED-PRINTABLE:1161 McDermott = Drive=3D0D=3D0AWest Chester, Pa. 19380=3D0D=3D0AUnited States of Amer=3D ica EMAIL;PREF;INTERNET:christopher.apple@unitedmessaging.com REV:20010621T205341Z END:VCARD ------=_NextPart_001_0025_01C1103D.C7C6D270-- ------=_NextPart_000_0024_01C1103D.C7C6D270 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIF1TCCAqQw ggINoAMCAQICAwT8XjANBgkqhkiG9w0BAQQFADCBkjELMAkGA1UEBhMCWkExFTATBgNVBAgTDFdl c3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3duMQ8wDQYDVQQKEwZUaGF3dGUxHTAbBgNVBAsT FENlcnRpZmljYXRlIFNlcnZpY2VzMSgwJgYDVQQDEx9QZXJzb25hbCBGcmVlbWFpbCBSU0EgMjAw MC44LjMwMB4XDTAxMDYwODE1NDgwOVoXDTAyMDYwODE1NDgwOVowVzEfMB0GA1UEAxMWVGhhd3Rl IEZyZWVtYWlsIE1lbWJlcjE0MDIGCSqGSIb3DQEJARYlY2hyaXN0b3BoZXIuYXBwbGVAdW5pdGVk bWVzc2FnaW5nLm5ldDCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEA0wb7dpXj0lZuRfGhErPC qQTyvOGL3DHONyKLfJEfbD3A/0zqEnkjKamgGiD7PVFc0Gwok9x/2Jl/mQO52ArIPO0AkSYY/KaZ mWKaFXxh1LedYLyNb5PRe1kN6y0EAva1D4nwyZmToJMBUqLNsvMGjPmLUuBwdbHLEdAAVo7Gp6kC AwEAAaNCMEAwMAYDVR0RBCkwJ4ElY2hyaXN0b3BoZXIuYXBwbGVAdW5pdGVkbWVzc2FnaW5nLm5l dDAMBgNVHRMBAf8EAjAAMA0GCSqGSIb3DQEBBAUAA4GBAIqkT3GDgyKLYOzIJ9h/OsiFbiefYTbc ALptWnwegAeXbfjhq+BUJN2ICWxfQtTCupvAG6mW4J2qI422TLc31Gf7uu5r93ppFDrCGYAM2mgH tqKgztYQmAsGPf2TijDOeE7JRbQ7dZJu4BJvuE3SY9PdI/umjiOh/WG/gaZNdl0bMIIDKTCCApKg AwIBAgIBDDANBgkqhkiG9w0BAQQFADCB0TELMAkGA1UEBhMCWkExFTATBgNVBAgTDFdlc3Rlcm4g Q2FwZTESMBAGA1UEBxMJQ2FwZSBUb3duMRowGAYDVQQKExFUaGF3dGUgQ29uc3VsdGluZzEoMCYG A1UECxMfQ2VydGlmaWNhdGlvbiBTZXJ2aWNlcyBEaXZpc2lvbjEkMCIGA1UEAxMbVGhhd3RlIFBl cnNvbmFsIEZyZWVtYWlsIENBMSswKQYJKoZIhvcNAQkBFhxwZXJzb25hbC1mcmVlbWFpbEB0aGF3 dGUuY29tMB4XDTAwMDgzMDAwMDAwMFoXDTAyMDgyOTIzNTk1OVowgZIxCzAJBgNVBAYTAlpBMRUw EwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEPMA0GA1UEChMGVGhhd3Rl MR0wGwYDVQQLExRDZXJ0aWZpY2F0ZSBTZXJ2aWNlczEoMCYGA1UEAxMfUGVyc29uYWwgRnJlZW1h aWwgUlNBIDIwMDAuOC4zMDCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEA3jMypmPHCSVFPtJu eCdngcXaiBmClw7jRCmKYzUqbXA8+tyu9+50bzC8M5B/+TRxoKNtmPHDT6Jl2w36S/HW3WGl+YXN VZo1Gp2Sdagnrthy+boC9tewkd4c6avgGAOofENCUFGHgzzwObSbVIoTh/+zm51JZgAtCYnslGvp oWkCAwEAAaNOMEwwKQYDVR0RBCIwIKQeMBwxGjAYBgNVBAMTEVByaXZhdGVMYWJlbDEtMjk3MBIG A1UdEwEB/wQIMAYBAf8CAQAwCwYDVR0PBAQDAgEGMA0GCSqGSIb3DQEBBAUAA4GBAHMbbyZli/8V NEtZYortRL5Jx+gNu4+5DWomKmKEH7iHY3QcbbfPGlORS+HN5jjZ7VD0Omw0kqzmkpxuwSMBwgmn 70uuct0GZ/VQby5YuLYLwVBXtewc1+8XttWIm7eiiBrtOVs5fTT8tpYYJU1q9J3Fw5EvqZa4BTxS /N3pYgNIMYICqjCCAqYCAQEwgZowgZIxCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENh cGUxEjAQBgNVBAcTCUNhcGUgVG93bjEPMA0GA1UEChMGVGhhd3RlMR0wGwYDVQQLExRDZXJ0aWZp Y2F0ZSBTZXJ2aWNlczEoMCYGA1UEAxMfUGVyc29uYWwgRnJlZW1haWwgUlNBIDIwMDAuOC4zMAID BPxeMAkGBSsOAwIaBQCgggFlMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkF MQ8XDTAxMDcxOTE0MzAwN1owIwYJKoZIhvcNAQkEMRYEFEt5lolVqBF4KL/P9b9KJqTmhzYqMFgG CSqGSIb3DQEJDzFLMEkwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwICAgCAMAcGBSsOAwIHMA0GCCqG SIb3DQMCAgEoMAcGBSsOAwIaMAoGCCqGSIb3DQIFMIGrBgkrBgEEAYI3EAQxgZ0wgZowgZIxCzAJ BgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEPMA0G A1UEChMGVGhhd3RlMR0wGwYDVQQLExRDZXJ0aWZpY2F0ZSBTZXJ2aWNlczEoMCYGA1UEAxMfUGVy c29uYWwgRnJlZW1haWwgUlNBIDIwMDAuOC4zMAIDBPxeMA0GCSqGSIb3DQEBAQUABIGAJgqpVW5J 2n/OcHmWMavGK6x1UYaUed3dw/cNB399QDsZqJAJguzhXL7Bt7ZjQuBf9EW2zvgOhdL3aqFA7LRF 5TXae5bPteYaoohyZhw4AXQes4tlPnmUbg3dVjVtpuxXRqrunegC4Wwek85ioP8N5/tjNT2XSXea 95h66eRPzcAAAAAAAAA= ------=_NextPart_000_0024_01C1103D.C7C6D270-- From owner-ietf-ldup@mail.imc.org Thu Jul 19 11:40:37 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA26871 for ; Thu, 19 Jul 2001 11:40:35 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.3/8.11.3) id f6JF4UJ17628 for ietf-ldup-bks; Thu, 19 Jul 2001 08:04:30 -0700 (PDT) Received: from netscape.com (r2d2.netscape.com [205.217.237.47]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f6JF4Sq17623 for ; Thu, 19 Jul 2001 08:04:28 -0700 (PDT) Received: from dredd.mcom.com (dredd.mcom.com [205.217.237.54]) by netscape.com (8.10.0/8.10.0) with ESMTP id f6JF4NB18773 for ; Thu, 19 Jul 2001 08:04:24 -0700 (PDT) Received: from netscape.com ([205.217.229.61]) by dredd.mcom.com (Netscape Messaging Server 4.15) with ESMTP id GGQ77000.UYF; Thu, 19 Jul 2001 08:04:12 -0700 Message-ID: <3B56F665.DBEC8946@netscape.com> Date: Thu, 19 Jul 2001 09:01:57 -0600 From: richm@netscape.com (Rich Megginson) Reply-To: richm@iplanet.com Organization: iPlanet - Directory Server X-Mailer: Mozilla 4.76 [en] (WinNT; U) X-Accept-Language: en,pdf MIME-Version: 1.0 To: Christopher Apple CC: ietf-ldup@imc.org, ietf-lcup@netscape.com Subject: Re: I-D Cut-Off Reminder References: Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------msE72D006B89CA7586B2F63700" Sender: owner-ietf-ldup@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a cryptographically signed message in MIME format. --------------msE72D006B89CA7586B2F63700 Content-Type: multipart/mixed; boundary="------------D1C6F7D719B62D11794CDFA5" This is a multi-part message in MIME format. --------------D1C6F7D719B62D11794CDFA5 Content-Type: multipart/alternative; boundary="------------950DA76BB69CFC127DC04BEA" --------------950DA76BB69CFC127DC04BEA Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit I will CC: the WG in the future. Attached is lcup-01 for your perusal. It should show up in the I-D repository any time now. Christopher Apple wrote: > Thanks. Its generally a good idea to Cc: the WG mailing list on these requestsso that the WG can start discussing the document > even before its published. > Can you send to the LDUP list and indicate that you've received the auto response > from the I-D Submission Manager?Chris Apple > Program Manager - Directory Services > United Messaging Inc. > > > (V) 610-425-2860 > > -----Original Message----- > From: richm@netscape.com [mailto:richm@netscape.com] > Sent: Thursday, July 19, 2001 10:35 AM > To: Christopher Apple > Subject: Re: I-D Cut-Off Reminder > > I submitted lcup-01 on Monday. Here is the confirmation I received. I just did a search of the I-D repository and > it's not there yet. > > > Subject: Re: draft-ietf-ldup-lcup-01.txt > > Date: Mon, 16 Jul 2001 16:37:29 -0400 (EDT) > > From: ietfauto@ietf.org (Internet Draft Submission Manager) > > > > Hello, > > > > This message is being sent to acknowledge receipt of your > > submission (or message) to internet-drafts@ietf.org > > > > Please note: if you submitted a completely new document (-00), > > it will NOT be processed or announced. You must resubmit > > after the London IETF meeting. > > > > If you attempt to update an initial document received between > > July 9-13, it will NOT be processed or announced. You must > > resubmit after the London IETF meeting. > > > > AS you may surmise, this is an extremly busy week. Be advised > > that it may take a number of days to process and announce your > > document. Our goal is to process and announce all valid > > Internet-Draft submissions by July 28, 2001 at the latest. > > > > We appreciate your understanding and patience. > > > > Internet-Drafts Administrator > > > Christopher Apple wrote: > > > The Cut-Off for I-Ds for the London IETF is 1700 ET, Friday, July 20, > > 2001. > > > > (Hopefully the revised LCUP draft will make it into the I-D Editor by > > then?) > > > > Chris Apple > > Program Manager - Directory Services > > United Messaging Inc. > > > > > > (V) 610-425-2860 > --------------950DA76BB69CFC127DC04BEA Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit I will CC: the WG in the future.

Attached is lcup-01 for your perusal.  It should show up in the I-D repository any time now.

Christopher Apple wrote:

Thanks. Its generally a good idea to Cc: the WG mailing list on these requestsso that the WG can start discussing the document even before its published.
 Can you send to the LDUP list and indicate that you've received the auto response
from the I-D Submission Manager?Chris Apple
Program Manager - Directory Services
United Messaging Inc.
<http://www.unitedmessaging.com>
<mailto:christopher.apple@unitedmessaging.com>
(V) 610-425-2860
-----Original Message-----
From: richm@netscape.com [mailto:richm@netscape.com]
Sent: Thursday, July 19, 2001 10:35 AM
To: Christopher Apple
Subject: Re: I-D Cut-Off Reminder
 
I submitted lcup-01 on Monday.  Here is the confirmation I received.  I just did a search of the I-D repository and it's not there yet. 
Subject: Re: draft-ietf-ldup-lcup-01.txt
Date:    Mon, 16 Jul 2001 16:37:29 -0400 (EDT)
From:    ietfauto@ietf.org (Internet Draft Submission Manager)
Hello,

This message is being sent to acknowledge receipt of your
submission (or message) to internet-drafts@ietf.org

Please note: if you submitted a completely new document (-00),
it  will NOT be processed or announced. You must resubmit
after the London IETF meeting.

If you attempt to update an initial document received between
July 9-13, it will NOT be processed or announced. You must
resubmit after the London IETF meeting.

AS you may surmise, this is an extremly busy week. Be advised
that it may take a number of days to process and announce your
document. Our goal is to process and announce all valid 
Internet-Draft submissions by July 28, 2001 at the latest.

We appreciate your understanding and patience.

Internet-Drafts Administrator
Christopher Apple wrote:
The Cut-Off for I-Ds for the London IETF is 1700 ET, Friday, July 20,
2001.

(Hopefully the revised LCUP draft will make it into the I-D Editor by
then?)

Chris Apple
Program Manager - Directory Services
United Messaging Inc.
<http://www.unitedmessaging.com>
<mailto:christopher.apple@unitedmessaging.com>
(V) 610-425-2860

--------------950DA76BB69CFC127DC04BEA-- --------------D1C6F7D719B62D11794CDFA5 Content-Type: text/plain; charset=us-ascii; name="draft-ietf-ldup-lcup-01.txt" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="draft-ietf-ldup-lcup-01.txt" Content-Transfer-Encoding: 7bit Internet Draft R. Megginson, Editor Document: M. Smith Category: Proposed Standard Netscape Communications Corp. O. Natkovich eTime Capital J. Parham Microsoft Corporation June 2001 LDAP Client Update Protocol Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026 [1]. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet- Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet- Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. 1. Abstract This document defines the LDAP Client Update Protocol (LCUP). The protocol is intended to allow an LDAP client to synchronize with the content of a directory information tree (DIT) stored by an LDAP server and to be notified about the changes to that content. 2. Conventions used in this document In the protocol flow definition, the notation C->S and S->C specifies the direction of the data flow from the client to the server and from the server to the client respectively. The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC-2119 [KEYWORDS]. 3. Overview The LCUP protocol is intended to allow LDAP clients to synchronize with the content stored by LDAP servers. The problem areas addressed by the protocol include: - mobile clients that maintain a local read-only copy of the directory data. While off-line, the client uses the local copy of the data. When the client connects to the network, it synchronizes with the current directory content and can be optionally notified about the changes that occur while it is on- line. For example, a mail client can maintain a local copy of the corporate address book that it synchronizes with the master copy whenever the client gets connected to the corporate network. - applications intending to synchronize heterogeneous data stores. A meta directory application, for instance, would periodically retrieve a list of modified entries from the directory, construct the changes and apply them to a foreign data store. - clients that need to take certain actions when a directory entry is modified. For instance, an electronic mail repository may want to perform a "create mailbox" task when a new person entry is added to an LDAP directory and a "delete mailbox" task when a person entry is removed. The problem areas not being considered: - directory server to directory server synchronization. The replication protocol that is being defined by the LDUP IETF working group should be used for this purpose. Several features of the protocol distinguish it from LDUP replication. First, the server does not maintain any state information on behalf of its clients. The clients are responsible for storing the information about how up to date they are with respect to the server's content. Second, no predefined agreements exist between the clients and the servers. The client decides when and from where to retrieve the changes. Finally, the server never pushes the data to the client; the client always initiates the update session during which it pulls the changes from the server. The set of clients that are allowed to synchronize with an LDAP server is determined by the server defined policy. There are currently several protocols in use for LDAP client server synchronization. While each protocol addresses the needs of a particular group of clients (e.g., on-line clients or off-line clients) none satisfies the requirements of all clients in the target group. For instance, a mobile client that was off-line and wants to become up to date with the server and stay up to date while connected can't be easily supported by any of the existing protocols. Megginson, et. al. Proposed Standard - Expires: November 2001 2 A server can define a naming context or some part thereof to participate in LCUP. This document will refer to this as an LCUP Context. For example, LDUP defines a replica, a part of the DIT which may participate in replication. The LCUP context may be coincident with the replicated area, depending on the server's implementation. It is assumed that most server implementations of LCUP will make use of the server's underlying replication mechanism, but this does not have to be LDUP compliant. 4. Protocol Specification This section describes the protocol elements and the protocol flow. 4.1 Unique Identifiers Distinguished names can change, so are therefore unreliable as identifiers. A Unique Identifier must therefore be assigned to each entry as it is created. This identifier will be stored as an operational attribute of the entry, named `entryUUID'. The entryUUID attribute is single valued. A consistent algorithm for generating such unique identifiers may be standardized at some point in the future. The definition of the entryUUID attribute type, written using the BNF form of AttributeDescription described in RFC 2252 [RFC2252] is: ( OID-To-Be-Specified NAME `entryUUID' DESC `unique entry identifier' EQUALITY caseIgnoreMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 SINGLE-VALUE NO-USER-MODIFICATION USAGE directoryOperation ) 4.2 LCUP Cookie Value The LCUP protocol uses a cookie to hold the state of the client's data with respect to the server's data. This value is the bytes of the BER encoding of the following: lcupCookie ::= SEQUENCE { scheme LDAPOID, value OCTET STRING OPTIONAL } scheme - this is the OID which identifies the format of the value. The scheme OID, like all object identifiers, MUST be unique for a given cookie scheme. The cookie value may be opaque or it may be exposed to LCUP clients. For cookie schemes that expose their value, the preferred form of documentation is an RFC. It is expected that there will be one or more standards track cookie schemes where the value format is exposed and described in detail. Megginson, et. al. Proposed Standard - Expires: November 2001 3 value - this is the actual data describing the state of the client's data. This value may be opaque, or its value may have some well known format, depending on the scheme. The cookie value MUST be included except when a client has no stored state; i.e., when the client is requesting a full synchronization. When the server sends back a cookie, the cookie value MUST be present. Further uses of the LCUP Cookie value are described below. 4.3 LCUP Cookie Schemes Operational Attribute The OIDs of the supported LCUP cookie schemes SHOULD be published using the following operational attribute: ( OID-TBD NAME 'lcupCookieScheme' EQUALITY objectIdentifierMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.38 NO-USER-MODIFICATION USAGE directoryOperation ) The lcupCookieScheme operational attribute SHOULD be present in every directory entry that may be used as the baseObject for a search request that contains an LCUP clientUpdate control. If a client wants to determine what LCUP cookie schemes are supported, it SHOULD use a base object search to read the lcupCookieScheme attribute from the entry that will be used as the baseObject in subsequent LCUP sessions. Clients SHOULD NOT search for entries that contain lcupCookieScheme values; rather, it is RECOMMENDED that servers support LCUP sessions based at as many different entries as possible. 4.4 Client Update Control Value A client initiates a synchronization session with a server by attaching a clientUpdate control to a search operation. The search specification determines the part of the directory information tree (DIT) the client wishes to synchronize with, the set of attributes it is interested in and the amount of data the client is willing to receive. The clientUpdate control contains the client's synchronization specification. The controlType field for the clientUpdate control is ClientUpdateControlOID (to be assigned). The controlValue is an OCTET STRING, whose contents are the bytes of the BER encoding of the following: ClientUpdateControlValue ::= SEQUENCE { updateType ENUMERATED { synchronizeOnly (0), synchronizeAndPersist (1), persistOnly (2) }, cookie lcupCookie OPTIONAL } updateType - specifies the type of update requested by the client Megginson, et. al. Proposed Standard - Expires: November 2001 4 synchronizeOnly - the server sends all the data needed to synchronize the client with the server, then closes the connection synchronizeAndPersist - the server sends all the data needed to synchronize the client with the server, then leaves open the connection, sending to the client any new added, modified, or deleted entries which satisfy the search criteria. persistOnly - the server does not synchronize the data with the client but leaves open the connection and sends over any new added, modified, or deleted entries which satisfy the search criteria. cookie - a value that represents the current state of the client's data. If a cookie is provided, the server MUST use the enclosed scheme throughout the duration of the LCUP session or until an LCUP context boundary is crossed, since a new cookie may be required in that case. If the value or scheme part of the cookie is invalid, the server MUST return immediately with a SearchResultDone message with the clientUpdateDone control attached with the reason set to the value of lcupInvalidCookie (see below). Also, the LDAP result code MUST be unwillingToPerform. If the scheme part of the cookie is a valid OID, but is not supported, the server MUST return immediately with a SearchResultDone message with the clientUpdateDone control attached with the reason set to the value of lcupUnsupportedScheme (see below). Also, the LDAP result code MUST be unwillingToPerform. If the cookie is omitted, the server MAY use any scheme it supports. 4.5 Entry Update Control Value In response to the client's synchronization request, the server returns one or more SearchResultEntry PDU that fits the client's specification. Each SearchResultEntry PDU also contains an entryUpdateControl which describes the LCUP state of the returned entry. To represent a deleted entry, the server attaches an entryUpdate control to the corresponding SearchResultEntry. The SearchResultEntry corresponding to a deleted entry MUST contain a valid DN and a valid Unique Identifier but, to reduce the amount of data sent to the client, it SHOULD not contain any other attributes. Distinguished names can change, so are therefore unreliable as identifiers. A Unique Identifier MUST therefore be assigned to each entry as it is created. The Unique Identifier allows the client to uniquely identify entries even in the presence of modrdn operations. The Unique Identifier is carried in the entryUUID attribute. Furthermore, the server may elect to periodically return to the client the cookie that represents the state of the client's data. This information is useful in case the client crashes or gets Megginson, et. al. Proposed Standard - Expires: November 2001 5 disconnected. The cookie is also provided in the entryUpdate control. The controlType field for the entryUpdate control is EntryUpdateControlOID (to be assigned). The controlValue is an OCTET STRING, whose contents are the bytes of the BER encoding of the following: EntryUpdateControlValue ::= SEQUENCE { stateUpdate BOOLEAN, entryDeleted BOOLEAN, cookie lcupCookie OPTIONAL } stateUpdate - if set to TRUE, indicates that the entry to which the control is attached contains no changes and it is sent only to communicate to the client the new cookie. In this case, the entryDeleted field MUST be ignored and the cookie field MUST contain the updated cookie. This feature allows updating the client's cookie when there are no changes that effect the client's data store. Note that the control MUST be attached to a valid SearchResultEntry, i.e. the entry should contain a valid dn. The server MAY send the entry at the root of the client's tree. entryDeleted - if set to TRUE, indicates that the entry to which the control is attached was deleted. The server MAY also set this to TRUE if the entry has left the client's search result set. As far as the client is concerned, a deleted entry is no different than an entry which has left the result set. cookie - the LCUP cookie value that represents the current state of the client's data. 4.6 Client Update Done Control Value When the server has finished processing the client's request, it attaches a clientUpdateDone control to the SearchResultDone message and sends it to the client. The controlType field for the clientUpdateDone control is ClientUpdateDoneControlOID (to be assigned). The controlValue is an OCTET STRING, whose contents are the bytes of the BER encoding of the following: ClientUpdateDoneControlValue ::= SEQUENCE { reason INTEGER, reasonText LDAPString, cookie lcupCookie } reason - reason for terminating the operation. Currently supported values are lcupSuccess (0) the operation was successfully processed lcupResourcesExhausted (1) the server is running out of resource Megginson, et. al. Proposed Standard - Expires: November 2001 6 lcupSecurityViolation (2) the client is suspected of malicious actions lcupInvalidCookie (3) invalid cookie was supplied by the client - both/either the scheme and/or the value part was invalid lcupUnsupportedScheme (4) The scheme part of the cookie is a valid OID but is not supported by this server lcupClientDisconnect (5) client requested search termination lcupReloadRequired (6) indicates that client data needs to be reinitialized. This reason is returned if the server does not contain sufficient information to synchronize the client or that the server's data was reloaded since the last synchronization session reasonText - The reasonText field of this construct may, at the server's option, be used to return a string containing a textual, human-readable (terminal control and page formatting characters should be avoided) error diagnostic. As this error diagnostic is not standardized, implementations MUST NOT rely on the values returned. If the server chooses not to return a textual diagnostic, the reasonText field of the ClientUpdateDoneControlValue MUST contain a zero length string. The character set for reasonText SHOULD be US-ASCII. cookie - the LCUP cookie value that represents the current state of the client's data. Although this value is OPTIONAL in other control values, it MUST be set in the ClientUpdateDoneControlValue. This provides a good "checksum" of what the server thinks the state of the client is. 4.7 Stop Client Update Request and Response The Stop Client Update operation is an LDAPv3 Extended Operation [RFC2251, Section 4.12] and is identified by the OBJECT IDENTIFIER stopClientUpdateOID (to be assigned). This section details the syntax of the protocol. An LDAPv3 Extended Request is defined in [LDAPv3] as follows: ExtendedRequest ::= [APPLICATION 23] SEQUENCE { requestName [0] LDAPOID, requestValue [1] OCTET STRING OPTIONAL } If the client needs to terminate the synchronization process and it wishes to obtain the cookie that represents the current state of its data, it issues a stopClientUpdateRequest extended operation. The operation carries the following data. The extended operation requestValue is an OCTET STRING, whose contents are the bytes of the BER encoding of the following: Megginson, et. al. Proposed Standard - Expires: November 2001 7 StopClientUpdateRequestValue ::= INTEGER StopClientUpdateRequestValue - the message ID of the search that included the original clientUpdate control The server responds immediately with a stopClientUpdateResponse extended operation that carries no data. The server MAY send any pending SearchResultEntry PDUs if the server cannot easily abort or remove those search results from its outgoing queue. The server SHOULD send as few of these remaining SearchResultEntry PDUs as possible. Finally, the server sends the message SearchResultDone with the clientUpdateDone control attached. The value of the reason in the clientUpdateDone control value MUST be either an error code (some value other than lcupSuccess) or lcupClientDisconnect. The stopClientUpdateResponse is sent only to satisfy LDAP requirement that every server must issue an extended response for each extended request it receives. If the client is not interested in the state information, it can simply abandon the search operation or disconnect from the server. If server resources become tight, the server can terminate one or more search operations by sending a SearchResultDone message to the client(s). Unless the client sets the updateType field to persistOnly, the server attaches a clientUpdateDone control that contains the cookie that corresponds to the current state of the client's data and the value of the reason field is set to lcupResourcesExhausted. A server set policy is used to decide which searches to terminate. This can also be used as a security mechanism to disconnect clients that are suspected of malicious actions, but if the server can infer that the client is malicious, the server should return lcupSecurityViolation in the reason field of the response. The stopClientUpdate extended operation indicates that the initiator wishes to terminate the current update operation. The requestName portion of the stopClientUpdate must be the OID stopClientUpdateOID . The requestValue is the message ID corresponding to the client's search request. If the message ID is not valid, the server MUST send back to the client an LDAP error code of unwillingToPerform. 4.8 Protocol Flow The client server interaction can proceed in three different ways depending on the client's requirements. Protocol flows beginning with an asterisk (*) are optional or conditional. If the client's intent is not to synchronize data but to trigger actions in response to directory modifications, the protocol proceeds as follows: C->S Sends a search operation with a clientUpdate control attached. Megginson, et. al. Proposed Standard - Expires: November 2001 8 The search specification determines the part of the DIT the client wishes to synchronize with and the set of attributes it is interested in. The updateType field of the control value should be set to persistOnly. *S->C If there is an error (invalid search scope, invalid cookie) the server returns the appropriate error codes and terminates the request (SearchResultDone message with clientUpdateDone control) S->C Sends change notification to the client for each change to the data within the client's search specification. Each SearchResultEntry may have an entryUpdate control attached. *S->C If the server starts to run out of resources or the client is suspected of malicious actions, the server SHOULD terminate the search operation by sending to the client a SearchResultDone message with clientUpdateDone control attached. The control contains the reason field set to lcupResourcesExhausted or lcupSecurityViolation depending on the reason for termination. The server MAY provide more details to the client via the reasonText field of the control. *C->S If the client receives lcupResourcesExhausted error from the server, it MUST wait for a while before attempting another synchronization session with the server. It is RECOMMENDED that clients use an exponential backoff strategy. C->S The client terminates the search. The client can do this by abandoning the search operation, disconnecting from the server, or by sending the stopClientUpdate extended operation. *S->C If the server receives the stopClientUpdate extended op, it will immediately send back the stopClientUpdate extended op response *S->C If the client sent the stopClientUpdate extended op, the server MAY send any pending SearchResultEntry PDUs in its outgoing queue *S->C If the client sent the stopClientUpdate extended op, after the server sends the response and any pending SearchResultEntry PDUs, the server sends the SearchResultDone message with the clientUpdateDone control attached. The value of the reason field of the clientUpdateDone control value will be either lcupClientDisconnect or some lcup error code (not lcupSuccess). S->C Stops sending changes to the client and closes the connection. If the client's intent is to synchronize with the server and then disconnect, the protocol proceeds as follows: C->S Sends a search operation with the clientUpdate control attached. The search specification determines the part of the DIT the client wishes to synchronize with, the set of attributes it is interested in and the amount of data the client is willing to receive. If this is the initial synchronization session, the client either does not provide a cookie or provides a cookie with no value; otherwise, the cookie field of the control is set to the cookie received from the server at the end of the last synchronization session. If the scheme field of the cookie was provided, the server MUST Megginson, et. al. Proposed Standard - Expires: November 2001 9 use that scheme throughout the duration of the LCUP session or until an LCUP boundary is crossed, since the server will usually require a different cookie in that case anyway. (Note that the client can synchronize with different servers during different synchronization sessions.) The updateType field of the control value is set to synchronizeOnly. *S->C If there is an error (invalid search scope, invalid cookie) the server returns the appropriate error codes and terminates the request (SearchResultDone message with clientUpdateDone control) *S->C If no cookie is specified in the clientUpdate control, or if the value field of the cookie is empty, the server sends all data that matches the client's search specification followed by the SearchResultDone message with a clientUpdateDone control attached. The control contains the cookie that corresponds to the current state of the client's data and the reason flag set to lcupSuccess. *S->C If an invalid cookie is specified, the server sends the SearchResultDone message with clientUpdateDone control attached. The reason field of the control is set to lcupInvalidCookie and the reasonText field MAY contain explanation of the error. *S->C If a valid cookie is specified and the data that matches the search specification has been reloaded or the server does not contain enough state information to synchronize the client, the server sends a SearchResultDone message with clientUpdateDone control attached. The reason field of the control is set to lcupReloadRequired and the reasonText field MAY contain explanation of the error. *S->C If the cookie is valid and the client is up to date, the server sends a success response to the client. S->C If the cookie is valid and there is data to be sent, the server sends the modified entries to the client. Each SearchResultEntry contains the attributes requested by the client in the search specification regardless of whether they were modified. An entryUpdate control with the entryDeleted field set to TRUE MUST be attached to every deleted entry. The server may also periodically attach an entryUpdate control to the entries sent to the client to indicate the current state of the client's data. In that case, the cookie field of the control represents the state of the client's data including the entry to which the control is attached. Once all the changes are sent, the server sends a SearchResultDone with the clientUpdateDone control attached. The control contains the cookie that represents the current state of the client's data. The reason field of the control is set to lcupSuccess. The client stores the cookie received from the server until the next synchronization session. *C->S If the reason field of the control is set lcupReloadRequired, the client clears its data store and repeats the synchronization process by sending the search operation with clientUpdate control that contains no cookie, or that contains a cookie with no value field. Megginson, et. al. Proposed Standard - Expires: November 2001 10 If the client's intent is to be synchronized with the server and stay notified about data modifications, the protocol proceeds as follows: C->S The client behaves exactly as in the previous case except it sets the updateType field in the control value to synchronizeAndPersist. S->C The server behaves exactly as in the previous case except the connection is kept open after the initial set of changes is sent to the client. A SearchResultDone message is not sent to the client; instead, the server keeps sending changes to the client. *S->C If the server starts to run out of resources or the client is suspected of malicious actions, the server SHOULD terminate the search operation by sending to the client a SearchResultDone message with clientUpdateDone control attached. The control contains the reason field set to lcupResourcesExhausted or lcupSecurityViolation depending on the reason for termination. The server MAY provide more details to the client via the reasonText field of the control. *C->S If the client receives lcupResourcesExhausted error from the server, it MUST wait for a while before attempting another synchronization session with the server. We recommend exponential backoff strategy. C->S Sends a stopClientUpdateRequest extended operation to the server to terminate the synchronization session. S->C Responds with a stopClientUpdateResponse extended operation followed by a SearchResultDone with the clientUpdateDone control attached. The control contains the cookie that represents the current state of the client's data. The value of the reason field of the clientUpdateDone control value will be either lcupClientDisconnect or some lcup error code (not lcupSuccess). 4.9 Size and Time Limits The search request size or the time limits can only be imposed for non-persistent operations, those that set the updateType field of the ClientUpdateControlValue to synchronizeOnly (for the entire operation) or synchronizeAndPersist (for the initial synchronization phase only). All other operations MUST set both limits to 0. The server SHOULD ignore the limits set for persistent operations. 4.10 Changes vs. Operations Since the server sends to the client the modified entries rather than the operations, a MODDN operation performed on a subtree will be seen by the client as a sequence of added or modified entries depending on whether the operation moved the entries into the scope of the client's search specification. 4.11 Operations on the Same Connection Megginson, et. al. Proposed Standard - Expires: November 2001 11 It is permissible for the client to issue other LDAP operations on the connection used by the protocol. Since each LDAP request/response carries a message id there will be no ambiguity about which PDU belongs to which operation. By sharing the connection among multiple operations, the server will be able to conserve its resources. 5. Additional Features There are several features present in other protocols or considered useful by clients that are currently not included in the protocol primarily because they are difficult to implement on the server. These features are briefly discussed in this section. This section is intended to open a discussion on the merits of including and approaches to implementing these features. 5.1 Change Type This feature is present in the Triggered Search specification. A flag is attached to each entry returned to the client indicating the reason why this entry is returned. The possible reasons from the draft are "- notChange: the entry existed in the directory and matched the search at the time the operation is being performed, - enteredSet: the entry entered the result, - leftSet: the entry left the result, - modified: the entry was part of the result set, was modified or renamed, and still is in the result set." The leftSet feature is particularly useful because it indicates to the client that an entry is no longer within the client's search specification and the client can remove the associated data from its data store. Ironically, this feature is the hardest to implement on the server because the server does not keep track of the client's state and has no easy way of telling which entries moved out of scope between synchronization sessions with the client. A compromise could be reached by only providing this feature for the operations that occur while the client is connected to the server. This is easier to accomplish because the decision about the change type can be made based only on the change without need for any historical information. This, however, would add complexity to the protocol. 5.2 Sending Changes Some earlier synchronization protocols sent the client(s) only the modified attributes of the entry rather than the entire entry. While this approach can significantly reduce the amount of data returned to the client, it has several disadvantages. First, unless a separate mechanism (like the change type described above) is used to notify the client about entries moving into the search scope, sending only the changes can result in the client having an incomplete version of the data. Let's consider an example. An Megginson, et. al. Proposed Standard - Expires: November 2001 12 attribute of an entry is modified. As a result of the change, the entry enters the scope of the client's search. If only the changes are sent, the client would never see the initial data of the entry. Second, this feature is hard to implement since the server might not contain sufficient information to construct the changes based solely on the server's state and the client's cookie. On the other hand, this feature can be easily implemented by the client assuming that the client has the previous version of the data and can perform value by value comparisons. 5.3 Data Size Limits Some earlier synchronization protocols allowed clients to control the amount of data sent to them in the search response. This feature was intended to allow clients with limited resources to process synchronization data in batches. However, an LDAP search operation already provides the means for the client to specify the size limit by setting the sizeLimit field in the SearchRequest to the maximum number of entries the client is willing to receive. While the granularity is not the same, the assumption is that LCUP protocol will be implemented by regular LDAP clients that can deal with the limitations of the LDAP protocol. 5.4 Data Ordering Some earlier synchronization protocols allowed a client to specify that parent entries should be sent before the children for add operations and children entries sent before their parents during delete operations. This ordering helps clients to maintain a hierarchical view of the data in their data store. While possibly useful, this feature is relatively hard to implement and is expensive to perform. Comments from M. Armijo: " Although I appreciate the difficulty in implementing this, I believe we need to at least make it an option. If we do not, we will need to define how clients handle issues where changes are received out of order (stub entries, etc.) At the very least we should define that the server must not return a cookie until all parents involved in a series of operations have been returned (does that make sense or should I reword it?). I am concerned that a client can disconnect and be in what it considers to be a 'valid' state while it's own DIT is no longer valid." 6. Client Side Considerations There are several issues that the implementors of a synchronization client need to consider: - The cookie received from the server after a synchronization session can only be used with the same or more restrictive search specification than the search that generated the cookie. The server will reject the search operation with a cookie that does not satisfy this condition. This is because the client can end up with an incomplete data store otherwise. A more restrictive Megginson, et. al. Proposed Standard - Expires: November 2001 13 search specification is the one that generates a subset of the data produced by the original search specification. - Because an LCUP client specifies the area of the tree with which it wishes to synchronize through the standard LDAP search specification, the client can be returned noSuchObject error if the root of the synchronization area was renamed between the synchronization sessions. If this condition occurs, the client can attempt to locate the root by using the root's Unique Identifier saved in client's local data store. It then can repeat the synchronization request using the new search base. In general, a client can detect that an entry was renamed and apply the changes received to the right entry by using the Unique Identifier rather then DN based addressing. - Each active persistent operation requires that an open TCP connection be maintained between an LDAP client and an LDAP server that might not otherwise be kept open. Therefore, client implementors are encouraged to avoid using persistent operations for non-essential tasks and to close idle LDAP connections as soon as practical. The server may close connections if server resources become tight. - The client MAY receive a continuation reference (SearchResultReference [RFC2251 SECTION 4.5.3]) if the search request spans multiple parts of the DIT, some of which may require a different LCUP cookie, some of which may not even be managed by LCUP. The client SHOULD maintain a cache of the LDAP URLs returned in the continuation references and the cookies associated with them. The client is responsible for performing another LCUP search to follow the references, and SHOULD use the cookie corresponding to the LDAP URL for that reference (if it has a cookie). - Changes to meta-data in the server may affect the presence of entries in the search set. Servers MAY notify LCUP clients of changes to the search set that result from changes to meta-data such as access control rules. But an LCUP client MUST NOT assume that such notification will occur. Therefore, in the case where a client is maintaining a cache of entries using LCUP, the data held by the client may be a superset or a subset of the entries that would be returned by a new search request. For example, if access control meta information is changed to deny access to particular entries in the search result set, and the access control information is outside of the search scope (e.g., in a parent entry), the client may have entries stored locally which are no longer part of its desired search set. Similarly, if entries are added to the search result set due to changes in meta-data, the client's cache of entries may not include these entries. 7. Server Implementation Considerations Megginson, et. al. Proposed Standard - Expires: November 2001 14 By design, the protocol supports multiple cookie schemes. This is to allow different implementations the flexibility of storing any information applicable to their environment. A reasonable implementation for an LDUP compliant server would be to use the Replica Update Vector (RUV). For each master, RUV contains the largest CSN seen from this master. In addition, the RUV implemented by some directory servers (not yet in LDUP) contains replica generation - an opaque string that identifies the replica's data store. The replica generation value changes whenever the replica's data is reloaded. Replica generation is intended to signal the replication/synchronization peers that the replica's data was reloaded and that all other replicas need to be reinitialized. RUV satisfies the three most important properties of the cookie: (1) it uniquely identifies the state of client's data, (2) it can be used to synchronize with multiple servers, and (3) it can be used to detect that the server's data was reloaded. A server may support one or more LCUP cookie schemes. It is expected that schemes will be published along with their OIDs as RFCs. If a client initiates an LCUP session with a particular scheme, the server MUST use that same scheme throughout the LCUP session, or until an LCUP context boundary is crossed, in which case the server will usually require a different cookie anyway. In addition, the cookie must contain enough information to allow the server to determine whether the cookie can be safely used with the search specification it is attached to. As discussed earlier in the document, the cookie can only be used with the search specification that is equally or more restrictive than the one for which the cookie was generated. An implementation must make sure that it can correctly update the client's cookie when there is a size limit imposed on the search results by either the client's request or by the server's configuration. If RUV is used as the cookie, entries last modified by a particular master must be sent to the client in the order of their last modified CSN. This ordering guarantees that the RUV can be updated after each entry is sent. The server's DIT may be partitioned into different sections which may have different cookies associated with them. For example, some servers may use some sort of replication mechanism to support LCUP. If so, the DIT may be partitioned into multiple replicas. A client may send an LCUP search request that spans multiple replicas. Some parts of the DIT spanned by the search request scope may be managed by LCUP and some may not. A part of the DIT which is enabled for LCUP is referred to as an LCUP Context. The server SHOULD send a SearchResultReference [RFC2251, SECTION 4.5.3] when the LCUP Context for a returned entry changes. The server SHOULD return all entries for a particular LCUP Context before returning a reference to other LCUP Contexts or non LCUP enabled parts of the DIT, in order to minimize the processing burden on the clients. The LDAP URL(s) returned MUST contain the DN(s) of the base of another section of the DIT (however the server implementation has partitioned the DIT). Megginson, et. al. Proposed Standard - Expires: November 2001 15 The client will then issue another LCUP search using the LDAP URL returned. Each section of the DIT MAY require a different cookie value, so the client SHOULD maintain a cache, mapping the different LDAP URL values to different cookies. If the cookie changes, the scheme may change as well, but the cookie scheme MUST be the same within a given LCUP Context. An implementation must be able to notify the client about all entries deleted since the last implementation session. An LDUP compliant implementation can achieve this through the use of entry tombstones. The implementation should avoid aggressive tombstone purging since lack of tombstones would cause client's data to be reloaded. We suggest that only the tombstone content be removed during the regular trimming cycle while tombstones themselves are discarded much less frequently. The specification makes no guarantees about how soon a server should send notification of a changed entry to the client when the connection between the client and the server is kept open. This is intentional as any specific maximum delay would be impossible to meet in a distributed directory service implementation. Server implementors are encouraged to minimize the delay before sending notifications to ensure that clients' needs for timeliness of change notification are met. Implementors of servers that support the mechanism described in this document should ensure that their implementation scales well as the number of active persistent operations and the number of changes made in the directory increases. Server implementors are also encouraged to support a large number of client connections if they need to support large numbers of persistent operations. 8. Synchronizing Heterogeneous Data Stores Clients, like a meta directory join engine, synchronizing multiple writable data stores will only work correctly if each piece of information is single mastered (for instance, only by an LDUP compliant directory). This is because different systems have different notions of time and different update resolution procedures. As a result, a change applied on one system can be discarded by the other, thus preventing the data stores from converging. 9. Security Considerations In some situations, it may be important to prevent general exposure of information about changes that occur in an LDAP server. Therefore, servers that implement the mechanism described in this document SHOULD provide a means to enforce access control on the entries returned and MAY also provide specific access control mechanisms to control the use of the controls and extended operations defined in this document. Megginson, et. al. Proposed Standard - Expires: November 2001 16 As with normal LDAP search requests, a malicious client can initiate a large number of persistent search requests in an attempt to consume all available server resources and deny service to legitimate clients. The protocol provides the means to stop malicious clients by disconnecting them from the server. The servers that implement the mechanism SHOULD provide the means to detect the malicious clients. In addition, the servers SHOULD provide the means to limit the number of resources that can be consumed by a single client. Access control on the data can be modified in such a way that the data is no longer visible to the client. The specification does not specify how the server should handle this condition. Moreover, data consistency is not guaranteed if access control is changed from a more restrictive to a less restrictive one. This is because access control can be considered as an additional filter on the search specification and the protocol does not support going from a more to a less restrictive search specification. See Client Side Considerations Section for more detailed explanation of the problem. 10. References [KEYWORDS] S. Bradner, "Keywords for use in RFCs to Indicate Requirement Levels", RFC 2119, March 1997. [RFC2251] M. Wahl, T. Howes, S. Kille "Lightweight Directory Access Protocol", RFC 2251, December 1997. [RFC2252] M. Wahl, A. Coulbeck, T. Howes, S. Kille, "Lightweight Directory Access Protocol (v3): Attribute Syntax Definitions", RFC 2252, December 1997. 11. Acknowledgements The LCUP protocol is based in part on the Persistent Search Change Notification Mechanism defined by Mark Smith, Gordon Good, Tim Howes, and Rob Weltman, the LDAPv3 Triggered Search Control defined by Mark Wahl, and the LDAP Control for Directory Synchronization defined by Michael Armijo. 12. Author's Addresses Rich Megginson Netscape Communications Corp. 901 San Antonio Rd. Palo Alto, CA 94303-4900 Mail Stop SCA17 - 201 Phone: +1 408 276-3752 Email: richm@netscape.com Olga Natkovich eTime Capital, Inc. 1154 E Arques Ave. Sunnyvale, CA 94085 Megginson, et. al. Proposed Standard - Expires: November 2001 17 Phone: +1 408 830-2029 Email: olga@etimecapital.com Mark Smith Netscape Communications Corp. 901 San Antonio Rd. Palo Alto, CA 94303-4900 Mail Stop SCA17 - 201 Phone: +1 650 937-3477 Email: mcs@netscape.com Jeff Parham Microsoft Corporation One Microsoft Way Redmond, WA 98052-6399 Phone: +1 425 882-8080 Email: jeffparh@microsoft.com 13. Full Copyright Statement "Copyright (C) The Internet Society (date). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 14. Appendix A - Summary of Changes Changes new to version 01: The opaque cookie has been split into two parts - a scheme which is an OID, and a value. The value may or may not have a format known to the client, depending on the specified scheme. Section 4.2 describes the new cookie format and defines the LCUP Cookie Value. Megginson, et. al. Proposed Standard - Expires: November 2001 18 Added new section 4.3 - the lcupCookieSchemes operational attribute. Changes new to version 00: Added the definition for Unique Identifier (basically copied from the LDUP model doc http://search.ietf.org/internet-drafts/draft- ietf-ldup-model-06.txt. I needed to add the definition here because LCUP needs a Unique Identifier but should not be dependent on LDUP. Removed all normative references to LDUP. I've left the implementation suggestions that refer to LDUP, but LCUP should not be dependent on LDUP. Cleaned up the protocol flows. Removed this text from section 4.8: "Clients MUST NOT issue multiple synchronization requests on the same connection. This is because the protocol includes an extended operation and it would be impossible to decide which synchronization session it belongs to." - This is no longer true, since the extended operation now includes the message ID of the search request. "Client Side Consideration" section - the client will never receive a referral or continuation reference Added section 12. Acknowledgements Removed normative references to documents not depended on. Removed explicit references to software vendors. Section 4.1 - Changed ClientUpdateControlValue to remove the keepConnection and changesOnly fields and replace them with updateType which is an ENUMERATED with three values: synchronizeOnly, synchronizeAndPersist, and persistOnly. Section 4.2 - The EntryUpdateControlValue fields stateUpdate and entryDeleted no longer have DEFAULT values, they must be specified - this eliminates any potential ambiguity. Added this text to the description of the entryDeleted field (section 4.2): "The server SHOULD also set this to TRUE if the entry has left the clients search result set. As far as the client is concerned, a deleted entry is no different than an entry which has left the result set." Section 4.2 - Added an explanation of the concept and requirement for the Unique Identifier. Section 4.4 - Added to the extended operation a request value containing the message id of the operation to stop. Updated contact information for Olga. Megginson, et. al. Proposed Standard - Expires: November 2001 19 Removed Michael Armijo and added Jeff Parham as an author. Changes new to previous version: "Authors" section - added Rich Megginson as the new editor. "Client Side Consideration" section - added a note and a question concerning referral and continuation reference handling. "Client Update Control Value" section (4.1) - clarified the meaning of keepConnection and added a table summarizing the effects of different values of keepConnection and changesOnly. "Stop Client Update Request and Response" - added section 4.4 describing this extended operation. Megginson, et. al. Proposed Standard - Expires: November 2001 20 --------------D1C6F7D719B62D11794CDFA5-- --------------msE72D006B89CA7586B2F63700 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature Content-Transfer-Encoding: base64 MIIJFwYJKoZIhvcNAQcCoIIJCDCCCQQCAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3DQEHAaCC BuowggMMMIICdaADAgECAgI4bjANBgkqhkiG9w0BAQQFADCBkzELMAkGA1UEBhMCVVMxCzAJ BgNVBAgTAkNBMRYwFAYDVQQHEw1Nb3VudGFpbiBWaWV3MRswGQYDVQQKExJBbWVyaWNhIE9u bGluZSBJbmMxGTAXBgNVBAsTEEFPTCBUZWNobm9sb2dpZXMxJzAlBgNVBAMTHkludHJhbmV0 IENlcnRpZmljYXRlIEF1dGhvcml0eTAeFw0wMTA2MDQxMzIzNTlaFw0wMTEyMDExMzIzNTla MIGCMRMwEQYKCZImiZPyLGQBGRYDY29tMRgwFgYKCZImiZPyLGQBGRYIbmV0c2NhcGUxITAf BgkqhkiG9w0BCQEWEnJpY2htQG5ldHNjYXBlLmNvbTEXMBUGA1UEAxMOUmljaCBNZWdnaW5z b24xFTATBgoJkiaJk/IsZAEBEwVyaWNobTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEA vzzOOuvTS4h7GhcAGzqVeimRSAAhcKDPG9I3nBzbjyhahyg1l+9jL3aWxzjZTeUc3mAvWuoK 3NsNsI6N4MV9kH2NDUEEw3GsSweDEU6MFBwPA2YCxa8Ct0NkR+VRWG/YfUalO/OqROKZ5KBY tiJCR31RQ5Iiwxe4ZgPVfrYoVzUCAwEAAaN+MHwwEQYJYIZIAYb4QgEBBAQDAgWgMA4GA1Ud DwEB/wQEAwIF4DA2BggrBgEFBQcBAQQqMCgwJgYIKwYBBQUHMAGGGmh0dHA6Ly9uc29jc3Au bmV0c2NhcGUuY29tMB8GA1UdIwQYMBaAFCnbsi2Dfn+LI7vCzGa5Oegp8wKGMA0GCSqGSIb3 DQEBBAUAA4GBAMkxCPa1hNJmPODo+PvjDyGxRdXIKlgcbWMDuoBVZ7OulY006Jg02nnvwNnq q8wLIciyyjVP1rTpHsBApNCGxkRa5Oc5sCetbnyP5ZIOBCaOe0Bh/IWDDTHl3y9HTWmNxX8b OPkzNkWGigfW45m2Xr3lTjnUhXdFgt4QU57EbizQMIID1jCCAz+gAwIBAgIEAgAB5jANBgkq hkiG9w0BAQUFADBFMQswCQYDVQQGEwJVUzEYMBYGA1UEChMPR1RFIENvcnBvcmF0aW9uMRww GgYDVQQDExNHVEUgQ3liZXJUcnVzdCBSb290MB4XDTAxMDYwMTEyNDcwMFoXDTA0MDYwMTIz NTkwMFowgZMxCzAJBgNVBAYTAlVTMQswCQYDVQQIEwJDQTEWMBQGA1UEBxMNTW91bnRhaW4g VmlldzEbMBkGA1UEChMSQW1lcmljYSBPbmxpbmUgSW5jMRkwFwYDVQQLExBBT0wgVGVjaG5v bG9naWVzMScwJQYDVQQDEx5JbnRyYW5ldCBDZXJ0aWZpY2F0ZSBBdXRob3JpdHkwgZ8wDQYJ KoZIhvcNAQEBBQADgY0AMIGJAoGBAOLvXyx2Q4lLGl+z5fiqb4svgU1n/71KD2MuxNyF9p4s SSYg/wAX5IiIad79g1fgoxEZEarW3Lzvs9IVLlTGbny/2bnDRtMJBYTlU1xI7YSFmg47PRYH XPCzeauaEKW8waTReEwG5WRB/AUlYybr7wzHblShjM5UV7YfktqyEkuNAgMBAAGjggGCMIIB fjBNBgNVHR8ERjBEMEKgQKA+hjxodHRwOi8vd3d3MS51cy1ob3N0aW5nLmJhbHRpbW9yZS5j b20vY2dpLWJpbi9DUkwvR1RFUm9vdC5jZ2kwHQYDVR0OBBYEFCnbsi2Dfn+LI7vCzGa5Oegp 8wKGMGYGA1UdIARfMF0wRgYKKoZIhvhjAQIBBTA4MDYGCCsGAQUFBwIBFipodHRwOi8vd3d3 LmJhbHRpbW9yZS5jb20vQ1BTL09tbmlSb290Lmh0bWwwEwYDKgMEMAwwCgYIKwYBBQUHAgEw WAYDVR0jBFEwT6FJpEcwRTELMAkGA1UEBhMCVVMxGDAWBgNVBAoTD0dURSBDb3Jwb3JhdGlv bjEcMBoGA1UEAxMTR1RFIEN5YmVyVHJ1c3QgUm9vdIICAaMwKwYDVR0QBCQwIoAPMjAwMTA2 MDExMjQ3MzBagQ8yMDAzMDkwMTIzNTkwMFowDgYDVR0PAQH/BAQDAgEGMA8GA1UdEwQIMAYB Af8CAQEwDQYJKoZIhvcNAQEFBQADgYEASmIO2fpGdwQKbA3d/tIiOZkQCq6ILYY9V4TmEiQ3 aftZXuIRsPmfpFeGimkfBmPRfe4zNkkQIA8flxcsJ2w9bDkEe+JF6IcbVLZgQW0drgXznfk6 NJrje2tMcfjrqCuDsDWQTBloce3wYyJewlvsIHq1sFFz6QfugWd2eVP3ldQxggH1MIIB8QIB ATCBmjCBkzELMAkGA1UEBhMCVVMxCzAJBgNVBAgTAkNBMRYwFAYDVQQHEw1Nb3VudGFpbiBW aWV3MRswGQYDVQQKExJBbWVyaWNhIE9ubGluZSBJbmMxGTAXBgNVBAsTEEFPTCBUZWNobm9s b2dpZXMxJzAlBgNVBAMTHkludHJhbmV0IENlcnRpZmljYXRlIEF1dGhvcml0eQICOG4wCQYF Kw4DAhoFAKCBsTAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0w MTA3MTkxNTAxNTdaMCMGCSqGSIb3DQEJBDEWBBThsi+HYVXRMgiXtu+4sBBi4NTAbjBSBgkq hkiG9w0BCQ8xRTBDMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDAHBgUrDgMCBzANBggq hkiG9w0DAgIBQDANBggqhkiG9w0DAgIBKDANBgkqhkiG9w0BAQEFAASBgFExTMhG+iSRf/NB 9k/+hF/LXxeclTkfMV5Yzkn37+M8aRGnO+u8WdYfILh6qNOwvUoapT19Jjb16co7LDp4RkU7 HGT6NSFjIKqxYqjS8/Vpr8dwpmL7AmSCLuCTfS3VgrTNbYY1PgyWerzUxk9WAFvZqAgIUdwX tED3A/armd/f --------------msE72D006B89CA7586B2F63700-- From owner-ietf-ldup@mail.imc.org Thu Jul 19 11:55:56 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA00161 for ; Thu, 19 Jul 2001 11:55:55 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.3/8.11.3) id f6JFUwY19485 for ietf-ldup-bks; Thu, 19 Jul 2001 08:30:58 -0700 (PDT) Received: from ns.oncalldba.com (cpe-66-1-184-87.ut.sprintbbd.net [66.1.184.87]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f6JFUuq19475 for ; Thu, 19 Jul 2001 08:30:56 -0700 (PDT) Received: from reed.oncalldba.com (reed.OnCallDBA.COM [192.168.1.3]) by ns.oncalldba.com (8.11.0/8.11.0) with SMTP id f6JFSqB29393 for ; Thu, 19 Jul 2001 09:28:52 -0600 Received: from RMINC_DOM-Message_Server by reed.oncalldba.com with Novell_GroupWise; Thu, 19 Jul 2001 09:29:13 -0600 Message-Id: X-Mailer: Novell GroupWise Internet Agent 5.5.2.1 Date: Thu, 19 Jul 2001 09:29:02 -0600 From: "Ed Reed" To: Cc: , Subject: Re: LDAPSubentries comments review and request for last callby LDAPEXT and LDUP working groups 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 f6JFUvq19480 Sender: owner-ietf-ldup@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 8bit Response: LDAP includes, by reference, X.500 subentries, including refinement. Just use them, if your applications require refinement. LDAPSubentries are intended to assist in representing policy information that doesn't require refinement as supported by X.500. Perhaps LDAPv3bis will clarify the LDAP representation of the X.500 subtreeSpecification, including the various chop semantics, and everyone will implement them as a result. Then the only obsticle will be getting test modules added to the Microsoft, Novell, Netscape, et al directory administrator certification test programs so there will be a prayer that they'll be used correctly by the 75,000 or so certified directory administrators out there in the real world. My personal view is that the subtreeSpecification is a neat piece of design that requires system administrators to view their application policy (ACI, Schema, whatever) as a collection of ropes created from multiple arbitrary threads connecting attributes and entries scattered throughout a tree (without intersecting or overlapping or leaving any attribute/entry unconnected). This multidimensional view is elegant, powerful, versitile, and pretty totally without the computational tools needed to inspect, modify, or test whether the refinements expressed actually relate in any interesting way to the policy the administrator had in mind when they started refining their policy. SubtreeSpecifications appear to be an interesting implementation mechanism for representing complex policy. Unfortunately, the current state of the market place is that developers, who can walk through the code in their minds to figure out what a thing will do, too often assume that everyone else can do that, too. Frankly, I've had enough trouble explaining (over and over and over again) to information technology consumers why "relational databases aren't just as good" as hierarchical tree structures for distributed management policy representation. Now you want to get them thinking multidimensionally, too? Crawl, walk, run - a lesson taught by real world experience, and addressed to developers of products, consumers of those products, and the executive managers of those consumers. Technologists who put forward elegant, powerful, versitile and uninspectable solutions find, in the mass market, that they're also unpredictable because they'll be used in the wildest, most amusing ways. I recommend we not go there. If the concensus of the group is that we must, then I think we need to seriously reconsider the advisability of taking LDAPv3bis forward, and realize that we all should just adopt X.500 in its entirity. Kurt and Albert have been correct in their assertions that LDAP isn't a distributed service, we're turning it into one by pieces, and the X.500 design (if we need the whole refinement thing, then we probably need the whole HOB thing as well, and if we do that, then what's left not to put into LDAPv3bis?) should be tried instead. If you can get Microsoft and Novell to go there, that is... I for one don't want to encourage LDAP customers to use refinement in ACI, nor to experiment with multimaster replication from sparse and fractional replicas. I think there's a world of applications (like non-global, in-the-tree schema management), in the distributed management world, that do not require that kind of power to be put into consumers hands to use to shoot themselves in the foot. But, if the number of customer support phone calls resulting from having hundreds of thousands of directory administrators trying to figure out why their highly refined policy doesn't behave "the way they thought it would" is a satisfactory definition of success, then go for it! I'll ask the chairs to decide the concensus of the working group. Ed ================= Ed Reed Reed-Matthews, Inc. +1 801 796 7065 http://www.Reed-Matthews.COM >>> "Kurt D. Zeilenga" 07/18/01 10:53PM >>> At 12:24 PM 7/16/2001, Ed Reed wrote: >So - I'd like more comments on the administrative model. Does it work for ACI as LDAPEXT is defining it? Other applications than just LDUP? I think it DOES work for LDUP (ie, managing replication areas). I don't think it works for access controls, subschema, collective attributes, and likely not for LDUP (consider sparse replica). Of course, my definition of "works" may be quite different than yours. ldapSubentry can only hold information associated with a subtree. ldapSubentry, by design, cannot hold information associated with a subtree refinement [X.501]. Consider a case where the administrator wishes to hold a set of shared attributes for the collection of entries which are immediately subordinate to a particular entry (but not the particular entry). This cannot be done using LDAPsubentries as LDAPsubentries requires that each subordinate have a separate subentry to hold the attributes. As these attributes are held in different subentries, they are not shared. And further subentries need to be created to break the inheritance (as the information was to be shared between the immediate subordinates). And, of course, needed subordinates are not automatically created/deleted upon add, delete, and rename. I believe there is good operational experience from the X.500 community that a subentry subtree refinement mechanism is needed to allow for effective administration of the Directory. I recommend we adapt X.500 subentries, including the subtree specification mechanism, for use with LDAP. Kurt From owner-ietf-ldup@mail.imc.org Thu Jul 19 21:17:29 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id VAA21431 for ; Thu, 19 Jul 2001 21:17:28 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.3/8.11.3) id f6K0kLM13783 for ietf-ldup-bks; Thu, 19 Jul 2001 17:46:21 -0700 (PDT) Received: from pretender.boolean.net (root@router.boolean.net [198.144.206.49]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f6K0jqq13766 for ; Thu, 19 Jul 2001 17:45:52 -0700 (PDT) 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 f6K0fZC53304; Fri, 20 Jul 2001 00:42:26 GMT (envelope-from Kurt@OpenLDAP.org) Message-Id: <5.1.0.14.0.20010719091823.0293c000@127.0.0.1> X-Sender: kurt@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Thu, 19 Jul 2001 17:40:52 -0700 To: "Ed Reed" From: "Kurt D. Zeilenga" Subject: Re: LDAPSubentries comments review and request for last callby LDAPEXT and LDUP working groups Cc: , In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-ldup@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: At 08:29 AM 7/19/2001, Ed Reed wrote: >LDAP includes, by reference, X.500 subentries, including refinement Then why are we wasting our time with LDAPsubentries? X.500 subentries provides a sound approach, an approach proven to work for holding subschema, ACIs, and collective attributes. We certainly don't need an second approach, especially one which is inconsistent with the X.500 data model which implementations "MUST act in accordance with." Kurt From owner-ietf-ldup@mail.imc.org Thu Jul 19 22:32:08 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id WAA18359 for ; Thu, 19 Jul 2001 22:32:07 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.3/8.11.3) id f6K2En016288 for ietf-ldup-bks; Thu, 19 Jul 2001 19:14:49 -0700 (PDT) Received: from ns.oncalldba.com (cpe-66-1-184-87.ut.sprintbbd.net [66.1.184.87]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f6K2Ekq16284 for ; Thu, 19 Jul 2001 19:14:47 -0700 (PDT) Received: from reed.oncalldba.com (reed.OnCallDBA.COM [192.168.1.3]) by ns.oncalldba.com (8.11.0/8.11.0) with SMTP id f6K2EiB30104 for ; Thu, 19 Jul 2001 20:14:44 -0600 Received: from RMINC_DOM-Message_Server by reed.oncalldba.com with Novell_GroupWise; Thu, 19 Jul 2001 20:14:44 -0600 Message-Id: X-Mailer: Novell GroupWise Internet Agent 5.5.2.1 Date: Thu, 19 Jul 2001 20:14:39 -0600 From: "Ed Reed" To: Cc: , Subject: Re: LDAPSubentries comments review and request for last callbyLDAPEXT and LDUP working groups 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 f6K2Emq16285 Sender: owner-ietf-ldup@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 8bit I think I answered that - because the X.500 refinement mechanism is too complex to be easily understood, configured, or implemented, much less managed. A profile of a simpler thing is needed for many applications. ================= Ed Reed Reed-Matthews, Inc. +1 801 796 7065 http://www.Reed-Matthews.COM >>> "Kurt D. Zeilenga" 07/19/01 06:40PM >>> At 08:29 AM 7/19/2001, Ed Reed wrote: >LDAP includes, by reference, X.500 subentries, including refinement Then why are we wasting our time with LDAPsubentries? X.500 subentries provides a sound approach, an approach proven to work for holding subschema, ACIs, and collective attributes. We certainly don't need an second approach, especially one which is inconsistent with the X.500 data model which implementations "MUST act in accordance with." Kurt From owner-ietf-ldup@mail.imc.org Fri Jul 20 00:53:06 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id AAA04206 for ; Fri, 20 Jul 2001 00:53:06 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.3/8.11.3) id f6K4bVD19345 for ietf-ldup-bks; Thu, 19 Jul 2001 21:37:31 -0700 (PDT) Received: from arnie.adacel.com.au (arnie.adacel.com.au [203.36.26.147]) by above.proper.com (8.11.3/8.11.3) with SMTP id f6K4bQq19338 for ; Thu, 19 Jul 2001 21:37:27 -0700 (PDT) Received: (qmail 18482 invoked from network); 20 Jul 2001 04:11:23 -0000 Received: from osmium.adacel.com.au (HELO osmium) (203.8.85.176) by arnie.adacel.com.au with SMTP; 20 Jul 2001 04:11:23 -0000 Reply-To: From: "Steven Legg" To: "'Kurt D. Zeilenga'" , "'Ed Reed'" Cc: , Subject: RE: LDAPSubentries comments review and request for last callby LDAPEXT and LDUP working groups Date: Fri, 20 Jul 2001 14:11:19 +1000 Message-ID: <007c01c110d2$07dee7f0$b05508cb@osmium.adacel.com.au> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook 8.5, Build 4.71.2377.0 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V4.72.2120.0 In-Reply-To: <5.1.0.14.0.20010719091823.0293c000@127.0.0.1> Sender: owner-ietf-ldup@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit Kurt D. Zeilenga wrote: > At 08:29 AM 7/19/2001, Ed Reed wrote: > >LDAP includes, by reference, X.500 subentries, including refinement > > Then why are we wasting our time with LDAPsubentries? > X.500 subentries provides a sound approach, an approach > proven to work for holding subschema, ACIs, and collective > attributes. We certainly don't need an second approach, > especially one which is inconsistent with the X.500 data > model which implementations "MUST act in accordance with." I agree. I would be very happy for the LDAP subentry model to be a proper subset of the X.500 administrative model since I already support the X.500 model through LDAP. Having to duplicate that functionality in a slightly different way for LDAP would be irksome, and the prospect of having to support two subschema subentries in each subschema area in the DIT, one conforming to X.500 and one conforming to LDAP, does not fill me with joy. The X.500 working group has a current work item for X.500 - LDAP alignment. If we ask them nicely I'm sure they will modify the subentry definitions to be more amenable to some of the uses being proposed for LDAP. For example, the requirement in X.501 that subentries "shall not have subordinates" could be relaxed to "may only have subentries as subordinates". Adding a requirement that subentries with the subschema, collectiveAttributeSubentry, accessControlSubentry, etc, auxiliary object classes must be immediately subordinate to an administration point entry assures backward compatibility with current uses of subentries while enabling subentry hierarchies for new subentry auxiliary classes defined for LDAP. Regards, Steven > > Kurt > > > From owner-ietf-ldup@mail.imc.org Fri Jul 20 01:48:46 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id BAA26620 for ; Fri, 20 Jul 2001 01:48:45 -0400 (EDT) Received: by above.proper.com (8.11.3/8.11.3) id f6K5XbK20674 for ietf-ldup-bks; Thu, 19 Jul 2001 22:33:37 -0700 (PDT) Received: from arnie.adacel.com.au (arnie.adacel.com.au [203.36.26.147]) by above.proper.com (8.11.3/8.11.3) with SMTP id f6K5XSq20667 for ; Thu, 19 Jul 2001 22:33:30 -0700 (PDT) Received: (qmail 28348 invoked from network); 20 Jul 2001 05:34:04 -0000 Received: from osmium.adacel.com.au (HELO osmium) (203.8.85.176) by arnie.adacel.com.au with SMTP; 20 Jul 2001 05:34:04 -0000 Reply-To: From: "Steven Legg" To: "'Ed Reed'" , Cc: , Subject: RE: LDAPSubentries comments review and request for lastcallbyLDAPEXT and LDUP working groups Date: Fri, 20 Jul 2001 15:33:59 +1000 Message-ID: <007d01c110dd$94ab0fa0$b05508cb@osmium.adacel.com.au> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook 8.5, Build 4.71.2377.0 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: > I think I answered that - because the X.500 refinement mechanism > is too complex to be easily understood, configured, or implemented, > much less managed. A profile of a simpler thing is needed for many > applications. Complexity is a relative thing. I find the subtree refinement mechanism much easier to get my head around than the LDAP access control model. Anyway, what's the problem with writing a profile for the use of subtree specifications in LDAP that restricts the possible forms (to one even!) ? The only proposal I've ever been able to find for an LDAP string representation of subtree specifications is the long expired draft-ietf-asid-ldapv3-attributes-03.txt. With this proposal, the simplest specification is "(####)", which means "the whole subtree". Can't new subentry classes for LDAP simply require the subtree specification to be exactly this ? Since there isn't a normative reference for the LDAP string representation of subtree specifications I would rather that the string encoding be defined algorithmically from the ASN.1, i.e. using the generic string encoding rules from my component matching draft. With those rules the whole subtree specification is just "{}". An overt description of the LDAP string representation of subtree specifications could just mention this form for the unwashed masses, while for those who need to use it for X.500 interworking, or want to experiment with it in LDAP, there is a deduceable ABNF for more refined subtree specifications. Regards, Steven > > ================= > Ed Reed > Reed-Matthews, Inc. > +1 801 796 7065 > http://www.Reed-Matthews.COM > > >>> "Kurt D. Zeilenga" 07/19/01 06:40PM >>> > > At 08:29 AM 7/19/2001, Ed Reed wrote: > >LDAP includes, by reference, X.500 subentries, including refinement > > Then why are we wasting our time with LDAPsubentries? > X.500 subentries provides a sound approach, an approach > proven to work for holding subschema, ACIs, and collective > attributes. We certainly don't need an second approach, > especially one which is inconsistent with the X.500 data > model which implementations "MUST act in accordance with." > > Kurt > > > > From owner-ietf-ldup@mail.imc.org Fri Jul 20 05:57:11 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id FAA13703 for ; Fri, 20 Jul 2001 05:57:10 -0400 (EDT) Received: by above.proper.com (8.11.3/8.11.3) id f6K9c7b19145 for ietf-ldup-bks; Fri, 20 Jul 2001 02:38:07 -0700 (PDT) Received: from ietf.org (odin.ietf.org [132.151.1.176]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f6K9c5q19141 for ; Fri, 20 Jul 2001 02:38:05 -0700 (PDT) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA06318; Fri, 20 Jul 2001 05:37:07 -0400 (EDT) Message-Id: <200107200937.FAA06318@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: ietf-ldup@imc.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-ldup-replica-req-10.txt Date: Fri, 20 Jul 2001 05:37:07 -0400 Sender: owner-ietf-ldup@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the LDAP Duplication/Replication/Update Protocols Working Group of the IETF. Title : LDAPv3 Replication Requirements Author(s) : E. Stokes, R. Weiser, R. Moats, R. Huber Filename : draft-ietf-ldup-replica-req-10.txt Pages : 30 Date : 19-Jul-01 This document discusses the fundamental requirements for replication of data accessible via the LDAPv3 [RFC2251] protocol. It is intended to be a gathering place for general replication requirements needed to provide interoperability between informational directories. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ldup-replica-req-10.txt Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-ldup-replica-req-10.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-ldup-replica-req-10.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20010719150035.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ldup-replica-req-10.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ldup-replica-req-10.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20010719150035.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ietf-ldup@mail.imc.org Fri Jul 20 05:59:29 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id FAA14226 for ; Fri, 20 Jul 2001 05:59:28 -0400 (EDT) Received: by above.proper.com (8.11.3/8.11.3) id f6K9c2b19136 for ietf-ldup-bks; Fri, 20 Jul 2001 02:38:02 -0700 (PDT) Received: from ietf.org (odin.ietf.org [132.151.1.176]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f6K9c0q19130 for ; Fri, 20 Jul 2001 02:38:00 -0700 (PDT) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA06273; Fri, 20 Jul 2001 05:37:03 -0400 (EDT) Message-Id: <200107200937.FAA06273@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: ietf-ldup@imc.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-ldup-lcup-01.txt Date: Fri, 20 Jul 2001 05:37:02 -0400 Sender: owner-ietf-ldup@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the LDAP Duplication/Replication/Update Protocols Working Group of the IETF. Title : LDAP Client Update Protocol Author(s) : R. Megginson et al. Filename : draft-ietf-ldup-lcup-01.txt Pages : 20 Date : 19-Jul-01 This document defines the LDAP Client Update Protocol (LCUP). The protocol is intended to allow an LDAP client to synchronize with the content of a directory information tree (DIT) stored by an LDAP server and to be notified about the changes to that content. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ldup-lcup-01.txt Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-ldup-lcup-01.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-ldup-lcup-01.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20010719150027.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ldup-lcup-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ldup-lcup-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20010719150027.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ietf-ldup@mail.imc.org Fri Jul 20 06:26:03 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id GAA18536 for ; Fri, 20 Jul 2001 06:26:01 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.3/8.11.3) id f6KA2UG21609 for ietf-ldup-bks; Fri, 20 Jul 2001 03:02:30 -0700 (PDT) Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f6KA2Tq21601 for ; Fri, 20 Jul 2001 03:02:29 -0700 (PDT) Received: from odin.France.Sun.COM ([129.157.197.2]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id DAA11098; Fri, 20 Jul 2001 03:02:27 -0700 (PDT) Received: from Sun.com (bondi [129.157.192.47]) by odin.France.Sun.COM (8.10.2+Sun/8.10.2/ENSMAIL,v2.1p1) with ESMTP id f6KA2QC13872; Fri, 20 Jul 2001 12:02:26 +0200 (MEST) Message-ID: <3B5801B2.D3F463CD@Sun.com> Date: Fri, 20 Jul 2001 12:02:26 +0200 From: Ludovic Poitou Organization: Sun Microsystems Inc. X-Mailer: Mozilla 4.7 [en] (X11; I; SunOS 5.8 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: internet-drafts@ietf.org CC: ggood@loudcloud.com, ietf-ldapext@netscape.com, mcs@netscape.com, ietf-ldup@imc.org Subject: update to draft-good-ldap-changelog-01.txt Content-Type: multipart/mixed; boundary="------------454482E795D1A8680588F9A5" Sender: owner-ietf-ldup@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multi-part message in MIME format. --------------454482E795D1A8680588F9A5 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Internet-Drafts Editors, Please publish draft-good-ldap-changelog-02.txt as an update to draft-good-ldap-changelog-01.txt LDAPExt and LDUP working groups, This is a re-publication of the now expired "draft-good-ldap-changelog-01.txt", with no updates in the content. The goal is to have the document moved to Informational status. I look forward to any input & insight the WGs can provide. Thank you and best regards, Ludovic. -- Ludovic Poitou Sun Microsystems Inc. iPlanet E-Commerce Solutions - Directory Group - Grenoble - France --------------454482E795D1A8680588F9A5 Content-Type: text/plain; charset=iso-8859-1; name="draft-good-ldap-changelog-02.txt" Content-Disposition: inline; filename="draft-good-ldap-changelog-02.txt" Content-Transfer-Encoding: quoted-printable INTERNET-DRAFT Gordon Good draft-good-ldap-changelog-02.txt Loudcloud Intended Category: Informational Ludovic Poitou Sun Microsystems 19 July 2001 Definition of an Object Class to Hold LDAP Change Records Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet- Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet Draft expires 19 January 2002. Abstract In order to support more flexible replication methods, it is desirable to specify some manner in which an LDAP client may retrieve a set of changes which have been applied to an LDAP server's database. The client, which may be another LDAP server, may then choose to update its own replicated copy of the data. This document specifies an object class which may be used to represent changes applied to an LDAP server. It also specifies a method for discovering the location of the container object which holds these change records, so that clients and servers have a common rendezvous point for this information. Background and Intended Usage This document describes an objectclass which can be used to represent changes which have been applied to a directory server. It also suggests a common location for a container which holds these objects. Good Expires 19 January 2002 [Page 1] =0C INTERNET-DRAFT Change Record Object Class 19 July 2001 A client may update its local copy of directory information by reading the entries within this container, and applying the changes to its local database. The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", and "MAY" in this document are to be interpreted as described in RFC 2119 [3]. New Attribute Types Used in the changeLogEntry Object Class ( 2.16.840.1.113730.3.1.5 NAME 'changeNumber' DESC 'a number which uniquely identifies a change made to a directory entry' SYNTAX 'INTEGER' EQUALITY 'integerMatch' ORDERING 'integerOrderingMatch' ) ( 2.16.840.1.113730.3.1.6 NAME 'targetDN' DESC 'the DN of the entry which was modified' EQUALITY distinguishedNameMatch SYNTAX 'DN' ) ( 2.16.840.1.113730.3.1.7 NAME 'changeType' DESC 'the type of change made to an entry' EQUALITY caseIgnoreMatch SYNTAX 'DirectoryString' ) ( 2.16.840.1.113730.3.1.8 NAME 'changes' DESC 'a set of changes to apply to an entry' SYNTAX 'OctetString' ) ( 2.16.840.1.113730.3.1.9 NAME 'newRDN' DESC 'the new RDN of an entry which is the target of a modrdn operation' EQUALITY distinguishedNameMatch SYNTAX 'DN' ) ( 2.16.840.1.113730.3.1.10 NAME 'deleteOldRDN' DESC 'a flag which indicates if the old RDN should be retained as an attribute of the entry' EQUALITY booleanMatch SYNTAX 'BOOLEAN' ) Good Expires 19 January 2002 [Page 2] =0C INTERNET-DRAFT Change Record Object Class 19 July 2001 ( 2.16.840.1.113730.3.1.11 NAME 'newSuperior' DESC 'the new parent of an entry which is the target of a moddn operation' EQUALITY distinguishedNameMatch SYNTAX 'DN' ) Schema Definition of the changeLogEntry Object Class ( 2.16.840.1.113730.3.2.1 NAME 'changeLogEntry' SUP top STRUCTURAL MUST ( changeNumber $ targetDN $ changeType ) MAY ( changes $ newRDN $ deleteOldRDN $ newSuperior ) ) Discussion of changeLogEntry Attributes: changeNumber: the change number, as assigned by the supplier. This integer MUST strictly increase as new entries are added, and must always be unique within a given server. Syntax: INTEGER targetdn: the distinguished name of the entry which was added, modified or deleted. In the case of a modrdn operation, the targetdn gives the DN of the entry before it was modified. Syntax: DN changeType: the type of change. One of: "add", "delete", "modify", "modrdn". Later RFCs may define additional values for changeType. Syntax: DirectoryString changes: the changes which were made to the directory server. These changes are in LDIF format, which is described in [1]. Syntax: OctetString newRDN: the new RDN (Relative Distinguished Name) of the entry, if the= changeType is "modrdn". If the changeType attribute does not have the= value "modrdn", then there should be no values contained in the newRDN= attribute. Syntax: DN Good Expires 19 January 2002 [Page 3] =0C INTERNET-DRAFT Change Record Object Class 19 July 2001 deleteOldRDN: a flag which tells whether the old RDN of the entry should be retained as a distinguished attribute of the entry, or should be deleted. A value of "FALSE" indicates that the RDN should b= e retained as a distinguished attribute, and a value of "TRUE" indicates= that it should not be retained as a distinguished attribute of the entry. If any value other than "TRUE" or "FALSE" is contained in the deleteOldRDN attribute, or if the deleteOldRDN contains multiple values, the RDN should be retained as a distinguished attribute (that is, "FALSE" is the default if no values are present, or if illegal values are present). Syntax: BOOLEAN newSuperior: if present, gives the name of the entry which becomes the immediate superior of the existing entry. This optional attribute reflects LDAPv3 functionality, and MUST NOT be generated by LDAPv2 servers [2]. Syntax: DN Discussion of the changeLogEntry object class The changeLogEntry object class is used to represent changes made to a= directory server. The set of changes made to a directory server, then= , is given by the ordered set of all entries within the changelog container, ordered by changeNumber. A client may synchronize its local copy of a remote directory server's= contents by searching the remote server's changelog container for any entries where the changenumber is greater than or equal to the last change previously retrieved from that server. If the entry with the changenumber matching the last change retrieved is not returned in the= search results, then the server's changelog has been trimmed. The client must then fall back to reading the entire directory to bring it= s copy in sync with the server's. Assuming that the client has successfully retrieved one or more change= log entries from the server, it can then use the information contained in = each entry to update the corresponding entry (named by the targetDN attribu= te) in its local copy of the database. Note that, due to access control restrictions, the client is not guara= nteed read access to the "changes" attribute. If the client discovers that = the "changes" attribute has no values, then it must read the entry given b= y the targetDN attribute, possibly only retrieving attributes it deems "interesting". However, in the case of delete and modrdn operations, = there is never a "changes" attribute, so it is never necessary to read the t= arget entry in these cases. Good Expires 19 January 2002 [Page 4] =0C INTERNET-DRAFT Change Record Object Class 19 July 2001 Examples of the changeLogEntry object class In each example below, the "changes" attribute is shown in plain text,= with embedded newlines. This is done for clarity. It is intended tha= t newlines be stored in the entry literally, not encoded in any way. If a "changes" attribute value is stored in an LDIF file, it must base-64 encoded. Example 1: A changeLogEntry representing the addition of a new entry to the directory dn: changenumber=3D1923, cn=3Dchangelog changenumber: 1923 targetdn: cn=3DBarbara Jensen, ou=3DAccounting, o=3DAce Industry, c=3D= US changetype: add changes: cn: Barbara Jensen\ncn: Babs Jensen\nsn: Jensen\n givenname: Barbara\ntelephonenumber: +1 212 555-1212\nmail: babs@ace.= com\n objectclass: top\nobjectclass: person\nobjectclass: organizationalPer= son\n objectclass: inetOrgPerson Example 2: A changeLogEntry representing the deletion of an entry from the directory dn: changenumber=3D2933, cn=3Dchangelog changenumber: 2933 targetdn: cn=3DGern Jensen, ou=3DProduct Testing, o=3DAce Industry, c=3D= US changetype: delete Example 3: A changeLogEntry representing the modification of an entry in the directory dn: changenumber=3D5883, cn=3Dchangelog changenumber: 5883 targetdn: cn=3DBjorn Jensen, ou=3DProduct Development, o=3DAce Industr= y, c=3DUS changetype: modify changes: delete: telephonenumber\ntelephonenumber: 1212\n-\n add: telephonenumber\ntelephonenumber: +1 212 555 1212\n- Example 4: A changeLogEntry representing a modrdn operation performed on an entry in the directory dn: changenumber=3D10042, cn=3Dchangelog changenumber: 10042 targetdn: cn=3DBjorn Jensen, ou=3DProduct Development, o=3DAce Industr= y, c=3DUS changetype: modrdn newrdn: cn=3DBjorn J Jensen deleteoldrdn: FALSE Good Expires 19 January 2002 [Page 5] =0C INTERNET-DRAFT Change Record Object Class 19 July 2001 Location of the container containing changeLogEntry objects For LDAPv3 servers, the location of the container which holds changeLogEntry objects is obtained by reading the "changeLog" attribut= e of a server's root DSE. For example, if the container's root is "cn=3Dchangelog", then the root DSE must have an attribute named "changeLog" with the value "cn=3Dchangelog". The "changelog" attribute is defined as follows: ( 2.16.840.1.113730.3.1.35 NAME 'changelog' DESC 'the distinguished name of the entry which contains the set of entries comprising this server's changelog' EQUALITY distinguishedNameMatch SYNTAX 'DN' ) For LDAPv2 servers, the name of the changelog container must be "cn=3Dchangelog". Interoperability between LDAPv2 and LDAPv3 implementations Implementors are discouraged from developing implementations in which an LDAPv2 server is synchronized from an LDAPv3 server using the changelog method described in this document. Problems can arise when a= n LDAPv2 server reads a "moddn" changelog entry which gives a new superior. Since LDAPv2 does not support such an operation, there is no= t way for the v2 server to perform the moddn operation atomically. It could, of course, delete all the entries under the old superior and ad= d them under the new superior entry, but such an operation would either not be atomic, or require extensive server-side support on the LDAPv2 server to make the operation appear as if it were atomic. It is recommended that servers which only implement LDAPv2 should refuse to synchronize from LDAPv3 servers. Before beginning synchronization, the LDAPv2 server should attempt to read the root DSE= of the supplier server. If the root DSE is present, and the supportedldapversion attribute contained in the root DSE contains the value "3", then the LDAPv2 server should immediately disconnect and proceed no further with synchronization. Security Considerations Servers implementing this scheme MUST NOT allow the "changes" attribute to be generally readable. The "changes" attribute contains all modifications made to an entry, and some changes may contain sensitive data, e.g. passwords. Good Expires 19 January 2002 [Page 6] =0C INTERNET-DRAFT Change Record Object Class 19 July 2001 If a server does allow read access on the "changes: attribute to a particular bound DN, then that DN should be trusted. For example, two= cooperating servers may exchange the password for some DN which is granted read access to the "changes" attribute of the changeLog. This= would allow one server to retrieve changes and apply them directly to its database. In situations where the "changes" attribute is not readable by a clien= t, that client may still use the entries in the changeLog to construct a list of entry DNs which are known to have changed since the last time the client synchronized. The client may then read each of those entri= es, subject to whatever access control is in effect on the server, and update its local copy of each entry. Servers implementing this scheme should disallow write access to the changelog container object and all entries contained within. Acknowledgements This material is based in part upon work supported by the National Science Foundation under Grant No. NCR-9416667. References [1] Good, G., "The LDAP Data Interchange Format (LDIF) - Technical Specification", RFC 2849 iPlanet e-commerce Solutions, June 2000, [2] Wahl, M., Howes, T., Kille, S., "Lightweight Directory Access Protocol (v3)", RFC 2251 Critical Angle, Inc., Netscape Communications= Corp., ISODE Consortium, July, 1997, [3] S. Bradner, "Key Words for use in RFCs to Indicate Requirement Levels", Harvard University, RFC 2119, March 1997, Authors' Addresses Gordon Good Loudcloud, Inc. 599 N. Mathilda Avenue Sunnyvale, CA 94085 Good Expires 19 January 2002 [Page 7] =0C INTERNET-DRAFT Change Record Object Class 19 July 2001 USA Phone: +1 408 744-7300 EMail: ggood@loudcloud.com Ludovic Poitou Sun Microsystems Inc. 32 Chemin du vieux chene 38920 Meylan France Phone: +33 476 188 212 Email: ludovic.poitou@sun.com Good Expires 19 January 2002 [Page 8] =0C --------------454482E795D1A8680588F9A5-- From owner-ietf-ldup@mail.imc.org Fri Jul 20 09:11:18 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA23041 for ; Fri, 20 Jul 2001 09:11:18 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.3/8.11.3) id f6KCrlZ27144 for ietf-ldup-bks; Fri, 20 Jul 2001 05:53:47 -0700 (PDT) Received: from hawk.ummail.com (hawk.ummail.com [64.58.86.57]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f6KCrkq27140 for ; Fri, 20 Jul 2001 05:53:46 -0700 (PDT) Received: from ex01.ummail.com (ex01.ummail.com [216.33.108.253:25]) by hawk.ummail.com with ESMTP id D0720-0853-364d00; Fri, 20 Jul 2001 12:53:21 GMT Received: by ex01.ummail.com with Internet Mail Service (5.5.2650.21) id <392HCXSS>; Fri, 20 Jul 2001 08:53:19 -0400 Message-ID: From: Christopher Apple To: "'paf@cisco.com'" , "'ned.freed@mrochek.com'" Cc: "'ietf-ldup@imc.org'" , "John Strassner (E-mail)" Subject: FW: I-D ACTION:draft-ietf-ldup-replica-req-10.txt Date: Fri, 20 Jul 2001 08:53:18 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) MIME-Version: 1.0 Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; boundary="----=_NextPart_000_0014_01C110F9.03524930"; micalg=SHA1 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: owner-ietf-ldup@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multi-part message in MIME format. ------=_NextPart_000_0014_01C110F9.03524930 Content-Type: multipart/mixed; boundary="----=_NextPart_001_0015_01C110F9.03524930" ------=_NextPart_001_0015_01C110F9.03524930 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Patrik & Ned, This document revision represents WG consensus on LDUP Requirements and incorporates WG Last Call comments. We believe the document is ready for IETF Last Call and request that it be reviewed by the IESG. Chris Apple Program Manager - Directory Services United Messaging Inc. (V) 610-425-2860 ------=_NextPart_001_0015_01C110F9.03524930 Content-Type: message/rfc822 Content-Disposition: attachment Reply-To: From: Cc: Subject: I-D ACTION:draft-ietf-ldup-replica-req-10.txt Date: Fri, 20 Jul 2001 05:37:07 -0400 Message-ID: <200107200937.FAA06318@ietf.org> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_0010_01C110F9.033E4C00" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2910.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Importance: Normal List-Unsubscribe: This is a multi-part message in MIME format. ------=_NextPart_000_0010_01C110F9.033E4C00 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the LDAP Duplication/Replication/Update Protocols Working Group of the IETF. Title : LDAPv3 Replication Requirements Author(s) : E. Stokes, R. Weiser, R. Moats, R. Huber Filename : draft-ietf-ldup-replica-req-10.txt Pages : 30 Date : 19-Jul-01 This document discusses the fundamental requirements for replication of data accessible via the LDAPv3 [RFC2251] protocol. It is intended to be a gathering place for general replication requirements needed to provide interoperability between informational directories. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ldup-replica-req-10.txt Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-ldup-replica-req-10.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-ldup-replica-req-10.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. ------=_NextPart_000_0010_01C110F9.033E4C00 Content-Type: message/rfc822 Content-Disposition: attachment MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_000F_01C110F9.033E4C00" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2910.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Importance: Normal This is a multi-part message in MIME format. ------=_NextPart_000_000F_01C110F9.033E4C00 Content-Type: Message/External-body; name="ATT17059" Content-Disposition: attachment; filename="ATT17059" Content-Transfer-Encoding: 7bit Content-type: message/external-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20010719150035.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ldup-replica-req-10.txt ------=_NextPart_000_000F_01C110F9.033E4C00 Content-Type: Message/External-body; name="draft-ietf-ldup-replica-req-10.url" Content-Disposition: attachment; filename="draft-ietf-ldup-replica-req-10.url" Content-Transfer-Encoding: 7bit [InternetShortcut] URL=ftp://ftp.ietf.org/internet-drafts/draft-ietf-ldup-replica-req-10.txt ------=_NextPart_000_000F_01C110F9.033E4C00-- ------=_NextPart_000_0010_01C110F9.033E4C00-- ------=_NextPart_001_0015_01C110F9.03524930 Content-Type: text/x-vcard; name="Chris Apple (E-mail).vcf" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="Chris Apple (E-mail).vcf" Content-Transfer-Encoding: quoted-printable BEGIN:VCARD VERSION:2.1 N:Apple;Chris FN:Chris Apple (E-mail) ORG:UMI TITLE:Program Manager TEL;WORK;VOICE:(610) 425-2860 TEL;HOME;VOICE:(215) 873-0850 TEL;CELL;VOICE:(610) 585-4241 TEL;WORK;FAX:(610) 425-6501 ADR;WORK:;;1161 McDermott Drive;West Chester;Pa.;19380;United States of = America LABEL;WORK;ENCODING=3DQUOTED-PRINTABLE:1161 McDermott = Drive=3D0D=3D0AWest Chester, Pa. 19380=3D0D=3D0AUnited States of Amer=3D ica EMAIL;PREF;INTERNET:christopher.apple@unitedmessaging.com REV:20010621T205341Z END:VCARD ------=_NextPart_001_0015_01C110F9.03524930-- ------=_NextPart_000_0014_01C110F9.03524930 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIF1TCCAqQw ggINoAMCAQICAwT8XjANBgkqhkiG9w0BAQQFADCBkjELMAkGA1UEBhMCWkExFTATBgNVBAgTDFdl c3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3duMQ8wDQYDVQQKEwZUaGF3dGUxHTAbBgNVBAsT FENlcnRpZmljYXRlIFNlcnZpY2VzMSgwJgYDVQQDEx9QZXJzb25hbCBGcmVlbWFpbCBSU0EgMjAw MC44LjMwMB4XDTAxMDYwODE1NDgwOVoXDTAyMDYwODE1NDgwOVowVzEfMB0GA1UEAxMWVGhhd3Rl IEZyZWVtYWlsIE1lbWJlcjE0MDIGCSqGSIb3DQEJARYlY2hyaXN0b3BoZXIuYXBwbGVAdW5pdGVk bWVzc2FnaW5nLm5ldDCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEA0wb7dpXj0lZuRfGhErPC qQTyvOGL3DHONyKLfJEfbD3A/0zqEnkjKamgGiD7PVFc0Gwok9x/2Jl/mQO52ArIPO0AkSYY/KaZ mWKaFXxh1LedYLyNb5PRe1kN6y0EAva1D4nwyZmToJMBUqLNsvMGjPmLUuBwdbHLEdAAVo7Gp6kC AwEAAaNCMEAwMAYDVR0RBCkwJ4ElY2hyaXN0b3BoZXIuYXBwbGVAdW5pdGVkbWVzc2FnaW5nLm5l dDAMBgNVHRMBAf8EAjAAMA0GCSqGSIb3DQEBBAUAA4GBAIqkT3GDgyKLYOzIJ9h/OsiFbiefYTbc ALptWnwegAeXbfjhq+BUJN2ICWxfQtTCupvAG6mW4J2qI422TLc31Gf7uu5r93ppFDrCGYAM2mgH tqKgztYQmAsGPf2TijDOeE7JRbQ7dZJu4BJvuE3SY9PdI/umjiOh/WG/gaZNdl0bMIIDKTCCApKg AwIBAgIBDDANBgkqhkiG9w0BAQQFADCB0TELMAkGA1UEBhMCWkExFTATBgNVBAgTDFdlc3Rlcm4g Q2FwZTESMBAGA1UEBxMJQ2FwZSBUb3duMRowGAYDVQQKExFUaGF3dGUgQ29uc3VsdGluZzEoMCYG A1UECxMfQ2VydGlmaWNhdGlvbiBTZXJ2aWNlcyBEaXZpc2lvbjEkMCIGA1UEAxMbVGhhd3RlIFBl cnNvbmFsIEZyZWVtYWlsIENBMSswKQYJKoZIhvcNAQkBFhxwZXJzb25hbC1mcmVlbWFpbEB0aGF3 dGUuY29tMB4XDTAwMDgzMDAwMDAwMFoXDTAyMDgyOTIzNTk1OVowgZIxCzAJBgNVBAYTAlpBMRUw EwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEPMA0GA1UEChMGVGhhd3Rl MR0wGwYDVQQLExRDZXJ0aWZpY2F0ZSBTZXJ2aWNlczEoMCYGA1UEAxMfUGVyc29uYWwgRnJlZW1h aWwgUlNBIDIwMDAuOC4zMDCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEA3jMypmPHCSVFPtJu eCdngcXaiBmClw7jRCmKYzUqbXA8+tyu9+50bzC8M5B/+TRxoKNtmPHDT6Jl2w36S/HW3WGl+YXN VZo1Gp2Sdagnrthy+boC9tewkd4c6avgGAOofENCUFGHgzzwObSbVIoTh/+zm51JZgAtCYnslGvp oWkCAwEAAaNOMEwwKQYDVR0RBCIwIKQeMBwxGjAYBgNVBAMTEVByaXZhdGVMYWJlbDEtMjk3MBIG A1UdEwEB/wQIMAYBAf8CAQAwCwYDVR0PBAQDAgEGMA0GCSqGSIb3DQEBBAUAA4GBAHMbbyZli/8V NEtZYortRL5Jx+gNu4+5DWomKmKEH7iHY3QcbbfPGlORS+HN5jjZ7VD0Omw0kqzmkpxuwSMBwgmn 70uuct0GZ/VQby5YuLYLwVBXtewc1+8XttWIm7eiiBrtOVs5fTT8tpYYJU1q9J3Fw5EvqZa4BTxS /N3pYgNIMYICqjCCAqYCAQEwgZowgZIxCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENh cGUxEjAQBgNVBAcTCUNhcGUgVG93bjEPMA0GA1UEChMGVGhhd3RlMR0wGwYDVQQLExRDZXJ0aWZp Y2F0ZSBTZXJ2aWNlczEoMCYGA1UEAxMfUGVyc29uYWwgRnJlZW1haWwgUlNBIDIwMDAuOC4zMAID BPxeMAkGBSsOAwIaBQCgggFlMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkF MQ8XDTAxMDcyMDEyNTAyM1owIwYJKoZIhvcNAQkEMRYEFMt9EvnqcmW4na/ioXAsml5gogczMFgG CSqGSIb3DQEJDzFLMEkwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwICAgCAMAcGBSsOAwIHMA0GCCqG SIb3DQMCAgEoMAcGBSsOAwIaMAoGCCqGSIb3DQIFMIGrBgkrBgEEAYI3EAQxgZ0wgZowgZIxCzAJ BgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEPMA0G A1UEChMGVGhhd3RlMR0wGwYDVQQLExRDZXJ0aWZpY2F0ZSBTZXJ2aWNlczEoMCYGA1UEAxMfUGVy c29uYWwgRnJlZW1haWwgUlNBIDIwMDAuOC4zMAIDBPxeMA0GCSqGSIb3DQEBAQUABIGAShHGOkvl WEILL3RRo6MCrCOQTh+l1NlklQCJzzAnSIIDOj2ABgUao29U5VGUXyZnlFu/QvrIotIC6DnB+qIJ JkUEV5i1Zeti71gbKSAAEfB6fpo6jxwLLZjyTDfMzRd5uJ+92o854TQApzq7D02oAnR1Tp9Ksva2 dfSWSJuYJkoAAAAAAAA= ------=_NextPart_000_0014_01C110F9.03524930-- From owner-ietf-ldup@mail.imc.org Fri Jul 20 09:17:01 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA23905 for ; Fri, 20 Jul 2001 09:17:00 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.3/8.11.3) id f6KD1ak27382 for ietf-ldup-bks; Fri, 20 Jul 2001 06:01:36 -0700 (PDT) Received: from hawk.ummail.com (hawk.ummail.com [64.58.86.20]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f6KD1Zq27378 for ; Fri, 20 Jul 2001 06:01:35 -0700 (PDT) Received: from ex01.ummail.com (ex01.ummail.com [216.33.108.253:25]) by hawk.ummail.com with ESMTP id W0720-0901-74a200; Fri, 20 Jul 2001 13:01:27 GMT Received: by ex01.ummail.com with Internet Mail Service (5.5.2650.21) id <392HCXSY>; Fri, 20 Jul 2001 09:01:25 -0400 Message-ID: From: Christopher Apple To: "'ietf-ldup@imc.org'" Cc: "John Strassner (E-mail)" Subject: RE: LDUP WG Agenda Date: Fri, 20 Jul 2001 09:01:25 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) MIME-Version: 1.0 Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; boundary="----=_NextPart_000_0022_01C110FA.23C4E820"; micalg=SHA1 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: owner-ietf-ldup@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multi-part message in MIME format. ------=_NextPart_000_0022_01C110FA.23C4E820 Content-Type: multipart/mixed; boundary="----=_NextPart_001_0023_01C110FA.23C4E820" ------=_NextPart_001_0023_01C110FA.23C4E820 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit A revised WG Agenda. Comments are welcome as are suggestions/requests for additional agenda items. 1) LDAPv3 Replication Requirements http://www.ietf.org/internet-drafts/draft-ietf-ldup-replica-req-10.txt - passed WG Last Call - Request sent to Applications Area ADs for IESG Review 2) LDUP Update Reconciliation Procedures http://www.ietf.org/internet-drafts/draft-ietf-ldup-urp-04.txt 3) LDAP Replication Architecture http://www.ietf.org/internet-drafts/draft-ietf-ldup-model-06.txt 4) LDUP Replication Information Model http://www.ietf.org/internet-drafts/draft-ietf-ldup-infomod-03.txt 5) LDAP Subentry Schema http://www.ietf.org/internet-drafts/draft-ietf-ldup-subentry-08.txt 6) General Usage Profile for LDAPv3 Replication http://www.ietf.org/internet-drafts/draft-ietf-ldup-usage-profile-00.txt -01.txt revision should be published by I-D Editor soon 7) LDAP Client Update Protocol http://www.ietf.org/internet-drafts/draft-ietf-ldup-lcup-01.txt 8) Adding LCUP Cookie Scheme(s) to LDUP WG Charter as Deliverables? 9) LDAP Access Control Model Work 10) General Charter Review Chris Apple Program Manager - Directory Services United Messaging Inc. (V) 610-425-2860 ------=_NextPart_001_0023_01C110FA.23C4E820 Content-Type: text/x-vcard; name="Chris Apple (E-mail).vcf" Content-Disposition: attachment; filename="Chris Apple (E-mail).vcf" Content-Transfer-Encoding: quoted-printable BEGIN:VCARD VERSION:2.1 N:Apple;Chris FN:Chris Apple (E-mail) ORG:UMI TITLE:Program Manager TEL;WORK;VOICE:(610) 425-2860 TEL;HOME;VOICE:(215) 873-0850 TEL;CELL;VOICE:(610) 585-4241 TEL;WORK;FAX:(610) 425-6501 ADR;WORK:;;1161 McDermott Drive;West Chester;Pa.;19380;United States of = America LABEL;WORK;ENCODING=3DQUOTED-PRINTABLE:1161 McDermott = Drive=3D0D=3D0AWest Chester, Pa. 19380=3D0D=3D0AUnited States of Amer=3D ica EMAIL;PREF;INTERNET:christopher.apple@unitedmessaging.com REV:20010621T205341Z END:VCARD ------=_NextPart_001_0023_01C110FA.23C4E820-- ------=_NextPart_000_0022_01C110FA.23C4E820 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIF1TCCAqQw ggINoAMCAQICAwT8XjANBgkqhkiG9w0BAQQFADCBkjELMAkGA1UEBhMCWkExFTATBgNVBAgTDFdl c3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3duMQ8wDQYDVQQKEwZUaGF3dGUxHTAbBgNVBAsT FENlcnRpZmljYXRlIFNlcnZpY2VzMSgwJgYDVQQDEx9QZXJzb25hbCBGcmVlbWFpbCBSU0EgMjAw MC44LjMwMB4XDTAxMDYwODE1NDgwOVoXDTAyMDYwODE1NDgwOVowVzEfMB0GA1UEAxMWVGhhd3Rl IEZyZWVtYWlsIE1lbWJlcjE0MDIGCSqGSIb3DQEJARYlY2hyaXN0b3BoZXIuYXBwbGVAdW5pdGVk bWVzc2FnaW5nLm5ldDCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEA0wb7dpXj0lZuRfGhErPC qQTyvOGL3DHONyKLfJEfbD3A/0zqEnkjKamgGiD7PVFc0Gwok9x/2Jl/mQO52ArIPO0AkSYY/KaZ mWKaFXxh1LedYLyNb5PRe1kN6y0EAva1D4nwyZmToJMBUqLNsvMGjPmLUuBwdbHLEdAAVo7Gp6kC AwEAAaNCMEAwMAYDVR0RBCkwJ4ElY2hyaXN0b3BoZXIuYXBwbGVAdW5pdGVkbWVzc2FnaW5nLm5l dDAMBgNVHRMBAf8EAjAAMA0GCSqGSIb3DQEBBAUAA4GBAIqkT3GDgyKLYOzIJ9h/OsiFbiefYTbc ALptWnwegAeXbfjhq+BUJN2ICWxfQtTCupvAG6mW4J2qI422TLc31Gf7uu5r93ppFDrCGYAM2mgH tqKgztYQmAsGPf2TijDOeE7JRbQ7dZJu4BJvuE3SY9PdI/umjiOh/WG/gaZNdl0bMIIDKTCCApKg AwIBAgIBDDANBgkqhkiG9w0BAQQFADCB0TELMAkGA1UEBhMCWkExFTATBgNVBAgTDFdlc3Rlcm4g Q2FwZTESMBAGA1UEBxMJQ2FwZSBUb3duMRowGAYDVQQKExFUaGF3dGUgQ29uc3VsdGluZzEoMCYG A1UECxMfQ2VydGlmaWNhdGlvbiBTZXJ2aWNlcyBEaXZpc2lvbjEkMCIGA1UEAxMbVGhhd3RlIFBl cnNvbmFsIEZyZWVtYWlsIENBMSswKQYJKoZIhvcNAQkBFhxwZXJzb25hbC1mcmVlbWFpbEB0aGF3 dGUuY29tMB4XDTAwMDgzMDAwMDAwMFoXDTAyMDgyOTIzNTk1OVowgZIxCzAJBgNVBAYTAlpBMRUw EwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEPMA0GA1UEChMGVGhhd3Rl MR0wGwYDVQQLExRDZXJ0aWZpY2F0ZSBTZXJ2aWNlczEoMCYGA1UEAxMfUGVyc29uYWwgRnJlZW1h aWwgUlNBIDIwMDAuOC4zMDCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEA3jMypmPHCSVFPtJu eCdngcXaiBmClw7jRCmKYzUqbXA8+tyu9+50bzC8M5B/+TRxoKNtmPHDT6Jl2w36S/HW3WGl+YXN VZo1Gp2Sdagnrthy+boC9tewkd4c6avgGAOofENCUFGHgzzwObSbVIoTh/+zm51JZgAtCYnslGvp oWkCAwEAAaNOMEwwKQYDVR0RBCIwIKQeMBwxGjAYBgNVBAMTEVByaXZhdGVMYWJlbDEtMjk3MBIG A1UdEwEB/wQIMAYBAf8CAQAwCwYDVR0PBAQDAgEGMA0GCSqGSIb3DQEBBAUAA4GBAHMbbyZli/8V NEtZYortRL5Jx+gNu4+5DWomKmKEH7iHY3QcbbfPGlORS+HN5jjZ7VD0Omw0kqzmkpxuwSMBwgmn 70uuct0GZ/VQby5YuLYLwVBXtewc1+8XttWIm7eiiBrtOVs5fTT8tpYYJU1q9J3Fw5EvqZa4BTxS /N3pYgNIMYICqjCCAqYCAQEwgZowgZIxCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENh cGUxEjAQBgNVBAcTCUNhcGUgVG93bjEPMA0GA1UEChMGVGhhd3RlMR0wGwYDVQQLExRDZXJ0aWZp Y2F0ZSBTZXJ2aWNlczEoMCYGA1UEAxMfUGVyc29uYWwgRnJlZW1haWwgUlNBIDIwMDAuOC4zMAID BPxeMAkGBSsOAwIaBQCgggFlMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkF MQ8XDTAxMDcyMDEyNTgyNFowIwYJKoZIhvcNAQkEMRYEFPrAosaASkJyLYgndkGL86UxErafMFgG CSqGSIb3DQEJDzFLMEkwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwICAgCAMAcGBSsOAwIHMA0GCCqG SIb3DQMCAgEoMAcGBSsOAwIaMAoGCCqGSIb3DQIFMIGrBgkrBgEEAYI3EAQxgZ0wgZowgZIxCzAJ BgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEPMA0G A1UEChMGVGhhd3RlMR0wGwYDVQQLExRDZXJ0aWZpY2F0ZSBTZXJ2aWNlczEoMCYGA1UEAxMfUGVy c29uYWwgRnJlZW1haWwgUlNBIDIwMDAuOC4zMAIDBPxeMA0GCSqGSIb3DQEBAQUABIGABuKVEBma EIAphghyns5PsTb3AyXnzJIXGOZ4yZRpzBgI54UqmtqlJHCaJJKvO16U8ZsREWAylglJWlVKcYlq 1t83qXadF1crhX/iGWFxa5GUFJ7bOY4p/uQ8+ZtvEljVDXV6X5JRlnbJ4YjmdtKoK5s+G1lmLOz9 sBMAG2UV5NAAAAAAAAA= ------=_NextPart_000_0022_01C110FA.23C4E820-- From owner-ietf-ldup@mail.imc.org Mon Jul 23 07:18:16 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA10999 for ; Mon, 23 Jul 2001 07:18:14 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.3/8.11.3) id f6NAtn916627 for ietf-ldup-bks; Mon, 23 Jul 2001 03:55:49 -0700 (PDT) Received: from ietf.org (odin.ietf.org [132.151.1.176]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f6NAtlq16623 for ; Mon, 23 Jul 2001 03:55:47 -0700 (PDT) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA09782; Mon, 23 Jul 2001 06:54:46 -0400 (EDT) Message-Id: <200107231054.GAA09782@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: ietf-ldup@imc.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-ldup-usage-profile-01.txt Date: Mon, 23 Jul 2001 06:54:46 -0400 Sender: owner-ietf-ldup@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the LDAP Duplication/Replication/Update Protocols Working Group of the IETF. Title : General Usage Profile for LDAPv3 Replication Author(s) : R. Huber et al. Filename : draft-ietf-ldup-usage-profile-01.txt Pages : 18 Date : 20-Jul-01 Support for replication in LDAP directory systems is often one of the key factors in the decision to deploy them. But replication brings design constraints along with its benefits. We discuss some of the factors that should be taken into consideration when designing a replicated directory system. Both programming and architectural/operational concerns are addressed. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ldup-usage-profile-01.txt Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-ldup-usage-profile-01.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-ldup-usage-profile-01.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20010720083052.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ldup-usage-profile-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ldup-usage-profile-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20010720083052.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ietf-ldup@mail.imc.org Mon Jul 23 15:05:39 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA16459 for ; Mon, 23 Jul 2001 15:05:38 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.3/8.11.3) id f6NIlG402227 for ietf-ldup-bks; Mon, 23 Jul 2001 11:47:16 -0700 (PDT) Received: from hawk.ummail.com (hawk.ummail.com [64.58.86.57]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f6NIlEq02222 for ; Mon, 23 Jul 2001 11:47:15 -0700 (PDT) Received: from ex01.ummail.com (ex01.ummail.com [216.33.108.253:25]) by hawk.ummail.com with ESMTP id Q0723-1447-5b9100; Mon, 23 Jul 2001 18:47:02 GMT Received: by ex01.ummail.com with Internet Mail Service (5.5.2650.21) id <392HCYYZ>; Mon, 23 Jul 2001 14:46:55 -0400 Message-ID: From: Christopher Apple To: "'ietf-ldup@imc.org'" Cc: "John Strassner (E-mail)" Subject: RE: LDUP WG Agenda Date: Mon, 23 Jul 2001 14:46:55 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) MIME-Version: 1.0 Content-Type: multipart/signed; micalg=SHA1; boundary="----=_NextPart_000_000D_01C11385.E2B2EEC0"; protocol="application/x-pkcs7-signature" X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: owner-ietf-ldup@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multi-part message in MIME format. ------=_NextPart_000_000D_01C11385.E2B2EEC0 Content-Type: multipart/mixed; boundary="----=_NextPart_001_000E_01C11385.E2B2EEC0" ------=_NextPart_001_000E_01C11385.E2B2EEC0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Another WG Agenda Revision. I plan to send this as the official WG Agenda 1700 ET, Wednesday, July 25, 2001. Please send comments/additions before then. 1) LDAPv3 Replication Requirements http://www.ietf.org/internet-drafts/draft-ietf-ldup-replica-req-10.txt - passed WG Last Call - Request sent to Applications Area ADs for IESG Review 2) LDUP Update Reconciliation Procedures http://www.ietf.org/internet-drafts/draft-ietf-ldup-urp-04.txt 3) LDAP Replication Architecture http://www.ietf.org/internet-drafts/draft-ietf-ldup-model-06.txt 4) LDUP Replication Information Model http://www.ietf.org/internet-drafts/draft-ietf-ldup-infomod-03.txt 5) LDAP Subentry Schema http://www.ietf.org/internet-drafts/draft-ietf-ldup-subentry-08.txt 6) General Usage Profile for LDAPv3 Replication http://www.ietf.org/internet-drafts/draft-ietf-ldup-usage-profile-01.txt 7) LDAP Client Update Protocol http://www.ietf.org/internet-drafts/draft-ietf-ldup-lcup-01.txt 8) Adding LCUP Cookie Scheme(s) to LDUP WG Charter as Deliverables? 9) LDAP Access Control Model Work 10) General Charter Review Chris Apple Program Manager - Directory Services United Messaging Inc. (V) 610-425-2860 >-----Original Message----- >From: Christopher Apple >[mailto:christopher.apple@UnitedMessaging.net] >Sent: Friday, July 20, 2001 9:01 AM >To: 'ietf-ldup@imc.org' >Cc: John Strassner (E-mail) >Subject: RE: LDUP WG Agenda > > >A revised WG Agenda. > >Comments are welcome as are suggestions/requests for >additional agenda items. > Chris Apple Program Manager - Directory Services United Messaging Inc. (V) 610-425-2860 ------=_NextPart_001_000E_01C11385.E2B2EEC0 Content-Type: text/x-vcard; name="Chris Apple (E-mail).vcf" Content-Disposition: attachment; filename="Chris Apple (E-mail).vcf" Content-Transfer-Encoding: quoted-printable BEGIN:VCARD VERSION:2.1 N:Apple;Chris FN:Chris Apple (E-mail) ORG:UMI TITLE:Program Manager TEL;WORK;VOICE:(610) 425-2860 TEL;HOME;VOICE:(215) 873-0850 TEL;CELL;VOICE:(610) 585-4241 TEL;WORK;FAX:(610) 425-6501 ADR;WORK:;;1161 McDermott Drive;West Chester;Pa.;19380;United States of = America LABEL;WORK;ENCODING=3DQUOTED-PRINTABLE:1161 McDermott = Drive=3D0D=3D0AWest Chester, Pa. 19380=3D0D=3D0AUnited States of Amer=3D ica EMAIL;PREF;INTERNET:christopher.apple@unitedmessaging.com REV:20010621T205341Z END:VCARD ------=_NextPart_001_000E_01C11385.E2B2EEC0-- ------=_NextPart_000_000D_01C11385.E2B2EEC0 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIF1TCCAqQw ggINoAMCAQICAwT8XjANBgkqhkiG9w0BAQQFADCBkjELMAkGA1UEBhMCWkExFTATBgNVBAgTDFdl c3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3duMQ8wDQYDVQQKEwZUaGF3dGUxHTAbBgNVBAsT FENlcnRpZmljYXRlIFNlcnZpY2VzMSgwJgYDVQQDEx9QZXJzb25hbCBGcmVlbWFpbCBSU0EgMjAw MC44LjMwMB4XDTAxMDYwODE1NDgwOVoXDTAyMDYwODE1NDgwOVowVzEfMB0GA1UEAxMWVGhhd3Rl IEZyZWVtYWlsIE1lbWJlcjE0MDIGCSqGSIb3DQEJARYlY2hyaXN0b3BoZXIuYXBwbGVAdW5pdGVk bWVzc2FnaW5nLm5ldDCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEA0wb7dpXj0lZuRfGhErPC qQTyvOGL3DHONyKLfJEfbD3A/0zqEnkjKamgGiD7PVFc0Gwok9x/2Jl/mQO52ArIPO0AkSYY/KaZ mWKaFXxh1LedYLyNb5PRe1kN6y0EAva1D4nwyZmToJMBUqLNsvMGjPmLUuBwdbHLEdAAVo7Gp6kC AwEAAaNCMEAwMAYDVR0RBCkwJ4ElY2hyaXN0b3BoZXIuYXBwbGVAdW5pdGVkbWVzc2FnaW5nLm5l dDAMBgNVHRMBAf8EAjAAMA0GCSqGSIb3DQEBBAUAA4GBAIqkT3GDgyKLYOzIJ9h/OsiFbiefYTbc ALptWnwegAeXbfjhq+BUJN2ICWxfQtTCupvAG6mW4J2qI422TLc31Gf7uu5r93ppFDrCGYAM2mgH tqKgztYQmAsGPf2TijDOeE7JRbQ7dZJu4BJvuE3SY9PdI/umjiOh/WG/gaZNdl0bMIIDKTCCApKg AwIBAgIBDDANBgkqhkiG9w0BAQQFADCB0TELMAkGA1UEBhMCWkExFTATBgNVBAgTDFdlc3Rlcm4g Q2FwZTESMBAGA1UEBxMJQ2FwZSBUb3duMRowGAYDVQQKExFUaGF3dGUgQ29uc3VsdGluZzEoMCYG A1UECxMfQ2VydGlmaWNhdGlvbiBTZXJ2aWNlcyBEaXZpc2lvbjEkMCIGA1UEAxMbVGhhd3RlIFBl cnNvbmFsIEZyZWVtYWlsIENBMSswKQYJKoZIhvcNAQkBFhxwZXJzb25hbC1mcmVlbWFpbEB0aGF3 dGUuY29tMB4XDTAwMDgzMDAwMDAwMFoXDTAyMDgyOTIzNTk1OVowgZIxCzAJBgNVBAYTAlpBMRUw EwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEPMA0GA1UEChMGVGhhd3Rl MR0wGwYDVQQLExRDZXJ0aWZpY2F0ZSBTZXJ2aWNlczEoMCYGA1UEAxMfUGVyc29uYWwgRnJlZW1h aWwgUlNBIDIwMDAuOC4zMDCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEA3jMypmPHCSVFPtJu eCdngcXaiBmClw7jRCmKYzUqbXA8+tyu9+50bzC8M5B/+TRxoKNtmPHDT6Jl2w36S/HW3WGl+YXN VZo1Gp2Sdagnrthy+boC9tewkd4c6avgGAOofENCUFGHgzzwObSbVIoTh/+zm51JZgAtCYnslGvp oWkCAwEAAaNOMEwwKQYDVR0RBCIwIKQeMBwxGjAYBgNVBAMTEVByaXZhdGVMYWJlbDEtMjk3MBIG A1UdEwEB/wQIMAYBAf8CAQAwCwYDVR0PBAQDAgEGMA0GCSqGSIb3DQEBBAUAA4GBAHMbbyZli/8V NEtZYortRL5Jx+gNu4+5DWomKmKEH7iHY3QcbbfPGlORS+HN5jjZ7VD0Omw0kqzmkpxuwSMBwgmn 70uuct0GZ/VQby5YuLYLwVBXtewc1+8XttWIm7eiiBrtOVs5fTT8tpYYJU1q9J3Fw5EvqZa4BTxS /N3pYgNIMYICqjCCAqYCAQEwgZowgZIxCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENh cGUxEjAQBgNVBAcTCUNhcGUgVG93bjEPMA0GA1UEChMGVGhhd3RlMR0wGwYDVQQLExRDZXJ0aWZp Y2F0ZSBTZXJ2aWNlczEoMCYGA1UEAxMfUGVyc29uYWwgRnJlZW1haWwgUlNBIDIwMDAuOC4zMAID BPxeMAkGBSsOAwIaBQCgggFlMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkF MQ8XDTAxMDcyMzE4NDM0OVowIwYJKoZIhvcNAQkEMRYEFIonJlmiGaFT+0kx+rvBhX9M65V0MFgG CSqGSIb3DQEJDzFLMEkwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwICAgCAMAcGBSsOAwIHMA0GCCqG SIb3DQMCAgEoMAcGBSsOAwIaMAoGCCqGSIb3DQIFMIGrBgkrBgEEAYI3EAQxgZ0wgZowgZIxCzAJ BgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEPMA0G A1UEChMGVGhhd3RlMR0wGwYDVQQLExRDZXJ0aWZpY2F0ZSBTZXJ2aWNlczEoMCYGA1UEAxMfUGVy c29uYWwgRnJlZW1haWwgUlNBIDIwMDAuOC4zMAIDBPxeMA0GCSqGSIb3DQEBAQUABIGAcyWem263 QF8+NDqNoSyMaP+c5xJTtgzIII+HEtrv0hpWqRqEj8cOqIf6S6m/zldq0zVnCYYs6MnAhSybJJyC m379y9Yjlk1Tr8rl/1roCM1jy9sC/sfFXwmoJ1WrKghNKRljJQfblgldkWSWTg2LJuoWjD9+W9fO 3RqSqCiAJacAAAAAAAA= ------=_NextPart_000_000D_01C11385.E2B2EEC0-- From owner-ietf-ldup@mail.imc.org Tue Jul 24 06:46:44 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id GAA07320 for ; Tue, 24 Jul 2001 06:46:43 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.3/8.11.3) id f6OAUf516854 for ietf-ldup-bks; Tue, 24 Jul 2001 03:30:41 -0700 (PDT) Received: from ietf.org (odin.ietf.org [132.151.1.176]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f6OAUdG16850 for ; Tue, 24 Jul 2001 03:30:40 -0700 (PDT) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA05924; Tue, 24 Jul 2001 06:29:40 -0400 (EDT) Message-Id: <200107241029.GAA05924@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; CC: ietf-ldapext@netscape.com, ietf-ldup@imc.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-good-ldap-changelog-02.txt Date: Tue, 24 Jul 2001 06:29:39 -0400 Sender: owner-ietf-ldup@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Definition of an Object Class to Hold LDAP Change Records Author(s) : G. Good, L. Poitou Filename : draft-good-ldap-changelog-02.txt Pages : 8 Date : 23-Jul-01 In order to support more flexible replication methods, it is desirable to specify some manner in which an LDAP client may retrieve a set of changes which have been applied to an LDAP server's database. The client, which may be another LDAP server, may then choose to update its own replicated copy of the data. This document specifies an object class which may be used to represent changes applied to an LDAP server. It also specifies a method for discovering the location of the container object which holds these change records, so that clients and servers have a common rendezvous point for this information. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-good-ldap-changelog-02.txt Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-good-ldap-changelog-02.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-good-ldap-changelog-02.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20010723140452.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-good-ldap-changelog-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-good-ldap-changelog-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20010723140452.I-D@ietf.org> --OtherAccess-- --NextPart--