Large-Scale Broadband Measurement Use Cases
RFC 7536

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

(Benoît Claise) Yes

(Jari Arkko) No Objection

(Alia Atlas) No Objection

Comment (2014-12-04 for -05)
No email
send info
I agree with Pete's concerns.

(Richard Barnes) No Objection

Alissa Cooper No Objection

Comment (2014-12-02 for -05)
No email
send info
= Section 4.3 =

I would recommend removing or re-wording some bits of language from this section that aren't strictly necessary and could be contentious or turn the reader off. The following seems like it could be deleted (especially since some of the relevant bits of the R&O, relating to transparency, have not been overturned):

"such as the court action negating the FCC R&O"

Similarly, I would suggest the following:

OLD
   Net neutrality regulations do not necessarily require every packet to
   be treated equally. Typically they allow "reasonable" traffic
   management (for example if there is exceptional congestion) and allow
   "specialized services" in parallel to, but separate from, ordinary
   Internet access (for example for facilities-based IPTV). A regulator
   may want to monitor such practices as input to the regulatory
   evaluation. However, these concepts are evolving and differ across
   jurisdictions, so measurement results should be assessed with
   caution.

   A regulator could monitor departures from application agnosticism
   such as blocking or throttling of traffic from specific applications,
   and preferential treatment of specific applications. A measurement
   system could send, or passively monitor, application-specific traffic
   and then measure in detail the transfer of the different packets.
   Whilst it is relatively easy to measure port blocking, it is a
   research topic how to detect other types of differentiated treatment.
    The paper, "Glasnost: Enabling End Users to Detect Traffic
   Differentiation" [M-Labs NSDI 2010] and follow-on tool "Glasnost"
   [Glasnost] are examples of work in this area.

NEW
   A regulator may want to monitor traffic management practices or compare the performance of Internet service with services offered in parallel to but separate from Internet access (for example IPTV). A regulator could monitor departures from application agnosticism
   such as blocking or throttling of traffic from specific applications,
   and preferential treatment of specific applications. A measurement
   system could send, or passively monitor, application-specific traffic
   and then measure in detail the transfer of the different packets.
   Whilst it is relatively easy to measure port blocking, it is a
   research topic how to detect other types of differentiated treatment.
    The paper, "Glasnost: Enabling End Users to Detect Traffic
   Differentiation" [M-Labs NSDI 2010] and follow-on tool "Glasnost"
   [Glasnost] are examples of work in this area.

(Adrian Farrel) No Objection

Comment (2014-12-01 for -05)
No email
send info
I have no objection to the publication of this document although a few editorial nits are revealed by idnits.

(Stephen Farrell) No Objection

Comment (2014-12-04 for -05)
No email
send info
- I do think that this kind of document is useful in
this case and am fine that it becomes an RFC.

- I agree with the comments about the language in the
regulator section in particular.

- 3.5: I'd be interested in a reference to back up
that 80% figure if there's a good one.

- 3.5: The on-demand test that the call centre runs
sounds dangerous to me unless at least accompanied by
a s/w update for the CPE - how do you avoid leaving
bad holes open otherwise?

- section 5: I think the list at the end should
acknowledge that a measurement system might itself
include vulnerabilities that put the user's home
network at risk, e.g. if it required opening a port on
the CPE or if someone could spoof the server-side of
the measurement system and the home-side had a buffer
overrun.

- section 6: I'm wondering if it's really wise to
include both measurement and troubleshooting
capabilities in the same thing. I see the attraction
but the latter may have more onerous security
requirements that would tend not to be met by
implementations of the former.

- section 7, point 4: Would it be worth noting that
the pattern of times for measurements could leak
information about the user's presence/activity at
home? E.g. if measurements are normally taken mostly
at night but for two weeks in august happen precisely
every hour all day long, then I could conclude the
person at that location is on vacation.

- section 7: "informed consent" - hmm, I wonder what
that really means but I like that you recognise the
issue and particularly the secondary uses problem.

- section 7 (or section 6): I think it would be good
to say here that LMAP protocols really do need
signiicant analysis of privacy considerations and it's
likely that those ought end up being explicitly
documented in the relevant specifications.

(Joel Jaeggli) No Objection

Comment (2014-12-01 for -05)
No email
send info
The text in 3.1 about sample size seems poorly justified. should be genericised, I think and would hopefully never be interpreted literally.

   "The understanding can be gained through a
   "panel", i.e. measurement probes deployed to a few 100 or 1000
   customers. The panel needs to include a representative sample for
   each of the operator's technologies (fiber, Hybrid Fibre-coaxial
   (HFC), DSL...) and broadband speeds (80Mb/s, 20Mb/s, basic...). For
   reasonable statistical validity, approximately 100 probes are needed
   for each ISP product."

Barry Leiba No Objection

(Ted Lemon) No Objection

Comment (2014-12-04 for -05)
No email
send info
I tend to agree with Pete's concerns about marketing fluff in the document, but I think the core message of the document is worth stating.   It would be nice if some of the fluff Pete is complaining about could be removed, but I'm not going to insist on it.

(Kathleen Moriarty) (was Discuss) No Objection

Comment (2015-02-12)
No email
send info
Thanks for addressing my prior discuss concerns with security and privacy considerations.

(Pete Resnick) (was Discuss) No Objection

Comment (2015-02-10)
No email
send info
Thank you for an excellent set of edits. This addresses my earlier concerns about the regulator use case text being too politically charged and focuses the document on the real engineering concerns that regulators need addressed. Well done.

(Spencer Dawkins) Abstain

Comment (2014-12-04 for -05)
No email
send info
I have the same concerns Pete has, but since he's already a Discuss, I don't need to be ...

(Brian Haberman) Abstain

Comment (2014-12-02 for -05)
No email
send info
Like my commentary on "requirements documents", I don't see the value in publishing use cases as standalone RFCs. I would rather see these maintained in a wiki or living I-D and either not published or published as an appendix to the
corresponding protocol specification.

That being said, I will not stand in the way of this document.