Sorry for taking so long to respond, but have been too busy -- some how
I guess you can understand.
On March 6, Eugene Chen wrote:
> 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 (?)
I believe you are correct!
>
> 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).
That is not all that is wrong. Do all hrStorageTable entries have to
belong
to a printer? As the HR MIB is for a generic host, it hould have
storage that
no printer has access to (e.g. a stand alone print server).
I believe that the description should be updated to be more
clear/correct.
Possibly:
"This table will have an entry for each printer reference
to an entry in the host MIB storage table that represents
storage associated with a printer managed by this agent."
>
> 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?
>
I believe that neither is explicitly wrong, however, vendor 2's
implementation
is somewhat odd as the prtStorageRefSeqNumber is incremented for no real
reason.
> 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 ?)
Again, I believe you are correct.
>
> 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).
Again I feel that the discription is bad and should be made more
clear/correct.
Possibly:
"This table will have an entry for each printer reference
to an entry in the host MIB device table that represents
a device associated with a printer managed by this agent."
>
> All responses are appreciated. Thank you.
>
> Eugene Chen
>
>
>
Eugene: Hope I have been of some help.
PWG: Do we want to potentially make these changes to the MIB?
Matt
-- Matt King Opinions are my own and Staff Engineer are not necessarily Lexmark International, Inc. those of Lexmark emking@lexmark.com