[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: printermib - compliance statement(s)
Well, the RFC1759 originated from the PRINT MIB WG as PS.
When documents are ready for advancement, we do not require
that a WG does the work. We do of course go through the
proper reviews and through a (4 week in this case) IETF
Last Call.
When they asked for review considering DS, we saw the
additions that were being made and convinced them to go
and recycle at PS. They keep coming back with answers
and requested changes as a result of our review.
So I feel that we (IETF) still do have change control
albeit not via an active WG.
I'd be willing to give up control and make it informational
if we think that would be best. I can tell that if we had
started out that way, that my reviews would be far less
strict... and so all sorts of things might have slipped
through.
We'd also have to check with APPS ADs, cause the original
RFC1759 was done in APPS area I believe.
Do many of us believe we better make these informational
and hand over change control to PWG?
The RFC2707 was really bad... did you check it?
I don't think we would encourage such sort of a MIB at all
in the IETF, that is why it is Informational and why it
has a serious IESG NOTE on it.
In fact I am thinking about a similar IESG NOTE for
draft-ietf-printmib-finishing-14.txt
which also uses such strange contructs of TCs.
Thanks,
Bert
> -----Original Message-----
> From: C. M. Heard [mailto:heard@pobox.com]
> Sent: woensdag 5 februari 2003 7:58
> To: Mreview (E-mail)
> Subject: RE: printermib - compliance statement(s)
>
>
> On Tue, 4 Feb 2003, Wijnen, Bert (Bert) wrote:
> > I am in fact pushing back somewhat...
> > - but we have had a lot of iterations with this MIB already
> > - it is HUGE and takes a serious context switch when you
> > have to review again
>
> I downloaded the draft and I see what you mean :-(
>
> > - Review (since they have so many changes here and thre
> > and everywhere) takes a day at least
>
> And that's if you are a speed demon. It would take me
> weeks (yes, plural) unless I could audit just the changes.
>
> > - they claim that all printer vendors and the (commercial)
> > mgmt apps for these MIBs are pretty much in sync on this
> > and really want to go this way. it is an org outside
> > IETF these days, even though the docs seem to indicate
> > that it is the IETF printmib WG (has not been active
> > within IETF for many years).
>
> I did a little digging and it seems that the organization
> doing this work is called the Printer Working Group or PWG
> ("PWG IEEE/ISTO Printer Working Group" according to the
> ORGANIZATION clause of the MIB module). It's apparently
> the same organization that is responsible for RFC 2707,
> The Job Monitoring MIB; at least, the web site
> http://www.pwg.org/ and the name PWG are the same.
>
> I notice that the document draft-ietf-printmib-mib-info-13.txt
> says it is targeted at the standards track, and your previous
> e-mail said the doc was recycling at PS. My question is,
> why is the document on the standards track at all if the
> IETF has ceded change control? RFC 2707 is informational
> and has an IESG Note that disclaims IETF responsibility for
> the document. Is seems to me that this document ought to
> get the same treatment as RFC 2707. Then you (and the MIB
> doctors) can advise, but the PWG will be free to ignore that
> advice, and the IETF can then wash its hands of responsibility.
> On the other hand, if it is going to be on the IETF standards
> track, then (to paraphrase something Marshall Rose once said)
> the MIB revisions ought to be done by the IETF's rules.
>
> //cmh
>
> P.S. I found RFC 2707 by looking through all RFCs to see if
> there were any references to the Printer-MIB in any published
> RFCs. The only ones were 2707 and 1759 (which was the previous
> incarnation of the MIB).
>
>