Re: [lmap] Proposed definition of Cycle-ID and related changes

["Carey, Timothy (Nokia - US)" <[e-mail]>]

Inline <TAC2>

-----Original Message-----
From: Juergen Schoenwaelder [mailto:[e-mail]] 
Sent: Monday, June 13, 2016 8:43 AM
To: Carey, Timothy (Nokia - US)
Cc: MORTON, ALFRED C (AL); [e-mail]; STARK, BARBARA H; [e-mail]
Subject: Re: [lmap] Proposed definition of Cycle-ID and related changes

On Mon, Jun 13, 2016 at 01:36:02PM +0000, Carey, Timothy (Nokia - US) wrote:
> Juergen,
> 
> Inline <TAC>
> 
> -----Original Message-----
> From: Juergen Schoenwaelder 
> [mailto:[e-mail]]
> Sent: Monday, June 13, 2016 6:39 AM
> To: Carey, Timothy (Nokia - US)
> Cc: MORTON, ALFRED C (AL); [e-mail]; STARK, BARBARA H; 
> [e-mail]
> Subject: Re: [lmap] Proposed definition of Cycle-ID and related 
> changes
> 
> On Sat, Jun 11, 2016 at 04:46:35PM +0000, Carey, Timothy (Nokia - US) wrote:
> > Juergen,
> > 
> > There are 3 things that need to be supported
> > 
> > 1) Cycle-Context-ID: Input as an option (we should discuss if this is an option or a tag - I assume option because it is a name/value pair Cycle-Context-ID:MyTest) associated Schedule or Action - We should discuss if this option name should be reserved in LMAP like channel or role.
> 
> Why would this be an option and not just a tag? Options are used to pass information to a running task; I do not think the task needs to know the Cycle-Context-ID since it is a pure organizational matter.
> <TAC> As I understand it tags do not have the capability for a Name and Value - its just a tag. So using a tag I can't know if MyTest tag value is the Cycle-Context-ID. However if I use an option - I could have Cycle-Context-ID name and MyTest value.

A Cycle-Context-ID is generated by a controller and likely meaningful to a piece of software analyzing data collected by a collector. I would assume that the data analysis software will obtain information from the controll about the tags the controller used to tag measurements.

<TAC2> Lets ask Al; what happens if/when the MAs and controllers are not in the same administrative domain - Me I like to be explicit about these things.
 
> > 2) Cycle-ID: As Al said this is generated based on: The MA receives 
> > the form and policy to generate the Cycle-ID as part of the 
> > Instruction's Schedule. The problem I see is "what is the form and 
> > policy that would be used" - We haven't addressed this piece. For 
> > example - there might be a policy to simply increment the 
> > Cycle-number.  If this is part of the knowledge of the task registry 
> > entry then OK; otherwise we might need some enhancements to the 
> > information model
> 
> Hence my proposal is that the implementation creates a unique event-id for every firing event and this event-id is reported with the result. I hope this event-id can be as simple as a counter that I bump whenever an event fires.
> <TAC> Well Cycle-numbers are necessarily tied to a firing of event - I thought it had its own context and definition - which can be tied to a firing of an event -sure but we risk overloading the term event-id. Which I would like to avoid.

So what is then this 'own context and definition' and how would I implement it? I do know how to implement an event-id and from what I understood Al Morton talking about this event-id would give him the means to correlate results.
<TAC2> Correct the Cycle-Number allows you to correlate the results within the context of the Cycle-Context-ID. How the Cycle-Number is calculated is what isn't defined right now and we should discuss how that is defined.

> > 3) Cycle-ID: This option (again name/value pair Cycle-ID:MyTest-1) is reported in the options element of the Result object. We should discuss if this option name should be reserved in LMAP. So a result would have the Cycle-Context-ID (since it was passed as input and echoed) and Cycle-ID in the result tags.
> 
> Tags are already reported back in the result. I am not sure there is anything needed to be done here.
> <TAC> The Cycle-ID is a result of combining the Cycle-Context-ID and the Cycle-Number - So for results - the Cycle-Context-ID is reported as a tag or option but the Cycle-Number is not reported - so we need to report that (or the combined Cycle-ID as an option, tag or as you suggest and I am leary of, an event-id.

My simple minded solution is that the controller tags measurements as it sees fit (this takes care of the Cycle-Context-ID) and the LMAP implementation would add an event-id to the result records, which echoes back the tags already. A data analysis program can then filter on both of them if desired.
<TAC> Yep I see that - Lets just make sure of the assumptions that the Context-ID can be used as a tag and the cycle-number can be restricted to the algorithm that would assign an event-id. Again I just like to be explicit since we do not know how this would work across administrative domains or if the operators would be able enforce a naming convention on a tag so that their system knows this is the Cycle-Context-ID.

/js

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