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

[Juergen Schoenwaelder <[e-mail]>]

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.

> >> = 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.

> > 
> >> = 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)?

> > 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. I think the text I
proposed is more precise.

> >   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/

fixed
 
> >   credentials An opaque type representing credentials needed by a
> >               cryptographic mechanism to security communication.  
> 
> s/security/secure/

fixed

/js

-- 
Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: [phone]         Campus Ring 1 | 28759 Bremen | Germany
Fax:   [phone]         <http://www.jacobs-university.de/>