From akoba@nttv6.net Wed Dec 2 08:24:37 2009 Return-Path: X-Original-To: ipfix@core3.amsl.com Delivered-To: ipfix@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A5F3328C21A for ; Wed, 2 Dec 2009 08:24:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.801 X-Spam-Level: X-Spam-Status: No, score=-1.801 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, GB_I_LETTER=-2, NO_RELAYS=-0.001, SUBJ_RE_NUM=2.799] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JnFIdQAJT1ai for ; Wed, 2 Dec 2009 08:24:35 -0800 (PST) Received: from mail.nttv6.net (mail.nttv6.net [IPv6:2001:fa8::25]) by core3.amsl.com (Postfix) with ESMTP id F10D928C1FC for ; Wed, 2 Dec 2009 08:24:33 -0800 (PST) Received: from [10.10.10.20] ([IPv6:2001:fa8:1000:0:c5f8:bc69:93a2:f1bf]) by mail.nttv6.net (8.14.3/8.14.3) with ESMTP id nB2GOO0C051190; Thu, 3 Dec 2009 01:24:24 +0900 (JST) (envelope-from akoba@nttv6.net) Date: Thu, 03 Dec 2009 01:13:04 +0900 From: Atsushi Kobayashi To: Gerhard Muenz In-Reply-To: <4AFF2FD0.7020704@net.in.tum.de> References: <20091110090506.659C.17391CF2@nttv6.net> <4AFF2FD0.7020704@net.in.tum.de> Message-Id: <20091202183004.4786.17391CF2@nttv6.net> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Becky! ver. 2.50.05 [ja] (Unregistered) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.3 (mail.nttv6.net [IPv6:2001:fa8::25]); Thu, 03 Dec 2009 01:24:24 +0900 (JST) Cc: IETF IPFIX Working Group Subject: Re: [IPFIX] WG last call on draft-ietf-ipfix-mediators-problem-statement-06 X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Dec 2009 16:24:37 -0000 Hi Gerhard, and all, Sorry for late reply. I have missed this mail till now. On Sat, 14 Nov 2009 23:31:44 +0100 Gerhard Muenz wrote: > > Hi Atsushi, > > comments inline. > > Regards, > Gerhard > > Atsushi Kobayashi wrote: > > Hi Gerhard, > > snip > >> > >> BTW, I would be careful with terms like "optimize" and "optimization". > >> > > > > I will change it as follows. Could you please rewrite it by your word, > > if not fine. > > As I do not know what you want to say, it is difficult for me to rewrite > it in my own words. > > > > > 1. Introduction > > > > One advantage of Flow-based measurement results from easily offering > > the traffic monitoring of a huge amount of traffic. While the usage > > is applied to any networks and to multiple measurement applications, > > You could start like this: > > An advantage of Flow-based measurement is that it allows monitoring hugh > amounts of traffic observed at distributed observation points. > Flow-based measurement may serve various purposes and applications with > very different requirements. > > > network administrators need to adjust some parameters of metering > > devices and of multiple measurement applications to these resources. > > I do not understand this semi-phrase. What do you mean by "to these > resources"? > They point to CPU powers or memories on Exporter/Collecotor. > > IP traffic growth and a wide variety of measurement application make > > the adjustment further difficult. To make a measurement system > > Why is it more difficult to adjust parameters in the presence of IP > traffic growth? > In the first sentence, you write that Flow-based measurement can monitor > huge amounts of traffic, so traffic growth should not be a problem. So, I mean that it is difficult to catch up the performance extension for Collector/Exporter side according to the increase of IP traffic growth. > > > flexible and scalable, an intermediate device can generally be > > applied to the system platform. > > Maybe you can discuss and clarify this paragraph with your co-authors. > I can hardly guess what the reasoning is supposed to be. > Could you please check the following paragraph, once more? 1. Introduction An advantage of flow-based measurement is that it allows monitoring large amount of traffic observed at distributed observation points. While flow-based measurement can be applied to one of various purposes and applications, it is difficult for flow-based measurement to apply to multiple applications with very different requirements in parallel. Network administrators need to adjust some parameters of metering devices according to the most severe one of requirements of multiple measurement applications within measurement system performance and capacity. IP traffic growth consuming furthermore measurement system capacity make it further difficult to keep the adjustment. To make a measurement system flexible and scalable, an intermediate device can generally be applied to the system. > > > >>> The IPFIX requirements defined in [RFC3917] mention examples of > >>> intermediate devices, such as IPFIX Proxies or Concentrators, there > >> missing conjunction, such as "but", "yet", or something like that > >> > >> The term "intermediate" or "intermediate device" does not appear in > >> RFC3917. So, explain why you call these devices like this. > >> (For example, because they are located between Exporters and Collectors.) > > > > Is it OK? > > > > The IPFIX requirements defined in [RFC3917] mention examples of > > intermediate devices located between Exporters and Collectors, such > > as IPFIX proxies or concentrators. But, there are no documents > > defining a generalized concept for such intermediate devices. This > > ok. > > > > >>> are no documents defining a generalized concept for such intermediate > >>> devices. This document addresses that issue by defining IPFIX > >>> Mediation, a generalized intermediate device concept for IPFIX, and > >>> examining in detail the motivations behind its application. > >>> > >>> This document is structured as follows: section 2 describes the > >>> terminology used in this document, section 3 gives an IPFIX/PSAMP > >>> document overview, section 4 introduces general problems related to > >>> flow-based measurement, section 5 describes some applicability > >>> examples where IPFIX Mediations would be beneficial, and, finally, > >>> section 6 describes some problems an IPFIX Mediation implementation > >>> might face. > >> > >>> 2. Terminology and Definitions > >>> > >>> The IPFIX-specific and PSAMP-specific terminology used in this > >>> document is defined in [RFC5101] and [RFC5476], respectively. In > >>> this document, as in [RFC5101] and [RFC5476], 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 use the generic term "record stream" to denote a > >> I would not call "record stream" a "term" unless it appears in the list > >> below with capitalized first letter. > >> > >>> set of flow- or packet-based data records with their additional > >> I would not say that the records are flow-based or packet-based. They > >> contain flow or packet information. > >> > > > > Actually, I am not sure how to say that. > > It seems hard to include "record stream" in capitalized terms, because > > it covers everything, such as IPFIX Flow Record, PSAMP Packet Record, NF > > flow record, and something else. Could you put your suggestion? > > > > Is the following paragraph fine? > > > > In this document, we use "record stream" to denote a set of flow- or > > packet-based information with their additional information that flows > > from data sources, whether encoded in IPFIX protocol as IPFIX Data > > Records, or non-IPFIX protocols. In IPFIX protocol, we use the > > generic term Data Records for IPFIX Flow Records, PSAMP Packet > > Reports, and Data Records defined by Options Templates, unless an > > explicit distinction is required. > > What about: > > 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 Records in any other format. > Ok, Thanks. > >>> information that flows from data sources, whether encoded in IPFIX > >>> protocol as IPFIX Data Records, or non-IPFIX protocols. In IPFIX > >>> protocol, we use the generic term Data Records for IPFIX Flow > >>> Records, PSAMP Packet Reports, and Data Records defined by Options > >>> Templates, unless an explicit distinction is required. > >> Do we need the last sentence? > > > > I think Yes. It indicates the usage of term Data Records to prevent > > readers from confusing it with IPFIX Flow Record and PSAMP packet report. > > I think the contrary. This sentence may confuse the reader. > > "In IPFIX protocol" is wrong because the "PSAMP Packet Report" does not > appear in RFC5101. > Therefore, it seems that you redefine the term Data Record, also this is > not what you want to do. > > If you really think that the sentence is necessary, maybe you like this: > "Note that the term Data Records comprises IPFIX Flow Records, PSAMP > Packet Reports, and Data Records defined by Options Templates." > > BTW: In IPFIX-CONFIG, I also use this term in the same way without > providing any further explanation. > Ok, I follows your draft way. > > >>> Original Exporter > >>> > >>> An Original Exporter is an IPFIX Device that hosts the Observation > >>> Points where the metered IP packets are observed. > >>> snip > >>> > >>> 4.4. Summary > >>> > >>> In optimizing the resources of a measurement system, it is important > >> I still do not understand what "optimize the resources" is supposed to mean. > >> > > > > I will change it as follows. > > > > 4.4. Summary > > > > In adjusting some parameters to the resources of a measurement > > system, it is important to use traffic data reduction techniques as > > early as possible, e.g., at the Exporter. However, this > > I do not understand. Maybe you want to say: > > Due to resource limitations of the measurement system, it is important to... > > > implementation is made difficult by heterogeneous environment of > > exporting devices to meet the requirements of different monitoring > > applications. > > > > > >>> to use traffic data reduction techniques as early as possible, e.g., > >>> at the Exporter. However, this implementation is made difficult by > >>> heterogeneous environment of exporting devices. > >> Please revise the entire paragraph above. It only talks about data > >> reduction. I do not think that this is the core of mediation. > >> > > No. It imply the distribution of traffic data in heterogeneous > > enviroment. Please suggest your idea. > > The summary covers 4.1 and 4.3. I miss the problem mentioned in 4.2. > Coukd you please see it. 4.4. Summary Due to resource limitations of the measurement system, it is important to use traffic data reduction techniques as early as possible, e.g., at the Exporter. (4.1) However, this implementation is made difficult by heterogeneous environment of exporting devices.(4.2) On the other hand, keeping data accuracy and flow granularity to meet the requirements of different monitoring applications requires a scalable and flexible collecting infrastructure.(4.3) Is it OK? > > > >>> This implies that a new Mediation function is required in typical > >>> Exporter-Collector architectures. Based on some applicability > >>> examples, the next section shows the limitation of the typical > >>> Exporter-Collector architecture model and the IPFIX Mediation > >>> benefits. > >> > >>> 5. Mediation Applicability Examples > >>> > >>> 5.1. Adjusting Flow Granularity > >>> > >>> A set of common properties of simplest Flow type is a fixed 5-tuple > >>> of protocol, source and destination IP addresses, and source and > >> As you talk about "Flow Keys", you should use this term and not invent a > >> new one! > > > > Actually, when I started to write this subsection, it implied covering > > IPFIX and NetFlow. > > > > I will change subsection as follows. > > > > 5.1. Adjusting Flow Granularity > > > > A simplest set Flow Keys is a fixed 5-tuple of protocol, source and > > destination IP addresses, and source and destination port numbers. A > > shorter set of Flow Keys, such as a triple, a double, or a single > > property, (for example network prefix, peering autonomous system > > number, or BGP Next-Hop fields), creates more aggregated Flow > > Records. This is especially useful for measuring router-level > > traffic matrices in a core network domain and for easily adjusting > > the performance of Exporters and Collectors. > > > > Implementation analysis: > > > > Implementations for this case depend on where Flow granularity is > > adjusted. More suitable implementations use configurable Metering > > Processes in Original Exporters. The cache in the Metering > > Process can specify its own set of Flow Keys and extra fields. > > The Original Exporter thus generates Flow Records of the desired > > Flow granularity. > > > > In the case where a Metering Process hosting no ability to change > > the Flow Keys in Original Exporter creates Flow Records, or PSAMP > > Packet Reports, an IPFIX Mediator can aggregate Data Records based > > on a new set of Flow Keys. Even in the case where the Metering > > Even in the case of a Metering Process... > Ok. Thanks. > > Process hosting this ability, an IPFIX Mediator can further > > aggregate the Flow Records. > > fine. > snip > >>> > >>> 5.2. Hierarchical Collecting Infrastructure > >>> > >>> The increase of IPFIX Exporters, the increase of the traffic, and the > > increasing number of exporters? > Yes. Increasing number of IPFIX Exporters, amount of IP traffic, and variety of treatments expected to be performed on the Data Records is more and more difficult to handle within a single Collector. > >>> variety of treatments expected to be performed over the Data Records > >> over => on > >> > > Ok. > > > >>> is more and more difficult to handle within a single Collector. > >>> Hence to increase the collecting (e.g., the bandwidth capacity) and > >>> processing capacity, distributed Collectors must be deployed. As a > >>> possible approach, a hierarchical structure is useful for increasing > >> I don't understand how the collecting and processing capacity increases > >> thanks to a hierarchical structure. > >> > >> The capacity increases because I implement more resources in the > >> network, e.g. more Collectors. > > > > Although increasing number of Collectors operated independently makes it > > more capacity, we cannot measure the all of amount of traffic data. > > Still not sure what you mean. > The original exporter measures traffic, not the collector. > If you cannot measure all the traffic, you need more powerful routers. Actually, if there is the capacity limitation in Exporter, as you say, powerful exporter would be necessary. It is so apparent to go without saying. > > IMO, the hierarchy is useful to gather data which has been collected at > different places in the network. But the hierarchy is not needed to > deploy distributed collectors. > Ok, I will change the section title as "Collecting Infrastructure". And, I will change whole subsection as follows. 5.2. Collecting Infrastructure Increasing number of IPFIX Exporters, amount of IP traffic, and the variety of treatments expected to be performed on the Data Records is more and more difficult to handle within a single Collector. Implementation analysis: To increase the collecting (e.g., the bandwidth capacity) and processing capacity, distributed Collectors close to Exporters need to be deployed. In such a case, those Collectors would become IPFIX Mediators, re-exporting Data Records on demand to centralized applications. To cope with the variety of treatments, one possible implementation uses an Intermediate Process deciding to which Collector(s) to export each record. More specific cases are described in section 5.9. > >>> the measurement systems capacity, both in export bandwidth capacity > >>> and in collecting capacity. > >>> > >>> Implementation analysis: > >>> > >>> To cope with the increase of IPFIX Exporters and traffic, one > >> "number of IPFIX Exporters" (only IPFIX?) > > Ok. > > > >>> possible implementation uses IPFIX Concentrators to build a > >>> hierarchical collection system. To cope with the variety of > >>> treatments, one possible implementation uses IPFIX Distributors to > >>> build a distributed collection system. More specific cases are > >>> described in section 5.9. > >> snip > >>> > >>> 5.6. Data Record Anonymization > >>> > >>> IPFIX exports across administrative domains can be used to measure > >>> traffic for wide-area traffic engineering or to analyze Internet > >>> traffic trends, as described in the spatial composition across > >>> administrative domains in the previous subsection. > >>> In such a case, administrators need to adhere to privacy protection > >>> policies and prevent access to confidential traffic measurements by > >>> other people. Typically, anonymization techniques enables the > >> enable > >> > > Yes. > > > >>> provision of traffic data to other people without violating these > >>> policies. > >>> > >>> Generally, anonymization modifies a data set to protect the identity > >>> of the people or entities described by the data set from being > >>> disclosed. It also attempts to preserve sets of network traffic > >>> properties useful for a given analysis while ensuring the data cannot > >>> be traced back to the specific networks, hosts, or users generating > >>> the traffic. For example, IP address anonymization is particularly > >>> important for avoiding the identification of the users, hosts, and > >> remove second "the" > >> > > Yes. > > > >>> routers. As another example, when ISP provides a traffic monitoring > >> an ISP > >> > > Yes. > > > >>> service to end customers by their own Exporters, even in case of > >>> exporting interface index fields, network administrators take care of > >>> anonymizing its fields to avoid disclosing the vulnerability. > >> Why does an interface represent a vulnerability? > >> > > > > Interface indexes assignment policies in several vendors are different. > > Some vender indexes show upper bytes indicating line card, lower byte > > indicating interfaces. > > By recognizing its policy, we can presume the vendors of Exporter. > > Ok. But I would not say that disclosing an interface index automatically > discloses a vulnerability. > > "vulnerability" => "information" Ok. I will change as follows. As another example, when an ISP provides a traffic monitoring service to end customers by their own Exporters, even in case of exporting interface index fields, network administrators take care of anonymizing its fields to avoid from identifying vendor or software version by disclosing the information. > > > > >>> Implementation analysis: > >>> > >>> One possible implementation for this case uses an anonymization > >>> function at the Original Exporter. However, this increases the > >>> load on the Original Exporter. A more flexible implementation > >>> uses a separate IPFIX Masquerading Proxy between the Original > >>> Exporter and Collector. > >> > >> > >> snip > >>> > >>> 7. Summary and Conclusion > >>> > >>> This document described the problems that network administrators have > >>> been facing, the applicability of IPFIX Mediation to these problems, > >>> and the problems related to the implementation of IPFIX Mediators. > >>> To assist the operations of the Exporters and Collectors, there are > >>> various IPFIX Mediations from which the administrators may select. > >>> Examples of the applicability of IPFIX Mediation are as follows. > >>> > >>> o Regarding large-scale measurement system, IPFIX Concentrators or > >>> IPFIX Distributors help to achieve traffic analysis with high data > >>> accuracy and fine flow granularity even as IP traffic grows. As > >>> IPFIX Mediation capabilities, Flow sampling, aggregation, and > >>> composition are effective. > >> Sampling and aggregation reduce the accuracy or granularity. > >> Correlation seems to be appropriate. > >> > > > > I means as follows. > > > > o Regarding large-scale measurement system, IPFIX Mediator with > > IPFIX File Writer helps to achieve traffic analysis with high data > > accuracy and fine flow granularity even as IP traffic grows. As > > IPFIX Mediation capabilities, Flow sampling, aggregation, and > > composition are effective. > > Flow sampling => Flow selection ? > > > > >>> o Regarding data retention, IPFIX Mediators enhance the export > >>> reliability, and the storage of the measurement system. > >>> > >>> o Regarding the distribution of Data Records, IPFIX Distributors > >>> help to achieve multipurpose traffic analysis for different > >>> organizations, or help to achieve respective traffic analysis > >> remove "respective"? > >> > > Ok. > > > >>> based on Data Record types(IPv4, IPv6, MPLS, and VPN). > >>> > >>> o Regarding the IPFIX export across domains, IPFIX Masquerading > >>> Proxies help administrators to anonymize or filter Data Records, > >>> preventing privacy violations. > >>> > >>> o Regarding interoperability, IPFIX Proxies provide interoperability > >>> between legacy protocols and IPFIX, even during the migration > >> even => for example > > Ok. > > > >>> period to IPFIX. > >>> > >>> As a result, the IPFIX Mediation benefits become apparent. However, > >>> there are still some open issues with the use of IPFIX Mediators. > >>> > >>> o Both Observation Point and IPFIX Message header information, such > >>> as the Exporter IP address, Observation Domain ID, and Export Time > >>> field, might be lost. This data should therefore be communicated > >>> between the Original Exporter and Collector via the IPFIX > >>> Mediator. > >>> > >>> o IPFIX Mediators are required to manage Transport Sessions, > >>> Template IDs, and Observation Domain IDs. Otherwise, anomalous > >>> IPFIX Messages could be created. > >>> > >>> o Data Records defined by Options Templates, such as those reporting > >>> the Sampling rate and Sampling algorithm used, might be lost > >>> during IPFIX Mediation. If a Collector is not informed of current > >>> Sampling rates, traffic information might become worthless. > >>> > >>> These problems stem from the fact that no standards regarding IPFIX > >>> Mediation have been set. In particular, the minimum set of > >>> information that should be communicated between Original Exporters > >>> and Collectors, the management between different IPFIX Transport > >>> Sessions, and the internal components of IPFIX Mediators should be > >>> standardized. > >> > >> There is a lot of repetition in this section. > >> > > > > You means this section should be removed. > > If it just repeats what has already been set, then probably yes. > I will furthermore summarise the section as follows. 7. Summary and Conclusion This document described the problems that network administrators have been facing, the applicability of IPFIX Mediation to these problems, and the problems related to the implementation of IPFIX Mediators. To assist the operations of the Exporters and Collectors, this document demonstrates there are various IPFIX Mediations from which the administrators may select. However, there are still some open issues with the use of IPFIX Mediators. These issues stem from the fact that no standards regarding IPFIX Mediation have been set. In particular, the minimum set of information that should be communicated between Original Exporters and Collectors, the management between different IPFIX Transport Sessions, and the internal components of IPFIX Mediators should be standardized. Regards, Atsushi From muenz@net.in.tum.de Thu Dec 3 01:08:19 2009 Return-Path: X-Original-To: ipfix@core3.amsl.com Delivered-To: ipfix@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 82AD73A68AD for ; Thu, 3 Dec 2009 01:08:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.249 X-Spam-Level: X-Spam-Status: No, score=-4.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, GB_I_LETTER=-2, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4NYDyQl515bI for ; Thu, 3 Dec 2009 01:08:17 -0800 (PST) Received: from mail-out1.informatik.tu-muenchen.de (mail-out1.informatik.tu-muenchen.de [131.159.0.8]) by core3.amsl.com (Postfix) with ESMTP id B48B528C136 for ; Thu, 3 Dec 2009 01:08:16 -0800 (PST) Received: from phoenix.net.informatik.tu-muenchen.de (phoenix.net.in.tum.de [131.159.14.1]) by services.net.informatik.tu-muenchen.de (Postix Mailer @ mail) with ESMTP id A44F847BD3; Thu, 3 Dec 2009 10:08:06 +0100 (CET) Received: from [131.159.20.108] (unknown [131.159.20.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by phoenix.net.informatik.tu-muenchen.de (Postfix) with ESMTP id 8B822A20; Thu, 3 Dec 2009 10:08:06 +0100 (CET) Message-ID: <4B178052.9020600@net.in.tum.de> Date: Thu, 03 Dec 2009 10:09:38 +0100 From: Gerhard Muenz User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Atsushi Kobayashi References: <20091110090506.659C.17391CF2@nttv6.net> <4AFF2FD0.7020704@net.in.tum.de> <20091202183004.4786.17391CF2@nttv6.net> In-Reply-To: <20091202183004.4786.17391CF2@nttv6.net> Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms040708030000050609060306" X-Virus-Scanned: ClamAV using ClamSMTP Cc: IETF IPFIX Working Group Subject: Re: [IPFIX] WG last call on draft-ietf-ipfix-mediators-problem-statement-06 X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Dec 2009 09:08:19 -0000 This is a cryptographically signed message in MIME format. --------------ms040708030000050609060306 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable Hi Atsushi, comments and improvements inline. Regards, Gerhard Atsushi Kobayashi wrote: > Hi Gerhard, and all, >=20 > Sorry for late reply. I have missed this mail till now. >=20 > On Sat, 14 Nov 2009 23:31:44 +0100 > Gerhard Muenz wrote: >=20 >> Hi Atsushi, >> >> comments inline. >> >> Regards, >> Gerhard >> >> Atsushi Kobayashi wrote: >>> Hi Gerhard, >>> > snip >=20 >>>> BTW, I would be careful with terms like "optimize" and "optimization= ". >>>> >>> I will change it as follows. Could you please rewrite it by your word= , >>> if not fine. >> As I do not know what you want to say, it is difficult for me to rewri= te >> it in my own words. >> >>> 1. Introduction >>> >>> One advantage of Flow-based measurement results from easily offeri= ng >>> the traffic monitoring of a huge amount of traffic. While the usa= ge >>> is applied to any networks and to multiple measurement application= s, >> You could start like this: >> >> An advantage of Flow-based measurement is that it allows monitoring hu= gh >> amounts of traffic observed at distributed observation points. >> Flow-based measurement may serve various purposes and applications wit= h >> very different requirements. >> >>> network administrators need to adjust some parameters of metering >>> devices and of multiple measurement applications to these resource= s. >> I do not understand this semi-phrase. What do you mean by "to these >> resources"? >> >=20 > They point to CPU powers or memories on Exporter/Collecotor. >=20 >=20 >>> IP traffic growth and a wide variety of measurement application ma= ke >>> the adjustment further difficult. To make a measurement system >> Why is it more difficult to adjust parameters in the presence of IP >> traffic growth? >> In the first sentence, you write that Flow-based measurement can monit= or >> huge amounts of traffic, so traffic growth should not be a problem. >=20 > So, I mean that it is difficult to catch up the performance extension > for Collector/Exporter side according to the increase of IP traffic > growth. >>> flexible and scalable, an intermediate device can generally be >>> applied to the system platform. >> Maybe you can discuss and clarify this paragraph with your co-authors.= >> I can hardly guess what the reasoning is supposed to be. >> > Could you please check the following paragraph, once more? >=20 > 1. Introduction >=20 > An advantage of flow-based measurement is that it allows monitoring > large amount of traffic observed at distributed observation points. > While flow-based measurement can be applied to one of various > purposes and applications, it is difficult for flow-based measuremen= t > to apply to multiple applications with very different requirements i= n > parallel. Network administrators need to adjust some parameters of > metering devices according to the most severe one of requirements of= > multiple measurement applications within measurement system > performance and capacity. IP traffic growth consuming furthermore > measurement system capacity make it further difficult to keep the > adjustment. To make a measurement system flexible and scalable, an= > intermediate device can generally be applied to the system. - What about the following: Network administrators need to adjust the parameters of the metering devices to fulfill the requirements of every single measurement application. Such configurations are often not supported by the metering devices, either because of functional restrictions or because of limited computational and memory resources, which inhibit the metering of large amounts of traffic with the desired setup. IPFIX Mediation fills the gap between restricted metering capabilities and the requirements of measurement applications by introducing an intermediate device called IPFIX Mediator. >=20 >=20 >>>>> The IPFIX requirements defined in [RFC3917] mention examples of >>>>> intermediate devices, such as IPFIX Proxies or Concentrators, th= ere >>>> missing conjunction, such as "but", "yet", or something like that >>>> >>>> The term "intermediate" or "intermediate device" does not appear in = >>>> RFC3917. So, explain why you call these devices like this. >>>> (For example, because they are located between Exporters and Collect= ors.) >>> Is it OK? >>> >>> The IPFIX requirements defined in [RFC3917] mention examples of >>> intermediate devices located between Exporters and Collectors, suc= h >>> as IPFIX proxies or concentrators. But, there are no documents >>> defining a generalized concept for such intermediate devices. Thi= s >> ok. >> >>>>> are no documents defining a generalized concept for such interme= diate >>>>> devices. This document addresses that issue by defining IPFIX >>>>> Mediation, a generalized intermediate device concept for IPFIX, = and >>>>> examining in detail the motivations behind its application. >>>>> >>>>> This document is structured as follows: section 2 describes the >>>>> terminology used in this document, section 3 gives an IPFIX/PSAM= P >>>>> document overview, section 4 introduces general problems related= to >>>>> flow-based measurement, section 5 describes some applicability >>>>> examples where IPFIX Mediations would be beneficial, and, finall= y, >>>>> section 6 describes some problems an IPFIX Mediation implementat= ion >>>>> might face. >>>>> 2. Terminology and Definitions >>>>> >>>>> The IPFIX-specific and PSAMP-specific terminology used in this >>>>> document is defined in [RFC5101] and [RFC5476], respectively. I= n >>>>> this document, as in [RFC5101] and [RFC5476], the first letter o= f >>>>> each IPFIX-specific and PSAMP-specific term is capitalized along= with >>>>> the IPFIX Mediation-specific term defined here. >>>>> >>>>> In this document, we use the generic term "record stream" to den= ote a >>>> I would not call "record stream" a "term" unless it appears in the l= ist=20 >>>> below with capitalized first letter. >>>> >>>>> set of flow- or packet-based data records with their additional >>>> I would not say that the records are flow-based or packet-based. The= y=20 >>>> contain flow or packet information. >>>> >>> Actually, I am not sure how to say that. >>> It seems hard to include "record stream" in capitalized terms, becaus= e >>> it covers everything, such as IPFIX Flow Record, PSAMP Packet Record,= NF >>> flow record, and something else. Could you put your suggestion? >>> >>> Is the following paragraph fine? >>> >>> In this document, we use "record stream" to denote a set of flow- = or >>> packet-based information with their additional information that fl= ows >>> from data sources, whether encoded in IPFIX protocol as IPFIX Data= >>> Records, or non-IPFIX protocols. In IPFIX protocol, we use the >>> generic term Data Records for IPFIX Flow Records, PSAMP Packet >>> Reports, and Data Records defined by Options Templates, unless an >>> explicit distinction is required. >> What about: >> >> 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 Records in any other format. >> >=20 > Ok, Thanks. >=20 >=20 >>>>> information that flows from data sources, whether encoded in IPF= IX >>>>> protocol as IPFIX Data Records, or non-IPFIX protocols. In IPFI= X >>>>> protocol, we use the generic term Data Records for IPFIX Flow >>>>> Records, PSAMP Packet Reports, and Data Records defined by Optio= ns >>>>> Templates, unless an explicit distinction is required. >>>> Do we need the last sentence? >>> I think Yes. It indicates the usage of term Data Records to prevent >>> readers from confusing it with IPFIX Flow Record and PSAMP packet rep= ort. >> I think the contrary. This sentence may confuse the reader. >> >> "In IPFIX protocol" is wrong because the "PSAMP Packet Report" does no= t >> appear in RFC5101. >> Therefore, it seems that you redefine the term Data Record, also this = is >> not what you want to do. >> >> If you really think that the sentence is necessary, maybe you like thi= s: >> "Note that the term Data Records comprises IPFIX Flow Records, PSAMP >> Packet Reports, and Data Records defined by Options Templates." >> >> BTW: In IPFIX-CONFIG, I also use this term in the same way without >> providing any further explanation. >> > Ok, I follows your draft way. >=20 >>>>> Original Exporter >>>>> >>>>> An Original Exporter is an IPFIX Device that hosts the Observ= ation >>>>> Points where the metered IP packets are observed. >>>>> >=20 > snip >=20 >>>>> 4.4. Summary >>>>> >>>>> In optimizing the resources of a measurement system, it is impor= tant >>>> I still do not understand what "optimize the resources" is supposed = to mean. >>>> >>> I will change it as follows. >>> >>> 4.4. Summary >>> >>> In adjusting some parameters to the resources of a measurement >>> system, it is important to use traffic data reduction techniques a= s >>> early as possible, e.g., at the Exporter. However, this >> I do not understand. Maybe you want to say: >> >> Due to resource limitations of the measurement system, it is important= to... >> >>> implementation is made difficult by heterogeneous environment of >>> exporting devices to meet the requirements of different monitoring= >>> applications. >>> >>> >>>>> to use traffic data reduction techniques as early as possible, e= =2Eg., >>>>> at the Exporter. However, this implementation is made difficult= by >>>>> heterogeneous environment of exporting devices. >>>> Please revise the entire paragraph above. It only talks about data=20 >>>> reduction. I do not think that this is the core of mediation. >>>> >>> No. It imply the distribution of traffic data in heterogeneous >>> enviroment. Please suggest your idea. >> The summary covers 4.1 and 4.3. I miss the problem mentioned in 4.2. >> >=20 > Coukd you please see it. >=20 > 4.4. Summary >=20 > Due to resource limitations of the measurement system, it is > important to use traffic data reduction techniques as early as > possible, e.g., at the Exporter. (4.1)=20 > However, this implementation is made difficult by heterogeneous > environment of exporting devices.(4.2) On the other hand, keeping > data accuracy and flow granularity to meet the requirements of > different monitoring applications requires a scalable and flexible > collecting infrastructure.(4.3) >=20 > Is it OK? - Have you switched 4.2 and 4.3? - I would remove (4.*) in the text above. >>>>> This implies that a new Mediation function is required in typica= l >>>>> Exporter-Collector architectures. Based on some applicability >>>>> examples, the next section shows the limitation of the typical >>>>> Exporter-Collector architecture model and the IPFIX Mediation >>>>> benefits. >>>>> 5. Mediation Applicability Examples >>>>> >>>>> 5.1. Adjusting Flow Granularity >>>>> >>>>> A set of common properties of simplest Flow type is a fixed 5-tu= ple >>>>> of protocol, source and destination IP addresses, and source and= >>>> As you talk about "Flow Keys", you should use this term and not inve= nt a=20 >>>> new one! >>> Actually, when I started to write this subsection, it implied coverin= g >>> IPFIX and NetFlow. >>> >>> I will change subsection as follows. >>> >>> 5.1. Adjusting Flow Granularity >>> >>> A simplest set Flow Keys is a fixed 5-tuple of protocol, source an= d >>> destination IP addresses, and source and destination port numbers.= A >>> shorter set of Flow Keys, such as a triple, a double, or a single >>> property, (for example network prefix, peering autonomous system >>> number, or BGP Next-Hop fields), creates more aggregated Flow >>> Records. This is especially useful for measuring router-level >>> traffic matrices in a core network domain and for easily adjusting= >>> the performance of Exporters and Collectors. >>> >>> Implementation analysis: >>> >>> Implementations for this case depend on where Flow granularity = is >>> adjusted. More suitable implementations use configurable Meter= ing >>> Processes in Original Exporters. The cache in the Metering >>> Process can specify its own set of Flow Keys and extra fields. >>> The Original Exporter thus generates Flow Records of the desire= d >>> Flow granularity. >>> >>> In the case where a Metering Process hosting no ability to chan= ge >>> the Flow Keys in Original Exporter creates Flow Records, or PSA= MP >>> Packet Reports, an IPFIX Mediator can aggregate Data Records ba= sed >>> on a new set of Flow Keys. Even in the case where the Metering= >> Even in the case of a Metering Process... >> > Ok. Thanks. >=20 >>> Process hosting this ability, an IPFIX Mediator can further >>> aggregate the Flow Records. >> fine. >> >=20 > snip >=20 >>>>> 5.2. Hierarchical Collecting Infrastructure >>>>> >>>>> The increase of IPFIX Exporters, the increase of the traffic, an= d the >> increasing number of exporters? >> > Yes. >=20 > Increasing number of IPFIX Exporters, amount of IP traffic, and variety= > of treatments expected to be performed on the Data Records is more and > more difficult to handle within a single Collector. >=20 >>>>> variety of treatments expected to be performed over the Data Rec= ords >>>> over =3D> on >>>> >>> Ok. >>> >>>>> is more and more difficult to handle within a single Collector. >>>>> Hence to increase the collecting (e.g., the bandwidth capacity) = and >>>>> processing capacity, distributed Collectors must be deployed. A= s a >>>>> possible approach, a hierarchical structure is useful for increa= sing >>>> I don't understand how the collecting and processing capacity increa= ses=20 >>>> thanks to a hierarchical structure. >>>> >>>> The capacity increases because I implement more resources in the=20 >>>> network, e.g. more Collectors. >>> Although increasing number of Collectors operated independently makes= it >>> more capacity, we cannot measure the all of amount of traffic data. >> Still not sure what you mean. >> The original exporter measures traffic, not the collector. >> If you cannot measure all the traffic, you need more powerful routers.= >=20 > Actually, if there is the capacity limitation in Exporter, as you say, > powerful exporter would be necessary. It is so apparent to go without > saying. >=20 >> IMO, the hierarchy is useful to gather data which has been collected a= t >> different places in the network. But the hierarchy is not needed to >> deploy distributed collectors. >> >=20 > Ok, I will change the section title as "Collecting Infrastructure". > And, I will change whole subsection as follows. >=20 > 5.2. Collecting Infrastructure >=20 > Increasing number of IPFIX Exporters, amount of IP traffic, and the > variety of treatments expected to be performed on the Data Records i= s > more and more difficult to handle within a single Collector. Increasing numbers of IPFIX Exporters, IP traffic growth, and the variety of treatments expected to be performed on the Data Records make=20 it more and more difficult to implement all measurement applications=20 within a single Collector. > Implementation analysis: >=20 > To increase the collecting (e.g., the bandwidth capacity) and > processing capacity, distributed Collectors close to Exporters > need to be deployed. In such a case, those Collectors would > become IPFIX Mediators, re-exporting Data Records on demand to > centralized applications. To cope with the variety of treatments= , measurement applications > one possible implementation uses an Intermediate Process deciding= > to which Collector(s) to export each record. More specific cases= =2E..deciding to which Collectors each record is exported. > are described in section 5.9. >=20 >>>>> the measurement systems capacity, both in export bandwidth capac= ity >>>>> and in collecting capacity. >>>>> >>>>> Implementation analysis: >>>>> >>>>> To cope with the increase of IPFIX Exporters and traffic, one= >>>> "number of IPFIX Exporters" (only IPFIX?) >>> Ok. >>> >>>>> possible implementation uses IPFIX Concentrators to build a >>>>> hierarchical collection system. To cope with the variety of >>>>> treatments, one possible implementation uses IPFIX Distributo= rs to >>>>> build a distributed collection system. More specific cases a= re >>>>> described in section 5.9. > snip >=20 >>>>> 5.6. Data Record Anonymization >>>>> >>>>> IPFIX exports across administrative domains can be used to measu= re >>>>> traffic for wide-area traffic engineering or to analyze Internet= >>>>> traffic trends, as described in the spatial composition across >>>>> administrative domains in the previous subsection. >>>>> In such a case, administrators need to adhere to privacy protect= ion >>>>> policies and prevent access to confidential traffic measurements= by >>>>> other people. Typically, anonymization techniques enables the >>>> enable >>>> >>> Yes. >>> >>>>> provision of traffic data to other people without violating thes= e >>>>> policies. >>>>> >>>>> Generally, anonymization modifies a data set to protect the iden= tity >>>>> of the people or entities described by the data set from being >>>>> disclosed. It also attempts to preserve sets of network traffic= >>>>> properties useful for a given analysis while ensuring the data c= annot >>>>> be traced back to the specific networks, hosts, or users generat= ing >>>>> the traffic. For example, IP address anonymization is particula= rly >>>>> important for avoiding the identification of the users, hosts, a= nd >>>> remove second "the" >>>> >>> Yes. >>> >>>>> routers. As another example, when ISP provides a traffic monito= ring >>>> an ISP >>>> >>> Yes. >>> >>>>> service to end customers by their own Exporters, even in case of= >>>>> exporting interface index fields, network administrators take ca= re of >>>>> anonymizing its fields to avoid disclosing the vulnerability. >>>> Why does an interface represent a vulnerability? >>>> >>> Interface indexes assignment policies in several vendors are differen= t. >>> Some vender indexes show upper bytes indicating line card, lower byte= >>> indicating interfaces. >>> By recognizing its policy, we can presume the vendors of Exporter. >> Ok. But I would not say that disclosing an interface index automatical= ly >> discloses a vulnerability. >> >> "vulnerability" =3D> "information" >=20 > Ok. I will change as follows. >=20 > As another example, when an ISP provides a traffic monitoring service t= o > end customers by their own Exporters, even in case of exporting > interface index fields, network administrators take care of anonymizing= > its fields to avoid from identifying vendor or software version by > disclosing the information. As another example, when an ISP provides traffic monitoring service to end customers, network administrators take care of anonymizing interface index fields which could disclose any information about the=20 vendor or software version of the Exporters. >=20 >>>>> Implementation analysis: >>>>> >>>>> One possible implementation for this case uses an anonymizati= on >>>>> function at the Original Exporter. However, this increases t= he >>>>> load on the Original Exporter. A more flexible implementatio= n >>>>> uses a separate IPFIX Masquerading Proxy between the Original= >>>>> Exporter and Collector. >>>> >>>> >=20 > snip >=20 >>>>> 7. Summary and Conclusion >>>>> >>>>> This document described the problems that network administrators= have >>>>> been facing, the applicability of IPFIX Mediation to these probl= ems, >>>>> and the problems related to the implementation of IPFIX Mediator= s. >>>>> To assist the operations of the Exporters and Collectors, there = are >>>>> various IPFIX Mediations from which the administrators may selec= t. >>>>> Examples of the applicability of IPFIX Mediation are as follows.= >>>>> >>>>> o Regarding large-scale measurement system, IPFIX Concentrators= or >>>>> IPFIX Distributors help to achieve traffic analysis with high= data >>>>> accuracy and fine flow granularity even as IP traffic grows. = As >>>>> IPFIX Mediation capabilities, Flow sampling, aggregation, and= >>>>> composition are effective. >>>> Sampling and aggregation reduce the accuracy or granularity. >>>> Correlation seems to be appropriate. >>>> >>> I means as follows. >>> >>> o Regarding large-scale measurement system, IPFIX Mediator with >>> IPFIX File Writer helps to achieve traffic analysis with high d= ata >>> accuracy and fine flow granularity even as IP traffic grows. A= s >>> IPFIX Mediation capabilities, Flow sampling, aggregation, and >>> composition are effective. >> Flow sampling =3D> Flow selection ? >> >>>>> o Regarding data retention, IPFIX Mediators enhance the export >>>>> reliability, and the storage of the measurement system. >>>>> >>>>> o Regarding the distribution of Data Records, IPFIX Distributor= s >>>>> help to achieve multipurpose traffic analysis for different >>>>> organizations, or help to achieve respective traffic analysis= >>>> remove "respective"? >>>> >>> Ok. >>> >>>>> based on Data Record types(IPv4, IPv6, MPLS, and VPN). >>>>> >>>>> o Regarding the IPFIX export across domains, IPFIX Masquerading= >>>>> Proxies help administrators to anonymize or filter Data Recor= ds, >>>>> preventing privacy violations. >>>>> >>>>> o Regarding interoperability, IPFIX Proxies provide interoperab= ility >>>>> between legacy protocols and IPFIX, even during the migration= >>>> even =3D> for example >>> Ok. >>> >>>>> period to IPFIX. >>>>> >>>>> As a result, the IPFIX Mediation benefits become apparent. Howe= ver, >>>>> there are still some open issues with the use of IPFIX Mediators= =2E >>>>> >>>>> o Both Observation Point and IPFIX Message header information, = such >>>>> as the Exporter IP address, Observation Domain ID, and Export= Time >>>>> field, might be lost. This data should therefore be communic= ated >>>>> between the Original Exporter and Collector via the IPFIX >>>>> Mediator. >>>>> >>>>> o IPFIX Mediators are required to manage Transport Sessions, >>>>> Template IDs, and Observation Domain IDs. Otherwise, anomalo= us >>>>> IPFIX Messages could be created. >>>>> >>>>> o Data Records defined by Options Templates, such as those repo= rting >>>>> the Sampling rate and Sampling algorithm used, might be lost >>>>> during IPFIX Mediation. If a Collector is not informed of cu= rrent >>>>> Sampling rates, traffic information might become worthless. >>>>> >>>>> These problems stem from the fact that no standards regarding IP= FIX >>>>> Mediation have been set. In particular, the minimum set of >>>>> information that should be communicated between Original Exporte= rs >>>>> and Collectors, the management between different IPFIX Transport= >>>>> Sessions, and the internal components of IPFIX Mediators should = be >>>>> standardized. >>>> There is a lot of repetition in this section. >>>> >>> You means this section should be removed. >> If it just repeats what has already been set, then probably yes. >> >=20 > I will furthermore summarise the section as follows. >=20 > 7. Summary and Conclusion >=20 > This document described the problems that network administrators hav= e > been facing, the applicability of IPFIX Mediation to these problems,= > and the problems related to the implementation of IPFIX Mediators. > To assist the operations of the Exporters and Collectors, this > document demonstrates there are various IPFIX Mediations from which =2E..demonstrates that there exist various IPFIX Mediation functions from= =20 which the administrators may select. > the administrators may select. >=20 > However, there are still some open issues with the use of IPFIX > Mediators. These issues stem from the fact that no standards > regarding IPFIX Mediation have been set. In particular, the minimum= > set of information that should be communicated between Original > Exporters and Collectors, the management between different IPFIX > Transport Sessions, and the internal components of IPFIX Mediators > should be standardized. >=20 >=20 > Regards, > Atsushi >=20 --=20 Dipl.-Ing. Gerhard M=FCnz Chair for Network Architectures and Services (I8) Technische Universit=E4t M=FCnchen - Department of Informatics Boltzmannstr. 3, 85748 Garching bei M=FCnchen, Germany Phone: +49 89 289-18008 Fax: +49 89 289-18033 E-mail: muenz@net.in.tum.de WWW: http://www.net.in.tum.de/~muenz --------------ms040708030000050609060306 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIJ6TCC Az8wggKooAMCAQICAQ0wDQYJKoZIhvcNAQEFBQAwgdExCzAJBgNVBAYTAlpBMRUwEwYDVQQI EwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEaMBgGA1UEChMRVGhhd3RlIENv bnN1bHRpbmcxKDAmBgNVBAsTH0NlcnRpZmljYXRpb24gU2VydmljZXMgRGl2aXNpb24xJDAi BgNVBAMTG1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBDQTErMCkGCSqGSIb3DQEJARYccGVy c29uYWwtZnJlZW1haWxAdGhhd3RlLmNvbTAeFw0wMzA3MTcwMDAwMDBaFw0xMzA3MTYyMzU5 NTlaMGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBM dGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQTCBnzAN BgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAxKY8VXNV+065yplaHmjAdQRwnd/p/6Me7L3N9Vvy Gna9fww6YfK/Uc4B1OVQCjDXAmNaLIkVcI7dyfArhVqqP3FWy688Cwfn8R+RNiQqE88r1fOC dz0Dviv+uxg+B79AgAJk16emu59l0cUqVIUPSAR/p7bRPGEEQB5kGXJgt/sCAwEAAaOBlDCB kTASBgNVHRMBAf8ECDAGAQH/AgEAMEMGA1UdHwQ8MDowOKA2oDSGMmh0dHA6Ly9jcmwudGhh d3RlLmNvbS9UaGF3dGVQZXJzb25hbEZyZWVtYWlsQ0EuY3JsMAsGA1UdDwQEAwIBBjApBgNV HREEIjAgpB4wHDEaMBgGA1UEAxMRUHJpdmF0ZUxhYmVsMi0xMzgwDQYJKoZIhvcNAQEFBQAD gYEASIzRUIPqCy7MDaNmrGcPf6+svsIXoUOWlJ1/TCG4+DYfqi2fNi/A9BxQIJNwPP2t4WFi w9k6GX6EsZkbAMUaC4J0niVQlGLH2ydxVyWN3amcOY6MIE9lX5Xa9/eH1sYITq726jTlEBpb NU1341YheILcIRk13iSx0x1G/11fZU8wggNPMIICuKADAgECAhAqxerdN2XVRkUZsuk5IKdP MA0GCSqGSIb3DQEBBQUAMGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3Vs dGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNz dWluZyBDQTAeFw0wOTAyMTkxMDI5NDVaFw0xMDAyMTkxMDI5NDVaMIGQMQ4wDAYDVQQEEwVN dWVuejEQMA4GA1UEKhMHR2VyaGFyZDEWMBQGA1UEAxMNR2VyaGFyZCBNdWVuejEwMC4GCSqG SIb3DQEJARYhbXVlbnpAaW5mb3JtYXRpay51bmktdHVlYmluZ2VuLmRlMSIwIAYJKoZIhvcN AQkBFhNtdWVuekBuZXQuaW4udHVtLmRlMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKC AQEAxC8p+6KRpyQyKvT9LAxUB2m8azrci+c5oQUYac2A4WsjoqiCqi2k/wgCrCIHrN0USQeH LmcbtSWT5O+1kMai28KGUdZG5xmJ7PLuLejKlYIu2TkR8tI1Q4gyu1Gs45yn9Rf+EGWmqa/s ebjMV3tc/zrpEN2b1ls8U9rM2/h0NcUUU+g170e8DlXNOL7+bsQD+tLH5G3nlV9mZntMQ68t PaaLG4MtupHuS99YGoo0yB4rzuTxiWRKTJgqjboQL0eS9+6dxsrT01g7sOc2QtXbO45PBnsG Ra5CAMpGLrqGT1ISZIpqYrGuMH9Rv7HTR3rLygL81WMDtNCa6W5/PPMlSwIDAQABo1MwUTBB BgNVHREEOjA4gSFtdWVuekBpbmZvcm1hdGlrLnVuaS10dWViaW5nZW4uZGWBE211ZW56QG5l dC5pbi50dW0uZGUwDAYDVR0TAQH/BAIwADANBgkqhkiG9w0BAQUFAAOBgQBOkMsohjpIH4Mr 33zNnhc5PkzAi0RZ6UAOB28nTtfjVZ25UVLWqmLgYEszbloTd07y5PcUZhSuPuwGzEwn4XdX i3VWl6qk5VcPpyP7+b5XEY5CU1A8cqeaXS88qWyshu1dXm2ToqueRPv+E2b3GJHAciNt2Qfc T4SNWymkvUyPSjCCA08wggK4oAMCAQICECrF6t03ZdVGRRmy6Tkgp08wDQYJKoZIhvcNAQEF BQAwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0 ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA5 MDIxOTEwMjk0NVoXDTEwMDIxOTEwMjk0NVowgZAxDjAMBgNVBAQTBU11ZW56MRAwDgYDVQQq EwdHZXJoYXJkMRYwFAYDVQQDEw1HZXJoYXJkIE11ZW56MTAwLgYJKoZIhvcNAQkBFiFtdWVu ekBpbmZvcm1hdGlrLnVuaS10dWViaW5nZW4uZGUxIjAgBgkqhkiG9w0BCQEWE211ZW56QG5l dC5pbi50dW0uZGUwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDELyn7opGnJDIq 9P0sDFQHabxrOtyL5zmhBRhpzYDhayOiqIKqLaT/CAKsIges3RRJB4cuZxu1JZPk77WQxqLb woZR1kbnGYns8u4t6MqVgi7ZORHy0jVDiDK7UazjnKf1F/4QZaapr+x5uMxXe1z/OukQ3ZvW WzxT2szb+HQ1xRRT6DXvR7wOVc04vv5uxAP60sfkbeeVX2Zme0xDry09posbgy26ke5L31ga ijTIHivO5PGJZEpMmCqNuhAvR5L37p3GytPTWDuw5zZC1ds7jk8GewZFrkIAykYuuoZPUhJk impisa4wf1G/sdNHesvKAvzVYwO00Jrpbn888yVLAgMBAAGjUzBRMEEGA1UdEQQ6MDiBIW11 ZW56QGluZm9ybWF0aWsudW5pLXR1ZWJpbmdlbi5kZYETbXVlbnpAbmV0LmluLnR1bS5kZTAM BgNVHRMBAf8EAjAAMA0GCSqGSIb3DQEBBQUAA4GBAE6QyyiGOkgfgyvffM2eFzk+TMCLRFnp QA4HbydO1+NVnblRUtaqYuBgSzNuWhN3TvLk9xRmFK4+7AbMTCfhd1eLdVaXqqTlVw+nI/v5 vlcRjkJTUDxyp5pdLzypbKyG7V1ebZOiq55E+/4TZvcYkcByI23ZB9xPhI1bKaS9TI9KMYID cTCCA20CAQEwdjBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcg KFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3Vpbmcg Q0ECECrF6t03ZdVGRRmy6Tkgp08wCQYFKw4DAhoFAKCCAdAwGAYJKoZIhvcNAQkDMQsGCSqG SIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMDkxMjAzMDkwOTM4WjAjBgkqhkiG9w0BCQQxFgQU cc+G5Ubnp0wEhYH+I99IvL0zRbAwXwYJKoZIhvcNAQkPMVIwUDALBglghkgBZQMEAQIwCgYI KoZIhvcNAwcwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqG SIb3DQMCAgEoMIGFBgkrBgEEAYI3EAQxeDB2MGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxU aGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwg RnJlZW1haWwgSXNzdWluZyBDQQIQKsXq3Tdl1UZFGbLpOSCnTzCBhwYLKoZIhvcNAQkQAgsx eKB2MGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBM dGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQQIQKsXq 3Tdl1UZFGbLpOSCnTzANBgkqhkiG9w0BAQEFAASCAQBwJ6NkEbrEhOsblL2mi30d9Qqbl4lU B5wBSeBm3e8X6PSnp1NzSfX7IRebohbWHEVhTnNj/sTBfBDLWnX5SW1CyR4niLsgdfG+1dTL L3dU2qTiISQS4Gj8fJi/WNvYNMh0YiznT/MG1NdYE6+GR2ij+qjEP02nzYl5DJIx6/dn1Rfp /sEUIbHZJmWbYBdXExhdpIpT98eS4G35IzKCwcTvA6BrGsaPKxYHygrL4nBR2+pfRzpCAmDh pc5YJayDprwSu5b0O286x3Rg3Ny/oZObC9pIaQLiXMDwY35Hcff+0yM3dQT2Gg1gskzzgK/+ zs8kQH34WAtZ9fFLEvtomORvAAAAAAAA --------------ms040708030000050609060306-- From akoba@nttv6.net Thu Dec 3 02:49:57 2009 Return-Path: X-Original-To: ipfix@core3.amsl.com Delivered-To: ipfix@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E9D7B28C139 for ; Thu, 3 Dec 2009 02:49:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.801 X-Spam-Level: X-Spam-Status: No, score=-0.801 tagged_above=-999 required=5 tests=[AWL=-1.000, BAYES_00=-2.599, NO_RELAYS=-0.001, SUBJ_RE_NUM=2.799] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UJwKzgPmp5Z6 for ; Thu, 3 Dec 2009 02:49:56 -0800 (PST) Received: from mail.nttv6.net (mail.nttv6.net [IPv6:2001:fa8::25]) by core3.amsl.com (Postfix) with ESMTP id 7204A3A6860 for ; Thu, 3 Dec 2009 02:49:55 -0800 (PST) Received: from [10.10.10.20] ([IPv6:2001:fa8:1000:0:906b:b3cc:5c8:7d40]) by mail.nttv6.net (8.14.3/8.14.3) with ESMTP id nB3AniGJ057380; Thu, 3 Dec 2009 19:49:45 +0900 (JST) (envelope-from akoba@nttv6.net) Date: Thu, 03 Dec 2009 19:38:23 +0900 From: Atsushi Kobayashi To: Gerhard Muenz In-Reply-To: <4B178052.9020600@net.in.tum.de> References: <20091202183004.4786.17391CF2@nttv6.net> <4B178052.9020600@net.in.tum.de> Message-Id: <20091203183422.47A4.17391CF2@nttv6.net> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Becky! ver. 2.50.05 [ja] (Unregistered) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.3 (mail.nttv6.net [IPv6:2001:fa8::25]); Thu, 03 Dec 2009 19:49:45 +0900 (JST) Cc: IETF IPFIX Working Group Subject: Re: [IPFIX] WG last call on draft-ietf-ipfix-mediators-problem-statement-06 X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Dec 2009 10:49:58 -0000 Hi Gerhard, Thank you for your contribution. Please see inline. On Thu, 03 Dec 2009 10:09:38 +0100 Gerhard Muenz wrote: > > Hi Atsushi, > > comments and improvements inline. > > Regards, > Gerhard > > > snip > > > > 1. Introduction > > > > An advantage of flow-based measurement is that it allows monitoring > > large amount of traffic observed at distributed observation points. > > While flow-based measurement can be applied to one of various > > purposes and applications, it is difficult for flow-based measurement > > to apply to multiple applications with very different requirements in > > parallel. Network administrators need to adjust some parameters of > > metering devices according to the most severe one of requirements of > > multiple measurement applications within measurement system > > performance and capacity. IP traffic growth consuming furthermore > > measurement system capacity make it further difficult to keep the > > adjustment. To make a measurement system flexible and scalable, an > > intermediate device can generally be applied to the system. > > - What about the following: > > Network administrators need to adjust the parameters of the metering > devices to fulfill the requirements of every single measurement > application. Such configurations are often not supported by the > metering devices, either because of functional restrictions or > because of limited computational and memory resources, which inhibit > the metering of large amounts of traffic with the desired setup. > IPFIX Mediation fills the gap between restricted metering > capabilities and the requirements of measurement applications by > introducing an intermediate device called IPFIX Mediator. > Fine with me. > > > > > >>>>> The IPFIX requirements defined in [RFC3917] mention examples of > >>>>> intermediate devices, such as IPFIX Proxies or Concentrators, there > >>>> missing conjunction, such as "but", "yet", or something like that snip > > > > 4.4. Summary > > > > Due to resource limitations of the measurement system, it is > > important to use traffic data reduction techniques as early as > > possible, e.g., at the Exporter. (4.1) > > However, this implementation is made difficult by heterogeneous > > environment of exporting devices.(4.2) On the other hand, keeping > > data accuracy and flow granularity to meet the requirements of > > different monitoring applications requires a scalable and flexible > > collecting infrastructure.(4.3) > > > > Is it OK? > > - Have you switched 4.2 and 4.3? yes. It's my mistake. > - I would remove (4.*) in the text above. > Yes. I would like to remove them before submitting it. > >>>>> This implies that a new Mediation function is required in typical > >>>>> Exporter-Collector architectures. Based on some applicability > >>>>> examples, the next section shows the limitation of the typical > >>>>> Exporter-Collector architecture model and the IPFIX Mediation > >>>>> benefits. snip > > > > 5.2. Collecting Infrastructure > > > > Increasing number of IPFIX Exporters, amount of IP traffic, and the > > variety of treatments expected to be performed on the Data Records is > > more and more difficult to handle within a single Collector. > > Increasing numbers of IPFIX Exporters, IP traffic growth, and the > variety of treatments expected to be performed on the Data Records make > it more and more difficult to implement all measurement applications > within a single Collector. Fine with me. > > > Implementation analysis: > > > > To increase the collecting (e.g., the bandwidth capacity) and > > processing capacity, distributed Collectors close to Exporters > > need to be deployed. In such a case, those Collectors would > > become IPFIX Mediators, re-exporting Data Records on demand to > > centralized applications. To cope with the variety of treatments, > > measurement applications > Yes. > > one possible implementation uses an Intermediate Process deciding > > to which Collector(s) to export each record. More specific cases > > ...deciding to which Collectors each record is exported. > > > are described in section 5.9. > > snip > > > >>>>> 5.6. Data Record Anonymization > >>>>> > >>>>> IPFIX exports across administrative domains can be used to measure > >>>>> traffic for wide-area traffic engineering or to analyze Internet > >>>>> traffic trends, as described in the spatial composition across > >>>>> administrative domains in the previous subsection. > >>>>> In such a case, administrators need to adhere to privacy protection > >>>>> policies and prevent access to confidential traffic measurements by > >>>>> other people. Typically, anonymization techniques enables the > >>>> enable > >>>> > >>> Yes. > >>> > >>>>> provision of traffic data to other people without violating these > >>>>> policies. > >>>>> > >>>>> Generally, anonymization modifies a data set to protect the identity > >>>>> of the people or entities described by the data set from being > >>>>> disclosed. It also attempts to preserve sets of network traffic > >>>>> properties useful for a given analysis while ensuring the data cannot > >>>>> be traced back to the specific networks, hosts, or users generating > >>>>> the traffic. For example, IP address anonymization is particularly > >>>>> important for avoiding the identification of the users, hosts, and > >>>> remove second "the" > >>>> > >>> Yes. > >>> > >>>>> routers. As another example, when ISP provides a traffic monitoring > >>>> an ISP > >>>> > >>> Yes. > >>> > >>>>> service to end customers by their own Exporters, even in case of > >>>>> exporting interface index fields, network administrators take care of > >>>>> anonymizing its fields to avoid disclosing the vulnerability. > >>>> Why does an interface represent a vulnerability? > >>>> > >>> Interface indexes assignment policies in several vendors are different. > >>> Some vender indexes show upper bytes indicating line card, lower byte > >>> indicating interfaces. > >>> By recognizing its policy, we can presume the vendors of Exporter. > >> Ok. But I would not say that disclosing an interface index automatically > >> discloses a vulnerability. > >> > >> "vulnerability" => "information" > > > > Ok. I will change as follows. > > > > As another example, when an ISP provides a traffic monitoring service to > > end customers by their own Exporters, even in case of exporting > > interface index fields, network administrators take care of anonymizing > > its fields to avoid from identifying vendor or software version by > > disclosing the information. > > As another example, when an ISP provides traffic monitoring service to > end customers, network administrators take care of anonymizing > interface index fields which could disclose any information about the > vendor or software version of the Exporters. > Fine. > > > > >>>>> Implementation analysis: > >>>>> > >>>>> One possible implementation for this case uses an anonymization > >>>>> function at the Original Exporter. However, this increases the > >>>>> load on the Original Exporter. A more flexible implementation > >>>>> uses a separate IPFIX Masquerading Proxy between the Original > >>>>> Exporter and Collector. > >>>> > >>>> > > > > snip > > > >>>>> 7. Summary and Conclusion > >>>>> > >>>>> This document described the problems that network administrators have > >>>>> been facing, the applicability of IPFIX Mediation to these problems, > >>>>> and the problems related to the implementation of IPFIX Mediators. > >>>>> To assist the operations of the Exporters and Collectors, there are > >>>>> various IPFIX Mediations from which the administrators may select. > >>>>> Examples of the applicability of IPFIX Mediation are as follows. > >>>>> > >>>>> o Regarding large-scale measurement system, IPFIX Concentrators or > >>>>> IPFIX Distributors help to achieve traffic analysis with high data > >>>>> accuracy and fine flow granularity even as IP traffic grows. As > >>>>> IPFIX Mediation capabilities, Flow sampling, aggregation, and > >>>>> composition are effective. > >>>> Sampling and aggregation reduce the accuracy or granularity. > >>>> Correlation seems to be appropriate. > >>>> > >>> I means as follows. > >>> > >>> o Regarding large-scale measurement system, IPFIX Mediator with > >>> IPFIX File Writer helps to achieve traffic analysis with high data > >>> accuracy and fine flow granularity even as IP traffic grows. As > >>> IPFIX Mediation capabilities, Flow sampling, aggregation, and > >>> composition are effective. > >> Flow sampling => Flow selection ? > >> > >>>>> o Regarding data retention, IPFIX Mediators enhance the export > >>>>> reliability, and the storage of the measurement system. > >>>>> > >>>>> o Regarding the distribution of Data Records, IPFIX Distributors > >>>>> help to achieve multipurpose traffic analysis for different > >>>>> organizations, or help to achieve respective traffic analysis > >>>> remove "respective"? > >>>> > >>> Ok. > >>> > >>>>> based on Data Record types(IPv4, IPv6, MPLS, and VPN). > >>>>> > >>>>> o Regarding the IPFIX export across domains, IPFIX Masquerading > >>>>> Proxies help administrators to anonymize or filter Data Records, > >>>>> preventing privacy violations. > >>>>> > >>>>> o Regarding interoperability, IPFIX Proxies provide interoperability > >>>>> between legacy protocols and IPFIX, even during the migration > >>>> even => for example > >>> Ok. > >>> > >>>>> period to IPFIX. > >>>>> > >>>>> As a result, the IPFIX Mediation benefits become apparent. However, > >>>>> there are still some open issues with the use of IPFIX Mediators. > >>>>> > >>>>> o Both Observation Point and IPFIX Message header information, such > >>>>> as the Exporter IP address, Observation Domain ID, and Export Time > >>>>> field, might be lost. This data should therefore be communicated > >>>>> between the Original Exporter and Collector via the IPFIX > >>>>> Mediator. > >>>>> > >>>>> o IPFIX Mediators are required to manage Transport Sessions, > >>>>> Template IDs, and Observation Domain IDs. Otherwise, anomalous > >>>>> IPFIX Messages could be created. > >>>>> > >>>>> o Data Records defined by Options Templates, such as those reporting > >>>>> the Sampling rate and Sampling algorithm used, might be lost > >>>>> during IPFIX Mediation. If a Collector is not informed of current > >>>>> Sampling rates, traffic information might become worthless. > >>>>> > >>>>> These problems stem from the fact that no standards regarding IPFIX > >>>>> Mediation have been set. In particular, the minimum set of > >>>>> information that should be communicated between Original Exporters > >>>>> and Collectors, the management between different IPFIX Transport > >>>>> Sessions, and the internal components of IPFIX Mediators should be > >>>>> standardized. > >>>> There is a lot of repetition in this section. > >>>> > >>> You means this section should be removed. > >> If it just repeats what has already been set, then probably yes. > >> > > > > I will furthermore summarise the section as follows. > > > > 7. Summary and Conclusion > > > > This document described the problems that network administrators have > > been facing, the applicability of IPFIX Mediation to these problems, > > and the problems related to the implementation of IPFIX Mediators. > > To assist the operations of the Exporters and Collectors, this > > document demonstrates there are various IPFIX Mediations from which > > ...demonstrates that there exist various IPFIX Mediation functions from > which the administrators may select. > Thanks. Regards, Atsushi --- Atsushi KOBAYASHI NTT Information Sharing Platform Lab. tel:+81-(0)422-59-3978 fax:+81-(0)422-59-5637 From root@core3.amsl.com Fri Dec 4 04:00:02 2009 Return-Path: X-Original-To: ipfix@ietf.org Delivered-To: ipfix@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id 2120B3A67FB; Fri, 4 Dec 2009 04:00:01 -0800 (PST) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20091204120002.2120B3A67FB@core3.amsl.com> Date: Fri, 4 Dec 2009 04:00:02 -0800 (PST) Cc: ipfix@ietf.org Subject: [IPFIX] I-D Action:draft-ietf-ipfix-reliability-template-ext-00.txt X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Dec 2009 12:00:02 -0000 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IP Flow Information Export Working Group of the IETF. Title : Reliability Extension for IPFIX Author(s) : S. Gupta Filename : draft-ietf-ipfix-reliability-template-ext-00.txt Pages : 11 Date : 2009-12-04 IPFIX[RFC3917] mandates the IPFIX device should be reliable.To be reliable the individual components like the Metering process or the Exporting process should not fail to meter & export the flow information to the collector, else indicate its incapability explicitly. Currently, IPFIX transmits failure by sending count of packets,flows it failed to process along with the duration of the failure. This document outlines some of the limitations an IPFIX device may have and suggests solutions. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ipfix-reliability-template-ext-00.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-ipfix-reliability-template-ext-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2009-12-04035157.I-D@ietf.org> --NextPart-- From Quittek@nw.neclab.eu Fri Dec 4 04:04:30 2009 Return-Path: X-Original-To: ipfix@core3.amsl.com Delivered-To: ipfix@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6E4003A67DF for ; Fri, 4 Dec 2009 04:04:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.866 X-Spam-Level: X-Spam-Status: No, score=-1.866 tagged_above=-999 required=5 tests=[AWL=0.133, BAYES_00=-2.599, J_CHICKENPOX_75=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LKvGOJ0Jsm32 for ; Fri, 4 Dec 2009 04:04:29 -0800 (PST) Received: from smtp0.neclab.eu (smtp0.neclab.eu [195.37.70.41]) by core3.amsl.com (Postfix) with ESMTP id 5D42F3A67B6 for ; Fri, 4 Dec 2009 04:04:29 -0800 (PST) Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp0.neclab.eu (Postfix) with ESMTP id 955DB2C01C9B0 for ; Fri, 4 Dec 2009 13:04:20 +0100 (CET) X-Virus-Scanned: Amavisd on Debian GNU/Linux (atlas2.office) Received: from smtp0.neclab.eu ([127.0.0.1]) by localhost (atlas2.office [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zD1Kv7zJaekJ for ; Fri, 4 Dec 2009 13:04:20 +0100 (CET) Received: from VENUS.office (mx1.office [192.168.24.3]) by smtp0.neclab.eu (Postfix) with ESMTP id 6066B2C00C525 for ; Fri, 4 Dec 2009 13:04:15 +0100 (CET) Received: from 10.7.0.54 ([10.7.0.54]) by VENUS.office ([192.168.24.102]) with Microsoft Exchange Server HTTP-DAV ; Fri, 4 Dec 2009 12:04:15 +0000 MIME-Version: 1.0 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-Type: multipart/signed; boundary="B_3342805451_61284358"; protocol="application/pkcs7-signature"; micalg=sha1 Content-class: urn:content-classes:message Date: Fri, 4 Dec 2009 13:04:11 +0100 Message-ID: In-Reply-To: <20091204120002.2120B3A67FB@core3.amsl.com> X-MS-Has-Attach: yes X-MS-TNEF-Correlator: Thread-Topic: [IPFIX] I-D Action:draft-ietf-ipfix-reliability-template-ext-00.txt Thread-Index: Acp02eOtN+JAORHo9kqt8k6wRUUbbQ== From: "Juergen Quittek" To: "IETF IPFIX Working Group" Subject: Re: [IPFIX] I-D Action:draft-ietf-ipfix-reliability-template-ext-00.txt X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Dec 2009 12:04:30 -0000 > This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --B_3342805451_61284358 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Dear all, This is not an IPFIX WG document as the name and the announcement implies. By mistake this individual draft was submitted as WG draft and by another mistake I clicked the wrong link in the web tool and approved it instead of rejecting it. I am sorry for this and already asked the IETF secretary to fix this. I also asked the author to re-submit the draft as an individual one. Sorry, Juergen On 04.12.09 21:00 "Internet-Drafts@ietf.org" wrote: > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > This draft is a work item of the IP Flow Information Export Working Group of > the IETF. > > > Title : Reliability Extension for IPFIX > Author(s) : S. Gupta > Filename : draft-ietf-ipfix-reliability-template-ext-00.txt > Pages : 11 > Date : 2009-12-04 > > IPFIX[RFC3917] mandates the IPFIX device should be reliable.To be > reliable the individual components like the Metering process or the > Exporting process should not fail to meter & export the flow > information to the collector, else indicate its incapability > explicitly. > > Currently, IPFIX transmits failure by sending count of packets,flows > it failed to process along with the duration of the failure. > > This document outlines some of the limitations an IPFIX device may > have and suggests solutions. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-ipfix-reliability-template-ext- > 00.txt > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > Below is the data which will enable a MIME compliant mail reader > implementation to automatically retrieve the ASCII version of the > Internet-Draft. > _______________________________________________ > IPFIX mailing list > IPFIX@ietf.org > https://www.ietf.org/mailman/listinfo/ipfix --B_3342805451_61284358 Content-type: application/pkcs7-signature; name="smime.p7s" Content-transfer-encoding: base64 Content-disposition: attachment; filename="smime.p7s" MIIQ6gYJKoZIhvcNAQcCoIIQ2zCCENcCAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3DQEHAaCC DpIwggU2MIIEHqADAgECAgQNLisHMA0GCSqGSIb3DQEBBQUAMIGQMQswCQYDVQQGEwJERTEY MBYGA1UEChMPTkVDIEV1cm9wZSBMdGQuMSAwHgYDVQQLExdORUMgTGFib3JhdG9yaWVzIEV1 cm9wZTESMBAGA1UEAxMJTkVDTEFCLUNBMTEwLwYJKoZIhvcNAQkBFiJ6ZXJ0aWZpemllcnVu Z3NzdGVsbGVAbncubmVjbGFiLmV1MB4XDTA4MTEwMzA3NTEyMFoXDTExMTEwMzA3NTEyMFow YzELMAkGA1UEBhMCREUxGDAWBgNVBAoTD05FQyBFdXJvcGUgTHRkLjEgMB4GA1UECxMXTkVD IExhYm9yYXRvcmllcyBFdXJvcGUxGDAWBgNVBAMTD0p1ZXJnZW4gUXVpdHRlazCCASIwDQYJ KoZIhvcNAQEBBQADggEPADCCAQoCggEBALYRfFB9x4h1YO6Mva6A5GCwKjwpgvzjiayFSmdD HwV8u5gHp3sHIhyVtxgMSifEp9AV+ChxWHS3KQwuQ3XhDAP/xDN6QSk4Bmqa6rCZuTJygxYh K39rNKd47ZfpuRC7j/Mbzwe9DTsbbBtpBgl5UKFc9c+zMbPlSwwlVbshWaUEoM6HoVFaDJdh tJBIpsblz1oQVKXDjxjGkUNh9Ds3m7BGXkr5yaGsEuEa0J/QAFdO+auvBJlAzIM0UwBAmlcT UHanS6Sdw5MkeutQqnmsUBtoenydq2Tmd9hfSfuTfiFuLmsvL3udH/jDAgQZ+PH6Mprqpyd3 wSycF/xZF5zz8X0CAwEAAaOCAcIwggG+MAkGA1UdEwQCMAAwCwYDVR0PBAQDAgXgMCkGA1Ud JQQiMCAGCCsGAQUFBwMCBggrBgEFBQcDBAYKKwYBBAGCNxQCAjAdBgNVHQ4EFgQUWQo3BPrO OLA4qljzDL1H8/6hIWEwHwYDVR0jBBgwFoAUTxyHeh3gL5n2vhWq0TWdDkrmujYwHwYDVR0R BBgwFoEUUXVpdHRla0Budy5uZWNsYWIuZXUwfQYDVR0fBHYwdDA4oDagNIYyaHR0cDovL2Nk cDEucGNhLmRmbi5kZS9uZWNsYWItY2EvcHViL2NybC9jYWNybC5jcmwwOKA2oDSGMmh0dHA6 Ly9jZHAyLnBjYS5kZm4uZGUvbmVjbGFiLWNhL3B1Yi9jcmwvY2FjcmwuY3JsMIGYBggrBgEF BQcBAQSBizCBiDBCBggrBgEFBQcwAoY2aHR0cDovL2NkcDEucGNhLmRmbi5kZS9uZWNsYWIt Y2EvcHViL2NhY2VydC9jYWNlcnQuY3J0MEIGCCsGAQUFBzAChjZodHRwOi8vY2RwMi5wY2Eu ZGZuLmRlL25lY2xhYi1jYS9wdWIvY2FjZXJ0L2NhY2VydC5jcnQwDQYJKoZIhvcNAQEFBQAD ggEBAB37+54yupDBTDpEMuyf+ouCRrOE3fPAD2SEGBXCpKTYteFkFSWvHlgN8ecRSma0Dz/5 QShzacGMeJ8o+XzVXHe2gtZbjzSVvJn+/nAKtKgDCzw0ltt3xkdMMv2ax6IKGR7BcccsXx7B R2PMaxdmHfCJseXiMzZO9QlWN2NZq2SSo3eGX/YDhHCWXDsoSu+uaKU/aRL2uZa92ptak2MA uKI5tylKLFZ3FHf08F8J+5tTaMGem6DfaMZR/9GZ8aRFJrdA7tzUAGKpl+CzRxsJVHbAAU5L hm5oTt6XYbh2G/cgdpeucsHJWBz9NQJrSrfWZYSwrv6AekMcvMi9X/CVZxEwggUvMIIEF6AD AgECAgQNIQpHMA0GCSqGSIb3DQEBBQUAMFoxCzAJBgNVBAYTAkRFMRMwEQYDVQQKEwpERk4t VmVyZWluMRAwDgYDVQQLEwdERk4tUEtJMSQwIgYDVQQDExtERk4tVmVyZWluIFBDQSBHbG9i YWwgLSBHMDEwHhcNMDgxMDI0MDg1MjA4WhcNMTkwNjMwMDAwMDAwWjCBkDELMAkGA1UEBhMC REUxGDAWBgNVBAoTD05FQyBFdXJvcGUgTHRkLjEgMB4GA1UECxMXTkVDIExhYm9yYXRvcmll cyBFdXJvcGUxEjAQBgNVBAMTCU5FQ0xBQi1DQTExMC8GCSqGSIb3DQEJARYiemVydGlmaXpp ZXJ1bmdzc3RlbGxlQG53Lm5lY2xhYi5ldTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoC ggEBAJ7yFbG1EaoyDnG5367mJEXHljmacrzNnm52KW3dXD/s3Vpuskex0jvaaTntWWRSGrAK 6kKXnTxBb3J3EhveBUbltzQ+K0XKtPJm6VE5qVpl33WJSaUHs27Dhwlke+DV6BBGyukz2SDB aSa+nc0AwMZ0XO1DoDuiUNVeNmd/QT4SGzyFs+uLfLL2n8WzkZsbpSZ+xecwyw3EdQBBsp/i /W+uOQBsGqaCjYe3EkBU6nW+pBsj0Iy1n7b9PXb5gQynrK3Mi2V7g1idSzHos0o1BMoHUrMz Vw94Hj4CWlWmQ0t6Pdt1uYAMjwk0saQBY/Fyfv+wKeYycGIYyYCfJIRUeyUCAwEAAaOCAcQw ggHAMBIGA1UdEwEB/wQIMAYBAf8CAQEwCwYDVR0PBAQDAgEGMB0GA1UdDgQWBBRPHId6HeAv mfa+FarRNZ0OSua6NjAfBgNVHSMEGDAWgBRJt8bP6D0ff+pEexMp9/EKcD7eZDAtBgNVHREE JjAkgSJ6ZXJ0aWZpemllcnVuZ3NzdGVsbGVAbncubmVjbGFiLmV1MIGIBgNVHR8EgYAwfjA9 oDugOYY3aHR0cDovL2NkcDEucGNhLmRmbi5kZS9nbG9iYWwtcm9vdC1jYS9wdWIvY3JsL2Nh Y3JsLmNybDA9oDugOYY3aHR0cDovL2NkcDIucGNhLmRmbi5kZS9nbG9iYWwtcm9vdC1jYS9w dWIvY3JsL2NhY3JsLmNybDCBogYIKwYBBQUHAQEEgZUwgZIwRwYIKwYBBQUHMAKGO2h0dHA6 Ly9jZHAxLnBjYS5kZm4uZGUvZ2xvYmFsLXJvb3QtY2EvcHViL2NhY2VydC9jYWNlcnQuY3J0 MEcGCCsGAQUFBzAChjtodHRwOi8vY2RwMi5wY2EuZGZuLmRlL2dsb2JhbC1yb290LWNhL3B1 Yi9jYWNlcnQvY2FjZXJ0LmNydDANBgkqhkiG9w0BAQUFAAOCAQEAbDEPnQ9JpouPHYA1OEek P3l3GNM0HBzadVbtbN5MDtFmoVgdLYqlQaHb30wFhuOMbsNCOzV0k8EOvBVOT9BiEJ70RWcl SZQ460jZS2MY6n5oG/ilZuu6N/N3GSLg2pBBNH9vZFCyBJ9n4Px7A4gQF07G+CNfV2jdE1yy PjzIVPhg6bBgia8nXroBFe6oteavMspo0gLGIJ63NsCbl6ckPa96grT+mnnQD0h6jk/IGtXS 09mEWRbN7zZu0x0q+SScpljG36Q+jnG0U5zQI0jAx8CcYEQQH5QOlsw1Zu35OI4lsi7ycFkz JNfbfEC4ihuw9J2L43BFGMojkhPkhVExHTCCBCEwggMJoAMCAQICAgDHMA0GCSqGSIb3DQEB BQUAMHExCzAJBgNVBAYTAkRFMRwwGgYDVQQKExNEZXV0c2NoZSBUZWxla29tIEFHMR8wHQYD VQQLExZULVRlbGVTZWMgVHJ1c3QgQ2VudGVyMSMwIQYDVQQDExpEZXV0c2NoZSBUZWxla29t IFJvb3QgQ0EgMjAeFw0wNjEyMTkxMDI5MDBaFw0xOTA2MzAyMzU5MDBaMFoxCzAJBgNVBAYT AkRFMRMwEQYDVQQKEwpERk4tVmVyZWluMRAwDgYDVQQLEwdERk4tUEtJMSQwIgYDVQQDExtE Rk4tVmVyZWluIFBDQSBHbG9iYWwgLSBHMDEwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEK AoIBAQDpm8NnhfkNrvWNVMOWUDU9YuluTO2U1wBblSJ01CDrNI/W7MAxBAuZgeKmFNJSoCgj hIt0iQReW+DieMF4yxbLKDU5ey2QRdDtoAB6fL9KDhsAw4bpXCsxEXsM84IkQ4wcOItqaACa 7txPeKvSxhObdq3u3ibo7wGvdA/BCaL2a869080UME/15eOkyGKbghoDJzANAmVgTe3RCSMq ljVYJ9N2xnG2kB3E7f81hn1vM7PbD8URwoqDoZRdQWvY0hD1TP3KUazZve+Sg7va64sWVlZD z+HVEz2mHycwzUlU28kTNJpxdcVs6qcLmPkhnSevPqM5OUhqjK3JmfvDEvK9AgMBAAGjgdkw gdYwcAYDVR0fBGkwZzBloGOgYYZfaHR0cDovL3BraS50ZWxlc2VjLmRlL2NnaS1iaW4vc2Vy dmljZS9hZl9Eb3dubG9hZEFSTC5jcmw/LWNybF9mb3JtYXQ9WF81MDkmLWlzc3Vlcj1EVF9S T09UX0NBXzIwHQYDVR0OBBYEFEm3xs/oPR9/6kR7Eyn38QpwPt5kMB8GA1UdIwQYMBaAFDHD eRu69VPXF+CJei0XbAqzK50zMA4GA1UdDwEB/wQEAwIBBjASBgNVHRMBAf8ECDAGAQH/AgEC MA0GCSqGSIb3DQEBBQUAA4IBAQA74Vp3wEgX3KkY7IGvWonwvSiSpspZGBJw7Cjy565/lizn 8l0ZMfYTK3S9vYCyufdnyTmieTvhERHua3iRM347XyYndVNljjNj7s9zw7CSI0khUHUjoR8Y 4pSFPT8z6XcgjaK95qGFKUD2P3MyWA0Ja6bahWzAP7uNZmRWJE6uDT8yNQFb6YyC2XJZT7GG hfF0hVblw/hc843uR7NTBXDn5U2KaYMo4RMJhp5eyOpYHgwf+aTUWgRo/Sg+iwK2WLX2oSw3 VwBnqyNojWOl75lrXP1LVvarQIc01BGSbOyHxQoLBzNytG8MHVQs2FHHzL8w00Ny8TK/jM5J Y6gA9/IcMYICIDCCAhwCAQEwgZkwgZAxCzAJBgNVBAYTAkRFMRgwFgYDVQQKEw9ORUMgRXVy b3BlIEx0ZC4xIDAeBgNVBAsTF05FQyBMYWJvcmF0b3JpZXMgRXVyb3BlMRIwEAYDVQQDEwlO RUNMQUItQ0ExMTAvBgkqhkiG9w0BCQEWInplcnRpZml6aWVydW5nc3N0ZWxsZUBudy5uZWNs YWIuZXUCBA0uKwcwCQYFKw4DAhoFAKBdMCMGCSqGSIb3DQEJBDEWBBQmhUMoP2cic0ZiG+HV ionmsSB92zAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0wOTEy MDQxMjA0MTFaMA0GCSqGSIb3DQEBAQUABIIBAB8qDsvsheUixFFgzNN74JU2tQQVZPZQHFIU r7wlLoin8ndP2FBgFockX8hm9gZIug/2+FpbvR1pBtx4/NirfXjSfe5vaHsrqpDIpeXRSrBD aiGXtkYuAoZuRzD3+vMOFo/ZJrm+9CP0ZzbQv9MYybs2m+3DOZW7X8u9WeWKNZwQJkGz7Vpt yQxvTyWL4h4MhZDGfiZelQPNEhOqo6jgvYp52cO5WEFAHPfrmHY1LkgBz2DzOdjvWOAuP0Lo 1jcol5BQAdCEVUN4mzDQKjHi6lIvHSIYH66RW78CqbvW7j5IAGZ4IjSLug9Fv6xxnGNfXKTg 9IivuqI986JLm1zUlgE= --B_3342805451_61284358-- From sujay.ietf@gmail.com Mon Dec 7 22:52:01 2009 Return-Path: X-Original-To: ipfix@core3.amsl.com Delivered-To: ipfix@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E71093A69D1 for ; Mon, 7 Dec 2009 22:52:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_75=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aPIdmH-gjKf4 for ; Mon, 7 Dec 2009 22:52:00 -0800 (PST) Received: from mail-pw0-f50.google.com (mail-pw0-f50.google.com [209.85.160.50]) by core3.amsl.com (Postfix) with ESMTP id 1D67D3A69DA for ; Mon, 7 Dec 2009 22:52:00 -0800 (PST) Received: by pwi20 with SMTP id 20so1762862pwi.29 for ; Mon, 07 Dec 2009 22:51:45 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:date:message-id:subject :from:to:cc:content-type; bh=dJk7DlXBVyMOBi50axFq5zObx70JeqmJsuMjACmAYlM=; b=ReyZNw+WviILCxDkjURBPbMQDhgVEmmkzKHPPcp6r65lHC7mnLFpng2olzrQruVldS tE7E8u98e7I5KByOo4LmY9P45CNZJg98Bh+T9kyErnmUbN2B0Gl0ya5PuTCfNrudaQ53 1x0FDmcV5Pt5yOeiEJWL7/wyjuFZhozCt7eZw= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:cc:content-type; b=H0KhygyFE/Qy6oO+SgXOUBwBchdwnVd1xRZqM03M4zmSYF08T7wTQ1BhZJ98Nt7tcV y5I3/1D37i7Ict7weegYzIX9SzmNvXPvBPIFP9mRmVXwI38soDMd0XehKORFusxlrbx1 YFElQhHHqp/PR19wBOFYfpKQGNHW1gkT9H19U= MIME-Version: 1.0 Received: by 10.142.120.3 with SMTP id s3mr836105wfc.301.1260255105748; Mon, 07 Dec 2009 22:51:45 -0800 (PST) Date: Tue, 8 Dec 2009 12:21:45 +0530 Message-ID: From: sujay gupta To: ipfix@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Cc: Juergen Quittek Subject: [IPFIX] draft-gupta-ipfix-reliability-template-ext-00.txt X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Dec 2009 06:52:01 -0000 HI, Request you to provide your comments and feedback on the following draft which has been submitted; Title: Reliability Template Extension for IPFIX draft-gupta-ipfix-reliability-template-ext-00.txt Brief: "IPFIX[RFC3917] mandates the IPFIX device should be reliable.To be reliable the individual components like the Metering process or the Exporting process should not fail to meter & export the flow information to the collector, else indicate its incapability explicitly. Currently, IPFIX transmits failure by sending count of packets,flows it failed to process along with the duration of the failure. This document outlines some of the limitations an IPFIX device may have and suggests solutions." A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-gupta-ipfix-reliability-template-ext-00.txt Thanking you, -Sujay From akoba@nttv6.net Thu Dec 10 00:01:27 2009 Return-Path: X-Original-To: ipfix@core3.amsl.com Delivered-To: ipfix@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D12273A67EA for ; Thu, 10 Dec 2009 00:01:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[AWL=1.899, BAYES_00=-2.599, GB_I_LETTER=-2, NO_RELAYS=-0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id g7PIurSgSmk2 for ; Thu, 10 Dec 2009 00:01:21 -0800 (PST) Received: from mail.nttv6.net (mail.nttv6.net [IPv6:2001:fa8::25]) by core3.amsl.com (Postfix) with ESMTP id 9867E3A62C1 for ; Thu, 10 Dec 2009 00:01:19 -0800 (PST) Received: from [10.10.10.20] ([IPv6:2001:fa8:1000:0:bdfa:b8e0:11d5:fc7e]) by mail.nttv6.net (8.14.3/8.14.3) with ESMTP id nBA8163b058401 for ; Thu, 10 Dec 2009 17:01:06 +0900 (JST) (envelope-from akoba@nttv6.net) Date: Thu, 10 Dec 2009 16:49:27 +0900 From: Atsushi Kobayashi To: ipfix@ietf.org Message-Id: <20091210164010.8C60.17391CF2@nttv6.net> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Becky! ver. 2.50.05 [ja] (Unregistered) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.3 (mail.nttv6.net [IPv6:2001:fa8::25]); Thu, 10 Dec 2009 17:01:06 +0900 (JST) Subject: [IPFIX] WGLC comments on draft-ietf-ipfix-configuration-model-04 X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Dec 2009 08:01:27 -0000 Dear Gerhard, Benoit, and Paul, I would like to show the respect for your great effort for writing this document. This document contains all of parameters and statistics with regard to IPFIX and PSAMP specification. Thus, it needs hard review even if except for section 6. I put my comments and questions in inline, please see it. > > > > IP Flow Information Export WG G. Muenz > Internet-Draft TU Muenchen > Intended status: Standards Track B. Claise > Expires: April 26, 2010 P. Aitken > Cisco Systems, Inc. > October 23, 2009 > > > Configuration Data Model for IPFIX and PSAMP > > > Status of this Memo > > This Internet-Draft is submitted to IETF in full conformance with the > provisions of BCP 78 and BCP 79. This document may contain material > from IETF Documents or IETF Contributions published or made publicly > available before November 10, 2008. The person(s) controlling the > copyright in some of this material may not have granted the IETF > Trust the right to allow modifications of such material outside the > IETF Standards Process. Without obtaining an adequate license from > the person(s) controlling the copyright in such materials, this > document may not be modified outside the IETF Standards Process, and > derivative works of it may not be created outside the IETF Standards > Process, except to format it for publication as an RFC or to > translate it into languages other than English. > > 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 26, 2010. > > Copyright Notice > > Copyright (c) 2009 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 in effect on the date of > publication of this document (http://trustee.ietf.org/license-info). > Please review these documents carefully, as they describe your rights > and restrictions with respect to this document. > > Abstract > > This document specifies a data model for the configuration of > selection processes, caches, exporting processes, and collecting Why do you capitalize the first letter of above terms? > processes of IPFIX and PSAMP compliant monitoring devices using UML > (Unified Modeling Language) class diagrams. The configuration data > is encoded in Extensible Markup Language (XML). The structure of the > data model is specified in a YANG module to ensure compatibility with > the NETCONF protocol. > > > Table of Contents > > 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5 > 1.1. IPFIX Documents Overview . . . . . . . . . . . . . . . . . 6 > 1.2. PSAMP Documents Overview . . . . . . . . . . . . . . . . . 6 > > 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 6 > > 3. Structure of the Configuration Data Model . . . . . . . . . . 8 > 3.1. UML Representation . . . . . . . . . . . . . . . . . . . . 10 > 3.2. Exporter Configuration . . . . . . . . . . . . . . . . . . 15 > 3.3. Collector Configuration . . . . . . . . . . . . . . . . . 17 > > 4. Configuration Parameters . . . . . . . . . . . . . . . . . . . 18 > 4.1. ObservationPoint Class . . . . . . . . . . . . . . . . . . 18 > 4.2. SelectionProcess Class . . . . . . . . . . . . . . . . . . 19 > 4.2.1. Selector Class . . . . . . . . . . . . . . . . . . . . 20 > 4.2.2. Sampler Classes . . . . . . . . . . . . . . . . . . . 21 > 4.2.3. Filter Classes . . . . . . . . . . . . . . . . . . . . 22 > 4.3. Cache Class . . . . . . . . . . . . . . . . . . . . . . . 23 > 4.3.1. CacheLayout Class . . . . . . . . . . . . . . . . . . 25 > 4.4. ExportingProcess Class . . . . . . . . . . . . . . . . . . 26 > 4.4.1. Destination Class . . . . . . . . . . . . . . . . . . 27 > 4.4.2. FileWriter Class . . . . . . . . . . . . . . . . . . . 29 > 4.4.3. Options Class . . . . . . . . . . . . . . . . . . . . 30 > 4.5. CollectingProcess Class . . . . . . . . . . . . . . . . . 31 > 4.5.1. Receiver Class . . . . . . . . . . . . . . . . . . . . 32 > 4.5.2. FileReader Class . . . . . . . . . . . . . . . . . . . 33 > 4.6. Transport Layer Security Class . . . . . . . . . . . . . . 33 > 4.7. Transport Session Class . . . . . . . . . . . . . . . . . 37 > 4.7.1. Template Class . . . . . . . . . . . . . . . . . . . . 38 > > 5. Adaptation to Device Capabilities . . . . . . . . . . . . . . 39 > > 6. YANG Module of the IPFIX/PSAMP Configuration Data Model . . . 40 > > 7. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 78 > 7.1. PSAMP Device . . . . . . . . . . . . . . . . . . . . . . . 78 > 7.2. IPFIX Device . . . . . . . . . . . . . . . . . . . . . . . 81 > 7.3. Export of Flow Records and Packet Reports . . . . . . . . 84 > 7.4. Collector and File Writer . . . . . . . . . . . . . . . . 89 > 7.5. Deviations . . . . . . . . . . . . . . . . . . . . . . . . 89 > > 8. Security Considerations . . . . . . . . . . . . . . . . . . . 90 > > 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 90 > > Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 91 > > > 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 91 > 10.1. Normative References . . . . . . . . . . . . . . . . . . . 91 > 10.2. Informative References . . . . . . . . . . . . . . . . . . 91 > > Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 93 > > > 1. Introduction > > IPFIX and PSAMP compliant Monitoring Devices (routers, switches, > monitoring probes, Collectors etc.) offer various configuration > possibilities that allow adapting network monitoring to the goals and > purposes of the application, such as accounting and charging, traffic > analysis, performance monitoring, security monitoring. The use of a > common vendor-independent configuration data model for IPFIX and > PSAMP compliant Monitoring Devices facilitates network management and > configuration, especially if Monitoring Devices of different > implementers and/or manufacturers are deployed simultaneously. On > the one hand, a vendor-independent configuration data model helps > storing and managing the configuration data of Monitoring Devices in > a consistent format. On the other hand, it can be used for local and > remote configuration of Monitoring Devices. However, this requires > that Monitoring Devices natively support the configuration data > model, or that a mapping between the configuration data model and the > device-specific representation of configuration data is provided. > I want to confirm the meaning of "mapping" in last sentence. If a vender deploy the different configuration model at first, does it need to replace them with the common configuration data? > The purpose of this document is the specification of a vendor- > independent configuration data model that covers the commonly > available configuration parameters of Selection Processes, Caches, > Exporting Processes, and Collecting Processes. The configuration > data model is defined using UML (Unified Modeling Language) class > diagrams [UML] while the actual configuration data is encoded in > Extensible Markup Language (XML) [W3C.REC-xml-20040204]. An XML > document conforming to the configuration data model contains the > configuration data of one Monitoring Device. In order to ensure > compatibility with the NETCONF protocol [RFC4741], YANG > [I-D.ietf-netmod-yang] is used as the modeling language. If > required, the YANG specification of the configuration data model can > be converted into XML Schema language [W3C.REC-xmlschema-0-20041028] > using the pyang tool [YANG-WEB]. YANG provides mechanisms to adapt > the configuration data model to device-specific constraints and to > augment the model with additional device-specific or vendor-specific > parameters. > > For the configuration of remote Monitoring Devices, an appropriate > protocol is needed to transfer the XML encoded configuration data. > The configuration data model is compatible with the NETCONF protocol > [RFC4741]. However, alternative protocols, such as the Simple Object > Access Protocol (SOAP) [W3C.REC-soap12-part1-20070427], are also > suitable for transferring XML data from a network management system > to a Monitoring Device. > > 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 [RFC2119]. > > > 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 [RFC5470], per the requirements > defined in [RFC3917]. The IPFIX protocol [RFC5101] specifies how > IPFIX Data Records and Templates are carried via a number of > transport protocols from IPFIX Exporting Processes to IPFIX > Collecting Process. IPFIX has a formal description of IPFIX > Information Elements, their name, type and additional semantic > information, as specified in [RFC5102]. [I-D.ietf-ipfix-mib] > specifies the IPFIX Management Information Base (IPFIX MIB). > Finally, [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. The storage of IPFIX Messages in a > file is specified in [I-D.ietf-ipfix-file]. > > 1.2. PSAMP Documents Overview > > The framework for packet selection and reporting [RFC5474] enables > network elements to select subsets of packets by statistical and > other methods, and to export a stream of reports on the selected > packets to a Collector. The set of packet selection techniques > (Sampling, Filtering, and hashing) standardized by PSAMP are > described in [RFC5475]. The PSAMP protocol [RFC5476] specifies the > export of packet information from a PSAMP Exporting Process to a > PSAMP Collector. Instead of exporting PSAMP Packet Reports, the > stream of selected packets may also serve as input to the generation > of IPFIX Flow Records. Like IPFIX, PSAMP has a formal description of > its Information Elements, their name, type and additional semantic > information. The PSAMP information model is defined in [RFC5477]. > [I-D.ietf-psamp-mib] describes the PSAMP Management Information Base > (PSAMP MIB). > > > 2. Terminology > > This document adopts the terminologies used in [RFC5101], > [I-D.ietf-ipfix-file], and [RFC5476]. As in these documents, all > specific terms have the first letter of a word capitalized when used > in this document. The following listing indicates in which > references the definitions of those terms that are commonly used > throughout this document can be found: > > o Definitions adopted from [RFC5101]: > * Collection Process > * Collector > * Data Record > * Exporter > * Flow Record > * Information Element > * IPFIX Device > * IPFIX Message > * Observation Domain > * Observation Point > * (Options) Template > > o Definitions adopted from [I-D.ietf-ipfix-file]: > * File Reader > * File Writer > > o Definitions adopted from [RFC5476]: > * Filtering > * Observed Packet Stream > * Packet Report > * PSAMP Device > * Sampling > * Selection Process > * Selection Sequence > * Selection Sequence Report Interpretation > * Selector, Primitive Selector, Composite Selector > > The terms Metering Process and Exporting Process have different > definitions in [RFC5101] and [RFC5476]. In the scope of this > document, these terms are used according to the following definitions > which cover the deployment in both PSAMP Devices and IPFIX Devices: > > Metering Process: The Metering Process generates IPFIX Flow Records > or PSAMP Packet Reports, depending on its deployment as part of an > IPFIX Device or PSAMP Device. Inputs to the process are packets > observed at one or multiple Observation Points belonging to a > single Observation Domain, as well as characteristics describing > the packet treatment at these Observation Points. The function of > the Metering Process is split into two types of functional blocks: > Selection Processes and Caches. > > Exporting Process: Depending on its deployment as part of an IPFIX > Device or PSAMP Device, the Exporting Process sends IPFIX Flow > Records or PSAMP Packet Reports to one or more Collecting > Processes. The IPFIX Flow Records or PSAMP Packet Reports are > generated by one or more Metering Processes. > > > In addition to the existing IPFIX and PSAMP terminology, the > following terms are defined: > > Cache: The Cache is a functional block in a Metering Process which > maintains IPFIX Flow Records or PSAMP Packet Reports. According > to [RFC5101], the maintenance of Flow Records may include creating > new records, updating existing ones, computing Flow statistics, > deriving further Flow properties, detecting Flow expiration, > passing Flow Records to the Exporting Process, and deleting Flow > Records. The maintenance of Packet Reports covers the same set of > functions. In the case of PSAMP Packet Reports, how is the Cache used in Metering Process? Is a PSAMP Packet Report maintained in Cache until deriving further properties? It seems an implementation matter. > > Cache Layout: The Cache Layout defines the superset of fields that > are included in the Packet Reports or Flow Records maintained by > the Cache. The fields are specified by the corresponding > Information Elements. In general, the largest possible subset of > the specified fields is derived for every Packet Report or Flow > Record. More specific rules about which fields must be included > are given in Section 4.3.1. > > Cache Mode: The Cache Mode specifies whether Packet Reports or Flow > Records are generated by the Cache. In the case of Flow Records, > it also specifies the Flow expiration policy. > > Monitoring Device: A Monitoring Device implements at least one of > the functional blocks specified in the context of IPFIX or PSAMP. > In particular, the term Monitoring Device encompasses Exporters, > Collectors, IPFIX Devices, and PSAMP Devices. > > Selected Packet Stream: The Selected Packet Stream is the set of all > packets selected by a Selection Process. > > > 3. Structure of the Configuration Data Model > > The IPFIX reference model in [RFC5470] describes Metering Processes, > Exporting Processes, and Collecting Processes as functional blocks of > IPFIX Devices. The PSAMP framework [RFC5474] provides the > corresponding information for PSAMP Devices and introduces Selection > Processes as functional blocks within Metering Processes. In > Section 2 of the document, the Cache is defined as another functional > block within Metering Processes. Further explanations about the > relationship between Selection Processes and Caches are given later > on in this section. IPFIX File Reader and File Writer are defined as > specific kinds of Exporting and Collecting Processes in > [I-D.ietf-ipfix-file]. > > Monitoring Device implementations usually maintain the separation of > various functional blocks although they do not necessarily implement > all of them. Furthermore, they provide various configuration > possibilities; some of them are specified as mandatory by the IPFIX > protocol [RFC5101] or PSAMP protocol [RFC5476]. The configuration > data model enables the setting of commonly available configuration > parameters for Selection Processes, Caches, Exporting Processes, and > Collecting Processes. In addition, it allows specifying the > composition of functional blocks within a Monitoring Device > configuration and their linkage with Observation Points. > > In a Monitoring Device implementation, the functionality of the > Metering Process is commonly split into packet Sampling and Filtering > functions performed by Selection Processes, and the maintenance of > Flow Records and Packet Reports performed by Caches. Figure 1 > illustrates this separation with the example of a basic Metering > Process consisting of one Selection Process and one Cache. > > +-----------------------------------+ > | Metering Process | > | +-----------+ Selected | > Observed | | Selection | Packet +-------+ | Stream of > Packet -->| Process |---------->| Cache |--> Flow Records or > Stream | +-----------+ Stream +-------+ | Packet Reports > +-----------------------------------+ > > Figure 1: Selection Process and Cache forming a Metering Process > > The configuration data model adopts the separation of Selection > Processes and Caches in order to support the flexible configuration > and combination of these functional blocks. As defined in [RFC5476], > the Selection Process takes the Observed Packet Stream as its input > and selects a subset of that stream as its output (Selected Packet > Stream). The action of the Selection Process on a single packet of > its input is defined by a Primitive Selector or a Composite Selector. > The Cache generates Flow Records or Packet Reports from the Selected > Packet Stream, depending on the configured Cache Mode. > > The Observed Packet Stream at the input of a Selection Process MUST > only contain packets originating from a single Observation Domain. > Similarly, the Selected Packet Stream at the input of a Cache MUST > only contain packets originating from a single Observation Domain. > Packets from Observation Points belonging to different Observation > Domains MUST NOT enter the same Selection Process or the same Cache. > Observed packets at different Observation Domain can be input into different Metering Process. Thus, they can not enter the same Metering Process. I think that the above sentence is already clear in existing IPFIX documents. Or it means other something? > Beyond the basic Metering Process shown in Figure 1, the > configuration data model enables the specification of more complex > configurations. A single Cache may process the output of multiple > Selection Processes. The Selected Packet Stream may be copied to I cannot image that a single cache process the output from multiple Selection Process. This sentence seems cause the inconsistency to the definition of Observation Domain, when a Metering Process consisting of a sequence of Selection Processes and Cahce. And I have another question. Are Selection Processes after Cahce available as an IPFIX Mediation? > enter several Caches, for example one Cache that generates Flow > Records and another Cache that generates Packet Reports. Selection > Processes can also be cascaded, such that the Selected Packet Stream > at the output of one Selection Process is passed to another Selection > Process. Cascading Selection Processes can be useful in specific > contexts such as the example in Section 7.3. > > The selection of parameters in the configuration data model is based > on configuration issues discussed in the IPFIX and PSAMP documents > [RFC3917], [RFC5101], [RFC5470], [RFC5476], [RFC5474], and [RFC5475]. > Furthermore, the structure and content of the IPFIX MIB module > [I-D.ietf-ipfix-mib] and the PSAMP MIB module [I-D.ietf-psamp-mib] > have been taken into consideration. Consistency between the > configuration data model and the IPFIX and PSAMP MIB modules is an > intended goal. Therefore, parameters in the configuration data model > are named according to corresponding managed objects. Certain IPFIX > MIB objects containing state data have been adopted as state > parameters in the configuration data model. State parameters cannot > be configured, yet their values can be queried from the Monitoring > Device. They can be queried from other devices as well as Monitoring Device. > > The next section explains how UML class diagrams are deployed to > illustrate the structure of the configuration data model. > Thereafter, Section 3.2 and Section 3.3 explain the class diagrams > for the configuration of Exporters and Collectors, respectively. > Each of the presented classes contains specific configuration > parameters which are specified in Section 4. The formal definition > of the configuration data model in YANG is given in Section 6. > Section 7 illustrates the usage of the model with example > configurations in XML. Section 5 gives a short introduction to YANG > concepts that allow adapting the configuration data model to the > capabilities of a device. > > 3.1. UML Representation > > We use UML class diagrams [UML] to explain the structure of the > configuration data model. The attributes of the classes are the > configuration or state parameters of the Monitoring Device. > > +------------------------------------------------+ > | Destination | > +------------------------------------------------+ > | name |<>-----+ > | exportMemberType = parallel | | 0..1 > | ipfixVersion = 10 | | > | transportProtocol | +------------+ > | destinationIpAddress | | Transport- | > | destinationPort = 4739|4740 | | Layer- | > | sendBufferSize {opt.} | | Security | > | rateLimit[0..1] | +------------+ > | localIpAddress[0..*] {SCTP only} | > | timedReliability = 0 {SCTP only} | > | numberOfStreams {opt.} {SCTP only} | > | sourceIpAddress[0..1] {UDP only} | > | templateRefreshTimeout = 600 {UDP only} | > | optionsTemplateRefreshTimeout = 600 {UDP only} | > | templateRefreshPacket[0..1] {UDP only} | > | optionsTemplateRefreshPacket[0..1] {UDP only} | > +------------------------------------------------+ > > Figure 2: UML example: Destination class > > As an example, Figure 2 shows the UML diagram of the Destination > class, which is specified in more detail in Section 4.4.1. The upper > box contains the name of the class. The lower box lists the > attributes of the class. The only parameters that MUST be configured > by the user are name, transportProtocol, and destinationIpAddress. > The remaining parameters have either defaults values, specific ~~~~~~~~~~~~~~~ default value? > properties, or a multiplicity indicator starting with zero > > A default value is indicated after the attribute behind the equality > symbol ("="). It means that this default value MUST be used by the > Monitoring Device if the parameter is not configured by the user. In > the example, IPFIX version 10 must be used if not configured > differently. For destinationPort, two default values are indicated, > namely the registered ports for IPFIX with and without transport > layer security (i.e., DTLS or TLS), respectively. Note that such > alternative default values cannot be formally specified in YANG. > Instead, they are described in the "description" statement. > > An attribute with property "{opt.}", such as sendBufferSize in the > Destination class, represents a parameter that MAY be configured by > the user. Otherwise, the Monitoring Device will assign an > appropriate value for this parameter. As a result, the parameter > will always exist in the configuration data, yet it is not mandatory > for the user to configure it. Note that this property cannot be > formally specified in YANG. Instead, it is described in the > "description" statement. > > The property "{SCTP only}" ("{UDP only}") means that the > corresponding parameters are only available if the transport protocol > is SCTP (UDP). In YANG, this is formalized in a "when" statement. > > Another property not shown in the example is "{readOnly}" specifying > state parameters which cannot be configured by the user. > > An attribute with a multiplicity indicator of "[0..1]" represents an > OPTIONAL configuration parameter. The parameter is not included in > the configuration data unless the user configures it. Typically, the > absence of the parameter has a specific meaning. For example, not > configuring rateLimit in the Destination class means that no rate > limiting will be applied to the exported data. > > A multiplicity indicator of "[0..*]" means that this parameter MAY be > configured multiple times with different values. In the example, > multiple local IP addresses may be configured if SCTP is transport > protocol. Note that attributes without this multiplicity indicator > MUST NOT appear more than once in each object of the class. > > If some parameters are related to each other, it can make sense to > group these parameters in a subclass. This is especially useful if > different subclasses represent choices of different parameter sets, > or if the parameters of a subclass may appear multiple times. For > example, the Destination class MAY contain the parameters of the > TransportLayerSecurity subclass. > > Classes define the structure of the objects of a specific > configuration. Objects and their parameters are encoded as XML > elements. So, one object of the Destination class corresponds to one > occurrence of > > > my-destination > ... > > > There are various possibilities how objects of classes can be related > to each other. In the scope of this document, we use two different > types of relationship between objects: aggregation and unidirectional > association. In UML class diagrams, two different arrow types are > used as shown in Figure 3. > > +---+ 0..* +---+ +---+ 0..* 1 +---+ > | A |<>------| B | | A |-------->| B | > +---+ +---+ +---+ +---+ > (a) Aggregation (b) Unidirectional association > > Figure 3: Class relationships in UML class diagrams > > Aggregation means that one object is part of the other object. In > Figure 3 (a), an object of class B is part of an object of class A. > This corresponds to nested XML elements: > > > > ... > > ... > > > Note that we write class names starting with a capital letter > throughout this document. The corresponding XML elements use > identical names starting with an uncapitalized letter because they > represent objects, not classes. > > A unidirectional association is a reference to an object. In > Figure 3 (b), an object of class A contains a reference to an object > of class B. This corresponds to separate XML elements that are not > nested. To distinguish different objects of class B, class B must > have a key. In the configuration data model, all keys are string > parameters called "name", corresponding to XML elements . The > names must be unique within the XML document. The reference to a > specific object of class B is encoded with an XML element which > contains the corresponding object name. In the given example, this > may look as follows: > > > ... > foo > ... > > > > foo > ... > > > In Figure 3, the indicated numbers define the multiplicity: > > "1": one only > "0..*": zero or more > "1..*": one or more > > In the case of aggregation, the multiplicity indicates how many > objects of one class may be included in one object of the other > class. In Figure 3 (a), an object of class A may contain an > arbitrary number of objects of class B. In the case of unidirectional > association, the multiplicity at the arrowhead specifies the number > of objects of a given class that may be referred to. The > multiplicity at the arrow tail specifies how many different objects > of one class may refer to a single object of the other class. In > Figure 3 (b), an object of class A refers to single object of class > B. One object of class B can be referred to from an arbitrary number > of objects of class A. > > Similar to classes that are referenced in UML associations, classes > which contain configuration parameters and which occur with > multiplicity greater than one in an aggregation relationship must > have a key which allows distinguishing different objects. This key > is necessary because every configuration parameter must be > addressable in order to manipulate or delete it. The values of the > key must be unique in the scope of the aggregating object. Hence, > under the assumption that class B in Figure 3 (a) contains at least > one configuration parameter, all objects of class B belonging to the > same object of class A must have different key values. Again, the > key appears as an attribute called "name" in all concerned classes. > > A class which contains state parameters but no configuration > parameters, such as the Template class (see Section 4.7.1), does not > have a key. This is because state parameters cannot be manipulated > or deleted, and therefore do not need to be addressable. > > Note that the usage of keys as described above is also required by > YANG [I-D.ietf-netmod-yang] which mandates the existence of a key for > all elements which appear in lists of configuration data. > > The configuration data model for IPFIX and PSAMP makes use of > unidirectional associations to specify the data flow between > different functional blocks. For example, if the output of a > Selection Process is processed by a Cache, this corresponds to an > object of the SelectionProcess class that contains a reference to an > object of the Cache class. The configuration data model does not > mandate that such a reference exists for every functional block that > has an output. If such a reference is absent, the output is dropped > without any further processing. Although such configurations are > incomplete, we do not consider them as invalid as they may > temporarily occur if a Monitoring Device is configured in multiple > steps. Also, it might be useful to pre-configure certain functions > of a Monitoring Device in order to be able to switch to a new > configuration more quickly. It is good idea. > > 3.2. Exporter Configuration > > Figure 4 below shows the main classes of the configuration data model > which are involved in the configuration of an IPFIX or PSAMP > Exporter. The role of the classes can be briefly summarized as > follows: > > o The ObservationPoint class specifies an Observation Point (i.e., > an interface or linecard) of the Monitoring Device at which > packets are captured for traffic measurements. An object of the > ObservationPoint class may be associated with one or more objects > of the SelectionProcess class configuring Selection Processes that > process the observed packets in parallel. As long as an > ObservationPoint object is specified without any references to > SelectionProcess objects, the Observation Point is not deployed > for traffic measurements. > > o The SelectionProcess class contains the configuration parameters > of a Selection Process. The Selection Process may be composed of > a single Selector or a sequence of Selectors, defining a Primitive > or Composite Selector, respectively. > > The Selection Process selects packets from an Observed Packet > Stream originating from one or multiple Observation Points. > Therefore, a SelectionProcess object MAY be referred to from > multiple ObservationPoint objects. The corresponding Observation > Points must belong to the same Observation Domain. The Selection Process after Cache handles the Flow Records or Packet Reports, not packets. > > A Selection Process MAY pass the Selected Packet Stream to one or > multiple Caches. Therefore, the SelectionProcess class enables > references to objects of the Cache class. > > It is possible to cascade different Selection Processes. In this > case, the Selected Packet Stream at the output of one or multiple > Selection Processes is passed to the input of another Selection > Process. Therefore, a SelectionProcess object MAY be referred to > from multiple SelectionProcess objects. For the same reason, one > SelectionProcess object may refer to other objects of the same > class. When cascading multiple Selection Processes, it must be > ensured that all packets entering a Selection Process have been > observed at Observation Points belonging to the same Observation > Domain. A configuration example is given later in Section 7.3. > > If a Selection Process is configured without any reference to > Selection Processes or Caches that receive the selected packets, > the selected packets are not accounted in any Packet Report or > Flow Record. > > o The Cache class contains configuration parameters of a Cache. A > Cache may receive the output of one or more Selection Processes > and maintains corresponding Packet Reports or Flow Records. > Therefore, an object of the Cache class MAY be referred to from > multiple SelectionProcess objects. However, the configuration > MUST ensure that all packets entering the Selection Process have ^^^^^^^^^^^^^^^^^ Cache? > been observed at Observation Points belonging to the same > Observation Domain. > > Configuration parameters of the Cache class specify the size of > the Cache, the Cache Mode and Layout, and expiration parameters. > The Cache Mode determines if Packet Reports or Flow Records are > generated. > > A Cache MAY pass its output to one or multiple Exporting Process. > Therefore, the Cache class enables references to one or multiple > objects of the ExportingProcess class. If a Cache object does not > specify any reference to an ExportingProcess object, the Cache > output is dropped. > > o The ExportingProcess class contains configuration parameters of an > Exporting Process. It includes various transport protocol > specific parameters and the export destinations. An object of the > ExportingProcess class MAY be referred to from multiple objects of > the Cache class. > > An Exporting Process MAY be configured as a File Writer according > to [I-D.ietf-ipfix-file]. > > +------------------+ > | ObservationPoint | > +------------------+ > 0..* | > | > 0..* V > +------------------+ > | SelectionProcess | > +------------------+<-+ > 0..* | 0..* | | 0..* > | +---+ > 0..* V > +------------------+ > | Cache | > +------------------+ > 0..* | > | > 0..* V > +------------------+ > | ExportingProcess | > +------------------+ > > Figure 4: Class diagram of Exporter configuration > > 3.3. Collector Configuration > > Figure 5 below shows the main classes of the configuration data model > which are involved in the configuration of a Collector. An object of > the CollectingProcess class specifies the local IP addresses, > transport protocols and port numbers of a Collecting Process. > Alternatively, the Collecting Process MAY be configured as a File > Reader according to [I-D.ietf-ipfix-file]. > > An object of the CollectingProcess class may refer to one or multiple > ExportingProcess objects configuring Exporting Processes that > reexport the received data. As an example, an Exporting Process can > be configured as a File Writer in order to save the received IPFIX > Messages in a file. > > +-------------------+ 0..* 0..* +------------------+ > | CollectingProcess |----------->| ExportingProcess | > +-------------------+ +------------------+ > > Figure 5: Class diagram of Collector configuration > > > 4. Configuration Parameters > > This section specifies the configuration and state parameters of the > configuration data model separately for each class. Parameters > serving as keys are depicted in brackets. > > 4.1. ObservationPoint Class > > +-------------------------------+ > | ObservationPoint | > +-------------------------------+ 1 +--------------------+ > | name |<>----------| Interface/Linecard | > | observationPointId {readOnly} | +--------------------+ > | observationDomainId | > | | 0..* 0..* +--------------------+ > | |----------->| SelectionProcess | > +-------------------------------+ +--------------------+ > > +------------------+ +----------------------------------+ > | Interface | | Linecard | > +------------------+ +----------------------------------+ > | ifIndex/ifName | | entPhysicalIndex/entPhysicalName | > | direction = both | | direction = both | > +------------------+ +----------------------------------+ > > Figure 6: ObservationPoint class > > Figure 6 shows the ObservationPoint class that identifies an > Observation Point of the Monitoring Device. The Observation Point > can either be an interface or a linecard. > > An object of the ObservationPoint class MUST specify the ID of the > Observation Domain the Observation Point belongs to. Observation > Points that are configured with the same Observation Domain ID belong > to the same Observation Domain. > > The Observation Point ID (i.e., the value of the Information Element > observationPointId [RFC5102]) is assigned by the Monitoring Device. > It appears as a state parameter in the ObservationPoint class. > > The configuration parameters to identify an interface or a linecard > are as follows: > > ifIndex/ifName (interface only): Either the index or name of the > interface MUST be specified according to corresponding objects in > the IF-MIB [RFC2863]. > > entPhysicalIndex/entPhysicalName (linecard only): Either the index > or name of the linecard MUST be specified according to > corresponding objects in the ENTITY-MIB [RFC4133]. > > direction: This parameter specifies if ingress traffic, egress > traffic, or both ingress and egress traffic is captured, using the > values "ingress", "egress", and "both", respectively. If not > configured, ingress and egress traffic is captured (i.e., the > default value is "both"). If not applicable (e.g., in the case of > a sniffing interface in promiscuous mode), the value of this > parameter is ignored. I have one question. In the case of a single ifIndex belonging to multiple Observation Domains, can this Interface class be referred by multiple ObservationPoint classes? > > An ObservationPoint object MAY refer to one or multiple > SelectionProcess objects configuring Selection Processes that process > the observed packets in parallel. > > 4.2. SelectionProcess Class > > +--------------------------------+ > | SelectionProcess | > +--------------------------------+ 1..* +----------+ > | name |<>----------| Selector | > | selectionSequenceId {readOnly} | +----------+ > | | 0..* > | |<---+ > | | | > | |----+ > | | 0..* > | | > | | 0..* 0..* +----------+ > | |----------->| Cache | > +--------------------------------+ +----------+ > > Figure 7: SelectionProcess class > > Figure 7 shows the SelectionProcess class. The SelectionProcess > class contains the configuration parameters of a Selection Process > which selects packets from the Observed Packet Stream at its input > and outputs the Selected Packet Stream to one or multiple other > Selection Processes or Caches. A non-empty ordered list defines a > sequence of Selectors. The actions defined by the Selectors are > applied to the stream of incoming packet in the specified order. > > The state parameter selectionSequenceId contains the Selection > Sequence ID (i.e., the value of the Information Element > selectionSequenceId [RFC5477]) which is assigned by the Monitoring > Device. The Selection Sequence ID MUST be unique within the > Observation Domain as required by [RFC5477]. > > The output of one Selection Process MAY be processed by other > Selection Processes. Therefore, the SelectionProcess class allows > references to itself, meaning that one SelectionProcess object MAY > refer to other SelectionProcess objects. > > A SelectionProcess object MAY include references to one or more > objects of the Cache class configuring Caches that receive the > Selected Packet Stream and generate corresponding Packet Reports or > Flow Records. If SelectionProcess class embodies the function of Metering Process, I prefer the name of MeteringProcess class instead of SelectionProcess from the consistency with IPFIX-MIB. > > 4.2.1. Selector Class > > +--------------------------------------+ > | Selector | > +--------------------------------------+ 1 +-----------------+ > | name |<>------+ SelectAll/ | > | selectorId {readOnly} | | SampCountBased/ | > | packetsObserved {readOnly} | | SampTimeBased/ | > | packetsDropped {readOnly} | | SampRandOutOfN/ | > | selectorDiscontinuityTime {readOnly} | | SampUniProb/ | > | | | FilterMatch/ | > | | | FilterHash/ | > +--------------------------------------+ +-----------------+ > > Figure 8: Selector class > > The Selector class in Figure 8 contains the configuration and state > parameters of a Selector. Standardized PSAMP Sampling and Filtering > methods are described in [RFC5475]; their configuration parameters > are specified in corresponding sampler (SampCountBased, > SampTimeBased, SampRandOutOfN, SampUniProb) or filter (FilterMatch, > FilterHash) classes. In addition, the SelectAll class, which has no > parameters, is used for a Selector that selects all packets. The > Selector class includes exactly one of these sampler and filter > classes, depending on the applied method. > > The state parameter selectorId contains the Selector ID (i.e., the > value of the Information Element selectorId [RFC5477]) assigned by > the Monitoring Device. The Selector ID MUST be unique within the > Observation Domain as required by [RFC5477]. > > As state parameters, the Selector class contains the Selector > statistics packetsObserved and packetsDropped that correspond to the > objects of the ipfixSelectorStatsTable in the IPFIX MIB module > [I-D.ietf-ipfix-mib]. > > > 4.2.2. Sampler Classes > > +----------------+ +----------------+ +----------------+ > | SampCountBased | | SampTimeBased | | SampRandOutOfN | > +----------------+ +----------------+ +----------------+ > | packetInterval | | timeInterval | | population | > | packetSpace | | timeSpace | | size | > +----------------+ +----------------+ +----------------+ > > +----------------+ > | SampUniProb | > +----------------+ > | probability | > +----------------+ > > Figure 9: Sampler classes > > The Sampler classes in Figure 9 contain the configuration parameters > of specific Sampling algorithms: > > packetInterval, packetSpace: For systematic count-based sampling, > packetInterval defines the number of packets that are > consecutively sampled between gaps of length packetSpace. These > parameters correspond to the Information Elements > samplingPacketInterval and samplingPacketSpace [RFC5477]. > > timeInterval, timeSpace: For systematic time-based sampling, > timeInterval defines the time interval during which all arriving > packets are sampled. timeSpace is the gap between two sampling > intervals. These parameters correspond to the Information > Elements samplingTimeInterval and samplingTimeSpace [RFC5477]. > The unit is microseconds. > > size, population: For n-out-of-N random sampling, size defines the > number of elements taken from the parent population. population > defines the number of elements in the parent population. These > parameters correspond to the Information Elements samplingSize and > samplingPopulation [RFC5477]. > > probability: For uniform probabilistic sampling, probability defines > the sampling probability. This parameter corresponds to the > Information Element samplingProbability [RFC5477]. > > > 4.2.3. Filter Classes > > +--------------------------+ > | FilterMatch | > +--------------------------+ > | ieId/ieName | > | ieEnterpriseNumber[0..1] | > | value | > +--------------------------+ > > +--------------------------+ > | FilterHash | > +--------------------------+ 1..* +---------------+ > | hashFunction = BOB |<>-------| SelectedRange | > | ipPayloadOffset = 0 | +---------------+ > | ipPayloadSize = 8 | | name | > | digestOutput = false | | min | > | initialiserValue[0..1] | | max | > +--------------------------+ +---------------+ > > Figure 10: Filter classes > > The Filter classes in Figure 10 contain the configuration parameters > of specific Filtering methods. For property match filtering, the > configuration parameters are: > > ieId, ieName, ieEnterpriseNumber: The property to be matched is > specified by either ieId or ieName, specifying the ID or name of > the Information Element, respectively. ieEnterpriseNumber MUST be > used for enterprise-specific Information Elements. If > ieEnterpriseNumber is omitted or zero, this is Information Element > is not enterprise-specific but registered at IANA. > > value: Matching value. > Can the ranges of value be defined like hash value? And, I would like to specify its instruction, "match" or "unmatch". > For hash-based filtering, the configuration parameters are: > > hashFunction: Hash function to be used. The following parameter > values are defined by the configuration data model: > * BOB: BOB Hash Function as specified in [RFC5475], Appendix A.2 > * IPSX: IP Shift-XOR (IPSX) Hash Function as specified in > [RFC5475], Appendix A.1 > * CRC: CRC-32 function as specified in [RFC1141] > Default value is "BOB". > > ipPayloadOffset, ipPayloadSize: ipPayloadOffset and ipPayloadSize > configure the offset and the size of the payload section used as > input to the hash function. Default values are 0 and 8, > respectively, corresponding to the minimum configurable values > according to [RFC5476], Section 6.2.5.6. These parameters > correspond to the Information Elements hashIPPayloadOffset and > hashIPPayloadSize [RFC5477]. > > digestOutput: digestOutput enables or disables the inclusion of the > packet digest in the resulting PSAMP Packet Report. This requires > that the Cache Layout of the Cache generating the Packet Reports > includes a digestHashValue field. This parameter corresponds to > the Information Element hashDigestOutput [RFC5477]. > > initialiserValue: Initializer value to the hash function. This > parameter corresponds to the Information Element > hashInitialiserValue [RFC5477]. If not configured by the user, > the monitoring device arbitrarily chooses an initializer value. > > One or more ranges of matching hash values are defined by the min and > max parameters of the SelectedRange subclass. These parameters > correspond to the Information Elements hashSelectedRangeMin and > hashSelectedRangeMax [RFC5477]. > > 4.3. Cache Class > > +-----------------------------------+ > | Cache | > +-----------------------------------+ 1 +-------------+ > | name |<>----------| CacheLayout | > | cacheMode | +-------------+ > | maxRecords {opt.} | > | activeTimeout {opt.} | 0..* 0..* +------------------+ > | {except Cache Mode "immediate"} |----------->| ExportingProcess | > | inactiveTimeout {opt.} | +------------------+ > | {Cache Mode "timeout" only} | > | activeFlows {readOnly} | > | inactiveFlows {readOnly} | > | cacheDataRecords {readOnly} | > | cacheDiscontinuityTime {readOnly} | > +-----------------------------------+ > > Figure 11: Cache class > > Figure 11 shows the Cache class that contains the configuration and > state parameters of a Cache. The configuration parameters of the > Cache class are as follows: > > cacheMode: Configures the Cache Mode. The following parameter > values are specified by the configuration data model: > * immediate: Data Records expire after the first packet > * timeout: Data Records expire after active or inactive timeout > * permanent: Data Records never expire, but are periodically > exported with interval set by the active timeout > In the case of "immediate", PSAMP Packet Reports are generated. > Otherwise, IPFIX Flow Records are generated. > > maxRecords: Maximum number of Data Records in the Cache. If not > configured by the user, the Monitoring Device sets this parameter. > When a cache becomes max Records, new Flow Records can be dropped or push the old one? Does it depend on the implementation matter? > activeTimeout: This parameter configures the active timeout in > milliseconds. It is not available for Cache Mode "immediate". > The parameter value zero indicates infinity, meaning that there is > no active timeout. If not configured by the user, the Monitoring > Device sets this parameter. > In the case of Cache Mode "timeout", the active timeout defines > the time after which a Flow Record is expired even though packets > matching this Flow are still received by the Cache. In the case > of Cache Mode "permanent", the active timeout defines the interval > for periodical export of Flow Records. In the case of Cache Mode "timeout", the timer for active timeout is set per a Flow Record. In the case of Cache Mode "permanent", the timer for active timeout is set per a Cache. If it is right, each meaning "active timeout" are different. Could you please add some explanation. > > inactiveTimeout: This parameter configures the inactive timeout in > milliseconds. It is not available for Cache Modes "immediate" and > "permanent". The parameter value zero indicates infinity, meaning > that there is no inactive timeout. If not configured by the user, > the Monitoring Device sets this parameter. > The inactive timeout defines the time after which a Flow Record is > expired if no packets matching this Flow are received by the > Cache. > > An object of the Cache class includes an object of the CacheLayout > class that defines which fields are included in the Packet Reports or > Flow Records. A Cache object MAY refer to one or multiple > ExportingProcess objects configuring different Exporting Processes. > > As state parameters, the Cache class contains the Metering Process > statistics activeFlows, inactiveFlows, and cacheDataRecords that > correspond to the objects of the ipfixMeteringProcessStatsTable of > the IPFIX MIB module [I-D.ietf-ipfix-mib]. > > > 4.3.1. CacheLayout Class > > +--------------+ > | CacheLayout | > +--------------+ 1..* +--------------------------+ > | |<>------| CacheField | > | | +--------------------------+ > | | | name | > | | | ieId/ieName | > | | | ieLength {opt.} | > | | | ieEnterpriseNumber[0..1] | > | | | isFlowKey[0..1] | > +--------------+ +--------------------------+ > > Figure 12: CacheLayout class > > A Cache generates and maintains Packet Reports or Flow Records > containing information that has been extracted from the incoming > stream of packets. Using the CacheField class, the CacheLayout class > specifies the superset of fields that are included in the Packet > Reports or Flow Records (see Figure 12). > > If Packet Reports are generated (i.e., if Cache Mode is "immediate"), > every field specified by the Cache Layout MUST be included in the > resulting Packet Report unless the corresponding Information Element > is not applicable or cannot be derived from the content or treatment > of the incoming packet. > > If Flow Records are generated (i.e., if Cache Mode is "timeout" or > "permanent"), every Flow Key field specified by the Cache Layout MUST > be included as Flow Key in the resulting Flow Record unless the > corresponding Information Element is not applicable or cannot be > derived from the content or treatment of the incoming packet. Two > packets MUST be accounted by different Flow Records if different > subsets of the Flow Key fields are applicable or derivable. Every > non-key field specified by the Cache Layout MUST be included in the > resulting Flow Record unless the corresponding Information Element is > not applicable or cannot be derived for the given Flow. > > For example, if a non-key field specifies an Information Element > whose value is determined by the first packet observed within a Flow > (which is the default rule according to [RFC5102]), this field MUST > be included in the resulting Flow Record if it can be determined from > the first packet of the Flow. > > The CacheLayout class does not have any parameters. The > configuration parameters of the CacheField class are as follows: > > ieId, ieName, ieEnterpriseNumber: These parameters specify a field > by the combination of the Information Element identifier or name, > and the Information Element enterprise number. Either ieId or > ieName MUST be specified. ieEnterpriseNumber MUST be used for > enterprise-specific Information Elements. If ieEnterpriseNumber > is omitted or zero, this is Information Element is not enterprise- > specific but registered at IANA. > > ieLength: This parameter specifies the length of the field in > octets. A value of 65535 means that the field is encoded as > variable-length Information Element. For Information Elements of > integer and float type, the field length MAY be set to a smaller > value than the standard length of the abstract data type if the > rules of reduced size encoding are fulfilled (see [RFC5101], > Section 6.2). If not configured by the user, the field length is > set by the Monitoring Device. > > isFlowKey: If present, this field is a Flow Key. > > 4.4. ExportingProcess Class > > +--------------------+ > | ExportingProcess | > +--------------------+ 0..* +------------------+ > | name |<>------| Destination | > | | +------------------+ > | | > | | 0..* +------------------+ > | |<>------| FileWriter | > | | +------------------+ > | | > | | 0..* +------------------+ > | |<>------| Options | > | | +------------------+ > | | > | | 0..* +------------------+ > | |<>------| TransportSession | > +--------------------+ +------------------+ > > Figure 13: ExportingProcess class > > The ExportingProcess class in Figure 13 specifies export destinations > and files to which the IPFIX Messages are exported using objects of > the Destination class and the FileWriter, respectively. These two > classes are described in Section 4.4.1 and Section 4.4.2. If not > configured by the user, the Exporting Process ID is assigned by the > Monitoring Device. The reporting of specific information with > Options Templates is defined with objects of the Options class. > As state data, the ExportingProcess class contains the list of > Transport Sessions that originate from the Exporting Process. The > TransportSession class is specified in Section 4.7. > > 4.4.1. Destination Class > > +------------------------------------------------+ > | Destination | > +------------------------------------------------+ > | name |<>-----+ > | exportMemberType = parallel | | 0..1 > | ipfixVersion = 10 | | > | transportProtocol | +------------+ > | destinationIpAddress | | Transport- | > | destinationPort = 4739|4740 | | Layer- | > | sendBufferSize {opt.} | | Security | > | rateLimit[0..1] | +------------+ > | localIpAddress[0..*] {SCTP only} | > | timedReliability = 0 {SCTP only} | > | numberOfStreams {opt.} {SCTP only} | > | sourceIpAddress[0..1] {UDP only} | > | templateRefreshTimeout = 600 {UDP only} | > | optionsTemplateRefreshTimeout = 600 {UDP only} | > | templateRefreshPacket[0..1] {UDP only} | > | optionsTemplateRefreshPacket[0..1] {UDP only} | > +------------------------------------------------+ > > Figure 14: Destination class > > The Destination class shown in Figure 14 contains the configuration > parameters of one export destination (i.e., Collector) the Exporting > Process sends IPFIX Messages to. Some of the parameters are only > applicable if a specific transport protocol (SCTP, UDP, or TCP) is > used. The following parameters apply to all transport protocols: > > exportMemberType: Configures the export member type that corresponds > to the ipfixTransportSessionGroupMemberType object in > [I-D.ietf-ipfix-mib]. The following parameter values are > specified by the configuration data model: > * primary: primary target of the Exporting Process > * secondary: secondary target of the Exporting Process used when > the primary target is not reachable > * parallel: parallel exporting to all destinations and files of > the Exporting Process > * loadBalancing: load-balancing between different destinations > and files of the Exporting Process > "parallel" is the default value if this parameter is not > configured. If one destination or file is configured as "primary" > target, all other destinations and files must be configured as > "secondary" targets. If "parallel" or "loadBalancing" is used, > the same type must be configured for all destinations and File > Writers of the Exporting Process. > > ipfixVersion: Version number of the IPFIX protocol used. If > omitted, the default value is 10 (=0x000a) as specified in > [RFC5101]. > > transportProtocol: One of "sctp", "udp", and "tcp". > > destinationIpAddress, destinationPort: Destination IP address and > destination port number to be used. destinationIpAddress is a > mandatory parameter. If destinationPort is omitted, standard port > 4739 (IPFIX without TLS and DTLS) or 4740 (IPFIX over TLS or DTLS) > is used. > > sendBufferSize: Size of the socket send buffer in bytes. > > rateLimit: Maximum number of bytes per second the Exporting Process > may export to the given destination as required by [RFC5476]. The > number of bytes is calculated from the lengths of the IPFIX > Messages exported. If this parameter is not configured, no rate > limiting is performed for this destination. > > The following parameters are applicable if SCTP is transport > protocol: > > localIpAddress: This optional parameter MAY appear multiple times to > specify the list of eligible local IP addresses of the SCTP > association [RFC4960]. If omitted, all locally assigned IP > addresses are used by the SCTP endpoint. > > timedReliability: Lifetime in milliseconds until an IPFIX Message > containing Data Sets only is "abandoned" due to the timed > reliability mechanism of PR-SCTP [RFC3758]. If this parameter is > set to zero, reliable SCTP transport is used. > > numberOfStreams: Number of outbound streams requested for SCTP > associations [RFC4960]. If not configured by the user, this > parameter is set by the Monitoring Device. > > The following parameters are applicable if UDP is transport protocol: > > sourceIpAddress: This parameter sets the source IP address. If this > parameter is omitted, the address assigned to the outgoing > interface is used. > I would like to make available in the case of TCP. > templateRefreshTimeout, optionsTemplateRefreshTimeout, > templateRefreshPacket, optionsTemplateRefreshPacket: Template > refresh parameters when using UDP as transport protocol. > templateRefreshTimeout and optionsTemplateRefreshTimeout are > specified in seconds between resendings of (Options) Templates. > If omitted, the default value of 600 seconds (10 minutes) is used > [RFC5101]. templateRefreshPacket and optionsTemplateRefreshPacket > are specified in number of IPFIX Messages. If omitted, the > (Options) Templates are only resent after timeout. > > Using the TransportLayerSecurity class, transport layer security is > enabled and configured for this export destination. If the transport > protocol is SCTP or UDP, transport layer security is realized using > DTLS. In the case of TCP, TLS is used instead. > > 4.4.2. FileWriter Class > > +-----------------------------+ > | FileWriter | > +-----------------------------+ > | name | > | exportMemberType = parallel | > | ipfixVersion = 10 | > | file | > +-----------------------------+ > > Figure 15: FileWriter classes > > Instead of exporting IPFIX Messages to remote destinations, the > Exporting Process can write them to a file as proposed in > [I-D.ietf-ipfix-file]. The FileWriter class contains the > configuration parameters for writing the IPFIX Messages to a specific > file: > > exportMemberType: Same parameter as in the Destination class. The > File Writers of an Exporting Process belong to the same Transport > Session group as any destination configured for the same Exporting > Process. > > ipfixVersion: Version number of the IPFIX protocol used. If > omitted, the default value is 10 (=0x000a) as specified in > [RFC5101]. > > file: File name and location specified as URI. > > 4.4.3. Options Class > > +-----------------------+ > | Options | > +-----------------------+ > | name | > | optionsType | > | optionsTimeout {opt.} | > +-----------------------+ > > Figure 16: Options class > > The Options class in Figure 16 defines the type of specific > information to be reported, such as statistics, flow keys, Sampling > and Filtering parameters etc. [RFC5101] and [RFC5476] specify > several types of reporting information which may be exported. The > following parameter values are specified by the configuration data > model: > > meteringStatistics: Export of Metering Process statistics using the > Metering Process Statistics Options Template [RFC5101]. > > meteringReliability: Export of Metering Process reliability > statistics using the Metering Process Reliability Statistics > Options Template [RFC5101]. > > exportingReliability: Export of Exporting Process reliability > statistics using the Exporting Process Reliability Statistics > Options Template [RFC5101]. > > flowKeys: Export of the Flow Key specification using the Flow Keys > Options Template [RFC5101]. > > selectionSequence: Export of Selection Sequence Report > Interpretation and Selector Report Interpretation [RFC5476]. > > selectionStatistics: Export of Selection Sequence Statistics Report > Interpretation [RFC5476]. > > accuracy: Export of Accuracy Report Interpretation [RFC5476]. > > reducingRedundancy: Export of common properties according to > [RFC5473]. > > The Exporting Process MUST choose a template definition according to > the options type and available options data. > > The optionsTimeout parameter specifies the reporting interval (in > milliseconds) for periodic export of the option data. A parameter > value of zero means that the export of the option data is not > triggered periodically, but whenever the available option data has > changed. This is the typical setting for options types flowKeys, > selectionSequence, accuracy, and reducingRedundancy. If > optionsTimeout is not configured by the user, it is set by the > Monitoring Device. > > 4.5. CollectingProcess Class > > +-------------------+ > | CollectingProcess | > +-------------------+ > | name | 0..* +------------------+ > | |<>----------| Receiver | > | | +------------------+ > | | > | | 0..* +------------------+ > | |<>----------| FileReader | > | | +------------------+ > | | > | | 0..* 0..* +------------------+ > | |----------->| ExportingProcess | > | | +------------------+ > | | > | | 0..* +------------------+ > | |<>----------| TransportSession | > +-------------------+ +------------------+ > > Figure 17: CollectingProcess class > > Figure 17 shows the CollectingProcess class that contains the > configuration and state parameters of a Collecting Process. Objects > of the Receiver class specify how IPFIX Messages are received from > remote Exporters. The Collecting Process can also be configured as a > File Reader using objects of the FileReader class. > > As state data, the CollectingProcess class contains the list of > Transport Sessions that terminate at the Collecting Process. The > TransportSession class is specified in Section 4.7. > > An CollectingProcess object MAY refer to one or multiple > ExportingProcess objects configuring Exporting Processes that export > the received data without modifications to a file or to another > Collector. > > 4.5.1. Receiver Class > > +--------------------------------------+ > | Receiver | > +--------------------------------------+ 0..1 +------------+ > | name |<>------| Transport- | > | transportProtocol | | Layer- | > | localIpAddress[0..*] | | Security | > | localPort = 4739|4740 | +------------+ > | maxAllowedStreams {opt.} {SCTP only} | > | templateLifetime = 1800 {UDP only} | > +--------------------------------------+ > > Figure 18: Receiver class > > The Receiver class contains the configuration parameters of a > listening socket of the Collecting Process. Some of the parameters > are specific to the transport protocol. The parameters are as > follows: > > transportProtocol: One of "sctp", "udp", and "tcp". > > localIpAddress: Local IP addresses the socket is bound to. If > ipAddress is omitted, the socket is bound to all local IP > addresses. In the case of SCTP, the local IP addresses correspond > to the eligible local IP addresses used by the local SCTP endpoint > [RFC4960]. > > localPort: Local port number. If omitted, standard port 4739 (IPFIX > without TLS and DTLS) or 4740 (IPFIX over TLS or DTLS) is used. > > maxAllowedStreams (available if transport protocol is SCTP): Maximum > number of allowed inbound streams per SCTP association. If not > configured by the user, this parameter is set by the Monitoring > Device. > > templateLifetime (available if transport protocol is UDP): Template > lifetime if UDP is used as transport protocol. If not configured, > the default value 1800 is used, which is three times the default > Template refresh timeout (see Section 4.4) as specified in > [RFC5101]. > > Using the TransportLayerSecurity class, transport layer security > using DTLS and TLS is enabled and configured for this listening > socket of the Collecting Process. If the transport protocol is SCTP > or UDP, transport layer security is realized using DTLS. In the case > of TCP, TLS is used instead. > > 4.5.2. FileReader Class > > +------------+ > | FileReader | > +------------+ > | name | > | file | > +------------+ > > Figure 19: FileReader classes > > The Collecting Process may import IPFIX Messages from a file as > proposed in [I-D.ietf-ipfix-file]. The FileReader class defines the > configuration parameter: > > file: File name and location specified as URI. > > 4.6. Transport Layer Security Class > > +--------------------------------------+ > | TransportLayerSecurity | > +--------------------------------------+ > | localCertificationAuthorityDN[0..*] | > | localSubjectDN[0..*] | > | localSubjectFQDN[0..*] | > | remoteCertificationAuthorityDN[0..*] | > | remoteSubjectDN[0..*] | > | remoteSubjectFQDN[0..*] | > +--------------------------------------+ > > Figure 20: TransportLayerSecurity class > > The TransportLayerSecurity class is used in the Exporting Process's > Destination class and the Collecting Process's Receiver class to > enable and configure transport layer security for IPFIX. Transport > layer security can be enabled without configuring any additional > parameters. In this case, an empty XML element > appears in the configuration. If > transport layer security is enabled, the endpoint must use DTLS > [RFC4347] if the transport protocol is SCTP or UDP, and TLS [RFC5246] > if the transport protocol is TCP. > > [RFC5101] mandates strong mutual authentication of Exporting > Processes and Collecting Process: > > "IPFIX Exporting Processes and IPFIX Collecting Processes are > identified by the fully qualified domain name of the interface on > which IPFIX Messages are sent or received, for purposes of X.509 > client and server certificates as in [RFC3280]. > > To prevent man-in-the-middle attacks from impostor Exporting or > Collecting Processes, the acceptance of data from an unauthorized > Exporting Process, or the export of data to an unauthorized > Collecting Process, strong mutual authentication via asymmetric > keys MUST be used for both TLS and DTLS. Each of the IPFIX > Exporting and Collecting Processes MUST verify the identity of its > peer against its authorized certificates, and MUST verify that the > peer's certificate matches its fully qualified domain name, or, in > the case of SCTP, the fully qualified domain name of one of its > endpoints. > > The fully qualified domain name used to identify an IPFIX > Collecting Process or Exporting Process may be stored either in a > subjectAltName extension of type dNSName, or in the most specific > Common Name field of the Subject field of the X.509 certificate. > If both are present, the subjectAltName extension is given > preference." > > In order to use transport layer security, appropriate certificates > and keys have to be previously installed on the Monitoring Devices. > For security reasons, the configuration data model does not offer the > possibility to upload any certificates or keys on a Monitoring > Device. If transport layer security is enabled on a Monitoring > Device which does not dispose of appropriate certificates and keys, > the configuration MUST be rejected with an error. > > The configuration data model allows restricting the authorization of > remote endpoints to certificates issued by specific certification > authorities or identifying specific fully qualified domain names for > authorization. Furthermore, the configuration data model allows > restricting the utilization of certificates identifying the local > endpoint. This is useful if the Monitoring Device disposes of more > than one certificate for the given local endpoint. > > The configuration parameters are defined as follows: > > localCertificationAuthorityDN: This parameter MAY appear one or > multiple times to restrict the identification of the local > endpoint during the TLS/DTLS handshake to certificates issued by > the configured certification authorities. Each occurrence of this > parameter contains the distinguished name of one certification > authority. > To identify the local endpoint, the Exporting Process or > Collecting Process MUST use a certificate issued by one of the > configured certification authority. Certificates issued by any > other certification authority MUST NOT be sent to the remote peer > during TLS/DTLS handshake. If none of the certificates installed > on the Monitoring Device fulfills the specified restrictions, the > configuration MUST be rejected with an error. > If localCertificationAuthorityDN is not configured, the choice of > certificates identifying the local endpoint is not restricted with > respect to the issuing certification authority. > > localSubjectDN, localSubjectFQDN: Each of these parameters MAY > appear one or multiple times to restrict the identification of the > local endpoint during the TLS/DTLS handshake to certificates > issued for specific subjects or for specific fully qualified > domain names. Each occurrence of localSubjectDN contains a > distinguished name identifying the local endpoint. Each > occurrence of localSubjectFQDN contains a fully qualified domain > name which is assigned to the local endpoint. > To identify the local endpoint, the Exporting Process or > Collecting Process MUST use a certificate that contains either one > of the configured distinguished names in the subject field or at > least one of the configured fully qualified domain names in a > dNSName component of the subject alternative extension field or in > the most specific commonName component of the subject field. If > none of the certificates installed on the Monitoring Device > fulfills the specified restrictions, the configuration MUST be > rejected with an error. > If any of the parameters localSubjectDN and localSubjectFQDN is > configured at the same time as the localCertificationAuthorityDN > parameter, certificates MUST also fulfill the specified > restrictions regarding the certification authority. > If localSubjectDN and localSubjectFQDN are not configured, the > choice of certificates identifying the local endpoint is not > restricted with respect to the subject's distinguished name or > fully qualified domain name. > > remoteCertificationAuthorityDN: This parameter MAY appear one or > multiple times to restrict the authentication of remote endpoints > during the TLS/DTLS handshake to certificates issued by the > configured certification authorities. Each occurrence of this > parameter contains the distinguished name of one certification > authority. > To authenticate the remote endpoint, the remote Exporting Process > or Collecting Process MUST provide a certificate issued by one of > the configured certification authority. Certificates issued by > any other certification authority MUST be rejected during TLS/DTLS > handshake. > If the Monitoring Device is not able to validate certificates > issued by the configured certification authorities (e.g., because > of missing public keys), the configuration must be rejected with > an error. > > If remoteCertificationAuthorityDN is not configured, the > authorization of remote endpoints is not restricted with respect > to the issuing certification authority of the delivered > certificate. > > remoteSubjectDN, remoteSubjectFQDN: Each of these parameters MAY > appear one or multiple times to restrict the authentication of > remote endpoints during the TLS/DTLS handshake to certificates > issued for specific subjects or for specific fully qualified > domain names. Each occurrence of remoteSubjectDN contains a > distinguished name identifying a remote endpoint. Each occurrence > of remoteSubjectFQDN contains a fully qualified domain name which > is assigned to a remote endpoint. > To authenticate a remote endpoint, the remote Exporting Process or > Collecting Process MUST provide a certificate that contains either > one of the configured distinguished names in the subject field or > at least one of the configured fully qualified domain names in a > dNSName component of the subject alternative extension field or in > the most specific commonName component of the subject field. > Certificates not fulfilling this condition MUST be rejected during > TLS/DTLS handshake. > If any of the parameters remoteSubjectDN and remoteSubjectFQDN is > configured at the same time as the remoteCertificationAuthorityDN > parameter, certificates MUST also fulfill the specified > restrictions regarding the certification authority in order to be > accepted. > If remoteSubjectDN and remoteSubjectFQDN are not configured, the > authorization of remote endpoints is not restricted with respect > to the subject's distinguished name or fully qualified domain name > of the delivered certificate. > > > 4.7. Transport Session Class > > +------------------------------------------------------+ > | TransportSession | > +------------------------------------------------------+ > | exportMemberType {readOnly} {Exporting Process only} |<>----+ 0..* > | ipfixVersion {readOnly} | | > | protocol {readOnly} {except File Reader/Writer} | +----------+ > | sourceAddress {readOnly} {except File Reader/Writer} | | Template | > | destinationAddress {readOnly} | +----------+ > | {except File Reader/Writer} | > | sourcePort {readOnly} {except File Reader/Writer} | > | destinationPort {readOnly} | > | {except File Reader/Writer} | > | sctpAssocId {readOnly} {SCTP only} | > | file {readOnly} {File Reader/Writer only} | > | templateRefreshTimeout {readOnly} {UDP only} | > | optionsTemplateRefreshTimeout {readOnly} {UDP only} | > | templateRefreshPacket {readOnly} {UDP only} | > | optionsTemplateRefreshPacket {readOnly} {UDP only} | > | status {readOnly} | > | rate {readOnly} | > | packets {readOnly} | > | bytes {readOnly} | > | messages {readOnly} | > | discardedMessages {readOnly} | > | records {readOnly} | > | templates {readOnly} | > | optionsTemplates {readOnly} | > | transportSessionDiscontinuityTime {readOnly} | > +------------------------------------------------------+ > > Figure 21: TransportSession class > > The TransportSession class contains state data about Transport > Sessions originating from an Exporting Process or terminating at a > Collecting Process. The names and semantics of the state parameters > correspond to the managed objects in the ipfixTransportSessionTable > and ipfixTransportSessionStatsTable of the IPFIX MIB module > [I-D.ietf-ipfix-mib]. Hence, if these state parameters are queried > from the Monitoring Device, the corresponding IPFIX MIB values can be They can be queried from other management device. > returned without any further processing. The MIB object > ipfixTransportSessionDeviceMode is not included in the > TransportSession class because its value can be derived from the > scope in which a TransportSession object appears: exporting(1) if it > belongs to an Exporting Process, collecting(2) if it belongs to a > Collecting Process. > > The state parameter exportMemberType is only available if the > TransportSession class is used within the ExportingProcess class. > exportMemberType then contains the value of the MIB object > ipfixExportMemberType of the ipfixExportTable of the IPFIX MIB > [I-D.ietf-ipfix-mib]. > The Destination already has exportMemberType. What is relation between two object between the object in Destination class and one in this class? > The TransportSession class is also used for state data of File > Readers and File Writers. In this case, the "file" parameter > specifies the name and location of the file as URI. To avoid > ambiguities, the parameters "protocol", "sourceAddress", > "destinationAddress", "sourcePort", "destinationPort", and > "sctpAssocId" MUST NOT appear if the parameter "file" is present. > The parameter "file" MUST NOT appear if at least one of the > parameters "protocol", "sourceAddress", "destinationAddress", > "sourcePort", "destinationPort", and "sctpAssocId" is present. Note > that the parameter "file" is currently not included in the IPFIX MIB. > The above paragraph can be removed. Because you already have File Reader and Writer class. > 4.7.1. Template Class > > +--------------------------------------+ > | Template | > +--------------------------------------+ > | observationDomainId {readOnly} |<>---+ 0..* > | templateId {readOnly} | | > | setId {readOnly} | | > | accessTime {readOnly} | | > | templateDataRecords {readOnly} | | > | templateDiscontinuityTime {readOnly} | | > +--------------------------------------+ | > | > +-------------------------------+ > | Field | > +-------------------------------+ > | ieId {readOnly} | > | ieLength {readOnly} | > | ieEnterpriseNumber {readOnly} | > | flags {readOnly} | > +-------------------------------+ > > Figure 22: Template class > > The Template class contains state data about Templates used by an > Exporting Process or received by a Collecting Process in a specific > Transport Session. The Field class defines one field of the > Template. The names and semantics of the state parameters correspond > to the managed objects in the ipfixTemplateTable, > ipfixTemplateDefinitionTable, and ipfixTemplateStatsTable of the > IPFIX MIB module [I-D.ietf-ipfix-mib]. Hence, if these state > parameters are queried from the Monitoring Device, the corresponding > IPFIX MIB values can be returned without any further processing. > > > 5. Adaptation to Device Capabilities > > The configuration data model standardizes a superset of common IPFIX > and PSAMP configuration parameters. A typical Monitoring Device > implementation will not support the entire range of possible > configurations. Certain functions may not be supported, such as the > Collecting Process that does not exist on a Monitoring Device > conceived as Exporter only. The configuration of other functions may > be subject to resource limitations. For example, the Cache size is > typically limited according to the available memory on the device. > > YANG [I-D.ietf-netmod-yang] offers several possibilities to restrict > and adapt a configuration data model. The current version of YANG > defines the concepts of "features" and "deviations". > > The feature concept allows the modeler to make proportions of the > model conditional in a manner that is controlled by the device. > Devices do not have to support these conditional parts to conform to > the model. Those features that are supported by a device must be > announced in the message of the NETCONF protocol [RFC4741]. > > The configuration data model for IPFIX and PSAMP covers the > configuration of Exporters, Collectors, and devices that may act as > both. As Exporters and Collectors implement different functions, the > corresponding proportions of the model are conditional on the > following features: > > exporter: If this feature is supported, Exporting Processes can be > configured. > > collector: If this feature is supported, Collecting Processes can be > configured. > > Exporters do not necessarily implement any Selection Processes, > Caches, or even Observation Points in particular cases. Therefore, > the corresponding proportions of the model are conditional on the > following feature: > > meter: If this feature is supported, Observation Points, Selection > Processes, and Caches can be configured. > > Additional features refer to different PSAMP Sampling and Filtering > methods: > > psampSampCountBased: If this feature is supported, Sampling method > sampCountBased can be configured. > > psampSampTimeBased: If this feature is supported, Sampling method > sampTimeBased can be configured. > > psampSampRandOutOfN: If this feature is supported, Sampling method > sampRandOutOfN can be configured. > > psampSampUniProb: If this feature is supported, Sampling method > sampUniProb can be configured. > > psampFilterMatch: If this feature is supported, Filtering method > filterMatch can be configured. > > psampFilterHash: If this feature is supported, Filtering method > filterHash can be configured. > > The following features concern the support of UDP and TCP as > transport protocols and the support of File Readers and File Writers: > > udpTransport: If this feature is supported, UDP can be used as > transport protocol by Exporting Processes and Collecting > Processes. > > tcpTransport: If this feature is supported, TCP can be used as > transport protocol by Exporting Processes and Collecting > Processes. > > fileReader: If this feature is supported, Collecting Processes can > be configured as File Readers. > > fileReader: If this feature is supported, Exporting Processes can be ^^^^^^^^^^ fileWriter? > configured as File Writers. > > The deviation concept enables a device to announce deviations from > the standard model. Deviations are typically used to specify > limitations due to resource constraints. Deviations concern existing > parameters of the standard model and must not be confused with model > extensions that are realized with the YANG statement "augment". Just > like features, deviations are announced in NETCONF's message. > A usage example of deviations is given in Section 7.5. > > Regards, Atsushi --- Atsushi KOBAYASHI NTT Information Sharing Platform Lab. tel:+81-(0)422-59-3978 fax:+81-(0)422-59-5637 From root@core3.amsl.com Thu Dec 10 03:30:01 2009 Return-Path: X-Original-To: ipfix@ietf.org Delivered-To: ipfix@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id 8D9333A6781; Thu, 10 Dec 2009 03:30:01 -0800 (PST) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20091210113001.8D9333A6781@core3.amsl.com> Date: Thu, 10 Dec 2009 03:30:01 -0800 (PST) Cc: ipfix@ietf.org Subject: [IPFIX] I-D Action:draft-ietf-ipfix-mib-09.txt X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Dec 2009 11:30:01 -0000 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IP Flow Information Export Working Group of the IETF. Title : Definitions of Managed Objects for IP Flow Information Export Author(s) : T. Dietz, et al. Filename : draft-ietf-ipfix-mib-09.txt Pages : 68 Date : 2009-12-10 This document defines managed objects for IP Flow Information Export (IPFIX). These objects provide information for monitoring IPFIX Exporters and IPFIX Collectors including the basic configuration information. 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 June 13, 2010. Copyright Notice Copyright (c) 2009 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 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 BSD License. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ipfix-mib-09.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-ipfix-mib-09.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2009-12-10032210.I-D@ietf.org> --NextPart-- From Thomas.Dietz@nw.neclab.eu Thu Dec 10 03:58:13 2009 Return-Path: X-Original-To: ipfix@core3.amsl.com Delivered-To: ipfix@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5043828C0E7 for ; Thu, 10 Dec 2009 03:58:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.152 X-Spam-Level: X-Spam-Status: No, score=-2.152 tagged_above=-999 required=5 tests=[AWL=0.447, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id INrZyAQ56Wy4 for ; Thu, 10 Dec 2009 03:58:12 -0800 (PST) Received: from smtp0.neclab.eu (smtp0.neclab.eu [195.37.70.41]) by core3.amsl.com (Postfix) with ESMTP id 80CB528C0E5 for ; Thu, 10 Dec 2009 03:58:11 -0800 (PST) Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp0.neclab.eu (Postfix) with ESMTP id CD9082C01CB09 for ; Thu, 10 Dec 2009 12:57:59 +0100 (CET) X-Virus-Scanned: Amavisd on Debian GNU/Linux (atlas2.office) Received: from smtp0.neclab.eu ([127.0.0.1]) by localhost (atlas2.office [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fifCYOx88KHv for ; Thu, 10 Dec 2009 12:57:59 +0100 (CET) Received: from VENUS.office (mx2.office [192.168.24.15]) by smtp0.neclab.eu (Postfix) with ESMTP id 9D55A2C01C9B0 for ; Thu, 10 Dec 2009 12:57:54 +0100 (CET) Content-class: urn:content-classes:message MIME-Version: 1.0 X-MimeOLE: Produced By Microsoft Exchange V6.5 Date: Thu, 10 Dec 2009 12:57:53 +0100 Content-Type: multipart/signed; boundary="----=_NextPart_000_005D_01CA7998.62C75160"; micalg=SHA1; protocol="application/x-pkcs7-signature" Message-ID: <547F018265F92642B577B986577D671CF678D7@VENUS.office> In-Reply-To: <20091210113001.8D9333A6781@core3.amsl.com> X-MS-Has-Attach: yes X-MS-TNEF-Correlator: Thread-Topic: [IPFIX] I-D Action:draft-ietf-ipfix-mib-09.txt Thread-Index: Acp5jFIp4b1qes5hSn2rDRGuq2zWswAA10yg References: <20091210113001.8D9333A6781@core3.amsl.com> From: "Thomas Dietz" To: Subject: Re: [IPFIX] I-D Action:draft-ietf-ipfix-mib-09.txt X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Dec 2009 11:58:13 -0000 This is a multi-part message in MIME format. ------=_NextPart_000_005D_01CA7998.62C75160 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Dear all, This is the new version of the IPFIX MIB with the changes discussed at the last IETF. The MIB has now a Observation Domain ID in the ObservationPointGroup table. Also the references in this table to the ENTITY MIB and IF MIB were made clearer. We hope to have a final version now. Best Regards, Thomas -- Thomas Dietz E-mail: Thomas.Dietz@nw.neclab.eu NEC Europe Ltd. Phone: +49 6221 4342-128 NEC Laboratories Europe Fax: +49 6221 4342-155 Network Research Division Kurfuersten-Anlage 36 69115 Heidelberg, Germany http://www.nw.neclab.eu NEC Europe Limited Registered in England 2832014 Registered Office: NEC House, 1 Victoria Road, London W3 6BL > -----Original Message----- > From: ipfix-bounces@ietf.org [mailto:ipfix-bounces@ietf.org] On Behalf > Of Internet-Drafts@ietf.org > Sent: Donnerstag, 10. Dezember 2009 12:30 > To: i-d-announce@ietf.org > Cc: ipfix@ietf.org > Subject: [IPFIX] I-D Action:draft-ietf-ipfix-mib-09.txt > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > This draft is a work item of the IP Flow Information Export Working > Group of the IETF. > > > Title : Definitions of Managed Objects for IP Flow > Information Export > Author(s) : T. Dietz, et al. > Filename : draft-ietf-ipfix-mib-09.txt > Pages : 68 > Date : 2009-12-10 > > This document defines managed objects for IP Flow Information Export > (IPFIX). These objects provide information for monitoring IPFIX > Exporters and IPFIX Collectors including the basic configuration > information. > > 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 June 13, 2010. > > Copyright Notice > > Copyright (c) 2009 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 > 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 BSD License. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-ipfix-mib-09.txt > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > Below is the data which will enable a MIME compliant mail reader > implementation to automatically retrieve the ASCII version of the > Internet-Draft. ------=_NextPart_000_005D_01CA7998.62C75160 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIISNzCCA58w ggKHoAMCAQICASYwDQYJKoZIhvcNAQEFBQAwcTELMAkGA1UEBhMCREUxHDAaBgNVBAoTE0RldXRz Y2hlIFRlbGVrb20gQUcxHzAdBgNVBAsTFlQtVGVsZVNlYyBUcnVzdCBDZW50ZXIxIzAhBgNVBAMT GkRldXRzY2hlIFRlbGVrb20gUm9vdCBDQSAyMB4XDTk5MDcwOTEyMTEwMFoXDTE5MDcwOTIzNTkw MFowcTELMAkGA1UEBhMCREUxHDAaBgNVBAoTE0RldXRzY2hlIFRlbGVrb20gQUcxHzAdBgNVBAsT FlQtVGVsZVNlYyBUcnVzdCBDZW50ZXIxIzAhBgNVBAMTGkRldXRzY2hlIFRlbGVrb20gUm9vdCBD QSAyMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAqwujNeCLKRSxFIWvPBDkOW81XUqu 3ephjZVJ9G9koxpgZqSpQCKE2dSl5XiTDmgBrblNXDrO07ioQkDfz6O6gllqkhusHJraCCslJ/lp I0fx4Ossepv1EwLQfjR8wp48AFmr9doM9TI8K6xQ2tbD3oOUyqgMmTIOCEhWW2r72uFYWAFJX3JB PBUGAY5draq4k7TNnuun6GotUjTbOu9cdVHa2/Mx+e5xmDLEVBVEDPmbVe2t3xgIoKOGiknuUwWP GUzV3lh5m9JqHEKrxdWnz2gPluThYZh2YciRfNY+AOKRUIfhnQrmrZfSHcY6fcu82gM01Y5bAfVq B7cWtm5KfwIDAQABo0IwQDAdBgNVHQ4EFgQUMcN5G7r1U9cX4Il6LRdsCrMrnTMwDwYDVR0TBAgw BgEB/wIBBTAOBgNVHQ8BAf8EBAMCAQYwDQYJKoZIhvcNAQEFBQADggEBAJRkWa05ZOcp6xP+WsOL E1fIBCTwdHfAYONn++mJpoO/loJ8btTDPe+egG67KbSYerE7VOs5F0d+Go4L/B8xWTEEss4X8yzH YjZV4iLYiVW0mEiqZPrWHDbYRHhaWiM6V5f1ejBPrp9qTEsrjqAD4z7gqdTSe9KzqOJyPK2e/4BZ 5JtFtPY7sM05GZgy5eohYZDkMSGONLH3LzVKhRDa54o3Ib5ZY+DyhYgxU9RUFIVwefQuBncndS8f uIr5/sW62Dbkg+znZbe/Y1rzRq+BlDfUQYzWI9Yez/VoG0Rjolq6pzVZoeVwBZsOI1eZlAptujlj KIaS8xiE2PvRzwVWZFcwggQhMIIDCaADAgECAgIAxzANBgkqhkiG9w0BAQUFADBxMQswCQYDVQQG EwJERTEcMBoGA1UEChMTRGV1dHNjaGUgVGVsZWtvbSBBRzEfMB0GA1UECxMWVC1UZWxlU2VjIFRy dXN0IENlbnRlcjEjMCEGA1UEAxMaRGV1dHNjaGUgVGVsZWtvbSBSb290IENBIDIwHhcNMDYxMjE5 MTAyOTAwWhcNMTkwNjMwMjM1OTAwWjBaMQswCQYDVQQGEwJERTETMBEGA1UEChMKREZOLVZlcmVp bjEQMA4GA1UECxMHREZOLVBLSTEkMCIGA1UEAxMbREZOLVZlcmVpbiBQQ0EgR2xvYmFsIC0gRzAx MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA6ZvDZ4X5Da71jVTDllA1PWLpbkztlNcA W5UidNQg6zSP1uzAMQQLmYHiphTSUqAoI4SLdIkEXlvg4njBeMsWyyg1OXstkEXQ7aAAeny/Sg4b AMOG6VwrMRF7DPOCJEOMHDiLamgAmu7cT3ir0sYTm3at7t4m6O8Br3QPwQmi9mvOvdPNFDBP9eXj pMhim4IaAycwDQJlYE3t0QkjKpY1WCfTdsZxtpAdxO3/NYZ9bzOz2w/FEcKKg6GUXUFr2NIQ9Uz9 ylGs2b3vkoO72uuLFlZWQ8/h1RM9ph8nMM1JVNvJEzSacXXFbOqnC5j5IZ0nrz6jOTlIaoytyZn7 wxLyvQIDAQABo4HZMIHWMHAGA1UdHwRpMGcwZaBjoGGGX2h0dHA6Ly9wa2kudGVsZXNlYy5kZS9j Z2ktYmluL3NlcnZpY2UvYWZfRG93bmxvYWRBUkwuY3JsPy1jcmxfZm9ybWF0PVhfNTA5Ji1pc3N1 ZXI9RFRfUk9PVF9DQV8yMB0GA1UdDgQWBBRJt8bP6D0ff+pEexMp9/EKcD7eZDAfBgNVHSMEGDAW gBQxw3kbuvVT1xfgiXotF2wKsyudMzAOBgNVHQ8BAf8EBAMCAQYwEgYDVR0TAQH/BAgwBgEB/wIB AjANBgkqhkiG9w0BAQUFAAOCAQEAO+Fad8BIF9ypGOyBr1qJ8L0okqbKWRgScOwo8ueuf5Ys5/Jd GTH2Eyt0vb2Asrn3Z8k5onk74RER7mt4kTN+O18mJ3VTZY4zY+7Pc8OwkiNJIVB1I6EfGOKUhT0/ M+l3II2iveahhSlA9j9zMlgNCWum2oVswD+7jWZkViROrg0/MjUBW+mMgtlyWU+xhoXxdIVW5cP4 XPON7kezUwVw5+VNimmDKOETCYaeXsjqWB4MH/mk1FoEaP0oPosCtli19qEsN1cAZ6sjaI1jpe+Z a1z9S1b2q0CHNNQRkmzsh8UKCwczcrRvDB1ULNhRx8y/MNNDcvEyv4zOSWOoAPfyHDCCBS8wggQX oAMCAQICBA0hCkcwDQYJKoZIhvcNAQEFBQAwWjELMAkGA1UEBhMCREUxEzARBgNVBAoTCkRGTi1W ZXJlaW4xEDAOBgNVBAsTB0RGTi1QS0kxJDAiBgNVBAMTG0RGTi1WZXJlaW4gUENBIEdsb2JhbCAt IEcwMTAeFw0wODEwMjQwODUyMDhaFw0xOTA2MzAwMDAwMDBaMIGQMQswCQYDVQQGEwJERTEYMBYG A1UEChMPTkVDIEV1cm9wZSBMdGQuMSAwHgYDVQQLExdORUMgTGFib3JhdG9yaWVzIEV1cm9wZTES MBAGA1UEAxMJTkVDTEFCLUNBMTEwLwYJKoZIhvcNAQkBFiJ6ZXJ0aWZpemllcnVuZ3NzdGVsbGVA bncubmVjbGFiLmV1MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAnvIVsbURqjIOcbnf ruYkRceWOZpyvM2ebnYpbd1cP+zdWm6yR7HSO9ppOe1ZZFIasArqQpedPEFvcncSG94FRuW3ND4r Rcq08mbpUTmpWmXfdYlJpQezbsOHCWR74NXoEEbK6TPZIMFpJr6dzQDAxnRc7UOgO6JQ1V42Z39B PhIbPIWz64t8svafxbORmxulJn7F5zDLDcR1AEGyn+L9b645AGwapoKNh7cSQFTqdb6kGyPQjLWf tv09dvmBDKesrcyLZXuDWJ1LMeizSjUEygdSszNXD3gePgJaVaZDS3o923W5gAyPCTSxpAFj8XJ+ /7Ap5jJwYhjJgJ8khFR7JQIDAQABo4IBxDCCAcAwEgYDVR0TAQH/BAgwBgEB/wIBATALBgNVHQ8E BAMCAQYwHQYDVR0OBBYEFE8ch3od4C+Z9r4VqtE1nQ5K5ro2MB8GA1UdIwQYMBaAFEm3xs/oPR9/ 6kR7Eyn38QpwPt5kMC0GA1UdEQQmMCSBInplcnRpZml6aWVydW5nc3N0ZWxsZUBudy5uZWNsYWIu ZXUwgYgGA1UdHwSBgDB+MD2gO6A5hjdodHRwOi8vY2RwMS5wY2EuZGZuLmRlL2dsb2JhbC1yb290 LWNhL3B1Yi9jcmwvY2FjcmwuY3JsMD2gO6A5hjdodHRwOi8vY2RwMi5wY2EuZGZuLmRlL2dsb2Jh bC1yb290LWNhL3B1Yi9jcmwvY2FjcmwuY3JsMIGiBggrBgEFBQcBAQSBlTCBkjBHBggrBgEFBQcw AoY7aHR0cDovL2NkcDEucGNhLmRmbi5kZS9nbG9iYWwtcm9vdC1jYS9wdWIvY2FjZXJ0L2NhY2Vy dC5jcnQwRwYIKwYBBQUHMAKGO2h0dHA6Ly9jZHAyLnBjYS5kZm4uZGUvZ2xvYmFsLXJvb3QtY2Ev cHViL2NhY2VydC9jYWNlcnQuY3J0MA0GCSqGSIb3DQEBBQUAA4IBAQBsMQ+dD0mmi48dgDU4R6Q/ eXcY0zQcHNp1Vu1s3kwO0WahWB0tiqVBodvfTAWG44xuw0I7NXSTwQ68FU5P0GIQnvRFZyVJlDjr SNlLYxjqfmgb+KVm67o383cZIuDakEE0f29kULIEn2fg/HsDiBAXTsb4I19XaN0TXLI+PMhU+GDp sGCJrydeugEV7qi15q8yymjSAsYgnrc2wJuXpyQ9r3qCtP6aedAPSHqOT8ga1dLT2YRZFs3vNm7T HSr5JJymWMbfpD6OcbRTnNAjSMDHwJxgRBAflA6WzDVm7fk4jiWyLvJwWTMk19t8QLiKG7D0nYvj cEUYyiOSE+SFUTEdMIIFODCCBCCgAwIBAgIEDTI0WzANBgkqhkiG9w0BAQUFADCBkDELMAkGA1UE BhMCREUxGDAWBgNVBAoTD05FQyBFdXJvcGUgTHRkLjEgMB4GA1UECxMXTkVDIExhYm9yYXRvcmll cyBFdXJvcGUxEjAQBgNVBAMTCU5FQ0xBQi1DQTExMC8GCSqGSIb3DQEJARYiemVydGlmaXppZXJ1 bmdzc3RlbGxlQG53Lm5lY2xhYi5ldTAeFw0wODExMDYwOTIwMTFaFw0xMTExMDYwOTIwMTFaMGAx CzAJBgNVBAYTAkRFMRgwFgYDVQQKEw9ORUMgRXVyb3BlIEx0ZC4xIDAeBgNVBAsTF05FQyBMYWJv cmF0b3JpZXMgRXVyb3BlMRUwEwYDVQQDEwxUaG9tYXMgRGlldHowggEiMA0GCSqGSIb3DQEBAQUA A4IBDwAwggEKAoIBAQCniLuqlMflMs7ag3idESVRwfZ9nrdIyUmq5Tget4k9APGSPo2GZ1f1hr8y MuJIGowc/HzS1laVSICclOXju1xW93Tm+Vco5gwkRqHXY3Rmda0r2jlb8niVie4qXQgXPzunFRqk yNmbwYep3oD5Kq0GfB6EuZ7X6cYH5A7erAMeeQPhoDQDIfR79lRHlcMtanJZyORYNQONPEa+L4AF v5f3nAsmY7ZLJ72wX7X8BtcF6Vdkr0T2b1YrPl8Qir7e0TKY9Rf0q5DKu3QdLnXk0Rb+63V/4vLS PZ3XQVdwHzLiOhIZJVVMJE7TmJI0DFeDFn99O/F/Le/sJOJjNO4n6KMLAgMBAAGjggHHMIIBwzAJ BgNVHRMEAjAAMAsGA1UdDwQEAwIF4DApBgNVHSUEIjAgBggrBgEFBQcDAgYIKwYBBQUHAwQGCisG AQQBgjcUAgIwHQYDVR0OBBYEFLkbmpJJpIXhIR9JFttGC+KHW5g5MB8GA1UdIwQYMBaAFE8ch3od 4C+Z9r4VqtE1nQ5K5ro2MCQGA1UdEQQdMBuBGVRob21hcy5EaWV0ekBudy5uZWNsYWIuZXUwfQYD VR0fBHYwdDA4oDagNIYyaHR0cDovL2NkcDEucGNhLmRmbi5kZS9uZWNsYWItY2EvcHViL2NybC9j YWNybC5jcmwwOKA2oDSGMmh0dHA6Ly9jZHAyLnBjYS5kZm4uZGUvbmVjbGFiLWNhL3B1Yi9jcmwv Y2FjcmwuY3JsMIGYBggrBgEFBQcBAQSBizCBiDBCBggrBgEFBQcwAoY2aHR0cDovL2NkcDEucGNh LmRmbi5kZS9uZWNsYWItY2EvcHViL2NhY2VydC9jYWNlcnQuY3J0MEIGCCsGAQUFBzAChjZodHRw Oi8vY2RwMi5wY2EuZGZuLmRlL25lY2xhYi1jYS9wdWIvY2FjZXJ0L2NhY2VydC5jcnQwDQYJKoZI hvcNAQEFBQADggEBAEbKwRBhNxAzsH6kAYRBoIziyI2IY2QnZGeiGitOfkLKcFNIBH3ZfQXH4j20 4BP34Vzzob17EgsbLbNkMlxh2M7tenXH9vA4MiN5yPPBKoR7SfI6mIaIr+7kewOizJ8D5dvpdfP5 HbAUTZVSYHqixgBWJyNp7sXWVQtOo+eOv8qKUeiodClanKuCnGD42Bl6EQR486dlXvOronEikRYX Xg6gFrhO+DonUYluMZpNdabnybKozchSdHcceOKd0JFMmyiSNG944ystXbR7QZqfNSh/Pbyc5QRp Z1vdFZLFh907iS3KxueDYKDPWmlsPt/QnmXmF4A9/5OrmVS1C45k5rcxggQ4MIIENAIBATCBmTCB kDELMAkGA1UEBhMCREUxGDAWBgNVBAoTD05FQyBFdXJvcGUgTHRkLjEgMB4GA1UECxMXTkVDIExh Ym9yYXRvcmllcyBFdXJvcGUxEjAQBgNVBAMTCU5FQ0xBQi1DQTExMC8GCSqGSIb3DQEJARYiemVy dGlmaXppZXJ1bmdzc3RlbGxlQG53Lm5lY2xhYi5ldQIEDTI0WzAJBgUrDgMCGgUAoIICczAYBgkq hkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0wOTEyMTAxMTU3NTNaMCMGCSqG SIb3DQEJBDEWBBREOPmOvceZPXSbPbW+/SIdq1F9EjCBqgYJKwYBBAGCNxAEMYGcMIGZMIGQMQsw CQYDVQQGEwJERTEYMBYGA1UEChMPTkVDIEV1cm9wZSBMdGQuMSAwHgYDVQQLExdORUMgTGFib3Jh dG9yaWVzIEV1cm9wZTESMBAGA1UEAxMJTkVDTEFCLUNBMTEwLwYJKoZIhvcNAQkBFiJ6ZXJ0aWZp emllcnVuZ3NzdGVsbGVAbncubmVjbGFiLmV1AgQNMjRbMIGsBgsqhkiG9w0BCRACCzGBnKCBmTCB kDELMAkGA1UEBhMCREUxGDAWBgNVBAoTD05FQyBFdXJvcGUgTHRkLjEgMB4GA1UECxMXTkVDIExh Ym9yYXRvcmllcyBFdXJvcGUxEjAQBgNVBAMTCU5FQ0xBQi1DQTExMC8GCSqGSIb3DQEJARYiemVy dGlmaXppZXJ1bmdzc3RlbGxlQG53Lm5lY2xhYi5ldQIEDTI0WzCBtwYJKoZIhvcNAQkPMYGpMIGm MAsGCWCGSAFlAwQBKjALBglghkgBZQMEARYwCgYIKoZIhvcNAwcwCwYJYIZIAWUDBAECMA4GCCqG SIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDAHBgUrDgMC GjALBglghkgBZQMEAgMwCwYJYIZIAWUDBAICMAsGCWCGSAFlAwQCATAKBggqhkiG9w0CBTANBgkq hkiG9w0BAQEFAASCAQBF/K67MJtdpOp3PRLKwor52sbpeD4HZMFX8EEjerl3ddpZMvoGwnVo0WvZ UCSaVKzqjQ51Uk09/0nRos+KlfPFKhSTABH9X7UgLPUWFPh+uOqSlADiR1+F956WHzj5zKQo9E8T TOfpuCsZZIAojDJcqevQ8Nbcb68gx4Oy35sqrzzCT737gMyP2Mapq73gHax2RZEhD85gu5HvSh8D 2nG8+YR64dNgTdzjuWHuv7weTAOLY3wYfCFw1sfxmqI5xZ+bliHraonf4V1dISxQSdaH7OaIzJFE QiLX3THbRFeUJi+8tUQ0Kh1SyKSsSfwRzAkznngT/W5K/kTOxKSJdpm2AAAAAAAA ------=_NextPart_000_005D_01CA7998.62C75160-- From root@core3.amsl.com Thu Dec 10 17:45:01 2009 Return-Path: X-Original-To: ipfix@ietf.org Delivered-To: ipfix@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id C13F23A6886; Thu, 10 Dec 2009 17:45:01 -0800 (PST) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20091211014501.C13F23A6886@core3.amsl.com> Date: Thu, 10 Dec 2009 17:45:01 -0800 (PST) Cc: ipfix@ietf.org Subject: [IPFIX] I-D Action:draft-ietf-ipfix-mediators-problem-statement-07.txt X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Dec 2009 01:45:01 -0000 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IP Flow Information Export Working Group of the IETF. Title : IPFIX Mediation: Problem Statement Author(s) : A. Kobayashi, et al. Filename : draft-ietf-ipfix-mediators-problem-statement-07.txt Pages : 29 Date : 2009-12-10 Flow-based measurement is a popular method for various network monitoring usages. The sharing of flow-based information for monitoring applications having different requirements raises some open issues in terms of measurement system scalability, flow-based measurement flexibility, and export reliability that IPFIX Mediation may help resolve. This document describes some problems related to flow-based measurement that network administrators have been facing, and then describes IPFIX Mediation applicability examples along with the problems. 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 May 5, 2010. Copyright Notice Copyright (c) 2009 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 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 BSD License. This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) controlling the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ipfix-mediators-problem-statement-07.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-ipfix-mediators-problem-statement-07.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2009-12-10173214.I-D@ietf.org> --NextPart-- From akoba@nttv6.net Thu Dec 10 18:06:21 2009 Return-Path: X-Original-To: ipfix@core3.amsl.com Delivered-To: ipfix@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 716CB3A68E4 for ; Thu, 10 Dec 2009 18:06:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.334 X-Spam-Level: X-Spam-Status: No, score=-2.334 tagged_above=-999 required=5 tests=[AWL=0.266, BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hkEt7g1oQkaO for ; Thu, 10 Dec 2009 18:06:20 -0800 (PST) Received: from mail.nttv6.net (mail.nttv6.net [IPv6:2001:fa8::25]) by core3.amsl.com (Postfix) with ESMTP id 666163A6803 for ; Thu, 10 Dec 2009 18:06:17 -0800 (PST) Received: from [10.10.10.20] ([IPv6:2001:fa8:1000:0:d01d:e00e:7212:f951]) by mail.nttv6.net (8.14.3/8.14.3) with ESMTP id nBB264kt064662 for ; Fri, 11 Dec 2009 11:06:04 +0900 (JST) (envelope-from akoba@nttv6.net) Date: Fri, 11 Dec 2009 10:54:23 +0900 From: Atsushi Kobayashi To: ipfix@ietf.org In-Reply-To: <20091211014501.C13F23A6886@core3.amsl.com> References: <20091211014501.C13F23A6886@core3.amsl.com> Message-Id: <20091211103937.8C75.17391CF2@nttv6.net> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Becky! ver. 2.50.05 [ja] (Unregistered) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.3 (mail.nttv6.net [IPv6:2001:fa8::25]); Fri, 11 Dec 2009 11:06:04 +0900 (JST) Subject: Re: [IPFIX] I-D Action:draft-ietf-ipfix-mediators-problem-statement-07.txt X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Dec 2009 02:06:21 -0000 Dear all, This is new version of Mediation Problem Statement with the changes that solve issues raised up in 2nd WGLC. I appreciate Gerhard, Brian, and Sujay for your comments and suggestion in WGLC. In the last IETF meeting, the new version was approved to submission to IESG. Now. it is ready for IESG. Regards, Atsushi On Thu, 10 Dec 2009 17:45:01 -0800 (PST) Internet-Drafts@ietf.org wrote: > A New Internet-Draft is available from the on-line Internet-Drafts directories. > This draft is a work item of the IP Flow Information Export Working Group of the IETF. > > > Title : IPFIX Mediation: Problem Statement > Author(s) : A. Kobayashi, et al. > Filename : draft-ietf-ipfix-mediators-problem-statement-07.txt > Pages : 29 > Date : 2009-12-10 > > Flow-based measurement is a popular method for various network > monitoring usages. The sharing of flow-based information for > monitoring applications having different requirements raises some > open issues in terms of measurement system scalability, flow-based > measurement flexibility, and export reliability that IPFIX Mediation > may help resolve. This document describes some problems related to > flow-based measurement that network administrators have been facing, > and then describes IPFIX Mediation applicability examples along with > the problems. > > 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 May 5, 2010. > > Copyright Notice > > Copyright (c) 2009 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 > 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 BSD License. > > This document may contain material from IETF Documents or IETF > Contributions published or made publicly available before November > 10, 2008. The person(s) controlling the copyright in some of this > material may not have granted the IETF Trust the right to allow > modifications of such material outside the IETF Standards Process. > Without obtaining an adequate license from the person(s) controlling > the copyright in such materials, this document may not be modified > outside the IETF Standards Process, and derivative works of it may > not be created outside the IETF Standards Process, except to format > it for publication as an RFC or to translate it into languages other > than English. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-ipfix-mediators-problem-statement-07.txt > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > Below is the data which will enable a MIME compliant mail reader > implementation to automatically retrieve the ASCII version of the > Internet-Draft. --- Atsushi KOBAYASHI NTT Information Sharing Platform Lab. tel:+81-(0)422-59-3978 fax:+81-(0)422-59-5637 From dromasca@avaya.com Mon Dec 21 00:51:21 2009 Return-Path: X-Original-To: ipfix@core3.amsl.com Delivered-To: ipfix@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9A9673A690F for ; Mon, 21 Dec 2009 00:51:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.479 X-Spam-Level: X-Spam-Status: No, score=-2.479 tagged_above=-999 required=5 tests=[AWL=0.120, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gY65+vABiVpo for ; Mon, 21 Dec 2009 00:51:20 -0800 (PST) Received: from de307622-de-outbound.net.avaya.com (de307622-de-outbound.net.avaya.com [198.152.71.100]) by core3.amsl.com (Postfix) with ESMTP id 2E2E53A687E for ; Mon, 21 Dec 2009 00:51:20 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.47,430,1257138000"; d="scan'208";a="167716294" Received: from unknown (HELO p-us1-erheast.us1.avaya.com) ([135.11.50.53]) by de307622-de-outbound.net.avaya.com with ESMTP; 21 Dec 2009 03:51:02 -0500 Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.13]) by p-us1-erheast-out.us1.avaya.com with ESMTP; 21 Dec 2009 03:51:01 -0500 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, 21 Dec 2009 09:50:30 +0100 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: IPFIX MIB approved by the IESG Thread-Index: AcqCGqYW9GbeOw9GQuy4cXa72biZfA== From: "Romascanu, Dan (Dan)" To: Subject: [IPFIX] IPFIX MIB approved by the IESG X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Dec 2009 08:51:21 -0000 This is a resend of a message sent last Thursday, unfortunately mail problems prevented me from sharing the good news. The IESG approved the IPFIX MIB. Thanks and congratulations to the authors, chairs and the whole WG.=20 Regards, Dan From wwwrun@core3.amsl.com Mon Dec 21 10:41:25 2009 Return-Path: X-Original-To: ipfix@ietf.org Delivered-To: ipfix@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 30) id EE0433A6A74; Mon, 21 Dec 2009 10:41:25 -0800 (PST) X-idtracker: yes From: The IESG To: IETF-Announce Message-Id: <20091221184125.EE0433A6A74@core3.amsl.com> Date: Mon, 21 Dec 2009 10:41:25 -0800 (PST) Cc: Internet Architecture Board , ipfix chair , ipfix mailing list , RFC Editor Subject: [IPFIX] Protocol Action: 'Definitions of Managed Objects for IP Flow Information Export' to Proposed Standard X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Dec 2009 18:41:26 -0000 The IESG has approved the following document: - 'Definitions of Managed Objects for IP Flow Information Export ' as a Proposed Standard This document is the product of the IP Flow Information Export Working Group. The IESG contact persons are Dan Romascanu and Ron Bonica. A URL of this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ipfix-mib-09.txt Technical Summary This document defines managed objects for IP Flow Information Export (IPFIX). These objects provide information for monitoring IPFIX Exporters and IPFIX Collectors including the basic configuration information. Working Group Summary This work originates from the PSAMP MIB module. The PSAMP WG had MIB development already chartered when there was no such plan in the IPFIX WG. But after the first versions of the PSAMP MIB module had been discussed it became clear that a lot of its content should rather be part of an IPFIX MIB module than of a PSAMP MIB module. Therefore, the IPFIX WG got a MIB module into its charter and took over most of the content of the former PSAMP MIB. The PSAMP MIB module is to be completed after the completions of the IPFIX MIB module. Document Quality The document underwent several reviews and two WG last calls in the IPFIX WG. This way, a high document quality has been achieved already. Still a review by a MIB doctor would be desirable. Personnel Juergen Quittek is shepherding this document. Dan Romascanu is the responsible Area director. From web-usrn@ISI.EDU Mon Dec 28 10:24:26 2009 Return-Path: X-Original-To: ipfix@core3.amsl.com Delivered-To: ipfix@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A8AC13A62C1 for ; Mon, 28 Dec 2009 10:24:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.002 X-Spam-Level: X-Spam-Status: No, score=-17.002 tagged_above=-999 required=5 tests=[AWL=-0.486, BAYES_00=-2.599, URIBL_RHS_DOB=1.083, USER_IN_DEF_WHITELIST=-15] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id j1ayKCf3XG7j for ; Mon, 28 Dec 2009 10:24:25 -0800 (PST) Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) by core3.amsl.com (Postfix) with ESMTP id A5CB83A6808 for ; Mon, 28 Dec 2009 10:24:25 -0800 (PST) Received: from boreas.isi.edu (localhost [127.0.0.1]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id nBSIMTrA028858; Mon, 28 Dec 2009 10:22:30 -0800 (PST) Received: (from web-usrn@localhost) by boreas.isi.edu (8.13.8/8.13.8/Submit) id nBSIMQ8n028844; Mon, 28 Dec 2009 10:22:26 -0800 (PST) Date: Mon, 28 Dec 2009 10:22:26 -0800 (PST) Message-Id: <200912281822.nBSIMQ8n028844@boreas.isi.edu> 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@netlab.nec.de From: RFC Errata System X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: web-usrn@boreas.isi.edu Cc: ah@TR-Sys.de, ipfix@ietf.org, rfc-editor@rfc-editor.org Subject: [IPFIX] [Editorial Errata Reported] RFC5655 (1984) X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Dec 2009 18:24: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=1984 -------------------------------------- Type: Editorial Reported by: Alfred Hoenes Section: 5.8, pg.13 Original Text ------------- Certain use cases for archival flow storage require the storage of collection infrastructure details alongside the data itself. These details include information about how and when data was received, and where it was received from. They are useful for auditing as well as | for the replaying received data for testing purposes. Corrected Text -------------- Certain use cases for archival flow storage require the storage of collection infrastructure details alongside the data itself. These details include information about how and when data was received, and where it was received from. They are useful for auditing as well as | for replaying received data for testing purposes. Notes ----- Alternative for last line: | for the replay of received data for testing purposes. Additional editorial remark (keep for update!): In Section 1.1, there's an unexpected blank line inserted into the first paragraph on page 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. -------------------------------------- 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 web-usrn@ISI.EDU Mon Dec 28 10:26:22 2009 Return-Path: X-Original-To: ipfix@core3.amsl.com Delivered-To: ipfix@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DCE7B3A68F6 for ; Mon, 28 Dec 2009 10:26:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -16.998 X-Spam-Level: X-Spam-Status: No, score=-16.998 tagged_above=-999 required=5 tests=[AWL=-0.482, BAYES_00=-2.599, URIBL_RHS_DOB=1.083, USER_IN_DEF_WHITELIST=-15] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vWG35pdva3Yp for ; Mon, 28 Dec 2009 10:26:21 -0800 (PST) Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) by core3.amsl.com (Postfix) with ESMTP id 232B53A62C1 for ; Mon, 28 Dec 2009 10:26:21 -0800 (PST) Received: from boreas.isi.edu (localhost [127.0.0.1]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id nBSIPBCI029623; Mon, 28 Dec 2009 10:25:12 -0800 (PST) Received: (from web-usrn@localhost) by boreas.isi.edu (8.13.8/8.13.8/Submit) id nBSIPBCa029622; Mon, 28 Dec 2009 10:25:11 -0800 (PST) Date: Mon, 28 Dec 2009 10:25:11 -0800 (PST) Message-Id: <200912281825.nBSIPBCa029622@boreas.isi.edu> 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@netlab.nec.de From: RFC Errata System X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: web-usrn@boreas.isi.edu Cc: ah@TR-Sys.de, ipfix@ietf.org, rfc-editor@rfc-editor.org Subject: [IPFIX] [Editorial Errata Reported] RFC5655 (1985) X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Dec 2009 18:26:22 -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=1985 -------------------------------------- Type: Editorial Reported by: Alfred Hoenes Section: 7.1, pg.16 Original Text ------------- ... third bullet, at the bottom of page 16: o resolve any conflict between a resent definition and a previous definition by assuming that the new Template replaces the old, as | consistent with Template expiration and ID reuse when using UDP at the IPFIX transport protocol; and Corrected Text -------------- o resolve any conflict between a resent definition and a previous definition by assuming that the new Template replaces the old, as | consistent with Template expiration and ID reuse when using UDP as the IPFIX transport protocol; and Notes ----- Rationale: typo; s/at/as/ . 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 web-usrn@ISI.EDU Mon Dec 28 10:30:28 2009 Return-Path: X-Original-To: ipfix@core3.amsl.com Delivered-To: ipfix@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F2C3D3A6927 for ; Mon, 28 Dec 2009 10:30:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -16.993 X-Spam-Level: X-Spam-Status: No, score=-16.993 tagged_above=-999 required=5 tests=[AWL=-0.477, BAYES_00=-2.599, URIBL_RHS_DOB=1.083, USER_IN_DEF_WHITELIST=-15] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PiXkmMUjdiMM for ; Mon, 28 Dec 2009 10:30:27 -0800 (PST) Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) by core3.amsl.com (Postfix) with ESMTP id 452653A6911 for ; Mon, 28 Dec 2009 10:30:27 -0800 (PST) Received: from boreas.isi.edu (localhost [127.0.0.1]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id nBSISJ1n000895; Mon, 28 Dec 2009 10:28:20 -0800 (PST) Received: (from web-usrn@localhost) by boreas.isi.edu (8.13.8/8.13.8/Submit) id nBSISJNS000893; Mon, 28 Dec 2009 10:28:19 -0800 (PST) Date: Mon, 28 Dec 2009 10:28:19 -0800 (PST) Message-Id: <200912281828.nBSISJNS000893@boreas.isi.edu> 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@netlab.nec.de From: RFC Errata System X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: web-usrn@boreas.isi.edu Cc: ah@TR-Sys.de, ipfix@ietf.org, rfc-editor@rfc-editor.org Subject: [IPFIX] [Editorial Errata Reported] RFC5655 (1986) X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Dec 2009 18:30:28 -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=1986 -------------------------------------- Type: Editorial Reported by: Alfred Hoenes Section: 8.1.4, pg.26 Original Text ------------- ... first paragraph: [...]. This Options Template | also allows the storage of the export session metadata provided the Export Session Details Options Template, for storing information from multiple Transport Sessions in the same IPFIX File. Corrected Text -------------- [...]. This Options Template | also allows the storage of the export session metadata provided by the Export Session Details Options Template, for storing information from multiple Transport Sessions in the same IPFIX File. Notes ----- Rationale: missing word, "by". 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 web-usrn@ISI.EDU Mon Dec 28 10:33:34 2009 Return-Path: X-Original-To: ipfix@core3.amsl.com Delivered-To: ipfix@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4EBD23A6927 for ; Mon, 28 Dec 2009 10:33:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -16.989 X-Spam-Level: X-Spam-Status: No, score=-16.989 tagged_above=-999 required=5 tests=[AWL=-0.473, BAYES_00=-2.599, URIBL_RHS_DOB=1.083, USER_IN_DEF_WHITELIST=-15] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pzgXjgEHj-74 for ; Mon, 28 Dec 2009 10:33:33 -0800 (PST) Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) by core3.amsl.com (Postfix) with ESMTP id 9E1463A693F for ; Mon, 28 Dec 2009 10:33:28 -0800 (PST) Received: from boreas.isi.edu (localhost [127.0.0.1]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id nBSIVNhR002158; Mon, 28 Dec 2009 10:31:24 -0800 (PST) Received: (from web-usrn@localhost) by boreas.isi.edu (8.13.8/8.13.8/Submit) id nBSIVN6Q002156; Mon, 28 Dec 2009 10:31:23 -0800 (PST) Date: Mon, 28 Dec 2009 10:31:23 -0800 (PST) Message-Id: <200912281831.nBSIVN6Q002156@boreas.isi.edu> 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@netlab.nec.de From: RFC Errata System X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: web-usrn@boreas.isi.edu Cc: ah@TR-Sys.de, ipfix@ietf.org, rfc-editor@rfc-editor.org Subject: [IPFIX] [Editorial Errata Reported] RFC5655 (1987) X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Dec 2009 18:33:34 -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=1987 -------------------------------------- Type: Editorial Reported by: Alfred Hoenes Section: 9, 1st para Original Text ------------- In order to ensure the integrity of IPFIX Files and the identity of IPFIX File Writers, File Writers and File Readers SHOULD provide for an interoperable and easily implemented method for signing IPFIX | Files, and verifying those signatures. This section specifies method | via CMS detached signatures. Corrected Text -------------- In order to ensure the integrity of IPFIX Files and the identity of IPFIX File Writers, File Writers and File Readers SHOULD provide for an interoperable and easily implemented method for signing IPFIX | Files, and verifying those signatures. This section specifies one | such method via CMS detached signatures. Notes ----- Rationale: missing word(s); suggest inserting "one such". 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 web-usrn@ISI.EDU Mon Dec 28 10:41:37 2009 Return-Path: X-Original-To: ipfix@core3.amsl.com Delivered-To: ipfix@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7602C3A6963 for ; Mon, 28 Dec 2009 10:41:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -16.985 X-Spam-Level: X-Spam-Status: No, score=-16.985 tagged_above=-999 required=5 tests=[AWL=-0.469, BAYES_00=-2.599, URIBL_RHS_DOB=1.083, USER_IN_DEF_WHITELIST=-15] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 66pbE8pwQjgE for ; Mon, 28 Dec 2009 10:41:36 -0800 (PST) Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) by core3.amsl.com (Postfix) with ESMTP id 9B0F13A693E for ; Mon, 28 Dec 2009 10:41:36 -0800 (PST) Received: from boreas.isi.edu (localhost [127.0.0.1]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id nBSIeDfx006409; Mon, 28 Dec 2009 10:40:14 -0800 (PST) Received: (from web-usrn@localhost) by boreas.isi.edu (8.13.8/8.13.8/Submit) id nBSIeDb3006406; Mon, 28 Dec 2009 10:40:13 -0800 (PST) Date: Mon, 28 Dec 2009 10:40:13 -0800 (PST) Message-Id: <200912281840.nBSIeDb3006406@boreas.isi.edu> 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@netlab.nec.de From: RFC Errata System X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: web-usrn@boreas.isi.edu Cc: ah@TR-Sys.de, ipfix@ietf.org, rfc-editor@rfc-editor.org Subject: [IPFIX] [Technical Errata Reported] RFC5655 (1988) X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Dec 2009 18:41:37 -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=1988 -------------------------------------- Type: Technical Reported by: Alfred Hoenes Section: 9.1.3, pg.39 Original Text ------------- signedAttrs: an optional set of attributes that are signed along with the content. | digestAlgorithm: identifies the digital signature algorithm and associated parameters used to generate the signature. signature: the digital signature of the associated file. unsignedAttrs: an optional set of attributes that are not signed. Corrected Text -------------- signedAttrs: an optional set of attributes that are signed along with the content. | signatureAlgorithm: identifies the digital signature algorithm and associated parameters used to generate the signature. signature: the digital signature of the associated file. unsignedAttrs: an optional set of attributes that are not signed. Notes ----- Rationale: Same SEQUENCE element name listed twice, for two different explanations. Further Note (keep for update!): In Section 9.1, in the ASN.1 on page 37, for a better approximation to ASN.1, all pairs of curly braces, "{" ... "}", should better be preceded by the keyword "SEQUENCE". 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 web-usrn@ISI.EDU Mon Dec 28 10:44:12 2009 Return-Path: X-Original-To: ipfix@core3.amsl.com Delivered-To: ipfix@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6D58D3A6988 for ; Mon, 28 Dec 2009 10:44:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -16.981 X-Spam-Level: X-Spam-Status: No, score=-16.981 tagged_above=-999 required=5 tests=[AWL=-0.465, BAYES_00=-2.599, URIBL_RHS_DOB=1.083, USER_IN_DEF_WHITELIST=-15] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ELvLbKsDboNa for ; Mon, 28 Dec 2009 10:44:11 -0800 (PST) Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) by core3.amsl.com (Postfix) with ESMTP id BFE7D3A68A2 for ; Mon, 28 Dec 2009 10:44:11 -0800 (PST) Received: from boreas.isi.edu (localhost [127.0.0.1]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id nBSIgkBJ007588; Mon, 28 Dec 2009 10:42:47 -0800 (PST) Received: (from web-usrn@localhost) by boreas.isi.edu (8.13.8/8.13.8/Submit) id nBSIgkPq007587; Mon, 28 Dec 2009 10:42:46 -0800 (PST) Date: Mon, 28 Dec 2009 10:42:46 -0800 (PST) Message-Id: <200912281842.nBSIgkPq007587@boreas.isi.edu> 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@netlab.nec.de From: RFC Errata System X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: web-usrn@boreas.isi.edu Cc: ah@TR-Sys.de, ipfix@ietf.org, rfc-editor@rfc-editor.org Subject: [IPFIX] [Editorial Errata Reported] RFC5655 (1989) X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Dec 2009 18:44:12 -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=1989 -------------------------------------- Type: Editorial Reported by: Alfred Hoenes Section: 10, pg. 39 Original Text ------------- [...] | IPFIX Templates tend to increase the information content per record by not requiring the export of irrelevant or non-present fields in records, and the technique described in [RFC5473] also reduces the export of redundant information. [...] Corrected Text -------------- [...] | IPFIX Templates tend to decrease the information content per record by not requiring the export of irrelevant or non-present fields in records, and the technique described in [RFC5473] also reduces the export of redundant information. [...] Notes ----- Rationale: arguably s/increase/decrease/ . 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 web-usrn@ISI.EDU Mon Dec 28 10:46:27 2009 Return-Path: X-Original-To: ipfix@core3.amsl.com Delivered-To: ipfix@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 642333A697B for ; Mon, 28 Dec 2009 10:46:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -16.977 X-Spam-Level: X-Spam-Status: No, score=-16.977 tagged_above=-999 required=5 tests=[AWL=-0.461, BAYES_00=-2.599, URIBL_RHS_DOB=1.083, USER_IN_DEF_WHITELIST=-15] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4MgV7Cwc-w6n for ; Mon, 28 Dec 2009 10:46:26 -0800 (PST) Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) by core3.amsl.com (Postfix) with ESMTP id A61AB3A6978 for ; Mon, 28 Dec 2009 10:46:26 -0800 (PST) Received: from boreas.isi.edu (localhost [127.0.0.1]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id nBSIjHHZ008436; Mon, 28 Dec 2009 10:45:18 -0800 (PST) Received: (from web-usrn@localhost) by boreas.isi.edu (8.13.8/8.13.8/Submit) id nBSIjHIS008435; Mon, 28 Dec 2009 10:45:17 -0800 (PST) Date: Mon, 28 Dec 2009 10:45:17 -0800 (PST) Message-Id: <200912281845.nBSIjHIS008435@boreas.isi.edu> 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@netlab.nec.de From: RFC Errata System X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: web-usrn@boreas.isi.edu Cc: ah@TR-Sys.de, ipfix@ietf.org, rfc-editor@rfc-editor.org Subject: [IPFIX] [Editorial Errata Reported] RFC5655 (1990) X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Dec 2009 18:46:27 -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=1990 -------------------------------------- Type: Editorial Reported by: Alfred Hoenes Section: 12, pg.42 Original Text ------------- [...]. However, aside from merely applying CMS for signatures, there are several security | issues which much be considered in certain circumstances; these are covered in the subsections below. Corrected Text -------------- [...]. However, aside from merely applying CMS for signatures, there are several security | issues that must be considered in certain circumstances; these are covered in the subsections below. Notes ----- Rationale: broken grammar; s/which much/that must/ . 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 web-usrn@ISI.EDU Mon Dec 28 10:54:26 2009 Return-Path: X-Original-To: ipfix@core3.amsl.com Delivered-To: ipfix@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BA3043A68C3 for ; Mon, 28 Dec 2009 10:54:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -16.973 X-Spam-Level: X-Spam-Status: No, score=-16.973 tagged_above=-999 required=5 tests=[AWL=-0.457, BAYES_00=-2.599, URIBL_RHS_DOB=1.083, USER_IN_DEF_WHITELIST=-15] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GiAv48xq2eCk for ; Mon, 28 Dec 2009 10:54:26 -0800 (PST) Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) by core3.amsl.com (Postfix) with ESMTP id 03B6A3A6816 for ; Mon, 28 Dec 2009 10:54:25 -0800 (PST) Received: from boreas.isi.edu (localhost [127.0.0.1]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id nBSIqxSA011317; Mon, 28 Dec 2009 10:53:00 -0800 (PST) Received: (from web-usrn@localhost) by boreas.isi.edu (8.13.8/8.13.8/Submit) id nBSIqwNl011301; Mon, 28 Dec 2009 10:52:58 -0800 (PST) Date: Mon, 28 Dec 2009 10:52:58 -0800 (PST) Message-Id: <200912281852.nBSIqwNl011301@boreas.isi.edu> 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@netlab.nec.de From: RFC Errata System X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: web-usrn@boreas.isi.edu Cc: ah@TR-Sys.de, ipfix@ietf.org, rfc-editor@rfc-editor.org Subject: [IPFIX] [Editorial Errata Reported] RFC5655 (1991) X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Dec 2009 18: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=1991 -------------------------------------- Type: Editorial Reported by: Alfred Hoenes Section: 12.2, pg.43 Original Text ------------- ... first paragraph: [...]. The channel | between the Exporting Process to Collecting Process using IPFIX is signed by the Exporting Process key and protected via TLS and DTLS, while the File is signed by the File Writer key and protected via CMS. [...] Corrected Text -------------- [...]. The channel | from the Exporting Process to the Collecting Process using IPFIX is signed by the Exporting Process key and protected via TLS and DTLS, while the File is signed by the File Writer key and protected via CMS. [...] Notes ----- Rationale: "channel between xxx to yyy" does not make sense. Either "channel _from_ xxx to yyy" or "channel between xxx _and_ yyy" should be written. The Corrected Text above suggests the first alternative (based on the essential unidirectionality of the information flow) and balances the use of articles. 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 web-usrn@ISI.EDU Mon Dec 28 11:02:09 2009 Return-Path: X-Original-To: ipfix@core3.amsl.com Delivered-To: ipfix@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EA5A63A6927 for ; Mon, 28 Dec 2009 11:02:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -16.969 X-Spam-Level: X-Spam-Status: No, score=-16.969 tagged_above=-999 required=5 tests=[AWL=-0.453, BAYES_00=-2.599, URIBL_RHS_DOB=1.083, USER_IN_DEF_WHITELIST=-15] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ikOZtbxN+zcG for ; Mon, 28 Dec 2009 11:02:09 -0800 (PST) Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) by core3.amsl.com (Postfix) with ESMTP id 3910E3A691D for ; Mon, 28 Dec 2009 11:02:09 -0800 (PST) Received: from boreas.isi.edu (localhost [127.0.0.1]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id nBSJ1R9q014201; Mon, 28 Dec 2009 11:01:27 -0800 (PST) Received: (from web-usrn@localhost) by boreas.isi.edu (8.13.8/8.13.8/Submit) id nBSJ1Rra014200; Mon, 28 Dec 2009 11:01:27 -0800 (PST) Date: Mon, 28 Dec 2009 11:01:27 -0800 (PST) Message-Id: <200912281901.nBSJ1Rra014200@boreas.isi.edu> 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@netlab.nec.de From: RFC Errata System X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: web-usrn@boreas.isi.edu Cc: ah@TR-Sys.de, ipfix@ietf.org, rfc-editor@rfc-editor.org Subject: [IPFIX] [Editorial Errata Reported] RFC5655 (1992) X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Dec 2009 19:02:10 -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=1992 -------------------------------------- Type: Editorial Reported by: Alfred Hoenes Section: GLOBAL Original Text ------------- Section 15.1 contains the outdated Normative Reference: | [RFC3852] Housley, R., "Cryptographic Message Syntax (CMS)", | RFC 3852, July 2004. "[RFC3852]" is used in Sections 5.6, 9.1, 9.1.1, and 12. Corrected Text -------------- At the time of publication of RFC 5655, the replacement RFC already had been published six weeks ago and should have been referred to, due to the essential corrections it incorporates: | [RFC5652] Housley, R., "Cryptographic Message Syntax (CMS)", | RFC 5652, September 2009. Notes ----- 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