Subject: [lmap] [information model] ma-task-object issues

From: Holger Wiehen <[email-masked]>
Date: Mon, 23 Jan 2017 13:51:47 -0200

Hi. 

I noticed 2 issues with the ma-task-object (LMAP Information Model).

1) Missing protocol information (OWAMP, TWAMP,…) 

In order to measure the metric specified on a task, coordination will be necessary between the Measurement Agent and a Measurement Peer, in most cases.
Shouldn’t the task indicate the measurement protocol to use, besides the metric to be measured?  In my understanding, the metric coming from the Ippm-Metrics-Registry will be protocol agnostic.
Today we rely on some implicit default for the measurement protocol. Alternatively the task could inform which protocol is to be used for a given metric. This would apply to capabilities (“I support metric X measured with Owamp”) and instructions (“measure metric Y, using Owamp”).

2) Inconsistency with the Yang Data Model

The information model only specifies “ma-task-functions” (Ippm Metrics) for a task.
The data model specifies “functions” (Ippm Metrics) and alternatively a “program” (local executable) to perform a task.
Should the “program” attribute appear in the information model?

Holger Wiehen

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Mon, 23 Jan 2017 19:41:10 +0100

> Today we rely on some implicit default for the measurement protocol. Alternatively the task could inform which protocol is to be used for a given metric. This would apply to capabilities (“I suppor…

Simply use task options. Good enough until we have sufficient
operational experience that something more elaborate is needed.
 
> Should the “program” attribute appear in the information model?

This difference is by design and not by accident. The information
model view is that the registry takes care of everything. The data
model view is that there exists stuff that is not covered by a
(metrics) registry. (And my implementation does not use the registry
at all right now since I have not really figured out how to make this
work.) I think it is fine if a data model 'expands' the information
model.

/js

-- 
Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: +49 421 200 3587         Campus Ring 1 | 28759 Bremen | Germany
Fax:   +49 421 200 3103         <http://www.jacobs-university.de/>

---

From: Holger Wiehen <[email-masked]>
Date: Mon, 23 Jan 2017 19:15:16 -0200

Hi Juergen.

I agree.
Thank’s for your clarification.

Holger Wiehen.

> On 23 Jan 2017, at 16:41, Juergen Schoenwaelder <[email-masked]> wrote:
>