Subject: Re: PMP> What constitutes a config change

From: JK Martin <[email-masked]>
Date: Thu, 24 Apr 1997 17:11:44 -0400 (EDT)

Harry,

I think Matt King pretty much said it all when he suggested that a
"configuration change" involves a change in any "attribute" in the
MIB.

I forget right offhand whether Matt proposed a definition for an
"attribute" in his message; however, one could argue that the
Printer MIB (and possibly most other MIBs) have essentially three
broad classes of variables:

  attributes	Descriptive kinds of things
  counters	Well, er, counter-like things  ;-)
  status	Specific state indicators, etc

When you look at the above list, the last two can be broadly
characterized as being dynamic and, for all intents and purposes,
not settable by a "manager".  (I don't wish to split hairs here,
particularly when I have so few... ;-)

Of course it would be best to have an absolutely all-encompassing
list of MIB objects that fall under the realm of "candidate for
a config change", but perhaps we can all agree that:

  "If the MIB object is not a counter nor a status object,
   then it must be an attribute, and as such, any change to
   an associated variable value constitutes a change in the
   configuration."

Is this a base philosophy to which we can all agree?

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

----- Begin Included Message -----

>From [email-masked] Wed Apr 23 19:49 EDT 1997
From: Harry Lewis <[email-masked]>
To: <[email-masked]>
Subject: PMP> What constitutes a config change
Date: Wed, 23 Apr 1997 19:49:48 -0400

Classification:
Prologue:
Epilogue: Harry Lewis - IBM Printing Systems

We had some trouble with config change counter at Stardust and I want to get it
right. I don't think we really tested config change thoroughly and I want to
see if we have consensus on what constitutes a config change. The MIB says
things that change the printer's capabilities and excludes things like the
level of supplies or temporary bin removal to replenish supplies. Great. I
would add to these exclusions (not asking for a MIB update, just consensus)
changes in localization, since these do not really effect the printer
capabilities.

Here's my list of what should result in a config counter bump were they to
change:

Paper (Input) Size
Output Size
Input Capacity
Output Capacity
Total Number of Input Trays
Total Number of Output Bins
Defaults (Input, Output, Marker, Media Path)
Media Path Size (only likely on highly sophisticated printers)
Total Number Of Interpreters
Total Number of Channels (probably fixed in most cases)
Total Number of Interfaces (probably ignored by most of today's implementations)
Output features supported (optional)

Here's some I'm not sure about:

Overall Storage Capacity (not storage used)
Change in FLASH size installed
Tray linking
Media Name

I'd like to hear what others think. I don't know if we should necessarily go
any farther with documenting this, I guess it depends on how much controversy
(if any) there is over this list.

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

---

From: Harry Lewis <[email-masked]>
Date: Fri, 25 Apr 1997 11:27:57 -0400

Classification:
Prologue:

I apologize to Matt and the PWG if I missed some earlier discussion on this
topic (SO MUCH flashes by in the PWG!!).

>"configuration change" involves a change in any "attribute" in the

I think I support Jay's paraphrasing

 >  an associated variable value constitutes a change in the

except that I would also define a GAUGE and exclude it from the config
changes. I think this is the spirit of the current definition which
excludes things like input tray current capacity changes.

I don't know if it's better to have a "base philosophy" statement

>Change in FLASH size installed

Gail has volunteered to put together a FAQ (thanks Gail!) when there is
consensus on this. Perhaps, we should state the philosophy followed by a list
for the printer MIB, if people want to contribute to the list. If not, I think
the statement may suffice.

Harry Lewis.

---

From: JK Martin <[email-masked]>
Date: Fri, 25 Apr 1997 11:41:37 -0400 (EDT)

Harry,

> excludes things like input tray current capacity changes.

Yep, GAUGE objects should also be excluded as being "attributes".  Are
there any other object types we should expressly point out for exclusion?

> [...snip...]

Whenever possible, a complete list is always preferred to avoid any
chance of ambiguity or misinterpretation.  Your list looks pretty
good, as long as the actual MIB names are used in the list (and not
just the simply summary names as you've submitted).

However, given the history of the Printer MIB development, it seems as
if it's in our best interest to always state the rationale used to make
key decisions for the MIB design.  That way, future readers can better
understand what to expect, and the rationale should help guide future
extensions.

So, both the list *and* the philosophy statement would be make fine
additions to the MIB document...assuming Randy doesn't have a problem
with that.  (Randy: if you need us to submit a "fully cooked" version
of the text, let us know!)  If for some reason the list and statement
can't make it into the draft, then it should definitely go into Gail's
new FAQ document.

	...jay