I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG.  Document editors and WG chairs should treat these comments just like any other last call comments. Summary: It's fine, though I couldn't resist making a few suggestions. LMAP is apparently a strained acronym for "Large-scale Measurement of Access network Performance", a collection of protocols designed for measuring the capacity and responsiveness of connectivity provided by broadband ISPs, though there may have been some feature creep as the protocols are sufficiently general to be used for other things. This document is a framework document defining terms and providing an overview of the intended deployment model (and intended to be INFORMATIONAL). There are companion I-Ds specifying individual protocols in more detail. As such, most of the security considerations would be discussed in those documents, though this overview document provides an overview of the types of security considerations to be discussed in those documents. The major components of LMAP are a Measurement Agent (MA) usually residing on customer premises that runs periodic performance tests and reports results, a Controller usually residing off-customer-premises that configures some large collection of Measurement Agents, and a Collector usually residing off-customer-premises that receives and records reports from the Measurement Agents. Those reports may contain statistical data concerning normal operation of the MA's platform as well as the results of specific tests. It is the Controller to MA and MA to Collector protocols that will require rigorous security analysis and which are specified in different documents within LMAP. The protocols whose performance is measured may also require a rigorous security analysis, but they are defined outside of LMAP. The security considerations section lists the sorts of issues that will need to be dealt with in the other documents. It does not go into how those issues are addressed; presumably the companion documents do. There is a much longer privacy considerations section that enumerates an intimidating set of potential privacy abuses that need to be mitigated. An important security consideration that I didn't see was dealing with the case of a corrupted MA that reports falsified information to the collector. This might occur in the case where a customer wants it to appear that the ISP is not meeting its commitments when in fact the ISP is. Whether this can be effectively mitigated depends on the platform on which the MA is deployed, but where the MA is deployed on a customer-controlled platform it must be recognized that the data collected is to some degree inherently untrustworthy. This means, for example, that in such configurations the data should not be used as the basis for a customer to get refunds of subscription fees. I saw two questionable aspects of the design (at this level of abstraction). The first has to do with who initiates the Controller to MA connection. This spec seems to imply that the connection can be initiated from either end... the Controller can initiate a connection to the MA when it wants to update the MA's configuration and the MA and initiate a connection to the controller to report errors and log debugging information. This is problematic for several reasons. Most importantly, in many scenarios the MA might move around and therefore be difficult for the Controller to find; or it might be behind a NAT or other firewall and might not be capable of accepting incoming connections (at least not without a lot of additional effort). If all such connections were initiated by the MA, including a polling interval configured by the controller, such configuration issues go away. Alternately, if the Controller initiated all connections, it becomes much easier to protect the Controller from DoS attacks, since it is generally much easier to attack a server than a client. But having connections being initiated from both directions gives the worst of both worlds. The second has to do with the MA sending error and log reports to the Controller. While it makes sense for the MA to report errors that occur in processing Controller Instructions in the responses to those commands, errors and logged events that occur asynchronously would seem (to me anyway) as more naturally being sent to the Collector, since its job is to harvest massive amounts of information from lots of MAs. It is likely to be more highly replicated and load balanced than the Controller, and thus more capable of handling bursty loads. But this has little to do with security, and I throw it out only for your consideration. Radia