Subject: [lmap] comments on draft-starkcarey-lmap-protocol-criteria-00

From: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Wed, 11 Feb 2015 13:28:46 +0000

Hi,

Thanks to the two editors for putting together the criteria and documenting them in this useful I-D.

Please find below my comments - please address them before or during the LMAP WG interim meeting tomorrow:

1.       I do not believe that there is a need to mention 2119 and refer to keywords. The document does not use 2119 keywords, which is good.

2.       The Mandatory Criteria sections 2.1 and 3.1 include the following sentence whose intent is lost to me:

Ø  .  Note
   that although the protocol may support the criterion, it is not
   necessarily the case that the criterion is mandatory to implement

What does this mean? A mandatory criterion MUST be implemented. Maybe the intent is to say that the criterion (function) may be optional in the respective protocol, but MUST be implemented for LMPA purposes? In this case clarification text would be useful.

3.       CP-MUST-3 and RP-MUST-2 describe the need for the respective protocols 'of being secured using certificates'. I believe that it is necessary to be explicit what 'being secured means for each of the protocols (authentication, encryption for privacy, protection against replay attacks, etc.). Also certificates are being mentioned only with a title of example in draft-ietf-lmap-framework. Why are they turned here in a requirement?

4.       CP-DIFF-3: 'It is possible to provide partial updates' - of what? Instruction set? Or status? Or both?

5.       CP-DIFF-4: 'asking out of curiosity' is not a good thing in a criteria document. If having an associated NAT/firewall traversal mechanism as part of the protocol is considered an advantage, then let us leave is as a criterion, and make clear that 'yes is better'

6.       CP-DIFF-5, CP-DIFF-6, RP-DIFF-6 use number of bytes as a function of the overhead. Absolute numbers do not say the whole story when it comes to overhead. I would add overhead bytes per message and overhead bytes divided to the total number of bytes (overhead percentage)

7.        I do not understand CP-DIFF-8 and RP-DIFF-7. What are 'mechanism to ensure interoperability'? The protocols themselves need to ensure interoperability. I must be missing something.

8.       CP-DIFF-11/12, and RP-DIFF-10/11 respectively: I believe that making (both) protocols versionable is a mandatory requirement. The second requirement in each set seems to be more a clarification question providing additional information to the first.

9.       CP-DIFF-13 and RP-DIFF-12 - I believe that we should say in both cases that multiple encodings is an advantage. Otherwise, drop the question.

10.   I believe that for both control and reporting protocols we should add a (maybe even mandatory!) requirement about separation of protocol and information (data model ) and ask what DMLs are supported.

11.   I believe that the framework (section 5.5) defines a mandatory requirement for the reporting protocol to support a 'push' mode - this is missing

Thanks and Regards,

Dan