Subject: [lmap] new version of framework

From: <[email-masked]>
Date: Fri, 13 Jun 2014 13:38:59 +0100

I just uploaded a new version
http://www.ietf.org/id/draft-ietf-lmap-framework-06.txt

Barbara, Greg, Ken and others who've made suggestions - Please could you do a quick check to make sure we got your points properly

Thanks
Phil

--12.6.  From -05 to -06

   o  clarified terminlogy around Measurement Methods and Tasks.  Since
      within a Method there may be several different roles (requester
      and responder, for instance)

   o  Suppression: there is now the concept of a flag (boolean) which
      indicates whether a Task is by default gets suppressed or not.
      The optional suppression message (with list of specific tasks
      /schedules to suppress) over-rides this flag.

   o  The previous bullet also means there is no need to make a
      distinction between active and passive Measurement Tasks, so this
      distinction is removed.

I now see a glitch! The final 2 bullets should be replaced by:-

   o  removed Configuration Protocol - Configuration is part of the Instruction and so uses the Control Protocol

---

From: Greg Mirsky <[email-masked]>
Date: Fri, 13 Jun 2014 10:33:26 -0700

Hi Phil,
many thanks for kind consideration my comments and thoroughly addressing
them. Minor point to definition of the control protocol in Section 3
Terminology it doesn't list MA configuration as one of functions performed
through the Control protocol though later on page 13 we state (added in
-06) "Finally, it allows the Controller to update the MA's configuration".
Just in case there will ever be -07 version.

Regards,
Greg

On Fri, Jun 13, 2014 at 5:38 AM, <[email-masked]> wrote:

> Barbara, Greg, Ken and others who’ve made suggestions - Please could you
> do a quick check to make sure we got your points properly
>
>
>
> Thanks
>
> Phil
>
>
>
> --12.6.  From -05 to -06
>
>
>
>    o  removed Configuration Protocol – Configuration is part of the
> Instruction and so uses the Control Protocol
>
>
>
> _______________________________________________
> lmap mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/lmap
>
>

---

From: "STARK, BARBARA H" <[email-masked]>
Date: Wed, 18 Jun 2014 18:07:16 +0000

I have just 2 comments. I'm also emailing a marked up Word version to the authors, that notes all nits that I found.
------

5.6.1.  End-user-controlled measurement system

...

   1.  an end-user could somehow request the ISP- (or regulator-) run

       measurement system to test his/her line.  The ISP (or regulator)

       Controller would then send an Instruction to the MA in the usual

       LMAP way.  Note that a user can't directly initiate a Measurement

       Task on an ISP- (or regulator-) controlled MA.

In a comment to the -04 version I'd asked to have the last sentence deleted. I didn't really follow up on this among all the other comments. But I still find this to be an unnecessary restriction. We have lots of devices that could be considered to have MAs that have both a "controller" interface that allows for all Controller - MA activities, and a local user interface for a limited set of user-requested actions. I don't think this should become prohibited and that we should be forced to remove such a local user interface just to make the MA "compliant" to this framework. This is an unnecessary sentence.
------

7.  Security considerations

...

   Since Collectors will be contacted repeatedly by MAs using the

   Collection Protocol to convey their recent results, a successful

   attack to exhaust the communication resources would prevent a

   critical operation: reporting.  Therefore, all LMAP Collectors should

   implement technical mechanisms to:

   o  limit the number of reporting connections from a single MA

      (simultaneous, and connections per unit time).

   o  limit the transmission rate from a single MA.

   o  limit the memory/storage consumed by a single MA's reports.

   o  efficiently reject reporting connections from unknown sources.

   o  separate resources if multiple authentication strengths are used,

      where the resources should be separated according to each class of

      strength.

   o  limit iteration counters to generate keys with both a lower and

      upper limit, to prevent an attacking system from requesting the

      maximum and causing the Controller to stall on the process (see

      section 6 of [RFC5357]).

   Many of the above considerations are applicable to a "pull" model,

   where the MA must contact the Controller because NAT or other network

   aspect prevents Controllers from contacting MAs directly.

The list above this last paragraph is all related to the MA to Collector interface. In the context of that interface, per descriptions in 5.5, these considerations are applicable to the "push" model (where the MA contacts the Collector) and not the "pull" model.

Barbara

From: lmap [mailto:[email-masked]] On Behalf Of [email-masked]
Sent: Friday, June 13, 2014 8:39 AM
To: [email-masked]
Subject: [lmap] new version of framework

Thanks
Phil

--12.6.  From -05 to -06

________________________________

---

From: 邓灵莉/Lingli Deng <[email-masked]>
Date: Thu, 19 Jun 2014 09:36:03 +0800

From: lmap [mailto:[email-masked]] On Behalf Of STARK, BARBARA H
Sent: Thursday, June 19, 2014 2:07 AM
To: [email-masked]; [email-masked]
Subject: Re: [lmap] new version of framework

I have just 2 comments. I’m also emailing a marked up Word version to the authors, that notes all nits that I found.

------

...

In a comment to the -04 version I’d asked to have the last sentence deleted. I didn’t really follow up on this among all the other comments. But I still find this to be an unnecessary restriction. We have lots of devices that could be considered to have MAs that have both a “controller” interface that allows for all Controller - MA activities, and a local user interface for a limited set of user-requested actions. I don’t think this should become prohibited and that we should be forced to remove such a local user interface just to make the MA “compliant” to this framework. This is an unnecessary sentence.

[邓灵莉/Lingli Deng] I don’t see it as a restriction on implementation. It only reads to me that LMAP would not standardize the direct user-MA interface.

------

...

      strength.

      section 6 of [RFC5357]).

The list above this last paragraph is all related to the MA to Collector interface. In the context of that interface, per descriptions in 5.5, these considerations are applicable to the “push” model (where the MA contacts the Collector) and not the “pull” model.

[邓灵莉/Lingli Deng] I agree. And I believe I made the same comment back in May. http://www.ietf.org/mail-archive/web/lmap/current/msg01418.html 

Barbara

Barbara, Greg, Ken and others who’ve made suggestions - Please could you do a quick check to make sure we got your points properly

Thanks

Phil

--12.6.  From -05 to -06

      distinction is removed.

   o  removed Configuration Protocol – Configuration is part of the Instruction and so uses the Control Protocol

---

From: <[email-masked]>
Date: Thu, 19 Jun 2014 13:43:31 +0100

Barbara,

Thanks for the comments - and for the nits (which I'll look at later)

On the first, sorry to have missed this, happy to delete the offending sentence.

On the second, I actually think most of these considerations are applicable whether the mA "pushes" the results or whether the Collector "pulls" them.
Certainly << limit the memory/storage consumed by a single MA's reports>> also I think the transmission rate. I guess limiting the number of connections from a MA is more applicable to push (at least is simple in the pull case!)

Maybe the best thing is simply to delete the final paragraph - don't think it adds anything that hasn't been said elsewhere. So delete

<< Many of the above considerations are applicable to a "pull" model,

phil

From: STARK, BARBARA H [mailto:[email-masked]]
Sent: 18 June 2014 19:07
To: Eardley,PL,Philip,TUB8 R; [email-masked]
Subject: RE: new version of framework

...

...

      strength.

      section 6 of [RFC5357]).

Barbara

From: lmap [mailto:[email-masked]] On Behalf Of [email-masked]<mailto:[email-masked]>
Sent: Friday, June 13, 2014 8:39 AM
To: [email-masked]<mailto:[email-masked]>
Subject: [lmap] new version of framework

Thanks
Phil

--12.6.  From -05 to -06

---

From: "STARK, BARBARA H" <[email-masked]>
Date: Thu, 19 Jun 2014 13:27:32 +0000

<bhs> Thanks. The main problem for me was actually that the intro to the list was about Collector, the final item in the list was about Controller, and the paragraph after the list (about the list) talked about the Controller. There needs to be consistency -- either the entire list and its intro and summary paragraphs are about the Collector, about the Controller, or both. Having the intro and first part of the list being Collector and last item and summary being Controller is very confusing for me.</bhs>

phil

From: STARK, BARBARA H [mailto:[email-masked]]
Sent: 18 June 2014 19:07
To: Eardley,PL,Philip,TUB8 R; [email-masked]<mailto:[email-masked]>
Subject: RE: new version of framework

...

...

      strength.

      section 6 of [RFC5357]).

Barbara

Thanks
Phil

--12.6.  From -05 to -06

---

From: KEN KO <[email-masked]>
Date: Thu, 19 Jun 2014 21:21:29 +0000

I read the last sentence as an explicit prohibition against a user directly initiating a Measurement Task.
I agree with Barbara in asking that it be deleted.

...

---

From: KEN KO <[email-masked]>
Date: Thu, 19 Jun 2014 21:50:25 +0000

Phil,

I've read the new framework document and other than things I've commented on separately, the only issues I found were a couple of minor points:

-          P.17, second bullet in Sec. 5.2.2.1 refers to "Active Measurement Traffic." Delete the word "Active."

-          P.17, sixth bullet specifies "Active Measurement Task(s)." Suggested rewording:

o   a demand that the MA ends any on-going Measurement Task(s) tagged for suppression immediately (and deletes the associated partial Measurement Result(s)). If absent, the MA completes on-going Measurement Tasks.

Thanks very much for everything.

Ken

Thanks
Phil

--12.6.  From -05 to -06

---

From: 邓灵莉/Lingli Deng <[email-masked]>
Date: Fri, 20 Jun 2014 10:06:07 +0800

From: lmap [mailto:[email-masked]] On Behalf Of KEN KO
Sent: Friday, June 20, 2014 5:21 AM
To: 邓灵莉/Lingli Deng; 'STARK, BARBARA H'; [email-masked]; [email-masked]
Subject: Re: [lmap] new version of framework

[邓灵莉/Lingli Deng] In that case, I support the deletion too.

...