[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: FW: Who owns/has change control over Printer/Finisher MIBs an d IA NA r elated MIBs



Inline

> -----Original Message-----
> From: Thomas Narten [mailto:narten@us.ibm.com]
> Sent: maandag 10 februari 2003 19:10
> To: Wijnen, Bert (Bert)
> Cc: Scott Bradner; iesg@ietf.org
> Subject: Re: FW: Who owns/has change control over 
>                  Printer/Finisher MIBs and IANA r elated MIBs 
> 
> 
> > The problem is that these guys used to be a IETF WG, and
> > they went off on their own and have all sorts of (closed
> > to non-members) meetings where they do the work.
> 
> Not necessarily an issue, so long as the output (i.e., the document)
> is reasonable. 
> 
Well... that took a lot of effort. I am now reviewing yet
another revision ... that I hope will be the final one.

> And if this is the de facto standard, and we don't have another MIB to
> recommend that folks implement instead, and we don'think its horribly
> broken, isn't PS the right signal?
> 
Several people (also other MIB doctors) have been telling me
that over the last few days. So I give in and will go for PS.

> > The other document draft-ietf-printmib-finishing-14.txt
> > has again similar stuff to RFC2707 on which we put an IESG note.
> > I feel for a similar IESG note for this one.
> 
> 2707 has at least two messages:
> 
>    This MIB module uses an unconventional scheme for modeling
>    management
>    information (on top of the SNMP model) which is unique to this MIB.
>    The IESG recommends against using this document as an 
>    example for the design of future MIBs.
> 
> This is a clear technical statement.
> 
And the Finisher MIB (which they want as Informational by the way)
has a similar approach (at least with a few of their objects).

>    The "Printer Working Group" industry consortium is not an IETF
>    working group, and the IETF does not recognize the Printer Working
>    Group as a standards-setting body.  This document is being 
>    published
>    solely to provide information to the Internet community regarding a
>    MIB that might be deployed in the marketplace. Publication of this
>    document as an RFC is not an endorsement of this MIB.
> 
> This is a bit odder, but seems OK for an info document and one that we
> aren't really all that happy with (which ties into the previous
> technical point).
> 
> I guess you are saying that the first comment applies to this document
> too. That might be grounds for making it info rather than PS. But I
> guess that also depends on how strongly the MIB community feels about
> that.
> 
Note that there are 2 documents. The first one Printer-MIB is for PS.
That one does not need the warnings. If they made the changes we as
MIB doctors requested then it is OK.

The 2nd doc has the issues. And I certainly want the first statement
on it. Probably also the second. I am discussiong that with PWG people
(which are also the authors).

Bert
> Thomas
>