From internet-drafts@ietf.org Fri Dec 2 10:39:22 2011 Return-Path: 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 CF3091F0C70; Fri, 2 Dec 2011 10:39:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.581 X-Spam-Level: X-Spam-Status: No, score=-102.581 tagged_above=-999 required=5 tests=[AWL=0.018, 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 Gkumjbzo+lpZ; Fri, 2 Dec 2011 10:39:22 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 44CC81F0C36; Fri, 2 Dec 2011 10:39:22 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 3.64 Message-ID: <20111202183922.19606.21744.idtracker@ietfa.amsl.com> Date: Fri, 02 Dec 2011 10:39:22 -0800 Cc: ipfix@ietf.org Subject: [IPFIX] I-D Action: draft-ietf-ipfix-protocol-rfc5101bis-00.txt X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Dec 2011 18:39:23 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the IP Flow Information Export Working Gr= oup of the IETF. Title : Specification of the IP Flow Information eXport (IPFIX) = Protocol for the Exchange of IP Traffic Flow Information Author(s) : Benoit Claise Brian Trammell Filename : draft-ietf-ipfix-protocol-rfc5101bis-00.txt Pages : 73 Date : 2011-11-29 This document specifies the IP Flow Information Export (IPFIX) protocol that serves for transmitting IP Traffic Flow information over the network. In order to transmit IP Traffic Flow information from an Exporting Process to an information Collecting Process, a common representation of flow data and a standard means of communicating them is required. This document describes how the IPFIX Data and Template Records are carried over a number of transport protocols from an IPFIX Exporting Process to an IPFIX Collecting Process. This document obsoletes RFC 5101. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ipfix-protocol-rfc5101bis-00= .txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-ipfix-protocol-rfc5101bis-00.= txt From bclaise@cisco.com Sat Dec 3 06:32:35 2011 Return-Path: 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 2E45821F8F5F for ; Sat, 3 Dec 2011 06:32:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.108 X-Spam-Level: X-Spam-Status: No, score=-2.108 tagged_above=-999 required=5 tests=[AWL=0.490, BAYES_00=-2.599, HTML_MESSAGE=0.001] 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 9oqn2GUGlh9d for ; Sat, 3 Dec 2011 06:32:34 -0800 (PST) Received: from av-tac-bru.cisco.com (weird-brew.cisco.com [144.254.15.118]) by ietfa.amsl.com (Postfix) with ESMTP id 2EDF221F8F5D for ; Sat, 3 Dec 2011 06:32:34 -0800 (PST) X-TACSUNS: Virus Scanned Received: from strange-brew.cisco.com (localhost.cisco.com [127.0.0.1]) by av-tac-bru.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id pB3EWX1f003462 for ; Sat, 3 Dec 2011 15:32:33 +0100 (CET) Received: from [10.60.67.84] (ams-bclaise-8913.cisco.com [10.60.67.84]) by strange-brew.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id pB3EWWL9025428; Sat, 3 Dec 2011 15:32:32 +0100 (CET) Message-ID: <4EDA3300.2000707@cisco.com> Date: Sat, 03 Dec 2011 15:32:32 +0100 From: Benoit Claise User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:8.0) Gecko/20111105 Thunderbird/8.0 MIME-Version: 1.0 To: "ipfix@ietf.org" References: <20111203131911.5982.51959.idtracker@ietfa.amsl.com> In-Reply-To: <20111203131911.5982.51959.idtracker@ietfa.amsl.com> X-Forwarded-Message-Id: <20111203131911.5982.51959.idtracker@ietfa.amsl.com> Content-Type: multipart/alternative; boundary="------------040900020802000202070704" Cc: "Nir Ben-Dvora \(nirbd\)" Subject: [IPFIX] Fwd: New Version Notification for draft-claise-export-application-info-in-ipfix-04.txt X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 03 Dec 2011 14:32:35 -0000 This is a multi-part message in MIME format. --------------040900020802000202070704 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Dear all, Here is a new version of the draft-claise-export-application-info-in-ipfix-04.txt. It includes the feedback received during the last IETF - format based on the Ethertype registry - format based on the LLC registry - we investigated the format based on the - we reintroduced applicationSubCategoryName, which we inadvertently removed from version 3 http://tools.ietf.org/html/draft-claise-export-application-info-in-ipfix-04 Regards, Paul, Nir, Benoit. -------- Original Message -------- Subject: New Version Notification for draft-claise-export-application-info-in-ipfix-04.txt Date: Sat, 03 Dec 2011 05:19:11 -0800 From: internet-drafts@ietf.org To: bclaise@cisco.com CC: bclaise@cisco.com, paitken@cisco.com, nirbd@cisco.com A new version of I-D, draft-claise-export-application-info-in-ipfix-04.txt has been successfully submitted by Benoit Claise and posted to the IETF repository. Filename: draft-claise-export-application-info-in-ipfix Revision: 04 Title: Export of Application Information in IPFIX Creation date: 2011-12-03 WG ID: Individual Submission Number of pages: 37 Abstract: This document specifies an extension to the IPFIX information model specified in [RFC5102] to export application information. The IETF Secretariat --------------040900020802000202070704 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 7bit Dear all,

Here is a new version of the draft-claise-export-application-info-in-ipfix-04.txt.
It includes the feedback received during the last IETF
- format based on the Ethertype registry
- format based on the LLC registry
- we investigated the format based on the
- we reintroduced applicationSubCategoryName, which we inadvertently removed from version 3

http://tools.ietf.org/html/draft-claise-export-application-info-in-ipfix-04

Regards, Paul, Nir, Benoit.

-------- Original Message --------
Subject: New Version Notification for draft-claise-export-application-info-in-ipfix-04.txt
Date: Sat, 03 Dec 2011 05:19:11 -0800
From: internet-drafts@ietf.org
To: bclaise@cisco.com
CC: bclaise@cisco.com, paitken@cisco.com, nirbd@cisco.com 


A new version of I-D, draft-claise-export-application-info-in-ipfix-04.txt has been successfully submitted by Benoit Claise and posted to the IETF repository.

Filename:	 draft-claise-export-application-info-in-ipfix
Revision:	 04
Title:		 Export of Application Information in IPFIX
Creation date:	 2011-12-03
WG ID:		 Individual Submission
Number of pages: 37

Abstract:
        This document specifies an extension to the IPFIX information
        model specified in [RFC5102] to export application information.


     
                                                                                  


The IETF Secretariat
--------------040900020802000202070704-- From bclaise@cisco.com Sat Dec 3 06:50:59 2011 Return-Path: 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 E9C6D21F8F78 for ; Sat, 3 Dec 2011 06:50:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.19 X-Spam-Level: X-Spam-Status: No, score=-2.19 tagged_above=-999 required=5 tests=[AWL=0.408, BAYES_00=-2.599, HTML_MESSAGE=0.001] 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 uEutrRsXLsC3 for ; Sat, 3 Dec 2011 06:50:59 -0800 (PST) Received: from av-tac-bru.cisco.com (weird-brew.cisco.com [144.254.15.118]) by ietfa.amsl.com (Postfix) with ESMTP id 1840A21F8E98 for ; Sat, 3 Dec 2011 06:50:58 -0800 (PST) X-TACSUNS: Virus Scanned Received: from strange-brew.cisco.com (localhost.cisco.com [127.0.0.1]) by av-tac-bru.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id pB3EownT005311 for ; Sat, 3 Dec 2011 15:50:58 +0100 (CET) Received: from [10.60.67.84] (ams-bclaise-8913.cisco.com [10.60.67.84]) by strange-brew.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id pB3EosaT002038; Sat, 3 Dec 2011 15:50:54 +0100 (CET) Message-ID: <4EDA374D.40700@cisco.com> Date: Sat, 03 Dec 2011 15:50:53 +0100 From: Benoit Claise User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:8.0) Gecko/20111105 Thunderbird/8.0 MIME-Version: 1.0 To: "ipfix@ietf.org" References: <20111203131911.5982.51959.idtracker@ietfa.amsl.com> <4EDA3300.2000707@cisco.com> In-Reply-To: <4EDA3300.2000707@cisco.com> Content-Type: multipart/alternative; boundary="------------030104020709060504070209" Cc: "Nir Ben-Dvora \(nirbd\)" Subject: Re: [IPFIX] Fwd: New Version Notification for draft-claise-export-application-info-in-ipfix-04.txt X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 03 Dec 2011 14:51:00 -0000 This is a multi-part message in MIME format. --------------030104020709060504070209 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit On 03/12/2011 15:32, Benoit Claise wrote: > Dear all, > > Here is a new version of the > draft-claise-export-application-info-in-ipfix-04.txt. > It includes the feedback received during the last IETF > - format based on the Ethertype registry > - format based on the LLC registry > - we investigated the format based on the .. the group mac address, but discovered it was not suitable to clearly identify the protocol Regards, Benoit. > - we reintroduced applicationSubCategoryName, which we inadvertently > removed from version 3 > > http://tools.ietf.org/html/draft-claise-export-application-info-in-ipfix-04 > > Regards, Paul, Nir, Benoit. > > -------- Original Message -------- > Subject: New Version Notification for > draft-claise-export-application-info-in-ipfix-04.txt > Date: Sat, 03 Dec 2011 05:19:11 -0800 > From: internet-drafts@ietf.org > To: bclaise@cisco.com > CC: bclaise@cisco.com, paitken@cisco.com, nirbd@cisco.com > > > > A new version of I-D, draft-claise-export-application-info-in-ipfix-04.txt has been successfully submitted by Benoit Claise and posted to the IETF repository. > > Filename: draft-claise-export-application-info-in-ipfix > Revision: 04 > Title: Export of Application Information in IPFIX > Creation date: 2011-12-03 > WG ID: Individual Submission > Number of pages: 37 > > Abstract: > This document specifies an extension to the IPFIX information > model specified in [RFC5102] to export application information. > > > > > > > The IETF Secretariat > > --------------030104020709060504070209 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 7bit On 03/12/2011 15:32, Benoit Claise wrote:
Dear all,

Here is a new version of the draft-claise-export-application-info-in-ipfix-04.txt.
It includes the feedback received during the last IETF
- format based on the Ethertype registry
- format based on the LLC registry
- we investigated the format based on the
.. the group mac address, but discovered it was not suitable to clearly identify the protocol

Regards, Benoit.
- we reintroduced applicationSubCategoryName, which we inadvertently removed from version 3

http://tools.ietf.org/html/draft-claise-export-application-info-in-ipfix-04

Regards, Paul, Nir, Benoit.

-------- Original Message --------
Subject: New Version Notification for draft-claise-export-application-info-in-ipfix-04.txt
Date: Sat, 03 Dec 2011 05:19:11 -0800
From: internet-drafts@ietf.org
To: bclaise@cisco.com
CC: bclaise@cisco.com, paitken@cisco.com, nirbd@cisco.com 


A new version of I-D, draft-claise-export-application-info-in-ipfix-04.txt has been successfully submitted by Benoit Claise and posted to the IETF repository.

Filename:	 draft-claise-export-application-info-in-ipfix
Revision:	 04
Title:		 Export of Application Information in IPFIX
Creation date:	 2011-12-03
WG ID:		 Individual Submission
Number of pages: 37

Abstract:
        This document specifies an extension to the IPFIX information
        model specified in [RFC5102] to export application information.


     
                                                                                  


The IETF Secretariat

--------------030104020709060504070209-- From bclaise@cisco.com Mon Dec 5 06:14:12 2011 Return-Path: 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 A38BF21F8B94 for ; Mon, 5 Dec 2011 06:14:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0 X-Spam-Level: X-Spam-Status: No, score=x tagged_above=-999 required=5 tests=[] 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 uEoRZMYwdCpx for ; Mon, 5 Dec 2011 06:14:12 -0800 (PST) Received: from av-tac-bru.cisco.com (weird-brew.cisco.com [144.254.15.118]) by ietfa.amsl.com (Postfix) with ESMTP id 7038D21F8B6B for ; Mon, 5 Dec 2011 06:14:10 -0800 (PST) X-TACSUNS: Virus Scanned Received: from strange-brew.cisco.com (localhost.cisco.com [127.0.0.1]) by av-tac-bru.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id pB5EE8IB020305; Mon, 5 Dec 2011 15:14:08 +0100 (CET) Received: from [10.60.67.86] (ams-bclaise-8915.cisco.com [10.60.67.86]) by strange-brew.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id pB5DjZIr005143; Mon, 5 Dec 2011 14:45:35 +0100 (CET) Message-ID: <4EDCCAFF.1080802@cisco.com> Date: Mon, 05 Dec 2011 14:45:35 +0100 From: Benoit Claise User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:8.0) Gecko/20111105 Thunderbird/8.0 MIME-Version: 1.0 To: Paul Aitken References: <4E369F30.3040602@cisco.com> In-Reply-To: <4E369F30.3040602@cisco.com> Content-Type: multipart/alternative; boundary="------------020200020803060909050804" Cc: IETF IPFIX Working Group Subject: Re: [IPFIX] review of draft-claise-ipfix-mediation-protocol-04 X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Dec 2011 14:14:12 -0000 This is a multi-part message in MIME format. --------------020200020803060909050804 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Hi Paul, As explained during the IETF, we overlooked this email. Sorry again. What I like about your reviews is that it's always a WG last call level of review. So very detailed. Many thanks. See inline. > Dear Authors, > > Please find a review of draft-claise-ipfix-mediation-protocol-04. > > Thanks, > P. > > >> IPFIX Working Group B. Claise >> Internet-Draft Cisco Systems, Inc. >> Intended Status: Standards Track A. Kobayashi >> Expires: January 7, 2012 NTT PF Lab. >> B. Trammell >> ETH Zurich >> July 7, 2011 >> >> >> Specification of the Protocol for IPFIX Mediations > > s/Mediations/Mediation/ Done. > > >> draft-claise-ipfix-mediation-protocol-04 >> >> >> Abstract >> >> This document specifies the IP Flow Information Export >> (IPFIX) protocol specific tothe Mediation. > > Consider "specific to Mediation." Done. > or "for Mediation [devices].". > > >> >> Status of this Memo >> >> This Internet-Draft is submitted to IETF in full conformance >> with the provisions of BCP 78 and BCP 79. >> >> Internet-Drafts are working documents of the Internet >> Engineering Task Force (IETF), its areas, and its working >> groups. Note that other groups may also distribute working >> documents as Internet-Drafts. >> >> Internet-Drafts are draft documents valid for a maximum of six >> months and may be updated, replaced, or obsoleted by other >> documents at any time. It is inappropriate to use Internet- >> Drafts as reference material or to cite them other than as "work >> in progress." >> >> The list of current Internet-Drafts can be accessed at >> http://www.ietf.org/ietf/1id-abstracts.txt >> >> The list of Internet-Draft Shadow Directories can be accessed at >> http://www.ietf.org/shadow.html >> >> This Internet-Draft will expire on April, 2011. >> >> >> Copyright Notice >> >> Copyright (c) 2011 IETF Trust and the persons identified as the >> document authors. All rights reserved. >> >> This document is subject to BCP 78 and the IETF Trust's Legal >> Provisions Relating to IETF Documents >> (http://trustee.ietf.org/license-info) in effect on the date of >> publication of this document. Please review these documents >> >> Expires January 7 2012 [Page 1] >> Internet-Draft July 2011 >> >> >> carefully, as they describe your rights and restrictions with >> respect to this document. Code Components extracted from this >> document must include Simplified BSD License text as described >> in Section 4.e of the Trust Legal Provisions and are provided >> without warranty as described in the Simplified BSD License. >> >> >> Conventions used in this document >> >> 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 [RFC2119]. >> >> >> Table of Contents >> >> >> 1. Introduction............................................ 3 >> 1.1. IPFIX Documents Overview........................... 4 >> 1.2. IPFIX Mediator Documents Overview.................. 4 >> 1.3. Relationship with IPFIX and PSAMP.................. 5 >> 2. Terminology............................................. 6 >> 3. Specifications.......................................... 9 >> 3.1. Encoding of IPFIX Message Header.................. 10 >> 3.2. Template Management............................... 11 >> 3.2.1. Template Management Without Template Records >> Change........................................11 >> 3.2.2. Template Management With New Template Records 14 >> 3.3. Time Management................................... 18 >> 3.4. Observation Point Management...................... 19 >> 3.4.1. Observation Domain Management................ 21 >> 3.5. Specific Reporting Requirements................... 22 >> 3.5.1. The Flow Keys Options Template............... 22 >> 3.5.2. IPFIX Protocol Options Template.............. 22 >> 3.5.3. IPFIX Mediator Options Template.............. 23 >> 3.6. The Collecting Process's Side..................... 24 >> 3.7. Configuration Management.......................... 24 >> 4. New Information Elements............................... 24 >> 4.1. - originalExporterIPv4Address..................... 24 >> 4.2. originalExporterIPv6Address....................... 25 >> 4.3. originalObservationDomainId....................... 25 >> 5. Security Considerations................................ 25 >> 6. IANA Considerations.................................... 26 >> 6.1. originalExporterIPv4Address....................... 26 >> 6.2. originalExporterIPv6Address....................... 27 >> 6.3. originalObservationDomainId....................... 27 >> 7. References............................................. 27 >> >> >> Expires January 6, 2012 [Page 2] >> >> Internet-Draft July 2011 >> >> >> 7.1. Normative References.............................. 27 >> 7.2. Informative References............................ 28 >> 8. Author's Addresses..................................... 29 >> 9. Appendix A. Additions to XML Specification of IPFIX >> Information Elements...................................... 30 >> >> >> 1. Introduction >> >> The IPFIX architectural components in [RFC5470] consist of >> IPFIX Devices and IPFIX Collectors communicating using the >> IPFIX protocol [RFC5101], which specifies how to export IP >> Flow information. This protocol is designed to export >> information about IP traffic Flows and related measurement >> data, where a Flow is defined by a set of key attributes >> (e.g. source and destination IP address, source and >> destination port, etc.). >> >> However, thanks to its Template mechanism, the IPFIX protocol >> can export any type of information, as long as the relevant >> Information Element is specified in the IPFIX Information >> Model [RFC5102], registered with IANA, or specified as an >> enterprise-specific Information Element. The specifications >> in the IPFIX protocol [RFC5101] have not been defined in the >> context of an IPFIX Mediator receiving, aggregating, >> correlating, anonymizing, etc... Flow Records from the one or >> multiple Exporters. Indeed, the IPFIX protocol must be >> adapted for Intermediate Processes, as defined in the IPFIX >> Mediation Reference Model as specified inthe Figure A of > > d/the/ Done. > > >> [IPFIX-MED-FMWK], which is based on the IPFIX Mediation >> Problem Statement [RFC5982]. >> >> This document specifies the IP Flow Information Export >> (IPFIX) protocol in the context of the implementation and >> deployment of IPFIX Mediators. The use of the IPFIX >> protocol within a Mediator -- a device which contains both >> as anExporting Process and a Collecting Process -- has an > > This is back to front, since a mediator collects before it exports. Done. > > >> impact on the technical details of the usage of the >> protocol. An overview of the technical problem is covered >> in section 6 ofthe [RFC5982]: loss of original exporter > > Either remove "the", Done. > or say "the IPFIX Mediation Problem Statement". > > >> information, loss of base time information, transport >> sessions management, loss of Options Template Information, >> Template Id management, considerations for network topology, >> and IPFIX Mediation interpretation,and considerations for >> aggregation. > > Remove the first "and". Done. > > >> >> >> >> >> Expires January 6, 2012 [Page 3] >> >> Internet-Draft July 2011 >> >> >> The specifications in this document are based on the IPFIX >> protocol specifications[ref] but adapted according to the IPFIX >> Mediation Framework [IPFIX-MED-FMWK]. > > Please add the missing reference. Done. > > >> >> >> 1.1. IPFIX Documents Overview >> >> The IPFIX Protocol [RFC5101] provides network administrators >> with access to IP Flow information. >> >> The architecture for the export of measured IP Flow >> information out of an IPFIX Exporting Process to a Collecting >> Process is defined in the IPFIX Architecture [RFC5470], per >> the requirements defined inRFC 3917 [RFC3917]. > > While I appreciate that this is probably cut-n-pasted from another > IPFIX doc, it would be better to say, "per the requirements defined in > the IPFIX Requirements doc, [RFC3917]." Done. > >> The IPFIX Architecture [RFC5470] specifies how IPFIX Data >> Records and Templates are carried via a congestion-aware >> transport protocol from IPFIX Exporting Processes to IPFIX >> Collecting Processes. >> >> IPFIX has a formal description of IPFIX Information Elements, >> their name, type and additional semantic information, as >> specified in the IPFIX Information Model [RFC5102]. >> >> The IPFIX Applicability Statement [RFC5472] describes what >> type of applications can use the IPFIX protocol and how they >> can use the information provided. It furthermore shows how >> the IPFIX framework relates to other architectures and >> frameworks. >> >> "IPFIX Mediation: Problem Statement" [RFC5982], describing the >> IPFIX Mediation applicability examples, along with some problems >> that network administrators have been facing, is the basis for >> the "IPFIX Mediation: Framework" [IPFIX-MED-FMWK]. This >> framework details the IPFIX Mediation reference model and the >> components of an IPFIX Mediator. >> >> >> 1.2. IPFIX Mediator Documents Overview >> >> The "IPFIX Mediation: Problem Statement" [RFC5982] provides an >> overview of the applicability of Mediators, and defines >> requirements for Mediators in general terms. This document is >> of use largely to define the problems to be solved through the >> deployment of IPFIX Mediators, and to provide scope to the role >> of Mediators within an IPFIX collection infrastructure. >> >> >> >> Expires January 6, 2012 [Page 4] >> >> Internet-Draft July 2011 >> >> >> The "IPFIX Mediation: Framework" [IPFIX-MED-FMWK] provides more >> architectural details of the arrangement of Intermediate >> Processes within a Mediator. >> >> The details of specific Intermediate Processes, when these have >> additional export specifications (e.g., metadata about the >> intermediate processing conveyed through IPFIX Options >> Templates), are each treated in their own document (e.g., the >> "IP Flow Anonymization Support" [RFC6235]). Documents >> specifying the operations of specific Intermediate Processes >> cover the operation of these Processes within the Mediator >> framework, andcomplying to the specifications given in this > > "comply with" Done. > > >> document; they may additionally specify the operation of the >> process independently, outside the context of a Mediator, when >> this is appropriate. As of today, these documents are: >> >> 1. "IP Flow Anonymization Support", [RFC6235], which describes >> Anonymization techniques for IP flow data and the export of >> Anonymized data using the IPFIX protocol. >> >> 2. "Flow Selection Techniques" [IPFIX-MED-FLOWSEL], which >> described the process of selecting a subset of flows from all > > "describes". Done. > > >> flows observed at an observation point, along with the >> motivations, and some specific flow selection techniques. > > "motivations"... for what? NEW: "Flow Selection Techniques" [IPFIX-MED-FLOWSEL], which describes the process of selecting a subset of flows from all flows observed at an observation point, the flow selection motivations, and some specific flow selection techniques. > > >> >> 3. "Exporting Aggregated Flow Data using the IP Flow Information >> Export" [IPFIX-MED-AGGR] which describes Aggregated Flow export >> within the framework of IPFIX Mediators and defines an >> interoperable, implementation-independent method for Aggregated >> Flow export. Added (to cover the next comment) This document specifies the IP Flow Information Export (IPFIX) protocol specific to Mediation, i.e. the specifications that all Intermediate Processes type must comply to. Some extra specifications might be required per Intermediate Process type (In which case, the Intermediate Process specific document would cover those). >> >> 1.3. Relationship with IPFIX and PSAMP >> >> The specification in this document applies to the IPFIX >> protocol specifications [RFC5101]. All specifications from >> [RFC5101] apply unless specified otherwise in this document. >> >> As the Packet Sampling (PSAMP) protocol specifications >> [RFC5476] are based on the IPFIX protocol specifications, the >> specifications in this document are also valid for the PSAMP >> protocol. Therefore, the method specified by this document >> also applies to PSAMP. > > Having read all this, it's not clear to me where the current document > fits in to the structure. > See above. > >> >> >> >> >> >> >> >> Expires January 6, 2012 [Page 5] >> >> Internet-Draft July 2011 >> >> >> 2. Terminology >> >> The IPFIX-specific terms, such as Observation Domain, Flow, Flow >> Key, Metering Process, Exporting Process, Exporter, IPFIX >> Device, Collecting Process, Collector, Template, IPFIX Message, >> Message Header, Template Record, Data Record, Options Template >> Record, Set, Data Set, Information Element, and Transport >> Session, used in this document are defined in [RFC5101]. >> The PSAMP-specific terms used in this document, such as >> Filtering and Sampling are defined in [RFC5476]. >> >> The IPFIX Mediation terms related to the aggregation, such as >> the Interval, Aggregated Flow, and AggregatedFonction are > > s/Fonction/Function/ Done. > > >> defined in [IPFIX-MED-AGGR]. >> >> The IPFIX Mediation-specific terminology used in this document >> is defined in "IPFIX Mediation: Problem Statement" [RFC5982], >> andreuse in "IPFIX Mediation: Framework" [IPFIX-MED-FMWK]. > > s/reuse/reused/ Done. > > >> However, since thosetwo documents are an informational RFC, the > > "since both of those documents are informational RFCs" Done. > > >> definitions have been reproduced here along with additional >> definitions. >> >> Similarly, sincethe [RFC6235] is an experimental RFC, the > > Either remove "the", or say "IP Flow Anonymization Support". Done. > > >> Anonymization Record, Anonymized Data Record, and Intermediate >> Anonymization Process terms, specified in [RFC6235], are also >> reproduced here. >> >> In this document, as in [RFC5101], [RFC5476], [IPFIX-MED-AGGR , >> and [RFC6235], the first letter of each IPFIX-specific and >> PSAMP-specific term is capitalized along with the IPFIX >> Mediation-specific term defined here.In this document, we call >> "record stream" a stream of records carrying flow- or packet- >> based information.The records may be encoded as IPFIX Data > > This is back to front: "In this document, we call a stream of records > carrying flow- or packet-based information a "record stream". > Done. > >> Records in any other format. > > "Records, or" Done. > > > The indentation of the following sections is inconsistent. The reason is that we start the definitions, which are indented > > >> >> Transport Session Information >> >> The Transport Session is specified in [RFC5101]. In SCTP, the >> Transport Session Information is the SCTP association. In TCP >> and UDP, the Transport Session Information corresponds to a 5- >> tuple {Exporter IP address, Collector IP address, Exporter >> transport port, Collector transport port, transport protocol}. >> >> Original Exporter >> >> An Original Exporter is an IPFIX Device that hosts the >> Observation Points where the metered IP packets are observed. >> >> >> Expires January 6, 2012 [Page 6] >> >> Internet-Draft July 2011 >> >> >> >> Original Observation Point >> >> An Observation Point of the Original Exporter(s). In the case >> of the Intermediate Aggregation Process on an IPFIX Mediator, >> the Original Observation Point can be composed of a (set of) >> specific exporter(s), a (set of) specific interface(s) on an >> Exporter, a (set of) line card(s) on an Exporter, or any >> combinations of these. > > This sounds like a limiting definition - in which case, please use > some 2119 language. > If it's just by way of example, then please say so. eg, "can be > composed of, but not limited to, ...". Done. > Or append, "this is not an exhaustive list." > > Also, you assume that the OPs are on the Exporter, which isn't > necessarily correct. First, you mean "Original Exporter". Done. > Second, the OPs are somewhere near the MP, which may be remote from > the Exporter. eg, the OPs and MP are on a linecard, while the EP is on > an RP. > Or with metered data stored in a file then replayed to a mediator, the > OPs may be quite remote from the EP. This Original Observation Point definition is based on the Original Exporter definition (An Original Exporter is an IPFIX Device that hosts the Observation Points where the metered IP packets are observed), so isn't it consistent? > > >> >> IPFIX Mediation >> >> IPFIX Mediation is the manipulation and conversion of a record >> stream for subsequent export using the IPFIX protocol. >> >> The following terms are used in this document to describe the >> architectural entities used by IPFIX Mediation. >> >> Intermediate Process >> >> An Intermediate Process takes a record stream as its input >> from Collecting Processes, Metering Processes, IPFIX File >> Readers, other Intermediate Processes, or other record >> sources; performssome transformations on this stream, based > > "Some" requires > 1. Consider "one or more". Cut and paste from RFC 6183. Listed as an open issue > > >> upon the content of each record, states maintained across >> multiple records, or other data sources; and passes the > > So a mediator can't do random sampling? Question: isn't it covered by "states maintained across multiple records", i.e. I want to select one random record across 100 ones. The states would be something such as: total number of records the IMP has seen, modulo 100 whether or not one has record has been selected already for the last interval > > >> transformed record stream as its output to Exporting >> Processes, IPFIX File Writers, or other Intermediate >> Processes,in order to perform IPFIX Mediation. Typically, an > > It sounds like it's passing the output to these consumers for them to > perform Mediation. > I don't think think this is what you meant. Consider moving this > clause to the top: > "In order to perform IPFIX Mediation, an Intermediate Process takes a > record stream..." Cut and paste from RFC 6183. Listed as an open issue > > >> Intermediate Process is hosted by anIPFIX Mediator. > > Define "IPFIX Mediator". eg, next under "IPFIX Mediation", "IPFIX > Mediator: A device which performs IPFIX mediation. An IPFIX Mediator > contains both a Collecting Process and an Exporting Process". > [Later] OK, you did define this... far too far down below. Moved here. > > >> Alternatively, an Intermediate Process may be hosted by an >> Original Exporter. >> >> Specific Intermediate Processes are described below. However, >> this is not an exhaustive list. > > Please indent the following list a bit more, so it's clear where the > list ends and other definitions continue. Done. > > >> >> Intermediate Conversion Process >> >> An Intermediate Conversion Process is an Intermediate Process >> that transformsnon-IPFIX into IPFIX, or manages therelation > > What about IPFIX into non-IPFIX (eg, NFv9, Nfv5) ? > > "relationship" Cut and paste from RFC 6183. Listed as an open issue > > >> among Templates and states of incoming/outgoing Transport >> Sessions (or equivalent for non IPFIX protocols) in the case >> of transport protocol conversion (e.g., from UDP to SCTP). >> >> Intermediate Aggregation Process >> >> >> >> >> Expires January 6, 2012 [Page 7] >> >> Internet-Draft July 2011 >> >> >> An Intermediate Aggregation Process is an Intermediate Process >> that aggregates records based upon a set of Flow Keys or >> functions applied to fields from the record (e.g., binning and >> subnet aggregation). >> >> Intermediate Correlation Process >> >> An Intermediate Correlation Process is an Intermediate Process >> that adds information to records, noting correlations among >> them, or generates new records with correlated data from >> multiple records (e.g., the production of bidirectional flow >> records from unidirectional flow records). >> >> Intermediate Selection Process >> >> An Intermediate Selection Process is an Intermediate Process >> that selects records froma sequence based upon criteria- > > What is "a sequence" ? Listed as an open issue > > >> evaluated record values and passes only those records that >> match the criteria (e.g., Filtering only records from a given >> network to a given Collector). >> >> Intermediate Anonymization Process >> >> An Intermediate Anonymization Process is an Intermediate >> Process that transforms records in order to anonymize them, to >> protect the identity of the entities described by the records >> (e.g., by applying prefix-preserving pseudonymization of IP >> addresses). > > Consider giving a reference here. Listed as an open issue > > >> >> IPFIX Mediator >> >> An IPFIX Mediator is an IPFIX Device that provides IPFIX >> Mediation by receiving a record stream fromsome data sources, > > "Some" is > 1. "One or more" seems sufficient. Listed as an open issue > > >> hosting one or more Intermediate Processes to transform that >> stream, and exporting the transformed record streaminto IPFIX > > s/into/in/ Listed as an open issue > > >> Messages via an Exporting Process. In the common case, an > > Can't it write to a file too? Listed as an open issue > > >> IPFIX Mediator receives a record stream from a Collecting >> Process, but it could also receive a record stream from data >> sources not encoded using IPFIX, e.g., in the case of >> conversion from the NetFlow V9 protocol [RFC3954] to IPFIX >> protocol. > > Great. Say this stuff WAY up at the top. Moved just after the Intermediate Process > > >> >> Template Mapping >> >> A mapping from Template Records and/or Options Template >> Records received by a Mediator to Template Records and/or >> Options Template Records sent by that IPFIX Mediator. Each >> >> >> Expires January 6, 2012 [Page 8] >> >> Internet-Draft July 2011 >> >> >> entry in a Template Mapping is scoped by incoming or outgoing >> Transport Session and Observation Domain, as with Templates >> and Options Templates in the IPFIX Protocol. >> >> Anonymization Record >> >> A record, defined by the Anonymization Options Template in >> section Section 6.1, that defines the properties of the > > Oops. Done. > > >> Anonymization applied to a single Information Element within a >> single Template or Options Template. >> >> Anonymized Data Record >> >> A Data Record within a Data Set containing at least one >> Information Element with Anonymized values. The Information >> Element(s) within the Template or Options Template describing >> this Data Record SHOULD have a corresponding Anonymization >> Record. >> >> >> 3. Specifications >> >> This section describes the IPFIX specifications for Mediation: >> more specifically, specifications for generic Intermediate >> Processes. Possible specific Intermediate Processes are: >> Intermediate Conversion Process, Intermediate Aggregation >> Process, Intermediate Correlation Process, Intermediate >> Selection Process, Intermediate Anonymization Process. > > Is this a definitive and exhaustive list? Earlier you said it wasn't. We wrote: "_Possible _specific Intermediate Processes are:" Do you need something else? > > >> >> For a specific Intermediate Process, the specifications in the >> followingreference MUST be followed, onthe top of the >> specifications in this document: > > "references". > > Remove "the". Done > > >> - For the Intermediate Aggregation Process, the specifications >> in [IPFIX-MED-AGGR] MUST be followed. >> - For the Intermediate Selection Process, the specifications in >> [IPFIX-MED-FLOWSEL] MUST be followed. >> - For the Intermediate Anonymization Process, the specifications >> in [RFC6235] should be considered as guidelines as [RFC6235] >> is an experimental RFC. >> Note that no specific document deals with the Intermediate >> Conversion Process at the time of this publication. > > Then where should this be specified? Question: In a new document (which is not part of the current charter). Do we need to mention that? > > >> >> These new specifications, which are more specificcompared to > > s/compared to/than/ done > > >> [RFC5101], are described with the key words described in >> [RFC2119]. >> >> >> >> >> Expires January 6, 2012 [Page 9] >> >> Internet-Draft July 2011 >> >> >> 3.1. Encoding of IPFIX Message Header >> >> The format of the IPFIX Message Header is shown in Figure A. >> Note that the format is similar to the IPFIX Message in >> [RFC5101], but some field definitions (for the example, the >> Export Time) have been updated in the context of the IPFIX >> Mediator. >> >> >> 0 1 2 3 >> 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> | Version Number | Length | >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> | Export Time | >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> | Sequence Number | >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> | Observation Domain ID | >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> >> >> Figure A: IPFIX Message Header format >> >> >> Message Header Field Descriptions >> >> Version >> >> Version of Flow Record format exported in this message. >> The value of this field is 0x000a for the current >> version, incrementing by one the version used in the >> NetFlow services export version 9 [RFC3954]. >> >> Length >> >> Total length of the IPFIX Message, measured in octets, >> including Message Header and Set(s). >> >> Export Time >> >> Time in seconds since 0000 UTC Jan 1st 1970, at which >> the IPFIX Message Header leaves the IPFIX Mediator. > > We're leave a legacy year-2106 problem :-( Solved > > >> Sequence Number >> >> >> >> Expires January 6, 2012 [Page 10] >> >> Internet-Draft July 2011 >> >> >> Incremental sequence counter modulo 2^32 of all IPFIX >> Data Records senton this PR-SCTP stream from the > > Where did you say we're using pr-SCTP? > If I'm not, then this definition doesn't apply? This is a cut/paste from RFC5101. > > >> current Observation Domain by the Exporting Process. >> Check the specific meaning of this field in the sub- >> sections ofsection 10 when UDP or TCP is selected as > > You don't have a section 10. You mean, "section 10 of [RFC5101]". Yes and no > > I get the feeling I'm the first to actually read this :-( This would refer to RFC5101, except that now we have to refer to RFC5101bis. So I put a RFC's editor note as we have multiple evolving documents > [Later] Yes, very much so. Btw, we really appreciate your thorough review. > > >> the transport protocol. This value SHOULD be used by >> the Collecting Process to identify whether any IPFIX >> Data Records have been missed. Template and Options >> Template Records do not increase the Sequence Number. >> >> Observation Domain ID >> >> A 32-bit identifier of the Observation Domain that is >> locally unique to the Exporting Process. The Exporting >> Process uses the Observation Domain ID to uniquely >> identify to the Collecting Process the Observation >> Domain that metered the Flows. It is RECOMMENDED that >> this identifier is also unique per IPFIX >> Device. Collecting Processes SHOULD use the Transport >> Session and the Observation Domain ID field to separate >> different export streams originating from the same >> Exporting Process. The Observation Domain ID SHOULD be >> 0 when no specific Observation Domain ID is relevant for >> the entire IPFIX Message. For example, when exporting >> the Exporting Process Statistics, or in case of >> hierarchy of Collector when aggregated Data Records are >> exported. >> Note: the Observation Domain Management is discussed in >> section 3.4.1. >> >> >> 3.2. Template Management >> >> 3.2.1. Template Management Without Template Records Change >> >> The first case is a situation where the IPFIX Mediator doesn't >> modify the (Options) Template Record(s) content. A typical >> example is an Intermediate Selection Process acting as >> distributor, which collects Flow Records from one ormultiple > > s/multiple/more/ Done. > > >> Exporters, and based on the Information Elements content, >> redirects the Flow Records to the appropriate Collector. This >> example is a typical case of a single network operation center >> managing multiple universities: an unique IPFIX Collector >> collects all Flow Records for the common infrastructure, but >> might be re-exporting specific university Flow Records to the >> responsible system administrator. >> >> >> >> Expires January 6, 2012 [Page 11] >> >> Internet-Draft July 2011 >> >> >> As specified in [RFC5101], the Template IDs are unique per >> Exporter, per Transport Session, and per Observation Domain. As >> there is no guarantee that, for similar Template Records, the >> Template IDs received on the incoming Transport Session and >> exported to the outgoing Transport Session would be same, the >> IPFIX Mediator MUST maintain a Template Mapping composed of >> similar received and exported (Options) Template Records: > > s/similar/related/ done. > > >> - for each received (Options) Template Record: Template Record >> Flow Keys and non Flow Keys, Template ID, Observation Domain >> Id, and Transport Session Information >> - for each exported (Options) Template Record: Template Record >> Flow Keys and non Flow Keys, Template ID, Collector, >> Observation Domain Id, and Transport Session Information >> >> If an IPFIX Mediator receives an IPFIX Withdrawal Message for a >> (Options) Template Record that is not used anymore in any >> outgoing Transport Sessions, the IPFIX Mediator SHOULD export >> the appropriate IPFIX Withdrawal Message(s) on the outgoing >> Transport Session, and remove the corresponding entry in the >> Template Mapping. > > - assuming it's a 1:1 mapping. As an optimisation, the mediator could > resolve identical incoming templates (which may differ in their > template ID, observation domain, and perhaps in the order of their > fields) into a single outgoing template in an n:1 mapping. i.e. the > basic information content is the same. I hope you mention this > somewhere in the draft. e.g., in figure C below, templates A and B may > be identical. With the same software version and configuration on > multiple boxes, this is a likely real-world scenario. Good catch. OLD: If an IPFIX Mediator receives an IPFIX Withdrawal Message for a (Options) Template Record that is not used anymore in any outgoing Transport Sessions, the IPFIX Mediator SHOULD export the appropriate IPFIX Withdrawal Message(s) on the outgoing Transport Session, and remove the corresponding entry in the Template Mapping. NEW If an IPFIX Mediator receives an IPFIX Withdrawal Message for a (Options) Template Record that is not used anymore in any _otherTemplate Mappings_, the IPFIX Mediator SHOULD export the appropriate IPFIX Withdrawal Message(s) on the outgoing Transport Session, and remove the corresponding entry in the Template Mapping. > > In this case, the TWM should cause the mediator to remove the received > (Options) Template Record information, and decrement the exported > (Options) Template Record refcount by 1 but only delete it if it's no > longer used by anyone. Yes. I believe it's now covered by "any other Template Mappings" > > >> >> If a (Options) Template Record is not used anymore in an >> outgoing Transport Session, it MUST be withdrawn with an IPFIX >> Template Withdrawal Message on that specific outgoing Transport >> Session, and its entry MUST be removed from the Template >> Mapping. >> >> If an incoming or outgoing Transport Session is gracefully >> shutdown or reset, the (Options) Template Records corresponding >> to that Transport Session MUST be removed from the Template >> Mapping. > > There's a rather sudden change here. Link the two sections with "For > example, Figure B ..." Done. > >> >> Figure Bdisplays an example of anIntermediate Selection >> Process, re-distributing Data Records to Collectors on the basis > > The figure's caption says, "Intermediate Aggregation Process Example". > Which is it, selection or aggregation? Intermediate Selection Process. Corrected. > > >> ofthe customer networks, i.e. the Route Distinguisher (RD). In > > d/the/ Done. > > >> this example, the Template Record received from the Exporter#1 >> is reused towardsthe Collector#1, Collector#2, and Collector#3. > > d/the/ Done. > > >> >> >> Templ. .---------. >> ID 256 | | >> .---->|Collector|<==>Customer >> | |#1 | #A >> | | | >> RD=100:1 '---------' >> .---------.Templ. .---------. | >> | |Id | |----' .---------. >> >> >> Expires January 6, 2012 [Page 12] >> >> Internet-Draft July 2011 >> >> >> | |258 | | RD=100:2 | | >> |IPFIX |------->|IPFIX |--------->|Collector|<==>Customer >> |Exporter | |Mediator | Templ. |#2 | #B >> |#1 | | | ID 257 | | >> | | | |----. '---------' >> '---------' '---------' | >> RD=100:3 >> Templ.| .---------. >> ID | | | >> 257 '---->|Collector|<==>Customer >> |#3 | #C >> | | >> '---------' >> >> Figure B: Intermediate Aggregation Process Example >> >> > > Introduce the following tables. Presumably, "The following table shows > the Template Mapping for the system shown in Figure B." Done. > > >> Template Entry A: >> Incoming Transport Session Information (from Exporter#1): >> Source IP: >> Destination IP: >> Protocol: SCTP >> Source Port: >> Destination Port: 4739 (IPFIX) >> Observation Domain Id: >> Template Id: 258 >> Flow Keys: >> Non Flow Keys: > > Would it be clearer to write example values in the Figure? I've not been able to find without overloading the picture. > > >> >> Template Entry B: >> Outgoing Transport Session Information (to Collector#1): >> Source IP: >> Destination IP: >> Protocol: SCTP >> Source Port: >> Destination Port: 4739 (IPFIX) >> Observation Domain Id: >> Template Id: 256 >> Flow Keys: >> Non Flow Keys: >> >> Template Entry C: >> Outgoing Transport Session Information (to Collector#2): >> Source IP: >> Destination IP: >> Protocol: SCTP >> Source Port: >> >> >> Expires January 6, 2012 [Page 13] >> >> Internet-Draft July 2011 >> >> >> Destination Port: 4739 (IPFIX) >> Observation Domain Id: >> Template Id: 257 >> Flow Keys: >> Non Flow Keys: >> >> Template Entry D: >> Outgoing Transport Session Information (to Collector#3): >> Source IP: >> Destination IP: >> Protocol: SCTP >> Source Port: >> Destination Port: 4739 (IPFIX) >> Observation Domain Id: >> Template Id: 257 >> Flow Keys: >> Non Flow Keys: >> >> The Template Mapping corresponding tothe figure B can be > > d/the/ Done. > > >> displayed as: >> >> Template Entry A<----> Template Entry B >> Template Entry A<----> Template Entry C >> Template Entry A<----> Template Entry D > > To be picky, this looks like three instances of Template Entry A. How > about: > > +--> Template Entry B > | > Template Entry A<--+--> Template Entry C > | > +--> Template Entry D > The issue is that we treat the easy case first. So I added. Alternatively, the Template Mapping may be optimized as: +--> Template Entry B | Template Entry A<--+--> Template Entry C | +--> Template Entry D >> >> Note that all examples use Transport Sessions based on the SCTP >> protocol, as simplified use cases. However, the protocol would >> be important in situations such as an Intermediate Conversion >> Process doing transport protocol conversion. >> >> >> 3.2.2. Template Management With New Template Records >> >> The second case is a situation where the IPFIX Mediator >> generates new (Options) Template Recordscompared to the > > "compared to" doesn't seem right here. NEW: The second case is a situation where the IPFIX Mediator generates new (Options) Template Records as a result of the Intermediate Process. > > >> received ones. >> >> In such a situation, the IPFIX Mediator doesn't need to maintain >> a Template Mapping, as it generates its own series of (Options) >> Template Records. However, the following special case might >> still require a Template Mapping, i.e. a situation where the >> IPFIX Mediator, typically containing an Intermediate Conversion >> Process, Intermediate Aggregation Process [IPFIX-MED-AGGR], or >> Intermediate Anonymization Process in case of black-marker >> Anonymization [RFC6235], generates new (Options) Template >> Records based on what it receives from the Exporter(s), and >> based on the Intermediate Process function. In such a case, >> >> >> Expires January 6, 2012 [Page 14] >> >> Internet-Draft July 2011 >> >> >> it's interesting to keep the correlation between the received >> (Options) Template Records and exported DerivedOptions) > > (Options) Done. > >> Template Records in the Template Mapping. >> >> Therefore, the IPFIX Mediator MAY maintain a Template Mapping >> composed of received (Options) Template Records and exported >> derivedOptions) Template Records: >> - for each received (Options) Template Record: Template Record >> Flow Keys and non Flow Keys, Template ID, Observation Domain, >> and Transport Session Information >> - for each exported derivedOptions) Template Record: Template >> Record Flow Keys and non Flow Keys, Template ID, Collector, >> Observation Domain, and Transport Session Information >> >> If an IPFIX Mediator receives an IPFIX Withdrawal Message for a >> (Options) Template Record that is not used anymore as the basis >> ofan inferred (Options) TemplateRecords, the IPFIX Mediator > > Use "Record" or "Record(s)" to match with "an". Done. > > >> SHOULD export the appropriate IPFIX Withdrawal Message(s) for >> the inferred (Options) Template Record on the outgoing Transport >> Session, and remove the corresponding entry in the Template >> Mapping. >> >> The following two examples illustrate this. >> >> First, consider an IPFIX Mediator hosting an Intermediate >> Aggregation Process that generates time-series traffic octet >> counts per source IP address (as in the example in section 8.1 >> of [IPFIX-MED-AGGR]). Here, the Intermediate Process accepts >> Flow Records fitting any Template, discards all Information >> Elements other than the sourceIPv[46]Address and >> octetDeltaCount, aggregates these across all original Exporters >> in a given regular time interval, and exports Flow Records >> according to a Template Record containing >> flowStartTimeMilliseconds, flowEndTimeMilliseconds, >> sourceIPv[46]Address, and octetDeltaCount. >> >> In this case, no Template Mapping is necessary. New Templates >> and Template Withdrawals in the Transport Sessions from the >> Original Exporters are handled as they would be at any >> Collecting Process. Records according to Templates which do not >> contain at least a timestamp, sourceIPv[46]Address, and >> octetDeltaCount IE are simply discarded by the Collector. >> >> Next, consider a more generic case of this Intermediate >> Aggregation Process, which creates time-series aggregates across >> all Original Exporters, imposing a time interval but keeping a >> subset of the incoming Flow Key received from the Original >> >> >> Expires January 6, 2012 [Page 15] >> >> Internet-Draft July 2011 >> >> >> Exporter. In this case, a Template Mapping is necessary, as >> there is a relationship between incoming and outgoing Templates. >> >> .--------. tid 256 (src) >> |IPFIX | >> |Exporter|----+ >> |#1 | | >> '--------' | >> .--------. | .----------. .---------. >> |IPFIX | '--------->| | | | >> |Exporter|-------------->|IPFIX |------------->|IPFIX | >> |#2 | tid 257 (src) |Mediator |tid 256 (src) |Collector| >> '--------' +--------->| | 257 (dst) | | >> .--------. | '----------' '---------' >> |IPFIX | | >> |Exporter|----' >> |#3 | tid 257 (dst) >> '--------' >> >> Figure C: Intermediate Aggregation Process Example > > Personally, I feel that "src" and "dst" clutter this figure without > adding much. > At first I didn't understand what a src or dst template ID was. removed. > > >> >> In Figure C, above, the Mediator accepts a Template Record >> containing only the sourceIPv4Address as the Flow Key from >> Exporters 1 and 2, and a Template Record containing only the >> destinationIPv4Address as the Flow Key from exporter 3. It >> exports time-series source aggregates as Template ID 256, and >> time-series destination aggregates as Template ID 257. The >> Template Entries in this case are as follows: >> >> Template Entry A: >> Incoming Transport Session Information (from Exporter#1): >> Source IP: >> Destination IP: >> Protocol: SCTP >> Source Port: >> Destination Port: 4739 (IPFIX) >> Observation Domain Id: >> Template Id: 256 >> Flow Keys: sourceIPv4Address >> Non Flow Keys: octetDeltaCount, [others] >> >> Template Entry B: >> Incoming Transport Session Information (from Exporter#2): >> Source IP: >> Destination IP: >> Protocol: SCTP >> Source Port: >> >> >> Expires January 6, 2012 [Page 16] >> >> Internet-Draft July 2011 >> >> >> Destination Port: 4739 (IPFIX) >> Observation Domain Id: >> Template Id: 257 >> Flow Keys: sourceIPv4Address >> Non Flow Keys: octetDeltaCount, [others] >> >> Template Entry C: >> Incoming Transport Session Information (from Exporter#3): >> Source IP: >> Destination IP: >> Protocol: SCTP >> Source Port: >> Destination Port: 4739 (IPFIX) >> Observation Domain Id: >> Template Id: 257 >> Flow Keys: destinationIPv4Address >> Non Flow Keys: octetDeltaCount, [others] >> >> Template Entry D: >> Outgoing Transport Session Information (to IPFIX Collector): >> Source IP: >> Destination IP: >> Protocol: SCTP >> Source Port: >> Destination Port: 4739 (IPFIX) >> Observation Domain Id: >> Template Id: 256 >> Flow Keys: sourceIPv4Address >> Non Flow Keys: octetDeltaCount >> >> Template Entry E: >> Outgoing Transport Session Information (to IPFIX Collector): >> Source IP: >> Destination IP: >> Protocol: SCTP >> Source Port: >> Destination Port: 4739 (IPFIX) >> Observation Domain Id: >> Template Id: 257 >> Flow Keys: destinationIPv4Address >> Non Flow Keys: octetDeltaCount >> >> The Template Mapping corresponding tothe figure C can be > > d/the/ Done. > > >> displayed as: >> >> Template Entry A<----> Template Entry D >> Template Entry B<----> Template Entry D >> >> >> Expires January 6, 2012 [Page 17] >> >> Internet-Draft July 2011 >> >> >> Template Entry C<----> Template Entry E >> >> Note that all examples use Transport Sessions based on the SCTP >> protocol, as simplified use cases. However, the protocol would >> be important in situations such as an Intermediate Conversion >> Process doing transport protocol conversion. >> >> >> 3.3. Time Management >> >> The IPFIX Message Header "Export Time" field is the time in >> seconds since 0000 UTC Jan 1, 1970, at which the IPFIX Message >> Header leaves the IPFIX Mediator. However, in the specific case > > The header isn't disembodied. d/Header/ Good catch. > > >> of an IPFIX Mediator containing an Intermediate Conversion >> Process, the IPFIX Mediator MAY keep the export time received >> from the incoming Transport Session. > > Very generous. Why? List as an open issue. > > >> >> It is RECOMMENDED that Mediators handle time using absolute >> timestamps (e.g. flowStartSeconds, flowStartMilliseconds, >> flowStartNanoseconds), which are specified relative to the UNIX >> epoch (00:00 UTC 1 Jan 1970), where possible, rather than >> relative timestamps (e.g. flowStartSysUpTime, >> flowStartDeltaMicroseconds), which are specified relative to >> protocol structures such as system initialization or message >> export time. >> >> The latter are difficult to manage for two reasons. First, they >> require constant translation, as the system initialization time >> of an intermediate system and the export time of an intermediate >> message will change across mediation operations. Further, >> relative timestamps introduce range problems. For example, when >> using the flowStartDeltaMicroseconds and >> flowEndDeltaMicroseconds Information Elements[RFC5102], the > > Should you cite IANA here instead? Listed as an open issue. > > >> Data Record must be exported within a maximum of 71 minutes >> after its creation. Otherwise, the 32-bit counter would not be >> sufficient to contain the flow start time offset. Those time >> constraints might be incompatible with some of the Intermediate >> Processes: Intermediate Aggregation Process (temporal) and >> Intermediate Correlation Process, for example. >> >> When an Intermediate Aggregation Process aggregates information >> from different Flow Records, the typical reporting times SHOULD >> BE the minimum of the start times and the maximum of the end > > s/BE/be/ ;-) > > >> times. However, if the Flow Records do not overlap, i.e. if >> there is a time gap between the times in the Flow Records, then >> the report may be inaccurate. The IPFIX Mediator is only >> reporting what it knows, on the basis of the information made >> >> >> Expires January 6, 2012 [Page 18] >> >> Internet-Draft July 2011 >> >> >> available to it - and there may not have been any data to >> observe during the gap. Then again, if there is an overlap in >> timestamps, there's the potential of double-accounting: >> different Observation Points may have observed the same traffic >> simultaneously.Therefore, as there is not a single rule that >> fits all different situations, the precise rules of applying the >> Flow Record timestamps in IPFIX Mediators is out of the scope of >> this document. However, some more specifications related to the > > Being a hard problem doesn't make it out of scope. I think this is > exactly something that should be specified here. Else, where? Listed as an open issue > > >> specific case of aggregation in space and time arespecified in > > "specifications... are specified" seems clumsy. s/specified/given/ Done. > > >> [IPFIX-MED-AGGR], and MUST be followed. >> >> >> 3.4. Observation Point Management >> >> Depending on the use case,top Collectors may need to receive > > What are "top collectors"? top, as top collector in a chain of collectors. NEW: Depending on the use case, the Collector in an Exporter-Mediator-Collector structure model may need to receive the Original Observation Point(s), note that "Exporter-Mediator-Collector structure model" was used in RFC5982 (Mediation requirements) > > >> the Original Observation Point(s), otherwiseit may wrongly >> conclude that the IPFIX Device exporting the Flow Records to >> him, i.e. the IPFIX Mediator, directly observed the packets that > > These singular pronouns don't match plural "top Collectors". Consider > "they" and "them". Done. > > >> generated the Flow Records. Two new InformationElement are > > s/Element/Elements/ Done. > > >> introduced to solve this use case: originalExporterIPv4Address >> and originalExporterIPv6Address. >> >> In the IPFIX Mediator, the Observation Point(s) may be >> represented by: >> - A single Original Exporter (represented by the >> originalExporterIPv4Address or originalExporterIPv6Address >> Information Elements) >> - A list of Original Exporter (represented by the >> originalExporterIPv4Address or originalExporterIPv6Address >> Information Elements_) > > d/_/ > > >> - A list of Original Exporter (represented by the >> originalExporterIPv4Address or originalExporterIPv6Address >> Information Elements), along with the associated interface >> (represented by the ingressInterface and/or egressInterface) > > You've described "(list of originalExporterIPv[46]Address) + interface". > I think you meant, "list of (originalExporterIPv[46]Address + interface)". Good catch! NEW: -A list of Original Exporter interface(s) (represented by the originalExporterIPv4Address or originalExporterIPv6Address, the ingressInterface and/or egressInterface Information Elements, respectively) > > >> - A list of Original Exporter (represented by the >> originalExporterIPv4Address or originalExporterIPv6Address >> Information Elements), along with the associated line card id >> (represented by the lineCardId) NEW: -A list of Original Exporter line card (represented by the originalExporterIPv4Address or originalExporterIPv6Address, the lineCardId Information Elements, respectively) > > Today's OP could be at many more places than an interface or LC. We > need to move away from this old thinking. > > >> - Any combination or list of Information Elements representing >> Observation Points. > > Consider removing the previous two points and using them as specific > examples of this point. Good suggestion. > > >> >> Some Information Elements characterizing the Observation Point >> may be added. For example, the flowDirection Information >> Element specifies the direction of the observation, and, as >> such, characterizes the Observation Point. >> >> >> >> >> Expires January 6, 2012 [Page 19] >> >> Internet-Draft July 2011 >> >> >> Any combination of the above examples is possible. For example, >> in case of an Intermediate Aggregation Process, an Original >> Observation Point can be composed of: >> exporterIPv4Address 192.0.2.1 >> exporterIPv4Address 192.0.2.2, >> interface ethernet 0, direction ingress >> interface ethernet 1, direction ingress >> interface serial 1, direction egress >> interface serial 2, direction egress >> exporterIPv4Address 192.0.2.3, >> lineCardId 1, direction ingress >> >> If the Original Observation Point is composed of a list, then >> the IPFIX Structured Data [IPFIX-STRUCT] MUST be used to export >> it from the IPFIX Mediator. >> >> The most generic way to export the Original Observation Point is >> to use a subTemplateMultiList, with the semantic "exactlyOneOf". >> Takingback the previous example, the following encoding can be > > d/back/ done. > > >> used: >> >> Template Record 257: exporterIPv4Address >> Template Record 258: exporterIPv4Address, basicList of >> ingressInterface, flowDirecdtion > > s/flowDirecdtion/flowDirection/ Done. > > >> >> Template Record 259: exporterIPv4Address, lineCardId, >> flowDirection > > How does the mediator come to know where the OPs are in the original > devices? Either > > eg, suppose the OP is at the QoS process in order to verify SLA. > Although interface IDs and/or LC IDs may be exported, these might > incorrectly imply multiple OPs. > > >> >> The Original Observation Point is modeled with the Data Records >> corresponding to either Template Record 1, Template Record 2, or >> Template Record 3 but not more than one of these ("exactlyOneOf" >> semantic). This implies that the Flow was observed at exactly >> one of the Observation Points reported. >> >> When an IPFIX Mediator receives Flow Records containing the >> Original Observation Point Information Element, i.e. > > Aha! You expect the original exporter to populate FR with OOPIE, just > in case a mediator is present? LOL. > No existing exporters do that today. How does the mediator work? Not exactly. The point in that sentence is ... "SHOULD NOT modify its value(s)" However, you have a good point. NEW to the 1st paragraph in this section; Mediator-Collector structure model may need to receive the Original Observation Point(s), otherwise it may wrongly conclude that the IPFIX Device exporting the Flow Records to him, i.e. the IPFIX Mediator, directly observed the packets that generated the Flow Records.Two new Information Elements areintroduced to solve this use case: originalExporterIPv4Address and originalExporterIPv6Address. _Practically, the Original Exporters will not exporting these Information Elements. Therefore, the Intermediate Process SHOULD report the Original Observation Point(s) to the best of its knowledge. Note that the Configuration Data Model for IPFIX and PSAMP [IPFIX-CONF ] may help._ Also listed as an open issue, for discussion. > > >> originalExporterIPv6Address or originalExporterIPv4Address, the >> IPFIX Mediator SHOULD NOT modify its value(s) when composing new >> Flow Records in the general case. Known exceptions include >> anonymization per [RFC6235] section 7.2.4 and an Intermediate >> Correlation Process rewriting addresses across NAT. >> >> In other words, the Original Observation Point should not be >> replaced the IPFIX Mediator Observation Point. The daisy chain >> of (Exporter, Observation Point) representing the path the Flow >> >> >> >> >> Expires January 6, 2012 [Page 20] >> >> Internet-Draft July 2011 >> >> >> Records took from the Exporter to thetop Collector, via the >> IPFIX Mediator(s) is out of the scope of this specification. > > Why do you say it's out of scope? Where else would you expect it to be > specified? Question: Do you believe it's important to report that the flow record was exported from exporter 1 via mediator 1 via mediator 2 via mediator 3 to collector 1? > > >> >> >> >> 3.4.1. Observation Domain Management >> >> In any case, the Observation Domain ID of any IPFIX Message >> containing Flow Records relevant to no particular Observation >> Domain, or to multiple Observation Domains, MUST have an >> Observation Domain ID of 0, as in section 3.1 above, and section >> 3.1 of [RFC5101]. >> >> IPFIX Mediators that do not change (Options) Template Records >> MUST maintain a Template Mapping, as detailed in section 3.2.1, >> to ensure that the combination of Observation Domain IDs and >> Template IDs do not collide on export. >> >> For IPFIX Mediators that export New (Options) Template Records >> unchanged, as in section 3.2.2, there are two options for >> Observation Domain ID management. The first and simplest of >> these is to completely decouple exported Observation Domain IDs >> from received Observation Domain IDs; the IPFIX Mediator, in >> this case, comprises its own set of Observation Domain(s) >> independent of the Observation Domain(s) of the Original >> Exporters. >> >> The second option is to provide or maintain a Template Mapping >> for received (Options) Template Records and exported inferred >> (Options) Template Records, along with the appropriate >> Observation Domain IDs per Transport Session, which ensures that >> the combination of Observation Domain IDs and Template IDs do >> not collide on export. >> >> In some cases where the IPFIX Message Header can't contain a >> consistent Observation Domain for the entire IPFIX Message, but >> the Flow Records exported from the IPFIX Mediator should anyway >> contain the Observation Domain of the Original Exporter, the >> (Options) Template Record must contain the >> originalObservationDomainId Information Element. When an IPFIX >> Mediator receives Flow Records containing the >> originalObservationDomainId Information Element, the IPFIX >> Mediator MUST NOT modify its value(s) when composing new Flow >> Records with the originalObservationDomainId Information >> Element. >> >> >> >> >> Expires January 6, 2012 [Page 21] >> >> Internet-Draft July 2011 >> >> >> 3.5. Specific Reporting Requirements >> >> Some specific Options Templates and Options Template Records are >> necessary to provide extra information about the Flow Records >> and about the Metering Process. >> >> The Options Template Records defined in these subsections, which >> impose some constraints on the Metering Process and Exporting >> Process implementations in Intermediate Processes, MAY be >> implemented. If implemented, the specific Option Templates >> SHOULD be implemented as specified in these subsections. >> >> The minimum set of Information Elements is always specified in >> theseSpecific IPFIX Options Templates. Nevertheless, extra > > Why is "Specific" capitalised? corrected. > > >> Information Elements may be used in these specific Options >> Templates. > > Other things I'd like to see in this section: > > What about IE ordering? May an exporter re-order received fields? eg, > two devices sending the same information, though with the fields in a > different order. Or the mediator is extracting the same information > from two sources. That seems to be a valid scenario. eg, this reduces > the number of templates received at the collector. > > What about temporal re-ordering? How should a mediator deal with > out-of-order data coming from multiple devices? It can't expect all > received data to be in time order. > > What should a mediator do with a field which it doesn't > know/understand? Inevitably, exporters will be updated without > mediators keeping in step. It's also very likely that mediators will > see Enterprise-specific IEs. May a mediator re-export unknown IEs > unchanged, or should it drop them? Presumably a mediator may report > received Enterprise-specific IEs even from multiple different Enterprises. > > What if an unknown field depends on the field ordering? eg, it's a > bitfield like flowKeyIndicator. Re-ordering, adding or removing fields > breaks the meaning of this field, so it can't be passed on. It can > only be used if the received fields are reported unchanged. Listed as an open issue. > > >> >> >> 3.5.1. The Flow Keys Options Template >> >> Exactly like the IPFIX protocol [RFC5101], the Flow Keys Option >> Template specifies the structure of a Data Record for reporting >> the Flow Keys of reported Flows. A Flow Keys Data Record >> extends a particular Template Record that is referenced by its >> templateId identifier. The Template Record is extended by >> specifying which of the Information Elements contained in the >> corresponding Data Records describe Flow properties that serve >> as Flow Keys of the reported Flow. >> >> The Flow Keys Option Template SHOULD contain the following >> Information Elements that are defined in [RFC5102] >> templateId An identifier of a Template. This >> Information Element MUST be defined >> as a Scope Field. >> >> flowKeyIndicator Bitmap with the positions of the Flow >> Keys in the Data Records. > > As a general point, can you space all your lists, with space before > and after too? > It's less easy to read when all the text is jammed together. Done. > > >> When any Intermediate Process changes the Flow Keys, the Flow >> Keys Option Template MUST include the new set of Flow Keys. >> Typically, an Intermediate Aggregation Process keeps or reduces >> the number of Flow Keys > > Missing full-stop here. Done. > > Consider mentioning how it can increase the number of keys. eg, by > adding info about the OP or Exporter. Good point. I added: However, the number of Flow Keys may increase when the Original Exporter or/and Original Observation Point is/are added. > > >> >> 3.5.2. IPFIX Protocol Options Template >> >> The "Metering Process Statistics Options Template", "The >> Metering Process Reliability Statistics Options Template", and >> "The Exporting Process Reliability Statistics Options Template", >> >> >> Expires January 6, 2012 [Page 22] >> >> Internet-Draft July 2011 >> >> >> as specified in [RFC5101], SHOULD be implemented on the IFPIX > > s/IFPIX/IPFIX/ ;-) > > >> Mediator. >> >> Refer to the document specifying a particular Intermediate >> Process type for specific values for these Options Template >> Records. For example, in case of an Intermediate Aggregation >> Process, [IPFIX-MED-AGGR]must specify which values to insert > > s/must specify/specifies/ done. > > >> into the fields of "Metering Process Statistics Options >> Template", "The Metering Process Reliability Statistics Options >> Template", and "The Exporting Process Reliability Statistics >> Options Template" >> >> >> 3.5.3. IPFIX Mediator Options Template >> >> There is no need for a specific Options Template for the IPFIX >> Mediator; instead, each Intermediate Process type requires some >> particular metadata. For example, a specification of IPFIX flow >> Anonymization including an Options Template for the export of >> metadata about Anonymized flows is described in [RFC6235]; when >> Anonymizing Flows Records, IPFIX Mediators SHOULD add the >> Options Template specified therein to annotate the exported >> data. >> >> Transport Session Management SCTP [RFC4960] using the PR-SCTP >> extension specified in [RFC3758] MUST be implemented by all >> compliant IPFIX Mediator implementations. UDP [UDP] MAY also be >> implemented by compliant IPFIX Mediator implementations. TCP >> [TCP] MAY also be implemented by IPFIX Mediator compliant >> implementations. > > For consistency, you should refer to these by their RFC numbers: "TCP > [RFC793]", "UDP [RFC768]". Done. > > >> >> PR-SCTP SHOULD be used in deployments where IPFIX Mediators and >> Collectors are communicating over links that are susceptible to >> congestion. PR-SCTP is capable of providing any required degree >> of reliability. >> >> TCP MAY be used in deployments where IPFIX Mediators and >> Collectors communicate over links that are susceptible to >> congestion, but PR-SCTP is preferred due to its ability to limit >> back pressure on Exporters and its message versus stream >> orientation. >> >> UDP MAY be used, although it is not a congestion-aware protocol. >> However, the IPFIX traffic between IPFIX Mediator and Collector > > However, in this case, the ... Done. > > >> MUST run in an environment where IPFIX traffic has been >> provisioned for, or is contained through some other means. >> >> >> >> Expires January 6, 2012 [Page 23] >> >> Internet-Draft July 2011 >> >> >> 3.6. The Collecting Process's Side >> >> An IPFIX Mediator MUST produce IPFIX Messages understandable by >> a RFC5101-compliant IPFIX Collector, with the additional > > Here you're limiting what mediators can do in future. If a future > mediator wants to do something that's not backwards compatible with > 5101 and specifies an extension to 5101 in order to do so, it'll break > this MUST. Removed the MUST This section has been updated to be compliant with RFC5101bis NEW: An IPFIX Mediator produces IPFIX Messages understandable by a IPFIX-compliant Collector, with the additional specifications in IPFIX Structured Data [IPFIX-STRUCT]. Therefore the Collecting Process on the top Collector MUST support the IPFIX protocol [RFC5101bis] and the IPFIX Structured Data [IPFIX-STRUCT]. > > >> specification inthe IPFIX Structured Data [IPFIX-STRUCT]. > > "specifications" > d/the/ Done. > > >> >> Therefore the Collecting Process on thetop Collector MUST >> support the IPFIX protocol [RFC5101] andthe IPFIX Structured >> Data [IPFIX-STRUCT]. >> >> >> 3.7. Configuration Management >> >> In some cases such as an Intermediate Aggregation Process >> aggregating Flow Records from multiple Original Exporters, a >> consistent configuration of the Metering Processes and Exporting >> Processes on theseOriginal offers some advantages. For > > Original Exporters. Done. > > >> example, consistent active timeout, inactive timeout, and/or >> consistent export timeallows to compare the number of the Flow >> Records per period of time. For example, consistent Sampling >> algorithm and parameters mightallow to compareFlow Records >> accuracy. > > Either s/allow to compare/allows comparison of/, or put "to be > compared" at the end: > > consistent active timeout, inactive timeout, and/or consistent > export time allows > the number of the Flow Records per period of time to be compared. > For example, consistent Sampling algorithm and parameters might > allow Flow Records accuracy to be compared. Done. > > >> >> While this is tempting to include all configuration parameters >> in Flow Records for the IPFIX Mediator to draw its own >> conclusion, the consistency of the configuration should be >> verified out of band, with the MIB modules ([RFC5815] and >> [PSAMP-MIB]or with the Configuration Data Model for IPFIX and >> PSAMP [IPFIX-CONF] > > [PSAMP-MIB]) > Missing full-stop. Done. > > >> >> >> 4. New Information Elements >> >> EDITOR NOTE: please change the TBD1, TBD2, and TBD3, with the >> IANA newly assigned numbers. >> >> 4.1.- originalExporterIPv4Address > > Remove the hyphen (dash) from the section title. done. > > >> Description: The IPv4 address used by the Exporting Process on >> the Original Exporter. This is used by an IPFIX Mediator >> Exporting Process to identify the Original Exporter. >> >> Abstract Data Type: ipv4Address >> >> ElementId: TBD3 >> >> Status: Proposed > > Add "Semantics: identifier" for consistency with similar fields in the > IANA IPFIX registry. > > [Later] OK, there's some duplication with section 6. You could just > list the Description and Type here, with a note that the full spec is > in the IANA section below. Done. NEW: Three new Information Elements are requested in this specifications: originalExporterIPv4Address, originalExporterIPv6Address, and originalObservationDomainId. See Section 6.1. , Section 6.2. , and Section 6.3. , respectively, for the formal definitions. > > >> >> >> Expires January 6, 2012 [Page 24] >> >> Internet-Draft July 2011 >> >> >> >> >> 4.2. originalExporterIPv6Address >> >> Description: The IPv6 address used by the Exporting Process on >> the Original Exporter. This is used by the IPFIX Mediator >> Exporting Process to identify the Original Exporter. >> >> Abstract Data Type: ipv6Address >> >> ElementId: TBD2 >> >> Status: Proposed > > Add "Semantics: identifier" for consistency with similar fields in the > IANA IPFIX registry. > > >> >> >> 4.3. originalObservationDomainId >> >> Description: An identifier of the Observation Domain on the >> Original Exporter, where the metered IP packets are observed. >> This is used by the IPFIX Mediator Exporting Process to identify >> an Observation Domain as received from the Original Exporter. >> >> Abstract Data Type: unsigned32 >> >> ElementId: TBD3 >> >> Status: Proposed > > Add "Semantics: identifier" for consistency with #149 in the IANA > IPFIX registry. > > >> >> >> >> 5. Security Considerations >> >> The same security considerations as for the IPFIX Protocol >> [RFC5101] apply. >> >> As they act as both IPFIX Collecting Processes and Exporting >> Processes, the Security Considerations forIPFIX [RFC5101]apply > > s/IPFIX/The IPFIX Protocol/ done. > > >> as well to Mediators. The Security Considerations for IPFIX > > s/apply as well/also apply/ Done. > > >> Files [RFC5655]apply as well to IPFIX Mediators that write > > s/apply as well/also apply/ Done. > > >> IPFIX Files or use them for internal storage. However, there >> are a few specific considerations that IPFIX Mediator >> implementationsmust take into account in addition. > > s/must take into account in addition/must also take into account/ done. > > >> >> By design, IPFIX Mediators are "men-in-the-middle": they >> intercede in the communication between an Original Exporter (or >> another upstream Mediator) and a downstream Collecting Process. >> This has two important implications for the level of >> >> >> Expires January 6, 2012 [Page 25] >> >> Internet-Draft July 2011 >> >> >> confidentiality provided across an IPFIX Mediator, and the >> ability to protect data integrity and Original Exporter >> authenticity across a Mediator. These are addressed in more >> detail in the Security Considerations for Mediators in [IPFIX- >> MED-FMWK]. >> >> Note that, while Mediators can use the exporterCertificate and >> collectorCertificate Information Elements defined in [RFC5655] >> as described in section 9.3 of [IPFIX-MED-FMWK] to export >> information about X.509 identities in upstream TLS-protected >> Transport Sessions, this mechanism cannot be used to provide >> true end-to-end assertions about a chain of IPFIX Mediators: any >> Mediator in the chain can simply falsify the information about >> upstream Transport Sessions In situations where information >> about the chain of mediation is important, it must be determined >> out of band. >> >> >> 6. IANA Considerations >> >> This document specifies three new IPFIX Information Elements: the >> applicationDescription, applicationTag and the applicationName. >> >> New Information Elements to be added to the IPFIX Information >> Element registry at [IANA-IPFIX] are listed below. >> >> EDITOR'S NOTE: the XML specification in Appendix A must be updated >> with theelementID values allocated, i.e. TBD1, TBD2, andTDB3, > > s/elementID/elementId/ > > s/TDB/TBD/ Done. > > The Appendix will be orphaned when this note is removed. So say > something like, "XML specifications of these elements can be found in > Appendix A". Done. > > >> must be replaced. >> >> >> 6.1. originalExporterIPv4Address >> >> Name: originalExporterIPv4Address >> Description: >> The IPv4 address used by the Exporting Process on the Original >> Exporter. This is used by an IPFIX Mediator Exporting Process >> to identify the Original Exporter. >> Abstract Data Type: ipv4Address >> Data Type Semantics: identifier >> ElementId: TBD1 >> Status: current >> >> >> >> >> >> >> >> Expires January 6, 2012 [Page 26] >> >> Internet-Draft July 2011 >> >> >> 6.2. originalExporterIPv6Address >> >> Name: originalExporterIPv6Address >> Description: >> The IPv6 address used by the Exporting Process on the Original >> Exporter. This is used by the IPFIX Mediator Exporting Process >> to identify the Original Exporter. >> Abstract Data Type: ipv6Address >> Data Type Semantics: identifier >> ElementId: TBD2 >> Status: current >> >> >> 6.3. originalObservationDomainId >> >> Name: originalObservationDomainId >> Description: >> An identifier of the Observation Domain on the Original >> Exporter, where the metered IP packets are observed. This is >> used by the IPFIX Mediator Exporting Process to identify an >> Observation Domain as received from the Original Exporter. >> Abstract Data Type: unsigned32 >> Data Type Semantics: identifier >> ElementId: TBD3 >> Status: current >> >> 7. References >> >> 7.1. Normative References >> >> [RFC2119] S. Bradner, Key words for use in RFCs to Indicate >> Requirement Levels, BCP 14, RFC 2119, March 1997 >> >> [RFC3758] Stewart, R., Ramalho, M, Xie, Q., Tuexen, M., and P. >> Conrad, "Stream Control Transmission Protocol (SCTP), >> Partial Reliability Extension", May 2004 >> >> [RFC4960] Stewart, R., Ed., "Stream Control Transmission >> Protocol", RFC 4960, September 2007. >> >> [RFC5101] Claise, B., Ed., "Specification of the IP Flow >> Information Export (IPFIX) Protocol for the Exchange of >> IP Traffic Flow Information", RFC 5101, January 2008. >> >> [RFC5102] Quittek, J., Bryant, S., Claise, B., Aitken, P., and >> J. Meyer, "Information Model for IP Flow Information >> Export", RFC 5102, January 2008. >> >> >> Expires January 6, 2012 [Page 27] >> >> Internet-Draft July 2011 >> >> >> >> [RFC5655] Trammell, B., Boschi, E., Mark, L., Zseby, T., and A. >> Wagner, "Specification of the IP Flow Information >> Export (IPFIX) File Format", RFC 5655, October 2009. >> >> [RFC5815] Dietz, T., Kobayashi, A., Claise, B., and G. Muenz, >> "Definitions of Managed Objects for IP Flow Information >> Export", RFC 5815, April 2010. >> >> [IPFIX-MED-FLOWSEL] D'antonio, S., Zseby, T., Henke, C. and L. >> Peluso, "Flow Selection Techniques", draft-ietf-ipfix- >> flow-selection-tech-06.txt, Internet-Draft work in >> progress, May 2011. >> >> [IPFIX-MED-AGGR] Trammell, B., Boschi, E., A. Wagner, and B. >> Claise, "Exporting Aggregated Flow Data using the IP >> Flow Information Export (IPFIX) Protocol", draft- >> trammell-ipfix-a9n-03.txt, Internet-Draft work in >> progress, June 2011. >> >> [IPFIX-STRUCT] Claise, B., Dhandapani, G., Aitken, P., and S. >> Yates, "Export of Structured Data in IPFIX", draft- >> ietf-ipfix-structured-data-06.txt, Internet-Draft work >> in progress, May 2011. >> >> [PSAMP-MIB] Dietz, T., Claise, B., and J. Quittek "Definitions >> of Managed Objects for Packet Sampling", draft-ietf- >> ipfix-psamp-mib-03.txt, Internet-Draft work in >> progress, March 2011. >> >> [IPFIX-CONF] Muenz, G., Claise, B., and P. Aitken "Configuration >> Data Model for IPFIX and PSAMP", draft-ietf-ipfix- >> configuration-model-09, Internet-Draft work in >> progress, March 2011. >> >> >> >> 7.2. Informative References >> >> >> [TCP] Postel, J., "Transmission Control Protocol", STD 7, RFC >> 793, September 1981. >> >> [UDP] Postel, J., "User Datagram Protocol", STD 6, RFC 768, >> August 1980. > > See earlier point: for consistency, you should reference these by > their RFC numbers, ie "[RFC793]" and "[RFC768]". Done. > > >> >> >> >> >> Expires January 6, 2012 [Page 28] >> >> Internet-Draft July 2011 >> >> >> [RFC3917] Quittek, J., Zseby, T., Claise, B., and S. Zander, >> "Requirements for IP Flow Information Export", RFC >> 3917, October 2004 >> >> [RFC3954] Claise, B. (Ed), "Cisco Systems NetFlow Services >> Export Version 9", RFC 3954, October 2004 >> >> [RFC5470] Sadasivan, G., Brownlee, N., Claise, B., and J. >> Quittek, "Architecture Model for IP Flow Information >> Export", RFC5470, March 2009 >> >> [RFC5472] Zseby, T., Boschi, E., Brownlee, N., and B. Claise, >> "IP Flow Information Export (IPFIX) Applicability", RFC >> 5472, March 2009 >> >> [RFC5476] Claise, B., Quittek, J., and A. Johnson, "Packet >> Sampling (PSAMP) Protocol Specifications", RFC 5476, >> March 2009. >> >> [RFC5982] Kobayashi, A. (Ed), Claise, B. (Ed), "P Flow >> Information Export (IPFIX) Mediation: Problem >> Statement", RFC 5982, August 2010. >> >> [IPFIX-MED-FMWK] Kobayashi, A., Claise, B., Muenz, G., and K. >> Ishibashi, "IPFIX Mediation: Framework", RFC 6183, >> April 2011. >> >> [RFC6235] Boschi, E., Trammell, B. "IP Flow Anonymization >> Support", RFC 6235, May 2011. >> >> [IANA-IPFIX]http://www.iana.org/assignments/ipfix/ipfix.xhtml >> >> >> 8. Author's Addresses >> >> Benoit Claise >> Cisco Systems, Inc. >> De Kleetlaan 6a b1 >> Diegem 1813 >> Belgium >> >> Phone: +32 2 704 5622 >> Email:bclaise@cisco.com >> >> >> Atsushi Kobayashi >> NTT Information Sharing Platform Laboratories >> >> >> Expires January 6, 2012 [Page 29] >> >> Internet-Draft July 2011 >> >> >> 3-9-11 Midori-cho >> Musashino-shi, Tokyo 180-8585 >> Japan >> >> Phone: +81-422-59-3978 >> Email:akoba@nttv6.net >> URI:http://www3.plala.or.jp/akoba/ >> >> >> Brian Trammell >> ETH Zurich >> Gloriastrasse 35 >> 8092 Zurich >> Switzerland >> >> Phone: +41 44 632 70 13 >> EMail:trammell@tik.ee.ethz.ch >> >> 9.Appendix A. Additions to XML Specification of IPFIX >> Information Elements > > s/9. Appendix A/Appendix A/ Done. Many thanks again. Impressive feedback. Regards, Benoit. > > >> This appendix contains additions to the machine-readable >> description of the IPFIX information model coded in XML in >> Appendix A and Appendix B in [RFC5102]. Note that this appendix >> is of informational nature, while the text in Section 6. >> (generated from this appendix) is normative. >> >> The following field definitions are appended to the IPFIX >> information model in Appendix A of [RFC5102]. >> >> > dataType="ipv4Address" >> group="config" >> elementId="TBD1" applicability="all" status="current"> >> >> >> The IPv4 address used by the Exporting Process on the >> Original Exporter. This is used by an IPFIX Mediator >> Exporting Process to identify the Original Exporter. >> >> >> >> >> >> > dataType="ipv6Address" >> group="config" >> >> >> Expires January 6, 2012 [Page 30] >> >> Internet-Draft July 2011 >> >> >> elementId="TBD2" applicability="all" status="current"> >> >> >> The IPv6 address used by the Exporting Process on the >> Original Exporter. This is used by the IPFIX Mediator >> Exporting Process to identify the Original Exporter. >> >> >> >> >> > dataType="unsigned32" >> group="config" >> elementId="TBD3" applicability="all" status="current"> >> >> >> An identifier of the Observation Domain on the Original >> Exporter, where the metered IP packets are observed. >> This is used by the IPFIX Mediator Exporting Process to >> identify an Observation Domain as received from the >> Original Exporter. >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> Expires January 6, 2012 [Page 31] >> >> --------------020200020803060909050804 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Hi Paul,

As explained during the IETF, we overlooked this email. Sorry again.
What I like about your reviews is that it's always a WG last call level of review. So very detailed. Many thanks.

See inline.
Dear Authors,

Please find a review of draft-claise-ipfix-mediation-protocol-04.

Thanks,
P.


     IPFIX Working Group                                    B. Claise 
     Internet-Draft                               Cisco Systems, Inc. 
     Intended Status: Standards Track                    A. Kobayashi 
     Expires: January 7, 2012                             NTT PF Lab.   
                                                          B. Trammell 
                                                           ETH Zurich 
                                                         July 7, 2011 
                                                                      
      
            Specification of the Protocol for IPFIX Mediations

s/Mediations/Mediation/
Done.


                 draft-claise-ipfix-mediation-protocol-04 


     Abstract 

        This document specifies the IP Flow Information Export 
        (IPFIX) protocol specific to the Mediation.

Consider "specific to Mediation."
Done.
or "for Mediation [devices].".


         
     Status of this Memo 

        This Internet-Draft is submitted to IETF in full conformance 
        with the provisions of BCP 78 and BCP 79.  
         
        Internet-Drafts are working documents of the Internet 
        Engineering Task Force (IETF), its areas, and its working 
        groups.  Note that other groups may also distribute working 
        documents as Internet-Drafts.  
         
        Internet-Drafts are draft documents valid for a maximum of six 
        months and may be updated, replaced, or obsoleted by other 
        documents at any time.  It is inappropriate to use Internet-
        Drafts as reference material or to cite them other than as "work 
        in progress."  
         
        The list of current Internet-Drafts can be accessed at 
        http://www.ietf.org/ietf/1id-abstracts.txt  
         
        The list of Internet-Draft Shadow Directories can be accessed at 
        http://www.ietf.org/shadow.html  
         
        This Internet-Draft will expire on April, 2011. 
         
         
     Copyright Notice 
      
        Copyright (c) 2011 IETF Trust and the persons identified as the 
        document authors.  All rights reserved. 
         
        This document is subject to BCP 78 and the IETF Trust's Legal 
        Provisions Relating to IETF Documents 
        (http://trustee.ietf.org/license-info) in effect on the date of 
        publication of this document.  Please review these documents 
      
     <Claise, et. Al>        Expires January 7 2012            [Page 1] 
     Internet-Draft     <Protocol for IPFIX Mediations>      July 2011 
         

        carefully, as they describe your rights and restrictions with 
        respect to this document.  Code Components extracted from this 
        document must include Simplified BSD License text as described 
        in Section 4.e of the Trust Legal Provisions and are provided 
        without warranty as described in the Simplified BSD License. 
         
         
     Conventions used in this document 

        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 [RFC2119]. 
      

     Table of Contents 

         
        1. Introduction............................................ 3 
           1.1. IPFIX Documents Overview........................... 4 
           1.2. IPFIX Mediator Documents Overview.................. 4 
           1.3. Relationship with IPFIX and PSAMP.................. 5 
        2. Terminology............................................. 6 
        3. Specifications.......................................... 9 
           3.1. Encoding of IPFIX Message Header.................. 10 
           3.2. Template Management............................... 11 
              3.2.1. Template Management Without Template Records 
                     Change........................................11 
              3.2.2. Template Management With New Template Records 14 
           3.3. Time Management................................... 18 
           3.4. Observation Point Management...................... 19 
              3.4.1. Observation Domain Management................ 21 
           3.5. Specific Reporting Requirements................... 22 
              3.5.1. The Flow Keys Options Template............... 22 
              3.5.2. IPFIX Protocol Options Template.............. 22 
              3.5.3. IPFIX Mediator Options Template.............. 23 
           3.6. The Collecting Process's Side..................... 24 
           3.7. Configuration Management.......................... 24 
        4. New Information Elements............................... 24 
           4.1. - originalExporterIPv4Address..................... 24 
           4.2. originalExporterIPv6Address....................... 25 
           4.3. originalObservationDomainId....................... 25 
        5. Security Considerations................................ 25 
        6. IANA Considerations.................................... 26 
           6.1. originalExporterIPv4Address....................... 26 
           6.2. originalExporterIPv6Address....................... 27 
           6.3. originalObservationDomainId....................... 27 
        7. References............................................. 27 
      
      
     <Claise, et. Al>       Expires January 6, 2012           [Page 2] 
         
     Internet-Draft     <Protocol for IPFIX Mediations>      July 2011 
         

           7.1. Normative References.............................. 27 
           7.2. Informative References............................ 28 
        8. Author's Addresses..................................... 29 
        9. Appendix A.  Additions to XML Specification of IPFIX 
        Information Elements...................................... 30 
         
         
     1. Introduction 

        The IPFIX architectural components in [RFC5470] consist of 
        IPFIX Devices and IPFIX Collectors communicating using the 
        IPFIX protocol [RFC5101], which specifies how to export IP 
        Flow information.  This protocol is designed to export 
        information about IP traffic Flows and related measurement 
        data, where a Flow is defined by a set of key attributes 
        (e.g. source and destination IP address, source and 
        destination port, etc.).  
         
        However, thanks to its Template mechanism, the IPFIX protocol 
        can export any type of information, as long as the relevant 
        Information Element is specified in the IPFIX Information 
        Model [RFC5102], registered with IANA, or specified as an 
        enterprise-specific Information Element.  The specifications 
        in the IPFIX protocol [RFC5101] have not been defined in the 
        context of an IPFIX Mediator receiving, aggregating, 
        correlating, anonymizing, etc... Flow Records from the one or 
        multiple Exporters.  Indeed, the IPFIX protocol must be 
        adapted for Intermediate Processes, as defined in the IPFIX 
        Mediation Reference Model as specified in the Figure A of

d/the/
Done.


        [IPFIX-MED-FMWK], which is based on the IPFIX Mediation 
        Problem Statement [RFC5982]. 
         
        This document specifies the IP Flow Information Export 
        (IPFIX) protocol in the context of the implementation and 
        deployment of IPFIX Mediators.  The use of the IPFIX 
        protocol within a Mediator -- a device which contains both 
        as an Exporting Process and a Collecting Process -- has an

This is back to front, since a mediator collects before it exports.
Done.


        impact on the technical details of the usage of the 
        protocol.  An overview of the technical problem is covered 
        in section 6 of the [RFC5982]: loss of original exporter

Either remove "the",
Done.
or say "the IPFIX Mediation Problem Statement".


        information, loss of base time information, transport 
        sessions management, loss of Options Template Information, 
        Template Id management, considerations for network topology, 
        and IPFIX Mediation interpretation, and considerations for 
        aggregation.

Remove the first "and".
Done.


         

      
      
     <Claise, et. Al>       Expires January 6, 2012           [Page 3] 
         
     Internet-Draft     <Protocol for IPFIX Mediations>      July 2011 
         

        The specifications in this document are based on the IPFIX 
        protocol specifications [ref] but adapted according to the IPFIX 
        Mediation Framework [IPFIX-MED-FMWK].

Please add the missing reference.
Done.


      
      
     1.1. IPFIX Documents Overview 

        The IPFIX Protocol [RFC5101] provides network administrators 
        with access to IP Flow information. 
         
        The architecture for the export of measured IP Flow 
        information out of an IPFIX Exporting Process to a Collecting 
        Process is defined in the IPFIX Architecture [RFC5470], per 
        the requirements defined in RFC 3917 [RFC3917].

While I appreciate that this is probably cut-n-pasted from another IPFIX doc, it would be better to say, "per the requirements defined in the IPFIX Requirements doc, [RFC3917]."
Done.

        The IPFIX Architecture [RFC5470] specifies how IPFIX Data 
        Records and Templates are carried via a congestion-aware 
        transport protocol from IPFIX Exporting Processes to IPFIX 
        Collecting Processes. 
         
        IPFIX has a formal description of IPFIX Information Elements, 
        their name, type and additional semantic information, as 
        specified in the IPFIX Information Model [RFC5102].   
         
        The IPFIX Applicability Statement [RFC5472] describes what 
        type of applications can use the IPFIX protocol and how they 
        can use the information provided.  It furthermore shows how 
        the IPFIX framework relates to other architectures and 
        frameworks.  
         
        "IPFIX Mediation: Problem Statement" [RFC5982], describing the 
        IPFIX Mediation applicability examples, along with some problems 
        that network administrators have been facing, is the basis for 
        the "IPFIX Mediation: Framework" [IPFIX-MED-FMWK].  This 
        framework details the IPFIX Mediation reference model and the 
        components of an IPFIX Mediator. 
              
      
     1.2. IPFIX Mediator Documents Overview 

        The "IPFIX Mediation: Problem Statement" [RFC5982] provides an 
        overview of the applicability of Mediators, and defines 
        requirements for Mediators in general terms.  This document is 
        of use largely to define the problems to be solved through the 
        deployment of IPFIX Mediators, and to provide scope to the role 
        of Mediators within an IPFIX collection infrastructure.   
         
      
      
     <Claise, et. Al>       Expires January 6, 2012           [Page 4] 
         
     Internet-Draft     <Protocol for IPFIX Mediations>      July 2011 
         

        The "IPFIX Mediation: Framework" [IPFIX-MED-FMWK] provides more 
        architectural details of the arrangement of Intermediate 
        Processes within a Mediator. 
      
        The details of specific Intermediate Processes, when these have 
        additional export specifications (e.g., metadata about the 
        intermediate processing conveyed through IPFIX Options 
        Templates), are each treated in their own document (e.g., the 
        "IP Flow Anonymization Support" [RFC6235]).  Documents 
        specifying the operations of specific Intermediate Processes 
        cover the operation of these Processes within the Mediator 
        framework, and complying to the specifications given in this

"comply with"
Done.


        document; they may additionally specify the operation of the 
        process independently, outside the context of a Mediator, when 
        this is appropriate.  As of today, these documents are:  
         
        1. "IP Flow Anonymization Support", [RFC6235], which describes 
        Anonymization techniques for IP flow data and the export of 
        Anonymized data using the IPFIX protocol.  
         
        2. "Flow Selection Techniques" [IPFIX-MED-FLOWSEL], which 
        described the process of selecting a subset of flows from all

"describes".
Done.


        flows observed at an observation point, along with the 
        motivations, and some specific flow selection techniques.

"motivations"... for what?
NEW:
"Flow Selection Techniques" [IPFIX-MED-FLOWSEL], which describes the process of selecting a subset of flows from all flows observed at an observation point, the flow selection motivations, and some specific flow selection techniques.


         
        3. "Exporting Aggregated Flow Data using the IP Flow Information 
        Export" [IPFIX-MED-AGGR] which describes Aggregated Flow export 
        within the framework of IPFIX Mediators and defines an 
        interoperable, implementation-independent method for Aggregated 
        Flow export.
Added (to cover the next comment)

This document specifies the IP Flow Information Export (IPFIX) protocol specific to Mediation, i.e. the specifications that all Intermediate Processes type must comply to.  Some extra specifications might be required per Intermediate Process type (In which case, the Intermediate Process specific document would cover those).


         
     1.3. Relationship with IPFIX and PSAMP 

        The specification in this document applies to the IPFIX 
        protocol specifications [RFC5101].  All specifications from 
        [RFC5101] apply unless specified otherwise in this document. 
      
        As the Packet Sampling (PSAMP) protocol specifications 
        [RFC5476] are based on the IPFIX protocol specifications, the 
        specifications in this document are also valid for the PSAMP 
        protocol.  Therefore, the method specified by this document 
        also applies to PSAMP.

Having read all this, it's not clear to me where the current document fits in to the structure.

See above.

         
         



      
      
     <Claise, et. Al>       Expires January 6, 2012           [Page 5] 
         
     Internet-Draft     <Protocol for IPFIX Mediations>      July 2011 
         

     2. Terminology 

        The IPFIX-specific terms, such as Observation Domain, Flow, Flow 
        Key, Metering Process, Exporting Process, Exporter, IPFIX 
        Device, Collecting Process, Collector, Template, IPFIX Message, 
        Message Header, Template Record, Data Record, Options Template 
        Record, Set, Data Set, Information Element, and Transport 
        Session, used in this document are defined in [RFC5101].  
        The PSAMP-specific terms used in this document, such as 
        Filtering and Sampling are defined in [RFC5476].  
         
        The IPFIX Mediation terms related to the aggregation, such as 
        the Interval, Aggregated Flow, and Aggregated Fonction are

s/Fonction/Function/
Done.


        defined in [IPFIX-MED-AGGR]. 
         
        The IPFIX Mediation-specific terminology used in this document 
        is defined in "IPFIX Mediation: Problem Statement" [RFC5982], 
        and reuse in "IPFIX Mediation: Framework" [IPFIX-MED-FMWK].

s/reuse/reused/
Done.


        However, since those two documents are an informational RFC, the

"since both of those documents are informational RFCs"
Done.


        definitions have been reproduced here along with additional 
        definitions.   
         
        Similarly, since the [RFC6235] is an experimental RFC, the

Either remove "the", or say "IP Flow Anonymization Support".
Done.


        Anonymization Record, Anonymized Data Record, and Intermediate 
        Anonymization Process terms, specified in [RFC6235], are also 
        reproduced here. 
      
        In this document, as in [RFC5101], [RFC5476], [IPFIX-MED-AGGR , 
        and [RFC6235], the first letter of each IPFIX-specific and 
        PSAMP-specific term is capitalized along with the IPFIX 
        Mediation-specific term defined here.  In this document, we call 
        "record stream" a stream of records carrying flow- or packet-
        based information.  The records may be encoded as IPFIX Data

This is back to front: "In this document, we call a stream of records carrying flow- or packet-based information a "record stream".

Done.

        Records in any other format.

"Records, or"
Done.


The indentation of the following sections is inconsistent.
The reason is that we start the definitions, which are indented


         
        Transport Session Information 
         
         The Transport Session is specified in [RFC5101].  In SCTP, the 
         Transport Session Information is the SCTP association.  In TCP 
         and UDP, the Transport Session Information corresponds to a 5-
         tuple {Exporter IP address, Collector IP address, Exporter 
         transport port, Collector transport port, transport protocol}. 
         
        Original Exporter 
         
          An Original Exporter is an IPFIX Device that hosts the  
          Observation Points where the metered IP packets are observed. 
      
      
     <Claise, et. Al>       Expires January 6, 2012           [Page 6] 
         
     Internet-Draft     <Protocol for IPFIX Mediations>      July 2011 
         

           
        Original Observation Point 
         
         An Observation Point of the Original Exporter(s).  In the case 
         of the Intermediate Aggregation Process on an IPFIX Mediator, 
         the Original Observation Point can be composed of a (set of) 
         specific exporter(s), a (set of) specific interface(s) on an 
         Exporter, a (set of) line card(s) on an Exporter, or any 
         combinations of these.

This sounds like a limiting definition - in which case, please use some 2119 language.
If it's just by way of example, then please say so. eg,  "can be composed of, but not limited to, ...".
Done.
Or append, "this is not an exhaustive list."

Also, you assume that the OPs are on the Exporter, which isn't necessarily correct. First, you mean "Original Exporter".
Done.
Second, the OPs are somewhere near the MP, which may be remote from the Exporter. eg, the OPs and MP are on a linecard, while the EP is on an RP.
Or with metered data stored in a file then replayed to a mediator, the OPs may be quite remote from the EP.
This Original Observation Point definition is based on the Original Exporter definition (An Original Exporter is an IPFIX Device that hosts the Observation Points where the metered IP packets are observed), so isn't it consistent? 


      
        IPFIX Mediation 
         
          IPFIX Mediation is the manipulation and conversion of a record 
          stream for subsequent export using the IPFIX protocol. 
         
        The following terms are used in this document to describe the 
        architectural entities used by IPFIX Mediation. 
         
        Intermediate Process 
         
          An Intermediate Process takes a record stream as its input 
          from Collecting Processes, Metering Processes, IPFIX File 
          Readers, other Intermediate Processes, or other record 
          sources; performs some transformations on this stream, based

"Some" requires > 1. Consider "one or more".
Cut and paste from RFC 6183. Listed as an open issue


          upon the content of each record, states maintained across 
          multiple records, or other data sources; and passes the

So a mediator can't do random sampling?
Question: isn't it covered by "states maintained across multiple records", i.e. I want to select one random record across 100 ones.
The states would be something such as:
    total number of records the IMP has seen, modulo 100
    whether or not one has record has been selected already for the last interval


          transformed record stream as its output to Exporting 
          Processes, IPFIX File Writers, or other Intermediate 
          Processes, in order to perform IPFIX Mediation. Typically, an

It sounds like it's passing the output to these consumers for them to perform Mediation.
I don't think think this is what you meant. Consider moving this clause to the top:
"In order to perform IPFIX Mediation, an Intermediate Process takes a record stream..."
Cut and paste from RFC 6183. Listed as an open issue 


          Intermediate Process is hosted by an IPFIX Mediator.

Define "IPFIX Mediator". eg, next under "IPFIX Mediation", "IPFIX Mediator: A device which performs IPFIX mediation. An IPFIX Mediator contains both a Collecting Process and an Exporting Process".
[Later] OK, you did define this... far too far down below.
Moved here.


          Alternatively, an Intermediate Process may be hosted by an 
          Original Exporter. 
         
        Specific Intermediate Processes are described below.  However, 
        this is not an exhaustive list.

Please indent the following list a bit more, so it's clear where the list ends and other definitions continue.
Done.


         
        Intermediate Conversion Process 
         
          An Intermediate Conversion Process is an Intermediate Process 
          that transforms non-IPFIX into IPFIX, or manages the relation

What about IPFIX into non-IPFIX (eg, NFv9, Nfv5) ?

"relationship"
Cut and paste from RFC 6183. Listed as an open issue 


          among Templates and states of incoming/outgoing Transport 
          Sessions (or equivalent for non IPFIX protocols) in the case 
          of transport protocol conversion (e.g., from UDP to SCTP). 
         
        Intermediate Aggregation Process 
         

      
      
     <Claise, et. Al>       Expires January 6, 2012           [Page 7] 
         
     Internet-Draft     <Protocol for IPFIX Mediations>      July 2011 
         

          An Intermediate Aggregation Process is an Intermediate Process 
          that aggregates records based upon a set of Flow Keys or 
          functions applied to fields from the record (e.g., binning and 
          subnet aggregation). 
         
        Intermediate Correlation Process 
         
          An Intermediate Correlation Process is an Intermediate Process 
          that adds information to records, noting correlations among 
          them, or generates new records with correlated data from 
          multiple records (e.g., the production of bidirectional flow 
          records from unidirectional flow records). 
         
        Intermediate Selection Process 
         
          An Intermediate Selection Process is an Intermediate Process 
          that selects records from a sequence based upon criteria-

What is "a sequence" ?
Listed as an open issue


          evaluated record values and passes only those records that 
          match the criteria (e.g., Filtering only records from a given 
          network to a given Collector). 
         
        Intermediate Anonymization Process 
         
          An Intermediate Anonymization Process is an Intermediate 
          Process that transforms records in order to anonymize them, to 
          protect the identity of the entities described by the records 
          (e.g., by applying prefix-preserving pseudonymization of IP 
          addresses).

Consider giving a reference here.
Listed as an open issue 


         
        IPFIX Mediator 
         
          An IPFIX Mediator is an IPFIX Device that provides IPFIX 
          Mediation by receiving a record stream from some data sources,

"Some" is > 1. "One or more" seems sufficient.
Listed as an open issue 


          hosting one or more Intermediate Processes to transform that 
          stream, and exporting the transformed record stream into IPFIX

s/into/in/
Listed as an open issue 


          Messages via an Exporting Process.  In the common case, an

Can't it write to a file too?
Listed as an open issue 


          IPFIX Mediator receives a record stream from a Collecting 
          Process, but it could also receive a record stream from data 
          sources not encoded using IPFIX, e.g., in the case of 
          conversion from the NetFlow V9 protocol [RFC3954] to IPFIX 
          protocol.

Great. Say this stuff WAY up at the top.
Moved just after the Intermediate Process


           
        Template Mapping 
         
         A mapping from Template Records and/or Options Template 
         Records received by a Mediator to Template Records and/or 
         Options Template Records sent by that IPFIX Mediator.  Each 
      
      
     <Claise, et. Al>       Expires January 6, 2012           [Page 8] 
         
     Internet-Draft     <Protocol for IPFIX Mediations>      July 2011 
         

         entry in a Template Mapping is scoped by incoming or outgoing 
         Transport Session and Observation Domain, as with Templates 
         and Options Templates in the IPFIX Protocol. 
           
        Anonymization Record    
         
         A record, defined by the Anonymization Options Template in 
         section Section 6.1, that defines the properties of the

Oops.
Done.


         Anonymization applied to a single Information Element within a 
         single Template or Options Template. 
         
        Anonymized Data Record    
         
         A Data Record within a Data Set containing at least one 
         Information Element with Anonymized values.  The Information 
         Element(s) within the Template or Options Template describing 
         this Data Record SHOULD have a corresponding Anonymization 
         Record. 
      
      
     3. Specifications 

        This section describes the IPFIX specifications for Mediation:   
        more specifically,  specifications for generic Intermediate 
        Processes.  Possible specific Intermediate Processes are: 
        Intermediate Conversion Process, Intermediate Aggregation 
        Process, Intermediate Correlation Process, Intermediate 
        Selection Process, Intermediate Anonymization Process.

Is this a definitive and exhaustive list? Earlier you said it wasn't.
We wrote: "Possible specific Intermediate Processes are:"
Do you need something else?


         
        For a specific Intermediate Process, the specifications in the 
        following reference MUST be followed, on the top of the 
        specifications in this document:

"references".

Remove "the".
Done


       - For the Intermediate Aggregation Process, the specifications 
          in [IPFIX-MED-AGGR] MUST be followed. 
       - For the Intermediate Selection Process, the specifications in 
          [IPFIX-MED-FLOWSEL] MUST be followed.  
       - For the Intermediate Anonymization Process, the specifications 
          in [RFC6235] should be considered as guidelines as [RFC6235] 
          is an experimental RFC. 
       Note that no specific document deals with the Intermediate 
       Conversion Process at the time of this publication.

Then where should this be specified?
Question: In a new document (which is not part of the current charter). Do we need to mention that?


        
        These new specifications, which are more specific compared to

s/compared to/than/
done


        [RFC5101], are described with the key words described in 
        [RFC2119].  
         

      
      
     <Claise, et. Al>       Expires January 6, 2012           [Page 9] 
         
     Internet-Draft     <Protocol for IPFIX Mediations>      July 2011 
         

     3.1. Encoding of IPFIX Message Header 

        The format of the IPFIX Message Header is shown in Figure A. 
        Note that the format is similar to the IPFIX Message in 
        [RFC5101], but some field definitions (for the example, the 
        Export Time) have been updated in the context of the IPFIX 
        Mediator.  
         

        0                   1                   2                   3 
        0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
       |       Version Number          |            Length             | 
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
       |                           Export Time                         | 
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
       |                       Sequence Number                         | 
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
       |                    Observation Domain ID                      | 
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
         

                      Figure A: IPFIX Message Header format 

         
        Message Header Field Descriptions  
         
        Version 

                Version of Flow Record format exported in this message.  
                The value of this field is 0x000a for the current 
                version, incrementing by one the version used in the 
                NetFlow services export version 9 [RFC3954]. 

        Length 

                Total length of the IPFIX Message, measured in octets, 
                including Message Header and Set(s). 

        Export Time 

                Time in seconds since 0000 UTC Jan 1st 1970, at which 
                the IPFIX Message Header leaves the IPFIX Mediator.

We're leave a legacy year-2106 problem :-(
Solved


        Sequence Number 

      
      
     <Claise, et. Al>       Expires January 6, 2012          [Page 10] 
         
     Internet-Draft     <Protocol for IPFIX Mediations>      July 2011 
         

                Incremental sequence counter modulo 2^32 of all IPFIX 
                Data Records sent on this PR-SCTP stream from the

Where did you say we're using pr-SCTP?
If I'm not, then this definition doesn't apply?
This is a cut/paste from RFC5101.


                current Observation Domain by the Exporting Process.  
                Check the specific meaning of this field in the sub-
                sections of section 10 when UDP or TCP is selected as

You don't have a section 10. You mean, "section 10 of [RFC5101]".
Yes and no

I get the feeling I'm the first to actually read this :-(

This would refer to RFC5101, except that now we have to refer to RFC5101bis.
So I put a RFC's editor note as we have multiple evolving documents
[Later] Yes, very much so.
Btw, we really appreciate your thorough review. 


                the transport protocol.  This value SHOULD be used by 
                the Collecting Process to identify whether any IPFIX 
                Data Records have been missed.  Template and Options 
                Template Records do not increase the Sequence Number. 
                 
        Observation Domain ID 

                A 32-bit identifier of the Observation Domain that is 
                locally unique to the Exporting Process.  The Exporting 
                Process uses the Observation Domain ID to uniquely 
                identify to the Collecting Process the Observation 
                Domain that metered the Flows.  It is RECOMMENDED that 
                this identifier is also unique per IPFIX 
                Device.  Collecting Processes SHOULD use the Transport 
                Session and the Observation Domain ID field to separate 
                different export streams originating from the same 
                Exporting Process.  The Observation Domain ID SHOULD be 
                0 when no specific Observation Domain ID is relevant for 
                the entire IPFIX Message.  For example, when exporting 
                the Exporting Process Statistics, or in case of 
                hierarchy of Collector when aggregated Data Records are 
                exported.   
                Note: the Observation Domain Management is discussed in 
                section 3.4.1.   
      

     3.2. Template Management 

     3.2.1. Template Management Without Template Records Change 

        The first case is a situation where the IPFIX Mediator doesn't 
        modify the (Options) Template Record(s) content.  A typical 
        example is an Intermediate Selection Process acting as 
        distributor, which collects Flow Records from one or multiple

s/multiple/more/
Done.


        Exporters, and based on the Information Elements content, 
        redirects the Flow Records to the appropriate Collector.  This 
        example is a typical case of a single network operation center 
        managing multiple universities: an unique IPFIX Collector 
        collects all Flow Records for the common infrastructure, but 
        might be re-exporting specific university Flow Records to the 
        responsible system administrator. 
         
      
      
     <Claise, et. Al>       Expires January 6, 2012          [Page 11] 
         
     Internet-Draft     <Protocol for IPFIX Mediations>      July 2011 
         

        As specified in [RFC5101], the Template IDs are unique per 
        Exporter, per Transport Session, and per Observation Domain.  As 
        there is no guarantee that, for similar Template Records, the 
        Template IDs received on the incoming Transport Session and 
        exported to the outgoing Transport Session would be same, the 
        IPFIX Mediator MUST maintain a Template Mapping composed of 
        similar received and exported (Options) Template Records:

s/similar/related/
done.


        - for each received (Options) Template Record: Template Record 
          Flow Keys and non Flow Keys, Template ID, Observation Domain 
          Id, and Transport Session Information 
        - for each exported (Options) Template Record: Template Record 
          Flow Keys and non Flow Keys, Template ID, Collector, 
          Observation Domain Id, and Transport Session Information 
         
        If an IPFIX Mediator receives an IPFIX Withdrawal Message for a 
        (Options) Template Record that is not used anymore in any 
        outgoing Transport Sessions, the IPFIX Mediator SHOULD export 
        the appropriate IPFIX Withdrawal Message(s) on the outgoing 
        Transport Session, and remove the corresponding entry in the 
        Template Mapping.

- assuming it's a 1:1 mapping. As an optimisation, the mediator could resolve identical incoming templates (which may differ in their template ID, observation domain, and perhaps in the order of their fields) into a single outgoing template in an n:1 mapping. i.e. the basic information content is the same. I hope you mention this somewhere in the draft. e.g., in figure C below, templates A and B may be identical. With the same software version and configuration on multiple boxes, this is a likely real-world scenario.
Good catch.
OLD:
        If an IPFIX Mediator receives an IPFIX Withdrawal Message for a 
        (Options) Template Record that is not used anymore in any 
        outgoing Transport Sessions, the IPFIX Mediator SHOULD export 
        the appropriate IPFIX Withdrawal Message(s) on the outgoing 
        Transport Session, and remove the corresponding entry in the 
        Template Mapping.
NEW
If an IPFIX Mediator receives an IPFIX Withdrawal Message for a 
(Options) Template Record that is not used anymore in any 
other Template Mappings, the IPFIX Mediator SHOULD export the 
appropriate IPFIX Withdrawal Message(s) on the outgoing Transport Session,
and remove the corresponding entry in the Template Mapping.



In this case, the TWM should cause the mediator to remove the received (Options) Template Record information, and decrement the exported (Options) Template Record refcount by 1 but only delete it if it's no longer used by anyone.
Yes. I believe it's now covered by "any other Template Mappings"


         
        If a (Options) Template Record is not used anymore in an 
        outgoing Transport Session, it MUST be withdrawn with an IPFIX 
        Template Withdrawal Message on that specific outgoing Transport 
        Session, and its entry MUST be removed from the Template 
        Mapping. 
         
        If an incoming or outgoing Transport Session is gracefully 
        shutdown or reset, the (Options) Template Records corresponding 
        to that Transport Session MUST be removed from the Template 
        Mapping.

There's a rather sudden change here. Link the two sections with "For example, Figure B ..."
Done.

         
        Figure B displays an example of an Intermediate Selection 
        Process, re-distributing Data Records to Collectors on the basis

The figure's caption says, "Intermediate Aggregation Process Example". Which is it, selection or aggregation?
Intermediate Selection Process. Corrected. 


        of the customer networks, i.e. the Route Distinguisher (RD).  In

d/the/
Done.


        this example, the Template Record received from the Exporter#1 
        is reused towards the Collector#1, Collector#2, and Collector#3.

d/the/
Done.


      
         
                                         Templ. .---------. 
                                         ID 256 |         | 
                                          .---->|Collector|<==>Customer 
                                          |     |#1       |    #A 
                                          |     |         | 
                                       RD=100:1 '---------' 
        .---------.Templ.  .---------.    | 
        |         |Id      |         |----'     .---------. 
      
      
     <Claise, et. Al>       Expires January 6, 2012          [Page 12] 
         
     Internet-Draft     <Protocol for IPFIX Mediations>      July 2011 
         

        |         |258     |         | RD=100:2 |         | 
        |IPFIX    |------->|IPFIX    |--------->|Collector|<==>Customer 
        |Exporter |        |Mediator | Templ.   |#2       |    #B 
        |#1       |        |         | ID 257   |         | 
        |         |        |         |----.     '---------' 
        '---------'        '---------'    |  
                                         RD=100:3 
                                    Templ.|     .---------. 
                                    ID    |     |         | 
                                    257   '---->|Collector|<==>Customer 
                                                |#3       |    #C 
                                                |         | 
                                                '---------' 
      
             Figure B: Intermediate Aggregation Process Example

Introduce the following tables. Presumably, "The following table shows the Template Mapping for the system shown in Figure B."
Done.


        Template Entry A: 
         Incoming Transport Session Information (from Exporter#1): 
           Source IP: <Exporter#1 export IP address> 
           Destination IP: <IPFIX Mediator IP address> 
           Protocol: SCTP 
           Source Port: <source port> 
           Destination Port: 4739 (IPFIX) 
         Observation Domain Id: <Observation Domain ID> 
         Template Id: 258        
           Flow Keys: <series of Flow Keys> 
           Non Flow Keys: <series of non Flow Keys>

Would it be clearer to write example values in the Figure?
I've not been able to find without overloading the picture.


                                                                    
        Template Entry B: 
         Outgoing Transport Session Information (to Collector#1): 
           Source IP: <IPFIX Mediator IP address> 
           Destination IP: <IPFIX Collector#1 IP address> 
           Protocol: SCTP 
           Source Port: <source port> 
           Destination Port: 4739 (IPFIX)  
         Observation Domain Id: <Observation Domain ID>   
         Template Id: 256    
           Flow Keys: <series of Flow Keys>  
           Non Flow Keys: <series of non Flow Keys> 
                
        Template Entry C: 
         Outgoing Transport Session Information (to Collector#2): 
           Source IP: <IPFIX Mediator IP address> 
           Destination IP: <IPFIX Collector#2 IP address> 
           Protocol: SCTP 
           Source Port: <source port>   
      
      
     <Claise, et. Al>       Expires January 6, 2012          [Page 13] 
         
     Internet-Draft     <Protocol for IPFIX Mediations>      July 2011 
         

           Destination Port: 4739 (IPFIX) 
         Observation Domain Id: <Observation Domain ID> 
         Template Id: 257 
           Flow Keys: <series of Flow Keys> 
           Non Flow Keys: <series of non Flow Keys> 
                                                                
        Template Entry D: 
         Outgoing Transport Session Information (to Collector#3): 
           Source IP: <IPFIX Mediator IP address> 
           Destination IP: <IPFIX Collector#3 IP address> 
           Protocol: SCTP 
           Source Port: <source port> 
           Destination Port: 4739 (IPFIX) 
         Observation Domain Id: <Observation Domain ID> 
           Template Id: 257 
           Flow Keys: <series of Flow Keys> 
           Non Flow Keys: <series of non Flow Keys> 
            
        The Template Mapping corresponding to the figure B can be

d/the/
Done.


        displayed as: 
         
           Template Entry A   <----> Template Entry B 
           Template Entry A   <----> Template Entry C 
           Template Entry A   <----> Template Entry D

To be picky, this looks like three instances of Template Entry A. How about:

                                 +--> Template Entry B 
                                 |
           Template Entry A   <--+--> Template Entry C 
                                 |
                                 +--> Template Entry D

The issue is that we treat the easy case first. So I added.

Alternatively, the Template Mapping may be optimized as:

 

                             +--> Template Entry B

                             |

       Template Entry A   <--+--> Template Entry C

                             |

                             +--> Template Entry D 


      
        Note that all examples use Transport Sessions based on the SCTP 
        protocol, as simplified use cases.  However, the protocol would 
        be important in situations such as an Intermediate Conversion 
        Process doing transport protocol conversion. 
      
      
     3.2.2. Template Management With New Template Records  

        The second case is a situation where the IPFIX Mediator 
        generates new (Options) Template Records compared to the

"compared to" doesn't seem right here.
NEW:

The second case is a situation where the IPFIX Mediator generates new (Options) Template Records as a result of the Intermediate Process.




        received ones. 
         
        In such a situation, the IPFIX Mediator doesn't need to maintain 
        a Template Mapping, as it generates its own series of (Options) 
        Template Records.  However, the following special case might 
        still require a Template Mapping, i.e. a situation where the 
        IPFIX Mediator, typically containing an Intermediate Conversion 
        Process, Intermediate Aggregation Process [IPFIX-MED-AGGR], or 
        Intermediate Anonymization Process in case of black-marker 
        Anonymization [RFC6235], generates new (Options) Template 
        Records based on what it receives from the Exporter(s), and 
        based on the Intermediate Process function.  In such a case, 
      
      
     <Claise, et. Al>       Expires January 6, 2012          [Page 14] 
         
     Internet-Draft     <Protocol for IPFIX Mediations>      July 2011 
         

        it's interesting to keep the correlation between the received 
        (Options) Template Records and exported Derived Options)

(Options)
Done.

        Template Records in the Template Mapping.  
         
        Therefore, the IPFIX Mediator MAY maintain a Template Mapping  
        composed of received (Options) Template Records and exported 
        derived Options) Template Records: 
        - for each received (Options) Template Record: Template Record 
          Flow Keys and non Flow Keys, Template ID, Observation Domain, 
          and Transport Session Information 
        - for each exported derived Options) Template Record: Template 
          Record Flow Keys and non Flow Keys, Template ID, Collector, 
          Observation Domain, and Transport Session Information 
        
       If an IPFIX Mediator receives an IPFIX Withdrawal Message for a 
       (Options) Template Record that is not used anymore as the basis 
       of an inferred (Options) Template Records, the IPFIX Mediator

Use "Record" or "Record(s)" to match with "an".
Done.


       SHOULD export the appropriate IPFIX Withdrawal Message(s) for 
       the inferred (Options) Template Record on the outgoing Transport 
       Session, and remove the corresponding entry in the Template 
       Mapping. 
        
       The following two examples illustrate this.  
        
       First, consider an IPFIX Mediator hosting an Intermediate 
       Aggregation Process that generates time-series traffic octet 
       counts per source IP address (as in the example in section 8.1 
       of [IPFIX-MED-AGGR]).  Here, the Intermediate Process accepts 
       Flow Records fitting any Template, discards all Information 
       Elements other than the sourceIPv[46]Address and 
       octetDeltaCount, aggregates these across all original Exporters 
       in a given regular time interval, and exports Flow Records 
       according to a Template Record containing 
       flowStartTimeMilliseconds, flowEndTimeMilliseconds, 
       sourceIPv[46]Address, and octetDeltaCount. 
        
       In this case, no Template Mapping is necessary.  New Templates 
       and Template Withdrawals in the Transport Sessions from the 
       Original Exporters are handled as they would be at any 
       Collecting Process.  Records according to Templates which do not 
       contain at least a timestamp, sourceIPv[46]Address, and 
       octetDeltaCount IE are simply discarded by the Collector. 
        
       Next, consider a more generic case of this Intermediate 
       Aggregation Process, which creates time-series aggregates across 
       all Original Exporters, imposing a time interval but keeping a 
       subset of the incoming Flow Key received from the Original 
      
      
     <Claise, et. Al>       Expires January 6, 2012          [Page 15] 
         
     Internet-Draft     <Protocol for IPFIX Mediations>      July 2011 
         

       Exporter.  In this case, a Template Mapping is necessary, as 
       there is a relationship between incoming and outgoing Templates. 
      
        .--------. tid 256 (src) 
        |IPFIX   |  
        |Exporter|----+ 
        |#1      |    | 
        '--------'    | 
        .--------.    |          .----------.              .---------. 
        |IPFIX   |    '--------->|          |              |         | 
        |Exporter|-------------->|IPFIX     |------------->|IPFIX    | 
        |#2      | tid 257 (src) |Mediator  |tid 256 (src) |Collector| 
        '--------'    +--------->|          |    257 (dst) |         | 
        .--------.    |          '----------'              '---------' 
        |IPFIX   |    | 
        |Exporter|----' 
        |#3      | tid 257 (dst) 
        '--------' 
      
             Figure C: Intermediate Aggregation Process Example

Personally, I feel that "src" and "dst" clutter this figure without adding much.
At first I didn't understand what a src or dst template ID was.
removed.


      
       In Figure C, above, the Mediator accepts a Template Record 
       containing only the sourceIPv4Address as the Flow Key from 
       Exporters 1 and 2, and a Template Record containing only the 
       destinationIPv4Address as the Flow Key from exporter 3.  It 
       exports time-series source aggregates as Template ID 256, and 
       time-series destination aggregates as Template ID 257. The 
       Template Entries in this case are as follows: 
      
        Template Entry A: 
         Incoming Transport Session Information (from Exporter#1): 
           Source IP: <Exporter#1 export IP address>  
           Destination IP: <IPFIX Mediator IP address> 
           Protocol: SCTP 
           Source Port: <source port> 
           Destination Port: 4739 (IPFIX)     
         Observation Domain Id: <Observation Domain ID> 
         Template Id: 256      
           Flow Keys: sourceIPv4Address 
           Non Flow Keys: octetDeltaCount, [others]   
                       
        Template Entry B: 
         Incoming Transport Session Information (from Exporter#2): 
           Source IP: <Exporter#2 export IP address> 
           Destination IP: <IPFIX Mediator IP address> 
           Protocol: SCTP 
           Source Port: <source port> 
      
      
     <Claise, et. Al>       Expires January 6, 2012          [Page 16] 
         
     Internet-Draft     <Protocol for IPFIX Mediations>      July 2011 
         

           Destination Port: 4739 (IPFIX)  
         Observation Domain Id: <Observation Domain ID> 
         Template Id: 257           
           Flow Keys: sourceIPv4Address 
           Non Flow Keys: octetDeltaCount, [others]   
                                    
        Template Entry C: 
         Incoming Transport Session Information (from Exporter#3): 
           Source IP: <Exporter#3 export IP address> 
           Destination IP: <IPFIX Mediator IP address>  
           Protocol: SCTP 
           Source Port: <source port>    
           Destination Port: 4739 (IPFIX)   
         Observation Domain Id: <Observation Domain ID> 
         Template Id: 257     
           Flow Keys: destinationIPv4Address     
           Non Flow Keys: octetDeltaCount, [others]      
      
        Template Entry D: 
         Outgoing Transport Session Information (to IPFIX Collector): 
           Source IP: <IPFIX Mediator export IP address> 
           Destination IP: <IPFIX Collector IP address> 
           Protocol: SCTP 
           Source Port: <source port> 
           Destination Port: 4739 (IPFIX) 
         Observation Domain Id: <Observation Domain ID> 
           Template Id: 256 
           Flow Keys: sourceIPv4Address 
           Non Flow Keys: octetDeltaCount 
            
        Template Entry E: 
         Outgoing Transport Session Information (to IPFIX Collector): 
           Source IP: <IPFIX Mediator export IP address> 
           Destination IP: <IPFIX Collector IP address> 
           Protocol: SCTP 
           Source Port: <source port> 
           Destination Port: 4739 (IPFIX) 
         Observation Domain Id: <Observation Domain ID> 
           Template Id: 257 
           Flow Keys: destinationIPv4Address 
           Non Flow Keys: octetDeltaCount 
            
        The Template Mapping corresponding to the figure C can be

d/the/
Done.


        displayed as: 
         
           Template Entry A   <----> Template Entry D 
           Template Entry B   <----> Template Entry D 
      
      
     <Claise, et. Al>       Expires January 6, 2012          [Page 17] 
         
     Internet-Draft     <Protocol for IPFIX Mediations>      July 2011 
         

           Template Entry C   <----> Template Entry E 
      
        Note that all examples use Transport Sessions based on the SCTP 
        protocol, as simplified use cases.  However, the protocol would 
        be important in situations such as an Intermediate Conversion 
        Process doing transport protocol conversion. 
      
      
     3.3. Time Management 

        The IPFIX Message Header "Export Time" field is the time in 
        seconds since 0000 UTC Jan 1, 1970, at which the IPFIX Message 
        Header leaves the IPFIX Mediator.  However, in the specific case

The header isn't disembodied. d/Header/
Good catch.


        of an IPFIX Mediator containing an Intermediate Conversion 
        Process, the IPFIX Mediator MAY keep the export time received 
        from the incoming Transport Session.

Very generous. Why?
List as an open issue.


         
        It is RECOMMENDED that Mediators handle time using absolute 
        timestamps (e.g. flowStartSeconds, flowStartMilliseconds, 
        flowStartNanoseconds), which are specified relative to the UNIX 
        epoch (00:00 UTC 1 Jan 1970), where possible, rather than 
        relative timestamps (e.g. flowStartSysUpTime, 
        flowStartDeltaMicroseconds), which are specified relative to 
        protocol structures such as system initialization or message 
        export time.   
         
        The latter are difficult to manage for two reasons.  First, they 
        require constant translation, as the system initialization time 
        of an intermediate system and the export time of an intermediate 
        message will change across mediation operations.  Further, 
        relative timestamps introduce range problems.  For example, when 
        using the flowStartDeltaMicroseconds and 
        flowEndDeltaMicroseconds Information Elements [RFC5102], the

Should you cite IANA here instead?
Listed as an open issue.


        Data Record must be exported within a maximum of 71 minutes 
        after its creation.  Otherwise, the 32-bit counter would not be 
        sufficient to contain the flow start time offset.  Those time 
        constraints might be incompatible with some of the Intermediate 
        Processes: Intermediate Aggregation Process (temporal) and 
        Intermediate Correlation Process, for example. 
         
        When an Intermediate Aggregation Process aggregates information 
        from different Flow Records, the typical reporting times SHOULD 
        BE the minimum of the start times and the maximum of the end

s/BE/be/
;-)


        times.  However, if the Flow Records do not overlap, i.e. if 
        there is a time gap between the times in the Flow Records, then 
        the report may be inaccurate.  The IPFIX Mediator is only 
        reporting what it knows, on the basis of the information made 
      
      
     <Claise, et. Al>       Expires January 6, 2012          [Page 18] 
         
     Internet-Draft     <Protocol for IPFIX Mediations>      July 2011 
         

        available to it - and there may not have been any data to 
        observe during the gap.  Then again, if there is an overlap in 
        timestamps, there's the potential of double-accounting: 
        different Observation Points may have observed the same traffic 
        simultaneously.  Therefore, as there is not a single rule that 
        fits all different situations, the precise rules of applying the 
        Flow Record timestamps in IPFIX Mediators is out of the scope of 
        this document.  However, some more specifications related to the

Being a hard problem doesn't make it out of scope. I think this is exactly something that should be specified here. Else, where?
Listed as an open issue


        specific case of aggregation in space and time are specified in

"specifications... are specified" seems clumsy. s/specified/given/
Done.


        [IPFIX-MED-AGGR], and MUST be followed. 
         
         
     3.4. Observation Point Management 

        Depending on the use case, top Collectors may need to receive

What are "top collectors"?
top, as top collector in a chain of collectors.
NEW:
Depending on the use case, the Collector in an Exporter-Mediator-Collector structure model may need to receive the Original Observation Point(s),


note that "Exporter-Mediator-Collector structure model" was used in RFC5982 (Mediation requirements) 


        the Original Observation Point(s), otherwise it may wrongly 
        conclude that the IPFIX Device exporting the Flow Records to 
        him, i.e. the IPFIX Mediator, directly observed the packets that

These singular pronouns don't match plural "top Collectors". Consider "they" and "them".
Done.


        generated the Flow Records.  Two new Information Element are

s/Element/Elements/
Done.


        introduced to solve this use case: originalExporterIPv4Address 
        and originalExporterIPv6Address. 
         
        In the IPFIX Mediator, the Observation Point(s) may be 
        represented by:  
        - A single Original Exporter (represented by the 
          originalExporterIPv4Address or originalExporterIPv6Address 
          Information Elements) 
        - A list of Original Exporter (represented by the 

          originalExporterIPv4Address or originalExporterIPv6Address 
          Information Elements_)

d/_/


        - A list of Original Exporter (represented by the 
          originalExporterIPv4Address or originalExporterIPv6Address 
          Information Elements), along with the associated interface 
          (represented by the ingressInterface and/or egressInterface)

You've described "(list of originalExporterIPv[46]Address) + interface".
I think you meant, "list of (originalExporterIPv[46]Address + interface)".
Good catch!
NEW:

-  A list of Original Exporter interface(s) (represented by the originalExporterIPv4Address or originalExporterIPv6Address, the ingressInterface and/or egressInterface Information Elements, respectively) 




        - A list of Original Exporter (represented by the 
          originalExporterIPv4Address or originalExporterIPv6Address 
          Information Elements), along with the associated line card id 
          (represented by the lineCardId)
NEW:

-  A list of Original Exporter line card (represented by the originalExporterIPv4Address or originalExporterIPv6Address, the lineCardId Information Elements, respectively) 


      

      

      Today's OP could be at many more places than an interface or LC.
      We need to move away from this old thinking.

      

      

      

        
        - Any combination or list of Information Elements representing 
          Observation Points.  


      

      

      Consider removing the previous two points and using them as
      specific examples of this point.

    

    Good suggestion.

    
 

      

      

        
        
        Some Information Elements characterizing the Observation Point 
        may be added.  For example, the flowDirection Information 
        Element specifies the direction of the observation, and, as 
        such, characterizes the Observation Point. 
      

      
      
     <Claise, et. Al>       Expires January 6, 2012          [Page 19] 
         
     Internet-Draft     <Protocol for IPFIX Mediations>      July 2011 
         

        Any combination of the above examples is possible.  For example, 
        in case of an Intermediate Aggregation Process, an Original 
        Observation Point can be composed of: 
              exporterIPv4Address 192.0.2.1  
              exporterIPv4Address 192.0.2.2,  
                       interface ethernet 0, direction ingress 
                       interface ethernet 1, direction ingress 
                       interface serial 1, direction egress 
                       interface serial 2, direction egress 
              exporterIPv4Address 192.0.2.3,  
                       lineCardId 1, direction ingress 
      
        If the Original Observation Point is composed of a list, then 
        the IPFIX Structured Data [IPFIX-STRUCT] MUST be used to export 
        it from the IPFIX Mediator.   
         
        The most generic way to export the Original Observation Point is 
        to use a subTemplateMultiList, with the semantic "exactlyOneOf".  
        Taking back the previous example, the following encoding can be 


      

      

      d/back/

    

    done.

    
 

      

      

        
        used: 
         
                 Template Record 257: exporterIPv4Address 
                 Template Record 258: exporterIPv4Address, basicList of 
                                    ingressInterface, flowDirecdtion

      

      

      s/flowDirecdtion/flowDirection/

    

    Done.

    
 

      

      

        
 
                 Template Record 259: exporterIPv4Address, lineCardId,  
                                    flowDirection 


      

      

      How does the mediator come to know where the OPs are in the
      original devices?

    

    Either 

    
 

      eg, suppose the OP is at the QoS process in order to verify SLA.
      Although interface IDs and/or LC IDs may be exported, these might
      incorrectly imply multiple OPs.

      

      

      

        
         
        The Original Observation Point is modeled with the Data Records 
        corresponding to either Template Record 1, Template Record 2, or 
        Template Record 3 but not more than one of these ("exactlyOneOf" 
        semantic).  This implies that the Flow was observed at exactly 
        one of the Observation Points reported. 
         
        When an IPFIX Mediator receives Flow Records containing the 
        Original Observation Point Information Element, i.e. 


      

      

      Aha! You expect the original exporter to populate FR with OOPIE,
      just in case a mediator is present? LOL.

      No existing exporters do that today. How does the mediator work?

    

    Not exactly. The point in that sentence is ...  "SHOULD NOT modify
    its value(s)"

    However, you have a good point.

    NEW to the 1st paragraph in this section;

    
    
    
Mediator-Collector structure model
      may need to receive the Original Observation
        Point(s), otherwise it may wrongly conclude that the IPFIX
        Device exporting the Flow Records to him, i.e. the IPFIX
        Mediator, directly observed the packets that generated the Flow
        Records.  Two new
        Information Elements are
        introduced to solve this use case: originalExporterIPv4Address
        and originalExporterIPv6Address.  Practically,
          the Original Exporters will not exporting these Information
          Elements. Therefore, the Intermediate Process SHOULD report
          the Original Observation Point(s) to the best of its
          knowledge.  Note that
          the Configuration Data Model for IPFIX and PSAMP [IPFIX-CONF] may help.

    

    
    
    
    
    
    
    

    Also listed as an open issue, for discussion.

    
 

      

      

        
        originalExporterIPv6Address or originalExporterIPv4Address, the 
        IPFIX Mediator SHOULD NOT modify its value(s) when composing new 
        Flow Records in the general case.   Known exceptions include 
        anonymization per [RFC6235] section 7.2.4 and an Intermediate 
        Correlation Process rewriting addresses across NAT.  
         
        In other words, the Original Observation Point should not be 
        replaced the IPFIX Mediator Observation Point.  The daisy chain 
        of (Exporter, Observation Point) representing the path the Flow 


      
      
     <Claise, et. Al>       Expires January 6, 2012          [Page 20] 
         
     Internet-Draft     <Protocol for IPFIX Mediations>      July 2011 
         

        Records took from the Exporter to the top Collector, via the 
        IPFIX Mediator(s) is out of the scope of this specification.   


      

      

      Why do you say it's out of scope? Where else would you expect it
      to be specified?

    

    Question: Do you believe it's important to report that the flow
    record was exported from exporter 1 via mediator 1 via mediator 2
    via mediator 3 to collector 1?

    

    
 

      

      

        
         
         

     3.4.1. Observation Domain Management 

        In any case, the Observation Domain ID of any IPFIX Message 
        containing Flow Records relevant to no particular Observation 
        Domain, or to multiple Observation Domains, MUST have an 
        Observation Domain ID of 0, as in section 3.1 above, and section 
        3.1 of [RFC5101]. 
         
        IPFIX Mediators that do not change (Options) Template Records 
        MUST maintain a Template Mapping, as detailed in section 3.2.1, 
        to ensure that the combination of Observation Domain IDs and 
        Template IDs do not collide on export. 
         
        For IPFIX Mediators that export New (Options) Template Records 
        unchanged, as in section 3.2.2, there are two options for 
        Observation Domain ID management.  The first and simplest of 
        these is to completely decouple exported Observation Domain IDs 
        from received Observation Domain IDs; the IPFIX Mediator, in 
        this case, comprises its own set of Observation Domain(s) 
        independent of the Observation Domain(s) of the Original 
        Exporters. 
         
        The second option is to provide or maintain a Template Mapping 
        for received (Options) Template Records and exported inferred 
        (Options) Template Records, along with the appropriate 
        Observation Domain IDs per Transport Session, which ensures that 
        the combination of Observation Domain IDs and Template IDs do 
        not collide on export.   
      
        In some cases where the IPFIX Message Header can't contain a 
        consistent Observation Domain for the entire IPFIX Message, but 
        the Flow Records exported from the IPFIX Mediator should anyway 
        contain the Observation Domain of the Original Exporter, the 
        (Options) Template Record must contain the 
        originalObservationDomainId Information Element.  When an IPFIX 
        Mediator receives Flow Records containing the 
        originalObservationDomainId Information Element, the IPFIX 
        Mediator MUST NOT modify its value(s) when composing new Flow 
        Records with the originalObservationDomainId Information  
        Element. 
      
         
      
      
     <Claise, et. Al>       Expires January 6, 2012          [Page 21] 
         
     Internet-Draft     <Protocol for IPFIX Mediations>      July 2011 
         

     3.5. Specific Reporting Requirements 

        Some specific Options Templates and Options Template Records are 
        necessary to provide extra information about the Flow Records 
        and about the Metering Process. 
         
        The Options Template Records defined in these subsections, which 
        impose some constraints on the Metering Process and Exporting 
        Process implementations in Intermediate Processes, MAY be 
        implemented.  If implemented, the specific Option Templates 
        SHOULD be implemented as specified in these subsections. 
         
        The minimum set of Information Elements is always specified in 
        these Specific IPFIX Options Templates.  Nevertheless, extra 


      

      

      Why is "Specific" capitalised?

    

    corrected.

    
 

      

      

        
        Information Elements may be used in these specific Options 
        Templates. 


      

      

      Other things I'd like to see in this section:

      

      What about IE ordering? May an exporter re-order received fields?
      eg, two devices sending the same information, though with the
      fields in a different order. Or the mediator is extracting the
      same information from two sources. That seems to be a valid
      scenario. eg, this reduces the number of templates received at the
      collector.

      

      What about temporal re-ordering? How should a mediator deal with
      out-of-order data coming from multiple devices? It can't expect
      all received data to be in time order.

      

      What should a mediator do with a field which it doesn't
      know/understand? Inevitably, exporters will be updated without
      mediators keeping in step. It's also very likely that mediators
      will see Enterprise-specific IEs. May a mediator re-export unknown
      IEs unchanged, or should it drop them? Presumably a mediator may
      report received Enterprise-specific IEs even from multiple
      different Enterprises.

      

      What if an unknown field depends on the field ordering? eg, it's a
      bitfield like flowKeyIndicator. Re-ordering, adding or removing
      fields breaks the meaning of this field, so it can't be passed on.
      It can only be used if the received fields are reported unchanged.

    

    Listed as an open issue.

    
 

      

      

        
         

     3.5.1. The Flow Keys Options Template 

        Exactly like the IPFIX protocol [RFC5101], the Flow Keys Option 
        Template specifies the structure of a Data Record for reporting 
        the Flow Keys of reported Flows.  A Flow Keys Data Record 
        extends a particular Template Record that is referenced by its 
        templateId identifier.  The Template Record is extended by 
        specifying which of the Information Elements contained in the 
        corresponding Data Records describe Flow properties that serve 
        as Flow Keys of the reported Flow. 
         
        The Flow Keys Option Template SHOULD contain the following 
        Information Elements that are defined in [RFC5102] 
           templateId              An identifier of a Template.  This 
                                   Information Element MUST be defined  
                                   as a Scope Field. 
         
           flowKeyIndicator        Bitmap with the positions of the Flow  
                                   Keys in the Data Records. 


      

      

      As a general point, can you space all your lists, with space
      before and after too?

      It's less easy to read when all the text is jammed together.

    

    Done.

    
 

      

      

        
        When any Intermediate Process changes the Flow Keys, the Flow 
        Keys Option Template MUST include the new set of Flow Keys. 
        Typically, an Intermediate Aggregation Process keeps or reduces 
        the number of Flow Keys 


      

      

      Missing full-stop here.

    

    Done.

    
 

      Consider mentioning how it can increase the number of keys. eg, by
      adding info about the OP or Exporter.

    

    Good point.

    I added:
    
    
    
However, the number of Flow Keys may increase
      when the Original
      Exporter or/and Original Observation Point is/are added.

    
    
    
    
    
    
    
    
 

      

      

        
         
     3.5.2. IPFIX Protocol Options Template 

        The "Metering Process Statistics Options Template", "The 
        Metering Process Reliability Statistics Options Template", and 
        "The Exporting Process Reliability Statistics Options Template", 
      
      
     <Claise, et. Al>       Expires January 6, 2012          [Page 22] 
         
     Internet-Draft     <Protocol for IPFIX Mediations>      July 2011 
         

        as specified in [RFC5101], SHOULD be implemented on the IFPIX 


      

      

      s/IFPIX/IPFIX/

    

    ;-)

    
 

      

      

        
        Mediator. 
         
        Refer to the document specifying a particular Intermediate 
        Process type for specific values for these Options Template 
        Records.  For example, in case of an Intermediate Aggregation 
        Process, [IPFIX-MED-AGGR] must specify which values to insert 


      

      

      s/must specify/specifies/

    

    done.

    
 

      

      

        
        into the fields of "Metering Process Statistics Options 
        Template", "The Metering Process Reliability Statistics Options 
        Template", and "The Exporting Process Reliability Statistics 
        Options Template" 
      
         
     3.5.3. IPFIX Mediator Options Template 

        There is no need for a specific Options Template for the IPFIX 
        Mediator; instead, each Intermediate Process type requires some 
        particular metadata.  For example, a specification of IPFIX flow 
        Anonymization including an Options Template for the export of 
        metadata about Anonymized flows is described in [RFC6235]; when 
        Anonymizing Flows Records, IPFIX Mediators SHOULD add the 
        Options Template specified therein to annotate the exported 
        data.   
         
        Transport Session Management SCTP [RFC4960] using the PR-SCTP 
        extension specified in [RFC3758] MUST be implemented by all 
        compliant IPFIX Mediator implementations.  UDP [UDP] MAY also be 
        implemented by compliant IPFIX Mediator implementations.  TCP 
        [TCP] MAY also be implemented by IPFIX Mediator compliant 
        implementations. 


      

      

      For consistency, you should refer to these by their RFC numbers:
      "TCP [RFC793]", "UDP [RFC768]".

    

    Done.

    
 

      

      

        
         
        PR-SCTP SHOULD be used in deployments where IPFIX Mediators and 
        Collectors are communicating over links that are susceptible to 
        congestion.  PR-SCTP is capable of providing any required degree 
        of reliability. 

        TCP MAY be used in deployments where IPFIX Mediators and 
        Collectors communicate over links that are susceptible to 
        congestion, but PR-SCTP is preferred due to its ability to limit 
        back pressure on Exporters and its message versus stream 
        orientation.  

        UDP MAY be used, although it is not a congestion-aware protocol. 
        However, the IPFIX traffic between IPFIX Mediator and Collector 


      

      

      However, in this case, the ...

    

    Done.

    
 

      

      

        
        MUST run in an environment where IPFIX traffic has been 
        provisioned for, or is contained through some other means. 
         
      
      
     <Claise, et. Al>       Expires January 6, 2012          [Page 23] 
         
     Internet-Draft     <Protocol for IPFIX Mediations>      July 2011 
         

     3.6. The Collecting Process's Side 

        An IPFIX Mediator MUST produce IPFIX Messages understandable by 
        a RFC5101-compliant IPFIX Collector, with the additional 


      

      

      Here you're limiting what mediators can do in future. If a future
      mediator wants to do something that's not backwards compatible
      with 5101 and specifies an extension to 5101 in order to do so,
      it'll break this MUST.

    

    Removed the MUST

    This section has been updated to be compliant with RFC5101bis

    NEW:

    
    
    
An IPFIX Mediator produces IPFIX Messages
      understandable by a IPFIX-compliant
      Collector, with the additional specifications in IPFIX Structured
      Data
      [IPFIX-STRUCT].

    
 

    
Therefore the Collecting Process on the top
      Collector MUST
      support the IPFIX protocol [RFC5101bis] and the IPFIX Structured
      Data
      [IPFIX-STRUCT].

    
    
    
    
    
    
    

    

    
 

      

      

        
        specification in the IPFIX Structured Data [IPFIX-STRUCT]. 


      

      

      "specifications"

      d/the/

    

    Done.

    
 

      

      

        
         
        Therefore the Collecting Process on the top Collector MUST 
        support the IPFIX protocol [RFC5101] and the IPFIX Structured 
        Data [IPFIX-STRUCT]. 

      

    

    

    

      

        
      
      
     3.7. Configuration Management 

        In some cases such as an Intermediate Aggregation Process 
        aggregating Flow Records from multiple Original Exporters, a 
        consistent configuration of the Metering Processes and Exporting 
        Processes on these Original offers some advantages.  For 


      

      

      Original Exporters.

    

    Done.

    
 

      

      

        
        example, consistent active timeout, inactive timeout, and/or 
        consistent export time allows to compare the number of the Flow 
        Records per period of time.  For example, consistent Sampling 
        algorithm and parameters might allow to compare Flow Records 
        accuracy. 


      

      

      Either s/allow to compare/allows comparison of/, or
      put "to be compared" at the end:

      

          consistent active timeout, inactive timeout, and/or consistent
      export time allows

          the number of the Flow Records per period of time to be
      compared.

          For example, consistent Sampling algorithm and parameters
      might allow Flow Records accuracy to be compared.

    

    Done.

    
 

      

      

        
         
        While this is tempting to include all configuration parameters 
        in Flow Records for the IPFIX Mediator to draw its own 
        conclusion, the consistency of the configuration should be 
        verified out of band, with the MIB modules ([RFC5815] and 
        [PSAMP-MIB] or with the Configuration Data Model for IPFIX and 
        PSAMP [IPFIX-CONF]  


      

      

      [PSAMP-MIB])

      Missing full-stop.

      

    Done.

    
 

        

      
      

        
           
         
     4. New Information Elements 

       EDITOR NOTE: please change the TBD1, TBD2, and TBD3, with the 
       IANA newly assigned numbers.  
        
     4.1. - originalExporterIPv4Address 


      

      

      Remove the hyphen (dash) from the section title.

    

    done.

    
 

      

      

        
        Description: The IPv4 address used by the Exporting Process on 
        the Original Exporter. This is used by an IPFIX Mediator 
        Exporting Process to identify the Original Exporter. 
         
        Abstract Data Type:   ipv4Address 
         
        ElementId:   TBD3 
         
        Status:   Proposed 


      

      

      Add "Semantics: identifier" for consistency with similar
        fields in the IANA IPFIX registry.

      

      [Later] OK, there's some duplication with section 6. You could
      just list the Description and Type here, with a note that the full
      spec is in the IANA section below.

    

    Done.

    NEW:

    
    
    
Three new Information
      Elements are
      requested in this specifications: originalExporterIPv4Address,
      originalExporterIPv6Address,
      and originalObservationDomainId.
         See Section 6.1.
        , Section 6.2.
        , and
        Section 6.3.
        ,
        respectively, for the formal definitions.

    
    
    
    
    
    
    

    
 

      

      

        
      
      
     <Claise, et. Al>       Expires January 6, 2012          [Page 24] 
         
     Internet-Draft     <Protocol for IPFIX Mediations>      July 2011 
         

         
         
     4.2.  originalExporterIPv6Address 

        Description: The IPv6 address used by the Exporting Process on 
        the Original Exporter. This is used by the IPFIX Mediator 
        Exporting Process to identify the Original Exporter.  
         
        Abstract Data Type:   ipv6Address 
         
        ElementId:   TBD2 
         
        Status:   Proposed 


      

      

      Add "Semantics: identifier" for consistency with similar
        fields in the IANA IPFIX registry.

      

      

      

        
         

     4.3. originalObservationDomainId 

        Description: An identifier of the Observation Domain on the 
        Original Exporter, where the metered IP packets are observed. 
        This is used by the IPFIX Mediator Exporting Process to identify 
        an Observation Domain as received from the Original Exporter. 
         
        Abstract Data Type:   unsigned32 
         
        ElementId:   TBD3 
         
        Status:   Proposed 


      

      

      Add "Semantics: identifier" for consistency with #149 in
        the IANA IPFIX registry.

      

      

      

        
      
      

     5. Security Considerations 

        The same security considerations as for the IPFIX Protocol 
        [RFC5101] apply. 
         
        As they act as both IPFIX Collecting Processes and Exporting 
        Processes, the Security Considerations for IPFIX [RFC5101] apply 


      

      

      s/IPFIX/The IPFIX Protocol/

    

    done.

    
 

      

      

        
        as well to Mediators.  The Security Considerations for IPFIX 


      

      

      s/apply as well/also apply/

    

    Done.

    
 

      

      

        
        Files [RFC5655] apply as well to IPFIX Mediators that write 


      

      

      s/apply as well/also apply/

    

    Done.

    
 

      

      

        
        IPFIX Files or use them for internal storage.  However, there 
        are a few specific considerations that IPFIX Mediator 
        implementations must take into account in addition. 


      

      

      s/must take into account in addition/must also take into account/

    

    done.

    
 

      

      

        
         
        By design, IPFIX Mediators are "men-in-the-middle": they 
        intercede in the communication between an Original Exporter (or 
        another upstream Mediator) and a downstream Collecting Process. 
        This has two important implications for the level of 
      
      
     <Claise, et. Al>       Expires January 6, 2012          [Page 25] 
         
     Internet-Draft     <Protocol for IPFIX Mediations>      July 2011 
         

        confidentiality provided across an IPFIX Mediator, and the 
        ability to protect data integrity and Original Exporter 
        authenticity across a Mediator. These are addressed in more 
        detail in the Security Considerations for Mediators in [IPFIX-
        MED-FMWK]. 
         
        Note that, while Mediators can use the exporterCertificate and 
        collectorCertificate Information Elements defined in [RFC5655] 
        as described in section 9.3 of [IPFIX-MED-FMWK] to export 
        information about X.509 identities in upstream TLS-protected 
        Transport Sessions, this mechanism cannot be used to provide 
        true end-to-end assertions about a chain of IPFIX Mediators: any 
        Mediator in the chain can simply falsify the information about 
        upstream Transport Sessions  In situations where information 
        about the chain of mediation is important, it must be determined 
        out of band. 

      
     6. IANA Considerations 

      This document specifies three new IPFIX Information Elements: the 
      applicationDescription, applicationTag and the applicationName. 
       
      New Information Elements to be added to the IPFIX Information 
      Element registry at [IANA-IPFIX] are listed below. 
       
      EDITOR'S NOTE: the XML specification in Appendix A must be updated 
      with the elementID values allocated, i.e. TBD1, TBD2, and TDB3, 


      

      

      s/elementID/elementId/

      

      s/TDB/TBD/

    

    Done.

    
 

      The Appendix will be orphaned when this note is removed. So say
      something like, "XML specifications of these elements can be found
      in Appendix A".

    

    Done.

    
 

      

      

        
      must be replaced. 
       
         
     6.1. originalExporterIPv4Address 

      Name: originalExporterIPv4Address 
      Description:  
        The IPv4 address used by the Exporting Process on the Original 
        Exporter. This is used by an IPFIX Mediator Exporting Process 
        to identify the Original Exporter.  
      Abstract Data Type: ipv4Address 
      Data Type Semantics: identifier 
      ElementId: TBD1 
      Status: current  
       
       



      
      
     <Claise, et. Al>       Expires January 6, 2012          [Page 26] 
         
     Internet-Draft     <Protocol for IPFIX Mediations>      July 2011 
         

     6.2. originalExporterIPv6Address 

      Name: originalExporterIPv6Address  
      Description:  
        The IPv6 address used by the Exporting Process on the Original 
        Exporter. This is used by the IPFIX Mediator Exporting Process 
        to identify the Original Exporter.  
      Abstract Data Type: ipv6Address 
      Data Type Semantics: identifier 
      ElementId: TBD2 
      Status: current  
       
       
     6.3. originalObservationDomainId 

      Name: originalObservationDomainId 
      Description:  
         An identifier of the Observation Domain on the Original 
         Exporter, where the metered IP packets are observed. This is 
         used by the IPFIX Mediator Exporting Process to identify an 
         Observation Domain as received from the Original Exporter. 
      Abstract Data Type: unsigned32 
     Data Type Semantics: identifier 
     ElementId: TBD3 
     Status: current  
         
     7. References 

     7.1. Normative References 

        [RFC2119] S. Bradner, Key words for use in RFCs to Indicate 
                Requirement Levels, BCP 14, RFC 2119, March 1997 
         
        [RFC3758] Stewart, R., Ramalho, M, Xie, Q., Tuexen, M., and P. 
                Conrad, "Stream Control Transmission Protocol (SCTP), 
                Partial Reliability Extension", May 2004 
         
        [RFC4960] Stewart, R., Ed., "Stream Control Transmission 
                Protocol", RFC 4960, September 2007. 
         
        [RFC5101] Claise, B., Ed., "Specification of the IP Flow 
                Information Export (IPFIX) Protocol for the Exchange of 
                IP Traffic Flow Information", RFC 5101, January 2008. 
         
        [RFC5102] Quittek, J., Bryant, S., Claise, B., Aitken, P., and 
                J. Meyer, "Information Model for IP Flow Information 
                Export", RFC 5102, January 2008. 
      
      
     <Claise, et. Al>       Expires January 6, 2012          [Page 27] 
         
     Internet-Draft     <Protocol for IPFIX Mediations>      July 2011 
         

         
        [RFC5655] Trammell, B., Boschi, E., Mark, L., Zseby, T., and A. 
                Wagner, "Specification of the IP Flow Information 
                Export (IPFIX) File Format", RFC 5655, October 2009. 
         
        [RFC5815] Dietz, T., Kobayashi, A., Claise, B., and G. Muenz, 
                "Definitions of Managed Objects for IP Flow Information 
                Export", RFC 5815, April 2010. 
         
        [IPFIX-MED-FLOWSEL] D'antonio, S., Zseby, T., Henke, C. and L. 
                Peluso, "Flow Selection Techniques", draft-ietf-ipfix-
                flow-selection-tech-06.txt, Internet-Draft work in 
                progress, May 2011. 
         
        [IPFIX-MED-AGGR] Trammell, B., Boschi, E., A. Wagner, and B. 
                Claise, "Exporting Aggregated Flow Data using the IP 
                Flow Information Export (IPFIX) Protocol", draft-
                trammell-ipfix-a9n-03.txt, Internet-Draft work in 
                progress, June 2011. 
         
        [IPFIX-STRUCT] Claise, B., Dhandapani, G., Aitken, P., and S. 
                Yates, "Export of Structured Data in IPFIX", draft-
                ietf-ipfix-structured-data-06.txt, Internet-Draft work 
                in progress, May 2011. 
         
        [PSAMP-MIB] Dietz, T., Claise, B., and J. Quittek "Definitions 
                of Managed Objects for Packet Sampling", draft-ietf-
                ipfix-psamp-mib-03.txt, Internet-Draft work in 
                progress, March 2011. 
         
        [IPFIX-CONF] Muenz, G., Claise, B., and P. Aitken "Configuration 
                Data Model for IPFIX and PSAMP", draft-ietf-ipfix-
                configuration-model-09, Internet-Draft work in 
                progress, March 2011. 
         
      
         
     7.2. Informative References 

         
        [TCP] Postel, J., "Transmission Control Protocol", STD 7, RFC 
                793, September 1981. 
         
        [UDP] Postel, J., "User Datagram Protocol", STD 6, RFC 768, 
                August 1980. 


      

      

      See earlier point: for consistency, you should reference these by
      their RFC numbers, ie "[RFC793]" and "[RFC768]".

    

    Done.

    
 

      

      

        
          

      
      
     <Claise, et. Al>       Expires January 6, 2012          [Page 28] 
         
     Internet-Draft     <Protocol for IPFIX Mediations>      July 2011 
         

        [RFC3917] Quittek, J., Zseby, T., Claise, B., and S. Zander, 
                "Requirements for IP Flow Information Export", RFC 
                3917, October 2004 
         
        [RFC3954] Claise, B. (Ed), "Cisco Systems NetFlow Services 
                Export Version 9", RFC 3954, October 2004 
         
        [RFC5470] Sadasivan, G., Brownlee, N., Claise, B., and J. 
                Quittek, "Architecture Model for IP Flow Information 
                Export", RFC5470, March 2009 
         
        [RFC5472] Zseby, T., Boschi, E., Brownlee, N., and B. Claise, 
                "IP Flow Information Export (IPFIX) Applicability", RFC 
                5472, March 2009 
         
        [RFC5476] Claise, B., Quittek, J., and A. Johnson, "Packet 
                Sampling (PSAMP) Protocol Specifications", RFC 5476, 
                March 2009. 
         
        [RFC5982] Kobayashi, A. (Ed), Claise, B. (Ed), "P Flow 
                Information Export (IPFIX) Mediation: Problem 
                Statement", RFC 5982, August 2010. 
         
        [IPFIX-MED-FMWK] Kobayashi, A., Claise, B., Muenz, G., and K. 
                Ishibashi, "IPFIX Mediation: Framework", RFC 6183, 
                April 2011. 
         
        [RFC6235] Boschi, E., Trammell, B. "IP Flow Anonymization 
                Support", RFC 6235, May 2011. 
         
        [IANA-IPFIX] http://www.iana.org/assignments/ipfix/ipfix.xhtml 
         
         
     8. Author's Addresses 

        Benoit Claise 
        Cisco Systems, Inc. 
        De Kleetlaan 6a b1 
        Diegem 1813 
        Belgium 
            
        Phone: +32 2 704 5622 
        Email: bclaise@cisco.com 
      
      
        Atsushi Kobayashi 
        NTT Information Sharing Platform Laboratories 
      
      
     <Claise, et. Al>       Expires January 6, 2012          [Page 29] 
         
     Internet-Draft     <Protocol for IPFIX Mediations>      July 2011 
         

        3-9-11 Midori-cho 
        Musashino-shi, Tokyo  180-8585 
        Japan 
         
        Phone: +81-422-59-3978 
        Email: akoba@nttv6.net 
        URI:   http://www3.plala.or.jp/akoba/ 
         
         
        Brian Trammell 
        ETH Zurich 
        Gloriastrasse 35 
        8092 Zurich 
        Switzerland 
         
        Phone: +41 44 632 70 13 
        EMail: trammell@tik.ee.ethz.ch 
         
      9. Appendix A.  Additions to XML Specification of IPFIX 
      Information Elements 


      

      

      s/9. Appendix A/Appendix A/

    

    Done.

    

    Many thanks again.

    Impressive feedback.

    

    Regards, Benoit.

    
 

      

      

        
        This appendix contains additions to the machine-readable 
        description of the IPFIX information model coded in XML in 
        Appendix A and Appendix B in [RFC5102].  Note that this appendix 
        is of informational nature, while the text in Section 6. 
        (generated from this appendix) is normative. 
         
        The following field definitions are appended to the IPFIX 
        information model in Appendix A of [RFC5102]. 
      
        <field name="originalExporterIPv4Address" 
                 dataType="ipv4Address" 
                 group="config" 
                 elementId="TBD1" applicability="all" status="current"> 
            <description> 
              <paragraph> 
                The IPv4 address used by the Exporting Process on the 
                Original Exporter. This is used by an IPFIX Mediator 
                Exporting Process to identify the Original Exporter. 
              </paragraph> 
            </description> 
          </field> 
         
      
        <field name="originalExporterIPv6Address" 
                 dataType="ipv6Address" 
                 group="config" 
      
      
     <Claise, et. Al>       Expires January 6, 2012          [Page 30] 
         
     Internet-Draft     <Protocol for IPFIX Mediations>      July 2011 
         

                 elementId="TBD2" applicability="all" status="current"> 
            <description> 
              <paragraph> 
                The IPv6 address used by the Exporting Process on the 
                Original Exporter. This is used by the IPFIX Mediator 
                Exporting Process to identify the Original Exporter.  
              </paragraph> 
            </description> 
          </field> 
         
        <field name="originalObservationDomainId" 
                 dataType="unsigned32" 
                 group="config" 
                 elementId="TBD3" applicability="all" status="current"> 
            <description> 
              <paragraph> 
                An identifier of the Observation Domain on the Original 
                Exporter, where the metered IP packets are observed. 
                This is used by the IPFIX Mediator Exporting Process to 
                identify an Observation Domain as received from the 
                Original Exporter. 
              </paragraph> 
            </description> 
          </field> 
         
         





















      
      
     <Claise, et. Al>       Expires January 6, 2012          [Page 31] 
         


      

    

    

    

    

  


--------------020200020803060909050804--

From internet-drafts@ietf.org  Tue Dec  6 05:45:08 2011
Return-Path: 
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 14C1D21F8B33; Tue,  6 Dec 2011 05:44:57 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.58
X-Spam-Level: 
X-Spam-Status: No, score=-102.58 tagged_above=-999 required=5 tests=[AWL=0.019, 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 Gt9fNKiaElSm; Tue,  6 Dec 2011 05:44:56 -0800 (PST)
Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6DFE421F8B30; Tue,  6 Dec 2011 05:44:56 -0800 (PST)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
From: internet-drafts@ietf.org
To: i-d-announce@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 3.64
Message-ID: <20111206134456.18051.82810.idtracker@ietfa.amsl.com>
Date: Tue, 06 Dec 2011 05:44:56 -0800
Cc: ipfix@ietf.org
Subject: [IPFIX] I-D Action: draft-ietf-ipfix-mediation-protocol-00.txt
X-BeenThere: ipfix@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: IPFIX WG discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 06 Dec 2011 13:45:08 -0000

A New Internet-Draft is available from the on-line Internet-Drafts director=
ies. This draft is a work item of the IP Flow Information Export Working Gr=
oup of the IETF.

	Title           : Specification of the Protocol for IPFIX Mediation
	Author(s)       : Benoit Claise
                          Atsushi Kobayashi
                          Brian Trammell
	Filename        : draft-ietf-ipfix-mediation-protocol-00.txt
	Pages           : 33
	Date            : 2011-12-06

        This document specifies the IP Flow Information Export
        (IPFIX) protocol specific to Mediation.


A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-ipfix-mediation-protocol-00.=
txt

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

This Internet-Draft can be retrieved at:
ftp://ftp.ietf.org/internet-drafts/draft-ietf-ipfix-mediation-protocol-00.t=
xt


From bclaise@cisco.com  Tue Dec  6 06:52:46 2011
Return-Path: 
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 84B9521F8B72 for ; Tue,  6 Dec 2011 06:52:46 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.698
X-Spam-Level: 
X-Spam-Status: No, score=-1.698 tagged_above=-999 required=5 tests=[AWL=-0.391, BAYES_00=-2.599, MISSING_HEADERS=1.292]
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 cP1aZMnmnEcX for ; Tue,  6 Dec 2011 06:52:45 -0800 (PST)
Received: from av-tac-bru.cisco.com (weird-brew.cisco.com [144.254.15.118]) by ietfa.amsl.com (Postfix) with ESMTP id 5715821F8B79 for ; Tue,  6 Dec 2011 06:52:45 -0800 (PST)
X-TACSUNS: Virus Scanned
Received: from strange-brew.cisco.com (localhost.cisco.com [127.0.0.1]) by av-tac-bru.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id pB6EqiQG001066 for ; Tue, 6 Dec 2011 15:52:44 +0100 (CET)
Received: from [10.60.67.86] (ams-bclaise-8915.cisco.com [10.60.67.86]) by strange-brew.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id pB6EqhKV017947 for ; Tue, 6 Dec 2011 15:52:43 +0100 (CET)
Message-ID: <4EDE2C3B.60305@cisco.com>
Date: Tue, 06 Dec 2011 15:52:43 +0100
From: Benoit Claise 
User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:8.0) Gecko/20111105 Thunderbird/8.0
MIME-Version: 1.0
CC: ipfix@ietf.org
References: <20111206134456.18051.82810.idtracker@ietfa.amsl.com>
In-Reply-To: <20111206134456.18051.82810.idtracker@ietfa.amsl.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: [IPFIX] I-D Action: draft-ietf-ipfix-mediation-protocol-00.txt
X-BeenThere: ipfix@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: IPFIX WG discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 06 Dec 2011 14:52:46 -0000

Dear all,

This version takes into account all the feedback received from Paul 
Aitken (I replied to Paul's email to the list yesterday).
On the top of that, the timestamps issue has been fixed by Brian.
Note that some points, which might require some discussions, have been 
listed in the open issues in the draft.

Regards, Benoit.
> A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IP Flow Information Export Working Group of the IETF.
>
> 	Title           : Specification of the Protocol for IPFIX Mediation
> 	Author(s)       : Benoit Claise
>                            Atsushi Kobayashi
>                            Brian Trammell
> 	Filename        : draft-ietf-ipfix-mediation-protocol-00.txt
> 	Pages           : 33
> 	Date            : 2011-12-06
>
>          This document specifies the IP Flow Information Export
>          (IPFIX) protocol specific to Mediation.
>
>
> A URL for this Internet-Draft is:
> http://www.ietf.org/internet-drafts/draft-ietf-ipfix-mediation-protocol-00.txt
>
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/
>
> This Internet-Draft can be retrieved at:
> ftp://ftp.ietf.org/internet-drafts/draft-ietf-ipfix-mediation-protocol-00.txt
>
> _______________________________________________
> IPFIX mailing list
> IPFIX@ietf.org
> https://www.ietf.org/mailman/listinfo/ipfix
>
>


From acmorton@att.com  Tue Dec  6 14:33:17 2011
Return-Path: 
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 B757521F847B; Tue,  6 Dec 2011 14:33:17 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -105.796
X-Spam-Level: 
X-Spam-Status: No, score=-105.796 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MSGID_FROM_MTA_HEADER=0.803, RCVD_IN_DNSWL_MED=-4, 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 vRXDY1lO88X1; Tue,  6 Dec 2011 14:33:17 -0800 (PST)
Received: from mail119.messagelabs.com (mail119.messagelabs.com [216.82.241.195]) by ietfa.amsl.com (Postfix) with ESMTP id 043A721F8C5E; Tue,  6 Dec 2011 14:33:16 -0800 (PST)
X-Env-Sender: acmorton@att.com
X-Msg-Ref: server-7.tower-119.messagelabs.com!1323210795!4533960!1
X-Originating-IP: [144.160.20.145]
X-StarScan-Version: 6.4.2; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2551 invoked from network); 6 Dec 2011 22:33:15 -0000
Received: from sbcsmtp6.sbc.com (HELO mlpd192.enaf.sfdc.sbc.com) (144.160.20.145) by server-7.tower-119.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 6 Dec 2011 22:33:15 -0000
Received: from enaf.sfdc.sbc.com (localhost.localdomain [127.0.0.1]) by mlpd192.enaf.sfdc.sbc.com (8.14.5/8.14.5) with ESMTP id pB6MXgUR019102; Tue, 6 Dec 2011 17:33:43 -0500
Received: from alpd052.aldc.att.com (alpd052.aldc.att.com [130.8.42.31]) by mlpd192.enaf.sfdc.sbc.com (8.14.5/8.14.5) with ESMTP id pB6MXcdX019033; Tue, 6 Dec 2011 17:33:39 -0500
Received: from aldc.att.com (localhost.localdomain [127.0.0.1]) by alpd052.aldc.att.com (8.14.4/8.14.4) with ESMTP id pB6MXAKI018895; Tue, 6 Dec 2011 17:33:10 -0500
Received: from mailgw1.maillennium.att.com (dns.maillennium.att.com [135.25.114.99]) by alpd052.aldc.att.com (8.14.4/8.14.4) with ESMTP id pB6MWsKh018012; Tue, 6 Dec 2011 17:33:01 -0500
Message-Id: <201112062233.pB6MWsKh018012@alpd052.aldc.att.com>
Received: from acmt.att.com (martym.mt.att.com[135.16.251.71](misconfigured sender)) by maillennium.att.com (mailgw1) with SMTP id <20111206223139gw100e4lfne>; Tue, 6 Dec 2011 22:31:39 +0000
X-Originating-IP: [135.16.251.71]
X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9
Date: Tue, 06 Dec 2011 17:33:49 -0500
To: bmwg@ietf.org
From: Al Morton 
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Cc: ipfix@ietf.org
Subject: [IPFIX] WGLC: draft-ietf-bmwg-ipflow-meth-05
X-BeenThere: ipfix@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: IPFIX WG discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 06 Dec 2011 22:33:17 -0000

BMWG,
CC: IPFIX WG,

This message begins the *fourth* WG Last call on the draft:

IP Flow Information Accounting and Export Benchmarking Methodology

A URL for this draft is:
http://tools.ietf.org/html/draft-ietf-bmwg-ipflow-meth-05

The Last Call will end on January 1, 2012.

We have discussed this draft in the working group for
over three years and made many improvements.
We have also benefited from review by folks from IPFIX WG.

*We have now looked in detail at comments from the 3rd WGLC
and their resolution, including 5 open issues identified
and resolved on the list.*

I now ask everyone to consider items where they commented earlier,
and make sure that the resolutions are satisfactory (and thanks to
those who did this during the second WGLC).

Please weigh-in on whether or not this Internet-Draft
should be given to the Area Directors and IESG for consideration and
publication as an Informational RFC.  Send your comments
to this list and/or acmorton@att.com.

Al
bmwg chair


From hendrik.scholz@voipfuture.com  Wed Dec  7 08:11:04 2011
Return-Path: 
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 6AF1A21F8C12 for ; Wed,  7 Dec 2011 08:11:04 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.185
X-Spam-Level: 
X-Spam-Status: No, score=-0.185 tagged_above=-999 required=5 tests=[BAYES_40=-0.185]
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 B5GVNiQ9Z+3a for ; Wed,  7 Dec 2011 08:11:03 -0800 (PST)
Received: from mail.voipfuture.com (mail.voipfuture.com [212.126.220.242]) by ietfa.amsl.com (Postfix) with ESMTP id 2EB2921F8C0C for ; Wed,  7 Dec 2011 08:11:03 -0800 (PST)
X-Footer: dm9pcGZ1dHVyZS5jb20=
Received: from [192.168.1.249] ([192.168.1.1]) (authenticated user hscholz@voipfuture.com) by mail.voipfuture.com (Kerio Connect 7.2.3 patch 1) (using TLSv1/SSLv3 with cipher AES256-SHA (256 bits)); Wed, 7 Dec 2011 17:08:40 +0100
Message-ID: <4EDF900D.50505@voipfuture.com>
Date: Wed, 07 Dec 2011 17:10:53 +0100
From: Hendrik Scholz 
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:8.0) Gecko/20111124 Thunderbird/8.0
MIME-Version: 1.0
To: ipfix@ietf.org
X-Enigmail-Version: 1.4a1pre
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 8bit
Subject: [IPFIX] sip-msg-02 SIP messages and aggregation
X-BeenThere: ipfix@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: IPFIX WG discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 07 Dec 2011 16:11:04 -0000

Hi!

My main interest is to write a single data record describing an
entire SIP dialog (e.g. a call between two parties) and not
a single SIP message.

Below are numerous points where I feel the current definition
may clash with that use case.

2.1 sipObservationType

There is a 'receiver' and 'sender' metering process type for
metering processes co-located with the SIP entity.
I case I want to aggregate multiple SIP messages into a single
entry what should I set here?
It does make a different whether the monitoring process was
co-located with the device or whether it pass 'mid-point'
(option 3 aka 'passive').

Another way of looking at the sipObservationType would be
'unknown', 'co-located' (aka 'end-point') and 'mid-point'.
This drops the 'sender'/'receiver' differentiation.
Could we extend it to have both bits of information encoded
in the sipObservationType?

2.5. sipFromURI
2.7. sipToURI

Would this include URI parameters?
sample: sip:user:password@host:port;uri-parameters?headers

This effectively duplicates the 2.6. sipFromTag and
2.8. sipToTag.

A system may opt to display sipFromURI and sipToURI which
may (rare case I guess) include the password. Often
sip:user@host would be enough, although it may be up
to the collector to remove unneeded bits.

2.9 sipCallId

Session-ID as defined in draft-kaplan-dispatch-session-id-03
won't be added for now as it's not a WG item, correct?

2.10. sipResponseStatus

In case multiple SIP messages are aggregated into one record
this should be allowed to hold the 'final response', e.g.
a 408 timeout even multiple callees responded with 486 or
early media (180, 183, ...).

3.1. sipContactURI

In the 'aggregated information' usage scenario there would
be (at least) two Contact URIs, e.g. named sipCallerURI and
sipCalleeURI (or UAS/UAC).

4. Template additions

For an aggregated 'sip session' the template would not only
need the observationTimeMilliseconds IE but also
a start/end time plus an optional PostDialDelay etc.
Essentially everything to calculate the RFC6076 SIP
performance metrics.

Finally we should allow SIPS URIs in the SIP URI fields or
point out that this is not intended.

Should I contribute a separate document with additional
Information Elements needed to describe SIP sessions
and a matching recommended template?

Regards,
 Hendrik

-- 
VOIPFUTURE GmbH   Wendenstraße 4   20097 Hamburg   Germany
Phone +49 40 688 900 163    Fax +49 40 688 900 199
Email hendrik.scholz@voipfuture.com   Web http://www.voipfuture.com

CEO Jan Bastian
Commercial Court AG Hamburg   HRB 109896
VAT ID DE263738086


From hendrik.scholz@voipfuture.com  Wed Dec  7 08:16:08 2011
Return-Path: 
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 D747221F8C5C for ; Wed,  7 Dec 2011 08:16:08 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.392
X-Spam-Level: 
X-Spam-Status: No, score=-1.392 tagged_above=-999 required=5 tests=[AWL=1.207,  BAYES_00=-2.599]
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 x1t8RBO5qFFq for ; Wed,  7 Dec 2011 08:16:08 -0800 (PST)
Received: from mail.voipfuture.com (mail.voipfuture.com [212.126.220.242]) by ietfa.amsl.com (Postfix) with ESMTP id ECF9321F8C50 for ; Wed,  7 Dec 2011 08:16:07 -0800 (PST)
X-Footer: dm9pcGZ1dHVyZS5jb20=
Received: from [192.168.1.249] ([192.168.1.1]) (authenticated user hscholz@voipfuture.com) by mail.voipfuture.com (Kerio Connect 7.2.3 patch 1) (using TLSv1/SSLv3 with cipher AES256-SHA (256 bits)); Wed, 7 Dec 2011 17:13:47 +0100
Message-ID: <4EDF9140.7070705@voipfuture.com>
Date: Wed, 07 Dec 2011 17:16:00 +0100
From: Hendrik Scholz 
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:8.0) Gecko/20111124 Thunderbird/8.0
MIME-Version: 1.0
To: ipfix@ietf.org
X-Enigmail-Version: 1.4a1pre
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 8bit
Subject: [IPFIX] RTP media stream template?
X-BeenThere: ipfix@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: IPFIX WG discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 07 Dec 2011 16:16:09 -0000

Hi!

Is anybody working on a template and related IEs for RTP media streams?
I am happy to contribute and/or author the needed documents.

The use cases for this include active VoIP components which handle
RTP streams and want to provide data records as well as passive
monitoring systems which are build to monitor RTP streams.
IEs include general RTP information (source, destination, codec)
as well as IP transport quality (jitter, packet loss, ..) and
higher-level metrics such as R-Factor and MOS value where available.

The template should allow both data records on entire streams (i.e.
part of calls minutes or even hours long) as well as fixed time slices
such as 10 seconds to allow monitoring with a high granularity.

Regards,
 Hendrik

-- 
VOIPFUTURE GmbH   Wendenstraße 4   20097 Hamburg   Germany
Phone +49 40 688 900 163    Fax +49 40 688 900 199
Email hendrik.scholz@voipfuture.com   Web http://www.voipfuture.com

CEO Jan Bastian
Commercial Court AG Hamburg   HRB 109896
VAT ID DE263738086


From carter@qosient.com  Wed Dec  7 08:30:48 2011
Return-Path: 
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 3148C21F8BE5 for ; Wed,  7 Dec 2011 08:30:48 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.599
X-Spam-Level: 
X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
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 9wPEaxa+ksXi for ; Wed,  7 Dec 2011 08:30:47 -0800 (PST)
Received: from relay02.pair.com (relay02.pair.com [209.68.5.16]) by ietfa.amsl.com (Postfix) with SMTP id 2EA6621F8C09 for ; Wed,  7 Dec 2011 08:30:47 -0800 (PST)
Received: (qmail 19195 invoked from network); 7 Dec 2011 16:30:45 -0000
Received: from 207.237.36.98 (HELO thoth.newyork.qosient.com) (207.237.36.98) by relay02.pair.com with SMTP; 7 Dec 2011 16:30:45 -0000
X-pair-Authenticated: 207.237.36.98
Mime-Version: 1.0 (Apple Message framework v1251.1)
Content-Type: multipart/signed; boundary="Apple-Mail=_19DBE804-0FED-4EA4-AE70-0A77839321B2"; protocol="application/pkcs7-signature"; micalg=sha1
From: Carter Bullard 
In-Reply-To: <4EDF9140.7070705@voipfuture.com>
Date: Wed, 7 Dec 2011 11:30:44 -0500
Message-Id: <83ABA88F-E8B8-4F2E-8FC8-04FA17FA6346@qosient.com>
References: <4EDF9140.7070705@voipfuture.com>
To: Hendrik Scholz 
X-Mailer: Apple Mail (2.1251.1)
Cc: ipfix@ietf.org
Subject: Re: [IPFIX] RTP media stream template?
X-BeenThere: ipfix@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: IPFIX WG discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 07 Dec 2011 16:30:48 -0000

--Apple-Mail=_19DBE804-0FED-4EA4-AE70-0A77839321B2
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=iso-8859-1

Hey Hendrik,
Argus has RTP specific flow records, with its own IEs for reporting =
attributes
and metrics for the media streams.   The argus sensor does RTP discovery
on the fly, generating the extended flow attributes without =
configuration.

The argus DSRs provide the RTP specific information, such as codec, as
well as jitter, ( adjusting for silence suppression when encountered ), =
loss
and out of order indications, and the argus-client aggregation deals =
with
handling both entire streams and fixed/variable time slices, no problem.

Argus is not IPFIX, but you may find the argus approach useful.

http://qosient.com/argus

Carter

Carter Bullard
CEO/President
QoSient, LLC
150 E 57th Street Suite 12D
New York, New York  10022

+1 212 588-9133 Phone
+1 212 588-9134 Fax

On Dec 7, 2011, at 11:16 AM, Hendrik Scholz wrote:

> Hi!
>=20
> Is anybody working on a template and related IEs for RTP media =
streams?
> I am happy to contribute and/or author the needed documents.
>=20
> The use cases for this include active VoIP components which handle
> RTP streams and want to provide data records as well as passive
> monitoring systems which are build to monitor RTP streams.
> IEs include general RTP information (source, destination, codec)
> as well as IP transport quality (jitter, packet loss, ..) and
> higher-level metrics such as R-Factor and MOS value where available.
>=20
> The template should allow both data records on entire streams (i.e.
> part of calls minutes or even hours long) as well as fixed time slices
> such as 10 seconds to allow monitoring with a high granularity.
>=20
> Regards,
> Hendrik
>=20
> --=20
> VOIPFUTURE GmbH   Wendenstra=DFe 4   20097 Hamburg   Germany
> Phone +49 40 688 900 163    Fax +49 40 688 900 199
> Email hendrik.scholz@voipfuture.com   Web http://www.voipfuture.com
>=20
> CEO Jan Bastian
> Commercial Court AG Hamburg   HRB 109896
> VAT ID DE263738086
>=20
> _______________________________________________
> IPFIX mailing list
> IPFIX@ietf.org
> https://www.ietf.org/mailman/listinfo/ipfix
>=20


--Apple-Mail=_19DBE804-0FED-4EA4-AE70-0A77839321B2
Content-Disposition: attachment;
	filename=smime.p7s
Content-Type: application/pkcs7-signature;
	name=smime.p7s
Content-Transfer-Encoding: base64

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIMRjCCBVAw
ggQ4oAMCAQICEE/C1XPaEv5Xc80XjVqbwwowDQYJKoZIhvcNAQEFBQAwgd0xCzAJBgNVBAYTAlVT
MRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29y
azE7MDkGA1UECxMyVGVybXMgb2YgdXNlIGF0IGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9ycGEg
KGMpMDkxHjAcBgNVBAsTFVBlcnNvbmEgTm90IFZhbGlkYXRlZDE3MDUGA1UEAxMuVmVyaVNpZ24g
Q2xhc3MgMSBJbmRpdmlkdWFsIFN1YnNjcmliZXIgQ0EgLSBHMzAeFw0xMTA0MTQwMDAwMDBaFw0x
MjA0MTMyMzU5NTlaMIIBEzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlT
aWduIFRydXN0IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9S
UEEgSW5jb3JwLiBieSBSZWYuLExJQUIuTFREKGMpOTgxHjAcBgNVBAsTFVBlcnNvbmEgTm90IFZh
bGlkYXRlZDEzMDEGA1UECxMqRGlnaXRhbCBJRCBDbGFzcyAxIC0gTmV0c2NhcGUgRnVsbCBTZXJ2
aWNlMRcwFQYDVQQDFA5DYXJ0ZXIgQnVsbGFyZDEhMB8GCSqGSIb3DQEJARYSY2FydGVyQHFvc2ll
bnQuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAnUsVMagrR+kSPj9tNNsMP6ZO
CRf4x70f3vT5OerV6rikEAz4XYJ+iv5Y6FiY5wjr2ez4BTrEuKwhAJN+aPSXHBW4cBZgB0J7mHwF
yJpY/vhhy2RrfugdCXjotFySXzevQHCfON4htlh+I3DYhN6LXmeBnnPtGz+J4mNZqdimZVlcdXqV
h0m7ysvdFkClht66vEvF+WObwLEpg3LIaFzTZBWpAiQ1FPIDJJd6uU//96grDvRy+D0oNjCkxmBp
bCkG0w1jaOuay6o62xRh7H41CxCRljzYjy3H4SwRYlYBwtqZuXg0YOI0OHdSuie6UyrUgmT+3S1U
FPiGz9yP9hninQIDAQABo4HSMIHPMAkGA1UdEwQCMAAwRAYDVR0gBD0wOzA5BgtghkgBhvhFAQcX
ATAqMCgGCCsGAQUFBwIBFhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhMAsGA1UdDwQEAwIF
oDAdBgNVHSUEFjAUBggrBgEFBQcDBAYIKwYBBQUHAwIwUAYDVR0fBEkwRzBFoEOgQYY/aHR0cDov
L2luZGMxZGlnaXRhbGlkLWczLWNybC52ZXJpc2lnbi5jb20vSW5kQzFEaWdpdGFsSUQtRzMuY3Js
MA0GCSqGSIb3DQEBBQUAA4IBAQBSg1+LGDk7EKu1hYCrpHEZVHY3I+850erL2DxLtfgzldWZPLYr
NpVa8wH5XTDhaFNLQgWwLMGfs8sJPkqXm2TfZfG7BkJWLtubW3Jw5jZ//Eygbae2IOU0bm1tAaG2
uoreBROJ5PU1ykK8aTnbNZxN772otsdHQ54gXd2wpPUoDoT740WzsdTeSI0ZXU+3J7RPbC0VHNfI
E88GgkTYBD5Xk3Ro+BSCBOh4XAA1ypHBZh2OX8C4syhPp6yfGWvwvqJ+oV5lkbAcO6FkeBlvb/Fi
XPa35ynGIIpntzpqOvr+0XJs8xq7hE8KU/QUNE6fa0gZyjxBVcbw89mv4lQx4FSOMIIG7jCCBdag
AwIBAgIQcRVmBUrkkSFN6bxE+azT3DANBgkqhkiG9w0BAQUFADCByjELMAkGA1UEBhMCVVMxFzAV
BgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTow
OAYDVQQLEzEoYykgMTk5OSBWZXJpU2lnbiwgSW5jLiAtIEZvciBhdXRob3JpemVkIHVzZSBvbmx5
MUUwQwYDVQQDEzxWZXJpU2lnbiBDbGFzcyAxIFB1YmxpYyBQcmltYXJ5IENlcnRpZmljYXRpb24g
QXV0aG9yaXR5IC0gRzMwHhcNMDkwNTAxMDAwMDAwWhcNMTkwNDMwMjM1OTU5WjCB3TELMAkGA1UE
BhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBO
ZXR3b3JrMTswOQYDVQQLEzJUZXJtcyBvZiB1c2UgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29t
L3JwYSAoYykwOTEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5WZXJp
U2lnbiBDbGFzcyAxIEluZGl2aWR1YWwgU3Vic2NyaWJlciBDQSAtIEczMIIBIjANBgkqhkiG9w0B
AQEFAAOCAQ8AMIIBCgKCAQEA7cRH3yooHXwGa7vXITLJbBOP6bGNQU4099oL42r6ZYggCxET6Zvg
SU6Lb9UB0F8NR5GKWkx0Pj/GkQm7TDSejW6hglFi92l2WJYHr54UGAdPWr2f0jGyVBlzRmoZQhHs
EnMhjfXcMM3l2VYKMcU2bSkUl70t2olHGYjYSwQ967Y8Zx50ABMN0Ibak2f4MwOuGjxraXj2wCyO
4YM/d/mZ//6fUlrCtIcK2GypR8FUKWVDPkrAlh/Brfd3r2yxBF6+wbaULZeQLSfSux7pg2qE9sSy
riMGZSalJ1grByK0b6ZiSBp38tVQJ5op05b7KPW6JHZi44xZ6/tu1ULEvkHH9QIDAQABo4ICuTCC
ArUwNAYIKwYBBQUHAQEEKDAmMCQGCCsGAQUFBzABhhhodHRwOi8vb2NzcC52ZXJpc2lnbi5jb20w
EgYDVR0TAQH/BAgwBgEB/wIBADBwBgNVHSAEaTBnMGUGC2CGSAGG+EUBBxcBMFYwKAYIKwYBBQUH
AgEWHGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9jcHMwKgYIKwYBBQUHAgIwHhocaHR0cHM6Ly93
d3cudmVyaXNpZ24uY29tL3JwYTA0BgNVHR8ELTArMCmgJ6AlhiNodHRwOi8vY3JsLnZlcmlzaWdu
LmNvbS9wY2ExLWczLmNybDAOBgNVHQ8BAf8EBAMCAQYwbgYIKwYBBQUHAQwEYjBgoV6gXDBaMFgw
VhYJaW1hZ2UvZ2lmMCEwHzAHBgUrDgMCGgQUS2u5KJYGDLvQUjibKaxLB4shBRgwJhYkaHR0cDov
L2xvZ28udmVyaXNpZ24uY29tL3ZzbG9nbzEuZ2lmMC4GA1UdEQQnMCWkIzAhMR8wHQYDVQQDExZQ
cml2YXRlTGFiZWw0LTIwNDgtMTE4MB0GA1UdDgQWBBR5R2EIQf04BKJL57XM9UP2SSsR+DCB8QYD
VR0jBIHpMIHmoYHQpIHNMIHKMQswCQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4x
HzAdBgNVBAsTFlZlcmlTaWduIFRydXN0IE5ldHdvcmsxOjA4BgNVBAsTMShjKSAxOTk5IFZlcmlT
aWduLCBJbmMuIC0gRm9yIGF1dGhvcml6ZWQgdXNlIG9ubHkxRTBDBgNVBAMTPFZlcmlTaWduIENs
YXNzIDEgUHVibGljIFByaW1hcnkgQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkgLSBHM4IRAItbdVaE
VIULAM+vOEjOsaQwDQYJKoZIhvcNAQEFBQADggEBADlNz0GZgbWpBbVSOOk5hIls5DSoWufYbAlM
JBq6WaSHO3Mh8ZOBz79oY1pn/jWFK6HDXaNKwjoZ3TDWzE3v8dKBl8pUWkO/N4t6jhmND0OojPKv
YLMVirOVnDzgnrMnmKQ1chfl/Cpdh9OKDcLRRSr4wPSsKpM61a4ScAjr+zvid+zoK2Q1ds262uDR
yxTWcVibvtU+fbbZ6CTFJGZMXZEfdrMXPn8NxiGJL7M3uKH/XLJtSd5lUkL7DojS7Uodv0vj+Mxy
+kgOZY5JyNb4mZg7t5Q+MXEGh/psWVMu198r7V9jAKwV7QO4VRaMxmgD5yKocwuxvKDaUljdCg5/
wYIxggSLMIIEhwIBATCB8jCB3TELMAkGA1UEBhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMu
MR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTswOQYDVQQLEzJUZXJtcyBvZiB1c2Ug
YXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYSAoYykwOTEeMBwGA1UECxMVUGVyc29uYSBO
b3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5WZXJpU2lnbiBDbGFzcyAxIEluZGl2aWR1YWwgU3Vic2Ny
aWJlciBDQSAtIEczAhBPwtVz2hL+V3PNF41am8MKMAkGBSsOAwIaBQCgggJtMBgGCSqGSIb3DQEJ
AzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTExMTIwNzE2MzA0NVowIwYJKoZIhvcNAQkE
MRYEFFAgp0yMMNdt0Z8m3sFeD+ANZczYMIIBAwYJKwYBBAGCNxAEMYH1MIHyMIHdMQswCQYDVQQG
EwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0IE5l
dHdvcmsxOzA5BgNVBAsTMlRlcm1zIG9mIHVzZSBhdCBodHRwczovL3d3dy52ZXJpc2lnbi5jb20v
cnBhIChjKTA5MR4wHAYDVQQLExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxNzA1BgNVBAMTLlZlcmlT
aWduIENsYXNzIDEgSW5kaXZpZHVhbCBTdWJzY3JpYmVyIENBIC0gRzMCEE/C1XPaEv5Xc80XjVqb
wwowggEFBgsqhkiG9w0BCRACCzGB9aCB8jCB3TELMAkGA1UEBhMCVVMxFzAVBgNVBAoTDlZlcmlT
aWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTswOQYDVQQLEzJUZXJt
cyBvZiB1c2UgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYSAoYykwOTEeMBwGA1UECxMV
UGVyc29uYSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5WZXJpU2lnbiBDbGFzcyAxIEluZGl2aWR1
YWwgU3Vic2NyaWJlciBDQSAtIEczAhBPwtVz2hL+V3PNF41am8MKMA0GCSqGSIb3DQEBAQUABIIB
AC1NUeiVwHPPXvOGp11nhzDRQySnoeN3yLUu1h4j0owMdOYv6AsVl6YZMNY5HIwZgS/UlBJ16B7t
2HBwBf/YX8Updviv1gKHYUwTJj1Uoup7TfqWO9tqCiVrpQGv3DVxzhsc/zltqlc11U02lAniAC23
YJ6omwv9aV0JuPCzOosZNTspU4GXpBANDJp/E9BArO9GyftiiAE7ranIVK2PAFkCEPcWKOWQtvmn
2xBj1SxYnVLaJf9Ettm5go+qxg1Wqe/T8B479Q/QubcFZFn5ezeS0L+C13W0y42cz9SgO9VHlACS
LFxT6mUn1/YLXeGTZufFFIaV+N9nqMpS8xn1HRIAAAAAAAA=

--Apple-Mail=_19DBE804-0FED-4EA4-AE70-0A77839321B2--

From bclaise@cisco.com  Fri Dec 16 01:08:15 2011
Return-Path: 
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 EB32221F8B20 for ; Fri, 16 Dec 2011 01:08:14 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.367
X-Spam-Level: 
X-Spam-Status: No, score=-2.367 tagged_above=-999 required=5 tests=[AWL=0.231,  BAYES_00=-2.599, HTML_MESSAGE=0.001]
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 uC6KR6VSMX+y for ; Fri, 16 Dec 2011 01:08:14 -0800 (PST)
Received: from av-tac-bru.cisco.com (weird-brew.cisco.com [144.254.15.118]) by ietfa.amsl.com (Postfix) with ESMTP id 0AE3521F8AE6 for ; Fri, 16 Dec 2011 01:08:13 -0800 (PST)
X-TACSUNS: Virus Scanned
Received: from strange-brew.cisco.com (localhost.cisco.com [127.0.0.1]) by av-tac-bru.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id pBG98Cgs029084 for ; Fri, 16 Dec 2011 10:08:12 +0100 (CET)
Received: from [10.60.67.87] (ams-bclaise-8916.cisco.com [10.60.67.87]) by strange-brew.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id pBG98BYc002600 for ; Fri, 16 Dec 2011 10:08:12 +0100 (CET)
Message-ID: <4EEB0A7B.9090007@cisco.com>
Date: Fri, 16 Dec 2011 10:08:11 +0100
From: Benoit Claise 
User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:8.0) Gecko/20111105 Thunderbird/8.0
MIME-Version: 1.0
To: "ipfix@ietf.org" 
References: 
In-Reply-To: 
X-Forwarded-Message-Id: 
Content-Type: multipart/alternative; boundary="------------040000090605040409040604"
Subject: [IPFIX] Authors list for RFCbis
X-BeenThere: ipfix@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: IPFIX WG discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 16 Dec 2011 09:08:15 -0000

This is a multi-part message in MIME format.
--------------040000090605040409040604
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

Dear all,

Knowing that the authors list is sometimes a sensitive topic, I've been 
seeking for advice and guidelines when publishing draft standards and I 
received the following answer:

    The most used current practice is to list on the first page only the
    editors of the latest version and to start the Acknowledgments
    section by mentioning the full list of the authors of the previous
    RFC and mention that this work is based upon and develops the
    original RFC.


I thought I would share this information with the group.

Regards, Benoit.



--------------040000090605040409040604
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit


  

    
  
  
    Dear all,

    

    Knowing that the authors list is sometimes a sensitive topic, I've
    been seeking for advice and guidelines when publishing draft
    standards and I received the following answer:

    

    
The most used current practice is to list on the first
      page only the editors of the latest version and to start the
      Acknowledgments section by mentioning the full list of the authors
      of the previous RFC and
      mention that this work is based upon and develops the original
      RFC. 

    

    

    I thought I would share this information with the group.

    

    Regards, Benoit.

    

    

  


--------------040000090605040409040604--

From bclaise@cisco.com  Mon Dec 19 01:50:53 2011
Return-Path: 
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 63FE621F84C3 for ; Mon, 19 Dec 2011 01:50:53 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.598
X-Spam-Level: 
X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001]
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 R3uam2YLJxFd for ; Mon, 19 Dec 2011 01:50:52 -0800 (PST)
Received: from av-tac-bru.cisco.com (weird-brew.cisco.com [144.254.15.118]) by ietfa.amsl.com (Postfix) with ESMTP id 2270621F851A for ; Mon, 19 Dec 2011 01:50:48 -0800 (PST)
X-TACSUNS: Virus Scanned
Received: from strange-brew.cisco.com (localhost.cisco.com [127.0.0.1]) by av-tac-bru.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id pBJ9oesw020428; Mon, 19 Dec 2011 10:50:40 +0100 (CET)
Received: from [10.60.67.89] (ams-bclaise-8918.cisco.com [10.60.67.89]) by strange-brew.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id pBJ9od7N019722; Mon, 19 Dec 2011 10:50:40 +0100 (CET)
Message-ID: <4EEF08EF.1040004@cisco.com>
Date: Mon, 19 Dec 2011 10:50:39 +0100
From: Benoit Claise 
User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:8.0) Gecko/20111105 Thunderbird/8.0
MIME-Version: 1.0
To: Nevil Brownlee 
References: <4ECABFF3.6040206@auckland.ac.nz>
In-Reply-To: <4ECABFF3.6040206@auckland.ac.nz>
Content-Type: multipart/alternative; boundary="------------050406040409050504030503"
Cc: IPFIX Working Group 
Subject: Re: [IPFIX] WG Last Call for  draft-ietf-ipfix-rfc5815bis-00
X-BeenThere: ipfix@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: IPFIX WG discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 19 Dec 2011 09:50:53 -0000

This is a multi-part message in MIME format.
--------------050406040409050504030503
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

Dear all,

Apparently, this WGLC is finished.
That would be great if we could advance this draft.
As a reminder of the different references between the drafts:

draft-ietf-ipfix-configuration-model-10.txt  status is MISSREF on draft-ietf-ipfix-psamp-mib

draft-ietf-ipfix-psamp-mib-04.txt    status is Waiting for AD Go-Ahead, because of the following normative reference

       [I-D.dkcm-ipfix-rfc5815bis]
                   Dietz, T., Kobayashi, A., Claise, B., and G. Muenz,
                   "Definitions of Managed Objects for IP Flow Information
                   Export", draft-dkcm-ipfix-rfc5815bis-00 (work in
                   progress), October 2011.

                Note: This reference is actually 
draft-ietf-ipfix-rfc5815bis-00

Conclusion: draft-ietf-ipfix-rfc5815bis-00 is the bottleneck to publish 
3 RFCs

Regards, Benoit.
>
> Hi all:
>
> As discussed at last week's meeting, the WG Last Call for this
> draft (updated version of the IPFIX MIB) starts now, and will
> end on Wednesday, 7 December.  If you have comments on this,
> please email them to the IPFIX list.
>
> Cheers, Nevil
>


--------------050406040409050504030503
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit


  
    
  
  
    Dear all,

    

    Apparently, this WGLC is finished.

    That would be great if we could advance this draft.

    As a reminder of the different references between the drafts:

    
draft-ietf-ipfix-configuration-model-10.txt status is MISSREF on draft-ietf-ipfix-psamp-mib 


    
draft-ietf-ipfix-psamp-mib-04.txt status is Waiting for AD Go-Ahead, because of the following normative reference


    

      
  [I-D.dkcm-ipfix-rfc5815bis]
              Dietz, T., Kobayashi, A., Claise, B., and G. Muenz,
              "Definitions of Managed Objects for IP Flow Information
              Export", draft-dkcm-ipfix-rfc5815bis-00 (work in
              progress), October 2011.

    

                   Note: This reference is actually
    draft-ietf-ipfix-rfc5815bis-00

    

    Conclusion: draft-ietf-ipfix-rfc5815bis-00 is the bottleneck to
    publish 3 RFCs

    

    Regards, Benoit.

    

      

      Hi all:
      

      

      As discussed at last week's meeting, the WG Last Call for this
      

      draft (updated version of the IPFIX MIB) starts now, and will
      

      end on Wednesday, 7 December.  If you have comments on this,
      

      please email them to the IPFIX list.
      

      

      Cheers, Nevil
      

      

    

    

  


--------------050406040409050504030503--

From paitken@cisco.com  Mon Dec 19 03:08:12 2011
Return-Path: 
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 376B921F8B53 for ; Mon, 19 Dec 2011 03:08:12 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.598
X-Spam-Level: 
X-Spam-Status: No, score=-10.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8]
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 z13Xz4q+y9Qn for ; Mon, 19 Dec 2011 03:08:11 -0800 (PST)
Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by ietfa.amsl.com (Postfix) with ESMTP id A537721F8B52 for ; Mon, 19 Dec 2011 03:08:10 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=paitken@cisco.com; l=8555; q=dns/txt; s=iport; t=1324292890; x=1325502490; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to; bh=hKEnK2vjPqNZrmC3Nzi6rYJFqEuQQ/QilV3igOJ5ARQ=; b=c5AP7P9Y5sXZT7w214MeKWBHIUKpnLp8KdpNDnrER3Qv6dWwu0QsD3L3 Bzj8Z3ecV8Eyr/A54e4LcDn1jm+emJk0oUSNL4li2aa8EukW6S1STZixj wN08FPUReZ/AOgQvx5l/eYeI2kmnDi9lvxIuxD9e1tLDnpECabglgm69b s=;
X-IronPort-AV: E=Sophos;i="4.71,375,1320624000";  d="scan'208,217";a="124116793"
Received: from ams-core-1.cisco.com ([144.254.72.81]) by ams-iport-1.cisco.com with ESMTP; 19 Dec 2011 11:08:08 +0000
Received: from [10.55.94.100] (dhcp-10-55-94-100.cisco.com [10.55.94.100]) by ams-core-1.cisco.com (8.14.3/8.14.3) with ESMTP id pBJB88It020693; Mon, 19 Dec 2011 11:08:08 GMT
Message-ID: <4EEF1B1A.3040001@cisco.com>
Date: Mon, 19 Dec 2011 11:08:10 +0000
From: Paul Aitken 
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.23) Gecko/20110922 Lightning/1.0b2 Thunderbird/3.1.15
MIME-Version: 1.0
To: ipfix@ietf.org
References: <4ECABFF3.6040206@auckland.ac.nz> <4EEF08EF.1040004@cisco.com>
In-Reply-To: <4EEF08EF.1040004@cisco.com>
Content-Type: multipart/alternative; boundary="------------090403090603020302070602"
Subject: Re: [IPFIX] WG Last Call for draft-ietf-ipfix-rfc5815bis-00
X-BeenThere: ipfix@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: IPFIX WG discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 19 Dec 2011 11:08:12 -0000

This is a multi-part message in MIME format.
--------------090403090603020302070602
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

Benoit,

That's nice. However, I didn't see _any_ feedback.

Did anyone review it?

So let me do that now:



Firstly, you haven't addressed _any_ of the 5815 errata. There are five. 
Please address them in -bis.

     
http://www.rfc-editor.org/errata_search.php?rfc=5815&rec_status=15&presentation=table



Otherwise my comments are only editorial:



Section 6:

     "{ ipfixSelectorFunctions 1}"

     - Whitespace imbalance around the { }.



Section 6:

     "The specification of new MIB objects SHOULD follow the structure 
specified in the next Section"

     - The next section is "6.1 The Selector Functions". Perhaps you 
mean "8.  MIB Definitions"? So it would be better to state the exact 
section number.



Section 6:

     - as a general comment, this would benefit from being broken into a 
few smaller paragraphs to improve readability.



Section 7.1:

     "the ENTITY MIB module[RFC4133]"

     - the reference runs into the text. Add space.



Section 8.2:

     Description

     "subject to Expert Review  RFC 5226"

     - too much space this time! :-)


     "RFC [NewRFCNumber]"

     - to make the RFC Editor's job easier, use either "NewRFCNumber" or 
"THISrfc", not both.



Section 10:

     Further on, IANA will maintain ...

     "Further on" implies "at some time in the future", which seems 
vague. I'd just drop those words and state, "IANA will create and 
maintain ...".



P.


On 19/12/11 09:50, Benoit Claise wrote:
> Dear all,
>
> Apparently, this WGLC is finished.
> That would be great if we could advance this draft.
> As a reminder of the different references between the drafts:
> draft-ietf-ipfix-configuration-model-10.txt  status is MISSREF on draft-ietf-ipfix-psamp-mib
> draft-ietf-ipfix-psamp-mib-04.txt    status is Waiting for AD Go-Ahead, because of the following normative reference
>
>        [I-D.dkcm-ipfix-rfc5815bis]
>                    Dietz, T., Kobayashi, A., Claise, B., and G. Muenz,
>                    "Definitions of Managed Objects for IP Flow Information
>                    Export", draft-dkcm-ipfix-rfc5815bis-00 (work in
>                    progress), October 2011.
>
>                Note: This reference is actually 
> draft-ietf-ipfix-rfc5815bis-00
>
> Conclusion: draft-ietf-ipfix-rfc5815bis-00 is the bottleneck to 
> publish 3 RFCs
>
> Regards, Benoit.
>>
>> Hi all:
>>
>> As discussed at last week's meeting, the WG Last Call for this
>> draft (updated version of the IPFIX MIB) starts now, and will
>> end on Wednesday, 7 December.  If you have comments on this,
>> please email them to the IPFIX list.
>>
>> Cheers, Nevil
>>
>
>
> _______________________________________________
> IPFIX mailing list
> IPFIX@ietf.org
> https://www.ietf.org/mailman/listinfo/ipfix


--------------090403090603020302070602
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit



  
    
    
  
  
    Benoit,

    

    That's nice. However, I didn't see _any_ feedback.

    

    Did anyone review it?

    

    So let me do that now:

    

    

    

    Firstly, you haven't addressed _any_ of the 5815 errata. There are
    five. Please address them in -bis.

    

       
http://www.rfc-editor.org/errata_search.php?rfc=5815&rec_status=15&presentation=table

    

    

    

    Otherwise my comments are only editorial:

    

    

    

    Section 6:

    

        "{ ipfixSelectorFunctions 1}"

    

        - Whitespace imbalance around the { }.

    

    

    

    Section 6:

    

        "The specification of new MIB objects SHOULD follow the
    structure specified in the next Section"

    

        - The next section is "6.1 The Selector Functions". Perhaps you
    mean "8.  MIB Definitions"? So it would be better to state the exact
    section number.

    

    

    

    Section 6:

    

        - as a general comment, this would benefit from being broken
    into a few smaller paragraphs to improve readability.

    

    

    

    Section 7.1:

    

        "the ENTITY MIB module[RFC4133]"

    

        - the reference runs into the text. Add space.

    

    

    

    Section 8.2:

    

        Description

    

        "subject to Expert Review  RFC 5226"

    

        - too much space this time! :-)

    

    

        "RFC [NewRFCNumber]"

    

        - to make the RFC Editor's job easier, use either "NewRFCNumber"
    or "THISrfc", not both.

    

    

    

    Section 10:

    

        Further on, IANA will maintain ...

    

        "Further on" implies "at some time in the future", which seems
    vague. I'd just drop those words and state, "IANA will create and
    maintain ...".

    

    

    

    P.

    

    

    On 19/12/11 09:50, Benoit Claise wrote:
    

      
      Dear all,

      

      Apparently, this WGLC is finished.

      That would be great if we could advance this draft.

      As a reminder of the different references between the drafts:

      
draft-ietf-ipfix-configuration-model-10.txt status is MISSREF on draft-ietf-ipfix-psamp-mib 


      
draft-ietf-ipfix-psamp-mib-04.txt status is Waiting for AD Go-Ahead, because of the following normative reference


      

        
  [I-D.dkcm-ipfix-rfc5815bis]
              Dietz, T., Kobayashi, A., Claise, B., and G. Muenz,
              "Definitions of Managed Objects for IP Flow Information
              Export", draft-dkcm-ipfix-rfc5815bis-00 (work in
              progress), October 2011.

      

                     Note: This reference is actually
      draft-ietf-ipfix-rfc5815bis-00

      

      Conclusion: draft-ietf-ipfix-rfc5815bis-00 is the bottleneck to
      publish 3 RFCs

      

      Regards, Benoit.

      

        

        Hi all: 

        

        As discussed at last week's meeting, the WG Last Call for this 

        draft (updated version of the IPFIX MIB) starts now, and will 

        end on Wednesday, 7 December.  If you have comments on this, 

        please email them to the IPFIX list. 

        

        Cheers, Nevil 

        

      

      

      

_______________________________________________
IPFIX mailing list
IPFIX@ietf.org
https://www.ietf.org/mailman/listinfo/ipfix


    

    

  


--------------090403090603020302070602--

From bclaise@cisco.com  Mon Dec 19 06:03:35 2011
Return-Path: 
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 022AE21F8B6D for ; Mon, 19 Dec 2011 06:03:35 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.133
X-Spam-Level: 
X-Spam-Status: No, score=-2.133 tagged_above=-999 required=5 tests=[AWL=0.465,  BAYES_00=-2.599, HTML_MESSAGE=0.001]
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 rs+FVYCRDvsA for ; Mon, 19 Dec 2011 06:03:34 -0800 (PST)
Received: from av-tac-bru.cisco.com (weird-brew.cisco.com [144.254.15.118]) by ietfa.amsl.com (Postfix) with ESMTP id 025E721F8B68 for ; Mon, 19 Dec 2011 06:03:33 -0800 (PST)
X-TACSUNS: Virus Scanned
Received: from strange-brew.cisco.com (localhost.cisco.com [127.0.0.1]) by av-tac-bru.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id pBJE3UY5022131 for ; Mon, 19 Dec 2011 15:03:30 +0100 (CET)
Received: from [10.60.67.89] (ams-bclaise-8918.cisco.com [10.60.67.89]) by strange-brew.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id pBJE3UY2016993; Mon, 19 Dec 2011 15:03:30 +0100 (CET)
Message-ID: <4EEF4432.10309@cisco.com>
Date: Mon, 19 Dec 2011 15:03:30 +0100
From: Benoit Claise 
User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:8.0) Gecko/20111105 Thunderbird/8.0
MIME-Version: 1.0
To: Paul Aitken 
References: <4ECABFF3.6040206@auckland.ac.nz> <4EEF08EF.1040004@cisco.com> <4EEF1B1A.3040001@cisco.com>
In-Reply-To: <4EEF1B1A.3040001@cisco.com>
Content-Type: multipart/alternative; boundary="------------000908000001070009070708"
Cc: ipfix@ietf.org
Subject: Re: [IPFIX] WG Last Call for draft-ietf-ipfix-rfc5815bis-00
X-BeenThere: ipfix@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: IPFIX WG discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 19 Dec 2011 14:03:35 -0000

This is a multi-part message in MIME format.
--------------000908000001070009070708
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

Paul,

You're right, we overlooked the errata. This is the reason why the 
reviews are required ;-)
We'll correct this.

Regards, Benoit.

> Benoit,
>
> That's nice. However, I didn't see _any_ feedback.
>
> Did anyone review it?
>
> So let me do that now:
>
>
>
> Firstly, you haven't addressed _any_ of the 5815 errata. There are 
> five. Please address them in -bis.
>
> http://www.rfc-editor.org/errata_search.php?rfc=5815&rec_status=15&presentation=table
>
>
>
> Otherwise my comments are only editorial:
>
>
>
> Section 6:
>
>     "{ ipfixSelectorFunctions 1}"
>
>     - Whitespace imbalance around the { }.
>
>
>
> Section 6:
>
>     "The specification of new MIB objects SHOULD follow the structure 
> specified in the next Section"
>
>     - The next section is "6.1 The Selector Functions". Perhaps you 
> mean "8.  MIB Definitions"? So it would be better to state the exact 
> section number.
>
>
>
> Section 6:
>
>     - as a general comment, this would benefit from being broken into 
> a few smaller paragraphs to improve readability.
>
>
>
> Section 7.1:
>
>     "the ENTITY MIB module[RFC4133]"
>
>     - the reference runs into the text. Add space.
>
>
>
> Section 8.2:
>
>     Description
>
>     "subject to Expert Review  RFC 5226"
>
>     - too much space this time! :-)
>
>
>     "RFC [NewRFCNumber]"
>
>     - to make the RFC Editor's job easier, use either "NewRFCNumber" 
> or "THISrfc", not both.
>
>
>
> Section 10:
>
>     Further on, IANA will maintain ...
>
>     "Further on" implies "at some time in the future", which seems 
> vague. I'd just drop those words and state, "IANA will create and 
> maintain ...".
>
>
>
> P.
>
>
> On 19/12/11 09:50, Benoit Claise wrote:
>> Dear all,
>>
>> Apparently, this WGLC is finished.
>> That would be great if we could advance this draft.
>> As a reminder of the different references between the drafts:
>> draft-ietf-ipfix-configuration-model-10.txt  status is MISSREF on draft-ietf-ipfix-psamp-mib
>> draft-ietf-ipfix-psamp-mib-04.txt    status is Waiting for AD Go-Ahead, because of the following normative reference
>>
>>        [I-D.dkcm-ipfix-rfc5815bis]
>>                    Dietz, T., Kobayashi, A., Claise, B., and G. Muenz,
>>                    "Definitions of Managed Objects for IP Flow Information
>>                    Export", draft-dkcm-ipfix-rfc5815bis-00 (work in
>>                    progress), October 2011.
>>
>>                Note: This reference is actually 
>> draft-ietf-ipfix-rfc5815bis-00
>>
>> Conclusion: draft-ietf-ipfix-rfc5815bis-00 is the bottleneck to 
>> publish 3 RFCs
>>
>> Regards, Benoit.
>>>
>>> Hi all:
>>>
>>> As discussed at last week's meeting, the WG Last Call for this
>>> draft (updated version of the IPFIX MIB) starts now, and will
>>> end on Wednesday, 7 December.  If you have comments on this,
>>> please email them to the IPFIX list.
>>>
>>> Cheers, Nevil
>>>
>>
>>
>> _______________________________________________
>> IPFIX mailing list
>> IPFIX@ietf.org
>> https://www.ietf.org/mailman/listinfo/ipfix
>


--------------000908000001070009070708
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit


  
    
  
  
    Paul,

    

    You're right, we overlooked the errata. This is the reason why the
    reviews are required ;-)

    We'll correct this.

    

    Regards, Benoit.

    

    

      
      
      Benoit,

      

      That's nice. However, I didn't see _any_ feedback.

      

      Did anyone review it?

      

      So let me do that now:

      

      

      

      Firstly, you haven't addressed _any_ of the 5815 errata. There are
      five. Please address them in -bis.

      

         
      http://www.rfc-editor.org/errata_search.php?rfc=5815&rec_status=15&presentation=table

      

      

      

      Otherwise my comments are only editorial:

      

      

      

      Section 6:

      

          "{ ipfixSelectorFunctions 1}"

      

          - Whitespace imbalance around the { }.

      

      

      

      Section 6:

      

          "The specification of new MIB objects SHOULD follow the
      structure specified in the next Section"

      

          - The next section is "6.1 The Selector Functions". Perhaps
      you mean "8.  MIB Definitions"? So it would be better to state the
      exact section number.

      

      

      

      Section 6:

      

          - as a general comment, this would benefit from being broken
      into a few smaller paragraphs to improve readability.

      

      

      

      Section 7.1:

      

          "the ENTITY MIB module[RFC4133]"

      

          - the reference runs into the text. Add space.

      

      

      

      Section 8.2:

      

          Description

      

          "subject to Expert Review  RFC 5226"

      

          - too much space this time! :-)

      

      

          "RFC [NewRFCNumber]"

      

          - to make the RFC Editor's job easier, use either
      "NewRFCNumber" or "THISrfc", not both.

      

      

      

      Section 10:

      

          Further on, IANA will maintain ...

      

          "Further on" implies "at some time in the future", which seems
      vague. I'd just drop those words and state, "IANA will create and
      maintain ...".

      

      

      

      P.

      

      

      On 19/12/11 09:50, Benoit Claise wrote:
      

        
        Dear all,

        

        Apparently, this WGLC is finished.

        That would be great if we could advance this draft.

        As a reminder of the different references between the drafts:

        
draft-ietf-ipfix-configuration-model-10.txt status is MISSREF on draft-ietf-ipfix-psamp-mib 


        
draft-ietf-ipfix-psamp-mib-04.txt status is Waiting for AD Go-Ahead, because of the following normative reference


        

          
  [I-D.dkcm-ipfix-rfc5815bis]
              Dietz, T., Kobayashi, A., Claise, B., and G. Muenz,
              "Definitions of Managed Objects for IP Flow Information
              Export", draft-dkcm-ipfix-rfc5815bis-00 (work in
              progress), October 2011.

        

                       Note: This reference is actually
        draft-ietf-ipfix-rfc5815bis-00

        

        Conclusion: draft-ietf-ipfix-rfc5815bis-00 is the bottleneck to
        publish 3 RFCs

        

        Regards, Benoit.

        
 

          Hi all: 

          

          As discussed at last week's meeting, the WG Last Call for this
          

          draft (updated version of the IPFIX MIB) starts now, and will
          

          end on Wednesday, 7 December.  If you have comments on this, 

          please email them to the IPFIX list. 

          

          Cheers, Nevil 

          

        

        

        

_______________________________________________
IPFIX mailing list
IPFIX@ietf.org
https://www.ietf.org/mailman/listinfo/ipfix


      

      

    

    

  


--------------000908000001070009070708--

From paitken@cisco.com  Tue Dec 20 06:52:48 2011
Return-Path: 
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 E874821F8AF7 for ; Tue, 20 Dec 2011 06:52:48 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.599
X-Spam-Level: 
X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8]
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 x79AKhWJj5IW for ; Tue, 20 Dec 2011 06:52:48 -0800 (PST)
Received: from ams-iport-2.cisco.com (ams-iport-2.cisco.com [144.254.224.141]) by ietfa.amsl.com (Postfix) with ESMTP id 106F621F8801 for ; Tue, 20 Dec 2011 06:52:47 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=paitken@cisco.com; l=1146; q=dns/txt; s=iport; t=1324392768; x=1325602368; h=message-id:date:from:mime-version:to:subject: content-transfer-encoding; bh=eSTxgxBoKtTokog6ouMkQgk3I0md6jYaD99AZUAL1N4=; b=TGiIRDWA14ygfq40H6sZMtZrYc2W5HPB/IqLYf4R0YI2XHLemtPucCLK OBOecB8YHGIq57cqj5PFA8ucL8eHvOe2B76v2UqYhhhD/s5MpRmAoyOwj vI8dxdt+elaB5eDzxPscFAH2NWL0JNnR9T+0Qx0mZ3xglFb/ywXWTh/9U U=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: Av0EAA6g8E6Q/khL/2dsb2JhbABDq3+BBYILASUzSjQCTA0IAQEenxqBJgGeRowMBJR/hU+MYQ
X-IronPort-AV: E=Sophos;i="4.71,382,1320624000"; d="scan'208";a="61731214"
Received: from ams-core-2.cisco.com ([144.254.72.75]) by ams-iport-2.cisco.com with ESMTP; 20 Dec 2011 14:52:45 +0000
Received: from [144.254.153.49] (dhcp-144-254-153-49.cisco.com [144.254.153.49]) by ams-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id pBKEqj0X017924 for ; Tue, 20 Dec 2011 14:52:45 GMT
Message-ID: <4EF0A13E.40401@cisco.com>
Date: Tue, 20 Dec 2011 14:52:46 +0000
From: Paul Aitken 
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.23) Gecko/20110922 Lightning/1.0b2 Thunderbird/3.1.15
MIME-Version: 1.0
To: IETF IPFIX Working Group 
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Subject: [IPFIX] two issues for RFC5102bis
X-BeenThere: ipfix@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: IPFIX WG discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 20 Dec 2011 14:52:49 -0000

Dear IPFIX experts,

Two issues for RFC5102bis:


Firstly, can we recognise that unsigned8, unsigned16, unsigned32, and 
unsigned64 aren't different types; they're simply different lengths of 
the same type. Accordingly, we should use a single "unsigned" type.

Similarly for signed.

Else, when using reduced size encoding to export unsigned64, the 
implication is that the _type_ changes? Clearly this isn't the case.

The encoding of float32 and float64 differs, so these should remain as 
different types.


Secondly, the info model should not specify the field size since sizes 
are specified in the template.

There was one argument that the maximum length must be specified for 
collector database design. This is only an issue if differently-sized 
fields are stored in the same database - eg, the database field is only 
8 bits wide, and is suddenly required to store a 16- or 32-bit wide 
field. This may only be an issue in an IPFIX aggregator.

If this is a real issue, then the infomodel should specify the maximum 
length for each field, rather than confusing this with the field type.


Thanks,
P.