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

[Alissa Cooper <[e-mail]>]

Hi Juergen,

> On Jan 26, 2017, at 3:53 AM, Juergen Schoenwaelder <[e-mail]> wrote:
> 
> On Wed, Jan 25, 2017 at 10:52:08AM -0500, Alissa Cooper wrote:
>> Hi Juergen,
>> 
>> Responses below. I trimmed out areas that don’t need a response.
>> 
> 
> Trimming even further...
> 
>>> 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?
> 
> You can have monolithic or modular implementations. In a modular
> implementation, the version of a metric implementation may change
> without the change of the version of the MA. People with measurement
> experience have often stated how important it is to know precisely
> which version of software was involved in a measurement since this
> often is essential to understand artifacts observed during data
> analysis.

Ok.

> 
>>>> = 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.
> 
> What kind of risks? The device-id is one piece of information that may
> be used by a controller while assigning an agent-id. So it is exposed
> to a controller anyway. And the model does not make any statement that
> an agent-id can only assigned during an initial bootstrap process,
> i.e., a controller may have reasons to re-bootstrap (is that a word?)
> the LMAP agent.

Since the device ID can be an ID that is re-used in all kinds of contexts (e.g., a MAC address), its use creates the potential to correlate LMAP activities with other activities in which the device is engaged, and potentially to identify the user. Again thinking about whether there might be different access control domains *within* a controller, it seems unnecessary to expose something like a MAC address in a status reporting context if the MA can be uniquely identified by the agent ID. Then only the code/people that deal with configuration need authorization to process MAC addresses or other device IDs.

> 
>>> 
>>>> = 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 …."
>> 
> 
> You want me to repeat this sentence
> 
>   [...] 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.
> 
> that is already in section 3.9 in the description of ma-task-functions
> (section 3.9.1)?

No, sorry, I was just suggesting that you add the word “may."

> 
>>> 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.
> 
> Well, an Action refers to a Configured Task, I do not think it is
> correct to say an Action is a Configured Task.

Then why does the text in later sections say "An Action is a Task with additional specific parameters”? That is where I am confused.

Thanks,
Alissa