Rate Measurement Test Protocol Problem Statement and Requirements
RFC 7497

Note: This ballot was opened for revision 09 and is now closed.

(Spencer Dawkins) Yes

(Jari Arkko) No Objection

(Alia Atlas) No Objection

(Richard Barnes) No Objection

(Benoît Claise) No Objection

Comment (2015-02-05 for -09)
No email
send info
- 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

(Adrian Farrel) No Objection

Comment (2015-02-01 for -09)
No email
send info
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.

(Stephen Farrell) No Objection

Comment (2015-02-04 for -09)
No email
send info
- 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.)

(Brian Haberman) No Objection

Comment (2015-02-04 for -09)
No email
send info
I agree with Stephen's observations about the use of 2119 keywords in this type of document.

(Joel Jaeggli) No Objection

Barry Leiba No Objection

(Ted Lemon) No Objection

(Kathleen Moriarty) No Objection

Comment (2015-02-04 for -09)
No email
send info
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.

(Martin Stiemerling) No Objection