[lmap] draft-burbridge-lmap-information-model

["Bajpai, Vaibhav" <[e-mail]>]

Hello,

I read the draft [1] and made some notes. Thought to share them along:

[1] http://tools.ietf.org/html/draft-burbridge-lmap-information-model-00


- version of measurement test:

  1.  Measurement Task Configuration: Object

          1.  Task Name
          2.  Registry Entry: URN
          3.  Options: Set (optional)
          4.  Measurement Cycle ID: String (optional)


It would be useful to convey the version of measurement test no?

A version bump will usually come due to a bugfix in a specific measurement
test implementation. The version information will help later segregate
measurement results coming out from different measurement test
implementations. hmm?





- measurement time in result report

   5.  Measurement Task: Set

          1.  Measurement Task Configuration: Object
          2.  Result Headers: List
              1.  Column Name: String
          3.  Result Data: List
              1.  Result Row: Object
                  1.  Measurement Time: datetime
                  2.  Cross-traffic: Integer (optional)
                  3.  Result Columns: List
                      1.  Column Data

Would it be useful to have explicit START (datetime) and END (datetime) in
replacement for the Measurement Time (datetime)? I mean the START and END
times when the measurement was performed.




- pre-configured information:

 Detail of the information model elements:

  1.  MA MAC: MAC Address
  2.  Controller: FQDN
  3.  MA Certificate: Certificate
  4.  Controller Communication Timing: Timing

maybe we should add these too, no? (it is discussed in the previous paragraph,
just seems to be missing from the list of items)

  5.  MA Private Key
  6.  CA certificate





- configuration information (retrieved from controller):

  1.  Measurement Agent ID: String
  2.  Measurement Group ID (optional): String
  3.  Report MA ID flag (optional): Boolean

If I understand correctly, this is additional information sent, when the MA
registers with the controller for the first time. In the LMAP protocol draft
[draft-bagnulo-lmap-http-00], however, we assume that the MA UUID is baked in
as part of the pre-configured information in the MA.

[draft-bagnulo-lmap-http-00] -

  In particular each MA has a version 4 UUID, which is
  randomly or pseudo randomly generated.  We assume that the UUID is
  preconfigured in the MA before deployment.

This could also be because in the LMAP protocol draft
[draft-bagnulo-lmap-http-00], we only have pre-configured information, and
the controller is only contacted to receive measurement instructions
(measurements, schedule, reporting channels).  Probably, we should discuss and
synchronize this no?





- measurement protocol

  and several measurement protocols between the MAs used to actually perform
  the measurements.

I searched the terminology document [draft-eardley-lmap-terminology-01], but
could not find a description of measurment protocol.





- measurement suppression instruction is defined in the information model, but
  is not discussed in the terminology [draft-eardley-lmap-terminology-01] and
  LMAP protocol drafts [draft-bagnulo-lmap-http-00].




Best, Vaibhav


-----------------------------------------------------
Vaibhav Bajpai

Research I, Room 86
Computer Networks and Distributed Systems  (CNDS) Lab
School of Engineering and Sciences
Jacobs University Bremen, Germany

www.vaibhavbajpai.com