Russ, thanks for your review. See my response to your comments inline. On Sun, Feb 26, 2017 at 01:09:50PM -0800, Russ Housley wrote: > Reviewer: Russ Housley > Review result: Almost Ready > > I am the assigned Gen-ART reviewer for this draft. The General Area > Review Team (Gen-ART) reviews all IETF documents being processed > by the IESG for the IETF Chair. Please wait for direction from your > document shepherd or AD before posting a new version of the draft. > > For more information, please see the FAQ at > <http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>. > > Document: draft-ietf-lmap-information-model-17 > Reviewer: Russ Housley > Review Date: 2017-02-26 > IETF LC End Date: 2017-03-08 > IESG Telechat date: Unknown > > Summary: Ready > > Major Concerns: > > Section 3.1 says that the pre-configuration information contains > the certificate of the Controller or the certificate of the CA > which issued the certificate for the Controller. Section 3.1.1 > includes ma-preconfig-credentials. Are these the same? The information model on purse is somewhat unspecific about what exactly the security credentials are. The reason is that the information model maps to two data models today (one in the BBF and one in the IETF). The IETF data model can be accessed over NETCONF and RESTCONF. RESTCONF runs over HTTP/TLS while NETCONF by default runs over SSH. As a consequence, the various credentials needed to support the different protocols varies. > Section 6 says that secure communication channels are needed. This > means > that some components of this system (at least the Controller) must > have > secret keys or private keys. I think that Section 6 should talk > about > which components of this system have keys and the consequences if the > keys are not well protected. There is a fairly large discussion of security issues in RFC 7594 and we point to them in section 6 rather than repeating them here. An implementation of this Information Model should support all the security and privacy requirements associated with the LMAP Framework [RFC7594]. > Minor Concerns: > > The Introduction in RFC 7594 says: "There is a desire to be able > to coordinate the execution of broadband measurements and the > collection of measurement results across a large scale set of > Measurement Agents (MAs)." The Fact that LMAP is about broadband > measurements should be stated in the first paragraph of the > Introduction of this document. I suggest to add a sentence including a reference to RFC 7536 so that the 1st paragraph of the Introduction reads: A large-scale measurement platform is a collection of components that work in a coordinated fashion to perform measurements from a large number of vantage points. A typical use case is the execution of broadband measurements [RFC7536]. The main components of a large- scale measurement platform are the Measurement Agents (hereafter MAs), the Controller(s) and the Collector(s). > Nits: > > In Section 3, the reason for the 6 categories should probably be > placed before the list instead of several paragraphs later. I agree, I have moved the text up (and due to some other comment we started to call the categories 'aspects'). So the new text reads: The information model is divided into six aspects. Firstly the grouping of information facilitates reader understanding. Secondly, the particular groupings chosen are expected to map to different protocols or different transmissions within those protocols. > In 3.1: s/If the MA ID is not provided at this stage then/ > /If the MA ID is not provided at this stage, then/ fixed /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany Fax: +49 421 200 3103 <http://www.jacobs-university.de/>