PMP Mail Archive: RE: PMP> Response to Printer MIB Comments

PMP Mail Archive: RE: PMP> Response to Printer MIB Comments

RE: PMP> Response to Printer MIB Comments

From: McDonald, Ira (imcdonald@sharplabs.com)
Date: Tue Mar 20 2001 - 01:06:23 EST

  • Next message: RonBergman@aol.com: "PMP> Response To AD Comments on Printer MIB"

    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@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@aol.com [mailto:RonBergman@aol.com]
    Sent: Friday, March 16, 2001 6:41 PM
    To: pmp@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



    This archive was generated by hypermail 2b29 : Tue Mar 20 2001 - 01:08:43 EST