[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