Hi Chuck,
My replies are inline below - thanks for your instant comments!
Caveat - my replies are my opinions - the eventual Printer MIB
Project WG concensus may vary - although hard rules about how
SNMP agents behave and how MIBs behave can't be bent for our
convenience.
Cheers,
- Ira
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
-----Original Message-----
From: pmp-owner@pwg.org [mailto:pmp-owner@pwg.org]On Behalf Of Bergman,
Ron
Sent: Tuesday, March 22, 2005 2:05 PM
To: Adams, Charles A; pmp@pwg.org
Subject: RE: PMP> Comments on Printer Port Monitor MIB 1.0 working draft
dated March 21, 2005
Hi Chuck,
Glad to see you are still monitoring our activity!
See my responses in-line.
Ron
-----Original Message-----
From: pmp-owner@pwg.org [mailto:pmp-owner@pwg.org]On Behalf Of Adams,
Charles A
Sent: Tuesday, March 22, 2005 8:46 AM
To: 'pmp@pwg.org'
Subject: PMP> Comments on Printer Port Monitor MIB 1.0 working draft
dated March 21, 2005
1. ppmGeneralNaturalLanguage
Why does this MIB define the following object?
It seems like localization information will reside in multiple places,
prtGeneralCurrentLocalization/prtLocalizationTable and also
ppmGeneralNaturalLanguage.
Is it because this MIB needs to be independent of the printer MIB? Is it
expected this MIB may be implemented on a device that does not implement
the printer MIB?
<Ron> I'll let Ira handle this one.
<ira> Yes, this MIB has to free-stand without Printer MIB. Also, the
Printer MIB language tags are broken - they're fixed at alpha-2 country
and alpha-2 language, which makes them unable to access the vast
majority of current alpha-3 ISO language codes (and the future alpha-4
and alpha-5 script and variant tags in the new parts of ISO 639).
And IETF best practices says we should have a proper RFC 3066 style
complete and extensible language tag - so we do in this MIB.
</ira>
2. ppmPortHrDeviceIndex - This seems to imply an hrDeviceTable entry is
needed for each port on the system. Is this the expected behavior?
Or is this just the hrDeviceIndex of the printer?
Or is the the hrDeviceIndex for the network card?
<Ron> This is primarly for servers with many attached printers. For the
network attached printer, this value should always be 1.
<ira> For the Microsoft tool (TCPMon), EACH port (channel) has to
have a separate 'hrDeviceIndex' - this is different than typical
Printer MIB implementations, but it's a Microsoft tool limitation.
Note that Microsoft TCPMon _only_ supports LPR and Raw ports (no
other protocol is supported or contemplated according to co-editor
Mike Fenelon from the Microsoft Longhorn printing team), so this
only means two 'hrDeviceIndex' values at most (for each printer).
</ira>
3. ppmPortSnmpCommunityName - This MIB is going to expose the SNMP read
community name? If the read community name is not already known by a
client, how can this value be read in the first place?
<Ron> Per Microsoft, some printers use a different community name as a
method to differentiate services in SNMP. For most printers this
value will be the known community name.
<ira> Bert Wijnen (IETF Ops & Mgmt Area Director and "MIB Doctor")
already complained about this - but because Ethernet packet sniffers
that decode SNMP headers are free and widely available on the Web,
there is _no_ security in SNMP community strings any more. This read
community string is used by external network adaptors as a poor man's
"MIB view" mechanism - a dumb idea, but apparently widely deployed.
</ira>
4. Seems like returning this value over SNMPv1 is a security hole that
should not be so
glaring. This value should be defined to always return a “NULL” string
unless the transfer is done using SNMP encryption and authentication.
<Ron> Good point. If the community names are all read-only, the risk
is minimal.
<ira> Nope - the version of SNMP reading an object MUST NOT change
the reported value - if you don't have authorization to read the
object, then the SNMP Agent MUST report an error, not just silently
hide the string value.
</ira>
5. Rather than defining ppmPortSnmpCommunityName it might be useful to
specify
ppmPortSnmpCommunityName as r/w. The MS applications that want to change the
community
name would then have a standard way to do this.
<Ron> Yes, but this does increase the security risk.
<ira> Nope - our Microsoft co-editors are (sensibly) strongly opposed
to putting any 'read-write' objects in this MIB. The MS applications
will NEVER have the authorization to change these community strings.
That must be done out-of-band (usually not even with SNMP at all).
</ira>
Chuck Adams
West Coast Program Management Team/SEBU/XOG
Phone (503) 685-2589 Internal 8-875-2589
Charles.A.Adams@office.xerox.com
This archive was generated by hypermail 2b29 : Tue Mar 22 2005 - 17:43:25 EST