PMP Mail Archive: PMP> 3 Issues for Port MIB (6 April 2005)

PMP Mail Archive: PMP> 3 Issues for Port MIB (6 April 2005)

PMP> 3 Issues for Port MIB (6 April 2005)

From: McDonald, Ira (
Date: Wed Apr 06 2005 - 15:06:33 EDT

  • Next message: Bergman, Ron: "PMP> Topics for Port Monitor MIB Meeting"

    Hi folks, Wednesday (6 April 2005)

    This note records several issues raised by Bert Wijnen (IETF Ops & Mgmt
    Area Director) in email shortly before we began the Last Call of the PWG
    Printer Port Monitor MIB.

    This note also _proposes_ resolutions for each of the Last Call issues,
    including revised MIB objects. Additional revisions to the body of the
    PPM MIB document are also required, but specific text is not proposed.

    PWG members and other interested parties should review these resolutions
    and criticize them as needed. We will attempt to endorse resolutions of
    these issues in some subsequent Last Call telecon (probably in later

    - Ira (co-editor of Printer Port Monitor MIB)

    Ira McDonald (Musician / Software Architect)
    Blue Roof Music / High North Inc
    PO Box 221 Grand Marais, MI 49839
    phone: +1-906-494-2434

    PPM-3-20050406 - Usage of 'PpmLocalizedStringTC' vs 'SnmpAdminString'

        Question: I wonder why you do not use SnmpAdminString (RFC3411)
        instead of defining own TC? [Bert Wijnen - 20050310 email]

        Discussion: This design choice was made by copying Printer MIB v2,
        for both 'ppmPortName' and 'ppmPortDescription' text string objects.
        But 'ppmPortDescription' (analogous to the Printer MIB v2 localized
        description objects) was deleted in draft v0.20 of the PPM MIB.

        3a) Add 'SnmpAdminString' (RFC 3411) to IMPORTS clause.

        3b) Delete 'PpmLocalizedStringTC' textual convention.

        3c) Change DESCRIPTION of 'ppmGeneralNaturalLanguage' and
            'ppmPortName' to refer to 'SnmpAdminString' (RFC 3411).

        3d) Change SYNTAX of 'ppmPortName' to 'SnmpAdminString'.

        3e) Change section 6 'Internationalization Considerations'
            to refer to 'SnmpAdminString' (RFC 3411).

        3f) Add RFC 3411 to section 8 'Normative References'.

    ppmGeneralNaturalLanguage OBJECT-TYPE
        SYNTAX SnmpAdminString (SIZE (0..63))
        MAX-ACCESS read-only
        STATUS current
            "The natural language tag (RFC 3066), specified in US-ASCII, for
            all localized text string objects defined in this MIB (syntax of
            'SnmpAdminString'), or the empty string if not specified. For
            example, 'fr-CH' (French as written in Switzerland).

            Compatibility Note: At the time of publication of this MIB,
            language tags are restricted to US-ASCII. In order to support
            possible future evolution of languages tags (in a successor to
            RFC 3066) to allow non-ASCII characters, this object has been
            defined with a syntax of UTF-8 (RFC 3629).

            This natural language tag is necessary for support of correct
            glyph selection for text display, for support of text-to-
            speech, for support of correct sorting of text values, etc.

            If this object is empty, then the natural language for all
            localized text string objects in this MIB MUST default to
            'en-US' (US English)."
            "prtGeneralCurrentLocalization in IETF Printer MIB (RFC
            jobNaturalLanguageTag in IETF Job Monitoring MIB (RFC 2707)."
        DEFVAL { ''H } -- no natural language tag
        ::= { ppmGeneral 1 }

    ppmPortName OBJECT-TYPE
        SYNTAX SnmpAdminString (SIZE (0..127))
        MAX-ACCESS read-only
        STATUS current
            "A user friendly name for this port, in the locale specified by
            'ppmGeneralNaturalLanguage'. May be used to facilitate user
            selection of a port on a multi-port network product.

            The value of this object SHOULD be unique (across all ports on
            this network product) and descriptive (e.g., 'ParallelPort1').

            The syntax of this text string object is UTF-8 (RFC 3629), in
            order to support names that cannot be represented in US-ASCII."
            "prtGeneralPrinterName in IETF Printer MIB v2 (RFC 3805)."
        DEFVAL { ''H } -- port name not specified
        ::= { ppmPortEntry 2 }


    PPM-4-20050406 - Usage of 'DisplayString' syntax (US NVT ASCII)

        Question: I am also worried somewhat by the use of all the
        DisplaySTring types (US NVT ASCII). Does not seem to be of current
        time anymore and certainly does not seem to be future proof to me.
        [Bert Wijnen - 20050310 email]

        Discussion: 'ppmPortSnmpCommunityName' should be changed to
        'OCTET STRING' (see PPM-5-20050406 below).
        'ppmPortIEEE1284DeviceId' is constrained by IEEE to ASCII, but might
        change to ISO 10646/Unicode in the future.
        'ppmPortServiceNameOrURI' is a mistake and should have been UTF-8,
        to directly support IRI (RFC 3987, January 2005).

        4a) Change SYNTAX of 'ppmPortIEEE1284DeviceId' to 'SnmpAdminString'
            and add warning about current ASCII restriction per IEEE 1284 to
            DESCRIPTION clause.

        4b) Change SYNTAX of 'ppmPortServiceNameOrURI' to 'SnmpAdminString'
            and add explicit reference to RFC 3987 to DESCRIPTION clause.

    ppmPortIEEE1284DeviceId OBJECT-TYPE
        SYNTAX SnmpAdminString (SIZE (0..255))
        MAX-ACCESS read-only
        STATUS current
            "The IEEE 1284 device ID for this port, a set of capabilities
            (keys and values) specified in the US-ASCII charset and the
            format 'key1: value {, value }; ... keyN: value {,value };',
            as follows:

            (a) SPACE (0x20), TAB (0x09), VTAB (0x0B), CR (0x0D), NL
              (0x0A), and FF (0x0C) are allowed, but ignored when parsing
            (b) other control characters (less than 0x20) MUST NOT be used
            (c) COLON (0x3A), COMMA (0x2C), and SEMICOLON (0x3B) are
              delimiters and MUST NOT be included in any key or value
            (d) each key MUST be separated from value(s) using COLON (0x3A)
            (e) multiple values MUST BE separated using COMMA (0x2C)
            (f) each capability MUST BE delimited using SEMICOLON (0x3B)
            (g) all ports MUST include the following capabilities
                - MANUFACTURER (or abbreviation MFG)
                - MODEL (or abbreviation MDL)
            (h) all ports MAY include the following capabilities
                - COMMAND SET (or abbreviation CMD)
                - COMMENT
                - ACTIVE COMMAND SET

            For example (actually all on one line of text):

                MANUFACTURER:ACME Manufacturing;
                COMMAND SET:PCL,PJL,PS,XHTML-Print+xml;
                MODEL:LaserBeam 9;
                COMMENT:Anything you like;
                ACTIVE COMMAND SET:PCL;

            The value of this object MUST exactly match the IEEE 1284-2000
            Device ID string, except that the length field MUST NOT be
            specified. The value MUST be assigned by the Printer vendor
            and MUST NOT be localized by the Print Service.

            Compatibility Note: At the time of publication of this MIB,
            IEEE device IDs are restricted to US-ASCII. In order to support
            possible future evolution of IEEE device IDs (in a successor to
            IEEE 1284-2000) to allow non-ASCII characters, this object has
            been defined with a syntax of UTF-8 (RFC 3629).

            If this object is empty, then the value of 'ppmPortProtocolType'
            SHOULD be used to load a generic driver."
            "Section 7.6 of IEEE 1284-2000."
        DEFVAL { ''H } -- no IEEE 1284 device ID
        ::= { ppmPortEntry 6 }

    ppmPortServiceNameOrURI OBJECT-TYPE
        SYNTAX SnmpAdminString (SIZE (0..255))
        MAX-ACCESS read-only
        STATUS current
            "The service name or URI for this port, specified in UTF-8 (RFC
            3629), in the locale specified by 'ppmGeneralNaturalLanguage'.
            The service name is typically a 'queue name'.

            Use Models: When this MIB is implemented in a network printer
            or implemented in an external network adaptor (with one or more
            locally-attached printers), the service name is sufficient
            (because all of the addressable ports are at the same network
            host name). However, when this MIB is implemented in a network
            spooler, the full service URI is necessary to address each of
            the downstream network printers.

            Compatibility Note: At the time of publication of this MIB,
            the Microsoft tools do not support LPR queue names longer than
            32 characters. Network administrators SHOULD NOT assign longer
            LPR queue names, to prevent interworking problems.

            Compatibility Note: At the time of publication of this MIB,
            IETF URI Generic Syntax (RFC 3986) requires that all non-ASCII
            characters be percent-encoded, while IETF Internationalized
            Resource Identifiers (RFC 3987) permits native UTF-8 resource
            identifiers and supplies mappings to and from standard URI.
            In order to support current use of IRI and possible future
            evolution of URI (in a successor to RFC 3986) to allow non-ASCII
            characters, this object has been defined with a syntax of UTF-8
            (RFC 3629).

            Examples of well-formed service URI for print protocols

                 - 'lpr://' (where 'public-
                    printer' is the LPR queue name portion)
                 - 'ipp://'

            If this object is non-empty, then it SHOULD NOT conflict with
            the default (IANA-registered) or explicit transport target port
            specified in 'ppmPortProtocolTargetPort'. In case of conflict,
            the URI value in 'ppmPortServiceNameOrURI' is authoritative
            (e.g., 'ipp://').

            If this object is empty and 'ppmPortProtocolType' is
            'chLPDServer(8)', the LPR queue name MUST default to 'LPR'."
            "IETF Line Printer Daemon Protocol (RFC 1179).
            'lpr:' URL scheme in IANA-registered SLP Printer Schema at
            IPP/1.1: IPP URL Scheme (RFC 3510).
            printer-uri-supported in IPP/1.1 Model and Semantics (RFC 2911).
            printer-uri in LDAP Printer Schema (RFC 3712)."
        DEFVAL { ''H } -- no service name or URI
        ::= { ppmPortEntry 10 }


    PPM-5-20050406 - Usage and syntax of 'ppmPortSnmpCommunityName'

        Question: This 'ppmPortSnmpCommunityName' object seems pretty
        INSECURE, plus, a valid SNMP communityName is allowed to contain
        non-ASCII characters. So I find this very questionable stuff.
        [Bert Wijnen - 20050310 email]

        The CommunityString (in SNMPv1 and v2c) is intended as a (albeit)
        weak secret, and not to be a human-consumable string. Such
        has been the case since the origins of SNMP, and it has ALWAYS been
        an OCTET STRING. So any agent (and manager) is supposed to be
        able to handle any octet value (also those that are NOT in the
        NVT ASCII set). And by using a DisplayString in your MIB module,
        you seem to be telling compliant implementations that they
        would not be compliant with your MIB module.
        [Bert Wijnen - 20050314 email]

        Discussion: The use of 'DisplayString' was an editorial mistake.
        This object models current implementations of external network print
        adapters that expose 'MIB views' in SNMPv1 by using a separate SNMP
        read community name for each port (which typically corresponds to a
        different value of 'ppmPortHrDeviceIndex'). Given freely available
        packet sniffers that decode SNMP packets, no security is offered by
        SNMPv1 read community names anyway.

        5a) Keep the 'ppmPortSnmpCommunityName' object in the PPM MIB.

        5b) Change the SYNTAX to 'OCTET STRING (SIZE (0..255))' (see above).

        5c) Change the DESCRIPTION to explain the use model and to warn that
            community names do not provide any SNMP security at all.

        5d) Change section 2.4.2 'External Network Adapter'
            to describe this simplistic model of SNMPv1 'MIB views'.

    ppmPortSnmpCommunityName OBJECT-TYPE
        SYNTAX OCTET STRING (SIZE (0..255))
        MAX-ACCESS read-only
        STATUS current
            "The SNMP read community name, an opaque binary string, for
            access to status information in IETF Host Resources MIB (RFC
            1514/2790) and IETF Printer MIB (RFC 1759/3805) for this port
            via the value of 'ppmPortHrDeviceIndex' (i.e., a 'MIB view' of
            these two MIBs).

            Security Warning: Due to the widespread availability of free
            'packet sniffers' (network traffic snooping applications) and
            SNMP packet decoders, SNMP community names no longer offers even
            weak security. This object SHOULD only be used to support 'MIB
            views'. Implementations SHOULD use SNMPv3 security to protect
            network resources from unauthorized monitoring.

            If this object is empty, then the SNMP read community name for
            this port (if any) SHOULD default to 'public' in US-ASCII."
            "snmpCommunityName in IETF SNMP Community MIB (RFC 3584)."
        DEFVAL { ''H } -- no SNMP read community name
        ::= { ppmPortEntry 8 }


    This archive was generated by hypermail 2b29 : Wed Apr 06 2005 - 15:07:04 EDT