However, when discussing how to write it in SNMP ASN.1 with Ira,
we realized that maybe the PWG ought to distinguish between
PWG experimental OIDs and PWG standard OIDs, just like with the
IETF MIBs.
So we propose the following:
Under iso(1) org(3) dod(6) internet(1) private(4) enterprises(1)
we have separate trees for PWG experimental and PWG standard:
pwg(2699) pwgstandard(1) jobmon(1)
pwg(2699) pwgexperimental(2) jobmon(1)
Our current jobmon MIB is so near to becoming a PWG standard that
we don't need this distinction. We haven't changed an OID during the
last six months of drafts. However, just to be safe, I'm going to
publish the next draft using the pwgexperimental(2) arc. Then if we
decide that the above OID scheme isn't any good, we can change it.
Experimental OIDs are free to be changed from draft to draft, but
standard ones are not.
The idea of pwgstandard OIDs is that the OIDs never change after being
published, just like the IETF. (Adding new OIDs can be done to
standards, that is NOT changing published OIDs).
We also propose NOT to asign arc to PWG projects, but to actual PWG
needs, in this case the jobmon mib. Thus a project can get one or
more arcs assigned, depending on its needs. Also OIDs can be assigned
for non-MIB purposes as well.
Another advantage to this approach, is that we don't need to decide
now what categories we might want in the future.
Ok?
Tom
At 08:37 11/13/1997 PST, Jay Martin wrote:
>Don,
>
>Well, ok. I guess all we can derive from your explanation is that
>you want to put all MIBs under one subtree, and other "things" in
>other subtrees (eg, IPP under a separate top-level subtree).
>
>I guess that's ok...but I sure would like some idea of what the
>other "things" might be. Either way, your approach is certainly
>acceptable.
>
>If there are no substantive objections, we shall assume the
>approach described by Don (below).
>
> ...jay
>
>----------------------------------------------------------------------
>-- JK Martin | Email: jkm@underscore.com --
>-- Underscore, Inc. | Voice: (603) 889-7000 --
>-- 41C Sagamore Park Road | Fax: (603) 889-2699 --
>-- Hudson, NH 03051-4915 | Web: http://www.underscore.com --
>----------------------------------------------------------------------
>
>
>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) *
>> **********************************************
>
>