A Framework for Large-Scale Measurement of Broadband Performance (LMAP)
draft-ietf-lmap-framework-14
Yes
No Objection
Note: This ballot was opened for revision 12 and is now closed.
Alvaro Retana No Objection
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.
(Benoît Claise; former steering group member) Yes
(Alia Atlas; former steering group member) No Objection
(Barry Leiba; former steering group member) No Objection
(Ben Campbell; former steering group member) No Objection
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 :-) )
(Deborah Brungard; former steering group member) No Objection
(Jari Arkko; former steering group member) No Objection
(Joel Jaeggli; former steering group member) No Objection
(Kathleen Moriarty; former steering group member) No Objection
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!
(Spencer Dawkins; former steering group member) No Objection
(Stephen Farrell; former steering group member) No Objection
- 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;-)
(Terry Manderson; former steering group member) No Objection