[Date Prev][Date Next]
[Chronological]
[Thread]
[Top]
[ldapext] Re: I-D ACTION:draft-furuseth-ldap-untypedobject-01.txt
- To: ldapext@ietf.org
- Subject: [ldapext] Re: I-D ACTION:draft-furuseth-ldap-untypedobject-01.txt
- From: "Kurt D. Zeilenga" <Kurt@OpenLDAP.org>
- Date: Fri, 20 Jan 2006 13:51:25 -0800
- In-reply-to: <E1F03Cs-0003UA-Cg@newodin.ietf.org>
- References: <E1F03Cs-0003UA-Cg@newodin.ietf.org>
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