Subject: Some comments on model-04

From: "David Chadwick" <[email-masked]>
Date: Fri, 21 Jul 2000 17:46:09 +0100

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 [email-masked]
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

***************************************************

---

From: "Albert Langer" <[email-masked]>
Date: Sun, 23 Jul 2000 03:19:14 +1000

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: [email-masked]
[mailto:[email-masked]]On Behalf Of David Chadwick
Sent: Saturday, July 22, 2000 2:46 AM
To: [email-masked]
Subject: Some comments on model-04

John & Co

David

David Chadwick

---

From: Uppili Srinivasan <[email-masked]>
Date: Sun, 23 Jul 2000 14:59:03 -0700

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.

---

From: "Albert Langer" <[email-masked]>
Date: Thu, 27 Jul 2000 01:22:15 +1000

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: [email-masked]
[mailto:[email-masked]]On Behalf Of Uppili Srinivasan
Sent: Monday, July 24, 2000 7:59 AM
To: [email-masked]
Cc: [email-masked]; [email-masked];
[email-masked]
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.