Don,
I did not intend to eliminate this combination and I would prefer it over
the combination that includes the standard / experimental.
Note that reserving spaces for future related projects does not have to be
a requirement. It happens automatically, whether you like it or not.
Also, an experimental branch (arc) could be defined (maybe at 100 which
would allow 99 funtional types), if this is desired.
Ron Bergman
Dataproducts Corp.
On Wed, 14 Jan 1998 don at lexmark.com wrote:
>> What about a combination of the functional and project structure that
> reserves
> spaces for future projects related to existing projects? For example:
>> ....2699.1 = MIBs
> ....2699.1.1 = Job Monitoring
> ....2699.1.1.1 = Job MIB
> ....2699.1.1.2 = Job MIB extensions #1
> ....2699.1.1.3 = Job MIB extensions #2
> ....2699.1.2 = Finisher
> ....2699.1.2.1 = Finisher MIB
> ....2699.1.2.2 = Finisher MIB extensions
> ....2699.1.3 = Printer
> ....2699.1.3.1 = Printer MIB II
> ....2699.1.3.2 = Printer MIB II extensions
> ....2699.2 = Protocols
> ....2699.2.1 = IPP
> ....2699.2.1.1 = IPP operations
> ....2699.2.1.2 = IPP Attributes
>> I think this has the advantages of both. The only downside is that
> the structure is one digit longer than either --- not really much
> of a problem.
>> **********************************************
> * Don Wright don at lexmark.com *
> * Product Manager, Strategic Alliances *
> * Lexmark International *
> * 740 New Circle Rd *
> * Lexington, Ky 40550 *
> * 606-232-4808 (phone) 606-232-6740 (fax) *
> **********************************************
>>>>>> rbergma%dpc.com at interlock.lexmark.com> 01/14/98 11:49 AM
>>> To: jmp%pwg.org at interlock.lexmark.com, pwg%pwg.org at interlock.lexmark.com> cc: (bcc: Don Wright)
> bcc: Don Wright
> Subject: JMP> PWG OID Structure Proposals
>>>>> 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.
>>>>>>>>>>>