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

[ldapext] Re: I-D ACTION:draft-furuseth-ldap-untypedobject-01.txt



I don't see way this class would have any MUST/MAY
attributes (other than 'objectClass' as required
by the SUP top).  It seems that it would be more
appropriate to use DIT content rules/auxiliary
object classes (including possibly extensibleObject)
to require/allow any desired attributes, including
those used for naming.

I don't like the name of this class, but the
alternatives don't seem much better (if better
at all),  'unclassifiedObject', 'structurallessObject',
'unstructuredObject' (at present, I prefer the latter).

A few misc. comments (mostly editorial, but some of
substance).
  Reference the revised LDAP TS instead of RFC 3377 for
  LDAP (its nearly all approved now).

  s/'natural'/natural/ so as not to be confused
  to be an descriptor

  Second paragraph of 1 is not only oddly formated,
  but oddly worded.

  Unclear whether [LDAP-NIS] refers to the revised
  NIS/LDAP specification or RFC 2307.  One or the other
  please.

  The example should include the LDIF for an object of  this class.

  "This document raises no known security issues."
  Well, given RFC 2256 discussions security considerations
  for attributes such as CN, I would think there are
  known security issues impacting this specification.
  And even if you were to removal all attributes from
  the class, there would likely still be some generally
  applicable considerations worthy of mention.  I suggest
  the authors read Section 7 of draft-zeilenga-ldap-ext
  and attempt to satisfy its requirements/recommendations
  here.
  
  "[Editor: I don't know if last sentence is necessary.]"
  It's not.  And the OID assigned would not be
  1.3.6.1.1, but some OID under 1.3.6.1.1.  The
  sentence and note should be deleted.








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