Re: Review of draft-ietf-lmap-information-model-17

[Juergen Schoenwaelder <[e-mail]>]

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: [phone]         Campus Ring 1 | 28759 Bremen | Germany
Fax:   [phone]         <http://www.jacobs-university.de/>