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

Re: draft-ietf-boreham-numsubordinates-00.txt



Mark Wahl wrote:

> First, the OID of the definition is different between the LDAP and X.500
> forms.  I would have expected 1.3.6.1.4.1.453 as the prefix.

Ah yes, that's a known error.
 
> Second, the syntax is not one already defined for use with LDAP.  Why not
> use the integer syntax 1.3.6.1.4.1.1466.115.121.1.27, as this is an integer
> value?

And that's a typo caused by me fixing the first error
above incorrectly.

Is this text correct ? :

    ( 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.1466.115.121.1.27
      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}
    }

 
> It might be useful to include some text in how client should expect to be
> able to use this attribute.  For example, should servers be expected to
> implement a filter of (subordinates>=1) in an efficient manner if they provide
> the capability.

Good suggestion.
 
> FWIW we found that 'immediateSubordinates' was a more obvious name for this
> attribute in this capacity.  We use 'immediateSubordinates' for the one-level
> count of both entries and DSEs in our implementation, and 'numSubordinates'
> for the count of the whole subtree including the target entry and all down to
> the leaves of the tree or referral DSEs.  I assume the intention of your
> attribute to count DSEs such as referrals as well as user entries?  We used

Yes, all entries are counted, including DSEs.

> 'numSubordinates' rather than 'subtreeSubordinates' as the latter was too
> difficult to pronounce.

Originally we used some other name, I forget
what it was. Then we discovered that ISODE had
implemented the same attribute as "numSubordinates",
so we changed the name to match that existing
shipping product. "numSubordinates" was used
for similarity with "hasSubordinates".

It's disapointing to discover that you are using
the same name for a different purpose.
Unfortunately, since this has been in the
server since DS4.0 beta 1, it's very unlikely
that we'd change it in the product now.