1. Information Model for LMAP draft-ietf-lmap-information-model-02 (and beyond!) IETF Interim, Dublin, September 2014 Trevor Burbridge, BT 1

2. Motivation Overall Purpose – Guide standardisation of one or more control and reporting protocols – Enable high-level interoperability between protocols – Clarify MA information and functionality Structure – Assist protocols in breaking information down into separate messages that can be delivered at different times over different protocols – Aid readability 2

3. Information Model Sections Pre-Configuration Configuration Instruction Logging Capability & Status Reporting Minimal set of information necessary for an MA to securely contact an initial Controller Information configured by the Controller pertaining to Controller communication or general MA settings such as MA and Group ID Configuration by the Controller of what Measurement Tasks to perform, when to perform them, and where/when to report the results Information transmitted back to the Controller with configuration or instruction errors and general failure notices Information available to be fetched by the Controller such as the Measurement Tasks supported by the MA or interface configuration Information sent to the Collector regarding the Measurement Task results including MA context and Task Configuration 3

4. Changes to 02 Various small corrections and improvements Role added to Task Configuration Tried to restructure task ‘datasets’ to separate ‘Channels’ and ‘Downstream Tasks’ to aid clarity – But clearly failed! 4

5. Discussion Thanks for all the comments and review Clearly too much to discuss today – Many are directly implementable suggestions/corrections – Onto some of the bigger suggestions…… 5

6. Discussion: Channels & Downstream Tasks Channel becomes Task Configuration Option? – Yes: simpler – No: may need several Report Task Configurations for multiple destinations Scheduled Tasks need to output to other Scheduled Tasks (and not Task Configurations) Do we want/need a explicit concept of ‘Data Queue’ – Clarity – Define retention options, handling of multiple consumers Terminology: ‘Downstream Task’? 6 Schedule Scheduled Task A Schedule Scheduled Task B Schedule Scheduled Task A Schedule Scheduled Task B Queue X Output to…. Input from….

7. Discussion: Task Configurations vs. Scheduled Tasks Do we want to be able to add/override Task Configuration Options within a Schedule? – Yes: adds flexibility – No: Just define another Task Configuration 7

8. Discussion: Generalisation of Task Configuration and Report Information Task role is “just another” task parameter – But so is everything, but helpful to agree on some standard names/formats? Or is role inherent in registry reference? Cross-traffic is “just another” task reporting column – Leaves format to individual tasks (can select which counters etc.) 8

9. Discussion: Reporting Include schedule information in report (in addition to Task Configuration) Don’t always report Task Configurations in Report headers – Only report when changed? – Option of the Reporting Task? What happens to data if Reporting Task is suppressed – Let it build up or throw away? – Tail/head drop? Undefined? 9

10. Discussion: Timing Remove ISO8601 compliance for datetimes (just leave RFC 3339) Are calendar timing defaults dangerous? – Would execute every second – force some/all values? Do we need negative enumerations? – E.g. test all days except Sat and Sun Do we need days-from-end-of-month? – E.g. test on last day of the month Does ‘startup’ timing execute on new schedule or just MA restart? What happens to two schedules starting at exactly same time? – Previous agreement was to run in parallel (order undefined or in order of instruction?) 10

11. Discussion: Other Data persistence is device dependent (not protocol dependent) – Does Controller need to get through capabilities? Remove JSON example? – Currently useful but maybe superseded by forthcoming protocol documents Need to standardise condition codes? 11