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

From: "Timothy Hahn" <[email-masked]>
Date: Thu, 11 Jan 2001 10:05:16 -0500

Greetings,

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