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

[<[e-mail]>]

Hi Vaibhav, thanks for the very useful comments/discussion.

See inline for my answers....

Trevor.

>-----Original Message-----
>From: [e-mail] [mailto:[e-mail]] On Behalf Of
>Bajpai, Vaibhav
>Sent: 10 July 2013 13:10
>To: [e-mail]
>Cc: Bajpai, Vaibhav; <[e-mail]>
>Subject: [lmap] draft-burbridge-lmap-information-model
>
>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?

Yes I agree. I considered and then removed some 'metadata' on the information objects: namely author, creation date, name (where not required by the MA as a reference, description and version number since I didn't want to clutter the first version too much. However I think I was over-zealous since I agree that the Measurement Configuration Version is something that should be reported by the MA.


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

I think the tests for which this is relevant can report a duration data column or even an end time if they want/prefer. Not against the idea, I just don't know it is required in the IM as it would be optional (since many tests wouldn't want to record or report this). I can see the point in having it in the standard IM though if you do want to isolate any measurement results that were conducted entirely within a period - just not sure how useful this is.

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

I originally had the certificate on the Controller and Collector in the IM. However, since these will be provided as required and fetched/validated outside the LMAP framework I removed them. Not against putting them back in, but not sure if strictly necessary.

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

This is an important discussion I think. Either the MA is given an ID when it registers, or it is pre-configured with and ID. I tended to prefer the first option since it allows IDs to be allocated depending on the registration context. It also doesn't waste ID space on MAs that may never be switched on. It also enables multiple vendor devices pre-configured by those vendors to receive guaranteed unique MAs from the Controller.

I'm not yet convinced the ID is required in order to contact the Controller, so the bottom line is that it can be allocated at registration.

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