Model-Based Metrics for Bulk Transport Capacity
draft-ietf-ippm-model-based-metrics-13

The abstract is overly long (long enough to run onto the second page.) That seems to detract from the purpose of an abstract. Can it be shortened to a paragraph or two?

High level comment:
I still (compared to an earlier review I did during the first wg last call) think that the document could benefit from a mayor editorial pass that aims to remove redundancy (especially in section 8) and hopefully would lead to a much shorter document in the end. Especially the split between section 6, 7 and 8 is not always clear. It would actually be nice if the general model aspects and its applicability to one traffic class with the assumption that self-clocked, loss/CE-based congestion control is used would be separated more clearly. This would also help to separate generally reasoning from the test and evaluation instructions and make those more clear and understandable (in the sense that concrete implementation guidelines for both the tests and the evaluation seem quite hidden between all the other text at the moment). However, I understand that this is a lot of work and probably not appropriate at this state of processing.

Processing comment:
The references are not split into normative and informative. I guess most references including draft-ietf-tcpm-rack are informative. Indicating this clearly in two separate reference sections would also address the editor comment in 1.1 regarding draft-ietf-tcpm-rack.

Various, mostly editorial comments:
- The terminology mentions open loop. I would recommend to also note in the intro that these are open loop tests (compared to using TCP traffic directly).
- ECN should be spelled out somewhere and RFC3168 should be referred (informatively).
- It seems that the currently specified metrics and tests assume ack-clocked and loss/ECN-based congestion control. This might also worth stating in the intro given quic is experimenting with rate-based schemes.
- Regarding the list at the end of section 4.1 on bursts: Shouldn't the initial window (which is usually today more than 4 packets) be mentioned additionally?
- Network power could be defined in the terminology section.
- It might also be useful to spell out more clearly in the intro that for these tests both endpoints (of the subpath under test) need to be under control of the tester.
- As mentioned several times in the document, some of the tests are not intended for frequent monitoring tests as the high load can impact other traffic negatively. This should be re-stated clearly  in the security considerations.