From owner-ietf-ldup@mail.imc.org Mon Jun 4 11:10:06 2001 Received: from above.proper.com ([208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA09460 for ; Mon, 4 Jun 2001 11:10:06 -0400 (EDT) Received: (from majordomo@localhost) by above.proper.com (8.9.3/8.9.3) id HAA12151 for ietf-ldup-bks; Mon, 4 Jun 2001 07:36:31 -0700 (PDT) Received: from hawk.ummail.com (hawk.ummail.com [64.58.86.57]) by above.proper.com (8.9.3/8.9.3) with ESMTP id HAA12139 for ; Mon, 4 Jun 2001 07:36:25 -0700 (PDT) Received: from ex01.ummail.com [216.33.108.253:25] by hawk.ummail.com with SMTP id Q0604-1036-6f6400; Mon, 4 Jun 2001 14:36:00 GMT Received: by ex01.ummail.com with Internet Mail Service (5.5.2650.21) id ; Mon, 4 Jun 2001 10:34:43 -0400 Message-ID: From: Christopher Apple To: "'ietf-ldup@imc.org'" Cc: "John Strassner (E-mail)" Subject: WG Last Call Status of Requirements Document Date: Mon, 4 Jun 2001 10:34:42 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: multipart/mixed; boundary="----_=_NextPart_000_01C0ED03.7E4FFCF0" Sender: owner-ietf-ldup@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_000_01C0ED03.7E4FFCF0 Content-Type: text/plain; charset="iso-8859-1" LDUPers, Thanks for the spirited discussion about the requirements draft. Your co-chairs have reviewed all relevant mail threads and would like to proceed as follows. We believe that we are close to resolving all outstanding issues raised during the WG Last Call on the requirements draft. However, because we haven't reached consensus on three important issues, we are, at this point in time, not able to proceed as Co-Chairs normally would by making a recommendation to our ADs to take this draft to the IESG for consideration for IETF Last Call. To help move us along towards a successful WG Last Call we've summarized the WG discussion so far related to those three outstanding issues below. In these summaries, we have also proposed some new language for the requirements in question. We are not proposing this language to push the WG towards any particular solution. Rather, this language is mostly intended to spark discussion of the issues underlying the contention over the wording of these requirements. These issues appear to be mostly centered around implying rather than explicitly specifying whether or not certain security features such as confidentiality, integrity, authentication, and authorization can be "switched off by mutual agreement between replicas and sources" during the context of initiating a replication session. First, and not related to the security-related issues mentioned above, there was an open question on requirement G9. Here it is again for your convenience: G9. LDAP replication SHOULD support replication of directoryOperation and distributedOperation attribute types defined in standards track LDAP extensions. Future standards track specifications MUST include a "Replication Considerations" section which indicates how and whether the new feature operates in a replicated environment. Kurt wanted to remove the last sentence. The Co-Chairs believe that this requirement should be relaxed from a MUST to a SHOULD. While we both firmly support the spirit of the requirement, it will be very difficult to actually enforce. Furthermore, while we can enforce this in the LDUP WG, there are many non-LDUP-related controls/extensions that are being developed. We don't think that it is permissible or even possible for LDUP as a WG to act as a "policing force" for all Internet-related work. However, as discussed on the list, there are good reasons for making this requirement a SHOULD rather than omitting it. So, our proposed new text is: 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. Second, there is the S1 requirement. Kurt suggested some wording changes, but Chris and I would like to suggest some more that will help further clarify what the current requirement wording implies. First, the requirement and Kurt's suggested change: | > S1. During initiation of a replication session, authentication and | > verification of authorization of both the replica and the source | > directory MUST be allowed before any data is transferred. | I would suggest a cleaner wording: | S1. The protocol MUST support mutual authentication and verification | of authorization of the protocol's peers before allowing | replication data transfer. The problem is that there are several concepts that are jumbled together into a single requirement. We propose, as a starting point for discussion, the following three requirements to take the place of the above: S1a. The protocol MUST support mutual authentication of the source and the replica directories during initialization of a replication session. S1b. 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. S1c. The protocol MUST also support the initialization of anonymous replication sessions. Note that we explicitly discuss anonymous replication. We feel that this issue has been brushed under the table, and want to tease it out into the open. We are not explicitly recommending the support of this feature; rather, we want to gauge whether or not consensus has been achieved for including or excluding support of this in implementations. We also feel, based on list discussions, that one additional issue hasn't been fleshed out fully. This is the issue of whether a data set MAY be relevant to determining if these entities are authorized to actually follow through with the process of replicating the data. We note that the data set for which replication is being initiated MAY or MAY NOT itself be relevant to the actual process of authentication of the entities involved. We would recommend that some additional discussion regarding this point be undertaken on the list and that proposals be made for any additional requirements related to that discussion be posted to the list. The third requirement to continue discussion on is S2. It, along with Kurt's suggested change, is repeated here below for your convenience: | | > S2. The transport for LDAP synchronization MUST permit assurance of | | > the integrity and privacy of all data transferred. | S2. The replication protocol MUST support transfer of data with | integrity and confidentiality protection. | (I note this broadens the requirement) First, we note that definitions for confidentiality and integrity are not present in the draft. They should probably be added. But for the sake of our purposes, consider the following definitions: Confidentiality: the assurance of data privacy; no one may read the data except for the specific entity (or entities) intended. Integrity: the assurance of non-alteration of data; the data (either in transit or storage) has not been undetectably altered. Given these definitions, we'd like to start with Kurt's changes and move forward. The above definitions render the use of the word "protection" unnecessary. In fact, using that word in a requirements document seems to push too close into protocol design, based on reading many relevant texts on security technology and concepts. A system cannot legitimately provide assurance that data has remained private and/or was unaltered during transmission if appropriate cryptographic techniques are not employed to provide such protection. Thus we feel that the use of the word "protection" in this requirement pushes the document too close to the specification of the replication protocol itself. It would certainly be appropriate to include prose in the replication protocol document specifying a framework within which such protective measures should be implemented, but the requirements language proposed in this e-mail should be sufficient to result in such a framework actually being specified - which we believe is one thing that the requirements document is supposed to help the WG accomplish. The original requirement indicates (using language that is less than ideal) that we must be able to check on whether integrity and privacy were maintained during data transfer, whereas Kurt's says that the protocol itself MUST support data transfer with integrity and privacy and implies that implementations SHOULD NOT support data transfer without integrity and privacy features enabled. Whether or not anyone actually agrees about whether this implication exists is not in issue - that two people such as the co-chairs could independently come up with this as one of a few different interpretations of this requirement is. This indicates that the requirement is not explicit enough to avoid potential related interoperability problems. We would like to see some discussion of how it is envisioned that replication sessions operate in trusted environments. In particular, we are concerned with how integrity and/or confidentiality requirements may be levied against operational replication processes, taking into account the overhead those requirements imply. Some *service* implementers making use of LDAP replication are likely to want a replication protocol that enables them to decide whether or not integrity and confidentiality are really requirements for their particular operational scenario. Thus we are compelled to make the following proposal to decompose the original requirement as follows: S2a. The replication protocol MUST support transfer of data with integrity and confidentiality. S2b. The replication protocol MUST support the ability during initialization of a replication session for an authenticated source and replica to mutually decide to turn off data integrity and confidentiality within the context of and for the duration of that particular replication session. We are not stating that this particular wording should be used in the next revision of the requirements document. We are proposing it as a way of encouraging open discussion of an issue which is neither adequately, nor explicitly addressed in the requirements document. regards, John and Chris Chris Apple Program Manager - Directory Services United Messaging Inc. (V) 610-425-2860 ------_=_NextPart_000_01C0ED03.7E4FFCF0 Content-Type: application/octet-stream; name="Chris Apple (E-mail).vcf" Content-Disposition: attachment; filename="Chris Apple (E-mail).vcf" 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=QUOTED-PRINTABLE:1161 McDermott Drive=0D=0AWest Chester, Pa. 19380=0D=0AUnited States of Amer= ica ADR;HOME:;;214 New Street, Apt 4-N;Philadelphia;PA;19106;United States of America LABEL;HOME;ENCODING=QUOTED-PRINTABLE:214 New Street, Apt 4-N=0D=0APhiladelphia, PA 19106=0D=0AUnited States of Am= erica EMAIL;PREF;INTERNET:christopher.apple@unitedmessaging.com REV:20010413T223539Z END:VCARD ------_=_NextPart_000_01C0ED03.7E4FFCF0-- From owner-ietf-ldup@mail.imc.org Mon Jun 4 16:34:02 2001 Received: from above.proper.com ([208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA18806 for ; Mon, 4 Jun 2001 16:34:01 -0400 (EDT) Received: (from majordomo@localhost) by above.proper.com (8.9.3/8.9.3) id NAA00562 for ietf-ldup-bks; Mon, 4 Jun 2001 13:10:50 -0700 (PDT) Received: from hawk.ummail.com (hawk.ummail.com [216.33.108.233]) by above.proper.com (8.9.3/8.9.3) with ESMTP id NAA00554 for ; Mon, 4 Jun 2001 13:10:44 -0700 (PDT) Received: from ex01.ummail.com [216.33.108.253:25] by hawk.ummail.com with SMTP id Q0604-1610-20aa00; Mon, 4 Jun 2001 20:10:26 GMT Received: by ex01.ummail.com with Internet Mail Service (5.5.2650.21) id ; Mon, 4 Jun 2001 16:09:10 -0400 Message-ID: From: Christopher Apple To: "'ietf-ldup@imc.org'" Subject: RE: WG Last Call Status of Requirements Document Date: Mon, 4 Jun 2001 16:09:09 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: multipart/mixed; boundary="----_=_NextPart_000_01C0ED32.3761ADF0" Sender: owner-ietf-ldup@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_000_01C0ED32.3761ADF0 Content-Type: text/plain; charset="iso-8859-1" Rick Huber pointed out that a clarification was needed about the term "anonymous replication." What John and I had in mind when using this term is: Anonymous Replication - Replication where the endpoints are identified to each other but not authenticated. (To give credit where its due, that's one of a few definitions that Rick proposed; this one happens to fit our intent when using the term in the original posting.) Chris Apple Program Manager - Directory Services United Messaging Inc. (V) 610-425-2860 -----Original Message----- From: Christopher Apple [mailto:christopher.apple@UnitedMessaging.net] Sent: Monday, June 04, 2001 10:35 AM To: 'ietf-ldup@imc.org' Cc: John Strassner (E-mail) Subject: WG Last Call Status of Requirements Document LDUPers, Thanks for the spirited discussion about the requirements draft. Your co-chairs have reviewed all relevant mail threads and would like to proceed as follows. We believe that we are close to resolving all outstanding issues raised during the WG Last Call on the requirements draft. However, because we haven't reached consensus on three important issues, we are, at this point in time, not able to proceed as Co-Chairs normally would by making a recommendation to our ADs to take this draft to the IESG for consideration for IETF Last Call. To help move us along towards a successful WG Last Call we've summarized the WG discussion so far related to those three outstanding issues below. In these summaries, we have also proposed some new language for the requirements in question. We are not proposing this language to push the WG towards any particular solution. Rather, this language is mostly intended to spark discussion of the issues underlying the contention over the wording of these requirements. These issues appear to be mostly centered around implying rather than explicitly specifying whether or not certain security features such as confidentiality, integrity, authentication, and authorization can be "switched off by mutual agreement between replicas and sources" during the context of initiating a replication session. First, and not related to the security-related issues mentioned above, there was an open question on requirement G9. Here it is again for your convenience: G9. LDAP replication SHOULD support replication of directoryOperation and distributedOperation attribute types defined in standards track LDAP extensions. Future standards track specifications MUST include a "Replication Considerations" section which indicates how and whether the new feature operates in a replicated environment. Kurt wanted to remove the last sentence. The Co-Chairs believe that this requirement should be relaxed from a MUST to a SHOULD. While we both firmly support the spirit of the requirement, it will be very difficult to actually enforce. Furthermore, while we can enforce this in the LDUP WG, there are many non-LDUP-related controls/extensions that are being developed. We don't think that it is permissible or even possible for LDUP as a WG to act as a "policing force" for all Internet-related work. However, as discussed on the list, there are good reasons for making this requirement a SHOULD rather than omitting it. So, our proposed new text is: 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. Second, there is the S1 requirement. Kurt suggested some wording changes, but Chris and I would like to suggest some more that will help further clarify what the current requirement wording implies. First, the requirement and Kurt's suggested change: | > S1. During initiation of a replication session, authentication and | > verification of authorization of both the replica and the source | > directory MUST be allowed before any data is transferred. | I would suggest a cleaner wording: | S1. The protocol MUST support mutual authentication and verification | of authorization of the protocol's peers before allowing | replication data transfer. The problem is that there are several concepts that are jumbled together into a single requirement. We propose, as a starting point for discussion, the following three requirements to take the place of the above: S1a. The protocol MUST support mutual authentication of the source and the replica directories during initialization of a replication session. S1b. 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. S1c. The protocol MUST also support the initialization of anonymous replication sessions. Note that we explicitly discuss anonymous replication. We feel that this issue has been brushed under the table, and want to tease it out into the open. We are not explicitly recommending the support of this feature; rather, we want to gauge whether or not consensus has been achieved for including or excluding support of this in implementations. We also feel, based on list discussions, that one additional issue hasn't been fleshed out fully. This is the issue of whether a data set MAY be relevant to determining if these entities are authorized to actually follow through with the process of replicating the data. We note that the data set for which replication is being initiated MAY or MAY NOT itself be relevant to the actual process of authentication of the entities involved. We would recommend that some additional discussion regarding this point be undertaken on the list and that proposals be made for any additional requirements related to that discussion be posted to the list. The third requirement to continue discussion on is S2. It, along with Kurt's suggested change, is repeated here below for your convenience: | | > S2. The transport for LDAP synchronization MUST permit assurance of | | > the integrity and privacy of all data transferred. | S2. The replication protocol MUST support transfer of data with | integrity and confidentiality protection. | (I note this broadens the requirement) First, we note that definitions for confidentiality and integrity are not present in the draft. They should probably be added. But for the sake of our purposes, consider the following definitions: Confidentiality: the assurance of data privacy; no one may read the data except for the specific entity (or entities) intended. Integrity: the assurance of non-alteration of data; the data (either in transit or storage) has not been undetectably altered. Given these definitions, we'd like to start with Kurt's changes and move forward. The above definitions render the use of the word "protection" unnecessary. In fact, using that word in a requirements document seems to push too close into protocol design, based on reading many relevant texts on security technology and concepts. A system cannot legitimately provide assurance that data has remained private and/or was unaltered during transmission if appropriate cryptographic techniques are not employed to provide such protection. Thus we feel that the use of the word "protection" in this requirement pushes the document too close to the specification of the replication protocol itself. It would certainly be appropriate to include prose in the replication protocol document specifying a framework within which such protective measures should be implemented, but the requirements language proposed in this e-mail should be sufficient to result in such a framework actually being specified - which we believe is one thing that the requirements document is supposed to help the WG accomplish. The original requirement indicates (using language that is less than ideal) that we must be able to check on whether integrity and privacy were maintained during data transfer, whereas Kurt's says that the protocol itself MUST support data transfer with integrity and privacy and implies that implementations SHOULD NOT support data transfer without integrity and privacy features enabled. Whether or not anyone actually agrees about whether this implication exists is not in issue - that two people such as the co-chairs could independently come up with this as one of a few different interpretations of this requirement is. This indicates that the requirement is not explicit enough to avoid potential related interoperability problems. We would like to see some discussion of how it is envisioned that replication sessions operate in trusted environments. In particular, we are concerned with how integrity and/or confidentiality requirements may be levied against operational replication processes, taking into account the overhead those requirements imply. Some *service* implementers making use of LDAP replication are likely to want a replication protocol that enables them to decide whether or not integrity and confidentiality are really requirements for their particular operational scenario. Thus we are compelled to make the following proposal to decompose the original requirement as follows: S2a. The replication protocol MUST support transfer of data with integrity and confidentiality. S2b. The replication protocol MUST support the ability during initialization of a replication session for an authenticated source and replica to mutually decide to turn off data integrity and confidentiality within the context of and for the duration of that particular replication session. We are not stating that this particular wording should be used in the next revision of the requirements document. We are proposing it as a way of encouraging open discussion of an issue which is neither adequately, nor explicitly addressed in the requirements document. regards, John and Chris Chris Apple Program Manager - Directory Services United Messaging Inc. (V) 610-425-2860 ------_=_NextPart_000_01C0ED32.3761ADF0 Content-Type: application/octet-stream; name="Chris Apple (E-mail).vcf" Content-Disposition: attachment; filename="Chris Apple (E-mail).vcf" 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=QUOTED-PRINTABLE:1161 McDermott Drive=0D=0AWest Chester, Pa. 19380=0D=0AUnited States of Amer= ica ADR;HOME:;;214 New Street, Apt 4-N;Philadelphia;PA;19106;United States of America LABEL;HOME;ENCODING=QUOTED-PRINTABLE:214 New Street, Apt 4-N=0D=0APhiladelphia, PA 19106=0D=0AUnited States of Am= erica EMAIL;PREF;INTERNET:christopher.apple@unitedmessaging.com REV:20010413T223539Z END:VCARD ------_=_NextPart_000_01C0ED32.3761ADF0-- From owner-ietf-ldup@mail.imc.org Wed Jun 6 17:24:42 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA09363 for ; Wed, 6 Jun 2001 17:24:41 -0400 (EDT) Received: by above.proper.com (8.9.3/8.9.3) id OAA28443 for ietf-ldup-bks; Wed, 6 Jun 2001 14:07:32 -0700 (PDT) Received: from kcmso1.proxy.att.com (kcmso1.att.com [192.128.133.69]) by above.proper.com (8.9.3/8.9.3) with ESMTP id OAA28422 for ; Wed, 6 Jun 2001 14:07:26 -0700 (PDT) Received: from qsun.mt.att.com ([135.16.12.1]) by kcmso1.proxy.att.com (AT&T IPNS/MSO-3.0) with SMTP id f56L6iD07665; Wed, 6 Jun 2001 17:06:45 -0400 (EDT) Received: from att.com by qsun.mt.att.com (SMI-8.6/ATTEMS-1.4.1 sol2) id RAA08347; Wed, 6 Jun 2001 17:06:42 -0400 Message-ID: <3B1E9B1C.BE279C64@att.com> Date: Wed, 06 Jun 2001 17:05:33 -0400 From: Richard Huber X-Mailer: Mozilla 4.75 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: "'ietf-ldup@imc.org'" CC: Christopher Apple , "John Strassner (E-mail)" Subject: Re: WG Last Call Status of Requirements Document 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 The authors have discussed this comment. It seems to pertain more to architecture than requirements. Here's how we think it would work: - the identities of the two endpoints involved in replication are established during inititation of the replication session - the identity allows each party to find the appropriate replication agreement - the replication agreement specifies the area(s) of replication that these particular entities are allowed to replicate (among other parameters) In support of this view, we will add "area(s) of replication" to the list of items in requirement M7 that "MUST be defined in a standard location (e.g. the replication agreements)". Beyond that, this seems to be more of an architecture issue than a requirements issue, so we propose that any additional discussion be in the context of the architecture. If we've misunderstood the point of the comment, I'm sure you'll let us know :-) Rick Huber Christopher Apple wrote: > We also feel, based on list discussions, that one additional issue > hasn't been fleshed out fully. This is the issue of whether a data > set MAY be relevant to determining if these entities are authorized to > actually follow through with the process of replicating the data. We note > that the data set for which replication is being initiated MAY or MAY NOT > itself be relevant to the actual process of authentication of the entities > involved. We would recommend that some additional discussion regarding > this point be undertaken on the list and that proposals be made for any > additional requirements related to that discussion be posted to the list. > From owner-ietf-ldup@mail.imc.org Wed Jun 6 18:41: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 SAA10111 for ; Wed, 6 Jun 2001 18:41:21 -0400 (EDT) Received: (from majordomo@localhost) by above.proper.com (8.9.3/8.9.3) id PAA02112 for ietf-ldup-bks; Wed, 6 Jun 2001 15:18:35 -0700 (PDT) Received: from pretender.boolean.net (root@router.boolean.net [198.144.206.49]) by above.proper.com (8.9.3/8.9.3) with ESMTP id PAA02105 for ; Wed, 6 Jun 2001 15:18:28 -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 f56MGlp15749; Wed, 6 Jun 2001 22:16:47 GMT (envelope-from Kurt@OpenLDAP.org) Message-Id: <5.1.0.14.0.20010606143502.02f06980@127.0.0.1> X-Sender: kurt@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Wed, 06 Jun 2001 15:16:44 -0700 To: Christopher Apple From: "Kurt D. Zeilenga" Subject: Re: WG Last Call Status of Requirements Document Cc: "'ietf-ldup@imc.org'" , "John Strassner (E-mail)" 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 07:34 AM 6/4/2001, Christopher Apple wrote: >G9. LDAP replication SHOULD support replication of directoryOperation > and distributedOperation attribute types defined in standards track > LDAP extensions. Future standards track specifications MUST include a > "Replication Considerations" section which indicates how and whether > the new feature operates in a replicated environment. > >Kurt wanted to remove the last sentence. To reiterate: it is my opinion that this sentence does not state a requirement upon the LDUP architecture, model, protocol, or other aspect of LDUP WG charter work items. It is a requirement upon designers of other extensions to detail replication considerations. As such, I believe it is beyond the scope of this document. It would be more appropriately be defined in a document detailing how to design LDAP extensions (such as Bruce's I-D). I note as well that "requirement" I-Ds such are only guidelines meant to focus the work effort. While the LDUP WG is somewhat bound by its charter to work through a requirements process, others developing LDAP extensions can simply ignore this document. While I agree that it is appropriate for designers of extensions to note a wide variety of considerations, there is no need to mandate that all future standard track specifications contain such sections. I note that to address LDAP replication considerations in an LDAP extension document requires that there be some technical specification of LDAP replication. This is very little to consider (other than to say "This document does not consider LDAP replication issues as there is no standard track specification of LDAP replication"). This requirement attempts to put the cart before the horse. >The Co-Chairs believe that >this requirement should be relaxed from a MUST to a SHOULD. While we >both firmly support the spirit of the requirement, it will be very >difficult to actually enforce. Furthermore, while we can enforce >this in the LDUP WG, there are many non-LDUP-related controls/extensions >that are being developed. We don't think that it is permissible or even >possible for LDUP as a WG to act as a "policing force" for all >Internet-related work. However, as discussed on the list, there >are good reasons for making this requirement a SHOULD rather >than omitting it. The only reason I can see for such a requirement is so that someone can say to an author "You didn't fulfill this requirement". I would much rather this person say "You need to address replication issues such as ...". >So, our proposed new text is: > >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. Please note my objections to inclusion of this requirement as either a MUST or a SHOULD. I suggest that this sentence not use an RFC 2119 imperative. That is, I believe it should be worded as a suggestion to developers of future standard track specifications. >Second, there is the S1 requirement. Kurt suggested some wording changes, >but Chris and I would like to suggest some more that will help further >clarify what the current requirement wording implies. First, the >requirement and Kurt's suggested change: > >| > S1. During initiation of a replication session, authentication and >| > verification of authorization of both the replica and the source >| > directory MUST be allowed before any data is transferred. >| I would suggest a cleaner wording: >| S1. The protocol MUST support mutual authentication and verification >| of authorization of the protocol's peers before allowing >| replication data transfer. > >The problem is that there are several concepts that are jumbled together >into a single requirement. We propose, as a starting point for discussion, >the following three requirements to take the place of the above: > > S1a. The protocol MUST support mutual authentication of the source > and the replica directories during initialization of a > replication session. > > S1b. 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. > > S1c. The protocol MUST also support the initialization of anonymous > replication sessions. > >Note that we explicitly discuss anonymous replication. We feel that this >issue has been brushed under the table, and want to tease it out into the >open. We are not explicitly recommending the support of this feature; >rather, we want to gauge whether or not consensus has been achieved for >including or excluding support of this in implementations. > >We also feel, based on list discussions, that one additional issue >hasn't been fleshed out fully. This is the issue of whether a data >set MAY be relevant to determining if these entities are authorized to >actually follow through with the process of replicating the data. We note >that the data set for which replication is being initiated MAY or MAY NOT >itself be relevant to the actual process of authentication of the entities >involved. We would recommend that some additional discussion regarding >this point be undertaken on the list and that proposals be made for any >additional requirements related to that discussion be posted to the list. > >The third requirement to continue discussion on is S2. It, along with >Kurt's suggested change, is repeated here below for your convenience: > >| | > S2. The transport for LDAP synchronization MUST permit assurance of >| | > the integrity and privacy of all data transferred. >| S2. The replication protocol MUST support transfer of data with >| integrity and confidentiality protection. >| (I note this broadens the requirement) > >First, we note that definitions for confidentiality and integrity are not >present in the draft. They should probably be added. But for the sake of >our purposes, consider the following definitions: I suggest use of RFC 2828 definitions in this I-D. In particular, I note that the term "data privacy" should be avoided (see RFC2828). > Confidentiality: the assurance of data privacy; no one may > read the data except for the specific entity > (or entities) intended. > > Integrity: the assurance of non-alteration of data; the data > (either in transit or storage) has not been > undetectably altered. >Given these definitions, we'd like to start with Kurt's changes >and move forward. The above definitions render the use >of the word "protection" unnecessary. In fact, using that word >in a requirements document seems to push too close into protocol >design, based on reading many relevant texts on security >technology and concepts. A system cannot legitimately provide >assurance that data has remained private and/or was unaltered >during transmission if appropriate cryptographic techniques >are not employed to provide such protection. Thus we feel >that the use of the word "protection" in this requirement >pushes the document too close to the specification of the >replication protocol itself. It would certainly be appropriate >to include prose in the replication protocol document specifying >a framework within which such protective measures should be >implemented, but the requirements language proposed in this >e-mail should be sufficient to result in such a framework >actually being specified - which we believe is one thing >that the requirements document is supposed to help the WG >accomplish. > >The original requirement indicates (using language that is less >than ideal) that we must be able to check on whether integrity and >privacy were maintained during data transfer, whereas Kurt's says that >the protocol itself MUST support data transfer with integrity and >privacy and implies that implementations SHOULD NOT support data >transfer without integrity and privacy features enabled. Whether or >not anyone actually agrees about whether this implication exists is >not in issue - that two people such as the co-chairs could independently >come up with this as one of a few different interpretations of this >requirement is. This indicates that the requirement is not explicit >enough to avoid potential related interoperability problems. > >We would like to see some discussion of how it is envisioned that >replication sessions operate in trusted environments. In particular, >we are concerned with how integrity and/or confidentiality requirements >may be levied against operational replication processes, taking into >account the overhead those requirements imply. Some *service* implementers >making use of LDAP replication are likely to want a replication >protocol that enables them to decide whether or not integrity and >confidentiality are really requirements for their particular operational >scenario. Thus we are compelled to make the following proposal to >decompose the original requirement as follows: > > S2a. The replication protocol MUST support transfer of data with > integrity and confidentiality. > > S2b. The replication protocol MUST support the ability during > initialization of a replication session for an authenticated > source and replica to mutually decide to turn off data > integrity and confidentiality within the context of and for > the duration of that particular replication session. > >We are not stating that this particular wording should be used in the >next revision of the requirements document. We are proposing it as >a way of encouraging open discussion of an issue which is neither >adequately, nor explicitly addressed in the requirements document. > >regards, >John and Chris > >Chris Apple >Program Manager - Directory Services >United Messaging Inc. > > >(V) 610-425-2860 > From owner-ietf-ldup@mail.imc.org Wed Jun 6 19:04: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 TAA10358 for ; Wed, 6 Jun 2001 19:04:08 -0400 (EDT) Received: (from majordomo@localhost) by above.proper.com (8.9.3/8.9.3) id PAA05414 for ietf-ldup-bks; Wed, 6 Jun 2001 15:52:41 -0700 (PDT) Received: from hawk.ummail.com (hawk.ummail.com [216.33.108.233]) by above.proper.com (8.9.3/8.9.3) with ESMTP id PAA05409 for ; Wed, 6 Jun 2001 15:52:35 -0700 (PDT) Received: from ex01.ummail.com [216.33.108.253:25] by hawk.ummail.com with SMTP id Q0606-1852-10c500; Wed, 6 Jun 2001 22:52:14 GMT Received: by ex01.ummail.com with Internet Mail Service (5.5.2650.21) id ; Wed, 6 Jun 2001 18:50:54 -0400 Message-ID: From: Christopher Apple To: "'Richard Huber'" , "'ietf-ldup@imc.org'" Cc: Christopher Apple , "John Strassner (E-mail)" Subject: RE: WG Last Call Status of Requirements Document Date: Wed, 6 Jun 2001 18:50:46 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: multipart/mixed; boundary="----_=_NextPart_000_01C0EEDB.1FBE7D40" Sender: owner-ietf-ldup@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_000_01C0EEDB.1FBE7D40 Content-Type: text/plain; charset="iso-8859-1" What you wrote seems consistent with what we meant to me. However, there is still the issue of language or wording to resolve for the existing requirement so that its more clear. And perhaps explicitly references the changed requirement M7? Chris Apple Program Manager - Directory Services United Messaging Inc. (V) 610-425-2860 -----Original Message----- From: Richard Huber [mailto:rvh@att.com] Sent: Wednesday, June 06, 2001 5:06 PM To: 'ietf-ldup@imc.org' Cc: Christopher Apple; John Strassner (E-mail) Subject: Re: WG Last Call Status of Requirements Document The authors have discussed this comment. It seems to pertain more to architecture than requirements. Here's how we think it would work: - the identities of the two endpoints involved in replication are established during inititation of the replication session - the identity allows each party to find the appropriate replication agreement - the replication agreement specifies the area(s) of replication that these particular entities are allowed to replicate (among other parameters) In support of this view, we will add "area(s) of replication" to the list of items in requirement M7 that "MUST be defined in a standard location (e.g. the replication agreements)". Beyond that, this seems to be more of an architecture issue than a requirements issue, so we propose that any additional discussion be in the context of the architecture. If we've misunderstood the point of the comment, I'm sure you'll let us know :-) Rick Huber Christopher Apple wrote: > We also feel, based on list discussions, that one additional issue > hasn't been fleshed out fully. This is the issue of whether a data > set MAY be relevant to determining if these entities are authorized to > actually follow through with the process of replicating the data. We note > that the data set for which replication is being initiated MAY or MAY NOT > itself be relevant to the actual process of authentication of the entities > involved. We would recommend that some additional discussion regarding > this point be undertaken on the list and that proposals be made for any > additional requirements related to that discussion be posted to the list. > ------_=_NextPart_000_01C0EEDB.1FBE7D40 Content-Type: application/octet-stream; name="Chris Apple (E-mail).vcf" Content-Disposition: attachment; filename="Chris Apple (E-mail).vcf" 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=QUOTED-PRINTABLE:1161 McDermott Drive=0D=0AWest Chester, Pa. 19380=0D=0AUnited States of Amer= ica ADR;HOME:;;214 New Street, Apt 4-N;Philadelphia;PA;19106;United States of America LABEL;HOME;ENCODING=QUOTED-PRINTABLE:214 New Street, Apt 4-N=0D=0APhiladelphia, PA 19106=0D=0AUnited States of Am= erica EMAIL;PREF;INTERNET:christopher.apple@unitedmessaging.com REV:20010413T223539Z END:VCARD ------_=_NextPart_000_01C0EEDB.1FBE7D40-- From owner-ietf-ldup@mail.imc.org Wed Jun 6 20:16:43 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA10913 for ; Wed, 6 Jun 2001 20:16:42 -0400 (EDT) Received: (from majordomo@localhost) by above.proper.com (8.9.3/8.9.3) id QAA09016 for ietf-ldup-bks; Wed, 6 Jun 2001 16:54:44 -0700 (PDT) Received: from hawk.ummail.com (hawk.ummail.com [64.58.86.58]) by above.proper.com (8.9.3/8.9.3) with ESMTP id QAA09003 for ; Wed, 6 Jun 2001 16:54:33 -0700 (PDT) Received: from ex01.ummail.com [216.33.108.253:25] by hawk.ummail.com with SMTP id Q0606-1953-629400; Wed, 6 Jun 2001 23:53:54 GMT Received: by ex01.ummail.com with Internet Mail Service (5.5.2650.21) id ; Wed, 6 Jun 2001 19:52:33 -0400 Message-ID: From: Christopher Apple To: "'Kurt D. Zeilenga'" , Christopher Apple Cc: "'ietf-ldup@imc.org'" , "John Strassner (E-mail)" Subject: RE: WG Last Call Status of Requirements Document Date: Wed, 6 Jun 2001 19:52:28 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: multipart/mixed; boundary="----_=_NextPart_000_01C0EEE3.BE370E80" Sender: owner-ietf-ldup@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_000_01C0EEE3.BE370E80 Content-Type: text/plain; charset="iso-8859-1" Comments 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 06, 2001 6:17 PM To: Christopher Apple Cc: 'ietf-ldup@imc.org'; John Strassner (E-mail) Subject: Re: WG Last Call Status of Requirements Document At 07:34 AM 6/4/2001, Christopher Apple wrote: >G9. LDAP replication SHOULD support replication of directoryOperation > and distributedOperation attribute types defined in standards track > LDAP extensions. Future standards track specifications MUST include a > "Replication Considerations" section which indicates how and whether > the new feature operates in a replicated environment. > >Kurt wanted to remove the last sentence. To reiterate: it is my opinion that this sentence does not state a requirement upon the LDUP architecture, model, protocol, or other aspect of LDUP WG charter work items. It is a requirement upon designers of other extensions to detail replication considerations. As such, I believe it is beyond the scope of this document. It would be more appropriately be defined in a document detailing how to design LDAP extensions (such as Bruce's I-D). CHRIS> I've had similar thoughts lately. However, I need to hear CHRIS> some hum of concurrence on the list before we could declare CHRIS> that this is what we actually will do with this document. I note as well that "requirement" I-Ds such are only guidelines meant to focus the work effort. While the LDUP WG is somewhat bound by its charter to work through a requirements process, others developing LDAP extensions can simply ignore this document. While I agree that it is appropriate for designers of extensions to note a wide variety of considerations, there is no need to mandate that all future standard track specifications contain such sections. CHRIS> I couldn't disagree more with that statement. The only place CHRIS> where I'm more flexible as a consumer of RFCs and I-Ds on CHRIS> these sorts of matters is about the strength of these types CHRIS> of requirements. Some of them can be justified as a MUST, CHRIS> others as a SHOULD. Perhaps even weaker labels are feasible, CHRIS> but I can't think of an example for using them in this context. CHRIS> It is actually quite common in the IETF to mandate that CHRIS> certain types of document sections be present. See CHRIS> RFC 2223 (ftp://ftp.rfc-editor.org/in-notes/rfc2223.txt) CHRIS> as an example. Note that different sections of an RFC CHRIS> are mandatory while others are not. My assertion is that CHRIS> a replication considerations section SHOULD be included CHRIS> in all future LDAP extension/control RFCs. Otherwise, CHRIS> you end up with inconsistently thought out documents used by CHRIS> different implementers and you are set up for interoperability CHRIS> problems in droves. I note that to address LDAP replication considerations in an LDAP extension document requires that there be some technical specification of LDAP replication. This is very little to consider (other than to say "This document does not consider LDAP replication issues as there is no standard track specification of LDAP replication"). This requirement attempts to put the cart before the horse. CHRIS> Putting the cart before the horse happens all the time CHRIS> in the IETF. Over time, usually, the horse finds its way CHRIS> to where it should be. :) >The Co-Chairs believe that >this requirement should be relaxed from a MUST to a SHOULD. While we >both firmly support the spirit of the requirement, it will be very >difficult to actually enforce. Furthermore, while we can enforce >this in the LDUP WG, there are many non-LDUP-related controls/extensions >that are being developed. We don't think that it is permissible or even >possible for LDUP as a WG to act as a "policing force" for all >Internet-related work. However, as discussed on the list, there >are good reasons for making this requirement a SHOULD rather >than omitting it. The only reason I can see for such a requirement is so that someone can say to an author "You didn't fulfill this requirement". I would much rather this person say "You need to address replication issues such as ...". CHRIS> I don't think that word choice in communicating this particular CHRIS> type of message is relevant to the fundamental issue of CHRIS> requiring such a section or not. Referring someone to a spec CHRIS> on how these types of documents must be written, by stating, CHRIS> "You didn't fulfill [the referenced document] requirement" CHRIS> shouldn't have a significantly different impact on the document CHRIS> itself than that author being told in a mailing list posting CHRIS> that they need to address replication issues. Especially if CHRIS> that author is conscientious enough to follow up on considering CHRIS> all comments objectively. However, because of the importance CHRIS> of considering replication issues when writing LDAP extensions CHRIS> given that LDUP will be implemented by several major LDAP implementers, CHRIS> I believe that the needs of the extended LDAP implementation and CHRIS> user communities will be better served in the long run if authors CHRIS> of extension I-Ds are told in *both* ways. One is explanatory and CHRIS> the other is a requirement documented somewhere. This is completely CHRIS> independent of the issue related to whether or not this requirement CHRIS> belongs in the document its currently in. >So, our proposed new text is: > >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. Please note my objections to inclusion of this requirement as either a MUST or a SHOULD. I suggest that this sentence not use an RFC 2119 imperative. That is, I believe it should be worded as a suggestion to developers of future standard track specifications. CHRIS> OK. I understand. John and I need to hear what others think CHRIS> about this. So far, we've only heard from you and I. That's CHRIS> insufficient to judge consensus that this requirement be removed CHRIS> from this document. >Second, there is the S1 requirement. Kurt suggested some wording changes, >but Chris and I would like to suggest some more that will help further >clarify what the current requirement wording implies. First, the >requirement and Kurt's suggested change: > >| > S1. During initiation of a replication session, authentication and >| > verification of authorization of both the replica and the source >| > directory MUST be allowed before any data is transferred. >| I would suggest a cleaner wording: >| S1. The protocol MUST support mutual authentication and verification >| of authorization of the protocol's peers before allowing >| replication data transfer. > >The problem is that there are several concepts that are jumbled together >into a single requirement. We propose, as a starting point for discussion, >the following three requirements to take the place of the above: > > S1a. The protocol MUST support mutual authentication of the source > and the replica directories during initialization of a > replication session. > > S1b. 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. > > S1c. The protocol MUST also support the initialization of anonymous > replication sessions. > >Note that we explicitly discuss anonymous replication. We feel that this >issue has been brushed under the table, and want to tease it out into the >open. We are not explicitly recommending the support of this feature; >rather, we want to gauge whether or not consensus has been achieved for >including or excluding support of this in implementations. > >We also feel, based on list discussions, that one additional issue >hasn't been fleshed out fully. This is the issue of whether a data >set MAY be relevant to determining if these entities are authorized to >actually follow through with the process of replicating the data. We note >that the data set for which replication is being initiated MAY or MAY NOT >itself be relevant to the actual process of authentication of the entities >involved. We would recommend that some additional discussion regarding >this point be undertaken on the list and that proposals be made for any >additional requirements related to that discussion be posted to the list. > >The third requirement to continue discussion on is S2. It, along with >Kurt's suggested change, is repeated here below for your convenience: > >| | > S2. The transport for LDAP synchronization MUST permit assurance of >| | > the integrity and privacy of all data transferred. >| S2. The replication protocol MUST support transfer of data with >| integrity and confidentiality protection. >| (I note this broadens the requirement) > >First, we note that definitions for confidentiality and integrity are not >present in the draft. They should probably be added. But for the sake of >our purposes, consider the following definitions: I suggest use of RFC 2828 definitions in this I-D. In particular, I note that the term "data privacy" should be avoided (see RFC2828). CHRIS> Please note that the requirements language proposed CHRIS> to spark discussion doesn't make use of the term CHRIS> "data privacy." RFC 2828 is intended as guidance CHRIS> for writing I-D and RFC content (referred to CHRIS> as ISDs in RFC 2828) and the author's thereof and not CHRIS> mailing list discussions. So even if the proposed reworded CHRIS> requirements were actually included in the next revision of CHRIS> the requirements document, we would be in compliance with CHRIS> RFC 2828 from the perspective of avoiding the use of the CHRIS> term "data privacy." CHRIS> CHRIS> We weren't suggesting that these definitions be included CHRIS> in the requirements document - only that they be considered for CHRIS> discussion purposes. > Confidentiality: the assurance of data privacy; no one may > read the data except for the specific entity > (or entities) intended. > > Integrity: the assurance of non-alteration of data; the data > (either in transit or storage) has not been > undetectably altered. CHRIS> If we wanted to be more consistent even in mailing list CHRIS> discussions with RFC 2828, these would become: data confidentiality (I) "The property that information is not made available or disclosed to unauthorized individuals, entities, or processes [i.e., to any unauthorized system entity]." [I7498 Part 2]. (See: data confidentiality service.) data integrity (I) The property that data has not been changed, destroyed, or lost in an unauthorized or accidental manner. (See: data integrity service.) (O) "The property that information has not been modified or destroyed in an unauthorized manner." [I7498 Part 2] (C) Deals with constancy of and confidence in data values, not with the information that the values represent (see: correctness integrity) or the trustworthiness of the source of the values (see: source integrity). CHRIS> Even given those definitions as pulled from RFC 2828, I can't CHRIS> see how the requirements language proposed for discussion CHRIS> purposes below could be interpreted as inconsistent with RFC 2828. >Given these definitions, we'd like to start with Kurt's changes >and move forward. The above definitions render the use >of the word "protection" unnecessary. In fact, using that word >in a requirements document seems to push too close into protocol >design, based on reading many relevant texts on security >technology and concepts. A system cannot legitimately provide >assurance that data has remained private and/or was unaltered >during transmission if appropriate cryptographic techniques >are not employed to provide such protection. Thus we feel >that the use of the word "protection" in this requirement >pushes the document too close to the specification of the >replication protocol itself. It would certainly be appropriate >to include prose in the replication protocol document specifying >a framework within which such protective measures should be >implemented, but the requirements language proposed in this >e-mail should be sufficient to result in such a framework >actually being specified - which we believe is one thing >that the requirements document is supposed to help the WG >accomplish. > >The original requirement indicates (using language that is less >than ideal) that we must be able to check on whether integrity and >privacy were maintained during data transfer, whereas Kurt's says that >the protocol itself MUST support data transfer with integrity and >privacy and implies that implementations SHOULD NOT support data >transfer without integrity and privacy features enabled. Whether or >not anyone actually agrees about whether this implication exists is >not in issue - that two people such as the co-chairs could independently >come up with this as one of a few different interpretations of this >requirement is. This indicates that the requirement is not explicit >enough to avoid potential related interoperability problems. > >We would like to see some discussion of how it is envisioned that >replication sessions operate in trusted environments. In particular, >we are concerned with how integrity and/or confidentiality requirements >may be levied against operational replication processes, taking into >account the overhead those requirements imply. Some *service* implementers >making use of LDAP replication are likely to want a replication >protocol that enables them to decide whether or not integrity and >confidentiality are really requirements for their particular operational >scenario. Thus we are compelled to make the following proposal to >decompose the original requirement as follows: > > S2a. The replication protocol MUST support transfer of data with > integrity and confidentiality. > > S2b. The replication protocol MUST support the ability during > initialization of a replication session for an authenticated > source and replica to mutually decide to turn off data > integrity and confidentiality within the context of and for > the duration of that particular replication session. > >We are not stating that this particular wording should be used in the >next revision of the requirements document. We are proposing it as >a way of encouraging open discussion of an issue which is neither >adequately, nor explicitly addressed in the requirements document. > >regards, >John and Chris > >Chris Apple >Program Manager - Directory Services >United Messaging Inc. > > >(V) 610-425-2860 > ------_=_NextPart_000_01C0EEE3.BE370E80 Content-Type: application/octet-stream; name="Chris Apple (E-mail).vcf" Content-Disposition: attachment; filename="Chris Apple (E-mail).vcf" 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=QUOTED-PRINTABLE:1161 McDermott Drive=0D=0AWest Chester, Pa. 19380=0D=0AUnited States of Amer= ica ADR;HOME:;;214 New Street, Apt 4-N;Philadelphia;PA;19106;United States of America LABEL;HOME;ENCODING=QUOTED-PRINTABLE:214 New Street, Apt 4-N=0D=0APhiladelphia, PA 19106=0D=0AUnited States of Am= erica EMAIL;PREF;INTERNET:christopher.apple@unitedmessaging.com REV:20010413T223539Z END:VCARD ------_=_NextPart_000_01C0EEE3.BE370E80-- From owner-ietf-ldup@mail.imc.org Thu Jun 7 14:53:02 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA12442 for ; Thu, 7 Jun 2001 14:53:02 -0400 (EDT) Received: by above.proper.com (8.9.3/8.9.3) id LAA02481 for ietf-ldup-bks; Thu, 7 Jun 2001 11:28:40 -0700 (PDT) Received: from pretender.boolean.net (root@router.boolean.net [198.144.206.49]) by above.proper.com (8.9.3/8.9.3) with ESMTP id LAA02472 for ; Thu, 7 Jun 2001 11:28:33 -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 f57IR4p18753; Thu, 7 Jun 2001 18:27:04 GMT (envelope-from Kurt@OpenLDAP.org) Message-Id: <5.1.0.14.0.20010607112512.00afd8d8@127.0.0.1> X-Sender: kurt@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Thu, 07 Jun 2001 11:27:00 -0700 To: Christopher Apple From: "Kurt D. Zeilenga" Subject: Re: WG Last Call Status of Requirements Document Cc: "'ietf-ldup@imc.org'" , "John Strassner (E-mail)" 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 07:34 AM 6/4/2001, Christopher Apple wrote: > S2a. The replication protocol MUST support transfer of data with > integrity and confidentiality. > > S2b. The replication protocol MUST support the ability during > initialization of a replication session for an authenticated > source and replica to mutually decide to turn off data > integrity and confidentiality within the context of and for > the duration of that particular replication session. These two requirements would adequate address my concerns in this area. Kurt From owner-ietf-ldup@mail.imc.org Fri Jun 8 11:13: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 LAA14032 for ; Fri, 8 Jun 2001 11:13:35 -0400 (EDT) Received: (from majordomo@localhost) by above.proper.com (8.9.3/8.9.3) id HAA01309 for ietf-ldup-bks; Fri, 8 Jun 2001 07:50:21 -0700 (PDT) Received: from hawk.ummail.com (hawk.ummail.com [216.33.108.234]) by above.proper.com (8.9.3/8.9.3) with ESMTP id HAA01304 for ; Fri, 8 Jun 2001 07:50:16 -0700 (PDT) Received: from ex01.ummail.com [216.33.108.253:25] by hawk.ummail.com with SMTP id Q0608-1044-408500; Fri, 8 Jun 2001 14:44:29 GMT Received: by ex01.ummail.com with Internet Mail Service (5.5.2650.21) id ; Fri, 8 Jun 2001 10:43:06 -0400 Message-ID: From: Christopher Apple To: "'mcs@netscape.com'" , James Benedict Cc: rvh@qsun.mt.att.com, ietf-lcup@netscape.com, ietf-ldup@imc.org, richm@iplanet.com Subject: RE: Comments on LCUP draft - opaque cookie Date: Fri, 8 Jun 2001 10:43:05 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: multipart/mixed; boundary="----_=_NextPart_000_01C0F029.5375AC40" Sender: owner-ietf-ldup@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_000_01C0F029.5375AC40 Content-Type: text/plain; charset="iso-8859-1" I have similar concerns about the opaque property of the cookie. I see nothing fundamentally wrong with LCUP clients storing different cookies for different servers, or even multiple cookies for the same server. However, I believe that this is still not sufficient to help encourage interoperability between LCUP clients and servers from different implementers. I believe that the structure of cookie content must be specified. The structure should be designed to support a minimum set of required elements (to provide some guarantee that compliant clients and servers can talk with each other at some level) and also have some mechanism for augmenting the required set of elements with experimental or vendor-specific ones. Clients and servers would have to behave gracefully in the event that they see an element in a cookie that they do not support or understand how to react to. Because I'm one of the co-chairs, I don't consider it appropriate for me to suggest a specific cookie structure, but I believe that one needs to be included in the document if we're to have any hope of achieving interoperability for LCUP. I also believe that the structure should have at least the properties described above. Chris Apple Program Manager - Directory Services United Messaging Inc. (V) 610-425-2860 -----Original Message----- From: mcs@netscape.com [mailto:mcs@netscape.com] Sent: Thursday, May 17, 2001 1:39 PM To: James Benedict Cc: rvh@qsun.mt.att.com; ietf-lcup@netscape.com; ietf-ldup@imc.org; richm@iplanet.com Subject: Re: Comments on LCUP draft - opaque cookie This is a good issue to discuss. I believe the intent is for an LCUP client to store one (or more) cookie(s) per server. But if a replicated set of directory servers are deployed and clients choose "one of many" to use for their LCUP sessions (for redundancy or load balancing reasons), it would be nice if the cookie format were consistent. On the other hand, specifying the format of the cookie will really tie the hands of server implementors. We need to clarify this in the LCUP specification, one way or another. -Mark James Benedict wrote: > > > -----Original Message----- > > From: rvh@qsun.mt.att.com [mailto:rvh@qsun.mt.att.com] > > Sent: Wednesday, May 16, 2001 12:55 PM > > To: ietf-lcup@netscape.com; ietf-ldup@imc.org; richm@iplanet.com > > Subject: Comments on LCUP draft - opaque cookie > > > > > > This comment refers to . > > > > The controls defined in the LCUP draft use an opaque cookie > > supplied by > > the server. I'm concerned about the consequences of leaving > > the cookie > > opaque. It seems to me that interoperability with multiple servers > > will be limited. > > > > Section 4.6 of the draft includes the note: > > > > (Note that the client can synchronize with different servers > during > > different synchronization sessions.) > > > > If the cookie is opaque, this will only work if the different > servers > > are all running the same server implementation. Different vendors' > > implementations of LCUP will inevitably use different cookie formats > > > because there is no standard format. > > > > Section 7 notes: > > > > By design, the protocol does not specify the format of the cookie. > > > This is to allow different implementations the flexibility > > of storing > > any information applicable to their environment. > > > > Haven't we been down this path before (with ACI)? I agree that the > standard should not force a particular means of storing data, HOWEVER > interoperability from a client perspective requires that information > be common "on-the-wire". > > Or is the intention that LCUP clients maintain one cookie per server > (or vendor type, or whatever...)? If this is the plan, then we still > need to put some more smarts on the cookie so that the client can > determine which cookie to send to which server. > > > But that flexibility will limit interoperability. Since > multi-vendor > > replicated directory environments are a goal of LDUP, shouldn't the > > content of the cookie be specified in the standard? > > > > Rick Huber ------_=_NextPart_000_01C0F029.5375AC40 Content-Type: application/octet-stream; name="Chris Apple (E-mail).vcf" Content-Disposition: attachment; filename="Chris Apple (E-mail).vcf" 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=QUOTED-PRINTABLE:1161 McDermott Drive=0D=0AWest Chester, Pa. 19380=0D=0AUnited States of Amer= ica ADR;HOME:;;214 New Street, Apt 4-N;Philadelphia;PA;19106;United States of America LABEL;HOME;ENCODING=QUOTED-PRINTABLE:214 New Street, Apt 4-N=0D=0APhiladelphia, PA 19106=0D=0AUnited States of Am= erica EMAIL;PREF;INTERNET:christopher.apple@unitedmessaging.com REV:20010413T223539Z END:VCARD ------_=_NextPart_000_01C0F029.5375AC40-- From owner-ietf-ldup@mail.imc.org Fri Jun 8 14:12: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 OAA18446 for ; Fri, 8 Jun 2001 14:12:45 -0400 (EDT) Received: (from majordomo@localhost) by above.proper.com (8.9.3/8.9.3) id KAA17338 for ietf-ldup-bks; Fri, 8 Jun 2001 10:44:23 -0700 (PDT) Received: from cosds004.continuumnetworks.com ([12.41.184.244]) by above.proper.com (8.9.3/8.9.3) with ESMTP id KAA17328 for ; Fri, 8 Jun 2001 10:44:17 -0700 (PDT) Received: from FARILJCS ([12.41.186.77]) by cosds004.continuumnetworks.com (Netscape Messaging Server 4.15) with SMTP id GEMH9100.O61; Fri, 8 Jun 2001 11:43:49 -0600 Reply-To: From: "John Strassner" To: "Christopher Apple" , "'Ietf-Ldup@Imc. Org'" , "'Kurt D. Zeilenga'" Subject: RE: WG Last Call Status of Requirements Document Date: Fri, 8 Jun 2001 10:43:48 -0700 MIME-Version: 1.0 Message-ID: X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) Importance: Normal Content-Type: multipart/signed; micalg=SHA1; boundary="----=_NextPart_000_0147_01C0F007.E5708DD0"; 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_0147_01C0F007.E5708DD0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit My comments inline, look for .. regards, John -----Original Message----- From: Christopher Apple [mailto:christopher.apple@UnitedMessaging.net] Sent: Wednesday, June 06, 2001 4:52 PM To: 'Kurt D. Zeilenga'; Christopher Apple Cc: 'ietf-ldup@imc.org'; John Strassner (E-mail) Subject: RE: WG Last Call Status of Requirements Document Comments 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 06, 2001 6:17 PM To: Christopher Apple Cc: 'ietf-ldup@imc.org'; John Strassner (E-mail) Subject: Re: WG Last Call Status of Requirements Document At 07:34 AM 6/4/2001, Christopher Apple wrote: >G9. LDAP replication SHOULD support replication of directoryOperation > and distributedOperation attribute types defined in standards track > LDAP extensions. Future standards track specifications MUST include a > "Replication Considerations" section which indicates how and whether > the new feature operates in a replicated environment. > >Kurt wanted to remove the last sentence. To reiterate: it is my opinion that this sentence does not state a requirement upon the LDUP architecture, model, protocol, or other aspect of LDUP WG charter work items. It is a requirement upon designers of other extensions to detail replication considerations. As such, I believe it is beyond the scope of this document. It would be more appropriately be defined in a document detailing how to design LDAP extensions (such as Bruce's I-D). CHRIS> I've had similar thoughts lately. However, I need to hear CHRIS> some hum of concurrence on the list before we could declare CHRIS> that this is what we actually will do with this document. I agree. But right now, we have the authors supporting this statement and you (Kurt) disagreeing. We therefore need to hear from additional members of the WG before we recommend more severe action; see below for additional thoughts. I note as well that "requirement" I-Ds such are only guidelines meant to focus the work effort. While the LDUP WG is somewhat bound by its charter to work through a requirements process, others developing LDAP extensions can simply ignore this document. While I agree that it is appropriate for designers of extensions to note a wide variety of considerations, there is no need to mandate that all future standard track specifications contain such sections. CHRIS> I couldn't disagree more with that statement. The only place CHRIS> where I'm more flexible as a consumer of RFCs and I-Ds on CHRIS> these sorts of matters is about the strength of these types CHRIS> of requirements. Some of them can be justified as a MUST, CHRIS> others as a SHOULD. Perhaps even weaker labels are feasible, CHRIS> but I can't think of an example for using them in this context. CHRIS> It is actually quite common in the IETF to mandate that CHRIS> certain types of document sections be present. See CHRIS> RFC 2223 (ftp://ftp.rfc-editor.org/in-notes/rfc2223.txt) CHRIS> as an example. Note that different sections of an RFC CHRIS> are mandatory while others are not. My assertion is that CHRIS> a replication considerations section SHOULD be included CHRIS> in all future LDAP extension/control RFCs. Otherwise, CHRIS> you end up with inconsistently thought out documents used by CHRIS> different implementers and you are set up for interoperability CHRIS> problems in droves. I completely agree with Chris. I note that to address LDAP replication considerations in an LDAP extension document requires that there be some technical specification of LDAP replication. This is very little to consider (other than to say "This document does not consider LDAP replication issues as there is no standard track specification of LDAP replication"). This requirement attempts to put the cart before the horse. CHRIS> Putting the cart before the horse happens all the time CHRIS> in the IETF. Over time, usually, the horse finds its way CHRIS> to where it should be. :) I assume that you're worried about LDAP extension documents that complete before LDUP completes, or at least before the LDUP req document completes. I see no reason why people couldn't go back later and, as part of the process to upgrade these Proposed Standards to Draft Standards, add in a replication section. As you have pointed out, and as we have agreed, the only policing mechanism that is practical is by like-minded people (starting with the co-chairs of LDAPEXT and LDUP) reading documents and saying "wait a minute, you forgot the replication section". So given that, I see nothing wrong with having the horse find the cart. >The Co-Chairs believe that >this requirement should be relaxed from a MUST to a SHOULD. While we >both firmly support the spirit of the requirement, it will be very >difficult to actually enforce. Furthermore, while we can enforce >this in the LDUP WG, there are many non-LDUP-related controls/extensions >that are being developed. We don't think that it is permissible or even >possible for LDUP as a WG to act as a "policing force" for all >Internet-related work. However, as discussed on the list, there >are good reasons for making this requirement a SHOULD rather >than omitting it. The only reason I can see for such a requirement is so that someone can say to an author "You didn't fulfill this requirement". I would much rather this person say "You need to address replication issues such as ...". CHRIS> I don't think that word choice in communicating this particular CHRIS> type of message is relevant to the fundamental issue of CHRIS> requiring such a section or not. Referring someone to a spec CHRIS> on how these types of documents must be written, by stating, CHRIS> "You didn't fulfill [the referenced document] requirement" CHRIS> shouldn't have a significantly different impact on the document CHRIS> itself than that author being told in a mailing list posting CHRIS> that they need to address replication issues. Especially if CHRIS> that author is conscientious enough to follow up on considering CHRIS> all comments objectively. However, because of the importance CHRIS> of considering replication issues when writing LDAP extensions CHRIS> given that LDUP will be implemented by several major LDAP implementers, CHRIS> I believe that the needs of the extended LDAP implementation and CHRIS> user communities will be better served in the long run if authors CHRIS> of extension I-Ds are told in *both* ways. One is explanatory and CHRIS> the other is a requirement documented somewhere. This is completely CHRIS> independent of the issue related to whether or not this requirement CHRIS> belongs in the document its currently in. I fail to see anything wrong with the text being used so that someone can tell a prospective author "you didn't fulfill this requirement"? Everyone agrees that it should be supported. The only way to really encourage people to implement support for replication is to have them view it as a requirement. Otherwise, support will be spotty at best, and guess what suffers? Interoperability, the thing that we're all here to support. >So, our proposed new text is: > >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. Please note my objections to inclusion of this requirement as either a MUST or a SHOULD. I suggest that this sentence not use an RFC 2119 imperative. That is, I believe it should be worded as a suggestion to developers of future standard track specifications. CHRIS> OK. I understand. John and I need to hear what others think CHRIS> about this. So far, we've only heard from you and I. That's CHRIS> insufficient to judge consensus that this requirement be removed CHRIS> from this document. Kurt, you're going to have to do a lot more to convince me. I don't see how we have the faintest hope of interoperability if this isn't in as a SHOULD. So please tell me how we can achieve widespread interoperability without having this statement in. That being said, I'll note that your are so far the only dissenter, with the authors obviously wanting either a MUST or a SHOULD. >Second, there is the S1 requirement. Kurt suggested some wording changes, >but Chris and I would like to suggest some more that will help further >clarify what the current requirement wording implies. First, the >requirement and Kurt's suggested change: > >| > S1. During initiation of a replication session, authentication and >| > verification of authorization of both the replica and the source >| > directory MUST be allowed before any data is transferred. >| I would suggest a cleaner wording: >| S1. The protocol MUST support mutual authentication and verification >| of authorization of the protocol's peers before allowing >| replication data transfer. > >The problem is that there are several concepts that are jumbled together >into a single requirement. We propose, as a starting point for discussion, >the following three requirements to take the place of the above: > > S1a. The protocol MUST support mutual authentication of the source > and the replica directories during initialization of a > replication session. > > S1b. 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. > > S1c. The protocol MUST also support the initialization of anonymous > replication sessions. > >Note that we explicitly discuss anonymous replication. We feel that this >issue has been brushed under the table, and want to tease it out into the >open. We are not explicitly recommending the support of this feature; >rather, we want to gauge whether or not consensus has been achieved for >including or excluding support of this in implementations. > >We also feel, based on list discussions, that one additional issue >hasn't been fleshed out fully. This is the issue of whether a data >set MAY be relevant to determining if these entities are authorized to >actually follow through with the process of replicating the data. We note >that the data set for which replication is being initiated MAY or MAY NOT >itself be relevant to the actual process of authentication of the entities >involved. We would recommend that some additional discussion regarding >this point be undertaken on the list and that proposals be made for any >additional requirements related to that discussion be posted to the list. > >The third requirement to continue discussion on is S2. It, along with >Kurt's suggested change, is repeated here below for your convenience: > >| | > S2. The transport for LDAP synchronization MUST permit assurance of >| | > the integrity and privacy of all data transferred. >| S2. The replication protocol MUST support transfer of data with >| integrity and confidentiality protection. >| (I note this broadens the requirement) > >First, we note that definitions for confidentiality and integrity are not >present in the draft. They should probably be added. But for the sake of >our purposes, consider the following definitions: I suggest use of RFC 2828 definitions in this I-D. In particular, I note that the term "data privacy" should be avoided (see RFC2828). CHRIS> Please note that the requirements language proposed CHRIS> to spark discussion doesn't make use of the term CHRIS> "data privacy." RFC 2828 is intended as guidance CHRIS> for writing I-D and RFC content (referred to CHRIS> as ISDs in RFC 2828) and the author's thereof and not CHRIS> mailing list discussions. So even if the proposed reworded CHRIS> requirements were actually included in the next revision of CHRIS> the requirements document, we would be in compliance with CHRIS> RFC 2828 from the perspective of avoiding the use of the CHRIS> term "data privacy." CHRIS> CHRIS> We weren't suggesting that these definitions be included CHRIS> in the requirements document - only that they be considered for CHRIS> discussion purposes. > Confidentiality: the assurance of data privacy; no one may > read the data except for the specific entity > (or entities) intended. > > Integrity: the assurance of non-alteration of data; the data > (either in transit or storage) has not been > undetectably altered. CHRIS> If we wanted to be more consistent even in mailing list CHRIS> discussions with RFC 2828, these would become: data confidentiality (I) "The property that information is not made available or disclosed to unauthorized individuals, entities, or processes [i.e., to any unauthorized system entity]." [I7498 Part 2]. (See: data confidentiality service.) data integrity (I) The property that data has not been changed, destroyed, or lost in an unauthorized or accidental manner. (See: data integrity service.) (O) "The property that information has not been modified or destroyed in an unauthorized manner." [I7498 Part 2] (C) Deals with constancy of and confidence in data values, not with the information that the values represent (see: correctness integrity) or the trustworthiness of the source of the values (see: source integrity). CHRIS> Even given those definitions as pulled from RFC 2828, I can't CHRIS> see how the requirements language proposed for discussion CHRIS> purposes below could be interpreted as inconsistent with RFC 2828. >Given these definitions, we'd like to start with Kurt's changes >and move forward. The above definitions render the use >of the word "protection" unnecessary. In fact, using that word >in a requirements document seems to push too close into protocol >design, based on reading many relevant texts on security >technology and concepts. A system cannot legitimately provide >assurance that data has remained private and/or was unaltered >during transmission if appropriate cryptographic techniques >are not employed to provide such protection. Thus we feel >that the use of the word "protection" in this requirement >pushes the document too close to the specification of the >replication protocol itself. It would certainly be appropriate >to include prose in the replication protocol document specifying >a framework within which such protective measures should be >implemented, but the requirements language proposed in this >e-mail should be sufficient to result in such a framework >actually being specified - which we believe is one thing >that the requirements document is supposed to help the WG >accomplish. > >The original requirement indicates (using language that is less >than ideal) that we must be able to check on whether integrity and >privacy were maintained during data transfer, whereas Kurt's says that >the protocol itself MUST support data transfer with integrity and >privacy and implies that implementations SHOULD NOT support data >transfer without integrity and privacy features enabled. Whether or >not anyone actually agrees about whether this implication exists is >not in issue - that two people such as the co-chairs could independently >come up with this as one of a few different interpretations of this >requirement is. This indicates that the requirement is not explicit >enough to avoid potential related interoperability problems. > >We would like to see some discussion of how it is envisioned that >replication sessions operate in trusted environments. In particular, >we are concerned with how integrity and/or confidentiality requirements >may be levied against operational replication processes, taking into >account the overhead those requirements imply. Some *service* implementers >making use of LDAP replication are likely to want a replication >protocol that enables them to decide whether or not integrity and >confidentiality are really requirements for their particular operational >scenario. Thus we are compelled to make the following proposal to >decompose the original requirement as follows: > > S2a. The replication protocol MUST support transfer of data with > integrity and confidentiality. > > S2b. The replication protocol MUST support the ability during > initialization of a replication session for an authenticated > source and replica to mutually decide to turn off data > integrity and confidentiality within the context of and for > the duration of that particular replication session. > >We are not stating that this particular wording should be used in the >next revision of the requirements document. We are proposing it as >a way of encouraging open discussion of an issue which is neither >adequately, nor explicitly addressed in the requirements document. > >regards, >John and Chris > >Chris Apple >Program Manager - Directory Services >United Messaging Inc. > > >(V) 610-425-2860 > ------=_NextPart_000_0147_01C0F007.E5708DD0 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 AQkFMQ8XDTAxMDYwODE3NDM0N1owIwYJKoZIhvcNAQkEMRYEFJMj4cnuwvlTr10uZaLbcC6dlM8I MFgGCSqGSIb3DQEJDzFLMEkwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwICAgCAMAcGBSsOAwIHMA0G CCqGSIb3DQMCAgEoMAcGBSsOAwIaMAoGCCqGSIb3DQIFMIGrBgkrBgEEAYI3EAQxgZ0wgZowgZIx CzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEP MA0GA1UEChMGVGhhd3RlMR0wGwYDVQQLExRDZXJ0aWZpY2F0ZSBTZXJ2aWNlczEoMCYGA1UEAxMf UGVyc29uYWwgRnJlZW1haWwgUlNBIDIwMDAuOC4zMAIDBKRvMA0GCSqGSIb3DQEBAQUABIGAGrS1 AmTCufuAq+GmXC1Q676jQwrYAP8XyA3TsLMaKeGec2EITCnip0fslH6F7M5KUAU1Crd8gO3QxkVF B0lZ9YPK9G5eSGwhy2ypHMr2+Xgj36N5lYJPH3Stn39H+kr40qy3Qls+ZypSnv74NGe9dsIFIcSd 0/wUySaPqbtdASsAAAAAAAA= ------=_NextPart_000_0147_01C0F007.E5708DD0-- From owner-ietf-ldup@mail.imc.org Mon Jun 11 12:27:11 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA14063 for ; Mon, 11 Jun 2001 12:27:11 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.3/8.11.3) id f5BFjxa07497 for ietf-ldup-bks; Mon, 11 Jun 2001 08:45:59 -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 f5BFjvJ07493 for ; Mon, 11 Jun 2001 08:45:57 -0700 (PDT) Received: from ex01.ummail.com [216.33.108.253:25] by hawk.ummail.com with SMTP id Q0611-1145-50fa00; Mon, 11 Jun 2001 15:45:37 GMT Received: by ex01.ummail.com with Internet Mail Service (5.5.2650.21) id ; Mon, 11 Jun 2001 11:44:07 -0400 Message-ID: From: Christopher Apple To: Christopher Apple , "'Richard Huber'" , "'ietf-ldup@imc.org'" Cc: "'John Strassner (E-mail)'" Subject: RE: WG Last Call Status of Requirements Document Date: Mon, 11 Jun 2001 11:44:03 -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_000B_01C0F26B.DFE20D10" 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_000B_01C0F26B.DFE20D10 Content-Type: multipart/mixed; boundary="----=_NextPart_001_000C_01C0F26B.DFE20D10" ------=_NextPart_001_000C_01C0F26B.DFE20D10 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Just spoke with Rick on the phone about this. The requirement wording has been adjusted from the original by adopting proposed language from John and I and making a few text changes here and there for clarity; in particular to be sure we use consistent security-related wording and that this wording is compliant with RFC 2828. The issue that I raised in the posting below is resolved. Chris Apple Program Manager - Directory Services United Messaging Inc. (V) 610-425-2860 -----Original Message----- From: Christopher Apple Sent: Wednesday, June 06, 2001 6:51 PM To: 'Richard Huber'; 'ietf-ldup@imc.org' Cc: Christopher Apple; John Strassner (E-mail) Subject: RE: WG Last Call Status of Requirements Document What you wrote seems consistent with what we meant to me. However, there is still the issue of language or wording to resolve for the existing requirement so that its more clear. And perhaps explicitly references the changed requirement M7? Chris Apple Program Manager - Directory Services United Messaging Inc. (V) 610-425-2860 -----Original Message----- From: Richard Huber [mailto:rvh@att.com] Sent: Wednesday, June 06, 2001 5:06 PM To: 'ietf-ldup@imc.org' Cc: Christopher Apple; John Strassner (E-mail) Subject: Re: WG Last Call Status of Requirements Document The authors have discussed this comment. It seems to pertain more to architecture than requirements. Here's how we think it would work: - the identities of the two endpoints involved in replication are established during inititation of the replication session - the identity allows each party to find the appropriate replication agreement - the replication agreement specifies the area(s) of replication that these particular entities are allowed to replicate (among other parameters) In support of this view, we will add "area(s) of replication" to the list of items in requirement M7 that "MUST be defined in a standard location (e.g. the replication agreements)". Beyond that, this seems to be more of an architecture issue than a requirements issue, so we propose that any additional discussion be in the context of the architecture. If we've misunderstood the point of the comment, I'm sure you'll let us know :-) Rick Huber Christopher Apple wrote: > We also feel, based on list discussions, that one additional issue > hasn't been fleshed out fully. This is the issue of whether a data > set MAY be relevant to determining if these entities are authorized to > actually follow through with the process of replicating the data. We note > that the data set for which replication is being initiated MAY or MAY NOT > itself be relevant to the actual process of authentication of the entities > involved. We would recommend that some additional discussion regarding > this point be undertaken on the list and that proposals be made for any > additional requirements related to that discussion be posted to the list. > ------=_NextPart_001_000C_01C0F26B.DFE20D10 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 ADR;HOME:;;214 New Street, Apt 4-N;Philadelphia;PA;19106;United States = of America LABEL;HOME;ENCODING=3DQUOTED-PRINTABLE:214 New Street, Apt = 4-N=3D0D=3D0APhiladelphia, PA 19106=3D0D=3D0AUnited States of Am=3D erica EMAIL;PREF;INTERNET:christopher.apple@unitedmessaging.com REV:20010413T223539Z END:VCARD ------=_NextPart_001_000C_01C0F26B.DFE20D10-- ------=_NextPart_000_000B_01C0F26B.DFE20D10 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 MQ8XDTAxMDYxMTE1NDQyNlowIwYJKoZIhvcNAQkEMRYEFJutL/cA5U+OjIBp2yPPRvPUiw99MFgG CSqGSIb3DQEJDzFLMEkwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwICAgCAMAcGBSsOAwIHMA0GCCqG SIb3DQMCAgEoMAcGBSsOAwIaMAoGCCqGSIb3DQIFMIGrBgkrBgEEAYI3EAQxgZ0wgZowgZIxCzAJ BgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEPMA0G A1UEChMGVGhhd3RlMR0wGwYDVQQLExRDZXJ0aWZpY2F0ZSBTZXJ2aWNlczEoMCYGA1UEAxMfUGVy c29uYWwgRnJlZW1haWwgUlNBIDIwMDAuOC4zMAIDBPxeMA0GCSqGSIb3DQEBAQUABIGAY5Moccki QWs1YnNhgYhcHYdAtcHsMBQnhQfZehS+gnSL2J6fkdV2hbSBm4v5CPMY11MsdF1WLn1igt0RANra nX3a3u/xuS7Ygfk2MkL1Gz11zJkBIB1tI7nzUSGl9mHab1Qvwa6438rbXXZpMizZxI/oQPB6Ngb2 EaVCYcRlBxsAAAAAAAA= ------=_NextPart_000_000B_01C0F26B.DFE20D10-- From owner-ietf-ldup@mail.imc.org Mon Jun 11 16:29:57 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA18418 for ; Mon, 11 Jun 2001 16:29:56 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.3/8.11.3) id f5BJxMi15318 for ietf-ldup-bks; Mon, 11 Jun 2001 12:59:22 -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 f5BJxKJ15314 for ; Mon, 11 Jun 2001 12:59:20 -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 f5BJxEY05375 for ; Mon, 11 Jun 2001 12:59:15 -0700 (PDT) Received: from netscape.com ([205.217.229.32]) by dredd.mcom.com (Netscape Messaging Server 4.15) with ESMTP id GES7IQ00.NYD for ; Mon, 11 Jun 2001 12:59:14 -0700 Message-ID: <3B2522A7.1136B34F@netscape.com> Date: Mon, 11 Jun 2001 13:57:27 -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: ietf-ldup@imc.org Subject: 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 To me, LCUP interoperability means that you can issue the same LCUP search request against different servers and expect to get the same result. For example: I have a client who regularly issues LCUP search requests against serverA for scopeA. Now, for some reason, serverA is unavailable, and the client must access serverB. 1) If serverB is in sync with serverA and serverB has the same implementation as serverA, everything is ok. 2) If serverB is in sync with serverA but is implemented differently, a client resync is necessary (different cookie). 3) If serverB is not in sync with serverA but has the same implementation, a client resync is necessary (cookie not fresh). How likely is scenario 2) above? Not very likely I think. The worst case scenario is that the client must do a full resync in that case. Note that case 3) is much more likely (IMHO) than case 2) and the outcome is the same. Is it really worth exposing the cookie format? Christopher Apple wrote: > I have similar concerns about the opaque property > of the cookie. > > I see nothing fundamentally wrong with LCUP clients > storing different cookies for different servers, or > even multiple cookies for the same server. > > However, I believe that this is still not sufficient to > help encourage interoperability between LCUP clients > and servers from different implementers. > > I believe that the structure of cookie content must > be specified. The structure should be designed to support > a minimum set of required elements (to provide some > guarantee that compliant clients and servers can talk > with each other at some level) and also have some mechanism > for augmenting the required set of elements with experimental > or vendor-specific ones. > > Clients and servers would have to behave gracefully in > the event that they see an element in a cookie that they > do not support or understand how to react to. > > Because I'm one of the co-chairs, I don't consider it > appropriate for me to suggest a specific cookie structure, > but I believe that one needs to be included in the document > if we're to have any hope of achieving interoperability > for LCUP. I also believe that the structure should have > at least the properties described above. > > Chris Apple > Program Manager - Directory Services > United Messaging Inc. > > > (V) 610-425-2860 > > -----Original Message----- > From: mcs@netscape.com [mailto:mcs@netscape.com] > Sent: Thursday, May 17, 2001 1:39 PM > To: James Benedict > Cc: rvh@qsun.mt.att.com; ietf-lcup@netscape.com; ietf-ldup@imc.org; > richm@iplanet.com > Subject: Re: Comments on LCUP draft - opaque cookie > > This is a good issue to discuss. I believe the intent is for an LCUP > client to store one (or more) cookie(s) per server. But if a replicated > set of directory servers are deployed and clients choose "one of many" > to use for their LCUP sessions (for redundancy or load balancing > reasons), it would be nice if the cookie format were consistent. On the > other hand, specifying the format of the cookie will really tie the > hands of server implementors. We need to clarify this in the LCUP > specification, one way or another. > > -Mark > > James Benedict wrote: > > > > > -----Original Message----- > > > From: rvh@qsun.mt.att.com [mailto:rvh@qsun.mt.att.com] > > > Sent: Wednesday, May 16, 2001 12:55 PM > > > To: ietf-lcup@netscape.com; ietf-ldup@imc.org; richm@iplanet.com > > > Subject: Comments on LCUP draft - opaque cookie > > > > > > > > > This comment refers to . > > > > > > The controls defined in the LCUP draft use an opaque cookie > > > supplied by > > > the server. I'm concerned about the consequences of leaving > > > the cookie > > > opaque. It seems to me that interoperability with multiple servers > > > will be limited. > > > > > > Section 4.6 of the draft includes the note: > > > > > > (Note that the client can synchronize with different servers > > during > > > different synchronization sessions.) > > > > > > If the cookie is opaque, this will only work if the different > > servers > > > are all running the same server implementation. Different vendors' > > > implementations of LCUP will inevitably use different cookie formats > > > > > because there is no standard format. > > > > > > Section 7 notes: > > > > > > By design, the protocol does not specify the format of the cookie. > > > > > This is to allow different implementations the flexibility > > > of storing > > > any information applicable to their environment. > > > > > > > Haven't we been down this path before (with ACI)? I agree that the > > standard should not force a particular means of storing data, HOWEVER > > interoperability from a client perspective requires that information > > be common "on-the-wire". > > > > Or is the intention that LCUP clients maintain one cookie per server > > (or vendor type, or whatever...)? If this is the plan, then we still > > need to put some more smarts on the cookie so that the client can > > determine which cookie to send to which server. > > > > > But that flexibility will limit interoperability. Since > > multi-vendor > > > replicated directory environments are a goal of LDUP, shouldn't the > > > content of the cookie be specified in the standard? > > > > > > Rick Huber From owner-ietf-ldup@mail.imc.org Mon Jun 11 17:10:01 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA19141 for ; Mon, 11 Jun 2001 17:10:00 -0400 (EDT) Received: by above.proper.com (8.11.3/8.11.3) id f5BKlfV16595 for ietf-ldup-bks; Mon, 11 Jun 2001 13:47:41 -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 f5BKldJ16590 for ; Mon, 11 Jun 2001 13:47:39 -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 f5BKkPp37746; Mon, 11 Jun 2001 20:46:25 GMT (envelope-from Kurt@OpenLDAP.org) Message-Id: <5.1.0.14.0.20010611133732.00af0ce0@127.0.0.1> X-Sender: kurt@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Mon, 11 Jun 2001 13:46:17 -0700 To: richm@iplanet.com From: "Kurt D. Zeilenga" Subject: Re: Comments on LCUP draft - opaque cookie Cc: ietf-ldup@imc.org In-Reply-To: <3B2522A7.1136B34F@netscape.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-ldup@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: At 12:57 PM 6/11/2001, Rich Megginson wrote: >Is it really worth exposing the cookie format? IMO, the cookie should be an opaque octet string. The client should never pass the cookie on to any peer other than the one which provided the cookie. Kurt From owner-ietf-ldup@mail.imc.org Mon Jun 11 17:44:37 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA19599 for ; Mon, 11 Jun 2001 17:44:34 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.3/8.11.3) id f5BLMs217561 for ietf-ldup-bks; Mon, 11 Jun 2001 14:22:54 -0700 (PDT) Received: from kcmso1.proxy.att.com (kcmso1.att.com [192.128.133.69]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f5BLMpJ17554 for ; Mon, 11 Jun 2001 14:22:51 -0700 (PDT) Received: from qsun.mt.att.com ([135.16.12.1]) by kcmso1.proxy.att.com (AT&T IPNS/MSO-3.0) with SMTP id f5BLMmD27970 for ; Mon, 11 Jun 2001 17:22:48 -0400 (EDT) Received: by qsun.mt.att.com (SMI-8.6/ATTEMS-1.4.1 sol2) id RAA21454; Mon, 11 Jun 2001 17:22:47 -0400 Date: Mon, 11 Jun 2001 17:22:47 -0400 Message-Id: <200106112122.RAA21454@qsun.mt.att.com> From: rvh@qsun.mt.att.com (Richard V Huber) To: ietf-ldup@imc.org, richm@iplanet.com Subject: Re: Comments on LCUP draft - opaque cookie Sender: owner-ietf-ldup@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: I don't see anything in the current draft that says that your case 1 ("If serverB is in sync with serverA and serverB has the same implementation as serverA, everything is ok") will work. If the cookie is opaque, why should we assume that there is no instance-dependent information in the cookie (for instance, the offset in this particular server's change log of the last update sent to the client)? Then even two sync'ed servers from the same vendor implementation would not have compatible cookies. Also, during server upgrades server code from the same vendor might have incompatible cookies. And while I grant that your case 1 is probably more common that case 2, that is in part true because existing standards do yet not support vendor interoperability for replication and update. It seems consistent with IETF goals to deliver standards that permit case 2. Think about a mobile user on the road with only dial access. And think about a coporate directory with thousands of entries that contain certificates. In such situations complete refreshes should be avoided whenever possible. The protocol should try to make complete refreshes a rare event. Does it really cost so much to expose the cookie format? Rick Huber : From: richm@netscape.com (Rich Megginson) : To: ietf-ldup@imc.org : Subject: Re: Comments on LCUP draft - opaque cookie : : To me, LCUP interoperability means that you can issue the same LCUP search : request against different servers and expect to get the same result. : : For example: : I have a client who regularly issues LCUP search requests against serverA : for scopeA. Now, for some reason, serverA is unavailable, and the client : must access serverB. : 1) If serverB is in sync with serverA and serverB has the same : implementation as serverA, everything is ok. : 2) If serverB is in sync with serverA but is implemented differently, a : client resync is necessary (different cookie). : 3) If serverB is not in sync with serverA but has the same implementation, : a client resync is necessary (cookie not fresh). : : How likely is scenario 2) above? Not very likely I think. The worst case : scenario is that the client must do a full resync in that case. Note that : case 3) is much more likely (IMHO) than case 2) and the outcome is the : same. : : Is it really worth exposing the cookie format? : : Christopher Apple wrote: : : > I have similar concerns about the opaque property : > of the cookie. : > : > I see nothing fundamentally wrong with LCUP clients : > storing different cookies for different servers, or : > even multiple cookies for the same server. : > : > However, I believe that this is still not sufficient to : > help encourage interoperability between LCUP clients : > and servers from different implementers. : > : > I believe that the structure of cookie content must : > be specified. The structure should be designed to support : > a minimum set of required elements (to provide some : > guarantee that compliant clients and servers can talk : > with each other at some level) and also have some mechanism : > for augmenting the required set of elements with experimental : > or vendor-specific ones. : > : > Clients and servers would have to behave gracefully in : > the event that they see an element in a cookie that they : > do not support or understand how to react to. : > : > Because I'm one of the co-chairs, I don't consider it : > appropriate for me to suggest a specific cookie structure, : > but I believe that one needs to be included in the document : > if we're to have any hope of achieving interoperability : > for LCUP. I also believe that the structure should have : > at least the properties described above. : > : > Chris Apple : > Program Manager - Directory Services : > United Messaging Inc. : > : > : > (V) 610-425-2860 : > : > -----Original Message----- : > From: mcs@netscape.com [mailto:mcs@netscape.com] : > Sent: Thursday, May 17, 2001 1:39 PM : > To: James Benedict : > Cc: rvh@qsun.mt.att.com; ietf-lcup@netscape.com; ietf-ldup@imc.org; : > richm@iplanet.com : > Subject: Re: Comments on LCUP draft - opaque cookie : > : > This is a good issue to discuss. I believe the intent is for an LCUP : > client to store one (or more) cookie(s) per server. But if a replicated : > set of directory servers are deployed and clients choose "one of many" : > to use for their LCUP sessions (for redundancy or load balancing : > reasons), it would be nice if the cookie format were consistent. On the : > other hand, specifying the format of the cookie will really tie the : > hands of server implementors. We need to clarify this in the LCUP : > specification, one way or another. : > : > -Mark : > : > James Benedict wrote: : > > : > > > -----Original Message----- : > > > From: rvh@qsun.mt.att.com [mailto:rvh@qsun.mt.att.com] : > > > Sent: Wednesday, May 16, 2001 12:55 PM : > > > To: ietf-lcup@netscape.com; ietf-ldup@imc.org; richm@iplanet.com : > > > Subject: Comments on LCUP draft - opaque cookie : > > > : > > > : > > > This comment refers to . : > > > : > > > The controls defined in the LCUP draft use an opaque cookie : > > > supplied by : > > > the server. I'm concerned about the consequences of leaving : > > > the cookie : > > > opaque. It seems to me that interoperability with multiple servers : > > > will be limited. : > > > : > > > Section 4.6 of the draft includes the note: : > > > : > > > (Note that the client can synchronize with different servers : > > during : > > > different synchronization sessions.) : > > > : > > > If the cookie is opaque, this will only work if the different : > > servers : > > > are all running the same server implementation. Different vendors' : > > > implementations of LCUP will inevitably use different cookie formats : > > : > > > because there is no standard format. : > > > : > > > Section 7 notes: : > > > : > > > By design, the protocol does not specify the format of the cookie. : > > : > > > This is to allow different implementations the flexibility : > > > of storing : > > > any information applicable to their environment. : > > > : > > : > > Haven't we been down this path before (with ACI)? I agree that the : > > standard should not force a particular means of storing data, HOWEVER : > > interoperability from a client perspective requires that information : > > be common "on-the-wire". : > > : > > Or is the intention that LCUP clients maintain one cookie per server : > > (or vendor type, or whatever...)? If this is the plan, then we still : > > need to put some more smarts on the cookie so that the client can : > > determine which cookie to send to which server. : > > : > > > But that flexibility will limit interoperability. Since : > > multi-vendor : > > > replicated directory environments are a goal of LDUP, shouldn't the : > > > content of the cookie be specified in the standard? : > > > : > > > Rick Huber From owner-ietf-ldup@mail.imc.org Mon Jun 11 17:48:14 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA19648 for ; Mon, 11 Jun 2001 17:48:12 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.3/8.11.3) id f5BLRUK17655 for ietf-ldup-bks; Mon, 11 Jun 2001 14:27:30 -0700 (PDT) Received: from kcmso1.proxy.att.com (kcmso1.att.com [192.128.133.69]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f5BLRSJ17650 for ; Mon, 11 Jun 2001 14:27:28 -0700 (PDT) Received: from qsun.mt.att.com ([135.16.31.2]) by kcmso1.proxy.att.com (AT&T IPNS/MSO-3.0) with SMTP id f5BLROD29732; Mon, 11 Jun 2001 17:27:24 -0400 (EDT) Received: by qsun.mt.att.com (SMI-8.6/ATTEMS-1.4.1 sol2) id RAA21995; Mon, 11 Jun 2001 17:27:22 -0400 Date: Mon, 11 Jun 2001 17:27:22 -0400 Message-Id: <200106112127.RAA21995@qsun.mt.att.com> From: rvh@qsun.mt.att.com (Richard V Huber) To: Kurt@OpenLDAP.org, richm@iplanet.com Subject: Re: Comments on LCUP draft - opaque cookie Cc: ietf-ldup@imc.org Sender: owner-ietf-ldup@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: But that would mean that any system with a load-balancer in front of a set of replicated directory servers would require complete resync unless the user lucked out and got the same server they had on their last connection. Rick Huber : To: richm@iplanet.com : From: "Kurt D. Zeilenga" : Subject: Re: Comments on LCUP draft - opaque cookie : Cc: ietf-ldup@imc.org : : : At 12:57 PM 6/11/2001, Rich Megginson wrote: : >Is it really worth exposing the cookie format? : : IMO, the cookie should be an opaque octet string. : The client should never pass the cookie on to any : peer other than the one which provided the cookie. : : Kurt From owner-ietf-ldup@mail.imc.org Mon Jun 11 18:04:21 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA19855 for ; Mon, 11 Jun 2001 18:04:20 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.3/8.11.3) id f5BLYmA17840 for ietf-ldup-bks; Mon, 11 Jun 2001 14:34:48 -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 f5BLYlJ17836 for ; Mon, 11 Jun 2001 14:34:47 -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 f5BLXcp37868; Mon, 11 Jun 2001 21:33:38 GMT (envelope-from Kurt@OpenLDAP.org) Message-Id: <5.1.0.14.0.20010611143125.00ae7df8@127.0.0.1> X-Sender: kurt@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Mon, 11 Jun 2001 14:33:34 -0700 To: rvh@qsun.mt.att.com (Richard V Huber) From: "Kurt D. Zeilenga" Subject: Re: Comments on LCUP draft - opaque cookie Cc: richm@iplanet.com, ietf-ldup@imc.org In-Reply-To: <200106112127.RAA21995@qsun.mt.att.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-ldup@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: At 02:27 PM 6/11/2001, Richard V Huber wrote: >But that would mean that any system with a load-balancer in front of a >set of replicated directory servers would require complete resync >unless the user lucked out and got the same server they had on their >last connection. Having an opaque cookie does not prevent a vendor from provide such capabilities. Kurt From owner-ietf-ldup@mail.imc.org Mon Jun 11 18:13:04 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA19956 for ; Mon, 11 Jun 2001 18:13:01 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.3/8.11.3) id f5BLj9Y18124 for ietf-ldup-bks; Mon, 11 Jun 2001 14:45:09 -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 f5BLj7J18118 for ; Mon, 11 Jun 2001 14:45:07 -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 f5BLiaE10953; Mon, 11 Jun 2001 17:44:36 -0400 (EDT) Received: by qsun.mt.att.com (SMI-8.6/ATTEMS-1.4.1 sol2) id RAA24056; Mon, 11 Jun 2001 17:44:34 -0400 Date: Mon, 11 Jun 2001 17:44:34 -0400 Message-Id: <200106112144.RAA24056@qsun.mt.att.com> From: rvh@qsun.mt.att.com (Richard V Huber) To: Kurt@OpenLDAP.org Subject: Re: Comments on LCUP draft - opaque cookie Cc: ietf-ldup@imc.org, richm@iplanet.com Sender: owner-ietf-ldup@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: True. But shouldn't we be trying to do more than just "not prevent" interoperability? Rick : To: rvh@qsun.mt.att.com (Richard V Huber) : From: "Kurt D. Zeilenga" : Subject: Re: Comments on LCUP draft - opaque cookie : Cc: richm@iplanet.com, ietf-ldup@imc.org : : At 02:27 PM 6/11/2001, Richard V Huber wrote: : >But that would mean that any system with a load-balancer in front of a : >set of replicated directory servers would require complete resync : >unless the user lucked out and got the same server they had on their : >last connection. : : Having an opaque cookie does not prevent a vendor from provide : such capabilities. : : Kurt From owner-ietf-ldup@mail.imc.org Mon Jun 11 18:22:54 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA20097 for ; Mon, 11 Jun 2001 18:22:53 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.3/8.11.3) id f5BM3qG18624 for ietf-ldup-bks; Mon, 11 Jun 2001 15:03:52 -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 f5BM3oJ18620 for ; Mon, 11 Jun 2001 15:03:50 -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 f5BM2hp37949; Mon, 11 Jun 2001 22:02:43 GMT (envelope-from Kurt@OpenLDAP.org) Message-Id: <5.1.0.14.0.20010611144514.00adf690@127.0.0.1> X-Sender: kurt@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Mon, 11 Jun 2001 15:02:38 -0700 To: rvh@qsun.mt.att.com (Richard V Huber) From: "Kurt D. Zeilenga" Subject: Re: Comments on LCUP draft - opaque cookie Cc: ietf-ldup@imc.org, richm@iplanet.com In-Reply-To: <200106112144.RAA24056@qsun.mt.att.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-ldup@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: At 02:44 PM 6/11/2001, Richard V Huber wrote: >True. But shouldn't we be trying to do more than just "not prevent" >interoperability? It is not preventing interoperability in replicated environments, it is deferring specification of such features to future documents. LCUP should be a simple client/server update protocol. If a particular client can update from a particular server, this client and server interoperate. If later, we want extend LCUP to allow a client to update from any replica in a distributed environment, we can do that. But I suggest we try to maintain a narrow focus on this work. That is, I believe we should avoid defining how LCUP works in a replicated/distributed environment at this time. Kurt >Rick > >: To: rvh@qsun.mt.att.com (Richard V Huber) >: From: "Kurt D. Zeilenga" >: Subject: Re: Comments on LCUP draft - opaque cookie >: Cc: richm@iplanet.com, ietf-ldup@imc.org >: >: At 02:27 PM 6/11/2001, Richard V Huber wrote: >: >But that would mean that any system with a load-balancer in front of a >: >set of replicated directory servers would require complete resync >: >unless the user lucked out and got the same server they had on their >: >last connection. >: >: Having an opaque cookie does not prevent a vendor from provide >: such capabilities. >: >: Kurt From owner-ietf-ldup@mail.imc.org Mon Jun 11 19:29:26 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA20648 for ; Mon, 11 Jun 2001 19:29:25 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.3/8.11.3) id f5BMvhZ19795 for ietf-ldup-bks; Mon, 11 Jun 2001 15:57:43 -0700 (PDT) Received: from hawk.ummail.com (hawk.ummail.com [216.33.108.234]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f5BMvgJ19791 for ; Mon, 11 Jun 2001 15:57:42 -0700 (PDT) Received: from ex01.ummail.com [216.33.108.253:25] by hawk.ummail.com with SMTP id Q0611-1857-28c200; Mon, 11 Jun 2001 22:57:04 GMT Received: by ex01.ummail.com with Internet Mail Service (5.5.2650.21) id ; Mon, 11 Jun 2001 18:55:35 -0400 Message-ID: From: Christopher Apple To: "'Kurt D. Zeilenga'" , richm@iplanet.com Cc: ietf-ldup@imc.org Subject: RE: Comments on LCUP draft - opaque cookie Date: Mon, 11 Jun 2001 18:55:31 -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_0071_01C0F2A8.27D6F400" 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_0071_01C0F2A8.27D6F400 Content-Type: multipart/mixed; boundary="----=_NextPart_001_0072_01C0F2A8.27D6F400" ------=_NextPart_001_0072_01C0F2A8.27D6F400 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit -----Original Message----- From: Kurt D. Zeilenga [mailto:Kurt@OpenLDAP.org] Sent: Monday, June 11, 2001 4:46 PM To: richm@iplanet.com Cc: ietf-ldup@imc.org Subject: Re: Comments on LCUP draft - opaque cookie At 12:57 PM 6/11/2001, Rich Megginson wrote: >Is it really worth exposing the cookie format? IMO, the cookie should be an opaque octet string. The client should never pass the cookie on to any peer other than the one which provided the cookie. Kurt I think those statements conflate a few issues that should really be dealt with separately: 1)Clients should never pass a cookie on to a peer other than the one which set/provided the cookie. I completely agree here. But that doesn't require or even necessarily make it a good idea to make the structure of the cookie content opaque. 2) The term "peer" generally refers to an operational instance of an LCUP server - in both the real world and the theoretical sense (e.g., in the protocol spec). Its the real world context where I find what you've said to be confusing. The reason I find this confusing is that my prior posting indicated that (I'm paraphrasing for brevity): 3) Clients and Servers from different implementers should be able to understand enough cookie content so that some level of cross-implementer Client-Server interoperability is possible. This doesn't mean that any real-world client would be required to send all of its cookies to any real-world peer (a deployed instance of a server) regardless of which real-world peer originally set the cookie. If you buy into 3, above, it means that there must be some basic level of cookie structure that is specified and required to be supported by compliant implementations. There should be a really compelling set of real-world reasons that the WG achieves consensus on in order for the co-chairs to make a recommendation that a document containing a feature that will impede interoperability of client and server implementations from different implementers be considered for IETF Last Call. With the present proposal of an opaque cookie format, that is the document's current status. I'm not suggesting by any means that discussion related to this topic should stop - in fact, I'm saying that more opinions need to be aired on the list about the more fundamental issue of client-server interoperability; and why it should or should not be a requirement. Chris Apple Program Manager - Directory Services United Messaging Inc. (V) 610-425-2860 ------=_NextPart_001_0072_01C0F2A8.27D6F400 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 ADR;HOME:;;214 New Street, Apt 4-N;Philadelphia;PA;19106;United States = of America LABEL;HOME;ENCODING=3DQUOTED-PRINTABLE:214 New Street, Apt = 4-N=3D0D=3D0APhiladelphia, PA 19106=3D0D=3D0AUnited States of Am=3D erica EMAIL;PREF;INTERNET:christopher.apple@unitedmessaging.com REV:20010413T223539Z END:VCARD ------=_NextPart_001_0072_01C0F2A8.27D6F400-- ------=_NextPart_000_0071_01C0F2A8.27D6F400 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 MQ8XDTAxMDYxMTIyNTYwMFowIwYJKoZIhvcNAQkEMRYEFI4329FxGn59dMn1t/12PGIs1EziMFgG CSqGSIb3DQEJDzFLMEkwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwICAgCAMAcGBSsOAwIHMA0GCCqG SIb3DQMCAgEoMAcGBSsOAwIaMAoGCCqGSIb3DQIFMIGrBgkrBgEEAYI3EAQxgZ0wgZowgZIxCzAJ BgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEPMA0G A1UEChMGVGhhd3RlMR0wGwYDVQQLExRDZXJ0aWZpY2F0ZSBTZXJ2aWNlczEoMCYGA1UEAxMfUGVy c29uYWwgRnJlZW1haWwgUlNBIDIwMDAuOC4zMAIDBPxeMA0GCSqGSIb3DQEBAQUABIGAjGKHUWOV tL0NoLIzDXpx7Hi+ygdscKV87watD8U+nfR70cw84VePkRtQzTWzCFZDKAlH6RJRAmUfjEudp84m 2ymjoY2civvGprx4HkUJCT9oMoZrzYdqRqqi4tsj/+0kpuG+7fTVY+qnpfZ4mBBGh9tPeXP37hWc v+IKJNph0BwAAAAAAAA= ------=_NextPart_000_0071_01C0F2A8.27D6F400-- From owner-ietf-ldup@mail.imc.org Mon Jun 11 19:51:08 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA20860 for ; Mon, 11 Jun 2001 19:51:08 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.3/8.11.3) id f5BN8ZA20028 for ietf-ldup-bks; Mon, 11 Jun 2001 16:08:35 -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 f5BN8YJ20024 for ; Mon, 11 Jun 2001 16:08:34 -0700 (PDT) Received: from ex01.ummail.com [216.33.108.253:25] by hawk.ummail.com with SMTP id Q0611-1908-389700; Mon, 11 Jun 2001 23:08:14 GMT Received: by ex01.ummail.com with Internet Mail Service (5.5.2650.21) id ; Mon, 11 Jun 2001 19:06:46 -0400 Message-ID: From: Christopher Apple To: "'richm@iplanet.com'" , ietf-ldup@imc.org Subject: RE: Comments on LCUP draft - opaque cookie Date: Mon, 11 Jun 2001 19:06:39 -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_0077_01C0F2A9.B6122090" 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_0077_01C0F2A9.B6122090 Content-Type: multipart/mixed; boundary="----=_NextPart_001_0078_01C0F2A9.B6122090" ------=_NextPart_001_0078_01C0F2A9.B6122090 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit I was referring more to "out-of-the-box" interoperability between clients from one implementer and servers from another. As a co-chair, that's part of the way I have to define interoperability unless there are compelling reasons for looking at it in a more constrained way as you've given examples for below. Those are certainly relevant scenarios, but I don't believe they should be the only constraints that we consider as potentially being levied against the spec. Need to hear from some other WG participants... Chris Apple Program Manager - Directory Services United Messaging Inc. (V) 610-425-2860 -----Original Message----- From: richm@netscape.com [mailto:richm@netscape.com] Sent: Monday, June 11, 2001 3:57 PM To: ietf-ldup@imc.org Subject: Re: Comments on LCUP draft - opaque cookie To me, LCUP interoperability means that you can issue the same LCUP search request against different servers and expect to get the same result. For example: I have a client who regularly issues LCUP search requests against serverA for scopeA. Now, for some reason, serverA is unavailable, and the client must access serverB. 1) If serverB is in sync with serverA and serverB has the same implementation as serverA, everything is ok. 2) If serverB is in sync with serverA but is implemented differently, a client resync is necessary (different cookie). 3) If serverB is not in sync with serverA but has the same implementation, a client resync is necessary (cookie not fresh). How likely is scenario 2) above? Not very likely I think. The worst case scenario is that the client must do a full resync in that case. Note that case 3) is much more likely (IMHO) than case 2) and the outcome is the same. Is it really worth exposing the cookie format? Christopher Apple wrote: > I have similar concerns about the opaque property > of the cookie. > > I see nothing fundamentally wrong with LCUP clients > storing different cookies for different servers, or > even multiple cookies for the same server. > > However, I believe that this is still not sufficient to > help encourage interoperability between LCUP clients > and servers from different implementers. > > I believe that the structure of cookie content must > be specified. The structure should be designed to support > a minimum set of required elements (to provide some > guarantee that compliant clients and servers can talk > with each other at some level) and also have some mechanism > for augmenting the required set of elements with experimental > or vendor-specific ones. > > Clients and servers would have to behave gracefully in > the event that they see an element in a cookie that they > do not support or understand how to react to. > > Because I'm one of the co-chairs, I don't consider it > appropriate for me to suggest a specific cookie structure, > but I believe that one needs to be included in the document > if we're to have any hope of achieving interoperability > for LCUP. I also believe that the structure should have > at least the properties described above. > > Chris Apple > Program Manager - Directory Services > United Messaging Inc. > > > (V) 610-425-2860 > > -----Original Message----- > From: mcs@netscape.com [mailto:mcs@netscape.com] > Sent: Thursday, May 17, 2001 1:39 PM > To: James Benedict > Cc: rvh@qsun.mt.att.com; ietf-lcup@netscape.com; ietf-ldup@imc.org; > richm@iplanet.com > Subject: Re: Comments on LCUP draft - opaque cookie > > This is a good issue to discuss. I believe the intent is for an LCUP > client to store one (or more) cookie(s) per server. But if a replicated > set of directory servers are deployed and clients choose "one of many" > to use for their LCUP sessions (for redundancy or load balancing > reasons), it would be nice if the cookie format were consistent. On the > other hand, specifying the format of the cookie will really tie the > hands of server implementors. We need to clarify this in the LCUP > specification, one way or another. > > -Mark > > James Benedict wrote: > > > > > -----Original Message----- > > > From: rvh@qsun.mt.att.com [mailto:rvh@qsun.mt.att.com] > > > Sent: Wednesday, May 16, 2001 12:55 PM > > > To: ietf-lcup@netscape.com; ietf-ldup@imc.org; richm@iplanet.com > > > Subject: Comments on LCUP draft - opaque cookie > > > > > > > > > This comment refers to . > > > > > > The controls defined in the LCUP draft use an opaque cookie > > > supplied by > > > the server. I'm concerned about the consequences of leaving > > > the cookie > > > opaque. It seems to me that interoperability with multiple servers > > > will be limited. > > > > > > Section 4.6 of the draft includes the note: > > > > > > (Note that the client can synchronize with different servers > > during > > > different synchronization sessions.) > > > > > > If the cookie is opaque, this will only work if the different > > servers > > > are all running the same server implementation. Different vendors' > > > implementations of LCUP will inevitably use different cookie formats > > > > > because there is no standard format. > > > > > > Section 7 notes: > > > > > > By design, the protocol does not specify the format of the cookie. > > > > > This is to allow different implementations the flexibility > > > of storing > > > any information applicable to their environment. > > > > > > > Haven't we been down this path before (with ACI)? I agree that the > > standard should not force a particular means of storing data, HOWEVER > > interoperability from a client perspective requires that information > > be common "on-the-wire". > > > > Or is the intention that LCUP clients maintain one cookie per server > > (or vendor type, or whatever...)? If this is the plan, then we still > > need to put some more smarts on the cookie so that the client can > > determine which cookie to send to which server. > > > > > But that flexibility will limit interoperability. Since > > multi-vendor > > > replicated directory environments are a goal of LDUP, shouldn't the > > > content of the cookie be specified in the standard? > > > > > > Rick Huber ------=_NextPart_001_0078_01C0F2A9.B6122090 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 ADR;HOME:;;214 New Street, Apt 4-N;Philadelphia;PA;19106;United States = of America LABEL;HOME;ENCODING=3DQUOTED-PRINTABLE:214 New Street, Apt = 4-N=3D0D=3D0APhiladelphia, PA 19106=3D0D=3D0AUnited States of Am=3D erica EMAIL;PREF;INTERNET:christopher.apple@unitedmessaging.com REV:20010413T223539Z END:VCARD ------=_NextPart_001_0078_01C0F2A9.B6122090-- ------=_NextPart_000_0077_01C0F2A9.B6122090 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 MQ8XDTAxMDYxMTIzMDcwOFowIwYJKoZIhvcNAQkEMRYEFMtqIqgJFe+24/x0NwXfxtXP18GZMFgG CSqGSIb3DQEJDzFLMEkwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwICAgCAMAcGBSsOAwIHMA0GCCqG SIb3DQMCAgEoMAcGBSsOAwIaMAoGCCqGSIb3DQIFMIGrBgkrBgEEAYI3EAQxgZ0wgZowgZIxCzAJ BgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEPMA0G A1UEChMGVGhhd3RlMR0wGwYDVQQLExRDZXJ0aWZpY2F0ZSBTZXJ2aWNlczEoMCYGA1UEAxMfUGVy c29uYWwgRnJlZW1haWwgUlNBIDIwMDAuOC4zMAIDBPxeMA0GCSqGSIb3DQEBAQUABIGAdUvvzUno 8HBKjaB7+1MHdSIEyNrYXnvea7ZRwfoj+fSt7tvsxt4YM3X12iJiFcqOSz3y5vi4NYjaK0qUXSVC C5vBQZ6XU+LY4nY8wfMd58f8iYnL9ZWAPFbptlKYvRPIqxr1u9KbcaUSijoOglgaXJsghdSC+HLH 6CXIVpeVstMAAAAAAAA= ------=_NextPart_000_0077_01C0F2A9.B6122090-- From owner-ietf-ldup@mail.imc.org Tue Jun 12 10:01:59 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA15362 for ; Tue, 12 Jun 2001 10:01:58 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.3/8.11.3) id f5CDbov25577 for ietf-ldup-bks; Tue, 12 Jun 2001 06:37:50 -0700 (PDT) Received: from kcmso1.proxy.att.com (kcmso1.att.com [192.128.133.69]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f5CDbhJ25567 for ; Tue, 12 Jun 2001 06:37:44 -0700 (PDT) Received: from qsun.mt.att.com ([135.16.30.2]) by kcmso1.proxy.att.com (AT&T IPNS/MSO-3.0) with SMTP id f5CDbaD08262; Tue, 12 Jun 2001 09:37:37 -0400 (EDT) Received: from att.com by qsun.mt.att.com (SMI-8.6/ATTEMS-1.4.1 sol2) id JAA00010; Tue, 12 Jun 2001 09:37:32 -0400 Message-ID: <3B261AD2.B86069BE@att.com> Date: Tue, 12 Jun 2001 09:36:18 -0400 From: Richard Huber X-Mailer: Mozilla 4.75 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: "Kurt D. Zeilenga" CC: ietf-ldup@imc.org, richm@iplanet.com Subject: Re: Comments on LCUP draft - opaque cookie References: <5.1.0.14.0.20010611144514.00adf690@127.0.0.1> 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 It seems to me that it will be a lot harder to add support for replicated environements later than it would be to put it in now. If we defer specification of the cookie, we will end up with a number of implementations with completely incompatible cookie formats. Once that has happened it will be much harder to get agreement on a standard format. Rick "Kurt D. Zeilenga" wrote: > At 02:44 PM 6/11/2001, Richard V Huber wrote: > >True. But shouldn't we be trying to do more than just "not prevent" > >interoperability? > > It is not preventing interoperability in replicated environments, > it is deferring specification of such features to future documents. > LCUP should be a simple client/server update protocol. If a > particular client can update from a particular server, this > client and server interoperate. > > If later, we want extend LCUP to allow a client to update > from any replica in a distributed environment, we can do > that. But I suggest we try to maintain a narrow focus > on this work. That is, I believe we should avoid defining > how LCUP works in a replicated/distributed environment at > this time. > > Kurt > > >Rick > > > >: To: rvh@qsun.mt.att.com (Richard V Huber) > >: From: "Kurt D. Zeilenga" > >: Subject: Re: Comments on LCUP draft - opaque cookie > >: Cc: richm@iplanet.com, ietf-ldup@imc.org > >: > >: At 02:27 PM 6/11/2001, Richard V Huber wrote: > >: >But that would mean that any system with a load-balancer in front of a > >: >set of replicated directory servers would require complete resync > >: >unless the user lucked out and got the same server they had on their > >: >last connection. > >: > >: Having an opaque cookie does not prevent a vendor from provide > >: such capabilities. > >: > >: Kurt From owner-ietf-ldup@mail.imc.org Tue Jun 12 10:20:16 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA16051 for ; Tue, 12 Jun 2001 10:20:11 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.3/8.11.3) id f5CDsk926286 for ietf-ldup-bks; Tue, 12 Jun 2001 06:54:46 -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 f5CDsjJ26282 for ; Tue, 12 Jun 2001 06:54:45 -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 f5CDscr04726 for ; Tue, 12 Jun 2001 06:54:38 -0700 (PDT) Received: from netscape.com ([205.217.243.76]) by judge.mcom.com (Netscape Messaging Server 4.15) with ESMTP id GETLB302.DOR; Tue, 12 Jun 2001 06:54:39 -0700 Message-ID: <3B261E83.A525A8DC@netscape.com> Date: Tue, 12 Jun 2001 09:52:03 -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: "Kurt D. Zeilenga" CC: Christopher Apple , "'ietf-ldup@imc.org'" , "John Strassner (E-mail)" Subject: Re: WG Last Call Status of Requirements Document References: <5.1.0.14.0.20010607112512.00afd8d8@127.0.0.1> 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 "Kurt D. Zeilenga" wrote: > > At 07:34 AM 6/4/2001, Christopher Apple wrote: > > S2a. The replication protocol MUST support transfer of data with > > integrity and confidentiality. > > > > S2b. The replication protocol MUST support the ability during > > initialization of a replication session for an authenticated > > source and replica to mutually decide to turn off data > > integrity and confidentiality within the context of and for > > the duration of that particular replication session. > > These two requirements would adequate address my concerns in this area. I would like to see the phrase "turn off" replaced with "disable." To me, "turn off" implies that data integrity and confidentiality is "on" by default which is not necessarily the case. Otherwise, I like both of these requirements. -Mark From owner-ietf-ldup@mail.imc.org Tue Jun 12 10:24:15 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA16153 for ; Tue, 12 Jun 2001 10:24:09 -0400 (EDT) Received: by above.proper.com (8.11.3/8.11.3) id f5CDxSk26520 for ietf-ldup-bks; Tue, 12 Jun 2001 06:59:28 -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 f5CDxRJ26516 for ; Tue, 12 Jun 2001 06:59:27 -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 f5CDxLY13054 for ; Tue, 12 Jun 2001 06:59:21 -0700 (PDT) Received: from netscape.com ([205.217.243.76]) by judge.mcom.com (Netscape Messaging Server 4.15) with ESMTP id GETLIX00.RLU; Tue, 12 Jun 2001 06:59:21 -0700 Message-ID: <3B262051.2F25D37D@netscape.com> Date: Tue, 12 Jun 2001 09:59:45 -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: john.strassner@intelliden.com CC: Christopher Apple , "'Ietf-Ldup@Imc. Org'" , "'Kurt D. Zeilenga'" Subject: Re: WG Last Call Status of Requirements Document 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 John Strassner wrote: > At 07:34 AM 6/4/2001, Christopher Apple wrote: > >G9. LDAP replication SHOULD support replication of directoryOperation > > and distributedOperation attribute types defined in standards track > > LDAP extensions. Future standards track specifications MUST include > a > > "Replication Considerations" section which indicates how and whether > > the new feature operates in a replicated environment. > > > >Kurt wanted to remove the last sentence. I would prefer to keep it, but change the "MUST" to a "SHOULD." I think the sentence needs some improvement though. Does the requirement refer to ALL future standards track RFCs for LDAP? Or just the ones that define extensions? -Mark From owner-ietf-ldup@mail.imc.org Tue Jun 12 11:29:23 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA17658 for ; Tue, 12 Jun 2001 11:29:23 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.3/8.11.3) id f5CF0eY28961 for ietf-ldup-bks; Tue, 12 Jun 2001 08:00:40 -0700 (PDT) Received: from avocet.mail.pas.earthlink.net (avocet.mail.pas.earthlink.net [207.217.121.50]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f5CF0dJ28955 for ; Tue, 12 Jun 2001 08:00:39 -0700 (PDT) Received: from FARILJCS (pool0143.cvx21-bradley.dialup.earthlink.net [209.179.192.143]) by avocet.mail.pas.earthlink.net (EL-8_9_3_3/8.9.3) with SMTP id IAA10103; Tue, 12 Jun 2001 08:00:24 -0700 (PDT) Reply-To: From: "John Strassner" To: "Mark C Smith" , "Kurt D. Zeilenga" Cc: "Christopher Apple" , Subject: RE: WG Last Call Status of Requirements Document Date: Tue, 12 Jun 2001 08:00:20 -0700 MIME-Version: 1.0 Message-ID: X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) Content-Type: multipart/signed; micalg=SHA1; protocol="application/x-pkcs7-signature"; boundary="----=_NextPart_000_0072_01C0F315.B97E9F80" In-Reply-To: <3B261E83.A525A8DC@netscape.com> Importance: Normal 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_0072_01C0F315.B97E9F80 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit I think that the replacement that Mark is suggesting better reflects the original intention of Chris and myself. Plus, semantically, it is clearer. regards, John -----Original Message----- From: owner-ietf-ldup@mail.imc.org [mailto:owner-ietf-ldup@mail.imc.org]On Behalf Of Mark C Smith Sent: Tuesday, June 12, 2001 6:52 AM To: Kurt D. Zeilenga Cc: Christopher Apple; 'ietf-ldup@imc.org'; John Strassner (E-mail) Subject: Re: WG Last Call Status of Requirements Document "Kurt D. Zeilenga" wrote: > > At 07:34 AM 6/4/2001, Christopher Apple wrote: > > S2a. The replication protocol MUST support transfer of data with > > integrity and confidentiality. > > > > S2b. The replication protocol MUST support the ability during > > initialization of a replication session for an authenticated > > source and replica to mutually decide to turn off data > > integrity and confidentiality within the context of and for > > the duration of that particular replication session. > > These two requirements would adequate address my concerns in this area. I would like to see the phrase "turn off" replaced with "disable." To me, "turn off" implies that data integrity and confidentiality is "on" by default which is not necessarily the case. Otherwise, I like both of these requirements. -Mark ------=_NextPart_000_0072_01C0F315.B97E9F80 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 AQkFMQ8XDTAxMDYxMjE1MDAxOVowIwYJKoZIhvcNAQkEMRYEFLsphBaFVp3jA9OC2bBz7oWppFDD MFgGCSqGSIb3DQEJDzFLMEkwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwICAgCAMAcGBSsOAwIHMA0G CCqGSIb3DQMCAgEoMAcGBSsOAwIaMAoGCCqGSIb3DQIFMIGrBgkrBgEEAYI3EAQxgZ0wgZowgZIx CzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEP MA0GA1UEChMGVGhhd3RlMR0wGwYDVQQLExRDZXJ0aWZpY2F0ZSBTZXJ2aWNlczEoMCYGA1UEAxMf UGVyc29uYWwgRnJlZW1haWwgUlNBIDIwMDAuOC4zMAIDBKRvMA0GCSqGSIb3DQEBAQUABIGAmQ3p qFpqdCsvMi7PIUe1COcfl5NVJYNJrjR5Qsu5F2BSob0xORbOCkmhR2BADde+ba15GlkZWQO7U3ND yksFfYYsarz0VOSr4nljZLBmUzbr3GP9ix59aBiqVgJQ0vYZdmbnC4N5dwFSt1TeCwP+jXsTx9+u LjFLP/UGjErAbtsAAAAAAAA= ------=_NextPart_000_0072_01C0F315.B97E9F80-- From owner-ietf-ldup@mail.imc.org Tue Jun 12 12:15:50 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA18499 for ; Tue, 12 Jun 2001 12:15:49 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.3/8.11.3) id f5CFlor05201 for ietf-ldup-bks; Tue, 12 Jun 2001 08:47:50 -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 f5CFlmJ05195 for ; Tue, 12 Jun 2001 08:47:48 -0700 (PDT) Received: from ex01.ummail.com [216.33.108.253:25] by hawk.ummail.com with SMTP id Q0612-1147-083600; Tue, 12 Jun 2001 15:47:31 GMT Received: by ex01.ummail.com with Internet Mail Service (5.5.2650.21) id ; Tue, 12 Jun 2001 11:46:00 -0400 Message-ID: From: Christopher Apple To: "'Richard Huber'" , "Kurt D. Zeilenga" Cc: ietf-ldup@imc.org, richm@iplanet.com Subject: RE: Comments on LCUP draft - opaque cookie Date: Tue, 12 Jun 2001 11:45:59 -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_002A_01C0F335.4F889020"; 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_002A_01C0F335.4F889020 Content-Type: multipart/mixed; boundary="----=_NextPart_001_002B_01C0F335.4F889020" ------=_NextPart_001_002B_01C0F335.4F889020 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Definitely agree with what Rick said. Here's another perspective, strictly not speaking as a co-chair, related to upgrading from a version of LCUP in which the cookie is opaque to one in which the cookie is exposed: I work for an ASP, specifically, a messaging ASP. Messaging applications are often tightly coupled with an LDAP or other directory implementation. Also, we happen to host 3 distinct messaging platforms from 3 different vendors, each of whom have their own LDAP/Directory implementations. Assume that we have a substantial portion of our customer base requiring synchronization services for which LCUP would be a fairly close match in a theoretical sense. Nearly all of these customers refuse to allow custom-built software (built by developers at my company) to be installed on servers that they operate. Couple this with the fact that as a whole, they have very diverse operating environments for their internally hosted IT systems and do not want to have to change that environment significantly to be able to outsource messaging application hosting to us. If we were to elect to use LCUP as a solution to the appropriate subset of synchronization problems that our customer base has, we would have to let them choose the LCUP client implementation that would operate in their own local environment - and we would, for operational simplicity, constrain ourselves to operating LCUP server-side interfaces that would be associated with the directories/LDAP servers tied to our 3 different messaging platforms. In my company's ASP environment, you end up with a couple of nasty problems if the cookie format is not standards track now but becomes so later on: 1) A complex upgrade situation affecting multiple customers' corporate messaging systems. 2) An overly complex operating environment from day 1. Assume LCUP becomes deployed. ASP customers often will not allow their ASPs to drive the selection of software necessary to integrate end-user client application address books with the LDAP servers associated with the messaging platforms that we host. Some of our customers actually require that some of their end-users be hosted on one messaging platform with the rest on a different platform. These customers also usually have: - 2 or 3 different end-user client machine environments - 6 or 7 different messaging clients (some of which are the same vendor's but different versions) that have address book applications or add-ons Even with a standards-track cookie format, that's a complex operating environment in which to get everything working smoothly from an LCUP perspective. But with a standards-track cookie format, you at least have a framework that can be used to certify that appropriately configured LCUP-compliant clients and servers can work together if from different vendors. If the cookie format is opaque, I'm not convinced it could ever work unless we start hacking apart cookies and translating them on the fly on a pair-wise basis for every deployed combination of client (including multiple versions) and server through some sort of application-level gateway. In fact, since most IT managers either will not or cannot do a flash upgrade of all end-user messaging client software within a narrow window of time, a cookie gateway would be a required component during upgrades if the cookie is opaque. This scenario would compound the operational complexity of executing an upgrade from versions of LCUP implementations that don't support an exposed cookie format to those that do. So much so, that I wouldn't be able to justify from an operational or a financial perspective, either the in-house implementation of an LCUP solution or the licensing of commercial LCUP technology for building an address book synchronization solution. Chris Apple Program Manager - Directory Services United Messaging Inc. (V) 610-425-2860 -----Original Message----- From: Richard Huber [mailto:rvh@att.com] Sent: Tuesday, June 12, 2001 9:36 AM To: Kurt D. Zeilenga Cc: ietf-ldup@imc.org; richm@iplanet.com Subject: Re: Comments on LCUP draft - opaque cookie It seems to me that it will be a lot harder to add support for replicated environements later than it would be to put it in now. If we defer specification of the cookie, we will end up with a number of implementations with completely incompatible cookie formats. Once that has happened it will be much harder to get agreement on a standard format. Rick "Kurt D. Zeilenga" wrote: > At 02:44 PM 6/11/2001, Richard V Huber wrote: > >True. But shouldn't we be trying to do more than just "not prevent" > >interoperability? > > It is not preventing interoperability in replicated environments, > it is deferring specification of such features to future documents. > LCUP should be a simple client/server update protocol. If a > particular client can update from a particular server, this > client and server interoperate. > > If later, we want extend LCUP to allow a client to update > from any replica in a distributed environment, we can do > that. But I suggest we try to maintain a narrow focus > on this work. That is, I believe we should avoid defining > how LCUP works in a replicated/distributed environment at > this time. > > Kurt > > >Rick > > > >: To: rvh@qsun.mt.att.com (Richard V Huber) > >: From: "Kurt D. Zeilenga" > >: Subject: Re: Comments on LCUP draft - opaque cookie > >: Cc: richm@iplanet.com, ietf-ldup@imc.org > >: > >: At 02:27 PM 6/11/2001, Richard V Huber wrote: > >: >But that would mean that any system with a load-balancer in front of a > >: >set of replicated directory servers would require complete resync > >: >unless the user lucked out and got the same server they had on their > >: >last connection. > >: > >: Having an opaque cookie does not prevent a vendor from provide > >: such capabilities. > >: > >: Kurt ------=_NextPart_001_002B_01C0F335.4F889020 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 ADR;HOME:;;214 New Street, Apt 4-N;Philadelphia;PA;19106;United States = of America LABEL;HOME;ENCODING=3DQUOTED-PRINTABLE:214 New Street, Apt = 4-N=3D0D=3D0APhiladelphia, PA 19106=3D0D=3D0AUnited States of Am=3D erica EMAIL;PREF;INTERNET:christopher.apple@unitedmessaging.com REV:20010413T223539Z END:VCARD ------=_NextPart_001_002B_01C0F335.4F889020-- ------=_NextPart_000_002A_01C0F335.4F889020 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 MQ8XDTAxMDYxMjE1NDYyNVowIwYJKoZIhvcNAQkEMRYEFGoxPb0OeMGMT80nK86kKnVE5sbuMFgG CSqGSIb3DQEJDzFLMEkwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwICAgCAMAcGBSsOAwIHMA0GCCqG SIb3DQMCAgEoMAcGBSsOAwIaMAoGCCqGSIb3DQIFMIGrBgkrBgEEAYI3EAQxgZ0wgZowgZIxCzAJ BgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEPMA0G A1UEChMGVGhhd3RlMR0wGwYDVQQLExRDZXJ0aWZpY2F0ZSBTZXJ2aWNlczEoMCYGA1UEAxMfUGVy c29uYWwgRnJlZW1haWwgUlNBIDIwMDAuOC4zMAIDBPxeMA0GCSqGSIb3DQEBAQUABIGAt3sxTOPO AhKWBICO0rzLbzNExx6o2y47X8xcZf0P6c5I3AmLnOBl8Ykbqkez+hjoecuSeQ1WD7g46AP35W6l PXEgyphUOYqFvBwzhmFC5934ibCeNJY73g6wI+a06a5ThzXD9Xc7ZhnF1jyFEKbHJp3/qG8dyOuq Wuvkim920P0AAAAAAAA= ------=_NextPart_000_002A_01C0F335.4F889020-- From owner-ietf-ldup@mail.imc.org Tue Jun 12 12:22:56 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA18615 for ; Tue, 12 Jun 2001 12:22:56 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.3/8.11.3) id f5CFmbP05237 for ietf-ldup-bks; Tue, 12 Jun 2001 08:48:37 -0700 (PDT) Received: from hawk.ummail.com (hawk.ummail.com [216.33.108.234]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f5CFmaJ05233 for ; Tue, 12 Jun 2001 08:48:36 -0700 (PDT) Received: from ex01.ummail.com [216.33.108.253:25] by hawk.ummail.com with SMTP id Q0612-1147-092800; Tue, 12 Jun 2001 15:47:51 GMT Received: by ex01.ummail.com with Internet Mail Service (5.5.2650.21) id ; Tue, 12 Jun 2001 11:46:21 -0400 Message-ID: From: Christopher Apple To: "'john.strassner@intelliden.com'" , Mark C Smith , "Kurt D. Zeilenga" Cc: Christopher Apple , ietf-ldup@imc.org Subject: RE: WG Last Call Status of Requirements Document Date: Tue, 12 Jun 2001 11:46:20 -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_0036_01C0F335.5C0E6F40"; 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_0036_01C0F335.5C0E6F40 Content-Type: multipart/mixed; boundary="----=_NextPart_001_0037_01C0F335.5C0E6F40" ------=_NextPart_001_0037_01C0F335.5C0E6F40 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Yup. Chris Apple Program Manager - Directory Services United Messaging Inc. (V) 610-425-2860 -----Original Message----- From: John Strassner [mailto:john.strassner@intelliden.com] Sent: Tuesday, June 12, 2001 11:00 AM To: Mark C Smith; Kurt D. Zeilenga Cc: Christopher Apple; ietf-ldup@imc.org Subject: RE: WG Last Call Status of Requirements Document I think that the replacement that Mark is suggesting better reflects the original intention of Chris and myself. Plus, semantically, it is clearer. regards, John -----Original Message----- From: owner-ietf-ldup@mail.imc.org [mailto:owner-ietf-ldup@mail.imc.org]On Behalf Of Mark C Smith Sent: Tuesday, June 12, 2001 6:52 AM To: Kurt D. Zeilenga Cc: Christopher Apple; 'ietf-ldup@imc.org'; John Strassner (E-mail) Subject: Re: WG Last Call Status of Requirements Document "Kurt D. Zeilenga" wrote: > > At 07:34 AM 6/4/2001, Christopher Apple wrote: > > S2a. The replication protocol MUST support transfer of data with > > integrity and confidentiality. > > > > S2b. The replication protocol MUST support the ability during > > initialization of a replication session for an authenticated > > source and replica to mutually decide to turn off data > > integrity and confidentiality within the context of and for > > the duration of that particular replication session. > > These two requirements would adequate address my concerns in this area. I would like to see the phrase "turn off" replaced with "disable." To me, "turn off" implies that data integrity and confidentiality is "on" by default which is not necessarily the case. Otherwise, I like both of these requirements. -Mark ------=_NextPart_001_0037_01C0F335.5C0E6F40 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 ADR;HOME:;;214 New Street, Apt 4-N;Philadelphia;PA;19106;United States = of America LABEL;HOME;ENCODING=3DQUOTED-PRINTABLE:214 New Street, Apt = 4-N=3D0D=3D0APhiladelphia, PA 19106=3D0D=3D0AUnited States of Am=3D erica EMAIL;PREF;INTERNET:christopher.apple@unitedmessaging.com REV:20010413T223539Z END:VCARD ------=_NextPart_001_0037_01C0F335.5C0E6F40-- ------=_NextPart_000_0036_01C0F335.5C0E6F40 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 MQ8XDTAxMDYxMjE1NDY0NlowIwYJKoZIhvcNAQkEMRYEFDpnVrTs+jB7GNNpqDdRdnju3hrbMFgG CSqGSIb3DQEJDzFLMEkwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwICAgCAMAcGBSsOAwIHMA0GCCqG SIb3DQMCAgEoMAcGBSsOAwIaMAoGCCqGSIb3DQIFMIGrBgkrBgEEAYI3EAQxgZ0wgZowgZIxCzAJ BgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEPMA0G A1UEChMGVGhhd3RlMR0wGwYDVQQLExRDZXJ0aWZpY2F0ZSBTZXJ2aWNlczEoMCYGA1UEAxMfUGVy c29uYWwgRnJlZW1haWwgUlNBIDIwMDAuOC4zMAIDBPxeMA0GCSqGSIb3DQEBAQUABIGAp00C3dAY gk2pIW7w8m02uIsggQ4wKXEkl0XNFcq8ZXoF1YQ4VbHGK7gvm0lgtE5CwR5dAEGxa2gUAlbiyLrT ia8iYn+U1NKcgV+fyc3SeQ82VvPsj3Iz0kxi0/b4JoUeno9+As5tmvMG/I6fO8NUniHHBgAk0gvj 8XQUB98Ema0AAAAAAAA= ------=_NextPart_000_0036_01C0F335.5C0E6F40-- From owner-ietf-ldup@mail.imc.org Tue Jun 12 13:40:26 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA20634 for ; Tue, 12 Jun 2001 13:40:25 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.3/8.11.3) id f5CH7Wq08225 for ietf-ldup-bks; Tue, 12 Jun 2001 10:07:32 -0700 (PDT) Received: from avocet.mail.pas.earthlink.net (avocet.mail.pas.earthlink.net [207.217.121.50]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f5CH7VJ08221 for ; Tue, 12 Jun 2001 10:07:31 -0700 (PDT) Received: from FARILJCS (pool0866.cvx20-bradley.dialup.earthlink.net [209.179.253.101]) by avocet.mail.pas.earthlink.net (EL-8_9_3_3/8.9.3) with SMTP id KAA22363; Tue, 12 Jun 2001 10:07:17 -0700 (PDT) Reply-To: From: "John Strassner" To: "Christopher Apple" , "'Richard Huber'" , "Kurt D. Zeilenga" Cc: , Subject: RE: Comments on LCUP draft - opaque cookie Date: Tue, 12 Jun 2001 10:07:09 -0700 MIME-Version: 1.0 Message-ID: X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) Content-Type: multipart/signed; micalg=SHA1; protocol="application/x-pkcs7-signature"; boundary="----=_NextPart_000_0112_01C0F327.70D22BF0" In-Reply-To: Importance: Normal 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_0112_01C0F327.70D22BF0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit I agree with Chris and Richard (and yes, this is an an individual and NOT as a co-chair). Having an opaque cookie defeats the purpose of interoperability, period. Promising that somehow, someday, we will agree on converging on one standard format while multiple private formats have been deployed won't happen. regards, John -----Original Message----- From: owner-ietf-ldup@mail.imc.org [mailto:owner-ietf-ldup@mail.imc.org]On Behalf Of Christopher Apple Sent: Tuesday, June 12, 2001 8:46 AM To: 'Richard Huber'; Kurt D. Zeilenga Cc: ietf-ldup@imc.org; richm@iplanet.com Subject: RE: Comments on LCUP draft - opaque cookie Definitely agree with what Rick said. Here's another perspective, strictly not speaking as a co-chair, related to upgrading from a version of LCUP in which the cookie is opaque to one in which the cookie is exposed: I work for an ASP, specifically, a messaging ASP. Messaging applications are often tightly coupled with an LDAP or other directory implementation. Also, we happen to host 3 distinct messaging platforms from 3 different vendors, each of whom have their own LDAP/Directory implementations. Assume that we have a substantial portion of our customer base requiring synchronization services for which LCUP would be a fairly close match in a theoretical sense. Nearly all of these customers refuse to allow custom-built software (built by developers at my company) to be installed on servers that they operate. Couple this with the fact that as a whole, they have very diverse operating environments for their internally hosted IT systems and do not want to have to change that environment significantly to be able to outsource messaging application hosting to us. If we were to elect to use LCUP as a solution to the appropriate subset of synchronization problems that our customer base has, we would have to let them choose the LCUP client implementation that would operate in their own local environment - and we would, for operational simplicity, constrain ourselves to operating LCUP server-side interfaces that would be associated with the directories/LDAP servers tied to our 3 different messaging platforms. In my company's ASP environment, you end up with a couple of nasty problems if the cookie format is not standards track now but becomes so later on: 1) A complex upgrade situation affecting multiple customers' corporate messaging systems. 2) An overly complex operating environment from day 1. Assume LCUP becomes deployed. ASP customers often will not allow their ASPs to drive the selection of software necessary to integrate end-user client application address books with the LDAP servers associated with the messaging platforms that we host. Some of our customers actually require that some of their end-users be hosted on one messaging platform with the rest on a different platform. These customers also usually have: - 2 or 3 different end-user client machine environments - 6 or 7 different messaging clients (some of which are the same vendor's but different versions) that have address book applications or add-ons Even with a standards-track cookie format, that's a complex operating environment in which to get everything working smoothly from an LCUP perspective. But with a standards-track cookie format, you at least have a framework that can be used to certify that appropriately configured LCUP-compliant clients and servers can work together if from different vendors. If the cookie format is opaque, I'm not convinced it could ever work unless we start hacking apart cookies and translating them on the fly on a pair-wise basis for every deployed combination of client (including multiple versions) and server through some sort of application-level gateway. In fact, since most IT managers either will not or cannot do a flash upgrade of all end-user messaging client software within a narrow window of time, a cookie gateway would be a required component during upgrades if the cookie is opaque. This scenario would compound the operational complexity of executing an upgrade from versions of LCUP implementations that don't support an exposed cookie format to those that do. So much so, that I wouldn't be able to justify from an operational or a financial perspective, either the in-house implementation of an LCUP solution or the licensing of commercial LCUP technology for building an address book synchronization solution. Chris Apple Program Manager - Directory Services United Messaging Inc. (V) 610-425-2860 -----Original Message----- From: Richard Huber [mailto:rvh@att.com] Sent: Tuesday, June 12, 2001 9:36 AM To: Kurt D. Zeilenga Cc: ietf-ldup@imc.org; richm@iplanet.com Subject: Re: Comments on LCUP draft - opaque cookie It seems to me that it will be a lot harder to add support for replicated environements later than it would be to put it in now. If we defer specification of the cookie, we will end up with a number of implementations with completely incompatible cookie formats. Once that has happened it will be much harder to get agreement on a standard format. Rick "Kurt D. Zeilenga" wrote: > At 02:44 PM 6/11/2001, Richard V Huber wrote: > >True. But shouldn't we be trying to do more than just "not prevent" > >interoperability? > > It is not preventing interoperability in replicated environments, > it is deferring specification of such features to future documents. > LCUP should be a simple client/server update protocol. If a > particular client can update from a particular server, this > client and server interoperate. > > If later, we want extend LCUP to allow a client to update > from any replica in a distributed environment, we can do > that. But I suggest we try to maintain a narrow focus > on this work. That is, I believe we should avoid defining > how LCUP works in a replicated/distributed environment at > this time. > > Kurt > > >Rick > > > >: To: rvh@qsun.mt.att.com (Richard V Huber) > >: From: "Kurt D. Zeilenga" > >: Subject: Re: Comments on LCUP draft - opaque cookie > >: Cc: richm@iplanet.com, ietf-ldup@imc.org > >: > >: At 02:27 PM 6/11/2001, Richard V Huber wrote: > >: >But that would mean that any system with a load-balancer in front of a > >: >set of replicated directory servers would require complete resync > >: >unless the user lucked out and got the same server they had on their > >: >last connection. > >: > >: Having an opaque cookie does not prevent a vendor from provide > >: such capabilities. > >: > >: Kurt ------=_NextPart_000_0112_01C0F327.70D22BF0 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 AQkFMQ8XDTAxMDYxMjE3MDcwOFowIwYJKoZIhvcNAQkEMRYEFKmXg81WLMdQsb6hFVHxxcdqcnvU MFgGCSqGSIb3DQEJDzFLMEkwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwICAgCAMAcGBSsOAwIHMA0G CCqGSIb3DQMCAgEoMAcGBSsOAwIaMAoGCCqGSIb3DQIFMIGrBgkrBgEEAYI3EAQxgZ0wgZowgZIx CzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEP MA0GA1UEChMGVGhhd3RlMR0wGwYDVQQLExRDZXJ0aWZpY2F0ZSBTZXJ2aWNlczEoMCYGA1UEAxMf UGVyc29uYWwgRnJlZW1haWwgUlNBIDIwMDAuOC4zMAIDBKRvMA0GCSqGSIb3DQEBAQUABIGAJuro /bAesL0nTOFMj31U/Pixw64NUIjX6vAAN2XnFxPLZUbQZy4FahRnS4is8+CiX7L9tOCWvQPBAwBK WY7HCjwIrb/9fWMccFnGkXm5ytKRloMvqViHrVeXDcT37XV7eJzUOkQfcTP81zNs+iNv8+5ABMSK bDQUutwa4K8Iav8AAAAAAAA= ------=_NextPart_000_0112_01C0F327.70D22BF0-- From owner-ietf-ldup@mail.imc.org Tue Jun 12 14:40:21 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA22198 for ; Tue, 12 Jun 2001 14:40:20 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.3/8.11.3) id f5CIHY710848 for ietf-ldup-bks; Tue, 12 Jun 2001 11:17:34 -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 f5CIHWJ10843 for ; Tue, 12 Jun 2001 11:17:32 -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 f5CIGsE25005; Tue, 12 Jun 2001 14:16:54 -0400 (EDT) Received: by qsun.mt.att.com (SMI-8.6/ATTEMS-1.4.1 sol2) id OAA11576; Tue, 12 Jun 2001 14:16:52 -0400 Date: Tue, 12 Jun 2001 14:16:52 -0400 Message-Id: <200106121816.OAA11576@qsun.mt.att.com> From: rvh@qsun.mt.att.com (Richard V Huber) To: internet-drafts@ietf.org Subject: New Requirements 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 draft below as draft-ietf-ldup-replica-req-09.txt LDUPers - Draft -09 of the requirements is attached below. Changes from draft -08 include: - Added definition of Anonymous Replication as previously posted to the list. - Changed G9 to make the Replication Considerations section a SHOULD instead of a MUST. - Added "area(s) of replication" to the list of replication parameters in M7. - Moved the old P3 to the M section and made it M12 since it addressed issues beyond the protocol. All the P requirements now clearly deal with the protocol. - Renumbered the P requirements since P3 was moved. - Added a note to P6 (formerly P7): "In a multi-master environment this may lead to an unresolvable conflict. MM5 and MM6 discuss how to handle this situation." - Added the new S requirements from Chris and John's email, reworded to make it clear that we are talking about data consistency and data integrity as defined in RFC2828. Also added Mark Smith's comment ("turn off" -> "disable"). As a result the S requirements were renumbered. - Rephrased Appendix B.6 in terms of the RFC2828 definitions. "Privacy" is no longer used. Also added a brief justification for Anonymous Replication. - Various changes to authors' affiliations and contact information. Since these changes were made as a result of the previous last call, the authors would like to start a new last call immediately. Rick Huber --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- Internet-Draft Ellen J. Stokes LDAP Duplication/Replication/Update Tivoli Systems Protocols WG Russel F. Weiser Intended Category: Informational Digital Signature Trust Expires: December 2001 Ryan D. Moats Richard V. Huber AT&T Laboratories June 2001 LDAPv3 Replication Requirements draft-ietf-ldup-replica-req-09.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 December 2001 [Page 1] Internet-Draft LDAPv3 Replication Requirements June 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 December 2001 [Page 2] Internet-Draft LDAPv3 Replication Requirements June 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...................................................11 4.7 Administration and Management..................................12 4.8 Security.......................................................13 5 Security Considerations...........................................13 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......................................16 A.5.Supplier Initiated Replication.................................17 A.6.Consumer Initiated Replication.................................17 A.7.Prioritized attribute replication..............................17 A.8.Bandwidth issues...............................................17 A.9.Interoperable Administration and Management....................18 A.10.Enterprise Directory Replication Mesh.........................18 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............................................19 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 December 2001 [Page 3] Internet-Draft LDAPv3 Replication Requirements June 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 December 2001 [Page 4] Internet-Draft LDAPv3 Replication Requirements June 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 December 2001 [Page 5] Internet-Draft LDAPv3 Replication Requirements June 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 December 2001 [Page 6] Internet-Draft LDAPv3 Replication Requirements June 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 December 2001 [Page 7] Internet-Draft LDAPv3 Replication Requirements June 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 LDUP replication may be limited for implementations that add semantics beyond those specified by the LDAP core documents (RFC 2251-2256, 2829, 2830). 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 - 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) Stokes, et al Expires December 2001 [Page 8] Internet-Draft LDAPv3 Replication Requirements June 2001 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 all copies of the replicated information to be complete copies of the replicated object. The model MUST support Partial Replicas. 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 Stokes, et al Expires December 2001 [Page 9] Internet-Draft LDAPv3 Replication Requirements June 2001 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. 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. Stokes, et al Expires December 2001 [Page 10] Internet-Draft LDAPv3 Replication Requirements June 2001 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. 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. Stokes, et al Expires December 2001 [Page 11] Internet-Draft LDAPv3 Replication Requirements June 2001 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. 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. Stokes, et al Expires December 2001 [Page 12] Internet-Draft LDAPv3 Replication Requirements June 2001 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. 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, 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]. Stokes, et al Expires December 2001 [Page 13] Internet-Draft LDAPv3 Replication Requirements June 2001 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. [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. [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. [RFC2820] E. Stokes, D. Byrne, B. Blakley, P. Behera, "Access Control Requirements for LDAP", RFC 2820, May 2000. [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. Stokes, et al Expires December 2001 [Page 14] Internet-Draft LDAPv3 Replication Requirements June 2001 [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 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. Stokes, et al Expires December 2001 [Page 15] Internet-Draft LDAPv3 Replication Requirements June 2001 - 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. 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. Stokes, et al Expires December 2001 [Page 16] Internet-Draft LDAPv3 Replication Requirements June 2001 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 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 Stokes, et al Expires December 2001 [Page 17] Internet-Draft LDAPv3 Replication Requirements June 2001 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. 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: Stokes, et al Expires December 2001 [Page 18] Internet-Draft LDAPv3 Replication Requirements June 2001 - 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 - 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, Stokes, et al Expires December 2001 [Page 19] Internet-Draft LDAPv3 Replication Requirements June 2001 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 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 Stokes, et al Expires December 2001 [Page 20] Internet-Draft LDAPv3 Replication Requirements June 2001 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. 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. Stokes, et al Expires December 2001 [Page 21] Internet-Draft LDAPv3 Replication Requirements June 2001 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 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. Stokes, et al Expires December 2001 [Page 22] Internet-Draft LDAPv3 Replication Requirements June 2001 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. 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 Stokes, et al Expires December 2001 [Page 23] Internet-Draft LDAPv3 Replication Requirements June 2001 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 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 Stokes, et al Expires December 2001 [Page 24] Internet-Draft LDAPv3 Replication Requirements June 2001 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. 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 Stokes, et al Expires December 2001 [Page 25] Internet-Draft LDAPv3 Replication Requirements June 2001 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 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. Stokes, et al Expires December 2001 [Page 26] Internet-Draft LDAPv3 Replication Requirements June 2001 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. - 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 Stokes, et al Expires December 2001 [Page 27] Internet-Draft LDAPv3 Replication Requirements June 2001 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 246 4323 Fax: +1 801 246 4361 Ellen J. Stokes 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 15621 Drexel Circle Omaha, NE 68135 USA E-Mail: j4yh4wk@netscape.net Stokes, et al Expires December 2001 [Page 28] Internet-Draft LDAPv3 Replication Requirements June 2001 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. 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 December 2001 [Page 29] From owner-ietf-ldup@mail.imc.org Tue Jun 12 14:48:30 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA22309 for ; Tue, 12 Jun 2001 14:48:30 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.3/8.11.3) id f5CIU2g11309 for ietf-ldup-bks; Tue, 12 Jun 2001 11:30: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 f5CIU0J11304 for ; Tue, 12 Jun 2001 11:30: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 f5CIShp41034; Tue, 12 Jun 2001 18:28:43 GMT (envelope-from Kurt@OpenLDAP.org) Message-Id: <5.1.0.14.0.20010612105554.00adec00@127.0.0.1> X-Sender: kurt@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Tue, 12 Jun 2001 11:28:34 -0700 To: From: "Kurt D. Zeilenga" Subject: RE: Comments on LCUP draft - opaque cookie Cc: "Christopher Apple" , "'Richard Huber'" , , In-Reply-To: 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: From my perspective, the format of the cookie isn't the real issue. The real issue is whether LCUP will support replicated environments. In particular, whether a client which updated from replica A can then incrementally update from replica B where the replicate model has loose data consistency rules (that is, in replicated environments where A and B may be out of sync, such as in LDUP-based replication). Supporting replicated environments will go far beyond specifying the structure of the cookie and require significant more work. It's my opinion that LCUP support of replicated environments should be viewed as beyond the scope of this work and left to future extension. Kurt From owner-ietf-ldup@mail.imc.org Tue Jun 12 15:43:32 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA23272 for ; Tue, 12 Jun 2001 15:43:31 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.3/8.11.3) id f5CJKkN13016 for ietf-ldup-bks; Tue, 12 Jun 2001 12:20:46 -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 f5CJKjJ13009 for ; Tue, 12 Jun 2001 12:20:45 -0700 (PDT) Received: from ex01.ummail.com [216.33.108.253:25] by hawk.ummail.com with SMTP id Q0612-1519-13cb00; Tue, 12 Jun 2001 19:19:53 GMT Received: by ex01.ummail.com with Internet Mail Service (5.5.2650.21) id ; Tue, 12 Jun 2001 15:18:22 -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: Comments on LCUP draft - opaque cookie Date: Tue, 12 Jun 2001 15:18:21 -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_000C_01C0F352.F9EDC130" 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_000C_01C0F352.F9EDC130 Content-Type: multipart/mixed; boundary="----=_NextPart_001_000D_01C0F352.F9F25510" ------=_NextPart_001_000D_01C0F352.F9F25510 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit There are really two questions that must be answered. Both of them represent very real issues for the WG to resolve. The answers that the WG achieves consensus on are at the crux of the degree to which LCUP clients and servers from different vendors will be able to interoperate. 1) Should LCUP's cookie format be exposed or opaque? 2) Should LCUP explicitly support replicated environments based on LDAPv3-based replication (LDUP)? You could answer 1 without necessarily considering 2 in detail. However, I don't believe that would be a good idea. Not considering 2 as input for answering 1 means that you could end up with a cookie format consensus that prohibits the support of operational scenarios in 2 in a mixed implementation environment (one which involves the use of a client and a server from different implementers). You shouldn't attempt to answer 2 explicitly without considering and answering 1 first. Doing so would mean that you do not understand the breadth of tools that might be available to you as an implementer while evaluating the overall quality of the LCUP specification. Speaking as a co-chair: The WG should achieve consensus on the issue of cookie format first - based on interoperability considerations. One of those considerations can be operating in a replicated environment. By considering that particular issue and being sure that we achieve consensus on a cookie format that doesn't prohibit it, the WG has not achieved a default consensus to explicitly support the operation of LCUP in a replicated environment. It only means that we don't believe we have prohibited it. We can then proceed to discussing the issue of applicability for this particular LCUP specification in a replicated environment based on the technical issues and scenarios relevant to it. There is nothing to prevent the WG from changing a previously achieved consensus related to cookie format if discussions related to replicated environment applicability of LCUP lead the WG to draw that conclusion. I haven't seen anything posted to the list so far that is substantive enough to outweigh the impedance of an opaque cookie on cross-implementation client-to-server interoperability. In fact, I've seen what I perceive to be some persuasive arguments in favor of exposing the cookie format rather than making it opaque. We need to hear from some folks in addition to the document authors, the co-chairs, Rick, and yourself. Specifically, we need to see technical and scenario-based arguments for and against exposed and opaque LCUP cookies. Chris Apple Program Manager - Directory Services United Messaging Inc. (V) 610-425-2860 -----Original Message----- From: Kurt D. Zeilenga [mailto:Kurt@OpenLDAP.org] Sent: Tuesday, June 12, 2001 2:29 PM To: john.strassner@intelliden.com Cc: Christopher Apple; 'Richard Huber'; ietf-ldup@imc.org; richm@iplanet.com Subject: RE: Comments on LCUP draft - opaque cookie From my perspective, the format of the cookie isn't the real issue. The real issue is whether LCUP will support replicated environments. In particular, whether a client which updated from replica A can then incrementally update from replica B where the replicate model has loose data consistency rules (that is, in replicated environments where A and B may be out of sync, such as in LDUP-based replication). Supporting replicated environments will go far beyond specifying the structure of the cookie and require significant more work. It's my opinion that LCUP support of replicated environments should be viewed as beyond the scope of this work and left to future extension. Kurt ------=_NextPart_001_000D_01C0F352.F9F25510 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 ADR;HOME:;;214 New Street, Apt 4-N;Philadelphia;PA;19106;United States = of America LABEL;HOME;ENCODING=3DQUOTED-PRINTABLE:214 New Street, Apt = 4-N=3D0D=3D0APhiladelphia, PA 19106=3D0D=3D0AUnited States of Am=3D erica EMAIL;PREF;INTERNET:christopher.apple@unitedmessaging.com REV:20010413T223539Z END:VCARD ------=_NextPart_001_000D_01C0F352.F9F25510-- ------=_NextPart_000_000C_01C0F352.F9EDC130 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 MQ8XDTAxMDYxMjE5MTg0N1owIwYJKoZIhvcNAQkEMRYEFATTrfHQn4jPvIlhbimXOuUUQbTrMFgG CSqGSIb3DQEJDzFLMEkwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwICAgCAMAcGBSsOAwIHMA0GCCqG SIb3DQMCAgEoMAcGBSsOAwIaMAoGCCqGSIb3DQIFMIGrBgkrBgEEAYI3EAQxgZ0wgZowgZIxCzAJ BgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEPMA0G A1UEChMGVGhhd3RlMR0wGwYDVQQLExRDZXJ0aWZpY2F0ZSBTZXJ2aWNlczEoMCYGA1UEAxMfUGVy c29uYWwgRnJlZW1haWwgUlNBIDIwMDAuOC4zMAIDBPxeMA0GCSqGSIb3DQEBAQUABIGAhjgUmMXf /BtJGZPJ13NXcfOVwF9ghFVuDkM7KfYoUI+FuusZjbl3ynCjBlMPVp33cMDaUBxh2xXLvCiHUA/+ zuTIeO+KZtPvw/VfSspXExXP+DpQ/y8iXxyzS0azklbZRtzd+zcHtbvhPlFCbxPGnee5fajBcdOd ufpNQOarO4UAAAAAAAA= ------=_NextPart_000_000C_01C0F352.F9EDC130-- From owner-ietf-ldup@mail.imc.org Tue Jun 12 15:48:10 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA23368 for ; Tue, 12 Jun 2001 15:48:08 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.3/8.11.3) id f5CJNWB13128 for ietf-ldup-bks; Tue, 12 Jun 2001 12:23:32 -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 f5CJNUJ13124 for ; Tue, 12 Jun 2001 12:23:31 -0700 (PDT) Received: from ex01.ummail.com [216.33.108.253:25] by hawk.ummail.com with SMTP id Q0612-1523-1cd400; Tue, 12 Jun 2001 19:23:15 GMT Received: by ex01.ummail.com with Internet Mail Service (5.5.2650.21) id ; Tue, 12 Jun 2001 15:21:44 -0400 Message-ID: From: Christopher Apple To: "'rvh@qsun.mt.att.com'" Cc: ietf-ldup@imc.org Subject: RE: New Requirements draft Date: Tue, 12 Jun 2001 15:21:43 -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_0012_01C0F353.7136DD30" 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_0012_01C0F353.7136DD30 Content-Type: multipart/mixed; boundary="----=_NextPart_001_0013_01C0F353.7136DD30" ------=_NextPart_001_0013_01C0F353.7136DD30 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Thanks for getting this out so quickly. Once its been announced by the I-D Editor, John and I will issue another WG Last Call within a couple of days. Chris Apple Program Manager - Directory Services United Messaging Inc. =20 (V) 610-425-2860 -----Original Message----- From: rvh@qsun.mt.att.com [mailto:rvh@qsun.mt.att.com] Sent: Tuesday, June 12, 2001 2:17 PM To: internet-drafts@ietf.org Cc: ietf-ldup@imc.org Subject: New Requirements draft Internet Drafts Editor - Please publish the draft below as draft-ietf-ldup-replica-req-09.txt LDUPers - Draft -09 of the requirements is attached below. Changes from draft -08 include: - Added definition of Anonymous Replication as previously posted to the list. - Changed G9 to make the Replication Considerations section a SHOULD instead of a MUST. - Added "area(s) of replication" to the list of replication parameters in M7. - Moved the old P3 to the M section and made it M12 since it addressed issues beyond the protocol. All the P requirements now clearly deal with the protocol. - Renumbered the P requirements since P3 was moved. - Added a note to P6 (formerly P7): "In a multi-master environment this may lead to an unresolvable conflict. MM5 and MM6 discuss how to handle this situation." - Added the new S requirements from Chris and John's email, reworded to make it clear that we are talking about data consistency and data integrity as defined in RFC2828. Also added Mark Smith's comment ("turn off" -> "disable"). As a result the S requirements were renumbered. - Rephrased Appendix B.6 in terms of the RFC2828 definitions. "Privacy" is no longer used. Also added a brief justification for Anonymous Replication. - Various changes to authors' affiliations and contact information. Since these changes were made as a result of the previous last call, the authors would like to start a new last call immediately. Rick Huber --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- Internet-Draft Ellen J. Stokes LDAP Duplication/Replication/Update Tivoli Systems Protocols WG Russel F. Weiser Intended Category: Informational Digital Signature Trust Expires: December 2001 Ryan D. Moats Richard V. Huber AT&T Laboratories June 2001 LDAPv3 Replication Requirements draft-ietf-ldup-replica-req-09.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 December 2001 [Page 1]=0C Internet-Draft LDAPv3 Replication Requirements June 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 December 2001 [Page 2]=0C Internet-Draft LDAPv3 Replication Requirements June 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...................................................11 4.7 Administration and Management..................................12 4.8 Security.......................................................13 5 Security Considerations...........................................13 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......................................16 A.5.Supplier Initiated Replication.................................17 A.6.Consumer Initiated Replication.................................17 A.7.Prioritized attribute replication..............................17 A.8.Bandwidth issues...............................................17 A.9.Interoperable Administration and Management....................18 A.10.Enterprise Directory Replication Mesh.........................18 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............................................19 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 December 2001 [Page 3]=0C Internet-Draft LDAPv3 Replication Requirements June 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 December 2001 [Page 4]=0C Internet-Draft LDAPv3 Replication Requirements June 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 December 2001 [Page 5]=0C Internet-Draft LDAPv3 Replication Requirements June 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 December 2001 [Page 6]=0C Internet-Draft LDAPv3 Replication Requirements June 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 December 2001 [Page 7]=0C Internet-Draft LDAPv3 Replication Requirements June 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 LDUP replication may be limited for implementations that add semantics beyond those specified by the LDAP core documents (RFC 2251-2256, 2829, 2830). 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 - 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) Stokes, et al Expires December 2001 [Page 8]=0C Internet-Draft LDAPv3 Replication Requirements June 2001 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 all copies of the replicated information to be complete copies of the replicated object. The model MUST support Partial Replicas. 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 Stokes, et al Expires December 2001 [Page 9]=0C Internet-Draft LDAPv3 Replication Requirements June 2001 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. 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. Stokes, et al Expires December 2001 [Page 10]=0C Internet-Draft LDAPv3 Replication Requirements June 2001 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. 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. Stokes, et al Expires December 2001 [Page 11]=0C Internet-Draft LDAPv3 Replication Requirements June 2001 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. 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. Stokes, et al Expires December 2001 [Page 12]=0C Internet-Draft LDAPv3 Replication Requirements June 2001 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. 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, 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]. Stokes, et al Expires December 2001 [Page 13]=0C Internet-Draft LDAPv3 Replication Requirements June 2001 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. [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. [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. [RFC2820] E. Stokes, D. Byrne, B. Blakley, P. Behera, "Access Control Requirements for LDAP", RFC 2820, May 2000. [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. Stokes, et al Expires December 2001 [Page 14]=0C Internet-Draft LDAPv3 Replication Requirements June 2001 [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 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. Stokes, et al Expires December 2001 [Page 15]=0C Internet-Draft LDAPv3 Replication Requirements June 2001 - 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. 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. Stokes, et al Expires December 2001 [Page 16]=0C Internet-Draft LDAPv3 Replication Requirements June 2001 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 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 Stokes, et al Expires December 2001 [Page 17]=0C Internet-Draft LDAPv3 Replication Requirements June 2001 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. 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: Stokes, et al Expires December 2001 [Page 18]=0C Internet-Draft LDAPv3 Replication Requirements June 2001 - 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 - 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, Stokes, et al Expires December 2001 [Page 19]=0C Internet-Draft LDAPv3 Replication Requirements June 2001 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 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 Stokes, et al Expires December 2001 [Page 20]=0C Internet-Draft LDAPv3 Replication Requirements June 2001 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. 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. Stokes, et al Expires December 2001 [Page 21]=0C Internet-Draft LDAPv3 Replication Requirements June 2001 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 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. Stokes, et al Expires December 2001 [Page 22]=0C Internet-Draft LDAPv3 Replication Requirements June 2001 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. 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 Stokes, et al Expires December 2001 [Page 23]=0C Internet-Draft LDAPv3 Replication Requirements June 2001 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 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 Stokes, et al Expires December 2001 [Page 24]=0C Internet-Draft LDAPv3 Replication Requirements June 2001 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. 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 Stokes, et al Expires December 2001 [Page 25]=0C Internet-Draft LDAPv3 Replication Requirements June 2001 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 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. Stokes, et al Expires December 2001 [Page 26]=0C Internet-Draft LDAPv3 Replication Requirements June 2001 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. - 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 Stokes, et al Expires December 2001 [Page 27]=0C Internet-Draft LDAPv3 Replication Requirements June 2001 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 246 4323 Fax: +1 801 246 4361 Ellen J. Stokes 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 15621 Drexel Circle Omaha, NE 68135 USA E-Mail: j4yh4wk@netscape.net Stokes, et al Expires December 2001 [Page 28]=0C Internet-Draft LDAPv3 Replication Requirements June 2001 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. 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 December 2001 [Page 29]=0C ------=_NextPart_001_0013_01C0F353.7136DD30 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 ADR;HOME:;;214 New Street, Apt 4-N;Philadelphia;PA;19106;United States = of America LABEL;HOME;ENCODING=3DQUOTED-PRINTABLE:214 New Street, Apt = 4-N=3D0D=3D0APhiladelphia, PA 19106=3D0D=3D0AUnited States of Am=3D erica EMAIL;PREF;INTERNET:christopher.apple@unitedmessaging.com REV:20010413T223539Z END:VCARD ------=_NextPart_001_0013_01C0F353.7136DD30-- ------=_NextPart_000_0012_01C0F353.7136DD30 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 MQ8XDTAxMDYxMjE5MjIwNFowIwYJKoZIhvcNAQkEMRYEFKGPacNccI25pWMWxwX8OD73xNwRMFgG CSqGSIb3DQEJDzFLMEkwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwICAgCAMAcGBSsOAwIHMA0GCCqG SIb3DQMCAgEoMAcGBSsOAwIaMAoGCCqGSIb3DQIFMIGrBgkrBgEEAYI3EAQxgZ0wgZowgZIxCzAJ BgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEPMA0G A1UEChMGVGhhd3RlMR0wGwYDVQQLExRDZXJ0aWZpY2F0ZSBTZXJ2aWNlczEoMCYGA1UEAxMfUGVy c29uYWwgRnJlZW1haWwgUlNBIDIwMDAuOC4zMAIDBPxeMA0GCSqGSIb3DQEBAQUABIGAI4le4Pjn zPFBr1+cQVPAX4Kf92M1xDm6CoiyFsFQQJ9pHoiDXYiW/ZEl6+tb5NrBFwJmIO5IPO6qVzPqteR3 ktVr4QjMyevm1mCEZRtKk04w5wNftWkgRlf6OfVwRBkQNE/EKvpfU8dlrC7T2uXRxuwsKSSm7PIm H0OvboAwyvUAAAAAAAA= ------=_NextPart_000_0012_01C0F353.7136DD30-- From owner-ietf-ldup@mail.imc.org Tue Jun 12 16:18:29 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA23868 for ; Tue, 12 Jun 2001 16:18:28 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.3/8.11.3) id f5CJu3N14182 for ietf-ldup-bks; Tue, 12 Jun 2001 12:56:03 -0700 (PDT) Received: from scaup.mail.pas.earthlink.net (scaup.mail.pas.earthlink.net [207.217.121.49]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f5CJu2J14178 for ; Tue, 12 Jun 2001 12:56:02 -0700 (PDT) Received: from FARILJCS (pool0752.cvx20-bradley.dialup.earthlink.net [209.179.252.242]) by scaup.mail.pas.earthlink.net (EL-8_9_3_3/8.9.3) with SMTP id MAA01998; Tue, 12 Jun 2001 12:55:26 -0700 (PDT) Reply-To: From: "John Strassner" To: "Kurt D. Zeilenga" Cc: "Christopher Apple" , "'Richard Huber'" , , Subject: Separate LCUP cookie vs replication - was RE: Comments on LCUP draft - opaque cookie Date: Tue, 12 Jun 2001 12:55:17 -0700 MIME-Version: 1.0 Message-ID: X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_0022_01C0F33E.ED377350" Importance: Normal In-Reply-To: <5.1.0.14.0.20010612105554.00adec00@127.0.0.1> 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_01C0F33E.ED377350 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Kurt, 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 regards, John -----Original Message----- From: Kurt D. Zeilenga [mailto:Kurt@OpenLDAP.org] Sent: Tuesday, June 12, 2001 11:29 AM To: john.strassner@intelliden.com Cc: Christopher Apple; 'Richard Huber'; ietf-ldup@imc.org; richm@iplanet.com Subject: RE: Comments on LCUP draft - opaque cookie From my perspective, the format of the cookie isn't the real issue. The real issue is whether LCUP will support replicated environments. In particular, whether a client which updated from replica A can then incrementally update from replica B where the replicate model has loose data consistency rules (that is, in replicated environments where A and B may be out of sync, such as in LDUP-based replication). Supporting replicated environments will go far beyond specifying the structure of the cookie and require significant more work. It's my opinion that LCUP support of replicated environments should be viewed as beyond the scope of this work and left to future extension. Kurt ------=_NextPart_000_0022_01C0F33E.ED377350 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 AQkFMQ8XDTAxMDYxMjE5NTUxNVowIwYJKoZIhvcNAQkEMRYEFNCMT7JsyD7hc2dpEm7z3Ag+1R/G MFgGCSqGSIb3DQEJDzFLMEkwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwICAgCAMAcGBSsOAwIHMA0G CCqGSIb3DQMCAgEoMAcGBSsOAwIaMAoGCCqGSIb3DQIFMIGrBgkrBgEEAYI3EAQxgZ0wgZowgZIx CzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEP MA0GA1UEChMGVGhhd3RlMR0wGwYDVQQLExRDZXJ0aWZpY2F0ZSBTZXJ2aWNlczEoMCYGA1UEAxMf UGVyc29uYWwgRnJlZW1haWwgUlNBIDIwMDAuOC4zMAIDBKRvMA0GCSqGSIb3DQEBAQUABIGAdkMj g+4aVg1X6myaY7ab9XWCImf8HLpek/EePJTZ3OK6PcnAY5mUn5PptRHgiUBYSs7srQZkLJlgiUxS 8akwIfzPpPvlc4YEdPRtEFLxEoUs4Ky4s3YOgmufxcwkJrVQJcIN16qVqUBLMb7GOU2Ex7nPmg2y kL3hmZXVqUsEYP8AAAAAAAA= ------=_NextPart_000_0022_01C0F33E.ED377350-- From owner-ietf-ldup@mail.imc.org Tue Jun 12 16:20:28 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA23926 for ; Tue, 12 Jun 2001 16:20:28 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.3/8.11.3) id f5CK0gL14328 for ietf-ldup-bks; Tue, 12 Jun 2001 13:00:42 -0700 (PDT) Received: from scaup.mail.pas.earthlink.net (scaup.mail.pas.earthlink.net [207.217.121.49]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f5CK0fJ14324 for ; Tue, 12 Jun 2001 13:00:41 -0700 (PDT) Received: from FARILJCS (pool0752.cvx20-bradley.dialup.earthlink.net [209.179.252.242]) by scaup.mail.pas.earthlink.net (EL-8_9_3_3/8.9.3) with SMTP id NAA26134; Tue, 12 Jun 2001 13:00:31 -0700 (PDT) Reply-To: From: "John Strassner" To: "Kurt D. Zeilenga" Cc: "Christopher Apple" , "'Richard Huber'" , , Subject: Shouls LCUP support replication? Date: Tue, 12 Jun 2001 13:00:23 -0700 MIME-Version: 1.0 Message-ID: X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_0028_01C0F33F.A3D57B20" Importance: Normal In-Reply-To: <5.1.0.14.0.20010612105554.00adec00@127.0.0.1> 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_0028_01C0F33F.A3D57B20 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Kurt, Now that we've split these into two topics, please tell me why you think that LCUP supporting replicated environments is out of scope. If it is, then at the minimum we shouldn't have it in LDUP, which we all agreed many moons ago was the most appropriate wg for this work to be in. regards, John -----Original Message----- From: Kurt D. Zeilenga [mailto:Kurt@OpenLDAP.org] Sent: Tuesday, June 12, 2001 11:29 AM To: john.strassner@intelliden.com Cc: Christopher Apple; 'Richard Huber'; ietf-ldup@imc.org; richm@iplanet.com Subject: RE: Comments on LCUP draft - opaque cookie From my perspective, the format of the cookie isn't the real issue. The real issue is whether LCUP will support replicated environments. In particular, whether a client which updated from replica A can then incrementally update from replica B where the replicate model has loose data consistency rules (that is, in replicated environments where A and B may be out of sync, such as in LDUP-based replication). Supporting replicated environments will go far beyond specifying the structure of the cookie and require significant more work. It's my opinion that LCUP support of replicated environments should be viewed as beyond the scope of this work and left to future extension. Kurt ------=_NextPart_000_0028_01C0F33F.A3D57B20 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 AQkFMQ8XDTAxMDYxMjIwMDAyMlowIwYJKoZIhvcNAQkEMRYEFIK/DRm+Pb3H6AjFAleO9QfnVymw MFgGCSqGSIb3DQEJDzFLMEkwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwICAgCAMAcGBSsOAwIHMA0G CCqGSIb3DQMCAgEoMAcGBSsOAwIaMAoGCCqGSIb3DQIFMIGrBgkrBgEEAYI3EAQxgZ0wgZowgZIx CzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEP MA0GA1UEChMGVGhhd3RlMR0wGwYDVQQLExRDZXJ0aWZpY2F0ZSBTZXJ2aWNlczEoMCYGA1UEAxMf UGVyc29uYWwgRnJlZW1haWwgUlNBIDIwMDAuOC4zMAIDBKRvMA0GCSqGSIb3DQEBAQUABIGAR63n TPjqTOxwOiGicP8RSrFho2wVBbspGiHN6PlML7IE/L1UOJtdn5bV+daZqC/Mega1uEiw2LSdzzS5 RS253XFZgY3Xg1Vlqkk81guY7D2zwOuua4Qo2K+aeGOsGpI1NU79mBSWOgUQId1TvAJ2+LWuRYl6 /D5FMQHFatoaTVIAAAAAAAA= ------=_NextPart_000_0028_01C0F33F.A3D57B20-- From owner-ietf-ldup@mail.imc.org Tue Jun 12 16:23:06 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA23958 for ; Tue, 12 Jun 2001 16:23:05 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.3/8.11.3) id f5CK7Ff14562 for ietf-ldup-bks; Tue, 12 Jun 2001 13:07:15 -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 f5CK79J14558 for ; Tue, 12 Jun 2001 13:07:09 -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 f5CK75Y25636 for ; Tue, 12 Jun 2001 13:07:05 -0700 (PDT) Received: from iplanet.com ([205.217.229.48]) by dredd.mcom.com (Netscape Messaging Server 4.15) with ESMTP id GEU2JU00.6PU; Tue, 12 Jun 2001 13:07:06 -0700 Message-ID: <3B267668.A7F8225E@iplanet.com> Date: Tue, 12 Jun 2001 14:07:04 -0600 From: Richard Megginson Organization: iPlanet Directory Server X-Mailer: Mozilla 4.77 [en] (X11; U; SunOS 5.6 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: ietf-ldup@imc.org, ietf-lcup@netscape.com CC: mcs@netscape.com, jeffparh@MICROSOFT.com, olga@etimecapital.com Subject: Response to the LCUP cookie format issue 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 One of the main goals of LCUP is that it will be lightweight and easy to implement, both from a client and a server perspective. Having an opaque cookie makes the client easier to implement, and makes the server much easier to implement. Another thing that worries me about defining the cookie format is that we may end up dragging a lot of LDUP into this, which may mean a dependence on an LDUP implementation before we can implement LCUP, and that is definitely contrary to the goals of LCUP. However, we (the authors of LCUP) do see the need to have a known cookie format to foster interoperability at some point in the future. To acheive this goal, Mark Smith has proposed the following: Specify that the cookie format is - where the scheme is an OID that can be implementation specific for now but an LDUP scheme will be defined also. In other words, LCUP provides the hook to allow cookie formats to be common but does not mandate they be common. Note that use of an opaque cookie format or use of a - extensible format will NOT prevent an LCUP client from vendor A from interoperating with an LCUP server from vendor B. From owner-ietf-ldup@mail.imc.org Tue Jun 12 16:36:24 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA24229 for ; Tue, 12 Jun 2001 16:36:23 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.3/8.11.3) id f5CKJDM14900 for ietf-ldup-bks; Tue, 12 Jun 2001 13:19:13 -0700 (PDT) Received: from scaup.mail.pas.earthlink.net (scaup.mail.pas.earthlink.net [207.217.121.49]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f5CKJCJ14895 for ; Tue, 12 Jun 2001 13:19:12 -0700 (PDT) Received: from FARILJCS (pool0752.cvx20-bradley.dialup.earthlink.net [209.179.252.242]) by scaup.mail.pas.earthlink.net (EL-8_9_3_3/8.9.3) with SMTP id NAA26359; Tue, 12 Jun 2001 13:19:06 -0700 (PDT) Reply-To: From: "John Strassner" To: "Christopher Apple" , "'Kurt D. Zeilenga'" , "'Richard Huber'" Cc: , Subject: RE: Comments on LCUP draft - opaque cookie Date: Tue, 12 Jun 2001 13:18:57 -0700 MIME-Version: 1.0 Message-ID: X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_0049_01C0F342.3ACD5460" Importance: Normal In-Reply-To: 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_0049_01C0F342.3ACD5460 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit With co-chair hat on, I fully agree with Chris. That's why I sent the two messages that I did before reading this one. -----Original Message----- From: Christopher Apple [mailto:christopher.apple@UnitedMessaging.net] Sent: Tuesday, June 12, 2001 12:18 PM To: 'Kurt D. Zeilenga'; john.strassner@intelliden.com Cc: Christopher Apple; 'Richard Huber'; ietf-ldup@imc.org; richm@iplanet.com Subject: RE: Comments on LCUP draft - opaque cookie There are really two questions that must be answered. Both of them represent very real issues for the WG to resolve. The answers that the WG achieves consensus on are at the crux of the degree to which LCUP clients and servers from different vendors will be able to interoperate. 1) Should LCUP's cookie format be exposed or opaque? 2) Should LCUP explicitly support replicated environments based on LDAPv3-based replication (LDUP)? You could answer 1 without necessarily considering 2 in detail. However, I don't believe that would be a good idea. Not considering 2 as input for answering 1 means that you could end up with a cookie format consensus that prohibits the support of operational scenarios in 2 in a mixed implementation environment (one which involves the use of a client and a server from different implementers). You shouldn't attempt to answer 2 explicitly without considering and answering 1 first. Doing so would mean that you do not understand the breadth of tools that might be available to you as an implementer while evaluating the overall quality of the LCUP specification. Speaking as a co-chair: The WG should achieve consensus on the issue of cookie format first - based on interoperability considerations. One of those considerations can be operating in a replicated environment. By considering that particular issue and being sure that we achieve consensus on a cookie format that doesn't prohibit it, the WG has not achieved a default consensus to explicitly support the operation of LCUP in a replicated environment. It only means that we don't believe we have prohibited it. We can then proceed to discussing the issue of applicability for this particular LCUP specification in a replicated environment based on the technical issues and scenarios relevant to it. There is nothing to prevent the WG from changing a previously achieved consensus related to cookie format if discussions related to replicated environment applicability of LCUP lead the WG to draw that conclusion. I haven't seen anything posted to the list so far that is substantive enough to outweigh the impedance of an opaque cookie on cross-implementation client-to-server interoperability. In fact, I've seen what I perceive to be some persuasive arguments in favor of exposing the cookie format rather than making it opaque. We need to hear from some folks in addition to the document authors, the co-chairs, Rick, and yourself. Specifically, we need to see technical and scenario-based arguments for and against exposed and opaque LCUP cookies. Chris Apple Program Manager - Directory Services United Messaging Inc. (V) 610-425-2860 -----Original Message----- From: Kurt D. Zeilenga [mailto:Kurt@OpenLDAP.org] Sent: Tuesday, June 12, 2001 2:29 PM To: john.strassner@intelliden.com Cc: Christopher Apple; 'Richard Huber'; ietf-ldup@imc.org; richm@iplanet.com Subject: RE: Comments on LCUP draft - opaque cookie From my perspective, the format of the cookie isn't the real issue. The real issue is whether LCUP will support replicated environments. In particular, whether a client which updated from replica A can then incrementally update from replica B where the replicate model has loose data consistency rules (that is, in replicated environments where A and B may be out of sync, such as in LDUP-based replication). Supporting replicated environments will go far beyond specifying the structure of the cookie and require significant more work. It's my opinion that LCUP support of replicated environments should be viewed as beyond the scope of this work and left to future extension. Kurt ------=_NextPart_000_0049_01C0F342.3ACD5460 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 AQkFMQ8XDTAxMDYxMjIwMTg1NFowIwYJKoZIhvcNAQkEMRYEFNyaq4uTY93G5c7qrqKsWNJc3WcL MFgGCSqGSIb3DQEJDzFLMEkwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwICAgCAMAcGBSsOAwIHMA0G CCqGSIb3DQMCAgEoMAcGBSsOAwIaMAoGCCqGSIb3DQIFMIGrBgkrBgEEAYI3EAQxgZ0wgZowgZIx CzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEP MA0GA1UEChMGVGhhd3RlMR0wGwYDVQQLExRDZXJ0aWZpY2F0ZSBTZXJ2aWNlczEoMCYGA1UEAxMf UGVyc29uYWwgRnJlZW1haWwgUlNBIDIwMDAuOC4zMAIDBKRvMA0GCSqGSIb3DQEBAQUABIGAUJ2t UQYH6G7uvkMLJJxNAc5BC/jxYghzrEm7HXZ5/q0ecnlj5teSZRj4cz833x7PMzaXlll8uhDb+HN6 dBUs0OK847S2bz+qHjlCKyasONikJk3VxbtB4N402TO2f+xrLrq29fDJKQUz8xeBWU9nr/jMv9Wn JRxRFjWgLpoTazcAAAAAAAA= ------=_NextPart_000_0049_01C0F342.3ACD5460-- From owner-ietf-ldup@mail.imc.org Wed Jun 13 07:38:25 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA18999 for ; Wed, 13 Jun 2001 07:38:25 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.3/8.11.3) id f5DBB0p10790 for ietf-ldup-bks; Wed, 13 Jun 2001 04:11:00 -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 f5DBAxJ10783 for ; Wed, 13 Jun 2001 04:10:59 -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 HAA18477; Wed, 13 Jun 2001 07:10:27 -0400 (EDT) Message-Id: <200106131110.HAA18477@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-09.txt Date: Wed, 13 Jun 2001 07:10:27 -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-09.txt Pages : 29 Date : 12-Jun-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-09.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-09.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-09.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: <20010612142745.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ldup-replica-req-09.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ldup-replica-req-09.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20010612142745.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ietf-ldup@mail.imc.org Wed Jun 13 11:38:32 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA25368 for ; Wed, 13 Jun 2001 11:38:31 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.3/8.11.3) id f5DFJX022250 for ietf-ldup-bks; Wed, 13 Jun 2001 08:19:33 -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 f5DFJWJ22245 for ; Wed, 13 Jun 2001 08:19:32 -0700 (PDT) Received: from ex01.ummail.com [216.33.108.253:25] by hawk.ummail.com with SMTP id Q0613-1119-7dd900; Wed, 13 Jun 2001 15:19:12 GMT Received: by ex01.ummail.com with Internet Mail Service (5.5.2650.21) id ; Wed, 13 Jun 2001 11:17:39 -0400 Message-ID: From: Christopher Apple To: "'Richard Megginson'" , ietf-ldup@imc.org, ietf-lcup@netscape.com Cc: mcs@netscape.com, jeffparh@MICROSOFT.com, olga@etimecapital.com Subject: RE: Response to the LCUP cookie format issue Date: Wed, 13 Jun 2001 11:17:38 -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_0006_01C0F3FA.82C1DAD0" 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_0006_01C0F3FA.82C1DAD0 Content-Type: multipart/mixed; boundary="----=_NextPart_001_0007_01C0F3FA.82C1DAD0" ------=_NextPart_001_0007_01C0F3FA.82C1DAD0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit -----Original Message----- From: Richard Megginson [mailto:richm@iplanet.com] Sent: Tuesday, June 12, 2001 4:07 PM To: ietf-ldup@imc.org; ietf-lcup@netscape.com Cc: mcs@netscape.com; jeffparh@MICROSOFT.com; olga@etimecapital.com Subject: Response to the LCUP cookie format issue One of the main goals of LCUP is that it will be lightweight and easy to implement, both from a client and a server perspective. Having an opaque cookie makes the client easier to implement, and makes the server much easier to implement. Another thing that worries me about defining the cookie format is that we may end up dragging a lot of LDUP into this, which may mean a dependence on an LDUP implementation before we can implement LCUP, and that is definitely contrary to the goals of LCUP. However, we (the authors of LCUP) do see the need to have a known cookie format to foster interoperability at some point in the future. To acheive this goal, Mark Smith has proposed the following: Specify that the cookie format is - where the scheme is an OID that can be implementation specific for now but an LDUP scheme will be defined also. In other words, LCUP provides the hook to allow cookie formats to be common but does not mandate they be common. - seems like a good fit to me. John Strassner pointed out to me yesterday on the phone that this is very similar to something that the POLICY WG did. OIDs are registered with IANA and corresponding syntaxes/structures are published. One thing that still concerns me is when you mention "foster interoperability at some point in the future." I do understand your concerns about keeping LCUP in the pipeline until LDUP protocol work is sufficiently far along. Given that scenario, how's this for a way to proceed: 1) go with - as a proposed cookie structure in the next revision of the LCUP document 2) add text proposing how the OIDs should be registered with IANA and how the syntax/structures should be published (it would be fine if these topics were dealt with in a separate document at some point, but I'd like to see a place holder for this in the next revision of the LCUP document) 3) add text indicating that the will have a syntax/format that may be opaque or exposed (or some other appropriate choices) 4) add text indicating that it is expected that there will be one or more standards-track - combinations and that those will be defined in other documents 5) add text indicating how implementations should respond to each other in the event that they receive or attempt to set a cookie with a , , or combination that they do not understand, is somehow invalid, or is understood but unsupported 5) John and I will add an agenda item for the London WG meeting to gauge interest in adding one or more such standards-track - specifications to the WG charter based on a proposed charter revision derived from discussion mentioned in 6 6) we should discuss what sorts of - combinations would be useful and feasible as a minimum and mandatory to implement set on the LDUP list (I have trouble believing that there are none that would be useful based on the sorts of operational scenarios I've seen so far on the list for LCUP) Note that use of an opaque cookie format or use of a - extensible format will NOT prevent an LCUP client from vendor A from interoperating with an LCUP server from vendor B. Sure. But that's not sufficient to provide some guarantee of minimum interoperability between those same types of entities. As a co-chair, that's one of the things that I'm supposed to be sure happens - or at least be able to make very clear arguments when requesting IESG review of the document about why the WG doesn't believe lack of such a guarantee is a problem. Chris Apple Program Manager - Directory Services United Messaging Inc. (V) 610-425-2860 ------=_NextPart_001_0007_01C0F3FA.82C1DAD0 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 ADR;HOME:;;214 New Street, Apt 4-N;Philadelphia;PA;19106;United States = of America LABEL;HOME;ENCODING=3DQUOTED-PRINTABLE:214 New Street, Apt = 4-N=3D0D=3D0APhiladelphia, PA 19106=3D0D=3D0AUnited States of Am=3D erica EMAIL;PREF;INTERNET:christopher.apple@unitedmessaging.com REV:20010413T223539Z END:VCARD ------=_NextPart_001_0007_01C0F3FA.82C1DAD0-- ------=_NextPart_000_0006_01C0F3FA.82C1DAD0 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 MQ8XDTAxMDYxMzE1MTgwMlowIwYJKoZIhvcNAQkEMRYEFCchTbiEIi/zQQBAY6CC+Cd5h/X4MFgG CSqGSIb3DQEJDzFLMEkwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwICAgCAMAcGBSsOAwIHMA0GCCqG SIb3DQMCAgEoMAcGBSsOAwIaMAoGCCqGSIb3DQIFMIGrBgkrBgEEAYI3EAQxgZ0wgZowgZIxCzAJ BgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEPMA0G A1UEChMGVGhhd3RlMR0wGwYDVQQLExRDZXJ0aWZpY2F0ZSBTZXJ2aWNlczEoMCYGA1UEAxMfUGVy c29uYWwgRnJlZW1haWwgUlNBIDIwMDAuOC4zMAIDBPxeMA0GCSqGSIb3DQEBAQUABIGAhUe+Vl2F wL553DVMFSnRk2miVS/rSyVJzMXg69IhpAZ+wlYMRrW+cG94CS+BQHji5PTMaF9Fne+L7A62KmTu pFew8CtirFQ5ky9er/JF+wEANaN6/WPQHl7Y9HUNhCwBxz92friuJx2wPNvIF2GRaf5T0dndsHfg v6N0EeWENNAAAAAAAAA= ------=_NextPart_000_0006_01C0F3FA.82C1DAD0-- From owner-ietf-ldup@mail.imc.org Fri Jun 15 12:18:05 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA13410 for ; Fri, 15 Jun 2001 12:18:04 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.3/8.11.3) id f5FFqYc27849 for ietf-ldup-bks; Fri, 15 Jun 2001 08:52:34 -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 f5FFqXJ27845 for ; Fri, 15 Jun 2001 08:52:33 -0700 (PDT) Received: from ex01.ummail.com [216.33.108.253:25] by hawk.ummail.com with SMTP id Q0615-1152-7b1000; Fri, 15 Jun 2001 15:52:10 GMT Received: by ex01.ummail.com with Internet Mail Service (5.5.2650.21) id ; Fri, 15 Jun 2001 11:50:48 -0400 Message-ID: From: Christopher Apple To: "'ietf-ldup@imc.org'" Subject: WG Last Call on Requirements I-D Date: Fri, 15 Jun 2001 11:50:39 -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_0009_01C0F591.87E37DF0" 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_0009_01C0F591.87E37DF0 Content-Type: multipart/mixed; boundary="----=_NextPart_001_000A_01C0F591.87E37DF0" ------=_NextPart_001_000A_01C0F591.87E37DF0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit The purpose of this message is to initiate the LDAPEXT working group last call on the LDAPv3 Replication Requirements I-D document. WHAT DOCUMENT? The document in last call is: http://www.ietf.org/internet-drafts/draft-ietf-ldup-replica-req-09.txt WHAT IS A LAST CALL FOR? The purpose of the working group last call is to ensure that the working group has reached consensus on the document, believes that all the known outstanding issues have been addressed, and is ready to put the document forward for proposed standard status. During the last call, any comments on the documents are collected and discussed on the mailing list. HOW LONG DOES IT LAST? The last call starts today and will last approximately two weeks. It will end on Friday, June 29, 2001. WHAT'S THE NEXT STEP? After the last call completes, there are three possible outcomes: 1) No changes are required and we request our ADs to put forward the documents to the IESG for informational status. 2) Minor changes agreed to on the list are required, and the documents are revised. We then ask our ADs to put forward the revised documents to the IESG for informational status. 3) Major issues are raised and no consensus is reached on the list. In this case, we discuss things until consensus is reached, at which time another working group last call will be issued. Assuming we achieve outcome 1) or 2), and that the ADs agree with our assessment, the next stop for the documents is with the IESG. The IESG reads them and may approve the documents (with or without changes), or send the documents back to the working group to have major issues addressed. If the first outcome happens, the documents are put forward for a two-week last call to the entire IETF, and after successful completion the documents are published as RFCs with proposed standard status. If the second outcome happens, we go back and address the issues, putting the documents forward again when we believe they're ready. WHAT SHOULD YOU DO? You should read the documents, making sure that 1) there are no problems or deficiencies or outstanding issues that need to be resolved; and 2) that there are no typos, formatting problems, grammatical errors, etc. Any substantive problems you find, you should send to the list. Any minor problems (typos, etc.) you may send to the list or just to the authors. If, for some reason, you have comments you don't want to send to the entire list, you may send them to me and/or LDUP WG co-chair John Strassner. Silence means consent. Read, enjoy, and send your comments in! regards, Chris Apple and John Strassner Chris Apple Program Manager - Directory Services United Messaging Inc. (V) 610-425-2860 ------=_NextPart_001_000A_01C0F591.87E37DF0 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 ADR;HOME:;;214 New Street, Apt 4-N;Philadelphia;PA;19106;United States = of America LABEL;HOME;ENCODING=3DQUOTED-PRINTABLE:214 New Street, Apt = 4-N=3D0D=3D0APhiladelphia, PA 19106=3D0D=3D0AUnited States of Am=3D erica EMAIL;PREF;INTERNET:christopher.apple@unitedmessaging.com REV:20010413T223539Z END:VCARD ------=_NextPart_001_000A_01C0F591.87E37DF0-- ------=_NextPart_000_0009_01C0F591.87E37DF0 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 MQ8XDTAxMDYxNTE1NTEzNlowIwYJKoZIhvcNAQkEMRYEFDiBT/ZQSEkc19dMLJN8yOdljGwGMFgG CSqGSIb3DQEJDzFLMEkwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwICAgCAMAcGBSsOAwIHMA0GCCqG SIb3DQMCAgEoMAcGBSsOAwIaMAoGCCqGSIb3DQIFMIGrBgkrBgEEAYI3EAQxgZ0wgZowgZIxCzAJ BgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEPMA0G A1UEChMGVGhhd3RlMR0wGwYDVQQLExRDZXJ0aWZpY2F0ZSBTZXJ2aWNlczEoMCYGA1UEAxMfUGVy c29uYWwgRnJlZW1haWwgUlNBIDIwMDAuOC4zMAIDBPxeMA0GCSqGSIb3DQEBAQUABIGASqNg+0uJ gXmMPSwoD+ex2AzMyI0VygRzOIawozC8Z2wkF5bLcgAMLC8ion59gazXPOFU3t2YOIN6B6gbDuHJ hJGZg95pOB9JL3yaqS/Ngx7mRIJJ6MXN71AgKv4dFKmfOVq4l+y0DdZqLAmMmxhfhOb0MzC8DFEM mys52/XCv28AAAAAAAA= ------=_NextPart_000_0009_01C0F591.87E37DF0-- From owner-ietf-ldup@mail.imc.org Fri Jun 15 14:53:41 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA23079 for ; Fri, 15 Jun 2001 14:53:40 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.3/8.11.3) id f5FIVWE01156 for ietf-ldup-bks; Fri, 15 Jun 2001 11:31:32 -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 f5FIVVJ01150 for ; Fri, 15 Jun 2001 11:31:31 -0700 (PDT) Received: from ex01.ummail.com [216.33.108.253:25] by hawk.ummail.com with SMTP id Q0615-1431-6ba900; Fri, 15 Jun 2001 18:31:21 GMT Received: by ex01.ummail.com with Internet Mail Service (5.5.2650.21) id ; Fri, 15 Jun 2001 14:29:59 -0400 Message-ID: From: Christopher Apple To: "'ietf-ldup@imc.org'" Subject: Revised: WG Last Call on Requirements I-D Date: Fri, 15 Jun 2001 14:29:57 -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_0032_01C0F5A7.C8F66B70" 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_0032_01C0F5A7.C8F66B70 Content-Type: multipart/mixed; boundary="----=_NextPart_001_0033_01C0F5A7.C8F978B0" ------=_NextPart_001_0033_01C0F5A7.C8F978B0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Correcting an error pointed out by Mark Wahl. The previous message indicated that this was an LDAPEXT working group last call. That was incorrect. This is an LDUP WG last call. REVISED LAST CALL ANNOUNCEMENT The purpose of this message is to initiate the LDUP working group last call on the LDAPv3 Replication Requirements I-D document. WHAT DOCUMENT? The document in last call is: http://www.ietf.org/internet-drafts/draft-ietf-ldup-replica-req-09.txt WHAT IS A LAST CALL FOR? The purpose of the working group last call is to ensure that the working group has reached consensus on the document, believes that all the known outstanding issues have been addressed, and is ready to put the document forward for proposed standard status. During the last call, any comments on the documents are collected and discussed on the mailing list. HOW LONG DOES IT LAST? The last call starts today and will last approximately two weeks. It will end on Friday, June 29, 2001. WHAT'S THE NEXT STEP? After the last call completes, there are three possible outcomes: 1) No changes are required and we request our ADs to put forward the documents to the IESG for informational status. 2) Minor changes agreed to on the list are required, and the documents are revised. We then ask our ADs to put forward the revised documents to the IESG for informational status. 3) Major issues are raised and no consensus is reached on the list. In this case, we discuss things until consensus is reached, at which time another working group last call will be issued. Assuming we achieve outcome 1) or 2), and that the ADs agree with our assessment, the next stop for the documents is with the IESG. The IESG reads them and may approve the documents (with or without changes), or send the documents back to the working group to have major issues addressed. If the first outcome happens, the documents are put forward for a two-week last call to the entire IETF, and after successful completion the documents are published as RFCs with proposed standard status. If the second outcome happens, we go back and address the issues, putting the documents forward again when we believe they're ready. WHAT SHOULD YOU DO? You should read the documents, making sure that 1) there are no problems or deficiencies or outstanding issues that need to be resolved; and 2) that there are no typos, formatting problems, grammatical errors, etc. Any substantive problems you find, you should send to the list. Any minor problems (typos, etc.) you may send to the list or just to the authors. If, for some reason, you have comments you don't want to send to the entire list, you may send them to me and/or LDUP WG co-chair John Strassner. Silence means consent. Read, enjoy, and send your comments in! regards, Chris Apple and John Strassner Chris Apple Program Manager - Directory Services United Messaging Inc. (V) 610-425-2860 ------=_NextPart_001_0033_01C0F5A7.C8F978B0 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 ADR;HOME:;;214 New Street, Apt 4-N;Philadelphia;PA;19106;United States = of America LABEL;HOME;ENCODING=3DQUOTED-PRINTABLE:214 New Street, Apt = 4-N=3D0D=3D0APhiladelphia, PA 19106=3D0D=3D0AUnited States of Am=3D erica EMAIL;PREF;INTERNET:christopher.apple@unitedmessaging.com REV:20010413T223539Z END:VCARD ------=_NextPart_001_0033_01C0F5A7.C8F978B0-- ------=_NextPart_000_0032_01C0F5A7.C8F66B70 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 MQ8XDTAxMDYxNTE4MzA1NFowIwYJKoZIhvcNAQkEMRYEFHdvXgJuQNNk8G9zWV9OeeyYC3UzMFgG CSqGSIb3DQEJDzFLMEkwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwICAgCAMAcGBSsOAwIHMA0GCCqG SIb3DQMCAgEoMAcGBSsOAwIaMAoGCCqGSIb3DQIFMIGrBgkrBgEEAYI3EAQxgZ0wgZowgZIxCzAJ BgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEPMA0G A1UEChMGVGhhd3RlMR0wGwYDVQQLExRDZXJ0aWZpY2F0ZSBTZXJ2aWNlczEoMCYGA1UEAxMfUGVy c29uYWwgRnJlZW1haWwgUlNBIDIwMDAuOC4zMAIDBPxeMA0GCSqGSIb3DQEBAQUABIGAYelY6f7Z LLB7Xh8HkrVTGMMsOck9IK3Fl17fLd1b/IrnHydw2PzMcCvDvt/ydsVqsint3GoLkPnWy8Crqnk+ Q3Pbqte2ccoeD0OW0uJyg8ydkeoU7JPuhGOeJ3AGc4BCrt9dGvPEhxvBX+S7NmOMK56Qd4zaXCkK QWxNsxh2/tEAAAAAAAA= ------=_NextPart_000_0032_01C0F5A7.C8F66B70-- From owner-ietf-ldup@mail.imc.org Fri Jun 22 19:07:26 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA14627 for ; Fri, 22 Jun 2001 19:07:25 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.3/8.11.3) id f5MMkqt23463 for ietf-ldup-bks; Fri, 22 Jun 2001 15:46:52 -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 f5MMkok23459 for ; Fri, 22 Jun 2001 15:46:51 -0700 (PDT) Received: from ex01.ummail.com [216.33.108.253:25] by hawk.ummail.com with SMTP id P0622-1846-171200; Fri, 22 Jun 2001 22:46:38 GMT Received: by ex01.ummail.com with Internet Mail Service (5.5.2650.21) id ; Fri, 22 Jun 2001 18:45:04 -0400 Message-ID: From: Christopher Apple To: "'ietf-ldup@imc.org'" Subject: Correction to Last Call posting Date: Fri, 22 Jun 2001 18:45:03 -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_0037_01C0FB4B.8950D970"; 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_0037_01C0FB4B.8950D970 Content-Type: multipart/mixed; boundary="----=_NextPart_001_0038_01C0FB4B.8950D970" ------=_NextPart_001_0038_01C0FB4B.8950D970 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Correcting an error pointed out by Kurt Zeilenga. The previously revised message incorrectly indicates that the document would be published as a proposed standard. This document would be published as informational. This correction is included below. CORRECTED LAST CALL ANNOUNCEMENT The purpose of this message is to initiate the LDUP working group last call on the LDAPv3 Replication Requirements I-D document. WHAT DOCUMENT? The document in last call is: http://www.ietf.org/internet-drafts/draft-ietf-ldup-replica-req-09.txt WHAT IS A LAST CALL FOR? The purpose of the working group last call is to ensure that the working group has reached consensus on the document, believes that all the known outstanding issues have been addressed, and is ready to put the document forward for proposed standard status. During the last call, any comments on the document are collected and discussed on the mailing list. HOW LONG DOES IT LAST? The last call starts today and will last approximately two weeks. It will end on Friday, June 29, 2001. WHAT'S THE NEXT STEP? After the last call completes, there are three possible outcomes: 1) No changes are required and we request our ADs to put forward the documents to the IESG for informational status. 2) Minor changes agreed to on the list are required, and the document is revised. We then ask our ADs to put forward the revised document to the IESG for informational status. 3) Major issues are raised and no consensus is reached on the list. In this case, we discuss things until consensus is reached, at which time another working group last call will be issued. Assuming we achieve outcome 1) or 2), and that the ADs agree with our assessment, the next stop for the document is with the IESG. The IESG reads them and may approve the document (with or without changes), or send the document back to the working group to have major issues addressed. If the first outcome happens, the document is put forward for a two-week last call to the entire IETF, and after successful completion the document is published as RFCs with informational status. If the second outcome happens, we go back and address the issues, putting the documents forward again when we believe they're ready. WHAT SHOULD YOU DO? You should read the document, making sure that 1) there are no problems or deficiencies or outstanding issues that need to be resolved; and 2) that there are no typos, formatting problems, grammatical errors, etc. Any substantive problems you find, you should send to the list. Any minor problems (typos, etc.) you may send to the list or just to the authors. If, for some reason, you have comments you don't want to send to the entire list, you may send them to me and/or LDUP WG co-chair John Strassner. Silence means consent. Read, enjoy, and send your comments in! regards, Chris Apple and John Strassner Chris Apple Program Manager - Directory Services United Messaging Inc. (V) 610-425-2860 ------=_NextPart_001_0038_01C0FB4B.8950D970 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_0038_01C0FB4B.8950D970-- ------=_NextPart_000_0037_01C0FB4B.8950D970 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 MQ8XDTAxMDYyMjIyNDU0MVowIwYJKoZIhvcNAQkEMRYEFP6MERIHPDL7OxaW+PQjdQDpZB5eMFgG CSqGSIb3DQEJDzFLMEkwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwICAgCAMAcGBSsOAwIHMA0GCCqG SIb3DQMCAgEoMAcGBSsOAwIaMAoGCCqGSIb3DQIFMIGrBgkrBgEEAYI3EAQxgZ0wgZowgZIxCzAJ BgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEPMA0G A1UEChMGVGhhd3RlMR0wGwYDVQQLExRDZXJ0aWZpY2F0ZSBTZXJ2aWNlczEoMCYGA1UEAxMfUGVy c29uYWwgRnJlZW1haWwgUlNBIDIwMDAuOC4zMAIDBPxeMA0GCSqGSIb3DQEBAQUABIGANjb/wjJB QoKCIDaIg/XPWNhQq7Ubx4RLG0FoZebAY94tjiP/D2+63JhbksG3jle1KHRs0jPIwbdoH7Rdl26N FotpzdV7HAfXKXGIYn5jA4QXSSEWPZrWCe109er5gR3pwWNcuGlzGLjUeK9v/0IFfXVkCuATTQAm QywOwkOAhWoAAAAAAAA= ------=_NextPart_000_0037_01C0FB4B.8950D970-- From owner-ietf-ldup@mail.imc.org Wed Jun 27 20:35: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 UAA23959 for ; Wed, 27 Jun 2001 20:35:00 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.3/8.11.3) id f5RNvn303170 for ietf-ldup-bks; Wed, 27 Jun 2001 16:57:49 -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 f5RNvlm03165 for ; Wed, 27 Jun 2001 16:57:48 -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 f5RNsEA42304; Wed, 27 Jun 2001 23:54:14 GMT (envelope-from Kurt@OpenLDAP.org) Message-Id: <5.1.0.14.0.20010627153832.030a96a0@127.0.0.1> X-Sender: kurt@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Wed, 27 Jun 2001 16:41:25 -0700 To: Christopher Apple , john.strassner@intelliden.com From: "Kurt D. Zeilenga" Subject: Re: Correction to Last Call posting Cc: ietf-ldup@imc.org In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-ldup@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: 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. 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. 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. 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. Security Considerations: "As noted in Section 3, security may be impacted..." Section 3 makes no statement about security. It makes a statement about interoperability. 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. "privacy" (S6,S7) should be replaced with "confidentiality".