Subject: [ldapext] OIDs in LDAP Internet-Drafts

From: "Jim Sermersheim" <[email-masked]>
Date: Fri, 25 Feb 2005 17:46:34 -0700

All,
 
While a specification progresses through its life cycle as an
Internet-Draft, Implementations of it may need to issue OIDs for schema
elements, extension names, etc.
 
Ideally, any time an implementation is updated to match a semantic
change in a newer version of the specification, it will revise the OID
it's using. This would have the effect of indicating support for the
semantics defined in the particular revision implemented.

I know some implementations use their own experimental OID arc for
implementations of pre-RFC specifications. I don't know what their
policy is in terms of updating OIDs as semantics of the specification
change.
 
It would be very useful if, instead of each implementation doing this,
it could be done in the I-D itself. Ideally, one would procure a
"proposed OID arc" from IANA. The I-D editor would then update OID
assignements in the specification, and rev them anytime a semantic
change would cause an interoperability problem. Alternately (more
simply) the editor could update them all everytime the I-D was revised.
To make it easy, they could even assign an arc below the IANA-assigned
arc which adopts the I-D revision number. i.e. if the IANA assigned arc
is 1.2.3.4, the OIDs in the I-D would be 1.2.3.4.0.x for the -00
revision, and 1.2.3.4.1.x for the -01 revision.

When the I-D is progressed to an RFC, IANA could do its usual
assignment / replacement.

The two benefits I see are that multiple interoperable implementations
may be produced while a specification is being progressed, and that the
experimental/temporary OIDs being used will match a specific incarnation
of the specification.

What think ye?

Jim

_______________________________________________
Ldapext mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ldapext

---

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Fri, 25 Feb 2005 19:50:19 -0800

I see a couple of flaws in your rationale for OID versioning
in "works in progress".   The main one is that early
implementations do not adhere strictly to one particular
revision of the "work in progress".  That is, aside from the
specification being a "work in progress", often so are early
implementations.  Consistency is hard in the early stages of
development of an extension specification and its implementations.

It seems far easier for a single implementor wanting to develop
peers to use a locally assigned OID.  This is what the OpenLDAP
Project does, it seems to work fine.  We have a special branch
for this, known the "devil made me do it" branch.  The assignment
practice in this branch is that each OID identifies a "work in
progress" (or portion thereof) as currently implemented.  Again,
no consistency guaranteed.  It's a work in progress after all.
For this and other reasons, we avoid advertising support for
"works in progress", even in development codes. 

For those wanting to do some interop testing, those participating
in the testing should easily be able to reach some adhoc agreement
as what OID to use.  Since we talking early implementation here, I
presume that changing OIDs to test is no big deal.

That all said, if you want to provide an OID, you may use
Experimental OIDs (see Section 3.1 of BCP 64).  These MUST be
replaced prior to publication as an RFC.  I see no reason why
you could version assignments under the OID.  BCP 64 certainly
does not preclude that.

I would not recommend updating OIDs on each revision.  That just
creates unnecessary change.   Instead only update the OIDs when
the new semantics are not backwards compatible with the old
semantics.

Personally, I think I'll stick to my current approach.  Avoid OIDs
in I-Ds.