From owner-ietf-ldup@mail.imc.org Tue Sep 4 03:41:45 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA05369 for ; Tue, 4 Sep 2001 03:41:44 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id f847HWP10969 for ietf-ldup-bks; Tue, 4 Sep 2001 00:17:32 -0700 (PDT) Received: from arnie.adacel.com.au (arnie.adacel.com.au [203.36.26.147]) by above.proper.com (8.11.6/8.11.3) with SMTP id f847HRD10958 for ; Tue, 4 Sep 2001 00:17:28 -0700 (PDT) Received: (qmail 21511 invoked from network); 4 Sep 2001 07:26:55 -0000 Received: from osmium.adacel.com.au (HELO osmium) (203.8.85.176) by arnie.adacel.com.au with SMTP; 4 Sep 2001 07:26:55 -0000 Reply-To: From: "Steven Legg" To: "'John McMeeking'" Cc: Subject: RE: WG Last Call on URP I-D Date: Tue, 4 Sep 2001 18:18:11 +1100 Message-ID: <000001c13511$c2439650$b05508cb@osmium.adacel.com.au> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook 8.5, Build 4.71.2377.0 X-MimeOLE: Produced By Microsoft MimeOLE V4.72.2120.0 Importance: Normal In-Reply-To: Sender: owner-ietf-ldup@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit John McMeeking wrote: > We have reviewed the LDUP Update Resolution Procedures Internet Draft > (draft-ietf-ldup-urp-04.txt) and have the following comments. Thanks for taking the time to have a close look at the document. > > > 1. Section 4.4, second para. It seems that a glue entry ought to be used > when breaking DIT loops. The glue entry would contain the DN of the > entry's parent at the time it was moved to Lost & Found. Without this, > there is nothing to tell an administrator where this entry originally came > from. We also note that glue entries are ill-defined at best in many > documents, and it is not clear whether statements that "a glue entry has > knowledge only of its name" is meant to imply that is knows the DN of the > entry it represents, or that a glue entry has its RDN (entryuuid=x) as its > only attribute. The description of glue entries in the architecture draft is inaccurate and needs further work. The URP draft is written on the assumption that certain concepts, like glue entries, replication agreements, Update Vectors, etc, are properly specified in the architecture draft. Insofar as they are not properly described, that is a problem with the architecture draft, not the URP draft. Glue entries touch upon the area of Directory Specific Entries, manageDSAIT controls and like, which have much wider scope than just URP and are still under debate. These topics are something the working group will have to address before LDUP can be considered complete but right now the URP document isn't the place to be resolving them. In the meantime, like so many things in LDAP, one must look to X.500 for a complete explanation. FYI, as far as URP is concerned, a glue entry can contain anything that a regular entry can contain except that it isn't necessarily a complete entry (parts can be missing) and isn't normally seen by average users. > > > 2. Section 5.1.3, b and c. You might note that Section 5.2 will show why > attribute value deletion records are not required in these cases. Case c) explicitly *does* require (attribute) value deletion records. An attribute deletion record instead of value deletion records for case b) was a free design choice (based on what is most likely to match the user's intention) so I don't see in what way Section 5.2 shows why value deletion records are not required for case b). Section 5.2 would work either way. > Under > (d), you might note that d) covers the special case for replace where a > replace with no attribute values is treated as a attribute deletion. I'll add an "if any" to the end of the last sentence in d). I'd rather not say that a replace with no values is treated like a deletion since a replace with listed values is most definitely *not* treated like a deletion with listed values. I think it is better to describe each case in isolation. > > > 3. Section 5.2, 1st para. Clarify that supplier is scanning entry, > attribute, and value CSNs. Current wording could leave one to think the > supplier is just looking at entry CSNs. The first paragraph introduces the basic idea and the subsequent paragraphs provide the detail. It should be abundantly clear from the subsequent paragraphs that the Name CSN, Parent CSN, Entry CSN and attribute value CSNs of an entry are all examined. Anyway, I propose this rewording of the third sentence in the first paragraph. "Conceptually, the supplier scans all the entries (glue and non-glue), entry contents and deletion records that are covered by the replication agreement with the consumer" ... > In the second paragraph, "A > p-add-entry primitive is generated for each entry whose entry CSN is > greater than the Update Vector CSN for the same replica." what does "same > replica" refer to? Consumer replica? Would adding this following paragraph after the first paragraph clarify the situation ? "The consumer's Update Vector has a CSN for each replica in the replica group. Each CSN held by the supplier contains a Replica Identifier. When a CSN held by the supplier is compared to the consumer's Update Vector during the generation of replication primitives it is compared to the single CSN in the consumer's Update Vector that has the same Replica Identifier as the held CSN." If so, I will also tweak the wording of the subsequent paragraphs, e.g. "A p-add-entry primitive is generated for each entry whose Entry CSN is greater than the Update Vector CSN with the same Replica Identifier." > > 4. Section 5.3.5, 2nd para. Could improve the grammar of the 3rd sentnce > by changing "If not, it disambiguates the names of the entries by adding > the Unique Identifier (i.e. the entryUUID attribute) of each of the > conflicting entries to their own RDN" to "... to each entry's RDN." That wording might suggest that every UUID is added to every conflicting entry. How about this wording instead ? "If not, it disambiguates the names of the entries by adding each conflicting entry's Unique Identifier to its RDN (i.e. making the value of its entryUUID attribute distinguished)." > > > 5. Section 5.3.5, CheckUniqueness function: > > IF E.rdn is empty > make C.uid distinguished > > Please explain this test. Why are we checking to see if the entry has > no RDN, and IF so, make the OLD conflicting entry's name contain the UID? It's a typo. > Perhaps make C.uid distinguished should be make E.uid distinguished? Yes. I'll make the correction. > > > 6. Section 5.3.5, just before RenameEntry(E,P). The pareter description > is missing the name of the second parameter. Perhaps: > "The parameters to this procedure are the entry, E, and the p-add-entry or > p-rename-entry primitive, P, specifying the new RDN." > ", P," was missing. OR "The parameters to this procedure are the entry, E, and P, the p-add-entry or p-rename-entry primitive specifying the new RDN." > > > 7. Section 5.3.5, RenameEntry(E,P). After > V.csn := GenerateNextCSN(V.csn) > Should a log-based implementation log a primitive for this change? We > think so. Yes it should. This action is mandated in the first paragraph of Section 5.3.3. > > The above comment also applies to 5.3.7 and 5.3.8. And to Section 5.3.11. All these cases are covered by the first paragraph of Section 5.3.3. > > > 8. Section 5.3.6. > replace V with P.value if they are not identical > Shouldn't this be: > replace V with P.value if they are not identical AND > the type is single-valued? No. The action also applies to values of multi-valued attribute types for the reason given in the first paragraph of Section 5.3.4. > > 9. Section 5.3.8 > > FOREACH attribute value, V, of type P.type in E (if any) > IF P.csn > V.csn > IF V is distinguished > IF ProtectDistinguished() > V.csn := GenerateNextCSN(P.csn) > ELSE > { > R := E.rdn > remove value V > CheckUniqueness(E, E.superior, R) > } > ELSE > remove value V > >>> StoreAttributeDeletion (P.uid, P.type, P.csn) > > If ProtectDistinguished() is TRUE, then the attribute deletion is false. > We should store Attribute Value deletions for all NON-distinguished values > - or, store an Attribute deletion and an attribute ADD for the > distinguished value. The procedure is already doing the latter. The CSN on the distinguished value is reset to the value returned by the GenerateNextCSN function call so a p-add-attribute-value primitive will be generated in due course. > > > 10. Section 5.3.11 and 5.3.12. Where we create glue entries, i.e. > E := CreateGlueEntry(P.uid) > Shouldn't this be followed by: > E.superior = LOST_AND_FOUND The CreateGlueEntry function does this already. To quote from Section 5.3.2: "The CreateGlueEntry function is called when required to create a glue entry as a subordinate of Lost & Found". > > > 11. Section 5.3.12 > replace V with N.value if they are not identical > Shouldn't this be: > replace V with N.value if they are not identical AND > the type is single-valued? Same response as for point 8. > > > 12. Section 5.3.11. We have two additional concerns with the p-move-entry > primitive. As written, it appears that Lost and Found of the participating > replicas do not all end up in the same state. They all end up in the same state when the full implications of the GenerateNextCSN function are considered. The missing steps in the example are discussed below. > Also, by moving entries > directly under Lost & Found, information about the original parent of the > entry is lost. We suggest that p-move-entry place entries under a glue > entry that has knowledge of the original parent DN. There is no doubt all sorts of useful information about the recent states of an entry that we could be collecting to present to administrators later, but since it doesn't have any bearing on URP and LDUP server interworking I've chosen not to go down that rat hole. URP doesn't preclude implementations from collecting and keeping additional records and I'm happy to leave such things to experimentation for now. > > The following example illustrates the first concern: > > Consider the following DIT: > > o=A L & F > | > ------------ > | | > ou=B ou=C > > And suppose there are two replicas, 1 & 2. > > at t1: client on server 1 moves ou=C beneath ou=B > > at t2: client on server 2 moves ou=B beneath ou=C > > DITs on each server now look like: > > Server 1: Server 2: > o=A o=A > | | > ------------ ------------ > | | | | > ou=B ou=C > | | > ou=C ou=B > > at t3: server 1 receives updates from server 2 > p-move-entry(B, t2, C) > This results in a loop, and the resolution is to move B to L&F In addition, the GenerateNextCSN function is called to reset the CSN on B's superior reference. This means that immediately (log-based) or eventually (state-based) a p-move-entry(B, t3, LOST_AND_FOUND) is generated and propagated to server 2. > > at t4: server 2 receives updates from server 1 > p-move-entry(C, t1, B) > This results in a loop, and the resolution is to move C to L&F Likewise, a p-move-entry(C, t4, LOST_AND_FOUND) is generated and propagated to server 1. > > Final outcome: > > Server 1: Server 2: > o=A L & F o=A L & F > | | | | > glue entry glue entry > | | > ou=B ou=C > | | > ou=C ou=B > > We ended up with differing outcomes in Lost and Found. Taking into consideration the two extra p-move-entry primitives, the final outcome at both servers is: o=A L & F | | ------------ | | ou=B ou=C Note that in this case there are no glue entries created. Regards, Steven From owner-ietf-ldup@mail.imc.org Tue Sep 4 12:05:27 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA20141 for ; Tue, 4 Sep 2001 12:05:26 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id f84Fl7Z18245 for ietf-ldup-bks; Tue, 4 Sep 2001 08:47:07 -0700 (PDT) Received: from pretender.boolean.net (root@router.boolean.net [198.144.206.49]) by above.proper.com (8.11.6/8.11.3) with ESMTP id f84Fl5D18238 for ; Tue, 4 Sep 2001 08:47:05 -0700 (PDT) Received: from nomad.OpenLDAP.org (root@localhost [127.0.0.1]) by pretender.boolean.net (8.11.3/8.11.1/Boolean/Hub) with ESMTP id f84Fl6C74461 for ; Tue, 4 Sep 2001 15:47:06 GMT (envelope-from Kurt@OpenLDAP.org) Message-Id: <5.1.0.14.0.20010904082254.01b382e8@127.0.0.1> X-Sender: kurt@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Tue, 04 Sep 2001 08:46:54 -0700 To: ietf-ldup@imc.org From: "Kurt D. Zeilenga" Subject: URP: value v. representation Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-ldup@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Section 5.3.4 ends with the sentence: Whenever a CSN for some value is refreshed the value is also refreshed using the exact value from the primitive so that all directory servers use exactly the same representation for the value. It should likely read: Whenever a CSN for some value is refreshed the value is also refreshed using the exact value from the primitive so that all directory servers use the same value. Each server is, of course, free to represent the value in any form allowed by the attribute's syntax. Replicas must converge to the same value, not to the same representation of that value. Note: CN value 'Foo Bar' is not the same value as CN 'Foo Bar' though they equal per the equality rule. Replicas must converge to one or the other (per URP). However, a member value of 'CN=Foo Bar' is the same as CN='Foo\20Bar'; no change is required by either replica. That is, URP must not force one replicas preferred form upon another server. BTW, the URP seems to be dependent upon having an EQUALITY rule defined for each attribute type and for each replica to implement this rule. What happens when the attribute does have an EQUALITY matching rule? or one replica implements the rule and another doesn't? Kurt From owner-ietf-ldup@mail.imc.org Tue Sep 4 12:05:30 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA20153 for ; Tue, 4 Sep 2001 12:05:29 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id f84FmY718475 for ietf-ldup-bks; Tue, 4 Sep 2001 08:48:34 -0700 (PDT) Received: from ckmso1.proxy.att.com (ckmso1.att.com [12.20.58.69]) by above.proper.com (8.11.6/8.11.3) with ESMTP id f84FmWD18468 for ; Tue, 4 Sep 2001 08:48:32 -0700 (PDT) Received: from qsun.mt.att.com ([135.16.31.2]) by ckmso1.proxy.att.com (AT&T IPNS/MSO-3.0) with SMTP id f84FmLO22134 for ; Tue, 4 Sep 2001 11:48:22 -0400 (EDT) Received: from att.com by qsun.mt.att.com (SMI-8.6/ATTEMS-1.4.1 sol2) id LAA20918; Tue, 4 Sep 2001 11:48:20 -0400 Message-ID: <3B94F771.7A71ED2D@att.com> Date: Tue, 04 Sep 2001 11:46:57 -0400 From: Richard Huber X-Mailer: Mozilla 4.75 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: "'Ietf-Ldup@Imc. Org'" Subject: Re: DRAFT Minutes of the 51st meeting for your review 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'd like to address the comment about the wording in the Access Control Model draft that says "This model does not (and cannot) fully specify the behavior of the Access Control Model in a distributed environment ..." This text is not talking about REPLICATED environments (in fact, there is already wording in the document that says "These same flows on the wire apply when ACI is transmitted during replication."; we certainly see replicated environments as an area where consistent access controls are needed). The comment about DISTRIBUTED environments was addressing the issues that arise when a replica does not hold the entire DIT, and in particular the case where a replica does not hold the root of the DIT. Since access rights at a given point in the tree may depend on access controls higher in the tree, there needs to be a way to check the access controls in parts of the tree not held in the replica. Note that these issues arise because of "partitioning" (servers that hold only part of the DIT) regardless of whether replication is used. The issue was discussed in more depth in Ed Reed's (now expired) draft-reed-ldup-inheritance-00.txt (the minutes of a bar-BOF in San Diego). This is one of those cases where I wish IDs were permanent; the draft doesn't solve the problem but it contains a useful description of it with recommendations towards a solution; it would be nice to have this recorded. It seems that the current text on distributed environments causes confusion - the Access Control Model draft should be clearer about the issues of distributed environments (and what we mean by that term). We will improve this in the next version. Rick Huber John Strassner wrote: > Greetings LDUPers, > > below please find the draft meeting minutes for the London meeting. > Apologies for the late delay - apparently this was never successfully > delivered. 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 and Chris Apple > LDUP WG Co-Chairs > Lots of stuff omitted. > > 9) LDAP Access Control Model Work > > The focus of this agenda item was to ferret out any concerns that > people had on the ACM work to ensure that these would not affect LDUP. > > It was noted that the model document does not define how access > control will work in a replicated environment. The LDUP general > usage profile document is a good job of indicating lots of things > (besides access control) that are affected when replication is added > to the environment. > > Open question to group by Chris Apple with respect to what > outstanding problems people have with the access control model > and replication? > > Kurt: model document still lists access control as not defined > how access control works in a replicated environment. There is > a need for LDUP folks to read and comment on the current > ACL model draft. Lot's more stuff omitted. From owner-ietf-ldup@mail.imc.org Tue Sep 4 19:41:44 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA00717 for ; Tue, 4 Sep 2001 19:41:43 -0400 (EDT) Received: by above.proper.com (8.11.6/8.11.3) id f84NNJ502718 for ietf-ldup-bks; Tue, 4 Sep 2001 16:23:19 -0700 (PDT) Received: from kcmso1.proxy.att.com (kcmso1.att.com [192.128.133.69]) by above.proper.com (8.11.6/8.11.3) with ESMTP id f84NNGD02713 for ; Tue, 4 Sep 2001 16:23:17 -0700 (PDT) Received: from qsun.mt.att.com ([135.16.31.2]) by kcmso1.proxy.att.com (AT&T IPNS/MSO-3.0) with SMTP id f84NNCV20416 for ; Tue, 4 Sep 2001 19:23:12 -0400 (EDT) Received: by qsun.mt.att.com (SMI-8.6/ATTEMS-1.4.1 sol2) id TAA27643; Tue, 4 Sep 2001 19:23:11 -0400 Date: Tue, 4 Sep 2001 19:23:11 -0400 Message-Id: <200109042323.TAA27643@qsun.mt.att.com> From: rvh@qsun.mt.att.com (Richard V Huber) To: ietf-ldup@imc.org Subject: URP draft Sender: owner-ietf-ldup@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Some style comments. I think the references need to be expanded. In particular, Section 4 needs a reference to the model document(s) being extended. It would also help if the document said a bit more (a paragraph or two) about how it fits into LDUP. What is covered in this document? What is specifically left to other documents? What assumptions are "inherited" from the underlying service (LDAP/X.500)? Since (as stated in the Abstract) URP is intended to be applicable to both X.500 and LDAP we need to be very clear about underlying assumptions. Rick Huber From owner-ietf-ldup@mail.imc.org Wed Sep 5 04:47:31 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA21695 for ; Wed, 5 Sep 2001 04:47:31 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id f858Y4F28058 for ietf-ldup-bks; Wed, 5 Sep 2001 01:34:04 -0700 (PDT) Received: from arnie.adacel.com.au (arnie.adacel.com.au [203.36.26.147]) by above.proper.com (8.11.6/8.11.3) with SMTP id f858XrD28020 for ; Wed, 5 Sep 2001 01:33:55 -0700 (PDT) Received: (qmail 15388 invoked from network); 5 Sep 2001 08:39:15 -0000 Received: from osmium.adacel.com.au (HELO osmium) (203.8.85.176) by arnie.adacel.com.au with SMTP; 5 Sep 2001 08:39:15 -0000 Reply-To: From: "Steven Legg" To: "'Ryan Moats'" Cc: Subject: RE: WG Last Call on URP I-D Date: Wed, 5 Sep 2001 19:34:41 +1100 Message-ID: <002901c135e5$9c7809e0$b05508cb@osmium.adacel.com.au> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook 8.5, Build 4.71.2377.0 X-MimeOLE: Produced By Microsoft MimeOLE V4.72.2120.0 Importance: Normal In-Reply-To: <20010824110334.A919@armada.local.windrose.omaha.ne.us> Sender: owner-ietf-ldup@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit Ryan, Ryan Moats wrote: > What I seemed to miss was the discussion of primitive generation > with respect to attribute types, attribute subtypes and > attribute options. > Specifically there was no clarification > > - whether attribute subtypes and options were or were not > supported. I > believe absense of a restriction means they are, but others > could read > absense of a restriction to mean they are not. The absence of any clear direction in URP on subtyping issues is an oversight. I had been assuming that attribute subtyping is basically ignored by URP, as is the case for updating in general and for X.500 replication updates in particular. I shall add words to the URP document to the effect that attribute types in a subtype hierarchy are treated as distinct and unrelated types by URP. Attribute options are a different matter since RFC 2251 isn't clear about how this form of subtyping applies to updates. For example, does a request to delete the cn attribute also delete the cn;foobar attribute ? If I can assume that the answer is no then I can just say that attribute types with options are also treated as distinct and unrelated types by URP. The alternative answer will require more extensive changes. Regardless of the answer, the replication primitives have a type parameter which is described as an attribute type. In the meantime I will revise this to be an attribute description. > > - whether or not dsaOperation types could be replicated. Since the > requirements draft states this as a MUST NOT (req G10), the lack of > a discussion in the primitive generation portion of the document > disturbs me. URP doesn't go into any detail about what is or isn't part of the area of replication since that is in the scope of another LDUP document and that document isn't yet ready to go to last call. URP just has a blanket statement that replication primitives are generated only for directory contents that are covered by the replication agreement, so it will automatically conform to whatever the final LDUP model document says. If the model draft says that dsaOperation types are never part of a replication agreement then URP will never replicate that kind of operational attribute and requirement G10 will be satisfied. Regards, Steven From owner-ietf-ldup@mail.imc.org Wed Sep 5 09:30:16 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA00662 for ; Wed, 5 Sep 2001 09:30:15 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id f85DEhY16995 for ietf-ldup-bks; Wed, 5 Sep 2001 06:14:43 -0700 (PDT) Received: from tconl91223.tconl.com (tconl91223.tconl.com [204.26.91.223]) by above.proper.com (8.11.6/8.11.3) with SMTP id f85DEgD16991 for ; Wed, 5 Sep 2001 06:14:42 -0700 (PDT) Received: (qmail 993 invoked by uid 500); 5 Sep 2001 13:11:58 -0000 Date: Wed, 5 Sep 2001 08:11:58 -0500 From: Ryan Moats To: Steven Legg Cc: ietf-ldup@imc.org Subject: Re: WG Last Call on URP I-D Message-ID: <20010905081158.A983@armada.local.windrose.omaha.ne.us> References: <20010824110334.A919@armada.local.windrose.omaha.ne.us> <002901c135e5$9c7809e0$b05508cb@osmium.adacel.com.au> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <002901c135e5$9c7809e0$b05508cb@osmium.adacel.com.au>; from steven.legg@adacel.com.au on Wed, Sep 05, 2001 at 07:34:41PM +1100 Sender: owner-ietf-ldup@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: On Wed, Sep 05, 2001 at 07:34:41PM +1100, Steven Legg wrote: | | Ryan, | | Ryan Moats wrote: | > What I seemed to miss was the discussion of primitive generation | > with respect to attribute types, attribute subtypes and | > attribute options. | > Specifically there was no clarification | > | > - whether attribute subtypes and options were or were not | > supported. I | > believe absense of a restriction means they are, but others | > could read | > absense of a restriction to mean they are not. | | The absence of any clear direction in URP on subtyping issues is an | oversight. I had been assuming that attribute subtyping is basically | ignored by URP, as is the case for updating in general and for X.500 | replication updates in particular. I shall add words to the URP | document to the effect that attribute types in a subtype hierarchy | are treated as distinct and unrelated types by URP. | | Attribute options are a different matter since RFC 2251 isn't clear | about how this form of subtyping applies to updates. For example, | does a request to delete the cn attribute also delete the cn;foobar | attribute ? If I can assume that the answer is no then I can just | say that attribute types with options are also treated as distinct | and unrelated types by URP. The alternative answer will require more | extensive changes. Hmm, I would think that principle of least surprise would say that deleting cn wouls also delete cn;foobar. I'd like to hear what others think of course. | Regardless of the answer, the replication primitives have a type | parameter which is described as an attribute type. In the meantime | I will revise this to be an attribute description. Thanks. | | > | > - whether or not dsaOperation types could be replicated. Since the | > requirements draft states this as a MUST NOT (req G10), the lack of | > a discussion in the primitive generation portion of the document | > disturbs me. | | URP doesn't go into any detail about what is or isn't part of the area | of replication since that is in the scope of another LDUP document and | that document isn't yet ready to go to last call. URP just has a blanket | statement that replication primitives are generated only for directory | contents that are covered by the replication agreement, so it will | automatically conform to whatever the final LDUP model document says. | If the model draft says that dsaOperation types are never part of a | replication agreement then URP will never replicate that kind of | operational attribute and requirement G10 will be satisfied. | I *think* I may have found the blanket statement: (in section 5.2, first para, last sentence) "No replication primitives are generated for entries or entry contents that are outside the scope of the replication agreement." Is this indeed it? If so, I missed it the first time through and I'd suggest that it be made its own paragraph (along with the supporting text of 5.3) to make it more obvious. Ryan From owner-ietf-ldup@mail.imc.org Wed Sep 5 10:18:02 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA03903 for ; Wed, 5 Sep 2001 10:18:02 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id f85E6j819576 for ietf-ldup-bks; Wed, 5 Sep 2001 07:06:45 -0700 (PDT) Received: from kcmso1.proxy.att.com (kcmso1.att.com [192.128.133.69]) by above.proper.com (8.11.6/8.11.3) with ESMTP id f85E6hD19572 for ; Wed, 5 Sep 2001 07:06:43 -0700 (PDT) Received: from qsun.mt.att.com ([135.16.30.2]) by kcmso1.proxy.att.com (AT&T IPNS/MSO-3.0) with SMTP id f85E5QV21574; Wed, 5 Sep 2001 10:05:26 -0400 (EDT) Received: by qsun.mt.att.com (SMI-8.6/ATTEMS-1.4.1 sol2) id KAA02813; Wed, 5 Sep 2001 10:05:24 -0400 Date: Wed, 5 Sep 2001 10:05:24 -0400 Message-Id: <200109051405.KAA02813@qsun.mt.att.com> From: rvh@qsun.mt.att.com (Richard V Huber) To: rmoats@lemurnetworks.net, steven.legg@adacel.com.au Subject: Re: WG Last Call on URP I-D Cc: ietf-ldup@imc.org Sender: owner-ietf-ldup@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: I include an extract from an exchange between Ryan and Steven. Ryan notes that he would expect a delete of an attribute type to include all subtypes as well. I would have thought the same, but a check of RFC2596 (Language Tags) shows: 3.7. Modify Operation A client MAY provide a language code in an AttributeDescription as part of a modification element in the modify operation. Attribute types and language codes MUST match exactly against values stored in the directory. For example, if the modification is a "delete", then if the stored values to be deleted have a language code, the language code MUST be provided in the modify operation, and if the stored values to be deleted do not have a language code, then no language code is to be provided. In other operations (e.g. compare, search results), giving the attribute type DOES include all subtypes, but not for delete. So if we are going to be consistent with other work on attribute options (and 2596 seems to be the only RFC that discusses them in detail), we should assume that a request to delete cn DOES NOT delete cn;foobar. Rick Huber : On Wed, Sep 05, 2001 at 07:34:41PM +1100, Steven Legg wrote: : | : | Ryan, : | : | Ryan Moats wrote: : | > What I seemed to miss was the discussion of primitive generation : | > with respect to attribute types, attribute subtypes and : | > attribute options. : | > Specifically there was no clarification : | > : | > - whether attribute subtypes and options were or were not : | > supported. I : | > believe absense of a restriction means they are, but others : | > could read : | > absense of a restriction to mean they are not. : | : | The absence of any clear direction in URP on subtyping issues is an : | oversight. I had been assuming that attribute subtyping is basically : | ignored by URP, as is the case for updating in general and for X.500 : | replication updates in particular. I shall add words to the URP : | document to the effect that attribute types in a subtype hierarchy : | are treated as distinct and unrelated types by URP. : | : | Attribute options are a different matter since RFC 2251 isn't clear : | about how this form of subtyping applies to updates. For example, : | does a request to delete the cn attribute also delete the cn;foobar : | attribute ? If I can assume that the answer is no then I can just : | say that attribute types with options are also treated as distinct : | and unrelated types by URP. The alternative answer will require more : | extensive changes. : : Hmm, I would think that principle of least surprise would say that : deleting cn wouls also delete cn;foobar. I'd like to hear what : others think of course. From owner-ietf-ldup@mail.imc.org Wed Sep 5 10:43:50 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA05302 for ; Wed, 5 Sep 2001 10:43:50 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id f85EVAj21341 for ietf-ldup-bks; Wed, 5 Sep 2001 07:31:10 -0700 (PDT) Received: from pretender.boolean.net (root@router.boolean.net [198.144.206.49]) by above.proper.com (8.11.6/8.11.3) with ESMTP id f85EV5D21335 for ; Wed, 5 Sep 2001 07:31:05 -0700 (PDT) Received: from nomad.OpenLDAP.org (root@localhost [127.0.0.1]) by pretender.boolean.net (8.11.3/8.11.1/Boolean/Hub) with ESMTP id f85EUNC78230; Wed, 5 Sep 2001 14:30:23 GMT (envelope-from Kurt@OpenLDAP.org) Message-Id: <5.1.0.14.0.20010905072657.01c98fc8@127.0.0.1> X-Sender: kurt@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Wed, 05 Sep 2001 07:30:05 -0700 To: rvh@qsun.mt.att.com (Richard V Huber) From: "Kurt D. Zeilenga" Subject: Re: WG Last Call on URP I-D Cc: rmoats@lemurnetworks.net, steven.legg@adacel.com.au, ietf-ldup@imc.org In-Reply-To: <200109051405.KAA02813@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: RFC2251: An AttributeDescription with one or more options is treated as a subtype of the attribute type without any options. Of course, ;binary is a bit of an exception to this. LDAPbis is working on clarifications. Kurt From owner-ietf-ldup@mail.imc.org Wed Sep 5 11:11:23 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA06819 for ; Wed, 5 Sep 2001 11:11:22 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id f85EwN023898 for ietf-ldup-bks; Wed, 5 Sep 2001 07:58:23 -0700 (PDT) Received: from e1.ny.us.ibm.com (e1.ny.us.ibm.com [32.97.182.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id f85EwKD23891; Wed, 5 Sep 2001 07:58:20 -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 KAA397898; Wed, 5 Sep 2001 10:54:55 -0400 Received: from d27ml001.rchland.ibm.com (d27ml001.rchland.ibm.com [9.5.39.28]) by northrelay02.pok.ibm.com (8.11.1m3/NCO v4.97.1) with ESMTP id f85En2j43494; Wed, 5 Sep 2001 10:49:02 -0400 Subject: Re: WG Last Call on URP I-D To: rvh@qsun.mt.att.com (Richard V Huber) Cc: ietf-ldup@imc.org, owner-ietf-ldup@mail.imc.org, rmoats@lemurnetworks.net, steven.legg@adacel.com.au X-Mailer: Lotus Notes Release 5.0.8 June 18, 2001 Message-ID: From: "John McMeeking" Date: Wed, 5 Sep 2001 10:00:46 -0500 X-MIMETrack: Serialize by Router on d27ml001/27/M/IBM(Release 5.0.8 |June 18, 2001) at 09/05/2001 10:00:48 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: My two bits worth... RFC2596 seems to leave a bit of room for interpretation. As I read it (in the context of this discussion), section 3.7 seems to refer to deleting specific values. I don't think it applies to deleting all values of an attribute. I would expect that a modify that deletes a specific value requires a match on the attribute options. Deleting or replacing the entire attribute would not require a match. "Replacing" a single value, is a delete-value and add-value So, for an entry like: dn: cn=some entry ... description: description of entry description;lang-en: english description of entry 1) Delete entire attribute dn: cn=some entry changetype: modify delete: description would delete all description values, including description;lang-en 2) delete specific value, but didn't match option dn: cn=some entry changetype: modify delete: description description: english description of entry would fail 3) Replace entire attribute dn: cn=some entry changetype: modify replace: description description: new description would result in dn: cn=some entry ... description: new description # description;lang-en: english description of entry -- this value deleted 4) Replace specific value, but didn't match option dn: cn=some entry changetype: modify replace: description description: english description of entry - add: description;lang-en new english description would fail John McMeeking OS/400 Directory Services (507)253-4596 (T/L) 553-4596 rvh@qsun.mt.att.co m (Richard V To: rmoats@lemurnetworks.net, steven.legg@adacel.com.au Huber) cc: ietf-ldup@imc.org Sent by: Subject: Re: WG Last Call on URP I-D owner-ietf-ldup@ma il.imc.org 09/05/2001 09:05 AM I include an extract from an exchange between Ryan and Steven. Ryan notes that he would expect a delete of an attribute type to include all subtypes as well. I would have thought the same, but a check of RFC2596 (Language Tags) shows: 3.7. Modify Operation A client MAY provide a language code in an AttributeDescription as part of a modification element in the modify operation. Attribute types and language codes MUST match exactly against values stored in the directory. For example, if the modification is a "delete", then if the stored values to be deleted have a language code, the language code MUST be provided in the modify operation, and if the stored values to be deleted do not have a language code, then no language code is to be provided. In other operations (e.g. compare, search results), giving the attribute type DOES include all subtypes, but not for delete. So if we are going to be consistent with other work on attribute options (and 2596 seems to be the only RFC that discusses them in detail), we should assume that a request to delete cn DOES NOT delete cn;foobar. Rick Huber : On Wed, Sep 05, 2001 at 07:34:41PM +1100, Steven Legg wrote: : | : | Ryan, : | : | Ryan Moats wrote: : | > What I seemed to miss was the discussion of primitive generation : | > with respect to attribute types, attribute subtypes and : | > attribute options. : | > Specifically there was no clarification : | > : | > - whether attribute subtypes and options were or were not : | > supported. I : | > believe absense of a restriction means they are, but others : | > could read : | > absense of a restriction to mean they are not. : | : | The absence of any clear direction in URP on subtyping issues is an : | oversight. I had been assuming that attribute subtyping is basically : | ignored by URP, as is the case for updating in general and for X.500 : | replication updates in particular. I shall add words to the URP : | document to the effect that attribute types in a subtype hierarchy : | are treated as distinct and unrelated types by URP. : | : | Attribute options are a different matter since RFC 2251 isn't clear : | about how this form of subtyping applies to updates. For example, : | does a request to delete the cn attribute also delete the cn;foobar : | attribute ? If I can assume that the answer is no then I can just : | say that attribute types with options are also treated as distinct : | and unrelated types by URP. The alternative answer will require more : | extensive changes. : : Hmm, I would think that principle of least surprise would say that : deleting cn wouls also delete cn;foobar. I'd like to hear what : others think of course. From owner-ietf-ldup@mail.imc.org Wed Sep 5 11:25:06 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA07487 for ; Wed, 5 Sep 2001 11:25:05 -0400 (EDT) Received: by above.proper.com (8.11.6/8.11.3) id f85FCHr24331 for ietf-ldup-bks; Wed, 5 Sep 2001 08:12:17 -0700 (PDT) Received: from kcmso1.proxy.att.com (kcmso1.att.com [192.128.133.69]) by above.proper.com (8.11.6/8.11.3) with ESMTP id f85FCED24327 for ; Wed, 5 Sep 2001 08:12:14 -0700 (PDT) Received: from qsun.mt.att.com ([135.16.157.16]) by kcmso1.proxy.att.com (AT&T IPNS/MSO-3.0) with SMTP id f85FBCV03414; Wed, 5 Sep 2001 11:11:12 -0400 (EDT) Received: by qsun.mt.att.com (SMI-8.6/ATTEMS-1.4.1 sol2) id LAA15557; Wed, 5 Sep 2001 11:11:11 -0400 Date: Wed, 5 Sep 2001 11:11:11 -0400 Message-Id: <200109051511.LAA15557@qsun.mt.att.com> From: rvh@qsun.mt.att.com (Richard V Huber) To: Kurt@OpenLDAP.org Subject: Re: WG Last Call on URP I-D Cc: ietf-ldup@imc.org, rmoats@lemurnetworks.net, steven.legg@adacel.com.au Sender: owner-ietf-ldup@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Yes, that is why I said that I originally thought a reference to the type would include all subtypes for a delete. But 2251 does not go into detail on what it MEANS to be "treated as a "subtype of the attribute type without any options". RFC2596 is a standards track RFC that does provide detail on treatment of attribute options, at least for the specific case of language tags. I don't think we want to be in a situation where we say "a delete of an attribute type includes all subtypes unless the subtype begins with 'lang-' in which case the rules of 2596 apply". We need to treat all attribute options, including language tags, consistently (with possible exceptions for tags like ;binary). Is LDAPBIS going to reissue 2596? How do we deal with the inconsistency? Rick Huber : From Kurt@OpenLDAP.org Wed Sep 5 10:30:28 2001 : Return-Path: : X-Sender: kurt@127.0.0.1 : To: rvh@qsun.mt.att.com (Richard V Huber) : From: "Kurt D. Zeilenga" : Subject: Re: WG Last Call on URP I-D : Cc: rmoats@lemurnetworks.net, steven.legg@adacel.com.au, ietf-ldup@imc.org : Mime-Version: 1.0 : : RFC2251: : An AttributeDescription with one or more options is treated as a : subtype of the attribute type without any options. : : Of course, ;binary is a bit of an exception to this. LDAPbis : is working on clarifications. : : Kurt From owner-ietf-ldup@mail.imc.org Wed Sep 5 12:38:51 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA10375 for ; Wed, 5 Sep 2001 12:38:50 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id f85GPPm00215 for ietf-ldup-bks; Wed, 5 Sep 2001 09:25:25 -0700 (PDT) Received: from pretender.boolean.net (root@router.boolean.net [198.144.206.49]) by above.proper.com (8.11.6/8.11.3) with ESMTP id f85GPND00211 for ; Wed, 5 Sep 2001 09:25:23 -0700 (PDT) Received: from nomad.OpenLDAP.org (root@localhost [127.0.0.1]) by pretender.boolean.net (8.11.3/8.11.1/Boolean/Hub) with ESMTP id f85GPQC78535; Wed, 5 Sep 2001 16:25:26 GMT (envelope-from Kurt@OpenLDAP.org) Message-Id: <5.1.0.14.0.20010905090236.01c81578@127.0.0.1> X-Sender: kurt@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Wed, 05 Sep 2001 09:25:06 -0700 To: rvh@qsun.mt.att.com (Richard V Huber) From: "Kurt D. Zeilenga" Subject: Re: WG Last Call on URP I-D Cc: ietf-ldup@imc.org, rmoats@lemurnetworks.net, steven.legg@adacel.com.au In-Reply-To: <200109051511.LAA15557@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 08:11 AM 2001-09-05, Richard V Huber wrote: >Yes, that is why I said that I originally thought a reference to the >type would include all subtypes for a delete. But 2251 does not go >into detail on what it MEANS to be "treated as a "subtype of the >attribute type without any options". I believe it means that 'cn;foo' is to 'cn' as 'name' is to 'cn'. Hence, deleting 'cn' would NOT delete 'cn;foo'. I believe 2596 is consistent with this interpretation. >Is LDAPBIS going to reissue 2596? It's not a charter item. I would suspect the authors would revise this based upon clarifications to LDAPv3 produced by LDAPbis and language tag clarifications already published. I note that LDAPbis is considering the impact of changes it proposes upon this and other extensions. >How do we deal with the inconsistency? Well, the primary inconsistency is that we currently have two different semantics for options: 1) most options act as subtypes 2) transfer options (;binary) don't act as subtypes I've heard two different suggestions to deal with this: a) detail two kinds of options b) axe transfer options Currently, LDAPbis is attempting a). If you have comments in this area, I suggest they be directed to the LDAPbis list. From owner-ietf-ldup@mail.imc.org Wed Sep 5 16:38:56 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA21667 for ; Wed, 5 Sep 2001 16:38:55 -0400 (EDT) Received: by above.proper.com (8.11.6/8.11.3) id f85KLsW05987 for ietf-ldup-bks; Wed, 5 Sep 2001 13:21:54 -0700 (PDT) Received: from mail.speakeasy.net (mail11.speakeasy.net [216.254.0.211]) by above.proper.com (8.11.6/8.11.3) with ESMTP id f85KLrD05983 for ; Wed, 5 Sep 2001 13:21:53 -0700 (PDT) Received: (qmail 59784 invoked from network); 5 Sep 2001 20:21:55 -0000 Received: from unknown (HELO dtasi2.directory-applications.com) ([64.81.50.175]) (envelope-sender ) by mail11.speakeasy.net (qmail-ldap-1.03) with SMTP for ; 5 Sep 2001 20:21:55 -0000 Message-Id: <5.1.0.14.0.20010905131813.00aa4078@mail.dtasi.com> X-Sender: bgreenblatt@mail.dtasi.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Wed, 05 Sep 2001 13:19:11 -0700 To: Ryan Moats From: Bruce Greenblatt Subject: Re: WG Last Call on URP I-D Cc: ietf-ldup@imc.org In-Reply-To: <20010905081158.A983@armada.local.windrose.omaha.ne.us> References: <002901c135e5$9c7809e0$b05508cb@osmium.adacel.com.au> <20010824110334.A919@armada.local.windrose.omaha.ne.us> <002901c135e5$9c7809e0$b05508cb@osmium.adacel.com.au> 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: At 08:11 AM 9/5/01 -0500, Ryan Moats wrote: >Hmm, I would think that principle of least surprise would say that >deleting cn wouls also delete cn;foobar. I'd like to hear what >others think of course. I agree with Ryan on this one. ============================================== Bruce Greenblatt, Ph. D. Directory Tools and Application Services, Inc. http://www.directory-applications.com From owner-ietf-ldup@mail.imc.org Thu Sep 6 02:04:53 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA15356 for ; Thu, 6 Sep 2001 02:04:53 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id f865pJn15348 for ietf-ldup-bks; Wed, 5 Sep 2001 22:51:19 -0700 (PDT) Received: from arnie.adacel.com.au (arnie.adacel.com.au [203.36.26.147]) by above.proper.com (8.11.6/8.11.3) with SMTP id f865pCD15342 for ; Wed, 5 Sep 2001 22:51:13 -0700 (PDT) Received: (qmail 15963 invoked from network); 6 Sep 2001 05:56:50 -0000 Received: from osmium.adacel.com.au (HELO osmium) (203.8.85.176) by arnie.adacel.com.au with SMTP; 6 Sep 2001 05:56:50 -0000 Reply-To: From: "Steven Legg" To: "'Kurt D. Zeilenga'" Cc: Subject: RE: WG Last Call on URP I-D Date: Thu, 6 Sep 2001 16:52:07 +1100 Message-ID: <000001c13698$110391a0$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: <5.1.0.14.0.20010824093137.00b11a58@127.0.0.1> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V4.72.2120.0 Sender: owner-ietf-ldup@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit Kurt, Kurt D. Zeilenga wrote: > I think the editors need to review the document to > ensure all necessary normative references are in > place. The document appears to be dependent on > LCUP (for entryUUID) and a variety of other LDUP > documents but contains no reference to them. Earlier drafts of the URP document had a reference to the LDUP architecture draft but this was taken out because it was decided at an ad-hoc meeting of the LDUP document editors (IIRC it was at the Washington IETF) that the architecture draft would reference the part specifications like URP, the model, the protocol (separate at that time), etc, and not the other way around. I think the reasoning was that the part specifications could then be progressed as each was completed instead of waiting until the whole of LDUP was ready. I can put appropriate references back in but that presumably halts progression of the URP document until the documents it references go through last call. I'll leave it to our working group chairs to advise how to proceed on this issue. > I note > as well that no other LDUP document formally references > this specification. The architecture draft, at least, was supposed to. > > As such, I am unsure of the context in which this > specification is meant to be used and hence find it > hard to perform a complete review. > > I note the only context I have from the I-D is LDAPv3 > and X.500, both which provide no support for multiple > master replication and, hence, have no need for such > procedures. Which is why they don't reference the URP document :-). The references are there because URP relies on the concepts of entries, attributes, values, matching rules, etc. > It seems the Abstract and Introduction > need more work to detail the context in which this > specification is used. The expection was (still is ?) that the architecture draft, in its final edit, would be providing that context. > > Kurt Regards, Steven From owner-ietf-ldup@mail.imc.org Thu Sep 6 03:51:40 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA17138 for ; Thu, 6 Sep 2001 03:51:39 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id f867SAJ00982 for ietf-ldup-bks; Thu, 6 Sep 2001 00:28:10 -0700 (PDT) Received: from arnie.adacel.com.au (arnie.adacel.com.au [203.36.26.147]) by above.proper.com (8.11.6/8.11.3) with SMTP id f867RxD00932 for ; Thu, 6 Sep 2001 00:28:01 -0700 (PDT) Received: (qmail 27588 invoked from network); 6 Sep 2001 07:33:28 -0000 Received: from osmium.adacel.com.au (HELO osmium) (203.8.85.176) by arnie.adacel.com.au with SMTP; 6 Sep 2001 07:33:28 -0000 Reply-To: From: "Steven Legg" To: "'Ryan Moats'" Cc: , Subject: RE: WG Last Call on URP I-D Date: Thu, 6 Sep 2001 18:28:45 +1100 Message-ID: <000201c136a5$90711b80$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: <20010905081158.A983@armada.local.windrose.omaha.ne.us> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V4.72.2120.0 Sender: owner-ietf-ldup@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit Ryan, Ryan Moats wrote: > On Wed, Sep 05, 2001 at 07:34:41PM +1100, Steven Legg wrote: > | > | Ryan, > | > | Ryan Moats wrote: > | > What I seemed to miss was the discussion of primitive generation > | > with respect to attribute types, attribute subtypes and > | > attribute options. > | > Specifically there was no clarification > | > > | > - whether attribute subtypes and options were or were not > | > supported. I > | > believe absense of a restriction means they are, but others > | > could read > | > absense of a restriction to mean they are not. > | > | The absence of any clear direction in URP on subtyping issues is an > | oversight. I had been assuming that attribute subtyping is basically > | ignored by URP, as is the case for updating in general and for X.500 > | replication updates in particular. I shall add words to the URP > | document to the effect that attribute types in a subtype hierarchy > | are treated as distinct and unrelated types by URP. > | > | Attribute options are a different matter since RFC 2251 isn't clear > | about how this form of subtyping applies to updates. For example, > | does a request to delete the cn attribute also delete the cn;foobar > | attribute ? If I can assume that the answer is no then I can just > | say that attribute types with options are also treated as distinct > | and unrelated types by URP. The alternative answer will require more > | extensive changes. > > Hmm, I would think that principle of least surprise would say that > deleting cn wouls also delete cn;foobar. I'd like to hear what > others think of course. What is surprising depends on your user. Someone who is familiar with X.500 attribute subtyping where subtypes are ignored for updates might be surprised that option subtypes are not ignored in LDAP updates. It is also surprising when values that weren't explicitly mentioned get deleted. Implicit deletion of anything is generally undesirable. Also consider that a request to remove just the cn value from an entry would require a delete and an add to put back the cn;foobar value. It is safer and cleaner to require that clients explicitly remove each option-subtyped value than to rely on them putting back any implicitly deleted ones. Deleting only the values of the nominated attribute options also side-steps questions of single versus multiple inheritance of options. For example, it avoids the need to know whether cn;foo;bar is a subtype of cn;bar. > | > - whether or not dsaOperation types could be replicated. Since the > | > requirements draft states this as a MUST NOT (req G10), the lack of > | > a discussion in the primitive generation portion of the document > | > disturbs me. > | > | URP doesn't go into any detail about what is or isn't part of the area > | of replication since that is in the scope of another LDUP document and > | that document isn't yet ready to go to last call. URP just has a blanket > | statement that replication primitives are generated only for directory > | contents that are covered by the replication agreement, so it will > | automatically conform to whatever the final LDUP model document says. > | If the model draft says that dsaOperation types are never part of a > | replication agreement then URP will never replicate that kind of > | operational attribute and requirement G10 will be satisfied. > | > > I *think* I may have found the blanket statement: > > (in section 5.2, first para, last sentence) > > "No replication primitives are generated for entries or entry contents > that are outside the scope of the replication agreement." > > Is this indeed it? It is. > If so, I missed it the first time through and > I'd suggest that it be made its own paragraph (along with the supporting > text of 5.3) to make it more obvious. It's easy enough to make it a separate paragraph but it's not clear to me what you regard as the supporting text of 5.3. Regards, Steven From owner-ietf-ldup@mail.imc.org Fri Sep 7 00:19:02 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA16789 for ; Fri, 7 Sep 2001 00:19:02 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id f872nwR20772 for ietf-ldup-bks; Thu, 6 Sep 2001 19:49:58 -0700 (PDT) Received: from pretender.boolean.net (root@router.boolean.net [198.144.206.49]) by above.proper.com (8.11.6/8.11.3) with ESMTP id f872nqD20767 for ; Thu, 6 Sep 2001 19:49:52 -0700 (PDT) Received: from nomad.OpenLDAP.org (root@localhost [127.0.0.1]) by pretender.boolean.net (8.11.3/8.11.1/Boolean/Hub) with ESMTP id f872nfC85089; Fri, 7 Sep 2001 02:49:41 GMT (envelope-from Kurt@OpenLDAP.org) Message-Id: <5.1.0.14.0.20010906194056.01bb7fd8@127.0.0.1> X-Sender: kurt@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Thu, 06 Sep 2001 19:49:36 -0700 To: From: "Kurt D. Zeilenga" Subject: RE: WG Last Call on URP I-D Cc: In-Reply-To: <000001c13698$110391a0$b05508cb@osmium.adacel.com.au> References: <5.1.0.14.0.20010824093137.00b11a58@127.0.0.1> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-ldup@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: I think that appropriate references need to be added. One cannot implement the specification without reading LCUP and various LDUP documents. I also of the opinion that it would be best to progress the complete LDUP technical specification at one time, primarily because reviewing it in piecewise is extremely difficult. Kurt At 10:52 PM 2001-09-05, Steven Legg wrote: >Kurt, > >Kurt D. Zeilenga wrote: >> I think the editors need to review the document to >> ensure all necessary normative references are in >> place. The document appears to be dependent on >> LCUP (for entryUUID) and a variety of other LDUP >> documents but contains no reference to them. > >Earlier drafts of the URP document had a reference to the LDUP >architecture draft but this was taken out because it was decided >at an ad-hoc meeting of the LDUP document editors (IIRC it was >at the Washington IETF) that the architecture draft would reference >the part specifications like URP, the model, the protocol (separate >at that time), etc, and not the other way around. I think the reasoning >was that the part specifications could then be progressed as each was >completed instead of waiting until the whole of LDUP was ready. > >I can put appropriate references back in but that presumably halts >progression of the URP document until the documents it references >go through last call. I'll leave it to our working group chairs to >advise how to proceed on this issue. > >> I note >> as well that no other LDUP document formally references >> this specification. > >The architecture draft, at least, was supposed to. > >> >> As such, I am unsure of the context in which this >> specification is meant to be used and hence find it >> hard to perform a complete review. >> >> I note the only context I have from the I-D is LDAPv3 >> and X.500, both which provide no support for multiple >> master replication and, hence, have no need for such >> procedures. > >Which is why they don't reference the URP document :-). > >The references are there because URP relies on the concepts >of entries, attributes, values, matching rules, etc. > >> It seems the Abstract and Introduction >> need more work to detail the context in which this >> specification is used. > >The expection was (still is ?) that the architecture draft, in its final >edit, would be providing that context. > >> >> Kurt > >Regards, >Steven From owner-ietf-ldup@mail.imc.org Fri Sep 7 12:20:26 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA18960 for ; Fri, 7 Sep 2001 12:20:25 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id f87G4ca16047 for ietf-ldup-bks; Fri, 7 Sep 2001 09:04:38 -0700 (PDT) Received: from e1.ny.us.ibm.com (e1.ny.us.ibm.com [32.97.182.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id f87G4bD16042 for ; Fri, 7 Sep 2001 09:04:37 -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 MAA285686; Fri, 7 Sep 2001 12:02:18 -0400 Received: from d27ml001.rchland.ibm.com (d27ml001.rchland.ibm.com [9.5.39.28]) by northrelay02.pok.ibm.com (8.11.1m3/NCO v4.97.1) with ESMTP id f87FuNF234728; Fri, 7 Sep 2001 11:56:24 -0400 Subject: RE: WG Last Call on URP I-D To: Cc: ietf-ldup@imc.org X-Mailer: Lotus Notes Release 5.0.8 June 18, 2001 Message-ID: From: "John McMeeking" Date: Fri, 7 Sep 2001 11:08:09 -0500 X-MIMETrack: Serialize by Router on d27ml001/27/M/IBM(Release 5.0.8 |June 18, 2001) at 09/07/2001 11:08:11 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: See responses In short - two responses that I thought might call for changes -- everything else looked fine. Also, there was a misunderstanding about subsequent replication of some URP resolutions. Rereading some stuff in that light, I see 4.1 mentions a pre-allocated unique identifier for Lost&Found. This is seems necessary for URP. It also implies a single Lost&Found for the entire server. The other documents do not seem to imply a single Lost&Found. I am okay with that, but I want to make sure this is what others expect. John McMeeking OS/400 Directory Services (507)253-4596 (T/L) 553-4596 "Steven Legg" cc: Subject: RE: WG Last Call on URP I-D 09/04/2001 02:18 AM Please respond to steven.legg John McMeeking wrote: > We have reviewed the LDUP Update Resolution Procedures Internet Draft > (draft-ietf-ldup-urp-04.txt) and have the following comments. Thanks for taking the time to have a close look at the document. > > > 1. Section 4.4, second para. It seems that a glue entry ought to be used > when breaking DIT loops. The glue entry would contain the DN of the > entry's parent at the time it was moved to Lost & Found. Without this, > there is nothing to tell an administrator where this entry originally came > from. We also note that glue entries are ill-defined at best in many > documents, and it is not clear whether statements that "a glue entry has > knowledge only of its name" is meant to imply that is knows the DN of the > entry it represents, or that a glue entry has its RDN (entryuuid=x) as its > only attribute. The description of glue entries in the architecture draft is inaccurate and needs further work. The URP draft is written on the assumption that certain concepts, like glue entries, replication agreements, Update Vectors, etc, are properly specified in the architecture draft. Insofar as they are not properly described, that is a problem with the architecture draft, not the URP draft. Glue entries touch upon the area of Directory Specific Entries, manageDSAIT controls and like, which have much wider scope than just URP and are still under debate. These topics are something the working group will have to address before LDUP can be considered complete but right now the URP document isn't the place to be resolving them. In the meantime, like so many things in LDAP, one must look to X.500 for a complete explanation. FYI, as far as URP is concerned, a glue entry can contain anything that a regular entry can contain except that it isn't necessarily a complete entry (parts can be missing) and isn't normally seen by average users. > > > 2. Section 5.1.3, b and c. You might note that Section 5.2 will show why > attribute value deletion records are not required in these cases. Case c) explicitly *does* require (attribute) value deletion records. An attribute deletion record instead of value deletion records for case b) was a free design choice (based on what is most likely to match the user's intention) so I don't see in what way Section 5.2 shows why value deletion records are not required for case b). Section 5.2 would work either way. I think I let a typo slip through -- I meant b and d (not c). Back to the original comment: Should there be any statement added that 5.2 (specifically when p-remove-attribute supercedes other primitives) shows why value deletion records are not required? > Under > (d), you might note that d) covers the special case for replace where a > replace with no attribute values is treated as a attribute deletion. I'll add an "if any" to the end of the last sentence in d). I'd rather not say that a replace with no values is treated like a deletion since a replace with listed values is most definitely *not* treated like a deletion with listed values. I think it is better to describe each case in isolation. I think it would be clearer to add a sentence like: "The replace alternative with no attribute values generates only an attribute deletion record." > > > 3. Section 5.2, 1st para. Clarify that supplier is scanning entry, > attribute, and value CSNs. Current wording could leave one to think the > supplier is just looking at entry CSNs. The first paragraph introduces the basic idea and the subsequent paragraphs provide the detail. It should be abundantly clear from the subsequent paragraphs that the Name CSN, Parent CSN, Entry CSN and attribute value CSNs of an entry are all examined. Anyway, I propose this rewording of the third sentence in the first paragraph. "Conceptually, the supplier scans all the entries (glue and non-glue), entry contents and deletion records that are covered by the replication agreement with the consumer" ... Looks good. > In the second paragraph, "A > p-add-entry primitive is generated for each entry whose entry CSN is > greater than the Update Vector CSN for the same replica." what does "same > replica" refer to? Consumer replica? Would adding this following paragraph after the first paragraph clarify the situation ? "The consumer's Update Vector has a CSN for each replica in the replica group. Each CSN held by the supplier contains a Replica Identifier. When a CSN held by the supplier is compared to the consumer's Update Vector during the generation of replication primitives it is compared to the single CSN in the consumer's Update Vector that has the same Replica Identifier as the held CSN." If so, I will also tweak the wording of the subsequent paragraphs, e.g. "A p-add-entry primitive is generated for each entry whose Entry CSN is greater than the Update Vector CSN with the same Replica Identifier." Looks good. > > 4. Section 5.3.5, 2nd para. Could improve the grammar of the 3rd sentnce > by changing "If not, it disambiguates the names of the entries by adding > the Unique Identifier (i.e. the entryUUID attribute) of each of the > conflicting entries to their own RDN" to "... to each entry's RDN." That wording might suggest that every UUID is added to every conflicting entry. How about this wording instead ? "If not, it disambiguates the names of the entries by adding each conflicting entry's Unique Identifier to its RDN (i.e. making the value of its entryUUID attribute distinguished)." Looks good > > > 5. Section 5.3.5, CheckUniqueness function: > > IF E.rdn is empty > make C.uid distinguished > > Please explain this test. Why are we checking to see if the entry has > no RDN, and IF so, make the OLD conflicting entry's name contain the UID? It's a typo. > Perhaps make C.uid distinguished should be make E.uid distinguished? Yes. I'll make the correction. > > > 6. Section 5.3.5, just before RenameEntry(E,P). The pareter description > is missing the name of the second parameter. Perhaps: > "The parameters to this procedure are the entry, E, and the p-add-entry or > p-rename-entry primitive, P, specifying the new RDN." > ", P," was missing. OR "The parameters to this procedure are the entry, E, and P, the p-add-entry or p-rename-entry primitive specifying the new RDN." Looks good. > > > 7. Section 5.3.5, RenameEntry(E,P). After > V.csn := GenerateNextCSN(V.csn) > Should a log-based implementation log a primitive for this change? We > think so. Yes it should. This action is mandated in the first paragraph of Section 5.3.3. Missed that somehow. We were laboring under the misunderstanding that update resolution was done independently by each server (i.e. didn't result in additional replication primitives). > > The above comment also applies to 5.3.7 and 5.3.8. And to Section 5.3.11. All these cases are covered by the first paragraph of Section 5.3.3. > > > 8. Section 5.3.6. > replace V with P.value if they are not identical > Shouldn't this be: > replace V with P.value if they are not identical AND > the type is single-valued? No. The action also applies to values of multi-valued attribute types for the reason given in the first paragraph of Section 5.3.4. Got it. > > 9. Section 5.3.8 > > FOREACH attribute value, V, of type P.type in E (if any) > IF P.csn > V.csn > IF V is distinguished > IF ProtectDistinguished() > V.csn := GenerateNextCSN(P.csn) > ELSE > { > R := E.rdn > remove value V > CheckUniqueness(E, E.superior, R) > } > ELSE > remove value V > >>> StoreAttributeDeletion (P.uid, P.type, P.csn) > > If ProtectDistinguished() is TRUE, then the attribute deletion is false. > We should store Attribute Value deletions for all NON-distinguished values > - or, store an Attribute deletion and an attribute ADD for the > distinguished value. The procedure is already doing the latter. The CSN on the distinguished value is reset to the value returned by the GenerateNextCSN function call so a p-add-attribute-value primitive will be generated in due course. Got it. > > > 10. Section 5.3.11 and 5.3.12. Where we create glue entries, i.e. > E := CreateGlueEntry(P.uid) > Shouldn't this be followed by: > E.superior = LOST_AND_FOUND The CreateGlueEntry function does this already. To quote from Section 5.3.2: "The CreateGlueEntry function is called when required to create a glue entry as a subordinate of Lost & Found". Got it. > > > 11. Section 5.3.12 > replace V with N.value if they are not identical > Shouldn't this be: > replace V with N.value if they are not identical AND > the type is single-valued? Same response as for point 8. Got it. > > > 12. Section 5.3.11. We have two additional concerns with the p-move-entry > primitive. As written, it appears that Lost and Found of the participating > replicas do not all end up in the same state. They all end up in the same state when the full implications of the GenerateNextCSN function are considered. The missing steps in the example are discussed below. > Also, by moving entries > directly under Lost & Found, information about the original parent of the > entry is lost. We suggest that p-move-entry place entries under a glue > entry that has knowledge of the original parent DN. There is no doubt all sorts of useful information about the recent states of an entry that we could be collecting to present to administrators later, but since it doesn't have any bearing on URP and LDUP server interworking I've chosen not to go down that rat hole. URP doesn't preclude implementations from collecting and keeping additional records and I'm happy to leave such things to experimentation for now. > > The following example illustrates the first concern: > > Consider the following DIT: > > o=A L & F > | > ------------ > | | > ou=B ou=C > > And suppose there are two replicas, 1 & 2. > > at t1: client on server 1 moves ou=C beneath ou=B > > at t2: client on server 2 moves ou=B beneath ou=C > > DITs on each server now look like: > > Server 1: Server 2: > o=A o=A > | | > ------------ ------------ > | | | | > ou=B ou=C > | | > ou=C ou=B > > at t3: server 1 receives updates from server 2 > p-move-entry(B, t2, C) > This results in a loop, and the resolution is to move B to L&F In addition, the GenerateNextCSN function is called to reset the CSN on B's superior reference. This means that immediately (log-based) or eventually (state-based) a p-move-entry(B, t3, LOST_AND_FOUND) is generated and propagated to server 2. > > at t4: server 2 receives updates from server 1 > p-move-entry(C, t1, B) > This results in a loop, and the resolution is to move C to L&F Likewise, a p-move-entry(C, t4, LOST_AND_FOUND) is generated and propagated to server 1. > > Final outcome: > > Server 1: Server 2: > o=A L & F o=A L & F > | | | | > glue entry glue entry > | | > ou=B ou=C > | | > ou=C ou=B > > We ended up with differing outcomes in Lost and Found. Taking into consideration the two extra p-move-entry primitives, the final outcome at both servers is: o=A L & F | | ------------ | | ou=B ou=C Note that in this case there are no glue entries created. Okay. Regards, Steven From owner-ietf-ldup@mail.imc.org Mon Sep 10 04:09:29 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA07098 for ; Mon, 10 Sep 2001 04:09:28 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id f8A7qFC20734 for ietf-ldup-bks; Mon, 10 Sep 2001 00:52:15 -0700 (PDT) Received: from arnie.adacel.com.au (arnie.adacel.com.au [203.36.26.147]) by above.proper.com (8.11.6/8.11.3) with SMTP id f8A7qAD20726 for ; Mon, 10 Sep 2001 00:52:11 -0700 (PDT) Received: (qmail 2338 invoked from network); 10 Sep 2001 07:51:45 -0000 Received: from osmium.adacel.com.au (HELO osmium) (203.8.85.176) by arnie.adacel.com.au with SMTP; 10 Sep 2001 07:51:45 -0000 Reply-To: From: "Steven Legg" To: "'John McMeeking'" Cc: Subject: RE: WG Last Call on URP I-D Date: Mon, 10 Sep 2001 17:46:17 +1100 Message-ID: <003401c139c4$4b7b0050$b05508cb@osmium.adacel.com.au> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook 8.5, Build 4.71.2377.0 X-MIMEOLE: Produced By Microsoft MimeOLE V4.72.2120.0 Importance: Normal In-Reply-To: Sender: owner-ietf-ldup@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit John, John McMeeking wrote: > See > > responses > > John McMeeking wrote: > > 2. Section 5.1.3, b and c. You might note that Section > 5.2 will show > why > > attribute value deletion records are not required in these cases. > > Case c) explicitly *does* require (attribute) value deletion records. > An attribute deletion record instead of value deletion > records for case b) > was a free design choice (based on what is most likely to > match the user's > intention) so I don't see in what way Section 5.2 shows why > value deletion > records are not required for case b). Section 5.2 would work > either way. > > > I think I let a typo slip through -- I meant b and d (not c). > Back to the > original comment: Should there be any statement added that 5.2 > (specifically when p-remove-attribute supercedes other > primitives) shows > why value deletion records are not required? > Now I understand. A statement like the following ? "It is not necessary to generate p-remove-attribute-value primitives for each of the values actually removed because the p-remove-attribute primitive would supersede all such primitives, by the rules in Section 5.2." I'll add it if you think it helps. > > > Under > > (d), you might note that d) covers the special case for > replace where a > > replace with no attribute values is treated as a attribute deletion. > > I'll add an "if any" to the end of the last sentence in d). > I'd rather not say that a replace with no values is treated like a > deletion since a replace with listed values is most definitely *not* > treated like a deletion with listed values. I think it is better to > describe each case in isolation. > > > I think it would be clearer to add a sentence like: "The replace > alternative with no attribute values generates only an > attribute deletion > record." > Okay. I'll add this. Regards, Steven From owner-ietf-ldup@mail.imc.org Mon Sep 10 08:28:17 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA12214 for ; Mon, 10 Sep 2001 08:28:17 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id f8ACEt112283 for ietf-ldup-bks; Mon, 10 Sep 2001 05:14:55 -0700 (PDT) Received: from e1.ny.us.ibm.com (e1.ny.us.ibm.com [32.97.182.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id f8ACErD12279 for ; Mon, 10 Sep 2001 05:14:53 -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 IAA384952; Mon, 10 Sep 2001 08:12:32 -0400 Received: from d27ml001.rchland.ibm.com (d27ml001.rchland.ibm.com [9.5.39.28]) by northrelay02.pok.ibm.com (8.11.1m3/NCO v4.97.1) with ESMTP id f8AC6cd75128; Mon, 10 Sep 2001 08:06:38 -0400 Subject: RE: WG Last Call on URP I-D To: Cc: ietf-ldup@imc.org X-Mailer: Lotus Notes Release 5.0.8 June 18, 2001 Message-ID: From: "John McMeeking" Date: Mon, 10 Sep 2001 07:18:27 -0500 X-MIMETrack: Serialize by Router on d27ml001/27/M/IBM(Release 5.0.8 |June 18, 2001) at 09/10/2001 07:18: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: We think both changes would help. Thanks. John McMeeking OS/400 Directory Services (507)253-4596 (T/L) 553-4596 "Steven Legg" cc: Subject: RE: WG Last Call on URP I-D 09/10/2001 01:46 AM Please respond to steven.legg John, John McMeeking wrote: > See > > responses > > John McMeeking wrote: > > 2. Section 5.1.3, b and c. You might note that Section > 5.2 will show > why > > attribute value deletion records are not required in these cases. > > Case c) explicitly *does* require (attribute) value deletion records. > An attribute deletion record instead of value deletion > records for case b) > was a free design choice (based on what is most likely to > match the user's > intention) so I don't see in what way Section 5.2 shows why > value deletion > records are not required for case b). Section 5.2 would work > either way. > > > I think I let a typo slip through -- I meant b and d (not c). > Back to the > original comment: Should there be any statement added that 5.2 > (specifically when p-remove-attribute supercedes other > primitives) shows > why value deletion records are not required? > Now I understand. A statement like the following ? "It is not necessary to generate p-remove-attribute-value primitives for each of the values actually removed because the p-remove-attribute primitive would supersede all such primitives, by the rules in Section 5.2." I'll add it if you think it helps. > > > Under > > (d), you might note that d) covers the special case for > replace where a > > replace with no attribute values is treated as a attribute deletion. > > I'll add an "if any" to the end of the last sentence in d). > I'd rather not say that a replace with no values is treated like a > deletion since a replace with listed values is most definitely *not* > treated like a deletion with listed values. I think it is better to > describe each case in isolation. > > > I think it would be clearer to add a sentence like: "The replace > alternative with no attribute values generates only an > attribute deletion > record." > Okay. I'll add this. Regards, Steven From owner-ietf-ldup@mail.imc.org Thu Sep 13 23:34:40 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA26323 for ; Thu, 13 Sep 2001 23:34:39 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id f8E2rDP16160 for ietf-ldup-bks; Thu, 13 Sep 2001 19:53:13 -0700 (PDT) Received: from arnie.adacel.com.au (arnie.adacel.com.au [203.36.26.147]) by above.proper.com (8.11.6/8.11.3) with SMTP id f8E2rAD16155 for ; Thu, 13 Sep 2001 19:53:10 -0700 (PDT) Received: (qmail 8636 invoked from network); 14 Sep 2001 03:00:13 -0000 Received: from osmium.adacel.com.au (HELO osmium) (203.8.85.176) by arnie.adacel.com.au with SMTP; 14 Sep 2001 03:00:13 -0000 Reply-To: From: "Steven Legg" To: "'Kurt D. Zeilenga'" Cc: Subject: RE: value v. representation Date: Fri, 14 Sep 2001 13:54:10 +1100 Message-ID: <001b01c13cc8$883c3f20$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: <5.1.0.14.0.20010904082254.01b382e8@127.0.0.1> 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 Kurt, Kurt D. Zeilenga wrote: > Section 5.3.4 ends with the sentence: > Whenever a CSN for some value is refreshed the value is > also refreshed using the exact value from the primitive > so that all directory servers use exactly the same > representation for the value. > > It should likely read: > Whenever a CSN for some value is refreshed the value is > also refreshed using the exact value from the primitive > so that all directory servers use the same value. Each > server is, of course, free to represent the value > in any form allowed by the attribute's syntax. I understand where you're coming from and I agree (it's what I meant), but there is a definitional problem with the meaning of "exact value" and "same value". Many people will interpret "same" to mean equal according to the equality matching rule, but we're already talking about a situation where URP has two values that are the "same" according to the equality matching rule, but still not identical. We understand that values exist in an abtract sense that is independent of which encoding (e.g. native LDAP or binary) is used to transfer them in protocol. Since a server could be storing values in any of the possible encodings, or in some other entirely different format, it is not appropriate to just test whether two values have the same series of octets. We need a definition of "identical" that is more fundamental than the usual equality matching rules and that does not depend on the transfer encoding. It occurs to me that the allComponentsMatch matching rule from draft-legg-ldapext-component-matching-03.txt provides a reasonable and well-defined test for the identicality of values that is independent of transfer encoding. If I make use of this definition in URP then the last sentence of the first paragraph in Section 5.3.4 could be reworded like this: "Whenever a CSN for some stored value is refreshed, the stored value itself is also refreshed using the value from the primitive if the stored value and primitive value are not identical. For the purposes of the procedures described in this document, two values are considered identical if they compare TRUE according to the allComponentsMatch matching rule defined in [CMR]. The purpose of refreshing stored values is so that all directory servers converge to the exact same abstract value. Each server is, of course, free to represent the value using any transfer encoding defined for the attribute's syntax." [CMR] being a reference to the component matching rules draft. The final paragraph in the section also needs to be reworded. A stored value that is replaced by the value from a primitive retains its distinguished or non-distinguished status. This includes replaced values of single-valued attribute types. > > Replicas must converge to the same value, not to the same > representation of that value. Note: CN value 'Foo Bar' > is not the same value as CN 'Foo Bar' though they > equal per the equality rule. Replicas must converge to > one or the other (per URP). However, a member > value of 'CN=Foo Bar' is the same as CN='Foo\20Bar'; no > change is required by either replica. > > That is, URP must not force one replicas preferred form > upon another server. I totally agree. > > BTW, the URP seems to be dependent upon having an EQUALITY > rule defined for each attribute type and for each replica > to implement this rule. What happens when the attribute > does [ not ] have an EQUALITY matching rule? Good question. I will have to add some text to cover this situation. The simple solution is to regard all values of such an attribute as being different. This would mean that stored values and values in a primitive are never considered equal, so duplicate values with different CSNs could accumulate in the attribute and the p-remove-attribute-value primitive will be ineffectual. However, if the servers are playing by the rules they should not be allowing clients to add or remove individual values of the attribute. The only permitted changes are to add, remove or replace the entire attribute. Therefore, except when values are first added to an attribute, there will be a p-remove-attribute primitive immediately prior to the p-add-attribute-value primitives for the added values, and only the values of the latest (by CSN) add or replace will appear in the attribute. It is possible that values could be simultaneously initially added to the previously non-existent attribute at two separate replicas, which would eventually lead to both sets of values appearing in the attribute. We can fix it so that only the set with the latest CSN appears in the attribute but it is hard to say which is the more desirable outcome, so I don't propose to "fix" it. The same effect will be achieved anyway if clients always use the replace alternative on attributes without an equality matching rule. > or one replica implements > the rule and another doesn't? This is just one of many possible functional inconsistencies or differing levels of conformance that will thwart URP, or LDUP in general. There is an obvious requirement that servers should only be replicating between themselves the attributes and entries to which they are equally capable of applying URP and the other LDUP procedures. The possible cases are innumerable, and it is mostly an issue of what can be usefully specified in replication agreements, so I don't intend saying anything about this in the URP document, and I'm not going to attempt to define what "equally capable" means. > > Kurt > > Regards, Steven From owner-ietf-ldup@mail.imc.org Fri Sep 21 02:19:51 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA13752 for ; Fri, 21 Sep 2001 02:19:50 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id f8L5uHc16358 for ietf-ldup-bks; Thu, 20 Sep 2001 22:56:17 -0700 (PDT) Received: from mgw-x2.nokia.com (mgw-x2.nokia.com [131.228.20.22]) by above.proper.com (8.11.6/8.11.3) with ESMTP id f8L5uFD16354 for ; Thu, 20 Sep 2001 22:56:16 -0700 (PDT) Received: from esvir02nok.nokia.com (esvir02nokt.ntc.nokia.com [172.21.143.34]) by mgw-x2.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id f8L5uo309442 for ; Fri, 21 Sep 2001 08:56:50 +0300 (EET DST) Received: from esebh25nok.ntc.nokia.com (unverified) by esvir02nok.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id for ; Fri, 21 Sep 2001 08:56:19 +0300 Received: by esebh25nok with Internet Mail Service (5.5.2652.78) id <3MSWSC4Q>; Fri, 21 Sep 2001 08:56:19 +0300 Message-ID: <80E79E0EE6BCD3468E7A01C9E5BAD2200BC88A@esebe003.NOE.Nokia.com> From: jukka.aakula@nokia.com To: ietf-ldup@imc.org Subject: Question on LCUP Date: Fri, 21 Sep 2001 08:56:12 +0300 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2652.78) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ietf-ldup@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Hi, I have a question on LCUP scalability. Shall the LCUP be scalable on number of persistent search requests ? I suppose the main use of LCUP is the following: The client caches a well defined subset ( like one subtree ) of the directory. Then there is propably only one or some Persistent Searches per client ? But suppose the client keeps a more dynamic cache in the sense that when the client "gets interested" in a certain entry, the client allways makes a Persistent Search ? Shall the LCUP scale for such situations ? The implementation of LCUP can then not be: Whenever an entry is modified go through all the Searches and act. At least an index is needed to find the relevant Searches. Is the scalability a standardisation issue at all ? Jukka Aakula From owner-ietf-ldup@mail.imc.org Fri Sep 21 11:28:10 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA28462 for ; Fri, 21 Sep 2001 11:28:09 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id f8LF7kZ08185 for ietf-ldup-bks; Fri, 21 Sep 2001 08:07:46 -0700 (PDT) Received: from netscape.com (r2d2.netscape.com [205.217.237.47]) by above.proper.com (8.11.6/8.11.3) with ESMTP id f8LF7iD08179 for ; Fri, 21 Sep 2001 08:07:44 -0700 (PDT) Received: from dredd.mcom.com (dredd.mcom.com [205.217.237.54]) by netscape.com (8.10.0/8.10.0) with ESMTP id f8LF7eh11388 for ; Fri, 21 Sep 2001 08:07:40 -0700 (PDT) Received: from netscape.com ([205.217.229.88]) by dredd.mcom.com (Netscape Messaging Server 4.15) with ESMTP id GK0Q0S00.BAZ; Fri, 21 Sep 2001 08:07:40 -0700 Message-ID: <3BAB56FC.6466DEE0@netscape.com> Date: Fri, 21 Sep 2001 09:04:28 -0600 From: richm@netscape.com (Rich Megginson) Organization: Netscape - Enterprise Products X-Mailer: Mozilla 4.76 [en] (WinNT; U) X-Accept-Language: en,pdf MIME-Version: 1.0 To: jukka.aakula@nokia.com CC: ietf-ldup@imc.org Subject: Re: Question on LCUP References: <80E79E0EE6BCD3468E7A01C9E5BAD2200BC88A@esebe003.NOE.Nokia.com> Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms621897CFFDFB40D4A54ECE41" Sender: owner-ietf-ldup@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a cryptographically signed message in MIME format. --------------ms621897CFFDFB40D4A54ECE41 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit jukka.aakula@nokia.com wrote: > Hi, > > I have a question on LCUP scalability. > > Shall the LCUP be scalable on number of persistent search requests ? > > I suppose the main use of LCUP is the following: > > The client caches a well defined subset ( like one > subtree ) of the directory. > > Then there is propably only one or some Persistent Searches > per client ? I should think the client would only have 1 Persistent Search at a time. > But suppose the client keeps a more dynamic cache in the sense > that when the client "gets interested" in a certain entry, > the client allways makes a Persistent Search ? Do you mean the client makes an additional Persistent Search? I don't think that would be necessary. If the client somehow becomes interested in an entry outside the scope of the current LCUP request, the client could simply close the connection and issue another LCUP request with a wider scope. I suppose the worst case would be that a client is interested in checking for changes in several naming contexts. In which case, the client would need an LCUP search for each naming context. > Shall the LCUP scale for such situations ? The implementation > of LCUP can then not be: > > Whenever an entry is modified go through all the Searches > and act. > > At least an index is needed to find the relevant Searches. > > Is the scalability a standardisation issue at all ? No, I don't think so. There are ways to efficiently index (or otherwise lookup) Searches on the server. LCUP does not (and I do not think it should) address implementation details. > > > Jukka Aakula --------------ms621897CFFDFB40D4A54ECE41 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature Content-Transfer-Encoding: base64 MIIJFwYJKoZIhvcNAQcCoIIJCDCCCQQCAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3DQEHAaCC BuowggMMMIICdaADAgECAgI4bjANBgkqhkiG9w0BAQQFADCBkzELMAkGA1UEBhMCVVMxCzAJ BgNVBAgTAkNBMRYwFAYDVQQHEw1Nb3VudGFpbiBWaWV3MRswGQYDVQQKExJBbWVyaWNhIE9u bGluZSBJbmMxGTAXBgNVBAsTEEFPTCBUZWNobm9sb2dpZXMxJzAlBgNVBAMTHkludHJhbmV0 IENlcnRpZmljYXRlIEF1dGhvcml0eTAeFw0wMTA2MDQxMzIzNTlaFw0wMTEyMDExMzIzNTla MIGCMRMwEQYKCZImiZPyLGQBGRYDY29tMRgwFgYKCZImiZPyLGQBGRYIbmV0c2NhcGUxITAf BgkqhkiG9w0BCQEWEnJpY2htQG5ldHNjYXBlLmNvbTEXMBUGA1UEAxMOUmljaCBNZWdnaW5z b24xFTATBgoJkiaJk/IsZAEBEwVyaWNobTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEA vzzOOuvTS4h7GhcAGzqVeimRSAAhcKDPG9I3nBzbjyhahyg1l+9jL3aWxzjZTeUc3mAvWuoK 3NsNsI6N4MV9kH2NDUEEw3GsSweDEU6MFBwPA2YCxa8Ct0NkR+VRWG/YfUalO/OqROKZ5KBY tiJCR31RQ5Iiwxe4ZgPVfrYoVzUCAwEAAaN+MHwwEQYJYIZIAYb4QgEBBAQDAgWgMA4GA1Ud DwEB/wQEAwIF4DA2BggrBgEFBQcBAQQqMCgwJgYIKwYBBQUHMAGGGmh0dHA6Ly9uc29jc3Au bmV0c2NhcGUuY29tMB8GA1UdIwQYMBaAFCnbsi2Dfn+LI7vCzGa5Oegp8wKGMA0GCSqGSIb3 DQEBBAUAA4GBAMkxCPa1hNJmPODo+PvjDyGxRdXIKlgcbWMDuoBVZ7OulY006Jg02nnvwNnq q8wLIciyyjVP1rTpHsBApNCGxkRa5Oc5sCetbnyP5ZIOBCaOe0Bh/IWDDTHl3y9HTWmNxX8b OPkzNkWGigfW45m2Xr3lTjnUhXdFgt4QU57EbizQMIID1jCCAz+gAwIBAgIEAgAB5jANBgkq hkiG9w0BAQUFADBFMQswCQYDVQQGEwJVUzEYMBYGA1UEChMPR1RFIENvcnBvcmF0aW9uMRww GgYDVQQDExNHVEUgQ3liZXJUcnVzdCBSb290MB4XDTAxMDYwMTEyNDcwMFoXDTA0MDYwMTIz NTkwMFowgZMxCzAJBgNVBAYTAlVTMQswCQYDVQQIEwJDQTEWMBQGA1UEBxMNTW91bnRhaW4g VmlldzEbMBkGA1UEChMSQW1lcmljYSBPbmxpbmUgSW5jMRkwFwYDVQQLExBBT0wgVGVjaG5v bG9naWVzMScwJQYDVQQDEx5JbnRyYW5ldCBDZXJ0aWZpY2F0ZSBBdXRob3JpdHkwgZ8wDQYJ KoZIhvcNAQEBBQADgY0AMIGJAoGBAOLvXyx2Q4lLGl+z5fiqb4svgU1n/71KD2MuxNyF9p4s SSYg/wAX5IiIad79g1fgoxEZEarW3Lzvs9IVLlTGbny/2bnDRtMJBYTlU1xI7YSFmg47PRYH XPCzeauaEKW8waTReEwG5WRB/AUlYybr7wzHblShjM5UV7YfktqyEkuNAgMBAAGjggGCMIIB fjBNBgNVHR8ERjBEMEKgQKA+hjxodHRwOi8vd3d3MS51cy1ob3N0aW5nLmJhbHRpbW9yZS5j b20vY2dpLWJpbi9DUkwvR1RFUm9vdC5jZ2kwHQYDVR0OBBYEFCnbsi2Dfn+LI7vCzGa5Oegp 8wKGMGYGA1UdIARfMF0wRgYKKoZIhvhjAQIBBTA4MDYGCCsGAQUFBwIBFipodHRwOi8vd3d3 LmJhbHRpbW9yZS5jb20vQ1BTL09tbmlSb290Lmh0bWwwEwYDKgMEMAwwCgYIKwYBBQUHAgEw WAYDVR0jBFEwT6FJpEcwRTELMAkGA1UEBhMCVVMxGDAWBgNVBAoTD0dURSBDb3Jwb3JhdGlv bjEcMBoGA1UEAxMTR1RFIEN5YmVyVHJ1c3QgUm9vdIICAaMwKwYDVR0QBCQwIoAPMjAwMTA2 MDExMjQ3MzBagQ8yMDAzMDkwMTIzNTkwMFowDgYDVR0PAQH/BAQDAgEGMA8GA1UdEwQIMAYB Af8CAQEwDQYJKoZIhvcNAQEFBQADgYEASmIO2fpGdwQKbA3d/tIiOZkQCq6ILYY9V4TmEiQ3 aftZXuIRsPmfpFeGimkfBmPRfe4zNkkQIA8flxcsJ2w9bDkEe+JF6IcbVLZgQW0drgXznfk6 NJrje2tMcfjrqCuDsDWQTBloce3wYyJewlvsIHq1sFFz6QfugWd2eVP3ldQxggH1MIIB8QIB ATCBmjCBkzELMAkGA1UEBhMCVVMxCzAJBgNVBAgTAkNBMRYwFAYDVQQHEw1Nb3VudGFpbiBW aWV3MRswGQYDVQQKExJBbWVyaWNhIE9ubGluZSBJbmMxGTAXBgNVBAsTEEFPTCBUZWNobm9s b2dpZXMxJzAlBgNVBAMTHkludHJhbmV0IENlcnRpZmljYXRlIEF1dGhvcml0eQICOG4wCQYF Kw4DAhoFAKCBsTAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0w MTA5MjExNTA0MjhaMCMGCSqGSIb3DQEJBDEWBBRlSWwF7chAIhtA9YsVIz2qDPUr0jBSBgkq hkiG9w0BCQ8xRTBDMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDAHBgUrDgMCBzANBggq hkiG9w0DAgIBQDANBggqhkiG9w0DAgIBKDANBgkqhkiG9w0BAQEFAASBgC33TxIow/XsUcHj sL5jvMD50q1Hq/zA8KU41obgEUygm3IfZCnePZJhMrT9hoiolyH+/ejiwdwJVn5iIwYQxFfv 6kvWLq7S+HaoQJcXOEA8/MOn9xkoSv2Fg4W3sLo256Vc/sxVfKrOfIVZ4ikowb7IbNMBU/+n 7GfKN7WlmkkA --------------ms621897CFFDFB40D4A54ECE41-- From owner-ietf-ldup@mail.imc.org Mon Sep 24 09:07:05 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA02343 for ; Mon, 24 Sep 2001 09:07:05 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id f8O68V616906 for ietf-ldup-bks; Sun, 23 Sep 2001 23:08:31 -0700 (PDT) Received: from mgw-x1.nokia.com (mgw-x1.nokia.com [131.228.20.21]) by above.proper.com (8.11.6/8.11.3) with ESMTP id f8O68TD16894 for ; Sun, 23 Sep 2001 23:08:29 -0700 (PDT) Received: from esvir01nok.ntc.nokia.com (esvir01nokt.ntc.nokia.com [172.21.143.33]) by mgw-x1.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id f8O66v905790 for ; Mon, 24 Sep 2001 09:06:57 +0300 (EET DST) Received: from esebh01nok.ntc.nokia.com (unverified) by esvir01nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Mon, 24 Sep 2001 09:08:32 +0300 Received: from samail01.nmp.nokia.com ([131.228.240.6]) by esebh01nok.ntc.nokia.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2652.78) id T3XAFVPH; Mon, 24 Sep 2001 09:08:32 +0300 Received: from www.nmp.nokia.com (www.nmp.nokia.com [131.228.244.112]) by samail01.nmp.nokia.com (8.8.6 (PHNE_17135)/8.8.6) with ESMTP id JAA12425; Mon, 24 Sep 2001 09:26:51 +0200 (EET) Received: from nokia.com (essrv103nok148107.ntc.nokia.com [172.21.148.107]) by www.nmp.nokia.com (8.9.3 (PHNE_18979)/8.8.4) with ESMTP id IAA05543; Mon, 24 Sep 2001 08:44:28 +0300 (EETDST) Message-ID: <3BAEC865.2AACA4AE@nokia.com> Date: Mon, 24 Sep 2001 08:45:09 +0300 From: JUKA AAKULA Organization: Nokia X-Mailer: Mozilla 4.06 [en] (WinNT; I) MIME-Version: 1.0 To: ietf-ldup@imc.org, richm@netscape.com Subject: Re: Question on LCUP 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 Thank you for the answer, Rich Still a question below: >> But suppose the client keeps a more dynamic cache in the sense >> that when the client "gets interested" in a certain entry, >> the client allways makes a Persistent Search ? > >Do you mean the client makes an additional Persistent Search? I don't think that would be necessary. If the client somehow >becomes interested in an entry outside the scope of the current LCUP request, the client could simply close the connection >and issue another LCUP request with a wider scope. Take an example: there are one million subscribers in a telephone catalogue. Each subscriber entry is immediately below the root entry. A client maintains a cache with a subset of the subscriber entries using persistent search. Each time a new subscriber is added in the subset the subscriber entry is searched for in the telephone catalogue using persistent search. (The subset is say members of some club.) Is such use of LCUP fully infeasible ? Or should the client make a persistent search for all the entries in the catalogue but skipping those it's not interested in ? Jukka From owner-ietf-ldup@mail.imc.org Mon Sep 24 10:47:55 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA15108 for ; Mon, 24 Sep 2001 10:47:53 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id f8OENEk29156 for ietf-ldup-bks; Mon, 24 Sep 2001 07:23:14 -0700 (PDT) Received: from netscape.com (c3po.netscape.com [205.217.237.46]) by above.proper.com (8.11.6/8.11.3) with ESMTP id f8OENCD29152 for ; Mon, 24 Sep 2001 07:23:12 -0700 (PDT) Received: from dredd.mcom.com (dredd.mcom.com [205.217.237.54]) by netscape.com (8.10.0/8.10.0) with ESMTP id f8OEN5Z07916 for ; Mon, 24 Sep 2001 07:23:05 -0700 (PDT) Received: from netscape.com ([205.217.229.184]) by dredd.mcom.com (Netscape Messaging Server 4.15) with ESMTP id GK67YJ00.HR9; Mon, 24 Sep 2001 07:23:07 -0700 Message-ID: <3BAF4109.B3F17E51@netscape.com> Date: Mon, 24 Sep 2001 08:19:53 -0600 From: richm@netscape.com (Rich Megginson) Organization: Netscape - Enterprise Products X-Mailer: Mozilla 4.76 [en] (WinNT; U) X-Accept-Language: en,pdf MIME-Version: 1.0 To: JUKA AAKULA CC: ietf-ldup@imc.org Subject: Re: Question on LCUP References: <3BAEC865.2AACA4AE@nokia.com> Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------msF303EEB91D635A7981B74212" Sender: owner-ietf-ldup@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a cryptographically signed message in MIME format. --------------msF303EEB91D635A7981B74212 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit JUKA AAKULA wrote: > Thank you for the answer, Rich > > Still a question below: > > >> But suppose the client keeps a more dynamic cache in the sense > >> that when the client "gets interested" in a certain entry, > >> the client allways makes a Persistent Search ? > > > >Do you mean the client makes an additional Persistent Search? I don't > think that would be necessary. If the client somehow > >becomes interested in an entry outside the scope of the current LCUP > request, the client could simply close the connection > >and issue another LCUP request with a wider scope. > > Take an example: there are one million subscribers in a telephone > catalogue. Each subscriber entry is immediately > below the root entry. > > A client maintains a cache with a subset of the subscriber entries using > persistent search. Each time a new subscriber is added in the subset the > subscriber entry is searched for in the telephone catalogue using > persistent search. (The subset is say > members of some club.) > > Is such use of LCUP fully infeasible ? No. In the LCUP model, you would do an LCUP (persistent) search with (for example) a base of o=root and a search filter of cn=some club. When a new entry is added, only that new entry is sent back via the persistent search. If for some reason the client was disconnected, the client issues an LCUP search the next time it is connected and gets back only the entries which were added or modified since the last LCUP search. > Or should the client make a persistent search for all the entries in the > catalogue but skipping those > it's not interested in ? I'm not sure that's necessary, since LCUP should only give you back the entries you are interested in. > > > Jukka --------------msF303EEB91D635A7981B74212 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature Content-Transfer-Encoding: base64 MIIJFwYJKoZIhvcNAQcCoIIJCDCCCQQCAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3DQEHAaCC BuowggMMMIICdaADAgECAgI4bjANBgkqhkiG9w0BAQQFADCBkzELMAkGA1UEBhMCVVMxCzAJ BgNVBAgTAkNBMRYwFAYDVQQHEw1Nb3VudGFpbiBWaWV3MRswGQYDVQQKExJBbWVyaWNhIE9u bGluZSBJbmMxGTAXBgNVBAsTEEFPTCBUZWNobm9sb2dpZXMxJzAlBgNVBAMTHkludHJhbmV0 IENlcnRpZmljYXRlIEF1dGhvcml0eTAeFw0wMTA2MDQxMzIzNTlaFw0wMTEyMDExMzIzNTla MIGCMRMwEQYKCZImiZPyLGQBGRYDY29tMRgwFgYKCZImiZPyLGQBGRYIbmV0c2NhcGUxITAf BgkqhkiG9w0BCQEWEnJpY2htQG5ldHNjYXBlLmNvbTEXMBUGA1UEAxMOUmljaCBNZWdnaW5z b24xFTATBgoJkiaJk/IsZAEBEwVyaWNobTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEA vzzOOuvTS4h7GhcAGzqVeimRSAAhcKDPG9I3nBzbjyhahyg1l+9jL3aWxzjZTeUc3mAvWuoK 3NsNsI6N4MV9kH2NDUEEw3GsSweDEU6MFBwPA2YCxa8Ct0NkR+VRWG/YfUalO/OqROKZ5KBY tiJCR31RQ5Iiwxe4ZgPVfrYoVzUCAwEAAaN+MHwwEQYJYIZIAYb4QgEBBAQDAgWgMA4GA1Ud DwEB/wQEAwIF4DA2BggrBgEFBQcBAQQqMCgwJgYIKwYBBQUHMAGGGmh0dHA6Ly9uc29jc3Au bmV0c2NhcGUuY29tMB8GA1UdIwQYMBaAFCnbsi2Dfn+LI7vCzGa5Oegp8wKGMA0GCSqGSIb3 DQEBBAUAA4GBAMkxCPa1hNJmPODo+PvjDyGxRdXIKlgcbWMDuoBVZ7OulY006Jg02nnvwNnq q8wLIciyyjVP1rTpHsBApNCGxkRa5Oc5sCetbnyP5ZIOBCaOe0Bh/IWDDTHl3y9HTWmNxX8b OPkzNkWGigfW45m2Xr3lTjnUhXdFgt4QU57EbizQMIID1jCCAz+gAwIBAgIEAgAB5jANBgkq hkiG9w0BAQUFADBFMQswCQYDVQQGEwJVUzEYMBYGA1UEChMPR1RFIENvcnBvcmF0aW9uMRww GgYDVQQDExNHVEUgQ3liZXJUcnVzdCBSb290MB4XDTAxMDYwMTEyNDcwMFoXDTA0MDYwMTIz NTkwMFowgZMxCzAJBgNVBAYTAlVTMQswCQYDVQQIEwJDQTEWMBQGA1UEBxMNTW91bnRhaW4g VmlldzEbMBkGA1UEChMSQW1lcmljYSBPbmxpbmUgSW5jMRkwFwYDVQQLExBBT0wgVGVjaG5v bG9naWVzMScwJQYDVQQDEx5JbnRyYW5ldCBDZXJ0aWZpY2F0ZSBBdXRob3JpdHkwgZ8wDQYJ KoZIhvcNAQEBBQADgY0AMIGJAoGBAOLvXyx2Q4lLGl+z5fiqb4svgU1n/71KD2MuxNyF9p4s SSYg/wAX5IiIad79g1fgoxEZEarW3Lzvs9IVLlTGbny/2bnDRtMJBYTlU1xI7YSFmg47PRYH XPCzeauaEKW8waTReEwG5WRB/AUlYybr7wzHblShjM5UV7YfktqyEkuNAgMBAAGjggGCMIIB fjBNBgNVHR8ERjBEMEKgQKA+hjxodHRwOi8vd3d3MS51cy1ob3N0aW5nLmJhbHRpbW9yZS5j b20vY2dpLWJpbi9DUkwvR1RFUm9vdC5jZ2kwHQYDVR0OBBYEFCnbsi2Dfn+LI7vCzGa5Oegp 8wKGMGYGA1UdIARfMF0wRgYKKoZIhvhjAQIBBTA4MDYGCCsGAQUFBwIBFipodHRwOi8vd3d3 LmJhbHRpbW9yZS5jb20vQ1BTL09tbmlSb290Lmh0bWwwEwYDKgMEMAwwCgYIKwYBBQUHAgEw WAYDVR0jBFEwT6FJpEcwRTELMAkGA1UEBhMCVVMxGDAWBgNVBAoTD0dURSBDb3Jwb3JhdGlv bjEcMBoGA1UEAxMTR1RFIEN5YmVyVHJ1c3QgUm9vdIICAaMwKwYDVR0QBCQwIoAPMjAwMTA2 MDExMjQ3MzBagQ8yMDAzMDkwMTIzNTkwMFowDgYDVR0PAQH/BAQDAgEGMA8GA1UdEwQIMAYB Af8CAQEwDQYJKoZIhvcNAQEFBQADgYEASmIO2fpGdwQKbA3d/tIiOZkQCq6ILYY9V4TmEiQ3 aftZXuIRsPmfpFeGimkfBmPRfe4zNkkQIA8flxcsJ2w9bDkEe+JF6IcbVLZgQW0drgXznfk6 NJrje2tMcfjrqCuDsDWQTBloce3wYyJewlvsIHq1sFFz6QfugWd2eVP3ldQxggH1MIIB8QIB ATCBmjCBkzELMAkGA1UEBhMCVVMxCzAJBgNVBAgTAkNBMRYwFAYDVQQHEw1Nb3VudGFpbiBW aWV3MRswGQYDVQQKExJBbWVyaWNhIE9ubGluZSBJbmMxGTAXBgNVBAsTEEFPTCBUZWNobm9s b2dpZXMxJzAlBgNVBAMTHkludHJhbmV0IENlcnRpZmljYXRlIEF1dGhvcml0eQICOG4wCQYF Kw4DAhoFAKCBsTAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0w MTA5MjQxNDE5NTNaMCMGCSqGSIb3DQEJBDEWBBQHlCuXJSK7vWo+jYL7v6VQDjJnbjBSBgkq hkiG9w0BCQ8xRTBDMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDAHBgUrDgMCBzANBggq hkiG9w0DAgIBQDANBggqhkiG9w0DAgIBKDANBgkqhkiG9w0BAQEFAASBgF1K8Vm8iS9if/oc RRNWXSLLWgPkh24P8qbR+hV5k88hGzvNnOegBKrfbFSyOaAcwbSeCEfCgXQUKXJNd/k9wDBo hbQkH402xuxQ4zTkTNhAZGIyAsN0y0Vauu7z2+QYDGqztrGcVeXH2AjXEpM+3TPSa7RE4yTc /j0FV03sO3ou --------------msF303EEB91D635A7981B74212-- From owner-ietf-ldup@mail.imc.org Tue Sep 25 00:16:44 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA08665 for ; Tue, 25 Sep 2001 00:16:44 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id f8P3okS24434 for ietf-ldup-bks; Mon, 24 Sep 2001 20:50:46 -0700 (PDT) Received: from mgw-x2.nokia.com (mgw-x2.nokia.com [131.228.20.22]) by above.proper.com (8.11.6/8.11.3) with ESMTP id f8P3oiD24430 for ; Mon, 24 Sep 2001 20:50:44 -0700 (PDT) Received: from esvir02nok.nokia.com (esvir02nokt.ntc.nokia.com [172.21.143.34]) by mgw-x2.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id f8P3pJ313854 for ; Tue, 25 Sep 2001 06:51:19 +0300 (EET DST) Received: from esebh25nok.ntc.nokia.com (unverified) by esvir02nok.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Tue, 25 Sep 2001 06:50:47 +0300 Received: by esebh25nok with Internet Mail Service (5.5.2652.78) id ; Tue, 25 Sep 2001 06:50:47 +0300 Message-ID: <80E79E0EE6BCD3468E7A01C9E5BAD2200BC8A5@esebe003.NOE.Nokia.com> From: jukka.aakula@nokia.com To: richm@netscape.com Cc: ietf-ldup@imc.org Subject: RE: Question on LCUP Date: Tue, 25 Sep 2001 06:50:45 +0300 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2652.78) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ietf-ldup@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Still one point on the club example: If the club membership is maintained in the directory your solution is ok, if the club membership is maintained outside the directory ( in the client ) it is not. Jukka > -----Original Message----- > From: ext Rich Megginson [mailto:richm@netscape.com] > Sent: 24. September 2001 17:20 > To: Aakula Jukka (NET/Espoo) > Cc: ietf-ldup@imc.org > Subject: Re: Question on LCUP > > > JUKA AAKULA wrote: > > > Thank you for the answer, Rich > > > > Still a question below: > > > > >> But suppose the client keeps a more dynamic cache in the sense > > >> that when the client "gets interested" in a certain entry, > > >> the client allways makes a Persistent Search ? > > > > > >Do you mean the client makes an additional Persistent > Search? I don't > > think that would be necessary. If the client somehow > > >becomes interested in an entry outside the scope of the > current LCUP > > request, the client could simply close the connection > > >and issue another LCUP request with a wider scope. > > > > Take an example: there are one million subscribers in a telephone > > catalogue. Each subscriber entry is immediately > > below the root entry. > > > > A client maintains a cache with a subset of the subscriber > entries using > > persistent search. Each time a new subscriber is added in > the subset the > > subscriber entry is searched for in the telephone catalogue using > > persistent search. (The subset is say > > members of some club.) > > > > Is such use of LCUP fully infeasible ? > > No. In the LCUP model, you would do an LCUP (persistent) > search with (for example) a base of o=root and a search filter of > cn=some club. When a new entry is added, only that new entry > is sent back via the persistent search. If for some reason the > client was disconnected, the client issues an LCUP search the > next time it is connected and gets back only the entries which were > added or modified since the last LCUP search. > > > Or should the client make a persistent search for all the > entries in the > > catalogue but skipping those > > it's not interested in ? > > I'm not sure that's necessary, since LCUP should only give > you back the entries you are interested in. > > > > > > > Jukka > From owner-ietf-ldup@mail.imc.org Fri Sep 28 10:23:29 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA16142 for ; Fri, 28 Sep 2001 10:23:28 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id f8SDnov06111 for ietf-ldup-bks; Fri, 28 Sep 2001 06:49:50 -0700 (PDT) Received: from e2.ny.us.ibm.com (e2.ny.us.ibm.com [32.97.182.102]) by above.proper.com (8.11.6/8.11.3) with ESMTP id f8SDnnD06107 for ; Fri, 28 Sep 2001 06:49:49 -0700 (PDT) Received: from northrelay02.pok.ibm.com (northrelay02.pok.ibm.com [9.117.200.22]) by e2.ny.us.ibm.com (8.9.3/8.9.3) with ESMTP id JAA163460 for ; Fri, 28 Sep 2001 09:47:23 -0400 Received: from d27ml001.rchland.ibm.com (d27ml001.rchland.ibm.com [9.5.39.28]) by northrelay02.pok.ibm.com (8.11.1m3/NCO v4.97.1) with ESMTP id f8SDmQq14558 for ; Fri, 28 Sep 2001 09:48:26 -0400 Subject: Operations crossing replication contexts To: ietf-ldup@imc.org X-Mailer: Lotus Notes Release 5.0.8 June 18, 2001 Message-ID: From: "John McMeeking" Date: Fri, 28 Sep 2001 08:52:07 -0500 X-MIMETrack: Serialize by Router on d27ml001/27/M/IBM(Release 5.0.8 |June 18, 2001) at 09/28/2001 08:52:10 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: Thought I'd move a discussion between Steven Legg and myself into the public eye... This particular discussion is about how to deal with operations that cross replication contexts: - move an entry/subtree from one replication context to another - delete/rename entries that ancesters of replication contexts (mentioned at March IETF meeting) It hasn't progressed to the point of proposing concrete solutions just yet. With respect to moving entries between replication contexts, we note that this has to be initiated on a server that has contains updateable replicas of both contexts, else the server would fail the client request. However, others servers may have replicas of only one of the contexts. Perhaps such an action shouldn't be allowed. Perhaps it should be allowed only if the initial server can detect (based on replicaSubebtries) that both contexts are present on all relevant servers. Or it requires a bit more invention. With respect to the second point, this has to do with how a server knows what the boundaries of a replication context are, then how the server(s) should behave. An engineering group was formed at the March IETF meeting. I couldn't attend the first get together, and I am not aware that anything happened afterwards. An example of the situation: - renaming the ancester of a relication context has the effect the renaming the child replication context. The server where the ancester is located may not be aware that the child context even exists. Should this be allowed? How would replication handle it? John McMeeking IBM ----- Forwarded by John McMeeking/Rochester/IBM on 09/28/2001 08:31 AM ----- "Steven Legg" cc: Subject: RE: Single lost & found (RE: WG Last Call on URP 09/28/2001 12:01 I-D) AM Please respond to steven.legg John, Apologies for taking my time responding. > Pondering this a bit more... > > The problem of cross replication context operations could be > rather crudely > solved by stating that LDUP does not support moving entries > into or out of > areas of replication. You must delete entries from the source, and > recreate them in the target. Hopefully an implementation > would provide > some tools to make that exercise simpler. I'm not sure requiring delete/insert for moves between replication contexts actually solves more problems than it creates. Moves by delete/insert are something I want to avoid, in part because it makes moving subtrees expensive and dangerous. Expensive because every entry in the subtree has to be deleted and reinserted, and dangerous because other updates to entries in the subtree could get lost or corrupted. Recovery from system crashes in the middle of a subtree move also has to be dealt with. Since the propagation of updates between servers is not instantaneous, we would still have to deal with the possibility of a clash between an already propagating move update and a propagating administrative action to repartition the replication area. Propagation delays and conflicting changes also make it possible for a server to perform what looks to it like an intra-context move but which to another server appears to be an inter-context move. This can happen even if both servers have full knowledge of the replication context boundaries. I also have concerns with any solution where consumer DSAs making secondary shadowing agreements can hamstring the operations of the original supplier DSA, i.e. by creating additional replication context boundaries across which the original supplier can no longer do simple moves. In X.500 replication (which we implement) a supplier DSA doesn't need to have any knowledge of the secondary replication agreements a consumer might make. This is a good thing for scalability in large distributed environments. My preferred approach is to have a go at solving the problems with entries moving in and out scope for partial replicas, and apply that solution to entries moving in and out of replication contexts, since the problem spaces appear to be related. I haven't been devoting much time to thinking about replication in recent times but an LDUP implementation is on the agenda for our next release so I will be spending more time on it. In the last couple of days I've been following up on the idea of tagging entries with the replication areas in which they appear. This approach is looking promising. I'll let you and the rest of the working group know what I discover. > > That still leaves the question of how a server knows when an operation > crosses such boundaries. I asked that question at the March > IETF meeting > in Minneapolis. An engineering group was formed (to include LDAP-EXT > folks), and far as I can tell, never met. I've had various > thoughts on the > matter. Except for the effects of propagation delays I don't see a serious problem in deciding if a move crosses a boundary, but maybe we're not talking about the same thing. A server can only action a move operation if it masters both the old and new superior entries. If it masters those entries then it will have the necessary information about the replication context of each. A new superior entry in a child replication context held in the same server presents no problem. If the child replication context is primarily held in a different server then the superior server either doesn't master the new superior so it will disallow the move, or it replicates the subordinate server's replication context in which case it has the necessary information. > - One idea was that each server participated in a > domain-like entity,where > the definition of the domain resides in LDAP as a special area of > replication. Each server then can has knowledge of all the > replication > contexts and all the servers. Alternately, x.500 glue > entries might be > used. My sense is that this type of approach implies more distributed > directory function than the LDUP members want. > - At a minimum, it seems that each server needs to know the > bounds of the > replicas it hosts, that is the names of subordinate > replication contexts. > I envision this being done through something like an > operational attribute > of a replication context. When a child area of replication > is created, the > "childReplicationContext" attribute of the parent replication > context is > updated, and that change replicated to other replicas of the parent. > Deleting a child replication context may require > administrative action, as > I don't see how any single server could know that it held the last > remaining copy of the child area of replication (unless this > happens on a > server that holds both the parent and child replication contexts). I > suppose creating a child area of replication might require > administrative > action too, unless we require that the child be created on a > server that > also holds the parent. And as I think this through more, I > suppose that > some sort of glue entry would do the trick here (possibly > with a reference > to some server containing that replication context). > > Either way, it implies that something holds knowledge of the entire > replication topology, and that a tool hide as much of the nastiness as > possible. > > Any thoughts? And I suppose I really ought to put this > discussion on the > LDUP mailing list. Do you agree? It wouldn't hurt. Regards, Steven From owner-ietf-ldup@mail.imc.org Sat Sep 29 17:24:33 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA26199 for ; Sat, 29 Sep 2001 17:24:32 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id f8TKtPo07880 for ietf-ldup-bks; Sat, 29 Sep 2001 13:55:25 -0700 (PDT) Received: from gull.mail.pas.earthlink.net (gull.mail.pas.earthlink.net [207.217.121.85]) by above.proper.com (8.11.6/8.11.3) with ESMTP id f8TKtOD07876 for ; Sat, 29 Sep 2001 13:55:24 -0700 (PDT) Received: from FARILJCS (sdn-ar-003cocsprP163.dialsprint.net [158.252.163.99]) by gull.mail.pas.earthlink.net (EL-8_9_3_3/8.9.3) with SMTP id NAA13943; Sat, 29 Sep 2001 13:55:17 -0700 (PDT) Reply-To: From: "John Strassner" To: "John McMeeking" , Subject: RE: Operations crossing replication contexts Date: Sat, 29 Sep 2001 13:55:26 -0700 MIME-Version: 1.0 Message-ID: X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) Importance: Normal In-Reply-To: Content-Type: multipart/signed; micalg=SHA1; boundary="----=_NextPart_000_00D6_01C148EC.673EDFA0"; protocol="application/x-pkcs7-signature" X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700 Sender: owner-ietf-ldup@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multi-part message in MIME format. ------=_NextPart_000_00D6_01C148EC.673EDFA0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hmmm, just when I was about to call to see if all of the comments were finished on URP, up pops this message. So I have a quick question to John, Steven, and others that are interested in this thread: is it your aim to resolve this question as part of the URP Last Call, or is this something that you think affects other documents than URP? thanks and kind regards, John -----Original Message----- From: owner-ietf-ldup@mail.imc.org [mailto:owner-ietf-ldup@mail.imc.org]On Behalf Of John McMeeking Sent: Friday, September 28, 2001 6:52 AM To: ietf-ldup@imc.org Subject: Operations crossing replication contexts Thought I'd move a discussion between Steven Legg and myself into the public eye... This particular discussion is about how to deal with operations that cross replication contexts: - move an entry/subtree from one replication context to another - delete/rename entries that ancesters of replication contexts (mentioned at March IETF meeting) It hasn't progressed to the point of proposing concrete solutions just yet. With respect to moving entries between replication contexts, we note that this has to be initiated on a server that has contains updateable replicas of both contexts, else the server would fail the client request. However, others servers may have replicas of only one of the contexts. Perhaps such an action shouldn't be allowed. Perhaps it should be allowed only if the initial server can detect (based on replicaSubebtries) that both contexts are present on all relevant servers. Or it requires a bit more invention. With respect to the second point, this has to do with how a server knows what the boundaries of a replication context are, then how the server(s) should behave. An engineering group was formed at the March IETF meeting. I couldn't attend the first get together, and I am not aware that anything happened afterwards. An example of the situation: - renaming the ancester of a relication context has the effect the renaming the child replication context. The server where the ancester is located may not be aware that the child context even exists. Should this be allowed? How would replication handle it? John McMeeking IBM ----- Forwarded by John McMeeking/Rochester/IBM on 09/28/2001 08:31 AM ----- "Steven Legg" cc: Subject: RE: Single lost & found (RE: WG Last Call on URP 09/28/2001 12:01 I-D) AM Please respond to steven.legg John, Apologies for taking my time responding. > Pondering this a bit more... > > The problem of cross replication context operations could be > rather crudely > solved by stating that LDUP does not support moving entries > into or out of > areas of replication. You must delete entries from the source, and > recreate them in the target. Hopefully an implementation > would provide > some tools to make that exercise simpler. I'm not sure requiring delete/insert for moves between replication contexts actually solves more problems than it creates. Moves by delete/insert are something I want to avoid, in part because it makes moving subtrees expensive and dangerous. Expensive because every entry in the subtree has to be deleted and reinserted, and dangerous because other updates to entries in the subtree could get lost or corrupted. Recovery from system crashes in the middle of a subtree move also has to be dealt with. Since the propagation of updates between servers is not instantaneous, we would still have to deal with the possibility of a clash between an already propagating move update and a propagating administrative action to repartition the replication area. Propagation delays and conflicting changes also make it possible for a server to perform what looks to it like an intra-context move but which to another server appears to be an inter-context move. This can happen even if both servers have full knowledge of the replication context boundaries. I also have concerns with any solution where consumer DSAs making secondary shadowing agreements can hamstring the operations of the original supplier DSA, i.e. by creating additional replication context boundaries across which the original supplier can no longer do simple moves. In X.500 replication (which we implement) a supplier DSA doesn't need to have any knowledge of the secondary replication agreements a consumer might make. This is a good thing for scalability in large distributed environments. My preferred approach is to have a go at solving the problems with entries moving in and out scope for partial replicas, and apply that solution to entries moving in and out of replication contexts, since the problem spaces appear to be related. I haven't been devoting much time to thinking about replication in recent times but an LDUP implementation is on the agenda for our next release so I will be spending more time on it. In the last couple of days I've been following up on the idea of tagging entries with the replication areas in which they appear. This approach is looking promising. I'll let you and the rest of the working group know what I discover. > > That still leaves the question of how a server knows when an operation > crosses such boundaries. I asked that question at the March > IETF meeting > in Minneapolis. An engineering group was formed (to include LDAP-EXT > folks), and far as I can tell, never met. I've had various > thoughts on the > matter. Except for the effects of propagation delays I don't see a serious problem in deciding if a move crosses a boundary, but maybe we're not talking about the same thing. A server can only action a move operation if it masters both the old and new superior entries. If it masters those entries then it will have the necessary information about the replication context of each. A new superior entry in a child replication context held in the same server presents no problem. If the child replication context is primarily held in a different server then the superior server either doesn't master the new superior so it will disallow the move, or it replicates the subordinate server's replication context in which case it has the necessary information. > - One idea was that each server participated in a > domain-like entity,where > the definition of the domain resides in LDAP as a special area of > replication. Each server then can has knowledge of all the > replication > contexts and all the servers. Alternately, x.500 glue > entries might be > used. My sense is that this type of approach implies more distributed > directory function than the LDUP members want. > - At a minimum, it seems that each server needs to know the > bounds of the > replicas it hosts, that is the names of subordinate > replication contexts. > I envision this being done through something like an > operational attribute > of a replication context. When a child area of replication > is created, the > "childReplicationContext" attribute of the parent replication > context is > updated, and that change replicated to other replicas of the parent. > Deleting a child replication context may require > administrative action, as > I don't see how any single server could know that it held the last > remaining copy of the child area of replication (unless this > happens on a > server that holds both the parent and child replication contexts). I > suppose creating a child area of replication might require > administrative > action too, unless we require that the child be created on a > server that > also holds the parent. And as I think this through more, I > suppose that > some sort of glue entry would do the trick here (possibly > with a reference > to some server containing that replication context). > > Either way, it implies that something holds knowledge of the entire > replication topology, and that a tool hide as much of the nastiness as > possible. > > Any thoughts? And I suppose I really ought to put this > discussion on the > LDUP mailing list. Do you agree? It wouldn't hurt. Regards, Steven ------=_NextPart_000_00D6_01C148EC.673EDFA0 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Disposition: attachment; filename="smime.p7s" Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIII9jCCApQw ggH9oAMCAQICAwSkbzANBgkqhkiG9w0BAQQFADCBkjELMAkGA1UEBhMCWkExFTATBgNVBAgTDFdl c3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3duMQ8wDQYDVQQKEwZUaGF3dGUxHTAbBgNVBAsT FENlcnRpZmljYXRlIFNlcnZpY2VzMSgwJgYDVQQDEx9QZXJzb25hbCBGcmVlbWFpbCBSU0EgMjAw MC44LjMwMB4XDTAxMDQxOTE5MjY0NFoXDTAyMDQxOTE5MjY0NFowTzEfMB0GA1UEAxMWVGhhd3Rl IEZyZWVtYWlsIE1lbWJlcjEsMCoGCSqGSIb3DQEJARYdam9obi5zdHJhc3NuZXJAaW50ZWxsaWRl bi5jb20wgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBAKOQF9xvr2IzkspSZ5NHATzu64yNJl1D NVVu08Upy0q/Dvfm0/dWVRc/sg09Tr1seHcVLIjAlY6QWFJsPf5tuglzSuMPy+6bGj/mI3KSXpte dhD5o33qc0oBnIOyn+PuqW7fpWjIJwM2MNCLr7gG1IjrchggMput4b5jq2M3zXxJAgMBAAGjOjA4 MCgGA1UdEQQhMB+BHWpvaG4uc3RyYXNzbmVyQGludGVsbGlkZW4uY29tMAwGA1UdEwEB/wQCMAAw DQYJKoZIhvcNAQEEBQADgYEAtHVVEjLYbfAxqW9D1GxSpZYh7kWX/em+JcgXrxFom6kU3wgCrluP F0Ce97vS4VX/TTs9x9b9YUONsEi8kqN5XLY3995FwnFgT+s2ZVljKNFoCgk4COQJ3OS2l/bZWFRc xgR4auC8sLZmE2oxtOm1cigZMhbT8ZnKvWuBN/8q2tUwggMpMIICkqADAgECAgEMMA0GCSqGSIb3 DQEBBAUAMIHRMQswCQYDVQQGEwJaQTEVMBMGA1UECBMMV2VzdGVybiBDYXBlMRIwEAYDVQQHEwlD YXBlIFRvd24xGjAYBgNVBAoTEVRoYXd0ZSBDb25zdWx0aW5nMSgwJgYDVQQLEx9DZXJ0aWZpY2F0 aW9uIFNlcnZpY2VzIERpdmlzaW9uMSQwIgYDVQQDExtUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwg Q0ExKzApBgkqhkiG9w0BCQEWHHBlcnNvbmFsLWZyZWVtYWlsQHRoYXd0ZS5jb20wHhcNMDAwODMw MDAwMDAwWhcNMDIwODI5MjM1OTU5WjCBkjELMAkGA1UEBhMCWkExFTATBgNVBAgTDFdlc3Rlcm4g Q2FwZTESMBAGA1UEBxMJQ2FwZSBUb3duMQ8wDQYDVQQKEwZUaGF3dGUxHTAbBgNVBAsTFENlcnRp ZmljYXRlIFNlcnZpY2VzMSgwJgYDVQQDEx9QZXJzb25hbCBGcmVlbWFpbCBSU0EgMjAwMC44LjMw MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDeMzKmY8cJJUU+0m54J2eBxdqIGYKXDuNEKYpj NSptcDz63K737nRvMLwzkH/5NHGgo22Y8cNPomXbDfpL8dbdYaX5hc1VmjUanZJ1qCeu2HL5ugL2 17CR3hzpq+AYA6h8Q0JQUYeDPPA5tJtUihOH/7ObnUlmAC0JieyUa+mhaQIDAQABo04wTDApBgNV HREEIjAgpB4wHDEaMBgGA1UEAxMRUHJpdmF0ZUxhYmVsMS0yOTcwEgYDVR0TAQH/BAgwBgEB/wIB ADALBgNVHQ8EBAMCAQYwDQYJKoZIhvcNAQEEBQADgYEAcxtvJmWL/xU0S1liiu1EvknH6A27j7kN aiYqYoQfuIdjdBxtt88aU5FL4c3mONntUPQ6bDSSrOaSnG7BIwHCCafvS65y3QZn9VBvLli4tgvB UFe17BzX7xe21Yibt6KIGu05Wzl9NPy2lhglTWr0ncXDkS+plrgFPFL83eliA0gwggMtMIIClqAD AgECAgEAMA0GCSqGSIb3DQEBBAUAMIHRMQswCQYDVQQGEwJaQTEVMBMGA1UECBMMV2VzdGVybiBD YXBlMRIwEAYDVQQHEwlDYXBlIFRvd24xGjAYBgNVBAoTEVRoYXd0ZSBDb25zdWx0aW5nMSgwJgYD VQQLEx9DZXJ0aWZpY2F0aW9uIFNlcnZpY2VzIERpdmlzaW9uMSQwIgYDVQQDExtUaGF3dGUgUGVy c29uYWwgRnJlZW1haWwgQ0ExKzApBgkqhkiG9w0BCQEWHHBlcnNvbmFsLWZyZWVtYWlsQHRoYXd0 ZS5jb20wHhcNOTYwMTAxMDAwMDAwWhcNMjAxMjMxMjM1OTU5WjCB0TELMAkGA1UEBhMCWkExFTAT BgNVBAgTDFdlc3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3duMRowGAYDVQQKExFUaGF3dGUg Q29uc3VsdGluZzEoMCYGA1UECxMfQ2VydGlmaWNhdGlvbiBTZXJ2aWNlcyBEaXZpc2lvbjEkMCIG A1UEAxMbVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIENBMSswKQYJKoZIhvcNAQkBFhxwZXJzb25h bC1mcmVlbWFpbEB0aGF3dGUuY29tMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDUadfUsJRk W3HpR9gMUbbqcpGwhF59LQ2PexLfhSV1KHQ6QixjJ5+Ve0vvfhmHHYbqo925zpZkGsIUbkSsfOaP 6E0PcR9AOKYAo4d49vmUhl6t6sBeduvZFKNdbnp8DKVLVX8GGSl/npom1Wq7OCQIapjHsdqjmJH9 edvlWsQcuQIDAQABoxMwETAPBgNVHRMBAf8EBTADAQH/MA0GCSqGSIb3DQEBBAUAA4GBAMfskn5O +PWWpWdiKqTwTRFg0G+NYFhhrCa7UjVcCM8w+6hKloofYkIjjBcP9LpknBesRynfnZhe0mxgcVyi rNx54+duAEcftQ0o6AKd5Jr9E/Sm2Xyx+NxfIyYJkYBz0BQb3kOpgyXy5pwvFcr+pquKB3WLDN1R hGvk+NHOd6KBMYICqjCCAqYCAQEwgZowgZIxCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJu IENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEPMA0GA1UEChMGVGhhd3RlMR0wGwYDVQQLExRDZXJ0 aWZpY2F0ZSBTZXJ2aWNlczEoMCYGA1UEAxMfUGVyc29uYWwgRnJlZW1haWwgUlNBIDIwMDAuOC4z MAIDBKRvMAkGBSsOAwIaBQCgggFlMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcN AQkFMQ8XDTAxMDkyOTIwNDExMlowIwYJKoZIhvcNAQkEMRYEFHhilkYfV27YkSLJk8b0FFo7YSkg MFgGCSqGSIb3DQEJDzFLMEkwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwICAgCAMAcGBSsOAwIHMA0G CCqGSIb3DQMCAgEoMAcGBSsOAwIaMAoGCCqGSIb3DQIFMIGrBgkrBgEEAYI3EAQxgZ0wgZowgZIx CzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEP MA0GA1UEChMGVGhhd3RlMR0wGwYDVQQLExRDZXJ0aWZpY2F0ZSBTZXJ2aWNlczEoMCYGA1UEAxMf UGVyc29uYWwgRnJlZW1haWwgUlNBIDIwMDAuOC4zMAIDBKRvMA0GCSqGSIb3DQEBAQUABIGAoGCy g3Xutd560fp+CgO2BHHjyPjLrG/p7T/mAeKoOV81cXw3BVGrd22dGx7B3XSmAqipYDm2rTK8wTlW fWiAgOQSpJQF3oBSJMpZS2VSc5ibpjl+kM/pbogSPdNZDZFbXUKNFnKep9LmkvnMnARy71PmHnD6 Ma/k9qS66IrLh3oAAAAAAAA= ------=_NextPart_000_00D6_01C148EC.673EDFA0--