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