From paitken@cisco.com Mon Aug 1 05:41: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 86F5511E8357 for ; Mon, 1 Aug 2011 05:41:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.282 X-Spam-Level: X-Spam-Status: No, score=-10.282 tagged_above=-999 required=5 tests=[AWL=-0.317, BAYES_00=-2.599, FM_ASCII_ART_SPACINGc=0.833, GB_I_LETTER=-2, HTML_MESSAGE=0.001, J_CHICKENPOX_37=0.6, J_CHICKENPOX_43=0.6, J_CHICKENPOX_92=0.6, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iGwlajU-nzUg for ; Mon, 1 Aug 2011 05:41:51 -0700 (PDT) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by ietfa.amsl.com (Postfix) with ESMTP id 1421011E836B for ; Mon, 1 Aug 2011 05:41:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=paitken@cisco.com; l=188627; q=dns/txt; s=iport; t=1312202513; x=1313412113; h=message-id:date:from:mime-version:to:cc:subject; bh=4ZZkY2KnhDragHZfmTF4NiAUK1gdo/rsRJt7VY4oNU8=; b=dS6/j2rrUDOM2dNwVPaapg4blepxYsLR8ToMj73pYSKe4IbSXdD1rT7I CmzDHax5kAXq9m0lWKSzLc7OCUuDerrVejbZewCroGcg6CnYTHLaYKK2V /X2v8LxCLsq1i5375J0xdHlqbsEpx7SWRzQf3z6zwgoMxKv6cBB3aZO+G 8=; X-IronPort-AV: E=Sophos;i="4.67,300,1309737600"; d="scan'208,217";a="105994292" Received: from ams-core-4.cisco.com ([144.254.72.77]) by ams-iport-1.cisco.com with ESMTP; 01 Aug 2011 12:41:47 +0000 Received: from [10.55.95.196] (dhcp-10-55-95-196.cisco.com [10.55.95.196]) by ams-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id p71CfhcI023785; Mon, 1 Aug 2011 12:41:43 GMT Message-ID: <4E369F30.3040602@cisco.com> Date: Mon, 01 Aug 2011 13:42:24 +0100 From: Paul Aitken User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.18) Gecko/20110617 Lightning/1.0b2 Thunderbird/3.1.11 MIME-Version: 1.0 To: "Benoit Claise (bclaise)" , Kobayashi Atsushi , Brian Trammell Content-Type: multipart/alternative; boundary="------------080802030101030506090309" Cc: IETF IPFIX Working Group Subject: [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, 01 Aug 2011 12:41:59 -0000 This is a multi-part message in MIME format. --------------080802030101030506090309 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit 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/ > draft-claise-ipfix-mediation-protocol-04 > > > Abstract > > This document specifies the IP Flow Information Export > (IPFIX) protocol specific tothe Mediation. Consider "specific to Mediation." 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/ > [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. > 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", 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". > > > > > 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. > > > 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]." > 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" > 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". > flows observed at an observation point, along with the > motivations, and some specific flow selection techniques. "motivations"... for what? > > 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. > > 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. > > > > > > > > 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/ > 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/ > However, since thosetwo documents are an informational RFC, the "since both of those documents are informational RFCs" > 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". > 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". > Records in any other format. "Records, or" The indentation of the following sections is inconsistent. > > 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, ...". 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". 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. > > 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". > 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? > 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..." > 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. > 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. > > 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" > 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" ? > 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. > > 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. > hosting one or more Intermediate Processes to transform that > stream, and exporting the transformed record streaminto IPFIX s/into/in/ > Messages via an Exporting Process. In the common case, an Can't it write to a file too? > 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. > > 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. > 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. > > For a specific Intermediate Process, the specifications in the > followingreference MUST be followed, onthe top of the > specifications in this document: "references". Remove "the". > - 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? > > These new specifications, which are more specificcompared to s/compared to/than/ > [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 :-( > 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? > 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]". I get the feeling I'm the first to actually read this :-( [Later] Yes, very much so. > 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/ > 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/ > - 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. 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. > > 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 ..." > > 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? > ofthe customer networks, i.e. the Route Distinguisher (RD). In d/the/ > this example, the Template Record received from the Exporter#1 > is reused towardsthe Collector#1, Collector#2, and Collector#3. d/the/ > > > 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." > 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? > > 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/ > 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 > > 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. > 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) > 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". > 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. > > 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/ > 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/ > 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? > > 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? > 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? > specific case of aggregation in space and time arespecified in "specifications... are specified" seems clumsy. s/specified/given/ > [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"? > 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". > generated the Flow Records. Two new InformationElement are s/Element/Elements/ > 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)". > - A list of Original Exporter (represented by the > originalExporterIPv4Address or originalExporterIPv6Address > Information Elements), along with the associated line card id > (represented by the lineCardId) 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. > > 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/ > used: > > Template Record 257: exporterIPv4Address > Template Record 258: exporterIPv4Address, basicList of > ingressInterface, flowDirecdtion s/flowDirecdtion/flowDirection/ > > Template Record 259: exporterIPv4Address, lineCardId, > flowDirection How does the mediator come to know where the OPs are in the original devices? 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? > 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? > > > > 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? > 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. > > > 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. > 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. Consider mentioning how it can increase the number of keys. eg, by adding info about the OP or Exporter. > > 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/ > 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]". > > 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 ... > 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. > specification inthe IPFIX Structured Data [IPFIX-STRUCT]. "specifications" d/the/ > > 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. > 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. > > 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. > > > 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. > 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. > > > 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/ > as well to Mediators. The Security Considerations for IPFIX s/apply as well/also apply/ > Files [RFC5655]apply as well to IPFIX Mediators that write s/apply as well/also apply/ > 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/ > > 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/ 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". > 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]". > > > > > 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/ > 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] > > --------------080802030101030506090309 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit 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/


                 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." 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/


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


        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", 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".


         

      
      
     <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.


      
      
     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]."


        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"


        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".


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

"motivations"... for what?


         
        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. 
         
     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.


         
         



      
      
     <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/


        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/


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

"since both of those documents are informational RFCs"


        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".


        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".


        Records in any other format.

"Records, or"


The indentation of the following sections is inconsistent.


         
        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, ...". 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". 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.


      
        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".


          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?


          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..."


          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.


          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.


         
        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"


          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" ?


          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.


         
        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.


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

s/into/in/


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

Can't it write to a file too?


          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.


           
        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.


         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.


         
        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".


       - 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?


        
        These new specifications, which are more specific compared to

s/compared to/than/


        [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 :-(


        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?


                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]".

I get the feeling I'm the first to actually read this :-(
[Later] Yes, very much so.


                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/


        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/


        - 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.

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.


         
        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 ..."

         
        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?


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

d/the/


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

d/the/


      
         
                                         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."


        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?


                                                                    
        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/


        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 

      
        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.


        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)

        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".


       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.


      
       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/


        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/


        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?


         
        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?


        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?


        specific case of aggregation in space and time are specified in

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


        [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"?


        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".


        generated the Flow Records.  Two new Information Element are

s/Element/Elements/


        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)".


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

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.


        
        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/


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

s/flowDirecdtion/flowDirection/


 
                 Template Record 259: exporterIPv4Address, lineCardId,  
                                    flowDirection

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

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?


        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?


         
         

     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?


        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.


         

     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.


        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.

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


         
     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/


        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]".


         
        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 ...


        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.


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

"specifications"
d/the/


         
        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.


        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.


         
        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.


 
           
         
     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.


        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.


      
      
     <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/


        as well to Mediators.  The Security Considerations for IPFIX

s/apply as well/also apply/


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

s/apply as well/also apply/


        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/


         
        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/

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".


      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]".


          

      
      
     <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/


        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]
--------------080802030101030506090309-- From wwwrun@rfc-editor.org Mon Aug 1 06:01:05 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 B6BCF11E80E1 for ; Mon, 1 Aug 2011 06:01:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.465 X-Spam-Level: X-Spam-Status: No, score=-102.465 tagged_above=-999 required=5 tests=[AWL=0.135, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id znB0f64jzKuJ for ; Mon, 1 Aug 2011 06:01:05 -0700 (PDT) Received: from rfc-editor.org (rfc-editor.org [IPv6:2001:1890:1112:1::2f]) by ietfa.amsl.com (Postfix) with ESMTP id 5F1F921F851F for ; Mon, 1 Aug 2011 06:01:05 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id A64ED98C4EB; Mon, 1 Aug 2011 06:01:09 -0700 (PDT) To: tanja.zseby@fokus.fraunhofer.de, elisa.boschi@hitachi-eu.com, nevil@caida.org, bclaise@cisco.com, dromasca@avaya.com, rbonica@juniper.net, n.brownlee@auckland.ac.nz, quittek@neclab.eu From: RFC Errata System Message-Id: <20110801130109.A64ED98C4EB@rfc-editor.org> Date: Mon, 1 Aug 2011 06:01:09 -0700 (PDT) Cc: ipfix@ietf.org, rfc-editor@rfc-editor.org Subject: [IPFIX] [Editorial Errata Reported] RFC5472 (2875) 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, 01 Aug 2011 13:01:05 -0000 The following errata report has been submitted for RFC5472, "IP Flow Information Export (IPFIX) Applicability". -------------------------------------- You may review the report below and at: http://www.rfc-editor.org/errata_search.php?rfc=5472&eid=2875 -------------------------------------- Type: Editorial Reported by: Paul Aitken Section: 5 Original Text ------------- The threat level to IPIFX itself Corrected Text -------------- The threat level to IPFIX itself Notes ----- s/IPIFX/IPFIX/ Instructions: ------------- This errata is currently posted as "Reported". If necessary, please use "Reply All" to discuss whether it should be verified or rejected. When a decision is reached, the verifying party (IESG) can log in to change the status and edit the report, if necessary. -------------------------------------- RFC5472 (draft-ietf-ipfix-as-12) -------------------------------------- Title : IP Flow Information Export (IPFIX) Applicability Publication Date : March 2009 Author(s) : T. Zseby, E. Boschi, N. Brownlee, B. Claise Category : INFORMATIONAL Source : IP Flow Information Export Area : Operations and Management Stream : IETF Verifying Party : IESG From wwwrun@rfc-editor.org Mon Aug 1 06:01: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 D70A211E811E for ; Mon, 1 Aug 2011 06:01:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.468 X-Spam-Level: X-Spam-Status: No, score=-102.468 tagged_above=-999 required=5 tests=[AWL=0.132, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iBFkEpaDXT-Y for ; Mon, 1 Aug 2011 06:01:48 -0700 (PDT) Received: from rfc-editor.org (rfc-editor.org [IPv6:2001:1890:1112:1::2f]) by ietfa.amsl.com (Postfix) with ESMTP id 844B211E810D for ; Mon, 1 Aug 2011 06:01:48 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id 7683198C4F3; Mon, 1 Aug 2011 06:01:52 -0700 (PDT) To: tanja.zseby@fokus.fraunhofer.de, elisa.boschi@hitachi-eu.com, nevil@caida.org, bclaise@cisco.com, dromasca@avaya.com, rbonica@juniper.net, n.brownlee@auckland.ac.nz, quittek@neclab.eu From: RFC Errata System Message-Id: <20110801130152.7683198C4F3@rfc-editor.org> Date: Mon, 1 Aug 2011 06:01:52 -0700 (PDT) Cc: ipfix@ietf.org, rfc-editor@rfc-editor.org Subject: [IPFIX] [Editorial Errata Reported] RFC5472 (2876) 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, 01 Aug 2011 13:01:49 -0000 The following errata report has been submitted for RFC5472, "IP Flow Information Export (IPFIX) Applicability". -------------------------------------- You may review the report below and at: http://www.rfc-editor.org/errata_search.php?rfc=5472&eid=2876 -------------------------------------- Type: Editorial Reported by: Paul Aitken Section: 5 Original Text ------------- even if IPIFX is not the target of the attack Corrected Text -------------- even if IPFIX is not the target of the attack Notes ----- s/IPIFX/IPFIX/ Instructions: ------------- This errata is currently posted as "Reported". If necessary, please use "Reply All" to discuss whether it should be verified or rejected. When a decision is reached, the verifying party (IESG) can log in to change the status and edit the report, if necessary. -------------------------------------- RFC5472 (draft-ietf-ipfix-as-12) -------------------------------------- Title : IP Flow Information Export (IPFIX) Applicability Publication Date : March 2009 Author(s) : T. Zseby, E. Boschi, N. Brownlee, B. Claise Category : INFORMATIONAL Source : IP Flow Information Export Area : Operations and Management Stream : IETF Verifying Party : IESG From wwwrun@rfc-editor.org Mon Aug 1 06:21: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 34D4011E80B0 for ; Mon, 1 Aug 2011 06:21:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.47 X-Spam-Level: X-Spam-Status: No, score=-102.47 tagged_above=-999 required=5 tests=[AWL=0.130, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HDScaPfnq24R for ; Mon, 1 Aug 2011 06:21:14 -0700 (PDT) Received: from rfc-editor.org (rfc-editor.org [IPv6:2001:1890:1112:1::2f]) by ietfa.amsl.com (Postfix) with ESMTP id D173211E8078 for ; Mon, 1 Aug 2011 06:21:14 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id 20E4098C4EB; Mon, 1 Aug 2011 06:21:21 -0700 (PDT) To: elisa.boschi@hitachi-eu.com, lutz.mark@ifam.fraunhofer.de, bclaise@cisco.com, dromasca@avaya.com, rbonica@juniper.net, n.brownlee@auckland.ac.nz, quittek@neclab.eu From: RFC Errata System Message-Id: <20110801132121.20E4098C4EB@rfc-editor.org> Date: Mon, 1 Aug 2011 06:21:21 -0700 (PDT) Cc: ipfix@ietf.org, rfc-editor@rfc-editor.org Subject: [IPFIX] [Editorial Errata Reported] RFC5473 (2877) 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, 01 Aug 2011 13:21:15 -0000 The following errata report has been submitted for RFC5473, "Reducing Redundancy in IP Flow Information Export (IPFIX) and Packet Sampling (PSAMP) Reports". -------------------------------------- You may review the report below and at: http://www.rfc-editor.org/errata_search.php?rfc=5473&eid=2877 -------------------------------------- Type: Editorial Reported by: Paul Aitken Section: A.2 Original Text ------------- o The Class of Service field: ClassOfServiceIPv4 in [RFC5102], with a type of 5 and a length of 1 octet. Corrected Text -------------- o The Class of Service field: ipClassOfService in [RFC5102], with a type of 5 and a length of 1 octet. Notes ----- s/ClassOfServiceIPv4/ipClassOfService/ per IANA IPFIX registry, #5. Instructions: ------------- This errata is currently posted as "Reported". If necessary, please use "Reply All" to discuss whether it should be verified or rejected. When a decision is reached, the verifying party (IESG) can log in to change the status and edit the report, if necessary. -------------------------------------- RFC5473 (draft-ietf-ipfix-reducing-redundancy-04) -------------------------------------- Title : Reducing Redundancy in IP Flow Information Export (IPFIX) and Packet Sampling (PSAMP) Reports Publication Date : March 2009 Author(s) : E. Boschi, L. Mark, B. Claise Category : INFORMATIONAL Source : IP Flow Information Export Area : Operations and Management Stream : IETF Verifying Party : IESG From wwwrun@rfc-editor.org Mon Aug 1 06:22:56 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 6C34721F8BDB for ; Mon, 1 Aug 2011 06:22:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.473 X-Spam-Level: X-Spam-Status: No, score=-102.473 tagged_above=-999 required=5 tests=[AWL=0.127, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AkmFI66FIfB3 for ; Mon, 1 Aug 2011 06:22:55 -0700 (PDT) Received: from rfc-editor.org (rfc-editor.org [IPv6:2001:1890:1112:1::2f]) by ietfa.amsl.com (Postfix) with ESMTP id E627A21F8BD5 for ; Mon, 1 Aug 2011 06:22:55 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id 6BC6298C4EB; Mon, 1 Aug 2011 06:23:02 -0700 (PDT) To: elisa.boschi@hitachi-eu.com, lutz.mark@ifam.fraunhofer.de, bclaise@cisco.com, dromasca@avaya.com, rbonica@juniper.net, n.brownlee@auckland.ac.nz, quittek@neclab.eu From: RFC Errata System Message-Id: <20110801132302.6BC6298C4EB@rfc-editor.org> Date: Mon, 1 Aug 2011 06:23:02 -0700 (PDT) Cc: ipfix@ietf.org, rfc-editor@rfc-editor.org Subject: [IPFIX] [Editorial Errata Reported] RFC5473 (2878) 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, 01 Aug 2011 13:22:56 -0000 The following errata report has been submitted for RFC5473, "Reducing Redundancy in IP Flow Information Export (IPFIX) and Packet Sampling (PSAMP) Reports". -------------------------------------- You may review the report below and at: http://www.rfc-editor.org/errata_search.php?rfc=5473&eid=2878 -------------------------------------- Type: Editorial Reported by: Paul Aitken Section: A.2 Original Text ------------- In this example, using IPFIX to export the measurement data for each received packet, 38 bytes have to be transferred (sourceAddressV4=4, destinationAddressV4=4, classOfServiceV4=1, protocolIdentifier=1, sourceTransportPort=2, destinationTransportPort=2, observationTimeMilliseconds=8, digestHashValue=8, ipTotalLength=8). Without considering the IPFIX protocol overhead, a Flow of 1000 packets produces 38000 bytes of measurement data. Using the proposed optimization, each packet produces an export of only 28 bytes (observationTimeMilliseconds=8, digestHashValue=8, ipTotalLength=8, commonPropertiesID=4). The export of the Flow information produces 18 bytes (sourceAddressV4=4, destinationAddressV4=4, classOfServiceV4=1, protocolIdentifier=1, sourceTransportPort=2, destinationTransportPort=2, commonPropertiesID=4). For a Flow of 1000 packets, this sums to 28018 bytes. This is a decrease of more than 26 percent. Corrected Text -------------- In this example, using IPFIX to export the measurement data for each received packet, 38 bytes have to be transferred (sourceIPv4Address=4, destinationIPv4Address=4, ipClassOfService=1, protocolIdentifier=1, sourceTransportPort=2, destinationTransportPort=2, observationTimeMilliseconds=8, digestHashValue=8, ipTotalLength=8). Without considering the IPFIX protocol overhead, a Flow of 1000 packets produces 38000 bytes of measurement data. Using the proposed optimization, each packet produces an export of only 28 bytes (observationTimeMilliseconds=8, digestHashValue=8, ipTotalLength=8, commonPropertiesID=4). The export of the Flow information produces 18 bytes (sourceIPv4Address=4, destinationIPv4Address=4, ipClassOfService=1, protocolIdentifier=1, sourceTransportPort=2, destinationTransportPort=2, commonPropertiesID=4). For a Flow of 1000 packets, this sums to 28018 bytes. This is a decrease of more than 26 percent. Notes ----- s/sourceAddressV4/sourceIPv4Address/ s/destinationAddressV4/destinationIPv4Address/ s/classOfServiceV4=1/ipClassOfService/ - twice each. Names are per IANA's IPFIX registry. Instructions: ------------- This errata is currently posted as "Reported". If necessary, please use "Reply All" to discuss whether it should be verified or rejected. When a decision is reached, the verifying party (IESG) can log in to change the status and edit the report, if necessary. -------------------------------------- RFC5473 (draft-ietf-ipfix-reducing-redundancy-04) -------------------------------------- Title : Reducing Redundancy in IP Flow Information Export (IPFIX) and Packet Sampling (PSAMP) Reports Publication Date : March 2009 Author(s) : E. Boschi, L. Mark, B. Claise Category : INFORMATIONAL Source : IP Flow Information Export Area : Operations and Management Stream : IETF Verifying Party : IESG From wwwrun@rfc-editor.org Mon Aug 1 06:31: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 87CC411E80C0 for ; Mon, 1 Aug 2011 06:31:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.475 X-Spam-Level: X-Spam-Status: No, score=-102.475 tagged_above=-999 required=5 tests=[AWL=0.125, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6J6z8OxrTVKT for ; Mon, 1 Aug 2011 06:31:53 -0700 (PDT) Received: from rfc-editor.org (rfc-editor.org [IPv6:2001:1890:1112:1::2f]) by ietfa.amsl.com (Postfix) with ESMTP id 095D711E80AF for ; Mon, 1 Aug 2011 06:31:53 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id 4849D98C4EB; Mon, 1 Aug 2011 06:31:59 -0700 (PDT) To: quittek@netlab.nec.de, stbryant@cisco.com, bclaise@cisco.com, paitken@cisco.com, jemeyer@paypal.com, dromasca@avaya.com, rbonica@juniper.net, n.brownlee@auckland.ac.nz, quittek@neclab.eu From: RFC Errata System Message-Id: <20110801133159.4849D98C4EB@rfc-editor.org> Date: Mon, 1 Aug 2011 06:31:59 -0700 (PDT) Cc: ipfix@ietf.org, rfc-editor@rfc-editor.org Subject: [IPFIX] [Editorial Errata Reported] RFC5102 (2879) 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, 01 Aug 2011 13:31:53 -0000 The following errata report has been submitted for RFC5102, "Information Model for IP Flow Information Export". -------------------------------------- You may review the report below and at: http://www.rfc-editor.org/errata_search.php?rfc=5102&eid=2879 -------------------------------------- Type: Editorial Reported by: Paul Aitken Section: 2.3 Original Text ------------- o Middleboxes [RFC3234] may change Flow properties, such as the Differentiated Service Code Point (DSCP) value or the source IP address. If an IPFIX Observation Point is located in the path of a Flow before one or more middleboxes that potentially modify packets of the Flow, then it may be desirable to also report Flow properties after the modification performed by the middleboxes. An example is an Observation Point before a packet marker changing a packet's IPv4 Type of Service (TOS) field that is encoded in Information Element classOfServiceIPv4. Then the value observed and reported by Information Element classOfServiceIPv4 is valid at the Observation Point, but not after the packet passed the packet marker. For reporting the change value of the TOS field, the IPFIX information model uses Information Elements that have a name prefix "post", for example, "postClassOfServiceIPv4". Corrected Text -------------- o Middleboxes [RFC3234] may change Flow properties, such as the Differentiated Service Code Point (DSCP) value or the source IP address. If an IPFIX Observation Point is located in the path of a Flow before one or more middleboxes that potentially modify packets of the Flow, then it may be desirable to also report Flow properties after the modification performed by the middleboxes. An example is an Observation Point before a packet marker changing a packet's IPv4 Type of Service (TOS) field that is encoded in Information Element ipClassOfService. Then the value observed and reported by Information Element ipClassOfService is valid at the Observation Point, but not after the packet passed the packet marker. For reporting the change value of the TOS field, the IPFIX information model uses Information Elements that have a name prefix "post", for example, "postIpClassOfService". Notes ----- s/ClassOfServiceIPv4/ipClassOfService/ (twice) s/postClassOfServiceIPv4/postIpClassOfService/ (once) Also correct another instance of "postClassOfServiceIPv4" in section 5: OLD Information Elements with a name having the "post" prefix, for example, "postClassOfServiceIPv4" NEW Information Elements with a name having the "post" prefix, for example, "postIpClassOfService" END Instructions: ------------- This errata is currently posted as "Reported". If necessary, please use "Reply All" to discuss whether it should be verified or rejected. When a decision is reached, the verifying party (IESG) can log in to change the status and edit the report, if necessary. -------------------------------------- RFC5102 (draft-ietf-ipfix-info-15) -------------------------------------- Title : Information Model for IP Flow Information Export Publication Date : January 2008 Author(s) : J. Quittek, S. Bryant, B. Claise, P. Aitken, J. Meyer Category : PROPOSED STANDARD Source : IP Flow Information Export Area : Operations and Management Stream : IETF Verifying Party : IESG From wwwrun@rfc-editor.org Mon Aug 1 06:46:11 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 86C7C11E8081 for ; Mon, 1 Aug 2011 06:46:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.477 X-Spam-Level: X-Spam-Status: No, score=-102.477 tagged_above=-999 required=5 tests=[AWL=0.123, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iA0BbwqOItvb for ; Mon, 1 Aug 2011 06:46:11 -0700 (PDT) Received: from rfc-editor.org (rfc-editor.org [IPv6:2001:1890:1112:1::2f]) by ietfa.amsl.com (Postfix) with ESMTP id 0BB0A11E8075 for ; Mon, 1 Aug 2011 06:46:11 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id 8D5DA98C4EB; Mon, 1 Aug 2011 06:46:17 -0700 (PDT) To: elisa.boschi@hitachi-eu.com, lutz.mark@ifam.fraunhofer.de, bclaise@cisco.com, dromasca@avaya.com, rbonica@juniper.net, n.brownlee@auckland.ac.nz, quittek@neclab.eu From: RFC Errata System Message-Id: <20110801134617.8D5DA98C4EB@rfc-editor.org> Date: Mon, 1 Aug 2011 06:46:17 -0700 (PDT) Cc: ipfix@ietf.org, rfc-editor@rfc-editor.org Subject: [IPFIX] [Editorial Errata Reported] RFC5473 (2880) 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, 01 Aug 2011 13:46:11 -0000 The following errata report has been submitted for RFC5473, "Reducing Redundancy in IP Flow Information Export (IPFIX) and Packet Sampling (PSAMP) Reports". -------------------------------------- You may review the report below and at: http://www.rfc-editor.org/errata_search.php?rfc=5473&eid=2880 -------------------------------------- Type: Editorial Reported by: Paul Aitken Section: Figure 15 Original Text ------------- 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Set ID = 3 | Length = 40 octets | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Template ID = 256 | Field Count = 7 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Scope Field count = 1 |0| commonPropertiesID = 137 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Scope 1 Field Length = 4 |0| sourceIPv4Address = 8 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Field Length = 4 |0| destinationIPv4Address = 12 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Field Length = 4 |0| classOfServiceIPv4 = 5 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Field Length = 1 |0| protocolIdentifier = 4 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Field Length = 1 |0| transportSourcePort = 7 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Field Length = 2 |0|transportDestinationPort = 11| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Field Length = 2 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Corrected Text -------------- 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Set ID = 3 | Length = 40 octets | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Template ID = 256 | Field Count = 7 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Scope Field count = 1 |0| commonPropertiesID = 137 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Scope 1 Field Length = 4 |0| sourceIPv4Address = 8 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Field Length = 4 |0| destinationIPv4Address = 12 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Field Length = 4 |0| ipClassOfService = 5 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Field Length = 1 |0| protocolIdentifier = 4 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Field Length = 1 |0| transportSourcePort = 7 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Field Length = 2 |0|transportDestinationPort = 11| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Field Length = 2 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Notes ----- s/classOfServiceIPv4/ipClassOfService/ Also, fix the alignment of the bit position numbering at the top of the figure. Instructions: ------------- This errata is currently posted as "Reported". If necessary, please use "Reply All" to discuss whether it should be verified or rejected. When a decision is reached, the verifying party (IESG) can log in to change the status and edit the report, if necessary. -------------------------------------- RFC5473 (draft-ietf-ipfix-reducing-redundancy-04) -------------------------------------- Title : Reducing Redundancy in IP Flow Information Export (IPFIX) and Packet Sampling (PSAMP) Reports Publication Date : March 2009 Author(s) : E. Boschi, L. Mark, B. Claise Category : INFORMATIONAL Source : IP Flow Information Export Area : Operations and Management Stream : IETF Verifying Party : IESG From wwwrun@rfc-editor.org Mon Aug 1 06:54:26 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 0028321F8D24 for ; Mon, 1 Aug 2011 06:54:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.479 X-Spam-Level: X-Spam-Status: No, score=-102.479 tagged_above=-999 required=5 tests=[AWL=0.121, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XePFYYqS7aNw for ; Mon, 1 Aug 2011 06:54:25 -0700 (PDT) Received: from rfc-editor.org (rfc-editor.org [IPv6:2001:1890:1112:1::2f]) by ietfa.amsl.com (Postfix) with ESMTP id 6CDB821F8D23 for ; Mon, 1 Aug 2011 06:54:25 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id E3F2798C4EB; Mon, 1 Aug 2011 06:54:31 -0700 (PDT) To: brian.trammell@hitachi-eu.com, elisa.boschi@hitachi-eu.com, lutz.mark@ifam.fraunhofer.de, tanja.zseby@fokus.fraunhofer.de, arno@wagner.name, dromasca@avaya.com, rbonica@juniper.net, n.brownlee@auckland.ac.nz, quittek@neclab.eu From: RFC Errata System Message-Id: <20110801135431.E3F2798C4EB@rfc-editor.org> Date: Mon, 1 Aug 2011 06:54:31 -0700 (PDT) Cc: ipfix@ietf.org, rfc-editor@rfc-editor.org Subject: [IPFIX] [Editorial Errata Reported] RFC5655 (2881) 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, 01 Aug 2011 13:54:26 -0000 The following errata report has been submitted for RFC5655, "Specification of the IP Flow Information Export (IPFIX) File Format". -------------------------------------- You may review the report below and at: http://www.rfc-editor.org/errata_search.php?rfc=5655&eid=2881 -------------------------------------- Type: Editorial Reported by: Paul Aitken Section: B.2 Original Text ------------- 6. Copy each FlowSet from the Netflow V9 packet to the IPFIX Message after the header. Replace Set ID 0 with Set ID 2 for Template Sets, and Set ID 1 with Set ID 3 for Options Template Sets. Corrected Text -------------- 6. Copy each FlowSet from the NetFlow V9 packet to the IPFIX Message after the header. Replace Set ID 0 with Set ID 2 for Template Sets, and Set ID 1 with Set ID 3 for Options Template Sets. Notes ----- s/Netflow/NetFlow/ Per RFC 3954 and searches of cisco.com and google, the correct term is "NetFlow". Instructions: ------------- This errata is currently posted as "Reported". If necessary, please use "Reply All" to discuss whether it should be verified or rejected. When a decision is reached, the verifying party (IESG) can log in to change the status and edit the report, if necessary. -------------------------------------- RFC5655 (draft-ietf-ipfix-file-05) -------------------------------------- Title : Specification of the IP Flow Information Export (IPFIX) File Format Publication Date : October 2009 Author(s) : B. Trammell, E. Boschi, L. Mark, T. Zseby, A. Wagner Category : PROPOSED STANDARD Source : IP Flow Information Export Area : Operations and Management Stream : IETF Verifying Party : IESG From wwwrun@rfc-editor.org Mon Aug 1 07:01: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 5706A11E809D for ; Mon, 1 Aug 2011 07:01:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.481 X-Spam-Level: X-Spam-Status: No, score=-102.481 tagged_above=-999 required=5 tests=[AWL=0.119, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pv6O+zAGqDit for ; Mon, 1 Aug 2011 07:01:45 -0700 (PDT) Received: from rfc-editor.org (rfc-editor.org [IPv6:2001:1890:1112:1::2f]) by ietfa.amsl.com (Postfix) with ESMTP id DCBA011E809B for ; Mon, 1 Aug 2011 07:01:45 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id 70D0E98C4EB; Mon, 1 Aug 2011 07:01:52 -0700 (PDT) To: Thomas.Dietz@nw.neclab.eu, akoba@nttv6.net, bclaise@cisco.com, muenz@net.in.tum.de, dromasca@avaya.com, rbonica@juniper.net, n.brownlee@auckland.ac.nz, quittek@neclab.eu From: RFC Errata System Message-Id: <20110801140152.70D0E98C4EB@rfc-editor.org> Date: Mon, 1 Aug 2011 07:01:52 -0700 (PDT) Cc: ipfix@ietf.org, rfc-editor@rfc-editor.org Subject: [IPFIX] [Editorial Errata Reported] RFC5815 (2882) 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, 01 Aug 2011 14:01:46 -0000 The following errata report has been submitted for RFC5815, "Definitions of Managed Objects for IP Flow Information Export". -------------------------------------- You may review the report below and at: http://www.rfc-editor.org/errata_search.php?rfc=5815&eid=2882 -------------------------------------- Type: Editorial Reported by: Paul Aitken Section: multiple Original Text ------------- Benoit Claise Cisco Systems, Inc. De Kleetlaan 6a b1 Degem 1831 BE Corrected Text -------------- Benoit Claise Cisco Systems, Inc. De Kleetlaan 6a b1 Diegem 1831 BE Notes ----- s/Degem/Diegem/ - three times: in the MIB in section 8.1, in the MIB in section 8.2, and in the Author's Addresses. Instructions: ------------- This errata is currently posted as "Reported". If necessary, please use "Reply All" to discuss whether it should be verified or rejected. When a decision is reached, the verifying party (IESG) can log in to change the status and edit the report, if necessary. -------------------------------------- RFC5815 (draft-ietf-ipfix-mib-10) -------------------------------------- Title : Definitions of Managed Objects for IP Flow Information Export Publication Date : April 2010 Author(s) : T. Dietz, Ed., A. Kobayashi, B. Claise, G. Muenz Category : PROPOSED STANDARD Source : IP Flow Information Export Area : Operations and Management Stream : IETF Verifying Party : IESG From wwwrun@rfc-editor.org Mon Aug 1 07:39:03 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 054EF11E80C4 for ; Mon, 1 Aug 2011 07:39:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.483 X-Spam-Level: X-Spam-Status: No, score=-102.483 tagged_above=-999 required=5 tests=[AWL=0.117, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9+OgLA2fPM32 for ; Mon, 1 Aug 2011 07:39:02 -0700 (PDT) Received: from rfc-editor.org (rfc-editor.org [IPv6:2001:1890:1112:1::2f]) by ietfa.amsl.com (Postfix) with ESMTP id 730FE11E8085 for ; Mon, 1 Aug 2011 07:39:02 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id C7EDC98C4EF; Mon, 1 Aug 2011 07:39:08 -0700 (PDT) To: boschie@tik.ee.ethz.ch, trammell@tik.ee.ethz.ch, dromasca@avaya.com, rbonica@juniper.net, n.brownlee@auckland.ac.nz, quittek@neclab.eu From: RFC Errata System Message-Id: <20110801143908.C7EDC98C4EF@rfc-editor.org> Date: Mon, 1 Aug 2011 07:39:08 -0700 (PDT) Cc: ipfix@ietf.org, rfc-editor@rfc-editor.org Subject: [IPFIX] [Editorial Errata Reported] RFC6235 (2883) 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, 01 Aug 2011 14:39:03 -0000 The following errata report has been submitted for RFC6235, "IP Flow Anonymization Support". -------------------------------------- You may review the report below and at: http://www.rfc-editor.org/errata_search.php?rfc=6235&eid=2883 -------------------------------------- Type: Editorial Reported by: Paul Aitken Section: 7.2.4 Original Text ------------- The Exporting Process Reliability Statistics Options Template, recommended in [RFC5101], contains an Exporting Process ID field, which may be an exportingProcessIPv4Address Information Element or an exportingProcessIPv6Address Information Element. ... Similarly, the Export Session Details Options Template and Message Details Options Template specified for the IPFIX File Format [RFC5655] may contain the exportingProcessIPv4Address Information Element or the exportingProcessIPv6Address Information Element to identify an Exporting Process from which a flow record was received, and the collectingProcessIPv4Address Information Element or the collectingProcessIPv6Address Information Element to identify the Collecting Process which received it. Corrected Text -------------- The Exporting Process Reliability Statistics Options Template, recommended in [RFC5101], contains an Exporting Process ID field, which may be an exporterIPv4Address Information Element or an exporterIPv6Address Information Element. ... Similarly, the Export Session Details Options Template and Message Details Options Template specified for the IPFIX File Format [RFC5655] may contain the exporterIPv4Address Information Element or the exporterIPv6Address Information Element to identify an Exporting Process from which a flow record was received, and the collectorIPv4Address Information Element or the collectorIPv6Address Information Element to identify the Collecting Process which received it. Notes ----- s/exportingProcessIPv4Address/exporterIPv4Address/ (twice) s/exportingProcessIPv6Address/exporterIPv6Address/ (twice) s/collectingProcessIPv4Address/collectorIPv4Address/ (once) s/collectingProcessIPv6Address/collectorIPv6Address/ (once) - per the names in IANA's IPFIX registry. Instructions: ------------- This errata is currently posted as "Reported". If necessary, please use "Reply All" to discuss whether it should be verified or rejected. When a decision is reached, the verifying party (IESG) can log in to change the status and edit the report, if necessary. -------------------------------------- RFC6235 (draft-ietf-ipfix-anon-06) -------------------------------------- Title : IP Flow Anonymization Support Publication Date : May 2011 Author(s) : E. Boschi, B. Trammell Category : EXPERIMENTAL Source : IP Flow Information Export Area : Operations and Management Stream : IETF Verifying Party : IESG From wwwrun@rfc-editor.org Mon Aug 1 07:51:29 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 A2DD121F8D2A for ; Mon, 1 Aug 2011 07:51:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.485 X-Spam-Level: X-Spam-Status: No, score=-102.485 tagged_above=-999 required=5 tests=[AWL=0.115, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BO-5ZNHIxMBT for ; Mon, 1 Aug 2011 07:51:29 -0700 (PDT) Received: from rfc-editor.org (rfc-editor.org [IPv6:2001:1890:1112:1::2f]) by ietfa.amsl.com (Postfix) with ESMTP id 38D1F21F8CE9 for ; Mon, 1 Aug 2011 07:51:29 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id DB17798C4F7; Mon, 1 Aug 2011 07:51:35 -0700 (PDT) To: bclaise@cisco.com, gowri@cisco.com, paitken@cisco.com, syates@cisco.com, dromasca@avaya.com, rbonica@juniper.net, n.brownlee@auckland.ac.nz, quittek@neclab.eu From: RFC Errata System Message-Id: <20110801145135.DB17798C4F7@rfc-editor.org> Date: Mon, 1 Aug 2011 07:51:35 -0700 (PDT) Cc: ipfix@ietf.org, rfc-editor@rfc-editor.org Subject: [IPFIX] [Editorial Errata Reported] RFC6313 (2884) 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, 01 Aug 2011 14:51:29 -0000 The following errata report has been submitted for RFC6313, "Export of Structured Data in IP Flow Information Export (IPFIX)". -------------------------------------- You may review the report below and at: http://www.rfc-editor.org/errata_search.php?rfc=6313&eid=2884 -------------------------------------- Type: Editorial Reported by: Paul Aitken Section: 10.1 Original Text ------------- "Reducing Redundancy in IP Flow Information Export (IPFIX) and Packet Sampling (PSAMP) Reports" [RFC5473] describes a bandwidth saving method for exporting Flow or packet information using the IP Flow Information Export (IPFIX) protocol. It defines the commonPropertiesID Information Element for exporting Common Properties. Corrected Text -------------- "Reducing Redundancy in IP Flow Information Export (IPFIX) and Packet Sampling (PSAMP) Reports" [RFC5473] describes a bandwidth saving method for exporting Flow or packet information using the IP Flow Information Export (IPFIX) protocol. It discusses the commonPropertiesID Information Element for exporting Common Properties. Notes ----- s/defines/discusses/ - commonPropertiesId is not defined in [RFC5473], but in [RFC5101]. [RFC5473] doesn't have any IANA actions. Instructions: ------------- This errata is currently posted as "Reported". If necessary, please use "Reply All" to discuss whether it should be verified or rejected. When a decision is reached, the verifying party (IESG) can log in to change the status and edit the report, if necessary. -------------------------------------- RFC6313 (draft-ietf-ipfix-structured-data-06) -------------------------------------- Title : Export of Structured Data in IP Flow Information Export (IPFIX) Publication Date : July 2011 Author(s) : B. Claise, G. Dhandapani, P. Aitken, S. Yates Category : PROPOSED STANDARD Source : IP Flow Information Export Area : Operations and Management Stream : IETF Verifying Party : IESG From wwwrun@rfc-editor.org Mon Aug 1 07:54:37 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 C836A21F8A35 for ; Mon, 1 Aug 2011 07:54:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.487 X-Spam-Level: X-Spam-Status: No, score=-102.487 tagged_above=-999 required=5 tests=[AWL=0.113, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id N70596aYQiPy for ; Mon, 1 Aug 2011 07:54:37 -0700 (PDT) Received: from rfc-editor.org (rfc-editor.org [IPv6:2001:1890:1112:1::2f]) by ietfa.amsl.com (Postfix) with ESMTP id 6B0F221F89CC for ; Mon, 1 Aug 2011 07:54:37 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id 1826298C4F7; Mon, 1 Aug 2011 07:54:44 -0700 (PDT) To: bclaise@cisco.com, gowri@cisco.com, paitken@cisco.com, syates@cisco.com, dromasca@avaya.com, rbonica@juniper.net, n.brownlee@auckland.ac.nz, quittek@neclab.eu From: RFC Errata System Message-Id: <20110801145444.1826298C4F7@rfc-editor.org> Date: Mon, 1 Aug 2011 07:54:44 -0700 (PDT) Cc: ipfix@ietf.org, rfc-editor@rfc-editor.org Subject: [IPFIX] [Editorial Errata Reported] RFC6313 (2885) 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, 01 Aug 2011 14:54:37 -0000 The following errata report has been submitted for RFC6313, "Export of Structured Data in IP Flow Information Export (IPFIX)". -------------------------------------- You may review the report below and at: http://www.rfc-editor.org/errata_search.php?rfc=6313&eid=2885 -------------------------------------- Type: Editorial Reported by: Paul Aitken Section: multiple Original Text ------------- commonPropertiesID Corrected Text -------------- commonPropertiesId Notes ----- s/commonPropertiesID/commonPropertiesId/ (thrice) - in sections 10.1, 10.1.1, and 10.1.2. Per the definition in RFC 5101 and in IANA's IPFIX registry. Instructions: ------------- This errata is currently posted as "Reported". If necessary, please use "Reply All" to discuss whether it should be verified or rejected. When a decision is reached, the verifying party (IESG) can log in to change the status and edit the report, if necessary. -------------------------------------- RFC6313 (draft-ietf-ipfix-structured-data-06) -------------------------------------- Title : Export of Structured Data in IP Flow Information Export (IPFIX) Publication Date : July 2011 Author(s) : B. Claise, G. Dhandapani, P. Aitken, S. Yates Category : PROPOSED STANDARD Source : IP Flow Information Export Area : Operations and Management Stream : IETF Verifying Party : IESG From wwwrun@rfc-editor.org Mon Aug 1 07:58:57 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 2B12811E8073 for ; Mon, 1 Aug 2011 07:58:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.489 X-Spam-Level: X-Spam-Status: No, score=-102.489 tagged_above=-999 required=5 tests=[AWL=0.111, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3lFZRAFkREum for ; Mon, 1 Aug 2011 07:58:56 -0700 (PDT) Received: from rfc-editor.org (rfc-editor.org [IPv6:2001:1890:1112:1::2f]) by ietfa.amsl.com (Postfix) with ESMTP id B9D0B11E8070 for ; Mon, 1 Aug 2011 07:58:56 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id E0D8598C4F7; Mon, 1 Aug 2011 07:58:58 -0700 (PDT) To: elisa.boschi@hitachi-eu.com, lutz.mark@ifam.fraunhofer.de, bclaise@cisco.com, dromasca@avaya.com, rbonica@juniper.net, n.brownlee@auckland.ac.nz, quittek@neclab.eu From: RFC Errata System Message-Id: <20110801145858.E0D8598C4F7@rfc-editor.org> Date: Mon, 1 Aug 2011 07:58:58 -0700 (PDT) Cc: ipfix@ietf.org, rfc-editor@rfc-editor.org Subject: [IPFIX] [Editorial Errata Reported] RFC5473 (2886) 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, 01 Aug 2011 14:58:57 -0000 The following errata report has been submitted for RFC5473, "Reducing Redundancy in IP Flow Information Export (IPFIX) and Packet Sampling (PSAMP) Reports". -------------------------------------- You may review the report below and at: http://www.rfc-editor.org/errata_search.php?rfc=5473&eid=2886 -------------------------------------- Type: Editorial Reported by: Paul Aitken Section: (all) Original Text ------------- commonPropertiesID Corrected Text -------------- commonPropertiesId Notes ----- This doc consistently uses "commonPropertiesID" when the field defined in [RFC5101] and IANA's IPFIX registry is "commonPropertiesId". Note that some of the other errata on this RFC also contain this incorrect usage. Instructions: ------------- This errata is currently posted as "Reported". If necessary, please use "Reply All" to discuss whether it should be verified or rejected. When a decision is reached, the verifying party (IESG) can log in to change the status and edit the report, if necessary. -------------------------------------- RFC5473 (draft-ietf-ipfix-reducing-redundancy-04) -------------------------------------- Title : Reducing Redundancy in IP Flow Information Export (IPFIX) and Packet Sampling (PSAMP) Reports Publication Date : March 2009 Author(s) : E. Boschi, L. Mark, B. Claise Category : INFORMATIONAL Source : IP Flow Information Export Area : Operations and Management Stream : IETF Verifying Party : IESG From wwwrun@rfc-editor.org Mon Aug 1 08:02: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 EB8AC21F8C70 for ; Mon, 1 Aug 2011 08:02:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.49 X-Spam-Level: X-Spam-Status: No, score=-102.49 tagged_above=-999 required=5 tests=[AWL=0.110, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6kbCwsiGmaEd for ; Mon, 1 Aug 2011 08:02:53 -0700 (PDT) Received: from rfc-editor.org (rfc-editor.org [IPv6:2001:1890:1112:1::2f]) by ietfa.amsl.com (Postfix) with ESMTP id 1713521F8BFE for ; Mon, 1 Aug 2011 08:02:48 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id 72DDA98C4F7; Mon, 1 Aug 2011 08:02:47 -0700 (PDT) To: boschie@tik.ee.ethz.ch, trammell@tik.ee.ethz.ch, dromasca@avaya.com, rbonica@juniper.net, n.brownlee@auckland.ac.nz, quittek@neclab.eu From: RFC Errata System Message-Id: <20110801150253.72DDA98C4F7@rfc-editor.org> Date: Mon, 1 Aug 2011 08:02:47 -0700 (PDT) Cc: ipfix@ietf.org, rfc-editor@rfc-editor.org Subject: [IPFIX] [Editorial Errata Reported] RFC6235 (2887) 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, 01 Aug 2011 15:02:54 -0000 The following errata report has been submitted for RFC6235, "IP Flow Anonymization Support". -------------------------------------- You may review the report below and at: http://www.rfc-editor.org/errata_search.php?rfc=6235&eid=2887 -------------------------------------- Type: Editorial Reported by: Paul Aitken Section: 7.2.1 Original Text ------------- In this description, a timestamp is an Information Element with the data type dateTimeSeconds, dataTimeMilliseconds, dateTimeMicroseconds, or dateTimeNanoseconds; Corrected Text -------------- In this description, a timestamp is an Information Element with the data type dateTimeSeconds, dateTimeMilliseconds, dateTimeMicroseconds, or dateTimeNanoseconds; Notes ----- s/dataTimeMilliseconds/dateTimeMilliseconds/ Per [RFC5102] section 3.1.16, the definition is "dateTimeMilliseconds" Instructions: ------------- This errata is currently posted as "Reported". If necessary, please use "Reply All" to discuss whether it should be verified or rejected. When a decision is reached, the verifying party (IESG) can log in to change the status and edit the report, if necessary. -------------------------------------- RFC6235 (draft-ietf-ipfix-anon-06) -------------------------------------- Title : IP Flow Anonymization Support Publication Date : May 2011 Author(s) : E. Boschi, B. Trammell Category : EXPERIMENTAL Source : IP Flow Information Export Area : Operations and Management Stream : IETF Verifying Party : IESG From wwwrun@rfc-editor.org Mon Aug 1 08:05:33 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 CFE3821F8D00 for ; Mon, 1 Aug 2011 08:05:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.492 X-Spam-Level: X-Spam-Status: No, score=-102.492 tagged_above=-999 required=5 tests=[AWL=0.108, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ahaPC-UEapTS for ; Mon, 1 Aug 2011 08:05:33 -0700 (PDT) Received: from rfc-editor.org (rfc-editor.org [IPv6:2001:1890:1112:1::2f]) by ietfa.amsl.com (Postfix) with ESMTP id 64D3C21F8CFF for ; Mon, 1 Aug 2011 08:05:33 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id 1839598C4F7; Mon, 1 Aug 2011 08:05:40 -0700 (PDT) To: bclaise@cisco.com, dromasca@avaya.com, rbonica@juniper.net, n.brownlee@auckland.ac.nz, quittek@neclab.eu From: RFC Errata System Message-Id: <20110801150540.1839598C4F7@rfc-editor.org> Date: Mon, 1 Aug 2011 08:05:40 -0700 (PDT) Cc: ipfix@ietf.org, rfc-editor@rfc-editor.org Subject: [IPFIX] [Editorial Errata Reported] RFC5101 (2888) 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, 01 Aug 2011 15:05:33 -0000 The following errata report has been submitted for RFC5101, "Specification of the IP Flow Information Export (IPFIX) Protocol for the Exchange of IP Traffic Flow Information". -------------------------------------- You may review the report below and at: http://www.rfc-editor.org/errata_search.php?rfc=5101&eid=2888 -------------------------------------- Type: Editorial Reported by: Paul Aitken Section: 6.1.7 Original Text ------------- 6.1.7. dateTimeSeconds The data type dateTimeseconds represents a time value in units of seconds normalized to the GMT timezone. It MUST be encoded in a 32-bit integer containing the number of seconds since 0000 UTC Jan 1, 1970. The 32-bit integer allows the time encoding up to 136 years. Corrected Text -------------- 6.1.7. dateTimeSeconds The data type dateTimeSeconds represents a time value in units of seconds normalized to the GMT timezone. It MUST be encoded in a 32-bit integer containing the number of seconds since 0000 UTC Jan 1, 1970. The 32-bit integer allows the time encoding up to 136 years. Notes ----- s/dateTimeseconds/dateTimeSeconds/ - per the section title, the definition in IANA's IPFIX registry, and usage in other IPFIX RFCs. Instructions: ------------- This errata is currently posted as "Reported". If necessary, please use "Reply All" to discuss whether it should be verified or rejected. When a decision is reached, the verifying party (IESG) can log in to change the status and edit the report, if necessary. -------------------------------------- RFC5101 (draft-ietf-ipfix-protocol-26) -------------------------------------- Title : Specification of the IP Flow Information Export (IPFIX) Protocol for the Exchange of IP Traffic Flow Information Publication Date : January 2008 Author(s) : B. Claise, Ed. Category : PROPOSED STANDARD Source : IP Flow Information Export Area : Operations and Management Stream : IETF Verifying Party : IESG From wwwrun@rfc-editor.org Mon Aug 1 08:19:33 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 E3BEF21F8743 for ; Mon, 1 Aug 2011 08:19:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.494 X-Spam-Level: X-Spam-Status: No, score=-102.494 tagged_above=-999 required=5 tests=[AWL=0.106, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Tz0mB0A6R-Sx for ; Mon, 1 Aug 2011 08:19:33 -0700 (PDT) Received: from rfc-editor.org (rfc-editor.org [IPv6:2001:1890:1112:1::2f]) by ietfa.amsl.com (Postfix) with ESMTP id 74AAB21F856D for ; Mon, 1 Aug 2011 08:19:32 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id 9008198C4EF; Mon, 1 Aug 2011 08:19:39 -0700 (PDT) To: bclaise@cisco.com, dromasca@avaya.com, rbonica@juniper.net, n.brownlee@auckland.ac.nz, quittek@neclab.eu From: RFC Errata System Message-Id: <20110801151939.9008198C4EF@rfc-editor.org> Date: Mon, 1 Aug 2011 08:19:39 -0700 (PDT) Cc: ipfix@ietf.org, rfc-editor@rfc-editor.org Subject: [IPFIX] [Editorial Errata Reported] RFC5101 (2889) 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, 01 Aug 2011 15:19:34 -0000 The following errata report has been submitted for RFC5101, "Specification of the IP Flow Information Export (IPFIX) Protocol for the Exchange of IP Traffic Flow Information". -------------------------------------- You may review the report below and at: http://www.rfc-editor.org/errata_search.php?rfc=5101&eid=2889 -------------------------------------- Type: Editorial Reported by: Paul Aitken Section: multiple Original Text ------------- exportedFlowCount Corrected Text -------------- exportedFlowRecordTotalCount Notes ----- s/exportedFlowCount/exportedFlowRecordTotalCount/ (four times) - in sections A.4.1 (+figure), and A.4.3 (+figure). The definition in [RFC5102] and IANA's IPFIX registry is "exportedFlowRecordTotalCount" (as correctly used elsewhere in this RFC). Instructions: ------------- This errata is currently posted as "Reported". If necessary, please use "Reply All" to discuss whether it should be verified or rejected. When a decision is reached, the verifying party (IESG) can log in to change the status and edit the report, if necessary. -------------------------------------- RFC5101 (draft-ietf-ipfix-protocol-26) -------------------------------------- Title : Specification of the IP Flow Information Export (IPFIX) Protocol for the Exchange of IP Traffic Flow Information Publication Date : January 2008 Author(s) : B. Claise, Ed. Category : PROPOSED STANDARD Source : IP Flow Information Export Area : Operations and Management Stream : IETF Verifying Party : IESG From acmorton@att.com Mon Aug 1 08:22: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 AB90B11E809C; Mon, 1 Aug 2011 08:22:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.985 X-Spam-Level: X-Spam-Status: No, score=-104.985 tagged_above=-999 required=5 tests=[AWL=0.811, BAYES_00=-2.599, MSGID_FROM_MTA_HEADER=0.803, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MdSkS5rGEhZY; Mon, 1 Aug 2011 08:22:12 -0700 (PDT) Received: from mail120.messagelabs.com (mail120.messagelabs.com [216.82.250.83]) by ietfa.amsl.com (Postfix) with ESMTP id 6743F11E8094; Mon, 1 Aug 2011 08:22:11 -0700 (PDT) X-VirusChecked: Checked X-Env-Sender: acmorton@att.com X-Msg-Ref: server-6.tower-120.messagelabs.com!1312212136!22822120!1 X-StarScan-Version: 6.2.17; banners=-,-,- X-Originating-IP: [144.160.20.145] Received: (qmail 24205 invoked from network); 1 Aug 2011 15:22:17 -0000 Received: from sbcsmtp6.sbc.com (HELO mlpd192.enaf.sfdc.sbc.com) (144.160.20.145) by server-6.tower-120.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 1 Aug 2011 15:22:17 -0000 Received: from enaf.sfdc.sbc.com (localhost.localdomain [127.0.0.1]) by mlpd192.enaf.sfdc.sbc.com (8.14.4/8.14.4) with ESMTP id p71FMfHL024577; Mon, 1 Aug 2011 11:22:42 -0400 Received: from alpd052.aldc.att.com (alpd052.aldc.att.com [130.8.42.31]) by mlpd192.enaf.sfdc.sbc.com (8.14.4/8.14.4) with ESMTP id p71FMZ1b024419; Mon, 1 Aug 2011 11:22:35 -0400 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 p71FM94U018814; Mon, 1 Aug 2011 11:22:09 -0400 Received: from mailgw1.maillennium.att.com (mailgw1.maillennium.att.com [135.25.114.99]) by alpd052.aldc.att.com (8.14.4/8.14.4) with ESMTP id p71FLxj6018359; Mon, 1 Aug 2011 11:22:00 -0400 Message-Id: <201108011522.p71FLxj6018359@alpd052.aldc.att.com> Received: from acmt.att.com (vpn-135-70-148-100.vpn.mwst.att.com[135.70.148.100](misconfigured sender)) by maillennium.att.com (mailgw1) with SMTP id <20110801152158gw100e4lnme>; Mon, 1 Aug 2011 15:21:59 +0000 X-Originating-IP: [135.70.148.100] X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Mon, 01 Aug 2011 11:22:46 -0400 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-03 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, 01 Aug 2011 15:22:12 -0000 BMWG, CC: IPFIX WG, This message begins the third 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-03 The Last Call will end on August 31, 2011. 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. 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 wwwrun@rfc-editor.org Mon Aug 1 08:24: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 ECD2E11E80BB for ; Mon, 1 Aug 2011 08:24:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.495 X-Spam-Level: X-Spam-Status: No, score=-102.495 tagged_above=-999 required=5 tests=[AWL=0.105, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HI74HLNPdZfd for ; Mon, 1 Aug 2011 08:24:08 -0700 (PDT) Received: from rfc-editor.org (rfc-editor.org [IPv6:2001:1890:1112:1::2f]) by ietfa.amsl.com (Postfix) with ESMTP id ABF8611E8094 for ; Mon, 1 Aug 2011 08:24:07 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id 3408D98C4EF; Mon, 1 Aug 2011 08:24:13 -0700 (PDT) To: bclaise@cisco.com, dromasca@avaya.com, rbonica@juniper.net, n.brownlee@auckland.ac.nz, quittek@neclab.eu From: RFC Errata System Message-Id: <20110801152413.3408D98C4EF@rfc-editor.org> Date: Mon, 1 Aug 2011 08:24:13 -0700 (PDT) Cc: ipfix@ietf.org, rfc-editor@rfc-editor.org Subject: [IPFIX] [Editorial Errata Reported] RFC5101 (2890) 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, 01 Aug 2011 15:24:09 -0000 The following errata report has been submitted for RFC5101, "Specification of the IP Flow Information Export (IPFIX) Protocol for the Exchange of IP Traffic Flow Information". -------------------------------------- You may review the report below and at: http://www.rfc-editor.org/errata_search.php?rfc=5101&eid=2890 -------------------------------------- Type: Editorial Reported by: Paul Aitken Section: multiple Original Text ------------- exportedPacketCount Corrected Text -------------- exportedMessageTotalCount Notes ----- s/exportedPacketCount/exportedMessageTotalCount/ (six times) - in sections A.4.1 (+figure), A.4.2 (+figure), and A.4.3 (+figure). [RFC5102] defines exportedMessageTotalCount, exportedOctetTotalCount, and exportedFlowRecordTotalCount - but no "exportedPacketCount". Presumably "exportedMessageTotalCount" is the name that's intended here. Instructions: ------------- This errata is currently posted as "Reported". If necessary, please use "Reply All" to discuss whether it should be verified or rejected. When a decision is reached, the verifying party (IESG) can log in to change the status and edit the report, if necessary. -------------------------------------- RFC5101 (draft-ietf-ipfix-protocol-26) -------------------------------------- Title : Specification of the IP Flow Information Export (IPFIX) Protocol for the Exchange of IP Traffic Flow Information Publication Date : January 2008 Author(s) : B. Claise, Ed. Category : PROPOSED STANDARD Source : IP Flow Information Export Area : Operations and Management Stream : IETF Verifying Party : IESG From wwwrun@rfc-editor.org Mon Aug 1 09:13:51 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 4C7D611E80DF for ; Mon, 1 Aug 2011 09:13:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.498 X-Spam-Level: X-Spam-Status: No, score=-102.498 tagged_above=-999 required=5 tests=[AWL=0.102, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5abUHwOiwpkr for ; Mon, 1 Aug 2011 09:13:50 -0700 (PDT) Received: from rfc-editor.org (rfc-editor.org [IPv6:2001:1890:1112:1::2f]) by ietfa.amsl.com (Postfix) with ESMTP id EA34011E8077 for ; Mon, 1 Aug 2011 09:13:50 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id AEF4098C50F; Mon, 1 Aug 2011 09:13:57 -0700 (PDT) To: bclaise@cisco.com, dromasca@avaya.com, rbonica@juniper.net, n.brownlee@auckland.ac.nz, quittek@neclab.eu From: RFC Errata System Message-Id: <20110801161357.AEF4098C50F@rfc-editor.org> Date: Mon, 1 Aug 2011 09:13:57 -0700 (PDT) Cc: ipfix@ietf.org, rfc-editor@rfc-editor.org Subject: [IPFIX] [Editorial Errata Reported] RFC5101 (2891) 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, 01 Aug 2011 16:13:51 -0000 The following errata report has been submitted for RFC5101, "Specification of the IP Flow Information Export (IPFIX) Protocol for the Exchange of IP Traffic Flow Information". -------------------------------------- You may review the report below and at: http://www.rfc-editor.org/errata_search.php?rfc=5101&eid=2891 -------------------------------------- Type: Editorial Reported by: Paul Aitken Section: multiple Original Text ------------- inOctetDeltaCount Corrected Text -------------- octetDeltaCount Notes ----- s/inOctetDeltaCount/octetDeltaCount/ (four times) - in sections A.2.1 (+figure) and A.2.2 (+figure) Per [RFC5102] and IANA's IPFIX registry, the correct name is "octetDeltaCount". Instructions: ------------- This errata is currently posted as "Reported". If necessary, please use "Reply All" to discuss whether it should be verified or rejected. When a decision is reached, the verifying party (IESG) can log in to change the status and edit the report, if necessary. -------------------------------------- RFC5101 (draft-ietf-ipfix-protocol-26) -------------------------------------- Title : Specification of the IP Flow Information Export (IPFIX) Protocol for the Exchange of IP Traffic Flow Information Publication Date : January 2008 Author(s) : B. Claise, Ed. Category : PROPOSED STANDARD Source : IP Flow Information Export Area : Operations and Management Stream : IETF Verifying Party : IESG From wwwrun@rfc-editor.org Mon Aug 1 09:15:11 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 CC54B11E80F4 for ; Mon, 1 Aug 2011 09:15:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.5 X-Spam-Level: X-Spam-Status: No, score=-102.5 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HhWYl2vgArkk for ; Mon, 1 Aug 2011 09:15:11 -0700 (PDT) Received: from rfc-editor.org (rfc-editor.org [IPv6:2001:1890:1112:1::2f]) by ietfa.amsl.com (Postfix) with ESMTP id 67CD711E8077 for ; Mon, 1 Aug 2011 09:15:11 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id 485DB98C50F; Mon, 1 Aug 2011 09:15:18 -0700 (PDT) To: bclaise@cisco.com, dromasca@avaya.com, rbonica@juniper.net, n.brownlee@auckland.ac.nz, quittek@neclab.eu From: RFC Errata System Message-Id: <20110801161518.485DB98C50F@rfc-editor.org> Date: Mon, 1 Aug 2011 09:15:18 -0700 (PDT) Cc: ipfix@ietf.org, rfc-editor@rfc-editor.org Subject: [IPFIX] [Editorial Errata Reported] RFC5101 (2892) 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, 01 Aug 2011 16:15:11 -0000 The following errata report has been submitted for RFC5101, "Specification of the IP Flow Information Export (IPFIX) Protocol for the Exchange of IP Traffic Flow Information". -------------------------------------- You may review the report below and at: http://www.rfc-editor.org/errata_search.php?rfc=5101&eid=2892 -------------------------------------- Type: Editorial Reported by: Paul Aitken Section: multiple Original Text ------------- inPacketDeltaCount Corrected Text -------------- packetDeltaCount Notes ----- s/inPacketDeltaCount/packetDeltaCount/ (four times) - in sections A.2.1 (+figure) and A.2.2 (+figure) Per [RFC5102] and IANA's IPFIX registry, the correct name is "packetDeltaCount". Instructions: ------------- This errata is currently posted as "Reported". If necessary, please use "Reply All" to discuss whether it should be verified or rejected. When a decision is reached, the verifying party (IESG) can log in to change the status and edit the report, if necessary. -------------------------------------- RFC5101 (draft-ietf-ipfix-protocol-26) -------------------------------------- Title : Specification of the IP Flow Information Export (IPFIX) Protocol for the Exchange of IP Traffic Flow Information Publication Date : January 2008 Author(s) : B. Claise, Ed. Category : PROPOSED STANDARD Source : IP Flow Information Export Area : Operations and Management Stream : IETF Verifying Party : IESG From wwwrun@rfc-editor.org Mon Aug 1 09:19:18 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 62E9911E80C4 for ; Mon, 1 Aug 2011 09:19:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.501 X-Spam-Level: X-Spam-Status: No, score=-102.501 tagged_above=-999 required=5 tests=[AWL=0.099, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sDlT0VkPM3Qf for ; Mon, 1 Aug 2011 09:19:18 -0700 (PDT) Received: from rfc-editor.org (rfc-editor.org [IPv6:2001:1890:1112:1::2f]) by ietfa.amsl.com (Postfix) with ESMTP id 08C0411E8077 for ; Mon, 1 Aug 2011 09:19:18 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id D474A98C50F; Mon, 1 Aug 2011 09:19:24 -0700 (PDT) To: elisa.boschi@hitachi-eu.com, lutz.mark@ifam.fraunhofer.de, bclaise@cisco.com, dromasca@avaya.com, rbonica@juniper.net, n.brownlee@auckland.ac.nz, quittek@neclab.eu From: RFC Errata System Message-Id: <20110801161924.D474A98C50F@rfc-editor.org> Date: Mon, 1 Aug 2011 09:19:24 -0700 (PDT) Cc: ipfix@ietf.org, rfc-editor@rfc-editor.org Subject: [IPFIX] [Editorial Errata Reported] RFC5473 (2893) 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, 01 Aug 2011 16:19:18 -0000 The following errata report has been submitted for RFC5473, "Reducing Redundancy in IP Flow Information Export (IPFIX) and Packet Sampling (PSAMP) Reports". -------------------------------------- You may review the report below and at: http://www.rfc-editor.org/errata_search.php?rfc=5473&eid=2893 -------------------------------------- Type: Editorial Reported by: Paul Aitken Section: A.1 Original Text ------------- inOctetDeltaCount Corrected Text -------------- octetDeltaCount Notes ----- s/inOctetDeltaCount/octetDeltaCount/ (three times) - including figure 10. Per [RFC5102] and IANA's IPFIX registry, the correct name is "octetDeltaCount". Instructions: ------------- This errata is currently posted as "Reported". If necessary, please use "Reply All" to discuss whether it should be verified or rejected. When a decision is reached, the verifying party (IESG) can log in to change the status and edit the report, if necessary. -------------------------------------- RFC5473 (draft-ietf-ipfix-reducing-redundancy-04) -------------------------------------- Title : Reducing Redundancy in IP Flow Information Export (IPFIX) and Packet Sampling (PSAMP) Reports Publication Date : March 2009 Author(s) : E. Boschi, L. Mark, B. Claise Category : INFORMATIONAL Source : IP Flow Information Export Area : Operations and Management Stream : IETF Verifying Party : IESG From wwwrun@rfc-editor.org Mon Aug 1 09:21:19 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 4ABBF11E8104 for ; Mon, 1 Aug 2011 09:21:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.503 X-Spam-Level: X-Spam-Status: No, score=-102.503 tagged_above=-999 required=5 tests=[AWL=0.097, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MsS2DEsQ2rI9 for ; Mon, 1 Aug 2011 09:21:15 -0700 (PDT) Received: from rfc-editor.org (rfc-editor.org [IPv6:2001:1890:1112:1::2f]) by ietfa.amsl.com (Postfix) with ESMTP id C8B8011E80FE for ; Mon, 1 Aug 2011 09:21:15 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id A3AC898C4EB; Mon, 1 Aug 2011 09:21:22 -0700 (PDT) To: elisa.boschi@hitachi-eu.com, lutz.mark@ifam.fraunhofer.de, bclaise@cisco.com, dromasca@avaya.com, rbonica@juniper.net, n.brownlee@auckland.ac.nz, quittek@neclab.eu From: RFC Errata System Message-Id: <20110801162122.A3AC898C4EB@rfc-editor.org> Date: Mon, 1 Aug 2011 09:21:22 -0700 (PDT) Cc: ipfix@ietf.org, rfc-editor@rfc-editor.org Subject: [IPFIX] [Editorial Errata Reported] RFC5473 (2894) 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, 01 Aug 2011 16:21:19 -0000 The following errata report has been submitted for RFC5473, "Reducing Redundancy in IP Flow Information Export (IPFIX) and Packet Sampling (PSAMP) Reports". -------------------------------------- You may review the report below and at: http://www.rfc-editor.org/errata_search.php?rfc=5473&eid=2894 -------------------------------------- Type: Editorial Reported by: Paul Aitken Section: A.1 Original Text ------------- inPacketDeltaCount Corrected Text -------------- packetDeltaCount Notes ----- s/inPacketDeltaCount/packetDeltaCount/ (three times) - including figure 10. Per [RFC5102] and IANA's IPFIX registry, the correct name is "packetDeltaCount". Instructions: ------------- This errata is currently posted as "Reported". If necessary, please use "Reply All" to discuss whether it should be verified or rejected. When a decision is reached, the verifying party (IESG) can log in to change the status and edit the report, if necessary. -------------------------------------- RFC5473 (draft-ietf-ipfix-reducing-redundancy-04) -------------------------------------- Title : Reducing Redundancy in IP Flow Information Export (IPFIX) and Packet Sampling (PSAMP) Reports Publication Date : March 2009 Author(s) : E. Boschi, L. Mark, B. Claise Category : INFORMATIONAL Source : IP Flow Information Export Area : Operations and Management Stream : IETF Verifying Party : IESG From wwwrun@rfc-editor.org Mon Aug 1 09:25:02 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 7D3F421F8C33 for ; Mon, 1 Aug 2011 09:25:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.504 X-Spam-Level: X-Spam-Status: No, score=-102.504 tagged_above=-999 required=5 tests=[AWL=0.096, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cEseFr9Rf5WT for ; Mon, 1 Aug 2011 09:25:01 -0700 (PDT) Received: from rfc-editor.org (rfc-editor.org [IPv6:2001:1890:1112:1::2f]) by ietfa.amsl.com (Postfix) with ESMTP id DD48421F8C25 for ; Mon, 1 Aug 2011 09:25:01 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id 6015598C4EB; Mon, 1 Aug 2011 09:25:08 -0700 (PDT) To: Thomas.Dietz@nw.neclab.eu, akoba@nttv6.net, bclaise@cisco.com, muenz@net.in.tum.de, dromasca@avaya.com, rbonica@juniper.net, n.brownlee@auckland.ac.nz, quittek@neclab.eu From: RFC Errata System Message-Id: <20110801162508.6015598C4EB@rfc-editor.org> Date: Mon, 1 Aug 2011 09:25:08 -0700 (PDT) Cc: ipfix@ietf.org, rfc-editor@rfc-editor.org Subject: [IPFIX] [Editorial Errata Reported] RFC5815 (2895) 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, 01 Aug 2011 16:25:02 -0000 The following errata report has been submitted for RFC5815, "Definitions of Managed Objects for IP Flow Information Export". -------------------------------------- You may review the report below and at: http://www.rfc-editor.org/errata_search.php?rfc=5815&eid=2895 -------------------------------------- Type: Editorial Reported by: Paul Aitken Section: 6.1 Original Text ------------- ipfixSelectorFunctions (1) | +- ipfixFuncMyFunc (?) | +- ipfixFuncMyFuncAvail (1) = true +- ipfixFuncMyFuncParameters (2) | +- ipfixFuncMyFuncParametersEntry (1) | +- index (1) (ipfixFuncMyFuncParametersIndex) | +- ipfixFuncMyFuncParam1 (1) = 47 | +- ipfixFuncMyFuncParam2 (2) = -128 | +- ipficFuncMyFuncParam3 (3) = 19 | +- index(4) (ipfixFuncMyFuncParametersIndex) +- ipfixFuncMyFuncParam1 (1) = 19 +- ipfixFuncMyFuncParam2 (2) = -1 +- ipficFuncMyFuncParam3 (3) = 728 Corrected Text -------------- ipfixSelectorFunctions (1) | +- ipfixFuncMyFunc (?) | +- ipfixFuncMyFuncAvail (1) = true +- ipfixFuncMyFuncParameters (2) | +- ipfixFuncMyFuncParametersEntry (1) | +- index (1) (ipfixFuncMyFuncParametersIndex) | +- ipfixFuncMyFuncParam1 (1) = 47 | +- ipfixFuncMyFuncParam2 (2) = -128 | +- ipfixFuncMyFuncParam3 (3) = 19 | +- index(4) (ipfixFuncMyFuncParametersIndex) +- ipfixFuncMyFuncParam1 (1) = 19 +- ipfixFuncMyFuncParam2 (2) = -1 +- ipfixFuncMyFuncParam3 (3) = 728 Notes ----- s/ipficFuncMyFuncParam3/ipfixFuncMyFuncParam3/ (twice) Typo. Instructions: ------------- This errata is currently posted as "Reported". If necessary, please use "Reply All" to discuss whether it should be verified or rejected. When a decision is reached, the verifying party (IESG) can log in to change the status and edit the report, if necessary. -------------------------------------- RFC5815 (draft-ietf-ipfix-mib-10) -------------------------------------- Title : Definitions of Managed Objects for IP Flow Information Export Publication Date : April 2010 Author(s) : T. Dietz, Ed., A. Kobayashi, B. Claise, G. Muenz Category : PROPOSED STANDARD Source : IP Flow Information Export Area : Operations and Management Stream : IETF Verifying Party : IESG From wwwrun@rfc-editor.org Mon Aug 1 09:29:55 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 5F59521F8E32 for ; Mon, 1 Aug 2011 09:29:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.505 X-Spam-Level: X-Spam-Status: No, score=-102.505 tagged_above=-999 required=5 tests=[AWL=0.095, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ejSAgbu9cFav for ; Mon, 1 Aug 2011 09:29:54 -0700 (PDT) Received: from rfc-editor.org (rfc-editor.org [IPv6:2001:1890:1112:1::2f]) by ietfa.amsl.com (Postfix) with ESMTP id F16B621F8E2F for ; Mon, 1 Aug 2011 09:29:54 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id CCC8798C4EB; Mon, 1 Aug 2011 09:30:01 -0700 (PDT) To: Thomas.Dietz@nw.neclab.eu, akoba@nttv6.net, bclaise@cisco.com, muenz@net.in.tum.de, dromasca@avaya.com, rbonica@juniper.net, n.brownlee@auckland.ac.nz, quittek@neclab.eu From: RFC Errata System Message-Id: <20110801163001.CCC8798C4EB@rfc-editor.org> Date: Mon, 1 Aug 2011 09:30:01 -0700 (PDT) Cc: ipfix@ietf.org, rfc-editor@rfc-editor.org Subject: [IPFIX] [Editorial Errata Reported] RFC5815 (2896) 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, 01 Aug 2011 16:29:55 -0000 The following errata report has been submitted for RFC5815, "Definitions of Managed Objects for IP Flow Information Export". -------------------------------------- You may review the report below and at: http://www.rfc-editor.org/errata_search.php?rfc=5815&eid=2896 -------------------------------------- Type: Editorial Reported by: Paul Aitken Section: multiple Original Text ------------- ipfixFunFn... Corrected Text -------------- ipfixFuncFn... Notes ----- Typo in section 6.1 and in the MIB in section 8.1. Inconsistent with use of "ipfixFuncF*" elsewhere in the document. Instructions: ------------- This errata is currently posted as "Reported". If necessary, please use "Reply All" to discuss whether it should be verified or rejected. When a decision is reached, the verifying party (IESG) can log in to change the status and edit the report, if necessary. -------------------------------------- RFC5815 (draft-ietf-ipfix-mib-10) -------------------------------------- Title : Definitions of Managed Objects for IP Flow Information Export Publication Date : April 2010 Author(s) : T. Dietz, Ed., A. Kobayashi, B. Claise, G. Muenz Category : PROPOSED STANDARD Source : IP Flow Information Export Area : Operations and Management Stream : IETF Verifying Party : IESG From wwwrun@rfc-editor.org Mon Aug 1 12:23:28 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 44D6B5E8019 for ; Mon, 1 Aug 2011 12:23:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.507 X-Spam-Level: X-Spam-Status: No, score=-102.507 tagged_above=-999 required=5 tests=[AWL=0.093, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ICL02vnw7jUq for ; Mon, 1 Aug 2011 12:23:27 -0700 (PDT) Received: from rfc-editor.org (rfc-editor.org [IPv6:2001:1890:1112:1::2f]) by ietfa.amsl.com (Postfix) with ESMTP id 0FCEB5E800D for ; Mon, 1 Aug 2011 12:23:26 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id 2F86198C4F3; Mon, 1 Aug 2011 12:23:26 -0700 (PDT) To: Thomas.Dietz@nw.neclab.eu, akoba@nttv6.net, bclaise@cisco.com, muenz@net.in.tum.de, dromasca@avaya.com, rbonica@juniper.net, n.brownlee@auckland.ac.nz, quittek@neclab.eu From: RFC Errata System Message-Id: <20110801192326.2F86198C4F3@rfc-editor.org> Date: Mon, 1 Aug 2011 12:23:26 -0700 (PDT) Cc: ipfix@ietf.org, rfc-editor@rfc-editor.org Subject: [IPFIX] [Editorial Errata Reported] RFC5815 (2897) 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, 01 Aug 2011 19:23:28 -0000 The following errata report has been submitted for RFC5815, "Definitions of Managed Objects for IP Flow Information Export". -------------------------------------- You may review the report below and at: http://www.rfc-editor.org/errata_search.php?rfc=5815&eid=2897 -------------------------------------- Type: Editorial Reported by: Paul Aitken Section: 8.1 Original Text ------------- ipfixMeteringProcessCacheId OBJECT-TYPE SYNTAX Unsigned32 (1..4294967295) MAX-ACCESS not-accessible STATUS current DESCRIPTION "Locally arbitrary, but unique identifier of an entry in the ipfixMeterinProcessTable. The value is expected to remain constant from a re-initialization of the entity's network management agent to the next re-initialization." ::= { ipfixMeteringProcessEntry 1 } Corrected Text -------------- ipfixMeteringProcessCacheId OBJECT-TYPE SYNTAX Unsigned32 (1..4294967295) MAX-ACCESS not-accessible STATUS current DESCRIPTION "Locally arbitrary, but unique identifier of an entry in the ipfixMeterinProcessTable. The value is expected to remain constant from a re-initialization of the entity's network management agent to the next re-initialization." ::= { ipfixMeteringProcessEntry 1 } Notes ----- s/ipfixMeterinProcessTable/ipfixMeteringProcessTable/ Typo: section 1.1.5: Metering Process Table defines "ipfixMeteringProcessTable". Instructions: ------------- This errata is currently posted as "Reported". If necessary, please use "Reply All" to discuss whether it should be verified or rejected. When a decision is reached, the verifying party (IESG) can log in to change the status and edit the report, if necessary. -------------------------------------- RFC5815 (draft-ietf-ipfix-mib-10) -------------------------------------- Title : Definitions of Managed Objects for IP Flow Information Export Publication Date : April 2010 Author(s) : T. Dietz, Ed., A. Kobayashi, B. Claise, G. Muenz Category : PROPOSED STANDARD Source : IP Flow Information Export Area : Operations and Management Stream : IETF Verifying Party : IESG From wwwrun@rfc-editor.org Mon Aug 1 12:37: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 EA85311E8132 for ; Mon, 1 Aug 2011 12:37:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.508 X-Spam-Level: X-Spam-Status: No, score=-102.508 tagged_above=-999 required=5 tests=[AWL=0.092, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZqydNXpoFtiQ for ; Mon, 1 Aug 2011 12:37:53 -0700 (PDT) Received: from rfc-editor.org (rfc-editor.org [IPv6:2001:1890:1112:1::2f]) by ietfa.amsl.com (Postfix) with ESMTP id 600C211E812C for ; Mon, 1 Aug 2011 12:37:47 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id 079D598C4F3; Mon, 1 Aug 2011 12:37:53 -0700 (PDT) To: Thomas.Dietz@nw.neclab.eu, akoba@nttv6.net, bclaise@cisco.com, muenz@net.in.tum.de, dromasca@avaya.com, rbonica@juniper.net, n.brownlee@auckland.ac.nz, quittek@neclab.eu From: RFC Errata System Message-Id: <20110801193753.079D598C4F3@rfc-editor.org> Date: Mon, 1 Aug 2011 12:37:53 -0700 (PDT) Cc: ipfix@ietf.org, rfc-editor@rfc-editor.org Subject: [IPFIX] [Editorial Errata Reported] RFC5815 (2898) 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, 01 Aug 2011 19:37:54 -0000 The following errata report has been submitted for RFC5815, "Definitions of Managed Objects for IP Flow Information Export". -------------------------------------- You may review the report below and at: http://www.rfc-editor.org/errata_search.php?rfc=5815&eid=2898 -------------------------------------- Type: Editorial Reported by: Paul Aitken Section: 1.1.7 Original Text ------------- ipfixSelectionProcessSelectorIndex OBJECT-TYPE SYNTAX Unsigned32 (1..4294967295) MAX-ACCESS not-accessible STATUS current DESCRIPTION "Index specifying the order in which the referenced ipfixSelctionProcessSelectorFunctions are applied to the observed packet stream within the given Selection Process (identified by the ipfixSelectionProcessIndex). The Selector Functions are applied in increasing order, i.e., Selector Functions with lower index are applied first." ::= { ipfixSelectionProcessEntry 2 } Corrected Text -------------- ipfixSelectionProcessSelectorIndex OBJECT-TYPE SYNTAX Unsigned32 (1..4294967295) MAX-ACCESS not-accessible STATUS current DESCRIPTION "Index specifying the order in which the referenced ipfixSelectionProcessSelectorFunctions are applied to the observed packet stream within the given Selection Process (identified by the ipfixSelectionProcessIndex). The Selector Functions are applied in increasing order, i.e., Selector Functions with lower index are applied first." ::= { ipfixSelectionProcessEntry 2 } Notes ----- s/ipfixSelctionProcessSelectorFunctions/ipfixSelectionProcessSelectorFunctions/ Typo: section 1.1.7 Selection Process Table defines "ipfixSelectionProcessSelectorFunction". Instructions: ------------- This errata is currently posted as "Reported". If necessary, please use "Reply All" to discuss whether it should be verified or rejected. When a decision is reached, the verifying party (IESG) can log in to change the status and edit the report, if necessary. -------------------------------------- RFC5815 (draft-ietf-ipfix-mib-10) -------------------------------------- Title : Definitions of Managed Objects for IP Flow Information Export Publication Date : April 2010 Author(s) : T. Dietz, Ed., A. Kobayashi, B. Claise, G. Muenz Category : PROPOSED STANDARD Source : IP Flow Information Export Area : Operations and Management Stream : IETF Verifying Party : IESG From wwwrun@rfc-editor.org Mon Aug 1 12:48:32 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 7BEB711E8156 for ; Mon, 1 Aug 2011 12:48:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.509 X-Spam-Level: X-Spam-Status: No, score=-102.509 tagged_above=-999 required=5 tests=[AWL=0.091, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ng-0l34vX1Hq for ; Mon, 1 Aug 2011 12:48:32 -0700 (PDT) Received: from rfc-editor.org (rfc-editor.org [IPv6:2001:1890:1112:1::2f]) by ietfa.amsl.com (Postfix) with ESMTP id 1637711E813A for ; Mon, 1 Aug 2011 12:48:32 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id 52C2A98C4F3; Mon, 1 Aug 2011 12:48:39 -0700 (PDT) To: bht@cert.org, elisa.boschi@hitachi-eu.com, dromasca@avaya.com, rbonica@juniper.net, n.brownlee@auckland.ac.nz, quittek@neclab.eu From: RFC Errata System Message-Id: <20110801194839.52C2A98C4F3@rfc-editor.org> Date: Mon, 1 Aug 2011 12:48:39 -0700 (PDT) Cc: ipfix@ietf.org, rfc-editor@rfc-editor.org Subject: [IPFIX] [Editorial Errata Reported] RFC5103 (2899) 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, 01 Aug 2011 19:48:32 -0000 The following errata report has been submitted for RFC5103, "Bidirectional Flow Export Using IP Flow Information Export (IPFIX)". -------------------------------------- You may review the report below and at: http://www.rfc-editor.org/errata_search.php?rfc=5103&eid=2899 -------------------------------------- Type: Editorial Reported by: Paul Aitken Section: 4 Original Text ------------- The location of the Observation Point(s) with respect to the middlebox can be communicated using Options with Observation Point as Scope and elements such as lineCardID or samplerID. Corrected Text -------------- The location of the Observation Point(s) with respect to the middlebox can be communicated using Options with Observation Point as Scope and elements such as lineCardId or selectorId. Notes ----- s/lineCardID/lineCardId/ s/samplerID/selectorId/ Per the definitions in RFC5102, RFC5477 and IANA's IPFIX registry. Instructions: ------------- This errata is currently posted as "Reported". If necessary, please use "Reply All" to discuss whether it should be verified or rejected. When a decision is reached, the verifying party (IESG) can log in to change the status and edit the report, if necessary. -------------------------------------- RFC5103 (draft-ietf-ipfix-biflow-05) -------------------------------------- Title : Bidirectional Flow Export Using IP Flow Information Export (IPFIX) Publication Date : January 2008 Author(s) : B. Trammell, E. Boschi Category : PROPOSED STANDARD Source : IP Flow Information Export Area : Operations and Management Stream : IETF Verifying Party : IESG From wwwrun@rfc-editor.org Mon Aug 1 12:54:11 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 79FD311E813A for ; Mon, 1 Aug 2011 12:54:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.51 X-Spam-Level: X-Spam-Status: No, score=-102.51 tagged_above=-999 required=5 tests=[AWL=0.090, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UHqpLNxP1T6a for ; Mon, 1 Aug 2011 12:54:10 -0700 (PDT) Received: from rfc-editor.org (rfc-editor.org [IPv6:2001:1890:1112:1::2f]) by ietfa.amsl.com (Postfix) with ESMTP id C6F6D11E8077 for ; Mon, 1 Aug 2011 12:54:10 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id DF39F98C4F3; Mon, 1 Aug 2011 12:54:17 -0700 (PDT) To: elisa.boschi@hitachi-eu.com, lutz.mark@fokus.fraunhofer.de, quittek@nw.neclab.eu, stiemerling@nw.neclab.eu, paitken@cisco.com, dromasca@avaya.com, rbonica@juniper.net, n.brownlee@auckland.ac.nz, quittek@neclab.eu From: RFC Errata System Message-Id: <20110801195417.DF39F98C4F3@rfc-editor.org> Date: Mon, 1 Aug 2011 12:54:17 -0700 (PDT) Cc: ipfix@ietf.org, rfc-editor@rfc-editor.org Subject: [IPFIX] [Editorial Errata Reported] RFC5153 (2900) 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, 01 Aug 2011 19:54:11 -0000 The following errata report has been submitted for RFC5153, "IP Flow Information Export (IPFIX) Implementation Guidelines". -------------------------------------- You may review the report below and at: http://www.rfc-editor.org/errata_search.php?rfc=5153&eid=2900 -------------------------------------- Type: Editorial Reported by: Paul Aitken Section: 7.2 Original Text ------------- Consequently, an Exporting Process reporting traffic Flows measured at a device that hosts one or more middleboxes should clearly indicate to Collecting Processes the location of the used Observation Point(s) with respect to the middlebox(es). This can be done by using Options with Observation Point as scope and elements like, for instance, lineCardID or samplerID. Otherwise, processing the measured Flow data could lead to wrong results. Corrected Text -------------- Consequently, an Exporting Process reporting traffic Flows measured at a device that hosts one or more middleboxes should clearly indicate to Collecting Processes the location of the used Observation Point(s) with respect to the middlebox(es). This can be done by using Options with Observation Point as scope and elements like, for instance, lineCardId or selectorId. Otherwise, processing the measured Flow data could lead to wrong results. Notes ----- s/lineCardID/lineCardId/ s/samplerID/selectorId/ Per the definitions in RFC5102, RFC5477 and IANA's IPFIX registry. Instructions: ------------- This errata is currently posted as "Reported". If necessary, please use "Reply All" to discuss whether it should be verified or rejected. When a decision is reached, the verifying party (IESG) can log in to change the status and edit the report, if necessary. -------------------------------------- RFC5153 (draft-ietf-ipfix-implementation-guidelines-08) -------------------------------------- Title : IP Flow Information Export (IPFIX) Implementation Guidelines Publication Date : April 2008 Author(s) : E. Boschi, L. Mark, J. Quittek, M. Stiemerling, P. Aitken Category : INFORMATIONAL Source : IP Flow Information Export Area : Operations and Management Stream : IETF Verifying Party : IESG From wwwrun@rfc-editor.org Mon Aug 1 12:58: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 E45CF11E8161 for ; Mon, 1 Aug 2011 12:58:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.511 X-Spam-Level: X-Spam-Status: No, score=-102.511 tagged_above=-999 required=5 tests=[AWL=0.089, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7aEaRVAnGSEQ for ; Mon, 1 Aug 2011 12:58:04 -0700 (PDT) Received: from rfc-editor.org (rfc-editor.org [IPv6:2001:1890:1112:1::2f]) by ietfa.amsl.com (Postfix) with ESMTP id 73C7711E8077 for ; Mon, 1 Aug 2011 12:58:04 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id 3B4B698C4F3; Mon, 1 Aug 2011 12:58:09 -0700 (PDT) To: elisa.boschi@hitachi-eu.com, lutz.mark@fokus.fraunhofer.de, quittek@nw.neclab.eu, stiemerling@nw.neclab.eu, paitken@cisco.com, dromasca@avaya.com, rbonica@juniper.net, n.brownlee@auckland.ac.nz, quittek@neclab.eu From: RFC Errata System Message-Id: <20110801195811.3B4B698C4F3@rfc-editor.org> Date: Mon, 1 Aug 2011 12:58:09 -0700 (PDT) Cc: ipfix@ietf.org, rfc-editor@rfc-editor.org Subject: [IPFIX] [Editorial Errata Reported] RFC5153 (2901) 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, 01 Aug 2011 19:58:05 -0000 The following errata report has been submitted for RFC5153, "IP Flow Information Export (IPFIX) Implementation Guidelines". -------------------------------------- You may review the report below and at: http://www.rfc-editor.org/errata_search.php?rfc=5153&eid=2901 -------------------------------------- Type: Editorial Reported by: Paul Aitken Section: 3.3 Original Text ------------- Note that it is sometimes necessary to export information about entities that exist outside any Observation Domain, or within multiple Observation Domains (e.g., information about Metering Processes scoped to meteringProcessID). Such information SHOULD be exported in an IPFIX Message with Observation Domain ID 0 (see [RFC5101], Section 3.1). Corrected Text -------------- Note that it is sometimes necessary to export information about entities that exist outside any Observation Domain, or within multiple Observation Domains (e.g., information about Metering Processes scoped to meteringProcessId). Such information SHOULD be exported in an IPFIX Message with Observation Domain ID 0 (see [RFC5101], Section 3.1). Notes ----- s/meteringProcessID/meteringProcessId/ Per RFC5102 and IANA's IPFIX registry, the correct name is "meteringProcessId". Instructions: ------------- This errata is currently posted as "Reported". If necessary, please use "Reply All" to discuss whether it should be verified or rejected. When a decision is reached, the verifying party (IESG) can log in to change the status and edit the report, if necessary. -------------------------------------- RFC5153 (draft-ietf-ipfix-implementation-guidelines-08) -------------------------------------- Title : IP Flow Information Export (IPFIX) Implementation Guidelines Publication Date : April 2008 Author(s) : E. Boschi, L. Mark, J. Quittek, M. Stiemerling, P. Aitken Category : INFORMATIONAL Source : IP Flow Information Export Area : Operations and Management Stream : IETF Verifying Party : IESG From wwwrun@rfc-editor.org Mon Aug 1 13:07: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 CF46011E8161 for ; Mon, 1 Aug 2011 13:07:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.513 X-Spam-Level: X-Spam-Status: No, score=-102.513 tagged_above=-999 required=5 tests=[AWL=0.087, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ivoe94K7hggS for ; Mon, 1 Aug 2011 13:07:59 -0700 (PDT) Received: from rfc-editor.org (rfc-editor.org [IPv6:2001:1890:1112:1::2f]) by ietfa.amsl.com (Postfix) with ESMTP id 5790E11E8157 for ; Mon, 1 Aug 2011 13:07:59 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id 782DE98C508; Mon, 1 Aug 2011 13:08:06 -0700 (PDT) To: bclaise@cisco.com, dromasca@avaya.com, rbonica@juniper.net, n.brownlee@auckland.ac.nz, quittek@neclab.eu From: RFC Errata System Message-Id: <20110801200806.782DE98C508@rfc-editor.org> Date: Mon, 1 Aug 2011 13:08:06 -0700 (PDT) Cc: ipfix@ietf.org, rfc-editor@rfc-editor.org Subject: [IPFIX] [Editorial Errata Reported] RFC5101 (2903) 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, 01 Aug 2011 20:07:59 -0000 The following errata report has been submitted for RFC5101, "Specification of the IP Flow Information Export (IPFIX) Protocol for the Exchange of IP Traffic Flow Information". -------------------------------------- You may review the report below and at: http://www.rfc-editor.org/errata_search.php?rfc=5101&eid=2903 -------------------------------------- Type: Editorial Reported by: Paul Aitken Section: 6.1.6 Original Text ------------- 6.1.6. string and octetarray The data type string represents a finite length string of valid characters of the Unicode character encoding set. The string data type MUST be encoded in UTF-8 format. The string is sent as an array of octets using an Information Element of fixed or variable length. The length of the Information Element specifies the length of the octetarray. Corrected Text -------------- 6.1.6. string and octetArray The data type string represents a finite length string of valid characters of the Unicode character encoding set. The string data type MUST be encoded in UTF-8 format. The string is sent as an array of octets using an Information Element of fixed or variable length. The length of the Information Element specifies the length of the octetArray. Notes ----- s/octetarray/octetArray/ (twice). Also in section 6.2: "Information Elements containing integer, string, float, and octetarray types in the information model ..." Per RFC5102 and IANA's IPFIX registry, the correct name is "octetArray". Instructions: ------------- This errata is currently posted as "Reported". If necessary, please use "Reply All" to discuss whether it should be verified or rejected. When a decision is reached, the verifying party (IESG) can log in to change the status and edit the report, if necessary. -------------------------------------- RFC5101 (draft-ietf-ipfix-protocol-26) -------------------------------------- Title : Specification of the IP Flow Information Export (IPFIX) Protocol for the Exchange of IP Traffic Flow Information Publication Date : January 2008 Author(s) : B. Claise, Ed. Category : PROPOSED STANDARD Source : IP Flow Information Export Area : Operations and Management Stream : IETF Verifying Party : IESG From wwwrun@rfc-editor.org Mon Aug 1 13:19: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 4178A21F8DC6 for ; Mon, 1 Aug 2011 13:19:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.515 X-Spam-Level: X-Spam-Status: No, score=-102.515 tagged_above=-999 required=5 tests=[AWL=0.085, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zSdve3LKbcbm for ; Mon, 1 Aug 2011 13:19:03 -0700 (PDT) Received: from rfc-editor.org (rfc-editor.org [IPv6:2001:1890:1112:1::2f]) by ietfa.amsl.com (Postfix) with ESMTP id ABD0921F8DC4 for ; Mon, 1 Aug 2011 13:19:03 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id F303498C4F3; Mon, 1 Aug 2011 13:19:10 -0700 (PDT) To: bclaise@cisco.com, gowri@cisco.com, paitken@cisco.com, syates@cisco.com, dromasca@avaya.com, rbonica@juniper.net, n.brownlee@auckland.ac.nz, quittek@neclab.eu From: RFC Errata System Message-Id: <20110801201910.F303498C4F3@rfc-editor.org> Date: Mon, 1 Aug 2011 13:19:10 -0700 (PDT) Cc: ipfix@ietf.org, rfc-editor@rfc-editor.org Subject: [IPFIX] [Editorial Errata Reported] RFC6313 (2904) 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, 01 Aug 2011 20:19:04 -0000 The following errata report has been submitted for RFC6313, "Export of Structured Data in IP Flow Information Export (IPFIX)". -------------------------------------- You may review the report below and at: http://www.rfc-editor.org/errata_search.php?rfc=6313&eid=2904 -------------------------------------- Type: Editorial Reported by: Paul Aitken Section: 9.4 Original Text ------------- 5-tuple (Flow Keys), octetCount, packetCount ... ------------------------------------------------------------------ srcIP | dstIP | src | dst | proto | octetCount | packet | | Port | Port | | | Count ------------------------------------------------------------------ 2001:DB8::1 2001:DB8::2 1025 80 6 108000 120 ------------------------------------------------------------------ Corrected Text -------------- 5-tuple (Flow Keys), octetTotalCount, packetTotalCount ... ----------------------------------------------------------------------- srcIP | dstIP | src | dst | proto | octetTotal | packetTotal | | Port | Port | | Count | Count ----------------------------------------------------------------------- 2001:DB8::1 2001:DB8::2 1025 80 6 108000 120 ----------------------------------------------------------------------- Notes ----- s/octetCount/octetTotalCount/ (twice) s/packetCount/packetTotalCount/ (twice) "octetCount" and "packetCount" don't exist. Per RFC5102 and IANA's IPFIX registry, the correct names are octetTotalCount and packetTotalCount. NB correct usage in the figure on page 43 and in Figure 20 indicates that these are not the DeltaCount form. Instructions: ------------- This errata is currently posted as "Reported". If necessary, please use "Reply All" to discuss whether it should be verified or rejected. When a decision is reached, the verifying party (IESG) can log in to change the status and edit the report, if necessary. -------------------------------------- RFC6313 (draft-ietf-ipfix-structured-data-06) -------------------------------------- Title : Export of Structured Data in IP Flow Information Export (IPFIX) Publication Date : July 2011 Author(s) : B. Claise, G. Dhandapani, P. Aitken, S. Yates Category : PROPOSED STANDARD Source : IP Flow Information Export Area : Operations and Management Stream : IETF Verifying Party : IESG From wwwrun@rfc-editor.org Mon Aug 1 13:24:32 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 CBEDB11E8161 for ; Mon, 1 Aug 2011 13:24:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.516 X-Spam-Level: X-Spam-Status: No, score=-102.516 tagged_above=-999 required=5 tests=[AWL=0.084, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Sp-qtAgIaMH9 for ; Mon, 1 Aug 2011 13:24:32 -0700 (PDT) Received: from rfc-editor.org (rfc-editor.org [IPv6:2001:1890:1112:1::2f]) by ietfa.amsl.com (Postfix) with ESMTP id 62AD311E815C for ; Mon, 1 Aug 2011 13:24:32 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id 546F398C4F3; Mon, 1 Aug 2011 13:24:38 -0700 (PDT) To: akoba@orange.plala.or.jp, bclaise@cisco.com, muenz@net.in.tum.de, ishibashi.keisuke@lab.ntt.co.jp, dromasca@avaya.com, rbonica@juniper.net, n.brownlee@auckland.ac.nz, quittek@neclab.eu From: RFC Errata System Message-Id: <20110801202438.546F398C4F3@rfc-editor.org> Date: Mon, 1 Aug 2011 13:24:38 -0700 (PDT) Cc: ipfix@ietf.org, rfc-editor@rfc-editor.org Subject: [IPFIX] [Editorial Errata Reported] RFC6183 (2905) 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, 01 Aug 2011 20:24:32 -0000 The following errata report has been submitted for RFC6183, "IP Flow Information Export (IPFIX) Mediation: Framework". -------------------------------------- You may review the report below and at: http://www.rfc-editor.org/errata_search.php?rfc=6183&eid=2905 -------------------------------------- Type: Editorial Reported by: Paul Aitken Section: 7 Original Text ------------- If information about a set of Original Exporters needs to be reported, it can be useful to export it as Common Properties as specified in [RFC5473]. The commonPropertiesID may then serve as a scope for the set of Original Exporters. Corrected Text -------------- If information about a set of Original Exporters needs to be reported, it can be useful to export it as Common Properties as specified in [RFC5473]. The commonPropertiesId may then serve as a scope for the set of Original Exporters. Notes ----- s/commonPropertiesID/commonPropertiesId/ Per RFC5102 and IANA's IPFIX registry, the correct name is "commonPropertiesId". Instructions: ------------- This errata is currently posted as "Reported". If necessary, please use "Reply All" to discuss whether it should be verified or rejected. When a decision is reached, the verifying party (IESG) can log in to change the status and edit the report, if necessary. -------------------------------------- RFC6183 (draft-ietf-ipfix-mediators-framework-09) -------------------------------------- Title : IP Flow Information Export (IPFIX) Mediation: Framework Publication Date : April 2011 Author(s) : A. Kobayashi, B. Claise, G. Muenz, K. Ishibashi Category : INFORMATIONAL Source : IP Flow Information Export Area : Operations and Management Stream : IETF Verifying Party : IESG From wwwrun@rfc-editor.org Mon Aug 1 13:41:49 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 118611F0C41 for ; Mon, 1 Aug 2011 13:41:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.517 X-Spam-Level: X-Spam-Status: No, score=-102.517 tagged_above=-999 required=5 tests=[AWL=0.083, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id snpOTGrxVn5h for ; Mon, 1 Aug 2011 13:41:48 -0700 (PDT) Received: from rfc-editor.org (rfc-editor.org [IPv6:2001:1890:1112:1::2f]) by ietfa.amsl.com (Postfix) with ESMTP id A833C1F0C40 for ; Mon, 1 Aug 2011 13:41:48 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id D603798C4F3; Mon, 1 Aug 2011 13:41:55 -0700 (PDT) To: brian.trammell@hitachi-eu.com, elisa.boschi@hitachi-eu.com, lutz.mark@ifam.fraunhofer.de, tanja.zseby@fokus.fraunhofer.de, arno@wagner.name, dromasca@avaya.com, rbonica@juniper.net, n.brownlee@auckland.ac.nz, quittek@neclab.eu From: RFC Errata System Message-Id: <20110801204155.D603798C4F3@rfc-editor.org> Date: Mon, 1 Aug 2011 13:41:55 -0700 (PDT) Cc: ipfix@ietf.org, rfc-editor@rfc-editor.org Subject: [IPFIX] [Editorial Errata Reported] RFC5655 (2906) 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, 01 Aug 2011 20:41:49 -0000 The following errata report has been submitted for RFC5655, "Specification of the IP Flow Information Export (IPFIX) File Format". -------------------------------------- You may review the report below and at: http://www.rfc-editor.org/errata_search.php?rfc=5655&eid=2906 -------------------------------------- Type: Editorial Reported by: Paul Aitken Section: B.1.1 Original Text ------------- Observation Domain ID: Similarly, the NetFlow V9 sourceID has become the IPFIX Observation Domain ID. Corrected Text -------------- Observation Domain ID: Similarly, the NetFlow V9 Source ID has become the IPFIX Observation Domain ID. Notes ----- s/sourceID/Source ID/ Per consistent usage in RFC3954, the correct term is "Source ID". Instructions: ------------- This errata is currently posted as "Reported". If necessary, please use "Reply All" to discuss whether it should be verified or rejected. When a decision is reached, the verifying party (IESG) can log in to change the status and edit the report, if necessary. -------------------------------------- RFC5655 (draft-ietf-ipfix-file-05) -------------------------------------- Title : Specification of the IP Flow Information Export (IPFIX) File Format Publication Date : October 2009 Author(s) : B. Trammell, E. Boschi, L. Mark, T. Zseby, A. Wagner Category : PROPOSED STANDARD Source : IP Flow Information Export Area : Operations and Management Stream : IETF Verifying Party : IESG From wwwrun@rfc-editor.org Mon Aug 1 13:50:09 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 F126F1F0C42 for ; Mon, 1 Aug 2011 13:50:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.518 X-Spam-Level: X-Spam-Status: No, score=-102.518 tagged_above=-999 required=5 tests=[AWL=0.082, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vYflECR7GrNH for ; Mon, 1 Aug 2011 13:50:08 -0700 (PDT) Received: from rfc-editor.org (rfc-editor.org [IPv6:2001:1890:1112:1::2f]) by ietfa.amsl.com (Postfix) with ESMTP id 745101F0C39 for ; Mon, 1 Aug 2011 13:50:08 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id CEB6298C1F0; Mon, 1 Aug 2011 13:50:15 -0700 (PDT) To: boschie@tik.ee.ethz.ch, trammell@tik.ee.ethz.ch, dromasca@avaya.com, rbonica@juniper.net, n.brownlee@auckland.ac.nz, quittek@neclab.eu From: RFC Errata System Message-Id: <20110801205015.CEB6298C1F0@rfc-editor.org> Date: Mon, 1 Aug 2011 13:50:15 -0700 (PDT) Cc: ipfix@ietf.org, rfc-editor@rfc-editor.org Subject: [IPFIX] [Editorial Errata Reported] RFC6235 (2907) 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, 01 Aug 2011 20:50:09 -0000 The following errata report has been submitted for RFC6235, "IP Flow Anonymization Support". -------------------------------------- You may review the report below and at: http://www.rfc-editor.org/errata_search.php?rfc=6235&eid=2907 -------------------------------------- Type: Editorial Reported by: Paul Aitken Section: Figure 5 Original Text ------------- 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Set ID = 3 | Length = 26 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Template ID = 257 | Field Count = 4 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Scope Field Count = 2 |0| templateID 145 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Field Length = 2 |0| informationElementId 303 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Field Length = 2 |0| anonymizationFlags 285 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Field Length = 2 |0| anonymizationTechnique 286 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Field Length = 2 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Corrected Text -------------- 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Set ID = 3 | Length = 26 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Template ID = 257 | Field Count = 4 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Scope Field Count = 2 |0| templateId 145 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Field Length = 2 |0| informationElementId 303 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Field Length = 2 |0| anonymizationFlags 285 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Field Length = 2 |0| anonymizationTechnique 286 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Field Length = 2 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Notes ----- s/templateID/templateId/ Per RFC5102 and IANA's IPFIX registry, the correct name is "templateId". Instructions: ------------- This errata is currently posted as "Reported". If necessary, please use "Reply All" to discuss whether it should be verified or rejected. When a decision is reached, the verifying party (IESG) can log in to change the status and edit the report, if necessary. -------------------------------------- RFC6235 (draft-ietf-ipfix-anon-06) -------------------------------------- Title : IP Flow Anonymization Support Publication Date : May 2011 Author(s) : E. Boschi, B. Trammell Category : EXPERIMENTAL Source : IP Flow Information Export Area : Operations and Management Stream : IETF Verifying Party : IESG From wwwrun@rfc-editor.org Mon Aug 1 13:56:52 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 D28751F0C3C for ; Mon, 1 Aug 2011 13:56:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.519 X-Spam-Level: X-Spam-Status: No, score=-102.519 tagged_above=-999 required=5 tests=[AWL=0.081, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4xi0rDQCe4W6 for ; Mon, 1 Aug 2011 13:56:52 -0700 (PDT) Received: from rfc-editor.org (rfc-editor.org [IPv6:2001:1890:1112:1::2f]) by ietfa.amsl.com (Postfix) with ESMTP id 565171F0C39 for ; Mon, 1 Aug 2011 13:56:52 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id 9CF8398C1F0; Mon, 1 Aug 2011 13:56:59 -0700 (PDT) To: elisa.boschi@hitachi-eu.com, lutz.mark@ifam.fraunhofer.de, bclaise@cisco.com, dromasca@avaya.com, rbonica@juniper.net, n.brownlee@auckland.ac.nz, quittek@neclab.eu From: RFC Errata System Message-Id: <20110801205659.9CF8398C1F0@rfc-editor.org> Date: Mon, 1 Aug 2011 13:56:59 -0700 (PDT) Cc: ipfix@ietf.org, rfc-editor@rfc-editor.org Subject: [IPFIX] [Editorial Errata Reported] RFC5473 (2908) 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, 01 Aug 2011 20:56:53 -0000 The following errata report has been submitted for RFC5473, "Reducing Redundancy in IP Flow Information Export (IPFIX) and Packet Sampling (PSAMP) Reports". -------------------------------------- You may review the report below and at: http://www.rfc-editor.org/errata_search.php?rfc=5473&eid=2908 -------------------------------------- Type: Editorial Reported by: Paul Aitken Section: Figure 15 Original Text ------------- 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Set ID = 3 | Length = 40 octets | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Template ID = 256 | Field Count = 7 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Scope Field count = 1 |0| commonPropertiesID = 137 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Scope 1 Field Length = 4 |0| sourceIPv4Address = 8 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Field Length = 4 |0| destinationIPv4Address = 12 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Field Length = 4 |0| classOfServiceIPv4 = 5 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Field Length = 1 |0| protocolIdentifier = 4 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Field Length = 1 |0| transportSourcePort = 7 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Field Length = 2 |0|transportDestinationPort = 11| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Field Length = 2 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Corrected Text -------------- 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Set ID = 3 | Length = 40 octets | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Template ID = 256 | Field Count = 7 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Scope Field count = 1 |0| commonPropertiesID = 137 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Scope 1 Field Length = 4 |0| sourceIPv4Address = 8 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Field Length = 4 |0| destinationIPv4Address = 12 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Field Length = 4 |0| classOfServiceIPv4 = 5 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Field Length = 1 |0| protocolIdentifier = 4 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Field Length = 1 |0| sourceTransportPort = 7 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Field Length = 2 |0|destinationTransportPort = 11| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Field Length = 2 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Notes ----- s/transportSourcePort/sourceTransportPort/ s/transportDestinationPort/destinationTransportPort/ Per RFC5102 and IANA's IPFIX registry, the correct names are "sourceTransportPort" and "destinationTransportPort". Errata 2880 also relates to this figure. Instructions: ------------- This errata is currently posted as "Reported". If necessary, please use "Reply All" to discuss whether it should be verified or rejected. When a decision is reached, the verifying party (IESG) can log in to change the status and edit the report, if necessary. -------------------------------------- RFC5473 (draft-ietf-ipfix-reducing-redundancy-04) -------------------------------------- Title : Reducing Redundancy in IP Flow Information Export (IPFIX) and Packet Sampling (PSAMP) Reports Publication Date : March 2009 Author(s) : E. Boschi, L. Mark, B. Claise Category : INFORMATIONAL Source : IP Flow Information Export Area : Operations and Management Stream : IETF Verifying Party : IESG From wwwrun@rfc-editor.org Tue Aug 2 02:01:21 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 487A521F8ED8 for ; Tue, 2 Aug 2011 02:01:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.527 X-Spam-Level: X-Spam-Status: No, score=-102.527 tagged_above=-999 required=5 tests=[AWL=0.073, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HHq-uPOBnwIs for ; Tue, 2 Aug 2011 02:01:20 -0700 (PDT) Received: from rfc-editor.org (rfc-editor.org [IPv6:2001:1890:1112:1::2f]) by ietfa.amsl.com (Postfix) with ESMTP id B15B321F8E7D for ; Tue, 2 Aug 2011 02:01:20 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id 3AFAC98C4E8; Tue, 2 Aug 2011 02:01:22 -0700 (PDT) To: bclaise@cisco.com, gowri@cisco.com, paitken@cisco.com, syates@cisco.com, dromasca@avaya.com, rbonica@juniper.net, n.brownlee@auckland.ac.nz, quittek@neclab.eu From: RFC Errata System Message-Id: <20110802090126.3AFAC98C4E8@rfc-editor.org> Date: Tue, 2 Aug 2011 02:01:22 -0700 (PDT) Cc: ipfix@ietf.org, rfc-editor@rfc-editor.org Subject: [IPFIX] [Editorial Errata Reported] RFC6313 (2909) 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, 02 Aug 2011 09:01:21 -0000 The following errata report has been submitted for RFC6313, "Export of Structured Data in IP Flow Information Export (IPFIX)". -------------------------------------- You may review the report below and at: http://www.rfc-editor.org/errata_search.php?rfc=6313&eid=2909 -------------------------------------- Type: Editorial Reported by: Paul Aitken Section: Figure 15 Original Text ------------- 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Set ID = 2 | Length = 16 octets | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Template ID = 257 | Field Count = 2 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0| observationTimeMicroSec=324 | Field Length = 8 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0| digestHashValue = 326 | Field Length = 4 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Corrected Text -------------- 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Set ID = 2 | Length = 16 octets | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Template ID = 257 | Field Count = 2 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0| observationTimeMicrosec=324 | Field Length = 8 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0| digestHashValue = 326 | Field Length = 4 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Notes ----- s/observationTimeMicroSec/observationTimeMicrosec/ Per RFC5477 and IANA's IPFIX registry, the correct name is "observationTimeMicroseconds". Instructions: ------------- This errata is currently posted as "Reported". If necessary, please use "Reply All" to discuss whether it should be verified or rejected. When a decision is reached, the verifying party (IESG) can log in to change the status and edit the report, if necessary. -------------------------------------- RFC6313 (draft-ietf-ipfix-structured-data-06) -------------------------------------- Title : Export of Structured Data in IP Flow Information Export (IPFIX) Publication Date : July 2011 Author(s) : B. Claise, G. Dhandapani, P. Aitken, S. Yates Category : PROPOSED STANDARD Source : IP Flow Information Export Area : Operations and Management Stream : IETF Verifying Party : IESG From wwwrun@rfc-editor.org Tue Aug 2 11:07:01 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 647B611E8098 for ; Tue, 2 Aug 2011 11:07:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Pyq28O56XGoe for ; Tue, 2 Aug 2011 11:07:01 -0700 (PDT) Received: from rfc-editor.org (rfc-editor.org [IPv6:2001:1890:1112:1::2f]) by ietfa.amsl.com (Postfix) with ESMTP id 0776F11E808C for ; Tue, 2 Aug 2011 11:07:01 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id B2B6498C517; Tue, 2 Aug 2011 11:07:10 -0700 (PDT) To: elisa.boschi@hitachi-eu.com, lutz.mark@ifam.fraunhofer.de, bclaise@cisco.com, dromasca@avaya.com, rbonica@juniper.net, n.brownlee@auckland.ac.nz, quittek@neclab.eu From: RFC Errata System Message-Id: <20110802180710.B2B6498C517@rfc-editor.org> Date: Tue, 2 Aug 2011 11:07:10 -0700 (PDT) Cc: rfc-editor@rfc-editor.org, ipfix@ietf.org Subject: [IPFIX] [Editorial Errata Reported] RFC5473 (2911) 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, 02 Aug 2011 18:07:01 -0000 The following errata report has been submitted for RFC5473, "Reducing Redundancy in IP Flow Information Export (IPFIX) and Packet Sampling (PSAMP) Reports". -------------------------------------- You may review the report below and at: http://www.rfc-editor.org/errata_search.php?rfc=5473&eid=2911 -------------------------------------- Type: Editorial Reported by: Gerhard Muenz Section: 10 Original Text ------------- The authors would like to thank Guido Pohl for initiating this work and for his contribution to early versions of this document. Thanks also to Andrew Johnson, Gehrard Muenz, Brian Trammell, and Paul Aitken for their comments and feedback. Corrected Text -------------- The authors would like to thank Guido Pohl for initiating this work and for his contribution to early versions of this document. Thanks also to Andrew Johnson, Gerhard Muenz, Brian Trammell, and Paul Aitken for their comments and feedback. Notes ----- s/Gehrard/Gerhard/ Typo Instructions: ------------- This errata is currently posted as "Reported". If necessary, please use "Reply All" to discuss whether it should be verified or rejected. When a decision is reached, the verifying party (IESG) can log in to change the status and edit the report, if necessary. -------------------------------------- RFC5473 (draft-ietf-ipfix-reducing-redundancy-04) -------------------------------------- Title : Reducing Redundancy in IP Flow Information Export (IPFIX) and Packet Sampling (PSAMP) Reports Publication Date : March 2009 Author(s) : E. Boschi, L. Mark, B. Claise Category : INFORMATIONAL Source : IP Flow Information Export Area : Operations and Management Stream : IETF Verifying Party : IESG From wwwrun@rfc-editor.org Mon Aug 8 14:07: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 46F5411E80C0 for ; Mon, 8 Aug 2011 14:07:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.56 X-Spam-Level: X-Spam-Status: No, score=-102.56 tagged_above=-999 required=5 tests=[AWL=0.040, BAYES_00=-2.599, NO_RELAYS=-0.001, 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 GJ-3HsfpsAD2 for ; Mon, 8 Aug 2011 14:07:52 -0700 (PDT) Received: from rfc-editor.org (rfc-editor.org [IPv6:2001:1890:123a::1:2f]) by ietfa.amsl.com (Postfix) with ESMTP id 9166F11E8089 for ; Mon, 8 Aug 2011 14:07:52 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id B7ABE98C51C; Mon, 8 Aug 2011 14:08:16 -0700 (PDT) To: bclaise@cisco.com, gowri@cisco.com, paitken@cisco.com, syates@cisco.com, dromasca@avaya.com, rbonica@juniper.net, n.brownlee@auckland.ac.nz, quittek@neclab.eu From: RFC Errata System Message-Id: <20110808210816.B7ABE98C51C@rfc-editor.org> Date: Mon, 8 Aug 2011 14:08:16 -0700 (PDT) Cc: ipfix@ietf.org, rfc-editor@rfc-editor.org Subject: [IPFIX] [Editorial Errata Reported] RFC6313 (2925) 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, 08 Aug 2011 21:07:53 -0000 The following errata report has been submitted for RFC6313, "Export of Structured Data in IP Flow Information Export (IPFIX)". -------------------------------------- You may review the report below and at: http://www.rfc-editor.org/errata_search.php?rfc=6313&eid=2925 -------------------------------------- Type: Editorial Reported by: Paul Aitken Section: Appendix A Original Text ------------- Represents a list of zero or more instances of any Information Element, primarily used for single-valued data types. Examples include a list of port numbers, a list of interface indexes, and a list of AS in a BGP AS-PATH. ... Represents a list of zero or more instances of a structured data type, where the data type of each list element is the same and corresponds with a single Template Record. Examples include a structured data type composed of multiple pairs of ("MPLS label stack entry position", "MPLS label stack value"), a structured data type composed of performance metrics, and a structured data type composed of multiple pairs of IP address. ... Represents a list of zero or more instances of structured data types, where the data type of each list element can be different and corresponds with different Template definitions. An example is a structured data type composed of multiple access-list entries, where entries can be composed of different criteria types. Corrected Text -------------- The type "basicList" represents a list of zero or more instances of any Information Element, primarily used for single-valued data types. Examples include a list of port numbers, a list of interface indexes, and a list of AS in a BGP AS-PATH. ... The type "subTemplateList" represents a list of zero or more instances of a structured data type, where the data type of each list element is the same and corresponds with a single Template Record. Examples include a structured data type composed of multiple pairs of ("MPLS label stack entry position", "MPLS label stack value"), a structured data type composed of performance metrics, and a structured data type composed of multiple pairs of IP address. ... The type "subTemplateMultiList" represents a list of zero or more instances of structured data types, where the data type of each list element can be different and corresponds with different Template definitions. An example is a structured data type composed of multiple access-list entries, where entries can be composed of different criteria types. Notes ----- Addition of 'The type "basicList"', 'The type "subTemplateList"' and 'The type "subTemplateMultiList"', for consistency with the existing descriptions which all begin 'The type xxx ...'. Note that this refers to text on page 63, for modifications to the IPFIX schema. The schema has been updated with the corrected text above. Instructions: ------------- This errata is currently posted as "Reported". If necessary, please use "Reply All" to discuss whether it should be verified or rejected. When a decision is reached, the verifying party (IESG) can log in to change the status and edit the report, if necessary. -------------------------------------- RFC6313 (draft-ietf-ipfix-structured-data-06) -------------------------------------- Title : Export of Structured Data in IP Flow Information Export (IPFIX) Publication Date : July 2011 Author(s) : B. Claise, G. Dhandapani, P. Aitken, S. Yates Category : PROPOSED STANDARD Source : IP Flow Information Export Area : Operations and Management Stream : IETF Verifying Party : IESG From wwwrun@rfc-editor.org Mon Aug 8 14:53:13 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 5E4EA21F8C16 for ; Mon, 8 Aug 2011 14:53:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.561 X-Spam-Level: X-Spam-Status: No, score=-102.561 tagged_above=-999 required=5 tests=[AWL=0.039, BAYES_00=-2.599, NO_RELAYS=-0.001, 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 6CIUtfpsYHw3 for ; Mon, 8 Aug 2011 14:53:12 -0700 (PDT) Received: from rfc-editor.org (rfc-editor.org [IPv6:2001:1890:123a::1:2f]) by ietfa.amsl.com (Postfix) with ESMTP id D3C6D21F8C15 for ; Mon, 8 Aug 2011 14:53:12 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id F203098C51C; Mon, 8 Aug 2011 14:53:39 -0700 (PDT) To: bclaise@cisco.com, gowri@cisco.com, paitken@cisco.com, syates@cisco.com, dromasca@avaya.com, rbonica@juniper.net, n.brownlee@auckland.ac.nz, quittek@neclab.eu From: RFC Errata System Message-Id: <20110808215339.F203098C51C@rfc-editor.org> Date: Mon, 8 Aug 2011 14:53:39 -0700 (PDT) Cc: ipfix@ietf.org, rfc-editor@rfc-editor.org Subject: [IPFIX] [Editorial Errata Reported] RFC6313 (2926) 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, 08 Aug 2011 21:53:13 -0000 The following errata report has been submitted for RFC6313, "Export of Structured Data in IP Flow Information Export (IPFIX)". -------------------------------------- You may review the report below and at: http://www.rfc-editor.org/errata_search.php?rfc=6313&eid=2926 -------------------------------------- Type: Editorial Reported by: Paul Aitken Section: Appendix A Original Text ------------- Represents an arbitrary-length sequence of structured data elements, either composed of regular Information Elements or composed of data conforming to a Template Record. Corrected Text -------------- Represents an arbitrary-length sequence of zero or more structured data Information Elements, either composed of regular Information Elements or composed of data conforming to a Template Record. Notes ----- Insertion of missing "zero or more" per the definition in section 4.2.1: 4.2. New Data Type Semantic 4.2.1. List A list represents an arbitrary-length sequence of zero or more structured data Information Elements, either composed of regular Information Elements or composed of data conforming to a Template Record. Note that this refers to the dataTypeSemantics on page 64, for modifications to the IPFIX schema. The schema has been updated with the corrected text above. Instructions: ------------- This errata is currently posted as "Reported". If necessary, please use "Reply All" to discuss whether it should be verified or rejected. When a decision is reached, the verifying party (IESG) can log in to change the status and edit the report, if necessary. -------------------------------------- RFC6313 (draft-ietf-ipfix-structured-data-06) -------------------------------------- Title : Export of Structured Data in IP Flow Information Export (IPFIX) Publication Date : July 2011 Author(s) : B. Claise, G. Dhandapani, P. Aitken, S. Yates Category : PROPOSED STANDARD Source : IP Flow Information Export Area : Operations and Management Stream : IETF Verifying Party : IESG From paitken@cisco.com Tue Aug 9 04:40:10 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 54A4721F8AD3 for ; Tue, 9 Aug 2011 04:40:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.246 X-Spam-Level: X-Spam-Status: No, score=-10.246 tagged_above=-999 required=5 tests=[AWL=-0.247, BAYES_00=-2.599, J_CHICKENPOX_37=0.6, 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 3HN6Pk7GiHLm for ; Tue, 9 Aug 2011 04:40:09 -0700 (PDT) Received: from ams-iport-2.cisco.com (ams-iport-2.cisco.com [144.254.224.141]) by ietfa.amsl.com (Postfix) with ESMTP id 0140721F8ADE for ; Tue, 9 Aug 2011 04:40:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=paitken@cisco.com; l=4696; q=dns/txt; s=iport; t=1312890037; x=1314099637; h=message-id:date:from:mime-version:to:subject: content-transfer-encoding; bh=roSuGNKbYzR/FJhMKva+3AQ3oI2rUepJh8yN5ZsX/D4=; b=YhzjWLrjXlKEQ3eZG1CmgiCCLvp2QGmdgc2krgZXAoXbuC3k2Fv7ZE9Y fZfiCi6DDR3PJQowDRbpiNNcqNObU6XgV3fsCYgeKSro2O7pnY5js4/l3 1ZWPRovDNDBQ/H5UdxOQ93QtZv2ZcgJ3NtQQBSvRzF6J8o0J+AuOhh8VI Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EAEMcQU6Q/khR/2dsb2JhbAAoGqc4d4FZASU9Az0WGAMCAQIBSw0IAQEFGYdPI5xIgSMBnn6GRgSTBYUJi2No X-IronPort-AV: E=Sophos;i="4.67,342,1309737600"; d="scan'208";a="48134585" Received: from ams-core-1.cisco.com ([144.254.72.81]) by ams-iport-2.cisco.com with ESMTP; 09 Aug 2011 11:40:34 +0000 Received: from [10.61.92.136] (ams3-vpn-dhcp7305.cisco.com [10.61.92.136]) by ams-core-1.cisco.com (8.14.3/8.14.3) with ESMTP id p79BeXE1005260 for ; Tue, 9 Aug 2011 11:40:33 GMT Message-ID: <4E411CB7.6010309@cisco.com> Date: Tue, 09 Aug 2011 12:40:39 +0100 From: Paul Aitken User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.18) Gecko/20110617 Lightning/1.0b2 Thunderbird/3.1.11 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] RFC 5102 errata 1737, 1738 and 1739 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, 09 Aug 2011 11:40:10 -0000 Dear IPFIXers, I've been reviewing RFC5102 errata 1737, 1738 and 1739 which tried to correct the bit-numbering of the "ipv4Options", "ipv6ExtensionHeaders" and "tcpOptions" information elements. See: http://www.rfc-editor.org/errata_search.php?eid=1737 http://www.rfc-editor.org/errata_search.php?eid=1738 http://www.rfc-editor.org/errata_search.php?eid=1739 While these errata corrected the bit ordering within the bytes, they left the wrong byte ordering - which leaves things worse than before. I hope that anyone who has implemented ipv4Options, ipv6ExtensionHeaders, or tcpOptions, has followed the text rather than the figures? eg, consider errata 1737 for ipv4Options. The options are defined in RFC 791 and assigned by IANA: http://www.iana.org/assignments/ip-parameters Each option has a number, from 0 to 30. The intention was for the ipv4Options bits to follow that numbering, with bit = 2^number. Unfortunately RFC bit numbering is from left to right, so we originally followed that and drew the figure like so: 0 1 2 3 4 5 6 7 +------+------+------+------+------+------+------+------+ | EOOL | NOP | SEC | LSR | TS |E-SEC |CIPSO | RR | ... +------+------+------+------+------+------+------+------+ That's exactly the reverse of what we had intended, which was like this: +------+------+------+------+------+------+------+------+ ... | RR |CIPSO |E-SEC | TS | LSR | SEC | NOP | EOOL | +------+------+------+------+------+------+------+------+ Errata 1737 fixed the bit ordering within the bytes, but left the wrong byte ordering. And that's what's currently shown in IANA's IPFIX registry, http://www.iana.org/assignments/ipfix/ipfix.xml : 0 1 2 3 4 5 6 7 +------+------+------+------+------+------+------+------+ | RR |CIPSO |E-SEC | TS | LSR | SEC | NOP | EOOL | ... +------+------+------+------+------+------+------+------+ 8 9 10 11 12 13 14 15 +------+------+------+------+------+------+------+------+ ... |ENCODE| VISA | FINN | MTUR | MTUP | ZSU | SSR | SID | ... +------+------+------+------+------+------+------+------+ 16 17 18 19 20 21 22 23 +------+------+------+------+------+------+------+------+ ... | DPS |NSAPA | SDB |RTRALT|ADDEXT| TR | EIP |IMITD | ... +------+------+------+------+------+------+------+------+ 24 25 26 27 28 29 30 31 +------+------+------+------+------+------+------+------+ ... | | EXP | to be assigned by IANA | QS | UMP | +------+------+------+------+------+------+------+------+ If you think of this as a 32-bit word, EOOL is at position 2^24, which you couldn't possibly infer from the associated text. The correct ordering is: 0 1 2 3 4 5 6 7 +------+------+------+------+------+------+------+------+ | | EXP | to be assigned by IANA | QS | UMP | ... +------+------+------+------+------+------+------+------+ 8 9 10 11 12 13 14 15 +------+------+------+------+------+------+------+------+ ... | DPS |NSAPA | SDB |RTRALT|ADDEXT| TR | EIP |IMITD | ... +------+------+------+------+------+------+------+------+ 16 17 18 19 20 21 22 23 +------+------+------+------+------+------+------+------+ ... |ENCODE| VISA | FINN | MTUR | MTUP | ZSU | SSR | SID | ... +------+------+------+------+------+------+------+------+ 24 25 26 27 28 29 30 31 +------+------+------+------+------+------+------+------+ ... | RR |CIPSO |E-SEC | TS | LSR | SEC | NOP | EOOL | +------+------+------+------+------+------+------+------+ If you ignore the bits-on-the-wire numbering and imagine this as a 32-bit word in memory, each option is at (2^value) as you'd expect. Unfortunately the RFC numbering is exactly the reverse of the values in the "ip-parameters" registry - which is what led to all this confusion. However there's no reason or need for these to agree. The exact same issues exist with errata 1738 and 1739: the bit ordering was swapped, but not the byte ordering. I'm opening new errata to correct all this properly. P. From dromasca@avaya.com Thu Aug 11 03:24:31 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 60A4E21F84DB for ; Thu, 11 Aug 2011 03:24:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.13 X-Spam-Level: X-Spam-Status: No, score=-103.13 tagged_above=-999 required=5 tests=[AWL=-0.131, BAYES_00=-2.599, J_CHICKENPOX_37=0.6, RCVD_IN_DNSWL_LOW=-1, 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 igY8mU-uB0Ea for ; Thu, 11 Aug 2011 03:24:30 -0700 (PDT) Received: from co300216-co-outbound.net.avaya.com (co300216-co-outbound.net.avaya.com [198.152.13.100]) by ietfa.amsl.com (Postfix) with ESMTP id D8BC021F8506 for ; Thu, 11 Aug 2011 03:24:29 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AtAAALWsQ06HCzI1/2dsb2JhbAAnGpd9j0l3gUABAQEBAwEBAQ8eCjQHEAQCAQgNAQMEAQELBgwLAQYBJh8JCAEBBAESCAEZh1EjoHQCnB+FaF8EmDeLSGc X-IronPort-AV: E=Sophos;i="4.67,355,1309752000"; d="scan'208";a="296985727" Received: from unknown (HELO p-us1-erheast.us1.avaya.com) ([135.11.50.53]) by co300216-co-outbound.net.avaya.com with ESMTP; 11 Aug 2011 06:25:01 -0400 Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.10]) by p-us1-erheast-out.us1.avaya.com with ESMTP; 11 Aug 2011 06:16:59 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Thu, 11 Aug 2011 12:24:59 +0200 Message-ID: In-Reply-To: <4E411CB7.6010309@cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [IPFIX] RFC 5102 errata 1737, 1738 and 1739 Thread-Index: AcxWiSsBb6u3hawcSD2k6nE1pntt1wBhyCCA References: <4E411CB7.6010309@cisco.com> From: "Romascanu, Dan (Dan)" To: "Paul Aitken" , "IETF IPFIX Working Group" Subject: Re: [IPFIX] RFC 5102 errata 1737, 1738 and 1739 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: Thu, 11 Aug 2011 10:24:31 -0000 Hi, Would it be possible that you propose the errata (as a plural) on the WG list, and the WG discussed them before?=20 The submission many errata (the last batch included more than 20) in one day is quite a load on the AD who needs to verify and approve them. I prefer the exact text to be submitted and discussed on the ipfix WG list BEFORE submitting. Of course, this is just a suggestion.=20 Thanks and Regards, Dan=20 > -----Original Message----- > From: ipfix-bounces@ietf.org [mailto:ipfix-bounces@ietf.org] On Behalf > Of Paul Aitken > Sent: Tuesday, August 09, 2011 2:41 PM > To: IETF IPFIX Working Group > Subject: [IPFIX] RFC 5102 errata 1737, 1738 and 1739 >=20 > Dear IPFIXers, >=20 > I've been reviewing RFC5102 errata 1737, 1738 and 1739 which tried to > correct the bit-numbering of the "ipv4Options", "ipv6ExtensionHeaders" > and "tcpOptions" information elements. >=20 > See: > http://www.rfc-editor.org/errata_search.php?eid=3D1737 > http://www.rfc-editor.org/errata_search.php?eid=3D1738 > http://www.rfc-editor.org/errata_search.php?eid=3D1739 >=20 >=20 > While these errata corrected the bit ordering within the bytes, they > left the wrong byte ordering - which leaves things worse than before. >=20 > I hope that anyone who has implemented ipv4Options, > ipv6ExtensionHeaders, or tcpOptions, has followed the text rather than > the figures? >=20 >=20 > eg, consider errata 1737 for ipv4Options. >=20 > The options are defined in RFC 791 and assigned by IANA: > http://www.iana.org/assignments/ip-parameters >=20 > Each option has a number, from 0 to 30. The intention was for the > ipv4Options bits to follow that numbering, with bit =3D 2^number. >=20 > Unfortunately RFC bit numbering is from left to right, so we originally > followed that and drew the figure like so: >=20 > 0 1 2 3 4 5 6 7 > +------+------+------+------+------+------+------+------+ > | EOOL | NOP | SEC | LSR | TS |E-SEC |CIPSO | RR | ... > +------+------+------+------+------+------+------+------+ >=20 >=20 > That's exactly the reverse of what we had intended, which was like > this: >=20 > +------+------+------+------+------+------+------+------+ > ... | RR |CIPSO |E-SEC | TS | LSR | SEC | NOP | EOOL | > +------+------+------+------+------+------+------+------+ >=20 >=20 > Errata 1737 fixed the bit ordering within the bytes, but left the wrong > byte ordering. > And that's what's currently shown in IANA's IPFIX registry, > http://www.iana.org/assignments/ipfix/ipfix.xml : >=20 > 0 1 2 3 4 5 6 7 > +------+------+------+------+------+------+------+------+ > | RR |CIPSO |E-SEC | TS | LSR | SEC | NOP | EOOL | ... > +------+------+------+------+------+------+------+------+ >=20 > 8 9 10 11 12 13 14 15 > +------+------+------+------+------+------+------+------+ > ... |ENCODE| VISA | FINN | MTUR | MTUP | ZSU | SSR | SID | ... > +------+------+------+------+------+------+------+------+ >=20 > 16 17 18 19 20 21 22 23 > +------+------+------+------+------+------+------+------+ > ... | DPS |NSAPA | SDB |RTRALT|ADDEXT| TR | EIP |IMITD | ... > +------+------+------+------+------+------+------+------+ >=20 > 24 25 26 27 28 29 30 31 > +------+------+------+------+------+------+------+------+ > ... | | EXP | to be assigned by IANA | QS | UMP | > +------+------+------+------+------+------+------+------+ >=20 >=20 > If you think of this as a 32-bit word, EOOL is at position 2^24, which > you couldn't possibly infer from the associated text. >=20 > The correct ordering is: >=20 > 0 1 2 3 4 5 6 7 > +------+------+------+------+------+------+------+------+ > | | EXP | to be assigned by IANA | QS | UMP | ... > +------+------+------+------+------+------+------+------+ >=20 > 8 9 10 11 12 13 14 15 > +------+------+------+------+------+------+------+------+ > ... | DPS |NSAPA | SDB |RTRALT|ADDEXT| TR | EIP |IMITD | ... > +------+------+------+------+------+------+------+------+ >=20 > 16 17 18 19 20 21 22 23 > +------+------+------+------+------+------+------+------+ > ... |ENCODE| VISA | FINN | MTUR | MTUP | ZSU | SSR | SID | ... > +------+------+------+------+------+------+------+------+ >=20 > 24 25 26 27 28 29 30 31 > +------+------+------+------+------+------+------+------+ > ... | RR |CIPSO |E-SEC | TS | LSR | SEC | NOP | EOOL | > +------+------+------+------+------+------+------+------+ >=20 >=20 > If you ignore the bits-on-the-wire numbering and imagine this as a > 32-bit word in memory, each option is at (2^value) as you'd expect. >=20 > Unfortunately the RFC numbering is exactly the reverse of the values in > the "ip-parameters" registry - which is what led to all this confusion. > However there's no reason or need for these to agree. >=20 > The exact same issues exist with errata 1738 and 1739: the bit ordering > was swapped, but not the byte ordering. >=20 > I'm opening new errata to correct all this properly. >=20 > P. >=20 > _______________________________________________ > IPFIX mailing list > IPFIX@ietf.org > https://www.ietf.org/mailman/listinfo/ipfix From paitken@cisco.com Thu Aug 11 05:07: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 8873521F85CE for ; Thu, 11 Aug 2011 05:07:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.511 X-Spam-Level: X-Spam-Status: No, score=-10.511 tagged_above=-999 required=5 tests=[AWL=0.088, 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 rySf-DWtKCye for ; Thu, 11 Aug 2011 05:07:07 -0700 (PDT) Received: from ams-iport-2.cisco.com (ams-iport-2.cisco.com [144.254.224.141]) by ietfa.amsl.com (Postfix) with ESMTP id 6B63E21F85CA for ; Thu, 11 Aug 2011 05:07:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=paitken@cisco.com; l=754; q=dns/txt; s=iport; t=1313064462; x=1314274062; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=7tuCX2ut3qGGGheluYp2mXG5uEoSilALxYpV6BlHjgM=; b=RX0CcMwr1Q6Vop3tPxE6JfVdQMybGYNTLnccjollCl4aZXSm5WbPRcm5 rOTVlaRTVVDoYWxe8hzhPyPjkA1xHUXJ7iOqaiUMCI1984cbuFI6PemTI oam6qOdogSF1D+0cNwAddfWYNWGlzndcuZmNONEu6Izv4yOKO53Nr2bEP g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EAA3FQ06Q/khN/2dsb2JhbABBp0Z3gUABAQEBAgESASVAAQULCyEWDwkDAgECAUUGDQEHAQEeh02dfAGfAoZHBJMOhQuLZQ X-IronPort-AV: E=Sophos;i="4.67,355,1309737600"; d="scan'208";a="49899119" Received: from ams-core-4.cisco.com ([144.254.72.77]) by ams-iport-2.cisco.com with ESMTP; 11 Aug 2011 12:07:40 +0000 Received: from [10.55.89.149] (dhcp-10-55-89-149.cisco.com [10.55.89.149]) by ams-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id p7BC7dXQ029295; Thu, 11 Aug 2011 12:07:39 GMT Message-ID: <4E43C60B.7020606@cisco.com> Date: Thu, 11 Aug 2011 13:07:39 +0100 From: Paul Aitken User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.18) Gecko/20110617 Lightning/1.0b2 Thunderbird/3.1.11 MIME-Version: 1.0 To: "Romascanu, Dan (Dan)" References: <4E411CB7.6010309@cisco.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: IETF IPFIX Working Group Subject: Re: [IPFIX] RFC 5102 errata 1737, 1738 and 1739 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: Thu, 11 Aug 2011 12:07:08 -0000 Dan, > Would it be possible that you propose the errata (as a plural) on the WG > list, and the WG discussed them before? Sure, will do. > The submission many errata (the last batch included more than 20) in one > day is quite a load on the AD who needs to verify and approve them. I > prefer the exact text to be submitted and discussed on the ipfix WG list > BEFORE submitting. Of course, this is just a suggestion. I didn't plan to submit the batch; I just started reviewing the documents (especially considering the proposed update to the IPFIX base standards) and one thing led to another. Most of the points were minor editorial issues and inconsistencies. However, errata 1737, 1738 and 1739 are technical issues. P. From paitken@cisco.com Tue Aug 16 03:56:02 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 41E2921F8AA8 for ; Tue, 16 Aug 2011 03:56:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.522 X-Spam-Level: X-Spam-Status: No, score=-10.522 tagged_above=-999 required=5 tests=[AWL=0.077, 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 1VfzzL1FNJJt for ; Tue, 16 Aug 2011 03:56:01 -0700 (PDT) Received: from ams-iport-2.cisco.com (ams-iport-2.cisco.com [144.254.224.141]) by ietfa.amsl.com (Postfix) with ESMTP id C147521F8ABE for ; Tue, 16 Aug 2011 03:56:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=paitken@cisco.com; l=5938; q=dns/txt; s=iport; t=1313492209; x=1314701809; h=message-id:date:from:mime-version:to:cc:subject: content-transfer-encoding; bh=V4IC1WTRKEmLkwwTtRGZyB3JkBaMoa4suI2E8MSw5uY=; b=llXz7fq2NrgBXsqTYGYfRe/Jdjxb9zxKCthCZAKVFHyhFwu/t+6VzBv5 Iza5DQKUllv37ZMMqKp3irBheyCeXJu7bKv3ISF3rJbMqKIMG1TDd/ip6 0Oxp8+yMr1WiOMmvym2h6qcS3SRXvZ9D4AR0Rd6n8okllFIg5G89CNQBm o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EAFpMSk6Q/khN/2dsb2JhbAAnGqgvd4FZASUzCgQ8NAIwHA0BBwEBBRmHUiObBQGfMIZHBJMShQyLamg X-IronPort-AV: E=Sophos;i="4.67,379,1309737600"; d="scan'208";a="50692084" Received: from ams-core-4.cisco.com ([144.254.72.77]) by ams-iport-2.cisco.com with ESMTP; 16 Aug 2011 10:56:37 +0000 Received: from [10.61.106.197] (dhcp-10-61-106-197.cisco.com [10.61.106.197]) by ams-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id p7GAubAv005611; Tue, 16 Aug 2011 10:56:37 GMT Message-ID: <4E4A4CE5.20506@cisco.com> Date: Tue, 16 Aug 2011 11:56:37 +0100 From: Paul Aitken User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.18) Gecko/20110617 Lightning/1.0b2 Thunderbird/3.1.11 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] Errata 1737 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, 16 Aug 2011 10:56:02 -0000 Dear IPFIX experts, RFC 5102, section "5.8.5. ipv4Options", provides the following table: Type Option Bit Value Name Reference ---+-----+-------+------------------------------------ 0 0 EOOL End of Options List, RFC 791 1 1 NOP No Operation, RFC 791 2 130 SEC Security, RFC 1108 3 131 LSR Loose Source Route, RFC 791 4 68 TS Time Stamp, RFC 791 5 133 E-SEC Extended Security, RFC 1108 6 134 CIPSO Commercial Security 7 7 RR Record Route, RFC 791 8 136 SID Stream ID, RFC 791 9 137 SSR Strict Source Route, RFC 791 10 10 ZSU Experimental Measurement 11 11 MTUP (obsoleted) MTU Probe, RFC 1191 12 12 MTUR (obsoleted) MTU Reply, RFC 1191 13 205 FINN Experimental Flow Control 14 142 VISA Experimental Access Control 15 15 ENCODE 16 144 IMITD IMI Traffic Descriptor 17 145 EIP Extended Internet Protocol, RFC 1385 18 82 TR Traceroute, RFC 3193 19 147 ADDEXT Address Extension 20 148 RTRALT Router Alert, RFC 2113 21 149 SDB Selective Directed Broadcast 22 150 NSAPA NSAP Address 23 151 DPS Dynamic Packet State 24 152 UMP Upstream Multicast Pkt. 25 25 QS Quick-Start 30 30 EXP RFC3692-style Experiment 30 94 EXP RFC3692-style Experiment 30 158 EXP RFC3692-style Experiment 30 222 EXP RFC3692-style Experiment ... ... ... Further options numbers may be assigned by IANA This is taken from the list of IPv4 option numbers assigned by IANA at http://www.iana.org/assignments/ip-parameters. The intention was to encode each option in the corresponding bit per the table, so EOOL would be 2^0, NOP would be 2^1, SEC would be 2^2 etc. So from a programming point of view, the bits should be: 7 6 5 4 3 2 1 0 +------+------+------+------+------+------+------+------+ ... | RR |CIPSO |E-SEC | TS | LSR | SEC | NOP | EOOL | +------+------+------+------+------+------+------+------+ Unfortunately RFCs number the bits in the opposite order, so what we drew in RFC 5102 was: 0 1 2 3 4 5 6 7 +------+------+------+------+------+------+------+------+ | EOOL | NOP | SEC | LSR | TS |E-SEC |CIPSO | RR | ... +------+------+------+------+------+------+------+------+ - which puts EOOL at 2^32, NOP at 2^31, etc. This is exactly the opposite of what was intended. The text is right, but the figure is backwards. Per the errata, "The diagram is back to front." Also note that if you're using reduced size encoding, EOOL could now be at any 8-bit boundary. I tried to correct this in Errata 1737: http://www.rfc-editor.org/errata_search.php?eid=1737 Unfortunately I only flipped the bits around inside the bytes without flipping the bytes around too. So if we list the bits from the errata in one long row, it's clear that everything is in the wrong place: 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 +------+------+------+------+------+------+------+------+------+------+------+------+------+------+------+------+------+------+------+------+------+------+------+------+------+------+------+------+------+------+------+------+ | RR |CIPSO |E-SEC | TS | LSR | SEC | NOP | EOOL |ENCODE| VISA | FINN | MTUR | MTUP | ZSU | SSR | SID | DPS |NSAPA | SDB |RTRALT|ADDEXT| TR | EIP |IMITD | | EXP | to be assigned by IANA | QS | UMP | +------+------+------+------+------+------+------+------+------+------+------+------+------+------+------+------+------+------+------+------+------+------+------+------+------+------+------+------+------+------+------+------+ bit: 7 6 5 4 3 2 1 0 15 14 13 12 11 10 9 8 23 22 21 20 19 18 17 16 31 30 25 24 What the errata should say is: 0 1 2 3 4 5 6 7 +------+------+------+------+------+------+------+------+ | | EXP | to be assigned by IANA | QS | UMP | ... +------+------+------+------+------+------+------+------+ 8 9 10 11 12 13 14 15 +------+------+------+------+------+------+------+------+ ... | DPS |NSAPA | SDB |RTRALT|ADDEXT| TR | EIP |IMITD | ... +------+------+------+------+------+------+------+------+ 16 17 18 19 20 21 22 23 +------+------+------+------+------+------+------+------+ ... |ENCODE| VISA | FINN | MTUR | MTUP | ZSU | SSR | SID | ... +------+------+------+------+------+------+------+------+ 24 25 26 27 28 29 30 31 +------+------+------+------+------+------+------+------+ ... | RR |CIPSO |E-SEC | TS | LSR | SEC | NOP | EOOL | +------+------+------+------+------+------+------+------+ Now EOOL is 2^0 as intended, NOP is 2^1 etc. Note that the network bit numbering in the figure is exactly the reverse of the "Bit" value in the table - so it might be better to rename "Bit" as "position". P. From paitken@cisco.com Wed Aug 17 04:08: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 D0B5721F8B32 for ; Wed, 17 Aug 2011 04:08:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.53 X-Spam-Level: X-Spam-Status: No, score=-10.53 tagged_above=-999 required=5 tests=[AWL=0.069, 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 pqQDX8eyztBj for ; Wed, 17 Aug 2011 04:08:35 -0700 (PDT) Received: from ams-iport-2.cisco.com (ams-iport-2.cisco.com [144.254.224.141]) by ietfa.amsl.com (Postfix) with ESMTP id CC43921F8B2F for ; Wed, 17 Aug 2011 04:08:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=paitken@cisco.com; l=3235; q=dns/txt; s=iport; t=1313579366; x=1314788966; h=message-id:date:from:mime-version:to:cc:subject: content-transfer-encoding; bh=kbAvJtDMsDwkt1DAv4TZ2OtPU9zqNx4OWjY7LkcihWM=; b=MbqLNgLaX3zZoX0O0u/3b0NJQ+eIqSLKxHJuD4ZU76ldnF5OPT3hrOKn gRYSfW5UVScY1SnAg+4fZY0tbFe/O2mKyGdV9q2f0c9We/Ob3IsvCSXEs XvQ4L3KJJQNXM/yKc3gkS987uaCt+uD1FJLo/AC0jKGiWnV5H0fLBfkNU k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av4EADigS06Q/khN/2dsb2JhbAAoGqhhd4FZASUzDQE8FhgDAgECAS8cDQEHAQEeh1IjmBoBny+GSASTE4UMi2po X-IronPort-AV: E=Sophos;i="4.68,239,1312156800"; d="scan'208";a="50877718" Received: from ams-core-4.cisco.com ([144.254.72.77]) by ams-iport-2.cisco.com with ESMTP; 17 Aug 2011 11:09:25 +0000 Received: from [144.254.153.24] (dhcp-144-254-153-24.cisco.com [144.254.153.24]) by ams-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id p7HB9OEt016050; Wed, 17 Aug 2011 11:09:25 GMT Message-ID: <4E4BA164.3080408@cisco.com> Date: Wed, 17 Aug 2011 12:09:24 +0100 From: Paul Aitken User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.18) Gecko/20110617 Lightning/1.0b2 Thunderbird/3.1.11 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] Errata 1738 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, 17 Aug 2011 11:08:35 -0000 Dear IPFIX experts, RFC 5102, section "5.8.6. ipv6ExtensionHeaders", provides the following table: Bit IPv6 Option Description 0, Res Reserved 1, FRA1 44 Fragmentation header - not first fragment 2, RH 43 Routing header 3, FRA0 44 Fragment header - first fragment 4, UNK Unknown Layer 4 header (compressed, encrypted, not supported) 5, Res Reserved 6, HOP 0 Hop-by-hop option header 7, DST 60 Destination option header 8, PAY 108 Payload compression header 9, AH 51 Authentication Header 10, ESP 50 Encrypted security payload 11 to 31 Reserved The intention was to encode each header in the corresponding bit per the table, so FRA1 would be 2^1, RH would be 2^2, UNK would be 2^4 etc. So from a programming point of view, the bits should be: 7 6 5 4 3 2 1 0 +------+------+------+------+------+------+------+------+ ... | DST | HOP | Res | UNK | FRA0 | RH | FRA1 | Res | +------+------+------+------+------+------+------+------+ Unfortunately RFCs number the bits in the opposite order, so what we drew in RFC 5102 was: 0 1 2 3 4 5 6 7 +-----+-----+-----+-----+-----+-----+-----+-----+ | Res | FRA1| RH | FRA0| UNK | Res | HOP | DST | ... +-----+-----+-----+-----+-----+-----+-----+-----+ - which is exactly the opposite of what was intended. The text is right, but the figure is backwards. Per the errata, "The diagram is back to front." I tried to correct this in Errata 1737: http://www.rfc-editor.org/errata_search.php?eid=1737 Unfortunately I only flipped the bits around inside the bytes without flipping the bytes around too. What the errata should say is: 0 1 2 3 4 5 6 7 +-----+-----+-----+-----+-----+-----+-----+-----+ | Reserved | ... +-----+-----+-----+-----+-----+-----+-----+-----+ 8 9 10 11 12 13 14 15 +-----+-----+-----+-----+-----+-----+-----+-----+ ... | Reserved | ... +-----+-----+-----+-----+-----+-----+-----+-----+ 16 17 18 19 20 21 22 23 +-----+-----+-----+-----+-----+-----+-----+-----+ ... | Reserved | ESP | AH | PAY | ... +-----+-----+-----+-----+-----+-----+-----+-----+ 24 25 26 27 28 29 30 31 +-----+-----+-----+-----+-----+-----+-----+-----+ ... | DST | HOP | Res | UNK | FRA0| RH | FRA1| Res | +-----+-----+-----+-----+-----+-----+-----+-----+ Note that the network bit numbering in the figure is exactly the reverse of the "Bit" value in the table - so it might be better to rename "Bit" as "position". P. From dromasca@avaya.com Wed Aug 17 05:26:16 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 B032121F8B63 for ; Wed, 17 Aug 2011 05:26:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.921 X-Spam-Level: X-Spam-Status: No, score=-102.921 tagged_above=-999 required=5 tests=[AWL=-0.322, 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 24-fYgZ-lGU6 for ; Wed, 17 Aug 2011 05:26:14 -0700 (PDT) Received: from p-us1-iereast-outbound.us1.avaya.com (p-us1-iereast-outbound.us1.avaya.com [135.11.29.13]) by ietfa.amsl.com (Postfix) with ESMTP id C1CA121F8B68 for ; Wed, 17 Aug 2011 05:26:14 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: As8AAMuxS06HCzI1/2dsb2JhbAAoGpkQj1Z3gUABAQEBAxIeCjEaBAIBCA0BAwQBAQsGDAsBBgFFCQgBAQQBEggah1IjmhkCnE2FaV8EmD2LTWc X-IronPort-AV: E=Sophos;i="4.68,239,1312171200"; d="scan'208";a="202233220" Received: from unknown (HELO p-us1-erheast.us1.avaya.com) ([135.11.50.53]) by p-us1-iereast-outbound.us1.avaya.com with ESMTP; 17 Aug 2011 08:27:04 -0400 Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.10]) by p-us1-erheast-out.us1.avaya.com with ESMTP; 17 Aug 2011 08:18:49 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Wed, 17 Aug 2011 14:27:02 +0200 Message-ID: In-Reply-To: <4E4BA164.3080408@cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Errata 1738 Thread-Index: AcxcziJmbBrYlzugQx+HDRPAyoSfRAACiQ3w References: <4E4BA164.3080408@cisco.com> From: "Romascanu, Dan (Dan)" To: "Paul Aitken" , "IETF IPFIX Working Group" Subject: Re: [IPFIX] Errata 1738 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, 17 Aug 2011 12:26:16 -0000 Thanks, Paul. This seems OK to me now. I would also like to know if any of the IPFIX experts sees any problem with this fix - before we enter and approve a new erratum.=20 Regards, Dan > -----Original Message----- > From: Paul Aitken [mailto:paitken@cisco.com] > Sent: Wednesday, August 17, 2011 2:09 PM > To: IETF IPFIX Working Group > Cc: Romascanu, Dan (Dan) > Subject: Errata 1738 >=20 > Dear IPFIX experts, >=20 > RFC 5102, section "5.8.6. ipv6ExtensionHeaders", provides the following > table: >=20 > Bit IPv6 Option Description >=20 > 0, Res Reserved > 1, FRA1 44 Fragmentation header - not first fragment > 2, RH 43 Routing header > 3, FRA0 44 Fragment header - first fragment > 4, UNK Unknown Layer 4 header > (compressed, encrypted, not supported) > 5, Res Reserved > 6, HOP 0 Hop-by-hop option header > 7, DST 60 Destination option header > 8, PAY 108 Payload compression header > 9, AH 51 Authentication Header > 10, ESP 50 Encrypted security payload > 11 to 31 Reserved >=20 >=20 > The intention was to encode each header in the corresponding bit per > the > table, so FRA1 would be 2^1, RH would be 2^2, UNK would be 2^4 etc. > So from a programming point of view, the bits should be: >=20 > 7 6 5 4 3 2 1 0 > +------+------+------+------+------+------+------+------+ > ... | DST | HOP | Res | UNK | FRA0 | RH | FRA1 | Res | > +------+------+------+------+------+------+------+------+ >=20 >=20 > Unfortunately RFCs number the bits in the opposite order, so what we > drew in RFC 5102 was: >=20 > 0 1 2 3 4 5 6 7 > +-----+-----+-----+-----+-----+-----+-----+-----+ > | Res | FRA1| RH | FRA0| UNK | Res | HOP | DST | ... > +-----+-----+-----+-----+-----+-----+-----+-----+ >=20 >=20 > - which is exactly the opposite of what was intended. The text is > right, > but the figure is backwards. Per the errata, "The diagram is back to > front." >=20 > I tried to correct this in Errata 1737: > http://www.rfc-editor.org/errata_search.php?eid=3D1737 >=20 > Unfortunately I only flipped the bits around inside the bytes without > flipping the bytes around too. >=20 > What the errata should say is: >=20 >=20 > 0 1 2 3 4 5 6 7 > +-----+-----+-----+-----+-----+-----+-----+-----+ > | Reserved | ... > +-----+-----+-----+-----+-----+-----+-----+-----+ >=20 > 8 9 10 11 12 13 14 15 > +-----+-----+-----+-----+-----+-----+-----+-----+ > ... | Reserved | ... > +-----+-----+-----+-----+-----+-----+-----+-----+ >=20 > 16 17 18 19 20 21 22 23 > +-----+-----+-----+-----+-----+-----+-----+-----+ > ... | Reserved | ESP | AH | PAY | ... > +-----+-----+-----+-----+-----+-----+-----+-----+ >=20 > 24 25 26 27 28 29 30 31 > +-----+-----+-----+-----+-----+-----+-----+-----+ > ... | DST | HOP | Res | UNK | FRA0| RH | FRA1| Res | > +-----+-----+-----+-----+-----+-----+-----+-----+ >=20 >=20 > Note that the network bit numbering in the figure is exactly the > reverse > of the "Bit" value in the table - so it might be better to rename "Bit" > as "position". >=20 > P. From paitken@cisco.com Wed Aug 17 06:05:05 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 BEFD221F8B6F for ; Wed, 17 Aug 2011 06:05:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.387 X-Spam-Level: X-Spam-Status: No, score=-9.387 tagged_above=-999 required=5 tests=[AWL=-1.088, BAYES_00=-2.599, MANGLED_SAVELE=2.3, 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 O-pX0i+a5z7Y for ; Wed, 17 Aug 2011 06:05:04 -0700 (PDT) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by ietfa.amsl.com (Postfix) with ESMTP id 509A821F8B73 for ; Wed, 17 Aug 2011 06:05:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=paitken@cisco.com; l=4632; q=dns/txt; s=iport; t=1313586355; x=1314795955; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=l9R3JhaPJF3KvDY00znHnrxaPQ8XFcc1Dtv+XYSa7rs=; b=Bj72+fLBvFrfT3hTfk4dG5S5EuTcOzaZwzbyXWkVDVAxRcHa4QL95Q8R eHqrafPlgO/LB9MrfZQddG4lHhrQ2NtD3vmAKp+fjHD5zwfCUfp60PR5s 1/u+PL2alr32eakyxst2I7JShFQq1n4P9WLhu/PDVkv8b2CTBU6gsiw2P 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: As8AAI67S06Q/khL/2dsb2JhbAAoGpkSj1Z3gUABAQEBAgESASUzDQEFBwQLEQQBAQoWCAcJAwIBAgE0CQgGDQEFAgEBHodOBCOXFgGfJIZIBJMThQyLamg X-IronPort-AV: E=Sophos;i="4.68,240,1312156800"; d="scan'208";a="111234099" Received: from ams-core-2.cisco.com ([144.254.72.75]) by ams-iport-1.cisco.com with ESMTP; 17 Aug 2011 13:05:53 +0000 Received: from [144.254.153.24] (dhcp-144-254-153-24.cisco.com [144.254.153.24]) by ams-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id p7HD5qXP017955; Wed, 17 Aug 2011 13:05:52 GMT Message-ID: <4E4BBCB0.5060408@cisco.com> Date: Wed, 17 Aug 2011 14:05:52 +0100 From: Paul Aitken User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.18) Gecko/20110617 Lightning/1.0b2 Thunderbird/3.1.11 MIME-Version: 1.0 To: "Romascanu, Dan (Dan)" References: <4E4BA164.3080408@cisco.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: IETF IPFIX Working Group Subject: Re: [IPFIX] Errata 1738 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, 17 Aug 2011 13:05:05 -0000 Dan, Note that the same applies to 1737, 1738 and 1739. I've written about 1737 and 1738. The revised figure for 1739 would be like so: 0 1 2 3 4 5 6 7 +-----+-----+-----+-----+-----+-----+-----+-----+ | 63 | 62 | 61 | 60 | 59 | 58 | 57 | 56 | ... +-----+-----+-----+-----+-----+-----+-----+-----+ . . . 56 57 58 59 60 61 62 63 +-----+-----+-----+-----+-----+-----+-----+-----+ ... | 7 | 6 | 5 | 4 | 3 | 2 | 1 | 0 | +-----+-----+-----+-----+-----+-----+-----+-----+ P. > Thanks, Paul. This seems OK to me now. I would also like to know if any > of the IPFIX experts sees any problem with this fix - before we enter > and approve a new erratum. > > Regards, > > Dan > > > > >> -----Original Message----- >> From: Paul Aitken [mailto:paitken@cisco.com] >> Sent: Wednesday, August 17, 2011 2:09 PM >> To: IETF IPFIX Working Group >> Cc: Romascanu, Dan (Dan) >> Subject: Errata 1738 >> >> Dear IPFIX experts, >> >> RFC 5102, section "5.8.6. ipv6ExtensionHeaders", provides the > following >> table: >> >> Bit IPv6 Option Description >> >> 0, Res Reserved >> 1, FRA1 44 Fragmentation header - not first fragment >> 2, RH 43 Routing header >> 3, FRA0 44 Fragment header - first fragment >> 4, UNK Unknown Layer 4 header >> (compressed, encrypted, not supported) >> 5, Res Reserved >> 6, HOP 0 Hop-by-hop option header >> 7, DST 60 Destination option header >> 8, PAY 108 Payload compression header >> 9, AH 51 Authentication Header >> 10, ESP 50 Encrypted security payload >> 11 to 31 Reserved >> >> >> The intention was to encode each header in the corresponding bit per >> the >> table, so FRA1 would be 2^1, RH would be 2^2, UNK would be 2^4 etc. >> So from a programming point of view, the bits should be: >> >> 7 6 5 4 3 2 1 0 >> +------+------+------+------+------+------+------+------+ >> ... | DST | HOP | Res | UNK | FRA0 | RH | FRA1 | Res | >> +------+------+------+------+------+------+------+------+ >> >> >> Unfortunately RFCs number the bits in the opposite order, so what we >> drew in RFC 5102 was: >> >> 0 1 2 3 4 5 6 7 >> +-----+-----+-----+-----+-----+-----+-----+-----+ >> | Res | FRA1| RH | FRA0| UNK | Res | HOP | DST | ... >> +-----+-----+-----+-----+-----+-----+-----+-----+ >> >> >> - which is exactly the opposite of what was intended. The text is >> right, >> but the figure is backwards. Per the errata, "The diagram is back to >> front." >> >> I tried to correct this in Errata 1737: >> http://www.rfc-editor.org/errata_search.php?eid=1737 >> >> Unfortunately I only flipped the bits around inside the bytes without >> flipping the bytes around too. >> >> What the errata should say is: >> >> >> 0 1 2 3 4 5 6 7 >> +-----+-----+-----+-----+-----+-----+-----+-----+ >> | Reserved | ... >> +-----+-----+-----+-----+-----+-----+-----+-----+ >> >> 8 9 10 11 12 13 14 15 >> +-----+-----+-----+-----+-----+-----+-----+-----+ >> ... | Reserved | ... >> +-----+-----+-----+-----+-----+-----+-----+-----+ >> >> 16 17 18 19 20 21 22 23 >> +-----+-----+-----+-----+-----+-----+-----+-----+ >> ... | Reserved | ESP | AH | PAY | ... >> +-----+-----+-----+-----+-----+-----+-----+-----+ >> >> 24 25 26 27 28 29 30 31 >> +-----+-----+-----+-----+-----+-----+-----+-----+ >> ... | DST | HOP | Res | UNK | FRA0| RH | FRA1| Res | >> +-----+-----+-----+-----+-----+-----+-----+-----+ >> >> >> Note that the network bit numbering in the figure is exactly the >> reverse >> of the "Bit" value in the table - so it might be better to rename > "Bit" >> as "position". >> >> P. From paitken@cisco.com Thu Aug 18 02:33:23 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 15DD021F8AEC for ; Thu, 18 Aug 2011 02:33:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.438 X-Spam-Level: X-Spam-Status: No, score=-10.438 tagged_above=-999 required=5 tests=[AWL=0.161, 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 MRtFi+va-XN7 for ; Thu, 18 Aug 2011 02:33:22 -0700 (PDT) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by ietfa.amsl.com (Postfix) with ESMTP id 4F70821F8A4F for ; Thu, 18 Aug 2011 02:33:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=paitken@cisco.com; l=1159; q=dns/txt; s=iport; t=1313660056; x=1314869656; h=message-id:date:from:mime-version:to:subject: content-transfer-encoding; bh=wBXqjuqRwfy9UgV8/rY/P4EqKwQxXCJshIihDibO0d4=; b=FVtZntYb5qnCzMqpWS+nSFhp9zfCswRr8fl0uHmsaiIoRt77nf+l9zpF uElr1EKAb9w3VD/+jqkWhPc40vHdTddivSXob/n/Gp6gy1ditqXrKKRhJ GOmnQXHh0z3Y8X3HpBRBlaxvMg62wVKqdIDA0UpCQTl6ZlYtnu+mUwURk s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EACzcTE6Q/khN/2dsb2JhbABBqG93gVkBJTMNPRYYAwIBAgE/DA0IAQEeoDmBIwGeeIZIBJMThQyLag X-IronPort-AV: E=Sophos;i="4.68,244,1312156800"; d="scan'208";a="111398811" Received: from ams-core-4.cisco.com ([144.254.72.77]) by ams-iport-1.cisco.com with ESMTP; 18 Aug 2011 09:34:11 +0000 Received: from [10.55.84.35] (dhcp-10-55-84-35.cisco.com [10.55.84.35]) by ams-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id p7I9YBgh026225 for ; Thu, 18 Aug 2011 09:34:11 GMT Message-ID: <4E4CDC92.5000003@cisco.com> Date: Thu, 18 Aug 2011 10:34:10 +0100 From: Paul Aitken User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.18) Gecko/20110617 Lightning/1.0b2 Thunderbird/3.1.11 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] template lifetime 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: Thu, 18 Aug 2011 09:33:23 -0000 Dear IPFIX experts, RFC5102, section 10.3.7 ("Collecting Process") says: The Collecting Process MUST associate a lifetime with each Template (or another definition of an identifier considered unique within the Transport Session) received via UDP. Templates (and similar definitions) not refreshed by the Exporting Process within the lifetime are expired at the Collecting Process. ... The Template lifetime at the Collecting Process MUST be at least 3 times higher than the Template refresh timeout configured on the Exporting Process. How does a collector determine the correct lifetime to associate with each Template, and how does it know "the Template refresh timeout configured on the Exporting Process." ? What are the default and acceptable range of lifetime values? Should we have a mechanism which allows an Exporting Process to report Template lifetimes to the Collecting Process? eg, by exporting an option of { scope = templateId, lifetime = lifeTimeUnits }, where lifeTimeUnits = u32 milliseconds - which allows 1ms to 49.7 days, with 0 = infinite? Thanks, P. From trammell@tik.ee.ethz.ch Thu Aug 18 04:08:14 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 5BF5B21F89BE for ; Thu, 18 Aug 2011 04:08:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] 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 Xm3N2XkSxfwN for ; Thu, 18 Aug 2011 04:08:13 -0700 (PDT) Received: from smtp.ee.ethz.ch (smtp.ee.ethz.ch [129.132.2.219]) by ietfa.amsl.com (Postfix) with ESMTP id 7225C21F86B3 for ; Thu, 18 Aug 2011 04:08:13 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by smtp.ee.ethz.ch (Postfix) with ESMTP id B74DCD930E; Thu, 18 Aug 2011 13:08:53 +0200 (MEST) X-Virus-Scanned: by amavisd-new on smtp.ee.ethz.ch Received: from smtp.ee.ethz.ch ([127.0.0.1]) by localhost (.ee.ethz.ch [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 2zfE-XVtUFg5; Thu, 18 Aug 2011 13:08:53 +0200 (MEST) Received: from pb-10243.ethz.ch (pb-10243.ethz.ch [82.130.102.152]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: briant) by smtp.ee.ethz.ch (Postfix) with ESMTPSA id 846EBD930B; Thu, 18 Aug 2011 13:08:53 +0200 (MEST) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Brian Trammell In-Reply-To: <4E4CDC92.5000003@cisco.com> Date: Thu, 18 Aug 2011 13:08:53 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <4E4CDC92.5000003@cisco.com> To: Paul Aitken X-Mailer: Apple Mail (2.1084) Cc: IETF IPFIX Working Group Subject: Re: [IPFIX] template lifetime 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: Thu, 18 Aug 2011 11:08:14 -0000 Hi, Paul, My personal opinion is that, if we're not going to deprecate UDP with = prejudice (which I realize to my sorrow we cannot do), we should = jettison all this template lifetime nonsense. We spent an inordinate = amount of time on 5101/5102 the first time around trying to come up with = sensible guidance, then gave up and basically said "template lifetimes = are configured out of band according to operational environment and = application constraints", which is essentially RFCese for "here, you = make this work." Which is actually sensible: there is no default that = covers edge-network, core-network, and = IPFIX-as-SNMP-replacement-on-the-moon use cases. Half a decade later, there has never been a successful interop test to = my knowledge demonstrating the template management (expiry, withdrawal, = reissue) features in IPFIX. Most export applications use one, two, twenty, thirty templates, and = that's all they'll ever use, because those templates reflect the core = data model in use by the application, and the export app wants to waste = as little effort in export transcoding as possible. Sure, collectors in = the wild have to handle more templates than that, but it doesn't take = long as a collector operator (or even implementor) to realize that = practically speaking, nobody is ever going to reuse an ID on you without = dropping a session, and just setting your template expiry time to = something practically infinite . You interpret templates as they come = in, you replace old with new, and everything works unless you find = yourself in an insanely rare corner case -- and if you do, you write = something to the log and wake up the human. Trying to export template lifetime information from EP to CP adds = complexity while pretending that the system as specified works better = than an infinite-lifetime-at-collector with silent replacement, which = IMO is not the case. I'd propose we use the RFC5655 File Reader template rules (accept = anything that would be legal on any transport in any combination), but I = don't know the right way to do this in 5101bis: perhaps filing technical = errata on all the "MUST drop the session" language on the grounds that = 1. a receiver cannot always reliably signal session failure to a = transmitter and 2. it violates the "be liberal in what you accept" = principle of protocol design. Cheers, Brian On Aug 18, 2011, at 11:34 AM, Paul Aitken wrote: > Dear IPFIX experts, >=20 >=20 > RFC5102, section 10.3.7 ("Collecting Process") says: >=20 > The Collecting Process MUST associate a lifetime with each Template > (or another definition of an identifier considered unique within the > Transport Session) received via UDP. Templates (and similar > definitions) not refreshed by the Exporting Process within the > lifetime are expired at the Collecting Process. >=20 > ... >=20 > The Template lifetime at the Collecting Process MUST be at least 3 > times higher than the Template refresh timeout configured on the > Exporting Process. >=20 >=20 >=20 > How does a collector determine the correct lifetime to associate with = each Template, and how does it know "the Template refresh timeout = configured on the Exporting Process." ? >=20 > What are the default and acceptable range of lifetime values? >=20 > Should we have a mechanism which allows an Exporting Process to report = Template lifetimes to the Collecting Process? > eg, by exporting an option of { scope =3D templateId, lifetime =3D = lifeTimeUnits }, where lifeTimeUnits =3D u32 milliseconds - which allows = 1ms to 49.7 days, with 0 =3D infinite? >=20 > Thanks, > P. > _______________________________________________ > IPFIX mailing list > IPFIX@ietf.org > https://www.ietf.org/mailman/listinfo/ipfix From muenz@net.in.tum.de Thu Aug 18 12:14:52 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 DDE4121F8B8E for ; Thu, 18 Aug 2011 12:14:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.249 X-Spam-Level: X-Spam-Status: No, score=-2.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35] 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 884-f7KJmX3C for ; Thu, 18 Aug 2011 12:14:52 -0700 (PDT) Received: from mail-out1.informatik.tu-muenchen.de (mail-out1.informatik.tu-muenchen.de [131.159.0.8]) by ietfa.amsl.com (Postfix) with ESMTP id 2A2F721F8B7B for ; Thu, 18 Aug 2011 12:14:51 -0700 (PDT) Received: from [192.168.1.2] (e181140000.adsl.alicedsl.de [85.181.140.0]) by mail.net.in.tum.de (Postfix) with ESMTPSA id DE5BB2255988; Thu, 18 Aug 2011 21:20:41 +0200 (CEST) Message-ID: <4E4D64DA.1080601@net.in.tum.de> Date: Thu, 18 Aug 2011 21:15:38 +0200 From: Gerhard Muenz User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:6.0) Gecko/20110812 Thunderbird/6.0 MIME-Version: 1.0 To: Brian Trammell References: <4E4CDC92.5000003@cisco.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: IETF IPFIX Working Group Subject: Re: [IPFIX] template lifetime 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: Thu, 18 Aug 2011 19:14:53 -0000 Hi Paul, As Brian says, this problem is quite an old story. I agree with you: at a certain point, every careful reader of the IPFIX documents will recognize that Option Templates are defined for a lot of things, but strangely not for the Template refresh timeout, although this parameter seems so essential. I do not know the details why this has not been added to the standard. I agree with Brian: in practice, the knowledge of the Template refresh timeout is usually not essential because Collectors can just operate with a very long or even infinite lifetime (RFC 5101 does not seem to disallow this). A default minimum lifetime is indirectly defined by RFC 5101: "The default value for the frequency of the (Options) Template transmission is 10 minutes." This means that, by default, the lifetime at the collector is 30 minutes or longer. Regards, Gerhard On 18.08.2011 13:08, Brian Trammell wrote: > Hi, Paul, > > My personal opinion is that, if we're not going to deprecate UDP with > prejudice (which I realize to my sorrow we cannot do), we should > jettison all this template lifetime nonsense. We spent an inordinate > amount of time on 5101/5102 the first time around trying to come up > with sensible guidance, then gave up and basically said "template > lifetimes are configured out of band according to operational > environment and application constraints", which is essentially RFCese > for "here, you make this work." Which is actually sensible: there is > no default that covers edge-network, core-network, and > IPFIX-as-SNMP-replacement-on-the-moon use cases. > > Half a decade later, there has never been a successful interop test > to my knowledge demonstrating the template management (expiry, > withdrawal, reissue) features in IPFIX. > > Most export applications use one, two, twenty, thirty templates, and > that's all they'll ever use, because those templates reflect the core > data model in use by the application, and the export app wants to > waste as little effort in export transcoding as possible. Sure, > collectors in the wild have to handle more templates than that, but > it doesn't take long as a collector operator (or even implementor) to > realize that practically speaking, nobody is ever going to reuse an > ID on you without dropping a session, and just setting your template > expiry time to something practically infinite . You interpret > templates as they come in, you replace old with new, and everything > works unless you find yourself in an insanely rare corner case -- and > if you do, you write something to the log and wake up the human. > > Trying to export template lifetime information from EP to CP adds > complexity while pretending that the system as specified works better > than an infinite-lifetime-at-collector with silent replacement, which > IMO is not the case. > > I'd propose we use the RFC5655 File Reader template rules (accept > anything that would be legal on any transport in any combination), > but I don't know the right way to do this in 5101bis: perhaps filing > technical errata on all the "MUST drop the session" language on the > grounds that 1. a receiver cannot always reliably signal session > failure to a transmitter and 2. it violates the "be liberal in what > you accept" principle of protocol design. > > Cheers, > > Brian > > On Aug 18, 2011, at 11:34 AM, Paul Aitken wrote: > >> Dear IPFIX experts, >> >> >> RFC5102, section 10.3.7 ("Collecting Process") says: >> >> The Collecting Process MUST associate a lifetime with each >> Template (or another definition of an identifier considered unique >> within the Transport Session) received via UDP. Templates (and >> similar definitions) not refreshed by the Exporting Process within >> the lifetime are expired at the Collecting Process. >> >> ... >> >> The Template lifetime at the Collecting Process MUST be at least 3 >> times higher than the Template refresh timeout configured on the >> Exporting Process. >> >> >> >> How does a collector determine the correct lifetime to associate >> with each Template, and how does it know "the Template refresh >> timeout configured on the Exporting Process." ? >> >> What are the default and acceptable range of lifetime values? >> >> Should we have a mechanism which allows an Exporting Process to >> report Template lifetimes to the Collecting Process? eg, by >> exporting an option of { scope = templateId, lifetime = >> lifeTimeUnits }, where lifeTimeUnits = u32 milliseconds - which >> allows 1ms to 49.7 days, with 0 = infinite? >> >> Thanks, P. _______________________________________________ IPFIX >> mailing list IPFIX@ietf.org >> https://www.ietf.org/mailman/listinfo/ipfix > > _______________________________________________ IPFIX mailing list > IPFIX@ietf.org https://www.ietf.org/mailman/listinfo/ipfix From andrewf@plixer.com Thu Aug 18 12:27:43 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 A11D421F8BCD for ; Thu, 18 Aug 2011 12:27:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[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 OY7gaFN30Yk8 for ; Thu, 18 Aug 2011 12:27:43 -0700 (PDT) Received: from smtp.plixer.com (smtp.plixer.com [66.186.184.193]) by ietfa.amsl.com (Postfix) with ESMTP id CC95021F8BCB for ; Thu, 18 Aug 2011 12:27:42 -0700 (PDT) Received: from [10.1.15.20] ([66.186.184.173]) by smtp.plixer.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Thu, 18 Aug 2011 15:28:36 -0400 Message-ID: <4E4D67E4.1080705@plixer.com> Date: Thu, 18 Aug 2011 15:28:36 -0400 From: Andrew Feren User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:8.0a1) Gecko/20110814 Thunderbird/8.0a1 MIME-Version: 1.0 To: ipfix@ietf.org References: <4E4CDC92.5000003@cisco.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 18 Aug 2011 19:28:36.0307 (UTC) FILETIME=[0660E230:01CC5DDD] Subject: Re: [IPFIX] template lifetime 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: Thu, 18 Aug 2011 19:27:43 -0000 I agree with Brian. You could export an options template with template lifetime information, but I don't think it solves any problems. The exporter still can't know when it is safe to reuse template ids since there is no upper bound on the lifetime that the collector MUST associate with a template. The way I see it this means either 1) the exporters also need to be notified of the lifetime used by the collector (how?) 2) template lifetime is a collector implementation detail and templates are silently replaced, logging problems as necessary Option 2 is a lot simpler and works well in practice. -Andrew On 08/18/2011 07:08 AM, Brian Trammell wrote: > Hi, Paul, > > My personal opinion is that, if we're not going to deprecate UDP with prejudice (which I realize to my sorrow we cannot do), we should jettison all this template lifetime nonsense. We spent an inordinate amount of time on 5101/5102 the first time around trying to come up with sensible guidance, then gave up and basically said "template lifetimes are configured out of band according to operational environment and application constraints", which is essentially RFCese for "here, you make this work." Which is actually sensible: there is no default that covers edge-network, core-network, and IPFIX-as-SNMP-replacement-on-the-moon use cases. > > Half a decade later, there has never been a successful interop test to my knowledge demonstrating the template management (expiry, withdrawal, reissue) features in IPFIX. > > Most export applications use one, two, twenty, thirty templates, and that's all they'll ever use, because those templates reflect the core data model in use by the application, and the export app wants to waste as little effort in export transcoding as possible. Sure, collectors in the wild have to handle more templates than that, but it doesn't take long as a collector operator (or even implementor) to realize that practically speaking, nobody is ever going to reuse an ID on you without dropping a session, and just setting your template expiry time to something practically infinite . You interpret templates as they come in, you replace old with new, and everything works unless you find yourself in an insanely rare corner case -- and if you do, you write something to the log and wake up the human. > > Trying to export template lifetime information from EP to CP adds complexity while pretending that the system as specified works better than an infinite-lifetime-at-collector with silent replacement, which IMO is not the case. > > I'd propose we use the RFC5655 File Reader template rules (accept anything that would be legal on any transport in any combination), but I don't know the right way to do this in 5101bis: perhaps filing technical errata on all the "MUST drop the session" language on the grounds that 1. a receiver cannot always reliably signal session failure to a transmitter and 2. it violates the "be liberal in what you accept" principle of protocol design. > > Cheers, > > Brian > > On Aug 18, 2011, at 11:34 AM, Paul Aitken wrote: > >> Dear IPFIX experts, >> >> >> RFC5102, section 10.3.7 ("Collecting Process") says: >> >> The Collecting Process MUST associate a lifetime with each Template >> (or another definition of an identifier considered unique within the >> Transport Session) received via UDP. Templates (and similar >> definitions) not refreshed by the Exporting Process within the >> lifetime are expired at the Collecting Process. >> >> ... >> >> The Template lifetime at the Collecting Process MUST be at least 3 >> times higher than the Template refresh timeout configured on the >> Exporting Process. >> >> >> >> How does a collector determine the correct lifetime to associate with each Template, and how does it know "the Template refresh timeout configured on the Exporting Process." ? >> >> What are the default and acceptable range of lifetime values? >> >> Should we have a mechanism which allows an Exporting Process to report Template lifetimes to the Collecting Process? >> eg, by exporting an option of { scope = templateId, lifetime = lifeTimeUnits }, where lifeTimeUnits = u32 milliseconds - which allows 1ms to 49.7 days, with 0 = infinite? >> >> Thanks, >> P. >> _______________________________________________ >> IPFIX mailing list >> IPFIX@ietf.org >> https://www.ietf.org/mailman/listinfo/ipfix > _______________________________________________ > IPFIX mailing list > IPFIX@ietf.org > https://www.ietf.org/mailman/listinfo/ipfix From paitken@cisco.com Thu Aug 18 12:35:44 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 B8FF61F0C3D for ; Thu, 18 Aug 2011 12:35:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.452 X-Spam-Level: X-Spam-Status: No, score=-10.452 tagged_above=-999 required=5 tests=[AWL=0.147, 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 APPyhPXs1grb for ; Thu, 18 Aug 2011 12:35:43 -0700 (PDT) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by ietfa.amsl.com (Postfix) with ESMTP id 9A84E1F0C3C for ; Thu, 18 Aug 2011 12:35:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=paitken@cisco.com; l=544; q=dns/txt; s=iport; t=1313696198; x=1314905798; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=RYjn5ugZixJTa2e8/wW+1+xs5wQf0/M8hL0sS2vPPf8=; b=me54csVbDfk0pxVjZ/8e5QR1q1ri490v9l6rDf4snBSo9J3p0G2wYRrL 9MuZAiS61c+XFE1E+poVDlF9ek+CojF4LpTlPofsdB6bmTgTk6AtSYH6N GgMOvQB4uMlz4urwiFNVnrmRoZRderxHSjtBKT+x1VRr1kle7DPCh7H9K Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EAMloTU6Q/khN/2dsb2JhbABCp3V3gUABAQEBAxIBJUABEAshFg8JAwIBAgFFBgEMAQcBAR6gVwGfH4ZIBJMThQyLag X-IronPort-AV: E=Sophos;i="4.68,247,1312156800"; d="scan'208";a="111483724" Received: from ams-core-4.cisco.com ([144.254.72.77]) by ams-iport-1.cisco.com with ESMTP; 18 Aug 2011 19:36:37 +0000 Received: from [10.55.84.35] (dhcp-10-55-84-35.cisco.com [10.55.84.35]) by ams-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id p7IJabU4018032; Thu, 18 Aug 2011 19:36:37 GMT Message-ID: <4E4D69C4.5080107@cisco.com> Date: Thu, 18 Aug 2011 20:36:36 +0100 From: Paul Aitken User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.18) Gecko/20110617 Lightning/1.0b2 Thunderbird/3.1.11 MIME-Version: 1.0 To: Gerhard Muenz , Brian Trammell References: <4E4CDC92.5000003@cisco.com> <4E4D64DA.1080601@net.in.tum.de> In-Reply-To: <4E4D64DA.1080601@net.in.tum.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: IETF IPFIX Working Group Subject: Re: [IPFIX] template lifetime 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: Thu, 18 Aug 2011 19:35:44 -0000 Brian, Gerhard, Thanks for your replies. I know it's an old problem, but someone asked what the default refresh interval should be. So it seems we should either define a mechanism for Exporters to inform Collectors what their default refresh interval is (eg, define a new standard options template), or re-work (or even remove?) the template timeout sections. Currently this is a gap which allows an Exporting Process and a Collecting Process to both claim to be IPFIX compliant, while being quite un-interoperable. P. From paitken@cisco.com Thu Aug 18 14:45:41 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 E449E11E80A2 for ; Thu, 18 Aug 2011 14:45:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.463 X-Spam-Level: X-Spam-Status: No, score=-10.463 tagged_above=-999 required=5 tests=[AWL=0.136, 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 Qf0GrsPoON-Y for ; Thu, 18 Aug 2011 14:45:41 -0700 (PDT) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by ietfa.amsl.com (Postfix) with ESMTP id C8BC511E80A9 for ; Thu, 18 Aug 2011 14:45:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=paitken@cisco.com; l=1288; q=dns/txt; s=iport; t=1313703996; x=1314913596; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=78oDuKbHR2XQMLpbw1/6TqYmLLYoiqPiG5Zd1EuPGPM=; b=TErCg8FqPUbzxZ+itMdJMP96OkQgFeMImGpulGFMf3BOBjXVa1qjWeMd P1UY7UDiJoOg78NcIy4HHbnRUsuExkSDXLWckmS03B0r+Hpj0WLSLi4/G +569tJljb0H9s4CXMIHJ2DIcMuP+dQ1nAgrQbhHCLkWlxRYNU1jmk6m84 k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av4EAN6GTU6Q/khR/2dsb2JhbABCp3d3gUABAQEBAgESASVBBQsLISUPAkYGDQEHAQEeh0+YSQGfC4ZIBJMThQyLag X-IronPort-AV: E=Sophos;i="4.68,247,1312156800"; d="scan'208";a="111493429" Received: from ams-core-1.cisco.com ([144.254.72.81]) by ams-iport-1.cisco.com with ESMTP; 18 Aug 2011 21:46:32 +0000 Received: from [10.55.84.35] (dhcp-10-55-84-35.cisco.com [10.55.84.35]) by ams-core-1.cisco.com (8.14.3/8.14.3) with ESMTP id p7ILkWdr004044; Thu, 18 Aug 2011 21:46:32 GMT Message-ID: <4E4D8838.80709@cisco.com> Date: Thu, 18 Aug 2011 22:46:32 +0100 From: Paul Aitken User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.18) Gecko/20110617 Lightning/1.0b2 Thunderbird/3.1.11 MIME-Version: 1.0 To: Andrew Feren References: <4E4CDC92.5000003@cisco.com> <4E4D67E4.1080705@plixer.com> In-Reply-To: <4E4D67E4.1080705@plixer.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: ipfix@ietf.org Subject: Re: [IPFIX] template lifetime 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: Thu, 18 Aug 2011 21:45:42 -0000 Andrew, > I agree with Brian. > > You could export an options template with template lifetime > information, but I don't think it solves any problems. The exporter > still can't know when it is safe to reuse template ids since there is > no upper bound on the lifetime that the collector MUST associate with > a template. > > The way I see it this means either > > 1) the exporters also need to be notified of the lifetime used by the > collector (how?) Out of band configuration. However this implies that one size must fit all, which is probably not the case. Exporters only need to re-send their templates in proportion to the data loss they can tolerate. For some, that may mean a template in every data packet (though they should clearly be using SCTP). For others, once in 24 hours may be quite sufficient. > 2) template lifetime is a collector implementation detail and > templates are silently replaced, logging problems as necessary I think the idea of template lifetime is to ensure that templates expire and are deleted before they're ever re-used - so there's never any redefinition. > Option 2 is a lot simpler and works well in practice. If we accept silent re-definition then lifetime is a non-issue. Thanks, P. From paitken@cisco.com Fri Aug 19 07:33:14 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 0FA2D21F8A30 for ; Fri, 19 Aug 2011 07:33:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.473 X-Spam-Level: X-Spam-Status: No, score=-10.473 tagged_above=-999 required=5 tests=[AWL=0.126, 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 GXFuUG2CTtEn for ; Fri, 19 Aug 2011 07:33:13 -0700 (PDT) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by ietfa.amsl.com (Postfix) with ESMTP id 44FC921F8997 for ; Fri, 19 Aug 2011 07:33:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=paitken@cisco.com; l=253; q=dns/txt; s=iport; t=1313764450; x=1314974050; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=/y8ptVk5jFfdbsYRt4x0T6KoFRuO7X5MJw2Toaz+IsA=; b=hxRxZxKmK3ihH0EEKuahn1rSkwztwvc4QmwO/JbrnGhGUUIRY14aB/wJ Sl6jXlsJWSRW3kEKTyuN7eo7fiWVjV6UxkYhjBbK0Rm7egpGKk50qSqfa AufwreoAsVXqfQ7Zhy41vBl/VqkvfsmSonwX6m4H3Xq8H0SUSoHLRzO1E 0=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EAPVzTk6Q/khN/2dsb2JhbABBqA13gUABAQEBAgESASUzDQEFCwshFg8JAwIBAgFFBg0BBwEBHodPmXoBnnKGSASTE4UMi2o X-IronPort-AV: E=Sophos;i="4.68,251,1312156800"; d="scan'208";a="111621577" Received: from ams-core-4.cisco.com ([144.254.72.77]) by ams-iport-1.cisco.com with ESMTP; 19 Aug 2011 14:34:09 +0000 Received: from [10.61.88.101] (ams3-vpn-dhcp6246.cisco.com [10.61.88.101]) by ams-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id p7JEY8Nq020540; Fri, 19 Aug 2011 14:34:09 GMT Message-ID: <4E4E7460.8040100@cisco.com> Date: Fri, 19 Aug 2011 15:34:08 +0100 From: Paul Aitken User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.18) Gecko/20110617 Lightning/1.0b2 Thunderbird/3.1.11 MIME-Version: 1.0 To: "Romascanu, Dan (Dan)" References: <4E4BA164.3080408@cisco.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: IETF IPFIX Working Group Subject: Re: [IPFIX] Errata 1738 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, 19 Aug 2011 14:33:14 -0000 Dan, > Thanks, Paul. This seems OK to me now. I would also like to know if any > of the IPFIX experts sees any problem with this fix - before we enter > and approve a new erratum. There was no reply. Shall I proceed with 3 new errata? P. From ishibashi.keisuke@lab.ntt.co.jp Wed Aug 17 23:08:50 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 CD82621F86FF for ; Wed, 17 Aug 2011 23:08:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.51 X-Spam-Level: ** X-Spam-Status: No, score=2.51 tagged_above=-999 required=5 tests=[BAYES_50=0.001, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265] 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 Dfja+DG7Df7S for ; Wed, 17 Aug 2011 23:08:50 -0700 (PDT) Received: from tama50.ecl.ntt.co.jp (tama50.ecl.ntt.co.jp [129.60.39.147]) by ietfa.amsl.com (Postfix) with ESMTP id DB7FE21F86D0 for ; Wed, 17 Aug 2011 23:08:49 -0700 (PDT) Received: from mfs5.rdh.ecl.ntt.co.jp (mfs5.rdh.ecl.ntt.co.jp [129.60.39.144]) by tama50.ecl.ntt.co.jp (8.14.5/8.14.5) with ESMTP id p7I69ff4011697 for ; Thu, 18 Aug 2011 15:09:41 +0900 (JST) Received: from mfs5.rdh.ecl.ntt.co.jp (localhost [127.0.0.1]) by mfs5.rdh.ecl.ntt.co.jp (Postfix) with ESMTP id 34CBB6D6B for ; Thu, 18 Aug 2011 15:09:41 +0900 (JST) Received: from imail1.m.ecl.ntt.co.jp (imail1-mgr.m.ecl.ntt.co.jp [129.60.144.41]) by mfs5.rdh.ecl.ntt.co.jp (Postfix) with ESMTP id 0FE1C6D65 for ; Thu, 18 Aug 2011 15:09:41 +0900 (JST) Received: from [127.0.0.1] ([129.60.21.189]) by imail1.m.ecl.ntt.co.jp (8.13.8/8.13.8) with ESMTP id p7I69elq027763; Thu, 18 Aug 2011 15:09:40 +0900 Message-ID: <4E4CACA4.100@lab.ntt.co.jp> Date: Thu, 18 Aug 2011 15:09:40 +0900 From: Keisuke ISHIBASHI User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; ja; rv:1.9.1.5) Gecko/20091204 Thunderbird/3.0 MIME-Version: 1.0 To: ipfix@ietf.org Content-Type: text/plain; charset=ISO-2022-JP Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Fri, 19 Aug 2011 13:55:01 -0700 Cc: Keisuke ISHIBASHI Subject: [IPFIX] Invited paper on IPFIX 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: Thu, 18 Aug 2011 06:08:50 -0000 Dear IPFIXers, Nevil kindly gave a invited paper to the IEICE transactions, which rather focuses on the history and future work of IPFIX WG, as well as the IPFIX protocol. The paper is freely available online at: http://search.ieice.org/bin/pdf_link.php?category=B&lang=E&year=2011&fname=e94-b_8_2190&abst= Thank you, Nevil! Keisuke ISHIBASHI From acmorton@att.com Sat Aug 20 06:53:42 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 67B9521F8A36; Sat, 20 Aug 2011 06:53:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.332 X-Spam-Level: X-Spam-Status: No, score=-105.332 tagged_above=-999 required=5 tests=[AWL=0.464, 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 hM4s1AJ8MuFi; Sat, 20 Aug 2011 06:53:41 -0700 (PDT) Received: from mail119.messagelabs.com (mail119.messagelabs.com [216.82.241.195]) by ietfa.amsl.com (Postfix) with ESMTP id 70C6B21F871C; Sat, 20 Aug 2011 06:53:41 -0700 (PDT) X-VirusChecked: Checked X-Env-Sender: acmorton@att.com X-Msg-Ref: server-3.tower-119.messagelabs.com!1313848479!35046721!1 X-StarScan-Version: 6.2.17; banners=-,-,- X-Originating-IP: [144.160.20.145] Received: (qmail 13137 invoked from network); 20 Aug 2011 13:54:39 -0000 Received: from sbcsmtp6.sbc.com (HELO mlpd192.enaf.sfdc.sbc.com) (144.160.20.145) by server-3.tower-119.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 20 Aug 2011 13:54:39 -0000 Received: from enaf.sfdc.sbc.com (localhost.localdomain [127.0.0.1]) by mlpd192.enaf.sfdc.sbc.com (8.14.4/8.14.4) with ESMTP id p7KDt5tQ029770; Sat, 20 Aug 2011 09:55:05 -0400 Received: from alpd052.aldc.att.com (alpd052.aldc.att.com [130.8.42.31]) by mlpd192.enaf.sfdc.sbc.com (8.14.4/8.14.4) with ESMTP id p7KDsxDG029721; Sat, 20 Aug 2011 09:55:00 -0400 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 p7KDsXbF007053; Sat, 20 Aug 2011 09:54:33 -0400 Received: from dns.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 p7KDsPvh006933; Sat, 20 Aug 2011 09:54:25 -0400 Message-Id: <201108201354.p7KDsPvh006933@alpd052.aldc.att.com> Received: from acmt.att.com (vpn-135-70-84-27.vpn.swst.att.com[135.70.84.27](misconfigured sender)) by maillennium.att.com (mailgw1) with SMTP id <20110820135424gw100e4l2he>; Sat, 20 Aug 2011 13:54:25 +0000 X-Originating-IP: [135.70.84.27] X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Sat, 20 Aug 2011 09:55:12 -0400 To: bmwg@ietf.org From: Al Morton In-Reply-To: <201108011522.p71FLxj6018359@alpd052.aldc.att.com> References: <201108011522.p71FLxj6018359@alpd052.aldc.att.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: ipfix@ietf.org Subject: Re: [IPFIX] [bmwg] WGLC: draft-ietf-bmwg-ipflow-meth-03 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, 20 Aug 2011 13:53:42 -0000 Reminder on this, Al At 11:22 AM 8/1/2011, Al Morton wrote: >BMWG, >CC: IPFIX WG, > >This message begins the third 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-03 > >The Last Call will end on August 31, 2011. > >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. > >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 > >_______________________________________________ >bmwg mailing list >bmwg@ietf.org >https://www.ietf.org/mailman/listinfo/bmwg From fcalabri@cisco.com Sat Aug 20 06:55:29 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 33E3D21F8A71; Sat, 20 Aug 2011 06:55:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.532 X-Spam-Level: X-Spam-Status: No, score=-0.532 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_NUMERIC_HELO=2.067] 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 OCNrJAB3nwMW; Sat, 20 Aug 2011 06:55:28 -0700 (PDT) Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) by ietfa.amsl.com (Postfix) with ESMTP id 9D76621F8A36; Sat, 20 Aug 2011 06:55:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=fcalabri@cisco.com; l=1412; q=dns/txt; s=iport; t=1313848588; x=1315058188; h=subject:references:content-transfer-encoding:from: in-reply-to:message-id:date:to:cc:mime-version; bh=RmbdZZSAAhWgkU1dHNYrnIKOUgBdzPOmQILEPNgZTh8=; b=Z1Fif90EqszLN+8EgDfRTc/sE5DYCnmh7QLJ0Xj475wWvm1a8lpuhx6u ASW5IET7cERCkxvEWjGeE9xvIPUZsPWGq1Q7ug6nTsPxh9Ev9EY5Gb4He /7dgREB9ehMg33g9zO7LCpTJbcrIgExBKJU5dGowvW0TEwWQj0s4pjZHS M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AtsIABq8T06tJV2c/2dsb2JhbABBqAwCd4FAAQEBAQIBAQEBDwEnNAsFCwIBCA4KLicwAQEEEyKHTwSaXgGeMYVpXwSYKYt9 X-IronPort-AV: E=Sophos;i="4.68,255,1312156800"; d="scan'208";a="14943604" Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by rcdn-iport-7.cisco.com with ESMTP; 20 Aug 2011 13:56:28 +0000 Received: from xbh-rcd-301.cisco.com (xbh-rcd-301.cisco.com [72.163.63.8]) by rcdn-core-5.cisco.com (8.14.3/8.14.3) with ESMTP id p7KDuSg5015663; Sat, 20 Aug 2011 13:56:28 GMT Received: from xmb-rcd-101.cisco.com ([72.163.62.143]) by xbh-rcd-301.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Sat, 20 Aug 2011 08:56:28 -0500 Received: from 72.163.62.136 ([72.163.62.136]) by XMB-RCD-101.cisco.com ([72.163.62.143]) with Microsoft Exchange Server HTTP-DAV ; Sat, 20 Aug 2011 13:56:27 +0000 References: <201108011522.p71FLxj6018359@alpd052.aldc.att.com> <201108201354.p7KDsPvh006933@alpd052.aldc.att.com> Content-Transfer-Encoding: 7bit From: "Fernando Calabria (fcalabri)" Content-Type: text/plain; charset="us-ascii" In-Reply-To: <201108201354.p7KDsPvh006933@alpd052.aldc.att.com> Thread-Topic: [bmwg] WGLC: draft-ietf-bmwg-ipflow-meth-03 Thread-Index: AcxfQPTZzHT0VmWGRVi1kFPX6hB2AQ== Message-ID: <2E918141-35E6-438B-A491-380FA066C038@cisco> Date: Sat, 20 Aug 2011 09:56:27 -0400 To: "Al Morton" MIME-Version: 1.0 (iPad Mail 8L1) X-OriginalArrivalTime: 20 Aug 2011 13:56:28.0406 (UTC) FILETIME=[F5400160:01CC5F40] X-Mailman-Approved-At: Sat, 20 Aug 2011 22:01:42 -0700 Cc: ipfix@ietf.org, bmwg@ietf.org Subject: Re: [IPFIX] [bmwg] WGLC: draft-ietf-bmwg-ipflow-meth-03 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, 20 Aug 2011 13:55:29 -0000 I support Rgds -Fernando On Aug 20, 2011, at 9:54, "Al Morton" wrote: > Reminder on this, > Al > > At 11:22 AM 8/1/2011, Al Morton wrote: >> BMWG, >> CC: IPFIX WG, >> >> This message begins the third 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-03 >> >> The Last Call will end on August 31, 2011. >> >> 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. >> >> 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 >> >> _______________________________________________ >> bmwg mailing list >> bmwg@ietf.org >> https://www.ietf.org/mailman/listinfo/bmwg > > _______________________________________________ > bmwg mailing list > bmwg@ietf.org > https://www.ietf.org/mailman/listinfo/bmwg From dromasca@avaya.com Sun Aug 21 08:01:28 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 610B721F8AD2 for ; Sun, 21 Aug 2011 08:01:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.932 X-Spam-Level: X-Spam-Status: No, score=-102.932 tagged_above=-999 required=5 tests=[AWL=-0.333, 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 JRZ+qGj5GBVv for ; Sun, 21 Aug 2011 08:01:28 -0700 (PDT) Received: from p-us1-iereast-outbound.us1.avaya.com (p-us1-iereast-outbound.us1.avaya.com [135.11.29.13]) by ietfa.amsl.com (Postfix) with ESMTP id D3F4B21F8ACC for ; Sun, 21 Aug 2011 08:01:27 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ar8AAOocUU6HCzI1/2dsb2JhbABBmDGPYXeBQAEBAQEDEh4KMQ4MBAIBCA0BAwQBAQsGDAsBBgFFCQgBAQQTCBqhdQKbB4VpXwSYPotO X-IronPort-AV: E=Sophos;i="4.68,258,1312171200"; d="scan'208";a="203037489" Received: from unknown (HELO p-us1-erheast.us1.avaya.com) ([135.11.50.53]) by p-us1-iereast-outbound.us1.avaya.com with ESMTP; 21 Aug 2011 11:02:29 -0400 Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.14]) by p-us1-erheast-out.us1.avaya.com with ESMTP; 21 Aug 2011 10:54:06 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Sun, 21 Aug 2011 17:02:27 +0200 Message-ID: In-Reply-To: <4E4E7460.8040100@cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Errata 1738 Thread-Index: AcxefRBnrVJJVb4CTOazVgfn+/hJOQBljxCA References: <4E4BA164.3080408@cisco.com> <4E4E7460.8040100@cisco.com> From: "Romascanu, Dan (Dan)" To: "Paul Aitken" Cc: IETF IPFIX Working Group Subject: Re: [IPFIX] Errata 1738 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: Sun, 21 Aug 2011 15:01:28 -0000 Yes, please! Regards, Dan > -----Original Message----- > From: Paul Aitken [mailto:paitken@cisco.com] > Sent: Friday, August 19, 2011 5:34 PM > To: Romascanu, Dan (Dan) > Cc: IETF IPFIX Working Group > Subject: Re: Errata 1738 >=20 > Dan, >=20 > > Thanks, Paul. This seems OK to me now. I would also like to know if > any > > of the IPFIX experts sees any problem with this fix - before we enter > > and approve a new erratum. >=20 > There was no reply. >=20 > Shall I proceed with 3 new errata? >=20 > P. From n.brownlee@auckland.ac.nz Sun Aug 21 15:31:51 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 4284D21F85C7 for ; Sun, 21 Aug 2011 15:31:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.32 X-Spam-Level: X-Spam-Status: No, score=-103.32 tagged_above=-999 required=5 tests=[AWL=0.279, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, 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 4JLI7FSGyWKO for ; Sun, 21 Aug 2011 15:31:50 -0700 (PDT) Received: from mx2-int.auckland.ac.nz (mx2-int.auckland.ac.nz [130.216.12.41]) by ietfa.amsl.com (Postfix) with ESMTP id 477A221F85C0 for ; Sun, 21 Aug 2011 15:31:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=auckland.ac.nz; i=n.brownlee@auckland.ac.nz; q=dns/txt; s=uoa; t=1313965974; x=1345501974; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; z=Message-ID:=20<4E51878A.1010302@auckland.ac.nz>|Date:=20 Mon,=2022=20Aug=202011=2010:32:42=20+1200|From:=20Nevil =20Brownlee=20|MIME-Version: =201.0|To:=20"Romascanu,=20Dan=20(Dan)"=20|CC:=20Paul=20Aitken=20,=20=0D=0A =20IETF=20IPFIX=20Working=20Group=20 |Subject:=20Re:=20[IPFIX]=20Errata=201738|References:=20< 4E4BA164.3080408@cisco.com>=20=20<4E4E7460. 8040100@cisco.com>=20|In-Reply-To:=20|Content-Transfer-Encoding:=207bit; bh=HkIfIP9gB7QNIm9io9KWs5Qg1njCYgjnusY2gGVzL28=; b=oCjzsXaCnwrpnMgjEeU1rHo3GQ23kLNepWOa6xNVAECxhBJUJptnTiJq kSzS8BFQpLwQYzYnzYsljwoNN3A/o90v5vw77C8niDXeTn1s11bIlgbr/ umnPk7hU3VFw6yykv1BlpS2TuhvMzLBEHtvk8Dxg54e3WW5X/C+3AA++E o=; X-IronPort-AV: E=Sophos;i="4.68,260,1312113600"; d="scan'208";a="79450677" X-Ironport-HAT: UNIVERSITY - $RELAY-THROTTLE X-Ironport-Source: 130.216.38.131 - Outgoing - Outgoing-SSL Received: from nevil-laptop1.sfac.auckland.ac.nz (HELO [130.216.38.131]) ([130.216.38.131]) by mx2-int.auckland.ac.nz with ESMTP; 22 Aug 2011 10:32:42 +1200 Message-ID: <4E51878A.1010302@auckland.ac.nz> Date: Mon, 22 Aug 2011 10:32:42 +1200 From: Nevil Brownlee User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:6.0) Gecko/20110812 Thunderbird/6.0 MIME-Version: 1.0 To: "Romascanu, Dan (Dan)" References: <4E4BA164.3080408@cisco.com> <4E4E7460.8040100@cisco.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: IETF IPFIX Working Group Subject: Re: [IPFIX] Errata 1738 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: Sun, 21 Aug 2011 22:31:51 -0000 Hi all: Now that I've had a chance to look carefully at Paul's errata, they do indeed seem OK to me. I think we should indeed make these changes now, so as to make the documents correspond exactly with what we'd intended. Cheers, Nevil On 22/08/11 3:02 AM, Romascanu, Dan (Dan) wrote: > Yes, please! > > Regards, > > Dan > > > > >> -----Original Message----- >> From: Paul Aitken [mailto:paitken@cisco.com] >> Sent: Friday, August 19, 2011 5:34 PM >> To: Romascanu, Dan (Dan) >> Cc: IETF IPFIX Working Group >> Subject: Re: Errata 1738 >> >> Dan, >> >>> Thanks, Paul. This seems OK to me now. I would also like to know if >> any >>> of the IPFIX experts sees any problem with this fix - before we > enter >>> and approve a new erratum. >> >> There was no reply. >> >> Shall I proceed with 3 new errata? >> >> P. > _______________________________________________ > IPFIX mailing list > IPFIX@ietf.org > https://www.ietf.org/mailman/listinfo/ipfix -- --------------------------------------------------------------------- Nevil Brownlee Computer Science Department | ITS Phone: +64 9 373 7599 x88941 The University of Auckland FAX: +64 9 373 7453 Private Bag 92019, Auckland 1142, New Zealand From trammell@tik.ee.ethz.ch Sun Aug 21 22:31:49 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 1EC9C21F86C0 for ; Sun, 21 Aug 2011 22:31:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] 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 hYVilUxgSG8n for ; Sun, 21 Aug 2011 22:31:48 -0700 (PDT) Received: from smtp.ee.ethz.ch (smtp.ee.ethz.ch [129.132.2.219]) by ietfa.amsl.com (Postfix) with ESMTP id 1ED9A21F862F for ; Sun, 21 Aug 2011 22:31:47 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by smtp.ee.ethz.ch (Postfix) with ESMTP id 2915FD9307; Mon, 22 Aug 2011 07:32:49 +0200 (MEST) X-Virus-Scanned: by amavisd-new on smtp.ee.ethz.ch Received: from smtp.ee.ethz.ch ([127.0.0.1]) by localhost (.ee.ethz.ch [127.0.0.1]) (amavisd-new, port 10024) with LMTP id SKGmfWIjvHMr; Mon, 22 Aug 2011 07:32:48 +0200 (MEST) Received: from [10.0.1.2] (cust-integra-121-161.antanet.ch [80.75.121.161]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: briant) by smtp.ee.ethz.ch (Postfix) with ESMTPSA id CED56D9300; Mon, 22 Aug 2011 07:32:48 +0200 (MEST) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Brian Trammell In-Reply-To: <4E51878A.1010302@auckland.ac.nz> Date: Mon, 22 Aug 2011 07:32:46 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <93BC68E9-5AE3-473A-A706-E6FFD9ADC984@tik.ee.ethz.ch> References: <4E4BA164.3080408@cisco.com> <4E4E7460.8040100@cisco.com> <4E51878A.1010302@auckland.ac.nz> To: Nevil Brownlee X-Mailer: Apple Mail (2.1084) Cc: IETF IPFIX Working Group Subject: Re: [IPFIX] Errata 1738 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, 22 Aug 2011 05:31:49 -0000 +1 (my previous message on this seems to have been lost, but didn't really = have any more content...) Cheers, Brian On Aug 22, 2011, at 12:32 AM, Nevil Brownlee wrote: >=20 > Hi all: >=20 > Now that I've had a chance to look carefully at Paul's errata, > they do indeed seem OK to me. I think we should indeed make these > changes now, so as to make the documents correspond exactly with > what we'd intended. >=20 > Cheers, Nevil >=20 >=20 > On 22/08/11 3:02 AM, Romascanu, Dan (Dan) wrote: >> Yes, please! >>=20 >> Regards, >>=20 >> Dan >>=20 >>=20 >>=20 >>=20 >>> -----Original Message----- >>> From: Paul Aitken [mailto:paitken@cisco.com] >>> Sent: Friday, August 19, 2011 5:34 PM >>> To: Romascanu, Dan (Dan) >>> Cc: IETF IPFIX Working Group >>> Subject: Re: Errata 1738 >>>=20 >>> Dan, >>>=20 >>>> Thanks, Paul. This seems OK to me now. I would also like to know if >>> any >>>> of the IPFIX experts sees any problem with this fix - before we >> enter >>>> and approve a new erratum. >>>=20 >>> There was no reply. >>>=20 >>> Shall I proceed with 3 new errata? >>>=20 >>> P. >> _______________________________________________ >> IPFIX mailing list >> IPFIX@ietf.org >> https://www.ietf.org/mailman/listinfo/ipfix >=20 >=20 > --=20 > --------------------------------------------------------------------- > Nevil Brownlee Computer Science Department | ITS > Phone: +64 9 373 7599 x88941 The University of Auckland > FAX: +64 9 373 7453 Private Bag 92019, Auckland 1142, New Zealand > _______________________________________________ > IPFIX mailing list > IPFIX@ietf.org > https://www.ietf.org/mailman/listinfo/ipfix From wwwrun@rfc-editor.org Mon Aug 22 04:00:11 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 F40AA21F8B02 for ; Mon, 22 Aug 2011 04:00:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.506 X-Spam-Level: X-Spam-Status: No, score=-102.506 tagged_above=-999 required=5 tests=[AWL=0.094, BAYES_00=-2.599, NO_RELAYS=-0.001, 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 yw+Dtcwjtv4v for ; Mon, 22 Aug 2011 04:00:10 -0700 (PDT) Received: from rfc-editor.org (rfc-editor.org [IPv6:2001:1890:123a::1:2f]) by ietfa.amsl.com (Postfix) with ESMTP id 73D4621F8B00 for ; Mon, 22 Aug 2011 04:00:10 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id 96E9F98C24C; Mon, 22 Aug 2011 04:01:11 -0700 (PDT) To: quittek@netlab.nec.de, stbryant@cisco.com, bclaise@cisco.com, paitken@cisco.com, jemeyer@paypal.com, dromasca@avaya.com, rbonica@juniper.net, n.brownlee@auckland.ac.nz, quittek@neclab.eu From: RFC Errata System Message-Id: <20110822110112.96E9F98C24C@rfc-editor.org> Date: Mon, 22 Aug 2011 04:01:11 -0700 (PDT) Cc: pjaitken@gmail.com, ipfix@ietf.org, rfc-editor@rfc-editor.org Subject: [IPFIX] [Technical Errata Reported] RFC5102 (2944) 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, 22 Aug 2011 11:00:11 -0000 The following errata report has been submitted for RFC5102, "Information Model for IP Flow Information Export". -------------------------------------- You may review the report below and at: http://www.rfc-editor.org/errata_search.php?rfc=5102&eid=2944 -------------------------------------- Type: Technical Reported by: Paul Aitken Section: 5.8.5 Original Text ------------- 0 1 2 3 4 5 6 7 +------+------+------+------+------+------+------+------+ | EOOL | NOP | SEC | LSR | TS |E-SEC |CIPSO | RR | ... +------+------+------+------+------+------+------+------+ 8 9 10 11 12 13 14 15 +------+------+------+------+------+------+------+------+ ... | SID | SSR | ZSU | MTUP | MTUR | FINN | VISA |ENCODE| ... +------+------+------+------+------+------+------+------+ 16 17 18 19 20 21 22 23 +------+------+------+------+------+------+------+------+ ... |IMITD | EIP | TR |ADDEXT|RTRALT| SDB |NSAPA | DPS | ... +------+------+------+------+------+------+------+------+ 24 25 26 27 28 29 30 31 +------+------+------+------+------+------+------+------+ ... | UMP | QS | to be assigned by IANA | EXP | | +------+------+------+------+------+------+------+------+ Corrected Text -------------- 0 1 2 3 4 5 6 7 +------+------+------+------+------+------+------+------+ | | EXP | to be assigned by IANA | QS | UMP | ... +------+------+------+------+------+------+------+------+ 8 9 10 11 12 13 14 15 +------+------+------+------+------+------+------+------+ ... | DPS |NSAPA | SDB |RTRALT|ADDEXT| TR | EIP |IMITD | ... +------+------+------+------+------+------+------+------+ 16 17 18 19 20 21 22 23 +------+------+------+------+------+------+------+------+ ... |ENCODE| VISA | FINN | MTUR | MTUP | ZSU | SSR | SID | ... +------+------+------+------+------+------+------+------+ 24 25 26 27 28 29 30 31 +------+------+------+------+------+------+------+------+ ... | RR |CIPSO |E-SEC | TS | LSR | SEC | NOP | EOOL | +------+------+------+------+------+------+------+------+ Notes ----- The bits were originally shown in the wrong order. Errata 1737 tried to correct this by reversing the bits, but overlooked reversing the bytes. Note that the network bit numbering in the figure is exactly the reverse of the "Bit" value in the following table. Instructions: ------------- This errata is currently posted as "Reported". If necessary, please use "Reply All" to discuss whether it should be verified or rejected. When a decision is reached, the verifying party (IESG) can log in to change the status and edit the report, if necessary. -------------------------------------- RFC5102 (draft-ietf-ipfix-info-15) -------------------------------------- Title : Information Model for IP Flow Information Export Publication Date : January 2008 Author(s) : J. Quittek, S. Bryant, B. Claise, P. Aitken, J. Meyer Category : PROPOSED STANDARD Source : IP Flow Information Export Area : Operations and Management Stream : IETF Verifying Party : IESG From wwwrun@rfc-editor.org Mon Aug 22 04:08:43 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 4706C21F8B22 for ; Mon, 22 Aug 2011 04:08:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.507 X-Spam-Level: X-Spam-Status: No, score=-102.507 tagged_above=-999 required=5 tests=[AWL=0.093, BAYES_00=-2.599, NO_RELAYS=-0.001, 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 YJdKN83r2mRk for ; Mon, 22 Aug 2011 04:08:42 -0700 (PDT) Received: from rfc-editor.org (rfc-editor.org [IPv6:2001:1890:123a::1:2f]) by ietfa.amsl.com (Postfix) with ESMTP id A4EEA21F8B20 for ; Mon, 22 Aug 2011 04:08:42 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id 1D7E498C24E; Mon, 22 Aug 2011 04:09:45 -0700 (PDT) To: quittek@netlab.nec.de, stbryant@cisco.com, bclaise@cisco.com, paitken@cisco.com, jemeyer@paypal.com, dromasca@avaya.com, rbonica@juniper.net, n.brownlee@auckland.ac.nz, quittek@neclab.eu From: RFC Errata System Message-Id: <20110822110945.1D7E498C24E@rfc-editor.org> Date: Mon, 22 Aug 2011 04:09:45 -0700 (PDT) Cc: ipfix@ietf.org, rfc-editor@rfc-editor.org Subject: [IPFIX] [Technical Errata Reported] RFC5102 (2945) 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, 22 Aug 2011 11:08:43 -0000 The following errata report has been submitted for RFC5102, "Information Model for IP Flow Information Export". -------------------------------------- You may review the report below and at: http://www.rfc-editor.org/errata_search.php?rfc=5102&eid=2945 -------------------------------------- Type: Technical Reported by: Paul Aitken Section: 5.8.6 Original Text ------------- 0 1 2 3 4 5 6 7 +-----+-----+-----+-----+-----+-----+-----+-----+ | Res | FRA1| RH | FRA0| UNK | Res | HOP | DST | ... +-----+-----+-----+-----+-----+-----+-----+-----+ 8 9 10 11 12 13 14 15 +-----+-----+-----+-----+-----+-----+-----+-----+ ... | PAY | AH | ESP | Reserved | ... +-----+-----+-----+-----+-----+-----+-----+-----+ 16 17 18 19 20 21 22 23 +-----+-----+-----+-----+-----+-----+-----+-----+ ... | Reserved | ... +-----+-----+-----+-----+-----+-----+-----+-----+ 24 25 26 27 28 29 30 31 +-----+-----+-----+-----+-----+-----+-----+-----+ ... | Reserved | +-----+-----+-----+-----+-----+-----+-----+-----+ Corrected Text -------------- 0 1 2 3 4 5 6 7 +-----+-----+-----+-----+-----+-----+-----+-----+ | Reserved | ... +-----+-----+-----+-----+-----+-----+-----+-----+ 8 9 10 11 12 13 14 15 +-----+-----+-----+-----+-----+-----+-----+-----+ ... | Reserved | ... +-----+-----+-----+-----+-----+-----+-----+-----+ 16 17 18 19 20 21 22 23 +-----+-----+-----+-----+-----+-----+-----+-----+ ... | Reserved | ESP | AH | PAY | ... +-----+-----+-----+-----+-----+-----+-----+-----+ 24 25 26 27 28 29 30 31 +-----+-----+-----+-----+-----+-----+-----+-----+ ... | DST | HOP | Res | UNK | FRA0| RH | FRA1| Res | +-----+-----+-----+-----+-----+-----+-----+-----+ Notes ----- The bits were originally shown in the wrong order. Errata 1738 tried to correct this by reversing the bits, but overlooked reversing the bytes. Note that the network bit numbering in the figure is exactly the reverse of the "Bit" value in the following table. Instructions: ------------- This errata is currently posted as "Reported". If necessary, please use "Reply All" to discuss whether it should be verified or rejected. When a decision is reached, the verifying party (IESG) can log in to change the status and edit the report, if necessary. -------------------------------------- RFC5102 (draft-ietf-ipfix-info-15) -------------------------------------- Title : Information Model for IP Flow Information Export Publication Date : January 2008 Author(s) : J. Quittek, S. Bryant, B. Claise, P. Aitken, J. Meyer Category : PROPOSED STANDARD Source : IP Flow Information Export Area : Operations and Management Stream : IETF Verifying Party : IESG From wwwrun@rfc-editor.org Mon Aug 22 04:15: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 17A7321F85B9 for ; Mon, 22 Aug 2011 04:15:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.357 X-Spam-Level: X-Spam-Status: No, score=-101.357 tagged_above=-999 required=5 tests=[AWL=-1.057, BAYES_00=-2.599, MANGLED_SAVELE=2.3, NO_RELAYS=-0.001, 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 gBsGzTFT4mOF for ; Mon, 22 Aug 2011 04:15:52 -0700 (PDT) Received: from rfc-editor.org (rfc-editor.org [IPv6:2001:1890:123a::1:2f]) by ietfa.amsl.com (Postfix) with ESMTP id 7C10C21F8586 for ; Mon, 22 Aug 2011 04:15:52 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id 6FA9298C24C; Mon, 22 Aug 2011 04:16:54 -0700 (PDT) To: quittek@netlab.nec.de, stbryant@cisco.com, bclaise@cisco.com, paitken@cisco.com, jemeyer@paypal.com, dromasca@avaya.com, rbonica@juniper.net, n.brownlee@auckland.ac.nz, quittek@neclab.eu From: RFC Errata System Message-Id: <20110822111654.6FA9298C24C@rfc-editor.org> Date: Mon, 22 Aug 2011 04:16:54 -0700 (PDT) Cc: ipfix@ietf.org, rfc-editor@rfc-editor.org Subject: [IPFIX] [Technical Errata Reported] RFC5102 (2946) 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, 22 Aug 2011 11:15:53 -0000 The following errata report has been submitted for RFC5102, "Information Model for IP Flow Information Export". -------------------------------------- You may review the report below and at: http://www.rfc-editor.org/errata_search.php?rfc=5102&eid=2946 -------------------------------------- Type: Technical Reported by: Paul Aitken Section: 5.8.8 Original Text ------------- 0 1 2 3 4 5 6 7 +-----+-----+-----+-----+-----+-----+-----+-----+ | 0 | 1 | 2 | 3 | 4 | 5 | 6 | 7 | ... +-----+-----+-----+-----+-----+-----+-----+-----+ 8 9 10 11 12 13 14 15 +-----+-----+-----+-----+-----+-----+-----+-----+ ... | 8 | 9 | 10 | 11 | 12 | 13 | 14 | 15 |... +-----+-----+-----+-----+-----+-----+-----+-----+ 16 17 18 19 20 21 22 23 +-----+-----+-----+-----+-----+-----+-----+-----+ ... | 16 | 17 | 18 | 19 | 20 | 21 | 22 | 23 |... +-----+-----+-----+-----+-----+-----+-----+-----+ . . . 56 57 58 59 60 61 62 63 +-----+-----+-----+-----+-----+-----+-----+-----+ ... | 56 | 57 | 58 | 59 | 60 | 61 | 62 | 63 | +-----+-----+-----+-----+-----+-----+-----+-----+ Corrected Text -------------- 0 1 2 3 4 5 6 7 +-----+-----+-----+-----+-----+-----+-----+-----+ | 63 | 62 | 61 | 60 | 59 | 58 | 57 | 56 | ... +-----+-----+-----+-----+-----+-----+-----+-----+ 8 9 10 11 12 13 14 15 +-----+-----+-----+-----+-----+-----+-----+-----+ ... | 55 | 54 | 53 | 52 | 51 | 50 | 49 | 48 |... +-----+-----+-----+-----+-----+-----+-----+-----+ 16 17 18 19 20 21 22 23 +-----+-----+-----+-----+-----+-----+-----+-----+ ... | 47 | 46 | 45 | 44 | 43 | 42 | 41 | 40 |... +-----+-----+-----+-----+-----+-----+-----+-----+ . . . 56 57 58 59 60 61 62 63 +-----+-----+-----+-----+-----+-----+-----+-----+ ... | 7 | 6 | 5 | 4 | 3 | 2 | 1 | 0 | +-----+-----+-----+-----+-----+-----+-----+-----+ Notes ----- The bits were originally shown in the wrong order. Errata 1739 tried to correct this by reversing the bits, but overlooked reversing the bytes. Instructions: ------------- This errata is currently posted as "Reported". If necessary, please use "Reply All" to discuss whether it should be verified or rejected. When a decision is reached, the verifying party (IESG) can log in to change the status and edit the report, if necessary. -------------------------------------- RFC5102 (draft-ietf-ipfix-info-15) -------------------------------------- Title : Information Model for IP Flow Information Export Publication Date : January 2008 Author(s) : J. Quittek, S. Bryant, B. Claise, P. Aitken, J. Meyer Category : PROPOSED STANDARD Source : IP Flow Information Export Area : Operations and Management Stream : IETF Verifying Party : IESG From trammell@tik.ee.ethz.ch Tue Aug 23 15:22:03 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 9AE1E21F8D5F for ; Tue, 23 Aug 2011 15:21:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.754 X-Spam-Level: X-Spam-Status: No, score=-5.754 tagged_above=-999 required=5 tests=[AWL=-0.845, BAYES_00=-2.599, DATE_IN_PAST_96_XX=1.69, RCVD_IN_DNSWL_MED=-4] 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 U5bgysFIDQD1 for ; Tue, 23 Aug 2011 15:21:53 -0700 (PDT) Received: from smtp.ee.ethz.ch (smtp.ee.ethz.ch [129.132.2.219]) by ietfa.amsl.com (Postfix) with ESMTP id 3B97721F8CD8 for ; Tue, 23 Aug 2011 15:21:51 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by smtp.ee.ethz.ch (Postfix) with ESMTP id 4E929D930A; Wed, 24 Aug 2011 00:22:58 +0200 (MEST) X-Virus-Scanned: by amavisd-new on smtp.ee.ethz.ch Received: from smtp.ee.ethz.ch ([127.0.0.1]) by localhost (.ee.ethz.ch [127.0.0.1]) (amavisd-new, port 10024) with LMTP id IS-AJBNbUkos; Wed, 24 Aug 2011 00:22:58 +0200 (MEST) Received: from [10.0.1.6] (cust-integra-121-161.antanet.ch [80.75.121.161]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: briant) by smtp.ee.ethz.ch (Postfix) with ESMTPSA id D3AD4D9307; Wed, 24 Aug 2011 00:22:57 +0200 (MEST) References: <4E4BA164.3080408@cisco.com> <4E4E7460.8040100@cisco.com> From: Brian Trammell Content-Type: text/plain; charset=us-ascii In-Reply-To: <4E4E7460.8040100@cisco.com> Message-Id: <91E1E9B6-68CB-437F-9D95-189A7F4C3AE0@tik.ee.ethz.ch> Date: Fri, 19 Aug 2011 19:34:12 +0200 To: Paul Aitken Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (iPhone Mail 8L1) X-Mailer: iPhone Mail (8L1) Cc: IETF IPFIX Working Group Subject: Re: [IPFIX] Errata 1738 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, 23 Aug 2011 22:22:03 -0000 Sorry, these were still in my queue. on quick review, these are good. cheers, B Sent from my iPhone On 19.08.2011, at 16:34, Paul Aitken wrote: > Dan, > >> Thanks, Paul. This seems OK to me now. I would also like to know if any >> of the IPFIX experts sees any problem with this fix - before we enter >> and approve a new erratum. > > There was no reply. > > Shall I proceed with 3 new errata? > > P. > _______________________________________________ > IPFIX mailing list > IPFIX@ietf.org > https://www.ietf.org/mailman/listinfo/ipfix From n.brownlee@auckland.ac.nz Wed Aug 24 16:34: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 7F3AB21F8CE5 for ; Wed, 24 Aug 2011 16:34:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.351 X-Spam-Level: X-Spam-Status: No, score=-103.351 tagged_above=-999 required=5 tests=[AWL=0.248, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, 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 M-c+QfL8MTRU for ; Wed, 24 Aug 2011 16:34:52 -0700 (PDT) Received: from mx2-int.auckland.ac.nz (mx2-int.auckland.ac.nz [130.216.12.41]) by ietfa.amsl.com (Postfix) with ESMTP id 9838B21F8CDE for ; Wed, 24 Aug 2011 16:34:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=auckland.ac.nz; i=n.brownlee@auckland.ac.nz; q=dns/txt; s=uoa; t=1314228965; x=1345764965; h=message-id:date:from:mime-version:to:subject: content-transfer-encoding; z=Message-ID:=20<4E558AE2.9000308@auckland.ac.nz>|Date:=20 Thu,=2025=20Aug=202011=2011:36:02=20+1200|From:=20Nevil =20Brownlee=20|MIME-Version: =201.0|To:=20IPFIX=20Working=20Group=20 |Subject:=20Any=20last=20comments=20on=20draft-ietf-ipfix -flow-selection-tech-07=20???|Content-Transfer-Encoding: =207bit; bh=4965TSuUSYElzwXhGuBHs/RybM3Br2tYT0vvwcZBq6c=; b=KrGpvD1vVf21lYulbgfhrlWrYz3/QVdrVL9hWg8p+MpAvIFoYPJHGOEu XGEi+7AVU2ghpcdgGrUlCFg29PJXjnziycmiH2ZsBQxn9gwOeZ6rghuF6 M9IjARv8BFxbshzjyoSodRtuV/LStgTkDkyCwXCwJjYMVF1JE8U1yzzte I=; X-IronPort-AV: E=Sophos;i="4.68,278,1312113600"; d="scan'208";a="80416378" X-Ironport-HAT: UNIVERSITY - $RELAY-THROTTLE X-Ironport-Source: 130.216.38.131 - Outgoing - Outgoing-SSL Received: from nevil-laptop1.sfac.auckland.ac.nz (HELO [130.216.38.131]) ([130.216.38.131]) by mx2-int.auckland.ac.nz with ESMTP; 25 Aug 2011 11:36:02 +1200 Message-ID: <4E558AE2.9000308@auckland.ac.nz> Date: Thu, 25 Aug 2011 11:36:02 +1200 From: Nevil Brownlee User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:6.0) Gecko/20110812 Thunderbird/6.0 MIME-Version: 1.0 To: IPFIX Working Group Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [IPFIX] Any last comments on draft-ietf-ipfix-flow-selection-tech-07 ??? 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, 24 Aug 2011 23:34:53 -0000 Hi all: There hasn't been any comment on the selection draft for nearly a month - as long as I don't hear any by next Monday, I'll declare its WG Last Call finished and send its write-up to Dan. Cheers, Nevil -- --------------------------------------------------------------------- Nevil Brownlee Computer Science Department | ITS Phone: +64 9 373 7599 x88941 The University of Auckland FAX: +64 9 373 7453 Private Bag 92019, Auckland 1142, New Zealand From trammell@tik.ee.ethz.ch Thu Aug 25 03:58:39 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 49FC121F8551 for ; Thu, 25 Aug 2011 03:58:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] 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 qa83UyMlYbxU for ; Thu, 25 Aug 2011 03:58:38 -0700 (PDT) Received: from smtp.ee.ethz.ch (smtp.ee.ethz.ch [129.132.2.219]) by ietfa.amsl.com (Postfix) with ESMTP id AA6DF21F84EB for ; Thu, 25 Aug 2011 03:58:37 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by smtp.ee.ethz.ch (Postfix) with ESMTP id 67B06D930E; Thu, 25 Aug 2011 12:59:49 +0200 (MEST) X-Virus-Scanned: by amavisd-new on smtp.ee.ethz.ch Received: from smtp.ee.ethz.ch ([127.0.0.1]) by localhost (.ee.ethz.ch [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 7Z1eUJFJeTg6; Thu, 25 Aug 2011 12:59:49 +0200 (MEST) Received: from pb-10243.ethz.ch (pb-10243.ethz.ch [82.130.102.152]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: briant) by smtp.ee.ethz.ch (Postfix) with ESMTPSA id 25E56D9302; Thu, 25 Aug 2011 12:59:49 +0200 (MEST) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Brian Trammell In-Reply-To: <4E558AE2.9000308@auckland.ac.nz> Date: Thu, 25 Aug 2011 12:59:48 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <08DFC317-B5DA-494F-ABDE-9D6A5F7A4610@tik.ee.ethz.ch> References: <4E558AE2.9000308@auckland.ac.nz> To: Nevil Brownlee X-Mailer: Apple Mail (2.1084) Cc: IPFIX Working Group Subject: Re: [IPFIX] Any last comments on draft-ietf-ipfix-flow-selection-tech-07 ??? 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: Thu, 25 Aug 2011 10:58:39 -0000 hi, Nevil, all, I'm still not a big fan of the IE names ("fs" means "filesystem" to me, = not "flow selection"), but as long as the conflict between IE 3 as = reserved for V9 and the fsFlowRecordTotalCount has been resolved (and it = appears, it has been resolved such that fsFlowRecordTotalCount gets a = new, non-compatible IE number, since its semantics really are different = from "flowDeltaCount" as implied by the series of IEs leading up to IE = 3), and there is no other objection, I'm willing to go with consensus on = this one. Otherwise the draft appears to address the comments received during the = -06 last call, so I consider it ready for the IESG. Cheers, Brian On Aug 25, 2011, at 1:36 AM, Nevil Brownlee wrote: >=20 > Hi all: >=20 > There hasn't been any comment on the selection draft for nearly a > month - as long as I don't hear any by next Monday, I'll declare > its WG Last Call finished and send its write-up to Dan. >=20 > Cheers, Nevil >=20 > --=20 > --------------------------------------------------------------------- > Nevil Brownlee Computer Science Department | ITS > Phone: +64 9 373 7599 x88941 The University of Auckland > FAX: +64 9 373 7453 Private Bag 92019, Auckland 1142, New Zealand > _______________________________________________ > IPFIX mailing list > IPFIX@ietf.org > https://www.ietf.org/mailman/listinfo/ipfix From Quittek@neclab.eu Sun Aug 28 21:56:55 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 9548721F85AC for ; Sun, 28 Aug 2011 21:56:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.349 X-Spam-Level: X-Spam-Status: No, score=-102.349 tagged_above=-999 required=5 tests=[AWL=0.250, 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 SlrhHUvbVgiy for ; Sun, 28 Aug 2011 21:56:55 -0700 (PDT) Received: from mailer1.neclab.eu (mailer1.neclab.eu [195.37.70.40]) by ietfa.amsl.com (Postfix) with ESMTP id AB55E21F85A4 for ; Sun, 28 Aug 2011 21:56:54 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by mailer1.neclab.eu (Postfix) with ESMTP id 0B36B280001AA for ; Mon, 29 Aug 2011 06:58:17 +0200 (CEST) X-Virus-Scanned: Amavisd on Debian GNU/Linux (atlas1.office.hd) Received: from mailer1.neclab.eu ([127.0.0.1]) by localhost (atlas1.office.hd [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0FSjAozX03xB for ; Mon, 29 Aug 2011 06:58:16 +0200 (CEST) Received: from METHONE.office.hd (Methone.office.hd [192.168.24.54]) by mailer1.neclab.eu (Postfix) with ESMTP id DA58C2800018F for ; Mon, 29 Aug 2011 06:58:11 +0200 (CEST) Received: from Polydeuces.office.hd ([169.254.3.194]) by METHONE.office.hd ([192.168.24.54]) with mapi id 14.01.0323.003; Mon, 29 Aug 2011 06:57:51 +0200 From: Juergen Quittek To: IETF IPFIX Working Group Thread-Topic: proposal for IPFIX charter update Thread-Index: AQHMZggzIq+uoU73cUmzabOsxYu6Tw== Date: Mon, 29 Aug 2011 04:57:50 +0000 Message-ID: Accept-Language: de-DE, en-US Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.12.0.110505 x-originating-ip: [10.7.0.92] Content-Type: text/plain; charset="us-ascii" Content-ID: <2A997F7765F9814F8089415F159C2192@office.hd> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [IPFIX] proposal for IPFIX charter update 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, 29 Aug 2011 04:56:55 -0000 Dear all, At our session in Quebec we discussed candidates for new IPFIX work items. Based on this discussion, Nevil and I drafted an update of our charter that you can find below. Please have a look at it and send us your comments. Thanks, Juergen IP Flow Information Export (ipfix) Description of Working Group The IPFIX working group has specified the information model (to describe IP flows) and the IPFIX protocol (to transfer IP flow data from IPFIX exporters to collectors). Several implementers have already built applications using the IPFIX protocol. As a result of a series of IPFIX interoperability testing events the WG has produced guidelines for IPFIX implementation and testing as well as recommendations for handling special cases such as bidirectional flow reporting and reducing redundancy in flow records. The IPFIX WG has developed a mediation framework, that defines IPFIX mediators for processing flow records for various purposes including aggregation, anonymization, etc. For configuring IPFIX devices, a YANG module has been developed. 1. Having a solid standardized base for IPFIX deployment and operation and several exiting implementations, the IPFIX WG will revisit the IPFIX protocol specifications (RFC 5101) and the IPFIX information element specification (RFC 5102) in order to advance them to draft standard. 2. For giving guidelines to developers of new IPFIX information elements and for better defining the process of registering new information elements at IANA the IPFIX WG will create an information element developers guideline document. 3. The export of IPFIX flow records from IPFIX mediators introduces a set of potential issues at the protocol level, such as the loss of information on the original exporter, loss of base time information, loss of original options template information, etc. The IPFIX WG will define common ways to deal with these issues, by specifying guidelines for the use of the IPFIX protocol on IPFIX mediators. 4. For supporting the aggregation of flow records at IPFIX mediators the IPFIX WG will define how to export aggregated flow information using IPFIX. An aggregated flow is essentially an IPFIX flow representing packets from multiple original Flows sharing some set of common properties. 5. The IPFIX WG will investigate the use of the IPFIX protocol for exporting MIB objects, avoiding the need to define new IPFIX information elements for existing management information base objects that are already fully specified. This method requires the specification of new template set and options template sets to allow the export of MIB objects along with IPFIX information elements. 6. The IPFIX MIB module (RFC 5815) defined a way to register packet selector functions at IANA. The WG agreed that another method would be preferable that requires a minor change of RFC 5815. The IPFIX WG will produce a new version of RFC 5815 with small modifications of the IANA actions and DESCRIPTION clauses in the the MIB modules. Oct 2011 Publish draft on guidelines for IE doctors Oct 2011 Publish draft on IPFIX use at mediators Oct 2011 Publish draft on intermediate aggregation Oct 2011 Publish draft on exporting MIB objects Oct 2011 Publish draft on data link IEs Dec 2011 Publish draft revising RFC 5101 Dec 2011 Publish draft revising RFC 5102 Apr 2012 Submit guidelines for IE doctors for publication as Informational BCP RFC Apr 2012 Submit draft on IPFIX use at mediators for publication as Standards track RFC Apr 2012 Submit draft on intermediate aggregation for publication as Standards track RFC Apr 2012 Submit draft on data link IEs for publication as Standards track RFC Apr 2012 Submit draft revising RFC 5101 for publication as Standards track RFC Apr 2012 Submit draft revising RFC 5102 for publication as Standards track RFC Sep 2012 Submit draft on exporting MIB objects for publication as Standards track RFC From trammell@tik.ee.ethz.ch Sun Aug 28 22:33:41 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 165BB21F87E2 for ; Sun, 28 Aug 2011 22:33:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.468 X-Spam-Level: X-Spam-Status: No, score=-6.468 tagged_above=-999 required=5 tests=[AWL=0.131, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] 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 qaeyq13LsQDP for ; Sun, 28 Aug 2011 22:33:40 -0700 (PDT) Received: from smtp.ee.ethz.ch (smtp.ee.ethz.ch [129.132.2.219]) by ietfa.amsl.com (Postfix) with ESMTP id 41F5421F87D9 for ; Sun, 28 Aug 2011 22:33:39 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by smtp.ee.ethz.ch (Postfix) with ESMTP id C489BD9303; Mon, 29 Aug 2011 07:35:02 +0200 (MEST) X-Virus-Scanned: by amavisd-new on smtp.ee.ethz.ch Received: from smtp.ee.ethz.ch ([127.0.0.1]) by localhost (.ee.ethz.ch [127.0.0.1]) (amavisd-new, port 10024) with LMTP id BZO84BXeZFRU; Mon, 29 Aug 2011 07:35:02 +0200 (MEST) Received: from [10.0.1.2] (cust-integra-121-161.antanet.ch [80.75.121.161]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: briant) by smtp.ee.ethz.ch (Postfix) with ESMTPSA id 67073D9302; Mon, 29 Aug 2011 07:35:02 +0200 (MEST) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Brian Trammell In-Reply-To: Date: Mon, 29 Aug 2011 07:34:59 +0200 Content-Transfer-Encoding: 7bit Message-Id: References: To: Juergen Quittek X-Mailer: Apple Mail (2.1084) Cc: IETF IPFIX Working Group Subject: Re: [IPFIX] proposal for IPFIX charter update 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, 29 Aug 2011 05:33:41 -0000 hi, Juergen, all, This charter looks good. Best regards, Brian On Aug 29, 2011, at 6:57 AM, Juergen Quittek wrote: > Dear all, > > At our session in Quebec we discussed candidates > for new IPFIX work items. Based on this discussion, > Nevil and I drafted an update of our charter that > you can find below. > > Please have a look at it and send us your comments. > > Thanks, > > Juergen > > > IP Flow Information Export (ipfix) > > > Description of Working Group > > > The IPFIX working group has specified the information model (to describe > IP flows) and the IPFIX protocol (to transfer IP flow data from IPFIX > exporters to collectors). Several implementers have already built > applications using the IPFIX protocol. As a result of a series of IPFIX > interoperability testing events the WG has produced guidelines for IPFIX > implementation and testing as well as recommendations for handling > special cases such as bidirectional flow reporting and reducing > redundancy in flow records. > > The IPFIX WG has developed a mediation framework, that defines IPFIX > mediators for processing flow records for various purposes including > aggregation, anonymization, etc. For configuring IPFIX devices, a YANG > module has been developed. > > 1. Having a solid standardized base for IPFIX deployment and operation > and several exiting implementations, the IPFIX WG will revisit the IPFIX > protocol specifications (RFC 5101) and the IPFIX information element > specification (RFC 5102) in order to advance them to draft standard. > > 2. For giving guidelines to developers of new IPFIX information > elements and for better defining the process of registering new > information elements at IANA the IPFIX WG will create an information > element developers guideline document. > > 3. The export of IPFIX flow records from IPFIX mediators introduces a > set of potential issues at the protocol level, such as the loss of > information on the original exporter, loss of base time information, > loss of original options template information, etc. The IPFIX WG will > define common ways to deal with these issues, by specifying guidelines > for the use of the IPFIX protocol on IPFIX mediators. > > 4. For supporting the aggregation of flow records at IPFIX mediators > the IPFIX WG will define how to export aggregated flow information using > IPFIX. An aggregated flow is essentially an IPFIX flow representing > packets from multiple original Flows sharing some set of common properties. > > 5. The IPFIX WG will investigate the use of the IPFIX protocol for > exporting > MIB objects, avoiding the need to define new IPFIX information elements > for existing management information base objects that are already fully > specified. This method requires the specification of new template set > and options template sets to allow the export of MIB objects along > with IPFIX information elements. > > 6. The IPFIX MIB module (RFC 5815) defined a way to register packet > selector functions at IANA. The WG agreed that another method would > be preferable that requires a minor change of RFC 5815. The IPFIX WG > will produce a new version of RFC 5815 with small modifications of > the IANA actions and DESCRIPTION clauses in the the MIB modules. > > Oct 2011 Publish draft on guidelines for IE doctors > Oct 2011 Publish draft on IPFIX use at mediators > Oct 2011 Publish draft on intermediate aggregation > Oct 2011 Publish draft on exporting MIB objects > Oct 2011 Publish draft on data link IEs > Dec 2011 Publish draft revising RFC 5101 > Dec 2011 Publish draft revising RFC 5102 > > Apr 2012 Submit guidelines for IE doctors for publication as > Informational BCP RFC > Apr 2012 Submit draft on IPFIX use at mediators for publication as > Standards track RFC > Apr 2012 Submit draft on intermediate aggregation for publication as > Standards track RFC > Apr 2012 Submit draft on data link IEs for publication as Standards > track RFC > Apr 2012 Submit draft revising RFC 5101 for publication as Standards > track RFC > Apr 2012 Submit draft revising RFC 5102 for publication as Standards > track RFC > Sep 2012 Submit draft on exporting MIB objects for publication as > Standards track RFC > > > _______________________________________________ > IPFIX mailing list > IPFIX@ietf.org > https://www.ietf.org/mailman/listinfo/ipfix From dromasca@avaya.com Mon Aug 29 01:19:05 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 F03D021F85B9 for ; Mon, 29 Aug 2011 01:19:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.904 X-Spam-Level: X-Spam-Status: No, score=-102.904 tagged_above=-999 required=5 tests=[AWL=-0.305, 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 IXWQ2TDvb3bc for ; Mon, 29 Aug 2011 01:19:04 -0700 (PDT) Received: from p-us1-iereast-outbound.us1.avaya.com (p-us1-iereast-outbound.us1.avaya.com [135.11.29.13]) by ietfa.amsl.com (Postfix) with ESMTP id 1905F21F856A for ; Mon, 29 Aug 2011 01:19:03 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ArAAAA9LW07GmAcF/2dsb2JhbABCmBqPXneBQAEBAQEDAQEBDx4KNBcEAgEIDQQEAQELBgwLAQYBJh8JCAIEAQkJCBqHVJpFApsuhWxgBJhLi1o X-IronPort-AV: E=Sophos;i="4.68,296,1312171200"; d="scan'208";a="204497011" Received: from unknown (HELO co300216-co-erhwest.avaya.com) ([198.152.7.5]) by p-us1-iereast-outbound.us1.avaya.com with ESMTP; 29 Aug 2011 04:20:26 -0400 Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.14]) by co300216-co-erhwest-out.avaya.com with ESMTP; 29 Aug 2011 04:16:11 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Mon, 29 Aug 2011 10:20:23 +0200 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [IPFIX] proposal for IPFIX charter update Thread-Index: AQHMZggzIq+uoU73cUmzabOsxYu6T5Uze7rA References: From: "Romascanu, Dan (Dan)" To: "Juergen Quittek" , "IETF IPFIX Working Group" Subject: Re: [IPFIX] proposal for IPFIX charter update 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, 29 Aug 2011 08:19:05 -0000 Editorial comments:=20 s/exiting implementations/existing implementations/ s/For giving guidelines/In order to provide guidelines/ s/For supporting the aggregation/In order to support the aggregation/ s/ the the MIB modules/the MIB modules/ s/draft/Internet-Draft/ (several times in the milestones) Regards, Dan > -----Original Message----- > From: ipfix-bounces@ietf.org [mailto:ipfix-bounces@ietf.org] On Behalf > Of Juergen Quittek > Sent: Monday, August 29, 2011 7:58 AM > To: IETF IPFIX Working Group > Subject: [IPFIX] proposal for IPFIX charter update >=20 > Dear all, >=20 > At our session in Quebec we discussed candidates > for new IPFIX work items. Based on this discussion, > Nevil and I drafted an update of our charter that > you can find below. >=20 > Please have a look at it and send us your comments. >=20 > Thanks, >=20 > Juergen >=20 >=20 > IP Flow Information Export (ipfix) >=20 >=20 > Description of Working Group >=20 >=20 > The IPFIX working group has specified the information model (to > describe > IP flows) and the IPFIX protocol (to transfer IP flow data from IPFIX > exporters to collectors). Several implementers have already built > applications using the IPFIX protocol. As a result of a series of IPFIX > interoperability testing events the WG has produced guidelines for > IPFIX > implementation and testing as well as recommendations for handling > special cases such as bidirectional flow reporting and reducing > redundancy in flow records. >=20 > The IPFIX WG has developed a mediation framework, that defines IPFIX > mediators for processing flow records for various purposes including > aggregation, anonymization, etc. For configuring IPFIX devices, a YANG > module has been developed. >=20 > 1. Having a solid standardized base for IPFIX deployment and operation > and several exiting implementations, the IPFIX WG will revisit the > IPFIX > protocol specifications (RFC 5101) and the IPFIX information element > specification (RFC 5102) in order to advance them to draft standard. >=20 > 2. For giving guidelines to developers of new IPFIX information > elements and for better defining the process of registering new > information elements at IANA the IPFIX WG will create an information > element developers guideline document. >=20 > 3. The export of IPFIX flow records from IPFIX mediators introduces a > set of potential issues at the protocol level, such as the loss of > information on the original exporter, loss of base time information, > loss of original options template information, etc. The IPFIX WG will > define common ways to deal with these issues, by specifying guidelines > for the use of the IPFIX protocol on IPFIX mediators. >=20 > 4. For supporting the aggregation of flow records at IPFIX mediators > the IPFIX WG will define how to export aggregated flow information > using > IPFIX. An aggregated flow is essentially an IPFIX flow representing > packets from multiple original Flows sharing some set of common > properties. >=20 > 5. The IPFIX WG will investigate the use of the IPFIX protocol for > exporting > MIB objects, avoiding the need to define new IPFIX information elements > for existing management information base objects that are already fully > specified. This method requires the specification of new template set > and options template sets to allow the export of MIB objects along > with IPFIX information elements. >=20 > 6. The IPFIX MIB module (RFC 5815) defined a way to register packet > selector functions at IANA. The WG agreed that another method would > be preferable that requires a minor change of RFC 5815. The IPFIX WG > will produce a new version of RFC 5815 with small modifications of > the IANA actions and DESCRIPTION clauses in the the MIB modules. >=20 > Oct 2011 Publish draft on guidelines for IE doctors > Oct 2011 Publish draft on IPFIX use at mediators > Oct 2011 Publish draft on intermediate aggregation > Oct 2011 Publish draft on exporting MIB objects > Oct 2011 Publish draft on data link IEs > Dec 2011 Publish draft revising RFC 5101 > Dec 2011 Publish draft revising RFC 5102 >=20 > Apr 2012 Submit guidelines for IE doctors for publication as > Informational BCP RFC > Apr 2012 Submit draft on IPFIX use at mediators for publication as > Standards track RFC > Apr 2012 Submit draft on intermediate aggregation for publication as > Standards track RFC > Apr 2012 Submit draft on data link IEs for publication as Standards > track RFC > Apr 2012 Submit draft revising RFC 5101 for publication as Standards > track RFC > Apr 2012 Submit draft revising RFC 5102 for publication as Standards > track RFC > Sep 2012 Submit draft on exporting MIB objects for publication as > Standards track RFC >=20 >=20 > _______________________________________________ > IPFIX mailing list > IPFIX@ietf.org > https://www.ietf.org/mailman/listinfo/ipfix