RE: [ldapext] draft-ietf-boreham-numsubordinates-01.txt

["Volpers, Helmut" <helmut.volpers@siemens.com>]

Hi,


> -----Original Message-----
> From: Andrew Sciberras [mailto:andrews@adacel.com.au] 
> Sent: Monday, November 03, 2003 12:37 AM
> To: Ldapext (E-mail)
> Subject: RE: [ldapext] draft-ietf-boreham-numsubordinates-01.txt
> 
> 
> >I feel that numsubordinates should return 0 when 
> hassubordinates would 
> >return FALSE.  Since hassubordinates can include subentries, 
> >numsubordinates should also.
> >
> >John  McMeeking
> >
> 
> 
> Hi,
> 
> I think that subentries should not be included in the 
> numSubordinates count.

I disagree.
> 
> If a use-case for the numSubordinates is to aid a GUI in 
> deciding (for browsing purposes) if an entry is a leaf, then 
> returning 0 (zero) for an entry with one or more subentry's 
> and zero subordinate entries is acceptable. This is because, 
> under your general browsing and searching type operations, 
> subentries are not considered. If the GUI was being used for 
> Administrative purposes, where subentries may wish to be 
> explored, then simply checking if the entry is an 
> administrative point should accomplish this.

I think normal user applications will not use this feature today and they 
don't need it in future. The GUI for administrative purposes will use
this feature and they will display the subentries also.
> 
> 
> Another possible use-case for the numSubordinates attribute, 
> which has been expressed on this list, is for making 
> decisions as to whether the entry is a leaf for deletion 
> purposes. Ludovic correctly pointed out that having 
> numSubordinates == 0 and getting a NON_LEAF error when 
> deleting would be confusing. I don't believe a use-case of 
> numSubordinates should be to identify if an entry is a leaf 
> for deletion purposes.

I agree.

 Aside from ignoring subentries, the 
> scenario of numSubordinates == 0 and a NON_LEAF error will 
> occur when the user does not have sufficient permissions for 
> the subordinate entries to be included within the 
> numSubordinates count.
> 
> On the topic of access control... The draft states:
> 'Servers MUST ensure that the value returned in the 
> numSubordinates attribute to clients is consistent with the 
> view that client has of other server contents.' 

I don't like this. What means consistent with the view that client has ?

It has been 
> established that this means that Access Controls should be 
> taken into consideration when returning the numSubordinates 
> value. I think the draft should be a little more specific 
> though. Depending on what the intended use-case of 
> numSubordinates is, a statement should exist regarding which 
> permissions should be assessed when returning a 
> numSubordinates value. E.g..

I think the numSubordinates is a operational attribute and a administrator
can put access  rights on this attribute, but if this attribute is granted
to
read then it should return the numSubordinates value and not different
values 
dependant of the rights.

> * Is the decision based on modify or read permissions?
> * What happens if the entry's DN can be returned in a search, 
> but the user is not allowed to browse its contents?
> * Which Access Control specification are we referring to? 
> (BAC as defined in X501, or the old 
> draft-ietf-ldapext-acl-model-xx.txt)

Make it independent of the Access Control.
> 
> 
> Not including subentries within the numSubordinates count 
> does introduce an inconsistency between the numSubordinates 
> and hasSubordinates attributes. Is it the intention of this 
> specification to maintain the some level of consistency? If 
> so, are you including Non-Specific Subordinate References or 
> child family members in the numSubordinates count? Whilst 
> NSSR and child family members are both X.500 things, LDAP 
> based Internet Drafts of each have existed at some point in the past.

I think nobody have implemented NSSR's and if you have child family members
it is the decision of the Server whether numsubordinates is counted with
"1" for one family or with the number of childs.


Regards

Helmut
> 

> 
> Regards,
> Andrew Sciberras
> Adacel Technologies.
> 
> 
> _______________________________________________
> Ldapext mailing list
> Ldapext@ietf.org
> https://www1.ietf.org/mailman/listinfo/ldapext
> 

_______________________________________________
Ldapext mailing list
Ldapext@ietf.org
https://www1.ietf.org/mailman/listinfo/ldapext