[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
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.