Subject: RE: PMP> Comments on Printer Port Monitor MIB 1.0 working draft d ated March 21, 2005

From: "McDonald, Ira" <[email-masked]>
Date: Tue, 22 Mar 2005 14:39:06 -0800

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: [email-masked]

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]On Behalf Of Bergman,
Ron
Sent: Tuesday, March 22, 2005 2:05 PM
To: Adams, Charles A; [email-masked]
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: [email-masked] [mailto:[email-masked]]On Behalf Of Adams,
Charles A
Sent: Tuesday, March 22, 2005 8:46 AM
To: [email-masked]'
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
[email-masked]

---

From: "McDonald, Ira" <[email-masked]>
Date: Fri, 25 Mar 2005 10:30:32 -0800

Hi Bill,
 
Because the MS tools use the value of 'hrDeviceIndex' to find and display
status for each SINGLE port (one print protocol bound to one network or 
local hardware interface).
 
There's nothing wrong with having more than one INSTANCE of the Printer
MIB (with different high-order 'hrDeviceIndex') displayed on a network
system
for this purpose.
 
Otherwise (using a single common 'hrDeviceIndex') if any port protocol is
down, they'll all appear to be down.  The MS tools do NOT inquire of the
Channel table in the Printer MIB for port-by-port status.  And Mike Fenelon
has indicated that that's not changing any time soon.
 
Please don't shoot the messenger - this design worked great for outboard
external network adaptors - it's admittedly cumbersome for a network printer
itself.
 
Cheers,
- Ira

-----Original Message-----
From: Bergman, Ron [mailto:[email-masked]]
Sent: Friday, March 25, 2005 12:36 PM
To: McDonald, Ira; Adams, Charles A; [email-masked]
Subject: RE: PMP> Comments on Printer Port Monitor MIB 1.0 working draft
dated March 21, 2005

Ira,
 
I don't understand your response.  If this is true, then this is not
hrDeviceIndex as used by the printer and must be clearly indicated
as such and should not be called hrDeviceIndex.
 
Why does the index for the table not satisfy this requirement?
 
    Ron
  _____  

From: McDonald, Ira [mailto:[email-masked]]
Sent: Fri 3/25/2005 8:14 AM
To: Bergman, Ron; McDonald, Ira; Adams, Charles A; [email-masked]
Subject: RE: PMP> Comments on Printer Port Monitor MIB 1.0 working draft
dated March 21, 2005

Hi Ron,

Going all the way back to the first Microsoft draft and ever since,
it's clear that the MS "port" entry has to have a separate device
index for each port, because the 'hr...' status objects have to be
separate for EACH port. 

Remember the main MS model is NOT an embedded printer.  It's either
an external network adaptor or a spooler.  In both of these cases,
only ONE protocol is being exposed fore each "port".

This isn't a new restriction.

In the case of an external network adaptor, each "port" is literally
a different direct-connect printer.

Cheers,
- Ira

-----Original Message-----
From: Bergman, Ron [ mailto:[email-masked]
<mailto:[email-masked]> ]
Sent: Thursday, March 24, 2005 3:03 PM
To: McDonald, Ira; Adams, Charles A; [email-masked]
Subject: RE: PMP> Comments on Printer Port Monitor MIB 1.0 working draft
dated March 21, 2005

Ira,

Regarding your comment:

I do not recall ever hearing this.  It certainly is not clear from
the MIB text (see below) that this is the case.  If this is true
then it is not really hrDeviceIndex that is indicated but is just
ppmPortIndex.

Also, for the printers I work with there will be a minimum of 10
ports reported.  If IPP is enable, there will be a minimum of 15.
The maximum number will be 192.

        Ron

From the MIB:
ppmPortHrDeviceIndex OBJECT-TYPE
    SYNTAX      Integer32 (0..2147483647)
    MAX-ACCESS  read-only
    STATUS      current
    DESCRIPTION
"The value of 'hrDeviceIndex' in the IETF Host Resources MIB
(RFC 1514/2790), to be used for status queries for this port if
the value of 'ppmPortSnmpStatusQueryEnabled' is 'true'.

If this object is zero, then monitoring applications MUST NOT
attempt status queries for this port in the IETF Host Resources
MIB (RFC 1514/2790) and/or IETF Printer MIB (RFC 1759/3805)."
    REFERENCE
"hrDeviceStatus, hrPrinterStatus, hrPrinterDetectedErrorState i
n IETF Host Resources MIB (RFC 1514/2790).
prtChannelStatus in IETF Printer MIB (RFC 1759/3805)."
    DEFVAL      { 0 }                   -- no host device index
    ::= { ppmPortEntry 7 }

---

From: "Bergman, Ron" <[email-masked]>
Date: Tue, 29 Mar 2005 11:35:07 -0800

Thursday (3/31) 10:00 AM PST is OK for me.
 
    Ron

-----Original Message-----
From: Harry Lewis [mailto:[email-masked]]
Sent: Tuesday, March 29, 2005 11:14 AM
To: McDonald, Ira
Cc: Dennis Carney; 'Ivan Pavicevic'; [email-masked]; Bergman, Ron
Subject: RE: PMP> Comments on Printer Port Monitor MIB 1.0 working draft d ated March 21, 2005

There are enough differing viewpoints that a conference call may be in order to help sort this topic and clear up some of the misunderstandings. 
If a core group can agree on a time I will distribute the dial-in information. 
This doesn't necessarily have to be a repeating time slot. I'd like to get this ironed out before Tokyo. 
I will start out suggesting Thursday 3/31 10AM PST, 1PM EST (directly following the PWG Steering Committee call). Please indicate the possibility of your attending or suggest a different time. 
---------------------------------------------- 
Harry Lewis 
IBM STSM
Chairman - IEEE-ISTO Printer Working Group
http://www.pwg.org
IBM Printing Systems 
http://www.ibm.com/printers
303-924-5337
---------------------------------------------- 

"McDonald, Ira" <[email-masked]> 
Sent by: [email-masked] 

03/28/2005 02:01 PM 

To
"'Ivan Pavicevic'" <[email-masked]>, "Bergman, Ron" <[email-masked]>, Dennis Carney/Boulder/IBM@IBMUS, [email-masked], "McDonald, Ira" <[email-masked]> 

cc

Subject
RE: PMP> Comments on Printer Port Monitor MIB 1.0 working draft d        ated March 21, 2005

Hi,

Please - will people stop just saying 'in the MIB'.  Only Ivan has
spoken precisely enough in this thread (by always saying either 
'HR MIB' or 'Printer MIB' explicitly) to make his meaning clear.

And since you all three (Ivan, Ron, Dennis) just quietly _disagreed_
because of obscurity about what's a 'port' and what's 'static' in a
configuration, let me try once more.

[Per Ivan]
- Status in Longhorn TcpMon comes ONLY from Host Resources MIB
- Ports in the 'ppmPortTable' should NOT be deleted when
 the software/hardware status of a 'port' changes 
 - because the Longhorn TcpMon tool will only read the
   'ppmPortTable' _once_ (to find 'hrDeviceIndex' values)
- Configuration (but NOT status) in Longhorn TcpMon comes from
 Printer MIB
- All 'ports' that have the same 'hrDeviceIndex' will always have
 the same displayed status in TcpMon

Ron and Dennis - please let's not waste time on discussing how
the Printer MIB was meant to be used.  The Printer MIB isn't even
in the logic path for 'port' status in Longhorn's TcpMon.

Cheers,
- Ira

-----Original Message-----
From: Ivan Pavicevic [mailto:[email-masked]]
Sent: Monday, March 28, 2005 3:04 PM
To: Bergman, Ron; Dennis Carney; [email-masked]; McDonald, Ira
Subject: RE: PMP> Comments on Printer Port Monitor MIB 1.0 working draft
dated March 21, 2005

TcpMon will use the hrDeviceIndex to query for the printer status from Host
Resource MIB and to query for the printer configuration from the Printer MIB
(support for new features in Longhorn OS). 
From the TcpMon perspective, if hrDeviceIndex is reused in the multiport
device, queries described above will hit the same MIB object for different
ports. If this is acceptable for the printer device then we are fine with
this. Note that TcpMon will get data from the Port MIB during printer
installation to allow the user to make a choice between different ports. If
the printer removes the port entry from the table in the Port MIB due to the
functioning failure, the port won't be listed as an option to be picked by
the user. Hence I agree that the Port MIB should reflect configuration of
the ports, not the status.

Thanks,
Ivan

From: [email-masked] [mailto:[email-masked]] On Behalf Of Bergman, Ron
Sent: Monday, March 28, 2005 10:22 AM
To: Dennis Carney; [email-masked]; McDonald, Ira
Subject: RE: PMP> Comments on Printer Port Monitor MIB 1.0 working draft
dated March 21, 2005

Dennis' comments seem to echo the concern I voiced last week.  And I agree
with Dennis that a unique
value of hrDeviceIndex is not needed for each service.  I have also reviewed
the document and do not find
any text that indicates the value of hrDeviceIndex cannot be the same for
all services.

hrDeviceIndex references a "device" and should not be overloaded to also
indicate a port within a device.
Although I cannot speak for all printers, in the implementations I am
familiar with, it is very unlikely that
only an LPR port or a raw socket port is "down".  If a port is disabled (per
the configuration), as Dennis
stated, it will not be present in the MIB.  The MIB should be essentially
"Static" and only be modified by
a configuration change.

   Ron
-----Original Message-----
From: [email-masked] [mailto:[email-masked]]On Behalf Of Dennis Carney
Sent: Monday, March 28, 2005 9:10 AM
To: [email-masked]; McDonald, Ira
Subject: RE: PMP> Comments on Printer Port Monitor MIB 1.0 working draft d
ated March 21, 2005
Hi Ira,

I would have said that if specifically the LPR port is down for whatever
reason, it wouldn't be listed in the MIB. This opinion was my first
(intuitive) reaction, but it also does not seem to be wrong based on a quick
reading of the document.

Is there a feeling among the people who have been working the most on this
MIB that it is supposed to be "static"--have essentially hard-coded rows and
values for a given printer model? If so, this should probably be made clear
in the document.

Dennis Carney
IBM Printing Systems
"McDonald, Ira" <[email-masked]>

"McDonald, Ira" <[email-masked]> 
03/27/2005 09:30 AM
To
Dennis Carney/Boulder/IBM@IBMUS, "McDonald, Ira" <[email-masked]>,
[email-masked]

cc

Subject
RE: PMP> Comments on Printer Port Monitor MIB 1.0 working draft d ated March
21, 2005

Hi Dennis,

OK - I probably picked an unwise example.

If one software channel (LPR) is down, because the thread
crashed (or the operator took down the LPR service), then
EVERY software channel is going to show as down, on your
network printer (remember MS does NOT read Printer MIB).

You're conflating all hardware status with the software
status of channels/interpreters.

But you're welcome to decide this is 'normal' behavior.

Cheers,
- Ira

-----Original Message-----
From: Dennis Carney [mailto:[email-masked]]
Sent: Saturday, March 26, 2005 4:37 PM
To: McDonald, Ira; [email-masked]
Subject: RE: PMP> Comments on Printer Port Monitor MIB 1.0 working draft d
ated March 21, 2005

Hi Ira,

Ira wrote:
>If a vendor implements a single 'hrDeviceIndex' value for all ports (i.e.,
channels) 
>on the "same" printer, then if ANY port is 'down' in 'hrDeviceStatus' they
will ALL 
>be shown 'down' in the MS tools. That's not acceptable behaviour.

To me, that *does* seem like acceptable behavior (or if you'd prefer,
"behaviour"--is that your proximity to Canada showing? :-).

If I am a single network printer advertising both an LPR port and a RAW
port, if my one input tray is out of paper, then *both* ports *should* be in
an "out of paper" state in the host resources MIB.

If instead I want to differentiate between the two (I really can't think of
many good reasons to do this on a network printer), I can do this using two
different indices into the hr MIB. But I would have guessed that 99% of
network printers would simply have all advertised ports (correctly, IMHO)
point to the same hr MIB entry.

Dennis Carney
IBM Printing Systems
"McDonald, Ira" <[email-masked]>

"McDonald, Ira" <[email-masked]> 
03/26/2005 09:12 AM

To
Dennis Carney/Boulder/IBM@IBMUS, [email-masked]

cc
"Adams, Charles A" <[email-masked]>, "'Bergman, Ron'"
<[email-masked]>, [email-masked]

Subject
RE: PMP> Comments on Printer Port Monitor MIB 1.0 working draft d ated March
21, 2005

Hi Dennis,

The Introduction and Background were recently added, for boilerplate
reasons.
They are not authoritative and in fact have not been reviewed.

Microsoft is NOT using the Printer MIB for status at all in Longhorn (per
Mike
Fenelon). The 'hrDeviceTable' and 'hrPrinterTable' in the Host Resources MIB

are the only status that will be displayed by Longhorn for printer ports.

If a vendor implements a single 'hrDeviceIndex' value for all ports (i.e.,
channels) 
on the "same" printer, then if ANY port is 'down' in 'hrDeviceStatus' they
will ALL 
be shown 'down' in the MS tools. That's not acceptable behaviour.

Cheers,
- Ira

-----Original Message-----
From: Dennis Carney [mailto:[email-masked]]
Sent: Friday, March 25, 2005 2:43 PM
To: [email-masked]
Cc: Adams, Charles A; McDonald, Ira; 'Bergman, Ron';
[email-masked]
Subject: RE: PMP> Comments on Printer Port Monitor MIB 1.0 working draft d
ated March 21, 2005

Ira, My reading of the "Introduction" and the "Background" of the document
seems to make it clear that the main MS model *IS* an embedded printer.

Mike Fenelon, is it really true that your port monitor makes it such that
each port *has to* have a different ppmPortHrDeviceIndex? If a network
printer implemented this MIB and advertised both an LPR and a RAW port,
would you really have a problem if both ports had a ppmPortHrDeviceIndex of
1?

Dennis
"McDonald, Ira" <[email-masked]>

"McDonald, Ira" <[email-masked]> 
Sent by: [email-masked] 
03/25/2005 09:14 AMTo
"'Bergman, Ron'" <[email-masked]>, "McDonald, Ira"
<[email-masked]>, "Adams, Charles A"
<[email-masked]>, [email-masked]
cc
Subject
RE: PMP> Comments on Printer Port Monitor MIB 1.0 working draft d ated March
21, 2005

Hi Ron,

Cheers,
- Ira

-----Original Message-----
From: Bergman, Ron [mailto:[email-masked]]
Sent: Thursday, March 24, 2005 3:03 PM
To: McDonald, Ira; Adams, Charles A; [email-masked]
Subject: RE: PMP> Comments on Printer Port Monitor MIB 1.0 working draft
dated March 21, 2005

Ira,

Regarding your comment:

Ron

From the MIB: