First off, I hope you don't mind if I post this reply to your private mail
to the general PMP list. I can't think of a better way to get discussion
rolling, if discussion happens at all.
The reason you have not seen a response from Underscore for these questions
(attached below) is because:
- We do not develop printers, nor (at the moment) Printer MIB agents inside
printers. As such, our opinions in these areas are not worth all that
much, quite honestly.
- We currently have no interest in those items; we are primarily focused
on STATUS and far less on CONFIGURATION in our product initiatives at
the moment. As you have witnessed, dealing with issues on STATUS alone
has already consumed our available time.
However, now that you have pressed us for a response, let me say this...
After dealing with RFC1759 for close to three years now, we are unsure as
to whether your rather complex configuration environment (ie, multiple
printers sharing common devices) can be reasonably handled via RFC1759.
It just seems too complex to us. (Your--and others'--mileage may vary.)
It could very well be that when the dust settles, the PWG may have to
make some sweeping statements regarding the "reasonable" application of
RFC1759 (and its successor) to a printer environment.
For example, note the many, many concerns regarding the use of the
Host Resources MIB. Many folks absolutely DESPISE this mechanism,
however, how else can one "manage" multiple printers via a single
SNMP agent implementation?
One solution to this problem is to say, simply, that you CAN'T; that is,
deprecate the entire HR MIB mechanism and allow only a single instance
of a printer within an agent. In doing so, Bill Wagner's longstanding
problems surrounding the Interfaces group could be immediately solved.
(That is, all objects describing "interfaces" would be implicitly owned
by the printer, and not the host on which the agent is running, etc.)
I know this is not exactly what you were looking for, but there it is.
Perhaps others can be of more help to EFI in this area.
...jay
----------------------------------------------------------------------
-- JK Martin | Email: jkm@underscore.com --
-- Underscore, Inc. | Voice: (603) 889-7000 --
-- 41C Sagamore Park Road | Fax: (603) 889-2699 --
-- Hudson, NH 03015-4915 | Web: http://www.underscore.com --
----------------------------------------------------------------------
----- Begin Included Message -----
From: "Gail Songer" <Gail.Songer@eng.efi.com>
Date: Sat, 8 Mar 1997 16:19:47 -0800
To: harryl@vnet.ibm.com, jkm@underscore.com
Mime-Version: 1.0
Harry, Jay,
A couple of days ago, my friend Eugene posted a question regarding prtStorage
and prtDevice. We had hoped to see some comments/suggestions on what the
"correct" implementation should be, since two companies did them differently,
but we have had no takers on the list. Since the two of you usually have
opinions on everything, I was hoping a private appeal would elicit some sort of
comment(even if it is to just go away :) If you really don't know, (or don't
care) do you remember who initially proposed this? I would be happy to bug
him.
Was this inconsistency noticed during the review?
Thanks a bunch!
Gail
On Mar 6, 5:51pm, Eugene Chen wrote:
> Subject: PMP> Questions about RFC1759
> Hi, All :
>
> I have two questions about the meaning of the prtStorageRefTable and
> prtDeviceRefTable in RFC1759.
>
> 1. Question for prtStorageRefTable :
>
> I have the following hypothetical situation in which one disk is shared
> between 2 printers.
>
> The prtStorageRefTable is described as having an entry for each storage
device
> in the
> hrStorage table.
> In my example, I have a hrStorageTable with 4 entries (4 harddisks : A, B, C
> and D), and Disk A and B belongs to printer 1, Disk C belongs to printer 2,
> and Disk D belongs to both printers.
> And suppose printer 1 has a deviceIndex of 3 and printer 2 has a
> deviceIndex of 7.
>
> hrStorageTable :
> hrStorageIndex
> 1 disk A (printer1 : deviceIndex=3)
> 2 disk B (printer1 : deviceIndex=3)
> 3 disk C (printer2 : deviceIndex=7)
> 4 disk D (printer1 & 2 : deviceIndex=3 & 7)
>
> So I will have 5 (?) entries in prtStorageRefTable.
> Then my prtStorageRefTable will be :
>
> prtStorageRefTable :
> hrStorageIndex prtStorageRefSeqNumber prtStorageRefIndex
> 1 1 3
> 2 1 3
> 3 1 7
> 4 1 3 (?)
> 4 2 7 (?)
>
> Is the above implementation correct ? Then it violates the description
> under prtStorageRefEntry :
> "This table will have an entry for each entry in
> the host MIB storage table that represents storage associated
> with a printer managed by this agent."
> Because we have 2 entries under one hrStorageTable entry (disk D).
>
> I looked at the Interop mib walk test results. Vendor 2 has 2 storage
devices
> and they use prtStorageRefIndex.1.1 and prtStorageIndex.2.2. Vendor 4 has 4
> devices,
> with prtStorageRefIndex.1.1, .2.1, .3.1 and .4.1. Which of these is more
> correct?
>
>
>
> 2. Question for prtDeviceRefTable :
>
> This case is almost exactly the same as the previous example, the parallel
> port, and the processor are shared between two printers.
>
> This table will have an entry for each hrDeviceTable entry in the hrDevice
> table,
> for example, I have a hrDeviceTable with 7 entries :
>
> hrDeviceTable :
> hrDeviceIndex
> 1 disk A (printer1 : deviceIndex=3)
> 2 disk B (printer2 : deviceIndex=7)
> 3 printer1
> 4 disk C (printer2 : deviceIndex=7)
> 5 Processor (printer1 & 2 : deviceIndex=3 & 7)
> 6 parallel port (printer1 & 2 : deviceIndex=3 & 7)
> 7 printer2
>
> So I will have 9 (?) entries in prtDeviceRefTable.
> Then my prtStorageRefTable will be :
>
> prtDeviceRefTable :
> hrDeviceIndex prtDeviceRefSeqNumber prtDeviceRefIndex
> 1 1 3
> 2 1 7
> 3 1 3 (point to printer1
itself ?)
> 4 1 7
> 5 1 3 (?)
> 5 2 7 (?)
> 6 1 3 (?)
> 6 2 7 (?)
> 7 1 7 (point to printer2
itself ?)
>
> Is the above implementation correct ? Then it violates the description
> under prtDeviceRefEntry :
> Because we have 2 entries under one hrDeviceTable entry (Processor and
> parallel port).
>
> All responses are appreciated. Thank you.
>
> Eugene Chen
>
>
>
> **** The following is taken directly from rfc1759 for reference. ****
> -- The System Resources Tables
>
> -- The Printer MIB makes use of the Host MIB to
> -- define system resources by referencing the storage
> -- and device groups of the print group. In order to
> -- determine, amongst multiple printers serviced by
> -- one agent, which printer owns a particular
> -- resource, the prtStorageRef and prtDeviceRef tables
> -- associate particular storage and device entries to
> -- printers.
>
> prtStorageRefTable OBJECT-TYPE
> SYNTAX SEQUENCE OF PrtStorageRefEntry
> MAX-ACCESS not-accessible
> STATUS current
> DESCRIPTION
> ""
> ::= { prtGeneral 2 }
>
> prtStorageRefEntry OBJECT-TYPE
> SYNTAX PrtStorageRefEntry
> MAX-ACCESS not-accessible
> STATUS current
> DESCRIPTION
> "This table will have an entry for each entry in
> the host MIB storage table that represents storage associated
> with a printer managed by this agent."
> INDEX { hrStorageIndex, prtStorageRefSeqNumber }
>
> PrtStorageRefEntry ::= SEQUENCE {
> prtStorageRefSeqNumber Integer32,
> prtStorageRefIndex Integer32
> }
>
> prtStorageRefSeqNumber OBJECT-TYPE
> SYNTAX Integer32 (0..65535)
> MAX-ACCESS not-accessible
> STATUS current
> DESCRIPTION
> "This value will be unique amongst all entries with a common
> value of hrStorageIndex.
>
> This object allows a storage entry to point to the multiple
> printer devices with which it is associated."
> ::= { prtStorageRefEntry 1 }
>
> prtStorageRefIndex OBJECT-TYPE
> SYNTAX Integer32 (0..65535)
> MAX-ACCESS read-only
> STATUS current
> DESCRIPTION
> "The value of the hrDeviceIndex of the printer device that this
> storageEntry is associated with."
> ::= { prtStorageRefEntry 2 }
>
> prtDeviceRefTable OBJECT-TYPE
> SYNTAX SEQUENCE OF PrtDeviceRefEntry
> MAX-ACCESS not-accessible
> STATUS current
> DESCRIPTION
> ""
> ::= { prtGeneral 3 }
>
> prtDeviceRefEntry OBJECT-TYPE
> SYNTAX PrtDeviceRefEntry
> MAX-ACCESS not-accessible
> STATUS current
> DESCRIPTION
> "This table will have an entry for each entry in
> the host MIB device table that represents a device associated
> with a printer managed by this agent."
> INDEX { hrDeviceIndex, prtDeviceRefSeqNumber }
> ::= { prtDeviceRefTable 1 }
>
> PrtDeviceRefEntry ::= SEQUENCE {
> prtDeviceRefSeqNumber Integer32,
> prtDeviceRefIndex Integer32
> }
>
> prtDeviceRefSeqNumber OBJECT-TYPE
> SYNTAX Integer32 (0..65535)
> MAX-ACCESS not-accessible
> STATUS current
> DESCRIPTION
> "This value will be unique amongst all entries with a common
> value of hrDeviceIndex.
>
> This object allows a device entry to point to the multiple
> printer devices with which it is associated."
> ::= { prtDeviceRefEntry 1 }
> SYNTAX Integer32 (0..65535)
> MAX-ACCESS read-only
> STATUS current
> DESCRIPTION
> "The value of the hrDeviceIndex of the printer device that this
> deviceEntry is associated with."
> ::= { prtDeviceRefEntry 2 }
>
>
>
> --
> _____________________________________________________________
> Eugene Chen Sr. Software Engineer, Networking.
> -------------------------------------------------------------
> DIR:(415) 286-8372 Electronics for Imaging, Inc.
> OPER:(415) 286-8600 2855 Campus Drive
> email:Eugene.Chen@eng.efi.com San Mateo, CA 94403
>
>
>-- End of excerpt from Eugene Chen
--Gail Songer Electronics For Imaging gail.songer@eng.efi.com 2855 Campus Drive (415) 286-7235 San Mateo, CA 94403
----- End Included Message -----