Re: Assigning OIDs to private schema items

["Kurt D. Zeilenga" <Kurt@OpenLDAP.org>]

At 11:35 AM 12/2/99 +1300, Graeme Joyce wrote:
>We've got an enterprise number / OID (1.3.6.1.4.1.2553) and now its time to
>actually assign numbers to attributetypes and objectclasses.

First, you should list the OID at http://www.alvestrand.no/harald/objectid/.
I also recommend you establish your own registry and listing services
for the OIDs under your control.   Your registry/listing can be a
simple flat file or something slicker.
  http://www.openldap.org/faq/index.cgi?file=197

>I guess we should leave room

Leaving Room is EVERY important, ESPECIALLY to allow delegation
of arcs to others.

We reserve .0 across our whole OID arc.

>in the numbering scheme for the possibility of also
>defining our own attribute syntaxes and matching rules in the future. I'm
>wondering if there are any accepted practices for going about this?

Most folks categorize the objects to which your are
assigning OID to and organize your tree based upon
these categories.  Many folks use the categories
provided by the protocol(s) or information model.
(Note, the protocol itself may be a category).

We (OpenLDAP) also categorize by use.  That is we have
an OID branch reserved for EXPERIMENTAL use.  Here
we allow object described by the OID to change.  We
have another category for PUBLISHED OIDs where the
object is not allowed to change (that is, any change
is considered a "new" object).

Within each of these arcs, we then categorize by
item type.

Another useful category is "related items".  That is,
if you are defining a set of related schema items (of
differnet types) you may want to assign an OID for
the set of items and use OIDs of the next level for
individual items within the set (with or without further
categorization).

I noted above the need to issue new OIDs for certain
categories of objects (such as published schema items).  One
way to handle this is use subOIDs to indicate revisions.  Example,
you want to define a new object class, you assigned OID 1.2.3.4
for the general description of the object class and 1.2.3.4.x
for each revision of the object's specification.  In use with
LDAP, you would always use an OID referring to a particular
specification.

Another categorization that may be useful is administrative
organizational units within your organization.  That is,
you may want to delete arcs under your OID to organizational
units and allow them to manage their arcs independently.
	<prefix>.1	Engineering
	<prefix>.2	IT
	<prefix>.3	Marketing :-)
or:
	<prefix>.1	US
	<prefix>.49	Germany

>Any reasons why this is or isn't a good idea?

Categorization is generally good up to a point.  You can make
the tree as deep or as flat as you like.

>Any suggestions for improvements?

You're doing exactly what I suggest.  Review what other folks
have done, make room for the future.

>Does it really matter if we all do something different?

You can do whatever you want with your OID arc.

>I have the feeling
>that looking at an OID an knowing whether it refers to an attributetype or
>an objectclass could be useful,
>but based on the above it seems too late for
>that to work across multiple schema definitions anyhow.

You should publish OID assignments appropriately.

For LDAP schema items, I recommend you publish specifications
for each item that includes both a plain language description
and a description in either (or both) ASN.1 or RFC2252 format.
You may also want to provide descriptions suitable for use
with the particular LDAP implementations you have deployed.