Hi Ron, Tuesday (6 November 2001)
Below are my responses to Dave Harrington's comments preceded by 'ira:'.
Separately, we should review and disposition all the errors and warnings
in the extensive 'smilint' comments on Printer MIB v2 that I posted
yesterday - this will take a little while.
There's an Internet-Drafts blackout in two weeks, due to the IETF
plenary in December, so we should be realistic about making that
deadline or just proceeding as fast as we can with edits.
Cheers,
- Ira McDonald
imcdonald@crt.xerox.com
906-494-2434 (work until later this week)
608-257-0466 (home/work in Madison, WI next week)
------------------------------------------------------------------------
The Working Group has review your comments and is sending the
following response. Unfortunately, many of your comments are
issues relating to the original Printer MIB (RFC 1759) and changes
cannot be made that affect interoperability.
Our responses below are preceded by "WG.."
<original message>...
David [dbh@enterasys.com]
Sent: Monday, October 29, 2001 3:32 PM
To: Bert Wijnen (E-mail); 'Ron.Bergman@Hitachi-hkis.com'
Subject: Print MIB 09
Hi,
comments on printmib 09
I didn't run this through a compiler to check syntax.
0) The overuse of TCs makes it way more difficult to work with this mib
than it needs to be. The single-use TCs should be eliminated.
WG.. The addition of the TCs was a decision by the Working Group
to allow these values to be imported into other MIBs. The
Finisher MIB presently uses some of these TCs and most others
are used in private MIBs.
ira: (We could ask Harry Lewis if IBM could bear to have most of the
'private' TCs made back into simple objects? - it would in fact not hurt
Xerox - because we already had private equivalent TCs for all of them)
My copy of -07- is truncated at prtChannelInformation, so I've reviewed
everything beyond that point afresh.
1) line 2644 "with" should be "which"
*** I cannot locate this !!! HELP???
ira: (I can't find it either - in the '.txt' or in the 'mstrip'
extracted '.mib' file - we need some more context or a quote to find
Dave's reference)
2) prtChannelInformation concerns me. It is a constructed octet string.
This type of constructed string is an invitation to vendors to use it
to pass proprietary information, which somewhat defeats the goal of
standardization.
WG.. We have actually defined very specific formats for this
object. Pages 116 and 117 provide very explicit details
regarding the encoding rules for this object. Also, the
PrtChannelTypeTC (pages 36 to 45) provides specific rules
for this object far each channel type.
ira: Agree - suggest changing your second line above to:
object. Pages 116 and 117 define machine-parseable details
3) prtInterpreterTable has an empty description clause. The description
is contained in comments instead. I believe it is considered
appropriate to put the description in the description clause. Some
tools strip the comments away, and the mib becomes much less useful
if the descriptions are in the comments. An example would be a
management application that imports description clauses and generates
help screens from them. Machine parsing won't recognize that the
comments contain the description.
WG.. This will be corrected in the next draft.
4) prtInterpreterIndex - could this be tightened up so the values are
guaranteed to be persistent across reboots?
WG.. This description is identical to RFC 1759. The exact reason
for this wording has been lost in time but it basically allows
a major upgrade to the functionality of the printer, either
through a firmware or a hardware upgrade, which essentially
creates a new printer. In practice this seldom occurs.
ira: we should correct the weak wording in all six affected
table index objects ...
prtLocalizationIndex
prtOutputIndex
prtMarkerColorantIndex
prtMediaPathIndex
prtInterpreterIndex
prtConsoleDisplayBufferIndex
for example, current description of 'prtInterpreterIndex':
"A unique value for each PDL or control language for which there
exists an interpreter or emulator in the printer. The value is
used to identify this interpreter. Although these values may
change due to a major reconfiguration of the device (e.g. the
addition of new interpreters to the printer), values are
expected to remain stable across successive printer power
cycles."
should change the last lines to:
addition of new interpreters to the printer), values SHOULD
remain stable across successive printer power cycles."
5) prtInterpreterFeedAddressability and other objects have no defined
ranges.
WG.. Do ranges make sense here?
ira: All integer MIB objects must have ranges, per SMIv2 (RFC 2578).
Regression loss - Gary Gocek discovered before with a MIB compiler.
My apologies Ron - the following edits will take a while
(I deskchecked the entire MIB - the following list is accurate).
We revise ALL of the many deficient objects which currently say:
SYNTAX Integer32 -- with no range specified
change
SYNTAX Integer32 (0..2147483647)
for the following two objects:
prtConsoleOnTime
prtConsoleOffTime
or
SYNTAX Integer32 (2..2147483647)
for the following one object:
prtMarkerColorantTonality
or
SYNTAX Integer32 (-1..2147483647)
for the following one object:
prtAlertGroupIndex
or
SYNTAX Integer32 (-3..2147483647)
for the following four objects:
prtInputCurrentLevel
prtInputNextIndex
prtOutputRemainingCapacity
prtMarkerSuppliesLevel
or
SYNTAX Integer32 (-1..65535)
for the following two objects:
prtInputDefaultIndex
prtOutputDefaultIndex
or
SYNTAX Integer32 (0..65535)
for the following two objects:
prtChannelCurrentJobCntlLangIndex
prtChannelDefaultPageDescLangIndex
or change all other affected objects (most) to:
SYNTAX Integer32 (-2..2147483647)
6) prtInterpreterDefaultCharSetIn and prtInterpreterDefaultCharSetOut -
define 2 as the DEFVAL?
WG.. The DEFVAL clause will be added and the text modified. The
CodedCharSet (TC) will also be modified to add "unknown(2)".
7) prtConsoleLightTable has an empty description.
WG.. This will be corrected in the next draft.
8) prtConsoleOnTime/OffTime - this may be a standard practice in
printers. It seems to me that it might be simpler to have one object
for on/off and another for blink rate, rather than requiring that both
of these objects be retrieved to determine that the light is off or on.
Couldn't this be done with an enumeration on/off/blinking plus a blink
rate? Why are these read-write? Do you anticipate an external
application adjusting the blink rate of a light, or turning the lights
on/off? If an external application was to read the values, how would
they be used? Are these values likely to change faster than network
latency allows the values to be retrieved? Are blink rates likely to
vary for a given light?
WG.. This model is from RFC 1759 and must be maintained for
compatabilty. We agree that the model is clumsy. The objects
are read-write to allow a remote application to either enable
or disable the lamps. In almost all implementations these are
read-only objects. Some implementations may use blinking vs
continuous on to indicate if the problem is critical or non-
critical. In this case, the remote app could look for this
state to determine the criticality of the condition. Although
this information more likely obtained from the alert table. In
all known implementations, the blinking rates do not vary.
9) Comments that "Implementation of every object in this group is
mandatory." may not be a good idea because the compliance clauses may
change at some point, and it might be ambiguous which took precedence.
Using the compliance clauses should eliminate the need to include such
comments.
WG.. All statements that define if the group is mandatory or
optional will be removed in the next draft. The compliance
clauses will provide the only definition.
10) prtAlertTable has an empty description
WG.. This will be corrected in the next draft.
11) Various table entry definitions do not describe the entry, but only
that a row may exist for each device of type printer.
It would generally be better to include meaningful information in the
descriptions, such as row persistence or what a row represents. This
can be helpful in the future as objects get added or deprecated to
ensure that the meaning of the row isn't changed inadvertently.
WG.. ?
ira: I suggest that I work with Ron and Ray Casterline to write
better DESCRIPTION clauses for some/all of 'xxxEntry' objects.
This will take a while.
12) I have concerns about the prtAlertTable. There are ways to help
the application avoid re-reading the entire table after a change.
RMON uses a timefilter; other tables use various mechanisms to record
the number of deletes done, or the last time the table was changed, and
so on. This table could benefit from some of these techniques.
WG.. The objects prtGeneralConfigurationChanges,
prtAlertCriticalEvents, and prtAlertAllEvents provide a global
view of the table. Also, hrDeviceStatus, hrPrinterStatus, and
hrPrinterDetectedErrorState are used by a management app to
determine if a problem exits that require examination of the
table.
ira: Out of our hands - we really cannot start adding more objects to
Printer MIB v2 five years after the first implementations.
13) The reliability of information from the prtAlerttable concerns me.
The resetting index could make it easy to overlook that a reset
occurred, and to ignore the current #1 in favor of the #1 I already
retreived before an undetected reset. It might be more appropriate to
use a non-resetting (persistent across reboots) TestAndIncrement to
generate the indexes here, or to use an RMON timefilter in the index.
WG.. This is very implementation dependent. On low cost printers
it can be very expensive to add non-volatile memory to support
this requirement. Most high end printers do have the necessary
memory and do not reset the index during a reboot. Note that
the alert table architecture is from RFC 1759 and must be
maintained to achieve interoperability.
ira: Out of our hands - we cannot start revising syntax or adding
objects to the 'prtAlertTable' - it has been shipping in printers
for six years.
14) prtAlertTrainingLevel - There is still the style problem of
over-using TCs. It makes it very difficult to really understand the
syntax of an object when you have to go elsewhere to lookup a TC to
see what the syntax is. Use of TCs is very appropriate when the same
behavior is repeated for multiple objects, and you want to define the
convention only once. But when only one object in the mib is defined
using that convention, it is better to define the syntax in the object
itself. Just to review the document, I kept two computers displaying
the document, one to keep track of where I was in the review, and
another to keep jumping around in the document looking up TCs. This
was mentioned in the original reviews by both me and Bert. It is bad
practice!!!!
WG.. We agree. When the enums were moved to TCs this issue was
considered. Only those enums were moved that were to be used
in the Finisher MIB or were requested for Private MIBs.
ira: (See point (0) above - how about collapsing all/most of the
single-use TCs back into the objects themselves, unless they
appear in the IMPORT section of Finisher MIB??)
15) prtAlertGroupIndex -
"An index of the row within the principle table in the
group identified by prtAlertGroup that represents the sub-unit
of the printer that caused this alert."
- huh??? What's a principle table? Again the overuse of TCs also
made this difficult because you couldn't see what the possible
enumerations were for the values that would have made it clearer. When
the pointers get complex, it is imperative that the text be clear and
easy to read, not buried away in some distant TCs.
WG.. ?
ira: Agree - we should change the first lines of the DESCRIPTION to:
"The low-order index of the row within the table identified
by prtAlertGroup that represents the sub-unit of the
printer that caused this alert, or (-1) if not applicable.
16) prtAlertTime - Given the issues I raised with the alert table,
making the AlertTime optional seems silly.
WG.. This also is identical to RFC 1759 and must maintained for
compatibility.
ira: Jurgen Schoenwaelder specifically requested that we correct
this object to the original (RFC 1759) OPTIONAL, because
to change it (as we had done earlier) was an illegal change
to a published MODULE-COMPLIANCE macro with an assigned OID.
17) printerV1Alert - Bert, you worked on the coexistence rules.
Is this the way traps should be handled in mibs?
WG.. This section was provided to the group by Steve Waldbusser.
ira: (Agree - this is Steve Waldbusser's work in RFC 1759).
18) The references section is rather different than normal. I'd prefer
to see it following the normal formats, and I'd like to see the
"unused" entries removed.
WG.. This section will be edited and the "unused" entries removed.
ira: (Ron - see section 10 'References' of SNMPv3 Arch (RFC 2571),
which Dave Harrington wrote, for what he wants as 'normal')
my $.02
dbh
David Harrington
Director, Network Management Architecture
Enterasys Networks, Inc.
dbh@enterasys.com
This archive was generated by hypermail 2b29 : Tue Nov 06 2001 - 14:27:34 EST