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

Re: Typos, bugs, clarifications for ACI draft (i, iii, v, vi)

David,

At 10:59 PM 7/17/00 +0100, David Chadwick wrote: 
Ellen

could you clarify a few points for me please

i) section 2 says the draft is neutral with respect to implicit vs
explicit denials, then says in 4.3 deny is the default when there is no
access control information. These statements seem to be in conflict.


(EJS) The neutrality statement in section 2 refers to whether you
deny by granting no rights (implicit) or you provide a deny verb in
the ACI to explicitly deny rights.  We've chosen to allow either.
Also, if I remember from email many months ago, there was
discussion of what the ACI is when no ACI is explicitly defined
at the root of the DIT held by a server - and the rough consensus
was 'default is deny'.


ii) 4.3 precedence of subjects has public in the bottom 2 levels and
this in the middle two levels. Can you explain this to me please.


(EJS) will respond in separate email


iii) delete this entry permission. What happens if the entry has
subordinates. Are permissions needed for the subordinates or not.
The text is mute on this point, although it does mention that no
permissions are needed on attributes in the entry.


(EJS)  The intent here was to provide the same semantic as X.500.
However, I think we may have missed the point you mention about
subordinates.  It seems to me that if you the entry you're deleting
is a leaf entry, then no problem.  If there are subordinates, then
you can't just delete an entry in the middle of the DIT, but also
need permisison to delete each subordinate.  What does X.500 do?


iv) add is permission for below an entry, but import appears not to
be ("permissions at the source location", not "below the source
location"). I dont think it is helpful to have different rules here (or
different text). Can we be consistent please as adding or importing
seem to be very similar in where the new entries are placed.


(EJS) will respond in separate email


v) bottom of 4.2.2, example of subtree#grant. If the grant list is
empty, why does this mean deny all?? See also comment i) above.


(EJS)  No rights are granted and no rights means deny (see i) response)


vi) section 4.2.4, Can you add text after role and ipAddress to say
what these mean (all the other subjects have some).

(EJS) Oops. Here's the proposed text:
ipAddress - defined as IP Address in dotted decimal form or domain
name; wildcards allowed (see BNF)
role - <One could define using the existing group object class definitions;
(from teminology section, draft 05) asserts a subject's organization
position and entitlement to perform the operations appropriate to that
organizational position; where group is just a collection>
<Or one could define a role object that looks identical to the group object>
---I'll have to think about the text some more for this one



vii) section 4.3, step 2. what does 'this may also be combined with
group to use the power of "this"' mean. Sorry to be dumb.


(EJS) will respond in separate email



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

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