I have no strong objection to your proposal, other than it requires an
additional OID on top of the 15 or so already present. (So what
difference does one more number make ;-)
When I proposed the flat project oriented model in Boulder, I did not
envision using OIDs for anything other than MIBs. The experience with IPP
certainly hinted that OIDs, and more correctly ASN.1 encoding, are old
technology. (But as we know, old things have a way of coming back in
style.)
If the consenus is that OIDs have a good probably of being used for other
than MIBs I would support your proposal.
On the other hand the Job and Finisher MIBs may be the only consumer of
this OID space.
Can anyone suggest any real requirements for "maybe IPP" and "something
else"? Or is this not worth any further discussion, and just accept Don's
proposed format?
Ron Bergman
Dataproducts Corp.
On Thu, 13 Nov 1997 don@lexmark.com wrote:
>
> JK Martin said:
>
> >> On a more technical note, I would suggest that we
> >> consider moving the Job MIB down one level in the
> >> OID space. I would prefer something like
> >>
> >> ..... 2699.1.1...... Job Mib
> >> ......2699.1.2...... Finisher MIB
> >>
> >> ...... 2699.2.1 ...... maybe IPP space?
> >> ...... 2699.3.1 ..... something else using OID space
> >>
> >> etc.
> >
> >What is your thinking here? I mean, what is the significance
> >of putting JMP/FIN under ...2699.1 versus having IPP under .3,
> >etc? Are you in some way suggesting a set of categories for
> >the top-level OID (ie, .2699.1, .2699.2, etc)?
> >
> >This approach sounds good to me; it's just that I'm trying to
> >figure out your plan here.
>
> My suggestion on the structure of the usage of our
> Enterprise number is to insure some kind of ordering
> and structure to our usage. I would prefer something
> like
>
> 2699
> |
> +-------+------...--+
> | | | |
> 1 2 3 n
> +---+ +---+ +---+ +----+
> | | | | | | | | |
> JMP-+ | | | | |
> | | | | |
> FIN --+ | | | |
> | | | |
> etc ----+ | | |
> | | |
> | | |
> attributes--+ | |
> | |
> operations ---+ |
> |
> etc ------------+
>
>
> This would allow us to put all the MIB work at one point
> (2699.1) and maybe all the IPP at another (2699.2) (maybe
> the need for IPP is non-existant but I use it as an example)
> and other "types" of objects at other places, properly grouped.
> I think this is a better structure than maybe:
>
>
> 2699
> |
> +-------+------...--+
> | | | |
> 1 2 3 n
> + +---+ + +----+
> | | | | |
> JMP---+ | | | |
> | | | |
> attributes -+ | | |
> | | |
> operations -----+ | |
> | |
> FIN --------------+ |
> |
> etc -------------------+
>
>
>
> Maybe its my obsessive/compulsive need for order and structure
> but that's my intent anyway.
>
> Does that explain it?
>
> Don
>
> **********************************************
> * Don Wright don@lexmark.com *
> * Manager, Strategic Alliances and Standards *
> * Lexmark International *
> * 740 New Circle Rd *
> * Lexington, Ky 40550 *
> * 606-232-4808 (phone) 606-232-6740 (fax) *
> **********************************************
>
>
>