Subject: [lmap] review of draft-ietf-lmap-framework-03

From: Juergen Schoenwaelder <[email-masked]>
Date: Fri, 7 Feb 2014 17:25:37 +0100

Hi,

I think the document is generally in a good shape. I do only have a
few technical comments:

a] I do not like the term MA-to-Controller channel. The situation is a
   bit complicated to explain. So let me go through a couple of
   definitions in order to explain why I think the terms we have are
   confusing:

     A Control Protocol "delivering Instruction(s) from a Controller
     to a Measurement Agent" and it "delivers Failure Information and
     Capabilities Information from the Measurement Agent to the
     Controller."

     A Control Channel is a channel "over which Instructions are
     sent."  So this is really an instruction channel somewhat
     mis-labelled as an Control Channel.

     A MA-to-Controller Channel is a channel over which Capabilities
     and Failure Information is sent. I think it would be more
     consistent to call it a Capabilities and Failure Information
     Channel.

   So if we keep the separation of the channels as they are defined, I
   would suggest to rename Control Channel to Instruction Channel and
   MA-to-Controller Channel to Capabilities and Failure Information
   Channel.

   That said, one can ask what the value is of defining two channels
   for the Control Protocol. Since the Control Protocol carries three
   different things, why are two of them in one channel and the third
   in a separate channel? Would it not make sense to either have three
   separate channels (Instruction Channel, Capabilities Channel,
   Failure Information Channel) or, alternatively, to have just one
   Control Channel? What is in the document right now does not seem to
   be very consistent.

   <soap>
     If I were to use lets say NETCONF, then Instruction and Capabilities
     would likely be carried over one "channel" while Failure Information
     would likely be carried over a separate notification "channel". I am
     mentioning this just as an example to demonstrate why the current
     distinction seems somewhat arbitrary.
   </soap>

   As far as I am concerned, my preference is that the terminology has
   a since conceptual Control Channel that carries Instructions,
   Capabilities, and Failure Information. I can also live with having
   three distinct conceptual channels (Instruction Channel,
   Capabilities Channel, Failure Information Channel) between the MA
   and the Controller.

b] The figure on page 14 mentions a "Suppression Channel" which I
   think is a leftover and should be removed. There is also text
   talking about a different channel for Suppressions on page 14.

c] The definition of Capabilities mentions "interface type and speed
   and its IP address" as examples. The text on page 16 says "Note
   that Capabilities do not include dynamic information like the MA's
   currently unused CPU, memory or battery life." For many devices,
   the set of IP addresses assigned to an interface is pretty much
   dynamic information, consider for example temporary IPv6 addresses
   with Randomized Interface Identifiers. My proposal is to (a) add
   text to the definition of Capabilities clarifying that Capabilities
   do not include dynamic information and (b) to remove IP address
   from the examples mentioned in the Capabilities definition.

d] I do not understand the {Comment} on page 20. Overlapping
   measurement tasks may be fine, it really depends on what the tasks
   actually do. I do not think a protocol document can resolve this.
   I sugges to simply remove the {Comment}.

/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/>