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