[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: printermib - problems other than compliances
Mike, I have not yet checked the new revision, and I won't get to
it untill tomorrow at the earliest.
Some quick comments on your issues below:
1. I don't think we have consensus between the MIB reviewers
yet on that issue. If we could drive to consensus on that
quickly, then I am willint to push for that consensus.
I agree that we need to change the copyright statement
somewhat. Not sure if it should be the full copy-right,
the rmon example I used when we got to the IESG statement
on these copy-right statements and that was not acceptable.
But let me bring this to the IESG, cause someone already
complained formally to IANA that the IANA ifType MIB
does not have a copyright statement, so we need to fix that
anyway. We can deal with this when the stuff goes to RFC
Editor and IANA.
2. Is a not. If they do a new rev, we will bring it up again.
If not, RFC-Editor will fix it.
3. I think this is cause by the fact that this was already in
RFC1759. Now... it is fair to ask to maybe change something
here, since they make so many (sort of forbidden) changes
anyway. But I don't feel we need to push on this.
4. Mmmm.. my latest email understanding with them was that they
were (for the most part) going to do away with the Type1/2/3
differentiation of TCs. I also had hoped they would have
taken your comment into consideration. Their text about the
violation of the rule was applicable in an earlier version
where they had just renamed and not deprected the old one.
Once we told them, they re-introduced the old one as
deprecated, and so they could have removed the "violates"
text.
5. Some 3 or 4 months ago I did go through all those changes
in very much detail (took me 2 days). And if we were to
take our rules to the "letter of the law" you are correct
and we should not accept them. We have made exceptions in
the past. We have exceptions aka:
- this is a clarification
- this is a bug fix
- this is what everyone implemented
And so what I did when I reported this all to them is to
point out what I thought about the "violation", if I thought
it would be trouble, or if it would be kind of acceptable
and so on. They also guaranteed me that all the participants
(so basically all the major implementers of this MIB) agree
on the changes. So what can we do. Let them do a complete
new MIB which nobody implements, or let them get away with
the things they feel are OK and are accepted by everyone.
Note that they DO RECYCLE at PS.
Juergen had suggested back then that they should add comment
lines as to where they sort of violated the rules and to
describe how and why they did so. SO that reviewers could
easily see it and so the during a Last Call it would be clear
that we're (the're) not sneaking somthing in under the covers.
So with that, I know that Juergen and Dave Harrington have looked
at this MIB several times... Can people react on the above.
Mike.... feel free to post your concerns to the authors of the
MIB (it may become time-consuming, you are warned) and copy me pls.
So they can answer your questions and try to address your concerns.
Maybe better is to try and get some consensus here as to which
topics really hurt and so that we focus on those and not on some
minor details.
Again, I do appreciate your miticulous (spelling?) review and
checking of things.
Thanks,
Bert
> -----Original Message-----
> From: C. M. Heard [mailto:heard@pobox.com]
> Sent: donderdag 13 februari 2003 8:23
> To: Mreview (E-mail)
> Subject: RE: printermib - problems other than compliances
>
>
> On Tue, 11 Feb 2003, Wijnen, Bert (Bert) wrote:
> > A new revission 14 has come out (or will today).
> >
> > draft-ietf-printmib-mib-info-14.txt (PS)
> >
> > Also a new rev for finishing mib will come out tiday.
> >
> > draft-ietf-printmib-finishing-15.txt (Informational)
> >
> > When they do, I think I am ready to approve them.
> > If anyone wants to take a quick look and warn me if they
> > still see any serious concerns, then pls do so.
>
> I just looked at <draft-ietf-printmib-mib-info-14.txt>.
> The list of problems is smaller, but not small enough
> for me to support having it on the standards-track. If
> it goes forward to IETF last call in its present form,
> you may expect negative comments from me. I've attached
> a problem report below. The items on that report I
> consider it vital to fix are item 1 (IANA module issues)
> and 3 (MIB compilation error). Item 2 is a nit that
> the RFC Editor can take care of (but the authors could
> do so very easily). Items 4 and 5 really should be
> fixed (and I think leaving item 5 unfixed should disqualify
> the module for standards-track status), but I will
> pretend that I did not see them if items 1 and 2 are
> fixed before IETF last call.
>
> BTW, all of these items were on the first report I
> made on the -13 version, except that some of the
> specifics of my issues with the IANA-PRINTER-MIB
> module are different now.
>
> > I had originally intended to push back on the PS for the
> > Printer-MIB (first doc) and rather see it as informational.
> > But I did see more support for recycling at PS so probably
> > will go that way.
>
> Well, I still don't agree with letting all the illegal
> revisions go by, but it appears that I am overruled.
>
> On Tue, 11 Feb 2003, Juergen Schoenwaelder wrote:
> > While there are problems, I do not share your conclusion. There has
> > already quite some work gone into this document to improve
> it and what
> > really lacks here (and in other cases) is an _effective_ scheme of
> > active cooperation between MIB experts and technology experts.
> >
> > I know that this MIB is already implemented in lots of printers and
> > there are no real technical issues with the objects
> themself as far as
> > I can tell - most issues are SMI style issues and so on. I
> strongly
> > support to fix these issues as good as we can and with that
> in place,
> > I strongly support to keep this on the standards track.
>
> On Tue, 11 Feb 2003, Harrington, David wrote:
> > I concur with Juergen that lots of work has already been done
> > on this mib, and I would support it remaining on the standards
> > track.
> >
> > If the document is going to continue to be reviewed by the MIB
> > Doctors, I would like to see some ground rules for future
> > cooperation established to make reviews easier and more timely.
>
> Do you gentlemen support going forward for proposed standard
> even though the MIB module violates the SMI revision rules
> (i.e., with item 5 below left unfixed)?
>
> //cmh
>
> Problem report on <draft-ietf-printmib-mib-info-14.txt>
>
> 1.) The initial version of the IANA-PRINTER-MIB module
> is not prepared in the generally accepted manner.
> Specifically, the IANA-PRINTER-MIB module now in
> Section 5 either needs to go into an appendix with a
> note to the RFC Editor that it is to be removed upon
> ublication when the IANA-maintained module goes on-line
> (recommended), or else the section in which it resides
> needs to be clearly marked as non-normative (and
> preferably moved to an appendix). In either case
> there needs to be a normative reference to the URL
> of the actual IANA-maintained IANA-PRINTER-MIB module
> (similar to the one for [CHARMIB]) , since that one
> (not the "base version" that is not in the draft) is
> what is needed to make the scheme work. Finally,
> even if the initial version of IANA-PRINTER-MIB is
> published in a non-normative section or appendix,
> the following copyright notice
>
> Copyright (C) The Internet Society (year). This
> version of this MIB module is part of RFC xxxx;
> see the RFC itself for full legal notices.
>
> will be incorrect once IANA has made the first change
> to the module (since the changed module will no longer
> be the version published in RFC xxxx). That needs to
> be fixed. I strongly recommend that the module have a
> stand-alone copyright similar to the one in
> ftp://ftp.rfc-editor.org/in-notes/mibs/current.mibs/rmon.mib
> since that will work for all the IANA-modified versions
> whether or not the initial version appears in an
> RFC somewhere.
>
> These are serious errors, and in my opinion MUST be fixed.
>
> Note: similar complaints apply to
> draft-mcdonald-iana-charset-mib-02.txt
>
> 2.) There is a reference to [RFC2026] on
> the front page. That's a no-no, according
> to http://www.ietf.org/ID-nits.html
>
> 3.) smilint complains about an inaccessible object
> used in a notification:
>
> Printer-MIB:3703: [3] {notification-object-access} object
> `prtAlertIndex' of notification `printerV2Alert' must not be
> `not-accessible'
>
> prtAlertIndex OBJECT-TYPE
> -- NOTE: In RFC 1759, the range was not defined.
> SYNTAX Integer32 (1..2147483647)
> MAX-ACCESS not-accessible
> STATUS current
> DESCRIPTION
> [ ... ]
> ::= { prtAlertEntry 1 }
>
> [ ... ]
>
> printerV2Alert NOTIFICATION-TYPE
> OBJECTS { prtAlertIndex, prtAlertSeverityLevel, prtAlertGroup,
> prtAlertGroupIndex, prtAlertLocation, prtAlertCode }
> STATUS current
> DESCRIPTION
> "This trap is sent whenever a critical event is added to the
> prtAlertTable.
>
> NOTE: The prtAlertIndex object was redundantly included in the
> bindings of the 'printerV2Alert' notification in RFC
> 1759, even
> though the value exists in the instance qualifier of all the
> other bindings. This object has been retained to provide
> compatiblity with existing RFC 1759 implementaions."
> ::= { printerV2AlertPrefix 1 }
>
> In fairness, this was a problem inherited from RFC 1759, and
> there is no strictly legal way to fix it. Probably the least
> evil thing would be to raise the MAX-ACCESS of prtAlertIndex
> to read-only; if its presence in the OBJECTS list is needed
> for compatibility, then previous implementations must have
> been doing something like that anyway.
>
> In any case, this is a serious error, and in my opinion
> it MUST be fixed.
>
> 4.) I see lots of ASN.1 comments that say things that do not
> seem right. For instance:
>
> PrtMediaUnitTC ::= TEXTUAL-CONVENTION
> -- This is a type 1 enumeration. Replaces MediaUnit in RFC 1759.
> -- Even though it is formally not allowed to change TC
> names, the WG
> -- decided this name change was necessary to clearly indicate this
> -- TC is from the Printer MIB.
>
> STATUS current
> DESCRIPTION
> "Units of measure for media dimensions."
> SYNTAX INTEGER {
> tenThousandthsOfInches(3), -- .0001
> micrometers(4)
> }
>
> MediaUnit ::= TEXTUAL-CONVENTION
> -- Replaced by prtMediaUnitTC.
> STATUS deprecated
> DESCRIPTION
> "Units of measure for media dimensions."
> SYNTAX INTEGER {
> tenThousandthsOfInches(3), -- .0001
> micrometers(4)
> }
>
> There is actually nothing illegal with what has been
> done here, i.e., deprecating the old TC and defining
> a new one. As far as I can tell, since the new one
> has the same syntax & semantics as the old one, it can be
> legally substituted in a SYNTAX clause (if substituting
> a TC for a base type is legal, then surely one TC for
> another with same base type and semantics is OK too).
> So the comments PrtMediaUnitTC are not really
> correct and should be removed.
>
> 5.) On the other hand, many of the revisions that have
> been made clearly are not legal revisions under SMIv2
> rules. smidiff lists 112 questionable changes. Some of
> them may be OK, but many of the ones that I have checked
> are not; I have not checked them all. An smidiff
> report will be made available upon request.
>
>