Introduction

OID strings are unique numeric identifiers based off of a hierarchical numeric namespace controlled by a central authority on the Internet: IANA (Internet Assigned Numbers Authority).

IANA allows companies and organizations to register for a specific OID base called an enterprise number. There can only be one IANA Enterprise Number per organization.

The ASF's Enterprise Number

Apache has such an enterprise number. You can look at the IANA assigned numbers here. Here's the record in this database for the Apache Software Foundation:

18060
  The Apache Software Foundation
    Alex Karasulu
      akarasulu@apache.org

This means the ASF can use the following unique OID base 1.3.6.1.4.1.18060 for any of it's needs. However we internal here at the ASF need some kind of scheme for assigning these numbers internally so we do not have collisions.

Current Assignments

Here's what we've assigned to date:

Each contact person is the authority for assigning unique OID values and ranges to projects or persons. Contact that person for more assignments.

Making Assignments

Contacts may wonder what scheme is best for making assignments. There is no rule for doing this. However some would recommend assigning the first digit past the enterprise number of an organization to be for identifying a protocol. Obviously we did not do this for Apache. The reason for this is because we feel it's better to model the assignments based on the structure of the organization since these are private ranges and need not conform to a global convention.

However this still does not tell us how contacts should make assignments. I think this is up to you. Perhaps a good example will be how the Directory TLP does things which is somewhat specific to their products and the nature of their products.

Assignment Scheme For Apache Directory

The ninth component in the OID could be reserved for subprojects like ApacheDS and Triplesec. This might be more attractive in TLPs with many subprojects because a single authority or contact can be used for a specific subproject. So here could be one assignment scheme:

bad OID! The Triplesec OID collides with another Directory OID. I suggest we use another OID for Triplesec, like 1.3.6.1.4.1.18060.5. And so this is what we have set it up as above.

Here's how the ApacheDS OID is branched off:

dITContentRules do not have their own OID, rather they reference the OID of the structural objectClass they influence. The same sort of situation exists for matchingRuleUse which uses the OID of the matchingRule it is associated with.

And here are the schema OIDs:

OID's for ApacheDS specific controls

Here are the new OIDs used:

OID's for the extended operations

Here are the new OIDs used: