Re: WG Last Call on URP I-D
"John McMeeking" <[email protected]>
| Newsgroups | gmane.ietf.ldup |
|---|---|
| Message-ID | <[email protected]> |
Hi all,
We have reviewed the LDUP Update Resolution Procedures Internet Draft
(draft-ietf-ldup-urp-04.txt) and have the following comments.
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.
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. 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.
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. 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?
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."
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?
Perhaps make C.uid distinguished should be make E.uid distinguished?
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.
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.
The above comment also applies to 5.3.7 and 5.3.8.
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?
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.
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
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?
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. 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.
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
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
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. An administrator
making a correction based on the outcome at replica 1 might chose to move B
(and C with it) back under A. At replica 2, this would result in C being
left in Lost and Found.
That illustrates the problem.
Possible solution:
When a DIT loop is detected, resolve the conflict by individually moving
each entry in the loop into Lost and Found. In my simple example above,
since the loop involves only the entries ou=B and ou=C, each of these
entries would be moved to Lost and Found:
o=A L & F
| |
---------------
| |
glue entry glue entry
| |
ou=C ou=B
Section 5.3.11 could be rewritten as:
<< start of change >>
5.3.11 Processing Move Entry Primitive
This section details the algorithm for processing the p-move-entry
(P.uid, P.superior, P.csn) primitive, which describes the moving of
an entry to a new immediate superior in the DIT. If the new superior
| specified by the primitive does not exist, then the entry is moved to
| Lost & Found. If the new superior is a direct or indirect subordinate
| of the entry being moved, then each entry in the path from the entry
| being moved and its new superior is moved to Lost & Found
| instead.
IF no entry deletion record (uid, csn) exists
where (uid = P.uid AND csn > P.csn)
{
IF entry, E, with uid = P.uid does not exist
E := CreateGlueEntry(P.uid)
IF P.csn > E.superior.csn
{
R := E.rdn
O := E.superior
IF entry, S, with uid = P.superior does not exist
S := CreateGlueEntry(P.superior)
| S.superior := LOST_AND_FOUND
IF S is not in the subtree of E
{
E.superior := P.superior
E.superior.csn = P.csn
| CheckUniqueness(E, O, R)
}
ELSE
{
FOR each entry, M, in the path from
| S to E (including entries S and E)
| {
| G := CreateGlueEntry(M.superior)
| G.superior := LOST_AND_FOUND
| M.superior := G
| M.superior.csn := GenerateNextCSN(P.csn)
| }
}
}
}
<< end of change >>
Note that this also moves the CheckUniqueness procedure into the
"successful move" leg. If CheckUniquenes should also be applied to the
entries moved into Lost and Found, then the CheckUniqueness procedure
should also be applied to each entry, M, moved into Lost and Found.
John McMeeking
OS/400 Directory Services
[email protected]
(507)253-4596
Christopher Apple
<christopher.apple@UnitedMess To: "'[email protected]'" <[email protected]>
aging.net> cc:
Sent by: Subject: WG Last Call on URP I-D
[email protected]
08/13/2001 05:30 PM
The purpose of this message is to initiate the LDUP
Working Group last call on the LDUP Update
Reconciliation Procedures I-D document.
WHAT DOCUMENT?
The document in last call is:
http://www.ietf.org/internet-drafts/draft-ietf-ldup-urp-04.txt
WHAT IS A LAST CALL FOR?
The purpose of the working group last call is to ensure
that the working group has reached consensus on the
document, believes that all the known outstanding issues
have been addressed, and is ready to put the document
forward for proposed standard status.
During the last call, any comments on the documents are
collected and discussed on the mailing list.
HOW LONG DOES IT LAST?
The last call starts today and will last approximately three
weeks. It will end on Tuesday, September 4, 2001 at 1830 US ET.
WHAT'S THE NEXT STEP?
After the last call completes, there are three possible
outcomes:
1) No changes are required and we request our ADs to put
forward the documents to the IESG for proposed standard
status.
2) Minor changes agreed to on the list are required, and
the documents are revised. We then ask our ADs to put
forward the revised documents to the IESG for
proposed standard status.
3) Major issues are raised and no consensus is reached on
the list. In this case, we discuss things until consensus
is reached, at which time another working group last call
will be issued.
Assuming we achieve outcome 1) or 2), and that the ADs
agree with our assessment, the next stop for the documents
is with the IESG. The IESG reads them and may approve the
documents (with or without changes), or send the documents
back to the working group to have major issues addressed.
If the first outcome happens, the documents are put forward
for a two-week last call to the entire IETF, and after
successful completion the documents are published as RFCs
with proposed standard status.
If the second outcome happens, we go back and address
the issues, putting the documents forward again when we
believe they're ready.
WHAT SHOULD YOU DO?
You should read the documents, making sure that 1) there
are no problems or deficiencies or outstanding issues that
need to be resolved; and 2) that there are no typos,
formatting problems, grammatical errors, etc.
Any substantive problems you find, you should send to the
list. Any minor problems (typos, etc.) you may send to the
list or just to the authors. If, for some reason, you have
comments you don't want to send to the entire list, you may
send them to me and/or LDUP WG co-chair John Strassner.
Silence means consent.
Read, enjoy, and send your comments in!
regards,
Chris Apple and John Strassner
Chris Apple
Program Manager - Directory Services
United Messaging Inc.
<http://www.unitedmessaging.com>
<mailto:[email protected]>
(V) 610-425-2860
#### Chris Apple (E-mail).vcf has been removed from this note on August 16
2001 by John McMeeking
#### smime.p7s has been removed from this note on August 16 2001 by John
McMeeking
smime.p7s
(application/octet-stream, 2.2 KB) - not displayed