[Date Prev][Date Next]
[Chronological]
[Thread]
[Top]
RE: Some comments on model-04
Re point i), there may perhaps also be an unintentional limitation in the
possibilities for replication agreements by defining a "Replica" as "an
instance of a replicated Naming Context" (3.5, p9). Although "sparse"
replicas are currently out of scope by 3.3g this refers to the complexity of
implementing entry selection filters. It may not have been intended to rule
out vertically adjacent replicated areas held by the same DSA in connection
with different replication agreements that are themselves contiguous or
convex subtrees and not "sparse". The term "Naming Context" does exclude
that, as explained in 4.4 of David's book "Understanding X.500", at the URL
below.
I believe this point may have been raised earlier (by Dieter?), with some
mention of the architecture authors following up to correct it in the
archives. But it doesn't seem to have been corrected.
The only benefit of this limitation that I can see is to ensure that
modifyDN operations within an NC can always be performed at any updateable
replica. That strikes me as unnecessary since a referral could just be given
to a "full" replica that holds replication agreements for the entire NC when
a modifyDN is outside the replication areas held by a DSA. A category of
"full" replicas, each of which is updatable for every replicated area within
the NC could be defined. The "primary" for any replicated area within an NC
would then also be the primary for all other replicated areas within the NC
and would be one of the "full" replicas. Alternatively it would not be all
that difficult to add a slightly more complex calculation of who to send a
referral to, when not all updateable replicas that can process modifyDN are
"full".
Even if this restriction was intentional, I can see no justification for
applying it to Read-Only replicas. Why shouldn't they hold vertically
adjacent replicated areas as well as disjoint ones?
eg Why shouldn't a branch office DSA serving a particular OU for an
organization hold read only copies of the top of an organization's tree as
well as read only copies for some, but not all, of the other OUs at the same
level, any of which might be vertically adjacent to the top area? Why
shouldn't another DSA at a different office interested in read only copies
of a different set of OUs also be able to do that? The present definition
requires that either the top be excluded so that disjoint NCs can be
defined, or that a single NC cover them all and every read only replica hold
the entire set.
I suspect it may have been unintentional, as there is clearly some confusion
around about the concept of an NC. The definition on p9 refers to X.501 but
does not make it clear that any other NCs encountered down the tree from the
context prefix held by a DSA must be context prefixes held in a different
DSA. In draft-ietf-ldapext-acl-model-06.txt, there is even a reference to
"adjacent naming contexts supported by that directory server" at 3.3, p6
despite the definition that NCs are disjoint, never adjacent within a DSA.
I am CCing this to ldapext for that last point, despite still not being
subscribed.
It isn't just a matter of terminology, but may relate to confusion about the
role of subschema and access control administration points and their
relations to distribution and replication.
In general, attempting to define replication and access controls without
having first clarified distribution models and administrative models doesn't
seem to have been a good idea.
Seeya, Albert
-----Original Message-----
From: owner-ietf-ldup@mail.imc.org
[mailto:owner-ietf-ldup@mail.imc.org]On Behalf Of David Chadwick
Sent: Saturday, July 22, 2000 2:46 AM
To: ietf-ldup@imc.org
Subject: Some comments on model-04
John & Co
I have a few comments to make on the Model doc, most of them
minor
i) you mention the term context prefix to refer to the root of a
naming context, but mostly use the term root. I would prefer that
you use context prefix consistently since a) this accords with X.518
and b) it can keep the term root reserved for the root of the DIT
ii) last sentence of 4.6.1. I would like some clarification of what this
actually means (A CSN is recorded.......).
iii) I believe there is a conflict between 8.2 and 10.3 concerning
fractional replication. Either the fraction is sent only the attributes it
contains (8.2) or the whole modification operation is sent (10.3) but
not both.
iv) section 12, steps 5 and 6 for DSA2. I believe there is a bug
here. In step 5 please state explicitly what the parent entry of the
rep agreement NC1R1-R2 is. I believe it should be NC1R1. In step
6 state explicitly what the parent of rep agreement NC1R2-R1. I
believe it should be NC1R2. Hence the rep agreements are not
siblings, as they dont have the same parent. (otherwise I have
misunderstood the model and perhaps some more text somewhere
to clarify this)
v) It is interesting that step 5 above said take a copy of the rep
agreement, whereas in section 14 it states that autentication
information should never be replicated between replicas. Perhaps
this statements are slightly at odds with each other. Also , if
password authentication is being employed, then the password will
need to be replicated between the DSAs, thus section 14 is wrong.
David
***************************************************
David Chadwick
IS Institute, University of Salford, Salford M5 4WT
Tel +44 161 295 5351 Fax +44 161 745 8169
Mobile +44 790 167 0359
Email D.W.Chadwick@salford.ac.uk
Home Page http://www.salford.ac.uk/its024/chadwick.htm
Understanding X.500 http://www.salford.ac.uk/its024/X500.htm
X.500/LDAP Seminars http://www.salford.ac.uk/its024/seminars.htm
Entrust key validation string MLJ9-DU5T-HV8J
***************************************************