There was considerable email discussion last December regarding the
structure of the OIDs in the PWG enterprises subtree, without a final
resolution. Here is a summary of the proposed PWG OID structures:
1. A flat structure where each item, whether it is a MIB, operations,
attributes, etc, is assigned a number under 2699. For example:
....2699.1 = Job Monitoring MIB
....2699.2 = Finisher MIB
....2699.3 = Printer MIB-2
....2699.4 = IPP operations
....2699.5 = IPP Attributes
....2699.6 = Finisher MIB extensions
....2699.7 = Job Monitoring MIB extensions
The next number in sequence is assigned as needed.
Experimental OIDs could be indicated by numbers in a higher range.
For example, numbers of 10000 or greater would be experimental.
Or, until a document is released as official, either as a IETF RFC
or by some other approved means, it is still regarded as
experimental. In this latter case, some numbers may never become
approved.
2. A project structure where related items are grouped together. In
this case the above would be grouped:
....2699.1 = Job Monitoring
....2699.1.1 = Job Monitoring MIB
....2699.1.2 = Job Monitoring MIB extensions
....2699.2 = Finisher
....2699.2.1 = Finisher MIB
....2699.2.2 = Finisher MIB extensions
....2699.3 = Printer
....2699.3.1 = Printer MIB-2
....2699.4 = IPP
....2699.4.1 = IPP operations
....2699.4.2 = IPP Attributes
3. A function structure where items are grouped by document type.
Again, the above items would now be grouped:
....2699.1 = MIBs
....2699.1.1 = Job Monitoring MIB
....2699.1.2 = Finisher MIB
....2699.1.3 = Printer MIB-2
....2699.1.4 = Finisher MIB extensions
....2699.1.5 = Job Monitoring MIB extensions
....2699.2 = Protocols
....2699.2.1 = IPP
....2699.2.1.1 = IPP operations
....2699.2.1.2 = IPP Attributes
4. A major grouping by experimental and standard items.
....2699.1 = PWG Standard OIDs
....2699.2 = PWG Experimental OIDs
Combinations of the above are also possible. For example, the
experimental / standard grouping could be followed by the function
structure and followed by the project structure. (It is an exercise for
the reader to create this figure using the above items.)
This subject was also discussed in the JMP session at both the Boulder
and LA meetings. In the Boulder meeting, Harry proposed the project
structure and I proposed the flat structure. In both meetings there
was not much excitement for this topic and the general agreement was
the flat structure was good enough.
The current Job Monitoring MIB follows the project structure and
results in the following OIDs:
First MIB object jmGeneralJobSetIndex: (x = Table index)
1.3.6.1.4.1.2699.1.1.1.1.1.1.1.x (15 OID positions)
Last MIB object jmAttributeValueAsOctets: (x, y, x = Table indices)
1.3.6.1.4.1.2699.1.1.1.4.1.1.4.x.y.z (17 OID positions)
Using the combinations of structures 2, 3, and 4 these OIDs are:
First MIB object jmGeneralJobSetIndex: (x = Table index)
1.3.6.1.4.1.2699.1.1.1.1.1.1.1.1.1.x (17 OID positions)
Last MIB object jmAttributeValueAsOctets: (x, y, x = Table indices)
1.3.6.1.4.1.2699.1.1.1.1.1.4.1.1.4.x.y.z (19 OID positions)
Using the flat structure provides the shortest OIDs:
First MIB object jmGeneralJobSetIndex: (x = Table index)
1.3.6.1.4.1.2699.1.1.1.1.1.1.x (14 OID positions)
Last MIB object jmAttributeValueAsOctets: (x, y, x = Table indices)
1.3.6.1.4.1.2699.1.1.4.1.1.4.x.y.z (16 OID positions)
While I believe that the combination of all three structures provides
the most information and flexibility, do we really need all this
capability? There is usually some elegance in simplicity. How many
projects will require an OID assignment in the future?
As should be evident, my preference is for the flat model. But I do not
see a major implementation difference in any of the proposals. We do
need to reach a group consensus on this topic to complete the Job MIB.
This issue should be discussed and an agreement reached in Maui. I would
like to add this discussion to the PWG general topics on Wednesday
morning.
Ron Bergman
Dataproducts Corp.