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

From: "Andrew Sciberras" <[email-masked]>
Date: Fri, 24 Oct 2003 11:50:32 +1000

Hi,

Just some comments regarding draft-ietf-boreham-numsubordinates-01.txt.

Firstly I'm curious as to what `numSubordinates' identifies as being a
subordinate?
Eg. Is a subentry counted as a subordinate?

>4. Attribute Definition
>
>   ( 1.3.6.1.4.1.453.16.2.103 NAME 'numSubordinates'
>     DESC 'count of immediate subordinates'
>     EQUALITY integerMatch ORDERING integerOrderingMatch
>     SYNTAX 1.3.6.1.4.1.453.16.2.103
>     SINGLE-VALUE NO-USER-MODIFICATION USAGE directoryOperation )
>
>   numSubordinates ATTRIBUTE ::= {
>	WITH SYNTAX		INTEGER
>	USAGE			directoryOperation
>	SINGLEVALUED		TRUE
> 	NO USER MODIFICATION	TRUE
>	ID			{dod internet(1) private(4)
>				enterprises(1) isode-consortium(453)
>				ic-dsa(16) ic-dsa-at(2) 103}
>   }

The SYNTAX is incorrect. It should be 1.3.6.1.4.1.1466.115.121.1.27

> 5. Client-Server Interaction

>Servers MUST ensure that the value returned in the numSubordinates
>attibute to clients is consistent with the view that client has of other
>server contents.

Is this suggesting that the numSubordinates value should take access control
information into consideration, and only provide an indication of how many
subordinate entries the user has access to?

>6.  Relationship to hasSubordinates
>
>The  X.500  hasSubordinates  operational  attribute[ITU-X501] can be
>regarded  as indicating whether numSubordinates has a non-zero value for
>the same entry. This leads to the potential for optimization in a server
>implementation, in that it isn't necessary to store both values.

This may not be exactly the case, as a TRUE value of the `hasSubordinates'
attribute only indicates that subordinates _may_ exist.
As stated in X501:

A value of TRUE may be returned when no subordinates exist if all possible
subordinates are available only through a
non-specific subordinate reference (see ITU-T Rec. X.518 | ISO/IEC 9594-4)
or if the only subordinates are subentries or child
family members.

Cheers,
Andrew Sciberras
Adacel Technologies Ltd

_______________________________________________
Ldapext mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ldapext

---

From: Michael Ströder <[email-masked]>
Date: Fri, 24 Oct 2003 12:29:26 +0200

HI!

I'd also like to add something from the client perspective. IMHO one of the 
most important use-cases for this kind of operational attributes is that it 
enables the client to detect leaf entries which is very useful for 
implementing a comfortable user interface.

> 4.  Attribute Definition
> [..]
> Every entry in the DIT MAY have a numSubordinates operational attribute 
> the contents of which indicate how  many  immediate subordinates that 
> entry has. For example, a leaf entry would have numSubordinates equal to 
> "0". Entry "ou=People, o=ace industry, c=us" in a DIT where the contents 
> of  that  container  comprises 1000 leaf entries, would have
> numSubordinates equal to "1000".

Note that a recent version of one LDAP server implementing numSubordinates 
(SunOne/iPlanet DS 5.x) unfortunately does not return numSubordinates: 0 
anymore (in opposite to Netscape DS 4.x). Instead no numSubordinates 
attribute is returned. This makes this attribute unusable to determine 
whether an entry is a leaf entry or not.

I'd like to see a note stating
'MUST return zero integer value "0" for leaf entries'.

> implementation, in that it isn't necessary to store both values.

I'd like to add a note that it's RECOMMENDED to implement hasSubordinates on 
the server's side if the server already implements numSubordinates. I think 
the "potential for optimization" justifies this.

Ciao, Michael.

---

From: "David Boreham" <[email-masked]>
Date: Thu, 23 Oct 2003 19:03:00 -0700

> Eg. Is a subentry counted as a subordinate?

Good question, and I remember this coming up when I implemented the feature.
My vote would be to not count subentries, but I'm interested to hear what
other folks think.

> The SYNTAX is incorrect. It should be 1.3.6.1.4.1.1466.115.121.1.27

Thanks. I suspect this was a typo as I had an old copy
of the document with the correct syntax OID (which I
un-corrected thinking that it was an error since it didn't
match the 1999 version of the document).

> subordinate entries the user has access to?

Yes.

> or if the only subordinates are subentries or child

Hmm...interesting. I'm happy to remove the paragraph referencing X.501.