Subject: Re: JMP> Structuring of the PWG enterprise OID tree

From: Tom Hastings <[email-masked]>
Date: Tue, 2 Dec 1997 11:45:44 PST

I started to edit the Job Monitoring MIB with the PWG standard OIDs
as proposed, even though I preferred Harry's flat OID approach.

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:   [email-masked]          --
>--  Underscore, Inc.        |  Voice:   (603) 889-7000              --
>--  41C Sagamore Park Road  |  Fax:     (603) 889-2699              --
>--  Hudson, NH 03051-4915   |  Web:     http://www.underscore.com   --
>----------------------------------------------------------------------
>
>
>[email-masked] 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                 [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: [email-masked] (Ira Mcdonald x10962)
Date: Wed, 3 Dec 1997 12:15:09 PST

Reference: Re: JMP> Structuring of the PWG enterprise OID tree

Hi folks,                                    Wednesday (3 December 1997)

Jay kind of distorted the form of the Internet OID tree.  Note that all
IETF standards track projects start out at 'experimental' (which is
'internet 3') and then move over (at Proposed Standard stage) to 'mgmt'
(which is 'internet 2').  The space is NOT flat under 'internet' (which
is 'iso(1) org(3) dod(6) 1').  Some 'internet' branches (see RFC 1902):

directory       OBJECT IDENTIFIER ::= { internet 1 }
mgmt            OBJECT IDENTIFIER ::= { internet 2 }
  mib-2           OBJECT IDENTIFIER ::= { mgmt 1 }
experimental    OBJECT IDENTIFIER ::= { internet 3 }
private         OBJECT IDENTIFIER ::= { internet 4 }
  enterprises     OBJECT IDENTIFIER ::= { private 1 }
security        OBJECT IDENTIFIER ::= { internet 5 }

I suggest that we avoid using the arc 'experimental' in the PWG tree, to
avoid confusion with the full OID 'experimental' in the Internet tree.

I still recommend that the Job Mon MIB module OIDs be:

    enterprises pwg(2699) pwgstandard(1) jobmon(1)
    enterprises pwg(2699) pwgexperimental(2) jobmon(1)

I also recommend that the next draft be 'pwgexperimental(2) jobmon(1)',
because the dust hasn't settled yet in the IESG on IPP and alignment
with the PWG Job Mon MIB v1.0 is highly desirable.

Cheers,
- Ira McDonald