Large-Scale Broadband Measurement Use Cases
draft-ietf-lmap-use-cases-06

I have no objection to the publication of this document although a few editorial nits are revealed by idnits.

I agree with Pete's concerns.

= 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.

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."

Thanks for addressing my prior discuss concerns with security and privacy considerations.

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.

- 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.

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.