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
April).
Cheers,
- 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
email: imcdonald@sharplabs.com
------------------------------------------------------------------------
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.
Resolution:
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
DESCRIPTION
"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)."
REFERENCE
"prtGeneralCurrentLocalization in IETF Printer MIB (RFC
1759/3805).
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
DESCRIPTION
"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."
REFERENCE
"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).
Resolution:
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
DESCRIPTION
"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."
REFERENCE
"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
DESCRIPTION
"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
include:
- 'lpr://foo.example.com/public-printer' (where 'public-
printer' is the LPR queue name portion)
and
- 'ipp://bar.example.com/printer/fox'
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://example.com:631/~smith/printer').
If this object is empty and 'ppmPortProtocolType' is
'chLPDServer(8)', the LPR queue name MUST default to 'LPR'."
REFERENCE
"IETF Line Printer Daemon Protocol (RFC 1179).
'lpr:' URL scheme in IANA-registered SLP Printer Schema at
http://www.iana.org/assignments/svrloc-templates/
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.
Resolution:
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
DESCRIPTION
"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."
REFERENCE
"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