Re: [Fwd: Re: [RMONMIB] I-D ACTION:draft-ietf-rmonmib-raqmon-pdu-08.txt]

["Randy Presuhn" <randy_presuhn@mindspring.com>]

Hi -

> From: "C. M. Heard" <heard@pobox.com>
> To: "Romascanu, Dan (Dan)" <dromasca@avaya.com>; "Mark Ellison (E-mail)" <ellison@ieee.org>
> Cc: "Wijnen, Bert (Bert)" <bwijnen@lucent.com>; "Mreview (E-mail)" <mreview@ops.ietf.org>
> Sent: Tuesday, January 04, 2005 2:31 PM
> Subject: RE: [Fwd: Re: [RMONMIB] I-D ACTION:draft-ietf-rmonmib-raqmon-pdu-08.txt]
...
> On Tue, 4 Jan 2005, Mark Ellison wrote:
> > Given a situation where a table is created for the purpose of
> > organizing a set of objects for use in notifications, and, given
> > that such a table has no columns other than index columns, then
> > 2578, sxn 7.7, says one of the objects MUST have an access of
> > read-only.
>
> But if you create a table with nothing but INDEX objects for the
> sole purpose of including the values of those objects in a
> notification, then you might as well make all those objects scalars
> with a MAX-ACCESS value of 'accessible-for-notify'.

That would be true only if the index values embedded in the OID
carried no information.  If the indexes DO carry information, it's
a nice, compact way to communicate it, particularly if there is
concern about the size of other variable bindings that might be
needed.  That said, I agree with Juergen's caveats.

> > This outcome is different than accessible-for-notify, as is the
> > case for the raqmonDsNotificationEntry with (at least one)
> > non-index object.  This seems counter-intuitive, and likely not
> > the intent of the standard.  I don't see why "accessible" must
> > mean (at least) "read-only".
>
> The reason is that no purpose is served by an accessible-for-notify
> table with nothing but INDEX objects, as explained above.
>
> By contrast, situations do arise (albeit rarely) when all of the
> useful information in a table that is accessed by get or get-next
> operations is in the index values.  For an example, see the UDP
> Listener table (udpTable) in RFC 2013.  Even in those situations,
> one could avoid the need for a readable index object by using a
> read-only RowStatus column or some other status variable.  See the
> revision history section of draft-ietf-ipv6-rfc2013-update-04.txt,
> specifically the parts dealing with udpEndpointInstance.

There seems to be an inconsistancy in the reasoning here.  Why would
sending notifications about something similar to the UDP listener
be so unreasonable, particularly if the intent is for the data to go
into a local log?

> In my opinion, it would have been better if RFC 2578 had simply
> required at least one non-auxiliary object in every table.  Then we
> would not be having this discussion.
...

Alternatively, we could admit that requiring indexes to be not accessible
really is a CLR.  Most of the time it is a reasonable thing to do, but
not always.  However, like SNMP and the SMI's other quirks, it's not
that hard to kludge around it most of the time.

Randy