[apps-discuss] apps-team review of draft-ietf-ipfix-mediators-framework-09

Aaron Stone <aaron@serendipity.cx> Fri, 24 December 2010 05:08 UTC

Return-Path: <aaron@serendipity.cx>
X-Original-To: apps-discuss@core3.amsl.com
Delivered-To: apps-discuss@core3.amsl.com
Received: from localhost (localhost []) by core3.amsl.com (Postfix) with ESMTP id E92C33A68E7; Thu, 23 Dec 2010 21:08:45 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -101.643
X-Spam-Status: No, score=-101.643 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, IP_NOT_FRIENDLY=0.334, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([]) by localhost (core3.amsl.com []) (amavisd-new, port 10024) with ESMTP id HLMF42jHQdVm; Thu, 23 Dec 2010 21:08:45 -0800 (PST)
Received: from slice.serendipity.cx (slice.serendipity.cx []) by core3.amsl.com (Postfix) with ESMTP id EF0433A68E0; Thu, 23 Dec 2010 21:08:44 -0800 (PST)
Received: from mail-vw0-f44.google.com (mail-vw0-f44.google.com []) by slice.serendipity.cx (Postfix) with ESMTPSA id DB3C6110196; Thu, 23 Dec 2010 21:17:21 -0800 (PST)
Received: by vws7 with SMTP id 7so2622349vws.31 for <multiple recipients>; Thu, 23 Dec 2010 21:10:45 -0800 (PST)
Received: by with SMTP id bg7mr992655vcb.124.1293167445259; Thu, 23 Dec 2010 21:10:45 -0800 (PST)
MIME-Version: 1.0
Received: by with HTTP; Thu, 23 Dec 2010 21:10:25 -0800 (PST)
From: Aaron Stone <aaron@serendipity.cx>
Date: Thu, 23 Dec 2010 21:10:25 -0800
Message-ID: <AANLkTi=1B9A+FLSZW+UGtA-n8+oveoxSQSnUjUHfc5mc@mail.gmail.com>
To: akoba@nttv6.net, bclaise@cisco.com, muenz@net.in.tum.de, ishibashi.keisuke@lab.ntt.co.jp, ipfix-chairs@tools.ietf.org, iesg@ietf.org, apps-discuss@ietf.org, dromasca@avaya.com, quittek@neclab.eu
Content-Type: text/plain; charset="ISO-8859-1"
Subject: [apps-discuss] apps-team review of draft-ietf-ipfix-mediators-framework-09
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: General discussion of application-layer protocols <apps-discuss.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/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: Fri, 24 Dec 2010 05:08:46 -0000

I have been selected as the Applications Area Review Team reviewer for
this draft (for background on apps-review, please see
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-mediators-framework-09
Title: IPFIX Mediation: Framework
Reviewer: Aaron Stone
Review Date: 2010-12-18
IETF Last Call Date: unknown
IESG Telechat Date: unknown
Summary: This is a very well-written document, with truly excellent
ASCII art, that appears ready for publication. Its intended status as
Informational seems mandatory, given that the document does not use
RFC 2119 keywords to directly specify behaviors.

Major issues:

I would say not using RFC 2119 is a major issue, but since the
intended status is Informational, I don't see a problem.

Minor issues:

Section 2: -- I suggest making three subsections, at the paragraphs that begin:
"The following terms are used in this document to describe the
architectural entities used by IPFIX Mediation."
"Specific Intermediate Processes are described below."
Section 2: -- The definition of "IPFIX Mediator" is core to this
document, so it seems like it should be at the top of the section, and
probably in the introduction.

Section 3: -- Is the term "documents" understood in a particular way
in IPFIX that a familiar reader would understand that you don't mean
"RFC document"? Or do you actually mean RFC documents, and you're
listing off which other RFCs one should read in order to better
understand what's going on here? If the latter, consider a text change
to directly state that you are listing other RFCs that the reader
should also read.

Section -- under "Temporal composition", perhaps replace
"Flow duration" with simply "duration"? If "Flow Duration" is a
specific term, it should be defined earlier.

Section 6: -- should "Collector input" be "Collector Input"? Or is it
maybe "Collector's input"? I found the complex string of terms to be

Section 9: -- Please flip the first sentence around: "As IPFIX
Mediators act as both IPFIX Collection Processes and Exporting
Processes, the Security Considerations for IPFIX Files [RFC5655] apply
to IPFix Mediators that write IPFIX Files or use them for internal
-- What are the specific considerations? Is that what the next
paragraph is about? ...oh, I see, the third paragraph / sentence by
itself here. Consider rephrasing this so that the reader is not
confused for a few minutes, as this reviewer has been :)

Section 9.4: -- Why is this a security consideration and not a
fundamental part of the specification, and explained in Section 3 or


Section 5.1: -- Should "Sampling parameters" be "Sampling Parameters"?
Section 5.2: -- add a colon after "following" before the list.
Section 5.2: -- rewrite the last sentence of the first bullet item as
"...become invalid (e.g., due to incoming session failure)."
Section -- second to last paragraph, last sentence, remove
the comma in "outgoing side, only".
Section -- add a colon after "following" before the list.
Section -- In "Correlation between Data Record and other meta
data", use either a single word, "metadata" or a hyphenated word,
"meta-data" (the RFC Editor probably has a preferred usage).
Section 6: -- add a color after "ways" before the list.