Hi Ron and Harry, Monday (19 March 2001)
Below are my comments (by Ron's issue numbers) on the IETF feedback from
Bert Wijnen and Dave Harrington on the Printer MIB v2 (9 August 2000).
Cheers,
- Ira McDonald, consulting architect at Sharp and Xerox
High North Inc
DISCLAIMER - The opinions below are my own - they are NOT officially
approved by either Sharp or Xerox implementors or management.
------------------------------------------------------------------------
ISSUE 1 - Use of MIB and table names rather than RFCs
- I agree to the use of table names within MIBs (System and Interfaces
table in IETF MIB-II).
- I do NOT agree to update references, so that Interfaces table says
RFC 2863 (Interfaces Group MIB) which is an IETF Draft Standard and
does NOT update or obsolete IETF MIB-II (IETF Internet Standard status)
according to the latest RFC Index.
ISSUE 2 - Section 2.2.1.1 'International Considerations'
- I agree that the seven 'xxxDescription' objects with their 'charset'
controlled by the value of 'prtGeneralCurrentLocalization' SHOULD have
their SYNTAX (and their SEQUENCE clause) changed to a textual convention
that makes this explicit, for example "LocalizedDescriptionString".
- We have already changed this section to state that the other string
objects (about 25) SHOULD be UTF-8 (RFC 2279) - given the many shipping
implementations of Printer MIB v1 (RFC 1759) that use legacy character
sets in some of these objects, this is the best we can do and remain
backward compatible.
- The SNMPv3 WG rejected changing old 'DisplayString' objects in the
System group to 'SnmpAdminString' (UTF-8). Any such change in the
Printer MIB would be far worse and would NOT be a semantically
compatible change.
ISSUE 3 - Section 2.2.4 - rewording
- I agree with this change (as does Ron).
ISSUE 4 - 2.2.13.1 - rewording
- I agree with this change (as does Ron).
ISSUE 5 - Section 2.2.13.4 - changing 'must' to 'MUST'
- Fix the first 'must' be eliding the two sentences as follows:
(old)
"When the table is full and new alerts need to be added, old
alerts must be removed. An alert to be deleted should be chosen
using the following rules:"
(new)
"When the table is full and new alerts need to be added,
an old alert to be deleted should be chosen
using the following rules:"
- Fix the second and third 'must' as follows:
(old)
"In the event that a critical binary alert must be managed out of the
alert table; when space allows and the alert condition still exists,
the alert must be re-added to the alert table even if there was no
subsequent transition into the associated state."
(new)
"In the event that a critical binary alert has been deleted out of the
alert table; when space allows and the alert condition still exists,
the alert should be re-added to the alert table even if there was no
subsequent transition into the associated state."
ISSUE 6 - Section 2.4.1 'Registering Additional Enumerated Values'
- I agree we should restore the original text verbatim from RFC 1759.
The additional explanatory information in the latest Printer MIB v2
draft (9 August 2000) is ambiguous and susceptible to misinterpretation.
ISSUE 7 - Sections 3.4.x
- I believe we should DELETE sections 3.4, 3.4.1, 3.4.2, and 3.4.3
entirely. They were NOT present in RFC 1759. They are ambiguous and
are probably incorrect about usage of Host Resources MIB and MIB-II.
ISSUE 8 - 'CodedCharSet' textual convention - deleted text
- A normative reference to BCP 19 / RFC 2278 "IANA Charset Registration
Procedures" was added by Gary Gocek (at my request).
- The original text in RFC 1759 on character set usage (especially the
use of the BOM in Unicode/ISO-10646) was just plain WRONG - it was
deleted by Gary Gocek (at my request).
ISSUE 9 - 'PrtChannelStateTC' textual convention - ambiguity
- I agree that the DESCRIPTION is the same as in RFC 1759.
- But, it IS ambiguous and should be changed as follows:
(old)
"The state of this print job delivery channel. The value
determine whether control information and print data is allowed
through this channel."
(new)
"The state of this print job delivery channel. The value
determines whether print data is allowed
through this channel."
(This SHOULD have been a boolean 'TruthValue' in RFC 1759).
ISSUE 10 - 'PrtChannelTypeTC' textual convention - dubious value
- I agree with Dave Harrington and Ron Bergman - this IS and WAS a bad
idea, but we're stuck with it now (because it's shipped for six years).
ISSUE 11 - Enumeration types in ASN.1 comments, not DESCRIPTION
- Right - Steve Waldbusser did it this way in RFC 1759 - we decline to
make such an extensive editiorial change.
ISSUE 12 - Definition of TCs for most enumerated objects added
- I agree with Ron Bergman - we use many of these textual conventions in
the Finisher MIB and in various vendor extension MIBs - we NEED them.
ISSUE 13 - 'PrtOutputPageDeliveryOrientationTC' - localized differences
- I agree with Ron Bergman - Steve Waldbusser did this in RFC 1759.
ISSUE 14 - 'PrtConsoleDisableTC' - ambiguous new enumerations
- I agree with Dave Harrington - the new values are ambiguous and are
NOT backward compatible with RFC 1759.
- Are there implementations of these new values (Ron and Harry)?
ISSUE 15 - 'PrtAlertGroupTC' - ambiguous Type 1 or Type 2
- I agree with Ron Bergman - this enumeration was Type 1 in RFC 1759
and MUST remain Type 1 in Printer MIB v2 for semantic compatibility.
- Also the underlying object 'prtAlertGroup' states it is Type 1 in the
latest Printer MIB v2 (9 August 2000).
ISSUE 16 - 'PrtAlertCodeTC' - should have been multiple enums?
- I agree with Ron Bergman - no change - RFC 1759 did it this way and
Steve Waldbusser made that design choice - multiple, distinct SNMP traps
for different alerts would have been better and much more standard SNMP
usage - but that's not the way Steve Waldbusser did it in RFC 1759.
ISSUE 17 - 'prtGeneralEntry' - new columns - some MANDATORY
- See ISSUE 26 below.
- We're in trouble here - these columns CANNOT be moved to a separate
table that AUGMENTS 'prtGeneralTable' - implementations of Printer MIB
v2 have been shipping for over two years.
- We COULD change the MODULE-COMPLIANCE and OBJECT-GROUP macros to
define new compliance groups for these new objects.
- But they MUST stay in the 'prtGeneralTable' at their current OIDs.
ISSUE 18 - 'prtGeneralConfigChanges' - semantic changes?
- I agree with Ron Bergman - these are intended clarifications.
- I think we should say (added 'temporarily')
(new)
"...input tray is temporarily removed to load paper..."
ISSUE 19 - 'prtGeneralCurrentLocalization' - semantic changes?
- I agree with Ron Bergman - these are intended clarifications.
- I also think we should refer to the (proposed above) new textual
convention 'LocalizedDescriptionString'.
ISSUE 20 - 'prtGeneralReset' - semantic changes?
- I agree with Ron Bergman - these are intended clarifications.
ISSUE 21 - 'prtAlertCriticalEvents' and 'prtAlertAllEvents' - Counter32?
- I agree with Ron Bergman - this is the intended behavior.
- Also, these objects CANNOT have their datatype changed now.
- Further, it is LEGAL behavior, per section 7.1.6 of RFC 2578:
"Counters have no defined "initial" value, and thus, a single value of
a Counter has (in general) no information content. Discontinuities
in the monotonically increasing value normally occur at re-
initialization of the management system, and at other times as
specified in the description of an object-type using this ASN.1 type"
ISSUE 22 - 'prtCoverIndex' - ambiguous across reboots?
- I agree with Ron Bergman - this object is indeed ambiguous at reboot.
ISSUE 23 - 'prtCoverStatus' - semantic changes?
- I agree with Ron Bergman - 'door' was changed to 'cover' by Printer
MIB WG concensus agreement.
ISSUE 24 - 'prtLocalizationLanguage' and 'prtLocalizationCountry'
- I agree with Ron Bergman - should be changed BACK from 'DisplayString'
to original 'OCTET STRING'.
- However, note that ISO 639 and ISO 3166 require use of ISO 636:IRV
(US-ASCII) - see RFC 3066 "Tags for the Identification of Languages".
ISSUE 25 - 'prtStorageRefSequenceNumber', 'prtStorageRefIndex',
'prtDeviceRefSequenceNumber', and 'prtDeviceRefIndex' - ranges?
- I agree with Dave Harrington - ranges MUST be restored to original
RFC 1759 values (even if they really didn't make sense).
ISSUE 26 - 'prtInputEntry' - new columns
- See ISSUE 17 above.
- We're in trouble here - these columns CANNOT be moved to a separate
table that AUGMENTS 'prtInputTable' - implementations of Printer MIB
v2 have been shipping for over two years.
- We COULD change the MODULE-COMPLIANCE and OBJECT-GROUP macros to
define new compliance groups for these new objects.
- But they MUST stay in the 'prtInputTable' at their current OIDs.
ISSUE 27 - 'prtInputMediaDimFeedDirChosen - semantic changes?
- I agree with Ron Bergman - these are intended clarifications.
ISSUE 28 - 'prtInputMediaName' - semantic changes?
- I agree with Ron Bergman - these are intended clarifications.
ISSUE 29 - 'prtInputSerialNumber' - changed OCTET STRING size?
- I agree with Dave Harrington and Ron Bergman - this size SHOULD be
changed back to 32 octets (from 63) - but is this going to break some
shipping implementations?
ISSUE 30 - 'prtInputMediaType' - semantic changes?
- I agree with Ron Bergman - these are intended clarifications.
ISSUE 31 - 'prtInputMediaColor' - semantic changes?
- I agree with Ron Bergman - change 'such as' back to 'which are'.
- Although, the new IEEE/ISTO PWG Media Standard probably WILL have an
official registry for extensions to ISO 10175/10180 media colors, so
there is a namespace collision mechanism on the way.
ISSUE 32 - 'prtOutputMaxDimFeedDir', 'prtOutputMaxDimXFeedDir',
'prtOutputMinDimFeedDir', and 'prtOutputMinDimXFeedDir' - units
- I agree with Dave Harrington and Ron Bergman.
- This was (DimUnit) in RFC 1759 - it's an editorial error.
- It would be MUCH better to reference 'prtOutputDimUnit' object here.
ISSUE 33 - 'prtOutputMaxDimFeedDir' - semantic changes?
- I agree with Ron Bergman - huh? - there was no change to this object.
ISSUE 34 - 'prtOutputPageCollated' and 'prtOutputOffsetStacking'
- I agree with Ron Bergman - these are intended clarifications.
ISSUE 35 - 'prtMarkerLifeCount' - semantic changes?
- I agree with Ron Bergman - these are intended clarifications.
ISSUE 36 - 'prtMarkerSuppliesIndex' - semantic changes?
- I agree with Dave Harrington and Ron Bergman - 'printer' SHOULD be
restored.
(new)
"...successive printer power cycles..."
ISSUE 37 - 'prtMarkerSuppliesColorantIndex' - semantic changes?
- I agree with Ron Bergman - these are intended clarifications.
ISSUE 38 - 'prtMarkerColorantIndex' - semantic changes?
- I agree with Ron Bergman - the deleted text should be restored.
ISSUE 39 - 'prtMarkerColorantValue' - semantic changes?
- I agree with Ron Bergman - these are intended clarifications.
ISSUE 40 - 'prtMarkerColorantTonality'
- I agree with Ron Bergman - this is the way Steve Waldbusser did it in
RFC 1759 (without a range).
ISSUE 41 - Print Job Delivery Channel Group - semantic changes?
- I agree with Ron Bergman - these are intended clarifications.
ISSUE 42 - 'prtChannelIndex' - range was added - semantic changes?
- I agree with Dave Harrington and Ron Bergman - this range SHOULD be
deleted (for compatibility with RFC 1759).
ISSUE 43 - 'prtChannelCurrentJobCntlLangIndex' and
'prtChannelDefaultPageDescLangIndex' - range change - zero added
- I agree with Ron Bergman - the old (DESCRIPTION) range in RFC 1759
was a BUG.
ISSUE 44 - 'prtConsoleLightIndex' - range change
- I agree with Ron Bergman - was Steve Waldbusser's BUG in RFC 1759.
- SNMP has always prohibited index values of zero in tables.
ISSUE 45 - 'prtConsoleOnTime' and 'prtConsoleOffTime' - semantic change?
- I agree with Ron Bergman - these are intended clarifications.
ISSUE 46 - 'prtAlertIndex' - range change and access change?
- I agree with Dave Harrington - access MUST be restored to 'read-write'
- I agree with Dave Harrington and Ron Bergman - this range SHOULD be
deleted (for compatibility with RFC 1759).
ISSUE 47 - 'prtAlertLocation' - semantic change?
- I agree with Ron Bergman - these are intended clarifications.
ISSUE 48 - 'printerV1Alert' - OBJECT-TYPE or OBJECT-IDENTITY?
- I agree with Ron Bergman - was this way in RFC 1759.
- It's also CORRECT usage - this is NOT the definition of the SMIv1
translated TRAP-TYPE, just the base arc for translation.
ISSUE 49 - 'prtGeneralGroup', 'prtChannelGroup', 'prtAlertTableGroup'
- I agree with Dave Harrington - we need new OBJECT-GROUP macros for
these new objects and we need new (additional) MODULE-COMPLIANCE macros
for the conformance packages - and NONE of the new objects can be made
MANDATORY for conformance to the MIB (an error in the current draft).
ISSUE 50 - 'prtAlertTimeGroup' - should be deprecated
- I agree with Dave Harrington and Ron Bergman.
ISSUE 51 - References out-of-date
- I agree with Ron Bergman - consequences of waiting in queue for years.
- References SHOULD be updated.
ISSUE 52 - MIB boilerplate and Changes Appendix
- I agree with Bert, Dave, and Ron - we SHOULD add the boilerplate.
- But the Changes are already present in section 4 "Differences from
Previous Version" ('Previous Version' should be changed to 'RFC 1759').
ISSUE 53 - need NOTIFICATION-GROUP for 'printerV2Alert'
- need 4-digit years in LAST-UPDATED and REVISION clauses
- I agree with Bert, Dave, and Ron - we SHOULD fix these.
ISSUE 54 - need new MODULE-COMPLIANCE macros and better documentation
- I agree with Bert, Dave, and Ron - we SHOULD fix these.
ISSUE 55 - need new MODULE-COMPLIANCE macros
- I agree with Bert, Dave, and Ron - we SHOULD fix these.
ISSUE 56 - who's going to do all this work? (Ron Bergman's issue)
- That remains to be seen - Gary Gocek MAY be willing to help with the
edits - Gary no longer works for Xerox or in the printer industry - I've
forwarded all of this traffic to Gary at his new email address.
- The Printer MIB WG was officially disbanded several years ago by our
IETF Applications Area Director (ironically, due to no activity).
- We need to get concensus on these proposed edits on the Printer MIB
mailing list (pmp at pwg.org) and move forward quickly.
- NO change that will break ANY of the many shipping implementations of
Printer MIB v2 is acceptable or will be approved on the mailing list.
------------------------------------------------------------------------
-----Original Message-----
From: RonBergman at aol.com [mailto:RonBergman at aol.com]
Sent: Friday, March 16, 2001 6:41 PM
To: pmp at pwg.org
Subject: PMP> Response to Printer MIB Comments
Here is my response to the comments from Bert Wijnen and
Dave Harrington. Everyone who is still interested in
updating the Printer MIB should read these and comment.
I have added issue numbers to the original comments to
make it easier to discuss via email. My proposed
responses are highlighted in yellow. This should make
it easier to follow. There is some discussion back and
forth between Bert and Dave, so keep it in mind as you
read.
These responses need a through review by others in the
PWG. If necessary, I will setup a conference call to
close specific issues. It would be best if all can be
accomplished via email.
Happy reading ;-)
Ron Bergman
Hitachi Koki Imaging Solutions