PWG> PWG OID Structure Proposals

PWG> PWG OID Structure Proposals

PWG> PWG OID Structure Proposals

Ron Bergman rbergma at dpc.com
Wed Jan 14 11:49:46 EST 1998


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.








     



More information about the Pwg mailing list