[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
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