Subject: Re: [lmap] WGLC for draft-ietf-lmap-information-model-02 (corrected date)

From: <[email-masked]>
Date: Mon, 1 Sep 2014 09:40:31 +0100

I have the corrected JSON and intend to correct with the next edit - I don't see any problem here. The JSON was added because a substantial amount of people wanted an example to aid understanding.

Trevor Burbridge

>-----Original Message-----
>From: lmap [mailto:[email-masked]] On Behalf Of ???/Lingli Deng
>Sent: 29 August 2014 04:42
>To: 'Liu,Shu@CATR'; [email-masked]
>Subject: Re: [lmap] WGLC for draft-ietf-lmap-information-model-02 (corrected
>date)
>
>I echo Vaibhav in removing the JSON blocks from this document, for they are
>neither required to understand the text nor helping with the call.
>
>Lingli
>
>> -----Original Message-----
>> From: lmap [mailto:[email-masked]] On Behalf Of Liu,Shu@CATR
>> Sent: Thursday, August 28, 2014 9:36 PM
>> To: [email-masked]
>> Subject: Re: [lmap] WGLC for draft-ietf-lmap-information-model-02
>> (corrected date)
>>
>> I couldn't agree more.
>>
>> Andy
>>
>> -----Original Message-----
>> From: Romascanu, Dan (Dan) [mailto:[email-masked]]
>> Sent: Thursday, August 28, 2014 6:25 PM
>> To: Bajpai, Vaibhav; <[email-masked]>
>> Cc: Liu,Shu@CATR
>> Subject: RE: [lmap] WGLC for draft-ietf-lmap-information-model-02
>> (corrected date)
>>
>> Hi,
>>
>> If we decide to keep them, the examples should be as clean
>> syntactically as we can make them. (even if included in an appendix)
>>
>> Regards,
>>
>> Dan
>>
>>
>> > -----Original Message-----
>> > From: Bajpai, Vaibhav [mailto:[email-masked]]
>> > Sent: Wednesday, August 27, 2014 4:21 PM
>> > To: <[email-masked]>
>> > Cc: Bajpai, Vaibhav; Romascanu, Dan (Dan); Liu,Shu@CATR
>> > Subject: Re: [lmap] WGLC for draft-ietf-lmap-information-model-02
>> > (corrected date)
>> >
>> > ** LMAP
>> >
>> > > On 27 Aug 2014, at 02:36, Liu,Shu@CATR <[email-masked]> wrote:
>> > >
>> > > The JSON blocks have a lot of syntax errors, I sent the parsable
>> > > blocks to Trevor, since the list did not allow me to post it.
>> >
>> > AFAIK, the JSON example is in the appendix for a reason. It is only
>> > meant to provide a _hint_ on how to translate the abstract objects
>> > into a concrete data model. As such, the example should not be used
>> > by implementations anyway.
>> >
>> > In order to avoid digressing ourselves into the JSON example, I
>> > propose to remove the JSON fragments from this document.
>> >
>> > 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
>>
>>
>> _______________________________________________
>> lmap mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/lmap
>
>
>
>_______________________________________________
>lmap mailing list
>[email-masked]
>https://www.ietf.org/mailman/listinfo/lmap

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Mon, 1 Sep 2014 13:43:49 +0200

On Mon, Sep 01, 2014 at 09:40:31AM +0100, [email-masked] wrote:

> I have the corrected JSON and intend to correct with the next edit -
> I don't see any problem here. The JSON was added because a
> substantial amount of people wanted an example to aid understanding.

Yes, but the information model at the end needs to be clear and I am
sharing Vaibhav's concern that people may mistakenly think they can
implement the JSON structures.

/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: Juergen Schoenwaelder <[email-masked]>
Date: Tue, 2 Sep 2014 15:54:07 +0200

On Tue, Aug 26, 2014 at 03:44:41PM +0000, Romascanu, Dan (Dan) wrote:
> This message opens a Working Group Last Call for the draft-ietf-lmap-information-model-02<http://datatracker.ietf.org/doc/draft-ietf-lmap-information-model/> Internet-Draft.
> 
> Please read and send comments about this document to the LMAP WG list before Wednesday September 10, 2014.
> 
> If you read the document and believe that it's ready to be submitted to the IESG for consideration as Proposed standards, please state this in a short message to the list.
> 
> The document is available at http://www.ietf.org/id/draft-ietf-lmap-information-model-02.txt.
> 

Hi,

Vaibhav and myself went through the exercise to derive a data model
from the information model in order to find spots where the
information model is unclear or where we find the model may need
improvement. The result of ~2 day work is a YANG data model that we
have posted as an I-D (together with a configuration XML snippet that
validates against the YANG data model):

  http://tools.ietf.org/html/draft-schoenw-lmap-yang-01

We will post the comments we have collected in a subsequent message.
Until we get the notes compiled, enjoy reading the YANG data model. ;-)

/js

---

From: "Bajpai, Vaibhav" <[email-masked]>
Date: Wed, 3 Sep 2014 09:04:04 +0000

** LMAP

> On 02 Sep 2014, at 15:54, Juergen Schoenwaelder <[email-masked]> wrote:

[...]

>> This message opens a Working Group Last Call for the draft-ietf-lmap-information-model-02
>> <http://datatracker.ietf.org/doc/draft-ietf-lmap-information-model/> Internet-Draft.
> 
> Hi,
> 

Please see below our review of the information model:

a) structural changes:
~~~~~~~~~~~~~~~~~~~~~~

   > 3.  LMAP Information Model  . . . . . . . . . . . . . . . . . . .   4
   >   3.1.  Information Structure . . . . . . . . . . . . . . . . . .   4
   >   3.2.  Pre-Configuration Information . . . . . . . . . . . . . .   8
   >   3.3.  Configuration Information . . . . . . . . . . . . . . . .   9
   >   3.4.  Instruction Information . . . . . . . . . . . . . . . . .  11
   >   3.5.  Logging Information . . . . . . . . . . . . . . . . . . .  13
   >   3.6.  Capability and Status Information . . . . . . . . . . . .  15
   >   3.7.  Reporting Information . . . . . . . . . . . . . . . . . .  17
   >   3.8.  Schedules . . . . . . . . . . . . . . . . . . . . . . . .  18
   >   3.9.  Channels  . . . . . . . . . . . . . . . . . . . . . . . .  21
   >   3.10. Task Configurations . . . . . . . . . . . . . . . . . . .  22
   >   3.11. Timing Information  . . . . . . . . . . . . . . . . . . .  23
   >     3.11.1.  Periodic Timing  . . . . . . . . . . . . . . . . . .  24
   >     3.11.2.  Calendar Timing  . . . . . . . . . . . . . . . . . .  25
   >     3.11.3.  One-Off Timing . . . . . . . . . . . . . . . . . . .  26
   >     3.11.4.  Immediate Timing . . . . . . . . . . . . . . . . . .  26
   >     3.11.5.  Startup Timing . . . . . . . . . . . . . . . . . . .  26

Can we bring the text inside 3.1 one level up directly within 3? This will
better show IM division of 6 (core components) + 4 (common objects) (as
described below):

   > For clarity the information model is divided into six sections:
   > 1.  Pre-Configuration Information.
   > 2.  Configuration Information.
   > 3.  Instruction Information.
   > 4.  Logging Information.
   > 5.  Capability and Status Information.
   > 6.  Reporting Information.

Perhaps we can also move the 4 common objects (below) into a separate section.
This will make it clearer how the IM consists of 6 core components with 4
objects shared amongst multiple components.

   > The information in these six sections is captured by a number of
   > common information objects.  These objects are also described later
   > in this document and comprise of:
   > 1.  Schedules.
   > 2.  Channels.
   > 3.  Task Configurations.
   > 4.  Timings.

Additionally since everything is defined to be a TASK. It would be nice to
have a classfication of envisaged tasks (measurement task, data-aggregation
tasks, reporting tasks, et al. for instance)

b) comment notations
~~~~~~~~~~~~~~~~~~~~

// Selected Task channel interfaces (selected by integer from array defined by the task) can be connected to
// Channels (referenced by name string(s))

This should be regular text. And in order to help people find the
text, it would be useful if the text about object 'foo' or attribute
'bar' would actually refer to 'foo' or 'bar' so that a text search
allows to find the relevant text easily.

c) channel granularity
~~~~~~~~~~~~~~~~~~~~~~

  > object {
  >     string              ma-schedule-name;
  >     ma-sched-task-obj   ma-schedule-tasks<0..*>;
  >     ma-timing-obj       ma-schedule-timing;
  > } ma-schedule-obj;

  > object {
  >     string                            ma-schedule-task-name;
  >     [ma-sched-channels-obj            ma-schedule-channels<0..*>;]
  >     [ma-sched-downstream-tasks-obj    ma-schedule-downstream-tasks<0..*>;]
  >  } ma-sched-task-obj;

  > object {
  >     [int                 ma-schedule-channel-interface-selection<0..*>;]  // default: all
  >     [string              ma-schedule-channel-names<0..*>];
  > } ma-sched-channels-obj;

Why do we define a separate channel for each task?  Given with the ^
structure, tasks that run measurements will just pipe their measurment results
to a downstream task (a reporting task). As a result, measurement tasks do not
necessarily need to worry about channels. It's eventually the reporting task
that pushes data on the reporting channel. Why don't we just pass the channel
as an option to the reporting / control task and simply remove channel stuff
from the schedule object?

d) task/downstream task relationships
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

  > object {
  >     string                            ma-schedule-task-name;
  >     [ma-sched-channels-obj            ma-schedule-channels<0..*>;]
  >     [ma-sched-downstream-tasks-obj    ma-schedule-downstream-tasks<0..*>;]
  >  } ma-sched-task-obj;

- How do ensure that task and downstram-task relationships are cycle-free?

- Example: There is a UDP latency task linked to a downstream immediate
  reporting task, For how long should the immediate reporting task wait for
  the upstream UDP latency task to complete?

e) terminology
~~~~~~~~~~~~~~

  1) ma-sched-task-obj:

This is set of tasks/downstream-tasks that need to be invoked as part of a
schedule. Can we come up with a better term for this? -- perhaps: action?

  2) downstream-tasks:

   > include an indication of the cross-traffic.  Cross traffic is defined
   > as the total number of Bytes both upstream and downstream of non-
   > measurement traffic passing through the interfaces used by a
   > Measurement Task during the measurement period.  The specific

A downstream task is the next task in a chain of linked tasks. However, the
term "downstream" is generally used to refer to the remote end. In fact it's
being used in ^ text snippet in that context. Can we come with a replacement
term for this?

f) schedules:
~~~~~~~~~~~~~

   > object {
   >     string              ma-schedule-name;
   >     ma-sched-task-obj   ma-schedule-tasks<0..*>;
   >     ma-timing-obj       ma-schedule-timing;
   > } ma-schedule-obj;

   >  object {
   >      string                            ma-schedule-task-name;
   >      [ma-sched-channels-obj            ma-schedule-channels<0..*>;]
   >      [ma-sched-downstream-tasks-obj    ma-schedule-downstream-tasks<0..*>;]
   >   } ma-sched-task-obj;

  1) naming inconsistencies:

The names within each object sometimes uniquely identify the object (see
ma-schedule-obj); however sometimes they provide a reference to another object
by name (see ma-sched-task-obj). Fine with either approach, but be nice to
keep it consistent.

  2) order of execution of tasks:

There can be multiple ma-sched-task-obj with the same timing. How should they
be kicked off by the scheduler? -- simultaneously, sequentially or should this
be implementation dependent?

  3) schedule options:

How about adding options to the schedule? The idea is that task configuration
can be rather static and reused while other arguments vary and it would be
nice to centralize the place where more frequent changes take place.

g) suppressing a reporting task:
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

What should happen with the measurement results when a reporting task is
either suppressed or not mentioned as a downstream-task in one of the
schedules?

h) task
~~~~~~~

   > object {
   >     string              ma-task-name;
   >     uri                 ma-task-registry-entry;
   >     string              ma-role;
   >     name-value-pair     ma-task-options<0..*>;
   >    [boolean             ma-task-suppress-by-default;] // default: TRUE
   >    [string              ma-task-cycle-id;]
   > } ma-task-obj;

  1) roles:

Can the ma-role not be identified as one of the task-options?

  2) granularity of task-options

Arguments are part of task-options. This means, arguments such as name of the
destination (measurement peer) needs to be indicated at the task-level. If
this is a list of destination, this will be replicated for each task per
schedule.

  3) granularity of cycle ID

A cycle ID can be used to tag a measurement campaign involving multiple
related tasks for a specific time-period. Would it suffice to just keep this
tag at the schedule-level than at the task-level.

i) pre-configuration and configuration
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

   >  object {
   >      [uuid                ma-agent-id;]
   >       ma-task-obj         ma-control-tasks<1..*>;
   >       ma-channel-obj      ma-control-channels<1..*>;
   >       ma-schedule-obj     ma-control-schedules<1..*>;
   >      [urn                 ma-device-id;]
   >       credentials         ma-credentials;
   >  } ma-config-obj;

The preconfiguration dictates that there should atleast be one pseudo task
that is used for initial configuration with the controller. This may not be
necessary for protocols (NETCONF for instance) which have their own call-home
mechanism built in. A pseudo task may not necessarily be required.

   > object {
   >     uuid                ma-agent-id;
   >    [ma-task-obj         ma-control-tasks<0..*>;]
   >     ma-channel-obj      ma-control-channels<1..*>;
   >    [ma-schedule-obj     ma-control-schedules<0..*>];
   >    [urn                 ma-device-id;]
   >     credentials         ma-credentials;
   >    [string              ma-group-id;]
   >    [boolean             ma-report-ma-id-flag;]
   >    [int                 ma-control-channel-failure-threshold;]
   > } ma-config-obj;

   1) cardinality inconsistencies

The ^ requirements also leads to cardinality inconsistencies when compared
with the configuration object. For instance, the configuration item after the
initial configuration now allows zero tasks (instead of atleast 1)

   2) ma-control-channel-failure-threshold

There is no description on this in text. Descriptions around items such as:
What happens when the threshold is reached?, Does the threshold limit reset
when a success is hit after a sequence of failures? Would it not be nice to
report the number of failures crossing this threshold in the report?

j) status information
~~~~~~~~~~~~~~~~~~~~~

   > object {
   >     uuid                ma-agent-id;
   >     urn                 ma-device-id;
   >     string              ma-hardware;
   >     string              ma-firmware;
   >     string              ma-version;
   >     ma-interface-obj    ma-interfaces<0..*>;

   >     datetime            ma-last-measurement;
   >     datetime            ma-last-report;
   >     datetime            ma-last-instruction;
   >     datetime            ma-last-configuration;

   >     [ma-condition-obj    ma-conditions<0..*>;]

   >     ma-task-capability-obj   ma-supported-tasks<0..*>;
   > } ma-status-obj;

  1) ma-hardware and ma-firmware refer to versions. Shall we rename them to
ma-hardware-version and ma-firmware-version.

  2) ma-version is a string. How do we come up with a lexical ordering of
version names?

  3) Why do we need both ma-last-instruction and ma-last-configuration? How is
ma-last-instruction different from ma-last-configuration?

  4) ma-last-measurement: by last-measurement do we mean,
last-measurement-task? Since everything is a task, how does the MA
differentiate measurement-task from report-task?

  5) Should we also record the datetime of the last failed scheduled task.
Should we also keep a record of number of last failures.

k) condition codes
~~~~~~~~~~~~~~~~~~

   > object {
   >   string                ma-condition-code;
   >   string                ma-condition-text;
   > } ma-condition-obj

condition codes cannot be learnt at runtime. As such, a list of defined
condition codes is needed. Ideally the IM should define these codes to allow
commonality b/w multiple data models. In the worst case, atleast the IM must
mention that these codes are left for the data model documents to define.

l) report object
~~~~~~~~~~~~~~~~

   > object {
   >     datetime            ma-report-date;
   >    [uuid                ma-report-agent-id;]
   >    [string              ma-report-group-id;]
   >     ma-report-task-obj  ma-report-tasks<0..*>;
   > } ma-report-obj;

Is the multiplicity of report-tasks really needed? I understand it's to allow
reporting of results from multiple tasks in one report object. However, the
savings it brings over the wire is minimal (date, agent-id, group-id).  It
would simplify the data model by having one report object for each task.
Results from multiple tasks can be shipped in separate report objects.

m) report task headers
~~~~~~~~~~~~~~~~~~~~~~

   > object {
   >     ma-task-obj         ma-report-task-config;
   >     string              ma-report-task-column-labels<0..*>;
   >     ma-result-row-obj   ma-report-task-rows<0..*>;
   > } ma-report-task-obj;

1) We ship the task config, but why don't we also ship the schedule
information back in the report?

2) We also ship the task config with each and every report. We should consider
that task config is slated to change less frequently.

n) report result rows:
~~~~~~~~~~~~~~~~~~~~~~

   > object {
   >     datetime            ma-report-result-start-time;
   >    [datetime            ma-report-result-end-time;]
   >     string              ma-report-result-conflicting-tasks<0..*>;
   >    [int                 ma-report-result-cross-traffic;] // Bytes of non-measurement traffic
   >                                                          // on measurement interface during measurement period
   >     data                ma-report-result-values<0..*>;
   > } ma-result-row-obj;

1) The cross-traffic is reported in absolute number of bytes. It's hard to
make any interpretation in the results by observing these absolute numbers
(500bytes vs 5Mbytes). Would it not be more useful to report the cross-traffic
in relation to total traffic seen on the interface?

2) How does the MA identify a conflicting task? Given the configuration can
change over time, the task-names referred to in the reports may either not
exist or may refer to something entirely different at reporting time.

   >     string              ma-report-result-conflicting-tasks<0..*>;
   >    [int                 ma-report-result-cross-traffic;] // Bytes of non-measurement traffic
   >                                                          // on measurement interface during measurement period

3) How do we make this environment reporting feature complete? An active test
may care about the cross-traffic; but a passive test cares more about how many
number of packets dropped during the test run.

o) calendar timing
~~~~~~~~~~~~~~~~~~

   > object {
   >    [datetime            ma-calendar-start;] // default: immediate
   >    [datetime            ma-calendar-end;]   // default: indefinite
   >    [int                 ma-calendar-months<0..*>;]   // default: 1-12
   >    [days                ma-calendar-days-of-week<0..*>;] // default: all
   >    [int                 ma-calendar-days-of-month<0..*>;] // default 1-31
   >    [int                 ma-calendar-hours<0..*>;]    // default: 0-23
   >    [int                 ma-calendar-minutes<0..*>;]  // default: 0-59
   >    [int                 ma-calendar-seconds<0..*>;]  // default: 0-59
   >    [int                 ma-calendar-timezone-offset;]
   >                         // default: system timezone offset
   > } ma-calendar-obj;

1) The default values are very dangerous. A calendar object with a start
datetime will essentially make the test run at each clock ticks!

2) Would it not be nice to say: "please run the test on the last day of each
month". The current object does not allow such a presentation. We may need
negative indexes that enumerate from the end to beginning of the list.

p) immediate timing
~~~~~~~~~~~~~~~~~~~

   > object {
   >                         // empty
   > } ma-immediate-obj;

There is a schedule with immediate timing. Now if the configuration is
reloaded, does the scheduler rerun this schedule?

Best, Vaibhav

Research I, Room 91
Computer Networks and Distributed Systems  (CNDS) Lab
School of Engineering and Sciences
Jacobs University Bremen, Germany

www.vaibhavbajpai.com

---

From: Arne Oslebo <[email-masked]>
Date: Thu, 04 Sep 2014 13:51:13 +0200

> b) comment notations
I agree. Using integers makes things unnecessarily difficult to read and
understand.

> c) channel granularity
The list of channels is defined as <0..*>, so if a measurement task do
not need a channel then we do not have to specify one. So I prefer it as
it is now.

> d) task/downstream task relationships
I am in the very early stages of an implementation and have given this
some thought. Assuming that downstream-tasks actually references a
schedule and not a task, then I will create a new instance of each task
referenced by a schedule. For one off schedules I will terminate the
task after it has been executed. For other schedules I will keep the
tasks active as long as the MA is running. When a measurement task sends
a report to a schedule containing a reporting task I will check the
timing of the schedule. If the timing is immediate, I will send the
report directly to the channel specified. If not, I will cache the
report and send it at the scheduled time.
> e) terminology
I like the suggestion of using the term action.

[...]

> be implementation dependent?
I think it should be implementation dependent but then we need some text
in the information model discussing it. If a device has the resources I
would prefer simultaneously, but for a resource limited device I think
sequentially is the only option. If we make it implementation dependent
we can add an element to ma-status-obj specifying how the timing is done.
> nice to centralize the place where more frequent changes take place.
+1
> either suppressed 
If the actual reporting task is  suppressed, then I think the results
should be dropped. The only reason I see for suppressing a reporting
task is if the caching of results takes too much resources. If a
schedule that contains a reporting task is suppressed, then I think we
should keep caching the results. But what should happen with the results
when there are no more resources left to cache them? Should new results
be dropped or should the oldest results be dropped?
> or not mentioned as a downstream-task in one of the
> schedules?
If a reporting task is not mention as a downstream-task it will never
receive any measurement results so it shouldn't be a problem. But what
should we do when a reporting schedule is deleted and the reporting task
in the schedule has measurement results that have not been sent? Should
they be dropped?
> Can the ma-role not be identified as one of the task-options?
I've wondered the same thing. It should at least be made optional as not
all tasks need a role.

Arne

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Fri, 5 Sep 2014 13:57:36 +0200

> not need a channel then we do not have to specify one. So I prefer it as

My understanding is that only control and reporting tasks need one of
LMAP these channels. I would find it simpler if we would configure the
channel where the control / reporting task is configured instead of
provisioning a way to configure channels for all tasks.

/js

---

From: <[email-masked]>
Date: Fri, 5 Sep 2014 18:04:12 +0100

Here are some fairly minor comments /suggestions

The nits checker has quite a few complaints, especially there are many lines that are too long - reaching an impressive 52 characters in excess! http://www.ietf.org/tools/idnits?url=http://www.ietf.org/archive/id/draft-ietf-lmap-information-model-02.txt  

There are quite a few places where the items in an object seem to be inconsistently named. For example
<< object {
    ma-task-obj         ma-instruction-tasks<0..*>;
    ma-channel-obj      ma-report-channels<0..*>;
    ma-schedule-obj     ma-instruction-schedules<0..*>;
    ma-suppression-obj  ma-suppression;
} ma-instruction-obj;
This makes me wonder, why not << ma-instruction-report-channels<0..*>;>> and << ma-instruction-suppression;>>
Here it may be deliberate (they're objects, so effectively points off to another section where they're defined), but there are other examples where this doesn't seem the case. Also, maybe in the comments you could add some pointers to other sections, where it isn't obvious.

Later, you have things like ma-report-XX and ma-report-task-XX. I wonder if it would be better to write ma-reporttask-XX or ma-report_task-obj, to make clear they're not linked?

Page 20 you have <<ma-sched-send-to-tasks-obj>> which I don't think is defined

S3.10, 
<<    string              ma-role;>>
Think this is optional, ie needs [...]. and ma-task-role would be better name?

S3.4
<<   [string              ma-suppression-task-names<0..*>;]
                        // default: all tasks if
                        // ma-suppression-task-names is empty
   [string              ma-suppression-schedule-names<0..*>;]
                        // default: all schedules if
                        // ma-suppression-schedule-names is empty
You mean: default is obey the boolean  ma-task-suppress-by-default (see S3.10)

S3.10, in the discussion of ma-task-options, it would be good to mention Input Parameters (I presume this is what this is referring to).
The framework S5.2.2 (Instruction) also mentions the interface to use (for the Measurement Task) and the 'measurement point designation' (*) of the MA and other MA/MP(s) if applicable. Are either of these things included, or are they further ma-task-options?
(*)'measurement point designation' is an abstract definition, on the lines of 'MA at the home gateway' and can be useful for helping the privacy of reports - see draft-ietf-ippm-reference-path.

S3.7 Reporting information
The framework S5.4 about the report mentions two things which may be in the report & I didn't spot in the information model: the subscriber's service parameters & the MA(s)/MP(s) 'measurement point designation'.
Framework also says that optionally a report isn't sent if there are no measurement results - should the info model cover this? (ie is this something the controller decides or the MA?)

Thanks
phil

------------

From: lmap [mailto:[email-masked]] On Behalf Of Romascanu, Dan (Dan)
Sent: 26 August 2014 16:45
To: [email-masked]
Subject: [lmap] WGLC for draft-ietf-lmap-information-model-02 (corrected date)

This message opens a Working Group Last Call for the draft-ietf-lmap-information-model-02 Internet-Draft.

Thanks and Regards,

Jason and Dan

---

From: KEN KO <[email-masked]>
Date: Mon, 8 Sep 2014 18:27:28 +0000

My comments:

Technical:

p.11, in MA Configuration object: I think "ma-schedule-obj    ma-control-schedules<0..*>" should be mandatory. This is a repeat comment from -01.

pp.19-20, directing output from Tasks. If the specified destination Task is listed in multiple Schedules, can we unambiguously define which Scheduled Task is the destination? We might need to specify both the Task and the Schedule in ma-sched-downstream-tasks-obj.

p.20, the Example refers to a ma-sched-send-to-tasks-obj. This object is not documented anywhere in the draft. I think you mean ma-sched-downstream-tasks-obj. Even then, the example syntax shown is unclear (there are a lot of dashes) and I can't tell from it what the intended destination is for Output 2.

Editorial:

P.12, "If both individual tasks and individual schedules are listed then /the union of these options is considered - i.e. the listed shcedules/only the listed schedules plus the listed tasks where present in other schedules will be suppressed regardless of the suppress-by-default flag/."

Formatting throughout draft - insert line breaks to prevent IETF tool from generating microscopic pages!

Best regards,
Ken

From: lmap [mailto:[email-masked]] On Behalf Of Romascanu, Dan (Dan)
Sent: Tuesday, August 26, 2014 11:45 AM
To: [email-masked]<mailto:[email-masked]>
Subject: [lmap] WGLC for draft-ietf-lmap-information-model-02 (corrected date)

Thanks and Regards,

Jason and Dan

---

From: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Tue, 9 Sep 2014 16:32:16 +0000

Please find below my comments.

Technical

T1: In section 3.1, when talking about Instruction Information, the following is said:

Ø  It also inlcudes Task Suppression

Ø         information that is used to over-ride normal Task execution

Ø         during emergency situations.

Ø

While Task Suppression is certainly used in emergency situations, the framework does not limit its usage to emergency cases, I believe that this claim should not be made here either

T2: Also in 3.1, under 1. Measurements Tasks I find the concept of Data Capture Tasks. This is again something the framework does not talk about, and neither could I find usage later in the IM. Unless there is some good justification or details that I am missing, I suggest to take this out

T3. Also in 3.1 - the concept of Downstream Tasks is introduced but never defined. Neither is it covered by the framework.

T4: In Section 3.3 I found:

Ø  While pre-configuration is persistent upon device reset or power

Ø     cycle due to its very nature, the persistency of the addtional

Ø     configuration information may be control protocol dependent.  Some

Ø     protocols may assume that reset devices will revert back to their

Ø     pre-configuration state, while other protocols may assume that all

Ø     configuration and instruction information is held in persistent

Ø     storage.

Ø

Is this something that really depends on the protocol? Can somebody give an example of a protocol that assumes that reset devices will revert to their pre-configuration state? I tend to believe that this is a device rather than a protocol characteristic, but I may be wrong

T5. In section 3.4 I see 'The datetime format ... MUST conform to RFC 3339 [RFC 3339] and ISO8601.' Are these the same thing, or does ISO8601 contain more requirements. As this is a MUST clause, we need clarity here and a Normative reference to ISO8601.  Or drop it if the two are the same.

T6. In Section 3.5 and 3.6. Are the interfaces of an MA the same as the interfaces of the device that hosts the MA? If they are the same some text should clarify this. If they are different or may be different, the examples in 3 'Status updates from the MA' should specify whether the interfaces of the MA or of the device are referred.

T7. I could not find some of the pieces of information described in section 5.2 of the framework I-D related to Logging in the IM objects in Section 3.5 of this I-D - e.g.

                the last time the MA ran a Measurement Task

   o  the last time the MA sent a Measurement Report

   o  the last time the MA received an Instruction Message

T8. What is ma-task-role? Requester/responder? If so or if something else some clarification would be welcome.

T9. The security considerations section should include some warning against using the (mis)configuration of the MAs as a mean to overload the network or launch DoS attacks.

T10. I believe that we should say some place in the document that the considerations of the Privacy Considerations section in the framework document apply to the IM model wherever applicable

Editorial

E1. The Introduction talks about 'basically three protocols' but the text that follows indicates that there are actually three types of protocols, but there can be more instances.

E2. First purpose in Introduction - implementations are not standardized, so s/data model implementations/data models/. Also s/Report protocol/Report protocols/

E3. In section 3.1 s/inlcudes/includes/

E4. In section 3.2 s/The detail of the Channel/The details of the Channel/

E5. In Section 3.3 s/addtional/additional/. Also please fix the first sentence in the second paragraph. Also s/vaue/value/

E6. In section 3.4 s/exceution/execution/

E7. In section 3.5 - What means 'achieved simply and flexibly'? sounds like 'marketing'

E8. In section 3.7 - s/inlcudes/includes/

E9. The first sentence in 3.9 looks like a circular definition with 'channel' being defined by being a 'channel' of some sorts. Maybe s/bi-directional communication channel/bi-directional communication path/

E10. Also in 3.9 - what a 'local short name' means? 'short' requires some context, or just drop it

E11. In 3.10 - s/bye used/be used/. Also do not capitalize NOT!

E12. Why is the appendix numbered as section 6? Either do not call this section 'Appendix' or append it at the end of the document.

Regards,

Dan

From: lmap [mailto:[email-masked]] On Behalf Of Romascanu, Dan (Dan)
Sent: Tuesday, August 26, 2014 6:45 PM
To: [email-masked]
Subject: [lmap] WGLC for draft-ietf-lmap-information-model-02 (corrected date)

Thanks and Regards,

Jason and Dan

---

From: "Carey, Timothy (Timothy)" <[email-masked]>
Date: Tue, 9 Sep 2014 16:57:59 +0000

Dan,

RFC 3339 and ISO8601 are not the same.
Honestly we should just pick one because its confusing to mandate both. I just assumed it meant RFC 3339 because this is a RFC draft...:)

The loss of configuration is not a protocol thing it is a device thing. Certain constrained devices might not have the persistent storage necessary for configuration so if the device resets; the controller will have to reload configuration. Doesn't happen much today as I am aware things like modems and RGs but who knows with other devices.

BR,
Tim

From: Romascanu, Dan (Dan) [mailto:[email-masked]]
Sent: Tuesday, September 09, 2014 11:32 AM
To: [email-masked]
Subject: Re: [lmap] WGLC for draft-ietf-lmap-information-model-02 (corrected date)

Technical

Ø

Ø     storage.

Ø

Editorial

Regards,

Dan

Thanks and Regards,

Jason and Dan