Subject: [lmap] Information Model - Proposed changes to 04

From: <[email-masked]>
Date: Mon, 16 Feb 2015 13:47:41 +0000

For anyone who didn't manage to attend the interim, here are the slides and proposals for the Information Model:
http://www.ietf.org/proceedings/interim/2015/02/12/lmap/slides/slides-interim-2015-lmap-1-1.pptx

In summary the main proposals are:
- To keep the JSON example data model (with corrections) and to also add to the references the YANG data model (draft-schoenw-lmap-yang)
- To standardise the well-known objects for Channel and Role, even though they are optional task parameters to aid interworking across different tasks
- To evolve the current general MA status information into MA and task specific status information
- To evolve the current general MA condition codes into MA and task specific condition codes
- Clarify that options for a scheduled task are appended to the options specified for the general task configuration

Any additional comments and suggestions are welcome until 23rd February, after which I will go ahead and make the changes. Please don't bother sending spelling corrections as I have already spellchecked it (and made the other minor corrections already suggested) ready for the more substantive 04 changes.

Trevor.

Trevor Burbridge
Network Infrastructure & Innovation | BT Research & Innovation
Tel: 01473 645115
Fax: 01473 640929

This email contains BT information, which may be privileged or confidential. It's meant only for the individual(s) or entity named above. If you're not the intended recipient, note that disclosing, copying, distributing or using this information is prohibited. If you've received this email in error, please let me know immediately on the email address above. Thank you.
We monitor our email system, and may record your emails. 
British Telecommunications plc
Registered office: 81 Newgate Street London EC1A 7AJ
Registered in England no: 1800000

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Mon, 16 Feb 2015 16:17:16 +0100

Hi,

there were a few more things mentioned on the list:

- introducing a configuration version number to avoid having to send
  the complete config back with reports; do we really want to assume
  that config is echoed with each report?
- clarify the semantics of feeding data between tasks following
  different schedules, buffering and blocking issues
- status (condition) codes - do we want to have common ones or is every
  data model / protocol free to invent their own codes?

/js

On Mon, Feb 16, 2015 at 01:47:41PM +0000, [email-masked] wrote:
> _______________________________________________
> lmap mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/lmap

-- 
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: <[email-masked]>
Date: Tue, 17 Feb 2015 10:03:02 +0000

See inline...

>-----Original Message-----
>From: Juergen Schoenwaelder [mailto:[email-masked]]
>Sent: 16 February 2015 15:17
>To: Burbridge,T,Trevor,TUB8 R
>Cc: [email-masked]
>Subject: Re: [lmap] Information Model - Proposed changes to 04
>
>Hi,
>

We've said that the flexibility of what to report is under the control of the reporting task implementation and configuration options. At the moment the task options are optional to be reported, but the task configuration has a text string name which is always reported. I thought this was sufficient but if we want a name AND version number we could add another field.

Having said that I do think we do need to make a change since it is only the task configuration name (and options) that are reported. I need to add in the schedule name and scheduled task options.

>  different schedules, buffering and blocking issues

I'll do this in a separate example. I don't think there is a problem with the Information Model, but we'll see.

>  data model / protocol free to invent their own codes?

Yes, this has been a question for a while, but I don't have any proposals to put into the next iteration of the Information Model.

>> - To keep the JSON example data model (with corrections) and to also
>> add to the references the YANG data model (draft-schoenw-lmap-yang)
>> - To standardise the well-known objects for Channel and Role, even
>> though they are optional task parameters to aid interworking across
>> different tasks
>> - Clarify that options for a scheduled task are appended to the
>> options specified for the general task configuration
>>
>> Any additional comments and suggestions are welcome until 23rd February,
>after which I will go ahead and make the changes. Please don't bother sending
>spelling corrections as I have already spellchecked it (and made the other minor
>corrections already suggested) ready for the more substantive 04 changes.
>>
>> Trevor.
>>
>> Trevor Burbridge
>> This email contains BT information, which may be privileged or confidential. It's
>meant only for the individual(s) or entity named above. If you're not the intended
>recipient, note that disclosing, copying, distributing or using this information is
>prohibited. If you've received this email in error, please let me know immediately
>on the email address above. Thank you.
>> Registered office: 81 Newgate Street London EC1A 7AJ Registered in
>> England no: 1800000
>>
>>