> I think I support Jay's paraphrasing
>
> > "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."
>
> 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.
Yep, GAUGE objects should also be excluded as being "attributes". Are
there any other object types we should expressly point out for exclusion?
> I don't know if it's better to have a "base philosophy" statement
> (as Jay calls it) or an agreed to list like I initiated:
>
> [...snip...]
>
> 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.
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