On 2017-03-14 09:53, Juergen Schoenwaelder wrote: > 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. > You keep missing my point which is this: I understand the difference between a data model and an information model. What I don't understand is if you need one or two credentials in the information model. Cheers LEif >> 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 >