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

[ldapext] Re: draft-boreham-numsubordinates-01.txt



David, Steve:

Technical comments:
  The document is not clear as to whether it is describing the
  well established semantics of an existing attribute or is
  attempting to introduce an attribute with possibly new
  semantics.  That is, are you just documenting what is or are you
  engineering what will be?  I'll defer making most of my
  comments until you clarify your objectives to the list,
  as they hinge on whether your engineering a new attribute
  type or documenting the well established semantics of an
  existing attribute type.

  A few things which don't hinge on the above question:

  I note that RFC 2252 and X.501 descriptions of
  attribute type differ in specified matching rules.

  DN string used in example does not strictly conform to
  RFC 2253 (extra spaces).

  I suggest the document not detail handling of
  NO-USER-MODIFICATION issues as such detailing is better
  left to base protocol specification.  It is sufficient
  to say that the attribute is defined as not allowing
  user modification and then cite RFC 2251 and 2252.  This
  avoids possible introduction of attribute type specific
  semantics (to what should remain attribute type neutral
  semantics).

  Security Considerations section should note that general
  LDAP security considerations (cite RFC 3377) apply.


Editorial comments:
  Document missing required text/sections
        Does not include (precisely) one of three listed RFC 2026
        statements (see ID guidelines)
        Does not include IANA Considerations section (to detail
        OID assignment and request registration of attribute
        type's short name).
        Does not include IPR statement.
        Does not include short copyright statement.
        Does not include full copyright statement.
  Document is not properly formatted.
        - Don't right justify text
        - Don't hyphenate words
  Document is garbled
        - hyphens replaced with spaces
  Document contains numerous nits
        - acronyms not spelled out on first use in Abstact
        - acronyms not spelled ont on first use in body
        - references not split (normative v. informative)

  The text "is it NOT" likely should be "it is not".
  (out of order, NOT isn't a keyword so shouldn't be uppercased.)

  Should cite RFC 3377 on first use of the term LDAP.
  Should cite RFC 2251 on first use of an protocol element
    defined in RFC 2251 (such as the Search operation).
  Should cite X.501 on use of term DIT.
  Should cite RFC 2252 when presenting LDAP attribute type descriptions.
  Should cite draft-zeilenga-ldap-user-schema-mr for integerOrderingMatch. 
  
-- Kurt 


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