Re: [lmap] review: draft-ietf-lmap-information-model-03

[<[e-mail]>]

Thanks Vaibhav,

I'll pick these up during the interim discussion and get the agreed changes in for the 04 edit.

Trevor.


>-----Original Message-----
>From: lmap [mailto:[e-mail]] On Behalf Of Bajpai, Vaibhav
>Sent: 26 January 2015 10:32
>To: <[e-mail]>
>Cc: Bajpai, Vaibhav
>Subject: [lmap] review: draft-ietf-lmap-information-model-03
>
>LMAP,
>
>> On 23 Jan 2015, at 17:33, Juergen Schoenwaelder <j.schoenwaelder@jacobs-
>university.de> wrote:
>>
>> we have updated the YANG data model in order to align it with the
>> latest update of the information model. A couple of questions came up
>> during the process, which we will post in a separate message. We also
>> added an instance document in XML and the same rendered in JSON. Both
>> have been validated against the YANG data model using the pyang
>> toolchain.
>
>Below is our review of the information model -03:
>
>
>
>Capability and Status Information
>~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>
>  >      datetime            ma-last-task;
>  >      datetime            ma-last-report;
>  >      datetime            ma-last-instruction;
>  >      datetime            ma-last-configuration;
>
>The semantics of ma-last-* is unclear. 'Last' means last executed or last
>succeessfuly completed? Additionally, how does the LMAP implementation know
>whether task X is a measurement task, a reporting task, et al.? If not how would
>the implementation fill in the datetime fields.
>
>In the YANG data model [1], we have added 'last-execution' (to all known
>tasks) and it records the last invocation of the task (but it should really be a pair
>'last-invocation' and 'last-completion'. But the point here is to report this for each
>tasks instead of a grouping of tasks by function.
>
>
>
>Condition Codes
>~~~~~~~~~~~~~~~
>
>  >    [ma-condition-obj    ma-conditions<0..*>;]
>
>  >    object {
>  >      string                ma-condition-code;
>  >      string                ma-condition-text;
>  >    } ma-condition-obj
>
>This is a list of condition codes.  Each condition code in this list needs to associate
>to a task.  How do we make the association?
>
>In the YANG data model [1], we have added 'last-failed-execution' (to all known
>tasks) and it records the last failed execution together with a status code and a
>status message. This makes sure that a subsequent successful execution is not
>removing the error code and message. We also believe that (at least in the data
>model) we need to define a set of suitable status codes in order to be
>interoperable.
>
>
>
>Reporting
>~~~~~~~~~
>
>  >  object {
>  >      string              ma-report-task-name;
>  >     [uri                 ma-report-task-registry-entry;]
>  >     [name-value-pair     ma-report-scheduled-task-options<0..*>];
>  >     [string              ma-report-task-cycle-id;]
>  >      string              ma-report-task-column-labels<0..*>;
>  >      ma-result-row-obj   ma-report-task-rows<0..*>;
>  >  } ma-report-task-obj;
>
>How about introducing a configuration version number?  This will remove remove
>the need to send entire task configuration as part of the report, since only config
>version numbers would need to be matched.
>
>
>
>Schedules
>~~~~~~~~~
>
>  >  object {
>  >     string                         ma-schedule-task-name;
>  >    [name-value-pair                ma-schedule-task-options<0..*>];
>  >    [ma-sched-downstream-tasks-obj  ma-schedule-destination-tasks<0..*>;]
>  >  } ma-sched-task-obj;
>
>
>  a) Task options are now part of both schedule and task configurations
>  (Thanks!). However, it's unclear whether schedule options are prepended or
>  appended to the task options. We think schedule options should be appended to
>  the task options because schedules are more frequently updated than task
>  configurations.
>
>  In the YANG data model [1], we have specified that options are appended.
>
>
>  b) Task and downstream relationship is not clear. Is it:
>
>    $ a | b (a streaming data to b)     (or)
>    $ a ; b (b running after a is completed)
>
>    In case of the latter, does the destination task wait for the upstream
>    task to be completed? For example, with an upstream task sending results
>    to a reporter, is the reporter blocking until there is data from the
>    upstream task? The behavior is not currently defined in the document.
>
>    The behavior of ^ relationship is unclear, when for example a periodic
>    scheduled task forwards data to an immediate schedule report (or an
>    immediate forwards to another immediate). In such cases, what would
>    immediate mean if a task consumes data from another task?
>
>
>
>  c) Let's not introduce a new 'name-value-pair' type. Instead it would be
>  better to refer to an options object which has a name and a value elements.
>
>
>  >   object {
>  >      [string    ma-schedule-task-destination-schedule-name];
>  >      [string    ma-schedule-task-destination-task-configuration-name];
>  >      [int       ma-schedule-task-output-selection<0..*>;]  // default: all
>  >   } ma-sched-destination-tasks-obj;
>
>The notion of an upstream task being able to direct outputs with different file
>descriptions to different destination tasks (which themselves are referred to by a
>schedule name) was challenging to grasp from the ^ snippet.
>Perhaps more description on this would be nice.
>
>  >   Measurement Task
>  >     Output 1 -----+----> "Hourly Schedule":"Hourly Reporting Task"
>  >     Output 2 ----/
>
>In the ^ example, how do we decide the the order of directing results into the
>hourly reporting task?
>
>
>
>
>References
>~~~~~~~~~~
>
>  >  [I-D.ietf-lmap-framework]
>  >             Eardley, P., Morton, A., Bagnulo, M., Burbridge, T.,
>  >             Aitken, P., and A. Akhter, "A framework for large-scale
>  >             measurement platforms (LMAP)", draft-ietf-lmap-
>  >             framework-03 (work in progress), January 2014.
>
>Needs an update.
>
>  >  [I-D.bagnulo-ippm-new-registry]
>  >             Bagnulo, M., Burbridge, T., Crawford, S., Eardley, P., and
>  >             A. Morton, "A registry for commonly used metrics", draft-
>  >             bagnulo-ippm-new-registry-01 (work in progress), July
>  >             2013.
>
>Needs an update.
>
>
>
>
>JSON Data Model Example
>~~~~~~~~~~~~~~~~~~~~~~~
>
>As part of the YANG data model definition [1], we now provide both a XML and a
>JSON encoded example for reference. The example is validated against the YANG
>data model definition. Can we remove the JSON example from this document?
>
>[1] http://tools.ietf.org/html/draft-schoenw-lmap-yang-02
>
>
>
>Editorial Comments:
>~~~~~~~~~~~~~~~~~~~
>
>A lot of new spelling errors were spotted when examining the diff.
>
>
>[1] http://tools.ietf.org/html/draft-schoenw-lmap-yang-02
>
>
>Best, Vaibhav
>
>=====================================================
>Vaibhav Bajpai
>
>Research I, Room 91
>Computer Networks and Distributed Systems (CNDS) Lab School of Engineering
>and Sciences Jacobs University Bremen, Germany
>
>www.vaibhavbajpai.com
>=====================================================