Subject: Re: [lmap] draft-ietf-lmap-information-model-06: Task status object

From: Juergen Schoenwaelder <[email-masked]>
Date: Wed, 23 Sep 2015 17:14:44 +0200

On Tue, Jul 28, 2015 at 02:52:53PM +0000, Carey, Timothy (Timothy) wrote:
> Juergen,
> 
> 
> In the ma-task-status object you have multiple role with a single registry entry for a task. Your description in ma-task-status-obj doesn't seem to add up.
> 
> What if we have a task with multiple metrics (registry entries)?
> 
> You also have a list of roles - but a registry entry would only be executed under 1 role.

My understanding is that a registry entry has at most one role defined
(draft-ietf-ippm-metric-registry-04 section 7.3.6). Hence, it seems the
ma-task-role is not really needed and should be removed.

Al Morton said that a task may generate a single packet train that is
used to obtain multiple metrics. This is why we allow multiple
references to the registry and we expect that tasks will not implement
impossible combinations.
 
> What is the unique functional key of a task status object now - Task Name, RegistryEntry, Role?

I think the key is the ma-task-name:

   ma-task-name:                   A name uniquely identifying a task.

/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: "MORTON, ALFRED C (AL)" <[email-masked]>
Date: Wed, 23 Sep 2015 13:01:35 -0400

Al chimes-in below:

> -----Original Message-----
> From: lmap [mailto:[email-masked]] On Behalf Of Juergen
> Schoenwaelder
> Sent: Wednesday, September 23, 2015 11:15 AM
> To: Carey, Timothy (Timothy)
> Cc: [email-masked]
> Subject: Re: [lmap] draft-ietf-lmap-information-model-06: Task status
> object
> 
> > In the ma-task-status object you have multiple role with a single
> registry entry for a task. Your description in ma-task-status-obj
> doesn't seem to add up.
> >
[ACM] 
I think this is a change from previous text, and not in a good way.
If we have to duplicate registry entries just to indicate a single fixed role
from two possible roles, then we haven't used the Run-Time parameters 
correctly or efficiently, in my opinion.

Yes, we need to give the set of possible roles for each metric *in the entry*.
These roles need to map to the reference text in the Method of measurement.

OTOH, I can see vendors building systems that only support one of two roles,
which is fine. I'd rather that this limitation was handled in protocols,
and not by duplicating registry entries to modify a single column, "Role".

> references to the registry and we expect that tasks will not implement
[ACM] 
Thank you for that.
I would like to see the YANG model synchronized with this feature in the
information model (unless I've missed it somehow).

regards,
Al

> _______________________________________________
> lmap mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/lmap

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Wed, 23 Sep 2015 19:28:20 +0200

> and not by duplicating registry entries to modify a single column, "Role".

So are you saying the text in section 7.3.6 of the registry is wrong?
Or is my understanding of that text wrong? I admit that I do not find
the text very clear. In implementations I am familiar with, the role
is often simply passed as an argument when you invoke a measurement
program (and hence it would not be a separate explicit task attribute
either).

> information model (unless I've missed it somehow).

In the YANG data model (draft-ietf-lmap-yang-01), the registry is a
leaf-list and not a simple leaf, hence it can point to multiple
registry entries.

/js

---

From: "MORTON, ALFRED C (AL)" <[email-masked]>
Date: Wed, 23 Sep 2015 13:55:25 -0400

> From: Juergen Schoenwaelder [mailto:j.schoenwaelder@jacobs-
> university.de]
> Sent: Wednesday, September 23, 2015 1:28 PM
> To: MORTON, ALFRED C (AL)
> Cc: Carey, Timothy (Timothy); [email-masked]
> > > Subject: Re: [lmap] draft-ietf-lmap-information-model-06: Task
> > > status object
> > >
> > > (draft-ietf-ippm-metric-registry-04 section 7.3.6). Hence, it seems
> > > the ma-task-role is not really needed and should be removed.
> > [ACM]
> > If we have to duplicate registry entries just to indicate a single
> > fixed role from two possible roles, then we haven't used the Run-Time
> > parameters correctly or efficiently, in my opinion.
> >
> > OTOH, I can see vendors building systems that only support one of two
> > roles, which is fine. I'd rather that this limitation was handled in
> > protocols, and not by duplicating registry entries to modify a single
> column, "Role".
> 
> the text very clear. In implementations I am familiar with, the role is
> often simply passed as an argument when you invoke a measurement program
> (and hence it would not be a separate explicit task attribute either).
[ACM] 
I think you've understood the text correctly.

I'm saying that the text is not consistent with my understanding of the
agreement reached when Barbara raised the need to identify roles
(which itself was an excellent observation).  But we've discussed this
more than once in meetings, possibly when I wasn't able to attend.
IMO, we've already bent over backwards by attempting to address 
the whole of IETF's scope of metrics. We now need to consider how
all the details will be used in practice.

> 
> > > Al Morton said that a task may generate a single packet train that
> > > is used to obtain multiple metrics. This is why we allow multiple
> > > references to the registry and we expect that tasks will not
> > > implement impossible combinations.
> > [ACM]
> > Thank you for that.
> > I would like to see the YANG model synchronized with this feature in
> > the information model (unless I've missed it somehow).
> 
> leaf-list and not a simple leaf, hence it can point to multiple registry
> entries.
> 
> /js
[ACM] 
Great, that works for me, thanks again.
Al