Subject: Re: [lmap] I-D Action: draft-ietf-lmap-information-model-00.txt

From: Charles Cook <[email-masked]>
Date: Tue, 11 Mar 2014 11:15:19 -0600

I finally got around to reviewing the Information Model.  Attached are
my comments. 

In summary:

It appears that the Information Channel is being referenced with
Pre-configuration information rather than Configuration information.  
Pre-configuration information cannot be provided via the Information
Channel because the MA has to register with the Controller before it can
receive Configuration information from the Controller.

There is a reference that Measurement Tasks will be executed "in order"
which may imply "serially" to some.  It would be more accurate to say
executed per the Measurement Schedule.

At one time I thought I heard that one of the "Elements" may be split
into two Elements.  If that happens, the draft will need to be updated. 
Given the recent discussion on Active vs Passive, maybe that is no
longer under consideration.

Regarding Operational Update messages, consideration should be given to
a "Scheduling conflict" message.  This may also need to be mentioned in
Section 3.7 "Reporting Information".

There were also a few editorial items.

Overall, it is looking good.

Charles

On 2/16/2014 8:20 AM, [email-masked] wrote:
> A New Internet-Draft is available from the on-line Internet-Drafts directories.
>  This draft is a work item of the Large-Scale Measurement of Broadband Performance Working Group of the IETF.
>
>         Title           : Information Model for Large-Scale Measurement Platforms (LMAP)
>         Authors         : Trevor Burbridge
>                           Philip Eardley
>                           Marcelo Bagnulo
>                           Juergen Schoenwaelder
> 	Filename        : draft-ietf-lmap-information-model-00.txt
> 	Pages           : 21
> 	Date            : 2014-02-14
>
> Abstract:
>    This Information Model applies to the Measurement Agent within a
>    Large-Scale Measurement Platform.  As such it outlines the
>    information that is (pre-)configured on the MA or exists in
>    communications with a Controller or Collector within an LMAP
>    framework.  The purpose of such an Information Model is to provide a
>    protocol and device independent view of the MA that can be
>    implemented via one or more Control and Report protocols.
>
>
>
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/draft-ietf-lmap-information-model/
>
> There's also a htmlized version available at:
> http://tools.ietf.org/html/draft-ietf-lmap-information-model-00
>
>
> Please note that it may take a couple of minutes from the time of submission
> until the htmlized version and diff are available at tools.ietf.org.
>
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/
>
> _______________________________________________
> lmap mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/lmap
>

-- 

Charles Cook 
Principal Architect
Network
5325 Zuni Street; Suite 224
Denver, CO  80221
Tel:  303.992.8952  Fax:  925.281.0662
[email-masked]

---

From: <[email-masked]>
Date: Tue, 11 Mar 2014 17:26:38 +0000

Thanks for the comments Charles.

Some of these were covered in the suggested updates during the IETF LMAP session, but see inline for answers....

>-----Original Message-----
>From: lmap [mailto:[email-masked]] On Behalf Of Charles Cook
>Sent: 11 March 2014 17:15
>To: [email-masked]
>Subject: Re: [lmap] I-D Action: draft-ietf-lmap-information-model-00.txt
>
>I finally got around to reviewing the Information Model.  Attached are my
>comments.
>
>In summary:
>
>It appears that the Information Channel is being referenced with Pre-
>configuration information rather than Configuration information.
>Pre-configuration information cannot be provided via the Information Channel
>because the MA has to register with the Controller before it can receive
>Configuration information from the Controller.

We're going to make the whole concept of channels a lot simpler. In the pre-config the MA will need an initial channel to contact the Controller. We no longer bind this channel to specific types of data (config, instruction, capabilities, logging etc.) or to a specific timing. Any channel will simply become a secure communication channel to an end-point.

Hopefully will make things a lot clearer (and also more flexible).

>which may imply "serially" to some.  It would be more accurate to say executed
>per the Measurement Schedule.

It does say that, and we did indeed mean serialised! We wanted the ability to specify a non-overlapping list of things to do in a single schedule. If you want to overlap then use multiple schedules.

>At one time I thought I heard that one of the "Elements" may be split into two
>Elements.  If that happens, the draft will need to be updated.
>Given the recent discussion on Active vs Passive, maybe that is no longer under
>consideration.

I think this was probably the one-off vs. repeated tasks. We agreed the information model does not need to split these (other than by the use of different timing objects). It is up to the protocol implementation into whether one-off and repeated tests are updated separately (or indeed any breakdown of the instruction).

>Regarding Operational Update messages, consideration should be given to a
>"Scheduling conflict" message.  This may also need to be mentioned in Section
>3.7 "Reporting Information".

Yes, I discussed on the last slide that we need further discussion on the reporting of test collisions.

>There were also a few editorial items.

Will make sure we catch them in the forthcoming 01 edit.

>Overall, it is looking good.

Thanks!

>Charles

Trevor.

>> Please note that it may take a couple of minutes from the time of
>> submission until the htmlized version and diff are available at tools.ietf.org.
>>

---

From: Charles Cook <[email-masked]>
Date: Tue, 11 Mar 2014 11:53:22 -0600

Trevor,

Thanks for the clarifications. 

One more question regarding the serialization of the Measurement Tasks. 
When you say "in order", do you mean in order as they were sent to the
MA, or do you mean in order as they are scheduled?  I assume it is that
later, but without that clarification in the draft some may think the
former.  For example, the Controller could send Measurement Tasks A, B,
and C in that order.  But when you look at the Measurement Schedule it
may say do B first, followed by C, followed by A.  Now we have an
ambiguity.  That is why I think what we really want to say is that the
Measurement Tasks will be executed "in order based on the Measurement
Schedule".  Let me know if I am missing something.

Charles

-- 

Charles Cook 
Principal Architect
Network

---

From: <[email-masked]>
Date: Wed, 12 Mar 2014 08:52:11 +0000

That's correct - will clarify on the next edit.

>From: Charles Cook [mailto:[email-masked]]
>Sent: 11 March 2014 17:53
>To: Burbridge,T,Trevor,TUB8 R
>Cc: [email-masked]
>When you say "in order", do you mean in order as they were sent to the MA, or
>do you mean in order as they are scheduled?  I assume it is that later, but without
>that clarification in the draft some may think the former.  For example, the
>Controller could send Measurement Tasks A, B, and C in that order.  But when
>you look at the Measurement Schedule it may say do B first, followed by C,
>followed by A.  Now we have an ambiguity.  That is why I think what we really
>want to say is that the Measurement Tasks will be executed "in order based on
>the Measurement Schedule".  Let me know if I am missing something.
>
>Charles
>
>>> I finally got around to reviewing the Information Model.  Attached
>>> are my comments.
>>>
>>> In summary:
>>>
>>> Channel because the MA has to register with the Controller before it
>>> can receive Configuration information from the Controller.
>> We're going to make the whole concept of channels a lot simpler. In the pre-
>config the MA will need an initial channel to contact the Controller. We no longer
>bind this channel to specific types of data (config, instruction, capabilities,
>logging etc.) or to a specific timing. Any channel will simply become a secure
>communication channel to an end-point.
>>
>> It does say that, and we did indeed mean serialised! We wanted the ability to
>specify a non-overlapping list of things to do in a single schedule. If you want to
>overlap then use multiple schedules.
>>
>> I think this was probably the one-off vs. repeated tasks. We agreed the
>information model does not need to split these (other than by the use of different
>timing objects). It is up to the protocol implementation into whether one-off and
>repeated tests are updated separately (or indeed any breakdown of the
>instruction).
>>
>>> Regarding Operational Update messages, consideration should be given
>>> to a "Scheduling conflict" message.  This may also need to be
>>> mentioned in Section
>>>>  This draft is a work item of the Large-Scale Measurement of
>>>> Broadband
>>> Performance Working Group of the IETF.
>>> Tel:  303.992.8952  Fax:  925.281.0662 [email-masked]