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

"Romascanu, Dan (Dan)" <dromasca@avaya.com> Wed, 11 February 2015 13:28 UTC

Return-Path: <dromasca@avaya.com>
X-Original-To: lmap@ietfa.amsl.com
Delivered-To: lmap@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 77E911A88A8 for <lmap@ietfa.amsl.com>; Wed, 11 Feb 2015 05:28:57 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.909
X-Spam-Level:
X-Spam-Status: No, score=-6.909 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0iavs_ddEzMl for <lmap@ietfa.amsl.com>; Wed, 11 Feb 2015 05:28:53 -0800 (PST)
Received: from p-us1-iereast-outbound.us1.avaya.com (p-us1-iereast-outbound.us1.avaya.com [135.11.29.13]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0B3501A88BE for <lmap@ietf.org>; Wed, 11 Feb 2015 05:28:49 -0800 (PST)
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AqgFAHJY21TGmAcV/2dsb2JhbABbgkMhIiIwXrAsAQEBAQEBBgWSHh0BhXoCgSVDAQEBAQEBfIQOAQEDEhteARUVViYBBBsaiAsBqz+Ef6FADCCGBIlCgmUMQB2BFAWJfoUkikeDBII9jCAigX8fgVCCM38BAQE
X-IronPort-AV: E=Sophos;i="5.09,558,1418101200"; d="scan'208,217";a="106397763"
Received: from unknown (HELO co300216-co-erhwest-exch.avaya.com) ([198.152.7.21]) by p-us1-iereast-outbound.us1.avaya.com with ESMTP; 11 Feb 2015 08:28:48 -0500
X-OutboundMail_SMTP: 1
Received: from unknown (HELO AZ-FFEXHC01.global.avaya.com) ([135.64.58.11]) by co300216-co-erhwest-out.avaya.com with ESMTP/TLS/AES128-SHA; 11 Feb 2015 08:28:48 -0500
Received: from AZ-FFEXMB04.global.avaya.com ([fe80::6db7:b0af:8480:c126]) by AZ-FFEXHC01.global.avaya.com ([135.64.58.11]) with mapi id 14.03.0174.001; Wed, 11 Feb 2015 14:28:46 +0100
From: "Romascanu, Dan (Dan)" <dromasca@avaya.com>
To: "lmap@ietf.org" <lmap@ietf.org>
Thread-Topic: comments on draft-starkcarey-lmap-protocol-criteria-00
Thread-Index: AdBF/qVP+I1zvHL/R1qUKKbaUsALkw==
Date: Wed, 11 Feb 2015 13:28:46 +0000
Message-ID: <9904FB1B0159DA42B0B887B7FA8119CA5C991C18@AZ-FFEXMB04.global.avaya.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [135.64.58.48]
Content-Type: multipart/alternative; boundary="_000_9904FB1B0159DA42B0B887B7FA8119CA5C991C18AZFFEXMB04globa_"
MIME-Version: 1.0
Archived-At: <http://mailarchive.ietf.org/arch/msg/lmap/BzsbvebmqoQ71TBl23blsKJV4lQ>
Subject: [lmap] comments on draft-starkcarey-lmap-protocol-criteria-00
X-BeenThere: lmap@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Large Scale Measurement of Access network Performance <lmap.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/lmap>, <mailto:lmap-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/lmap/>
List-Post: <mailto:lmap@ietf.org>
List-Help: <mailto:lmap-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/lmap>, <mailto:lmap-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 11 Feb 2015 13:28:57 -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