Re: [ippm] [lmap] I-D Action: draft-ietf-lmap-framework-05.txt

["Bajpai, Vaibhav" <[e-mail]>]

On 30 May 2014, at 16:14, STARK, BARBARA H <[e-mail]> wrote:

>> Doesn't become too complicated? What is the difference between the
>> Measurement Method Role and Measurement Task and why do we need
>> the two distinct terms? Maybe it would help if you can provide a definition of
>> Measurement Method Role because I frankly cannot compile ' Measurement
>> Task is an instantiation of a Measurement Method Role', in other words why
>> do we need a generic term and an instantiation?
> 
> The information model says:
>   The Measurement Task Configuration will include ...  a registry
>   entry [I-D....-ippm-...] that defines the Measurement
>   Task.  The MA itself will resolve the registry entry to a local
>   executable program.  In addition the Measurement Task is specialised
>   through a set of configuration Options.  The nature and number of
>   these Options will depend upon the Measurement Task and will be
>   defined in the Measurement Task Registry.

The framework document [1] makes the measurement method refer to the IPPM metrics registries.
The information model (IM) [2] on the other hand, makes the measurement task refer to the 
IPPM metrics registries. If we really want to use both Measurement Method and Measurement Task 
terminologies, perhaps we need to update the IM to adhere better to the framework document:

   object {
       string              ma-method-name;
       urn                 ma-method-registry;
       ma-task-obj         ma-task-obj<0..*>;
   } ma-method-obj; 

   object {
       string              ma-task-name;
       string              ma-task-options<0..*>;
      [string              ma-task-cycle-id;]
   } ma-task-obj; 

> So the information-model makes the Measurement Task an instantiation of a local executable program. But how does the Controller learn about what registry entries the MA is capable of resolving to local executable programs? That is, how does the Controller know what local executable programs exist on the MA? I had thought this would be part of the capabilities that get reported to the Controller by the MA. Bu the ma-capability object has some distinct other undefined measurement-id urn and doesn't provide the Controller with any list of registry entries that the MA is capable of resolving. Hopefully, this is just something that needs to be fixed in the information-model, and not an intentional lack of relationship between ma-capability and ma-task (or ma-task-registry). 

I also think so:

   object {
       urn                 ma-measurement-id;
      [string              ma-measurement-version;]
       ma-task-obj         ma-task-obj<0..*>;
   } ma-capability-obj;

The ma-tasks<0...*> objects sent in the instruction object will now be subset of the
the ma-tasks<0…*> objects sent by the MA.


> Anyway, information-model says (wrt capability reporting) that "Capabilities include ... the set of Measurement Tasks that are actually installed or available on the MA." This, to me, is a problematic statement. Now, not only is the term Measurement Task being used to describe an instantiation of a local executable program with a specific set of values for input parameters (ma-task-options<0..*>) and perhaps a particular cycle id (ma-task-cycle-id) with a pointer to the local executable program (ma-task-registry), the term is also being used as synonymous with the local executable program. 
> 
> I do not think that "Measurement Task" should be used as another name for the local executable program. I would like to see this fixed. It would also appear that the ma-capability object is supposed to be the object that provides the information regarding these local executable programs that are installed/available on the MA. But the word "capabilities" is also said to include interface details. So "local executable programs" is a subset of "capabilities" (which means "capabilities" is also not an appropriate word to use to just mean "local executable programs"). 
> 
> So do these "local executable programs" need a better name, so we aren't tempted to call them "Measurement Task"? Or maybe we can just call them "Local Executable Programs”

A locally executable program can be any program (for e.g. ls) within the MA, no? 
Shouldn’t we restrict the terminology to programs that do measurements?

> and define them as functionality in a MA that allows the MA to perform a specific role of a Measurement Method. And Measurement Task is an instantiation of a Local Executable Program. Because Measurement Task is definitely not an instantiation of the holistic Measurement Method. The ping initiator Local Executable Program can be completely distinct from the ping responder Local Executable Program. And it often is.
> Barbara

[1] http://tools.ietf.org/html/draft-ietf-lmap-framework-05
[2] http://tools.ietf.org/html/draft-ietf-lmap-information-model-00

Best, Vaibhav

-----------------------------------------------------
Vaibhav Bajpai

Research I, Room 86
Computer Networks and Distributed Systems  (CNDS) Lab
School of Engineering and Sciences
Jacobs University Bremen, Germany

www.vaibhavbajpai.com