PMP> Printer MIB - what to do?

PMP> Printer MIB - what to do?

Harry Lewis harryl at us.ibm.com
Thu Nov 19 12:53:53 EST 1998


Please - no one take offense - I'm not criticizing anyone in particular (I'm
just pleading for collective sanity) but... THIS IS RIDICULOUS!

In a note to the PWG on 11/17, the HR MIB editor stated...

>I was doing the hostmib advancement really for the PWG group.  Empire
>and the rest of the HostMIB community did not have much stake either
>way in advancing the Host MIB or leaving it where it currently stands.

Now, in order to get the few minor interoperability improvements recognized as
standards track, after sitting on the burner for (2 years!?)... we end up with
the option...

>1. Re-align the new Printer MIB with RFC1514 and submit the new Printer
>MIB as Proposed. (Fastest path to RFC, however this means removing
>the changes to hrPrinterDetectedErrorState.)

Options 2, 3, 4, 5, 6, 7, 8... WAIT, WAIT, WAIT, WAIT!!

HEY PEOPLE!!! It's hr***PRINTER***ErrorState we're talking about here! Doesn't
ANYONE else understand this!? No one else ON EARTH is interested in this OID in
the HR MIB except PRINTER PEOPLE... for whom the representative body (the PWG)
has clearly, patiently and consistently requested this SIMPLE change. Further,
the "change" is a simple EXTENSION to an OID which was obviously architected
for extension!!!

WHAT in the world is going on here!!!???

In October 1997 I proposed an alternative. I said leave the HR MIB as is and
add a mirror object in the Printer MIB for the extensions. In other words bring
"control" and management of hrPrinterDetectedErrorState into the Printer MIB
where it so obviously belongs. I did not propose deprecating the existing
definitions from the HR MIB, just simply making any and all future extensions
in the Printer MIB. This would have entirely de-coupled us from this HR
dilemma.

I was told I could not discuss this topic at the meeting because is had not
previously been added to the agenda! I made the suggestion via e-mail but
reaction was watered down by the constant peering to the horizon for action on
the HR MIB.

COME ON!!!!! Are we BROKE, or WHAT!?

Harry Lewis - IBM Printing Systems
harryl at us.ibm.com



pmp-owner at pwg.org on 11/18/98 04:27:13 PM
Please respond to pmp-owner at pwg.org
To: pmp at pwg.org
cc:
Subject: PMP> Printer MIB - what to do?


I have heard from Don and Harry that there was a group opinion
stated at the Tucson PWG meeting last week that a RFC number for the
Printer MIB was desired ASAP. I wanted to state a couple of things
and then get down to the business at hand. First, I had heard the
same thing from Don after the Savannah meeting in September and put
out an email attempting to gather a consensus and only three people
responded with no consensus on how we should proceed. I am going
to assume that my email dated September 8th entitled Possible
Change in direction for the Printer MIB was not clear enough and
attempt to gather a consensus again on how we should proceed.
Secondly, if you cast a vote at the face to face PWG meeting, you
still need to state your opinion on the mailing list so we can
reach a consensus with the entire working group and not just the
ones that attended the face to face meeting.

If a RFC number is desired for the Printer MIB ASAP then the only
option that I know is to back out the changes to
hrPrinterDetectedErrorState that were made in the latest Host
Resources MIB Internet Draft and align the new Printer MIB with
the HR MIB published as RFC1514. In other words if we want to pick
up the additional bit definitions for hrPrinterDetectedErrorState
then we need to continue to wait for the new Host Resources MIB to
get a new RFC number.

Therefore I think we have three options available to us:
1. Re-align the new Printer MIB with RFC1514 and submit the new Printer
MIB as Proposed. (Fastest path to RFC, however this means removing
the changes to hrPrinterDetectedErrorState.)
2. Wait for the new Host Resources MIB to get an RFC number and
submit the new Printer MIB (with the new hrPrinterDetectedErrorState)
as Proposed.
3. Wait for the new Host Resources MIB to get an RFC number and
submit the new Printer MIB (with the new hrPrinterDetectedErrorState)
as Draft.

Choosing Option 1 is certainly the fastest path to RFC publication.
We would give up some function improvement with the new
hrPrinterDetectedErrorState but we would still gain all of the other
improvements that have been made in the new Printer MIB.

If Option 1 is not acceptable then there is Option 2 or 3. While I listed
Option 2, it has any advantage over Option 3. In fact our Area Directors
have told us that Option 3 would be faster than Option 2.

Therefore with all of this, we as a working group need to decide if the
hrPrinterDetectedErrorState changes are important enough to continue to
wait on the new HR MIB.

If anyone else thinks there is another option, I would like to hear
their ideas.

One other side item - if you feel that getting the Printer MIB to Draft
Standard is extremely important then you should vote for Option 3. For
several reasons if the working group chooses Option 1, it will be difficult
to move the Printer MIB to Draft in the future.

Again so everyone understands, I am requesting a vote for Option 1, Option
2 or Option 3 (at least until someone suggests another option).

Regards,
Lloyd

------------------------------------------------------------
Lloyd Young                       Lexmark International, Inc.
Senior Program Manager            Dept. C08L/Bldg. 035-3
Strategic Alliances               740 New Circle Road NW
internet: lpyoung at lexmark.com     Lexington, KY 40550
Phone: (606) 232-5150             Fax: (606) 232-6740







More information about the Pmp mailing list