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

["Romascanu, Dan \(Dan\)" <dromasca@avaya.com>]

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