Subject: Re: PMP> Discussion items for 4/22 Conference call

From: JK Martin <[email-masked]>
Date: Mon, 21 Apr 1997 18:32:10 -0400 (EDT)

Matt,

Excellent job on resolving your action items.  I agree with almost
everything you've stated in your message, with a few small exceptions:

> 1. Clarification of Unary and Binary event management.
> 
> [...]
> 
> b) In the list of rules after paragraph 5 of section 2.2.13.4, first
> rule refers to "simple" alerts.  I believe this reference should be
> changed to "unary".

Actually, there are at least 5 references to "simple" in that section
of the MIB (as documented in my last posting on this subject).  Hopefully
Randy can change all of them at once to "unary" for the next draft.

> 4. Clarification of what should cause prtGeneralConfigChanges to
>    be incremented.
> 
> a) In the first sentence of the prtGeneralConfigChanges description,
> replace "media size" with "any media attributes".

Further in your text you consistently use this phrase:

    "...that results in a change to..."

I sincerely hope that a *real* change must be effected within the
SNMP agent in these circumstances.  Right?

That is, the Lexmark printers we test have the characteristic of
adding quite a few "prtInputMedia" alerts when a tray is pulled out,
and then quite a few more when the tray is put back in...even when
no change in any media-related attributes has occurred.

Does your new wording then imply that if the SNMP agent can not detect
any changes in such media-related attributes, that the agent should NOT
increment prtGeneralConfigChanges?

In even simpler words, just because the tray is pulled, the SNMP agent
should not announce "Media Size/Weight/Form/Name" has Changed!" in the
Alert Table.  Ditto for when the tray is restored.  Right?

As we discussed at the interop testing last February, this particular
issue has been a serious sore point as we try to deal with the various
implementations of the Printer MIB in some vendors' network printers.
Hopefully we can all come to a clean and consistent resolution here.

Again, very nice work, Matt.

	...jay

----------------------------------------------------------------------
--  JK Martin               |  Email:   [email-masked]          --
--  Underscore, Inc.        |  Voice:   (603) 889-7000              --
--  41C Sagamore Park Road  |  Fax:     (603) 889-2699              --
--  Hudson, NH 03051-4915   |  Web:     http://www.underscore.com   --
----------------------------------------------------------------------

---

From: Matt King <[email-masked]>
Date: Tue, 22 Apr 1997 11:59:26 -0400

JK Martin wrote:
> [ ... ]

Yes, as real as configuration change is.  Setting a configuration
variable is a config change even though no physical change was made.

> no change in any media-related attributes has occurred.

That is a "feature" that we will be removing.  It makes no sense to add
an alert for something that the printer connot detect.  If the admin
cares what color paper he put in the printer, he should modify SNMP
variable himself.  The act of modifying the variable should cause
prtGeneralConfigChanges to be incremented, however.

Regardless, the new wording says that prtGeneralConfigChanges is only
incremented on config changes (a variable, such as prtInputMediaColor
must be modified).  Even though lexmark added an alert to the alert
table, we did not change any attribute variables.

> increment prtGeneralConfigChanges?

No.  It says that any attribute change (not necessarily media related)
that either physically or logically (via an SNMP set) occurs will
trigger an increment of prtGeneralConfigChanges.

> Alert Table.  Ditto for when the tray is restored.  Right?

I agree that pulling a tray or putting it back should not add an alert
(as Lexmark currently does), however, that is really unrelated to the
prtGeneralConfigChanges.

-- 
Matt King                                     Opinions are my own and
Staff Engineer                                    are not necessarily
Lexmark International, Inc.                          those of Lexmark
[email-masked]