[lmap] Feedback on draft-eardley-lmap-terminology

[Benoit Claise <[e-mail]>]

Dear authors,

A couple of high level points.
One of the goal behind this email is to generate discussions, either on 
the list, or during the IETF meeting next week.

-

    The consensus is that the LMAP working group should assume that a
    Measurement Agent receives Instruction from only a single Controller
    at any point in time (however it may Report to more than one
    Collector).

Instead of consensus, I would use "a key assumption"
The charter says:

    A key assumption constraining the initial work is that the
    measurement system is under the control of a single organization
    (for example, an Internet Service Provider or a regulator).

-
Same remark for the term "consensus" in

        The job of a Bootstrap Protocol is to provide an automated way to
        associate a Measurement Agent to its Controller, including
        authentication credentials.  Similarly, there should be a way to pull
        the plug on rogue Measurement Agents.  The current consensus on the
        LMAP mailing list is that the working group should define the
        bootstrap process but not a protocol.

The charter mentions:

    "The management protocol to bootstrap the MAs in measurement devices
    is out of scope of the LMAP charter."

-
I would like to draw your attention to claise-ippm-perf-metric-registry 
<http://tools.ietf.org/html/draft-claise-ippm-perf-metric-registry>, 
which will be presented in IPPM.

-
I'm not too clear if the Measurement Peer are dedicated test server, or 
real server (google.com, SIP server, youtube)
Do the Measurement Peer need the functionality of an IP SLA responder or 
a TWAMP controller?
This might be clarified in the use case draft.

-
This draft is good shape, but it's really a mix of terminology and 
framework concepts.
I'm glad that there is a single delivery in the charter for both:
"1. The LMAP Framework - provides common terminology, basic architecture 
elements, and justifies the simplifying constraints"


Regards, Benoit