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

[Alissa Cooper <[e-mail]>]

Hi Juergen,

Responses below. I trimmed out areas that don’t need a response.

> On Jan 24, 2017, at 11:07 AM, Juergen Schoenwaelder <[e-mail]> wrote:
> 
> Alissa,
> 
> thanks for your review - much appreciated. Some of the questions
> indeed touch on the question 'what needs to be dealt with in an
> information model and what can be left out', which I think has no
> clear answer. Please see my response inline...
> 
> On Mon, Jan 23, 2017 at 02:22:25PM -0500, Alissa Cooper wrote:
> 
>> = 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.
> 
> I agree. And I think this is not only relevant for group IDs but equally
> applies to tags or other names that can be freely choosen. What about this
> at the end of the Security Considerations:
> 
>   [...] In addition, users of this Information Model are
>   advised to choose identifiers for Group IDs, tags or names of
>   information model objects (e.g., configured tasks, schedules or
>   actions) that do not reveal any sensitive information to people
>   authorized to process measurement results but who are not authorized
>   to know details about the Measurement Agents that were used to
>   perform the measurement.

Sounds good. 

> 
>> = 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.
>> 
> 
> Names of objects are generally assumed to be unique within an MA.

I think it’s worth saying that explicitly.

> 
> The version here is essentially used to be able to distinguish
> different versions of an implementation of a given metric. I might
> have MAs with an old version of a metric implementation with specific
> bugs and I might have MAs with a new version of a metric
> implementation with different kind of bugs.

Is there a reason that level of detail is needed on a metric-by-metric basis, as opposed to just using a software version number for the implementation as a whole?

> 
>> = 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)?
> 
> We could make the ma-status-device-id optional to be consistent.

That sounds better but I still think you need to justify it being there, even as optional. Up to this point I thought the device ID was used potentially to generate an agent ID during configuration, but after that it seems to create unnecessary risk to include it in status reports.

> 
> 
>> = 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.
> 
> Creating an LMAP task registry was briefly discussed on the mailing
> list but so far no concrete proposal has been written. I think the
> definition in section 3.9 is actually fine since it does not refer
> explicitely to the IPPM metrics registry.

I think it would help if it said "Both measurement and non-measurement Tasks may have registry entries …."


> 
>> (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?
> 
> The set of referenced regristry entry entries can be empty. The phrase
> 'or a local specification of the task' is indeed confusing. What is
> meant here is a task that is essentially well-known by its name. For
> example, there is a task called 'traceroute' or 'iperf' and I expect
> it to do a traceroute or to run iperf measurements. Perhaps the text
> should be changed to read:
> 
>   A configured task can be referenced by its name and it
>   contains a possibly empty set of URIs to link to registry entries.

That would help, yes.

> 
>> = 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. 
>> 
> 
> An entry in the metrics registry may define multiple roles. The
> ma-registry-role selects which of these roles are instantiated.

Got it, ok.

> 
>> Nits and minor comments:
> 
>> = Section 3 =
>> 
>> (1) s/(from a measurement to reporting or communicating with the Controller)/(including measurements or reporting or communicating with the Controller)/
> 
> fixed
> 
>> (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.
> 
> I agree - Actions came in later and it still shows. I will see what I
> can do to reword this. What about this:
> 
>> (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.
> 
> What about this (right below Figure 1):
> 
>   The primary function of an MA is to execute Schedules.  A Schedule,
>   which is triggered by an Event, executes a number of Actions.  An
>   Action refers to a Configured Task and it may feed results to a
>   Destination Schedule.  Both, Actions and Configured Tasks can provide
>   parameters, represented as Action Options and Task Options.

Some minor tweaks:

The primary function of an MA is to execute Schedules.  A Schedule,
  which is triggered by an Event, executes a number of Actions.  An
  Action is a Configured Task and it may feed results to a
  Destination Schedule.  Both Actions and Configured Tasks can provide
  parameters, represented as Action Options and Task Options.

> 
>> = 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.
> 
> The point is that the cycle-number is a fixed-point _number_.

Ok, fair enough.

> 
> To address the questions (above) concerning the semantics of several
> base types we have used, I think it makes sense to add the following
> to section 2:
> 
>   The object definitions use a couple of base types that are defined as
>   follows:
> 
>   int         A type representing signed or unsigned integer numbers.
>               This information model does not define a precision nor
>               does it make a distinction between signed and unsigned
>               number ranges.  This type is also used to represent
>               enumerations.
> 
>   boolean     A type representing a boolean value.
> 
>   string      A type representing a human-readable strings consisting
>               of a (possibly restricted) subset of Unicode and ISO/IEC
> 	       10646 [ISO.10646] characters.

s/strings/string/

> 
>   datetime    A type representing a date and time using the Gregorian
>               calendar.  The datetime format MUST conform to RFC 3339
>               [RFC3339].
> 
>   uuid        A type representing Universally Unique IDentifier (UUID(
>               as defined in RFC 4122 [RFC4122].  The UUID values are
>               expected to be unique within an installation of a large-
>               scale measurement system.
> 
>   uri         A type representing a Uniform Resource Identifier as
>               defined in STD 66 [RFC3986].
> 
>   ip-address  A type representing an IP address.  This type supports
>               both IPv4 and IPv6 addresses.
> 
>   counter     A non-negative integer that monotonically increases.
> 	       Counters may have discontinuities and they are not
> 	       expected to persist across restarts.
> 
>   credentials An opaque type representing credentials needed by a
>               cryptographic mechanism to security communication.  

s/security/secure/

Thanks,
Alissa