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

RE: Some comments on model-04

Uppili,

Fine. When you do review it, if you decide to permit (vertically) adjacent
non-overlapping areas, please use a different term than "Naming Context" as
this has a precisely standardized meaning defined in X.500. I would suggest
"replication area" as already used in the protocol draft.

Also, I suggest using the word "adjacent" (or non-adjacent), as in the ACL
draft, and giving a precise definition of that word. "Contiguous" is
commonly used, but I find it slightly confusing (eg see my even more
confusing use of "convex" below ;-)

PS I should now be able to complete the responses to Steve in the next
couple of days, as I've just managed to not let a daughter depart for Japan
with a non-functional laptop, thus avoiding the classic "cobbler's family
with no shoes" syndrome, and can therefore do some LDUP work :-)

Hope it's not too late for people already on their way to IETF meeting.

-----Original Message-----
From: owner-ietf-ldup@mail.imc.org
[mailto:owner-ietf-ldup@mail.imc.org]On Behalf Of Uppili Srinivasan
Sent: Monday, July 24, 2000 7:59 AM
To: Albert.Langer@directory-designs.org
Cc: d.w.chadwick@salford.ac.uk; ietf-ldup@imc.org;
ietf-ldapext@netscape.com
Subject: 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
>
> ***************************************************