Comments on draft-ietf-rmonmib-raqmon-framework-13.txt

Section 5.13 should refer to the definition of End System Delay in 
RFC3611.  It does not make any sense to have two definitions of the same 
parameter reported from the same endpoint and could lead to 
inconsistencies.  The same could be said of sections 5.20-5.23

Section 5.14 and 5.15 refer only to PPDV and IP PDV.  Within the ITU 
several other approaches have been standardized, including MAPDV, which 
mirrors more precisely the impact of jitter on discard rate.

Section 5.16 gives a count of the number of application packets sent. 
Section 5.17 gives a count of the number of application packets received. 
These are described as counters that are a "snapshot in time" that may 
vary with application state - e.g. may start by counting signaling 
packets - may (or may not) be reset when media starts.. 
This is a confusing description in both cases and leads to a situation 
in which the collector/ reporting application needs to know what the 
state of the application is in order to interpret the metric. As the 
application state appears not to be reported then the metric cannot be 
interpreted.
Also - since so much is optional - what if one end chooses to include 
signaling and media packets in its "sent" count and the other chooses to 
reset its "received" count after signaling has completed - the central 
application may not know if packets had been lost or not?
Another also - if the counter is reset during a reporting interval then 
how would the collector/reporting application know what the counter 
value was prior to reset. 
It would be simpler from all three perspectives to have separate 
counters for signaling and media.

Regards

Alan