Subject: Replication Management - Some questions on the Information Model

From: [email-masked] (Richard V Huber)
Date: Wed, 23 Jan 2002 23:52:49 -0500

A few questions on InfoMod (draft -04).

 1. In Section 8.3.3 (definition of the replicaAgreementSubentry
    objectclass), why is replicaDN a MAY rather than a MUST?  The
    replication agreement is useless without a replicaDN, and the text
    states that the replicaAgreementSubentry is ignored if the
    replicaDN is missing, so why not just require that it be there?

 2. There are a number of attributes listed as NO-USER-MODIFICATION.
    They are (with section number where they are defined):

      attributeExclusionFilter (Section 8.2.4)
      attributeInclusionFilter (Section 8.2.5)
      replicationStatus (Section 8.2.7)
      replicaType (Section 8.2.8)
      updateVector (Section 8.2.9)
      secondsToWaitDefault (Section 8.2.18)
      secondsToWait1 (Section 8.2.19)
      secondsToWait2 (Section 8.2.21)

    Do all of these attributes really need to be unmodifiable?  For
    adminstrative purposes, we can see some cases where replicaType or
    updateVector need to be changed (though only by administrators).
    And it's not clear to us why the filter and secondsToWait
    attributes need to be unmodifiable in any case.

    Would availability of access controls make some of these questions
    moot?  Are some of these attributes marked NO-USER-MODIFICATION
    because they should only be changed by administrators?

 3. The replicationStatus attribute is in the
    replicaAgreementSubentry.  The attribute is optional and the
    replicationAgreementSubentry itself is optional.  This means that
    there is no standard place where replication status can be found.

    Shouldn't there be some known place to check for status?  Should we
    move replicationStatus to the replicaSubentry and make it a MUST
    instead of a MAY?  Or do we need to define some other place where
    status can always be checked?

 4. The replicationAgreementSubentry is optional.  But the
    replicationCredentialsDN is in the replicationAgreementSubentry.
    This means that in the simple case described in Section 9,
    replication is unauthenticated.  Is that really what we want?

Rick Huber
John McMeeking
Ryan Moats