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

[Mark Ellison <ellison@ieee.org>]

Hi Juergen,

Juergen Schoenwaelder wrote:

> Having said this (just for the completeness of the discussion I think
>
> ;-), I generally believe that accessible-for-notify is in almost all
> cases something to avoid, usually indicating some lack of status
> objects that can be polled to detect the same event that the
> notification is supposed to communicate. I have not checked the
> MIB in question (and do not plan to do so any time soon) but if
> we consider adding language to the guidelines explaining how to 
> create such accessible-for-notify tables we should also add language
> how to avoid such accessible-for-notify tables.
>  

While I believe it is possible to model the objects as a group of 
related scalars, using a conceptual table and the INDEX construct allows 
the SMI to provide a uniqueness constraint that otherwise could only be 
captured in descriptive text.  Using a conceptual table also provides a 
coexistence quality and instance multiplicity that a scalar should not.  
This seems to be a good use for the SMI.

The RAQMON-RDS-MIB maps the real-time application quality of service 
monitoring statistics reported by a raqmon data source (RDS) in the 
raqmon pdu to SNMP notifications.  These reports are collected by a 
raqmon report collector (RRC).  The raqmon functional architecture is 
discussed in sxn 2 of draft-ietf-rmonmib-raqmon-framework.  Essentially 
the RDS is resource poor and the RRC is resource rich.  The RRC uses the 
raqmon stats in exposing the RAQMON-MIB.

I am not very familiar with raqmon, so I am sure Dan and others can 
provide more specific motivations for using a conceptual table for this 
puporse.

Regards,

Mark