Re: Replication Management - Some questions on the Information Model
"Ed Reed" <[email protected]>
| Newsgroups | gmane.ietf.ldup |
|---|---|
| Message-ID | <[email protected]> |
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 protected]> 02/27/02 09:19PM >>> 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> <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> 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> 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> <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> 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> Rick Huber John McMeeking Ryan Moats