[apps-discuss] APPSDIR review of draft-ietf-ipfix-flow-selection-tech-14

S Moonesamy <sm+ietf@elandsys.com> Tue, 09 April 2013 11:06 UTC

Return-Path: <sm@elandsys.com>
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 670B621F905C; Tue, 9 Apr 2013 04:06:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.159
X-Spam-Level:
X-Spam-Status: No, score=-102.159 tagged_above=-999 required=5 tests=[AWL=0.441, 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 3O+otzlQdOua; Tue, 9 Apr 2013 04:06:43 -0700 (PDT)
Received: from mx.ipv6.elandsys.com (mx.ipv6.elandsys.com [IPv6:2001:470:f329:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id A83BA21F9120; Tue, 9 Apr 2013 04:06:43 -0700 (PDT)
Received: from SUBMAN.elandsys.com ([197.224.142.138]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id r39B6Tk7023328 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 9 Apr 2013 04:06:40 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1365505602; bh=mLe25Y/RtHSyLJFO3nWqVbBIKwcocSGZQYzMXzPPUz0=; h=Date:To:From:Subject:Cc; b=jwND6rKBnOGin3k8M6xY7pnpteOSy8JC70udgzHSOT6+kV6MnLj3ICbyB1IBYvk+V ud3dnlw5TzST/dpt1mm5SF8XkQohqInh2DXYxlVzAI50l/9p2p7BhKLQTMV3x77K/o 6vVVjVgtgWicZz3B0iGf5bBoJqVzd1k7PVDxBk/M=
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=elandsys.com; s=mail; t=1365505602; i=@elandsys.com; bh=mLe25Y/RtHSyLJFO3nWqVbBIKwcocSGZQYzMXzPPUz0=; h=Date:To:From:Subject:Cc; b=Zi2c9QyvM8kdvGOmJLRkJ0hTlCZgrViPgcgkuQZXkeRc/Uk9/cNCAN8JMkt8sqwu9 ihfTgM3VsKFJknz2l8hXSNQb/k63GfmfwJjebAup/M01X9EpakvgQuO2d5BnHNJ9GT R3vrSq51husVqnpa3UN5lXXrBW8MyYMfdqhwqBL8=
Message-Id: <6.2.5.6.2.20130409030107.0e720478@elandnews.com>
X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6
Date: Tue, 09 Apr 2013 04:05:42 -0700
To: apps-discuss@ietf.org, draft-ietf-ipfix-flow-selection-tech.all@tools.ietf.org
From: S Moonesamy <sm+ietf@elandsys.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format="flowed"
Cc: iesg@ietf.org
Subject: [apps-discuss] APPSDIR review of draft-ietf-ipfix-flow-selection-tech-14
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: General discussion of application-layer protocols <apps-discuss.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/apps-discuss>
List-Post: <mailto:apps-discuss@ietf.org>
List-Help: <mailto:apps-discuss-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 09 Apr 2013 11:06:44 -0000

I have been selected as the Applications Area Directorate reviewer 
for this draft (for background on APPSDIR, please see 
http://trac.tools.ietf.org/area/app/trac/wiki/ApplicationsAreaDirectorate ).

Please resolve these comments along with any other Last Call comments 
you may receive. Please wait for direction from your document 
shepherd or AD before posting a new version of the draft.

Document: draft-ietf-ipfix-flow-selection-tech-14
Title: Flow Selection Techniques
Reviewer: S. Moonesamy
Review Date: April 9, 2013
IETF Last Call Date: March 18, 2013

Summary: This draft is almost ready for publication.

This document describes Intermediate Flow Selection Process 
techniques for network traffic measurements, provides a 
categorization of Intermediate Flow Selection Process techniques and 
describes configuration and reporting parameters for them.  Idid not 
find any applications-related considerations.

Major issues: none

Minor issues:

The intended status of the document is Standards Track.  Some of the 
requirements I could find are:

In Section 1:

   "In order to be compliant with this document, at least the Property
    Match Filtering MUST be implemented."

The above text is repeated in Section 5.1.  I suggest removing this 
sentence as it does not seem related to scope.

My reading of the "MUST" is that it is being used for compliance 
instead of the reasons described in RFC 2119.  I suggest reviewing 
the usage of RFC 2119 key words in Section 5.1.

Why should this document be published on the Standards Track instead 
of Informational?  I am asking this question as I could not suggest 
Standards Track as the intended status.

In Section 8.1.1:

   "The flowSelectorAlgorithm registry is maintained by IANA."

I suggest phasing this as a request to create the registry.

   "The registry can be updated when specifications of the new
    technique(s) and any new Information Elements are provided."

How should this registry be managed?

Regards,
S. Moonesamy