[ addressee list trimmed to cut down on duplicate copies ]
On Wed, 5 Jan 2005, Mark Ellison wrote:
<cmh> What do you think that the clarification should say?
<cmh> And where whould it go in the document?
I propose the following be considered. Probably the best place
in mib-review-guidelines is sxn 4.6.4:
- For conceptual rows used exclusively for defining objects
referenced by notification definitions:
- At least one non-auxiliary object must be defined with
a MAX-ACCESS of (at least) "accessible-for-notify"
This language protects the "i.e. read-only" boundary case in 2578 sxn
7.7 where only auxiliary objects exist, like the udpTable, while
clarifying the special case encountered with a conceptual row used
exclusively for object definitions used by notification definitions.
Please hack away at the suggested text. Possibly some will want to add
another line to the effect, '...but, in most design situations, one is
better off modelling such objects as a group of scalars anyway..." and
this might require an example as well.
Thanks for providing the proposed text. If we do agree to include this
(or something like it) in the MIB review guidelines, then we will want
to make it clear that this applies only in the special situation where
all of the columns appear in the INDEX clause. The following
alternative is an attempt to do that:
- For conceptual rows that include all columns in the INDEX clause:
- One of the columns must have a MAX-ACCESS value of 'read-only',
unless the columns are intended to be referenced only by
notification definitions; in that case one of the columns must
have a MAX-ACCESS value of 'accessible-for-notify'.
However (speaking now as a contributor rather than as document editor)
I don't think this really qualifies as a _clarification_ to RFC 2578;
my reading of the document is that this would be a _change_ to the
rules, and that runs counter to the general policy stated in the second
paragraph of Section 1 of the MIB review guidelines document:
Please note that the guidelines in this memo are not intended to
alter requirements or prohibitions (in the sense of "MUST", "MUST
NOT", "SHALL", or "SHALL NOT" as defined in RFC 2119 [RFC2119]) of
existing BCPs or Internet Standards except where those requirements
or prohibitions are ambiguous or contradictory.
As noted in earlier messages in this thread, there are other ways to
achieve the same objective without changing the rules in this way.
Another point to be made is that (as far as I can tell) no IETF WG
has actually proposed to define a conceptual row to be used for
notification definitions only with all of its columns in the INDEX
clause (the row in draft-ietf-rmonmib-raqmon-pdu-08.txt that brought
up this issue has many non-INDEX objects). Is anticipation of this
eventuality really worth making a such a change (and adding more
text for the readers of the review document for people to wade
through)? I don't think so.
As you can see, I'm not in favor of making this change, but I'll gladly
do so if most other folks see it differently.
Thanks,
Mike