RE: WG Last Call on URP I-D
"John McMeeking" <[email protected]>
| Newsgroups | gmane.ietf.ldup |
|---|---|
| Message-ID | <[email protected]> |
See
<JAM>
responses
</JAM>
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"
<steven.legg@adac To: John McMeeking/Rochester/IBM@IBMUS
el.com.au> cc: <[email protected]>
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.
<JAM>
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?
</JAM>
> 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.
<JAM>
I think it would be clearer to add a sentence like: "The replace
alternative with no attribute values generates only an attribute deletion
record."
</JAM>
>
>
> 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" ...
<JAM>
Looks good.
</JAM>
> 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."
<JAM>
Looks good.
</JAM>
>
> 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)."
<JAM>
Looks good
</JAM>
>
>
> 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."
<JAM>
Looks good.
</JAM>
>
>
> 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.
<JAM>
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).
</JAM>
>
> 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.
<JAM>
Got it.
</JAM>
>
> 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.
<JAM>
Got it.
</JAM>
>
>
> 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".
<JAM>
Got it.
</JAM>
>
>
> 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.
<JAM>
Got it.
</JAM>
>
>
> 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.
<JAM>
Okay.
</JAM>
Regards,
Steven