[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 [127.0.0.1]) 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-Level:
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 ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (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 [67.23.2.90]) 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 [209.85.212.44]) 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 10.220.177.7 with SMTP id bg7mr992655vcb.124.1293167445259; Thu, 23 Dec 2010 21:10:45 -0800 (PST)
MIME-Version: 1.0
Received: by 10.220.179.129 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 http://www.apps.ietf.org/content/applications-area-review-team). 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 5.3.2.3: -- 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 confusing. 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 storage." -- 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 4? Nits: 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 5.3.2.1: -- second to last paragraph, last sentence, remove the comma in "outgoing side, only". Section 5.3.2.4: -- add a colon after "following" before the list. Section 5.3.2.5: -- 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. Cheers, Aaron