[lmap] AD evaluation: draft-ietf-lmap-information-model-16

[Alissa Cooper <[e-mail]>]

I have reviewed this document in preparation for IETF last call. I have a few substantive comments and questions that I’d like to discuss before issuing the LC. I’ve also included some nits and minor comments that should be resolved together with any IETF LC comments.

Substantive comments and questions:

For a number of my comments below, it might be the case that you think the detail I'm asking for does not belong in the information model, but would be more appropriate in a specification of a specific data model or protocol. I'm not particularly wedded to any of these details appearing here, but I do think they need to appear somewhere, so if they're not going to be specified here I think this document needs to explain that data models and/or protocols need to specify them.

= String type definition =

Is it expected that data models and/or protocols will define what character encoding is expected for the string data type? If so, it would be good to say that somewhere.

= Credentials: Section 3.1, 3.2, 3.8, 6 =

I have a couple of questions about how credentials are defined and used in this document:

(1) Is it expected that data models and/or protocols will define the 'credential' type and format? If so, it would help to make that clear up front.

(2) Are ma-preconfig-credentials and ma-config-credentials meant to be credentials only for the MA to be authenticated by a Controller or Collector? I assume that the credentials that allow the MA to authenticate other endpoints, and to protect communications to those endpoints, are stored in ma-channel-credentials, but it would help to clarify which set of credentials each of these fields is referring to.

(3) I'm a little concerned that both ma-config-control-channels and ma-config-credentials are mandatory fields in ma-config-obj, and that the point of having them specified there is to override the pre-configuration information. If I'm understanding correctly, this means that an MA could be preconfigured with certificates it uses to authenticate and encrypt its initial request to a Controller, and the Controller could then respond by saying, "don't use those credentials for yourself or for me, but use these other ones instead." How can an MA then distinguish between a Controller it should trust and one that has been compromised? I know the bootstrapping process is generally out of scope for LMAP, but that scenario seems to imply a security threat that was not specifically contemplated in the framework. Since the fields are being defined here, I think this document needs to discuss these implications, or explain whether there is some (two-way) exchange expected between the MA and the Controller using all the pre-configured credentials that needs to happen before the MA agrees to use different sets of credentials provisioned by the Controller.  

= Section 3.1.1, 3.4.1, 3.5.3 =

I think you need to specify the scope within which uuids are expected to be unique, and whether the same uuids are expected to be re-used for config, logging, and status.

= Section 3.2 =

I think it would be good to provide some guidance about how NOT to construct a group ID. E.g., I would assume putting sensitive information like "low-income neighborhood" or similar in the group ID would be ill-advised, because even within the single administrative domain where MAs are communicating with Controllers and Collectors, there may be people who are authorized to process the measurement data but not know that level of detail about which kind of group a device/connection belongs to. In that kind of case a mapping between an opaque identifier in the group ID and more contextual information on the Controller/Collector back-end would be wise. I think the draft would benefit from some explanation of that here or in Section 6 with a cross-reference back to here.

= Section 3.5.2 =

What would be the cause for defining different versions of the same task? Also, since the two different versions would have the same name (presumably), I think you need to state of the expected scope of uniqueness of the task name.

= Section 3.5.3 =

Why does this object need both an agent ID and a device ID? Is the device ID here expected to be the same as the one that gets pre-configured on the device? What is an MA supposed to put in the device-id field defined here if there was no device ID pre-configured (since in pre-configuration it's an optional field)?

= Section 3.5.4 =

Are ma-status-schedule-invocations, ma-status-schedule-suppressions, and ma-status-schedule-overlaps meant to report counters over all of time, or only since ma-status-last-started? I think this needs to be clarified.

= Section 3.5.5 =

Same question as 3.5.4 for the counters in this section.

= Section 3.9 and 3.9.1 =

"Both measurement and non-measurement
   Tasks have registry entries to enable the MA to uniquely identify the
   Task it should execute and retrieve the schema for any parameters
   that may be passed to the Task.
   ...
A configured task can be referenced by its name and it
   contains a set of URIs to link to registry entries or a local
   specification of the task.
   ...
ma-task-functions:        A possibly empty unordered set of registry
                             entries identifying the functions of the
                             configured task."

I have a couple of questions about this:

(1) Are there any registries being defined for non-measurement tasks, or is this just indicating that such registries could be created? I think it would help to clarify since there is obviously the metrics registry for measurement tasks.

(2) I don't understand "or a local specification of the task." Is that local specification supposed to be represented with a local URI, the same as other registry objects? Or if not, is ma-task-functions not properly defined, since it's possible to reference something other than a registry entry there?

= Section 3.10.1 =

I don't understand why ma-registry-role is defined here. In draft-ietf-ippm-metric-registry, the role is part of the registry entry, so by specifying the URI, one should know which role is the appropriate one for that entry. 


Nits and minor comments:

= Section 1 =

s/Large Measurement platform/Large-Scale Measurement platform/

= Section 3 =

(1) s/(from a measurement to reporting or communicating with the Controller)/(including measurements or reporting or communicating with the Controller)/

(2) It seems a bit odd that Action first appears in Figure 1 but is not included in the enumerated list of objects above it.

(3) "Every Action contained in a Schedule is defined as a Task. ... Tasks can implement a variety of different types of Actions." I think this will be confusing to readers because it's circular. It sounds like all Actions are Tasks but Tasks are comprised of Actions; I think the abstraction needs to be explained better, and made consistent. See also sections 3.3 and 3.7: "An Action is a Task with additional specific parameters." I think it would be better to define what an Action is once at its earliest use.

= Section 3.1.1 =

s/set of tasks objects/set of task objects/

= Section 3.2 =

OLD
The reporting of a
   Group ID without the MA ID allows the MA to remain anonymous

NEW
The reporting of a
   Group ID without the MA ID may allow the MA to remain anonymous

(Rationale: Given all of the other data and potential identifiers the MA may report, it may still be possible for a Collector or other entity to identify the MA -- not providing an agent ID helps, but does not guarantee anonymity.)

= Secion 3.3 =

s/This enabled fine/This enables fine/

= Section 3.3.2 =

Please add a citation for POSIX.2 fnmatch().

= Section 3.5.4, 3.5.5, and 3.5.6 =

To reduce redundancy I would suggest defining the values 'enabled,' 'suppressed,' 'disabled,' and 'running' outside of all of these sections one time and then within the field definitions just saying which values are valid for each field that uses them.

= Section 3.6 =

s/Where the Configuration/Whereas the Configuration/

(Right? I couldn't quite parse the sentence.)

= Section 3.6.2 =

I think it would be good to provide a short explanation in the text as to why RFC 3339 format is not being used for ma-report-result-cycle-number.

= Section 3.8 =

s/it's own/its own/

= Section 6 =

OLD
This would, for example, allow the MA to remain
   anonymous

NEW
This may, for example, allow the MA to remain
   anonymous

(Same rationale as 3.2.)