I have reviewed this document as part of the Operational directorate's ongoing effort to review all IETF documents being processed by the IESG.  These comments were written primarily for the benefit of the operational area directors.  Document editors and WG chairs should treat these comments just like any other last call comments.   Ready with one issue   This I-D is an informational document that does not define a new protocol or protocol extensions. It does however contain a problem statement for test protocols conducting access rate measurement in productions networks. These protocols can be OWAMP (RFC 4656) or TWAMP (RFC 5357) but also non-IETF protocols. The following operational considerations in Appendix A.1 of RFC 5706 apply, I believe, and do not receive appropriate answers in the document:   5. Has the impact on network operation been discussed? See Section 2.5. * Will the new protocol significantly increase traffic load on existing networks? * Will the proposed management for the new protocol significantly increase traffic load on existing networks? * How will the new protocol impact the behavior of other protocols in the network? Will it impact performance (e.g., jitter) of certain types of applications running in the same network?   I believe that at least a reference to these aspects need to be included, especially as the In-Service testing with injection of active traffic on production network is one of the methods discussed by the document.   The following reference to the effects of the high level traffic is not sufficient IMO:   Ø   Section 5 of [RFC2680] lists the problems with high    measurement traffic rates, and the most relevant for rate measurement Ø   is the tendency for measurement traffic to skew the results, followed    by the possibility of introducing congestion on the access link.  In-    Service testing MUST respect these traffic constraints.  Obviously,    categories of rate measurement methods that use less active test    traffic than others with similar accuracy are preferred for In-    Service testing.   Section 5 of RFC2680 does not provide too many details as I was expecting. It actually deals with traffic injection as with a security concern:   Ø   There are two types of security concerns: potential harm caused by Ø    the measurements, and potential harm to the measurements. The Ø    measurements could cause harm because they are active, and inject Ø    packets into the network. The measurement parameters MUST be Ø    carefully selected so that the measurements inject trivial amounts of Ø    additional traffic into the networks they measure. If they inject Ø    "too much" traffic, they can skew the results of the measurement, and Ø    in extreme cases cause congestion and denial of service. Ø ‘trivial amounts of additional traffic’ is too vague – I believe that more clear text that deals with the issue as with an operational issue, and makes clear that degradation of service for users is not acceptable if In-Service testing policies are applied would be welcome.   I hope this helps.   Regards,   Dan