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 recogn=
ized 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 Printe=
r
>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 thi=
s OID in
the HR MIB except PRINTER PEOPLE... for whom the representative body (t=
he PWG)
has clearly, patiently and consistently requested this SIMPLE change. F=
urther,
the "change" is a simple EXTENSION to an OID which was obviously archit=
ected
for extension!!!
WHAT in the world is going on here!!!???
In October 1997 I proposed an alternative. I said leave the HR MIB as i=
s and
add a mirror object in the Printer MIB for the extensions. In other wor=
ds bring
"control" and management of hrPrinterDetectedErrorState into the Printe=
r MIB
where it so obviously belongs. I did not propose deprecating the existi=
ng
definitions from the HR MIB, just simply making any and all future exte=
nsions
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 b=
ut
reaction was watered down by the constant peering to the horizon for ac=
tion on
the HR MIB.
COME ON!!!!! Are we BROKE, or WHAT!?
Harry Lewis - IBM Printing Systems
harryl@us.ibm.com
pmp-owner@pwg.org on 11/18/98 04:27:13 PM
Please respond to pmp-owner@pwg.org
To: pmp@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 list=
ed
Option 2, it has any advantage over Option 3. In fact our Area Director=
s
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 diffi=
cult
to move the Printer MIB to Draft in the future.
Again so everyone understands, I am requesting a vote for Option 1, Opt=
ion
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@lexmark.com Lexington, KY 40550
Phone: (606) 232-5150 Fax: (606) 232-6740
=