RE: WG Last Call on URP I-D
"Steven Legg" <[email protected]>
| Newsgroups | gmane.ietf.ldup |
|---|---|
| Message-ID | <[email protected]> |
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