[lmap] my comments on draft-akhter-lmap-framework-00

["Romascanu, Dan (Dan)" <[e-mail]>]

Please find below a set of comments after my first reading of draft-akhter-lmap-framework-00. These are made from the perspective of contributor, and take into account the fact that this is a 00 individual submission, so idnits was not run, spelling and references were not checked, etc. 

1. The name of the I-D speaks about 'Inventory' which is a little bit confusing or mis-reading. Actually the authors rather seem to have described some applications and protocols that fit into the LMAP architecture, so it's rather an incomplete 'taxonomy'. See more when talking about the (lack of) requirements. 

2. The previous contributions on LMAP framework included in draft-eardley-lmap-framework were completely ignored, some material is duplicated (in content, not in text), but the eardley I-D is not even included in the list of references. As the two I-Ds (and other relevant contributions) will need to be consolidated into one single WG I-D pretty soon I will refer in the following to some of the similarities and some of the differences. 

3. The order of Sections 1.2 and 1.3 should be reversed. 

4. Figure 1 is almost identical to Figure 1 in draft-eardley with two differences. The first is that the entity named Measurement Peer in draft-eardley is called here Remote Measurement Test Target and seems to have a much richer functionality and variants as illustrated in Sections 3.2 and Figure 2. The option of one measurement agent communicating with multiple Remote Measurement Agents needs to bear a warning concerning scalability. 

5. The second significant difference in the two diagrams is the communication between the Controller and the Collector. Later in the draft this is described as optional and motivated by the need to optimize for Collector Test Configuration synchronization (so that each MA needs not report its configuration to controllers). This addition to the basic architecture needs to be carefully discussed by the WG. 

6. One crisp limitation that is being introduced by draft-eardley is about each MA being configured only by one Controller (motivated among other by the need of simplifying authentication of Controllers with the MA). This limitation is not mentioned in this I-D, at least not explicitly. Is this an editorial miss, or the authors take a different stand on this issue? 

7. Sections 3,4,5 are to some extent written with one set of protocols already in mind to answer LMAP architectural requirements (OWAMP and TWAMP for active monitoring, PSAMP for passive monitoring, IPFIX for reporting protocol, IPFIX mediators to solve the scalability issues). Although this may be a reasonable set of solutions, it seems a little bit too early and too detailed at this phase. Missing here are the basic requirements for the Control protocol, Report protocol, and associated data models. I would prefer to see this being written first. 

8. The Security Consideration section needs to include not only information about authentication, but also about the risks of modification of information (data integrity).

Thanks and Regards,

Dan
(as contributor)