Subject: PMP> How to hande mgmt of shared devices in prtStorage, etc.

From: JK Martin <[email-masked]>
Date: Sun, 9 Mar 1997 11:47:40 -0500 (EST)

Gail,

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:   [email-masked]          --
--  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 [email-masked] Sat Mar  8 19:19 EST 1997
From: "Gail Songer" <[email-masked]>
Date: Sat, 8 Mar 1997 16:19:47 -0800
To: [email-masked], [email-masked]
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:[email-masked]  San Mateo, CA 94403
>
>
>-- End of excerpt from Eugene Chen

-- 

Gail Songer                                             Electronics For Imaging
[email-masked]                                 2855 Campus Drive
(415) 286-7235                                          San Mateo, CA 94403

----- End Included Message -----

---

From: "Gail Songer" <[email-masked]>
Date: Mon, 10 Mar 1997 12:16:10 -0800

Friends,

What we currently need solved is how prtStorageRefIndex and prtDeviceRefIndex
are actually indexed. As a reference, we looked that the mib walk from the
interoperability test, and we noticed that the two companies who had more than
one device in the prtStorage table, indexed the variables differently.

If we can figure out how a single printer references it's devices, then we will
be well on our way to two printers with shared devices.

Comments? Please.....

>     We had hoped to see some comments/suggestions on what the
> but we have had no takers on the list.
> ...
>

> ...

--

---

From: "Gail Songer" <[email-masked]>
Date: Mon, 10 Mar 1997 12:15:41 -0800

On Mar 9, 11:47am, JK Martin wrote:
> Subject: How to hande mgmt of shared devices in prtStorage, etc.
> Gail,
>

Jay, your opinion is always valuable to me.  If they weren't, I wouldn't bug
you.

> It just seems too complex to us.  (Your--and others'--mileage may vary.)

Unfortunately, two devices are a very real to us at EFI.  As you may remember,
we attach copiers to the network via a box call an "XJ".  This box has a single
PS rip, supports multiple networks, and feeds two copiers.  Some time ago, I
asked how EFI should represent this system via 1759, given that some of the
components were shared, and some were unique.  The response that the committee
came back with, was the same that we internally came up with: represent it as
two printers.

Now we had been planning on having one SNMP agent report that there were two
printer devices, and then index the two devices with hrDeviceIndexes of .1 and
.2, hence Eugene's question.

> by the printer, and not the host on which the agent is running, etc.)

I understand why you want to get rid of it, but this poses some complications
for us.  The XJ has one IP address, and one, well known, snmp socket. Without
hrDeviceIndex on the printer mib variables, EFI could only report one of the
two attached copiers.  This would be a poor solution for us and our OEM's.

--

---

From: "Eugene Chen" <[email-masked]>
Date: Tue, 11 Mar 1997 10:13:18 -0800

Hi, Gail and friends in PWG :

Regarding the question about the different MIB-WALK implementations of
> > with prtStorageRefIndex.1.1, .2.1, .3.1 and .4.1.  Which of these is more

I think it's very clear that vendor 2 (it's not too difficult to guess who it
is) has wrong implementation. And we should urge them to fix it. The reasons
are :
1. RFC1759 says the prtStorageRefSeqNumber is "unique amongst all the entries
with a common value of hrStorageIndex". This means it's sub-index in
prtStorageRefTable. Since it's an index itself, it should start with 1, not 2.

2. It doesn't make sense to have two duplicated indexes in a single table. If
two indexes are having the same value, there should only be one index in the
table.

Regarding the implementation issues for prtStorageRefTable and
prtDeviceRefTable in multiple printer environment, I believe the interpretation
I made on March 6th email is the most reasonable and clear. Since we haven't
heard any objections from any company for the past five days, EFI will be the
first one to use this table in this way (unless any objection comes out after
this email).

So, the only suggestion I have is we should include an example in the next
printer mib RFC to explain prtStorageRefTable and prtDeviceRefTable, so it will
not be ambiguous to the future implementors.

I am pretty new to the PWG mail list and if I violated any traditions or
unspoken rules in the group, please accept my appology.

Eugene

---

From: JK Martin <[email-masked]>
Date: Tue, 11 Mar 1997 16:25:03 -0500 (EST)

Eugene,

> prtStorageRefTable. Since it's an index itself, it should start with 1, not 2.

If I'm not mistaken (but I could be), there is no rule that requires index
values must start with 1, unless the definition of the index object itself
requires such a restriction.

Index values in MIBs are primarily used to implement uniqueness.  As such,
it should matter what the values are, just so long as they are unique.
(Of course, issues revolving around the need to collate the data may
reasonably require some sort of ordering of index values.)

I would agree, though, that starting with an index value is a bit strange.
But I don't believe any "rules" have been broken here.

Anyone disagree/agree with this?

	...jay

---

From: "Eugene Chen" <[email-masked]>
Date: Tue, 11 Mar 1997 18:08:31 -0800

Jay :

What you say may be true, but it sure looks very strange to me. If I implement
a table with the following index :

1.1
2.2
3.3
3.4
4.4
4.5
5.5
..

vs.

1.1
2.1
3.1
3.2
4.1
4.2
5.1
..

Some of the SNMP management program may still work, but I will get pretty
confused by the way it is indexed. Besides, are you sure vendor 2 did not think
hrStorageIndex and prtStorageRefSeqNumber are referring to the same thing ?

Thanks,

Eugene

---

From: Matt King <[email-masked]>
Date: Wed, 12 Mar 1997 16:01:54 -0500

Eugene,

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:
> The prtStorageRefTable is described as having an entry for each storage device
> in the
> hrStorage table.

I believe you are correct!

> 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

I believe that neither is explicitly wrong, however, vendor 2's
implementation
is somewhat odd as the prtStorageRefSeqNumber is incremented for no real
reason.

>     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.

> Because we have 2 entries under one hrDeviceTable entry (Processor and

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

---

From: "Gail Songer" <[email-masked]>
Date: Wed, 12 Mar 1997 16:40:59 -0800

Harish,

I have also found the interaction between the host resources mib and printer
mib very confusing.  Luckily, a friend of mine(Hi Eugene) explained it to me,
and I am willing to share that with you. The explaination comes in the form of
two sets of the hrDevice table, the hrStorage table, the prtDevice table and
the prtStorage table.  The first set is a single printer system, and the second
set is a dual printer system. It shows how we could index and respond to the
variables in these tables.  The two prt tables included the full index, since
for me, this was the most confusing part. Since this is only an example we
chose in the dual printer model, to have the printer device id's as 1 and 7 as
this clearly identifies what in the world is going on.  If you are interested,
let me know and I will get them up on the FTP server.

Since I am working on the FAQ, the topic may well end up in there.

The host resources mib provides for over-all status of the device, tho' some of
the people here will, justifiably, question the usefullness of those status
flags.  As such it does have some purpose in a single printer system.

On Mar 12, 10:58am, Harish nachnani wrote:
> I find the HR mib relationship with printer mib very confusing. If the
> vendor was sure that the snmp agent running on his printer would be
> managing only one printer, should the host resource mib objects still be
> implemented ?
>-- End of excerpt from Harish nachnani

--