Re: Do we agree on an RFC-Erratum for RFC2578

[Keith McCloghrie <kzm@cisco.com>]

I agree that the proposed change is the smallest possible erratum which
allows what you seem to want to allow.  However, I'm undecided on whether
I would want to allow it.  Specifically, I don't think that I would
ever define a MIB table which would require this change, because it
implies that a notification's varbindlist will contain a varbind
something like "(object.x.y.z, y)", i.e., that "y" occur twice.
Repeating a value which is already present has a usefulness of zero; in
contrast, there is always additional information which can be included
in a notification and which has a non-zero potential for being useful.
Therefore, I would add a columnar (not an auxiliary) object as
accessible-for-notify containing whatever additional information I
thought might be useful.  (Even if I couldn't think of anything useful,
defining an object with a syntax of "INTEGER { noop(1) }", while
somewhat inelegant, has the same zero usefulness as repeating "y", and
would be the minimal length ASN.1 encoding, and therefore result in a
message with a length less or equal to the one with the repeated "y".)

But, maybe I'm unusual in that I know/remember how everything works,
and that other MIB designers would prefer the (less efficient) MIB
table with fewer OBJECT-TYPEs.  Perhaps, the SMI ought to provide "more
rope" to MIB designers by allowing them to define less efficient MIBs
which have fewer OBJECT-TYPEs.  In other words, even if we were to
agree that it represents a "non-optimal" MIB design, perhaps the SMI is
not the right instrument for prohibiting such MIB designs.  In that
case, I think the best erratum would be to keep the "i.e.," but add
"accessible-for-notify" as a second allowed possibility.  This would be
better because retaining "e.g.," makes "read-write" and "read-create"
into allowed possibilities (despite the subsequent parenthetical
sentence).

Keith.

> [Added Mark, because he brought up the issue I believe, 
>  Added Keith because he is one of the co-editors of RFC2578]
> 
> We've had some discussion about a piece of text in RFC2578 and possible
> clarifying text in the mib review guidelines. We're wondering if
> it is maybe better to clarify the RFC itself via an RFC-erratum.
> 
> So ALL MREVIEW list members, pls speak up and post your opinion:
> 
> RFC2578 sect 7.7. states on page 29:
> 
>   (2)  a conceptual row must contain at least one columnar object which is
>        not an auxiliary object.  In the event that all of a conceptual
>        row's columnar objects are also specified in its INDEX clause, then
>        one of them must be accessible, i.e., have a MAX-ACCESS clause of
>        "read-only". (Note that this situation does not arise for a
>        conceptual row allowing create access, since such a row will have a
>        status column which will not be an auxiliary object.)
> 
> The proposed erratum is to change the "i.e." into an "e.g." because we
> intended to say (for example) in the above text. So it would read:
> 
>   (2)  a conceptual row must contain at least one columnar object which is
>        not an auxiliary object.  In the event that all of a conceptual
>        row's columnar objects are also specified in its INDEX clause, then
>        one of them must be accessible, e.g., have a MAX-ACCESS clause of
>        "read-only". (Note that this situation does not arise for a
>        conceptual row allowing create access, since such a row will have a
>        status column which will not be an auxiliary object.)
> 
> So this makes it clearer that a table that has only auxiliary objects of 
> which one of them has a MAX-ACCESS of accessible-for-notify or read-only. 
> 
> Thanks
> Bert
>