[IPFIX] AD Review of draft-ipfix-mediators-framework-08

"Romascanu, Dan (Dan)" <dromasca@avaya.com> Tue, 12 October 2010 12:16 UTC

Return-Path: <dromasca@avaya.com>
X-Original-To: ipfix@core3.amsl.com
Delivered-To: ipfix@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4828D3A6930 for <ipfix@core3.amsl.com>; Tue, 12 Oct 2010 05:16:14 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.517
X-Spam-Level:
X-Spam-Status: No, score=-102.517 tagged_above=-999 required=5 tests=[AWL=0.082, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ejaBlG6IbVwX for <ipfix@core3.amsl.com>; Tue, 12 Oct 2010 05:16:11 -0700 (PDT)
Received: from co300216-co-outbound.net.avaya.com (co300216-co-outbound.net.avaya.com [198.152.13.100]) by core3.amsl.com (Postfix) with ESMTP id 473F43A690C for <ipfix@ietf.org>; Tue, 12 Oct 2010 05:16:11 -0700 (PDT)
X-IronPort-AV: E=Sophos;i="4.57,320,1283745600"; d="scan'208";a="242287991"
Received: from unknown (HELO co300216-co-erhwest.avaya.com) ([198.152.7.5]) by co300216-co-outbound.net.avaya.com with ESMTP; 12 Oct 2010 08:17:25 -0400
X-IronPort-AV: E=Sophos;i="4.57,320,1283745600"; d="scan'208";a="525678493"
Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.12]) by co300216-co-erhwest-out.avaya.com with ESMTP; 12 Oct 2010 08:17:24 -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: Tue, 12 Oct 2010 14:17:12 +0200
Message-ID: <EDC652A26FB23C4EB6384A4584434A040260F207@307622ANEX5.global.avaya.com>
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: AD Review of draft-ipfix-mediators-framework-08
Thread-Index: ActqB2Yxqtty17xJSaGSalPIt+oMBQ==
From: "Romascanu, Dan (Dan)" <dromasca@avaya.com>
To: IPFIX Working Group <ipfix@ietf.org>
Subject: [IPFIX] AD Review of draft-ipfix-mediators-framework-08
X-BeenThere: ipfix@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: IPFIX WG discussion list <ipfix.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/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: Tue, 12 Oct 2010 12:16:14 -0000

Please find below the AD review of 

This document is in quite good shape. I would however suggest to deal
with the issues in this review before sending the document to the IETF
Last Call. 

The technical comments are marked Tx and the editorial comments are
marked Ex.

T1. Sections 5.2, 5.3: It is not clear what you mean when you say 'This
function must be configurable' - does this mean that some parameters
related to this function are configurable (which ones?), or that
'Activation of this function must be configurable'? 

T2. Same sections and phrase. This seems to me a very clear
architectural requirement where RFC 2119 capitalized MUST would fit.
Please consider this as a non-blocking comment. 

T3. In 5.3 'This relation can be configurable' - same question as at T1.


T4. Section 5.3.2.1: 

      Maintaining the mapping information about Transport Sessions,
      Observation Domain IDs, and Template IDs on the incoming and
      outgoing sides to ensure the appropriateness of the scope field
      values in Data Records defined by Options Templates and of IPFIX
      Template Withdrawal Messages.

I could not figure out what 'the appropriateness of the scope field
values' means. 

T5. The 'must', 'should', 'may' in the Security Considerations section
seem appropriate for RFC 2119 keywords capitalization. Please consider
this as a non-blocking comment. 


E1. idnits complains about 

** The document seems to lack a both a reference to RFC 2119 and the
     recommended RFC 2119 boilerplate, even if it appears to use RFC
2119
     keywords. 

     RFC 2119, paragraph 2:
     "The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL
NOT",
      "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in
      this document are to be interpreted as described in RFC 2119."

This is probably because of a SHOULD left capitalized in the Security
Considerations section. Change it into a 'should' unless you decide to
follow the recommendations in T2 and T5. 

E2. idnits points to potential problems in references. Please confirm if
this is what you intended, or updates are needed. 

  Checking references for intended status: Informational
 
------------------------------------------------------------------------
----

  == Outdated reference: draft-ietf-ipfix-mediators-problem-statement
has
     been published as RFC 5982

  == Outdated reference: A later version (-01) exists of
     draft-ietf-ipfix-psamp-mib-00

  -- Obsolete informational reference (is this intentional?): RFC 3280
     (Obsoleted by RFC 5280)

  -- Obsolete informational reference (is this intentional?): RFC 4346
     (Obsoleted by RFC 5246)

E3. Section 1: 

s/To fulfill application requirements with limited system resources,
IPFIX architecture needs to introduce/To fulfill application
requirements with limited system resources, the IPFIX architecture needs
to introduce/ 

E4. Section 2: 

s/The use of the terms "must", "should", and "may" in this document are
informational only/The use of the terms "must", "should", and "may" in
this document is informational only/

E5. what does 'binning' mean in the context of this document? 

E6. Figure F: IPFIX Mediation Functional Block - should be either
'Blocks' or 'Block Diagram'

E7. in 5.3.2.3 s/describied/described/