Subject: Re: [lmap] draft-ietf-lmap-framework-07 3rd WGLC

From: Juergen Schoenwaelder <[email-masked]>
Date: Sun, 6 Jul 2014 13:49:03 +0200

On Tue, Jun 24, 2014 at 12:04:30PM -0400, Weil, Jason wrote:

> This is to initiate a two week working group last call on
> http://tools.ietf.org/html/draft-ietf-lmap-framework-07 There has
> been extensive discussion on a number of items following the 2nd
> WGLC and the chairs would like feedback from the WG to see if all
> major concerns have been addressed. Please take a look at this
> updated version and provide comments or a statement of support for
> draft as written to the list by July 8th. Nits and minor edits can
> be sent to the authors.

I did read -07 from beginning to end and here are my comments.
(Previously I focused more on reviewing the changes and most
importantly the terminology section.)

* Definition of Control Protocol

   Control Protocol: The protocol delivering Instruction(s) from a
   Controller to a Measurement Agent.  It also delivers Capabilities,
   Failure and Logging Information from the Measurement Agent to the
   Controller.  It can also be used to update the MA's configuration.

  Since 'configuration' is not a defined term, it remains somewhat
  unclear what "update the MA's configuration" means. If I have a
  device that is for example configured using NETCONF, will the
  Control Protocol interfere with it by messing around with NETCONF
  datastores? What is the reason for having the last sentence?

  Perhaps configuration has a much more limited meaning here, as in
  section 5.2.1. But in that case, it might be useful to define the
  term Configuration explicitly so that the scope of it is clear.

  Note, I also see Configuration capitalized in 5.2.1...

* Definition of Report Channel

   Report Channel: a communications channel between a MA and a
   Collector, which is defined by a specific MA, Collector, Report
   Schedule and associated security, and over which Reports are sent.

  Do we really want the Report Schedule to be an intrinsic part of the
  Report Channel? That is, we rule out that reports of different
  measurement tasks are sent over the same channel using different
  schedules? Or that several report channels follow the same schedule?

  Note that the definition of Instruction explicitely mentions
  "configuration of Report Schedule(s)" - it seems this definition
  does not assume the Report Schedule to be part of the Report
  Channel.

  Also section 5.2.2 seems to treat report channels as being distinct
  from report channels.

* Section 5.1

  Devices have in general multiple MAC addresses these days. Hence:

  s/such as its MAC/one of its MAC addresses/

  I do not understand this "multi-stage process where the MA contacts
  the device" - it remains unclear to me what "the device" is here.

* Section 5.4

  The MA should also include the Cycle-ID if it has been set in the
  report. This needs to be added to the ascii art and the itemized
  list.

* Section 6.1

  This section says "The different elements of the Instruction can be
  updated independently." while section 5.2.2 says that it is up to
  the protocol to define the granularity.

  I also do not understand what this tells me: "There could be a
  problem if, for example, a Measurement Task involving a 1kB file
  upload could be changed into a 1GB file upload." There are many ways
  to shoot yourself into the foot, why is it needed to discuss
  specific update examples? 

* Section 6.2.3

  What does "prop open the firewall" mean?

* Section 8.1

  Broken sentence:

     [...] performing Measurement Tasks and collecting and Results.

  Probably you meant:

     [...] performing Measurement Tasks and collecting Results.

* Section 8.4

  What is the 'Assigned Controller IP address or FQDN'? I thought
  there is only an Initial Controller IP address or FQDN. Since these
  words are capitalized, where is the definition of these terms? I
  actually do not think these need to be capitalized. (Or are these
  capitalized because these are list items? But then the list is
  part of a sentence - at least logically, no?)

* Section 8.4.4

  It is not clear why a detailed figrue is needed here. What is
  missing, I think, is that the MP may look at the IP addresses
  traffic is originating from an study the behaviour over time.  It
  may be possible to figure out for example at which times a certain
  MA is not seeing cross traffic, e.g. at which times someone is on
  vacation. And perhaps even pairing this information with traffic
  injection, one might be able to obtain more information about the
  nature of a subscriber than the IP address itself may reveal.  The
  point is that traffic analysis at the MP may actually reveal
  interesting insights even though the measurement protocol itself
  does not carry much privacy sensitive information.

* Overall

  I would have preferred the document to be more concise and less
  repetitive. Saying things once instead of multiple times has the
  advantage that it is easier to ensure consistency.

  While this is an Informational document, there are some sections
  that are more important than others. For instance, I expect the
  terminology to be used in normative documents and I also think the
  section on constraints and the protocol is relatively important
  while the section on deployment considerations seems more an essay
  on how to use things. Hence, I suggest to move section 6 into the
  appendix next to the deployment examples (or even better merge the
  section with appendix A since there is yet more redundancy) in order
  to indicate that in case of inconsistencies, the other sections in
  the main body of the document are authoritative.

* Editorial

  Capitalization of section headers is inconsistent.

  Since the document is about LMAP, do we need to repeat LMAP in
  some section headers or can we leave it out consistently, i.e.,

  s/LMAP Protocol Model/Protocol Model/
  s/Privacy Considerations for LMAP/Privacy Considerations/

  In xml2rfc, you can start an appendix simply by moving the
  <section/> into the <back/> element (usually following the
  <references/> elements).

/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: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Tue, 8 Jul 2014 18:04:32 +0000

Hi,

I support the submission of the document to the IESG for consideration as Informational RFC.

There are a few issues that should be clarified however, please see my comments below:

Technical Comments

1.       In section 2: A device with a Measurement Agent may have multiple physical interfaces (Wi-Fi, Ethernet, DSL, fibre) - not sure what 'fibre' has to do with this enumeration, it's a physical media, Ethernet can run atop of it, I would drop it

2.       5.2.2.1: assuming several Suppress messages where sent to the same MA suppressing different elements (different schedules, distinct Measurement Tasks, etc.) does one un-Suppress message cancel all previous Suppresses? - please clarify

3.       In Section 5.4 - The content of the report should include the network address to support the multi-homing cases discussed in section 6.2.4

4.       Also in Section 5.4 - the time of the acquisition of the Management Results is included in the reports - is there any requirement on a minimal granularity, or clocks synchronization? Even if there is none, it would be good to be clear on this

5.       Security Considerations - there is no mention about the need to authenticate collectors with the MAs - how is a masquerade attack preempted? Maybe a more generic requirement should be mutual authentication of all pairs (controller, MA) and (MA, collector)

Editorial Comments

1.       Numbering the Appendix as a Section is confusing, the usual convention is to list the Appendix after all the other sections as Section A, or Section A1, etc.

2.       Quite a lot of acronyms need expansion at the first occurrence - worth making a pass on these

3.       In Section 2 - 'In this section we provide an overview of the whole measurement system and we introduce the main terms needed for the LMAP framework.' this seems a leftover a previous version where outline and terminology were in the same section, now terminology is in Section 3

4.       In Section 3 - I suggest to drop 'and that is carefully specified' from the definition of the term 'Metric'

5.       4.1 - add The in the title

6.       When talking about the Control Protocol - logging is inconsistently capitalized in some places 'Failure and Logging', in other 'Failure and Logging' - I suggest consistency (I prefer the capitalized form)

7.       Section 5 s/ define elsewhere (e.g.  IPPM)/ defined elsewhere (e.g.  IPPM)/

8.       Section 5.2.3 - I believe that the title of this section should be Capabilities, Failure and Logging Information

Regards,

Dan

From: lmap [mailto:[email-masked]] On Behalf Of Weil, Jason
Sent: Tuesday, June 24, 2014 7:05 PM
To: [email-masked]
Subject: [lmap] draft-ietf-lmap-framework-07 3rd WGLC

This is to initiate a two week working group last call on http://tools.ietf.org/html/draft-ietf-lmap-framework-07  There has been extensive discussion on a number of items  following the 2nd WGLC and the chairs would like feedback from the WG to see if all major concerns have been addressed. Please take a look at this updated version and provide  comments or a statement of support for draft as written to the list by July 8th. Nits and minor edits can be sent to the authors.

Thanks,

Jason

________________________________
This E-mail and any of its attachments may contain Time Warner Cable proprietary information, which is privileged, confidential, or subject to copyright belonging to Time Warner Cable. This E-mail is intended solely for the use of the individual or entity to which it is addressed. If you are not the intended recipient of this E-mail, you are hereby notified that any dissemination, distribution, copying, or action taken in relation to the contents of and attachments to this E-mail is strictly prohibited and may be unlawful. If you have received this E-mail in error, please notify the sender immediately and permanently delete the original and any copy of this E-mail and any printout.

---

From: KEN KO <[email-masked]>
Date: Tue, 8 Jul 2014 21:21:29 +0000

I also support the submission of the document to the IESG. And, I also have a few comments.

Section 5.2.2.1: There is ambiguity in what to do when both a set of Tasks and a set of Schedules are supplied in a Suppression element. I suggest we disallow this combination and say that either Tasks or Schedules, but not both, may be specified.

The remaining comments relate to descriptive text in this document compared to corresponding material in the Information Model. I consider them largely editorial for the framework since the normative material properly belongs in the IM.

Figure on p.15: Change Measurement Schedule and Report Schedule to generic Schedule. Even better, delete that level of detail in the figure and simply show Instruction and  Response. This comment applies to all of the figures – leave the detail in the message structures to the Information Model.

p.16, Measurement Method role: It may be better to define the role with a field of its own rather than just calling it a parameter, since the role is integral to reporting of capabilities. I’m making a similar comment on the IM draft.

p.16, suppression flag. This does have its own field in the Task configuration rather than being an input parameter.

p.16: Configuration of Measurement Schedules and Report Schedules is listed separately. Since these are both handled as Schedules in the IM it would probably read better for them to both be discussed in the same bullet here.

Ken

From: lmap [mailto:[email-masked]] On Behalf Of Weil, Jason
Sent: Tuesday, June 24, 2014 7:05 PM
To: [email-masked]<mailto:[email-masked]>
Subject: [lmap] draft-ietf-lmap-framework-07 3rd WGLC

Thanks,

Jason

---

From: <[email-masked]>
Date: Mon, 21 Jul 2014 15:32:00 +0100

Ken,

thanks for the comments. will check these points to make consistent with the Info Model - and try to leave the detail for the info model.

<<Section 5.2.2.1: There is ambiguity in what to do when both a set of Tasks and a set of Schedules are supplied in a Suppression element. I suggest we disallow this combination and say that either Tasks or Schedules, but not both, may be specified.>>
i don't think this is ambiguous  - surely you just suppress a task if it's either listed explicitly, or is in a listed schedule.

One question about suppression
<<So the default action (if none of the optional fields is set) is that
   the MA does not begin any new Measurement Task with the "suppress"
   flag.

suppose the optional field for "start time for suppression" is set, but none of the other fields. a strict reading of the current text means that we don't follow the default action, so we suppress specifically list of tasks/schedules - but this field is empty  -  therefore nothing is suppressed.
i presume this isn't what we want.
so we mean that we suppress tasks with the "suppress flag", unless there's a specific list of tasks or schedules.

phil

________________________________
From: lmap [[email-masked]] On Behalf Of KEN KO [[email-masked]]
Sent: 08 July 2014 22:21
To: Weil, Jason; [email-masked]
Subject: Re: [lmap] draft-ietf-lmap-framework-07 3rd WGLC

Ken

Thanks,

Jason

---

From: <[email-masked]>
Date: Mon, 21 Jul 2014 15:57:16 +0100

Dan,
thanks!
in-line
phil

________________________________
From: lmap [[email-masked]] On Behalf Of Romascanu, Dan (Dan) [[email-masked]]
Sent: 08 July 2014 19:04
To: Weil, Jason; [email-masked]
Subject: Re: [lmap] draft-ietf-lmap-framework-07 3rd WGLC

Hi,

Technical Comments

1.       In section 2: A device with a Measurement Agent may have multiple physical interfaces (Wi-Fi, Ethernet, DSL, fibre) – not sure what ‘fibre’ has to do with this enumeration, it’s a physical media, Ethernet can run atop of it, I would drop it

[phil] - ok

2.       5.2.2.1: assuming several Suppress messages where sent to the same MA suppressing different elements (different schedules, distinct Measurement Tasks, etc.) does one un-Suppress message cancel all previous Suppresses? – please clarify

[phil] - not sure i agree with your assumption. i've been thinking that a suppress message should replace an earlier one.

what do people think? given that suppression is a rare event used in emergencies, i'd favour whatever keeps things simplest.

3.       In Section 5.4 – The content of the report should include the network address to support the multi-homing cases discussed in section 6.2.4

[phil] yes, in this case the network address used for the measurements needs to be reported. I think this should be mentioned in the Info model - i guess it's part of ma-context-obj

(The info model is rather brief and just says <<The ma-context-obj, which covers things like line speed or the device type, is not further detailed here.>>)

4.       Also in Section 5.4 – the time of the acquisition of the Management Results is included in the reports – is there any requirement on a minimal granularity, or clocks synchronization? Even if there is none, it would be good to be clear on this

[phil] comments? i assume no requirements, and this is just the MA's estimate of the time

5.       Security Considerations – there is no mention about the need to authenticate collectors with the MAs – how is a masquerade attack preempted? Maybe a more generic requirement should be mutual authentication of all pairs (controller, MA) and (MA, collector)

[phil] thanks, yes this case should be mentioned

Editorial Comments

[phil] I can't work out how to do this (xml mind xml editor), so will leave this for RFC editor, unless someone knows how to solve

2.       Quite a lot of acronyms need expansion at the first occurrence – worth making a pass on these

3.       In Section 2 – ‘In this section we provide an overview of the whole measurement system and we introduce the main terms needed for the LMAP framework.’ this seems a leftover a previous version where outline and terminology were in the same section, now terminology is in Section 3

4.       In Section 3 – I suggest to drop ‘and that is carefully specified’ from the definition of the term ‘Metric’

[phil] Any objections to this change?

5.       4.1 – add The in the title

6.       When talking about the Control Protocol – logging is inconsistently capitalized in some places ‘Failure and Logging’, in other ‘Failure and Logging’ – I suggest consistency (I prefer the capitalized form)

8.       Section 5.2.3 – I believe that the title of this section should be Capabilities, Failure and Logging Information

Regards,

Dan

Thanks,

Jason

---

From: KEN KO <[email-masked]>
Date: Mon, 21 Jul 2014 15:03:15 +0000

I agree - each Suppress (or Unsupress) message replaces any previous message. I thought that was already documented but can't find it so we should make it clear.

---

From: KEN KO <[email-masked]>
Date: Mon, 21 Jul 2014 14:57:59 +0000

Phil, responses inline …
Ken

From: [email-masked] [mailto:[email-masked]]
Sent: Monday, July 21, 2014 10:32 AM
To: KEN KO; [email-masked]; [email-masked]
Subject: RE: draft-ietf-lmap-framework-07 3rd WGLC

Ken,

Here is an example: you have two Schedules: Schedule 1 with Tasks A, B and C and Schedule 2 with Tasks C, D and E.
You receive a Suppression element listing Schedule 1 and Task C. Do you:

-          Suppress all of the Tasks in Schedule 1 and also Task C in Schedule 2 (the union of the lists)?

-          Suppress only Task C and only in Schedule 1 (the intersection of the lists)?

I have seen this question raised in the lmap list before (by Juergen perhaps?) and I think both could be considered valid interpretations unless we clarify what is meant. I suggested that we disallow both lists in the same Suppression message because that incrementally simplifies the MA, but I would also be satisfied if we resolve the ambiguity. (and my choice would be to resolve it as the union of the two lists, which I think is also your choice since you used “or” in your comment above.)

Nice catch – I agree with you. Since the third bullet in the list immediately preceding this sentence already describes this behavior very well, we could simply delete the sentence.

phil

To: Weil, Jason; [email-masked]<mailto:[email-masked]>

Figure on p.15: Change Measurement Schedule and Report Schedule to generic Schedule. Even better, delete that level of detail in the figure and simply show Instruction• and • Response. This comment applies to all of the figures – leave the detail in the message structures to the Information Model.

Ken

Thanks,

Jason

---

From: <[email-masked]>
Date: Tue, 22 Jul 2014 15:32:32 +0100

yes, i meant the union of the lists

________________________________
From: KEN KO [[email-masked]]
Sent: 21 July 2014 15:57
To: Eardley,PL,Philip,TUB8 R; [email-masked]; [email-masked]
Subject: RE: draft-ietf-lmap-framework-07 3rd WGLC

Phil, responses inline …
Ken

Ken,

phil

Ken

Thanks,

Jason

---

From: <[email-masked]>
Date: Tue, 22 Jul 2014 16:26:34 +0100

Juergen - thanks!
in-line
phil
________________________________________
From: lmap [[email-masked]] On Behalf Of Juergen Schoenwaelder [[email-masked]]
Sent: 06 July 2014 12:49
To: Weil, Jason
Cc: [email-masked]
Subject: Re: [lmap] draft-ietf-lmap-framework-07 3rd WGLC

[phil] ok, we can define Configuration. it's something like: The process for informing the MA about its MA-ID, the (optional) Group-ID and the Control Channel

[phil] you're right. i forgot to update the definition, it should be similar to the definition of Control Channel, so something like
   Report Channel: a Channel between a Collecctor and a MA over which
   Report messages are sent.

* Section 5.1

[phil] ok, i think "the device at" can be deleted

* Section 5.4

[phil] ok

* Section 6.1

[phil] the S5.2.2 text is correct - will align 6.1
think an illustrative example may be useful?

* Section 6.2.3

[phil] i think some words here haven't been aligned with the terminology, will update.

* Section 8.4.4

[phil] good points, thanks.

* Overall

[phil] Happy to move S6 to Appendix - please say if you object.
I'll look at how easy it is to merge S6 into the current Appendix (and when I'd have enough time to do a merger - don't want to delay the doc too long)
The other places that maybe repeat a bit what's elsewhere in the doc - the intro and the privacy section. however, think these are ok - need an intro so the new reader understands the overall point of lmap, and the privacy section is fairly self-contained discussion of privacy issues. 

* Editorial

[phil] thanks, will try and create an appendix like this. 

/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/>
_______________________________________________
lmap mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/lmap

---

From: "MORTON, ALFRED C (AL)" <[email-masked]>
Date: Tue, 22 Jul 2014 11:46:29 -0400

On,

j/ wrote
* Section 8.4.4

I thought this was addressed somewhere, but I agree this could be
a place to emphasise the point that the presence of certain types
of measurement traffic indicates the absence of conflicting subscriber traffic,
and over long periods an observer can infer that the subscriber is 
absent.  However, it might be simpler to distinguish measurement traffic 
based on its repeating nature, from user traffic, and the user traffic
would also be absent when user is on-vacation. We are talking about
focused surveillance of a user, and there are many possibilities under
those circumstances. 

Al

________________________________________
From: lmap [[email-masked]] On Behalf Of [email-masked] [[email-masked]]
Sent: Tuesday, July 22, 2014 11:26 AM
To: [email-masked]; [email-masked]
Cc: [email-masked]
Subject: Re: [lmap] draft-ietf-lmap-framework-07 3rd WGLC

Juergen - thanks!
in-line
phil