Subject: Re: [lmap] info model issues list

From: Juergen Schoenwaelder <[email-masked]>
Date: Fri, 23 Oct 2015 23:13:20 +0200

On Wed, Sep 30, 2015 at 09:39:52PM +0000, Carey, Timothy (Timothy) wrote:
> Juergen,
> 
> I check this list against my list and have the following comments:
> 
> Missing: We need to put back the [ma-condition-obj ma-conditions<..*> to allow for conditions or status not specified by the IM.
>

I am not sure I understand this, can you please elaborate? The IM does
not define a fixed set of status codes as far as I can tell.

> Missing: Could we add the issue for the IM to describe its interaction with the registry - parameters, outputs, roles...

Does this have to part of the IM? Right now this is discussed in a
separate document, draft-morton-lmap-examples-00.txt.
 
> LI05: When we talk about MA reporting its task capabilities - Could we note that we have to report the Registry entry capabilities associated with the task. I would suspect that for each supported task the capabilities (parameters, outputs, roles) might change by MA.

Yes, this is what LI05 is all about and I think the next version will
have this addressed.

/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: "Carey, Timothy (Timothy)" <[email-masked]>
Date: Sat, 24 Oct 2015 10:59:20 +0000

Inline <TAC>

-----Original Message-----
From: Juergen Schoenwaelder [mailto:[email-masked]] 
Sent: Friday, October 23, 2015 4:13 PM
To: Carey, Timothy (Timothy)
Cc: [email-masked]
Subject: Re: [lmap] info model issues list

> Missing: We need to put back the [ma-condition-obj ma-conditions<..*> to allow for conditions or status not specified by the IM.

I am not sure I understand this, can you please elaborate? The IM does not define a fixed set of status codes as far as I can tell.
<TAC> IM-draft-04 had MA conditions as part of the IM. We need that put back as it disappeared in IM-draft-05.
   // Main MA Status information object

   object {
       uuid                    ma-agent-id;
       urn                     ma-device-id;
       string                  ma-hardware;
       string                  ma-firmware;
       string                  ma-version;
       ma-interface-obj        ma-interfaces<0..*>;
       ma-task-capability-obj  ma-supported-tasks<0..*>;
       datetime                ma-last-started;
      [ma-condition-obj        ma-conditions<0..*>;]
      [ma-task-status-obj      ma-task-status<0..*>;]
   } ma-status-obj;

> Missing: Could we add the issue for the IM to describe its interaction with the registry - parameters, outputs, roles...

Does this have to part of the IM? Right now this is discussed in a separate document, draft-morton-lmap-examples-00.txt.
<TAC> Ok by me as long as it get documented.
 
> LI05: When we talk about MA reporting its task capabilities - Could we note that we have to report the Registry entry capabilities associated with the task. I would suspect that for each supported…

Yes, this is what LI05 is all about and I think the next version will have this addressed.
<TAC> Thanks - looking forward to the next version.

/js

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Tue, 27 Oct 2015 10:18:37 +0100

>       [ma-task-status-obj      ma-task-status<0..*>;]

You need to help me to understand what these ma-condition-objs are
supposed to do. There were no further descriptions in -04 and hence I
am a bit clueless which purpose these ma-condition-objs serve.

/js

---

From: "Carey, Timothy (Timothy)" <[email-masked]>
Date: Tue, 27 Oct 2015 12:54:37 +0000

Juergen,

These were conditions present on the MA at the time that would/could effect its operation. What we realized was that given the varying nature of MAs the conditions would be specific to the type of MA and its hosting environment so the IM would only reflect a code and value combination.

For example in a STB conditions could include IP stream buffer over run or a constrained device might have a RAM threshold exceeded or Zombie processes.

Honestly - I think if we report conditions it ought to be related to the latest task status because that would provide conditions that affected the last task run; seems to be more useful to me. That way test designers could possibly add these to outputs of tests? Have to ask Al Morton if conditions of a task makes sense to place in the registry. 

BR,
Tim

-----Original Message-----
From: Juergen Schoenwaelder [mailto:[email-masked]] 
Sent: Tuesday, October 27, 2015 4:19 AM
To: Carey, Timothy (Timothy)
Cc: [email-masked]
Subject: Re: [lmap] info model issues list

On Sat, Oct 24, 2015 at 10:59:20AM +0000, Carey, Timothy (Timothy) wrote:
> From: Juergen Schoenwaelder 
> [mailto:[email-masked]]

You need to help me to understand what these ma-condition-objs are supposed to do. There were no further descriptions in -04 and hence I am a bit clueless which purpose these ma-condition-objs serve.

/js

---

From: "MORTON, ALFRED C (AL)" <[email-masked]>
Date: Tue, 27 Oct 2015 09:24:55 -0400

Hi Tim and Juergen,

If I understand the scope of this topic and the intent:
> Have to ask Al
> Morton if conditions of a task makes sense to place in the registry.
>
We once had a registry column for "Environmental" conditions
in a *very* early version of the registry.

While we agreed this is an important factor, IPPM discussion
concluded that it was beyond the scope of the performance metrics 
registry, IIRC. I think we need to express system conditions in the
info model.

It seems we need a clear(er) division of responsibilities and 
scope between the PM registry and the info model, although I think
we are close to that understanding.

regards,
Al

> From: lmap [mailto:[email-masked]] On Behalf Of Carey, Timothy
> (Timothy)
> Sent: Tuesday, October 27, 2015 8:55 AM
> To: Juergen Schoenwaelder
> Cc: [email-masked]
> These were conditions present on the MA at the time that would/could
> effect its operation. What we realized was that given the varying nature
> of MAs the conditions would be specific to the type of MA and its
> hosting environment so the IM would only reflect a code and value
> combination.
> 
> For example in a STB conditions could include IP stream buffer over run
> or a constrained device might have a RAM threshold exceeded or Zombie
> processes.
> 
> Honestly - I think if we report conditions it ought to be related to the
> latest task status because that would provide conditions that affected
> the last task run; seems to be more useful to me. That way test
> designers could possibly add these to outputs of tests? Have to ask Al
> Morton if conditions of a task makes sense to place in the registry.
> 
> BR,
> Tim
> 
> 
> 
> > > Missing: We need to put back the [ma-condition-obj ma-
> conditions<..*> to allow for conditions or status not specified by the
> IM.
> > >
> >
> > <TAC> IM-draft-04 had MA conditions as part of the IM. We need that
> put back as it disappeared in IM-draft-05.
> supposed to do. There were no further descriptions in -04 and hence I am
> a bit clueless which purpose these ma-condition-objs serve.
> 
> /js
> 
> --
> _______________________________________________
> lmap mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/lmap

---

From: "Carey, Timothy (Timothy)" <[email-masked]>
Date: Tue, 27 Oct 2015 13:27:22 +0000

Al,

Thanks - then we will need to have the conditions reported with the task status and part of the Report result.

BR,
Tim

-----Original Message-----
From: MORTON, ALFRED C (AL) [mailto:[email-masked]] 
Sent: Tuesday, October 27, 2015 8:25 AM
To: Carey, Timothy (Timothy); Juergen Schoenwaelder
Cc: [email-masked]
Subject: RE: [lmap] info model issues list

Hi Tim and Juergen,

> Morton if conditions of a task makes sense to place in the registry.
We once had a registry column for "Environmental" conditions in a *very* early version of the registry.

While we agreed this is an important factor, IPPM discussion concluded that it was beyond the scope of the performance metrics registry, IIRC. I think we need to express system conditions in the info model.

It seems we need a clear(er) division of responsibilities and scope between the PM registry and the info model, although I think we are close to that understanding.

regards,
Al

> effect its operation. What we realized was that given the varying 
> nature of MAs the conditions would be specific to the type of MA and 
> its hosting environment so the IM would only reflect a code and value 
> combination.
> 
> For example in a STB conditions could include IP stream buffer over 
> run or a constrained device might have a RAM threshold exceeded or 
> Zombie processes.
> 
> Honestly - I think if we report conditions it ought to be related to 
> the latest task status because that would provide conditions that 
> affected the last task run; seems to be more useful to me. That way 
> test designers could possibly add these to outputs of tests? Have to 
> ask Al Morton if conditions of a task makes sense to place in the registry.
> 
> BR,
> Tim
> 
> 
>

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Tue, 27 Oct 2015 15:12:32 +0100

> Honestly - I think if we report conditions it ought to be related to the latest task status because that would provide conditions that affected the last task run; seems to be more useful to me. Tha…

Yes. The -06 version has a status/message pair associated with a task
status object (section 3.5.2). Since a configured task can be used by
multiple actions, -07 will have the status/message pair associated
with an action status object.

/js

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Tue, 27 Oct 2015 15:14:55 +0100

> we are close to that understanding.

I think we discussed this in LMAP and concluded that if you want to
know "environmental" conditions, you run a task that collects and
exports "environmental" conditions like any other measurement result.
Such a task may choose to not refer to something defined in the IPPM
registry.

/js

---

From: "Carey, Timothy (Timothy)" <[email-masked]>
Date: Tue, 27 Oct 2015 14:30:53 +0000

Juergen,

Ok - so we will have to run a parallel "conditions" task along with the test we want to perform.
I am ok with that direction.  Al - what do you think?

BR,
Tim

-----Original Message-----
From: Juergen Schoenwaelder [mailto:[email-masked]] 
Sent: Tuesday, October 27, 2015 9:15 AM
To: MORTON, ALFRED C (AL)
Cc: Carey, Timothy (Timothy); [email-masked]
Subject: Re: [lmap] info model issues list

On Tue, Oct 27, 2015 at 09:24:55AM -0400, MORTON, ALFRED C (AL) wrote:
> While we agreed this is an important factor, IPPM discussion concluded 
> that it was beyond the scope of the performance metrics registry, 
> IIRC. I think we need to express system conditions in the info model.
> 
> It seems we need a clear(er) division of responsibilities and scope 
> between the PM registry and the info model, although I think we are 
> close to that understanding.
>

I think we discussed this in LMAP and concluded that if you want to know "environmental" conditions, you run a task that collects and exports "environmental" conditions like any other measurement result.
Such a task may choose to not refer to something defined in the IPPM registry.

/js

---

From: "MORTON, ALFRED C (AL)" <[email-masked]>
Date: Tue, 27 Oct 2015 10:38:13 -0400

Yes, the parallel task to collect conditions works for me,
thanks for the suggestion, Juergen.

Al

> From: Carey, Timothy (Timothy) [mailto:[email-masked]]
> Sent: Tuesday, October 27, 2015 10:31 AM
> To: Juergen Schoenwaelder; MORTON, ALFRED C (AL)
> Cc: [email-masked]
> I think we discussed this in LMAP and concluded that if you want to know
> "environmental" conditions, you run a task that collects and exports
> "environmental" conditions like any other measurement result.

---

From: "STARK, BARBARA H" <[email-masked]>
Date: Tue, 27 Oct 2015 18:10:51 +0000

> Yes, the parallel task to collect conditions works for me, thanks for the
> suggestion, Juergen.
> 
> Al

Yes. That was what I thought we'd previously agreed to, also.
Barbara
 
> > From: Carey, Timothy (Timothy)
> > [mailto:[email-masked]]
> > > registry, IIRC. I think we need to express system conditions in the info
> model.
> > >