Subject: Re: Replication Management - Some questions on the Information Model

From: "Timothy Hahn" <[email-masked]>
Date: Wed, 27 Feb 2002 21:19:26 -0500

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-masked]
Internal: Timothy Hahn/Endicott/IBM@IBMUS or IBMUSM00(HAHNT)
phone: 607.752.6388     tie-line: 8/852.6388
fax: 607.752.3681

                      [email-masked]                                                                                                
                      om (Richard V            To:       [email-masked]                                                             
                      Huber)                   cc:       [email-masked], Timothy Hahn/Endicott/IBM@IBMUS, John                      
                      Sent by:                  McMeeking/Rochester/IBM@IBMUS, [email-masked], [email-masked]           
                      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

---

From: "Ed Reed" <[email-masked]>
Date: Thu, 28 Feb 2002 06:53:44 -0700

I'll throw my original intent into <eer>  comments </eer>, too

=================
Ed Reed
Reed-Matthews, Inc.
+1 585 624 2402
http://www.Reed-Matthews.COM
Note:  Area code is 585

>>> "Timothy Hahn" <[email-masked]> 02/27/02 09:19PM >>>

Rick,

Regards,
Tim Hahn

                                                                                                                                       
                      [email-masked]                                                                                                

                      01/23/2002 11:52                                                                                                 
                      PM                                                                                                               

<eer>
Original intent - specifically to deal with the case when the replica
pointed to by a replication agreement is deleted.  If the DSA enforces
referential integrity of DN pointers by deleting the DN pointer when
the thing it points to is deleted, then the absence of the pointer
makes the agreement "incomplete", but the agreement doesn't go
away (there's no "foreign key" relationship in LDAP to force the
deletion of the entry that refers to the deleted entry.

This was my way of handling that.  There may be others, but this
is the approach I took.
</eer>

<eer>
The intent was that ONLY administrative tools should be modifying the configuration
attributes, not USER tools.  I envisioned a control being used by the administrative
tools to indicate that priviledged operations (over ride NO-USER-MODIFICATION flags,
for instance, or creation of entries with given creation UUIDs, for instance).  But
mainly I wanted plain users not to be able to modify these attributes that are
crucial to the correct operation of the distributed directory.
</eer>

<eer>
I could argue that the usual "known place to check for status" is the
logs of the servers involved.  The purpose of this was, as Tim says,
to make it easier in the distributed environment, for a remote operator
to quickly check the "health" of the replication system, and to detect
failures that need further investigation.  There was no intent to provide
full diagnostic support here - only the report of success or failure (and
reason code if a failure) of the last attempt at replication.
</eer>

<eer>
The notion I had (hey, it doesn't have to have been a GOOD notion!)
was that the absence of a replication agreement would indicate that
all defaults were to be taken between this replica and other replicas...
probably something like "send changes after a short countdown counter
expires to all other replicas using the public key certificate identity
associated with the originating DSA to establish a mutual authentication
TLS session to the DSA holding each of the other replicas defined, one
at a time".  In other words, use a default authentication mechanism that
doesn't require configuration information from the replication agreement
(the certificate on the entry in the directory representing the DSA
holding the replica), on some default schedule.

I explicitly did NOT expect that ANY replication session EVER would
be conducted anonymously, and I DO NOT think that anonymous
replication sessions SHOULD be allowed, at all, in contravention of
my reading of requirement S3 - "The protocol MUST also support the 
initialization of anonymous replication sessions."  Which I needed to
ask you (Rick) about, anyway!  Do I misunderstand the intent of that
requirement, or am I correct that I simply opose it alltogether?
</eer>

Rick Huber
John McMeeking
Ryan Moats

---

From: "Timothy Hahn" <[email-masked]>
Date: Thu, 28 Feb 2002 07:03:53 -0500

Ed,

I agree with the comments you made here.

Regards,
Tim Hahn

                                                                                                                                       
                      "Ed Reed"                                                                                                        
                      <[email-masked]        To:       <[email-masked]>, <[email-masked]>                                      
                      M>                       cc:       <[email-masked]>, <[email-masked]>, John                       
                      Sent by:                  McMeeking/Rochester/IBM@IBMUS                                                          
                      owner-ietf-ldup@m        Subject:  Re: Replication Management - Some questions on the Information    Model       
                      ail.imc.org                                                                                                      

                      02/28/2002 08:53                                                                                                 
                      AM                                                                                                               
                      Please respond to                                                                                                
                      Timothy Hahn                                                                                                     

=================
Ed Reed
Reed-Matthews, Inc.
+1 585 624 2402

Rick,

Regards,
Tim Hahn

---

From: "John McMeeking" <[email-masked]>
Date: Thu, 28 Feb 2002 08:07:00 -0600

Ed (and others),

Here's my thoughts on two responses <jam></jam>.  I'm okay with the others.

John  McMeeking

<eer>
The intent was that ONLY administrative tools should be modifying the
configuration
attributes, not USER tools.  I envisioned a control being used by the
administrative
tools to indicate that priviledged operations (over ride NO-USER-
MODIFICATION flags,
for instance, or creation of entries with given creation UUIDs, for
instance).  But
mainly I wanted plain users not to be able to modify these attributes that
are
crucial to the correct operation of the distributed directory.
</eer>

<jam>
Perhaps this would be better accomplished via access control, then, with a
note in the security section to the affect that:

"Because the replication configuration information stored in the directory
is crucial to the correct operation of the distributed directory,
appropriate access control mechanisms SHOULD be applied."

It is reasonable that user modification of the updateVector require a
special mechanism, and thus be marked as NO-USER-MODIFICATION.
</jam>

<eer>

<jam>
I suggest that text be added to clarify that in the absense of replication
agreements, the authentication mechanism used is determined by the
implementation.  Implementations MUST provide a means for specifying the
authentication mechanism and credentials that will be used.

My reading is that the replicationCredentialsDN is used only by the
supplier server; the consumer uses an implementation defined mechanism to
define credentials that it accepts for replication (though I don't recall
reading that anywhere).  The presence or absence of credentials in an
[implied] agreement isn't critical, as long as we define what happens in
their absence.

As to use of anonymous replication, if someone really wants to do that, let
them.  I wouldn't make it the default set up on the consumer end, though.
</jam>