Skip to main content

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

Yes

(Benoît Claise)

No Objection

(Barry Leiba)
(Jari Arkko)
(Richard Barnes)

Abstain


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

Benoît Claise Former IESG member
Yes
Yes (for -05) Unknown

                            
Adrian Farrel Former IESG member
No Objection
No Objection (2014-12-01 for -05) Unknown
I have no objection to the publication of this document although a few editorial nits are revealed by idnits.
Alia Atlas Former IESG member
No Objection
No Objection (2014-12-04 for -05) Unknown
I agree with Pete's concerns.
Alissa Cooper Former IESG member
No Objection
No Objection (2014-12-02 for -05) Unknown
= 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.
Barry Leiba Former IESG member
No Objection
No Objection (for -05) Unknown

                            
Jari Arkko Former IESG member
No Objection
No Objection (for -05) Unknown

                            
Joel Jaeggli Former IESG member
No Objection
No Objection (2014-12-01 for -05) Unknown
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."
Kathleen Moriarty Former IESG member
(was Discuss) No Objection
No Objection (2015-02-12) Unknown
Thanks for addressing my prior discuss concerns with security and privacy considerations.
Pete Resnick Former IESG member
(was Discuss) No Objection
No Objection (2015-02-10) Unknown
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.
Richard Barnes Former IESG member
No Objection
No Objection (for -05) Unknown

                            
Stephen Farrell Former IESG member
No Objection
No Objection (2014-12-04 for -05) Unknown
- 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.
Ted Lemon Former IESG member
No Objection
No Objection (2014-12-04 for -05) Unknown
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.
Brian Haberman Former IESG member
Abstain
Abstain (2014-12-02 for -05) Unknown
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.
Spencer Dawkins Former IESG member
Abstain
Abstain (2014-12-04 for -05) Unknown
I have the same concerns Pete has, but since he's already a Discuss, I don't need to be ...