From owner-ietf-ldup@mail.imc.org Tue Apr 3 03:41:54 2001 Received: from above.proper.com ([208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id DAA24759 for ; Tue, 3 Apr 2001 03:41:53 -0400 (EDT) Received: (from majordomo@localhost) by above.proper.com (8.9.3/8.9.3) id AAA22885 for ietf-ldup-bks; Tue, 3 Apr 2001 00:03:04 -0700 (PDT) Received: from arnie.adacel.com.au (arnie.adacel.com.au [203.36.26.147]) by above.proper.com (8.9.3/8.9.3) with SMTP id AAA22876 for ; Tue, 3 Apr 2001 00:02:59 -0700 (PDT) Received: (qmail 2612 invoked from network); 3 Apr 2001 07:07:26 -0000 Received: from unknown (HELO osmium) (203.8.85.176) by arnie.adacel.com.au with SMTP; 3 Apr 2001 07:07:26 -0000 Reply-To: From: "Steven Legg" To: "'Ed Reed'" Cc: Subject: RE: Conflict Detection within the Current Architecture, was RE:New LDUP requirements draft Date: Tue, 3 Apr 2001 17:04:46 +1000 Message-ID: <004001c0bc0c$5f2280a0$b05508cb@osmium.adacel.com.au> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook 8.5, Build 4.71.2377.0 In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V4.72.2120.0 Importance: Normal Sender: owner-ietf-ldup@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit Ed, Ed Reed wrote: > Thanks for the idea, Steve - let me see if I understand the > main points... > > 1) The ending CSN vector you'd propagate in the update protocol for > each entry would really be the originating replica's CSN for whatever > set of modifications are being reported (in the state based > replication > system) for the entry - if the replica had several updates to the same > entry since the last replication cycle or replication session > with another > replica, it would be the CSN assigned to the last of those changes by > the originating replica. One conflict detection information (CDI) record is propagated for each update, not for each entry. Its state vectors are generated from the entry contents at the time the user update is processed by the originating replica. If a replica has processed N updates to the same entry since the last replication session then it will retain, and also propagate, N CDI records. Each CDI record is distinct. It does not represent the latest state of some specific directory data item like a replication primitive does. It cannot be superseded by any other CDI record, but it can be purged in due course. > 2) The starting CSN vector would be what, the vector of CSNs > constructed > by looking at the pre-image version of the entry attribute > values being > modified at the replica where the modification was entered? Not the > whole entry's CSN, nor the CSN vector constructed from the > entire entry, > but a CSN vector constructed by looking at the attributes which were > changed on the entry and using the CSNs of each of those > attributes/values. A start vector is constructed by considering all the CSNs associated with the updated entry. This includes not only the CSNs on attribute values, but the EntryCSN, Name CSN, Parent CSN, and the CSNs of relevant deletion records. All attributes are considered, not just the ones being modified, so the same start vector is generated regardless of what kind of update is about to be performed. It might be possible to construct the start vector by only considering the CSNs on parts of the entry actually read by the update, but right now I'm not at all sure this variation would work. > I can see that (1), if I understand it correctly, is > essentially what we call > for in LDUP, now - the state based system sends the entry's > attribute/values > with CSN values later than the CSN in the update CSN vector > corresponding > to the replica consuming the replication information for that > session, The CDI records would propagate around in the same way according to consumers' update vectors. If the supplier holds a CDI record with a CSN greater than the consumer's update vector that record will be sent. > which > would include the CSNs for each "updated" attribute/value - > so the end vector > you describe would be implicitly sent. Typically yes, but the effects of an earlier update can be completely overwritten by later updates. We need to explicitly include the CSN representing the end vector in the CDI record so that even if all the replication primitives for some update get superseded by later updates and disappear, we still have enough information in the CDI record (which will continue to propagate until all replicas have received it) to detect any conflicts involving that update. > I'm having some greater trouble getting my head around (2). > The starting > vector you describe sounds like would be constructed from a > pre-modification > image of the entry prior to (each? any? all?) modifications > subsequent to the > last replication session with the consuming replica. A CDI record is constructed for each update. The timing of the replication sessions doesn't come into it. > Some questions about that: > > Since the supplier replica may have replica agreements with > several other > replicas, the start vector of CSNs for each entry might need > to be different for > the modified entry for each replication session with the > different replicas, right? No. The start vector is a representation of the local state of the entry immediately prior to an update being performed. An alternative way to think of the start vector is as a description of the previous updates that the replica performing the update already knows about when the update is performed. Which ever way you think of it, the start vector has no dependency on the replica agreements because the entry has a single state at the time an update is performed, irrespective of the replication agreements that exist. Every other replica will receive exactly the same start vector for any particular update. > In other words, if there are three other replicas, the update > vector held by > the the supplier replica for each of the other replicas might > indicate that each of the > other three have received a different set of updates with > regard to the > supplying replica, and so the supplier would need to be able > to construct > a start vector (from a different starting point) for each > entry that is correct for > each consuming replica? The originating replica is only concerned with the state of the entry in its local repository at the time the user update is performed. The update vectors of eventual recipients of the resulting CDI record don't apply. > (This is hard to talk about - pictures might be easier). > > If that is the case, then it sounds like each entry needs to > keep the start vector > constructed from the pre-image view of that entry for each > modification > made to the entry (at least for changes originating at this > replica - I haven't > figured out whether it will also need start vectors > associated with each > replicated modification received, but suspect that it will). The CDI records from both locally originated updates and propagated updates need to be kept at least until they become old enough to be purged. It is sufficient if a replica tests each propagated CDI record for conflicts against the updates it originated (there is no need to test propagated CDI records against each other), but it does need to keep the propagated CDI records until they become purgable, in case they need to be forwarded to some other replica. > The storage of such start vectors for each modification would > provide some > compression of space in comparison to the storage of the > actual modification > (storing CSNs instead of CSNs + operations + values). But > one can think of > situations where the storage would not be much less (a group with 10 > members has changes (deletes) made to 3 of the members in a > single modification > would have one CSN to store with the modification, but could > have up to > one CSN per modified value if each of the pre-existing members have > come from different replicas, so as many as 3 CSNs in this case. > > It seems like there is some reduction in log storage requirements > versus simply storing the modification itself, but not an order of > magnitude difference. For a modest improvement, it seems it might > be simpler and more straight forward to simply have logged > the modification > in its entirity, and to gain the benefits that a full > log-based replication system > would have to offer in terms of being able to completely > replay operations > in sequence. Recall that this was one of the candidate approaches going into the architecture bake-off. It has some serious performance problems with the constant roll-backs and roll-forwards, as well technical difficulties with keeping the DNs straight (URP achieves the same outcome without the performance hit and DN ambiguity). Propagating the updates in their original form doesn't necessarily lead to a simple way to detect conflicts. Some of the arguments against using the original operations in the replication protocol apply for conflict detection as well. If one server is using a recently standardized or proprietary extension that other servers can't execute, the conflict detection breaks down. What I've proposed for conflict detection doesn't depend on consumer's of the CDI records knowing anything about the original update. It works even if some replicas are not capable of performing the original update. > In my mind, the principle benefit a state based replication > scheme has to > offer is that the information retention requirements are simply the > values of the data and their last CSNs. The CSNs add storage > requirements > above and beyond those needed for the data alone, but storeage > increases linearly with the number of entries, attributes, > and values, without > regard to the rate of change, the number of changes, or the > length of time elapsed since replication cycles were last > completed. Even > deletions, which can't be purged until the replication cycle > is complete with > all other replicas, are limited in their storage requirements. > > So, the rational for using a state based replication system > is all about > data storage, and sharply bounding the storage requirements > in the face > of lots of changes. > > Adding the need to hold start vectors of CSNs for entry modifications > seems to re-introduce a possibly unbounded storage requirement, which > is counter to the objective of the state based replication scheme. > > Do I understand your proposal, and am I correct in my assumption that > the storage of entry start vectors grows as the number of unreplicated > changes grows? Yes, but probably not as aggressively as you first thought. The number of CDI records a replica has to hold at any point in time will be roughly proportional to the rate of updates performed between replication sessions. Any conflict detection scheme will have that property. The scheme I'm describing is at least an add-on that doesn't require fundamental re-engineering of state-based implementations. If the conflict detection is switched off a state-based implementation will behave the way it always has, with all the benefits that entails. Regards, Steven > > Regards, > Ed > > > > > > ================= > Ed Reed > Reed-Matthews, Inc. > +1 801 796 7065 > http://www.Reed-Matthews.COM From owner-ietf-ldup@mail.imc.org Tue Apr 3 19:41:27 2001 Received: from above.proper.com ([208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA20385 for ; Tue, 3 Apr 2001 19:41:27 -0400 (EDT) Received: by above.proper.com (8.9.3/8.9.3) id QAA13144 for ietf-ldup-bks; Tue, 3 Apr 2001 16:17:21 -0700 (PDT) Received: from ns.oncalldba.com ([66.1.184.87]) by above.proper.com (8.9.3/8.9.3) with ESMTP id QAA13140 for ; Tue, 3 Apr 2001 16:17:17 -0700 (PDT) Received: from reed.oncalldba.com (reed.OnCallDBA.COM [192.168.1.3]) by ns.oncalldba.com (8.11.0/8.8.7) with SMTP id f33NGeh20647 for ; Tue, 3 Apr 2001 17:16:40 -0600 Received: from RMINC_DOM-Message_Server by reed.oncalldba.com with Novell_GroupWise; Tue, 03 Apr 2001 17:04:45 -0600 Message-Id: X-Mailer: Novell GroupWise Internet Agent 5.5.2.1 Date: Tue, 03 Apr 2001 17:04:34 -0600 From: "Ed Reed" To: Cc: Subject: RE: Conflict Detection within the Current Architecture, was RE:New LDUP requirements draft Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Disposition: inline Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id QAA13141 Sender: owner-ietf-ldup@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 8bit [eer] Comments inline [/eer] >>> "Steven Legg" 04/03/01 01:04AM >>> Ed, Ed Reed wrote: [snip] > Do I understand your proposal, and am I correct in my assumption that > the storage of entry start vectors grows as the number of unreplicated > changes grows? Yes, but probably not as aggressively as you first thought. The number of CDI records a replica has to hold at any point in time will be roughly proportional to the rate of updates performed between replication sessions. Any conflict detection scheme will have that property. [eer] - Well, any scheme attempting to provide protection against this sort of conflict. A simpler conflict resolution scheme (last write wins, with nuances to handle transient inconsistencies in DN construction and other persistent data constraints) only grows as entry and value deletion flags accumulate without being purged, and they do so with the advantage that they typically take less space than the entries and values they delete (which values may be purged when the deletion flag with its CSN is recorded). [/eer] The scheme I'm describing is at least an add-on that doesn't require fundamental re-engineering of state-based implementations. If the conflict detection is switched off a state-based implementation will behave the way it always has, with all the benefits that entails. [eer] I think you're right - if such a conflict detection mechanism could be turned off, the state based scheme could devolve gracefully (or, indeed, operate correctly if the policy had never been enabled or asserted). The policy governing the conflict dection mechanism would need to be documented at the replicaSubentry, and be supported by all replicas of the replication area. Of course, the question still arises whether this feature would be a desireable one or not. For the applications I am familiar with, I don't think it affords a benefit proportional to its additional costs in terms of processing, storage, network traffic, or complexity in the conflict resolution algorithm. Thank you for your clarifications - they were most useful. Ed [/eer] Regards, Steven > > Regards, > Ed > > > > > > ================= > Ed Reed > Reed-Matthews, Inc. > +1 801 796 7065 > http://www.Reed-Matthews.COM From owner-ietf-ldup@mail.imc.org Wed Apr 4 03:39:37 2001 Received: from above.proper.com ([208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id DAA10771 for ; Wed, 4 Apr 2001 03:39:37 -0400 (EDT) Received: (from majordomo@localhost) by above.proper.com (8.9.3/8.9.3) id AAA13905 for ietf-ldup-bks; Wed, 4 Apr 2001 00:12:36 -0700 (PDT) Received: from arnie.adacel.com.au (arnie.adacel.com.au [203.36.26.147]) by above.proper.com (8.9.3/8.9.3) with SMTP id AAA13887 for ; Wed, 4 Apr 2001 00:12:33 -0700 (PDT) Received: (qmail 13790 invoked from network); 4 Apr 2001 07:17:11 -0000 Received: from unknown (HELO osmium) (203.8.85.176) by arnie.adacel.com.au with SMTP; 4 Apr 2001 07:17:11 -0000 Reply-To: From: "Steven Legg" To: "'Ryan Moats'" , "'Richard V Huber'" , Cc: , Subject: RE: New LDUP requirements draft Date: Wed, 4 Apr 2001 17:14:24 +1000 Message-ID: <001201c0bcd6$e1c63360$b05508cb@osmium.adacel.com.au> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook 8.5, Build 4.71.2377.0 In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V4.72.2120.0 Importance: Normal Sender: owner-ietf-ldup@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit Ryan, Ryan Moats wrote: > See ... inline below... Ryan > > Rick, > > Richard V Huber wrote: > > This started out as a reply to Steven Legg's message, but I > > guess it is > > now also a reply to Tim Hahn, Ed Reed, and Kurt Zeilenga. > > > > P7 is a protocol requirement. The change between previous > drafts and > > draft -07 was to make it clearer what atomicity information > has to be > > carried by the protocol. > > In my opinion, the requirement is now less clear. The > requirement might > now clarify what atomicity information has to be carried by > the protocol > but we've lost the immediate context that we are talking > about "atomicity > information that must be carried in the protocol". It don't > think it is > enough to expect readers will fill in the missing context by noting it > is a *protocol* requirement. > > Steve, you've totally lost me here. I don't see where the context > has been lost. The section talks about protocol and it say > specifically > what the protocol must carry. I disagree that it is less clear. Can you please point me at the sentence in the section that specifically says that P7 is about "what the protocol must carry"? I can't seem to find it. Other requirements in the same section have consequences that go beyond just what the protocol must carry. It is not unreasonable for the reader to assume that P7 might also have wider consequences. The way P7 now reads suggests to me some unintended serious consequences for the architecture and the conflict resolution mechanism. > > I don't think this clarification makes it > > inconsistent with other parts of the document. > > Given the understanding that P7 is still about what atomicity > information is > required to be carried in the protocol then I agree that it > is consistent > with other parts of the document, but my problem is that I believe the > current wording suggests other (possibly inconsistent) > interpretations. > A casual reader might not notice that their interpretation doesn't > fit with the rest of the document. Each requirement should be clear > and able to stand on its own without having to analyse the other > requirements to weed out the correct interpretation. > > I saw a similar problem with the previous version and > so we added the reference to RFC 2251 specifically to provide some > clarity. Are you asking for "LDAP operations" to be replaced by > "LDAP modify operations"? No. I want P7 to be rewritten so that it no longer seems to be imposing a requirement on the conflict resolution mechanism, i.e. URP, to maintain the atomicity of LDAP operations. I remain unconvinced that P7 clearly says what you mean it to say. We may have to agree to disagree. By the way, RFC 2251 only mentions atomicity in the context of the set of modifications in a Modify Request. The atomicity requirements for other operations are unstated. The same situation applies in X.511. Conventional wisdom is that all LDAP and DAP update operations are atomic, but none of the specifications make that clear. Regards, Steven From owner-ietf-ldup@mail.imc.org Wed Apr 4 10:14:41 2001 Received: from above.proper.com ([208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA20313 for ; Wed, 4 Apr 2001 10:14:40 -0400 (EDT) Received: (from majordomo@localhost) by above.proper.com (8.9.3/8.9.3) id GAA27570 for ietf-ldup-bks; Wed, 4 Apr 2001 06:45:28 -0700 (PDT) Received: from mail.coreon.net (IDENT:mirapoint@mail.coreon.net [216.74.131.6]) by above.proper.com (8.9.3/8.9.3) with ESMTP id GAA27562 for ; Wed, 4 Apr 2001 06:45:26 -0700 (PDT) Received: from rmoats2 (wenjus3.coreon.net [216.74.131.3]) by mail.coreon.net (Mirapoint) with ESMTP id AAA73967 (AUTH rmoats); Wed, 4 Apr 2001 09:45:01 -0400 (EDT) From: "Ryan Moats" To: , "'Richard V Huber'" , Cc: , Subject: RE: New LDUP requirements draft Date: Wed, 4 Apr 2001 08:54:56 -0500 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 Importance: Normal In-Reply-To: <001201c0bcd6$e1c63360$b05508cb@osmium.adacel.com.au> Sender: owner-ietf-ldup@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit ... inline below... Ryan -----Original Message----- Ryan, Ryan Moats wrote: > See ... inline below... Ryan > > Rick, > > Richard V Huber wrote: > > This started out as a reply to Steven Legg's message, but I > > guess it is > > now also a reply to Tim Hahn, Ed Reed, and Kurt Zeilenga. > > > > P7 is a protocol requirement. The change between previous > drafts and > > draft -07 was to make it clearer what atomicity information > has to be > > carried by the protocol. > > In my opinion, the requirement is now less clear. The > requirement might > now clarify what atomicity information has to be carried by > the protocol > but we've lost the immediate context that we are talking > about "atomicity > information that must be carried in the protocol". It don't > think it is > enough to expect readers will fill in the missing context by noting it > is a *protocol* requirement. > > Steve, you've totally lost me here. I don't see where the context > has been lost. The section talks about protocol and it say > specifically > what the protocol must carry. I disagree that it is less clear. Can you please point me at the sentence in the section that specifically says that P7 is about "what the protocol must carry"? I can't seem to find it. Other requirements in the same section have consequences that go beyond just what the protocol must carry. It is not unreasonable for the reader to assume that P7 might also have wider consequences. The way P7 now reads suggests to me some unintended serious consequences for the architecture and the conflict resolution mechanism. To me, the word "protocol" means only "protocol". If you are becoming confused that other requirements in the section are not limited in their wording to the protocol, then that is something that needs to be examined. Taking a fresh look at section 4.3, the only requirement that I see as possibly having consequences outside of the scope of the protocol is P3. This needs to be reworded or moved to the model section. This is consistent with previous changes where requirements were moved from the protocol section when it became clear that they covered more than just the protocol. > > I don't think this clarification makes it > > inconsistent with other parts of the document. > > Given the understanding that P7 is still about what atomicity > information is > required to be carried in the protocol then I agree that it > is consistent > with other parts of the document, but my problem is that I believe the > current wording suggests other (possibly inconsistent) > interpretations. > A casual reader might not notice that their interpretation doesn't > fit with the rest of the document. Each requirement should be clear > and able to stand on its own without having to analyse the other > requirements to weed out the correct interpretation. > > I saw a similar problem with the previous version and > so we added the reference to RFC 2251 specifically to provide some > clarity. Are you asking for "LDAP operations" to be replaced by > "LDAP modify operations"? No. I want P7 to be rewritten so that it no longer seems to be imposing a requirement on the conflict resolution mechanism, i.e. URP, to maintain the atomicity of LDAP operations. I remain unconvinced that P7 clearly says what you mean it to say. We may have to agree to disagree. We may indeed have to agree to disagree. I think it is reasonable to say that the replication protocol (not the resolution procedures, not ...) should maintain the same atomicity information that is available via LDAP itself. From owner-ietf-ldup@mail.imc.org Wed Apr 4 19:04:21 2001 Received: from above.proper.com ([208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA04098 for ; Wed, 4 Apr 2001 19:04:21 -0400 (EDT) Received: (from majordomo@localhost) by above.proper.com (8.9.3/8.9.3) id PAA06243 for ietf-ldup-bks; Wed, 4 Apr 2001 15:24:34 -0700 (PDT) Received: from sj-msg-core-2.cisco.com (sj-msg-core-2.cisco.com [171.69.43.88]) by above.proper.com (8.9.3/8.9.3) with ESMTP id PAA06237 for ; Wed, 4 Apr 2001 15:24:33 -0700 (PDT) Received: from mira-sjcm-1.cisco.com (mira-sjcm-1.cisco.com [171.69.43.102]) by sj-msg-core-2.cisco.com (8.9.3/8.9.1) with ESMTP id PAA26703 for ; Wed, 4 Apr 2001 15:24:25 -0700 (PDT) Received: from JSTRASSN-W2K1.cisco.com (dhcp-128-107-131-50.cisco.com [128.107.131.50]) by mira-sjcm-1.cisco.com (Mirapoint) with ESMTP id AEJ17982; Wed, 4 Apr 2001 15:24:01 -0700 (PDT) Message-Id: <4.3.2.7.2.20010404124758.00b7b0d8@mira-sjcm-1.cisco.com> X-Sender: jstrassn@mira-sjcm-1.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Wed, 04 Apr 2001 15:23:54 -0700 To: ietf-ldup@imc.org From: John Strassner Subject: WG Meeting Minutes Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ietf-ldup@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Greetings LDUPers, below please find the draft meeting minutes for the San Diego meeting. Please submit any comments and corrections to me asap so that I can include these in the official minutes. And thanks presenters, I already have all of your slides for inclusion. regards, John Strassner LDUP WG Co-Chair ====================== SNIP HERE ========================== Draft Summary and Meeting Minutes LDUP Working Group Meeting 50th IETF, Minneapolis Minutes recorded by John Strassner, March 19, 2000 The agenda was presented by John, and no adjustments were made. Discussion of Changes Made to Requirements I-D draft-ietf-ldup-replica-req-07 The discussion was led by one of the co-authors, Rick Huber. A summary of the changes made in response to Last Call comments was presented. The key points are as follows: - interoperability paragraph was rewritten and clarified - replaced the term "naming context" with the term "replication base entry" - replaced the term "replica ring" with the term "replica group" - deprecated the term "updateable replicas" - clarified model 1 and multi-master atomicity - requirements G9-G11 were added to cover what needs to be replicated at the attribute level - M3 was reworded for clarity - requirement P2 was split into two requirements, P2 and P3, and all subsequent P requirements were renumbered - moved (the old) P7 to G8 since it is not limited to protocol - rewrote P6 (now P7) to explicitly require propagation of atomicity of LDAP operations as defined in 2251 - explicitly noted (ongoing) ACL work in the security section - made text in section A.10 self-consistent - changed text in B.5.5 to clarify the term "at the same time" Questions: -Ellen asked about other documents that need to be brought in line. Will be tabled until later in the meeting -A question of why "updateable replica" was deprecated. It comes from Kurt's mail. -Point that P7 moving to G8 makes G2 and G8 copies of each other; authors to address this in the next revision of the requirements draft Rich then presented items that were deferred. The key points were: - external locking will be addressed in the profiles I-D - clarified that the term "area of replication" is equivalent to X.525's term "replicated area" Question: -Point about "area of replication" and X.525 "replicated area" brought the comment from Ed that the only requirement for LDUP is to define the contiguous sub-tree. Kurt wants a note that LDUP protocol may define it own administrative model. Request that the area of replication is a subset of X.500 and that the administrative model...authors seemed to agree Next steps: The authors will issue a new draft (-08) ASAP and are requesting another WG last call. John urged all members to *please* get their comments in this week or as soon as the document was issued so that the authors would have time to address any additional comments before doing another last call. Kurt wanted to know if this is really necessary? John responded yes, because technical changes have been made. John asked the meeting participants if anyone had any objections to the requirements draft going to last call, and there were no objections. Kurt said that he would look at the security section. ================================================ Discussion of Usage Profile I-D draft-ietf-ldup-usage-profile-00.txt The discussion was led by Rick Huber, one of the co-authors of the draft. Rick gave an overview of the -00 draft. Its scope is to discuss the design and development issues that may arise due to using replication in directory deployments. The document will discuss both single- and multi-master scenarios. The authors encourage any application-specific profiles to be added. Next steps would be to add a discussion of external locking from the requirements draft, and to discuss different ways to preserve atomicity across replication. The authors wanted to know whether the target track for this draft should be informational or BCP. The sense of the room was that this should be an informational track document, as there isn't a set of standards from which to recommend best current practices. John noted that this draft contains multi-master and master-slave profiles, so the charter needs correction. John further noted that this is a working, living draft, and not ready for last call any time soon. John urged everyone to read the draft and submit comments asap, in order to help the authors develop the next version of the draft. =========================================================== Discussion of Changes Made to Architecture Document draft-ietf-ldup-model-06.txt This discussion was led by Ed Reed, one of the authors of the draft. The authors think that it is ready for WG Last Call. This version is based largely on the comments made by Tim Hahn. The discussion of policy inheritance was removed from the document and placed into a new I-D. The one outstanding item that the authors know needs to be removed is to drop a reference to search filter visibility of subentries. Question from the floor - how well does this version correlate with the requirements document? A lengthy discussion then ensued. However, one of the major questions that arose was, what happened with operations that cross replication boundaries? How should they be handled? The answer lies in the direction of a distributed directory, but LDAP doesn't yet have a truly distributed model. LDAP Subentry can help. Problem with deleting superiors that have subordinate reference - you either delete the subordinate, move it to Lost+Found, or say that the operation is not allowed because it has children. But this last option is NOT currently in LDAP. More general question is, how do you take two portions of the namespace, where the superior and the subordinate are in different partitions? Note that you have DSE types - the object is in one management plane and the subordinate is in another management plane (note that LDAP doesn't have DSEs). We need to look at the namedref document. Both LDAPext and LDUP have a stake in how this comes out. In an LDAP environment, this is an issue that crops up regardless of whether there is replication. Since this appears to be a significant design issue, John called for a group of volunteers to form a design team to study and resolve this problem. The volunteers were: John McMeeking Mark Smith Mark Wahl Skip Sloane Steve Mclane Kurt Zeilenga Ed Reed This design team's first meeting is tomorrow at 3pm. They will report back to the LDUP WG. Their feedback will then be incorporated into the draft. ====================================================== Discussion on URP - ready for Last Call or not? draft-ietf-ldup-urp-03.txt Unfortunately, neither of the authors could attend this meeting due to work and illness. John relayed this information. With respect to the draft, it has timed out, and needs to be reissued. Note that it should be compared against the requirements draft, and nothing will happen until the requirements doc passes WG Last Call. ======================================================= Discussion on the LDUP Replication Update Protocol draft-ietf-ldup-protocol-02.txt The discussion was led by Ellen Stokes, one of the authors of the draft. This draft has timed out and needs to be reissued. Ellen suggested a hard deadline of Friday the 13th [ed: honest! ;-) ] of April due for an update due to a hard vacation deadline; Roger Harrison to give Ellen an update tomorrow. This document **appears** to be ready for Last Call - only minor comments were posted in the last revision. Poll of room - no negative comments, Roger thinks that it probably is ready as he has been through the document. ========================================== Discussion on LDUP Subentry Schema draft-ietf-ldup-subentry-07.txt This discussion was led by Ed Reed, one of the authors of the draft. Note that this is a product of both the LDUP and the LDAPext WGs. Issued version 7. Main changes included separating the inheritance discussion, and put that in a separate document (draft-reed-ldup-inheritance-00.txt). Removed the search-filter mechanism for visibility. The search operation behaves as though the visibility control is present, even though it isn't. In other words, it doesn't make any sense if you have used an LDAP Subentry as the base object of the search, and you didn't include the control to return the results of the search. Kurt pointed out that since these may be nested, and if the base object of the search is a subentry, then you should behave as if the control is present. Ed agreed. A discussion followed clarifying other operations. It was agreed that if the control is present and true, all you get is subentries, otherwise you do not get subentries. Kurt and Ed will recheck the draft one last time to be sure that this (and the above) behavior is specified this way in the draft. Ed agreed to add the description of an administrative area, and then state that you can't replicate either a rootDSE or any subentries of the rootDSE. The purpose of InheritableLDAPSubentry was to provide an example of how to add inheritance to policy. After a short discussion, it was agreed in the room that it would be best to remove this from the draft. ====================================================== Discussion of Policy Inheritance Mechanisms for LDAP draft-reed-ldup-inheritance-00.txt Ed made a short presentation Ed said that he would make these changes and try and publish the document asap. Ed further stated that he will actively look for an author to take up the inheritance work, because otherwise he will let it die. =============================================== Discussion on LDAP Client Update Protocol draft-natkovich-ldap-lcup-02.txt (Chair note: please resubmit this draft with as a wg draft (i.e., draft-ietf-ldup-lcup-00.txt) This discussion was led by Mark Smith, one of the authors of the draft. Rich Megginson has taken over editing. It has been reviewed by the authors. No substantial changes, but a fair amount of clarifying text. Note that this is not really a -00, as there were several versions of persistent and triggered search, and lcup as an individual submission. Still some open issues in the document, so we need to decide as a group whether to punt because they are out of scope or not. It was noted that LCUP is replacing triggered search, persistent search, and dirSync. ====================================================== Discussion of other missing drafts John McMeeking and Ryan have offered to take up the Mandatory Replica Management draft. Tim Hahn has offered to take up the Infomod draft. ====================================================== Any other business It has become apparent that, after listening to the discussions on progress of the various drafts, that two things are missing. They are: - we need common naming and terminology applied to all drafts - we need someone to compare the requirements document to the other drafts John suggested that the co-chairs perform this policing (volunteers are solicited and welcome!). Draft authors can't really review the drafts for these points, as they already should be doing this, and we need independent people doing this review. End of meeting. From owner-ietf-ldup@mail.imc.org Thu Apr 5 07:13:48 2001 Received: from above.proper.com ([208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA27617 for ; Thu, 5 Apr 2001 07:13:48 -0400 (EDT) Received: by above.proper.com (8.9.3/8.9.3) id DAA02779 for ietf-ldup-bks; Thu, 5 Apr 2001 03:39:38 -0700 (PDT) Received: from plmta00.chello.pl (plmta00.chello.pl [213.46.248.62]) by above.proper.com (8.9.3/8.9.3) with ESMTP id DAA02774 for ; Thu, 5 Apr 2001 03:39:36 -0700 (PDT) Message-Id: <200104051039.DAA02774@above.proper.com> Received: from hetnet.nl ([213.93.48.181]) by plmta00.chello.pl (Post.Office MTA v3.5.3 release 223 ID# 0-0U10L2S100V35) with SMTP id pl for ; Thu, 5 Apr 2001 08:01:16 -0100 From: "Rita de Groot" To: Subject: huidziekte Mime-Version: 1.0 Content-Type: text/plain; charset="ISO-8859-1" Date: Thu, 5 Apr 2001 10:58:47 +0200 Content-Transfer-Encoding: 8bit Sender: owner-ietf-ldup@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 8bit Vijf jaar voordat deze foto's werden genomen werd bij mij diagnose reumatische artritis gesteld en als zodanig ook behandeld. Niets hielp. Toen de ziekte zich zo manifesteerde zoals u hieronder kunt zien.......... http://www.naardedokter.com/testimonials/sys_lup_eryth.htm From owner-ietf-ldup@mail.imc.org Fri Apr 6 10:53:04 2001 Received: from above.proper.com ([208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA11049 for ; Fri, 6 Apr 2001 10:53:04 -0400 (EDT) Received: by above.proper.com (8.9.3/8.9.3) id HAA00474 for ietf-ldup-bks; Fri, 6 Apr 2001 07:24:12 -0700 (PDT) Received: from e1.ny.us.ibm.com (e1.ny.us.ibm.com [32.97.182.101]) by above.proper.com (8.9.3/8.9.3) with ESMTP id HAA00459 for ; Fri, 6 Apr 2001 07:24:11 -0700 (PDT) Received: from northrelay01.pok.ibm.com (northrelay01.pok.ibm.com [9.117.200.21]) by e1.ny.us.ibm.com (8.9.3/8.9.3) with ESMTP id KAA115948 for ; Fri, 6 Apr 2001 10:22:45 -0400 Received: from d01mlc96.pok.ibm.com (d01mlc96.pok.ibm.com [9.117.250.33]) by northrelay01.pok.ibm.com (8.8.8m3/NCO v4.95) with ESMTP id KAA24552 for ; Fri, 6 Apr 2001 10:24:04 -0400 To: ietf-ldup@imc.org Subject: entryUUID X-Mailer: Lotus Notes Release 5.0.5 September 22, 2000 From: "Timothy Hahn" Message-ID: Date: Fri, 6 Apr 2001 10:23:22 -0400 X-MIMETrack: Serialize by Router on D01MLC96/01/M/IBM(Release 5.0.7.dev00 SPR #MIAS4UTJ8H &S/390 SPR #JHEG4V8UT5|April 3, 2001) at 04/06/2001 10:24:04 AM, Serialize complete at 04/06/2001 10:24:04 AM MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="=_alternative 004ED53685256A26_=" Sender: owner-ietf-ldup@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multipart message in MIME format. --=_alternative 004ED53685256A26_= Content-Type: text/plain; charset="us-ascii" Hello all, We have found a need to use the proposed attribute: entryUUID prior to a full definition of LDUP replication models. Has anyone crisply defined this attribute, including an OID? Would anyone like to do so so that applications could use this definition prior to having an LDUP set of RFCs? The alternative could be that each implementation/vendor defines their own in the mean-time ... not necessarily with the same format. Does anyone out there care? Regards, Tim Hahn Internet: hahnt@us.ibm.com Internal: Timothy Hahn/Endicott/IBM@IBMUS or IBMUSM00(HAHNT) phone: 607.752.6388 tie-line: 8/852.6388 fax: 607.752.3681 --=_alternative 004ED53685256A26_= Content-Type: text/html; charset="us-ascii"
Hello all,

We have found a need to use the proposed attribute: entryUUID prior to a full definition of LDUP replication models.

Has anyone crisply defined this attribute, including an OID?

Would anyone like to do so so that applications could use this definition prior to having an LDUP set of RFCs?

The alternative could be that each implementation/vendor defines their own in the mean-time ... not necessarily with the same format.

Does anyone out there care?
Regards,
Tim Hahn

Internet: hahnt@us.ibm.com
Internal: Timothy Hahn/Endicott/IBM@IBMUS or IBMUSM00(HAHNT)
phone: 607.752.6388     tie-line: 8/852.6388
fax: 607.752.3681
 --=_alternative 004ED53685256A26_=-- From owner-ietf-ldup@mail.imc.org Fri Apr 6 12:36:01 2001 Received: from above.proper.com ([208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA14013 for ; Fri, 6 Apr 2001 12:36:00 -0400 (EDT) Received: by above.proper.com (8.9.3/8.9.3) id JAA11036 for ietf-ldup-bks; Fri, 6 Apr 2001 09:04:43 -0700 (PDT) Received: from ns.oncalldba.com ([66.1.184.87]) by above.proper.com (8.9.3/8.9.3) with ESMTP id JAA11031 for ; Fri, 6 Apr 2001 09:04:41 -0700 (PDT) Received: from reed.oncalldba.com (reed.OnCallDBA.COM [192.168.1.3]) by ns.oncalldba.com (8.11.0/8.8.7) with SMTP id f36G42A01233 for ; Fri, 6 Apr 2001 10:04:02 -0600 Received: from RMINC_DOM-Message_Server by reed.oncalldba.com with Novell_GroupWise; Fri, 06 Apr 2001 09:38:49 -0600 Message-Id: X-Mailer: Novell GroupWise Internet Agent 5.5.2.1 Date: Fri, 06 Apr 2001 09:38:36 -0600 From: "Ed Reed" To: Cc: , , , , , "Ed Reed" , Subject: draft-ietf-ldup-subentry-08.txt Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Disposition: inline Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id JAA11033 Sender: owner-ietf-ldup@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 8bit Please publish the attached revised internet draft. Abstract: This document describes an administrative model for LDAP, and an object class called ldapSubEntry and a control ldapSubentriesControl (to control the visibility of entries of type ldapSubEntry) that are to be used by directory servers claiming support for the administrative model defined here. ================= Ed Reed Reed-Matthews, Inc. +1 801 796 7065 http://www.Reed-Matthews.COM From owner-ietf-ldup@mail.imc.org Fri Apr 6 13:03:03 2001 Received: from above.proper.com ([208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA14514 for ; Fri, 6 Apr 2001 13:03:02 -0400 (EDT) Received: by above.proper.com (8.9.3/8.9.3) id JAA13827 for ietf-ldup-bks; Fri, 6 Apr 2001 09:40:45 -0700 (PDT) Received: from ns.oncalldba.com ([66.1.184.87]) by above.proper.com (8.9.3/8.9.3) with ESMTP id JAA13823 for ; Fri, 6 Apr 2001 09:40:43 -0700 (PDT) Received: from reed.oncalldba.com (reed.OnCallDBA.COM [192.168.1.3]) by ns.oncalldba.com (8.11.0/8.8.7) with SMTP id f36Ge4A01396 for ; Fri, 6 Apr 2001 10:40:04 -0600 Received: from RMINC_DOM-Message_Server by reed.oncalldba.com with Novell_GroupWise; Fri, 06 Apr 2001 10:14:47 -0600 Message-Id: X-Mailer: Novell GroupWise Internet Agent 5.5.2.1 Date: Fri, 06 Apr 2001 10:14:29 -0600 From: "Ed Reed" To: , Subject: Re: entryUUID Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Disposition: inline Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id JAA13824 Sender: owner-ietf-ldup@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 8bit Tim - it's within the proper scope of draft-ietf-ldup-infomod. ;-) The value UUIDs and the entryUUID are described there, and are intended to conform to, the DCE UUID specification used in DCE (duh) and the corresponding ISO RPC specification. Generating an RFC that describes them without treading on copyright restrictions has hindered publication of an RFC for that purpose to date, but that's what's intended by LDUP. Its syntax should be octet string, in my opinion. Ed >>> "Timothy Hahn" 04/06/01 08:23AM >>> Hello all, We have found a need to use the proposed attribute: entryUUID prior to a full definition of LDUP replication models. Has anyone crisply defined this attribute, including an OID? Would anyone like to do so so that applications could use this definition prior to having an LDUP set of RFCs? The alternative could be that each implementation/vendor defines their own in the mean-time ... not necessarily with the same format. Does anyone out there care? Regards, Tim Hahn Internet: hahnt@us.ibm.com Internal: Timothy Hahn/Endicott/IBM@IBMUS or IBMUSM00(HAHNT) phone: 607.752.6388 tie-line: 8/852.6388 fax: 607.752.3681 From owner-ietf-ldup@mail.imc.org Fri Apr 6 13:05:11 2001 Received: from above.proper.com ([208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA14554 for ; Fri, 6 Apr 2001 13:05:09 -0400 (EDT) Received: (from majordomo@localhost) by above.proper.com (8.9.3/8.9.3) id JAA11273 for ietf-ldup-bks; Fri, 6 Apr 2001 09:07:56 -0700 (PDT) Received: from ns.oncalldba.com ([66.1.184.87]) by above.proper.com (8.9.3/8.9.3) with ESMTP id JAA11267 for ; Fri, 6 Apr 2001 09:07:53 -0700 (PDT) Received: from reed.oncalldba.com (reed.OnCallDBA.COM [192.168.1.3]) by ns.oncalldba.com (8.11.0/8.8.7) with SMTP id f36G7EA01267 for ; Fri, 6 Apr 2001 10:07:14 -0600 Received: from RMINC_DOM-Message_Server by reed.oncalldba.com with Novell_GroupWise; Fri, 06 Apr 2001 09:42:03 -0600 Message-Id: X-Mailer: Novell GroupWise Internet Agent 5.5.2.1 Date: Fri, 06 Apr 2001 09:41:43 -0600 From: "Ed Reed" To: Cc: , , , , , "Ed Reed" , Subject: draft-ietf-ldup-subentry-08.txt (with attachment, this time) Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="=_A7FC5DDB.FE9FF288" Sender: owner-ietf-ldup@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: --=_A7FC5DDB.FE9FF288 Content-Type: text/plain; charset=US-ASCII Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Please publish the attached (really!) revised draft. Abstract: This document describes an administrative model for LDAP,=20 and an object class called ldapSubEntry and a control=20 ldapSubentriesControl (to control the visibility of entries=20 of type ldapSubEntry) that are to be used by directory=20 servers claiming support for the administrative model=20 defined here.=20 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Ed Reed Reed-Matthews, Inc. +1 801 796 7065 http://www.Reed-Matthews.COM --=_A7FC5DDB.FE9FF288 Content-Type: text/plain Content-Disposition: attachment; filename="draft-ietf-ldup-subentry-08.txt" Content-Transfer-Encoding: base64 DQoKCgoKCiBJTlRFUk5FVC1EUkFGVCANCiBkcmFmdC1pZXRmLWxkdXAtc3ViZW50cnktMDgudHh0 IA0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg RWQgUmVlZCANCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIFJlZWQt TWF0dGhld3MsIEluYy4gDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICBBcHJpbCA2LCAyMDAxIA0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICANCiAgICAgICAgICAgICAgICAgICAgIExEQVAg U3ViZW50cnkgU2NoZW1hIA0KCgogMSAgU3RhdHVzIG9mIHRoaXMgTWVtbyANCgogVGhpcyBkb2N1 bWVudCBpcyBhbiBJbnRlcm5ldC1EcmFmdCBhbmQgaXMgaW4gZnVsbCANCiBjb25mb3JtYW5jZSB3 aXRoIGFsbCBwcm92aXNpb25zIG9mIFNlY3Rpb24gMTAgb2YgUkZDMjAyNi4gDQogIA0KIEludGVy bmV0LURyYWZ0cyBhcmUgd29ya2luZyBkb2N1bWVudHMgb2YgdGhlIEludGVybmV0IA0KIEVuZ2lu ZWVyaW5nIFRhc2sgRm9yY2UgKElFVEYpLCBpdHMgYXJlYXMsIGFuZCBpdHMgd29ya2luZyANCiBn cm91cHMuIE5vdGUgdGhhdCBvdGhlciBncm91cHMgbWF5IGFsc28gZGlzdHJpYnV0ZSB3b3JraW5n IA0KIGRvY3VtZW50cyBhcyBJbnRlcm5ldC1EcmFmdHMuICANCiAgDQogSW50ZXJuZXQtRHJhZnRz IGFyZSBkcmFmdCBkb2N1bWVudHMgdmFsaWQgZm9yIGEgbWF4aW11bSBvZiANCiBzaXggbW9udGhz IGFuZCBtYXkgYmUgdXBkYXRlZCwgcmVwbGFjZWQsIG9yIG9ic29sZXRlZCBieSANCiBvdGhlciBk b2N1bWVudHMgYXQgYW55IHRpbWUuIEl0IGlzIGluYXBwcm9wcmlhdGUgdG8gdXNlIA0KIEludGVy bmV0LURyYWZ0cyBhcyByZWZlcmVuY2UgbWF0ZXJpYWwgb3IgdG8gY2l0ZSB0aGVtIG90aGVyIA0K IHRoYW4gYXMgIndvcmsgaW4gcHJvZ3Jlc3MuIiAgDQogIA0KIFRoZSBsaXN0IG9mIGN1cnJlbnQg SW50ZXJuZXQtRHJhZnRzIGNhbiBiZSBhY2Nlc3NlZCBhdCANCiBodHRwOi8vd3d3LmlldGYub3Jn L2lldGYvMWlkLWFic3RyYWN0cy50eHQuICANCiAgDQogVGhlIGxpc3Qgb2YgSW50ZXJuZXQtRHJh ZnQgU2hhZG93IERpcmVjdG9yaWVzIGNhbiBiZSANCiBhY2Nlc3NlZCBhdCBodHRwOi8vd3d3Lmll dGYub3JnL3NoYWRvdy5odG1sLiANCiAgDQogVGhpcyBJbnRlcm5ldC1EcmFmdCBleHBpcmVzIG9u IE9jdG9iZXIgNiwgMjAwMS4gDQoKCiAyICBBYnN0cmFjdCAvIERlc2NyaXB0aW9uIA0KCiBUaGlz IGRvY3VtZW50IGRlc2NyaWJlcyBhbiBhZG1pbmlzdHJhdGl2ZSBtb2RlbCBmb3IgTERBUCwgDQog YW5kIGFuIG9iamVjdCBjbGFzcyBjYWxsZWQgbGRhcFN1YkVudHJ5IGFuZCBhIGNvbnRyb2wgDQog bGRhcFN1YmVudHJpZXNDb250cm9sICh0byBjb250cm9sIHRoZSB2aXNpYmlsaXR5IG9mIGVudHJp ZXMgDQogb2YgdHlwZSBsZGFwU3ViRW50cnkpIHRoYXQgYXJlIHRvIGJlIHVzZWQgYnkgZGlyZWN0 b3J5IA0KIHNlcnZlcnMgY2xhaW1pbmcgc3VwcG9ydCBmb3IgdGhlIGFkbWluaXN0cmF0aXZlIG1v ZGVsIA0KIGRlZmluZWQgaGVyZS4gDQoKICBUaGUga2V5IHdvcmRzICJNVVNUIiwgIk1VU1QgTk9U IiwgIlJFUVVJUkVEIiwgIlNIQUxMIiwgDQogIlNIQUxMIE5PVCIsICJTSE9VTEQiLCAiU0hPVUxE IE5PVCIsICJSRUNPTU1FTkRFRCIsICJNQVkiLCANCiBhbmQgICJPUFRJT05BTCIgaW4gdGhpcyBk b2N1bWVudCBhcmUgdG8gYmUgaW50ZXJwcmV0ZWQgYXMgDQogZGVzY3JpYmVkIGluIFtSRkMyMTE5 XS4gVGhlIHNlY3Rpb25zIGJlbG93IHJlaXRlcmF0ZSB0aGVzZSANCiBkZWZpbml0aW9ucyBhbmQg aW5jbHVkZSBzb21lIGFkZGl0aW9uYWwgb25lcy4gDQoKCiBSZWVkICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBbUGFnZSAxXSANCiAgICAgICAg ICAgICAgICAgICBFeHBpcmVzIE9jdG9iZXIgNiwgMjAwMSAMDQoKCiBJTlRFUk5FVC1EUkFGVCAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIDYgQXByaWwgMjAwMSANCiAgICAgICAgICAg ICAgICAgICAgIExEQVAgU3ViZW50cnkgU2NoZW1hIA0KCiAzICBUYWJsZSBvZiBDb250ZW50cyAN CgogMSAgU3RhdHVzIG9mIHRoaXMgTWVtbyAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgIDEgDQogMiAgQWJzdHJhY3QgLyBEZXNjcmlwdGlvbiAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgIDEgDQogMyAgVGFibGUgb2YgQ29udGVudHMgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIDIgDQogNCAgQWRtaW5pc3RyYXRpdmUg QXJlYXMgaW4gdGhlIERpcmVjdG9yeSAgICAgICAgICAgICAgICAgICAgICAgIDIgDQogNC4xICBY LjUwMSBBZG1pbmlzdHJhdGl2ZSBNb2RlbCBPdmVydmlldyAgICAgICAgICAgICAgICAgICAgICAg ICAyIA0KIDQuMiAgQW4gTERBUCBBZG1pbmlzdHJhdGl2ZSBNb2RlbCAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgMyANCiA1ICBPYmplY3QgQ2xhc3MgRGVmaW5pdGlvbnMgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgNCANCiA1LjEgIGxkYXBTdWJFbnRyeSBDbGFzcyAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIDQgDQogNS4xLjEgICAgIE5h bWluZyBhbmQgU3RydWN0dXJlIGNvbnN0cmFpbnRzICAgICAgICAgICAgICAgICAgICAgICA0IA0K IDUuMS4yICAgICBTY29wZSBSdWxlcyAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgNSANCiA2ICBWaXNpYmlsaXR5IENvbnRyb2wgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgNiANCiA2LjEgIGxkYXBTdWJlbnRyaWVzQ29udHJvbCAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIDYgDQogNi4xLjEgICAgIE90aGVyIExE QVAgb3BlcmF0aW9ucyAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICA2IA0KIDYuMS4y ICAgICBDb3JyZXNwb25kZW5jZSB0byBbWDUxMV0gICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgNiANCiA3ICBTZWN1cml0eSBDb25zaWRlcmF0aW9ucyAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgNyANCiA4ICBSZWZlcmVuY2VzICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgNyANCiA5ICBDb3B5cmlnaHQgTm90aWNlICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgOCANCiAxMCBBY2tub3dsZWRn ZW1lbnRzICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgOCANCiAx MSBBdXRob3IncyBBZGRyZXNzICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgOSANCiAgDQoKCiA0ICBBZG1pbmlzdHJhdGl2ZSBBcmVhcyBpbiB0aGUgRGlyZWN0b3J5 IA0KCgogNC4xIFguNTAxIEFkbWluaXN0cmF0aXZlIE1vZGVsIE92ZXJ2aWV3IA0KCiBbWDUwMV0g Y29udGFpbnMgdGhlIGRlZmluaXRpdmUgZGVzY3JpcHRpb24gb2YgDQogQWRtaW5pc3RyYXRpdmUg QXJlYXMgYW5kIHRoZWlyIHJvbGUgaW4gdGhlIG1hbmFnZW1lbnQgYW5kIA0KIGFkbWluaXN0cmF0 aW9uIG9mIGRpcmVjdG9yaWVzLiAgVGhlIExEQVAgYWRtaW5pc3RyYXRpdmUgDQogbW9kZWwgZGVm aW5lZCBoZXJlIGlzIGludGVuZGVkIHRvIGJlIGEgY29tcGF0aWJsZSwgcHJvcGVyIA0KIHN1YnNl dCBvZiB0aGUgW1g1MDFdIG1vZGVsLiAgVGhlIGRlc2NyaXB0aW9uIGhlcmUgZHJhd3MgDQogaGVh dmlseSBvbiB0aGUgZGVzY3JpcHRpb25zIGFuZCBjb25jZXB0cyBsYWlkIG91dCBpbiANCiBbWDUw MV0uIA0KICANCiBBbiBhZG1pbmlzdHJhdGl2ZSBhcmVhIGlzIGEgc3ViLXRyZWUgb2YgdGhlIGRp cmVjdG9yeSANCiBpbmZvcm1hdGlvbiB0cmVlLCByb290ZWQgYXQgYW4gYWRtaW5pc3RyYXRpdmUg cG9pbnQgKHRoZSANCiByb290LW1vc3QgZW50cnkgaW4gdGhlIHN1Yi10cmVlKSwgd2hlcmUgYWRt aW5pc3RyYXRpdmUgDQogZW50cmllcyAocGVyaGFwcyBpbmNsdWRpbmcgc3ViZW50cmllcywgb3Bl cmF0aW9uYWwgDQogYXR0cmlidXRlcywgb3IgYm90aCkgYXJlIGxvY2F0ZWQuICBBdXRvbm9tb3Vz IA0KIGFkbWluaXN0cmF0aXZlIGFyZWFzIGFyZSBkaXN0aW5jdCBwYXJ0aXRpb25zIG9mIHRoZSAN CiBkaXJlY3RvcnkgaW5mb3JtYXRpb24gdHJlZSB3aG9zZSBlbnRyaWVzIGFyZSBhbGwgDQogYWRt aW5pc3RlcmVkIGJ5IGEgc2luZ2xlIGFkbWluaXN0cmF0aXZlIGF1dGhvcml0eS4gIEVhY2ggDQog ZW50cnkgaW4gdGhlIGRpcmVjdG9yeSBpbmZvcm1hdGlvbiB0cmVlIGlzIGFkbWluaXN0ZXJlZCBi eSANCiBleGFjdGx5IG9uZSBhdXRvbm9tb3VzIGFkbWluaXN0cmF0aXZlIGF1dGhvcml0eS4gDQog IA0KCiBSZWVkICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBb UGFnZSAyXSANCiAgICAgICAgICAgICAgICAgICBFeHBpcmVzIE9jdG9iZXIgNiwgMjAwMSANCiAg DA0KCgogSU5URVJORVQtRFJBRlQgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICA2IEFw cmlsIDIwMDEgDQogICAgICAgICAgICAgICAgICAgICBMREFQIFN1YmVudHJ5IFNjaGVtYSANCgog VGhlcmUgbWF5IGJlIG1hbnkgYXNwZWN0cyBvZiBhZG1pbmlzdHJhdGlvbiBkZWZpbmVkIGJ5IHRo ZSANCiBkaXJlY3RvcnkgYW5kIG90aGVyIGFwcGxpY2F0aW9ucyBmb3Igc3BlY2lmaWMgcHVycG9z ZXMsIA0KIHN1Y2ggYXMgc3Vic2NoZW1hIGFkbWluaXN0cmF0aW9uIGFyZWFzLCBhY2Nlc3MgY29u dHJvbCANCiBhZG1pbmlzdHJhdGlvbiBhcmVhcywgY29sbGVjdGl2ZS1hdHRyaWJ1dGUgYWRtaW5p c3RyYXRpb24gDQogYXJlYXMsIGNvbnRleHQgZGVmYXVsdCBhZG1pbmlzdHJhdGl2ZSBhcmVhcywg YW5kIHNlcnZpY2UgDQogYWRtaW5pc3RyYXRpdmUgYXJlYXMuICBXaXRoaW4gYW4gYXV0b25vbW91 cyBhZG1pbmlzdHJhdGl2ZSANCiBhcmVhLCBzcGVjaWZpYyBhZG1pbmlzdHJhdGl2ZSBhcmVhcyBm b3IgdGhlc2UgKGFuZCBvdGhlcikgDQogZGlmZmVyZW50IGFzcGVjdHMgbWF5IG92ZXJsYXAgb25l IGFub3RoZXIuICAgDQogIA0KIFNwZWNpZmljIGFkbWluaXN0cmF0aXZlIGFyZWFzIG1heSBiZSBz dWItcGFydGl0aW9uZWQgYnkgdGhlIA0KIGFwcGxpY2F0aW9ucyBvciBzZXJ2aWNlcyB3aGljaCBk ZWZpbmUgdGhlbSB0byBmYWNpbGl0YXRlIA0KIGRlbGVnYXRpb24gb2YgYXV0aG9yaXR5IG9yIGZv ciBvdGhlciBwdXJwb3Nlcy4gIFRoYXQgbWVhbnMgDQogdGhhdCBhIHNpbmdsZSBlbnRyeSBpbiB0 aGUgZGlyZWN0b3J5IG1heSBiZSBwYXJ0IG9mIG1hbnkgDQogZGlmZmVyZW50IHNwZWNpZmljIGFk bWluaXN0cmF0aXZlIGFyZWFzLCBidXQgb25seSBiZSBwYXJ0IA0KIG9mIG9uZSBzcGVjaWZpYyBh ZG1pbmlzdHJhdGl2ZSBhcmVhIChvciBzdWItYXJlYSkgb2YgZWFjaCANCiBhc3BlY3Qgb2YgYWRt aW5pc3RyYXRpb24uIA0KICANCiBUaGUgW1g1MDFdIHN1YmVudHJ5IHNwZWNpZmljYXRpb24gb3B0 aW9uYWxseSB1c2VzIGEgDQogU3VidHJlZVNwZWNpZmljYXRpb24gdG8gaW5kaWNhdGUgYSBzdWJz ZXQgb2YgZW50cmllcyBpbiBhIA0KIHN1Yi10cmVlIHdpdGggd2hpY2ggdGhlIHN1YmVudHJ5IGlz IGNvbmNlcm5lZC4gIFdoZW4gdGhlIA0KIFN1YnRyZWVTcGVjaWZpY2F0aW9uIGlzIGVtcHR5IHRo ZSBzY29wZSBvZiB0aGUgW1g1MDFdIA0KIHN1YmVudHJ5IGlzIGltcGxpY2l0bHkgZGVmaW5lZCBi eSB0aGUgY29udGV4dCBpbiB3aGljaCBpdCANCiBvY2N1cnMuICAgDQoKIDQuMiBBbiBMREFQIEFk bWluaXN0cmF0aXZlIE1vZGVsIA0KCiBUaGUgYWRtaW5pc3RyYXRpdmUgbW9kZWwgZm9yIExEQVAg ZGVmaW5lZCBoZXJlIGlzIGEgDQogc2ltcGxpZmllZCB2ZXJzaW9uIG9mIHRoZSBvbmUgZGVzY3Jp YmVkIGluIFtYNTAxXSwgaW4gdGhhdCANCiB0aGUgc2NvcGUgZGVmaW5lZCBmb3IgdGhlIGxkYXBT dWJlbnRyeSBvYmplY3QgY2xhc3MgaXMgDQogbGltaXRlZC4gICANCiAgDQogVGhlIExEQVAgU3Vi ZW50cnkgZGVmaW5pdGlvbiBiZWxvdyBzcGVjaWZpY2FsbHkgZG9lcyBub3QgDQogaW5jbHVkZSBh IFN1YnRyZWVTcGVjaWZpY2F0aW9uLCBzbyBpdHMgc2NvcGUgaXMgZXhwbGljaXRseSANCiB0aGUg Y29tcGxldGUgc2V0IG9mIGVudHJpZXMgaW4gdGhlIHNwZWNpZmljIGFkbWluaXN0cmF0aXZlIA0K IGFyZWEgKG9yIHN1Yi1hcmVhKSBpbiB3aGljaCBpdCBvY2N1cnMuICBBbGwgYWRtaW5pc3RyYXRp dmUgDQogYXJlYXMgYXJlIGNvbnNpZGVyZWQgdG8gYmUgc3BlY2lmaWMgYWRtaW5pc3RyYXRpdmUg YXJlYXMgDQogd2l0aGluIGFuIGF1dG9ub21vdXMgYWRtaW5pc3RyYXRpdmUgYXJlYS4gICANCiAg DQogSWYgYSBzcGVjaWZpYyBhZG1pbmlzdHJhdGlvbiBhcmVhIGlzIG5vdCBwYXJ0aXRpb25lZCwg dGhlbiANCiBpdHMgZXh0ZW50IChvciBzY29wZSkgaXMgc2FpZCB0byBiZSB0aGF0IG9mIHRoZSBh dXRvbm9tb3VzIA0KIGFkbWluaXN0cmF0aXZlIGFyZWEgaW4gd2hpY2ggaXQgaXMgZGVmaW5lZC4g DQogIA0KIEFwcGxpY2F0aW9ucyBhbmQgc2VydmljZXMgd2hpY2ggZGVmaW5lIHNwZWNpZmljIA0K IGFkbWluaXN0cmF0aXZlIGFyZWFzIG11c3Qgc3BlY2lmeSB3aGV0aGVyIHRoZSBhcmVhcyBtYXkg YmUgDQogcGFydGl0aW9uZWQgb3Igbm90LiAgQnkgZGVmYXVsdCwgdGhlIHNjb3BlIG9mIExEQVAg DQogU3ViZW50cmllcyBpcyBsaW1pdGVkIHRvIHRoZSBzdWItYXJlYSBvZiB0aGUgcGFydGl0aW9u ZWQgDQogc3BlY2lmaWMgYWRtaW5pc3RyYXRpdmUgYXJlYSBpbiB3aGljaCB0aGV5IGFyZSBwcmVz ZW50LiAgDQoKCiBSZWVkICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICBbUGFnZSAzXSANCiAgICAgICAgICAgICAgICAgICBFeHBpcmVzIE9jdG9iZXIgNiwgMjAw MSANCiAgDA0KCgogSU5URVJORVQtRFJBRlQgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICA2IEFwcmlsIDIwMDEgDQogICAgICAgICAgICAgICAgICAgICBMREFQIFN1YmVudHJ5IFNjaGVt YSANCgogNSAgT2JqZWN0IENsYXNzIERlZmluaXRpb24gDQoKCiA1LjEgbGRhcFN1YkVudHJ5IENs YXNzIA0KCiAoIDIuMTYuODQwLjEuMTEzNzE5LjIuMTQyLjYuMS4xIE5BTUUgJ2xkYXBTdWJFbnRy eScgIA0KICAgIERFU0MgJ0xEQVAgU3ViZW50cnkgY2xhc3MsIHZlcnNpb24gMScgIA0KICAgICAg U1VQIHRvcCBTVFJVQ1RVUkFMICANCiAgICAgIE1BWSAoIGNuICkgKSAgDQoKIFRoZSBjbGFzcyBs ZGFwU3ViRW50cnkgaXMgaW50ZW5kZWQgdG8gYmUgdXNlZCBhcyBhIHN1cGVyLQ0KIGNsYXNzIHdo ZW4gZGVmaW5pbmcgb3RoZXIgc3RydWN0dXJhbCBjbGFzc2VzIHRvIGJlIHVzZWQgYXMgDQogTERB UCBTdWJlbnRyaWVzLCBhbmQgYXMgdGhlIHN0cnVjdHVyYWwgY2xhc3MgdG8gd2hpY2ggDQogQXV4 aWxpYXJ5IGNsYXNzZXMgbWF5IGJlIGFkZGVkIGZvciBhcHBsaWNhdGlvbiBzcGVjaWZpYyANCiBz dWJlbnRyeSBpbmZvcm1hdGlvbi4gIFdoZXJlIHBvc3NpYmxlLCB0aGUgdXNlIG9mIEF1eGlsaWFy eSANCiBjbGFzc2VzIHRvIGV4dGVuZCBMREFQIFN1YmVudHJpZXMgaXMgc3Ryb25nbHkgcHJlZmVy cmVkLiANCiAgDQogVGhlIHByZXNlbmNlIG9mIGxkYXBTdWJFbnRyeSBpbiB0aGUgbGlzdCBvZiBz dXBlci1jbGFzc2VzIA0KIG9mIGFuIGVudHJ5IGluIHRoZSBkaXJlY3RvcnkgbWFrZXMgdGhhdCBl bnRyeSBhbiBMREFQIA0KIFN1YmVudHJ5LiAgT2JqZWN0IGNsYXNzZXMgZGVyaXZlZCBmcm9tIGxk YXBTdWJFbnRyeSBhcmUgDQogdGhlbXNlbHZlcyBjb25zaWRlcmVkIGxkYXBTdWJFbnRyeSBjbGFz c2VzLCBmb3IgdGhlIHB1cnBvc2UgDQogb2YgdGhpcyBkaXNjdXNzaW9uLiANCgoKIDUuMS4xTmFt aW5nIGFuZCBTdHJ1Y3R1cmUgY29uc3RyYWludHMgDQoKIExEQVAgU3ViZW50cmllcyBNQVkgYmUg bmFtZWQgYnkgdGhlaXIgY29tbW9uTmFtZSBhdHRyaWJ1dGUgDQogW1JGQzIyNTFdLiAgT3RoZXIg bmFtaW5nIGF0dHJpYnV0ZXMgYXJlIGFsc28gcGVybWl0dGVkLiAgDQogRm9yIGNvbXBhdGliaWxp dHkgd2l0aCBbWDUwMV0sIHRoZSBjb21tb25OYW1lIGF0dHJpYnV0ZSBpcyANCiBvcHRpb25hbCAo W1g1MDFdIHJlcXVpcmVzIEVJVEhFUiBjbiBPUiBhIA0KIFN1YlRyZWVTcGVjaWZpY2F0aW9uKSwg YnV0IG5vdGUgdGhhdCBpbiB0aGUgYWJzZW5jZSBvZiBhbnkgDQogb3RoZXIgbmFtaW5nIGF0dHJp YnV0ZSwgYSBjbiBpcyByZXF1aXJlZCB0byBuYW1lIHRoZSBMREFQIA0KIFN1YmVudHJ5LiANCgog TERBUCBTdWJlbnRyaWVzIE1BWSBiZSBjb250YWluZXJzLCB1bmxpa2UgdGhlaXIgW1g1MDFdIA0K IGNvdW50ZXJwYXJ0cy4gIFRoaXMgaXMgYSBkZXBhcnR1cmUgZnJvbSBbWDUwMV0sIGJ1dCBpcyAN CiBjb25zaWRlcmVkIGFuIGltcG9ydGFudCBleHRlbnNpb24gdG8gaW5jcmVhc2UgdGhlIGFiaWxp dHkgDQogdG8gbW9yZSBlYXNpbHkgY29uc3RydWN0IHJpY2hlciAoaS5lLiwgbW9yZSBjb21wbGV4 KSBwb2xpY3kgDQogcmVwcmVzZW50YXRpb25zIGluIHRoZSBkaXJlY3RvcnkgdXNpbmcgTERBUCBT dWJlbnRyaWVzLiAgDQogVXNpbmcgTERBUCBTdWJlbnRyeSBjb250YWluZXJzIHRvIGhvbGQgZW50 cmllcyB0aGF0IGFyZSBub3QgDQogdGhlbXNlbHZlcyBMREFQIFN1YmVudHJpZXMgaXMgcHJvaGli aXRlZCwgYXMgdGhhdCB3b3VsZCANCiBzaWduaWZpY2FudGx5IGFmZmVjdCBjb21wYXRpYmlsaXR5 IHdpdGggW1g1MDFdIHNlcnZpY2VzLiANCgogTERBUCBTdWJlbnRyaWVzIE1BWSBiZSBjb250YWlu ZWQgYnksIGFuZCB3aWxsIHVzdWFsbHkgYmUgDQogbG9jYXRlZCBpbiB0aGUgZGlyZWN0b3J5IGlu Zm9ybWF0aW9uIHRyZWUgaW1tZWRpYXRlbHkgDQogc3Vib3JkaW5hdGUgdG8gdGhlaXIgYWRtaW5p c3RyYXRpdmUgcG9pbnRzLiAgTERBUCANCiBTdWJlbnRyaWVzIE1BWSBhbHNvIGJlIGNvbnRhaW5l ZCBieSBvdGhlciBMREFQIFN1YmVudHJpZXMgDQogKHRoZSB3YXkgb3JnYW5pemF0aW9uYWwgdW5p dHMgbWF5IGJlIGNvbnRhaW5lZCBieSBvdGhlciANCgogUmVlZCAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgW1BhZ2UgNF0gDQogICAgICAgICAgICAgICAgICAg RXhwaXJlcyBPY3RvYmVyIDYsIDIwMDEgDQogIAwNCgoKIElOVEVSTkVULURSQUZUICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgNiBBcHJpbCAyMDAxIA0KICAgICAgICAgICAgICAgICAg ICAgTERBUCBTdWJlbnRyeSBTY2hlbWEgDQoKIG9yZ2FuaXphdGlvbmFsIHVuaXRzKS4gIERlZXAg bmVzdGluZyBvZiBMREFQIFN1YmVudHJpZXMgYXJlIA0KIGRpc2NvdXJhZ2VkLCBidXQgbm90IHBy b2hpYml0ZWQuICBEZXZlbG9wZXJzIGFyZSB3YXJuZWQgDQogdGhhdCBkZWVwIG5lc3Rpbmcgb2Yg TERBUCBTdWJlbnRyaWVzIG1heSBub3QgYmUgc3VwcG9ydGVkIA0KIGJ5IGFsbCAob3IgaW5kZWVk LCBieSBhbnkpIExEQVAgc2VydmVyIGltcGxlbWVudGF0aW9ucy4gIA0KIEZvciBjb21wYXRpYmls aXR5IHdpdGggW1g1MDFdLCBhIHN1Yi10cmVlIG1hZGUgdXAgb2YgYSANCiBjb2xsZWN0aW9uIG9m IExEQVAgU3ViZW50cmllcyBtYXkgYmUgbWFwcGVkIG9udG8gYSBzaW5nbGUgDQogKHBvc3NpYmx5 IHZlcnkgY29tcGxleCkgW1g1MDFdIHN1YmVudHJ5LCBhbmQgdmljZSB2ZXJzYS4gDQoKCiA1LjEu MlNjb3BlIFJ1bGVzIA0KCiBUaGUgZGVmYXVsdCBzY29wZSBvZiBhbiBMREFQIFN1YmVudHJ5IGlz IGxpbWl0ZWQgdG8gdGhlIA0KIHNwZWNpZmljIGFkbWluaXN0cmF0aXZlIGFyZWEgKG9yIHN1Yi1h cmVhKSBpbiB3aGljaCBpdCBpcyANCiBkZWZpbmVkLiAgU3BlY2lmaWNhbGx5LCB0aGUgc3VidHJl ZSBvZiB0aGUgZGlyZWN0b3J5IA0KIG5hbWVzcGFjZSBiYXNlZCBhdCB0aGUgYWRtaW5pc3RyYXRp dmUgcG9pbnQgbW9zdCANCiBpbW1lZGlhdGVseSBzdXBlcmlvciB0byB0aGUgTERBUCBTdWJlbnRy eSwgZG93biB0byBidXQgbm90IA0KIGluY2x1ZGluZyBhbnkgc3Vib3JkaW5hdGUgYWRtaW5pc3Ry YXRpdmUgcG9pbnRzIG9yIGFyZWFzIG9mIA0KIHRoZSBzYW1lIGFzcGVjdCBvciB0eXBlLiAgUG9s aWN5IGRlZmluZWQgaW4gYW4gTERBUCANCiBTdWJlbnRyeSBpcyBub3QgaW5oZXJpdGFibGUsIHVu bGVzcyBzdWNoIGluaGVyaXRhbmNlIGlzIA0KIGV4cGxpY2l0bHkgZGVmaW5lZCBieSBhbiBhcHBs aWNhdGlvbi1zcGVjaWZpYyBwb2xpY3kuIA0KCiBJZiBhbiBMREFQIFN1YmVudHJ5IGlzIHN1Ym9y ZGluYXRlIHRvIGFub3RoZXIgTERBUCANCiBTdWJlbnRyeSwgaXQgdGFrZXMgdGhlIHNhbWUgZGVm YXVsdCBzY29wZSBhcyB0aGUgcGFyZW50IA0KIExEQVAgU3ViZW50cnkuIA0KCiBBcHBsaWNhdGlv bnMgTUFZIGRlZmluZSBhbHRlcm5hdGl2ZSBzY29wZSBzZW1hbnRpY3MgZm9yIA0KIGNsYXNzZXMg dGhleSBkZWZpbmUgd2hpY2ggYXJlIGRlcml2ZWQgZnJvbSB0aGUgbGRhcFN1YkVudHJ5IA0KIGNs YXNzLiBUaGlzIG1lYW5zIHRoYXQgYW4gYXBwbGljYXRpb24gY2FuIGRlcml2ZSBhIG5ldyANCiBj bGFzcyBmcm9tIHRoZSBsZGFwU3ViRW50cnkgY2xhc3MgYW5kIGFkZCBhbiBhdHRyaWJ1dGUsIA0K IGxpa2UgU3ViVHJlZVNwZWNpZmljYXRpb24gW1g1MDFdIHRvIGRlZmluZSBhIG5ldyBzY29wZSBy dWxlIA0KIGZvciB0aGF0IGFwcGxpY2F0aW9uIHRvIHVzZS4gDQoKIEFwcGxpY2F0aW9ucyBNVVNU IE5PVCBkZWZpbmUgYWx0ZXJuYXRpdmUgc2NvcGUgcnVsZXMgZm9yIA0KIGF1eGlsaWFyeSBjbGFz c2VzIHVzZWQgdG8gZGVjb3JhdGUgZW50cmllcyBvZiB0aGUgDQogbGRhcFN1YkVudHJ5IGNsYXNz LiAgVGhpcyByZXN0cmljdGlvbiBpcyByZXF1aXJlZCB0byBhdm9pZCANCiBoYXZpbmcgY29uZmxp Y3Rpbmcgb3IgY29udHJhZGljdG9yeSBzY29wZSBkZWZpbml0aW9ucyANCiBhcHBsaWVkIGJ5IGRp ZmZlcmVudCBhcHBsaWNhdGlvbnMgdG8gdGhlIHNhbWUgTERBUCANCiBTdWJlbnRyeS4gDQoKCgoK CgoKCgoKCiBSZWVkICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICBbUGFnZSA1XSANCiAgICAgICAgICAgICAgICAgICBFeHBpcmVzIE9jdG9iZXIgNiwgMjAwMSAN CiAgDA0KCgogSU5URVJORVQtRFJBRlQgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICA2 IEFwcmlsIDIwMDEgDQogICAgICAgICAgICAgICAgICAgICBMREFQIFN1YmVudHJ5IFNjaGVtYSAN CgogNiAgVmlzaWJpbGl0eSBDb250cm9sIA0KCgogNi4xIGxkYXBTdWJlbnRyaWVzQ29udHJvbCAN CgogVGhpcyBjb250cm9sIGlzIGluY2x1ZGVkIGluIHRoZSBzZWFyY2hSZXF1ZXN0IG1lc3NhZ2Ug YXMgDQogcGFydCBvZiB0aGUgY29udHJvbHMgZmllbGQgb2YgdGhlIExEQVBNZXNzYWdlLCBhcyBk ZWZpbmVkIA0KIGluIFNlY3Rpb24gNC4xLjEyIG9mIFtSRkMyMjUxXS4gDQoKIFRoZSBjb250cm9s VHlwZSBpcyBzZXQgdG8gIjEuMy42LjEuNC4xLjc2MjguNS4xMDEuMSIuIFRoZSANCiBjcml0aWNh bGl0eSBNQVkgYmUgc2V0IHRvIGVpdGhlciBUUlVFIG9yIEZBTFNFLiAgVGhlIA0KIGNvbnRyb2xW YWx1ZSBpcyBhYnNlbnQuICAgDQoKIFRoZXJlIGlzIG5vIGNvcnJlc3BvbmRpbmcgcmVzcG9uc2Ug Y29udHJvbCBkZWZpbmVkLiANCgogTERBUCBzZXJ2ZXJzIHRoYXQgc3VwcG9ydCB0aGlzIGNvbnRy b2wgTVVTVCB0cmVhdCBMREFQIA0KIFN1YmVudHJpZXMgYXMgIm9wZXJhdGlvbmFsIG9iamVjdHMi IGluIG11Y2ggdGhlIHNhbWUgd2F5IA0KIHRoYXQgIm9wZXJhdGlvbmFsIGF0dHJpYnV0ZXMiIGFy ZSBub3QgcmV0dXJuZWQgaW4gc2VhcmNoIA0KIHJlc3VsdHMgYW5kIFtYNTExXSByZWFkIG9wZXJh dGlvbnMgd2hlbiBvbmx5IHVzZXIgDQogYXR0cmlidXRlcyBhcmUgcmVxdWVzdGVkLiAgDQoKIEVu dHJpZXMgd2hpY2ggYXJlIG5vdCBMREFQIFN1YmVudHJpZXMgbWF5IGJlIHJlZmVyZW5jZWQgaW4g DQogdGhlIGJhc2Ugb2JqZWN0IG9mIHNlYXJjaCBvcGVyYXRpb25zIHdoZXJlIHRoZSANCiBsZGFw U3ViZW50cmllc0NvbnRyb2wgaXMgcHJlc2VudCBpbiB0aGUgcmVxdWVzdC4gICANCgogSW4gdGhl IGFic2VuY2Ugb2YgdGhlIExEQVAgU3ViZW50cmllcyB2aXNpYmlsaXR5IGNvbnRyb2wsIA0KIHN1 YmVudHJpZXMgYXJlIG5vdCB2aXNpYmxlIHRvIHNlYXJjaCBvcGVyYXRpb25zIFVOTEVTUyB0aGUg DQogdGFyZ2V0L2Jhc2Ugb2YgdGhlIG9wZXJhdGlvbiBpcyBhIHN1YmVudHJ5LiANCiAgDQogSW4g cHJlc2VuY2Ugb2YgdGhlIHN1YmVudHJ5IHZpc2liaWxpdHkgY29udHJvbCwgT05MWSANCiBzdWJl bnRyaWVzIGFyZSB2aXNpYmxlLiAgIA0KCiA2LjEuMU90aGVyIExEQVAgb3BlcmF0aW9ucyANCgog VGhlIGxkYXBTdWJlbnRyaWVzQ29udHJvbCBpcyBub3QgZGVmaW5lZCBmb3IgYW55IExEQVAgDQog b3BlcmF0aW9uIG90aGVyIHRoYW4gU2VhcmNoLiAgSG93ZXZlciwgYW4gTERBUHYzIEV4dGVuc2lv biANCiBNQVkgZGVmaW5lIGEgdXNlIG9mIHRoaXMgY29udHJvbCB3aXRoIHRoYXQgZXh0ZW5zaW9u IGFzIA0KIGxvbmcgYXMgc3VjaCB1c2UgaXMgY29uc2lzdGVudCB3aXRoIHRoaXMgc3BlY2lmaWNh dGlvbi4gDQoKCiA2LjEuMkNvcnJlc3BvbmRlbmNlIHRvIFtYNTExXSANCgogSW4gcHJlc2VuY2Ug b2YgdGhlIHZpc2liaWxpdHkgY29udHJvbCwgdGhlIHNlbWFudGljcyBvZiB0aGUgDQogTERBUFN1 YmVudHJpZXNDb250cm9sIGFyZSBpbiBhY2NvcmRhbmNlIHdpdGggdGhlIGluZGljYXRpb24gDQog b2YgdGhlIFtYNTExXSBjb21tb24gYXJndW1lbnQgc2VydmljZUNvbnRyb2xzIG9wdGlvbnMgDQog c3ViZW50cmllcyBiZWluZyBzZXQuIA0KICANCgoKIFJlZWQgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgIFtQYWdlIDZdIA0KICAgICAgICAgICAgICAgICAgIEV4 cGlyZXMgT2N0b2JlciA2LCAyMDAxIA0KICAMDQoKCiBJTlRFUk5FVC1EUkFGVCAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgIDYgQXByaWwgMjAwMSANCiAgICAgICAgICAgICAgICAgICAg IExEQVAgU3ViZW50cnkgU2NoZW1hIA0KCiBJbiBbWDUxMV0gYSBTZXJ2aWNlQ29udHJvbCBvcHRp b24gaXMgdXNlZCB0byBnb3Zlcm4gdGhlIA0KIHZpc2liaWxpdHkgb2YgW1g1MDFdIHN1YmVudHJp ZXMuICBUaGUgc3ViZW50cnkgDQogU2VydmljZUNvbnRyb2wgb3B0aW9uIGlzIGEgc3BlY2lmaWMg Yml0IG9mIGEgYml0c3RyaW5nIA0KIHRoYXQsIHdoZW4gc2V0IGluIHRoZSBjb21tb24gYXJndW1l bnRzIG9mIGFuIFtYNTExXSBTZWFyY2ggDQogb3IgTGlzdCBvcGVyYXRpb24sIGluZGljYXRlcyB0 aGF0IHRoZSBvcGVyYXRpb24gaXMgdG8gDQogYWNjZXNzIE9OTFkgdGhlIHN1YmVudHJpZXMgZm91 bmQgaW4gdGhlIGNvbnRleHQgb2YgdGhlIGxpc3QgDQogb3Igc2VhcmNoLiAgSW4gZmFjdCwgbm9y bWFsIGVudHJpZXMgYXJlIGV4cGxpY2l0bHkgTk9UIA0KIHJldHVybmVkIGluIHRoZSByZXN1bHQg b2YgYSBsaXN0IG9yIHNlYXJjaCBvcGVyYXRpb24gd2hlbiANCiB0aGUgW1g1MTFdIHN1YmVudHJp ZXMgU2VydmljZUNvbnRyb2wgaXMgc2V0LiAgIA0KCiBFbnRyaWVzIHdoaWNoIGFyZSBub3Qgc3Vi ZW50cmllcyBtYXkgYmUgdXNlZCBpbiB0aGUgYmFzZSANCiBvYmplY3Qgb2YgbGlzdCBhbmQgc2Vh cmNoIG9wZXJhdGlvbnMgd2hlcmUgdGhlIHN1YmVudHJpZXMgDQogY29udHJvbCBpcyBzZXQuICAg DQoKIFRoZSBbWDUxMV0gc3ViZW50cmllcyBTZXJ2aWNlQ29udHJvbCBoYXMgbm8gbWVhbmluZyBm b3IgDQogb3BlcmF0aW9ucyBvdGhlciB0aGFuIFNlYXJjaCBhbmQgTGlzdCAoaS5lLiwgaXQgaXMg bm90IA0KIGRlZmluZWQgZm9yIFJlYWQsIE1vZGlmeSwgRGVsZXRlLCBldGMuKS4gDQoKCgogNyAg U2VjdXJpdHkgQ29uc2lkZXJhdGlvbnMgDQoKIExEQVAgU3ViZW50cmllcyB3aWxsIGZyZXF1ZW50 bHkgYmUgdXNlZCB0byBob2xkIGRhdGEgd2hpY2ggDQogcmVmbGVjdHMgZWl0aGVyIHRoZSBhY3R1 YWwgb3IgaW50ZW5kZWQgYmVoYXZpb3Igb2YgdGhlIA0KIGRpcmVjdG9yeSBzZXJ2aWNlLiAgQXMg c3VjaCwgcGVybWlzc2lvbiB0byByZWFkIHN1Y2ggDQogZW50cmllcyBNQVkgbmVlZCB0byBiZSBy ZXN0cmljdGVkIHRvIGF1dGhvcml6ZWQgdXNlcnMuICANCiBNb3JlIGltcG9ydGFudGx5LCBpZiBh IGRpcmVjdG9yeSBzZXJ2aWNlIHRyZWF0cyB0aGUgDQogaW5mb3JtYXRpb24gaW4gYW4gTERBUCBT dWJlbnRyeSBhcyB0aGUgYXV0aG9yaXRhdGl2ZSBzb3VyY2UgDQogb2YgcG9saWN5IHRvIGJlIHVz ZWQgdG8gY29udHJvbCB0aGUgYmVoYXZpb3Igb2YgdGhlIA0KIGRpcmVjdG9yeSwgdGhlbiBwZXJt aXNzaW9uIHRvIGNyZWF0ZSwgbW9kaWZ5LCBvciBkZWxldGUgDQogc3VjaCBlbnRyaWVzIE1VU1Qg YmUgY2FyZWZ1bGx5IHJlc3RyaWN0ZWQgdG8gYXV0aG9yaXplZCANCiBhZG1pbmlzdHJhdG9ycy4g DQoKCgogOCAgUmVmZXJlbmNlcyANCgogW1JGQzIxMTldIFMuIEJyYWRuZXIsICJLZXkgd29yZHMg Zm9yIHVzZSBpbiBSRkNzIHRvIA0KIEluZGljYXRlIFJlcXVpcmVtZW50IExldmVscyIsIFJGQyAy MTE5LCBNYXJjaCAxOTk3IA0KCiBbUkZDMjI1MV0gUy4gS2lsbGUsIE0uIFdhaGwsIGFuZCBULiBI b3dlcywgIkxpZ2h0d2VpZ2h0IA0KIERpcmVjdG9yeSBBY2Nlc3MgUHJvdG9jb2wgKHYzKSIsIFJG QyAyMjUxLCBEZWNlbWJlciAxOTk3IA0KCiBbWDUwMV0gSVRVLVQgUmVjLiBYLjUwMSwgIlRoZSBE aXJlY3Rvcnk6IE1vZGVscyIsIDE5OTMgYW5kIA0KIHN1YnNlcXVlbnQgdmVyc2lvbnMgDQoKIFtY NTAxXSBJVFUtVCBSZWMuIFguNTExLCAiVGhlIERpcmVjdG9yeTogQWJzdHJhY3QgU2VydmljZSAN CiBEZWZpbml0aW9uIiwgMTk5MyBhbmQgc3Vic2VxdWVudCB2ZXJzaW9ucyANCgogUmVlZCAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgW1BhZ2UgN10gDQogICAg ICAgICAgICAgICAgICAgRXhwaXJlcyBPY3RvYmVyIDYsIDIwMDEgDQogIAwNCgoKIElOVEVSTkVU LURSQUZUICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgNiBBcHJpbCAyMDAxIA0KICAg ICAgICAgICAgICAgICAgICAgTERBUCBTdWJlbnRyeSBTY2hlbWEgDQoKIDkgIENvcHlyaWdodCBO b3RpY2UgDQoKIENvcHlyaWdodCAoQykgVGhlIEludGVybmV0IFNvY2lldHkgKDIwMDApLiBBbGwg UmlnaHRzIA0KIFJlc2VydmVkLiAgDQogIA0KIFRoaXMgZG9jdW1lbnQgYW5kIHRyYW5zbGF0aW9u cyBvZiBpdCBtYXkgYmUgY29waWVkIGFuZCANCiBmdXJuaXNoZWQgdG8gb3RoZXJzLCBhbmQgZGVy aXZhdGl2ZSB3b3JrcyB0aGF0IGNvbW1lbnQgb24gDQogb3Igb3RoZXJ3aXNlIGV4cGxhaW4gaXQg b3IgYXNzaXN0IGluIGl0cyBpbXBsZW1lbnRhdGlvbiBtYXkgDQogYmUgcHJlcGFyZWQsIGNvcGll ZCwgcHVibGlzaGVkIGFuZCBkaXN0cmlidXRlZCwgaW4gd2hvbGUgb3IgDQogaW4gcGFydCwgd2l0 aG91dCByZXN0cmljdGlvbiBvZiBhbnkga2luZCwgcHJvdmlkZWQgdGhhdCB0aGUgDQogYWJvdmUg Y29weXJpZ2h0IG5vdGljZSBhbmQgdGhpcyBwYXJhZ3JhcGggYXJlIGluY2x1ZGVkIG9uIA0KIGFs bCBzdWNoIGNvcGllcyBhbmQgZGVyaXZhdGl2ZSB3b3Jrcy4gSG93ZXZlciwgdGhpcyANCiBkb2N1 bWVudCBpdHNlbGYgbWF5IG5vdCBiZSBtb2RpZmllZCBpbiBhbnkgd2F5LCBzdWNoIGFzIGJ5IA0K IHJlbW92aW5nIHRoZSBjb3B5cmlnaHQgbm90aWNlIG9yIHJlZmVyZW5jZXMgdG8gdGhlIEludGVy bmV0IA0KIFNvY2lldHkgb3Igb3RoZXIgSW50ZXJuZXQgb3JnYW5pemF0aW9ucywgZXhjZXB0IGFz IG5lZWRlZCANCiBmb3IgdGhlIHB1cnBvc2Ugb2YgZGV2ZWxvcGluZyBJbnRlcm5ldCBzdGFuZGFy ZHMgaW4gd2hpY2ggDQogY2FzZSB0aGUgcHJvY2VkdXJlcyBmb3IgY29weXJpZ2h0cyBkZWZpbmVk IGluIHRoZSBJbnRlcm5ldCANCiBTdGFuZGFyZHMgcHJvY2VzcyBtdXN0IGJlIGZvbGxvd2VkLCBv ciBhcyByZXF1aXJlZCB0byANCiB0cmFuc2xhdGUgaXQgaW50byBsYW5ndWFnZXMgb3RoZXIgdGhh biBFbmdsaXNoLiANCiAgDQogVGhlIGxpbWl0ZWQgcGVybWlzc2lvbnMgZ3JhbnRlZCBhYm92ZSBh cmUgcGVycGV0dWFsIGFuZCANCiB3aWxsIG5vdCBiZSByZXZva2VkIGJ5IHRoZSBJbnRlcm5ldCBT b2NpZXR5IG9yIGl0cyANCiBzdWNjZXNzb3JzIG9yIGFzc2lnbnMuIA0KICANCiBUaGlzIGRvY3Vt ZW50IGFuZCB0aGUgaW5mb3JtYXRpb24gY29udGFpbmVkIGhlcmVpbiBpcyANCiBwcm92aWRlZCBv biBhbiAiQVMgSVMiIGJhc2lzIGFuZCBUSEUgSU5URVJORVQgU09DSUVUWSBBTkQgDQogVEhFIElO VEVSTkVUIEVOR0lORUVSSU5HIFRBU0sgRk9SQ0UgRElTQ0xBSU1TIEFMTCANCiBXQVJSQU5USUVT LCBFWFBSRVNTIE9SIElNUExJRUQsIElOQ0xVRElORyBCVVQgTk9UIExJTUlURUQgDQogVE8gQU5Z IFdBUlJBTlRZIFRIQVQgVEhFIFVTRSBPRiBUSEUgSU5GT1JNQVRJT04gSEVSRUlOIFdJTEwgDQog Tk9UIElORlJJTkdFIEFOWSBSSUdIVFMgT1IgQU5ZIElNUExJRUQgV0FSUkFOVElFUyBPRiANCiBN RVJDSEFOVEFCSUxJVFkgT1IgRklUTkVTUyBGT1IgQSBQQVJUSUNVTEFSIFBVUlBPU0UuIiANCgoK IDEwIEFja25vd2xlZGdlbWVudHMgDQoKIFRoZSB1dGlsaXR5IG9mIHN1YkVudHJ5IG9iamVjdCBj bGFzcyB3YXMgb3JpZ2luYWxseSANCiBzdWdnZXN0ZWQgYXMgYSBtZWFucyB0byBzdG9yZSBSZXBs aWNhIGFuZCBSZXBsaWNhdGlvbiANCiBBZ3JlZW1lbnQgaW5mb3JtYXRpb24gd2l0aCBhIHRoZSBs dWNpZCBleHBsYW5hdGlvbiBieSBNYXJrIA0KIFdhaGwsICh0aGVuIG9mIElubm9zb2Z0KSwgb2Yg aG93IHRoZXkgY291bGQgYmUgdXNlZCBhbmQgDQogZXh0ZW5kZWQuIA0KICANCiBUaGUgSUVURiB0 YWtlcyBubyBwb3NpdGlvbiByZWdhcmRpbmcgdGhlIHZhbGlkaXR5IG9yIHNjb3BlIA0KIG9mIGFu eSBpbnRlbGxlY3R1YWwgcHJvcGVydHkgb3Igb3RoZXIgcmlnaHRzIHRoYXQgbWlnaHQgYmUgDQog Y2xhaW1lZCB0byBwZXJ0YWluIHRvIHRoZSBpbXBsZW1lbnRhdGlvbiBvciB1c2Ugb2YgdGhlIA0K IHRlY2hub2xvZ3kgZGVzY3JpYmVkIGluIHRoaXMgZG9jdW1lbnQgb3IgdGhlIGV4dGVudCB0byAN CiB3aGljaCBhbnkgbGljZW5zZSB1bmRlciBzdWNoIHJpZ2h0cyBtaWdodCBvciBtaWdodCBub3Qg YmUgDQogYXZhaWxhYmxlOyBuZWl0aGVyIGRvZXMgaXQgcmVwcmVzZW50IHRoYXQgaXQgaGFzIG1h ZGUgYW55IA0KIGVmZm9ydCB0byBpZGVudGlmeSBhbnkgc3VjaCByaWdodHMuIEluZm9ybWF0aW9u IG9uIHRoZSANCgogUmVlZCAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgW1BhZ2UgOF0gDQogICAgICAgICAgICAgICAgICAgRXhwaXJlcyBPY3RvYmVyIDYsIDIw MDEgDQogIAwNCgoKIElOVEVSTkVULURSQUZUICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgNiBBcHJpbCAyMDAxIA0KICAgICAgICAgICAgICAgICAgICAgTERBUCBTdWJlbnRyeSBTY2hl bWEgDQoKIElFVEYncyBwcm9jZWR1cmVzIHdpdGggcmVzcGVjdCB0byByaWdodHMgaW4gc3RhbmRh cmRzLXRyYWNrIA0KIGFuZCBzdGFuZGFyZHMtcmVsYXRlZCBkb2N1bWVudGF0aW9uIGNhbiBiZSBm b3VuZCBpbiBCQ1AtMTEuIA0KIENvcGllcyBvZiBjbGFpbXMgb2YgcmlnaHRzIG1hZGUgYXZhaWxh YmxlIGZvciBwdWJsaWNhdGlvbiANCiBhbmQgYW55IGFzc3VyYW5jZXMgb2YgbGljZW5zZXMgdG8g YmUgbWFkZSBhdmFpbGFibGUsIG9yIHRoZSANCiByZXN1bHQgb2YgYW4gYXR0ZW1wdCBtYWRlIHRv IG9idGFpbiBhIGdlbmVyYWwgbGljZW5zZSBvciANCiBwZXJtaXNzaW9uIGZvciB0aGUgdXNlIG9m IHN1Y2ggcHJvcHJpZXRhcnkgcmlnaHRzIGJ5IA0KIGltcGxlbWVudGVycyBvciB1c2VycyBvZiB0 aGlzIHNwZWNpZmljYXRpb24gY2FuIGJlIG9idGFpbmVkIA0KIGZyb20gdGhlIElFVEYgU2VjcmV0 YXJpYXQuIA0KICANCiBUaGUgSUVURiBpbnZpdGVzIGFueSBpbnRlcmVzdGVkIHBhcnR5IHRvIGJy aW5nIHRvIGl0cyANCiBhdHRlbnRpb24gYW55IGNvcHlyaWdodHMsIHBhdGVudHMgb3IgcGF0ZW50 IGFwcGxpY2F0aW9ucywgDQogb3Igb3RoZXIgcHJvcHJpZXRhcnkgcmlnaHRzIHdoaWNoIG1heSBj b3ZlciB0ZWNobm9sb2d5IHRoYXQgDQogbWF5IGJlIHJlcXVpcmVkIHRvIHByYWN0aWNlIHRoaXMg c3RhbmRhcmQuIFBsZWFzZSBhZGRyZXNzIA0KIHRoZSBpbmZvcm1hdGlvbiB0byB0aGUgSUVURiBF eGVjdXRpdmUgRGlyZWN0b3IuIA0KCgogMTEgQXV0aG9yJ3MgQWRkcmVzcyANCgogICAgICBFZHdh cmRzIEUuIFJlZWQgDQogICAgICBSZWVkLU1hdHRoZXdzLCBJbmMuIA0KICAgICAgMTA2NCBFIDE0 MCBOb3J0aCANCiAgICAgIExpbmRvbiwgVVQgIDg0MDQyIA0KICAgICAgVVNBIA0KICAgICAgRS1t YWlsOiBlZXJAb25jYWxsZGJhLmNvbSAgDQogICAgICAgDQogICAgICBMRFVQIE1haWxpbmcgTGlz dDogaWV0Zi1sZHVwQGltYy5vcmcgIA0KICAgICAgTERBUEVYVCBNYWlsaW5nIExpc3Q6IGlldGYt bGRhcGV4dEBuZXRzY2FwZS5jb20gDQoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKIFJlZWQgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIFtQYWdlIDldIA0KICAgICAg ICAgICAgICAgICAgIEV4cGlyZXMgT2N0b2JlciA2LCAyMDAxIA0KICAM --=_A7FC5DDB.FE9FF288-- From owner-ietf-ldup@mail.imc.org Sat Apr 7 02:41:48 2001 Received: from above.proper.com ([208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id CAA11797 for ; Sat, 7 Apr 2001 02:41:48 -0400 (EDT) Received: by above.proper.com (8.9.3/8.9.3) id XAA24493 for ietf-ldup-bks; Fri, 6 Apr 2001 23:11:43 -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 XAA24479 for ; Fri, 6 Apr 2001 23:11:41 -0700 (PDT) Received: from gypsy.OpenLDAP.org (root@router.boolean.net [198.144.206.49]) by pretender.boolean.net (8.11.1/8.11.1/Boolean/Hub) with ESMTP id f376E5D22156 for ; Sat, 7 Apr 2001 06:14:05 GMT (envelope-from Kurt@OpenLDAP.org) Message-Id: <5.0.2.1.0.20010406204524.01e696a0@127.0.0.1> X-Sender: guru@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 5.0.2 Date: Fri, 06 Apr 2001 23:14:03 -0700 To: ietf-ldup@imc.org From: "Kurt D. Zeilenga" Subject: naming context definition 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: X.501(93), Section 17, excerpts: naming context: A subtree of entries held in a single master DSA. A naming context is a subtree of the DIT, all entries of which have a common administrative authority and are held in the same master DSA. Note: The DIT is therefore partitioned into disjoint naming contexts, each under the administrative authority of a single master DSA. It seem to me that the definition of namingContext makes little sense in the face of multiple master replication. Consider the following: A DIT which consists of two adjacent subtrees of entries A and B where A is superior to B. C refers to the set of entries comprising A and B. Three servers configured as follows: Server 1: masters A Server 2: masters B Server 3: masters C Does the DIT consist of one or two naming contexts? There is no right or wrong answer here... but there is need for the LDUP specification to provide an answer. Kurt From owner-ietf-ldup@mail.imc.org Sat Apr 7 05:57:24 2001 Received: from above.proper.com ([208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id FAA12453 for ; Sat, 7 Apr 2001 05:57:24 -0400 (EDT) Received: (from majordomo@localhost) by above.proper.com (8.9.3/8.9.3) id CAA21934 for ietf-ldup-bks; Sat, 7 Apr 2001 02:25:16 -0700 (PDT) Received: from ns.oncalldba.com ([66.1.184.87]) by above.proper.com (8.9.3/8.9.3) with ESMTP id CAA21930 for ; Sat, 7 Apr 2001 02:25:14 -0700 (PDT) Received: from reed.oncalldba.com (reed.OnCallDBA.COM [192.168.1.3]) by ns.oncalldba.com (8.11.0/8.8.7) with SMTP id f379OZA03569 for ; Sat, 7 Apr 2001 03:24:35 -0600 Received: from RMINC_DOM-Message_Server by reed.oncalldba.com with Novell_GroupWise; Sat, 07 Apr 2001 02:55:51 -0600 Message-Id: X-Mailer: Novell GroupWise Internet Agent 5.5.2.1 Date: Sat, 07 Apr 2001 02:55:46 -0600 From: "Ed Reed" To: , Subject: Re: naming context definition Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Disposition: inline Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id CAA21931 Sender: owner-ietf-ldup@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 8bit Yeah - I've wondered what naming contexts are to replication areas, or replication areas are to naming contexts, once I figured out what the formal definition of naming contexts was. The conflict is in the phrase "...and are held in the same master DSA". X.500(93) is explicitly single master, so there's no way that both server 1 and 3 in your example could be "master" replicas. But, of course, we're dealing with multi-master, here, so both servers 1 and 3 hold a master replica of the A partition of the DIT, and both servers 2 and 3 hold a master replica of the B partition of the DIT. In this world, I've never appreciated what sense it makes to talk about server 3 holding a naming context C which is the union of partitions A and B. It makes more sense to me to just say that server 3 holds A and B replication areas. It strikes me that if there's a conflict, it's likely to be that you would expect that naming context C would have subentries that govern the behavior in C, i.e., both A and B partitions. But, we're saying (in the LDAP Subentry draft) that there's no inheritance...so any subentries you'd want to affect both A and B need to be separately asserted in each, so that server 1 and server 2 unambiguously have all their subentry information without server 2 being dependent on either server 1 or 3 for the DIT partition A subentries. So, while it may be interesting that server 3 holds naming context C which is the union of A and B, that information is of little interest or value to the replication system, or to clients using the replicaSubentry information to navigate among servers to answer questions about where what data are located (ie, to generate referrals or to perform chaining). Knowing that both server 1 and 3 hold naming contexts rooted at the same administrative point (A) is nice, but unless you also know whether the subordinate (b) DIT is also present, you'll just have to blindly pick one to continue your resolve name operation. If, instead, you know that 1 holds A but 3 holds both A and B, then you may choose to choose server 3 instead of server 1 to direct your chained or referred operation, since 3 will not have to refer/chain you again should you need B to answer your query. Knowledge of where data are can be useful in such cases, and the more you know about the topology the better informed your decisions will be (if the operation against A is a single container or single entry search, then either server 1 or 3 will do, but if it is an unconstrained subtree search, 3 is by far a better choice). So - what does LDUP need to do or say? Ed ================= Ed Reed Reed-Matthews, Inc. +1 801 796 7065 http://www.Reed-Matthews.COM >>> "Kurt D. Zeilenga" 04/07/01 12:14AM >>> X.501(93), Section 17, excerpts: naming context: A subtree of entries held in a single master DSA. A naming context is a subtree of the DIT, all entries of which have a common administrative authority and are held in the same master DSA. Note: The DIT is therefore partitioned into disjoint naming contexts, each under the administrative authority of a single master DSA. It seem to me that the definition of namingContext makes little sense in the face of multiple master replication. Consider the following: A DIT which consists of two adjacent subtrees of entries A and B where A is superior to B. C refers to the set of entries comprising A and B. Three servers configured as follows: Server 1: masters A Server 2: masters B Server 3: masters C Does the DIT consist of one or two naming contexts? There is no right or wrong answer here... but there is need for the LDUP specification to provide an answer. Kurt From owner-ietf-ldup@mail.imc.org Sat Apr 7 11:54:26 2001 Received: from above.proper.com ([208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA15417 for ; Sat, 7 Apr 2001 11:54:26 -0400 (EDT) Received: by above.proper.com (8.9.3/8.9.3) id IAA20738 for ietf-ldup-bks; Sat, 7 Apr 2001 08:26:27 -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 IAA20730 for ; Sat, 7 Apr 2001 08:26:26 -0700 (PDT) Received: from gypsy.OpenLDAP.org (root@router.boolean.net [198.144.206.49]) by pretender.boolean.net (8.11.1/8.11.1/Boolean/Hub) with ESMTP id f37FScD23056; Sat, 7 Apr 2001 15:28:38 GMT (envelope-from Kurt@OpenLDAP.org) Message-Id: <5.0.2.1.0.20010407073522.01f6b1d0@127.0.0.1> X-Sender: guru@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 5.0.2 Date: Sat, 07 Apr 2001 08:27:34 -0700 To: "Ed Reed" From: "Kurt D. Zeilenga" Subject: Re: naming context definition Cc: In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-ldup@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: At 02:55 AM 4/7/01 -0600, Ed Reed wrote: >Yeah - I've wondered what naming contexts are to replication >areas, or replication areas are to naming contexts, once I figured >out what the formal definition of naming contexts was. Well, what I've been trying to figure out is who is authoritative over an entry (or attribute?). Naming contexts are just one part of the administrative model which is based on the simple premise that each entry is wholly mastered by one and only one DSA and the administrator of that DSA is authoritative for each entry mastered in it. LDUP seems to allow shared authority of an entry and might even allow authority for certain attributes to different than for other attributes of an entry (due to multiple-master fractional replication). It seems possible that no DSA is actually required to master all attributes of an entry. It seems many of the concepts of which LDUP is based upon just cannot be described using LDAP/X.500 terminology. That is, it seems quite difficult to describe a system supporting multiple-master replication using models designed for single-master. >So - what does LDUP need to do or say? Well, I think the group needs to slash a few requirements. First, I'd eliminate multiple-master fractional replication. Then, I'd start examining the question "who is authoritative over an entry?" because until you answer this, you cannot design the administrative model. Kurt From owner-ietf-ldup@mail.imc.org Sat Apr 7 12:34:56 2001 Received: from above.proper.com ([208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA15790 for ; Sat, 7 Apr 2001 12:34:56 -0400 (EDT) Received: (from majordomo@localhost) by above.proper.com (8.9.3/8.9.3) id JAA28111 for ietf-ldup-bks; Sat, 7 Apr 2001 09:10:11 -0700 (PDT) Received: from ns.oncalldba.com ([66.1.184.87]) by above.proper.com (8.9.3/8.9.3) with ESMTP id JAA28102 for ; Sat, 7 Apr 2001 09:10:08 -0700 (PDT) Received: from reed.oncalldba.com (reed.OnCallDBA.COM [192.168.1.3]) by ns.oncalldba.com (8.11.0/8.8.7) with SMTP id f37G9SA04645 for ; Sat, 7 Apr 2001 10:09:29 -0600 Received: from RMINC_DOM-Message_Server by reed.oncalldba.com with Novell_GroupWise; Sat, 07 Apr 2001 09:39:21 -0600 Message-Id: X-Mailer: Novell GroupWise Internet Agent 5.5.2.1 Date: Sat, 07 Apr 2001 09:39:14 -0600 From: "Ed Reed" To: Cc: Subject: Re: naming context definition Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Disposition: inline Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id JAA28108 Sender: owner-ietf-ldup@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 8bit Your point about authoritative "ownership" of entries is a good one. The original model called for three replica types: Primary, Updateable, and Read/Only. The Primary was there because I (yes, me) wanted to promote a single-master replica topology scheme on top of the multi-master data replication scheme. That is, the Primary replica is a designated updateable replica to which all modifications of replicaSubentries and replicationAgreements would be directed. I think the restriction could be reduced to say that Primaries are the only places where creations, modifications, and deletions of replicaSubentries are allowed. This effectively makes the mandatory to implement management operations a single-master application, regardless of how many updateable replicas there are for the replication area, only the master would permit additions or changes to replicas. As I said, that was my original notion. That's not what we have, now. The requirements as they are presently written eliminated the primary replica designation, and renamed the updateable replica type to be "master". All's equal, none superior, there is no ownership of the name space, anyone with sufficient administrative authority can add a replica or otherwise change the replica topology. Further, there's no way to tell if there are replica topology changes already propagating through the environment, because they could have been initiated anywhere. So race conditions, naming collisions, and all manner of other multi-master "untidyness" will bedevil replica management operations. I think that is unwise. I don't know how to safely manage the replica information without a coordinator of the topology. Others who do will have to work with the management operations authors to demonstrate how to do it. I had forgotten that the primary replica also neatly fills the role of "data owner" that the X.500 master provided - the primary replica, being the final authority over what new replicas may be placed on what servers, effectively "owns" the data in the replication area, and controls where it may flow. That is another desireable property of the Primary replica. I would propose that the Primary replica type be restored to the requirements document. It still exists in the architecture model and information model documents. Ed ================= Ed Reed Reed-Matthews, Inc. +1 801 796 7065 http://www.Reed-Matthews.COM >>> "Kurt D. Zeilenga" 04/07/01 09:27AM >>> At 02:55 AM 4/7/01 -0600, Ed Reed wrote: >Yeah - I've wondered what naming contexts are to replication >areas, or replication areas are to naming contexts, once I figured >out what the formal definition of naming contexts was. Well, what I've been trying to figure out is who is authoritative over an entry (or attribute?). Naming contexts are just one part of the administrative model which is based on the simple premise that each entry is wholly mastered by one and only one DSA and the administrator of that DSA is authoritative for each entry mastered in it. LDUP seems to allow shared authority of an entry and might even allow authority for certain attributes to different than for other attributes of an entry (due to multiple-master fractional replication). It seems possible that no DSA is actually required to master all attributes of an entry. It seems many of the concepts of which LDUP is based upon just cannot be described using LDAP/X.500 terminology. That is, it seems quite difficult to describe a system supporting multiple-master replication using models designed for single-master. >So - what does LDUP need to do or say? Well, I think the group needs to slash a few requirements. First, I'd eliminate multiple-master fractional replication. Then, I'd start examining the question "who is authoritative over an entry?" because until you answer this, you cannot design the administrative model. Kurt From owner-ietf-ldup@mail.imc.org Sun Apr 8 09:52:49 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA09358 for ; Sun, 8 Apr 2001 09:52:49 -0400 (EDT) Received: (from majordomo@localhost) by above.proper.com (8.9.3/8.9.3) id GAA00152 for ietf-ldup-bks; Sun, 8 Apr 2001 06:14:25 -0700 (PDT) Received: from clmboh1-smtp3.columbus.rr.com (clmboh1-smtp3.columbus.rr.com [65.24.0.112]) by above.proper.com (8.9.3/8.9.3) with ESMTP id GAA00148 for ; Sun, 8 Apr 2001 06:14:23 -0700 (PDT) Received: from willeke.com (dhcp024-166-090-249.neo.rr.com [24.166.90.249]) by clmboh1-smtp3.columbus.rr.com (8.11.2/8.11.2) with ESMTP id f38DBQt09866; Sun, 8 Apr 2001 09:11:26 -0400 (EDT) Message-ID: <3AD06423.7070200@willeke.com> Date: Sun, 08 Apr 2001 09:14:11 -0400 From: Jim Willeke User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; 0.8.1) Gecko/20010323 X-Accept-Language: en MIME-Version: 1.0 To: "Kurt D. Zeilenga" CC: Ed Reed , ietf-ldup@imc.org Subject: Re: naming context definition References: <5.0.2.1.0.20010407073522.01f6b1d0@127.0.0.1> Content-Type: multipart/alternative; boundary="------------070606010603050001010807" Sender: owner-ietf-ldup@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: --------------070606010603050001010807 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit If I could pop some ideas into this discussion. I see no reason for there to be a "Master" of any data, as long as the schema is the same across the entries. Many conflict resolution ideas could be used to replicate the values of existing schema entries. (Attributes or Objects). NDS uses a unique time stamp and ActiveDirectory uses a GUID stamp and I am sure there are others. For replication of Schema, I think there must be a "Master" or at least an agreement point. You could do somting like: Change is initiated by server A. He sends notice (Status Flag perhaps) to the Schema Master (SM). SM sends notice to all servers in the replication domain that a chenge is in progress. Each Server then notifies SM that they are aware a change is taking place. Server SM sends the change to all server in the replication Domain. All servers in the replication domain acknowlege they have received the change and they can make the change. When the SM receives the notification from all server in the replication domain, he then send a notice to committ the changes. Each server then sends notification the change was applied. When the SM receive notice from all servers in the replication domain, the replication domain is unlocked. -jim Kurt D. Zeilenga wrote: > At 02:55 AM 4/7/01 -0600, Ed Reed wrote: > >> Yeah - I've wondered what naming contexts are to replication >> areas, or replication areas are to naming contexts, once I figured >> out what the formal definition of naming contexts was. > > > Well, what I've been trying to figure out is who is authoritative > over an entry (or attribute?). Naming contexts are just one > part of the administrative model which is based on the simple > premise that each entry is wholly mastered by one and only one > DSA and the administrator of that DSA is authoritative for > each entry mastered in it. > > LDUP seems to allow shared authority of an entry and might > even allow authority for certain attributes to different > than for other attributes of an entry (due to multiple-master > fractional replication). It seems possible that no DSA is > actually required to master all attributes of an entry. > > It seems many of the concepts of which LDUP is based upon > just cannot be described using LDAP/X.500 terminology. That > is, it seems quite difficult to describe a system supporting > multiple-master replication using models designed for > single-master. > >> So - what does LDUP need to do or say? > > > Well, I think the group needs to slash a few requirements. > First, I'd eliminate multiple-master fractional replication. > Then, I'd start examining the question "who is authoritative > over an entry?" because until you answer this, you cannot > design the administrative model. > > Kurt > > > > --------------070606010603050001010807 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit If I could pop some ideas into this discussion.

I see no reason for there to be a "Master" of any data, as long as the schema is the same across the entries.
Many conflict resolution ideas could be used to replicate the values of existing schema entries. (Attributes or Objects). NDS uses a unique time stamp and ActiveDirectory uses a GUID stamp and I am sure there are others.
For replication of Schema, I think there must be a "Master" or at least an agreement point. You could do somting like:
Change is initiated by server A.
He sends notice (Status Flag perhaps) to the Schema Master (SM).
SM sends notice to all servers in the replication domain that a chenge is in progress.
Each Server then notifies SM that they are aware a change is taking place.
Server SM sends the change to all server in the replication Domain.
All servers in the replication domain acknowlege they have received the change and they can make the change.
When the SM receives the notification from all server in the replication domain, he then send a notice to committ the changes.
Each server then sends notification the change was applied.
When the SM receive notice from all servers in the replication domain, the replication domain is unlocked.

-jim


Kurt D. Zeilenga wrote:
At 02:55 AM 4/7/01 -0600, Ed Reed wrote:
Yeah - I've wondered what naming contexts are to replication
areas, or replication areas are to naming contexts, once I figured
out what the formal definition of naming contexts was.

Well, what I've been trying to figure out is who is authoritative
over an entry (or attribute?).  Naming contexts are just one
part of the administrative model which is based on the simple
premise that each entry is wholly mastered by one and only one
DSA and the administrator of that DSA is authoritative for
each entry mastered in it.

LDUP seems to allow shared authority of an entry and might
even allow authority for certain attributes to different
than for other attributes of an entry (due to multiple-master
fractional replication).  It seems possible that no DSA is
actually required to master all attributes of an entry.

It seems many of the concepts of which LDUP is based upon
just cannot be described using LDAP/X.500 terminology.  That
is, it seems quite difficult to describe a system supporting
multiple-master replication using models designed for
single-master.

So - what does LDUP need to do or say?

Well, I think the group needs to slash a few requirements.
First, I'd eliminate multiple-master fractional replication.
Then, I'd start examining the question "who is authoritative
over an entry?" because until you answer this, you cannot
design the administrative model.

Kurt





--------------070606010603050001010807-- From owner-ietf-ldup@mail.imc.org Sun Apr 8 14:31: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 OAA11674 for ; Sun, 8 Apr 2001 14:31:41 -0400 (EDT) Received: (from majordomo@localhost) by above.proper.com (8.9.3/8.9.3) id KAA19712 for ietf-ldup-bks; Sun, 8 Apr 2001 10:55:10 -0700 (PDT) Received: from relay1.pair.com (relay1.pair.com [209.68.1.20]) by above.proper.com (8.9.3/8.9.3) with SMTP id KAA19707 for ; Sun, 8 Apr 2001 10:55:08 -0700 (PDT) Received: (qmail 28630 invoked from network); 8 Apr 2001 17:54:37 -0000 Received: from cpe-144-132-70-18.vic.bigpond.net.au (HELO w98) (144.132.70.18) by relay1.pair.com with SMTP; 8 Apr 2001 17:54:37 -0000 X-pair-Authenticated: 144.132.70.18 Reply-To: From: "Albert Langer" To: "'Ed Reed'" , Cc: , , , , , Subject: RE: draft-ietf-ldup-subentry-08.txt (with attachment, this time) Date: Mon, 9 Apr 2001 03:59:21 +1000 Message-ID: <001101c0c055$a4510460$6628a8c0@nowhere.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2910.0) In-Reply-To: Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Sender: owner-ietf-ldup@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit I am opposed to adoption of an administrative model for LDAP via what was originally supposed to be a subentry specification for LDUP. The administrative model has already been standardized by X.500 and any "simplification" of it should be undertaken very carefully based on a thorough understanding. Such work should be done in LDAP-EXT or a new WG and only after close liaison with relevant X.500 WGs has been established (LUDP should also be involved in liaison but it clearly affects both X.500 and LDAP without regard to replication). The overview of the X.500 model within the subentry draft is itself sufficient demonstration that LDUP lacks the expertize to do this work, as it is clearly wrong and has remained so after errors were pointed out. Current discussions indicate complete confusion about elementary matters like the purpose and function of Naming Context which must be understood for namespace management and name resolution in a distributed directory, even without regard to further complications in relation to replicated areas. Since LDUP has not been chartered to do this work I formally request that it be withdrawn from the sub-entry draft and submitted separately as an individual submission. Recently Ed responded re UUIDs: "Tim - it's within the proper scope of draft-ietf-ldup-infomod. ;-)" There is currently no such document. I drew Ed's attention to this privately prior to the recent IETF. In my view he should fix that before undertaking to redesign the X.500 administrative model. (BTW That is also a response to Kurt's correct suggestion that I should refresh MDCR to solicit discussion. After careful consideration I do not wish to solicit discussion of MDCR while the WG remains in its current state, but am simply making the text available for anyone who wants to look by having placed it in the list archives.) Ed should publish a revised architecture draft with whatever the conclusions are from his recent discussions with Steve, so that if we get a final call on requirements as has been formally requested by the editors, it will be possible to figure out what they are talking about concerning their objections (or conclude that they do not know themselves) rather than being delayed. PS I am in broad agreement with many of Ed's comments in recent messages concerning the need for (floating or failover) single masters for various aspects such as schema management and namespace management. I again recommend study of the method used in Active Directory. Also agree with substance of Kurt's comments: vvvvvvvvvvvvv It seems many of the concepts of which LDUP is based upon just cannot be described using LDAP/X.500 terminology. That is, it seems quite difficult to describe a system supporting multiple-master replication using models designed for single-master. >So - what does LDUP need to do or say? Well, I think the group needs to slash a few requirements. First, I'd eliminate multiple-master fractional replication. Then, I'd start examining the question "who is authoritative over an entry?" because until you answer this, you cannot design the administrative model. ^^^^^^^^^^^^^^ However my conclusion would be, as perhaps Kurt was hinting, that LDUP needs to understand and then fit in with LDAP/X.500 concepts rather than adopting an indescribable architecture. Do not agree with earlier remark in same message that: "Naming contexts are just one part of the administrative model [...]" (though I agree broadly with the omitted point actually being made). Naming Contexts are part of the distribution model, which LDUP still has no real understanding of, despite it's importance for understanding replication issues. My view on what LDUP needs to do is start by publishing tutorial material and working it's way towards a glossary to get some common understanding of basic concepts. First however it needs to do some summing up of how we got where we are and have people assigned to perform essential functions for Facilitator, Secretary, and Consultant familiar with IETF architecture and standards process as the WG co-chairs are still plainly AWOL and have still not been replaced. Meanwhile I don't see much point in discussing issues on which there are no I-Ds as well no point in publishing WG I-Ds (as opposed to individual submissions) on subjects for which we have no charter. Either somebody actually does something to get LDUP functional as an IETF WG or it will continue just drifting aimlessly. At this stage I do not feel any obligation to respond to bits and pieces of the drifting and will simply, follow the discussions without participating (except at final calls) until something is done. I do believe there is some obligation to speak up during discussions on the list rather than wait until final call, but at present this seems to me a waste of time and effort. So I am just generically putting on record that I *have* spoken up and did not agree with whatever was being discussed prior to whatever it is that may or may not be submitted as an I-D to a final call and will just review whatever documents somebody claims are "final" each time I see yet another "final" version. -----Original Message----- From: owner-ietf-ldup@mail.imc.org [mailto:owner-ietf-ldup@mail.imc.org]On Behalf Of Ed Reed Sent: Saturday, April 07, 2001 1:42 AM To: internet-drafts@ietf.org Cc: roland@catalogix.se; jstrassn@cisco.com; capple@ecal.com; ietf-ldup@imc.org; ietf-ldapext@netscape.com; Ed Reed; Mark.Wahl@Sun.COM Subject: draft-ietf-ldup-subentry-08.txt (with attachment, this time) Please publish the attached (really!) revised draft. Abstract: This document describes an administrative model for LDAP, and an object class called ldapSubEntry and a control ldapSubentriesControl (to control the visibility of entries of type ldapSubEntry) that are to be used by directory servers claiming support for the administrative model defined here. ================= Ed Reed Reed-Matthews, Inc. +1 801 796 7065 http://www.Reed-Matthews.COM From owner-ietf-ldup@mail.imc.org Sun Apr 8 21:09:57 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id VAA13303 for ; Sun, 8 Apr 2001 21:09:56 -0400 (EDT) Received: (from majordomo@localhost) by above.proper.com (8.9.3/8.9.3) id RAA14134 for ietf-ldup-bks; Sun, 8 Apr 2001 17:32:27 -0700 (PDT) Received: from ns.oncalldba.com ([66.1.184.87]) by above.proper.com (8.9.3/8.9.3) with ESMTP id RAA14129 for ; Sun, 8 Apr 2001 17:32:24 -0700 (PDT) Received: from reed.oncalldba.com (reed.OnCallDBA.COM [192.168.1.3]) by ns.oncalldba.com (8.11.0/8.8.7) with SMTP id f390VlA14208 for ; Sun, 8 Apr 2001 18:31:47 -0600 Received: from RMINC_DOM-Message_Server by reed.oncalldba.com with Novell_GroupWise; Sun, 08 Apr 2001 17:55:01 -0600 Message-Id: X-Mailer: Novell GroupWise Internet Agent 5.5.2.1 Date: Sun, 08 Apr 2001 17:54:55 -0600 From: "Ed Reed" To: , Cc: Subject: Re: naming context definition Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Disposition: inline Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id RAA14130 Sender: owner-ietf-ldup@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 8bit That's very much the kind of distributed operation coordination that the "primary" that I had in mind to do for replicaSubentries. Schema is possibly another good application for the same thing - it would simplify some conflict resolution issues by insisting that the schema be "unlocked" - i.e., completely distributed to all replicas - before allowing LDAP operations that depend on it to change data. Ed ================= Ed Reed Reed-Matthews, Inc. +1 801 796 7065 http://www.Reed-Matthews.COM >>> Jim Willeke 04/08/01 07:14AM >>> If I could pop some ideas into this discussion. I see no reason for there to be a "Master" of any data, as long as the schema is the same across the entries. Many conflict resolution ideas could be used to replicate the values of existing schema entries. (Attributes or Objects). NDS uses a unique time stamp and ActiveDirectory uses a GUID stamp and I am sure there are others. For replication of Schema, I think there must be a "Master" or at least an agreement point. You could do somting like: Change is initiated by server A. He sends notice (Status Flag perhaps) to the Schema Master (SM). SM sends notice to all servers in the replication domain that a chenge is in progress. Each Server then notifies SM that they are aware a change is taking place. Server SM sends the change to all server in the replication Domain. All servers in the replication domain acknowlege they have received the change and they can make the change. When the SM receives the notification from all server in the replication domain, he then send a notice to committ the changes. Each server then sends notification the change was applied. When the SM receive notice from all servers in the replication domain, the replication domain is unlocked. -jim Kurt D. Zeilenga wrote: > At 02:55 AM 4/7/01 -0600, Ed Reed wrote: > >> Yeah - I've wondered what naming contexts are to replication >> areas, or replication areas are to naming contexts, once I figured >> out what the formal definition of naming contexts was. > > > Well, what I've been trying to figure out is who is authoritative > over an entry (or attribute?). Naming contexts are just one > part of the administrative model which is based on the simple > premise that each entry is wholly mastered by one and only one > DSA and the administrator of that DSA is authoritative for > each entry mastered in it. > > LDUP seems to allow shared authority of an entry and might > even allow authority for certain attributes to different > than for other attributes of an entry (due to multiple-master > fractional replication). It seems possible that no DSA is > actually required to master all attributes of an entry. > > It seems many of the concepts of which LDUP is based upon > just cannot be described using LDAP/X.500 terminology. That > is, it seems quite difficult to describe a system supporting > multiple-master replication using models designed for > single-master. > >> So - what does LDUP need to do or say? > > > Well, I think the group needs to slash a few requirements. > First, I'd eliminate multiple-master fractional replication. > Then, I'd start examining the question "who is authoritative > over an entry?" because until you answer this, you cannot > design the administrative model. > > Kurt > > > > From owner-ietf-ldup@mail.imc.org Sun Apr 8 23:50:05 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id XAA16447 for ; Sun, 8 Apr 2001 23:50:05 -0400 (EDT) Received: by above.proper.com (8.9.3/8.9.3) id UAA19814 for ietf-ldup-bks; Sun, 8 Apr 2001 20:20:39 -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 UAA19810 for ; Sun, 8 Apr 2001 20:20:38 -0700 (PDT) Received: from gypsy.OpenLDAP.org (root@router.boolean.net [198.144.206.49]) by pretender.boolean.net (8.11.1/8.11.1/Boolean/Hub) with ESMTP id f393N5D30020 for ; Mon, 9 Apr 2001 03:23:05 GMT (envelope-from Kurt@OpenLDAP.org) Message-Id: <5.0.2.1.0.20010408194500.020b3b30@127.0.0.1> X-Sender: guru@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 5.0.2 Date: Sun, 08 Apr 2001 20:23:03 -0700 To: ietf-ldup@imc.org From: "Kurt D. Zeilenga" Subject: G9 requirement upon LDAP, not LDUP 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: draft-ietf-ldup-replica-req-08.txt: > 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. The latter sentence states a requirement not upon the LDUP, but upon future LDAP specifications. It is my opinion that such requirements are outside the scope of this document and this group. Even it were in scope, I believe it's inappropriate for this document to require designers of future LDAP extensions to detail how they might work with a ''work in progress''. I call for this sentence be stricken from the document. This is not to say that designers of extensions should ignore such considerations. Designers of extensions should consider all aspects of the LDAP/X.500 data and service models including replication. Kurt From owner-ietf-ldup@mail.imc.org Mon Apr 9 01:40:54 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id BAA21719 for ; Mon, 9 Apr 2001 01:40:54 -0400 (EDT) Received: by above.proper.com (8.9.3/8.9.3) id WAA23446 for ietf-ldup-bks; Sun, 8 Apr 2001 22:15:35 -0700 (PDT) Received: from ns.oncalldba.com ([66.1.184.87]) by above.proper.com (8.9.3/8.9.3) with ESMTP id WAA23438 for ; Sun, 8 Apr 2001 22:15:31 -0700 (PDT) Received: from reed.oncalldba.com (reed.OnCallDBA.COM [192.168.1.3]) by ns.oncalldba.com (8.11.0/8.8.7) with SMTP id f395EoA14905 for ; Sun, 8 Apr 2001 23:14:55 -0600 Received: from RMINC_DOM-Message_Server by reed.oncalldba.com with Novell_GroupWise; Sun, 08 Apr 2001 22:37:06 -0600 Message-Id: X-Mailer: Novell GroupWise Internet Agent 5.5.2.1 Date: Sun, 08 Apr 2001 22:36:57 -0600 From: "Ed Reed" To: , Subject: Re: G9 requirement upon LDAP, not LDUP Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Disposition: inline Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id WAA23442 Sender: owner-ietf-ldup@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 8bit Gee - I guess I thought we all just sorta wanted to highlight things that folks should do when they extend LDAP if they expect LDUP to respond. Maybe another way to say it is that in the future, authors of standards track specifications that change, add, or delete requirements on LDUP have an obligation to say so in their documents, rather that asking them to come back to a presumably defunct by that time LDUP working group, since we all want to sunset groups as soon as all their official work is done. What's the deal, Kurt? Of course LDUP can't put requirements on other groups. But it does need to put future authors on notice that LDUP is not required to have anticipated all their requirements, and to note that it would be only polite for them to note anything in their future documents that seriously affects users of LDUP. Isn't that common sense? Rather than strike it, propose rewording that accomplishes that notice. Ed ================= Ed Reed Reed-Matthews, Inc. +1 801 796 7065 http://www.Reed-Matthews.COM >>> "Kurt D. Zeilenga" 04/08/01 09:23PM >>> draft-ietf-ldup-replica-req-08.txt: > 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. The latter sentence states a requirement not upon the LDUP, but upon future LDAP specifications. It is my opinion that such requirements are outside the scope of this document and this group. Even it were in scope, I believe it's inappropriate for this document to require designers of future LDAP extensions to detail how they might work with a ''work in progress''. I call for this sentence be stricken from the document. This is not to say that designers of extensions should ignore such considerations. Designers of extensions should consider all aspects of the LDAP/X.500 data and service models including replication. Kurt From owner-ietf-ldup@mail.imc.org Mon Apr 9 01:53:24 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id BAA23285 for ; Mon, 9 Apr 2001 01:53:24 -0400 (EDT) Received: by above.proper.com (8.9.3/8.9.3) id WAA23820 for ietf-ldup-bks; Sun, 8 Apr 2001 22:24:05 -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 WAA23815 for ; Sun, 8 Apr 2001 22:24:03 -0700 (PDT) Received: from gypsy.OpenLDAP.org (root@router.boolean.net [198.144.206.49]) by pretender.boolean.net (8.11.1/8.11.1/Boolean/Hub) with ESMTP id f395QaD30284 for ; Mon, 9 Apr 2001 05:26:36 GMT (envelope-from Kurt@OpenLDAP.org) Message-Id: <5.0.2.1.0.20010408212808.020b09a0@127.0.0.1> X-Sender: guru@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 5.0.2 Date: Sun, 08 Apr 2001 22:26:35 -0700 To: ietf-ldup@imc.org From: "Kurt D. Zeilenga" Subject: requirement I-D: security considerations Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-ldup@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: The sentence: As noted in Section 3, security may be impacted when replicating among servers that implement non-standard extensions to basic LDAP semantics. Section 3 makes no comment upon security. It does state there are interoperability issues related to non-standard extensions but it doesn't discussion what security implications of these issues. The sentence: 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]. I believe is a false statement. LDAPext is working on an access control model for LDAP, but there is no requirement for this access control model (as stated in RFC2820 or LDAPext's charter) to address access control in replicated environments. And, as been noted in both LDAPext and LDUP, the current ACM I-D states: The behavior of the Access Control Model in distributed (replicated) environments is beyond the scope of this draft. I note that any distributed ACM depends upon having a consistent authentication and authorization model which LDAP [RFC2829] currently does not provide: The method by which a server composes and validates an authorization identity from the authentication credentials supplied by a client is implementation-specific. Hence, it is unclear to me how LDUP implementations will fulfill the LDAP requirement [RFC2251]: Servers which perform caching or shadowing MUST ensure that they do not violate any access control constraints placed on the data by the originating server. unless significant new work is undertaken or its left to implementors. But in regards to the requirements document, I suggest stating: As LDUP replication will be defined after the specification of authentication, authorization, and (future) access control models, these models do not address implications of their use in replicated environments. Hence, LDUP MUST address the implications of replication upon LDAP's authentication, authorization, and (future) access control models to ensure replicas do not violate access control constraints placed upon data by the authoritative administrator. Kurt From owner-ietf-ldup@mail.imc.org Mon Apr 9 03:38:57 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id DAA01395 for ; Mon, 9 Apr 2001 03:38:57 -0400 (EDT) Received: by above.proper.com (8.9.3/8.9.3) id XAA09711 for ietf-ldup-bks; Sun, 8 Apr 2001 23:55:08 -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 XAA09701 for ; Sun, 8 Apr 2001 23:55:06 -0700 (PDT) Received: from gypsy.OpenLDAP.org (root@router.boolean.net [198.144.206.49]) by pretender.boolean.net (8.11.1/8.11.1/Boolean/Hub) with ESMTP id f396vQD30539; Mon, 9 Apr 2001 06:57:26 GMT (envelope-from Kurt@OpenLDAP.org) Message-Id: <5.0.2.1.0.20010408224129.020b12b0@127.0.0.1> X-Sender: guru@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 5.0.2 Date: Sun, 08 Apr 2001 23:57:25 -0700 To: "Ed Reed" From: "Kurt D. Zeilenga" Subject: Re: G9 requirement upon LDAP, not LDUP Cc: In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-ldup@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: At 10:36 PM 4/8/01 -0600, Ed Reed wrote: >Gee - I guess I thought we all just sorta wanted to highlight things >that folks should do when they extend LDAP if they expect LDUP >to respond. This document details requirements upon LDUP, not to highlight things folks should do when they extend LDAP if they expect LDUP WG to respond. >Maybe another way to say it is that in the future, I think we're talking about two different "futures". I'm talking about a future which starts immediate after publication of the requirements I-D as an RFC. You seem to be talking about some other future. If LDUP has requirements upon future LDAP extensions, then the LDUP requirements document should state a requirement that the LDUP specification state such a requirement. >Of course LDUP can't put requirements on other groups. Then don't. >But it does need to put future authors on notice >that LDUP is not required to have anticipated all their requirements, It who? This I-D or this group? I'll assume this I-D. The purpose of this I-D is to detail anticipated replication issues and detail appropriate LDUP requirements. Obviously it cannot anticipate all issues. However, I note, the LDUP WG would be under some obligation to address technical issues which might be later raised. Of course, LDUP might address a particular issue by saying "no, that's out of scope of our documented requirements." >and to note that it would be only polite for them to note anything >in their future documents that seriously affects users of LDUP. It would be polite to ask designers of LDUP to raise issues they might have with the designs of other works and it would be polite to ask designers of other works to raise issues they might have with LDUP. >Isn't that common sense? Being polite makes common sense. But I'm not sure it makes sense to detail a LDUP requirement that says designers should be polite. Kurt From owner-ietf-ldup@mail.imc.org Mon Apr 9 04:01: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 EAA01518 for ; Mon, 9 Apr 2001 04:01:35 -0400 (EDT) Received: by above.proper.com (8.9.3/8.9.3) id AAA14781 for ietf-ldup-bks; Mon, 9 Apr 2001 00:26:37 -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 AAA14773 for ; Mon, 9 Apr 2001 00:26:35 -0700 (PDT) Received: from gypsy.OpenLDAP.org (root@router.boolean.net [198.144.206.49]) by pretender.boolean.net (8.11.1/8.11.1/Boolean/Hub) with ESMTP id f397T4D30593 for ; Mon, 9 Apr 2001 07:29:04 GMT (envelope-from Kurt@OpenLDAP.org) Message-Id: <5.0.2.1.0.20010409002144.020bf8b0@127.0.0.1> X-Sender: guru@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 5.0.2 Date: Mon, 09 Apr 2001 00:29:03 -0700 To: ietf-ldup@imc.org From: "Kurt D. Zeilenga" Subject: no-copy control requirement 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: X.500 replication model provide a mechanism for clients to state the operation should not be preformed on a copy of the entry. This is useful when the client needs to ensure it is operating upon the master DSA instead of a shadow DSA. There likely should be some requirement to support this feature in LDUP. Kurt From owner-ietf-ldup@mail.imc.org Mon Apr 9 04:14:18 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id EAA01592 for ; Mon, 9 Apr 2001 04:14:17 -0400 (EDT) Received: (from majordomo@localhost) by above.proper.com (8.9.3/8.9.3) id AAA16040 for ietf-ldup-bks; Mon, 9 Apr 2001 00:37:56 -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 AAA16031 for ; Mon, 9 Apr 2001 00:37:52 -0700 (PDT) Received: from ex01.ummail.com [216.33.108.253:25] by hawk.ummail.com with SMTP id P0409-0337-465300; Mon, 9 Apr 2001 07:37:27 GMT Received: by ex01.ummail.com with Internet Mail Service (5.5.2650.21) id <2B6170ZF>; Mon, 9 Apr 2001 03:37:15 -0400 Message-ID: From: Christopher Apple To: Ed Reed , ietf-ldup@imc.org, Kurt@OpenLDAP.org Subject: RE: G9 requirement upon LDAP, not LDUP Date: Mon, 9 Apr 2001 03:37:08 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: multipart/mixed; boundary="----_=_NextPart_000_01C0C0C7.E19BE890" 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_01C0C0C7.E19BE890 Content-Type: text/plain; charset="iso-8859-1" I recall that this requirement has been around for quite some time with the present wording - which represents WG consensus. Kurt's is the only dissenting opinion that I recall seeing - but I'm writing this without taking another look at mailing list archives. One of the authors of the document that Kurt is commenting should post the earliest known revision number of that document containing this requirement so that I can plow through the mailing list to verify that Kurt's opinion is indeed the only dissenting one since the time this requirement was modified (if ever) to the present wording. I agree with Ed's basic points below. It would not be wise to just remove such a requirement from a document. Reducing the strength of the requirement from MUST to SHOULD might be a more reasonable compromise. However, before that change could be made - it must represent the consensus of the WG....and so far - I've only seen postings about either side of this from two WG participants. That's not enough to justify changing it at all in my opinion. Chris Apple Program Manager - Directory Services United Messaging Inc. http://www.unitedmessaging.com christopher.apple@unitedmessaging.com (V) 610-425-2860 > -----Original Message----- > From: Ed Reed [mailto:eer@OnCallDBA.COM] > Sent: Monday, April 09, 2001 12:37 AM > To: ietf-ldup@imc.org; Kurt@OpenLDAP.org > Subject: Re: G9 requirement upon LDAP, not LDUP > > > Gee - I guess I thought we all just sorta wanted to highlight things > that folks should do when they extend LDAP if they expect LDUP > to respond. Maybe another way to say it is that in the future, > authors of standards track specifications that change, add, or > delete requirements on LDUP have an obligation to say so in their > documents, rather that asking them to come back to a presumably > defunct by that time LDUP working group, since we all want to sunset > groups as soon as all their official work is done. > > What's the deal, Kurt? Of course LDUP can't put requirements on > other groups. But it does need to put future authors on notice > that LDUP is not required to have anticipated all their requirements, > and to note that it would be only polite for them to note anything > in their future documents that seriously affects users of LDUP. Isn't > that common sense? > > Rather than strike it, propose rewording that accomplishes > that notice. > > Ed > > ================= > Ed Reed > Reed-Matthews, Inc. > +1 801 796 7065 > http://www.Reed-Matthews.COM > > >>> "Kurt D. Zeilenga" 04/08/01 09:23PM >>> > draft-ietf-ldup-replica-req-08.txt: > > 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. > > The latter sentence states a requirement not upon the LDUP, but upon > future LDAP specifications. It is my opinion that such requirements > are outside the scope of this document and this group. Even it > were in scope, I believe it's inappropriate for this document > to require designers of future LDAP extensions to detail how they > might work with a ''work in progress''. I call for this sentence > be stricken from the document. > > This is not to say that designers of extensions should ignore > such considerations. Designers of extensions should consider all > aspects of the LDAP/X.500 data and service models including > replication. > > Kurt > > ------_=_NextPart_000_01C0C0C7.E19BE890 Content-Type: application/octet-stream; name="Christopher Apple (E-mail).vcf" Content-Disposition: attachment; filename="Christopher Apple (E-mail).vcf" BEGIN:VCARD VERSION:2.1 N:Apple;Christopher FN:Christopher 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 EMAIL;PREF;INTERNET:christopher.apple@unitedmessaging.com REV:20010405T144628Z END:VCARD ------_=_NextPart_000_01C0C0C7.E19BE890-- From owner-ietf-ldup@mail.imc.org Mon Apr 9 07:27:58 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA03008 for ; Mon, 9 Apr 2001 07:27:57 -0400 (EDT) Received: by above.proper.com (8.9.3/8.9.3) id DAA13071 for ietf-ldup-bks; Mon, 9 Apr 2001 03:50:10 -0700 (PDT) Received: from ietf.org (odin.ietf.org [132.151.1.176]) by above.proper.com (8.9.3/8.9.3) with ESMTP id DAA13066 for ; Mon, 9 Apr 2001 03:50:08 -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 GAA02534; Mon, 9 Apr 2001 06:50:08 -0400 (EDT) Message-Id: <200104091050.GAA02534@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-subentry-08.txt Date: Mon, 09 Apr 2001 06:50:08 -0400 Sender: owner-ietf-ldup@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the LDAP Duplication/Replication/Update Protocols Working Group of the IETF. Title : LDAP Subentry Schema Author(s) : E. Reed Filename : draft-ietf-ldup-subentry-08.txt Pages : 9 Date : 06-Apr-01 This document describes an administrative model for LDAP, and an object class called ldapSubEntry and a control ldapSubentriesControl (to control the visibility of entries of type ldapSubEntry) that are to be used by directory servers claiming support for the administrative model defined here. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ldup-subentry-08.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-subentry-08.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-subentry-08.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: <20010406125102.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ldup-subentry-08.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ldup-subentry-08.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20010406125102.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ietf-ldup@mail.imc.org Mon Apr 9 09:10:30 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA05488 for ; Mon, 9 Apr 2001 09:10:30 -0400 (EDT) Received: (from majordomo@localhost) by above.proper.com (8.9.3/8.9.3) id FAA23205 for ietf-ldup-bks; Mon, 9 Apr 2001 05:36:50 -0700 (PDT) Received: from e1.ny.us.ibm.com (e1.ny.us.ibm.com [32.97.182.101]) by above.proper.com (8.9.3/8.9.3) with ESMTP id FAA23194 for ; Mon, 9 Apr 2001 05:36:41 -0700 (PDT) Received: from northrelay02.pok.ibm.com (northrelay02.pok.ibm.com [9.117.200.22]) by e1.ny.us.ibm.com (8.9.3/8.9.3) with ESMTP id IAA91238; Mon, 9 Apr 2001 08:34:48 -0400 Received: from d27ml001.rchland.ibm.com ([9.5.39.28]) by northrelay02.pok.ibm.com (8.8.8m3/NCO v4.95) with ESMTP id IAA24734; Mon, 9 Apr 2001 08:31:17 -0400 Importance: Normal Subject: Re: entryUUID To: "Ed Reed" Cc: , "Timothy Hahn" X-Mailer: Lotus Notes Release 5.0.6a January 17, 2001 Message-ID: From: "John McMeeking" Date: Mon, 9 Apr 2001 07:36:07 -0500 X-MIMETrack: Serialize by Router on d27ml001/27/M/IBM(Release 5.0.7 |March 21, 2001) at 04/09/2001 07:36:27 AM MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: owner-ietf-ldup@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: I don't think that we need the full DCE UUID specification. Something like the following ought to work: EntryUUID is a 16-byte structure defined as: server-generated ID - 80 bits IEEE adapter address -- 48 bits server-generated ID: This field uniquely identifies an entry across all entries created on a single DSA. If an entry is deleted, and another entry later created with the same DN, a different server-generated ID shall be assigned to the entry. The algorithm for generating this value is implementation defined. A server could generated this value using the system clock, a counter, or other means. IEEE adapter adress: This field contains one of the 48-bit IEEE adapter addresses for this server. If an adapter address is not available, an implementation must use a fake adapter address with the first bit (the multi-cast address bit) set to 1. A fake adapter address must be unique across all servers that an entry could be present on. For example, in a multi-master replication environment, the address must be unique across all servers to which the entry is replicated, or a value may need to be unique across a corporate intranet. The algorithm for generating a fake adapter addres is implementation defined, but could be based on data such as the system name, IP address, or system clock; the adapter address could be assigned by an administrator. The combination of server-generated ID and IEEE adapter address ensures that an entryUUID is unique across all entries on all server. An example of a widely known algorithm that generates UUIDs like this is the DCE entry UUID algorithm used for remote remote procedure calls. EntryUUID has applications outside of replication. It might be best to have a separate I-D for just entryUUID. Two examples of things that could use entryUUID without replication being present: - an application that needs to be able to distinguish between two instances of an entry with the same distinguished name; for example, to distinguish between "cn=my data" created today, and a future "cn=my data" created two weeks from now after deleting the existing "cn=my data". Depending on the nature of the application, it may be a requirement that the server generate such values to ensure that a client can not recreate the entry with a previously used entryUUID. - a LDAP event notification model that notifies a client of changes to a DIT subtree in which the client may not be authorized to all entries. A server could include the entryUUID in the event notification without needing to first determine if a client was authorized to the particular entry. This is useful in cases where the DN might contain information a client is not authorized to. John McMeeking jmcmeek@us.ibm.com (507)253-4596 "Ed Reed" @mail.imc.org on 04/06/2001 11:14:29 AM Sent by: owner-ietf-ldup@mail.imc.org To: , Timothy Hahn/Endicott/IBM@IBMUS cc: Fax to: Subject: Re: entryUUID Tim - it's within the proper scope of draft-ietf-ldup-infomod. ;-) The value UUIDs and the entryUUID are described there, and are intended to conform to, the DCE UUID specification used in DCE (duh) and the corresponding ISO RPC specification. Generating an RFC that describes them without treading on copyright restrictions has hindered publication of an RFC for that purpose to date, but that's what's intended by LDUP. Its syntax should be octet string, in my opinion. Ed >>> "Timothy Hahn" 04/06/01 08:23AM >>> Hello all, We have found a need to use the proposed attribute: entryUUID prior to a full definition of LDUP replication models. Has anyone crisply defined this attribute, including an OID? Would anyone like to do so so that applications could use this definition prior to having an LDUP set of RFCs? The alternative could be that each implementation/vendor defines their own in the mean-time ... not necessarily with the same format. Does anyone out there care? Regards, Tim Hahn Internet: hahnt@us.ibm.com Internal: Timothy Hahn/Endicott/IBM@IBMUS or IBMUSM00(HAHNT) phone: 607.752.6388 tie-line: 8/852.6388 fax: 607.752.3681 From owner-ietf-ldup@mail.imc.org Mon Apr 9 11:06:49 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA08732 for ; Mon, 9 Apr 2001 11:06:48 -0400 (EDT) Received: by above.proper.com (8.9.3/8.9.3) id HAA01980 for ietf-ldup-bks; Mon, 9 Apr 2001 07:30:04 -0700 (PDT) Received: from e31.bld.us.ibm.com (e31.co.us.ibm.com [32.97.110.129]) by above.proper.com (8.9.3/8.9.3) with ESMTP id HAA01975 for ; Mon, 9 Apr 2001 07:30:02 -0700 (PDT) Received: from westrelay02.boulder.ibm.com (westrelay02.boulder.ibm.com [9.99.140.23]) by e31.bld.us.ibm.com (8.9.3/8.9.3) with ESMTP id KAA11454; Mon, 9 Apr 2001 10:22:42 -0400 Received: from d04nm203.raleigh.ibm.com (d04nm203.raleigh.ibm.com [9.67.228.40]) by westrelay02.boulder.ibm.com (8.8.8m3/NCO v4.95) with ESMTP id IAA200622; Mon, 9 Apr 2001 08:30:00 -0600 Importance: Normal Subject: Re: no-copy control requirement To: "Kurt D. Zeilenga" Cc: ietf-ldup@imc.org X-Mailer: Lotus Notes Release 5.0.3 (Intl) 21 March 2000 Message-ID: From: "John McGarvey" Date: Mon, 9 Apr 2001 10:30:02 -0400 X-MIMETrack: Serialize by Router on D04NM203/04/M/IBM(Release 5.0.6 |December 14, 2000) at 04/09/2001 10:30:00 AM MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: owner-ietf-ldup@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Kurt, I suggested such a mechanism about 2 months back, because such a mechanism could ensure atomicity of changes for one or several entries. This suggestion was pretty much ignored by the list. Albert replied that this would create a single point of failure, and that to require the client to know where the master is for some replication context is inconsistent with a globally scalable distributed environment. I believe, however, that such a mechanism is needed to give atomicity of changes. Some on this mailing list have suggested that we solve the atomicity problem with error notification. Error notification is necessary, but it is an anemic solution, which would likely require frequent administrative intervention. At that time, I suggested that there be a "master master" for each replication context. This does create a single point of failure, and it is not transparent to the client. So, here's an alternative approach. Perhaps there should be an "atomicity lock" for each replication context, which could pass from server to server. If a server that holds the lock goes down, another server could reclaim the lock by majority vote of the rest of the DSAs for that replication context -- eliminating the single point of failure. Also, if the client passes controls indicating the need for a group of changes to be applied atomically, the server with which it is communicating could either request the atomicity lock, or pass a referral to the current holder of the lock. (An atomic change to a collection of entries which are spread over several replication contexts is more difficult. A single server may have to claim several locks, and there would have to be a mechanism to prevent deadlock conditions.) -- John McGarvey "Kurt D. Zeilenga" @mail.imc.org on 04/09/2001 03:29:03 AM Sent by: owner-ietf-ldup@mail.imc.org To: ietf-ldup@imc.org cc: Subject: no-copy control requirement X.500 replication model provide a mechanism for clients to state the operation should not be preformed on a copy of the entry. This is useful when the client needs to ensure it is operating upon the master DSA instead of a shadow DSA. There likely should be some requirement to support this feature in LDUP. Kurt From owner-ietf-ldup@mail.imc.org Mon Apr 9 11:32:11 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA09368 for ; Mon, 9 Apr 2001 11:32:10 -0400 (EDT) Received: (from majordomo@localhost) by above.proper.com (8.9.3/8.9.3) id HAA03060 for ietf-ldup-bks; Mon, 9 Apr 2001 07:49:37 -0700 (PDT) Received: from ns.oncalldba.com ([66.1.184.87]) by above.proper.com (8.9.3/8.9.3) with ESMTP id HAA03055 for ; Mon, 9 Apr 2001 07:49:34 -0700 (PDT) Received: from reed.oncalldba.com (reed.OnCallDBA.COM [192.168.1.3]) by ns.oncalldba.com (8.11.0/8.8.7) with SMTP id f39EmqA16394 for ; Mon, 9 Apr 2001 08:48:52 -0600 Received: from RMINC_DOM-Message_Server by reed.oncalldba.com with Novell_GroupWise; Mon, 09 Apr 2001 08:09:10 -0600 Message-Id: X-Mailer: Novell GroupWise Internet Agent 5.5.2.1 Date: Mon, 09 Apr 2001 08:09:06 -0600 From: "Ed Reed" To: Cc: Subject: Re: no-copy control requirement Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Disposition: inline Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id HAA03057 Sender: owner-ietf-ldup@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 8bit And, this would require either 1) reinstatement of the "primary" replica designation, as the "owner" of all data in the replication area (not the same as the server to which all data modifications are made, but a "soft" designation for use by applications, like replica topology management, to use by common agreement as the single server to use so that such a "high confidence" or "no copy" bit can be made to make sense), or 2) carry sufficient information on each attribute value so that the server where that data was originally entered into the DIT can be identified (the CSN replica id may suffice), so that the client (or chaining or referring server) can individually contact each of the servers at which various values of attributes for the entry was entered and verify that the values read at the copy are still the values of record at the originating server. Of course, in a multi master environment, there's no guarantee that #2 above will actually contact a server where an update has occurred that has not yet propagated to either the DSA handling the no-copy request from the client (presuming it is either chaining or that it is trying hard to provide useful referral information to the client), or indeed to the DSA where the original value was entered. Using the approach in #1, it is possible for applications with single-master dependencies to algorithmically select a single master of all the master replicas (by looking at the replica types) to which to direct their modification operations, without unduely hindering other applications that dont' require such relatively high assurance consistency. But it does not give the client nor any server the omniscience required to locate as yet un- replicated changes among the replicas of the DIT. I don't know of other approaches to providing this non-LDAP control, but I agree its a necessary thing to define. I had thought it something to be defined as part of the distributed operations model of the directory, instead of the LDUP itself. It's also interesting to consider how the whole subject of referrals and how they're to be generated gathers the information to give to the client who wants to constrain itself to talking to data where "copy is not sufficient" constraints are in place. Another argument, in my view, of using information in the DIT that includes replica type knowlege, as the source of things like subordinate references (so references generated for clients who have asserted the "no copy" control will be correctly directed to the appropriate replica of the subordinate name space). Ed ================= Ed Reed Reed-Matthews, Inc. +1 801 796 7065 http://www.Reed-Matthews.COM >>> "Kurt D. Zeilenga" 04/09/01 01:29AM >>> X.500 replication model provide a mechanism for clients to state the operation should not be preformed on a copy of the entry. This is useful when the client needs to ensure it is operating upon the master DSA instead of a shadow DSA. There likely should be some requirement to support this feature in LDUP. Kurt From owner-ietf-ldup@mail.imc.org Mon Apr 9 12:33:34 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA11021 for ; Mon, 9 Apr 2001 12:33:33 -0400 (EDT) Received: (from majordomo@localhost) by above.proper.com (8.9.3/8.9.3) id IAA11233 for ietf-ldup-bks; Mon, 9 Apr 2001 08:55:54 -0700 (PDT) Received: from e1.ny.us.ibm.com (e1.ny.us.ibm.com [32.97.182.101]) by above.proper.com (8.9.3/8.9.3) with ESMTP id IAA11225 for ; Mon, 9 Apr 2001 08:55:51 -0700 (PDT) Received: from northrelay02.pok.ibm.com (northrelay02.pok.ibm.com [9.117.200.22]) by e1.ny.us.ibm.com (8.9.3/8.9.3) with ESMTP id LAA109442; Mon, 9 Apr 2001 11:53:59 -0400 Received: from d01mlc96.pok.ibm.com (d01mlc96.pok.ibm.com [9.117.250.33]) by northrelay02.pok.ibm.com (8.8.8m3/NCO v4.95) with ESMTP id LAA38118; Mon, 9 Apr 2001 11:50:26 -0400 To: "Ed Reed" , ietf-ldup@imc.org Subject: Re: entryUUID X-Mailer: Lotus Notes Release 5.0.5 September 22, 2000 From: "Timothy Hahn" Message-ID: Date: Mon, 9 Apr 2001 11:55:00 -0400 X-MIMETrack: Serialize by Router on D01MLC96/01/M/IBM(Release 5.0.7.dev00 SPR #MIAS4UTJ8H &S/390 SPR #JHEG4V8UT5|April 3, 2001) at 04/09/2001 11:55:21 AM, Serialize complete at 04/09/2001 11:55:21 AM MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="=_alternative 005649EF85256A29_=" Sender: owner-ietf-ldup@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multipart message in MIME format. --=_alternative 005649EF85256A29_= Content-Type: text/plain; charset="us-ascii" Ed, I would suggest a separate syntax and matching rule - like what has been described for ldapChangeSequenceNumber - since the "string-form" of the UUID should be passed "in protocol". This would allow implementations to store the attribute however they see fit, while the string form is something everyone is used to seeing and dealing with. Sound OK to you? Regards, Tim Hahn Internet: hahnt@us.ibm.com Internal: Timothy Hahn/Endicott/IBM@IBMUS or IBMUSM00(HAHNT) phone: 607.752.6388 tie-line: 8/852.6388 fax: 607.752.3681 "Ed Reed" 04/06/2001 12:14 PM To: , "Timothy Hahn" cc: Subject: Re: entryUUID Tim - it's within the proper scope of draft-ietf-ldup-infomod. ;-) The value UUIDs and the entryUUID are described there, and are intended to conform to, the DCE UUID specification used in DCE (duh) and the corresponding ISO RPC specification. Generating an RFC that describes them without treading on copyright restrictions has hindered publication of an RFC for that purpose to date, but that's what's intended by LDUP. Its syntax should be octet string, in my opinion. Ed >>> "Timothy Hahn" 04/06/01 08:23AM >>> Hello all, We have found a need to use the proposed attribute: entryUUID prior to a full definition of LDUP replication models. Has anyone crisply defined this attribute, including an OID? Would anyone like to do so so that applications could use this definition prior to having an LDUP set of RFCs? The alternative could be that each implementation/vendor defines their own in the mean-time ... not necessarily with the same format. Does anyone out there care? Regards, Tim Hahn Internet: hahnt@us.ibm.com Internal: Timothy Hahn/Endicott/IBM@IBMUS or IBMUSM00(HAHNT) phone: 607.752.6388 tie-line: 8/852.6388 fax: 607.752.3681 --=_alternative 005649EF85256A29_= Content-Type: text/html; charset="us-ascii"
Ed,

I would suggest a separate syntax and matching rule - like what has been described for ldapChangeSequenceNumber - since the "string-form" of the UUID should be passed "in protocol".  This would allow implementations to store the attribute however they see fit, while the string form is something everyone is used to seeing and dealing with.

Sound OK to you?
Regards,
Tim Hahn

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


"Ed Reed" <eer@OnCallDBA.COM>

04/06/2001 12:14 PM

       
        To:        <ietf-ldup@imc.org>, "Timothy Hahn" <hahnt@us.ibm.com>
        cc:        
        Subject:        Re: entryUUID

       


Tim - it's within the proper scope of draft-ietf-ldup-infomod.  ;-)

The value UUIDs and the entryUUID are described there, and are
intended to conform to, the DCE UUID specification used in
DCE (duh) and the corresponding ISO RPC specification.  Generating
an RFC that describes them without treading on copyright
restrictions has hindered publication of an RFC for that purpose to
date, but that's what's intended by LDUP.  Its syntax should be
octet string, in my opinion.

Ed

>>> "Timothy Hahn" <hahnt@us.ibm.com> 04/06/01 08:23AM >>>
Hello all,

We have found a need to use the proposed attribute: entryUUID prior to a
full definition of LDUP replication models.

Has anyone crisply defined this attribute, including an OID?

Would anyone like to do so so that applications could use this definition
prior to having an LDUP set of RFCs?

The alternative could be that each implementation/vendor defines their own
in the mean-time ... not necessarily with the same format.

Does anyone out there care?

Regards,
Tim Hahn

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

--=_alternative 005649EF85256A29_=-- From owner-ietf-ldup@mail.imc.org Mon Apr 9 15:57: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 PAA15391 for ; Mon, 9 Apr 2001 15:57:07 -0400 (EDT) Received: (from majordomo@localhost) by above.proper.com (8.9.3/8.9.3) id MAA23811 for ietf-ldup-bks; Mon, 9 Apr 2001 12:25:11 -0700 (PDT) Received: from hawk.ummail.com (hawk.ummail.com [216.33.108.202]) by above.proper.com (8.9.3/8.9.3) with ESMTP id MAA23801 for ; Mon, 9 Apr 2001 12:25:08 -0700 (PDT) Received: from ex01.ummail.com [216.33.108.253:25] by hawk.ummail.com with SMTP id P0409-1524-182000; Mon, 9 Apr 2001 19:24:36 GMT Received: by ex01.ummail.com with Internet Mail Service (5.5.2650.21) id <2B6182X5>; Mon, 9 Apr 2001 15:24:16 -0400 Message-ID: From: Christopher Apple To: Christopher Apple , "'Kurt D. Zeilenga'" Cc: "'johns@cisco.com'" , "'ietf-ldup@imc.org'" , "'paf@cisco.com'" Subject: RE: G9 requirement upon LDAP, not LDUP Date: Mon, 9 Apr 2001 15:24:15 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: multipart/mixed; boundary="----_=_NextPart_000_01C0C12A.AA65CF40" 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_01C0C12A.AA65CF40 Content-Type: text/plain; charset="iso-8859-1" Please note that Patrik's e-mail address was incorrect on my original reply. This time its correct. "Ghost" entries in my address book...... Chris Apple Program Manager - Directory Services United Messaging Inc. http://www.unitedmessaging.com christopher.apple@unitedmessaging.com (V) 610-425-2860 > -----Original Message----- > From: Christopher Apple > Sent: Monday, April 09, 2001 3:17 PM > To: 'Kurt D. Zeilenga'; Christopher Apple > Cc: johns@cisco.com; 'ietf-ldup@imc.org'; 'paf@swip.net' > Subject: RE: G9 requirement upon LDAP, not LDUP > > > John and I can certainly look at scope issues and will. > > I didn't intend to squash discussion. People are free to comment > on this issue as they always are on the mailing list. I was pointing > out that so far - we've only heard something from two people. So, more > discussion is required about this topic on the list before consensus > can be gauged. > > Generally, when a requirement shows up in a WG document, its either > a proposal for the WG to consider or represents consensus of the WG. > Rick Huber pointed out to me in a private reply that this requirement > was actually new as of the -07 revision of the document. So, > my recollection > was not correct. As far as judging consensus based on no > discussion of the > issue in the mailing list, please take note that I mentioned > (using different > words) in my reply to your posting that I still needed to do that sort > of audit to confirm (or refute, though I did not specifically > use that word) > my recollection. > > I want to hear more from others about a proposed resolution to your > opinion/posting before a change of this nature is made to the draft. > > Strictly speaking without my co-chair hat on, I think its certainly > appropriate to recommend in a requirements document for > LDAPv3 Replication > (its just called LDUP because of a set of words that someone > culled together > before one of the first BOF meetings on the topic) that future LDAPv3 > extensions should include a section on how that particular > extension is > affected by or could potentially affect replication. I do not have a > strong feeling at this point about the strength that we should install > into that requirement. > > Speaking as co-chair, I need to see more discussion of the > issue before > consensus can be gauged. > > Chris Apple > Program Manager - Directory Services > United Messaging Inc. > http://www.unitedmessaging.com > christopher.apple@unitedmessaging.com (V) 610-425-2860 > -----Original Message----- > From: Kurt D. Zeilenga [mailto:Kurt@OpenLDAP.org] > Sent: Monday, April 09, 2001 10:58 AM > To: Christopher Apple > Cc: johns@cisco.com > Subject: RE: G9 requirement upon LDAP, not LDUP > > > Christopher, > > Maybe I was unclear in the nature of my objection. I do not believe > the sentence in question states a technical requirement upon the > design of LDUP. It states a requirement upon the design and > specification of other LDAP extensions. I ask that you or John, > the WG chairs, review the charter and make a determination whether > the LDUP WG is tasked to develop requirements upon the developers > of other LDAP extensions and then to take action based upon this > determination. > > If you believe it is within scope, I object to you squashing > discussion on this issue and ask you reconsider. > > There was no such requirement in revision -06 which went up for > WG Last Call. At last call, an issue was discussed regarding > "active" and "passive" data and I believe the eventual consensus > was to replace this characterization with the userApplications v. > operational characterization. > > This sentence, however, was not part of that discussion. I cannot > find any prior discussion as to why it was added and I believe my > posting of yesterday initiated the first discussion regarding the > addition. It is unclear to me how one could draw what the WG > consensus regarding an issue which has yet to be discussed. > > Thanks, Kurt > ------_=_NextPart_000_01C0C12A.AA65CF40 Content-Type: application/octet-stream; name="Christopher Apple (E-mail).vcf" Content-Disposition: attachment; filename="Christopher Apple (E-mail).vcf" BEGIN:VCARD VERSION:2.1 N:Apple;Christopher FN:Christopher 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 EMAIL;PREF;INTERNET:christopher.apple@unitedmessaging.com REV:20010405T144628Z END:VCARD ------_=_NextPart_000_01C0C12A.AA65CF40-- From owner-ietf-ldup@mail.imc.org Mon Apr 9 15:58:34 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA15420 for ; Mon, 9 Apr 2001 15:58:33 -0400 (EDT) Received: (from majordomo@localhost) by above.proper.com (8.9.3/8.9.3) id MAA23057 for ietf-ldup-bks; Mon, 9 Apr 2001 12:18:20 -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 MAA23042 for ; Mon, 9 Apr 2001 12:18:15 -0700 (PDT) Received: from ex01.ummail.com [216.33.108.253:25] by hawk.ummail.com with SMTP id P0409-1517-057d00; Mon, 9 Apr 2001 19:17:15 GMT Received: by ex01.ummail.com with Internet Mail Service (5.5.2650.21) id <2B6182SN>; Mon, 9 Apr 2001 15:17:02 -0400 Message-ID: From: Christopher Apple To: "'Kurt D. Zeilenga'" , Christopher Apple Cc: johns@cisco.com, "'ietf-ldup@imc.org'" , "'paf@swip.net'" Subject: RE: G9 requirement upon LDAP, not LDUP Date: Mon, 9 Apr 2001 15:17:02 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: multipart/mixed; boundary="----_=_NextPart_000_01C0C129.A7F95890" 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_01C0C129.A7F95890 Content-Type: text/plain; charset="iso-8859-1" John and I can certainly look at scope issues and will. I didn't intend to squash discussion. People are free to comment on this issue as they always are on the mailing list. I was pointing out that so far - we've only heard something from two people. So, more discussion is required about this topic on the list before consensus can be gauged. Generally, when a requirement shows up in a WG document, its either a proposal for the WG to consider or represents consensus of the WG. Rick Huber pointed out to me in a private reply that this requirement was actually new as of the -07 revision of the document. So, my recollection was not correct. As far as judging consensus based on no discussion of the issue in the mailing list, please take note that I mentioned (using different words) in my reply to your posting that I still needed to do that sort of audit to confirm (or refute, though I did not specifically use that word) my recollection. I want to hear more from others about a proposed resolution to your opinion/posting before a change of this nature is made to the draft. Strictly speaking without my co-chair hat on, I think its certainly appropriate to recommend in a requirements document for LDAPv3 Replication (its just called LDUP because of a set of words that someone culled together before one of the first BOF meetings on the topic) that future LDAPv3 extensions should include a section on how that particular extension is affected by or could potentially affect replication. I do not have a strong feeling at this point about the strength that we should install into that requirement. Speaking as co-chair, I need to see more discussion of the issue before consensus can be gauged. Chris Apple Program Manager - Directory Services United Messaging Inc. http://www.unitedmessaging.com christopher.apple@unitedmessaging.com (V) 610-425-2860 > -----Original Message----- > From: Kurt D. Zeilenga [mailto:Kurt@OpenLDAP.org] > Sent: Monday, April 09, 2001 10:58 AM > To: Christopher Apple > Cc: johns@cisco.com > Subject: RE: G9 requirement upon LDAP, not LDUP > > > Christopher, > > Maybe I was unclear in the nature of my objection. I do not believe > the sentence in question states a technical requirement upon the > design of LDUP. It states a requirement upon the design and > specification of other LDAP extensions. I ask that you or John, > the WG chairs, review the charter and make a determination whether > the LDUP WG is tasked to develop requirements upon the developers > of other LDAP extensions and then to take action based upon this > determination. > > If you believe it is within scope, I object to you squashing > discussion on this issue and ask you reconsider. > > There was no such requirement in revision -06 which went up for > WG Last Call. At last call, an issue was discussed regarding > "active" and "passive" data and I believe the eventual consensus > was to replace this characterization with the userApplications v. > operational characterization. > > This sentence, however, was not part of that discussion. I cannot > find any prior discussion as to why it was added and I believe my > posting of yesterday initiated the first discussion regarding the > addition. It is unclear to me how one could draw what the WG > consensus regarding an issue which has yet to be discussed. > > Thanks, Kurt > ------_=_NextPart_000_01C0C129.A7F95890 Content-Type: application/octet-stream; name="Christopher Apple (E-mail).vcf" Content-Disposition: attachment; filename="Christopher Apple (E-mail).vcf" BEGIN:VCARD VERSION:2.1 N:Apple;Christopher FN:Christopher 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 EMAIL;PREF;INTERNET:christopher.apple@unitedmessaging.com REV:20010405T144628Z END:VCARD ------_=_NextPart_000_01C0C129.A7F95890-- From owner-ietf-ldup@mail.imc.org Mon Apr 9 17:39: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 RAA17569 for ; Mon, 9 Apr 2001 17:39:42 -0400 (EDT) Received: (from majordomo@localhost) by above.proper.com (8.9.3/8.9.3) id NAA01892 for ietf-ldup-bks; Mon, 9 Apr 2001 13:53:02 -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 NAA01883 for ; Mon, 9 Apr 2001 13:53:00 -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 f39KqN707785; Mon, 9 Apr 2001 16:52:23 -0400 (EDT) Received: from att.com by qsun.mt.att.com (SMI-8.6/ATTEMS-1.4.1 sol2) id QAA04200; Mon, 9 Apr 2001 16:52:22 -0400 Message-ID: <3AD220CC.3A6AA1F7@att.com> Date: Mon, 09 Apr 2001 16:51:24 -0400 From: Richard Huber X-Mailer: Mozilla 4.75 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Christopher Apple CC: "'Kurt D. Zeilenga'" , "'johns@cisco.com'" , "'ietf-ldup@imc.org'" , "'paf@cisco.com'" Subject: Re: G9 requirement upon LDAP, not LDUP References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-ldup@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit I certainly agree that the sentence in question "...states a requirement upon the design and specification of other LDAP extensions". That's what we were trying to do. The requirement grew out of an issue that was discussed in San Diego. Albert Langer had noted in email that the subentry draft might add new replication needs. It may indeed, as may other proposals. We need to have a way to track these needs so they can be addressed. We can write requirements and models that address current LDAP features, but we really can't address all possible future features. So, in order to make sure that we understand the replication issues of future LDAP extensions, we added the requirement. Kurt, in a previous email you seem to agree that our concern is valid: > This is not to say that designers of extensions should ignore > such considerations. Designers of extensions should consider all > aspects of the LDAP/X.500 data and service models including > replication. > So if your concern is with our proposed mechanism rather than our goal, do you see some other way we can address the issue? Rick Huber Christopher Apple wrote: > Please note that Patrik's e-mail address was incorrect on my original > reply. This time its correct. "Ghost" entries in my address book...... > > Chris Apple > Program Manager - Directory Services > United Messaging Inc. > http://www.unitedmessaging.com > christopher.apple@unitedmessaging.com > > (V) 610-425-2860 > > > -----Original Message----- > > From: Christopher Apple > > Sent: Monday, April 09, 2001 3:17 PM > > To: 'Kurt D. Zeilenga'; Christopher Apple > > Cc: johns@cisco.com; 'ietf-ldup@imc.org'; 'paf@swip.net' > > Subject: RE: G9 requirement upon LDAP, not LDUP > > > > > > John and I can certainly look at scope issues and will. > > > > I didn't intend to squash discussion. People are free to comment > > on this issue as they always are on the mailing list. I was pointing > > out that so far - we've only heard something from two people. So, more > > discussion is required about this topic on the list before consensus > > can be gauged. > > > > Generally, when a requirement shows up in a WG document, its either > > a proposal for the WG to consider or represents consensus of the WG. > > Rick Huber pointed out to me in a private reply that this requirement > > was actually new as of the -07 revision of the document. So, > > my recollection > > was not correct. As far as judging consensus based on no > > discussion of the > > issue in the mailing list, please take note that I mentioned > > (using different > > words) in my reply to your posting that I still needed to do that sort > > of audit to confirm (or refute, though I did not specifically > > use that word) > > my recollection. > > > > I want to hear more from others about a proposed resolution to your > > opinion/posting before a change of this nature is made to the draft. > > > > Strictly speaking without my co-chair hat on, I think its certainly > > appropriate to recommend in a requirements document for > > LDAPv3 Replication > > (its just called LDUP because of a set of words that someone > > culled together > > before one of the first BOF meetings on the topic) that future LDAPv3 > > extensions should include a section on how that particular > > extension is > > affected by or could potentially affect replication. I do not have a > > strong feeling at this point about the strength that we should install > > into that requirement. > > > > Speaking as co-chair, I need to see more discussion of the > > issue before > > consensus can be gauged. > > > > Chris Apple > > Program Manager - Directory Services > > United Messaging Inc. > > http://www.unitedmessaging.com > > christopher.apple@unitedmessaging.com > > (V) 610-425-2860 > > > -----Original Message----- > > From: Kurt D. Zeilenga [mailto:Kurt@OpenLDAP.org] > > Sent: Monday, April 09, 2001 10:58 AM > > To: Christopher Apple > > Cc: johns@cisco.com > > Subject: RE: G9 requirement upon LDAP, not LDUP > > > > > > Christopher, > > > > Maybe I was unclear in the nature of my objection. I do not believe > > the sentence in question states a technical requirement upon the > > design of LDUP. It states a requirement upon the design and > > specification of other LDAP extensions. I ask that you or John, > > the WG chairs, review the charter and make a determination whether > > the LDUP WG is tasked to develop requirements upon the developers > > of other LDAP extensions and then to take action based upon this > > determination. > > > > If you believe it is within scope, I object to you squashing > > discussion on this issue and ask you reconsider. > > > > There was no such requirement in revision -06 which went up for > > WG Last Call. At last call, an issue was discussed regarding > > "active" and "passive" data and I believe the eventual consensus > > was to replace this characterization with the userApplications v. > > operational characterization. > > > > This sentence, however, was not part of that discussion. I cannot > > find any prior discussion as to why it was added and I believe my > > posting of yesterday initiated the first discussion regarding the > > addition. It is unclear to me how one could draw what the WG > > consensus regarding an issue which has yet to be discussed. > > > > Thanks, Kurt > > From owner-ietf-ldup@mail.imc.org Mon Apr 9 22:07:28 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id WAA22192 for ; Mon, 9 Apr 2001 22:07:28 -0400 (EDT) Received: (from majordomo@localhost) by above.proper.com (8.9.3/8.9.3) id SAA19345 for ietf-ldup-bks; Mon, 9 Apr 2001 18:35:17 -0700 (PDT) Received: from arnie.adacel.com.au (arnie.adacel.com.au [203.36.26.147]) by above.proper.com (8.9.3/8.9.3) with SMTP id SAA19340 for ; Mon, 9 Apr 2001 18:35:13 -0700 (PDT) Received: (qmail 14399 invoked from network); 10 Apr 2001 01:40:52 -0000 Received: from unknown (HELO osmium) (203.8.85.176) by arnie.adacel.com.au with SMTP; 10 Apr 2001 01:40:52 -0000 Reply-To: From: "Steven Legg" To: "'John McMeeking'" Cc: Subject: RE: entryUUID Date: Tue, 10 Apr 2001 11:36:56 +1000 Message-ID: <001801c0c15e$bba82760$b05508cb@osmium.adacel.com.au> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook 8.5, Build 4.71.2377.0 Importance: Normal In-Reply-To: X-MIMEOLE: Produced By Microsoft MimeOLE V4.72.2120.0 Sender: owner-ietf-ldup@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit John, A long time ago I suggested that the format for the entry unique identifier should be prefixed with a mechanism type so that a variety of schemes could be used. Type 0 could be the full DCE UUID form, type 1 could be a simpler scheme such as you describe below, and so on. I would find an object identifier form particularly useful. The only requirement on the unique identifier is that it is a globally unique sequence of octets. Servers can compare UUIDs as OCTET STRINGs using octetStringMatch without regard to which mechanism was used to generate them. A server only needs to know one of the possible mechanisms to generate UUIDs. It doesn't need to know any other current or future defined mechanism. We need to standardize the type numbers and their corresponding mechanisms of course, but that's no big deal. Regards, Steven > -----Original Message----- > From: owner-ietf-ldup@mail.imc.org > [mailto:owner-ietf-ldup@mail.imc.org]On Behalf Of John McMeeking > Sent: Monday, 9 April 2001 22:36 > To: Ed Reed > Cc: ietf-ldup@imc.org; Timothy Hahn > Subject: Re: entryUUID > > > > > I don't think that we need the full DCE UUID specification. > Something like > the following ought to work: > > EntryUUID is a 16-byte structure defined as: > server-generated ID - 80 bits > IEEE adapter address -- 48 bits > > server-generated ID: This field uniquely identifies an entry > across all > entries created on a single DSA. If an entry is deleted, and > another entry > later created with the same DN, a different server-generated > ID shall be > assigned to the entry. The algorithm for generating this value is > implementation defined. A server could generated this value using the > system clock, a counter, or other means. > > IEEE adapter adress: This field contains one of the 48-bit > IEEE adapter > addresses for this server. If an adapter address is not available, an > implementation must use a fake adapter address with the first bit (the > multi-cast address bit) set to 1. A fake adapter address > must be unique > across all servers that an entry could be present on. For > example, in a > multi-master replication environment, the address must be > unique across all > servers to which the entry is replicated, or a value may need > to be unique > across a corporate intranet. The algorithm for generating a > fake adapter > addres is implementation defined, but could be based on data > such as the > system name, IP address, or system clock; the adapter address could be > assigned by an administrator. > > The combination of server-generated ID and IEEE adapter > address ensures > that an entryUUID is unique across all entries on all server. > > An example of a widely known algorithm that generates UUIDs > like this is > the DCE entry UUID algorithm used for remote remote procedure calls. > > > EntryUUID has applications outside of replication. It might > be best to > have a separate I-D for just entryUUID. Two examples of > things that could > use entryUUID without replication being present: > > - an application that needs to be able to distinguish between > two instances > of an entry with the same distinguished name; for example, to > distinguish > between "cn=my data" created today, and a future "cn=my data" > created two > weeks from now after deleting the existing "cn=my data". > Depending on the > nature of the application, it may be a requirement that the > server generate > such values to ensure that a client can not recreate the entry with a > previously used entryUUID. > > - a LDAP event notification model that notifies a client of > changes to a > DIT subtree in which the client may not be authorized to all > entries. A > server could include the entryUUID in the event notification without > needing to first determine if a client was authorized to the > particular > entry. This is useful in cases where the DN might contain > information a > client is not authorized to. > > > > John McMeeking > jmcmeek@us.ibm.com > (507)253-4596 > > > "Ed Reed" @mail.imc.org on 04/06/2001 11:14:29 AM > > Sent by: owner-ietf-ldup@mail.imc.org > > > To: , Timothy Hahn/Endicott/IBM@IBMUS > cc: > Fax to: > Subject: Re: entryUUID > > > > Tim - it's within the proper scope of draft-ietf-ldup-infomod. ;-) > > The value UUIDs and the entryUUID are described there, and are > intended to conform to, the DCE UUID specification used in > DCE (duh) and the corresponding ISO RPC specification. Generating > an RFC that describes them without treading on copyright > restrictions has hindered publication of an RFC for that purpose to > date, but that's what's intended by LDUP. Its syntax should be > octet string, in my opinion. > > Ed > > >>> "Timothy Hahn" 04/06/01 08:23AM >>> > Hello all, > > We have found a need to use the proposed attribute: entryUUID > prior to a > full definition of LDUP replication models. > > Has anyone crisply defined this attribute, including an OID? > > Would anyone like to do so so that applications could use > this definition > prior to having an LDUP set of RFCs? > > The alternative could be that each implementation/vendor > defines their own > in the mean-time ... not necessarily with the same format. > > Does anyone out there care? > > Regards, > Tim Hahn > > Internet: hahnt@us.ibm.com > Internal: Timothy Hahn/Endicott/IBM@IBMUS or IBMUSM00(HAHNT) > phone: 607.752.6388 tie-line: 8/852.6388 > fax: 607.752.3681 > > > > > From owner-ietf-ldup@mail.imc.org Tue Apr 10 00:54: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 AAA24899 for ; Tue, 10 Apr 2001 00:54:43 -0400 (EDT) Received: (from majordomo@localhost) by above.proper.com (8.9.3/8.9.3) id VAA23414 for ietf-ldup-bks; Mon, 9 Apr 2001 21:27:15 -0700 (PDT) Received: from arnie.adacel.com.au (arnie.adacel.com.au [203.36.26.147]) by above.proper.com (8.9.3/8.9.3) with SMTP id VAA23410 for ; Mon, 9 Apr 2001 21:27:12 -0700 (PDT) Received: (qmail 3489 invoked from network); 10 Apr 2001 04:32:58 -0000 Received: from unknown (HELO osmium) (203.8.85.176) by arnie.adacel.com.au with SMTP; 10 Apr 2001 04:32:58 -0000 Reply-To: From: "Steven Legg" To: "'Ed Reed'" Cc: Subject: RE: no-copy control requirement Date: Tue, 10 Apr 2001 14:29:00 +1000 Message-ID: <001a01c0c176$c570ce60$b05508cb@osmium.adacel.com.au> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook 8.5, Build 4.71.2377.0 Importance: Normal In-Reply-To: X-MIMEOLE: Produced By Microsoft MimeOLE V4.72.2120.0 Sender: owner-ietf-ldup@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit Ed, In X.500 single master replication an entry is either a master (modifiable) copy or a shadow (read-only) copy. For every shadow entry there is a corresponding master entry, transient inconsistency notwithstanding. In our current multimaster architecture an entry is either a shadow copy, a co-mastered copy or a single-mastered copy. There is either one single-mastered copy of an entry within the replica group or two or more co-mastered copies. If we use a no-copy *bit* then we have to decide whether it means don't use shadow entries or don't use shadow or co-mastered entries. If it means the latter then an operation should be failed if no-copy is requested but the entry is co-mastered. If one master replica is nominated as some sort of primary then we have four possible entry copy states: shadow, co-mastered, primary-co-mastered or single-mastered. An entry can have both co-mastered copies and a primary-co-mastered copy within the replica group. A two-valued control isn't enough. We would want clients to be able to request one of the four following treatments through a control. 1) Use any kind of copy. This case doesn't apply for updates. 2) Don't use shadow copies (use any mastered copy). This case should be the default when the control is absent. I'm inclined to map the X.500 dontUseCopy service control to this case as well. This control setting won't cause an operation to fail. 3) Don't use shadow or co-mastered copies (use primary-co-mastered or single-mastered copies). The operation should be failed if there is no primary-co-mastered or single-mastered copy. 4) Don't use shadow or co-mastered or primary-co-mastered copies (use only single-mastered copies). The operation should be failed if there is no single-mastered copy. If the control is expressive enough then we don't need to *mandate* the existence of a primary master replica. Clients decide if it matters to them whether a primary master replica is actually deployed. For good measure we can also add a fifth case to the control: 5) Guarantee strong consistency. If the entry is single-mastered then strong consistency is already assured, but if the entry is co-mastered the control implies the client is requesting that a distributed update be invoked - something like the locking solution John McGarvey is talking about, or the strong consistency solution I sketched out previously on the mailing list. Regards, Steven Ed Reed wrote: > And, this would require either > > 1) reinstatement of the "primary" replica designation, as the "owner" > of all data in the replication area (not the same as the server to > which all data modifications are made, but a "soft" designation for > use by applications, like replica topology management, to use > by common agreement as the single server to use so that such a > "high confidence" or "no copy" bit can be made to make sense), or > > 2) carry sufficient information on each attribute value so that the > server where that data was originally entered into the DIT can be > identified (the CSN replica id may suffice), so that the client (or > chaining or referring server) can individually contact each of the > servers at which various values of attributes for the entry was > entered and verify that the values read at the copy are still > the values of record at the originating server. > > Of course, in a multi master environment, there's no guarantee > that #2 above will actually contact a server where an update > has occurred that has not yet propagated to either the DSA > handling the no-copy request from the client (presuming it is > either chaining or that it is trying hard to provide useful > referral information to the client), or indeed to the DSA where > the original value was entered. > > Using the approach in #1, it is possible for applications with > single-master dependencies to algorithmically select a single > master of all the master replicas (by looking at the replica types) > to which to direct their modification operations, without unduely > hindering other applications that dont' require such relatively > high assurance consistency. But it does not give the client > nor any server the omniscience required to locate as yet un- > replicated changes among the replicas of the DIT. > > I don't know of other approaches to providing this non-LDAP > control, but I agree its a necessary thing to define. I had > thought it something to be defined as part of the distributed > operations model of the directory, instead of the LDUP > itself. > > It's also interesting to consider how the whole subject of > referrals and how they're to be generated gathers the information > to give to the client who wants to constrain itself to talking > to data where "copy is not sufficient" constraints are in place. > Another argument, in my view, of using information in the DIT > that includes replica type knowlege, as the source of things > like subordinate references (so references generated > for clients who have asserted the "no copy" control will be > correctly directed to the appropriate replica of the subordinate > name space). > > Ed > > ================= > Ed Reed > Reed-Matthews, Inc. > +1 801 796 7065 > http://www.Reed-Matthews.COM > > >>> "Kurt D. Zeilenga" 04/09/01 01:29AM >>> > X.500 replication model provide a mechanism for clients > to state the operation should not be preformed on a > copy of the entry. This is useful when the client > needs to ensure it is operating upon the master DSA > instead of a shadow DSA. There likely should be some > requirement to support this feature in LDUP. > > Kurt > > > From owner-ietf-ldup@mail.imc.org Tue Apr 10 10:55:54 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA17263 for ; Tue, 10 Apr 2001 10:55:51 -0400 (EDT) Received: (from majordomo@localhost) by above.proper.com (8.9.3/8.9.3) id HAA28771 for ietf-ldup-bks; Tue, 10 Apr 2001 07:22:45 -0700 (PDT) Received: from ns.oncalldba.com ([66.1.184.87]) by above.proper.com (8.9.3/8.9.3) with ESMTP id HAA28765 for ; Tue, 10 Apr 2001 07:22:42 -0700 (PDT) Received: from reed.oncalldba.com (reed.OnCallDBA.COM [192.168.1.3]) by ns.oncalldba.com (8.11.0/8.8.7) with SMTP id f3AEM3A19934 for ; Tue, 10 Apr 2001 08:22:03 -0600 Received: from RMINC_DOM-Message_Server by reed.oncalldba.com with Novell_GroupWise; Tue, 10 Apr 2001 07:37:30 -0600 Message-Id: X-Mailer: Novell GroupWise Internet Agent 5.5.2.1 Date: Tue, 10 Apr 2001 07:37:18 -0600 From: "Ed Reed" To: Cc: Subject: RE: no-copy control requirement Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Disposition: inline Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id HAA28767 Sender: owner-ietf-ldup@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 8bit Steve - sounds like a good approach, to me. This also sounds like a control definition that needs to be defined...but where? doesn't make sense to do it in the mandatory to implement management operations doc, nor the info model. Perhaps it's time to create a single LDAP control that embodies the common arguments that are otherwise missing from X.500 DAP? That way they'd be there syntactally, whether actually in use or not, and the groundwork would be made for promoting LDAP to DAP in the long run (just had to throw that it - its starting to make sense to me). Whachathink? Ed ================= Ed Reed Reed-Matthews, Inc. +1 801 796 7065 http://www.Reed-Matthews.COM >>> "Steven Legg" 04/09/01 10:29PM >>> Ed, In X.500 single master replication an entry is either a master (modifiable) copy or a shadow (read-only) copy. For every shadow entry there is a corresponding master entry, transient inconsistency notwithstanding. In our current multimaster architecture an entry is either a shadow copy, a co-mastered copy or a single-mastered copy. There is either one single-mastered copy of an entry within the replica group or two or more co-mastered copies. If we use a no-copy *bit* then we have to decide whether it means don't use shadow entries or don't use shadow or co-mastered entries. If it means the latter then an operation should be failed if no-copy is requested but the entry is co-mastered. If one master replica is nominated as some sort of primary then we have four possible entry copy states: shadow, co-mastered, primary-co-mastered or single-mastered. An entry can have both co-mastered copies and a primary-co-mastered copy within the replica group. A two-valued control isn't enough. We would want clients to be able to request one of the four following treatments through a control. 1) Use any kind of copy. This case doesn't apply for updates. 2) Don't use shadow copies (use any mastered copy). This case should be the default when the control is absent. I'm inclined to map the X.500 dontUseCopy service control to this case as well. This control setting won't cause an operation to fail. 3) Don't use shadow or co-mastered copies (use primary-co-mastered or single-mastered copies). The operation should be failed if there is no primary-co-mastered or single-mastered copy. 4) Don't use shadow or co-mastered or primary-co-mastered copies (use only single-mastered copies). The operation should be failed if there is no single-mastered copy. If the control is expressive enough then we don't need to *mandate* the existence of a primary master replica. Clients decide if it matters to them whether a primary master replica is actually deployed. For good measure we can also add a fifth case to the control: 5) Guarantee strong consistency. If the entry is single-mastered then strong consistency is already assured, but if the entry is co-mastered the control implies the client is requesting that a distributed update be invoked - something like the locking solution John McGarvey is talking about, or the strong consistency solution I sketched out previously on the mailing list. Regards, Steven Ed Reed wrote: > And, this would require either > > 1) reinstatement of the "primary" replica designation, as the "owner" > of all data in the replication area (not the same as the server to > which all data modifications are made, but a "soft" designation for > use by applications, like replica topology management, to use > by common agreement as the single server to use so that such a > "high confidence" or "no copy" bit can be made to make sense), or > > 2) carry sufficient information on each attribute value so that the > server where that data was originally entered into the DIT can be > identified (the CSN replica id may suffice), so that the client (or > chaining or referring server) can individually contact each of the > servers at which various values of attributes for the entry was > entered and verify that the values read at the copy are still > the values of record at the originating server. > > Of course, in a multi master environment, there's no guarantee > that #2 above will actually contact a server where an update > has occurred that has not yet propagated to either the DSA > handling the no-copy request from the client (presuming it is > either chaining or that it is trying hard to provide useful > referral information to the client), or indeed to the DSA where > the original value was entered. > > Using the approach in #1, it is possible for applications with > single-master dependencies to algorithmically select a single > master of all the master replicas (by looking at the replica types) > to which to direct their modification operations, without unduely > hindering other applications that dont' require such relatively > high assurance consistency. But it does not give the client > nor any server the omniscience required to locate as yet un- > replicated changes among the replicas of the DIT. > > I don't know of other approaches to providing this non-LDAP > control, but I agree its a necessary thing to define. I had > thought it something to be defined as part of the distributed > operations model of the directory, instead of the LDUP > itself. > > It's also interesting to consider how the whole subject of > referrals and how they're to be generated gathers the information > to give to the client who wants to constrain itself to talking > to data where "copy is not sufficient" constraints are in place. > Another argument, in my view, of using information in the DIT > that includes replica type knowlege, as the source of things > like subordinate references (so references generated > for clients who have asserted the "no copy" control will be > correctly directed to the appropriate replica of the subordinate > name space). > > Ed > > ================= > Ed Reed > Reed-Matthews, Inc. > +1 801 796 7065 > http://www.Reed-Matthews.COM > > >>> "Kurt D. Zeilenga" 04/09/01 01:29AM >>> > X.500 replication model provide a mechanism for clients > to state the operation should not be preformed on a > copy of the entry. This is useful when the client > needs to ensure it is operating upon the master DSA > instead of a shadow DSA. There likely should be some > requirement to support this feature in LDUP. > > Kurt > > > From owner-ietf-ldup@mail.imc.org Wed Apr 11 02:58:41 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id CAA18224 for ; Wed, 11 Apr 2001 02:58:41 -0400 (EDT) Received: by above.proper.com (8.9.3/8.9.3) id XAA29431 for ietf-ldup-bks; Tue, 10 Apr 2001 23:26:55 -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 XAA29418 for ; Tue, 10 Apr 2001 23:26:53 -0700 (PDT) Received: from gypsy.OpenLDAP.org (root@router.boolean.net [198.144.206.49]) by pretender.boolean.net (8.11.1/8.11.1/Boolean/Hub) with ESMTP id f3B6TRD38660; Wed, 11 Apr 2001 06:29:27 GMT (envelope-from Kurt@OpenLDAP.org) Message-Id: <5.0.2.1.0.20010410190325.00a84090@127.0.0.1> X-Sender: guru@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 5.0.2 Date: Tue, 10 Apr 2001 19:27:54 -0700 To: Richard Huber From: "Kurt D. Zeilenga" Subject: Re: G9 requirement upon LDAP, not LDUP Cc: In-Reply-To: <3AD220CC.3A6AA1F7@att.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-ldup@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: [Cc list trimmed] At 04:51 PM 4/9/01 -0400, Richard Huber wrote: >> This is not to say that designers of extensions should ignore >> such considerations. Designers of extensions should consider all >> aspects of the LDAP/X.500 data and service models including >> replication. >> >So if your concern is with our proposed mechanism rather than our goal, do >you see some other way we can address the issue? Well, I think in the short term (from now to the time when an LDUP Standard Track specification), I think the best way to ensure that LDAP/X.500 data and service models issues are addressed if for concerned members of the IETF to do appropriate review of the documents as they are progressed though the IETF. If the LDUP requirement were to actually mandate a "Replication Considerations" section, here are some samples which you will likely get: 1) no section, the authors/review did not see the req't. 2) no section, the authors/review don't believe any section can be provided which adds value. 3) section with: "LDAP Replication was not considered as LDUP is a "work in progress''." 4) section with: "This extension is designed to support LDAP replication which is consistent with the LDAP/X.500 data and service models." 5) section with: "This extension is designed to support LDUP, ''a work in progress'', as currently designed but may not support LDUP as defined in future Standard Track documents." None of these are particular useful. Until LDUP matures, I don't see how any useful statement can actually be made. The problem is that the requirement, as stated, attempts to mandate that all LDAP Standard Track specifications to express considerations for a ''work in a progress''. This seems quite inappropriate to me. I would suggest instead of requiring the authors to document such considerations you just say: Authors of LDAP extensions SHOULD consider replication issues. As LDAP Replication is currently a "work in progress", authors SHOULD note that any I-Ds detailing this work may be updated, replaced, or obsoleted by other documents at any time. I-Ds MUST NOT be viewed as a definitive. As this is not a requirement upon LDUP, I would not enumerate it as such. I would instead place in the Introduction. From owner-ietf-ldup@mail.imc.org Wed Apr 11 03:44:13 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id DAA18516 for ; Wed, 11 Apr 2001 03:44:12 -0400 (EDT) Received: (from majordomo@localhost) by above.proper.com (8.9.3/8.9.3) id AAA08470 for ietf-ldup-bks; Wed, 11 Apr 2001 00:17:34 -0700 (PDT) Received: from relay1.pair.com (relay1.pair.com [209.68.1.20]) by above.proper.com (8.9.3/8.9.3) with SMTP id AAA08463 for ; Wed, 11 Apr 2001 00:17:32 -0700 (PDT) Received: (qmail 10813 invoked from network); 11 Apr 2001 07:16:55 -0000 Received: from cpe-144-132-70-18.vic.bigpond.net.au (HELO w98) (144.132.70.18) by relay1.pair.com with SMTP; 11 Apr 2001 07:16:55 -0000 X-pair-Authenticated: 144.132.70.18 Reply-To: From: "Albert Langer" To: "'Kurt D. Zeilenga'" , "'Richard Huber'" Cc: Subject: RE: G9 requirement upon LDAP, not LDUP Date: Wed, 11 Apr 2001 17:19:03 +1000 Message-ID: <000e01c0c257$b1e08ac0$6628a8c0@nowhere.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2910.0) In-Reply-To: <5.0.2.1.0.20010410190325.00a84090@127.0.0.1> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Sender: owner-ietf-ldup@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit I agree with Kurt. In addition it is especially difficult for anyone to consider impact on specifications that are not only "in progress" but quite immature. Also suggest that the wording placed in introduction should be more reciprocal - actively *soliciting* input from elsewhere as to how LDUP should take into account the needs of *other* areas. Stressed this earlier - especially re atomicity but obviously applies to many things. LDUP needs to *learn*, not make demands. -----Original Message----- From: owner-ietf-ldup@mail.imc.org [mailto:owner-ietf-ldup@mail.imc.org]On Behalf Of Kurt D. Zeilenga Sent: Wednesday, April 11, 2001 12:28 PM To: Richard Huber Cc: ietf-ldup@imc.org Subject: Re: G9 requirement upon LDAP, not LDUP [Cc list trimmed] At 04:51 PM 4/9/01 -0400, Richard Huber wrote: >> This is not to say that designers of extensions should ignore >> such considerations. Designers of extensions should consider all >> aspects of the LDAP/X.500 data and service models including >> replication. >> >So if your concern is with our proposed mechanism rather than our goal, do >you see some other way we can address the issue? Well, I think in the short term (from now to the time when an LDUP Standard Track specification), I think the best way to ensure that LDAP/X.500 data and service models issues are addressed if for concerned members of the IETF to do appropriate review of the documents as they are progressed though the IETF. If the LDUP requirement were to actually mandate a "Replication Considerations" section, here are some samples which you will likely get: 1) no section, the authors/review did not see the req't. 2) no section, the authors/review don't believe any section can be provided which adds value. 3) section with: "LDAP Replication was not considered as LDUP is a "work in progress''." 4) section with: "This extension is designed to support LDAP replication which is consistent with the LDAP/X.500 data and service models." 5) section with: "This extension is designed to support LDUP, ''a work in progress'', as currently designed but may not support LDUP as defined in future Standard Track documents." None of these are particular useful. Until LDUP matures, I don't see how any useful statement can actually be made. The problem is that the requirement, as stated, attempts to mandate that all LDAP Standard Track specifications to express considerations for a ''work in a progress''. This seems quite inappropriate to me. I would suggest instead of requiring the authors to document such considerations you just say: Authors of LDAP extensions SHOULD consider replication issues. As LDAP Replication is currently a "work in progress", authors SHOULD note that any I-Ds detailing this work may be updated, replaced, or obsoleted by other documents at any time. I-Ds MUST NOT be viewed as a definitive. As this is not a requirement upon LDUP, I would not enumerate it as such. I would instead place in the Introduction. From owner-ietf-ldup@mail.imc.org Wed Apr 11 03:46:39 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id DAA18532 for ; Wed, 11 Apr 2001 03:46:39 -0400 (EDT) Received: (from majordomo@localhost) by above.proper.com (8.9.3/8.9.3) id AAA08499 for ietf-ldup-bks; Wed, 11 Apr 2001 00:17:41 -0700 (PDT) Received: from relay1.pair.com (relay1.pair.com [209.68.1.20]) by above.proper.com (8.9.3/8.9.3) with SMTP id AAA08493 for ; Wed, 11 Apr 2001 00:17:40 -0700 (PDT) Received: (qmail 10813 invoked from network); 11 Apr 2001 07:16:55 -0000 Received: from cpe-144-132-70-18.vic.bigpond.net.au (HELO w98) (144.132.70.18) by relay1.pair.com with SMTP; 11 Apr 2001 07:16:55 -0000 X-pair-Authenticated: 144.132.70.18 Reply-To: From: "Albert Langer" To: "'Kurt D. Zeilenga'" , "'Richard Huber'" Cc: Subject: RE: G9 requirement upon LDAP, not LDUP Date: Wed, 11 Apr 2001 17:19:03 +1000 Message-ID: <000e01c0c257$b1e08ac0$6628a8c0@nowhere.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2910.0) In-Reply-To: <5.0.2.1.0.20010410190325.00a84090@127.0.0.1> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Sender: owner-ietf-ldup@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit I agree with Kurt. In addition it is especially difficult for anyone to consider impact on specifications that are not only "in progress" but quite immature. Also suggest that the wording placed in introduction should be more reciprocal - actively *soliciting* input from elsewhere as to how LDUP should take into account the needs of *other* areas. Stressed this earlier - especially re atomicity but obviously applies to many things. LDUP needs to *learn*, not make demands. -----Original Message----- From: owner-ietf-ldup@mail.imc.org [mailto:owner-ietf-ldup@mail.imc.org]On Behalf Of Kurt D. Zeilenga Sent: Wednesday, April 11, 2001 12:28 PM To: Richard Huber Cc: ietf-ldup@imc.org Subject: Re: G9 requirement upon LDAP, not LDUP [Cc list trimmed] At 04:51 PM 4/9/01 -0400, Richard Huber wrote: >> This is not to say that designers of extensions should ignore >> such considerations. Designers of extensions should consider all >> aspects of the LDAP/X.500 data and service models including >> replication. >> >So if your concern is with our proposed mechanism rather than our goal, do >you see some other way we can address the issue? Well, I think in the short term (from now to the time when an LDUP Standard Track specification), I think the best way to ensure that LDAP/X.500 data and service models issues are addressed if for concerned members of the IETF to do appropriate review of the documents as they are progressed though the IETF. If the LDUP requirement were to actually mandate a "Replication Considerations" section, here are some samples which you will likely get: 1) no section, the authors/review did not see the req't. 2) no section, the authors/review don't believe any section can be provided which adds value. 3) section with: "LDAP Replication was not considered as LDUP is a "work in progress''." 4) section with: "This extension is designed to support LDAP replication which is consistent with the LDAP/X.500 data and service models." 5) section with: "This extension is designed to support LDUP, ''a work in progress'', as currently designed but may not support LDUP as defined in future Standard Track documents." None of these are particular useful. Until LDUP matures, I don't see how any useful statement can actually be made. The problem is that the requirement, as stated, attempts to mandate that all LDAP Standard Track specifications to express considerations for a ''work in a progress''. This seems quite inappropriate to me. I would suggest instead of requiring the authors to document such considerations you just say: Authors of LDAP extensions SHOULD consider replication issues. As LDAP Replication is currently a "work in progress", authors SHOULD note that any I-Ds detailing this work may be updated, replaced, or obsoleted by other documents at any time. I-Ds MUST NOT be viewed as a definitive. As this is not a requirement upon LDUP, I would not enumerate it as such. I would instead place in the Introduction. From owner-ietf-ldup@mail.imc.org Wed Apr 11 13:00:23 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA28851 for ; Wed, 11 Apr 2001 13:00:22 -0400 (EDT) Received: (from majordomo@localhost) by above.proper.com (8.9.3/8.9.3) id JAA27235 for ietf-ldup-bks; Wed, 11 Apr 2001 09:18:40 -0700 (PDT) Received: from hawk.ummail.com (hawk.ummail.com [64.58.86.20]) by above.proper.com (8.9.3/8.9.3) with ESMTP id JAA27229 for ; Wed, 11 Apr 2001 09:18:38 -0700 (PDT) Received: from ex01.ummail.com [216.33.108.253:25] by hawk.ummail.com with SMTP id P0411-1217-249100; Wed, 11 Apr 2001 16:17:53 GMT Received: by ex01.ummail.com with Internet Mail Service (5.5.2650.21) id <2B619XD4>; Wed, 11 Apr 2001 12:17:37 -0400 Message-ID: From: Christopher Apple To: "'Kurt D. Zeilenga'" , Richard Huber Cc: ietf-ldup@imc.org Subject: RE: G9 requirement upon LDAP, not LDUP Date: Wed, 11 Apr 2001 12:17:37 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: multipart/mixed; boundary="----_=_NextPart_000_01C0C2A2.EC504D30" 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_01C0C2A2.EC504D30 Content-Type: text/plain; charset="iso-8859-1" I think we could accomplish the same end you seem to be advocating if we simply replace the word MUST with SHOULD in the original text. That way, its still a requirement that a replication considerations sections be there, but the SHOULD allows editors of new LDAP extension I-Ds opt to not include one if there is a very good reason to do so. One very good reason to *not* include such a section is that the LDUP WG has not concluded its work. However, I can't conceive of any substantive downside to simply including the section and stating whether or not LDAPv3 replication considerations were made during the creation of any such I-D. So, I think most editors that behave in a way that you have agreed is desirable (paying attention to X.500/LDAP considerations) would simply include the 10 or so extra lines of text required to accommodate this requirement. My comments on your sample reactions to this sort of requirement are below... Chris Apple Program Manager - Directory Services United Messaging Inc. http://www.unitedmessaging.com christopher.apple@unitedmessaging.com (V) 610-425-2860 > -----Original Message----- > From: Kurt D. Zeilenga [mailto:Kurt@OpenLDAP.org] > Sent: Tuesday, April 10, 2001 10:28 PM > To: Richard Huber > Cc: ietf-ldup@imc.org > Subject: Re: G9 requirement upon LDAP, not LDUP > > > [Cc list trimmed] > > At 04:51 PM 4/9/01 -0400, Richard Huber wrote: > >> This is not to say that designers of extensions should ignore > >> such considerations. Designers of extensions should consider all > >> aspects of the LDAP/X.500 data and service models including > >> replication. > >> > >So if your concern is with our proposed mechanism rather > than our goal, do > >you see some other way we can address the issue? > > Well, I think in the short term (from now to the time when an > LDUP Standard Track specification), I think the best way to > ensure that LDAP/X.500 data and service models issues are > addressed if for concerned members of the IETF to do appropriate > review of the documents as they are progressed though the IETF. > > If the LDUP requirement were to actually mandate a "Replication > Considerations" section, here are some samples which you will > likely get: > > 1) no section, the authors/review did not see the req't. > 2) no section, the authors/review don't believe any section can > be provided which adds value. For samples 1 & 2, I believe that during review of any I-D, several folks would be inclined to comment that no such sections exist and SHOULD, provided that the requirement is indeed present in an RFC. And that's a key point related to this discussion I believe. Until this requirement is published within an RFC, it carries no real weight for anyone outside of the Editors and participants of the LDUP WG. Which would lead me to believe that sample 3 is actually quite useful. I certainly want to know as an LDAP implementer (product or service) whether or not LDAP replication was considered during the design of any particular extension. And while its true that I will assume that such considerations have not been made if a replication considerations section is not present. I'm much more comfortable, speaking as an LDAP service implementer, not as co-chair, knowing that explicitly. So I disagree with your assertion that sample 3 is not useful. I wouldn't make reference to LDUP still being an active WG, but the message that LDAP replication was not considered is useful to me. > 3) section with: > "LDAP Replication was not considered as LDUP is a "work > in progress''." I think that sample 4 is a useful introductory sentence for such document sections. As a WG participant and LDAP service implementer, I'd be inclined to comment that more text should be included to explain any known limitations, constraints, etc., or a statement that none are known to exist. > 4) section with: > "This extension is designed to support LDAP replication > which is consistent with the LDAP/X.500 data and service > models." When it comes to sample 5, I'm inclined to agree that this is not all that useful as worded. However, to cover the situation it seems to be covering, I'd say that until the LDUP WG has concluded, it makes more sense to include a replication considerations section in LDAP extension I-Ds of the same form as sample 3. > 5) section with: > "This extension is designed to support LDUP, ''a work in > progress'', as currently designed but may not support > LDUP as defined in future Standard Track documents." > > None of these are particular useful. Until LDUP matures, > I don't see how any useful statement can actually be made. > > The problem is that the requirement, as stated, attempts to > mandate that all LDAP Standard Track specifications to express > considerations for a ''work in a progress''. This seems quite > inappropriate to me. You are correct. The present wording does mandate this. My proposed re-wording makes it more, but not completely, optional. However, I believe that replication considerations are important enough that not including such sections should be justified by good reasons in open discussion on a mailing list on a case-by-case basis. "Good" is of course subjective, and that's something that the collective IETF LDAP community should decide on a case-by-case basis. > > I would suggest instead of requiring the authors to document > such considerations you just say: > Authors of LDAP extensions SHOULD consider replication > issues. > As LDAP Replication is currently a "work in progress", > authors SHOULD note that any I-Ds detailing this work may be > updated, replaced, or obsoleted by other documents at any > time. I don't see a need to point out that I-Ds should not be viewed as definitive. There is boiler plate text to this effect that is supposed to be included with every I-D written. > I-Ds MUST NOT be viewed as a definitive. > > > > > As this is not a requirement upon LDUP, I would not enumerate > it as such. I would instead place in the Introduction. > I don't follow what you mean by the above statement. Are you recommending that this text be included in every LDAP extension draft? Chris. ------_=_NextPart_000_01C0C2A2.EC504D30 Content-Type: application/octet-stream; name="Christopher Apple (E-mail).vcf" Content-Disposition: attachment; filename="Christopher Apple (E-mail).vcf" BEGIN:VCARD VERSION:2.1 N:Apple;Christopher FN:Christopher 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 EMAIL;PREF;INTERNET:christopher.apple@unitedmessaging.com REV:20010405T144628Z END:VCARD ------_=_NextPart_000_01C0C2A2.EC504D30-- From owner-ietf-ldup@mail.imc.org Wed Apr 11 13:20:50 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA29271 for ; Wed, 11 Apr 2001 13:20:50 -0400 (EDT) Received: by above.proper.com (8.9.3/8.9.3) id JAA28534 for ietf-ldup-bks; Wed, 11 Apr 2001 09:43:05 -0700 (PDT) Received: from hawk.ummail.com (hawk.ummail.com [64.58.86.21]) by above.proper.com (8.9.3/8.9.3) with ESMTP id JAA28529 for ; Wed, 11 Apr 2001 09:43:04 -0700 (PDT) Received: from ex01.ummail.com [216.33.108.253:25] by hawk.ummail.com with SMTP id P0411-1242-610e00; Wed, 11 Apr 2001 16:42:18 GMT Received: by ex01.ummail.com with Internet Mail Service (5.5.2650.21) id <2B619XZ8>; Wed, 11 Apr 2001 12:42:03 -0400 Message-ID: From: Christopher Apple To: "'Kurt D. Zeilenga'" , Richard Huber Cc: ietf-ldup@imc.org Subject: RE: G9 requirement upon LDAP, not LDUP Date: Wed, 11 Apr 2001 12:42:02 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: multipart/mixed; boundary="----_=_NextPart_000_01C0C2A6.557737D0" 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_01C0C2A6.557737D0 Content-Type: text/plain; charset="iso-8859-1" RE: the issue of whether or not this requirement is in-scope for LDUP.....I'm conferring with Patrik, John, Mark, and Roland. Patrik is out on holiday now - it'll likely be a bit longer before we get some AD guidance on this matter. Outside of the scope issue - I still think the discussion we've been having on the LDUP list is useful. Regardless of where this sort of requirement ends up (or doesn't) it is a good thing to discuss the usefulness of such a requirement in the first place. Chris Apple Program Manager - Directory Services United Messaging Inc. http://www.unitedmessaging.com christopher.apple@unitedmessaging.com (V) 610-425-2860 ------_=_NextPart_000_01C0C2A6.557737D0 Content-Type: application/octet-stream; name="Christopher Apple (E-mail).vcf" Content-Disposition: attachment; filename="Christopher Apple (E-mail).vcf" BEGIN:VCARD VERSION:2.1 N:Apple;Christopher FN:Christopher 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 EMAIL;PREF;INTERNET:christopher.apple@unitedmessaging.com REV:20010405T144628Z END:VCARD ------_=_NextPart_000_01C0C2A6.557737D0-- From owner-ietf-ldup@mail.imc.org Wed Apr 11 14:25:25 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA00493 for ; Wed, 11 Apr 2001 14:25:24 -0400 (EDT) Received: by above.proper.com (8.9.3/8.9.3) id KAA02753 for ietf-ldup-bks; Wed, 11 Apr 2001 10:54:04 -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 KAA02749 for ; Wed, 11 Apr 2001 10:54:03 -0700 (PDT) Received: from gypsy.OpenLDAP.org (root@router.boolean.net [198.144.206.49]) by pretender.boolean.net (8.11.1/8.11.1/Boolean/Hub) with ESMTP id f3BHucD40733; Wed, 11 Apr 2001 17:56:38 GMT (envelope-from Kurt@OpenLDAP.org) Message-Id: <5.0.2.1.0.20010411101118.00af8060@127.0.0.1> X-Sender: guru@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 5.0.2 Date: Wed, 11 Apr 2001 10:56:33 -0700 To: Christopher Apple From: "Kurt D. Zeilenga" Subject: RE: G9 requirement upon LDAP, not LDUP Cc: Richard Huber , ietf-ldup@imc.org In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-ldup@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: At 12:17 PM 4/11/01 -0400, Christopher Apple wrote: >And that's a key point related to this discussion I believe. Until >this requirement is published within an RFC, it carries no real >weight for anyone outside of the Editors and participants of the >LDUP WG. I disagree here. This is being published as an Informational RFC. It will have weight upon the LDUP WG only because the LDUP charter says that the approach used to produce LDUP will be driven by these requirements. WG/Individuals producing of other Standard Track LDAP extensions have some obligations to consider the work of others, I don't think such a requirement carries any real weight upon the WG/Individuals. I am quite concerned that such a requirement statement would lead to appeals on future documents based not on technical issues, but based upon compliance with an Informational RFC which they were not bound to though some charter or other process mechanism. >"Good" is of course subjective, and that's something >that the collective IETF LDAP community should decide on >a case-by-case basis. Yes! I trust that the Internet Process will ensure that any LDAP replication issues anyone might have will be addressed in future Standard Track specifications. >> As this is not a requirement upon LDUP, I would not enumerate >> it as such. I would instead place in the Introduction. >> > >I don't follow what you mean by the above statement. I was suggesting the alternative statement I offered be placed in the Introduction of the LDUP Requirements I-D. Kurt From owner-ietf-ldup@mail.imc.org Wed Apr 11 14:57:11 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA01070 for ; Wed, 11 Apr 2001 14:57:10 -0400 (EDT) Received: (from majordomo@localhost) by above.proper.com (8.9.3/8.9.3) id LAA03948 for ietf-ldup-bks; Wed, 11 Apr 2001 11:21:55 -0700 (PDT) Received: from hawk.ummail.com (hawk.ummail.com [216.33.108.202]) by above.proper.com (8.9.3/8.9.3) with ESMTP id LAA03942 for ; Wed, 11 Apr 2001 11:21:53 -0700 (PDT) Received: from ex01.ummail.com [216.33.108.253:25] by hawk.ummail.com with SMTP id P0411-1421-62af00; Wed, 11 Apr 2001 18:21:40 GMT Received: by ex01.ummail.com with Internet Mail Service (5.5.2650.21) id <2B6195QZ>; Wed, 11 Apr 2001 14:21:24 -0400 Message-ID: From: "Christopher Apple(EXCHANGE)" To: "'Kurt D. Zeilenga'" Cc: Richard Huber , ietf-ldup@imc.org Subject: RE: G9 requirement upon LDAP, not LDUP Date: Wed, 11 Apr 2001 14:21:21 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: multipart/mixed; boundary="----_=_NextPart_000_01C0C2B4.357955E0" 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_01C0C2B4.357955E0 Content-Type: text/plain; charset="iso-8859-1" Comments below.... Chris Apple Program Manager - Directory Services United Messaging Inc. http://www.unitedmessaging.com christopher.apple@unitedmessaging.com (V) 610-425-2860 > -----Original Message----- > From: Kurt D. Zeilenga [mailto:Kurt@OpenLDAP.org] > Sent: Wednesday, April 11, 2001 1:57 PM > To: Christopher Apple > Cc: Richard Huber; ietf-ldup@imc.org > Subject: RE: G9 requirement upon LDAP, not LDUP > > > At 12:17 PM 4/11/01 -0400, Christopher Apple wrote: > >And that's a key point related to this discussion I believe. Until > >this requirement is published within an RFC, it carries no real > >weight for anyone outside of the Editors and participants of the > >LDUP WG. > > I disagree here. This is being published as an Informational RFC. > It will have weight upon the LDUP WG only because the LDUP charter > says that the approach used to produce LDUP will be driven by these > requirements. WG/Individuals producing of other Standard Track LDAP > extensions have some obligations to consider the work of others, > I don't think such a requirement carries any real weight upon the > WG/Individuals. > > I am quite concerned that such a requirement statement would lead to > appeals on future documents based not on technical issues, but based > upon compliance with an Informational RFC which they were not bound to > though some charter or other process mechanism. > > >"Good" is of course subjective, and that's something > >that the collective IETF LDAP community should decide on > >a case-by-case basis. > > Yes! I trust that the Internet Process will ensure that any > LDAP replication issues anyone might have will be addressed in > future Standard Track specifications. > In principal, we agree then that the actual inclusion of such a section should be decided according to normal IETF processes. That doesn't mean that you have to avoid reducing to writing a non-mandatory requirement to include a replication considerations section in future LDAP extension I-Ds, at least as a reminder that there should be a good reason for not doing so. That may be our most significant point of disagreement. Lets leave the issue of whether or not it belongs in this document alone until we hear from Patrik. I think we have to do that since you have requested that its scope be reviewed. With that said, I do feel very strongly that such a requirement should be written down in *some* document that is intended to result in LDAPv3 Extension editors being required to add a section on replication considerations or have a good reason for not doing so (and I can think of no good reason for not doing so, even if the section contains boiler plate text stating that it is not known whether this extension will work in a replicated environment or not). Whether or not a requirement of this nature belongs in this document, I'm beginning to doubt somewhat myself. But I'm not quite where you are just yet.... > >> As this is not a requirement upon LDUP, I would not enumerate > >> it as such. I would instead place in the Introduction. > >> > > > >I don't follow what you mean by the above statement. > > I was suggesting the alternative statement I offered be placed in > the Introduction of the LDUP Requirements I-D. OK. Got what you are suggesting. Think we need to wait for Patrik to respond. Chris. > > Kurt > ------_=_NextPart_000_01C0C2B4.357955E0 Content-Type: application/octet-stream; name="Christopher Apple (E-mail).vcf" Content-Disposition: attachment; filename="Christopher Apple (E-mail).vcf" BEGIN:VCARD VERSION:2.1 N:Apple;Christopher FN:Christopher 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 EMAIL;PREF;INTERNET:christopher.apple@unitedmessaging.com REV:20010405T144628Z END:VCARD ------_=_NextPart_000_01C0C2B4.357955E0-- From owner-ietf-ldup@mail.imc.org Wed Apr 11 15:03:39 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA01212 for ; Wed, 11 Apr 2001 15:03:39 -0400 (EDT) Received: by above.proper.com (8.9.3/8.9.3) id LAA04408 for ietf-ldup-bks; Wed, 11 Apr 2001 11:30:55 -0700 (PDT) Received: from hawk.ummail.com (hawk.ummail.com [64.58.86.21]) by above.proper.com (8.9.3/8.9.3) with ESMTP id LAA04403 for ; Wed, 11 Apr 2001 11:30:53 -0700 (PDT) Received: from ex01.ummail.com [216.33.108.253:25] by hawk.ummail.com with SMTP id P0411-1430-780900; Wed, 11 Apr 2001 18:30:06 GMT Received: by ex01.ummail.com with Internet Mail Service (5.5.2650.21) id <2B6195Y2>; Wed, 11 Apr 2001 14:29:49 -0400 Message-ID: From: "Christopher Apple(EXCHANGE)" To: "'Kurt D. Zeilenga'" Cc: "'Richard Huber'" , "'ietf-ldup@imc.org'" Subject: RE: G9 requirement upon LDAP, not LDUP Date: Wed, 11 Apr 2001 14:29:48 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: multipart/mixed; boundary="----_=_NextPart_000_01C0C2B5.63DD98F0" 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_01C0C2B5.63DD98F0 Content-Type: text/plain; charset="iso-8859-1" > -----Original Message----- [SNIP] > With that said, I do feel very strongly that such a requirement > should be written down in *some* document that is intended to > result in LDAPv3 Extension editors being required to add a section > on replication considerations or have a good reason for not doing so > (and I can think of no good reason for not doing so, even if the > section contains boiler plate text stating that it is not known > whether this extension will work in a replicated environment or not). Note that I've changed my own position on what a good reason could be for not including such a document section....I don't think its a good idea to leave the section out at all. Even if all it says is the equivalent of "not considered," I really want to know that as a service implementer. I believe that drafts produced before LDUP concludes its work should have such a section. The content of that section I'm flexible about. I doubt that it would be a good idea to refer to LDUP as a WG or as "work-in-progress" by referencing the WG acronym in such sections. But until we have a real situation, debating that issue seems moot. [SNIP] Chris Apple Program Manager - Directory Services United Messaging Inc. http://www.unitedmessaging.com christopher.apple@unitedmessaging.com (V) 610-425-2860 ------_=_NextPart_000_01C0C2B5.63DD98F0 Content-Type: application/octet-stream; name="Christopher Apple (E-mail).vcf" Content-Disposition: attachment; filename="Christopher Apple (E-mail).vcf" BEGIN:VCARD VERSION:2.1 N:Apple;Christopher FN:Christopher 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 EMAIL;PREF;INTERNET:christopher.apple@unitedmessaging.com REV:20010405T144628Z END:VCARD ------_=_NextPart_000_01C0C2B5.63DD98F0-- From owner-ietf-ldup@mail.imc.org Wed Apr 11 21:30: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 VAA06057 for ; Wed, 11 Apr 2001 21:30:25 -0400 (EDT) Received: (from majordomo@localhost) by above.proper.com (8.9.3/8.9.3) id RAA02100 for ietf-ldup-bks; Wed, 11 Apr 2001 17:50:28 -0700 (PDT) Received: from arnie.adacel.com.au (arnie.adacel.com.au [203.36.26.147]) by above.proper.com (8.9.3/8.9.3) with SMTP id RAA02079 for ; Wed, 11 Apr 2001 17:50:23 -0700 (PDT) Received: (qmail 25721 invoked from network); 12 Apr 2001 00:56:26 -0000 Received: from unknown (HELO osmium) (203.8.85.176) by arnie.adacel.com.au with SMTP; 12 Apr 2001 00:56:26 -0000 Reply-To: From: "Steven Legg" To: "'Ed Reed'" Cc: Subject: RE: no-copy control requirement Date: Thu, 12 Apr 2001 10:52:49 +1000 Message-ID: <001001c0c2ea$e59fba00$b05508cb@osmium.adacel.com.au> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook 8.5, Build 4.71.2377.0 In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V4.72.2120.0 Importance: Normal Sender: owner-ietf-ldup@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit Ed, Ed Reed wrote: > Steve - sounds like a good approach, to me. This also sounds > like a control > definition that needs to be defined...but where? doesn't > make sense to > do it in the mandatory to implement management operations doc, nor > the info model. The control itself deserves its own ID, however some of the model aspects belong elsewhere. It makes sense to me for the four entry copy states to be described by the info model, where they can be referenced by any knowledge/distribution model documents and the control's specification, among other things. > Perhaps it's time to create a single LDAP control that embodies the > common arguments that are otherwise missing from X.500 DAP? I take it you mean a control for X.500 CommonArguments facilities missing from LDAP rather than a control for facilities missing from the X.500 CommonArguments. Isn't English wonderfully ambiguous ? I recall the former being suggested in the past, but not receiving much support. One difficulty is that extending such a control requires the involvement and cooperation of the X.500 working group. Such an extension would be required to handle the richer replica copy selection cases that arise due to multi-master replication. Anyway, I'm in favour since I already support CommonArguments for DAP. > That > way they'd be there syntactally, whether actually in use or not, and > the groundwork would be made for promoting LDAP to DAP in the > long run (just had to throw that it - its starting to make > sense to me). Especially now that the X.500 protocols can be implemented over TCP/IP without the OSI stack. Regards, Steven > > Whachathink? > > Ed > > ================= > Ed Reed > Reed-Matthews, Inc. > +1 801 796 7065 > http://www.Reed-Matthews.COM > > >>> "Steven Legg" 04/09/01 10:29PM >>> > > Ed, > > In X.500 single master replication an entry is either a > master (modifiable) > copy or a shadow (read-only) copy. For every shadow entry there is a > corresponding master entry, transient inconsistency notwithstanding. > In our current multimaster architecture an entry is either a > shadow copy, > a co-mastered copy or a single-mastered copy. There is either one > single-mastered copy of an entry within the replica group or > two or more > co-mastered copies. If we use a no-copy *bit* then we have to decide > whether it means don't use shadow entries or don't use shadow or > co-mastered entries. If it means the latter then an operation > should be > failed if no-copy is requested but the entry is co-mastered. > > If one master replica is nominated as some sort of primary > then we have > four possible entry copy states: shadow, co-mastered, > primary-co-mastered > or single-mastered. An entry can have both co-mastered copies and a > primary-co-mastered copy within the replica group. > > A two-valued control isn't enough. We would want clients to be able to > request one of the four following treatments through a control. > > 1) Use any kind of copy. This case doesn't apply for updates. > > 2) Don't use shadow copies (use any mastered copy). This case > should be > the default when the control is absent. I'm inclined to map the X.500 > dontUseCopy service control to this case as well. This control setting > won't cause an operation to fail. > > 3) Don't use shadow or co-mastered copies (use primary-co-mastered or > single-mastered copies). The operation should be failed if there is > no primary-co-mastered or single-mastered copy. > > 4) Don't use shadow or co-mastered or primary-co-mastered copies > (use only single-mastered copies). The operation should be failed > if there is no single-mastered copy. > > If the control is expressive enough then we don't need to > *mandate* the > existence of a primary master replica. Clients decide if it matters to > them whether a primary master replica is actually deployed. > > For good measure we can also add a fifth case to the control: > > 5) Guarantee strong consistency. If the entry is single-mastered then > strong consistency is already assured, but if the entry is co-mastered > the control implies the client is requesting that a distributed update > be invoked - something like the locking solution John McGarvey is > talking about, or the strong consistency solution I sketched > out previously > on the mailing list. > > Regards, > Steven > > Ed Reed wrote: > > And, this would require either > > > > 1) reinstatement of the "primary" replica designation, as > the "owner" > > of all data in the replication area (not the same as the server to > > which all data modifications are made, but a "soft" designation for > > use by applications, like replica topology management, to use > > by common agreement as the single server to use so that such a > > "high confidence" or "no copy" bit can be made to make sense), or > > > > 2) carry sufficient information on each attribute value so that the > > server where that data was originally entered into the DIT can be > > identified (the CSN replica id may suffice), so that the client (or > > chaining or referring server) can individually contact each of the > > servers at which various values of attributes for the entry was > > entered and verify that the values read at the copy are still > > the values of record at the originating server. > > > > Of course, in a multi master environment, there's no guarantee > > that #2 above will actually contact a server where an update > > has occurred that has not yet propagated to either the DSA > > handling the no-copy request from the client (presuming it is > > either chaining or that it is trying hard to provide useful > > referral information to the client), or indeed to the DSA where > > the original value was entered. > > > > Using the approach in #1, it is possible for applications with > > single-master dependencies to algorithmically select a single > > master of all the master replicas (by looking at the replica types) > > to which to direct their modification operations, without unduely > > hindering other applications that dont' require such relatively > > high assurance consistency. But it does not give the client > > nor any server the omniscience required to locate as yet un- > > replicated changes among the replicas of the DIT. > > > > I don't know of other approaches to providing this non-LDAP > > control, but I agree its a necessary thing to define. I had > > thought it something to be defined as part of the distributed > > operations model of the directory, instead of the LDUP > > itself. > > > > It's also interesting to consider how the whole subject of > > referrals and how they're to be generated gathers the information > > to give to the client who wants to constrain itself to talking > > to data where "copy is not sufficient" constraints are in place. > > Another argument, in my view, of using information in the DIT > > that includes replica type knowlege, as the source of things > > like subordinate references (so references generated > > for clients who have asserted the "no copy" control will be > > correctly directed to the appropriate replica of the subordinate > > name space). > > > > Ed > > > > ================= > > Ed Reed > > Reed-Matthews, Inc. > > +1 801 796 7065 > > http://www.Reed-Matthews.COM > > > > >>> "Kurt D. Zeilenga" 04/09/01 01:29AM >>> > > X.500 replication model provide a mechanism for clients > > to state the operation should not be preformed on a > > copy of the entry. This is useful when the client > > needs to ensure it is operating upon the master DSA > > instead of a shadow DSA. There likely should be some > > requirement to support this feature in LDUP. > > > > Kurt > > > > > > > > From owner-ietf-ldup@mail.imc.org Thu Apr 12 12:02:12 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA03478 for ; Thu, 12 Apr 2001 12:02:11 -0400 (EDT) Received: (from majordomo@localhost) by above.proper.com (8.9.3/8.9.3) id IAA11736 for ietf-ldup-bks; Thu, 12 Apr 2001 08:10:55 -0700 (PDT) Received: from sj-msg-core-2.cisco.com (sj-msg-core-2.cisco.com [171.69.43.88]) by above.proper.com (8.9.3/8.9.3) with ESMTP id IAA11731 for ; Thu, 12 Apr 2001 08:10:53 -0700 (PDT) Received: from mira-sjcm-1.cisco.com (mira-sjcm-1.cisco.com [171.69.43.102]) by sj-msg-core-2.cisco.com (8.9.3/8.9.1) with ESMTP id IAA07020 for ; Thu, 12 Apr 2001 08:10:48 -0700 (PDT) Received: from JSTRASSN-W2K1.cisco.com ([171.69.108.130]) by mira-sjcm-1.cisco.com (Mirapoint) with ESMTP id AFP06728; Thu, 12 Apr 2001 08:10:21 -0700 (PDT) Message-Id: <4.3.2.7.2.20010412080832.00b1d950@mira-sjcm-1.cisco.com> X-Sender: jstrassn@mira-sjcm-1.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Thu, 12 Apr 2001 08:10:07 -0700 To: ietf-ldup@imc.org From: John Strassner Subject: Last chance for comments Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ietf-ldup@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: LDUPers, this is the last chance to get me any comments and corrections before the meeting minutes are submitted. You have till 8am PST tomorrow, Friday the 13th. regards, John >X-Sender: jstrassn@mira-sjcm-1.cisco.com >X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 >Date: Wed, 04 Apr 2001 15:23:54 -0700 >To: ietf-ldup@imc.org >From: John Strassner >Subject: WG Meeting Minutes >Sender: owner-ietf-ldup@mail.imc.org >List-Archive: >List-ID: >List-Unsubscribe: > >Greetings LDUPers, > >below please find the draft meeting minutes for the San Diego meeting. >Please submit any comments and corrections to me asap so that I can >include these in the official minutes. And thanks presenters, I already >have all of your slides for inclusion. > >regards, John Strassner >LDUP WG Co-Chair > >====================== SNIP HERE ========================== >Draft Summary and Meeting Minutes LDUP Working Group Meeting 50th IETF, >Minneapolis Minutes recorded by John Strassner, March 19, 2000 > >The agenda was presented by John, and no adjustments were made. > >Discussion of Changes Made to Requirements I-D > draft-ietf-ldup-replica-req-07 > >The discussion was led by one of the co-authors, Rick Huber. > >A summary of the changes made in response to Last Call comments was >presented. The key points are as follows: > > - interoperability paragraph was rewritten and clarified > - replaced the term "naming context" with the term "replication base entry" > - replaced the term "replica ring" with the term "replica group" > - deprecated the term "updateable replicas" > - clarified model 1 and multi-master atomicity > - requirements G9-G11 were added to cover what needs to be replicated > at the attribute level > - M3 was reworded for clarity > - requirement P2 was split into two requirements, P2 and P3, > and all subsequent P requirements were renumbered > - moved (the old) P7 to G8 since it is not limited to protocol > - rewrote P6 (now P7) to explicitly require propagation of > atomicity of LDAP operations as defined in 2251 > - explicitly noted (ongoing) ACL work in the security section > - made text in section A.10 self-consistent > - changed text in B.5.5 to clarify the term "at the same time" > >Questions: > -Ellen asked about other documents that need to be brought in > line. Will be > tabled until later in the meeting > -A question of why "updateable replica" was deprecated. It comes from > Kurt's mail. > -Point that P7 moving to G8 makes G2 and G8 copies of each other; > authors to > address this in the next revision of the requirements draft > >Rich then presented items that were deferred. The key points were: > > - external locking will be addressed in the profiles I-D > - clarified that the term "area of replication" is > equivalent to X.525's term "replicated area" > >Question: > -Point about "area of replication" and X.525 "replicated area" brought > the comment from Ed that the only requirement for LDUP is to define the > contiguous sub-tree. Kurt wants a note that LDUP protocol may define > it own administrative model. Request that the area of replication is > a subset of X.500 and that the administrative model...authors seemed > to agree > >Next steps: > >The authors will issue a new draft (-08) ASAP and are requesting another >WG last call. John urged all members to *please* get their comments in >this week or as soon as the document was issued so that the authors would >have time to address any additional comments before doing another last call. > >Kurt wanted to know if this is really necessary? John responded yes, >because technical changes have been made. John asked the meeting >participants if anyone had any objections to the requirements draft going >to last call, and there were no objections. Kurt said that he would look >at the security section. > >================================================ > >Discussion of Usage Profile I-D > draft-ietf-ldup-usage-profile-00.txt > >The discussion was led by Rick Huber, one of the co-authors of the draft. > >Rick gave an overview of the -00 draft. Its scope is to discuss the design >and development issues that may arise due to using replication in >directory deployments. The document will discuss both single- and >multi-master scenarios. The authors encourage any application-specific >profiles to be added. > >Next steps would be to add a discussion of external locking from the >requirements draft, and to discuss different ways to preserve atomicity >across replication. > >The authors wanted to know whether the target track for this draft should >be informational or BCP. The sense of the room was that this should be an >informational track document, as there isn't a set of standards from which >to recommend best current practices. > >John noted that this draft contains multi-master and master-slave >profiles, so the charter needs correction. John further noted that this is >a working, living draft, and not ready for last call any time soon. John >urged everyone to read the draft and submit comments asap, in order to >help the authors develop the next version of the draft. > >=========================================================== > >Discussion of Changes Made to Architecture Document > draft-ietf-ldup-model-06.txt > >This discussion was led by Ed Reed, one of the authors of the draft. The >authors think that it is ready for WG Last Call. This version is based >largely on the comments made by Tim Hahn. The discussion of policy >inheritance was removed from the document and placed into a new I-D. The >one outstanding item that the authors know needs to be removed is to drop >a reference to search filter visibility of subentries. > >Question from the floor - how well does this version correlate with the >requirements document? A lengthy discussion then ensued. However, one of >the major questions that arose was, what happened with operations that >cross replication boundaries? How should they be handled? > >The answer lies in the direction of a distributed directory, but LDAP >doesn't yet have a truly distributed model. LDAP Subentry can help. >Problem with deleting superiors that have subordinate reference - you >either delete the subordinate, move it to Lost+Found, or say that the >operation is not allowed because it has children. But this last option is >NOT currently in LDAP. > >More general question is, how do you take two portions of the namespace, >where the superior and the subordinate are in different partitions? Note >that you have DSE types - the object is in one management plane and the >subordinate is in another management plane (note that LDAP doesn't have >DSEs). We need to look at the namedref document. > >Both LDAPext and LDUP have a stake in how this comes out. In an LDAP >environment, this is an issue that crops up regardless of whether there is >replication. > >Since this appears to be a significant design issue, John called for a >group of volunteers to form a design team to study and resolve this >problem. The volunteers were: > >John McMeeking >Mark Smith >Mark Wahl >Skip Sloane >Steve Mclane >Kurt Zeilenga >Ed Reed > >This design team's first meeting is tomorrow at 3pm. They will report back >to the LDUP WG. Their feedback will then be incorporated into the draft. > >====================================================== > >Discussion on URP - ready for Last Call or not? > draft-ietf-ldup-urp-03.txt > >Unfortunately, neither of the authors could attend this meeting due to >work and illness. John relayed this information. > >With respect to the draft, it has timed out, and needs to be reissued. >Note that it should be compared against the requirements draft, and >nothing will happen until the requirements doc passes WG Last Call. > >======================================================= > >Discussion on the LDUP Replication Update Protocol > draft-ietf-ldup-protocol-02.txt > >The discussion was led by Ellen Stokes, one of the authors of the draft. > >This draft has timed out and needs to be reissued. Ellen suggested a hard >deadline of Friday the 13th [ed: honest! ;-) ] of April due for an update >due to a hard vacation deadline; Roger Harrison to give Ellen an update >tomorrow. This document **appears** to be ready for Last Call - only minor >comments were posted in the last revision. Poll of room - no negative >comments, Roger thinks that it probably is ready as he has been through >the document. > >========================================== > >Discussion on LDUP Subentry Schema > draft-ietf-ldup-subentry-07.txt > >This discussion was led by Ed Reed, one of the authors of the draft. Note >that this is a product of both the LDUP and the LDAPext WGs. > >Issued version 7. Main changes included separating the inheritance >discussion, and put that in a separate document >(draft-reed-ldup-inheritance-00.txt). Removed the search-filter mechanism >for visibility. The search operation behaves as though the visibility >control is present, even though it isn't. In other words, it doesn't make >any sense if you have used an LDAP Subentry as the base object of the >search, and you didn't include the control to return the results of the >search. Kurt pointed out that since these may be nested, and if the base >object of the search is a subentry, then you should behave as if the >control is present. Ed agreed. > >A discussion followed clarifying other operations. It was agreed that if >the control is present and true, all you get is subentries, otherwise you >do not get subentries. Kurt and Ed will recheck the draft one last time to >be sure that this (and the above) behavior is specified this way in the draft. > >Ed agreed to add the description of an administrative area, and then state >that you can't replicate either a rootDSE or any subentries of the rootDSE. > >The purpose of InheritableLDAPSubentry was to provide an example of how to >add inheritance to policy. After a short discussion, it was agreed in the >room that it would be best to remove this from the draft. > >====================================================== > >Discussion of Policy Inheritance Mechanisms for LDAP > draft-reed-ldup-inheritance-00.txt > >Ed made a short presentation Ed said that he would make these changes and >try and publish the document asap. Ed further stated that he will actively >look for an author to take up the inheritance work, because otherwise he >will let it die. > >=============================================== > >Discussion on LDAP Client Update Protocol > draft-natkovich-ldap-lcup-02.txt > >(Chair note: please resubmit this draft with as a wg draft (i.e., >draft-ietf-ldup-lcup-00.txt) > >This discussion was led by Mark Smith, one of the authors of the draft. > >Rich Megginson has taken over editing. It has been reviewed by the >authors. No substantial changes, but a fair amount of clarifying text. >Note that this is not really a -00, as there were several versions of >persistent and triggered search, and lcup as an individual submission. > >Still some open issues in the document, so we need to decide as a group >whether to punt because they are out of scope or not. > >It was noted that LCUP is replacing triggered search, persistent search, >and dirSync. > >====================================================== > >Discussion of other missing drafts > >John McMeeking and Ryan have offered to take up the Mandatory Replica >Management draft. Tim Hahn has offered to take up the Infomod draft. > >====================================================== > >Any other business > >It has become apparent that, after listening to the discussions on >progress of the various drafts, that two things are missing. They are: > > - we need common naming and terminology applied to all drafts > - we need someone to compare the requirements document to the other drafts > >John suggested that the co-chairs perform this policing (volunteers are >solicited and welcome!). Draft authors can't really review the drafts for >these points, as they already should be doing this, and we need >independent people doing this review. > >End of meeting. From owner-ietf-ldup@mail.imc.org Thu Apr 12 13:31:20 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA05567 for ; Thu, 12 Apr 2001 13:31:19 -0400 (EDT) Received: (from majordomo@localhost) by above.proper.com (8.9.3/8.9.3) id JAA21421 for ietf-ldup-bks; Thu, 12 Apr 2001 09:44:39 -0700 (PDT) Received: from relay1.pair.com (relay1.pair.com [209.68.1.20]) by above.proper.com (8.9.3/8.9.3) with SMTP id JAA21416 for ; Thu, 12 Apr 2001 09:44:37 -0700 (PDT) Received: (qmail 22642 invoked from network); 12 Apr 2001 16:43:54 -0000 Received: from cpe-144-132-70-18.vic.bigpond.net.au (HELO w98) (144.132.70.18) by relay1.pair.com with SMTP; 12 Apr 2001 16:43:54 -0000 X-pair-Authenticated: 144.132.70.18 Reply-To: From: "Albert Langer" To: "'John Strassner'" , Subject: RE: Last chance for comments Date: Fri, 13 Apr 2001 02:43:20 +1000 Message-ID: <000001c0c36f$afa842c0$6628a8c0@nowhere.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2910.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Importance: Normal In-Reply-To: <4.3.2.7.2.20010412080832.00b1d950@mira-sjcm-1.cisco.com> Sender: owner-ietf-ldup@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit I am assuming that this will be taken to be an accurate record of discussions at the WG meeting unless corrected now. Naturally I have no comments as I wasn't there. I am also assuming that any specific technical decisions (as opposed to next steps, action items, sense of the room etc referred to in the minutes), on which a rough consensus of the WG is to be determined will be put separately to the WG list. I see nothing in these minutes contrary to that assumption and am not seeking a reply, while still waiting patiently for a response to my appeal concerning John's conduct during the last WG final call. But I am spelling it out, to minimize any surprise at the more vigorous response that would result from even passing references as WG co-chair to an alleged WG consensus decision next time. -----Original Message----- From: owner-ietf-ldup@mail.imc.org [mailto:owner-ietf-ldup@mail.imc.org]On Behalf Of John Strassner Sent: Friday, April 13, 2001 1:10 AM To: ietf-ldup@imc.org Subject: Last chance for comments LDUPers, this is the last chance to get me any comments and corrections before the meeting minutes are submitted. You have till 8am PST tomorrow, Friday the 13th. regards, John >X-Sender: jstrassn@mira-sjcm-1.cisco.com >X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 >Date: Wed, 04 Apr 2001 15:23:54 -0700 >To: ietf-ldup@imc.org >From: John Strassner >Subject: WG Meeting Minutes >Sender: owner-ietf-ldup@mail.imc.org >List-Archive: >List-ID: >List-Unsubscribe: > >Greetings LDUPers, > >below please find the draft meeting minutes for the San Diego meeting. >Please submit any comments and corrections to me asap so that I can >include these in the official minutes. And thanks presenters, I already >have all of your slides for inclusion. > >regards, John Strassner >LDUP WG Co-Chair > >====================== SNIP HERE ========================== >Draft Summary and Meeting Minutes LDUP Working Group Meeting 50th IETF, >Minneapolis Minutes recorded by John Strassner, March 19, 2000 > >The agenda was presented by John, and no adjustments were made. > >Discussion of Changes Made to Requirements I-D > draft-ietf-ldup-replica-req-07 > >The discussion was led by one of the co-authors, Rick Huber. > >A summary of the changes made in response to Last Call comments was >presented. The key points are as follows: > > - interoperability paragraph was rewritten and clarified > - replaced the term "naming context" with the term "replication base entry" > - replaced the term "replica ring" with the term "replica group" > - deprecated the term "updateable replicas" > - clarified model 1 and multi-master atomicity > - requirements G9-G11 were added to cover what needs to be replicated > at the attribute level > - M3 was reworded for clarity > - requirement P2 was split into two requirements, P2 and P3, > and all subsequent P requirements were renumbered > - moved (the old) P7 to G8 since it is not limited to protocol > - rewrote P6 (now P7) to explicitly require propagation of > atomicity of LDAP operations as defined in 2251 > - explicitly noted (ongoing) ACL work in the security section > - made text in section A.10 self-consistent > - changed text in B.5.5 to clarify the term "at the same time" > >Questions: > -Ellen asked about other documents that need to be brought in > line. Will be > tabled until later in the meeting > -A question of why "updateable replica" was deprecated. It comes from > Kurt's mail. > -Point that P7 moving to G8 makes G2 and G8 copies of each other; > authors to > address this in the next revision of the requirements draft > >Rich then presented items that were deferred. The key points were: > > - external locking will be addressed in the profiles I-D > - clarified that the term "area of replication" is > equivalent to X.525's term "replicated area" > >Question: > -Point about "area of replication" and X.525 "replicated area" brought > the comment from Ed that the only requirement for LDUP is to define the > contiguous sub-tree. Kurt wants a note that LDUP protocol may define > it own administrative model. Request that the area of replication is > a subset of X.500 and that the administrative model...authors seemed > to agree > >Next steps: > >The authors will issue a new draft (-08) ASAP and are requesting another >WG last call. John urged all members to *please* get their comments in >this week or as soon as the document was issued so that the authors would >have time to address any additional comments before doing another last call. > >Kurt wanted to know if this is really necessary? John responded yes, >because technical changes have been made. John asked the meeting >participants if anyone had any objections to the requirements draft going >to last call, and there were no objections. Kurt said that he would look >at the security section. > >================================================ > >Discussion of Usage Profile I-D > draft-ietf-ldup-usage-profile-00.txt > >The discussion was led by Rick Huber, one of the co-authors of the draft. > >Rick gave an overview of the -00 draft. Its scope is to discuss the design >and development issues that may arise due to using replication in >directory deployments. The document will discuss both single- and >multi-master scenarios. The authors encourage any application-specific >profiles to be added. > >Next steps would be to add a discussion of external locking from the >requirements draft, and to discuss different ways to preserve atomicity >across replication. > >The authors wanted to know whether the target track for this draft should >be informational or BCP. The sense of the room was that this should be an >informational track document, as there isn't a set of standards from which >to recommend best current practices. > >John noted that this draft contains multi-master and master-slave >profiles, so the charter needs correction. John further noted that this is >a working, living draft, and not ready for last call any time soon. John >urged everyone to read the draft and submit comments asap, in order to >help the authors develop the next version of the draft. > >=========================================================== > >Discussion of Changes Made to Architecture Document > draft-ietf-ldup-model-06.txt > >This discussion was led by Ed Reed, one of the authors of the draft. The >authors think that it is ready for WG Last Call. This version is based >largely on the comments made by Tim Hahn. The discussion of policy >inheritance was removed from the document and placed into a new I-D. The >one outstanding item that the authors know needs to be removed is to drop >a reference to search filter visibility of subentries. > >Question from the floor - how well does this version correlate with the >requirements document? A lengthy discussion then ensued. However, one of >the major questions that arose was, what happened with operations that >cross replication boundaries? How should they be handled? > >The answer lies in the direction of a distributed directory, but LDAP >doesn't yet have a truly distributed model. LDAP Subentry can help. >Problem with deleting superiors that have subordinate reference - you >either delete the subordinate, move it to Lost+Found, or say that the >operation is not allowed because it has children. But this last option is >NOT currently in LDAP. > >More general question is, how do you take two portions of the namespace, >where the superior and the subordinate are in different partitions? Note >that you have DSE types - the object is in one management plane and the >subordinate is in another management plane (note that LDAP doesn't have >DSEs). We need to look at the namedref document. > >Both LDAPext and LDUP have a stake in how this comes out. In an LDAP >environment, this is an issue that crops up regardless of whether there is >replication. > >Since this appears to be a significant design issue, John called for a >group of volunteers to form a design team to study and resolve this >problem. The volunteers were: > >John McMeeking >Mark Smith >Mark Wahl >Skip Sloane >Steve Mclane >Kurt Zeilenga >Ed Reed > >This design team's first meeting is tomorrow at 3pm. They will report back >to the LDUP WG. Their feedback will then be incorporated into the draft. > >====================================================== > >Discussion on URP - ready for Last Call or not? > draft-ietf-ldup-urp-03.txt > >Unfortunately, neither of the authors could attend this meeting due to >work and illness. John relayed this information. > >With respect to the draft, it has timed out, and needs to be reissued. >Note that it should be compared against the requirements draft, and >nothing will happen until the requirements doc passes WG Last Call. > >======================================================= > >Discussion on the LDUP Replication Update Protocol > draft-ietf-ldup-protocol-02.txt > >The discussion was led by Ellen Stokes, one of the authors of the draft. > >This draft has timed out and needs to be reissued. Ellen suggested a hard >deadline of Friday the 13th [ed: honest! ;-) ] of April due for an update >due to a hard vacation deadline; Roger Harrison to give Ellen an update >tomorrow. This document **appears** to be ready for Last Call - only minor >comments were posted in the last revision. Poll of room - no negative >comments, Roger thinks that it probably is ready as he has been through >the document. > >========================================== > >Discussion on LDUP Subentry Schema > draft-ietf-ldup-subentry-07.txt > >This discussion was led by Ed Reed, one of the authors of the draft. Note >that this is a product of both the LDUP and the LDAPext WGs. > >Issued version 7. Main changes included separating the inheritance >discussion, and put that in a separate document >(draft-reed-ldup-inheritance-00.txt). Removed the search-filter mechanism >for visibility. The search operation behaves as though the visibility >control is present, even though it isn't. In other words, it doesn't make >any sense if you have used an LDAP Subentry as the base object of the >search, and you didn't include the control to return the results of the >search. Kurt pointed out that since these may be nested, and if the base >object of the search is a subentry, then you should behave as if the >control is present. Ed agreed. > >A discussion followed clarifying other operations. It was agreed that if >the control is present and true, all you get is subentries, otherwise you >do not get subentries. Kurt and Ed will recheck the draft one last time to >be sure that this (and the above) behavior is specified this way in the draft. > >Ed agreed to add the description of an administrative area, and then state >that you can't replicate either a rootDSE or any subentries of the rootDSE. > >The purpose of InheritableLDAPSubentry was to provide an example of how to >add inheritance to policy. After a short discussion, it was agreed in the >room that it would be best to remove this from the draft. > >====================================================== > >Discussion of Policy Inheritance Mechanisms for LDAP > draft-reed-ldup-inheritance-00.txt > >Ed made a short presentation Ed said that he would make these changes and >try and publish the document asap. Ed further stated that he will actively >look for an author to take up the inheritance work, because otherwise he >will let it die. > >=============================================== > >Discussion on LDAP Client Update Protocol > draft-natkovich-ldap-lcup-02.txt > >(Chair note: please resubmit this draft with as a wg draft (i.e., >draft-ietf-ldup-lcup-00.txt) > >This discussion was led by Mark Smith, one of the authors of the draft. > >Rich Megginson has taken over editing. It has been reviewed by the >authors. No substantial changes, but a fair amount of clarifying text. >Note that this is not really a -00, as there were several versions of >persistent and triggered search, and lcup as an individual submission. > >Still some open issues in the document, so we need to decide as a group >whether to punt because they are out of scope or not. > >It was noted that LCUP is replacing triggered search, persistent search, >and dirSync. > >====================================================== > >Discussion of other missing drafts > >John McMeeking and Ryan have offered to take up the Mandatory Replica >Management draft. Tim Hahn has offered to take up the Infomod draft. > >====================================================== > >Any other business > >It has become apparent that, after listening to the discussions on >progress of the various drafts, that two things are missing. They are: > > - we need common naming and terminology applied to all drafts > - we need someone to compare the requirements document to the other drafts > >John suggested that the co-chairs perform this policing (volunteers are >solicited and welcome!). Draft authors can't really review the drafts for >these points, as they already should be doing this, and we need >independent people doing this review. > >End of meeting. From owner-ietf-ldup@mail.imc.org Fri Apr 13 01:35:04 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id BAA21915 for ; Fri, 13 Apr 2001 01:35:03 -0400 (EDT) Received: by above.proper.com (8.9.3/8.9.3) id WAA27685 for ietf-ldup-bks; Thu, 12 Apr 2001 22:05:39 -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 WAA27680 for ; Thu, 12 Apr 2001 22:05:37 -0700 (PDT) Received: from gypsy.OpenLDAP.org (root@router.boolean.net [198.144.206.49]) by pretender.boolean.net (8.11.1/8.11.1/Boolean/Hub) with ESMTP id f3D532G01343 for ; Fri, 13 Apr 2001 05:03:03 GMT (envelope-from Kurt@OpenLDAP.org) Message-Id: <5.0.2.1.0.20010412211229.02be5c30@127.0.0.1> X-Sender: guru@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 5.0.2 Date: Thu, 12 Apr 2001 22:03:01 -0700 To: ietf-ldup@imc.org From: "Kurt D. Zeilenga" Subject: req't, security related comments Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-ldup@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: I suggest the term "data privacy" be replaced with "data confidentiality" within the requirements document as "data privacy" is somewhat confusing. I highly recommend use of RFC 2838 terminology be used in describing security requirements. > 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. > 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) > S3. To promote interoperability, there MUST be a mandatory-to- > implement data privacy mechanism. S3. To promote interoperability, there MUST be mandatory-to-implement data integrity and confidentiality protection mechanism. > S4. The transport for administrative access MUST permit assurance of > the integrity and privacy of all data transferred. Due to the rewording of S2, this would be redundant. 5. Security Considerations > As noted in Section 3, security may be impacted when replicating > among servers that implement non-standard extensions to basic > LDAP semantics. I note that security is also impacted by servers implementing standard extensions as well as differing optional features of the "core" protocol or implement same features in different ways. That is, the section 3 section: > 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). should be broaden to say: 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), or implement differing sets of optional features of the LDAP, or implement them in differently. I don't see why the document doesn't just say: Interoperability between independently developed implementations of LDAP servers using LDUP may be limited as LDAP has numerous optional features and extensions and allows for a wide range of implementation behavior. Kurt From owner-ietf-ldup@mail.imc.org Fri Apr 13 01:38:30 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id BAA22287 for ; Fri, 13 Apr 2001 01:38:28 -0400 (EDT) Received: by above.proper.com (8.9.3/8.9.3) id WAA27971 for ietf-ldup-bks; Thu, 12 Apr 2001 22:15:09 -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 WAA27967 for ; Thu, 12 Apr 2001 22:15:07 -0700 (PDT) Received: from gypsy.OpenLDAP.org (root@router.boolean.net [198.144.206.49]) by pretender.boolean.net (8.11.1/8.11.1/Boolean/Hub) with ESMTP id f3D5CXG01395 for ; Fri, 13 Apr 2001 05:12:33 GMT (envelope-from Kurt@OpenLDAP.org) Message-Id: <5.0.2.1.0.20010412220718.02be0ec0@127.0.0.1> X-Sender: guru@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 5.0.2 Date: Thu, 12 Apr 2001 22:12:32 -0700 To: ietf-ldup@imc.org From: "Kurt D. Zeilenga" Subject: req't, security related comments (CORRECTED) Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-ldup@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: [this post corrects a few typos including a key reference] I suggest the term "data privacy" be replaced with "data confidentiality" within the requirements document as "data privacy" is somewhat confusing. I highly recommend use of RFC 2828 terminology be used in describing security requirements. > 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. > 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) > S3. To promote interoperability, there MUST be a mandatory-to- > implement data privacy mechanism. S3. To promote interoperability, there MUST be a mandatory-to-implement data integrity and confidentiality protection mechanism. > S4. The transport for administrative access MUST permit assurance of > the integrity and privacy of all data transferred. Due to the rewording of S2, this would be redundant. 5. Security Considerations > As noted in Section 3, security may be impacted when replicating > among servers that implement non-standard extensions to basic > LDAP semantics. I note that security is also impacted by servers implementing standard extensions as well as differing optional features of the "core" protocol as well as by implementing same features in different ways. That is, the section 3 section: > 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 believe this should be broaden to say: 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), or implement differing sets of optional features of the LDAP, or implement them in differently. I don't see why the document doesn't just say: Interoperability between independently developed server implementations of LDAP using LDUP may be limited as LDAP has numerous optional features and extensions and allows for a wide range of implementation behavior. Kurt From owner-ietf-ldup@mail.imc.org Sat Apr 14 12:19:50 2001 Received: from above.proper.com ([208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA13464 for ; Sat, 14 Apr 2001 12:19:49 -0400 (EDT) Received: (from majordomo@localhost) by above.proper.com (8.9.3/8.9.3) id IAA14100 for ietf-ldup-bks; Sat, 14 Apr 2001 08:39:45 -0700 (PDT) Received: from KVRA ([211.217.77.46]) by above.proper.com (8.9.3/8.9.3) with ESMTP id IAA14071; Sat, 14 Apr 2001 08:39:40 -0700 (PDT) From: Sabrina_B@btts.net Message-ID: <000079eb7bf9$0000089b$000056d3@btts.net> To: Subject: Customer Care Center 22227 Date: Fri, 13 Apr 2001 06:05:59 -0800 MIME-Version: 1.0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Priority: 1 X-MSMail-Priority: High Sender: owner-ietf-ldup@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: quoted-printable = Take Control Of Your Conference Calls
Why Pay=
 More For Your Confere=
nce Calls?
Onl=
y .18 Cents per minute (Including long distance!)
=

          • =
No setup fees
          • No contracts or monthly fees
          • Call=
 anytime, from anywhere, to anywhere
          • International Dial In 18 cents per minut=
e
          • C=
onnects up to 100 participants
          • Operator Help available 24/7
            <=
/LI>
=
Get the best quality, the easiest to use,=
 and lowest rate in the industry.
<=
TR>
<=
FONT color=3D#ff0000 size=3D2>Required Input Field*
If you like saving money, fill out the form below and one of=
 our consultants will contact you.
<=
TBODY>
Web Address*
<=
/TR> <=
TD width=3D"51%"> <=
TR>
Name*
 
 
Company Name*
State
 
Business Phone*
 <=
/TD>
Home Phone
E-mail*
 
Type of Business
 =


       =
;            &=
nbsp;           &nb=
sp;  


This c=
ould be your ad!
Click here to e-mail us your contact info.
This email is to those persons that have contacted Con=
ference Calls for Less regarding available services or product information=
.  If this email is reaching you in error and you feel that you have not c=
ontacted us, click here. We apologize and will gladly remove you from our mail=
ing list.









From owner-ietf-ldup@mail.imc.org  Tue Apr 17 16:18:33 2001
Received: from above.proper.com (above.proper.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA15804
	for ; Tue, 17 Apr 2001 16:18:32 -0400 (EDT)
Received: by above.proper.com (8.9.3/8.9.3) id MAA11321
	for ietf-ldup-bks; Tue, 17 Apr 2001 12:43:39 -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 MAA11316
	for ; Tue, 17 Apr 2001 12:43:38 -0700 (PDT)
Received: from gypsy.OpenLDAP.org (root@router.boolean.net [198.144.206.49])
	by pretender.boolean.net (8.11.1/8.11.1/Boolean/Hub) with ESMTP id f3HJfKG29132;
	Tue, 17 Apr 2001 19:41:20 GMT
	(envelope-from Kurt@OpenLDAP.org)
Message-Id: <5.1.0.14.0.20010417112532.00aa1750@127.0.0.1>
X-Sender: guru@127.0.0.1
X-Mailer: QUALCOMM Windows Eudora Version 5.1
Date: Tue, 17 Apr 2001 12:41:19 -0700
To: ietf-ldapext@netscape.com
From: "Kurt D. Zeilenga" 
Subject: ACM & Replication (Was: LDAPEXT Minutes)
Cc: ietf-ldup@imc.org
In-Reply-To: <3ADC83B2.D25E2ECB@sun.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 10:56 AM 4/17/01, Mark Wahl wrote:
>ACL
> - replication requirements
>
>As John Strassner, co-chair of LDUP, requested that replication requirements 
>of a document should be addressed in the working group where the document is 
>authored, Rick Huber will incorporate replication requirements into the 
>access control drafts.

Is there a description of what "replication requirements" which
need to be addressed?  I can find no discussion of replication
requirements upon the LDAP ACM in RFC 2820 nor the LDUP requirements
document (though the latter details requirements upon LDUP to
replicate access control information).

Thanks, Kurt



From owner-ietf-ldup@mail.imc.org  Tue Apr 17 17:27: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 RAA16836
	for ; Tue, 17 Apr 2001 17:27:41 -0400 (EDT)
Received: by above.proper.com (8.9.3/8.9.3) id OAA18076
	for ietf-ldup-bks; Tue, 17 Apr 2001 14:00:52 -0700 (PDT)
Received: from ckmso1.proxy.att.com (ckmso1.att.com [12.20.58.69])
	by above.proper.com (8.9.3/8.9.3) with ESMTP id OAA18069
	for ; Tue, 17 Apr 2001 14:00:51 -0700 (PDT)
Received: from qsun.mt.att.com ([135.16.30.2])
	by ckmso1.proxy.att.com (AT&T IPNS/MSO-3.0) with SMTP id f3HL0K113086;
	Tue, 17 Apr 2001 17:00:21 -0400 (EDT)
Received: by qsun.mt.att.com (SMI-8.6/ATTEMS-1.4.1 sol2)
	id RAA17101; Tue, 17 Apr 2001 17:00:14 -0400
Date: Tue, 17 Apr 2001 17:00:14 -0400
Message-Id: <200104172100.RAA17101@qsun.mt.att.com>
From: rvh@qsun.mt.att.com (Richard V Huber)
To: Kurt@OpenLDAP.org, ietf-ldapext@netscape.com
Subject: Re: ACM & Replication (Was: LDAPEXT Minutes)
Cc: ietf-ldup@imc.org
Sender: owner-ietf-ldup@mail.imc.org
Precedence: bulk
List-Archive: 
List-ID: 
List-Unsubscribe: 

The main replication-related change to the ACM draft is to make it
clear that the ACM applies to wire-line flows of data being
replicated.

Ellen Stokes agreed to add that to the ACM draft.  I'll propose
specific wording if needed.

Rick Huber

: To: ietf-ldapext@netscape.com
: From: "Kurt D. Zeilenga" 
: Subject: ACM & Replication (Was: LDAPEXT Minutes)
: Cc: ietf-ldup@imc.org
: 
: At 10:56 AM 4/17/01, Mark Wahl wrote:
: >ACL
: > - replication requirements
: >
: >As John Strassner, co-chair of LDUP, requested that replication requirements 
: >of a document should be addressed in the working group where the document is 
: >authored, Rick Huber will incorporate replication requirements into the 
: >access control drafts.
: 
: Is there a description of what "replication requirements" which
: need to be addressed?  I can find no discussion of replication
: requirements upon the LDAP ACM in RFC 2820 nor the LDUP requirements
: document (though the latter details requirements upon LDUP to
: replicate access control information).
: 
: Thanks, Kurt


From owner-ietf-ldup@mail.imc.org  Tue Apr 17 19:25:24 2001
Received: from above.proper.com (above.proper.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA18087
	for ; Tue, 17 Apr 2001 19:25:22 -0400 (EDT)
Received: by above.proper.com (8.9.3/8.9.3) id PAA26100
	for ietf-ldup-bks; Tue, 17 Apr 2001 15:50:54 -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 PAA26096
	for ; Tue, 17 Apr 2001 15:50:53 -0700 (PDT)
Received: from gypsy.OpenLDAP.org (root@router.boolean.net [198.144.206.49])
	by pretender.boolean.net (8.11.1/8.11.1/Boolean/Hub) with ESMTP id f3HMmZG59196;
	Tue, 17 Apr 2001 22:48:35 GMT
	(envelope-from Kurt@OpenLDAP.org)
Message-Id: <5.1.0.14.0.20010417142830.00a7d970@127.0.0.1>
X-Sender: guru@127.0.0.1
X-Mailer: QUALCOMM Windows Eudora Version 5.1
Date: Tue, 17 Apr 2001 15:48:33 -0700
To: rvh@qsun.mt.att.com (Richard V Huber)
From: "Kurt D. Zeilenga" 
Subject: Re: ACM & Replication (Was: LDAPEXT Minutes)
Cc: ietf-ldapext@netscape.com, ietf-ldup@imc.org
In-Reply-To: <200104172100.RAA17101@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:00 PM 4/17/01, Richard V Huber wrote:
>The main replication-related change to the ACM draft is to make it
>clear that the ACM applies to wire-line flows of data being
>replicated.

Are you saying here that LDAP ACM would be used to control what
was replicated between servers?  That seems presumptive.

>Ellen Stokes agreed to add that to the ACM draft.  I'll propose
>specific wording if needed.

Please do. That would allow some WG discussion of the specifics.
I certainly not sure what type of clarification you trying to
make.

I note I belief that the section paragraph of the Introduction and
the second paragraph of the Security Considerations were pretty
clear as how LDAP replication issues related to the LDAP ACM
are to be addressed.  That is, such issues are "out of scope".
I would certainly question any attempt to bring them into scope.

Kurt



From owner-ietf-ldup@mail.imc.org  Tue Apr 17 19:48:55 2001
Received: from above.proper.com (above.proper.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA18480
	for ; Tue, 17 Apr 2001 19:48:54 -0400 (EDT)
Received: by above.proper.com (8.9.3/8.9.3) id QAA27815
	for ietf-ldup-bks; Tue, 17 Apr 2001 16:17:30 -0700 (PDT)
Received: from almso1.proxy.att.com (almso1.att.com [192.128.167.69])
	by above.proper.com (8.9.3/8.9.3) with ESMTP id QAA27810
	for ; Tue, 17 Apr 2001 16:17:28 -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 f3HNH0Z06418;
	Tue, 17 Apr 2001 19:17:00 -0400 (EDT)
Received: by qsun.mt.att.com (SMI-8.6/ATTEMS-1.4.1 sol2)
	id TAA01088; Tue, 17 Apr 2001 19:16:59 -0400
Date: Tue, 17 Apr 2001 19:16:59 -0400
Message-Id: <200104172316.TAA01088@qsun.mt.att.com>
From: rvh@qsun.mt.att.com (Richard V Huber)
To: Kurt@OpenLDAP.org
Subject: Re: ACM & Replication (Was: LDAPEXT Minutes)
Cc: ietf-ldapext@netscape.com, ietf-ldup@imc.org
Sender: owner-ietf-ldup@mail.imc.org
Precedence: bulk
List-Archive: 
List-ID: 
List-Unsubscribe: 

: Are you saying here that LDAP ACM would be used to control what
: was replicated between servers?  That seems presumptive.

No, replication agreements control what is replicated among servers.

All I'm saying is that the format specified by the ACM for representing
access control information on the wire is also the format LDUP should
use to transport access control information during replication.  So
there should be a few additions to the ACM draft to clarify this
additional intended use.

Rick Huber

: From Kurt@OpenLDAP.org Tue Apr 17 18:50:59 2001
: Return-Path: 
: X-Sender: guru@127.0.0.1
: To: rvh@qsun.mt.att.com (Richard V Huber)
: From: "Kurt D. Zeilenga" 
: Subject: Re: ACM & Replication (Was: LDAPEXT Minutes)
: Cc: ietf-ldapext@netscape.com, ietf-ldup@imc.org
: Mime-Version: 1.0
: 
: At 02:00 PM 4/17/01, Richard V Huber wrote:
: >The main replication-related change to the ACM draft is to make it
: >clear that the ACM applies to wire-line flows of data being
: >replicated.
: 
: Are you saying here that LDAP ACM would be used to control what
: was replicated between servers?  That seems presumptive.
: 
: >Ellen Stokes agreed to add that to the ACM draft.  I'll propose
: >specific wording if needed.
: 
: Please do. That would allow some WG discussion of the specifics.
: I certainly not sure what type of clarification you trying to
: make.
: 
: I note I belief that the section paragraph of the Introduction and
: the second paragraph of the Security Considerations were pretty
: clear as how LDAP replication issues related to the LDAP ACM
: are to be addressed.  That is, such issues are "out of scope".
: I would certainly question any attempt to bring them into scope.
: 
: Kurt


From owner-ietf-ldup@mail.imc.org  Tue Apr 17 22:24: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 WAA20871
	for ; Tue, 17 Apr 2001 22:24:45 -0400 (EDT)
Received: by above.proper.com (8.9.3/8.9.3) id SAA07337
	for ietf-ldup-bks; Tue, 17 Apr 2001 18:54:03 -0700 (PDT)
Received: from mg01.austin.ibm.com (mg01.austin.ibm.com [192.35.232.18])
	by above.proper.com (8.9.3/8.9.3) with ESMTP id SAA07333
	for ; Tue, 17 Apr 2001 18:54:01 -0700 (PDT)
Received: from austin.ibm.com (netmail.austin.ibm.com [9.53.250.98])
	by mg01.austin.ibm.com (AIX4.3/8.9.3/8.9.3) with ESMTP id UAA26332;
	Tue, 17 Apr 2001 20:56:48 -0500
Received: from estokes.austin.ibm.com (lig32-227-160-27.us.lig-dial.ibm.com [32.227.160.27])
	by austin.ibm.com (AIX4.3/8.9.3/8.9.3) with ESMTP id UAA27328;
	Tue, 17 Apr 2001 20:54:00 -0500
Message-Id: <5.0.2.1.0.20010417204927.00a78ce0@popmail2.austin.ibm.com>
X-Sender: stokes@popmail2.austin.ibm.com
X-Mailer: QUALCOMM Windows Eudora Version 5.0.2
Date: Tue, 17 Apr 2001 20:53:59 -0500
To: "Kurt D. Zeilenga" ,
        rvh@qsun.mt.att.com (Richard V Huber)
From: Ellen Stokes 
Subject: Re: ACM & Replication (Was: LDAPEXT Minutes)
Cc: ietf-ldapext@netscape.com, ietf-ldup@imc.org
In-Reply-To: <5.1.0.14.0.20010417142830.00a7d970@127.0.0.1>
References: <200104172100.RAA17101@qsun.mt.att.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: owner-ietf-ldup@mail.imc.org
Precedence: bulk
List-Archive: 
List-ID: 
List-Unsubscribe: 

 From discussion with Rick Huber in Minneapolis, the following paragraphs
of the model draft have been modified and now read as follows (excerpted
from their sections with section headers):

2.  The LDAPv3 Access Control Model
    - What flows on the wire for interoperability

      The existing LDAP protocol flows for ldap operations
      are used to manipulate access control information.
      These same flows on the wire apply when ACI is
      transmitted during replication.  A set of permissions
      and their semantics with respect to ldap operations is
      defined.  The permissions parallel the defined set of
      ldap operations.  What is transmitted is exactly what
      is read back.  Encoding of access control information
      on the wire is per the LDAPv3 specifications.

4.  The Access Control Information Attributes and Syntax
The attributes are defined so access control information
(ACI) can be addressed in a server independent of server
implementation.  These attributes are used in typical LDAP
APIs, in LDIF output of ACI and in transfer of ACI during
replication. These attributes may be queried or set on all
directory objects.  The BNF and definitions are given below.

Ellen


At 03:48 PM 4/17/2001 -0700, Kurt D. Zeilenga wrote:
>At 02:00 PM 4/17/01, Richard V Huber wrote:
> >The main replication-related change to the ACM draft is to make it
> >clear that the ACM applies to wire-line flows of data being
> >replicated.
>
>Are you saying here that LDAP ACM would be used to control what
>was replicated between servers?  That seems presumptive.
>
> >Ellen Stokes agreed to add that to the ACM draft.  I'll propose
> >specific wording if needed.
>
>Please do. That would allow some WG discussion of the specifics.
>I certainly not sure what type of clarification you trying to
>make.
>
>I note I belief that the section paragraph of the Introduction and
>the second paragraph of the Security Considerations were pretty
>clear as how LDAP replication issues related to the LDAP ACM
>are to be addressed.  That is, such issues are "out of scope".
>I would certainly question any attempt to bring them into scope.
>
>Kurt



From owner-ietf-ldup@mail.imc.org  Tue Apr 17 23: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 SMTP id XAA22173
	for ; Tue, 17 Apr 2001 23:15:49 -0400 (EDT)
Received: by above.proper.com (8.9.3/8.9.3) id TAA09190
	for ietf-ldup-bks; Tue, 17 Apr 2001 19:42:30 -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 TAA09185
	for ; Tue, 17 Apr 2001 19:42:29 -0700 (PDT)
Received: from gypsy.OpenLDAP.org (root@router.boolean.net [198.144.206.49])
	by pretender.boolean.net (8.11.1/8.11.1/Boolean/Hub) with ESMTP id f3I2dtG67358;
	Wed, 18 Apr 2001 02:39:55 GMT
	(envelope-from Kurt@OpenLDAP.org)
Message-Id: <5.1.0.14.0.20010417190437.00a952b0@127.0.0.1>
X-Sender: guru@127.0.0.1
X-Mailer: QUALCOMM Windows Eudora Version 5.1
Date: Tue, 17 Apr 2001 19:39:54 -0700
To: Ellen Stokes 
From: "Kurt D. Zeilenga" 
Subject: Re: ACM & Replication (Was: LDAPEXT Minutes)
Cc: rvh@qsun.mt.att.com (Richard V Huber), ietf-ldapext@netscape.com,
        ietf-ldup@imc.org
In-Reply-To: <5.0.2.1.0.20010417204927.00a78ce0@popmail2.austin.ibm.com>
References: <5.1.0.14.0.20010417142830.00a7d970@127.0.0.1>
 <200104172100.RAA17101@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 06:53 PM 4/17/01, Ellen Stokes wrote:
>From discussion with Rick Huber in Minneapolis, the following paragraphs
>of the model draft have been modified and now read as follows (excerpted
>from their sections with section headers):
>
>2.  The LDAPv3 Access Control Model
>   - What flows on the wire for interoperability
>
>     The existing LDAP protocol flows for ldap operations
>     are used to manipulate access control information.
>     These same flows on the wire apply when ACI is
>     transmitted during replication.  A set of permissions
>     and their semantics with respect to ldap operations is
>     defined.  The permissions parallel the defined set of
>     ldap operations.  What is transmitted is exactly what
>     is read back.  Encoding of access control information
>     on the wire is per the LDAPv3 specifications.

This basically says:
        Access control information is represented as elements
        of the LDAP data model and can be manipulated using
       normal LDAP operations.  A set of permissions and their
       semantics with respect to LDAP operations is defined.  The
       permissions parallel the defined set of LDAP operations.

That is, LDAP defines the wire format of LDAP operations
including data elements.  All this "on the wire" stuff just
muddies the waters and is completely unnecessary. 

I note that statement:
      "What is transmitted is exactly what is read back."

implies that the server is not free to store the values as it
pleases (which is contrary to other statements in the ACM as
well as rfc2251).  The data and service model only requires,
in general, that information can be read back in an equivalent
form.  This is needed to support multiple transfer modes
(string v. ;binary) and to give the server to store the data
in alternative forms, such as needed to support other
protocols/services.

>4.  The Access Control Information Attributes and Syntax
>The attributes are defined so access control information
>(ACI) can be addressed in a server independent of server
>implementation.

Suggest replacing "can be... " with:
    can be represented in an implementation independent
    manner.

>These attributes are used in typical LDAP
>APIs, in LDIF output of ACI and in transfer of ACI during
>replication.

s/are used/may be used/

>These attributes may be queried or set on all
>directory objects.  The BNF and definitions are given below.



From owner-ietf-ldup@mail.imc.org  Thu Apr 19 21:46:58 2001
Received: from above.proper.com (above.proper.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id VAA21723
	for ; Thu, 19 Apr 2001 21:46:58 -0400 (EDT)
Received: (from majordomo@localhost)
	by above.proper.com (8.9.3/8.9.3) id SAA14241
	for ietf-ldup-bks; Thu, 19 Apr 2001 18:15:52 -0700 (PDT)
Received: from hermes.tconl.com (mail.tconl.com [204.26.80.9])
	by above.proper.com (8.9.3/8.9.3) with ESMTP id SAA14237
	for ; Thu, 19 Apr 2001 18:15:51 -0700 (PDT)
Received: from rmoats2 (tconl91223.tconl.com [204.26.91.223])
	by hermes.tconl.com (8.11.0/TeleChoice) with SMTP id f3K1Fqi22335
	for ; Thu, 19 Apr 2001 20:15:52 -0500
From: "Ryan Moats" 
To: 
Subject: Re: req't, security related comments (CORRECTED)
Date: Thu, 19 Apr 2001 20:17:39 -0500
Message-ID: 
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0)
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700
Sender: owner-ietf-ldup@mail.imc.org
Precedence: bulk
List-Archive: 
List-ID: 
List-Unsubscribe: 
Content-Transfer-Encoding: 7bit

| [this post corrects a few typos including a key reference]
| 
| I suggest the term "data privacy" be replaced with "data
| confidentiality" within the requirements document as
| "data privacy" is somewhat confusing.  I highly recommend
| use of RFC 2828 terminology be used in describing security
| requirements.
|
| > 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.
|
| > 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)
|
| > S3.  To promote interoperability, there MUST be a mandatory-to-
| > implement data privacy mechanism.
|
| S3.  To promote interoperability, there MUST be a mandatory-to-
| implement data integrity and confidentiality protection mechanism.
|
| > S4. The transport for administrative access MUST permit assurance of
| > the integrity and privacy of all data transferred.
|
| Due to the rewording of S2, this would be redundant.

I'm ok with all of the above suggestions.

| 5.  Security Considerations
| > As noted in Section 3, security may be impacted when replicating
| > among servers that implement non-standard extensions to basic
| > LDAP semantics.
|
| I note that security is also impacted by servers implementing
| standard extensions as well as differing optional features of the
| "core" protocol as well as by implementing same features in
| different ways.
|
| That is, the section 3 section:
| > 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 believe this should be broaden to say:
|   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), or implement
|   differing sets of optional features of the LDAP, or implement them
|   in differently.
|
| I don't see why the document doesn't just say:
|   Interoperability between independently developed server
|   implementations of LDAP using LDUP may be limited as LDAP
|   has numerous optional features and extensions and allows
|   for a wide range of implementation behavior.

However, I do not agree with either of these wordings.  IMHO, it is the
responsibility of LDUP to handle all of the optional features of LDAP
already documented while to me the above suggestions read as a pass.
New experimental or optional features of LDAP (from when LDUP is
published) are themselves required to address any impact they have on
replication.

Ryan


From owner-ietf-ldup@mail.imc.org  Thu Apr 19 23:31: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 XAA23634
	for ; Thu, 19 Apr 2001 23:31:41 -0400 (EDT)
Received: by above.proper.com (8.9.3/8.9.3) id UAA18620
	for ietf-ldup-bks; Thu, 19 Apr 2001 20:07:10 -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 UAA18615
	for ; Thu, 19 Apr 2001 20:07:08 -0700 (PDT)
Received: from gypsy.OpenLDAP.org (root@router.boolean.net [198.144.206.49])
	by pretender.boolean.net (8.11.1/8.11.1/Boolean/Hub) with ESMTP id f3K34tG79675;
	Fri, 20 Apr 2001 03:04:55 GMT
	(envelope-from Kurt@OpenLDAP.org)
Message-Id: <5.1.0.14.0.20010419195931.00aba490@127.0.0.1>
X-Sender: guru@127.0.0.1
X-Mailer: QUALCOMM Windows Eudora Version 5.1
Date: Thu, 19 Apr 2001 20:04:53 -0700
To: "Ryan Moats" 
From: "Kurt D. Zeilenga" 
Subject: Re: req't, security related comments (CORRECTED)
Cc: 
In-Reply-To: 
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: owner-ietf-ldup@mail.imc.org
Precedence: bulk
List-Archive: 
List-ID: 
List-Unsubscribe: 

At 06:17 PM 4/19/01, Ryan Moats wrote:
>| 5.  Security Considerations
>
>However, I do not agree with either of these wordings.  IMHO, it is the
>responsibility of LDUP to handle all of the optional features of LDAP
>already documented while to me the above suggestions read as a pass.

It's not a pass, its a realization that LDUP will not remove
allowed differences between LDAP implementations and these
differences can have significant impact upon security in
replicated environments.



From owner-ietf-ldup@mail.imc.org  Tue Apr 24 15:01:59 2001
Received: from above.proper.com ([208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA12793
	for ; Tue, 24 Apr 2001 15:01:59 -0400 (EDT)
Received: by above.proper.com (8.9.3/8.9.3) id LAA06812
	for ietf-ldup-bks; Tue, 24 Apr 2001 11:34:25 -0700 (PDT)
Received: from uxtpaprx1.pwcglobal.com (uxtpaprx1.pwcglobal.com [12.26.159.121])
	by above.proper.com (8.9.3/8.9.3) with ESMTP id LAA06804
	for ; Tue, 24 Apr 2001 11:34:23 -0700 (PDT)
From: elizabeth.r.deschenes@us.pwcglobal.com
Received: by uxtpaprx1.pwcglobal.com; id OAA19820; Tue, 24 Apr 2001 14:30:50 -0400 (EDT)
Received: from uxtpabuf1.us.pw.com(10.26.104.81) by uxtpaprx1.us.pw.com via smap (V5.5)
	id xma018169; Tue, 24 Apr 01 14:29:28 -0400
Received: from us-amsmta005.us.pw.com by uxtpabuf1.us.pw.com
 (PMDF V5.1-12 #U3932) with ESMTP id <0GCB00ACU7FZ3T@uxtpabuf1.us.pw.com> for
 ietf-ldup@imc.org; Tue, 24 Apr 2001 14:31:12 -0400 (EDT)
Date: Tue, 24 Apr 2001 14:32:03 -0400
Subject: PricewaterhouseCoopers is looking for a LDAP Practice Leader for it's
 E-biz practice
To: ietf-ldup@imc.org
Message-id: 
MIME-version: 1.0
Content-type: text/plain; charset=us-ascii
X-MIMETrack: Serialize by Router on US-AMSMTA005/US/INTL(Release 5.0.6
 |December 14, 2000) at 04/24/2001 02:32:32 PM
Sender: owner-ietf-ldup@mail.imc.org
Precedence: bulk
List-Archive: 
List-ID: 
List-Unsubscribe: 






PricewaterhouseCoopers is  looking for a Sr. Level LDAP/Directory Practice
leader for our growing e-Biz practice.  Our practice is fairly new  ( about
a year old) and roughly we have 120 consultants. We need someone who has
designed and implemented LDAP multiple times, can manage projects and
people.  Being in charge of knowledge transfer with the staff is extremely
important.

The position could reside out of any major city and would involve at least
80% travel.  The compensation would range from 140k to 200k plus an
excellent benefits package.


If anyone would happen to know of someone that would be a good fit and like
to hear more , please have them contact me either through e-mail or phone.
Thanks



Elizabeth Deschenes
678-419-4104










----------------------------------------------------------------
The information transmitted is intended only for the person or entity to
which it is addressed and may contain confidential and/or privileged
material.  Any review, retransmission, dissemination or other use of, or
taking of any action in reliance upon, this information by persons or
entities other than the intended recipient is prohibited.   If you received
this in error, please contact the sender and delete the material from any
computer.