PMP Mail Archive: Re: PMP> Printer MIB - what to do?

Re: PMP> Printer MIB - what to do?

Harry Lewis (harryl@us.ibm.com)
Thu, 19 Nov 1998 18:09:08 -0500

Ron's observation is right on...

>Why not just state that this is the new definition for this object whi=
ch
>replaces
(or extends - HRL)
>the definition in RFC 1514.

and his proposal is superior to mine...

>...simply add the new bits...exactly like any other enum...without
>having to resort to an new object.

The point is... in October 1997 we had these options on the table... wh=
y are we
still here?

I agree with Ron. Ship the Printer MIB to the IETF - AS IS - and forget=
about
advancement to "Draft" standard.

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

pmp-owner@pwg.org on 11/19/98 03:36:50 PM
Please respond to pmp-owner@pwg.org
To: Harry Lewis/Boulder/IBM@ibmus
cc: pmp@pwg.org
Subject: Re: PMP> Printer MIB - what to do?

Harry has brought up some very good issues and I sure that many of us
believe that the new Printer MIB is never going to happen.

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 publish=
ed
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 RF=
C.

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 151=
4.

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 oth=
er
enum. Harry's proposal for a "mirror object" is another alternative, b=
ut
I beleive that the extensibility mechanisms are all ready in place with=
out
having to resort to an new object.

We need to have an RFC soon. A Printer MIB as a Draft Standard can com=
e
later.

Ron Bergman
Dataproducts Corp.

On Thu, 19 Nov 1998, Harry Lewis wrote:

> Please - no one take offense - I'm not criticizing anyone in particul=
ar (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. Empir=
e
> >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 stand=
s.
>
> Now, in order to get the few minor interoperability improvements reco=
gnized as
> standards track, after sitting on the burner for (2 years!?)... we en=
d up with
> the option...
>
> >1. Re-align the new Printer MIB with RFC1514 and submit the new Prin=
ter
> >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 t=
his 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 arch=
itected
> 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 w=
ords
bring
> "control" and management of hrPrinterDetectedErrorState into the Prin=
ter MIB
> where it so obviously belongs. I did not propose deprecating the exis=
ting
> definitions from the HR MIB, just simply making any and all future ex=
tensions
> 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 h=
ad 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 Print=
er
> 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 li=
sted
> Option 2, it has any advantage over Option 3. In fact our Area Direct=
ors
> 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 t=
he
> 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 Dra=
ft
> Standard is extremely important then you should vote for Option 3. Fo=
r
> several reasons if the working group chooses Option 1, it will be dif=
ficult
> to move the Printer MIB to Draft in the future.
>
> Again so everyone understands, I am requesting a vote for Option 1, O=
ption
> 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
>
>
>
>
>

=