I really don't see the necessity to hold the current draft until it can
also be advance to a "Draft Standard". A new RFC is not required to
advance a Standards Track Document. If the current document is published
now it can later be advanced to "Draft" when the HR MIB is finally
published. In the mean time we can start implementing to an offical RFC.
I also don't understand why the changes to hrPrinterDetectedErrorState
must be removed. Any RFC can update or modify an older RFC, you don't
have to revise the older document. Why not just state that this is the
new definition for this object which replaces the definition in RFC 1514.
About a year ago I suggested that we treat hrPrinterDetectedErrorState as
any other enum and simply add the new bits. We should be able to
continually add new bits via a registration method exactly like any other
enum. Harry's proposal for a "mirror object" is another alternative, but
I beleive that the extensibility mechanisms are all ready in place without
having to resort to an new object.
We need to have an RFC soon. A Printer MIB as a Draft Standard can come
later.
Ron Bergman
Dataproducts Corp.
On Thu, 19 Nov 1998, Harry Lewis wrote:
> 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@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 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@lexmark.com Lexington, KY 40550
> Phone: (606) 232-5150 Fax: (606) 232-6740
>
>
>
>
>