Rate Measurement Test Protocol Problem Statement and Requirements
RFC 7497
Yes
No Objection
Note: This ballot was opened for revision 09 and is now closed.
(Spencer Dawkins; former steering group member) Yes
(Adrian Farrel; former steering group member) No Objection
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.
(Alia Atlas; former steering group member) No Objection
(Barry Leiba; former steering group member) No Objection
(Benoît Claise; former steering group member) No Objection
- 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
(Brian Haberman; former steering group member) No Objection
I agree with Stephen's observations about the use of 2119 keywords in this type of document.
(Jari Arkko; former steering group member) No Objection
(Joel Jaeggli; former steering group member) No Objection
(Kathleen Moriarty; former steering group member) No Objection
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; former steering group member) No Objection
(Richard Barnes; former steering group member) No Objection
(Stephen Farrell; former steering group member) No Objection
- 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.)
(Ted Lemon; former steering group member) No Objection