Summary: Has enough positions to pass.
I share the Gen-ART reviewer's discomfort about the weak language in the security considerations section, but will leave it to the responsible AD to do the right thing.
Section 1: s/controlled environment/controlled environments/ With the above change, I think the document is clear enough about where these tests should be run.
We don't really explain the usage of the "variation pattern index" that I can see. Section 3 + Bottleneck-link capacity: defines minimum capacity of the end-to-end path I'm not sure I'd describe this as the "minimum capacity of the end-to-end path", since attempts to use anything larger than this value will pile up at the bottleneck. Section 5.6, 5.7 Do we want anyone to consider testing with alternative TCP congestion control algorithms? Section 6.1 If you're not going to reference what scheme is used for implementing priority, say how these priority values are interpreted. Section 6.2 nit: "delay-based" (hyphenated) Section 6.3 Expected behavior: The candidate algorithm is expected to achieve full utilization at both bottleneck links without starving any of the I'm not sure how we can get "full utilization" at both bottlenecks, when the links in question have different capacity ratios. Section 11.2 Some of these may need to be normative references; e.g., if we require default TCP congestion control (RFC5681) for the competing TCP flows, then it's mandatory.
Thanks for the work on this document. I have only one minor nit to call out. ID Nits reports: ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 458: '...didate proposals MAY show the effectiv...'