PMP Mail Archive: Re: PMP> Printer MIB Working Group mtg. in Boulder
PMP Mail Archive: Re: PMP> Printer MIB Working Group mtg. in Boulder
Re: PMP> Printer MIB Working Group mtg. in Boulder
Bill Wagner (email@example.com
Tue, 28 Oct 1997 15:40:16 -0500
I have been reading these messages with increasing concern. I will not
be at Boulder, so please interpret this statement as my proxy vote.
Although the inconsistency and generally strange behavior of the
IETF/IESG area coordinators has confused things, it was my
understanding that the PMP had resolved two objectives v-v the printer
1. to take the MIB in RFC1759, with minor corrections and
elucidations and some remaining imperfections, to the draft standards
2. to take all of the great new ideas and better solutions and
start work on a printer MIB II, that we could expect to get out
formally in a year or so.
This deferment of the big fixes reflected a belief that:
a. to get virtually universal buy-in, you needed an RFC that was
not automatically obsoleted in two years (which, formally, RFC 1759
b. that the industry as a whole (including Microsoft) would not
fully support a proposed standard but would support a draft standard
c. that by watching what we changed, we had a good chance of easily
getting to a draft standard
d. that having a well accepted although imperfect MIB that is
widely accepted is preferable to a perfect MIB that is narrowly
We did lose sight of this approach occasionally and, as Jay indicates,
he any others did try to get it back on track. We took too long and
perhaps we made too many changes. But, going to draft is what our
chairmen feel is still possible and desirable. This is, indeed their
However, although (d) is still valid, I am seeing increasing buy-in to
RFC1759 on the part of "other" printer vendors and increasing evidence
that IESG does not understand and does not care about printer MIB's.
If these perceptions are correct, then we should might drop the
attempt to go to draft status with our current candidate, and start on
a PWG enterprise Printer MIB II.
With the slowly increasing buy-in to RFC1759, I suggest that the
appearance of multiple printer MIB's will be highly detremental. I
think it will be confusing and will slow down adaption. I think, since
we have been advertising it as our intent, going to a draft standard
with something that is a less drastic change from the original than
what we are presently working with would encourage wider adaption. In
retrospect, I strongly regret that we strayed from this objective to
clarify and formalize but not significantly change RFC1759.
I would suggest that the group first decide if they want to pursue the
ultimate printer MIB. I would abstain.
If yes, the group should decide is this is to be a standards track or
a PWG enterprise MIB. I would vote PWG enterprise.
Now, what to do with the current MIB.
I suggest the first consideration be in the degree of change. There
are four possibilities: submit nothing; submit just clarifications and
minor things (e.g., making alert time mandatory); submit what we have
now; or fix it up more. Dividing this into two votes, one would be no
or minimal change versus substantive change. If substantive change is
selected, I would vote for the current draft versus adding anything
If minimal change is selected, the second vote would be for none or
clarification. I would vote that, if we are doing a MIB II, there be
minimal change to the current MIB. That means dropping some new
objects (including channel information) not because they are not
useful and desirable, but because they are not absolutely necessary in
the 80/20 consideration, they will cause confusion, most general apps
will not use them since the installed base will have a large
proportion of RFC1759 implementations, and because the real fixes are
in Printer MIB II. Indeed, I would volunteer to propose a modified
1759 update. (Of course, if the vote is to not do a MIB II, I would
suggest keeping the current draft as it is).
Then the last consideration would be if the clarified RFC1759 be
submitted as a new proposed, as an informational, or as a draft
standard. I would vote the path that Lloyd suggested for dual
1. put all the real fixes in Printer MIB II, due out some time in the
2. provide help, clarifications, and perhaps minor improvements, but
do not really mess with RFC1759. Maybe take it to draft status, maybe
a new proposed, maybe just an informational RFC to assist in
ambiguities. But avoid the impression that we are scrapping the whole
thing and starting over.
______________________________ Reply Separator _________________________________
Subject: Re: PMP> Printer MIB Working Group mtg. in Boulder
Author: Jay Martin <firstname.lastname@example.org> at Internet
Date: 10/28/97 1:07 AM
This is starting to get stranger by the moment.
Lloyd, you are now suggesting that the work the PMP has engaged in
over the last two years be submitted as a *new* standard (which
starts off as "Proposed" in the IETF standards track), and not
submit it as the "Draft" form for RFC 1759, right?
I think this is the RIGHT thing to do. (And we should be calling
this new spec something like "Printer MIB II" to follow similar
trends in other MIB-related efforts.)
However, given that, how is it that you are saying we avoid adding
any new stuff to the spec, or significantly changing things that we
(as a group) believe were broken in RFC 1759? Isn't this something
of a contradiction?
Again, I must point out that way back in the January 1996 meeting
(in Miami) I publicly stated that we must immediately shutdown all
attempts to add new objects to the MIB, lest we run into trouble
with the IETF. Morever, we should immediately wrap up minor fixes
to RFC 1759, then move on to "Printer MIB II". When the group
voted on my proposal, it was defeated.
That was almost TWO YEARS AGO.
Something is just not right here. We really must discuss this
situation while so many of the usual participants are currently
gathered together at the Boulder meetings. The PWG has a long and
positive history with regard to quickly dealing with problems
(more importantly, avoiding them in the first place), and now is
not the time to run into the mud. Let's talk.
-- JK Martin | Email: email@example.com --
-- Underscore, Inc. | Voice: (603) 889-7000 --
-- 41C Sagamore Park Road | Fax: (603) 889-2699 --
-- Hudson, NH 03015-4915 | Web: http://www.underscore.com --
> You are correct in what I am suggesting.
> With regards to your question, the exact letter of the law says
> that something must be at a Proposed Standard level for six months
> before progressing to Draft Standard. However there are exceptions
> to this rule and Chris and I believe that if we make NO changes to
> the new Printer MIB after being at Proposed then we have an excellent
> opportunity to bypass the six month wait. A big part of the reasoning
> is that we have made few changes to the new Printer MIB from RFC 1759
> and have considerable interoperability testing on implementations of
> RFC 1759. If we go this route and our Area Directors do not find enough
> justification to wave the six month wait period then they probably
> would not have find enough justification to have accepted the new Printer
> MIB as a Draft Standard now anyway and we would still have had to
> recycle the new Printer MIB through Proposed anyway.
> 10/27/97 05:10 PM
> To: Lloyd Young@Lexmark
> cc: firstname.lastname@example.org
> Subject: RE: PMP> Printer MIB Working Group mtg. in Boulder
> I'm not sure that I follow you. You said:
> > With regards to moving the Printer MIB to Draft Standard, our
> > Area Directors have taken a hard line stand that a MIB cannot be
> > advanced from Proposed to Draft if any new function has been added
> > to a MIB, deletion of function is the only acceptable change.
> > Based on this position, the best thing for us to do to move forward
> > is to submit the new Printer MIB as a Proposed Standard. If we still
> > want to go to Draft Standard, wait until the HR MIB goes to Draft and
> > then quickly submit the new Printer MIB as a Draft Standard as well.
> Are you suggesting that we submit the new Printer MIB as a Proposed
> Standard and then, if Draft Standard status is desired, submit the new
> Printer MIB as Draft Standard after the HR MIB goes to Draft Standard? If
> so, is there a time delay required for the Printer MIB to stay at the
> Proposed Standard level (that might prevent us from moving to Draft
> Standard to immediately follow the HR MIB)?