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

["C. M. Heard" <heard@pobox.com>]

On Tue, 4 Jan 2005, Romascanu, Dan (Dan) wrote:
> My interpretation is that having objects with a MAX-ACCESS of
> 'accessible-for-notify' in the conceptual row is enough to meet
> the intent of SMIv2.

I agree with this.  To put it more precisely:  if all the auxiliary
objects (i.e., INDEX columns) have a MAX-ACESS of 'not-accessible'
and if there is at least one additional object that is not an INDEX
column and that has a MAX-ACCESS value of (at least)
'accessible-for-notify', then you have fully satisfied the
requirements of RFC 2578.

On Tue, 4 Jan 2005, in a subsequent message, Dan also wrote:
> I believe the raqmon issue was clarified, and I am happy. 
> 
> I still have a feeling the 2578 language is not crystal clear. 
> 
> > > > 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".
> ...
> 
> > No.  'read-only' is NOT an example, but the situation outlined
> > in RFC 2578 Section 7.7 is when ALL of a conceptual row's
> > columnar objects are also specified its INDEX clause. 
> 
> Can you clarify why making one of the objects in the case
> described in 2578 accessible by having a MAX-ACCESS clause of
> 'accessible-for-notify' is not enough?
> 
> This would be the difference between i.e and e.g.

My reading of this has always been that RFC 2578 specifically
intended to prohibit giving an auxiliary object a MAX-ACCESS value
other than 'not-accessible' or 'read-only', except in MIB modules
that were originally written in SMIv1 (they will have index columns
that have a MAX-ACCESS of 'read-only' or, more rarely,
'read-create').  In particular, it is illegal for an auxiliary
object to have a MAX-ACCESS value of 'accessible-for-notify'.  I
know that the SMICng MIB compiler (at least the older versions)
agreed with this interpretation.

While I might debate the necessity of an outright ban on auxiliary
objects with a MAX-ACCESS value of 'accessible-for-notify', I most
certainly do agree that auxiliary objects do not belong in the
OBJECTS clause of a notification definition.  I would therefore
agree that there is no need for an auxiliary object to have a
MAX-ACCESS value of 'accessible-for-notify'

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

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

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.

> I would like to see a clarification on this point for the next
> mib review guidelines draft.  It sounds like most folks in this
> thread are in agreement on this point.  Are there other factors
> involved, that to be aware of here?

As always, it would be a help to the editor (me) if you would be
specific.  What do you think that the clarification should say?
And where whould it go in the document?

Thanks,

Mike Heard