Subject: Comments on draft-ietf-ldup-model-05.txt

From: "Timothy Hahn" <[email-masked]>
Date: Tue, 16 Jan 2001 23:05:51 -0500

Greetings,

(My apologies for the re-post if you see this twice - I did not see it 
come through the mailing list).

General: From a replication management/configuration and server 
perspective, it seems we ought to define a standard way for setting and/or 
looking up a server's replica ID.  A server needs to know its own ID to 
generate CSNs, and to configure replication you need to be able to 
determine the IDs of the other participating servers.  This might be 
better addresed in the information model.
Proposal:  Add a root DSE attribute, replicaID, that "advertises" the 
server's ID.  How this value is set could be implementation defined, but 
if I were developiong a replication management tool, I would like to be 
able to set this attribute via LDAP operations from the management tool. I 
suggest that this attribute must be modifiable via a modify operation on 
the root DSE.  Alternately, I could see that it might be desirable to make 
this an attribute of the replication area "name context" object -- though 
I don't know of any need for a "per replication area" replicaID.

General - I feel that this document should have a section that shows which 
requirements (from the replication requirements draft) are addressed and 
which are not - instead of leaving this as an "exercize for the reader".

3.3.e - Please clarify what is meant by "overlapping replicated regions".

4.1 - I think that replica Type should have a setting for listing the 
replica as "partial".

4.4 - What is the format/algorithm for generating entry UUIDs?   What is 
the canonical string representation for an entry's UUID?  Where is the 
full attribute type definition and OID for "entryUUID" defined?  Will 
there be a new syntax?

4.5 - If a Modify operation MUST assign one CSN per modification, is there 
an order here?  I assume that CSNs are assigned IN ORDER of the 
modification list, one CSN per modification item in the list.  Is this the 
intent?

4.5.1 - What is the recommended format and choice for the replica ID, as 
used in the CSN and elsewhere? Common use of the term replica ID and 
replica Identifier would be nice.  Some refer to this as the "rdn 
attribute", others, including examples, use integers.  If this is an 
integer, shouldn't the integer value be in the replicaSubentry as a 
separate attribute?

4.6 - Do all attribute values have CSN's or only those that have been 
modified or deleted?

4.6.1 - Need more explanation on the last sentence of this section: "A CSN 
is recorded for both the RDN, and the Superior DN of the entry."  Does 
LDUP require storing the Superior DN and/or Superior UUID with every 
entry?  Is the "superior entry" marked as updated?  Or do there exist 
separate CSNs in EACH ENTRY corresponding to rdnCSN and superiorDNCSN, in 
addition to createdEntryCSN and deletedEntryCSN?

5.1 - It seems like the schema is always associated with the naming 
context, and that naming contexts can be nested.  Is this right?  Is there 
any meaning for the subschema entry pointed to by the rootDSE?  How are 
subschema entries related to replication contexts - if at all?

5.1 -  The CSN format seems to imply that the naming attribute for 
replicaSubentry entries MUST be caseIgnoreIA5.  This should be stipulated.

5.2 -  What are the rootDSE attributes needed for LDUP replication?  I 
don't see them in the information model.  In section 7.3, I saw a 
reference to to a 'supportedReplicationProtocols' attribute - there may be 
others.

5.4 - It should it be noted that Fractional replicas can ONLY be 
read-only.

5.5 -  What is the DN of the Lost and Found entry?

5.6 -  How should the authentication credentials be stored securely?

6.1 -  Need clarification relative to the meaning of the subschemasubentry 
attribute in the rootDSE.  Does paragraph two then imply a requirement 
that schema be updateable (as well as published)?  Should this be a 
setting (whether or not to replicate schema updates) in the replica 
agreement?  Recommend we allow choice in replication agreement of whether 
schema should be replicated.

6.1 - "Given the strict ordering of replication events, schema 
modifications will naturally be replicated ...".  I don't recall such an 
ordering requirement.  It may be implicit in a log-based implementation, 
but not in a state-based implementation.  It does seem, though, that some 
ordering of schema changes and entry changes is required.  This could be a 
problem in implementations (many) where the schema is server-wide.
Proposal(s):
1)  Replace this statement with a MUST(?) requirement to the effect: "To 
ensure that schema modifications precede entry creations/modifications 
that use them and follow data deletions which eliminate references to 
schema elements to be changed or deleted, replication MUST preserve the 
ordering of schema changes with respect to other directory entry changes."
2) Alternately, it seems that a requirement could be imposed for the 
servers to recheck "damaged" entries as schema changes come in, the goal 
in either case being that at the end of successful replication of entry 
changes and associated schema changes, no entries be in an "administrative 
action required" state.
I do not have a feel for which is better, but I do feel that as currently 
stated, the "strict ordering" referred to does not exist, making it 
possible that an administrator might have to do some sort of repair for 
entries that either aren't really broken, and needn't have become broken. 
What other LDUP drafts will clarify this?

7.1.1 -  says that the credentials for authenticated bind to another 
replica are kept as attributes within replication agreements.  The 
information model shows no such attributes.

7.3 - required changes to the rootDSE should be summarized somewhere - 
information model draft perhaps?

9.1 - Full Update Transfer: This seems impractical for large naming 
contexts, because it would take too long.  Are there any alternatives that 
should be considered?

9.4 - This paragraph seems to imply that replicaSubentry objects are also 
replicated between replica servers.  However, in absence of this 
information (becuase the "new" replica isn't "well known" yet - unknown 
updateVector information, for example), how does the supplier know that it 
should be keeping track of updates? Maybe this only applies to log-based 
replication?
9.4 - The paragraph, as written, seems to imply that if a full update is 
to be performed, then prior to starting, a 'snapshot' of the whole 
replication context must be taken so that incremental changes that come in 
can thence be sent to the replica.  If so, this should be 
clarified/pointed out.

10 - What is the recommended error code?  LDAP_UNWILLING_TO_PERFORM? 
Serializing all replication operations would seem to require some 
explanation as to why.

10.5.4 - What is the mechanism for marking an entry as requiring 
"administrative repair"?  Is this information intended to be LDAP 
accessible?
Proposal:  I would like to see this (needs administrative repair) 
accessible via LDAP, with some information as to the nature of the error. 
To this end, we could add an operational attribute(?), 
replicationSchemaError, which is present if replication introduces a 
schema violation.  A subsequent LDAP (or replication) operation which 
corrects this error will result in the replicationSchemaError attribute no 
longer being returned on a search.  If a schema change is required to 
correct the error, the mechanism for correcting the error would be to 
update the schema, then perform an LDAP modify operation to delete the 
replicationSchemaError attribute.  If the object no longer violates the 
schema, the operation will succeed.  The syntax of this attribute would be 
directory string.  Implementations should set the attribute to a string 
describing the error (for example, "attribute xxx not allowed"). 
Implementations may return the attribute as an empty string.

10.5.7 - "The resolution procedure is to break the cycle by changing the 
parent of the entry closest to be the lost and found entry."  Closest to 
what?  To the root?  Why not say "the resolution procedure is to move the 
entry (and possibly whole sub-tree) into the lost+found area"?

12 -  How much of replication management entries are replicated?
12 - Step one of the example scenario; what is a "context prefix"?
12 - Why is step 5 necessary?  Why isn't this information just replicated 
over on the next replication between the two replicas?

13 - hat is the diference between serverClocksOutOfSync (72) and 
excessiveCSNskew (200), defined in the LDUP Replication Update Protocol? 
ExcessiveCSNskew is not referenced outside of the protocol draft.

14 - There appears to be a "special case" in replication processing in 
that the "authentication information" that is presumably stored in 
replication agreement subentries should NOT be replicated.  Thus, servers 
must code special work-arounds to avoid replicating this information.  Is 
this the intent?

Regards,
Tim Hahn

Internet: [email-masked]
Internal: Timothy Hahn/Endicott/IBM@IBMUS or IBMUSM00(HAHNT)
phone: 607.752.6388     tie-line: 8/852.6388
fax: 607.752.3681