Re: Replication Management - Some questions on the Information Model

Rick,

So, this is probably too long in coming up with a reply, but I'll take a
stab at it anyway.  See <TJH> ... </TJH> below.

Regards,
Tim Hahn

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



                                                                                                                                       
                      [email protected]                                                                                                
                      om (Richard V            To:       [email protected]                                                             
                      Huber)                   cc:       [email protected], Timothy Hahn/Endicott/IBM@IBMUS, John                      
                      Sent by:                  McMeeking/Rochester/IBM@IBMUS, [email protected], [email protected]           
                      owner-ietf-ldup@m        Subject:  Replication Management - Some questions on the Information Model              
                      ail.imc.org                                                                                                      
                                                                                                                                       
                                                                                                                                       
                      01/23/2002 11:52                                                                                                 
                      PM                                                                                                               
                                                                                                                                       
                                                                                                                                       




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?
<TJH>
I believe we left it as optional so that for servers that implement
"referential integrity" of distinguished name attributes, that values
for this attribute could be deleted (indeed, the whole attribute
can be deleted without violating the schema for the entry.
</TJH>

 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?
<TJH>
I will assert that the answer to the last question is yes.  Now, in
looking at the draft, I tend to agree now that attributeExclusionFilter,
attributeInclusionFilter, replicaType, secondsToWaitDefault,
secondsToWait1, and
secondsToWait2 need not be NO-USER-MODIFICATION.  UpdateVector, however,
I feel should remain NO-USER-MODIFICATION as direct modification of this
information seems disasterous.  I would rather see some sort of extended
operation
or control be defined for doing surgery on the update vector.
</TJH>

 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?
<TJH>
The intent of the status value was to give some place for administration
tools to look for status relative to the replicationAgreement between
the supplier and consumer.  The values were meant to represent the last
known status as seen by the supplier the last time a replication session
was performed to the consumer.  As such, I think it still belongs in the
replicationAgreementSubentry.

It is a valid question as to where to check for status - in general.  I
suspect that the administration application(s) will have to connect to
multiple (if not all) servers in the replication topology to determine each
one's replication "status" so that the real "status" of replication can be
discerned through correlation of each server's information.  This is not an
answer, just pointing out that where to report status is a "thorny" issue.

Perhaps the replicaSubentry could hold a "replicaStatus" as well?
</TJH>

 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?
<TJH>
No, I don't think so :-).

I don't have a good answer for this one yet - I'll have to discuss it
with the other authors (Ed any ideas here?)
</TJH>

Rick Huber
John McMeeking
Ryan Moats