I agree with Jay's improvements on Tom's proposal. I also feel we are f=
ar
enough along with the Job MIB to skip Experimental. In all, however, I =
think we
need to lay down a process for going from Experimental to Standard incl=
uding
any last call, bakeoff, internet informational RFC and subsequent IETF
timelines etc. I am very interested in getting to the point of a standa=
rd job
mib. I don't want to loose sight of the fact that this is our opportuni=
ty to
establish a viable process for the new PWG standards body !
Harry Lewis - IBM Printing Systems
---------------------- Forwarded by Harry Lewis/Boulder/IBM on 12/02/97=
04:47 PM
---------------------------
jkm at underscore.com on 12/02/97 03:44:39 PM
Please respond to jkm at underscore.com @ internet
To: Harry Lewis/Boulder/IBM at ibmus
cc: JMP at pwg.org @ internet, pwg at pwg.org @ internet, hastings at cp10.es.xe=
rox.com
@ internet
Subject: Re: PWG> Re: JMP> Structuring of the PWG enterprise OID tree
Tom,
I, too, tend to like your proposal. However, instead of:
> pwg(2699) pwgstandard(1) jobmon(1)
> pwg(2699) pwgexperimental(2) jobmon(1)
How about more simple words, such as:
pwg(2699) standard(1) jobmon(1)
pwg(2699) experimental(2) jobmon(1)
That is, there is no real value in having the "pwg" prefix.
The more I think of it, though, I don't think we need to have
an explicit "standard" tree. Instead--just like the IETF--we
have an "experimental" subtree, but all other trees at that
level represent "standard" assignments. This means we end up
with (for example):
pwg(2699) jobmon(1)
pwg(2699) experimental(2) jobmon(1)
Btw, I also agree with you that it is quite unnecessary to put
the Job MIB under an "experimental" tree at this point. Let's
just assign the final, "standard" tree and be done with it.
...jay
----------------------------------------------------------------------
-- JK Martin | Email: jkm at 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 --
----------------------------------------------------------------------
Harry Lewis wrote:
>> Tom, I like your idea for experimental and standard. My only question=
is what
> triggers a standard registration and when do we expect this for the J=
ob MIB?
>> Harry Lewis
>> ----- Forwarded by Harry Lewis ------
>>owner-pwg at pwg.org on 12/02/97 12:54:27 PM
> Please respond to owner-pwg at pwg.org @ internet
> To: don at lexmark.com @ internet, jkm at underscore.com @ internet
> cc: JMP at pwg.org @ internet, pwg at pwg.org @ internet
> Subject: PWG> Re: JMP> Structuring of the PWG enterprise OID tree
>> 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 bein=
g
> 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 assigne=
d
> 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
=