Re: Replication Management - Some questions on the Information Model

Ed (and others),

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


John  McMeeking


 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>

<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>

 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>

<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>

<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>