[Date Prev][Date Next]
[Chronological]
[Thread]
[Top]
OIDs (Was: [ldapext] Password Policy OIDs)
At 04:20 PM 10/27/2004, Jim Sermersheim wrote:
>FWIW, this is what finally pushed me into raising the thread on the list ? Do I get another OID from the Netscape folks? Do I add the first IANA_ASSIGNED oid? I'd rather move to all IANA_ASSIGNED oids at the same time I assign the administrative role OID.
I suggest you use a marker in the I-D, IANA-ASSIGNED-OID, for the
one "directory" OID to be assigned by IANA. The RFC Editor will
replace this with the assigned "directory" OID just prior to
publication.
Or you can ask IANA an experimental OID to the I-D and use that
while the I-D is a "work in progress". The RFC Editor will replace
this OID just prior to publication with an IANA assigned directory
OID.
In either case, you'll need an IANA consideration section requesting
an OID be assigned to the RFC (as well as detailing all uses of that
OID), as well as note to the RFC Editor to do the appropriate edits
(especially in the latter case). I generally recommend the former
approach.
You should generally avoid use of private OIDs in IETF standards.
See BCP 64 (RFC 3383) for guidance.
>
>We also need to dscribe how these administrative areas work. Can they overlap? Can they be defined in a way that causes some objects to be governed by no pwd policy subentry? Can one object be governed by multiple pwd policy subentries? If so, must each governing subentry list a unique pwd attribute?
>
>Jim
>
>_______________________________________________
>Ldapext mailing list
>Ldapext@ietf.org
>https://www1.ietf.org/mailman/listinfo/ldapext
_______________________________________________
Ldapext mailing list
Ldapext@ietf.org
https://www1.ietf.org/mailman/listinfo/ldapext