A Framework for Large-Scale Measurement of Broadband Performance (LMAP)
RFC 7594

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

(Benoît Claise) Yes

(Jari Arkko) No Objection

(Alia Atlas) No Objection

Deborah Brungard No Objection

(Ben Campbell) No Objection

Comment (2015-04-08 for -12)
No email
send info
Section 1, paragraph starting with "Broadly speaking there are two types of Measurement Method. "

s / Method / Methods

Figures:

Several figures that start at the top of the page have the first line out of alignment.

Figure numbers might be useful. (For example, had there been numbers I could have referenced the figures with the alignment problem :-)  )

(Spencer Dawkins) No Objection

(Stephen Farrell) No Objection

Comment (2015-04-09 for -12)
No email
send info
- general: Thanks for the significant consideration
of privacy, the draft has a quite good analysis. I
want to check though that the plan is that other lmap
drafts, esp protocol drafts, will in fact describe
(and maybe mandate) ways to meet privacy goals, and
will not simply refer to section 8 of this and tell
developers to go figure it out. If that latter was
the plan/expectation, then we'd be better off
discussing that now, rather than as a late surprise
for the WG. I assume though that the plan is rather
to try make the lmap protocol something that can
really be used in a privacy sensitive manner and that
defaults to that where possible, in which case we'll
not have that problem.

- One way in which it might be possible to provide
evidence that a system respects user privacy would be
to have some kind of auditor entity as part of the
framework. For example, an MA could be setup to send
some selection of reports/instructions to (or
encrypted for) the auditor as well as to the normal
destination. Did the WG consider such an entity?
(This is not a DISCUSS as I can see pros and cons in
the auditor-approach, so I'm not sure if it'd be a
good idea in the end.)

- Thanks for section 8, one suggestion - I'd argue
that "privacy respecting/friendly" ought be a bullet
at the end of section 1, as if the system is not,
then it'll eventually be turned off, one way or
another. If you agree, I'd be happy. If not, I'll not
get in the way.

- 5.4 (and elsewhere) I'm not sure a Group-ID by
itself is sufficient to hide identity (timing and
soure addressing may expose it anyway). That should
be noted, and that lmap protocols should be analysed
to see what turns out to be the case. I'm not sure
talking about "anonymising" is really correct as
anonymity is a very very hard thing to achieve. 

- section 8: I'm not that keen on considering the
privacy of organisations at the same level as that of
people. I can see why you might do it but that is
also often done as a way to minimise the privacy of
people.

- section 8: I didn't spot considerations related to
re-identification, which can be significant.  E.g. if
I can see other traffic that identifies a person and
the re-identify that person based on LMAP trafic
later on (or elsewhere). Did the WG consider that?

- section 8: I'm not sure that the "user consent"
thing is really of that much benefit here (and it's
ubiquitously abused on the Internet today).  It
would have been welcome had the WG come up with
something better, but then since I don't have a
solution to hand, I can't insist that you do;-)

(Joel Jaeggli) No Objection

Barry Leiba No Objection

(Terry Manderson) No Objection

(Kathleen Moriarty) No Objection

Comment (2015-04-08 for -12)
No email
send info
Thank you for your very careful and detailed attention to security and privacy, with options suggested to protect privacy in practice through group ids instead of ones that identify an individual.

I just have one question. The security considerations section has a lower case 'must' for providing session encryption, but then the privacy section warns that monitoring can be possible when sessions are not encrypted.  When I saw the privacy considerations, I went back to the security section to make sure active attacks against session traffic that was not encrypted was addressed as I didn't see this same 'must' and by that time needed to go back to make sure something as in place.  I'm wondering why these weren't just addressed together since more security things could happen too if sessions were not encrypted (in other words, there could be less text, unless I am missing something and we need more on the security side).  Thanks!

Alvaro Retana No Objection

Comment (2015-04-08 for -12)
No email
send info
This document provides a framework, as such it is not defining the specific final pieces.  Section 2 reads:

   Other LMAP specifications will define an information model, the
   associated data models, and select/extend one or more protocols for
   the secure communication: . . .

I believe there are at least 2 superfluous forward references that the document can live without.

1. Information Model.  For example, in Section 5:

   The protocol model is closely related to the Information Model
   [I-D.ietf-lmap-information-model], which is the abstract definition
   of the information carried by the protocol.  (If there is any
   difference between this document and the Information Model, the
   latter is definitive, since it is on the standards track.)  The
   purpose of both is to provide a protocol and device independent view,
   which can be implemented via specific protocols.  LMAP defines a
   specific Control Protocol and Report Protocol, but others could be
   defined by other standards bodies or be proprietary.  However it is
   important that they all implement the same Information Model and
   protocol model, in order to ease the definition, operation and
   interoperability of large-scale Measurement Systems.

Reference is made to Information Model work in progress that could match this document.  Given the disclaimer in the text about potential differences, I think that leaving a reference in the text could cause confusion.  IOW, I'm suggesting you take out the reference and the disclaimer, and just let the Information Model draft speak for itself.

2. Registry for Performance Metrics.  Section 5.2.2:

   o  the Measurement Task configurations, each of which needs:

      *  the Metric, specified as a URI to a registry entry; it includes
         the specification of a Measurement Method.  The registry could
         be defined by the IETF [I-D.ietf-ippm-metric-registry], locally
         by the operator of the Measurement System or perhaps by another
         standards organisation.

The framework is leaving the door open for multiple ways to define a registry, but is making reference to a specific one (still WIP)..it just causes confusion.


Neither of these comments are major, not do they take away from the technical value of the document.  Mostly suggestions to improve the clarity of what the framework is proposing.