Rate Measurement Test Protocol Problem Statement and Requirements
draft-ietf-ippm-rate-problem-10

I have no objection to the publication of this document, but I did
have one observation:


Although section 2 has discussion of the variation of a number of
fields and specifically includes...

   o  Transport protocol (e.g. where TCP packets may be routed
      differently from UDP)

...I was surprised to find no mention of ECMP and the consequences that
it may introduce for the reliability of rate measurement figures.

- Thanks for the "Operational Considerations" new section, as discussed with D. Romascanu

- The document tile says problem statement, but it's a mix of problem statement, use cases, and some protocol requirements with RFC 2119 keywords. I believe the title should be modified accordingly.

- I agree with Stephen regarding the use of RFC 2119.

   Service subscribers and
   authorized users SHOULD obtain their network operator's or service
   provider's permission before conducting tests.

Really, should I have my provider consent before running http://www.speedtest.net/ ? :-)

-

   Current IETF standardized test protocols do not
   possess the asymmetric size generation capability with two-way
   testing.

Do you mean OWAMP/TWAMP? Please be specific

I agree with Stephen's observations about the use of 2119 keywords in this type of document.

I'll follow along on Stephen's comments and don't have any others to add.  The draft is well-written, thank you for your work on it.

- I'm not clear why it's a good plan for this document to
state a bunch of MUST level requirements on protocol
specifications, but I assume if that were problematic then
this informational document would be ignored and if it's not
a problem that's fine:-). Including that kind of thing can
lead to unnecessary arguments though so I wondered. For
example, on page 8 it (I think) says that protocols MUST
allow for control (by whom?) of payload lengths, which is not
something I see in typical speed test tools that'd be used by
massive numbers of users, or at least that's not exposed via
a UI that I can see.

- section 6: surely this needs to note the problem that there
can be privacy issues with (esp. multiple uses) of
measurement - e.g. if I use my phone in different places to
do similar measurements I may be open to some new forms of
tracking. Why not note this? Why is there no "MUST NOT"
requirement from this?  (Assuming you stick with including
such.) RFC2330 does recognise privacy for example, so why not
here too? BTW I don't think I see privacy issues considered
in 4656 or 5357, but I only had a very quick look. (This
would be a DISCUSS from me if this were a protocol document,
but I'm ok to just leave it as a comment on one like this.)