IP Performance Metrics (IPPM) Standard Advancement Testing
draft-ietf-ippm-metrictest-05

A useful document, thanks.

I think that the use of 2119 language in here is superfluous, if not just wrong. I don't see what difference it makes to a reader of this document to say, e.g., "The conditions for which the ADK test has been passed with the specified confidence level must be documented" instead of "MUST be documented."

Overall this is a fine document.

I concur with those who have commented regarding RFC 2119 language -- in many places I think you could just as easily change the text to use "needs to", "ought to", and "might" with no harm to the meaning. (For example: "The methods proposed here *might* be generally applicable....")

I have just one small editorial comment.  I can't parse this test from
Section 2; it might need some clarification:

   o  The error induced by the sample size must be small enough to
      minimize its influence on the test result.  This may have to be
      respected, especially if two implementations measure with
      different average probing rates.

I support each of Dan's discuss points, and with Sean's observation about code components.

There are several places where 2119 keywords are used in non-meaningful ways. It would strengthen
the document to review and remove the instances that are not truly needed. (The use of RECOMMENDED
at the top of page 10 is a particularly strong example.)

When you update the document to take RFC 6410 into account, please note
that while interop reports are no longer required in general, if you have consensus
to do so, you can still require them for advancing these metric definitions. If you
chose not to require them, please consider text strongly encouraging them.

There are several places where you REQUIRE something "whenever possible". That
leaves a lot of vagueness in the specification (is "it costs too much" a reasonable excuse for
"not possible"?). Please consider removing the exception clause, or at least explicitly discussing 
what to do or what it means when meeting that requirement is not possible.

The first paragraph of 3.1 (stating an implementation MUST implement all the MUSTs in a specification)
is vacuous - please remove it.

Or perhaps the intent of the whole section was to clarify what's required to be reported in an
implementation report and you were asking for an explicit statement that the implementation
implemented all the MUSTs - if so, please clarify. That would be consistent with the second paragraph
of 3.1 which appears to be asking that the report document which options were supported in "sufficient
detail". But what defines sufficient, and for what purpose? Please consider continuing that sentence 
("in sufficient detail to <achieve this documented goal>").

Please consider addressing the following nits.

The string "state of the art" isn't adding anything useful to the text - please remove it.

The third paragraph of section 3.5 does not parse - should "by" be deleted?

Why is there a link to xml.resource.org in the first paragraph of Appendix A.

I have the same question Dan has about BCP vs Standards Track.

There's a couple of extra references that are unused:

 == Unused Reference: 'RFC2680' is defined on line 1070, but no explicit
      reference was found in the text

 == Unused Reference: 'RFC2681' is defined on line 1073, but no explicit
      reference was found in the text

 == Unused Reference: 'RFC4719' is defined on line 1094, but no explicit
      reference was found in the text

Dan already pointed out the downref issue.

s/Pseudo WIre/Pseudowire/