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

From: [email-masked]
Date: Thu, 13 Nov 1997 08:09:27 -0500

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: Jay Martin <[email-masked]>
Date: Thu, 13 Nov 1997 11:37:12 -0500

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   --
----------------------------------------------------------------------

---

From: Jay Martin <[email-masked]>
Date: Thu, 13 Nov 1997 11:37:12 -0500

Don,

	...jay

---

From: Ron Bergman <[email-masked]>
Date: Thu, 13 Nov 1997 18:38:51 -0800 (Pacific Standard Time)

Don,

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.

---

From: Ron Bergman <[email-masked]>
Date: Thu, 13 Nov 1997 18:38:51 -0800 (Pacific Standard Time)

Don,

	Ron Bergman
	Dataproducts Corp.

---

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

---

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

Ok?

Tom