Mike,
+1 with what Dan is saying....
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. 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".
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?
Regards,
Mark
Romascanu, Dan (Dan) wrote:
Mike,
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.
Regards,
Dan
-----Original Message-----
From: C. M. Heard [mailto:heard@pobox.com]
Sent: 04 January, 2005 12:09 AM
To: Mark Ellison
Cc: Wijnen, Bert (Bert); Romascanu, Dan (Dan); Mreview (E-mail)
Subject: Re: [Fwd: Re: [RMONMIB] I-D
ACTION:draft-ietf-rmonmib-raqmon-pdu-08.txt]
On Mon, 3 Jan 2005, Mark Ellison wrote:
There is currently a dicussion about a point in RFC 2578 sxn
7.7, as described below. Possibly, this issue could be
clarified in the next id for the mib review guidelines?
First, I see that a solution to the specific problem has been
agreed upon:
2) raqmonDsNotificationEntry
objects used in index clause [raqmonDSRC, raqmonRCN,
raqmonPeerAddrType, raqmonPeerAddr] according to
SMIv2 (2578 sxn 7.7) should have a MAX-ACCESS of
not-accessible.
The two defined notifications, raqmonDsNotification and
raqmonDsByeNotification require only index objects be sent.
Since the value part of the object instance is included
in the index portion of the varbind name, there is a
unnecessary duplication of information.
This suggests one of two alternative approaches- either
a) change the OBJECTS clause for the NOTIFICATION-TYPEs
to specify an accessible-for-notify object that is not
mentioned in the INDEX clause of raqmonDsNotificationEntry
and replace the current OBJECTs list with this object.
b) change the raqmonDsNotificationEntry into a group of
scalars, leaving the index objects with a MAX-ACCESS of
accessible-for-notify, and, leaving the two defined
NOTIFICATION-TYPEs as is.
[Romascanu, Dan (Dan)] I will go with your proposal a.
There are reasons to keep the table structure, so that the
information is correlated if the table is extended in the
future.
After looking at draft-ietf-rmonmib-raqmon-pdu-08.txt I also
think that
solution (a) is appropriate. The INDEX objects should then be given a
MAX-ACCESS value of 'not-accessible'.
[Mark Ellison] I like the table structure as well.
Since 2578 Sxn 7.7 appears specifies that at least one
object in an entry must have a MAX-ACCESS of at
least read-only,
it might be a good idea to address this point in the
description
clause of the entry, given the design choice to
stick with the
current organization, or, make an object read-only, and then
restrict its MAX-ACCESS to accessible-for-notify in a
compliance clause.
[Romascanu, Dan (Dan)] Actually I believe that this is OK and we
do not need a 'read-only' object. What RFC 2578 says is:
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".
"read-only" is an example. The objects in
raqmonDsNotificationEntry
are accessible-for-notify.
[Mark Ellison] Yes, its the "i.e." part that requires
clarification,
since "i.e." usually means "that is", whereas "e.g."
usually means "for
example". I've forwarded a copy of this email to Bert
Wijnen. Perhaps
a clarification can be added to the next id for the mib review
guidelines. I hope an "e.g." was intended, and that a MAX-ACCESS of
accessible-for-notify is compliant in this regard.
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. That is not the case
with raqmonDsNotificationEntry. If I correctly understand what I
read, it has 32 columns, of which four (raqmonDSRC, raqmonRCN,
raqmonPeerAddrType, and raqmonPeerAddr) are INDEX columns. These
should have a MAX-ACCESS value of 'not-accessible'. The remaining
28 columns have a MAX-ACCESS value of 'accessible-for-notify'. I
see no contradiction with RFC 2578 Sec. 7.7.
I think that the language in RFC 2578 Sec. 7.7 is quite clear, and I
see no problems with it. After this discussion, do you still think
that something needs to be clarified or changed?
Thanks,
Mike
|