Subject: RE: PMP> Printer MIB Working Group mtg. in Boulder

From: [email-masked]
Date: Mon, 27 Oct 1997 17:53:38 -0500

Bob,
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.
Lloyd
------------

[email-masked]
10/27/97 05:10 PM

To:   Lloyd Young@Lexmark
cc:   [email-masked]
bcc:
Subject:  RE: PMP> Printer MIB Working Group mtg. in Boulder

Lloyd,
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)?
Bob

---

From: Jay Martin <[email-masked]>
Date: Tue, 28 Oct 1997 01:07:54 -0500

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.

	...jay

----------------------------------------------------------------------
--  JK Martin               |  Email:   [email-masked]          --
--  Underscore, Inc.        |  Voice:   (603) 889-7000              --
--  41C Sagamore Park Road  |  Fax:     (603) 889-2699              --
--  Hudson, NH 03015-4915   |  Web:     http://www.underscore.com   --
----------------------------------------------------------------------