[lmap] AD review of draft-ietf-lmap-framework-10

[Benoit Claise <[e-mail]>]

Dear all,

First of all, very sorry for the delay in getting back to you.
Thank you for this new draft version. The document really improved 
between version 8 and 10.
Here is my feedback on version 10. Nothing major. I propose to start the 
IETF LC as soon a new version is posted

- In http://tools.ietf.org/html/draft-ietf-lmap-use-cases-06, LMAP 
stands for Large-scale Measurement of Broadband Performance.
Here, in the abstract, it stands for large-scale measurement platforms. 
Please change it.

- Some repetitions in section 1

    It is expected
    that such a system could easily comprise 100,000 devices.

       It is expected that a Measurement
       System could easily encompass a few hundred thousand or even
       millions of Measurement Agents.

- Section 2
OLD:

    Another possibility is for the
    MA may generate (or receive) traffic specially created for the
    purpose and measure some metric associated with its transfer.

NEW:
    Another possibility is for the
    MA_to_generate (or receive) traffic specially created for the
    purpose and measure some metric associated with its transfer.

- Section 2
OLD:

	Messages are transferred over a secure Channel.

NEW:
	Both control and report messages are transferred over a secure Channel.

-

results repository or Results repository?
Please check all instances.

- Figure 1
The Report goes over the Report Channel, not Control Channel

- Figure 1
The traffic between "End user or Measurement Peer" represents the MA 
passive monitoring.
If you would add an arrow from the MA to End User or Measurement Peer on 
the right (to show that some MAs can generate active traffic), you would 
have a complete picture.
Something like this:

    +-----------+                         +-----------+     ^
    |End user or|                         |End user or|     |
    |Measurement|                         |Measurement| Non-LMAP
    |  Peer     |                         |   Peer    |   Scope
    +-----------+                         +-----------+     v
        ^                                        ^ ^
         \ Observed +---------------+           / /         ^
          \.........|...............|........../ /          |
       Traffic Flow | Measurement ..|.........../           |
       +----------->|   Agent       |Measurement Traffic    |
       |            +---------------+                       |


Note that I have reused your terminology: Measurement Traffic and 
Observed Traffic Flow

- Section 5.2.2

Instruction:                            ->
    [(Measurement Task configuration
        URI of Metric(
       [Input Parameter],
       (interface),
       (Cycle-ID))),
     (Report Channel),
     (Schedule),
     (Suppression information)]

Should we expect a 1:1 mapping between the parameters above and the list 
that follows?
For example, I see in the list

          * the Measurement Method role.  For some Measurement Methods,
          different parties play different roles; for example (figure A3
          in the Appendix) an iperf sender and receiver.  Each Metric and
          its associated Measurement Method will describe all measurement
          roles involved in the process.

          * optionally, the measurement point designation
          [I-D.ietf-ippm-lmap-path  <http://tools.ietf.org/html/draft-ietf-lmap-framework-10#ref-I-D.ietf-ippm-lmap-path>] of the MA and, if applicable, of the
          MP or other MA.  This can be useful for reporting.

- Section 5.2.2
I guess that most MAs will have one Report Channel, as the default 
option. Right?

OLD:
  o  configuration of the Report Channels, each of which needs:

NEW:
  o  configuration of the Report Channel(s), each of which needs:

- Section 5.2.3

OLD:

       the MA failed record the Measurement Results because it
       (unexpectedly) is out of spare memory

NEW:
       the MA failed_to_record the Measurement Results because it
       (unexpectedly) is out of spare memory

- Section 5.4.1
To match the charter:
OLD:
     It may also be possible to transfer the information via the MA.

NEW:
     If the subscriber's service parameters are available to the MAs, 
they could be reported
     with the Measurement Results in the Report Protocol.

- section 6 Deployment considerations

    The Appendix has some examples of possible deployment arrangements of
    Measurement Agents and Peers.

What does this text tell me? Should I read the appendix before proceeding?
If yes (btw, I think this is the natural reading flow), why is this an 
appendix, and not in the core of the document?
Note: this appendix contains some nice examples that really glue all the 
concepts into practical examples.

- Appendix A
OLD:

    Next, we consider Measurement Methods that measure user traffic.

NEW:

    Next, we consider Measurement Methods that meter the Observed Traffic Flow.

NEW figure A4

    +--------+   +----------------+            +--------+      ^
    |End user|   |  MA: Monitor   |  Observed  |End user|      |
    | or MP  |<--|----------------|--Traffic ->| or MP  |  non-LMAP
    |        |   |                |  Flow      |        |    Scope
    +--------+   |                |            +--------+      |
              ...|................|............................v..
                 | LMAP interface |                            ^
                 +----------------+                            |
                         ^     |                               |
             Instruction |     |  Report                       |
                         |     +-----------------+             |
                         |                       |             |
                         |                       v            LMAP
                   +------------+             +------------+  Scope
                   | Controller |             |  Collector |   |
                   +------------+             +------------+   v


    Figure A4: Schematic of LMAP-based Measurement System,
    with a Measurement Agent monitoring traffic


- Security Considerations
There is a privacy aspects for Observed Traffic Flow (typically the 
figure A4), as you mentioned in sections 8.2, 8.3, 8.4.5 (and maybe some 
others). FYI. This has been addressed in IPFIX: see 
https://tools.ietf.org/html/rfc7011#section-11.8

- Question: Have you discussed the ability for LMAP to use sampling for 
Observed Traffic Flows? Is this necessary?
See http://datatracker.ietf.org/wg/psamp/documents/

Regards, Benoit