[Date Prev][Date Next] [Chronological] [Thread] [Top]

Re: Some comments on model-04

Albert:

The "Naming context" definition in the context of replication was meant to avoid
two replicas in the same DSA with over lapping or contiguous areas.  It does
allow multiple agreements associated with the same replica.

You are right about some changes that were discussed around the definition of
NC.  The idea was to alter it as necessary so that the definition is consistent
across replication, the ACL model (Ellen) and also for any future sub schema
work (Mark Wahl).  Let me try to make the necessary modification after some
discussion at Pittsburgh with these authors.

I would like to re-examine the ambiguities you have highlighted (regarding what
is intentionally or unintentionally implied as requirements for read-only
replicas) with a modified definition of NC.

Thanks,
Uppili.

Albert Langer wrote:

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