Subject: [lmap] comments on draft-eardley-lmap-terminology-00.txt

From: Juergen Schoenwaelder <[email-masked]>
Date: Mon, 15 Apr 2013 13:46:51 +0200

Hi,

I have read draft-eardley-lmap-terminology-00.txt and here are some of
my comments:

a) In section 2, I suggest you use IP addresses from the reserved
   example address space, see RFC 5737 for IPv4.

b) Bullet #5 in section should not really be a bullet. It might be
   useful to switch to a numbered list and then this bullet can be
   moved behind the list stating "Items 1-4 effectively define a
   Measurement Task" and then you add "Items x-y effectively define a
   Report" (removing "The definition of the Report." from the current
   bullet 6 since also subsequent bullets seem to belong to a Report).
   (Yes, this is editorial nitpicking, I know.)

c) End of section 2: You seem to put JSON and YANG into the same bin
   but I think they are not. YANG is traditionally used to describe
   the structure of data that is serialized in XML. (There is also
   some work to also serialize YANG specified data into JSON.) In
   other words, YANG is a data modeling language, JSON is an encoding
   format and so you would need to talk about a JSON schema language
   here.

d) Definition of Active Measurement Method: should we not replace
   "two" with "at least two"? Section 4 has already some examples
   why more than two MAs may be involved in an Active Measurement
   Task.

e) Does it make sense to introduce abbreviations for at least some of
   the terms? This way, we could write MA in emails like this and be
   sure everybody reads that as Measurement Agent.

f) Controller: s/an Instruction/Instructions/

g) Control Protocol: I suggest to rephrase this as follows:

   Control Protocol: The protocol delivering Instructions from a
   Controller to a Complete-MA.

   I think this shorter version is sufficient and avoids confusion
   (some might read transport protocol that as a layer 4 protocol).

h) Information Model: I suggest to rephrase this:

   Information Model: The protocol neutral definition of the semantics
   of either the Instruction or the Report.

   This aligns with RFC 3444. In particular, I disagree that
   arrangement of fields (the order they appear in and any hierarchy)
   belong into an Information Model. 

   Note: JSON does not maintain order of the name/value pairs making
   up an object, see RFC 4627.

i) Instruction: I suggest to remove "; a specific instance of the Data
   Model" given that the definition of "Data Model" is fairly broad.

j) Report Protocol: I suggest to rephrase this as follows:

   Report Protocol: The protocol delivering Reports from a Complete-MA
   to a Collector.

   I think this shorter version is sufficient and avoids confusion
   (some might read transport protocol as a layer 4 protocol).

k) I think the last paragraph in section 4 should not be there. In
   fact, I likely won't agree to it as it goes far beyond talking
   about terminology. So I propose to remove this paragraph and
   instead to define the term Bootstrap Protocol, e.g. like this:

   Bootstrap Protocol: A protocol that initializes a Complete-MA
   with the information necessary to talk to a Controller.

   If you want to keep text in section 4, you may mention that there
   might be different bootstrap protocols and that organizations other
   than the IETF might design their own bootstrap protocols (e.g., BBF
   based on TR-069).

l) We found it very useful to talk about something we call a
   Measurement Cycle.

   Measurement Cycle: A collection of Measurement Results collected
   for over a given time period and/or for a specific purpose,
   typically with a consistent set of measurement parameters and a
   consistent Measurement Schedule.

   We found it very helpful to have data tagged with a Measurement
   Cycle identifier when it is received by the collector. This allows
   to filter out data easily during data analysis without having to
   track when an updated was actually pushed to an MA.

Finally, should we also define the terms Measurement Parameters and
Environmental Constraints? They are part of the Instruction according
to section 2 but not covered by the terms defined.

I also have comments concerning MA, Complete-MA, and Remote MA but
I will put those into a different email.

/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: <[email-masked]>
Date: Thu, 18 Apr 2013 09:29:27 +0100

Thanks Juergen, very useful improvements. I basically agree with them all

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> Juergen Schoenwaelder
> Sent: 15 April 2013 12:47
> To: [email-masked]
> Subject: [lmap] comments on draft-eardley-lmap-terminology-00.txt
...
>    format and so you would need to talk about a JSON schema language

So where S2 says <<they consist of a Data Model (the semantics and structure of the information, in a particular language such as JSON or YANG) >>

How should do you suggest this is re-phrased? [I suppose just deleting "JSON or" is one answer]

>    why more than two MAs may be involved in an Active Measurement

Assuming we change to Measurement Agent and Measurement Peer, this needs some re-phrasing anyway.
Not sure whether we should take account of possibly more than two Measurement <thingies> being involved - at least I don't yet understand how this would really work (would the generator of cross-traffic just be at the MA?) - so am inclined to modify later.

Also, am I right in thinking that an Active Measurement Method (Task) always involves a Measurement Agent and a Measurement Peer? 
(ie it never involves two Measurement Agents; ie for a particular Task, the same entity always gets the Instruction and sends the Report.)

>    sure everybody reads that as Measurement Agent.

"MA" is in the terminology. 
Think other abbreviations should be introduced later, when the terms have embedded in our brains. Otherwise too much potential for confusion!

> to section 2 but not covered by the terms defined.

Prefer to add terms as we're sure we need them. Suggest that we see how the Information Models progress - will probably then become clearer which terms are needed (I guess it quite likely that something like Task Parameters will be useful - not sure about environmental constraints)

Thanks
Phil

Ps separate emails about measurement cycle and bootstrap protocol

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Thu, 18 Apr 2013 20:38:44 +0200

> How should do you suggest this is re-phrased? [I suppose just deleting "JSON or" is one answer]

Several options are possible:

... in a particular data modeling language such as YANG

... in a particular data modeling language such as a JSON schema
    language or YANG

... in a particular data modeling language.
 
> Assuming we change to Measurement Agent and Measurement Peer, this
> needs some re-phrasing anyway.  Not sure whether we should take
> account of possibly more than two Measurement <thingies> being
> involved - at least I don't yet understand how this would really
> work (would the generator of cross-traffic just be at the MA?) - so
> am inclined to modify later.

As long as there is not a strong reason why a MA can not talk to
multiple MPs, I would allow this. Consider an MA that sends out a
multicast and has multiple MPs echo results back. How do I look at an
MA that does a traceroute? Are all the routers on the path sending
ICMP packets acting as MPs in this case? I would prefer to keep the
definition flexible - narrowing it down is easy, widening it later on
may be much harder.

> Also, am I right in thinking that an Active Measurement Method
> (Task) always involves a Measurement Agent and a Measurement Peer?
> (ie it never involves two Measurement Agents; ie for a particular
> Task, the same entity always gets the Instruction and sends the
> Report.)

This is a tough one. Making this assumption clearly simplifies things
a lot.

> Think other abbreviations should be introduced later, when the terms
> have embedded in our brains. Otherwise too much potential for
> confusion!

Oops, started to use MP above - sorry for that. ;-) 

> Prefer to add terms as we're sure we need them. Suggest that we see
> how the Information Models progress - will probably then become
> clearer which terms are needed (I guess it quite likely that
> something like Task Parameters will be useful - not sure about
> environmental constraints)

I am almost 100% sure we need Measurement Task Parameters and somewhat
confident about Environmental Constraints.

/js