[IPFIX] AD review of draft-ietf-ipfix-flow-selection-tech-10.txt
"Romascanu, Dan (Dan)" <dromasca@avaya.com> Wed, 21 March 2012 16:42 UTC
Return-Path: <dromasca@avaya.com>
X-Original-To: ipfix@ietfa.amsl.com
Delivered-To: ipfix@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7ED6721E804D for <ipfix@ietfa.amsl.com>; Wed, 21 Mar 2012 09:42:21 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.868
X-Spam-Level:
X-Spam-Status: No, score=-102.868 tagged_above=-999 required=5 tests=[AWL=-0.269, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VoVRcyecOwGh for <ipfix@ietfa.amsl.com>; Wed, 21 Mar 2012 09:42:21 -0700 (PDT)
Received: from p-us1-iereast-outbound.us1.avaya.com (p-us1-iereast-outbound.us1.avaya.com [135.11.29.13]) by ietfa.amsl.com (Postfix) with ESMTP id 1322A21E805E for <ipfix@ietf.org>; Wed, 21 Mar 2012 09:42:17 -0700 (PDT)
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: Av0EAKMEak+HCzI1/2dsb2JhbABEtn+BB4ILAQEDEh4KMSABFRUGDAwHVwEEGxqHaJdehBucHpAeYwSbbooYgmg
X-IronPort-AV: E=Sophos;i="4.73,624,1325480400"; d="scan'208";a="615279"
Received: from unknown (HELO p-us1-erheast.us1.avaya.com) ([135.11.50.53]) by p-us1-iereast-outbound.us1.avaya.com with ESMTP; 21 Mar 2012 12:41:58 -0400
Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.13]) by p-us1-erheast-out.us1.avaya.com with ESMTP; 21 Mar 2012 12:26:22 -0400
x-mimeole: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Date: Wed, 21 Mar 2012 17:41:52 +0100
Message-ID: <EDC652A26FB23C4EB6384A4584434A0407638B8F@307622ANEX5.global.avaya.com>
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: AD review of draft-ietf-ipfix-flow-selection-tech-10.txt
Thread-Index: Ac0HgYT2PNNa/4XrS9iDIJxRD2mpEw==
From: "Romascanu, Dan (Dan)" <dromasca@avaya.com>
To: IETF IPFIX Working Group <ipfix@ietf.org>
Subject: [IPFIX] AD review of draft-ietf-ipfix-flow-selection-tech-10.txt
X-BeenThere: ipfix@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: IPFIX WG discussion list <ipfix.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ipfix>, <mailto:ipfix-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ipfix>
List-Post: <mailto:ipfix@ietf.org>
List-Help: <mailto:ipfix-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ipfix>, <mailto:ipfix-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 21 Mar 2012 16:42:21 -0000
Please find below the AD review of draft-ietf-ipfix-flow-selection-tech-10.txt. The document is in a good enough shape to be sent to IETF LC. Please consider my comments together with the other IETF LC comments. The comments are divided into T (Technical) and E (Editorial). T1. In section 5.1.2: Nevertheless there MAY be the incentive to apply Hash- based Flow Filtering not on the packet level during the Metering Process, for example when the size of the selection range and therefore the sampling probability is dependent on the number of observed flows. I think that the usage of a capitalized RFC 2119 MAY is not justified here. T2. In section 6.1 please provide references for the hash functions mentioned as possible functions. T3. In section 7: In this section we describe Information Elements (IEs) that SHOULD be exported by a flow selection process in order to support the interpretation of measurement results from flow measurements where only some flows are selected. Why is this a SHOULD and not a MUST? What are the exception cases? T4. Also in section 7: All counters SHOULD be exported and reset when a new measurement interval starts. Why is this a SHOULD and not a MUST? What are the exception cases? Are exporting counters and reset of counters independent, in other words can some counters be exported but not reset when a new measurement interval starts? T5. Where are allocated all the IDs marked as TBD in the table in Section 7? I do not see a request for allocation in the IANA considerations section. What am I missing? T6. Even if configuration methods and protocols are out of the scope of this document I believe that this statement in the Security Considerations section is not sufficient: Nevertheless, a full analysis and assessment of threats for configuration and reporting has to be done if configuration or reporting methods are proposed. I think that this document needs at least make a complete assessment of the threats and place requirements in the configuration and reporting methods to be later defined. E1. Three of the missing references prompted up by idnits seem to be indeed missing references: == Missing Reference: 'RFC5226' is mentioned on line 868, but not defined 'administered by IANA and are subject to Expert Review [RFC5226...' == Missing Reference: 'I-D.dkcm-ipfix-rfc5815bis' is mentioned on line 1330, but not defined 'according to the procedures set forth in [I-D.dkcm-ipfix-rfc5815b...' == Missing Reference: 'GoRe07' is mentioned on line 1372, but not defined '[GoRe07]....' E2. Drop the comma from 'The reason is, that flow-state dependent ...' E3. Section 5.2.1: Systematic sampling MAY BE applied during the Metering Process. BE needs not be capitalized. E4. It would be useful to nuumber the Tables in the document like the one in Section 6, for later references in other documents. Regards, Dan
- [IPFIX] AD review of draft-ietf-ipfix-flow-select… Romascanu, Dan (Dan)
- [IPFIX] R: AD review of draft-ietf-ipfix-flow-sel… Salvatore D'Antonio
- Re: [IPFIX] AD review of draft-ietf-ipfix-flow-se… Romascanu, Dan (Dan)