Subject: Re: JMP> Job MIB - trials and tribulations

From: [email-masked]
Date: Fri, 14 Nov 1997 12:59:14 -0500

Harry Lewis said:

>I will just reiterate my proposal which bases the hierarchy on PWG
projects...
>given that these tend to "foster" separate standards...
>
>..... 2699.1.1......  Job Mib
>..... 2699.1.2 .....  Future Job Mib extensions
>..... 2699.2.1 .....  Finisher Mib
>..... 2699.2.2 .....  Finisher Mib extensions
>..... 2699.3.1 .....  Hey, how about... Printer Mib
>..... 2699.3.2 .....  Printer MIB extensions
>..... 2699.3.2 .....  Printer MIB extensions
>..... 2699.4.1 .....  IPP Operations (as suggested by someone, below)
>..... 2699.4.2 .....  IPP Attributes
>
>What about a space for registering things like type-2 enums etc.?
>
>I don't feel real strongly about this proposal... I think just about any
>structure will have pro's and con's.

In Harry's format, I would really prefer the following which tends to group
like things together, IMHO.  If we add some other MIB later on, it would
fall under the MIB sub-tree as opposed to after IPP and the Internet
Finishing Protocol or whatever else happens before that new MIB.
......2699.1........  MIBS
..... 2699.1.1.1......  Job Mib
..... 2699.1.1.2 .....  Future Job Mib extensions
..... 2699.1.2.1 .....  Finisher Mib
..... 2699.1.2.2 .....  Finisher Mib extensions
..... 2699.1.3.1 .....  Hey, how about... Printer Mib
..... 2699.1.3.2 .....  Printer MIB extensions
..... 2699.1.3.2 .....  Printer MIB extensions
......2699.2.......   IPP
..... 2699.2.1 .....    IPP Operations (as suggested by someone, below)
..... 2699.2.2 .....    IPP Attributes
......2699.3.......   Something else

To be consistant, we might even want to do something like:

......2699.1........  MIBS
..... 2699.1.1.1......  Job Mib
..... 2699.1.1.2 .....  Future Job Mib extensions
..... 2699.1.2.1 .....  Finisher Mib
..... 2699.1.2.2 .....  Finisher Mib extensions
..... 2699.1.3.1 .....  Hey, how about... Printer Mib
..... 2699.1.3.2 .....  Printer MIB extensions
..... 2699.1.3.2 .....  Printer MIB extensions
......2699.2........  PROTOCOLS
......2699.2.1......    IPP
..... 2699.2.1.1 .....    IPP Operations (as suggested by someone, below)
..... 2699.2.1.2 .....    IPP Attributes
......2699.2.2.......   Some Other Protocol
......2699.3........  SOMETHING_ELSE_BESIDES_MIBS_AND_PROTOCOLS

but I won't get hung up on that.  I think insuring all the MIBs are in the
same
sub-tree is probably sufficient.

Don

**********************************************
* Don Wright                 [email-masked] *
* Manager, Strategic Alliances and Standards *
* Lexmark International                      *
* 740 New Circle Rd                          *
* Lexington, Ky 40550                        *
* 606-232-4808 (phone) 606-232-6740 (fax)    *
**********************************************

---

From: Tom Hastings <[email-masked]>
Date: Fri, 14 Nov 1997 12:51:10 PST

Could someone write down the entire path for OIDs that will be needed
for the Job Mon MIB?  How many octets long is it?  Is the length a problem?

By the way, I don't see any use of OIDs for IPP at the moment.  We don't
have an OID attribute syntax.  We are using keywords for the same purpose.

There are the following possible examples for the PWG assigning OIDs for
use with:

a. ISO DPA attributes or values.  Maybe even assiging attribute OIDs for use
with the DPA Printer object that are the equivalent of Printer MIB objects.

b. OIDs for use with other MIBs as object values, such as device types in
HR MIB(?).

On the other hand, the value immediately under the 2699 could be for
whatever type.  

So with either scheme, we are not constrained with inventing new types
of uses for OIDs as far as I can see.

The advantage of the scheme agreed in Boulder, is that we don't need
to have any more discussion about what other uses we might put OIDs to.
We can just use them for whatever purpose when the need arises and just
assign the next available arc which would be 2 after the Job Monitoring MIB
uses 1.

The advantage of Don's scheme is that like things are grouped together.
But would it hurt if ...2699.1.xx was Job MIB, ...2699.2.xx was for some
non-MIB thing, and xxx2699.3.xx was for another PWG MIB?  Even SNMP
MIB walks would just skip over any holes that had been used for non-MIB
things.

So I'm in favor of the original proposal as being shorter, simpler,
and easier to agree to.

Tom

---

From: Tom Hastings <[email-masked]>
Date: Fri, 14 Nov 1997 12:51:10 PST

Tom