From dromasca@avaya.com Wed Apr 1 02:32: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 F11AC3A6997 for ; Wed, 1 Apr 2009 02:32:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.506 X-Spam-Level: X-Spam-Status: No, score=-2.506 tagged_above=-999 required=5 tests=[AWL=0.093, 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 ZVpzCxznEsSl for ; Wed, 1 Apr 2009 02:32:01 -0700 (PDT) Received: from nj300815-nj-outbound.net.avaya.com (nj300815-nj-outbound.net.avaya.com [198.152.12.100]) by core3.amsl.com (Postfix) with ESMTP id BC0893A690B for ; Wed, 1 Apr 2009 02:32:00 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.39,305,1235970000"; d="scan'208";a="157143375" Received: from unknown (HELO co300216-co-erhwest.avaya.com) ([198.152.7.5]) by nj300815-nj-outbound.net.avaya.com with ESMTP; 01 Apr 2009 05:32:59 -0400 Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.12]) by co300216-co-erhwest-out.avaya.com with ESMTP; 01 Apr 2009 05:32:59 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Wed, 1 Apr 2009 11:32:36 +0200 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: RFC 5473 on Reducing Redundancy in IP Flow Information Export (IPFIX)and Packet Sampling (PSAMP) Reports Thread-Index: AcmyXWobRkLizjooR8OckJE0EDgY7gAT0Mog From: "Romascanu, Dan (Dan)" To: "IETF IPFIX Working Group" Subject: [IPFIX] FW: RFC 5473 on Reducing Redundancy in IP Flow Information Export (IPFIX)and Packet Sampling (PSAMP) Reports 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, 01 Apr 2009 09:32:02 -0000 Congratulations to the Editors, Chairs and to the whole Working Group for the publication of the new IPFIX RFCs.=20 Dan -----Original Message----- From: ietf-announce-bounces@ietf.org [mailto:ietf-announce-bounces@ietf.org] On Behalf Of rfc-editor@rfc-editor.org Sent: Wednesday, April 01, 2009 2:58 AM To: ietf-announce@ietf.org; rfc-dist@rfc-editor.org Cc: ipfix@ietf.org; rfc-editor@rfc-editor.org Subject: RFC 5473 on Reducing Redundancy in IP Flow Information Export (IPFIX)and Packet Sampling (PSAMP) Reports A new Request for Comments is now available in online RFC libraries. =20 RFC 5473 Title: Reducing Redundancy in IP Flow=20 Information Export (IPFIX) and Packet Sampling=20 (PSAMP) Reports=20 Author: E. Boschi, L. Mark, B. Claise Status: Informational Date: March 2009 Mailbox: elisa.boschi@hitachi-eu.com,=20 lutz.mark@ifam.fraunhofer.de,=20 bclaise@cisco.com Pages: 27 Characters: 64654 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-ietf-ipfix-reducing-redundancy-04.txt URL: http://www.rfc-editor.org/rfc/rfc5473.txt This document describes a bandwidth saving method for exporting Flow or packet information using the IP Flow Information eXport (IPFIX) protocol. As the Packet Sampling (PSAMP) protocol is based on IPFIX, these considerations are valid for PSAMP exports as well. This method works by separating information common to several Flow Records from information specific to an individual Flow Record. Common Flow information is exported only once in a Data Record defined by an Options Template, while the rest of the specific Flow information is associated with the common information via a unique identifier. This memo provides information for the Internet community. This document is a product of the IP Flow Information Export Working Group of the IETF. INFORMATIONAL: This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce and rfc-dist lists. To subscribe or unsubscribe, see http://www.ietf.org/mailman/listinfo/ietf-announce http://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see http://www.rfc-editor.org/rfcsearch.html. For downloading RFCs, see http://www.rfc-editor.org/rfc.html. Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-editor@rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team USC/Information Sciences Institute _______________________________________________ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce From bclaise@cisco.com Wed Apr 1 03:38:02 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 AEEF228C178 for ; Wed, 1 Apr 2009 03:38:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.543 X-Spam-Level: X-Spam-Status: No, score=-2.543 tagged_above=-999 required=5 tests=[AWL=0.055, BAYES_00=-2.599, HTML_MESSAGE=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 NpRlCsWZtpGO for ; Wed, 1 Apr 2009 03:38:01 -0700 (PDT) Received: from av-tac-bru.cisco.com (odd-brew.cisco.com [144.254.15.119]) by core3.amsl.com (Postfix) with ESMTP id A06803A67A7 for ; Wed, 1 Apr 2009 03:38:00 -0700 (PDT) X-TACSUNS: Virus Scanned Received: from strange-brew.cisco.com (localhost [127.0.0.1]) by av-tac-bru.cisco.com (8.11.7p3+Sun/8.11.7) with ESMTP id n31Acwd06831; Wed, 1 Apr 2009 12:38:58 +0200 (CEST) Received: from [10.55.43.53] (ams-bclaise-8714.cisco.com [10.55.43.53]) by strange-brew.cisco.com (8.11.7p3+Sun/8.11.7) with ESMTP id n31Acst06920; Wed, 1 Apr 2009 12:38:54 +0200 (CEST) Message-ID: <49D3443D.5090007@cisco.com> Date: Wed, 01 Apr 2009 12:38:53 +0200 From: Benoit Claise User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: Gerhard Muenz References: <49AE3881.3050909@cisco.com> <49C78756.3030204@net.in.tum.de> In-Reply-To: <49C78756.3030204@net.in.tum.de> Content-Type: multipart/alternative; boundary="------------060009050605050203010609" Cc: "ipfix@ietf.org" Subject: Re: [IPFIX] [Fwd: I-D ACTION:draft-claise-structured-data-in-ipfix-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: Wed, 01 Apr 2009 10:38:02 -0000 This is a multi-part message in MIME format. --------------060009050605050203010609 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Gerhard, Thank you very much for the nice feedback on the draft. See inline. > Hi Benoit, Gowri, Stan, Paul, > > I like your approach of structured data types. Such types, especially > the list type, are urgently needed in the context of PSAMP! > Interestingly, you do not mention these applications in the draft. So, > I'll briefly sketch them: > > 1) PSAMP Selection Sequence Report Interpretation > ------------------------------------------------- > > Here, RFC5476 explicitly mentions the need for list types: > > Scope: selectionSequenceId > Non-Scope: one Information Element mapping the Observation Point > selectorId (one or more) > > An Information Element representing the Observation Point would > typically be taken from the ingressInterface, egressInterface, > lineCardId, exporterIPv4Address, or exporterIPv6Address Information > Elements (specified in [RFC5102]), but is not limited to those: any > Information Element specified in [RFC5102] or [RFC5477] can > potentially be used. In case of more complex Observation Points > (such as a list of interfaces, a bus, etc.), a new Information > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > Good catch. Will be added in the next version. > Element describing the new type of Observation Point must be > specified, along with an Options Template Record describing it in > more detail (if necessary). > > In fact, this is the business case that you pretend not to see for > Options Templates in 5.2 of your draft ;) > Maybe. In section 5.2, we mentioned: Therefore, a Structured Data Information Element could be used as scope in an Options Template Set. However, in practice, the authors don't see an immediate business case for such a case. In the case of selectionSequenceId, the selectionSequenceId is a unique Id. We're thinking: do we need a list in the scope field? > > 2) PSAMP Property Match Filtering > --------------------------------- > > From RFC75476: > > When multiple different Information Elements are defined, the filter > acts as a logical AND. Note that the logical OR is not covered by > these PSAMP specifications. > > In practice, a logical OR is urgently needed. See my recent discussion > with Andrew on the ML: > http://www.ietf.org/mail-archive/web/ipfix/current/msg04802.html > > In draft-sommer-ipfix-mediator-ext-01, we proposed ADTs orderedList, > orderedPair, and portRanges which allow the definition new IEs for port > ranges etc. Your proposal is more generic as it does not require the > specification of a new IE for every purpose where a list is needed. > > The OR-semantic of a filter could be solved with a new Information > Element anyList which is derived from the ADT basicList. In contrast to > IE basicList, anyList introduces the semantic that exactly one of the > reported values was observed. As a consequence, we can export an anyList > of port numbers in Property Match Filtering in order to describe a > filter that selects packets given a list of port numbers. > We'll tried to. > > I would appreciate if the above issues were addressed in a future > version of your draft! > > > Further comments: > All editorial changes have been inserted already. Thanks again. Regards, Benoit. > >> 3.1. IPFIX Limitations >> ... >> To export this information in IPFIX, the data would need to be >> flattened (thus losing the hierarchical relationships) and a new >> IPFIX Template created for each alert, according to the number of >> applicationID elements in each target, the number of targets and >> attackers in each participant and the number of participants in >> each alert. Clearly each Template will be unique to each alert, >> and a large amount of CPU, memory and export bandwith will be >> > > bandwidth > > >> wasted creating, exporting, maintaining, and withdrawing the >> Templates. >> > > >> 4.4.1. basicList >> ... >> BasicList Content >> >> A Collection Process decodes list elements from the BasicList >> Content until no further data remains. A record count is not >> included but can be derived when the Information Element is >> decoded. >> > > Replace record count by field count? > > >> 5.2. Structured Data Information Elements Applicability in Options >> Template Sets >> >> All the examples in this document uses the Structured Data >> > > use > > >> Information Elements, abstract data types, and data type semantic >> in Template Sets. However, they could also be used in and Options >> > > remove "and" > > >> Template Sets. >> > > > >> 8.1. Encoding BasicList >> >> Consider encoding an user_record containing the following data: >> > > a user_record > > > Regards, > Gerhard > > > Benoit Claise wrote: > >> Dear all, >> >> Here is a new IPFIX draft. >> I think that the abstract is quite clear about its goal. >> >> Regards, Benoit. >> >> -------- Original Message -------- >> Subject: I-D ACTION:draft-claise-structured-data-in-ipfix-00.txt >> Date: Tue, 3 Mar 2009 15:15:01 -0800 (PST) >> From: Internet-Drafts@ietf.org >> Reply-To: internet-drafts@ietf.org >> To: i-d-announce@ietf.org >> >> >> >> A New Internet-Draft is available from the on-line Internet-Drafts >> directories. >> >> >> Title : Export of Structured Data in IPFIX >> Author(s) : B. Claise, G. Dhandapani, S. Yates, P. Aitken >> Filename : draft-claise-structured-data-in-ipfix-00.txt >> Pages : 36 >> Date : 2009-3-3 >> >> This document specifies an extension to IP Flow Information >> eXport (IPFIX) protocol specification in [RFC5101] and the IPFIX >> information model specified in [RFC5102] to support hierarchical >> structured data and lists (sequences) of Information Elements in >> data records. This extension allows definition of complex data >> structures such as variable-length lists and specification of >> hierarchical containment relationships between Templates. >> >> A URL for this Internet-Draft is: >> http://www.ietf.org/internet-drafts/draft-claise-structured-data-in-ipfix-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 >> > > --------------060009050605050203010609 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Gerhard,

Thank you very much for the nice feedback on the draft.
See inline.
Hi Benoit, Gowri, Stan, Paul,

I like your approach of structured data types. Such types, especially
the list type, are urgently needed in the context of PSAMP!
Interestingly, you do not mention these applications in the draft. So,
I'll briefly sketch them:

1) PSAMP Selection Sequence Report Interpretation
-------------------------------------------------

Here, RFC5476 explicitly mentions the need for list types:

   Scope:     selectionSequenceId
   Non-Scope: one Information Element mapping the Observation Point
              selectorId (one or more)

   An Information Element representing the Observation Point would
   typically be taken from the ingressInterface, egressInterface,
   lineCardId, exporterIPv4Address, or exporterIPv6Address Information
   Elements (specified in [RFC5102]), but is not limited to those: any
   Information Element specified in [RFC5102] or [RFC5477] can
   potentially be used.  In case of more complex Observation Points
   (such as a list of interfaces, a bus, etc.), a new Information
    ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Good catch. Will be added in the next version.
   Element describing the new type of Observation Point must be
   specified, along with an Options Template Record describing it in
   more detail (if necessary).

In fact, this is the business case that you pretend not to see for
Options Templates in 5.2 of your draft ;)
Maybe. In section 5.2, we mentioned:
      Therefore, a Structured Data Information Element could be used as 
      scope in an Options Template Set.  However, in practice, the 
      authors don't see an immediate business case for such a case.
In the case of selectionSequenceId, the selectionSequenceId is a unique Id.
We're thinking: do we need a list in the scope field?

2) PSAMP Property Match Filtering
---------------------------------

>From RFC75476:

   When multiple different Information Elements are defined, the filter
   acts as a logical AND.  Note that the logical OR is not covered by
   these PSAMP specifications.

In practice, a logical OR is urgently needed. See my recent discussion
with Andrew on the ML:
http://www.ietf.org/mail-archive/web/ipfix/current/msg04802.html

In draft-sommer-ipfix-mediator-ext-01, we proposed ADTs orderedList,
orderedPair, and portRanges which allow the definition new IEs for port
ranges etc. Your proposal is more generic as it does not require the
specification of a new IE for every purpose where a list is needed.

The OR-semantic of a filter could be solved with a new Information
Element anyList which is derived from the ADT basicList. In contrast to
IE basicList, anyList introduces the semantic that exactly one of the
reported values was observed. As a consequence, we can export an anyList
of port numbers in Property Match Filtering in order to describe a
filter that selects packets given a list of port numbers.
We'll tried to.

I would appreciate if the above issues were addressed in a future
version of your draft!


Further comments:
All editorial changes have been inserted already.

Thanks again.

Regards, Benoit.
  
     3.1. IPFIX Limitations 
...
      To export this information in IPFIX, the data would need to be 
      flattened (thus losing the hierarchical relationships) and a new 
      IPFIX Template created for each alert, according to the number of 
      applicationID elements in each target, the number of targets and 
      attackers in each participant and the number of participants in 
      each alert.  Clearly each Template will be unique to each alert, 
      and a large amount of CPU, memory and export bandwith will be 
    

bandwidth

  
      wasted creating, exporting, maintaining, and withdrawing the 
      Templates.  
    

  
     4.4.1. basicList 
...
       BasicList Content
       
          A Collection Process decodes list elements from the BasicList 
          Content until no further data remains.  A record count is not 
          included but can be derived when the Information Element is 
          decoded. 
    

Replace record count by field count?

  
     5.2. Structured Data Information Elements Applicability in Options 
        Template Sets 

      All the examples in this document uses the Structured Data 
    

use

  
      Information Elements, abstract data types, and data type semantic 
      in Template Sets.  However, they could also be used in and Options 
    

remove "and"

  
      Template Sets. 
    


  
    8.1. Encoding BasicList 

      Consider encoding an user_record containing the following data: 
    

a user_record


Regards,
Gerhard


Benoit Claise wrote:
  
Dear all,

Here is a new IPFIX draft.
I think that the abstract is quite clear about its goal.

Regards, Benoit.

-------- Original Message --------
Subject: 	I-D ACTION:draft-claise-structured-data-in-ipfix-00.txt
Date: 	Tue, 3 Mar 2009 15:15:01 -0800 (PST)
From: 	Internet-Drafts@ietf.org
Reply-To: 	internet-drafts@ietf.org
To: 	i-d-announce@ietf.org



A New Internet-Draft is available from the on-line Internet-Drafts 
directories.


	Title		: Export of Structured Data in IPFIX
	Author(s)	: B. Claise, G. Dhandapani, S. Yates, P. Aitken
	Filename	: draft-claise-structured-data-in-ipfix-00.txt
	Pages		: 36
	Date		: 2009-3-3
	
        This document specifies an extension to IP Flow Information 
        eXport (IPFIX) protocol specification in [RFC5101] and the IPFIX 
        information model specified in [RFC5102] to support hierarchical 
        structured data and lists (sequences) of Information Elements in 
        data records.  This extension allows definition of complex data 
        structures such as variable-length lists and specification of 
        hierarchical containment relationships between Templates. 

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-claise-structured-data-in-ipfix-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

--------------060009050605050203010609-- From bclaise@cisco.com Wed Apr 1 03:43: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 0CA6928C14E for ; Wed, 1 Apr 2009 03:43:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.546 X-Spam-Level: X-Spam-Status: No, score=-2.546 tagged_above=-999 required=5 tests=[AWL=0.052, BAYES_00=-2.599, HTML_MESSAGE=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 l9EN5PCsD6nj for ; Wed, 1 Apr 2009 03:43:55 -0700 (PDT) Received: from av-tac-bru.cisco.com (odd-brew.cisco.com [144.254.15.119]) by core3.amsl.com (Postfix) with ESMTP id 2006A3A690B for ; Wed, 1 Apr 2009 03:43:51 -0700 (PDT) X-TACSUNS: Virus Scanned Received: from strange-brew.cisco.com (localhost [127.0.0.1]) by av-tac-bru.cisco.com (8.11.7p3+Sun/8.11.7) with ESMTP id n31Aip807277; Wed, 1 Apr 2009 12:44:51 +0200 (CEST) Received: from [10.55.43.53] (ams-bclaise-8714.cisco.com [10.55.43.53]) by strange-brew.cisco.com (8.11.7p3+Sun/8.11.7) with ESMTP id n31Aint17055; Wed, 1 Apr 2009 12:44:50 +0200 (CEST) Message-ID: <49D345A1.2020308@cisco.com> Date: Wed, 01 Apr 2009 12:44:49 +0200 From: Benoit Claise User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: Atsushi Kobayashi References: <49AE3881.3050909@cisco.com> <49C78756.3030204@net.in.tum.de> <20090323223212.CE35.17391CF2@nttv6.net> In-Reply-To: <20090323223212.CE35.17391CF2@nttv6.net> Content-Type: multipart/alternative; boundary="------------000704060100090802060109" Cc: "ipfix@ietf.org" Subject: Re: [IPFIX] [Fwd: I-D ACTION:draft-claise-structured-data-in-ipfix-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: Wed, 01 Apr 2009 10:43:57 -0000 This is a multi-part message in MIME format. --------------000704060100090802060109 Content-Type: text/plain; charset=ISO-2022-JP Content-Transfer-Encoding: 7bit Kobayashi-san, Due to the lack of time, we focused just on a few examples, with the IPS alert being the most important one. While we started to receive feedback on this draft, we quickly understood that it was a mistake to (only) focus on IPS alert, as this is not a security draft. We'll address some more examples in the next version. Your examples are good ones. The best one is the export of performance metrics... from a mediation function or from the original exporter. Regards, Benoit. > Dear Gerhard, Benoit, Gowri, Stan, Paul, > > Gerhard, good point. I hope logical OR. > > I think BasicList also allows to encode the egress interface indexes of > multicast packets/flows, and the BGP communities of specific destination > IP address. Even AS path can be encoded in a Flow Records. > > It can be considered more sophisticated way than traditional one. I hope > that the examples about Flow Records in the draft are rich to be easy to > understand. > > And also, in QoS performance measurement, Exporter or Mediator creates > some metrics every 1 or 2 seconds, so they need to export data record > every 1 or 2 seconds. BasicList allows to encode metrics list during > some periods, such as 60 sec. It can reduce redundancy. > > Regards, > Atsushi KOBAYASHI > > > On Mon, 23 Mar 2009 13:57:58 +0100 > Gerhard Muenz wrote: > > >> Hi Benoit, Gowri, Stan, Paul, >> >> I like your approach of structured data types. Such types, especially >> the list type, are urgently needed in the context of PSAMP! >> Interestingly, you do not mention these applications in the draft. So, >> I'll briefly sketch them: >> >> 1) PSAMP Selection Sequence Report Interpretation >> ------------------------------------------------- >> >> Here, RFC5476 explicitly mentions the need for list types: >> >> Scope: selectionSequenceId >> Non-Scope: one Information Element mapping the Observation Point >> selectorId (one or more) >> >> An Information Element representing the Observation Point would >> typically be taken from the ingressInterface, egressInterface, >> lineCardId, exporterIPv4Address, or exporterIPv6Address Information >> Elements (specified in [RFC5102]), but is not limited to those: any >> Information Element specified in [RFC5102] or [RFC5477] can >> potentially be used. In case of more complex Observation Points >> (such as a list of interfaces, a bus, etc.), a new Information >> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ >> Element describing the new type of Observation Point must be >> specified, along with an Options Template Record describing it in >> more detail (if necessary). >> >> In fact, this is the business case that you pretend not to see for >> Options Templates in 5.2 of your draft ;) >> >> >> 2) PSAMP Property Match Filtering >> --------------------------------- >> >> From RFC75476: >> >> When multiple different Information Elements are defined, the filter >> acts as a logical AND. Note that the logical OR is not covered by >> these PSAMP specifications. >> >> In practice, is urgently needed. See my recent discussion >> with Andrew on the ML: >> http://www.ietf.org/mail-archive/web/ipfix/current/msg04802.html >> >> In draft-sommer-ipfix-mediator-ext-01, we proposed ADTs orderedList, >> orderedPair, and portRanges which allow the definition new IEs for port >> ranges etc. Your proposal is more generic as it does not require the >> specification of a new IE for every purpose where a list is needed. >> >> The OR-semantic of a filter could be solved with a new Information >> Element anyList which is derived from the ADT basicList. In contrast to >> IE basicList, anyList introduces the semantic that exactly one of the >> reported values was observed. As a consequence, we can export an anyList >> of port numbers in Property Match Filtering in order to describe a >> filter that selects packets given a list of port numbers. >> >> >> I would appreciate if the above issues were addressed in a future >> version of your draft! >> >> >> Further comments: >> >> >>> 3.1. IPFIX Limitations >>> ... >>> To export this information in IPFIX, the data would need to be >>> flattened (thus losing the hierarchical relationships) and a new >>> IPFIX Template created for each alert, according to the number of >>> applicationID elements in each target, the number of targets and >>> attackers in each participant and the number of participants in >>> each alert. Clearly each Template will be unique to each alert, >>> and a large amount of CPU, memory and export bandwith will be >>> >> bandwidth >> >> >>> wasted creating, exporting, maintaining, and withdrawing the >>> Templates. >>> >>> 4.4.1. basicList >>> ... >>> BasicList Content >>> >>> A Collection Process decodes list elements from the BasicList >>> Content until no further data remains. A record count is not >>> included but can be derived when the Information Element is >>> decoded. >>> >> Replace record count by field count? >> >> >>> 5.2. Structured Data Information Elements Applicability in Options >>> Template Sets >>> >>> All the examples in this document uses the Structured Data >>> >> use >> >> >>> Information Elements, abstract data types, and data type semantic >>> in Template Sets. However, they could also be used in and Options >>> >> remove "and" >> >> >>> Template Sets. >>> >> >>> 8.1. Encoding BasicList >>> >>> Consider encoding an user_record containing the following data: >>> >> a user_record >> >> >> Regards, >> Gerhard >> >> >> Benoit Claise wrote: >> >>> Dear all, >>> >>> Here is a new IPFIX draft. >>> I think that the abstract is quite clear about its goal. >>> >>> Regards, Benoit. >>> >>> -------- Original Message -------- >>> Subject: I-D ACTION:draft-claise-structured-data-in-ipfix-00.txt >>> Date: Tue, 3 Mar 2009 15:15:01 -0800 (PST) >>> From: Internet-Drafts@ietf.org >>> Reply-To: internet-drafts@ietf.org >>> To: i-d-announce@ietf.org >>> >>> >>> >>> A New Internet-Draft is available from the on-line Internet-Drafts >>> directories. >>> >>> >>> Title : Export of Structured Data in IPFIX >>> Author(s) : B. Claise, G. Dhandapani, S. Yates, P. Aitken >>> Filename : draft-claise-structured-data-in-ipfix-00.txt >>> Pages : 36 >>> Date : 2009-3-3 >>> >>> This document specifies an extension to IP Flow Information >>> eXport (IPFIX) protocol specification in [RFC5101] and the IPFIX >>> information model specified in [RFC5102] to support hierarchical >>> structured data and lists (sequences) of Information Elements in >>> data records. This extension allows definition of complex data >>> structures such as variable-length lists and specification of >>> hierarchical containment relationships between Templates. >>> >>> A URL for this Internet-Draft is: >>> http://www.ietf.org/internet-drafts/draft-claise-structured-data-in-ipfix-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 >>> >> -- >> Dipl.-Ing. Gerhard M〓z >> Chair for Network Architectures and Services (I8) >> Department of Informatics >> Technische Universit舩 M〓chen >> Boltzmannstr. 3, 85748 Garching bei M〓chen, 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 >> >> >> > > --- > Atsushi KOBAYASHI > NTT Information Sharing Platform Lab. > tel:+81-(0)422-59-3978 fax:+81-(0)422-59-5637 > --------------000704060100090802060109 Content-Type: text/html; charset=ISO-2022-JP Content-Transfer-Encoding: 7bit Kobayashi-san,

Due to the lack of time, we focused just on a few examples, with the IPS alert being the most important one.
While we started to receive feedback on this draft, we quickly understood that it was a mistake to (only) focus on IPS alert, as this is not a security draft.
We'll address some more examples in the next version. Your examples are good ones. The best one is the export of performance metrics... from a mediation function or from the original exporter.

Regards, Benoit.

Dear Gerhard, Benoit, Gowri, Stan, Paul,

Gerhard, good point. I hope logical OR.

I think BasicList also allows to encode the egress interface indexes of
multicast packets/flows, and the BGP communities of specific destination
IP address. Even AS path can be encoded in a Flow Records. 

It can be considered more sophisticated way than traditional one. I hope
that the examples about Flow Records in the draft are rich to be easy to
understand.

And also, in QoS performance measurement, Exporter or Mediator creates
some metrics every 1 or 2 seconds, so they need to export data record
every 1 or 2 seconds. BasicList allows to encode metrics list during
some periods, such as 60 sec. It can reduce redundancy.

Regards,
Atsushi KOBAYASHI


On Mon, 23 Mar 2009 13:57:58 +0100
Gerhard Muenz <muenz@net.in.tum.de> wrote:

  
Hi Benoit, Gowri, Stan, Paul,

I like your approach of structured data types. Such types, especially
the list type, are urgently needed in the context of PSAMP!
Interestingly, you do not mention these applications in the draft. So,
I'll briefly sketch them:

1) PSAMP Selection Sequence Report Interpretation
-------------------------------------------------

Here, RFC5476 explicitly mentions the need for list types:

   Scope:     selectionSequenceId
   Non-Scope: one Information Element mapping the Observation Point
              selectorId (one or more)

   An Information Element representing the Observation Point would
   typically be taken from the ingressInterface, egressInterface,
   lineCardId, exporterIPv4Address, or exporterIPv6Address Information
   Elements (specified in [RFC5102]), but is not limited to those: any
   Information Element specified in [RFC5102] or [RFC5477] can
   potentially be used.  In case of more complex Observation Points
   (such as a list of interfaces, a bus, etc.), a new Information
    ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
   Element describing the new type of Observation Point must be
   specified, along with an Options Template Record describing it in
   more detail (if necessary).

In fact, this is the business case that you pretend not to see for
Options Templates in 5.2 of your draft ;)


2) PSAMP Property Match Filtering
---------------------------------

>From RFC75476:

   When multiple different Information Elements are defined, the filter
   acts as a logical AND.  Note that the logical OR is not covered by
   these PSAMP specifications.

In practice,  is urgently needed. See my recent discussion
with Andrew on the ML:
http://www.ietf.org/mail-archive/web/ipfix/current/msg04802.html

In draft-sommer-ipfix-mediator-ext-01, we proposed ADTs orderedList,
orderedPair, and portRanges which allow the definition new IEs for port
ranges etc. Your proposal is more generic as it does not require the
specification of a new IE for every purpose where a list is needed.

The OR-semantic of a filter could be solved with a new Information
Element anyList which is derived from the ADT basicList. In contrast to
IE basicList, anyList introduces the semantic that exactly one of the
reported values was observed. As a consequence, we can export an anyList
of port numbers in Property Match Filtering in order to describe a
filter that selects packets given a list of port numbers.


I would appreciate if the above issues were addressed in a future
version of your draft!


Further comments:

    
     3.1. IPFIX Limitations 
...
      To export this information in IPFIX, the data would need to be 
      flattened (thus losing the hierarchical relationships) and a new 
      IPFIX Template created for each alert, according to the number of 
      applicationID elements in each target, the number of targets and 
      attackers in each participant and the number of participants in 
      each alert.  Clearly each Template will be unique to each alert, 
      and a large amount of CPU, memory and export bandwith will be 
      
bandwidth

    
      wasted creating, exporting, maintaining, and withdrawing the 
      Templates.  
      
     4.4.1. basicList 
...
       BasicList Content
       
          A Collection Process decodes list elements from the BasicList 
          Content until no further data remains.  A record count is not 
          included but can be derived when the Information Element is 
          decoded. 
      
Replace record count by field count?

    
     5.2. Structured Data Information Elements Applicability in Options 
        Template Sets 

      All the examples in this document uses the Structured Data 
      
use

    
      Information Elements, abstract data types, and data type semantic 
      in Template Sets.  However, they could also be used in and Options 
      
remove "and"

    
      Template Sets. 
      
    
    8.1. Encoding BasicList 

      Consider encoding an user_record containing the following data: 
      
a user_record


Regards,
Gerhard


Benoit Claise wrote:
    
Dear all,

Here is a new IPFIX draft.
I think that the abstract is quite clear about its goal.

Regards, Benoit.

-------- Original Message --------
Subject: 	I-D ACTION:draft-claise-structured-data-in-ipfix-00.txt
Date: 	Tue, 3 Mar 2009 15:15:01 -0800 (PST)
From: 	Internet-Drafts@ietf.org
Reply-To: 	internet-drafts@ietf.org
To: 	i-d-announce@ietf.org



A New Internet-Draft is available from the on-line Internet-Drafts 
directories.


	Title		: Export of Structured Data in IPFIX
	Author(s)	: B. Claise, G. Dhandapani, S. Yates, P. Aitken
	Filename	: draft-claise-structured-data-in-ipfix-00.txt
	Pages		: 36
	Date		: 2009-3-3
	
        This document specifies an extension to IP Flow Information 
        eXport (IPFIX) protocol specification in [RFC5101] and the IPFIX 
        information model specified in [RFC5102] to support hierarchical 
        structured data and lists (sequences) of Information Elements in 
        data records.  This extension allows definition of complex data 
        structures such as variable-length lists and specification of 
        hierarchical containment relationships between Templates. 

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-claise-structured-data-in-ipfix-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
      
-- 
Dipl.-Ing. Gerhard M〓z
Chair for Network Architectures and Services (I8)
Department of Informatics
Technische Universit舩 M〓chen
Boltzmannstr. 3, 85748 Garching bei M〓chen, 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


    

--- 
Atsushi KOBAYASHI  <akoba@nttv6.net>
NTT Information Sharing Platform Lab.
tel:+81-(0)422-59-3978 fax:+81-(0)422-59-5637

--------------000704060100090802060109-- From muenz@net.in.tum.de Wed Apr 1 04:20: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 3D27F3A6B20 for ; Wed, 1 Apr 2009 04:20:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.135 X-Spam-Level: X-Spam-Status: No, score=-2.135 tagged_above=-999 required=5 tests=[AWL=0.114, BAYES_00=-2.599, 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 sWazfhczuE1G for ; Wed, 1 Apr 2009 04:20:11 -0700 (PDT) Received: from mail-out2.informatik.tu-muenchen.de (mail-out2.informatik.tu-muenchen.de [131.159.0.36]) by core3.amsl.com (Postfix) with ESMTP id 8B6013A677C for ; Wed, 1 Apr 2009 04:20:10 -0700 (PDT) Received: from phoenix.net.informatik.tu-muenchen.de (phoenix.net.informatik.tu-muenchen.de [131.159.14.1]) by services.net.informatik.tu-muenchen.de (Postix Mailer @ mail) with ESMTP id 8F47347372; Wed, 1 Apr 2009 13:21:08 +0200 (CEST) Received: from [131.159.20.108] (repulse.net.informatik.tu-muenchen.de [131.159.20.108]) by phoenix.net.informatik.tu-muenchen.de (Postfix) with ESMTP id 7B796A9B; Wed, 1 Apr 2009 13:21:08 +0200 (CEST) Message-ID: <49D34E26.1050207@net.in.tum.de> Date: Wed, 01 Apr 2009 13:21:10 +0200 From: Gerhard Muenz User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: Benoit Claise References: <49AE3881.3050909@cisco.com> <49C78756.3030204@net.in.tum.de> <49D3443D.5090007@cisco.com> In-Reply-To: <49D3443D.5090007@cisco.com> Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms000904080300080901090000" X-Virus-Scanned: ClamAV using ClamSMTP Cc: "ipfix@ietf.org" Subject: Re: [IPFIX] [Fwd: I-D ACTION:draft-claise-structured-data-in-ipfix-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: Wed, 01 Apr 2009 11:20:12 -0000 This is a cryptographically signed message in MIME format. --------------ms000904080300080901090000 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Benoit, >> 1) PSAMP Selection Sequence Report Interpretation >> ------------------------------------------------- >> >> Here, RFC5476 explicitly mentions the need for list types: >> >> Scope: selectionSequenceId >> Non-Scope: one Information Element mapping the Observation Point >> selectorId (one or more) >> >> An Information Element representing the Observation Point would >> typically be taken from the ingressInterface, egressInterface, >> lineCardId, exporterIPv4Address, or exporterIPv6Address Information= >> Elements (specified in [RFC5102]), but is not limited to those: any= >> Information Element specified in [RFC5102] or [RFC5477] can >> potentially be used. In case of more complex Observation Points >> (such as a list of interfaces, a bus, etc.), a new Information >> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ >> =20 > Good catch. Will be added in the next version. >> Element describing the new type of Observation Point must be >> specified, along with an Options Template Record describing it in >> more detail (if necessary). >> >> In fact, this is the business case that you pretend not to see for >> Options Templates in 5.2 of your draft ;) >> =20 > Maybe. In section 5.2, we mentioned: >=20 > Therefore, a Structured Data Information Element could be used as= =20 > scope in an Options Template Set. However, in practice, the=20 > authors don't see an immediate business case for such a case.=20 >=20 > In the case of selectionSequenceId, the selectionSequenceId is a unique= Id. > We're thinking: do we need a list in the scope field? You are right. Of course, the list of OP identifiers would not appear as a scope field. I should have read the copied text more carefully ;) Regards, Gerhard --=20 Dipl.-Ing. Gerhard M=FCnz Chair for Network Architectures and Services (I8) Department of Informatics Technische Universit=E4t M=FCnchen 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 --------------ms000904080300080901090000 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 ZDCCA2ACAQEwdjBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcg KFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3Vpbmcg Q0ECECrF6t03ZdVGRRmy6Tkgp08wCQYFKw4DAhoFAKCCAcMwGAYJKoZIhvcNAQkDMQsGCSqG SIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMDkwNDAxMTEyMTEwWjAjBgkqhkiG9w0BCQQxFgQU LZIBvgmRTiixGyaHWEr+1QiJN7cwUgYJKoZIhvcNAQkPMUUwQzAKBggqhkiG9w0DBzAOBggq hkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwICASgwgYUG CSsGAQQBgjcQBDF4MHYwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0 aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1 aW5nIENBAhAqxerdN2XVRkUZsuk5IKdPMIGHBgsqhkiG9w0BCRACCzF4oHYwYjELMAkGA1UE BhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMT I1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBAhAqxerdN2XVRkUZsuk5IKdP MA0GCSqGSIb3DQEBAQUABIIBAJNwOtgc+u0b2GeHFDDLVdOh2uVMlmjKYYVWOfaNI3hKE2UI jfSoo6c2DmFCjHDcCto6uRTeLeagFZYClzSdEExt13kSuJBJ3HoqQMU5cq9qfHbXOomnxdpS nXJEgvrFPMcoDdaPwMnPxY4f9ia6P78DXU+VuymJi35nk5u9XJNM4gAEJtPa9gUQn7AOGgFK xz+gQ06mKtd9WxfJAuftpwx9QLLZChmncDQMheQprbbcu7qcTrfSi24/ReNAXcfqx7FSYDQw QWpbGRsUD26+/CTaZ4k3OT6RwQMOMvpjgpQghI6oAM6BRzsBci+ekjGWJlsYkqKxHcBSTvm9 ggOmwUwAAAAAAAA= --------------ms000904080300080901090000-- From irino.hitoshi@lab.ntt.co.jp Wed Apr 1 18:28:04 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 7FF813A6C4D for ; Wed, 1 Apr 2009 18:28:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.56 X-Spam-Level: X-Spam-Status: No, score=0.56 tagged_above=-999 required=5 tests=[AWL=0.650, BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265] 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 pHSLGB476jMB for ; Wed, 1 Apr 2009 18:28:03 -0700 (PDT) Received: from tama50.ecl.ntt.co.jp (tama50.ecl.ntt.co.jp [129.60.39.147]) by core3.amsl.com (Postfix) with ESMTP id DD9693A69FF for ; Wed, 1 Apr 2009 18:27:48 -0700 (PDT) Received: from mfs6.rdh.ecl.ntt.co.jp (mfs6.rdh.ecl.ntt.co.jp [129.60.39.149]) by tama50.ecl.ntt.co.jp (8.14.2/8.14.2) with ESMTP id n321SmtX020400; Thu, 2 Apr 2009 10:28:48 +0900 (JST) Received: from mfs6.rdh.ecl.ntt.co.jp (localhost [127.0.0.1]) by mfs6.rdh.ecl.ntt.co.jp (Postfix) with ESMTP id 0DEEA6603; Thu, 2 Apr 2009 10:28:48 +0900 (JST) Received: from imm.m.ecl.ntt.co.jp (imm0.m.ecl.ntt.co.jp [129.60.5.151]) by mfs6.rdh.ecl.ntt.co.jp (Postfix) with ESMTP id DEA386600; Thu, 2 Apr 2009 10:28:47 +0900 (JST) Received: from [127.0.0.1] ([129.60.80.56]) by imm.m.ecl.ntt.co.jp (8.13.8/8.13.8) with ESMTP id n321SXxg000037; Thu, 2 Apr 2009 10:28:47 +0900 (JST) Message-ID: <49D414D8.5030005@lab.ntt.co.jp> Date: Thu, 02 Apr 2009 10:28:56 +0900 From: Hitoshi Irino Organization: NTT User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: Benoit Claise References: <49C72F0A.9090305@lab.ntt.co.jp> <49D0A6F8.60903@cisco.com> In-Reply-To: <49D0A6F8.60903@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: ipfix@ietf.org Subject: Re: [IPFIX] about Collecting Process MIB objects 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, 02 Apr 2009 01:28:04 -0000 Hello Benoit, > - Furthermore, the proposed mechanism, i.e. compare the > packets/bytes/messages from one table to the sum of the transport > sessionS stats for whatever Template Records/Flow Records are written > into a File is not intuitive. If we want to do something, I'm in favor > of a very simple flag expressing: "I can't deal with all the Flow > Records". Then it's up to the sys admin to investigate the causes. I agree, the flag you proposed is enough to just inform to administrator about unusual state of collector(s). It is easier and simpler than my proposed mechanism. On the other hand, I think that packets/bytes/messages counters for writing can be useful information for investigating the causes. regards, Hitoshi IRINO (2009/03/30 20:03), Benoit Claise wrote: > Hitoshi-san, > > What you trying to achieve is basically a way to have the > application-level acknowledgements, i.e. knowing when the transport > protocol is able to transmit the data, while the collector is not able > to write them down. > > A few points: > - We discussed that capability a long time ago in the WG, and my > recollection is that it was deemed unnecessary to overload the IPFIX > protocol with that mechanism. > - If the Collector can detect that, it might be interesting to flag that > - However, I guess that we don't want to postpone the MIB anymore, as it > was mentioned. So if the group wants to do something, this might be in > the configuration data model (even there is nothing to configure in this > case) > - Furthermore, the proposed mechanism, i.e. compare the > packets/bytes/messages from one table to the sum of the transport > sessionS stats for whatever Template Records/Flow Records are written > into a File is not intuitive. If we want to do something, I'm in favor > of a very simple flag expressing: "I can't deal with all the Flow > Records". Then it's up to the sys admin to investigate the causes. > > Regards, Benoit. > > >> Dear IPFIX-MIB authors and all, >> >> I'd like to propose to add MIB objects about collecting process, if >> you agree and if you can. (I am sorry for my very late opinion, I hit >> on this recently.) >> >> Collected information will be passed to another process (e.g., File >> Writer, Metering Process in Mediators and/or any applications for >> analyzing and/or displaying graphical view in Collectors) from >> collecting process generally, I think. >> >> If the number of processed packets, bytes, and messages in Collecting >> Process (which I call them as >> ipfixCollectingProcessProcessedPackets/Bytes/Messages in this mail >> temporarily) can be got, I think these objects are useful to detect >> failure in Collectors (or Mediators) by comparing >> ipfixTransportSessionPackets/Bytes/Messages and these objects. >> Therefore I'd like to add >> ipfixCollectingProcessProcessedPackets/Bytes/Messages. >> >> An example situation: If a Collector's disk is full filled and File >> Writer will fail in writing, >> ipfixTransportSessionPackets/Bytes/Messages will be increased but >> ipfixCollectingProcessProcessedPackets/Bytes/Messages will not be >> increased when a Collecting Process receives new IPFIX Message. >> >> regards, >> Hitoshi IRINO >> > -- Hitoshi Irino NTT Network Service Systems Laboratories 9-11 Midori-cho 3-Chome, Musashino-shi, Tokyo 180-8585 Japan Tel: +81-422-59-4403 Fax: +81-422-59-4549 From dromasca@avaya.com Thu Apr 2 01:31:54 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 779053A69B8; Thu, 2 Apr 2009 01:31:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.505 X-Spam-Level: X-Spam-Status: No, score=-2.505 tagged_above=-999 required=5 tests=[AWL=0.094, 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 2gfoxIs9mdkg; Thu, 2 Apr 2009 01:31:53 -0700 (PDT) Received: from nj300815-nj-outbound.net.avaya.com (nj300815-nj-outbound.net.avaya.com [198.152.12.100]) by core3.amsl.com (Postfix) with ESMTP id 0650C3A67F1; Thu, 2 Apr 2009 01:31:49 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.39,313,1235970000"; d="scan'208";a="157260726" Received: from unknown (HELO nj300815-nj-erheast.avaya.com) ([198.152.6.5]) by nj300815-nj-outbound.net.avaya.com with ESMTP; 02 Apr 2009 04:32:50 -0400 Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.12]) by nj300815-nj-erheast-out.avaya.com with ESMTP; 02 Apr 2009 04:32:50 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Thu, 2 Apr 2009 10:32:47 +0200 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Moving the MIB work to IPFIX and shutting down PSAMP Thread-Index: AcmzbZpcm5ijnOgXQ+qiiMVuEaNESA== From: "Romascanu, Dan (Dan)" To: Cc: Ronald Bonica , IETF IPFIX Working Group Subject: [IPFIX] Moving the MIB work to IPFIX and shutting down PSAMP 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, 02 Apr 2009 08:31:54 -0000 With the publication of RFC 5474 to RFC 5477 the PSAMP WG charter is completed with the exception of the PSAMP MIB. As previously discussed on the list and at the IPFIX meeting in SF we shall conclude the PSAMP WG and move the MIB work in IPFIX.=20 The mail list will stay open at least for a while for clarification questions and implementation discussions and reports.=20 Dan From dromasca@avaya.com Thu Apr 2 03:15:16 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 9EA783A67A8 for ; Thu, 2 Apr 2009 03:15:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.506 X-Spam-Level: X-Spam-Status: No, score=-2.506 tagged_above=-999 required=5 tests=[AWL=0.093, 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 6+D5ByIBAwpf for ; Thu, 2 Apr 2009 03:15:15 -0700 (PDT) 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 00C8B3A6A2C for ; Thu, 2 Apr 2009 03:15:14 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.39,313,1235970000"; d="txt'?scan'208";a="142054655" Received: from unknown (HELO nj300815-nj-erheast.avaya.com) ([198.152.6.5]) by de307622-de-outbound.net.avaya.com with ESMTP; 02 Apr 2009 06:16:13 -0400 Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.12]) by nj300815-nj-erheast-out.avaya.com with ESMTP; 02 Apr 2009 06:16:13 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----_=_NextPart_001_01C9B37C.0B6C5B23" Date: Thu, 2 Apr 2009 12:16:09 +0200 Message-ID: X-MS-Has-Attach: yes X-MS-TNEF-Correlator: Thread-Topic: Gen-ART LC review of draft-ietf-ipfix-mib-06.txt Thread-Index: AcmzEimVETxQ5oMqTFeGZI2wNJctiwAacNZw From: "Romascanu, Dan (Dan)" To: "IETF IPFIX Working Group" Subject: [IPFIX] FW: Gen-ART LC review of draft-ietf-ipfix-mib-06.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, 02 Apr 2009 10:15:16 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01C9B37C.0B6C5B23 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Document editors and chairs - please consider the issues raised by Brian Carpenter in the General Area review.=20 Thanks and Regards, Dan -----Original Message----- From: Brian E Carpenter [mailto:brian.e.carpenter@gmail.com]=20 Sent: Thursday, April 02, 2009 12:38 AM To: draft-ietf-ipfix-mib@tools.ietf.org; General Area Review Team Cc: ipfix-chairs@tools.ietf.org; Romascanu, Dan (Dan) Subject: Gen-ART LC review of draft-ietf-ipfix-mib-06.txt ------_=_NextPart_001_01C9B37C.0B6C5B23 Content-Type: text/plain; name="draft-ietf-ipfix-mib-06-carpenter.txt" Content-Transfer-Encoding: base64 Content-Description: draft-ietf-ipfix-mib-06-carpenter.txt Content-Disposition: attachment; filename="draft-ietf-ipfix-mib-06-carpenter.txt" SSBoYXZlIGJlZW4gc2VsZWN0ZWQgYXMgdGhlIEdlbmVyYWwgQXJlYSBSZXZpZXcgVGVhbSAoR2Vu LUFSVCkgcmV2aWV3ZXINCmZvciB0aGlzIGRyYWZ0IChmb3IgYmFja2dyb3VuZCBvbiBHZW4tQVJU LCBwbGVhc2Ugc2VlDQpodHRwOi8vd3d3LmFsdmVzdHJhbmQubm8vaWV0Zi9nZW4vYXJ0L2dlbi1h cnQtRkFRLmh0bWwpLg0KUGxlYXNlIHJlc29sdmUgdGhlc2UgY29tbWVudHMgYWxvbmcgd2l0aCBh bnkgb3RoZXIgTGFzdCBDYWxsIGNvbW1lbnRzDQp5b3UgbWF5IHJlY2VpdmUuDQoNCkRvY3VtZW50 OiBkcmFmdC1pZXRmLWlwZml4LW1pYi0wNi50eHQNClJldmlld2VyOiBCcmlhbiBDYXJwZW50ZXIN ClJldmlldyBEYXRlOiAyMDA5LTA0LTAyDQpJRVRGIExDIEVuZCBEYXRlOiAyMDA5LTA0LTAzDQpJ RVNHIFRlbGVjaGF0IGRhdGU6IChpZiBrbm93bikNCg0KU3VtbWFyeTogIFJlYWR5DQotLS0tLS0t LQ0KDQpDb21tZW50czogDQotLS0tLS0tLS0gDQoNClRoZSB0ZWNobmljYWwgZGVzY3JpcHRpb24g aXMgY2xlYXIgYW5kIGRpZCBub3QgcmFpc2UgYW55IHF1ZXN0aW9ucyBpbiBteQ0KbWluZC4gSSBk aWQgbm90IGNoZWNrIHRoZSBNSUIgbW9kdWxlIGluIGRldGFpbC4NCg0KDQpFZGl0b3JpYWwgaXNz dWVzOg0KLS0tLS0tLS0tLS0tLS0tLS0NCg0KSSBxdWVzdGlvbiB3aGV0aGVyIHRoaXMgZG9jdW1l bnQgcmVhbGx5IG5lZWRzIHRoZSBwcmUtNTM3OA0KZGlzY2xhaW1lciAoIlRoaXMgZG9jdW1lbnQg bWF5IGNvbnRhaW4gbWF0ZXJpYWwgZnJvbSBJRVRGIERvY3VtZW50cw0Kb3IgSUVURiBDb250cmli dXRpb25zIHB1Ymxpc2hlZCBvciBtYWRlIHB1YmxpY2x5IGF2YWlsYWJsZSBiZWZvcmUNCk5vdmVt YmVyIDEwLCAyMDA4Li4uIikuIFRoZXJlIGlzIG5vdGhpbmcgaW4gdGhlIEFja25vd2xlZGdtZW50 cw0Kb3IgYW55d2hlcmUgZWxzZSB0byBzdWdnZXN0IHRoYXQgaXQgaW5jb3Jwb3JhdGVzIGFueSBz dWNoIHRleHQuDQpTbyB3aHkgaXMgaXQgdGhlcmU/DQoNClRoaXMgY291bGQgbWF0dGVyLCBzaW5j ZSBhIHJlYWRlciB3aG8gZG9lc24ndCBhY3R1YWxseSB1bmRlcnN0YW5kDQp0aGUgcnVsZXMgaW4g ZGV0YWlsIG1pZ2h0IGNvbmNsdWRlIHRoYXQgZXh0cmFjdGluZyB0aGUgTUlCIHRleHQgYW5kDQpp bmNsdWRpbmcgaXQgaW4gYSBwcm9kdWN0IGlzIG5vdCBhbGxvd2VkLCB3aGVyZWFzICpldmVyeSog dmVyc2lvbg0Kb2YgdGhlIElFVEYgY29weXJpZ2h0IHJ1bGVzIGhhcyBhbGxvd2VkIHRoaXMuIEl0 IHdvdWxkIGJlIGJldHRlcg0KaWYgdGhlIGRpc2NsYWltZXIgY2FuIGJlIGRyb3BwZWQgZnJvbSB0 aGUgUkZDLg0KDQogID09IE91dGRhdGVkIHJlZmVyZW5jZTogZHJhZnQtaWV0Zi1pcGZpeC1hcmNo aXRlY3R1cmUgaGFzIGJlZW4gcHVibGlzaGVkIGFzDQogICAgIFJGQyA1NDcwDQoNCiAgPT0gT3V0 ZGF0ZWQgcmVmZXJlbmNlOiBkcmFmdC1pZXRmLWlwZml4LWFzIGhhcyBiZWVuIHB1Ymxpc2hlZCBh cyBSRkMgNTQ3Mg0KDQogID09IE91dGRhdGVkIHJlZmVyZW5jZTogZHJhZnQtaWV0Zi1wc2FtcC1m cmFtZXdvcmsgaGFzIGJlZW4gcHVibGlzaGVkIGFzIFJGQw0KICAgICA1NDc0DQoNCiAgPT0gT3V0 ZGF0ZWQgcmVmZXJlbmNlOiBkcmFmdC1pZXRmLXBzYW1wLXNhbXBsZS10ZWNoIGhhcyBiZWVuIHB1 Ymxpc2hlZCBhcw0KICAgICBSRkMgNTQ3NQ0KDQogID09IE91dGRhdGVkIHJlZmVyZW5jZTogZHJh ZnQtaWV0Zi1wc2FtcC1wcm90b2NvbCBoYXMgYmVlbiBwdWJsaXNoZWQgYXMgUkZDDQogICAgIDU0 NzY= ------_=_NextPart_001_01C9B37C.0B6C5B23-- From dromasca@avaya.com Thu Apr 2 03:58:24 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 4EE203A6AAD for ; Thu, 2 Apr 2009 03:58:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.506 X-Spam-Level: X-Spam-Status: No, score=-2.506 tagged_above=-999 required=5 tests=[AWL=0.093, 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 b9EmzLdTRDld for ; Thu, 2 Apr 2009 03:58:23 -0700 (PDT) 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 CCC4D3A6953 for ; Thu, 2 Apr 2009 03:58:22 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.39,313,1235970000"; d="txt'?scan'208";a="142057303" Received: from unknown (HELO nj300815-nj-erheast.avaya.com) ([198.152.6.5]) by de307622-de-outbound.net.avaya.com with ESMTP; 02 Apr 2009 06:59:22 -0400 Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.12]) by nj300815-nj-erheast-out.avaya.com with ESMTP; 02 Apr 2009 06:59:21 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----_=_NextPart_001_01C9B382.13EE7578" Date: Thu, 2 Apr 2009 12:59:20 +0200 Message-ID: X-MS-Has-Attach: yes X-MS-TNEF-Correlator: Thread-Topic: Gen-ART review for draft-ietf-ipfix-file-03.txt Thread-Index: AcmzC44b1mtfINB2Sf+53VL7cm4llQAdoCCQ From: "Romascanu, Dan (Dan)" To: "IETF IPFIX Working Group" Subject: [IPFIX] FW: Gen-ART review for draft-ietf-ipfix-file-03.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, 02 Apr 2009 10:58:24 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01C9B382.13EE7578 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable =20 -----Original Message----- From: Vijay K. Gurbani [mailto:vkg@alcatel-lucent.com]=20 Sent: Wednesday, April 01, 2009 11:51 PM To: brian.trammell@hitachi-eu.com; elisa.boschi@hitachi-eu.com; lutz.mark@ifam.fraunhofer.de; tanja.zseby@fokus.fraunhofer.de; arno@wagner.name Cc: gen-art@ietf.org; n.brownlee@auckland.ac.nz; quittek@netlab.nec.de; Romascanu, Dan (Dan) Subject: Gen-ART review for draft-ietf-ipfix-file-03.txt I have been selected as the General Area Review Team (Gen-ART) reviewer for this draft (for background on Gen-ART, please see http://www.alvestrand.no/ietf/gen/art/gen-art-FAQ.html). Please wait for direction from your document shepherd or AD before posting a new version of the draft. Document: draft-ietf-ipfix-file-03.txt Reviewer: Vijay K. Gurbani Review Date: Apr 1, 2009 IESG Telechat date: Apr 3, 2009 Summary: This draft is ready for publication as a Proposed Standard. The draft has 0 major issues, 0 minor issues, and 0 Nits/Editorial comments. Thanks, - vijay -- Vijay K. Gurbani, Bell Laboratories, Alcatel-Lucent 1960 Lucent Lane, Rm. 9C-533, Naperville, Illinois 60566 (USA) Email: vkg@{alcatel-lucent.com,bell-labs.com,acm.org} WWW: http://www.alcatel-lucent.com/bell-labs ------_=_NextPart_001_01C9B382.13EE7578 Content-Type: text/plain; name="file____C__DOCUME~1_VKG_LOCALS~1_TEMP_nsmail-1.txt" Content-Transfer-Encoding: base64 Content-Description: file____C__DOCUME~1_VKG_LOCALS~1_TEMP_nsmail-1.txt Content-Disposition: inline; filename="file____C__DOCUME~1_VKG_LOCALS~1_TEMP_nsmail-1.txt" X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCkdlbi1hcnQg bWFpbGluZyBsaXN0DQpHZW4tYXJ0QGlldGYub3JnDQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWls bWFuL2xpc3RpbmZvL2dlbi1hcnQNCg0K ------_=_NextPart_001_01C9B382.13EE7578-- From paitken@cisco.com Fri Apr 3 04:52:04 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 1EFC13A692E for ; Fri, 3 Apr 2009 04:52:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.236 X-Spam-Level: X-Spam-Status: No, score=-8.236 tagged_above=-999 required=5 tests=[AWL=-1.638, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] 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 h+jSNL9fB-7Q for ; Fri, 3 Apr 2009 04:52:03 -0700 (PDT) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by core3.amsl.com (Postfix) with ESMTP id 49DEB3A67AF for ; Fri, 3 Apr 2009 04:52:03 -0700 (PDT) Received: from ams-dkim-2.cisco.com ([144.254.224.139]) by sj-iport-6.cisco.com with ESMTP; 03 Apr 2009 11:53:05 +0000 Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by ams-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id n33Br40g029049; Fri, 3 Apr 2009 13:53:04 +0200 Received: from [10.61.106.115] (dhcp-10-61-106-115.cisco.com [10.61.106.115]) by ams-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id n33Br4SI007614; Fri, 3 Apr 2009 11:53:04 GMT Message-ID: <49D5F89F.5080603@cisco.com> Date: Fri, 03 Apr 2009 12:53:03 +0100 From: Paul Aitken User-Agent: Mozilla/5.0 (X11; U; Linux i686 (x86_64); en-GB; rv:1.8.1.21) Gecko/20090303 SeaMonkey/1.1.15 MIME-Version: 1.0 To: "ipfix@ietf.org" Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=931; t=1238759584; x=1239623584; c=relaxed/simple; s=amsdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=paitken@cisco.com; z=From:=20Paul=20Aitken=20 |Subject:=20correction=20to=20the=20IPFIX=20Information=20E lements=20registry |Sender:=20; bh=MpiFdB7498kMVMz6q6nvTxqyTLiwq1hz/twug6jcuDM=; b=YGOG3neoz5oY5Y9PJfGzZOmh0/k4ZEPKumEJhXyLcQYsdIVntFRRPektnS rQ23XzUJlgodATyrDWg/0e7fJHuaxj3h/+gu89PPKY2Vm4875sCQ6k6Scakt 0KxToGf6ox; Authentication-Results: ams-dkim-2; header.From=paitken@cisco.com; dkim=pass ( sig from cisco.com/amsdkim2001 verified; ); Cc: Michelle Cotton via RT Subject: [IPFIX] correction to the IPFIX Information Elements registry 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, 03 Apr 2009 11:52:04 -0000 Looking at the IPFIX Information Element registry: http://iana.org/assignments/ipfix/ipfix.xhtml http://iana.org/assignments/ipfix/ipfix.txt The definition of element #91 has been incorrectly duplicated from element #98. The correct definition of #91 is: #91 mplsTopLabelPrefixLength Description: The prefix length of the subnet of the mplsTopLabelIPv4Address that the MPLS top label will cause the Flow to be forwarded to. Abstract Data Type: unsigned 8 Data Type Semantics: ElementId: 91 Status: current Units: bits Range: The valid range is 0-32 Reference: See RFC 3031 for the association between MPLS labels and prefix lengths. Also, the references for #98 contains a typo, "Informaiton Model". I've just submitted a correction to IANA, ticket 233924. Cheers, P. -- Paul Aitken Cisco Systems Ltd, Edinburgh, Scotland. From limmer@informatik.uni-erlangen.de Tue Apr 7 05:17:55 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 7CEDE3A6DCE for ; Tue, 7 Apr 2009 05:17:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.249 X-Spam-Level: X-Spam-Status: No, score=-2.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XmC4GYfoowB6 for ; Tue, 7 Apr 2009 05:17:49 -0700 (PDT) Received: from faui45.informatik.uni-erlangen.de (faui45.informatik.uni-erlangen.de [131.188.34.45]) by core3.amsl.com (Postfix) with ESMTP id 5B5883A6DCA for ; Tue, 7 Apr 2009 05:17:49 -0700 (PDT) Received: from faui7as (faui7as.informatik.uni-erlangen.de [131.188.37.230]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by faui45.informatik.uni-erlangen.de (Postfix) with ESMTPS id A9A4154C4; Tue, 7 Apr 2009 14:18:54 +0200 (MEST) Received: from faui7ma3.informatik.uni-erlangen.de (faui7ma3.informatik.uni-erlangen.de [131.188.37.40]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by faui7as (Postfix) with ESMTPSA id 82B3C438112; Tue, 7 Apr 2009 14:18:54 +0200 (CEST) Message-Id: <0441C576-8C01-4822-9670-D3A507340FF6@informatik.uni-erlangen.de> From: Tobias Limmer To: ipfix@ietf.org Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v930.3) Date: Tue, 7 Apr 2009 14:18:54 +0200 X-Mailer: Apple Mail (2.930.3) Subject: [IPFIX] Vulnerabilities in Flow Meters 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, 07 Apr 2009 12:18:40 -0000 Hi all, flow meters usually employ hashtables for efficient flow aggregation. We analyzed possible vulnerabilities of two software-based Netflow/ IPFIX flow meters, nProbe and Vermont, from an attacker's perspective and discovered some major problems. We found out, that hash functions used in these hashtables are easily exploitable. So attackers are able to decrease the meter's performance drastically and cause packet drops on purpose. More detail is provided in the technical report [1]. Now my question to this list: Has anyone already investigated this problem? What about hardware-based flow meters such as Cisco boxes? My guess is that these are vulnerable, too. Could you provide any information about that topic? Thanks & bye, Tobi [1] -- Dipl.-Inf. Tobias Limmer Computer Networks and Communication Systems University of Erlangen-Nuremberg, Germany Phone: +49 (9131) 85-27931 Fax: +49 (9131) 85-27409 eMail: limmer .at. informatik.uni-erlangen.de WWW: http://www7.informatik.uni-erlangen.de/~limmer From paitken@cisco.com Tue Apr 7 05:28:08 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 D500F3A6D8E for ; Tue, 7 Apr 2009 05:28:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.909 X-Spam-Level: X-Spam-Status: No, score=-9.909 tagged_above=-999 required=5 tests=[AWL=0.690, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] 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 Ii4xhw3yD-ZD for ; Tue, 7 Apr 2009 05:28:08 -0700 (PDT) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by core3.amsl.com (Postfix) with ESMTP id 8CD7B3A689C for ; Tue, 7 Apr 2009 05:28:07 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.39,337,1235952000"; d="scan'208";a="37614063" Received: from ams-dkim-1.cisco.com ([144.254.224.138]) by ams-iport-1.cisco.com with ESMTP; 07 Apr 2009 12:29:13 +0000 Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by ams-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id n37CTD6E028014; Tue, 7 Apr 2009 14:29:13 +0200 Received: from [10.61.110.209] (dhcp-10-61-110-209.cisco.com [10.61.110.209]) by ams-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id n37CTCFV021281; Tue, 7 Apr 2009 12:29:12 GMT Message-ID: <49DB4718.9000108@cisco.com> Date: Tue, 07 Apr 2009 13:29:12 +0100 From: Paul Aitken User-Agent: Mozilla/5.0 (X11; U; Linux i686 (x86_64); en-GB; rv:1.8.1.21) Gecko/20090303 SeaMonkey/1.1.15 MIME-Version: 1.0 To: Tobias Limmer References: <0441C576-8C01-4822-9670-D3A507340FF6@informatik.uni-erlangen.de> In-Reply-To: <0441C576-8C01-4822-9670-D3A507340FF6@informatik.uni-erlangen.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=365; t=1239107353; x=1239971353; c=relaxed/simple; s=amsdkim1002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=paitken@cisco.com; z=From:=20Paul=20Aitken=20 |Subject:=20Re=3A=20[IPFIX]=20Vulnerabilities=20in=20Flow=2 0Meters |Sender:=20; bh=KohojiqQfN8j5IZF5M1OCxm/95iHFegfcchiwP/1zB4=; b=WstO77Ve0+DYfsSbqEiy3ni4HkDuQX+wu1OwcdaKW/kya3vjj64Z4am44m CzGsHqXBGLfLxFlqRTBgu+Lha6652Jaqn2KMbY6QKn62sGFFh8Zwrqc0hP7l SXU3eFjK3d; Authentication-Results: ams-dkim-1; header.From=paitken@cisco.com; dkim=pass ( sig from cisco.com/amsdkim1002 verified; ); Cc: ipfix@ietf.org Subject: Re: [IPFIX] Vulnerabilities in Flow Meters 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, 07 Apr 2009 12:28:08 -0000 Tobi, > What about hardware-based flow meters such as Cisco boxes? My guess > is that these are vulnerable, too. Could you provide any information > about that topic? Rephrased, "can you tell me how to break a cisco box" ? :-( I'm sure we can discuss details of our implementation under NDA. -- Paul Aitken Cisco Systems Ltd, Edinburgh, Scotland. From jeroen@unfix.org Tue Apr 7 05:42:50 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 230CE3A68A8 for ; Tue, 7 Apr 2009 05:42:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.646 X-Spam-Level: X-Spam-Status: No, score=-2.646 tagged_above=-999 required=5 tests=[AWL=-0.046, 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 ccij1mQlxxde for ; Tue, 7 Apr 2009 05:42:49 -0700 (PDT) Received: from abaddon.unfix.org (abaddon.unfix.org [IPv6:2001:41e0:ff00:0:216:3eff:fe00:4]) by core3.amsl.com (Postfix) with ESMTP id ED1863A6767 for ; Tue, 7 Apr 2009 05:42:48 -0700 (PDT) Received: from [IPv6:2001:620:20:1001:216:d3ff:fe25:14da] (spaghetti.zurich.ibm.com [IPv6:2001:620:20:1001:216:d3ff:fe25:14da]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: jeroen) by abaddon.unfix.org (Postfix) with ESMTPSA id 610BB402038; Tue, 7 Apr 2009 14:43:53 +0200 (CEST) Message-ID: <49DB4A84.6050307@spaghetti.zurich.ibm.com> Date: Tue, 07 Apr 2009 14:43:48 +0200 From: Jeroen Massar Organization: Unfix User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.21) Gecko/20090302 Lightning/0.9 Thunderbird/2.0.0.21 Mnenhy/0.7.6.666 MIME-Version: 1.0 To: Paul Aitken References: <0441C576-8C01-4822-9670-D3A507340FF6@informatik.uni-erlangen.de> <49DB4718.9000108@cisco.com> In-Reply-To: <49DB4718.9000108@cisco.com> X-Enigmail-Version: 0.95.7 OpenPGP: id=333E7C23 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enigD100CD07684520ED59C9CC7D" Cc: Tobias Limmer , ipfix@ietf.org Subject: Re: [IPFIX] Vulnerabilities in Flow Meters 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, 07 Apr 2009 12:42:50 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigD100CD07684520ED59C9CC7D Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Paul Aitken wrote: > Tobi, >=20 >> What about hardware-based flow meters such as Cisco boxes? My guess >> is that these are vulnerable, too. Could you provide any information >> about that topic? >=20 > Rephrased, "can you tell me how to break a cisco box" ? :-( >=20 > I'm sure we can discuss details of our implementation under NDA. Which is also the reason why breaking it will be difficult: figuring out the problem in the hash is near impossible, as the general population doesn't have the source/design. As such these kind of implementations will be mostly safe. But what is the problem with all of this? Everybody knows that at one point in time one can DoS a certain point in a network, be it filling up the link or some flow table. Depending on what you want to attack, you pick the point where it breaks first. If you are using software-based flow monitors then you are already at a loss as they won't be able to keep up with 10GE, and most botnets can easily sustain that multiple times. The testing in that 'report' where done on 100mbit links, take a guess how long it takes to fill those up with real truely valid data. The problem in this setup is the probe itself, not the fact that an "attack" is being made. Those things will probably not even survive a slashdot... Thus what are you protecting when this attack happens and what is it that you want to see? Greets, Jeroen --------------enigD100CD07684520ED59C9CC7D Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (MingW32) iD8DBQFJ20qHKaooUjM+fCMRAvdMAJ9Ui8/+8z76HLJY5UO055rNJimzkwCguhvC RcO76dXenapmmWIMk34OUf0= =v1fS -----END PGP SIGNATURE----- --------------enigD100CD07684520ED59C9CC7D-- From root@core3.amsl.com Tue Apr 14 01: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 6DF493A6AD0; Tue, 14 Apr 2009 01:45:01 -0700 (PDT) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20090414084501.6DF493A6AD0@core3.amsl.com> Date: Tue, 14 Apr 2009 01:45:01 -0700 (PDT) Cc: ipfix@ietf.org Subject: [IPFIX] I-D Action:draft-ietf-ipfix-exporting-type-03.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, 14 Apr 2009 08: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 : Exporting Type Information for IPFIX Information Elements Author(s) : E. Boschi, et al. Filename : draft-ietf-ipfix-exporting-type-03.txt Pages : 19 Date : 2009-04-14 This document describes an extension to the IP Flow Information Export (IPFIX) protocol, which is used to represent and transmit data from IP flow measurement devices for collection, storage and analysis, to allow the encoding of IPFIX Information Model properties within an IPFIX Message stream. This enables the export of extended type information for enterprise-specific Information Elements, and the storage of such information within IPFIX Files, facilitating interoperability and reusability among a wide variety of applications and tools. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ipfix-exporting-type-03.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-exporting-type-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2009-04-14014106.I-D@ietf.org> --NextPart-- From dromasca@avaya.com Tue Apr 14 02:12: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 464343A67B6 for ; Tue, 14 Apr 2009 02:12:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.509 X-Spam-Level: X-Spam-Status: No, score=-2.509 tagged_above=-999 required=5 tests=[AWL=0.090, 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 AuEako9nqgXO for ; Tue, 14 Apr 2009 02:12:18 -0700 (PDT) Received: from co300216-co-outbound.net.avaya.com (co300216-co-outbound.net.avaya.com [198.152.13.100]) by core3.amsl.com (Postfix) with ESMTP id 7AB2B3A6840 for ; Tue, 14 Apr 2009 02:12:18 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.40,183,1238990400"; d="scan'208";a="167803655" Received: from unknown (HELO co300216-co-erhwest.avaya.com) ([198.152.7.5]) by co300216-co-outbound.net.avaya.com with ESMTP; 14 Apr 2009 05:13:29 -0400 Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.10]) by co300216-co-erhwest-out.avaya.com with ESMTP; 14 Apr 2009 05:13:29 -0400 X-MIMEOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Tue, 14 Apr 2009 11:12:53 +0200 Message-ID: In-reply-to: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [IPFIX] FW: Gen-ART LC review of draft-ietf-ipfix-mib-06.txt Thread-index: AcmzEimVETxQ5oMqTFeGZI2wNJctiwAacNZwAllNtGA= References: From: "Romascanu, Dan (Dan)" To: "Romascanu, Dan (Dan)" , "IETF IPFIX Working Group" Subject: Re: [IPFIX] FW: Gen-ART LC review of draft-ietf-ipfix-mib-06.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, 14 Apr 2009 09:12:19 -0000 Have these issues been addressed? How?=20 Dan =20 > -----Original Message----- > From: ipfix-bounces@ietf.org [mailto:ipfix-bounces@ietf.org]=20 > On Behalf Of Romascanu, Dan (Dan) > Sent: Thursday, April 02, 2009 1:16 PM > To: IETF IPFIX Working Group > Subject: [IPFIX] FW: Gen-ART LC review of draft-ietf-ipfix-mib-06.txt >=20 > Document editors and chairs - please consider the issues=20 > raised by Brian Carpenter in the General Area review.=20 >=20 > Thanks and Regards, >=20 > Dan >=20 >=20 > -----Original Message----- > From: Brian E Carpenter [mailto:brian.e.carpenter@gmail.com] > Sent: Thursday, April 02, 2009 12:38 AM > To: draft-ietf-ipfix-mib@tools.ietf.org; General Area Review Team > Cc: ipfix-chairs@tools.ietf.org; Romascanu, Dan (Dan) > Subject: Gen-ART LC review of draft-ietf-ipfix-mib-06.txt >=20 >=20 From dromasca@avaya.com Tue Apr 14 02:51:39 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 2808D3A6840 for ; Tue, 14 Apr 2009 02:51:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.509 X-Spam-Level: X-Spam-Status: No, score=-2.509 tagged_above=-999 required=5 tests=[AWL=0.090, 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 D0azBw4BUi0x for ; Tue, 14 Apr 2009 02:51:38 -0700 (PDT) Received: from nj300815-nj-outbound.net.avaya.com (nj300815-nj-outbound.net.avaya.com [198.152.12.100]) by core3.amsl.com (Postfix) with ESMTP id 470533A67A1 for ; Tue, 14 Apr 2009 02:51:38 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.40,183,1238990400"; d="scan'208";a="158327737" Received: from unknown (HELO nj300815-nj-erheast.avaya.com) ([198.152.6.5]) by nj300815-nj-outbound.net.avaya.com with ESMTP; 14 Apr 2009 05:52:49 -0400 Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.10]) by nj300815-nj-erheast-out.avaya.com with ESMTP; 14 Apr 2009 05:52:49 -0400 X-MIMEOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Tue, 14 Apr 2009 11:52:40 +0200 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: draft-ietf-ipfix-exporting-type-03.txt Thread-index: Acm85r/Q2OfjY0mAQ9+KsJ9mk6O59A== From: "Romascanu, Dan (Dan)" To: "IETF IPFIX Working Group" Subject: [IPFIX] draft-ietf-ipfix-exporting-type-03.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, 14 Apr 2009 09:51:39 -0000 I placed draft-ietf-ipfix-exporting-type-03.txt on the agenda of the 4/23 telechat. Note that the IANA review indicates that an IANA expert reviewer needs to be assigned. Please let me know who this individual will be.=20 Thanks and Regards, Dan From mrw@sandstorm.net Tue Apr 14 08:16: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 778CF28C143; Tue, 14 Apr 2009 08:16:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.132 X-Spam-Level: X-Spam-Status: No, score=-2.132 tagged_above=-999 required=5 tests=[AWL=0.133, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] 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 uqEVGgf1pAMB; Tue, 14 Apr 2009 08:16:56 -0700 (PDT) Received: from sirocco.sandstorm.net (sirocco.sandstorm.net [69.33.111.75]) by core3.amsl.com (Postfix) with ESMTP id 2A20028C138; Tue, 14 Apr 2009 08:16:55 -0700 (PDT) Received: from lilac.sandstorm.net (ip-69-33-111-74.bos.megapath.net [69.33.111.74]) (authenticated bits=0) by sirocco.sandstorm.net (8.13.8/8.13.3) with ESMTP id n3EFI11l087077 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 14 Apr 2009 11:18:01 -0400 (EDT) (envelope-from mrw@sandstorm.net) Message-Id: <52A8982A-9405-4A29-BB85-9F43E621CA9E@sandstorm.net> From: Margaret Wasserman To: "Romascanu, Dan (Dan)" In-Reply-To: Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Apple Message framework v930.4) Date: Tue, 14 Apr 2009 11:18:01 -0400 References: X-Mailer: Apple Mail (2.930.4) Cc: ops-dir@ietf.org, IESG IESG , ipfix@ietf.org Subject: Re: [IPFIX] [OPS-DIR] FW: Evaluation: draft-ietf-ipfix-file-03.txt 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: Tue, 14 Apr 2009 15:16:57 -0000 I have some significant concerns about draft-ietf-ipfix-file-03.txt =20 that I would like to discuss. ISSUE #1: Security Requirements This document does not seem to be consistent with its own stated =20 security requirements, nor does it specify any interoperable security =20= mechanisms. In particular, sections 5.6 of the document says: "5.6. Creator Authentication and Confidentiality "Archival storage of flow data may also require assurance that no =20 unauthorized entity can read or modify the stored data. Asymmetric- =20 key cryptography can be applied to this problem, by signing flow data =20= with the private key of the creator, and encrypting it with the public =20= keys of those authorized to read it. The ideal flow storage format =20 will support the encryption and signing of flow data. As with error =20 correction, this problem has been addressed well at a layer below that =20= addressed by this document. Instead of specifying a particular choice =20= of encryption technology, we can leverage the fact Trammell, et al. =20 Expires April 27, 2009 [Page 12] =0C Internet-Draft IPFIX Files October = 20=20 08 that existing cryptographic technologies work quite well on data =20 stored in files to meet this requirement. Beyond support for the use =20 of TLS for transport over TCP or DTLS for transport over SCTP or UDP, =20= both of which provide transient authentication and confidentiality, =20 the IPFIX protocol does not support this requirement directly. It is =20 assumed that this requirement will be met externally." I agree with this section, but I cannot find any place in the document =20= where it describes what type of file signing technology should be =20 implemented in File Readers and Writers, what the certificates would =20 look like and/or how they would be bound to the file data. It also =20 doesn't indicate what encryption technologies should be used by a File =20= Writer to encrypt the file, what elements should/shouldn't be =20 encrypted or how a File Reader would determine what type of decryption =20= to perform. Without including this information, the document is, =20 essentially, suggesting (or nearly mandating) the implementation of =20 non-interoperable security mechanisms. ISSUE #2: Option Scoping There are options defined that are meant to apply to "the the whole =20 IPFIX Transport Session (i.e., the IPFIX File in the common case)", =20 such as the Export Session Details Option. However, the document also =20= indicates that the IPFIX file format is intended to support the free =20 concatenation and splitting of IPFIX files at IPFIX Message =20 boundaries. Is it expected that session-scoped options will appear in =20= all of the messages to which they apply? If not, how would the =20 session boundaries be determined? I see that there are min and max =20 export times in the session scoped options, but I don't see anything =20 that prohibits (or even warns against) concatenating IPFIX sessions =20 with overlapping times. There is some discussion of this topic in =20 section 7.1, where it is stated that File Readers may treat multiple =20 files as a single Transport Session, but that they will not treat a =20 single file as representing multiple Transport Sessions. However, =20 that doesn't seem to be consistent with the "free manipulability of =20 IPFIX Files through concatenation, appending, and splitting (on IPFIX =20= Message boundaries)" described in section 3. ISSUE #3: Data Compression This issues is similar to the security issue described in ISSUE #1 =20 above. The document indicates that data compression is desirable. =20 Section 9.1 talks in details about issues with data compression and =20 suggests that block compression be used. However, the document does =20 not mandate the implementation of any specific compression algorithm, =20= nor does it indicate how a File Reader would determine that a file had =20= been compressed and/or what type of compression was used. Without =20 this information, the document is suggesting the implementation of a =20 non-interoperable compression mechanism. IMO, the three issues I have listed above should be resolved before =20 this document is published. I have very recently started following the work of the ipfix WG, and I =20= have recently subscribed to the mailing list. So, I should be able to =20= see replies that are sent to the list. Thanks for your consideration of these issues. Margaret On Apr 14, 2009, at 6:32 AM, Romascanu, Dan (Dan) wrote: > > > A URL of this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-ipfix-file-03.txt > > Technical Summary > > This document describes a file format for the storage of flow data =20 > based > upon the IPFIX Protocol. It proposes a set of requirements for > flat-file, binary flow data file formats, then specifies the IPFIX =20 > File > format to meet these requirements based upon IPFIX Messages. > This IPFIX File format is designed to facilitate interoperability and > reusability among a wide variety of flow storage, processing, and > analysis tools. > > Working Group Summary > > Work started on this document in 2006, and has gone through several > revisions in response to mailing list discussion. Originally it > included the material about 'exporting type information,' but the WG > split it out into a seperate RFC to make it more easily accessible for > other uses. The WG has reached a clear consensus on this draft. > > Document Quality > > This document has been reviwed by Benoit Claise, Paul Aitken, Andrew > Johnson, and Gerhard Muenz, as well as by the WG chairs. Vijay K. > Gurbani reviewed the document on behaf of GenART. It specifies a file > format for IPFIX data, making the point that this is simply another =20= > data > transport for IPFIX. It does not make any changes to the IPFIX > protocol. > > Personnel > > Nevil Brownlee is the Protocol Shepherd, Dan Romascanu is the > shepherding AD. > > RFC Editor Note > > (Insert RFC Editor Note here or remove section) > > IRTF Note > > (Insert IRTF Note here or remove section) > > IESG Note > > (Insert IESG Note here or remove section) > > IANA Note > > (Insert IANA Note here or remove section) > > > > > > > _______________________________________________ > OPS-DIR mailing list > OPS-DIR@ietf.org > https://www.ietf.org/mailman/listinfo/ops-dir From n.brownlee@auckland.ac.nz Tue Apr 14 09:47:41 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 4A4CF3A6DD4 for ; Tue, 14 Apr 2009 09:47:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fT8KQCk3LlVq for ; Tue, 14 Apr 2009 09:47:40 -0700 (PDT) Received: from mailhost.auckland.ac.nz (curly.its.auckland.ac.nz [130.216.12.33]) by core3.amsl.com (Postfix) with ESMTP id 7FBAD3A6D97 for ; Tue, 14 Apr 2009 09:47:40 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by mailhost.auckland.ac.nz (Postfix) with ESMTP id 1A49B9FCD0; Wed, 15 Apr 2009 04:48:51 +1200 (NZST) X-Virus-Scanned: by amavisd-new at mailhost.auckland.ac.nz Received: from mailhost.auckland.ac.nz ([127.0.0.1]) by localhost (curly.its.auckland.ac.nz [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mH4EZW3ScmAB; Wed, 15 Apr 2009 04:48:50 +1200 (NZST) Received: from [192.172.226.46] (dyn46.caida.org [192.172.226.46]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailhost.auckland.ac.nz (Postfix) with ESMTP id 6DD849FCCF; Wed, 15 Apr 2009 04:48:49 +1200 (NZST) Message-ID: <49E4BE6A.7000908@auckland.ac.nz> Date: Tue, 14 Apr 2009 09:48:42 -0700 From: Nevil Brownlee User-Agent: Thunderbird 2.0.0.21 (X11/20090318) MIME-Version: 1.0 To: "Romascanu, Dan (Dan)" References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: IETF IPFIX Working Group Subject: Re: [IPFIX] draft-ietf-ipfix-exporting-type-03.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, 14 Apr 2009 16:47:41 -0000 Hi Dan: I'd be happy to be an expert reviewer for IANA on this. Cheers, Nevil Romascanu, Dan (Dan) wrote: > I placed draft-ietf-ipfix-exporting-type-03.txt on the agenda of the > 4/23 telechat. Note that the IANA review indicates that an IANA expert > reviewer needs to be assigned. Please let me know who this individual > will be. > > Thanks and Regards, > > Dan > _______________________________________________ > IPFIX mailing list > IPFIX@ietf.org > https://www.ietf.org/mailman/listinfo/ipfix -- --------------------------------------------------------------------- Nevil Brownlee Computer Science Department | ITS Phone: +64 9 373 7599 x88941 The University of Auckland FAX: +64 9 373 7453 Private Bag 92019, Auckland 1142, New Zealand From dromasca@avaya.com Thu Apr 16 00:37:35 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 E315D28C0F1; Thu, 16 Apr 2009 00:37:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.517 X-Spam-Level: X-Spam-Status: No, score=-2.517 tagged_above=-999 required=5 tests=[AWL=0.082, 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 QU5LK0KXeYfI; Thu, 16 Apr 2009 00:37:35 -0700 (PDT) Received: from co300216-co-outbound.net.avaya.com (co300216-co-outbound.net.avaya.com [198.152.13.100]) by core3.amsl.com (Postfix) with ESMTP id DD1DC3A6D05; Thu, 16 Apr 2009 00:37:34 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.40,197,1238990400"; d="scan'208";a="168048181" Received: from unknown (HELO co300216-co-erhwest.avaya.com) ([198.152.7.5]) by co300216-co-outbound.net.avaya.com with ESMTP; 16 Apr 2009 03:38:47 -0400 Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.10]) by co300216-co-erhwest-out.avaya.com with ESMTP; 16 Apr 2009 03:38:46 -0400 X-MIMEOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Thu, 16 Apr 2009 09:38:30 +0200 Message-ID: In-reply-to: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [MIB-DOCTORS] [IPFIX] AD review of draft-ietf-ipfix-mib-05.txt Thread-index: AcmRHJmf24PVuTAzTrOZoe2H0CfpvQPihcJAAcqLQMAFpQf5IA== References: <547F018265F92642B577B986577D671C7009CF@VENUS.office> From: "Romascanu, Dan (Dan)" To: "Romascanu, Dan (Dan)" , "Thomas Dietz" , "IETF IPFIX Working Group" Cc: "MIB Doctors \(E-mail\)" Subject: Re: [IPFIX] [MIB-DOCTORS] AD review of draft-ietf-ipfix-mib-05.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, 16 Apr 2009 07:37:36 -0000 Thomas, I do not think that the pending issues T19 and T21 were addressed properly in draft-ietf-ipfix-mib-06.txt See in-line my concerns.=20 Thanks and Regards, Dan > -----Original Message----- > From: mib-doctors-bounces@ietf.org=20 > [mailto:mib-doctors-bounces@ietf.org] On Behalf Of Romascanu,=20 > Dan (Dan) > Sent: Wednesday, March 18, 2009 3:57 PM > To: Thomas Dietz; IETF IPFIX Working Group > Cc: MIB Doctors (E-mail) > Subject: Re: [MIB-DOCTORS] [IPFIX] AD review of=20 > draft-ietf-ipfix-mib-05.txt >=20 > Thank you for addressing my comments. Most of the issues were=20 > acknowledged and fixed accordingly. T19 and T21 still need=20 > discussion, while T23 needs to be acknowledged by the other editors.=20 >=20 > My question to the WG chairs is whether we should send the=20 > document to IETF Last Call, considering the open issues as=20 > Last Call issues, to be answered and resolved together with=20 > other Last Call comments we receive. >=20 >=20 > Dan > =20 >=20 > > -----Original Message----- > > From: Thomas Dietz [mailto:Thomas.Dietz@nw.neclab.eu] > > Sent: Monday, March 09, 2009 1:26 PM > > To: Romascanu, Dan (Dan); IETF IPFIX Working Group > > Cc: MIB Doctors (E-mail) > > Subject: RE: [IPFIX] AD review of draft-ietf-ipfix-mib-05.txt > >=20 > > Dear Dan, all, > >=20 > > find my comments inline... > >=20 > >=20 > > > T19. I cannot understand what useful information carries=20 > > > ipfixmeteringProcessId - it is not an index and its value is=20 > > > implementation dependent. > >=20 > > We wanted to give a kind of ID to make it possible to identify the=20 > > process that creates the Flow Records. This may be a process id or=20 > > something similar. Maybe we should specify it as process id. This=20 > > needs further discussion. > >=20 This does not seem to be addressed. The object with the current DESCRIPTION clause would not help an implementer understand what is the information to be placed in or a manager to know what to do with it.=20 > >=20 > > > T21. I assume that selection functions will be added in the > > future. If > > > I am wrong please delete all mention of extensibility and > > take out the > > > ipfixSelectorFunctions group. If I am right, I suggest to put=20 > > > ipfixSelectorFunctions in a separate MIB module that will be IANA=20 > > > maintained, so that new functions can be added in the > > future without > > > the need to revise the MIB module and the RFC. The separate > > MIB module > > > will become the initial version of the IANA maintained > > module, and new > > > selector functions will be added using for example Expert Review=20 > > > policy. > > >=20 > > >=20 > >=20 > > I personally think this makes sense to put it in a separate=20 > MIB module=20 > > which is maintained by IANA but this needs further=20 > discussion on the=20 > > list which I will start soon. This does not seem to be addressed From your response it looked like you agreed that moving ipfixSelectorFunctions to a separate IANA-maintained module would be a good idea. Yet, I see that the group is still present in the current MIB, and although it includes only one object ipfixFuncSelectAllAvail - you would need to deprecate it when the IANA-maintained MIB module shows up. This is cumbersome, I suggest to take it out as the object does not provide any useful information any way, from the DESCRIPTION clause it is always at value true.=20 From Thomas.Dietz@nw.neclab.eu Thu Apr 16 00:42:32 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 D711D28C159; Thu, 16 Apr 2009 00:42:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id P2BDsugy+0a2; Thu, 16 Apr 2009 00:42:31 -0700 (PDT) Received: from smtp0.neclab.eu (smtp0.neclab.eu [195.37.70.41]) by core3.amsl.com (Postfix) with ESMTP id 29DB63A6CBC; Thu, 16 Apr 2009 00:42:31 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp0.neclab.eu (Postfix) with ESMTP id ADB9B2C0008EB; Thu, 16 Apr 2009 09:43:43 +0200 (CEST) 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 MhKktVLNpwVG; Thu, 16 Apr 2009 09:43:43 +0200 (CEST) Received: from VENUS.office (mx2.office [192.168.24.15]) by smtp0.neclab.eu (Postfix) with ESMTP id 79ED12C000305; Thu, 16 Apr 2009 09:43:28 +0200 (CEST) Content-class: urn:content-classes:message MIME-Version: 1.0 X-MimeOLE: Produced By Microsoft Exchange V6.5 Date: Thu, 16 Apr 2009 09:43:26 +0200 Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; boundary="----=_NextPart_000_0036_01C9BE77.CA4401D0"; micalg=SHA1 Message-ID: <547F018265F92642B577B986577D671C7FE79E@VENUS.office> In-Reply-To: X-MS-Has-Attach: yes X-MS-TNEF-Correlator: Thread-Topic: [MIB-DOCTORS] [IPFIX] AD review of draft-ietf-ipfix-mib-05.txt Thread-Index: AcmRHJmf24PVuTAzTrOZoe2H0CfpvQPihcJAAcqLQMAFpQf5IAAAc1IQ References: <547F018265F92642B577B986577D671C7009CF@VENUS.office> From: "Thomas Dietz" To: "Romascanu, Dan \(Dan\)" , "IETF IPFIX Working Group" Cc: "MIB Doctors \(E-mail\)" Subject: Re: [IPFIX] [MIB-DOCTORS] AD review of draft-ietf-ipfix-mib-05.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, 16 Apr 2009 07:42:32 -0000 This is a multi-part message in MIME format. ------=_NextPart_000_0036_01C9BE77.CA4401D0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Dear Dan, you are right we need a revised version of the draft. Meanwhile we agreed that for T19 the object will be deleted. For T21 we need to put up the text and the extra MIB module in the draft. I will do that asap. 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: Romascanu, Dan (Dan) [mailto:dromasca@avaya.com] > Sent: Donnerstag, 16. April 2009 09:38 > To: Romascanu, Dan (Dan); Thomas Dietz; IETF IPFIX Working Group > Cc: MIB Doctors (E-mail) > Subject: RE: [MIB-DOCTORS] [IPFIX] AD review of draft-ietf-ipfix-mib- > 05.txt > > Thomas, > > I do not think that the pending issues T19 and T21 were addressed > properly in draft-ietf-ipfix-mib-06.txt > > See in-line my concerns. > > Thanks and Regards, > > Dan > > > > > -----Original Message----- > > From: mib-doctors-bounces@ietf.org > > [mailto:mib-doctors-bounces@ietf.org] On Behalf Of Romascanu, > > Dan (Dan) > > Sent: Wednesday, March 18, 2009 3:57 PM > > To: Thomas Dietz; IETF IPFIX Working Group > > Cc: MIB Doctors (E-mail) > > Subject: Re: [MIB-DOCTORS] [IPFIX] AD review of > > draft-ietf-ipfix-mib-05.txt > > > > Thank you for addressing my comments. Most of the issues were > > acknowledged and fixed accordingly. T19 and T21 still need > > discussion, while T23 needs to be acknowledged by the other editors. > > > > My question to the WG chairs is whether we should send the > > document to IETF Last Call, considering the open issues as > > Last Call issues, to be answered and resolved together with > > other Last Call comments we receive. > > > > > > Dan > > > > > > > -----Original Message----- > > > From: Thomas Dietz [mailto:Thomas.Dietz@nw.neclab.eu] > > > Sent: Monday, March 09, 2009 1:26 PM > > > To: Romascanu, Dan (Dan); IETF IPFIX Working Group > > > Cc: MIB Doctors (E-mail) > > > Subject: RE: [IPFIX] AD review of draft-ietf-ipfix-mib-05.txt > > > > > > Dear Dan, all, > > > > > > find my comments inline... > > > > > > > > > > T19. I cannot understand what useful information carries > > > > ipfixmeteringProcessId - it is not an index and its value is > > > > implementation dependent. > > > > > > We wanted to give a kind of ID to make it possible to identify the > > > process that creates the Flow Records. This may be a process id or > > > something similar. Maybe we should specify it as process id. This > > > needs further discussion. > > > > > This does not seem to be addressed. The object with the current > DESCRIPTION clause would not help an implementer understand what is the > information to be placed in or a manager to know what to do with it. > > > > > > > > T21. I assume that selection functions will be added in the > > > future. If > > > > I am wrong please delete all mention of extensibility and > > > take out the > > > > ipfixSelectorFunctions group. If I am right, I suggest to put > > > > ipfixSelectorFunctions in a separate MIB module that will be IANA > > > > maintained, so that new functions can be added in the > > > future without > > > > the need to revise the MIB module and the RFC. The separate > > > MIB module > > > > will become the initial version of the IANA maintained > > > module, and new > > > > selector functions will be added using for example Expert Review > > > > policy. > > > > > > > > > > > > > > I personally think this makes sense to put it in a separate > > MIB module > > > which is maintained by IANA but this needs further > > discussion on the > > > list which I will start soon. > > This does not seem to be addressed From your response it looked like > you agreed that moving ipfixSelectorFunctions to a separate > IANA-maintained module would be a good idea. Yet, I see that the group > is still present in the current MIB, and although it includes only one > object ipfixFuncSelectAllAvail - you would need to deprecate it when > the > IANA-maintained MIB module shows up. This is cumbersome, I suggest to > take it out as the object does not provide any useful information any > way, from the DESCRIPTION clause it is always at value true. ------=_NextPart_000_0036_01C9BE77.CA4401D0 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 hkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0wOTA0MTYwNzQzMjZaMCMGCSqG SIb3DQEJBDEWBBQakHnrHUOZfAb2EIGPDWdBLvW7uzCBqgYJKwYBBAGCNxAEMYGcMIGZMIGQMQsw CQYDVQQGEwJERTEYMBYGA1UEChMPTkVDIEV1cm9wZSBMdGQuMSAwHgYDVQQLExdORUMgTGFib3Jh dG9yaWVzIEV1cm9wZTESMBAGA1UEAxMJTkVDTEFCLUNBMTEwLwYJKoZIhvcNAQkBFiJ6ZXJ0aWZp emllcnVuZ3NzdGVsbGVAbncubmVjbGFiLmV1AgQNMjRbMIGsBgsqhkiG9w0BCRACCzGBnKCBmTCB kDELMAkGA1UEBhMCREUxGDAWBgNVBAoTD05FQyBFdXJvcGUgTHRkLjEgMB4GA1UECxMXTkVDIExh Ym9yYXRvcmllcyBFdXJvcGUxEjAQBgNVBAMTCU5FQ0xBQi1DQTExMC8GCSqGSIb3DQEJARYiemVy dGlmaXppZXJ1bmdzc3RlbGxlQG53Lm5lY2xhYi5ldQIEDTI0WzCBtwYJKoZIhvcNAQkPMYGpMIGm MAsGCWCGSAFlAwQBKjALBglghkgBZQMEARYwCgYIKoZIhvcNAwcwCwYJYIZIAWUDBAECMA4GCCqG SIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDAHBgUrDgMC GjALBglghkgBZQMEAgMwCwYJYIZIAWUDBAICMAsGCWCGSAFlAwQCATAKBggqhkiG9w0CBTANBgkq hkiG9w0BAQEFAASCAQA1M+gMnl3fFTC4c1Gtypr16q/9w8Mx4Qypj1KKXXQkzqOVfq7eUPXqW5KP aAhx7DDRcRohxv3KvVsCnuK62PX04DY1YDRaz0eloxYXNbVZv1QY97nE/pAMQTcWPTJCYBpKO8y7 VapqDqjk8ErClM0HBwRq662xBg95RCMazzGILoHc1CZHBpUVJbnBxkiYGTtV2DSgi2WczNgg8KG5 9wvJuyzIAMTcZHS9fFWNx/mTaiHBo0/gCJX3R4nRg79LWYWXD47HkpLDW1yqbi8qDdWtwf5aCEM3 OxpmAhl1o/POzeDo9kncsxrDD4bthfJtQgiC+HQoZd+rPZCn1idZU+XDAAAAAAAA ------=_NextPart_000_0036_01C9BE77.CA4401D0-- From fweimer@bfk.de Mon Apr 20 02:17:05 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 301DF3A6E5D for ; Mon, 20 Apr 2009 02:17:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.582 X-Spam-Level: X-Spam-Status: No, score=-0.582 tagged_above=-999 required=5 tests=[AWL=0.178, BAYES_05=-1.11, 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 MqNNOeRFYPf8 for ; Mon, 20 Apr 2009 02:17:04 -0700 (PDT) Received: from mx01.bfk.de (mx01.bfk.de [193.227.124.2]) by core3.amsl.com (Postfix) with ESMTP id 0FDED3A6A97 for ; Mon, 20 Apr 2009 02:17:02 -0700 (PDT) Received: from mx00.int.bfk.de ([10.119.110.2]) by mx01.bfk.de with esmtps (TLS-1.0:RSA_AES_256_CBC_SHA1:32) id 1LvpdV-0006wr-U3; Mon, 20 Apr 2009 11:17:57 +0200 Received: from fweimer by bfk.de with local id 1Lvpdm-0008IP-VB; Mon, 20 Apr 2009 11:18:15 +0200 To: Tobias Limmer References: <0441C576-8C01-4822-9670-D3A507340FF6@informatik.uni-erlangen.de> From: Florian Weimer Date: Mon, 20 Apr 2009 11:18:14 +0200 In-Reply-To: <0441C576-8C01-4822-9670-D3A507340FF6@informatik.uni-erlangen.de> (Tobias Limmer's message of "Tue, 7 Apr 2009 14:18:54 +0200") Message-ID: <82ab6bvg2x.fsf@mid.bfk.de> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Cc: ipfix@ietf.org Subject: Re: [IPFIX] Vulnerabilities in Flow Meters 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, 20 Apr 2009 09:17:05 -0000 * Tobias Limmer: > Now my question to this list: Has anyone already investigated this > problem? In 2003, I've asked a few vendors to look into this when I discovered a similar issue in the Linux route cache (which has been more or less fixed by using a keyed hash based on Jenkins' design). fprobe and a few other code bases in use at that time were affected, too. softflowd is not affected. > [1] > IIRC, the general issue is also mentioned in one of the classic algorithms textbooks, but I forgot which one. --=20 Florian Weimer BFK edv-consulting GmbH http://www.bfk.de/ Kriegsstra=DFe 100 tel: +49-721-96201-1 D-76133 Karlsruhe fax: +49-721-96201-99 From dromasca@avaya.com Mon Apr 20 12:42:02 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 18C543A67F4 for ; Mon, 20 Apr 2009 12:42:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.516 X-Spam-Level: X-Spam-Status: No, score=-2.516 tagged_above=-999 required=5 tests=[AWL=0.083, 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 NSM9J78hv1xL for ; Mon, 20 Apr 2009 12:41:59 -0700 (PDT) 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 9E6363A6A6B for ; Mon, 20 Apr 2009 12:41:58 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.40,218,1238990400"; d="scan'208";a="143586342" Received: from unknown (HELO co300216-co-erhwest.avaya.com) ([198.152.7.5]) by de307622-de-outbound.net.avaya.com with ESMTP; 20 Apr 2009 15:43:12 -0400 Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.14]) by co300216-co-erhwest-out.avaya.com with ESMTP; 20 Apr 2009 15:43:10 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Mon, 20 Apr 2009 21:42:47 +0200 Message-ID: In-Reply-To: <060CE160-0ED0-438D-B556-7384BFE8D541@lilacglade.org> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [OPS-DIR] FW: Evaluation: draft-ietf-ipfix-file-03.txt to Proposed Standard Thread-Index: Acm9Es3MpUQf9hzoQ4y7PEu8YXV0VAE3Q1BA References: <060CE160-0ED0-438D-B556-7384BFE8D541@lilacglade.org> From: "Romascanu, Dan (Dan)" To: Cc: Margaret Wasserman Subject: Re: [IPFIX] [OPS-DIR] FW: Evaluation: draft-ietf-ipfix-file-03.txt 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, 20 Apr 2009 19:42:02 -0000 Editors and Chairs, I did not see yet any answer to the issues raised by Margaret in the OPS-DIR review. Please address these before the IESG telechat on Thursday.=20 Dan > -----Original Message----- > From: Margaret Wasserman [mailto:mrw@lilacglade.org]=20 > Sent: Tuesday, April 14, 2009 6:08 PM > To: Romascanu, Dan (Dan) > Cc: ops-dir@ietf.org; ipfix@ietf.org; IESG IESG > Subject: Re: [OPS-DIR] FW: Evaluation:=20 > draft-ietf-ipfix-file-03.txt to Proposed Standard >=20 >=20 > I have some significant concerns about=20 > draft-ietf-ipfix-file-03.txt that I would like to discuss. >=20 > ISSUE #1: Security Requirements >=20 > This document does not seem to be consistent with its own=20 > stated security requirements, nor does it specify any=20 > interoperable security mechanisms. In particular, sections=20 > 5.6 of the document says: > "5.6. Creator Authentication and Confidentiality "Archival=20 > storage of flow data may also require assurance that no=20 > unauthorized entity can read or modify the stored data.=20 > Asymmetric- key cryptography can be applied to this problem,=20 > by signing flow data with the private key of the creator, and=20 > encrypting it with the public keys of those authorized to=20 > read it. The ideal flow storage format will support the=20 > encryption and signing of flow data. As with error=20 > correction, this problem has been addressed well at a layer=20 > below that addressed by this document. Instead of specifying=20 > a particular choice of encryption technology, we can leverage=20 > the fact Trammell, et al. =20 > Expires April 27, 2009 [Page 12]=0C> Internet-Draft IPFIX Files = October 20 > 08 that existing cryptographic technologies work quite well=20 > on data stored in files to meet this requirement. Beyond=20 > support for the use of TLS for transport over TCP or DTLS for=20 > transport over SCTP or UDP, both of which provide transient=20 > authentication and confidentiality, the IPFIX protocol does=20 > not support this requirement directly. It is assumed that=20 > this requirement will be met externally." > I agree with this section, but I cannot find any place in the=20 > document where it describes what type of file signing=20 > technology should be implemented in File Readers and Writers,=20 > what the certificates would look like and/or how they would=20 > be bound to the file data. It also doesn't indicate what=20 > encryption technologies should be used by a File Writer to=20 > encrypt the file, what elements should/shouldn't be encrypted=20 > or how a File Reader would determine what type of decryption=20 > to perform. Without including this information, the document=20 > is, essentially, suggesting (or nearly mandating) the=20 > implementation of non-interoperable security mechanisms. > ISSUE #2: Option Scoping > There are options defined that are meant to apply to "the the=20 > whole IPFIX Transport Session (i.e., the IPFIX File in the=20 > common case)", such as the Export Session Details Option. =20 > However, the document also indicates that the IPFIX file=20 > format is intended to support the free concatenation and=20 > splitting of IPFIX files at IPFIX Message boundaries. Is it=20 > expected that session-scoped options will appear in all of=20 > the messages to which they apply? If not, how would the=20 > session boundaries be determined? I see that there are min=20 > and max export times in the session scoped options, but I=20 > don't see anything that prohibits (or even warns against)=20 > concatenating IPFIX sessions with overlapping times. There=20 > is some discussion of this topic in section 7.1, where it is=20 > stated that File Readers may treat multiple files as a single=20 > Transport Session, but that they will not treat a single file=20 > as representing multiple Transport Sessions. However, that=20 > doesn't seem to be consistent with the "free manipulability=20 > of IPFIX Files through concatenation, appending, and=20 > splitting (on IPFIX Message boundaries)" described in section 3. > ISSUE #3: Data Compression > This issues is similar to the security issue described in ISSUE #1 =20 > above. The document indicates that data compression is desirable. =20 > Section 9.1 talks in details about issues with data=20 > compression and suggests that block compression be used. =20 > However, the document does not mandate the implementation of=20 > any specific compression algorithm, nor does it indicate how=20 > a File Reader would determine that a file had been compressed=20 > and/or what type of compression was used. Without this=20 > information, the document is suggesting the implementation of=20 > a non-interoperable compression mechanism. > IMO, the three issues I have listed above should be resolved=20 > before this document is published. > I have very recently started following the work of the ipfix=20 > WG, and I have recently subscribed to the mailing list. So,=20 > I should be able to see replies that are sent to the list. > Thanks for your consideration of these issues. > Margaret >=20 > On Apr 14, 2009, at 6:32 AM, Romascanu, Dan (Dan) wrote: >=20 > > > > > > A URL of this Internet-Draft is: > > http://www.ietf.org/internet-drafts/draft-ietf-ipfix-file-03.txt > > > > Technical Summary > > > > This document describes a file format for the storage of flow data=20 > > based upon the IPFIX Protocol. It proposes a set of=20 > requirements for=20 > > flat-file, binary flow data file formats, then specifies the IPFIX=20 > > File format to meet these requirements based upon IPFIX Messages. > > This IPFIX File format is designed to facilitate=20 > interoperability and=20 > > reusability among a wide variety of flow storage, processing, and=20 > > analysis tools. > > > > Working Group Summary > > > > Work started on this document in 2006, and has gone through several=20 > > revisions in response to mailing list discussion. Originally it=20 > > included the material about 'exporting type information,'=20 > but the WG=20 > > split it out into a seperate RFC to make it more easily=20 > accessible for=20 > > other uses. The WG has reached a clear consensus on this draft. > > > > Document Quality > > > > This document has been reviwed by Benoit Claise, Paul=20 > Aitken, Andrew=20 > > Johnson, and Gerhard Muenz, as well as by the WG chairs. Vijay K. > > Gurbani reviewed the document on behaf of GenART. It=20 > specifies a file=20 > > format for IPFIX data, making the point that this is simply another=20 > > data transport for IPFIX. It does not make any changes to=20 > the IPFIX=20 > > protocol. > > > > Personnel > > > > Nevil Brownlee is the Protocol Shepherd, Dan Romascanu is the=20 > > shepherding AD. > > > > RFC Editor Note > > > > (Insert RFC Editor Note here or remove section) > > > > IRTF Note > > > > (Insert IRTF Note here or remove section) > > > > IESG Note > > > > (Insert IESG Note here or remove section) > > > > IANA Note > > > > (Insert IANA Note here or remove section) > > > > > > > > > > > > > > _______________________________________________ > > OPS-DIR mailing list > > OPS-DIR@ietf.org > > https://www.ietf.org/mailman/listinfo/ops-dir >=20 >=20 From trammell@tik.ee.ethz.ch Tue Apr 21 10:09:05 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 1625C3A69CF; Tue, 21 Apr 2009 10:09:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.486 X-Spam-Level: X-Spam-Status: No, score=-6.486 tagged_above=-999 required=5 tests=[AWL=0.113, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] 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 XK0A7MJobI28; Tue, 21 Apr 2009 10:09:03 -0700 (PDT) Received: from smtp.ee.ethz.ch (smtp.ee.ethz.ch [129.132.2.219]) by core3.amsl.com (Postfix) with ESMTP id C8B433A697F; Tue, 21 Apr 2009 10:09:02 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by smtp.ee.ethz.ch (Postfix) with ESMTP id 695ABD9340; Tue, 21 Apr 2009 19:10:15 +0200 (MEST) X-Virus-Scanned: by amavisd-new on smtp.ee.ethz.ch Received: from smtp.ee.ethz.ch ([127.0.0.1]) by localhost (.ee.ethz.ch [127.0.0.1]) (amavisd-new, port 10024) with LMTP id gh7x144eZ1gu; Tue, 21 Apr 2009 19:10:15 +0200 (MEST) Received: from pb-10072.ethz.ch (pb-10072.ethz.ch [82.130.103.195]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: briant) by smtp.ee.ethz.ch (Postfix) with ESMTP id 1B494D934A; Tue, 21 Apr 2009 19:10:15 +0200 (MEST) Message-Id: <8C07FFAE-71E0-46C3-9EBC-74F011AD3E47@tik.ee.ethz.ch> From: Brian Trammell To: Margaret Wasserman In-Reply-To: <52A8982A-9405-4A29-BB85-9F43E621CA9E@sandstorm.net> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v930.3) Date: Tue, 21 Apr 2009 19:10:14 +0200 References: <52A8982A-9405-4A29-BB85-9F43E621CA9E@sandstorm.net> X-Mailer: Apple Mail (2.930.3) Cc: ops-dir@ietf.org, IESG IESG , IETF IPFIX Working Group , draft-ietf-ipfix-file@tools.ietf.org Subject: Re: [IPFIX] [OPS-DIR] FW: Evaluation: draft-ietf-ipfix-file-03.txt 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: Tue, 21 Apr 2009 17:09:05 -0000 Margaret, Thank you for your comprehensive review of the draft; my responses and comments appear inline below: On Apr 14, 2009, at 5:18 PM, Margaret Wasserman wrote: > ISSUE #1: Security Requirements > > This document does not seem to be consistent with its own stated > security requirements, nor does it specify any interoperable > security mechanisms. In particular, sections 5.6 of the document > says: > "5.6. Creator Authentication and Confidentiality > "Archival storage of flow data may also require assurance that no > unauthorized entity can read or modify the stored data. Asymmetric- > key cryptography can be applied to this problem, by signing flow > data with the private key of the creator, and encrypting it with the > public keys of those authorized to read it. The ideal flow storage > format will support the encryption and signing of flow data. As with > error correction, this problem has been addressed well at a layer > below that addressed by this document. Instead of specifying a > particular choice of encryption technology, we can leverage the fact > that existing cryptographic technologies work quite well on data > stored in files to meet this requirement. Beyond support for the use > of TLS for transport over TCP or DTLS for transport over SCTP or > UDP, both of which provide transient authentication and > confidentiality, the IPFIX protocol does not support this > requirement directly. It is assumed that this requirement will be > met externally." > I agree with this section, but I cannot find any place in the > document where it describes what type of file signing technology > should be implemented in File Readers and Writers, what the > certificates would look like and/or how they would be bound to the > file data. It also doesn't indicate what encryption technologies > should be used by a File Writer to encrypt the file, what elements > should/shouldn't be encrypted or how a File Reader would determine > what type of decryption to perform. Without including this > information, the document is, essentially, suggesting (or nearly > mandating) the implementation of non-interoperable security > mechanisms. This was something of a deliberate choice that is, indeed, probably better reviewed. Originally, we were thinking that compression and encryption were far more likely to be used for archival storage applications, where integration into _existing_ storage processes was more important than interoperability. The File Reader is assumed to be told how to decrypt data out of band. However, you are right in pointing out that without guidance this has serious interoperability concerns. Everything that you say here applies, as you say below, to compression as well (on which specifics below). I'm not a crypto expert, so we will want some assistance from someone in the Security Area to at least verify the correctness and feasibility of our choice. The principle of least surprise would seem to dictate that we select something already standardized for encrypting files or file-like data. Symmetric and asymmetric crypto should both be supported. We would also like to actually be able to test interoperability, so working available implementations would be nice too. On an initial admittedly cursory survey, CMS (RFCs 3852 and 4853, perhaps optionally with 5083) would seem to meet these requirements; we would need to provide recommendations on which content types are appropriate for which situations. This has the added advantage of direct compatibility with S/MIME, for people who want to mail IPFIX files about. It seems structurally the best place to specify this would be a mention in 7.1 and 7.2, with further elaboration (including appropriate parts of current section 9.2) in a restructured section 9. (This point consequently implies we'll need a MIME type, which we should probably have anyway.) > ISSUE #2: Option Scoping > There are options defined that are meant to apply to "the the whole > IPFIX Transport Session (i.e., the IPFIX File in the common case)", > such as the Export Session Details Option. However, the document > also indicates that the IPFIX file format is intended to support the > free concatenation and splitting of IPFIX files at IPFIX Message > boundaries. Is it expected that session-scoped options will appear > in all of the messages to which they apply? If not, how would the > session boundaries be determined? I see that there are min and max > export times in the session scoped options, but I don't see anything > that prohibits (or even warns against) concatenating IPFIX sessions > with overlapping times. There is some discussion of this topic in > section 7.1, where it is stated that File Readers may treat multiple > files as a single Transport Session, but that they will not treat a > single file as representing multiple Transport Sessions. However, > that doesn't seem to be consistent with the "free manipulability of > IPFIX Files through concatenation, appending, and splitting (on > IPFIX Message boundaries)" described in section 3. Yes. This is indeed inconsistent, and we'd missed it. Session boundaries are taken to be file boundaries, except in certain specific cases (large collections of very large files, where file sizes are limited by the underlying filesystem or other deployment- time concerns); the point of the sessionScope Information Element is to serve as a "null scope" allowing an Option to be bound to a Session (Options and Templates are taken to expire at Session end anyway, and are furthermore also implicitly scoped to Observation Domain). Free manipulability is only available on files which don't contain any session-scoped information (and are furthermore not compressed or encrypted, of course); these are of course completely legal IPFIX Files. However, on further review, completely arbitrary concatenation operations seem to suffer from further minor problems (template and observation domain ID conflicts, sequence numbering) which the document must also address. My proposed remedy would be as follows: 1. Removal of any mention of free concatenation, appending, and splitting as a feature from the document. This was never a primary requirement of the file format; though it has often been discussed among the authors and the WG as a side-benefit of the format (over, e.g., file formats with explicit header and footer information), the text in section 3 seems to be the only place such language remains. 2. A short mention at an appropriate point in section 7.2 or 8 that when combining multiple files into one, or splitting files into parts, session-level information must be kept consistent, with an enumeration of said information. > ISSUE #3: Data Compression > This issues is similar to the security issue described in ISSUE #1 > above. The document indicates that data compression is desirable. > Section 9.1 talks in details about issues with data compression and > suggests that block compression be used. However, the document does > not mandate the implementation of any specific compression > algorithm, nor does it indicate how a File Reader would determine > that a file had been compressed and/or what type of compression was > used. Without this information, the document is suggesting the > implementation of a non-interoperable compression mechanism. As above, yes. As for selecting a compression format, Section 9.1 states some desirable properties of an IPFIX file compression algorithm. bzip2 meets these (it is indeed mentioned as an example in 9.1), but has the disadvantage of relatively slow compression, and an unclear reference to standardize against (RFC4880 references the homepage, for example). gzip (RFC1952) is more standards-friendly and in the general case faster to compress, but may have resynchronization issues in the face of errors. It seems relatively easy to specify both (bz2 and gz streams can be distinguished by their magic numbers), but I'm not certain which I would recommend as mandatory. I'll say what I said here for encryption: it seems structurally the best place to specify this would be a mention in 7.1 and 7.2, with further elaboration (including appropriate parts of current section 9.1) in a restructured section 9. > IMO, the three issues I have listed above should be resolved before > this document is published. Agreed on all three points; hopefully these proposals will move us toward their resolution. Thanks again, and best regards, Brian From dromasca@avaya.com Tue Apr 21 10:44:32 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 364A13A6AE0; Tue, 21 Apr 2009 10:44:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.518 X-Spam-Level: X-Spam-Status: No, score=-2.518 tagged_above=-999 required=5 tests=[AWL=0.081, 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 kXnRgcKdVUgi; Tue, 21 Apr 2009 10:44:30 -0700 (PDT) Received: from co300216-co-outbound.net.avaya.com (co300216-co-outbound.net.avaya.com [198.152.13.100]) by core3.amsl.com (Postfix) with ESMTP id 9B04A3A690C; Tue, 21 Apr 2009 10:44:30 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.40,225,1238990400"; d="scan'208";a="168574215" Received: from unknown (HELO co300216-co-erhwest.avaya.com) ([198.152.7.5]) by co300216-co-outbound.net.avaya.com with ESMTP; 21 Apr 2009 13:45:46 -0400 Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.14]) by co300216-co-erhwest-out.avaya.com with ESMTP; 21 Apr 2009 13:45:45 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Tue, 21 Apr 2009 19:45:24 +0200 Message-ID: In-Reply-To: <8C07FFAE-71E0-46C3-9EBC-74F011AD3E47@tik.ee.ethz.ch> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [IPFIX] [OPS-DIR] FW: Evaluation: draft-ietf-ipfix-file-03.txt to Proposed Standard Thread-Index: AcnCpAxSA6vaERp/S7SK5avkH3HJtgAAZRBA References: <52A8982A-9405-4A29-BB85-9F43E621CA9E@sandstorm.net> <8C07FFAE-71E0-46C3-9EBC-74F011AD3E47@tik.ee.ethz.ch> From: "Romascanu, Dan (Dan)" To: "Brian Trammell" , "Margaret Wasserman" Cc: draft-ietf-ipfix-file@tools.ietf.org, ops-dir@ietf.org, IESG IESG , IETF IPFIX Working Group Subject: Re: [IPFIX] [OPS-DIR] FW: Evaluation: draft-ietf-ipfix-file-03.txt 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: Tue, 21 Apr 2009 17:44:32 -0000 Thanks, Brian. I am entering Margaret's issues in a COMMENT, waiting for one of the AD's who did not yet enter a position to take these in a DISCUSS.=20 Also we can probably use the advice of one of the Security AD's on issue #1. Dan =20 > -----Original Message----- > From: Brian Trammell [mailto:trammell@tik.ee.ethz.ch]=20 > Sent: Tuesday, April 21, 2009 8:10 PM > To: Margaret Wasserman > Cc: Romascanu, Dan (Dan); ops-dir@ietf.org; IESG IESG; IETF=20 > IPFIX Working Group; draft-ietf-ipfix-file@tools.ietf.org > Subject: Re: [IPFIX] [OPS-DIR] FW: Evaluation:=20 > draft-ietf-ipfix-file-03.txt to Proposed Standard >=20 > Margaret, >=20 > Thank you for your comprehensive review of the draft; my=20 > responses and comments appear inline below: >=20 > On Apr 14, 2009, at 5:18 PM, Margaret Wasserman wrote: >=20 > > ISSUE #1: Security Requirements > > > > This document does not seem to be consistent with its own stated=20 > > security requirements, nor does it specify any=20 > interoperable security=20 > > mechanisms. In particular, sections 5.6 of the document > > says: > > "5.6. Creator Authentication and Confidentiality "Archival=20 > storage of=20 > > flow data may also require assurance that no unauthorized=20 > entity can=20 > > read or modify the stored data. Asymmetric- key cryptography can be=20 > > applied to this problem, by signing flow data with the=20 > private key of=20 > > the creator, and encrypting it with the public keys of those=20 > > authorized to read it. The ideal flow storage format will=20 > support the=20 > > encryption and signing of flow data. As with error correction, this=20 > > problem has been addressed well at a layer below that addressed by=20 > > this document. Instead of specifying a particular choice of=20 > encryption=20 > > technology, we can leverage the fact that existing cryptographic=20 > > technologies work quite well on data stored in files to meet this=20 > > requirement. Beyond support for the use of TLS for=20 > transport over TCP=20 > > or DTLS for transport over SCTP or UDP, both of which provide=20 > > transient authentication and confidentiality, the IPFIX=20 > protocol does=20 > > not support this requirement directly. It is assumed that this=20 > > requirement will be met externally." > > I agree with this section, but I cannot find any place in=20 > the document=20 > > where it describes what type of file signing technology should be=20 > > implemented in File Readers and Writers, what the=20 > certificates would=20 > > look like and/or how they would be bound to the file data. It also=20 > > doesn't indicate what encryption technologies should be=20 > used by a File=20 > > Writer to encrypt the file, what elements should/shouldn't be=20 > > encrypted or how a File Reader would determine what type of=20 > decryption=20 > > to perform. Without including this information, the document is,=20 > > essentially, suggesting (or nearly > > mandating) the implementation of non-interoperable security=20 > > mechanisms. >=20 > This was something of a deliberate choice that is, indeed,=20 > probably better reviewed. Originally, we were thinking that=20 > compression and encryption were far more likely to be used=20 > for archival storage applications, where integration into=20 > _existing_ storage processes was more important than=20 > interoperability. The File Reader is assumed to be told how=20 > to decrypt data out of band. However, you are right in=20 > pointing out that without guidance this has serious=20 > interoperability concerns. Everything that you say here=20 > applies, as you say below, to compression as well (on which=20 > specifics below). >=20 > I'm not a crypto expert, so we will want some assistance from=20 > someone in the Security Area to at least verify the=20 > correctness and feasibility of our choice. The principle of=20 > least surprise would seem to dictate that we select something=20 > already standardized for encrypting files or file-like data.=20 > Symmetric and asymmetric crypto should both be supported. We=20 > would also like to actually be able to test interoperability,=20 > so working available implementations would be nice too. >=20 > On an initial admittedly cursory survey, CMS (RFCs 3852 and=20 > 4853, perhaps optionally with 5083) would seem to meet these=20 > requirements; we would need to provide recommendations on=20 > which content types are appropriate for which situations.=20 > This has the added advantage of direct compatibility with=20 > S/MIME, for people who want to mail IPFIX files about. >=20 > It seems structurally the best place to specify this would be=20 > a mention in 7.1 and 7.2, with further elaboration (including=20 > appropriate parts of current section 9.2) in a restructured section 9. >=20 > (This point consequently implies we'll need a MIME type,=20 > which we should probably have anyway.) >=20 > > ISSUE #2: Option Scoping > > There are options defined that are meant to apply to "the the whole=20 > > IPFIX Transport Session (i.e., the IPFIX File in the common case)",=20 > > such as the Export Session Details Option. However, the=20 > document also=20 > > indicates that the IPFIX file format is intended to support=20 > the free=20 > > concatenation and splitting of IPFIX files at IPFIX Message=20 > > boundaries. Is it expected that session-scoped options=20 > will appear in=20 > > all of the messages to which they apply? If not, how would the=20 > > session boundaries be determined? I see that there are min and max=20 > > export times in the session scoped options, but I don't see=20 > anything=20 > > that prohibits (or even warns against) concatenating IPFIX sessions=20 > > with overlapping times. There is some discussion of this topic in=20 > > section 7.1, where it is stated that File Readers may treat=20 > multiple=20 > > files as a single Transport Session, but that they will not treat a=20 > > single file as representing multiple Transport Sessions. However,=20 > > that doesn't seem to be consistent with the "free manipulability of=20 > > IPFIX Files through concatenation, appending, and splitting=20 > (on IPFIX=20 > > Message boundaries)" described in section 3. >=20 > Yes. This is indeed inconsistent, and we'd missed it. >=20 > Session boundaries are taken to be file boundaries, except in=20 > certain specific cases (large collections of very large=20 > files, where file sizes are limited by the underlying=20 > filesystem or other deployment- time concerns); the point of=20 > the sessionScope Information Element is to serve as a "null=20 > scope" allowing an Option to be bound to a Session (Options=20 > and Templates are taken to expire at Session end anyway, and=20 > are furthermore also implicitly scoped to Observation Domain). >=20 > Free manipulability is only available on files which don't=20 > contain any session-scoped information (and are furthermore=20 > not compressed or encrypted, of course); these are of course=20 > completely legal IPFIX Files. However, on further review,=20 > completely arbitrary concatenation operations seem to suffer=20 > from further minor problems (template and observation domain=20 > ID conflicts, sequence numbering) which the document must=20 > also address. My proposed remedy would be as follows: >=20 > 1. Removal of any mention of free concatenation, appending,=20 > and splitting as a feature from the document. This was never=20 > a primary requirement of the file format; though it has often=20 > been discussed among the authors and the WG as a side-benefit=20 > of the format (over, e.g., file formats with explicit header=20 > and footer information), the text in section 3 seems to be=20 > the only place such language remains. >=20 > 2. A short mention at an appropriate point in section 7.2 or=20 > 8 that when combining multiple files into one, or splitting=20 > files into parts, session-level information must be kept=20 > consistent, with an enumeration of said information. >=20 > > ISSUE #3: Data Compression > > This issues is similar to the security issue described in ISSUE #1 =20 > > above. The document indicates that data compression is=20 > desirable. =20 > > Section 9.1 talks in details about issues with data compression and=20 > > suggests that block compression be used. However, the=20 > document does=20 > > not mandate the implementation of any specific compression=20 > algorithm,=20 > > nor does it indicate how a File Reader would determine that=20 > a file had=20 > > been compressed and/or what type of compression was used. Without=20 > > this information, the document is suggesting the=20 > implementation of a=20 > > non-interoperable compression mechanism. >=20 > As above, yes. >=20 > As for selecting a compression format, Section 9.1 states=20 > some desirable properties of an IPFIX file compression=20 > algorithm. bzip2 meets these (it is indeed mentioned as an=20 > example in 9.1), but has the disadvantage of relatively slow=20 > compression, and an unclear reference to standardize against=20 > (RFC4880 references the homepage, for example). =20 > gzip (RFC1952) is more standards-friendly and in the general=20 > case faster to compress, but may have resynchronization=20 > issues in the face of errors. >=20 > It seems relatively easy to specify both (bz2 and gz streams=20 > can be distinguished by their magic numbers), but I'm not=20 > certain which I would recommend as mandatory. >=20 > I'll say what I said here for encryption: it seems=20 > structurally the best place to specify this would be a=20 > mention in 7.1 and 7.2, with further elaboration (including=20 > appropriate parts of current section > 9.1) in a restructured section 9. >=20 > > IMO, the three issues I have listed above should be resolved before=20 > > this document is published. >=20 > Agreed on all three points; hopefully these proposals will=20 > move us toward their resolution. >=20 > Thanks again, and best regards, >=20 > Brian >=20 >=20 From mrw@sandstorm.net Thu Apr 23 09:13:47 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 DA73928C6CA; Thu, 23 Apr 2009 09:13:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.176 X-Spam-Level: X-Spam-Status: No, score=-2.176 tagged_above=-999 required=5 tests=[AWL=0.089, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] 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 w9747YfUdf+q; Thu, 23 Apr 2009 09:13:46 -0700 (PDT) Received: from sirocco.sandstorm.net (sirocco.sandstorm.net [69.33.111.75]) by core3.amsl.com (Postfix) with ESMTP id 5A5A328C6C8; Thu, 23 Apr 2009 09:13:46 -0700 (PDT) Received: from [10.2.1.23] (ip-69-33-111-74.bos.megapath.net [69.33.111.74]) (authenticated bits=0) by sirocco.sandstorm.net (8.13.8/8.13.3) with ESMTP id n3NGEuGi097726 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 23 Apr 2009 12:14:57 -0400 (EDT) (envelope-from mrw@sandstorm.net) Message-ID: <49F09400.5050901@sandstorm.net> Date: Thu, 23 Apr 2009 12:14:56 -0400 From: Margaret Wasserman User-Agent: Thunderbird 1.5.0.7 (X11/20061027) MIME-Version: 1.0 To: Brian Trammell References: <52A8982A-9405-4A29-BB85-9F43E621CA9E@sandstorm.net> <8C07FFAE-71E0-46C3-9EBC-74F011AD3E47@tik.ee.ethz.ch> In-Reply-To: <8C07FFAE-71E0-46C3-9EBC-74F011AD3E47@tik.ee.ethz.ch> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: ops-dir@ietf.org, IESG IESG , IETF IPFIX Working Group , draft-ietf-ipfix-file@tools.ietf.org Subject: Re: [IPFIX] [OPS-DIR] FW: Evaluation: draft-ietf-ipfix-file-03.txt 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: Thu, 23 Apr 2009 16:13:47 -0000 Hi Brian, This all sounds good. Please let me know if there is anything I can do to help. Margaret Brian Trammell wrote: > Margaret, > > Thank you for your comprehensive review of the draft; my responses and > comments appear inline below: > > On Apr 14, 2009, at 5:18 PM, Margaret Wasserman wrote: > >> ISSUE #1: Security Requirements >> >> This document does not seem to be consistent with its own stated >> security requirements, nor does it specify any interoperable security >> mechanisms. In particular, sections 5.6 of the document says: >> "5.6. Creator Authentication and Confidentiality >> "Archival storage of flow data may also require assurance that no >> unauthorized entity can read or modify the stored data. Asymmetric- >> key cryptography can be applied to this problem, by signing flow data >> with the private key of the creator, and encrypting it with the public >> keys of those authorized to read it. The ideal flow storage format >> will support the encryption and signing of flow data. As with error >> correction, this problem has been addressed well at a layer below that >> addressed by this document. Instead of specifying a particular choice >> of encryption technology, we can leverage the fact that existing >> cryptographic technologies work quite well on data stored in files to >> meet this requirement. Beyond support for the use of TLS for transport >> over TCP or DTLS for transport over SCTP or UDP, both of which provide >> transient authentication and confidentiality, the IPFIX protocol does >> not support this requirement directly. It is assumed that this >> requirement will be met externally." >> I agree with this section, but I cannot find any place in the document >> where it describes what type of file signing technology should be >> implemented in File Readers and Writers, what the certificates would >> look like and/or how they would be bound to the file data. It also >> doesn't indicate what encryption technologies should be used by a File >> Writer to encrypt the file, what elements should/shouldn't be >> encrypted or how a File Reader would determine what type of decryption >> to perform. Without including this information, the document is, >> essentially, suggesting (or nearly mandating) the implementation of >> non-interoperable security mechanisms. > > This was something of a deliberate choice that is, indeed, probably > better reviewed. Originally, we were thinking that compression and > encryption were far more likely to be used for archival storage > applications, where integration into _existing_ storage processes was > more important than interoperability. The File Reader is assumed to be > told how to decrypt data out of band. However, you are right in pointing > out that without guidance this has serious interoperability concerns. > Everything that you say here applies, as you say below, to compression > as well (on which specifics below). > > I'm not a crypto expert, so we will want some assistance from someone in > the Security Area to at least verify the correctness and feasibility of > our choice. The principle of least surprise would seem to dictate that > we select something already standardized for encrypting files or > file-like data. Symmetric and asymmetric crypto should both be > supported. We would also like to actually be able to test > interoperability, so working available implementations would be nice too. > > On an initial admittedly cursory survey, CMS (RFCs 3852 and 4853, > perhaps optionally with 5083) would seem to meet these requirements; we > would need to provide recommendations on which content types are > appropriate for which situations. This has the added advantage of direct > compatibility with S/MIME, for people who want to mail IPFIX files about. > > It seems structurally the best place to specify this would be a mention > in 7.1 and 7.2, with further elaboration (including appropriate parts of > current section 9.2) in a restructured section 9. > > (This point consequently implies we'll need a MIME type, which we should > probably have anyway.) > >> ISSUE #2: Option Scoping >> There are options defined that are meant to apply to "the the whole >> IPFIX Transport Session (i.e., the IPFIX File in the common case)", >> such as the Export Session Details Option. However, the document also >> indicates that the IPFIX file format is intended to support the free >> concatenation and splitting of IPFIX files at IPFIX Message >> boundaries. Is it expected that session-scoped options will appear in >> all of the messages to which they apply? If not, how would the >> session boundaries be determined? I see that there are min and max >> export times in the session scoped options, but I don't see anything >> that prohibits (or even warns against) concatenating IPFIX sessions >> with overlapping times. There is some discussion of this topic in >> section 7.1, where it is stated that File Readers may treat multiple >> files as a single Transport Session, but that they will not treat a >> single file as representing multiple Transport Sessions. However, >> that doesn't seem to be consistent with the "free manipulability of >> IPFIX Files through concatenation, appending, and splitting (on IPFIX >> Message boundaries)" described in section 3. > > Yes. This is indeed inconsistent, and we'd missed it. > > Session boundaries are taken to be file boundaries, except in certain > specific cases (large collections of very large files, where file sizes > are limited by the underlying filesystem or other deployment-time > concerns); the point of the sessionScope Information Element is to serve > as a "null scope" allowing an Option to be bound to a Session (Options > and Templates are taken to expire at Session end anyway, and are > furthermore also implicitly scoped to Observation Domain). > > Free manipulability is only available on files which don't contain any > session-scoped information (and are furthermore not compressed or > encrypted, of course); these are of course completely legal IPFIX Files. > However, on further review, completely arbitrary concatenation > operations seem to suffer from further minor problems (template and > observation domain ID conflicts, sequence numbering) which the document > must also address. My proposed remedy would be as follows: > > 1. Removal of any mention of free concatenation, appending, and > splitting as a feature from the document. This was never a primary > requirement of the file format; though it has often been discussed among > the authors and the WG as a side-benefit of the format (over, e.g., file > formats with explicit header and footer information), the text in > section 3 seems to be the only place such language remains. > > 2. A short mention at an appropriate point in section 7.2 or 8 that when > combining multiple files into one, or splitting files into parts, > session-level information must be kept consistent, with an enumeration > of said information. > >> ISSUE #3: Data Compression >> This issues is similar to the security issue described in ISSUE #1 >> above. The document indicates that data compression is desirable. >> Section 9.1 talks in details about issues with data compression and >> suggests that block compression be used. However, the document does >> not mandate the implementation of any specific compression algorithm, >> nor does it indicate how a File Reader would determine that a file had >> been compressed and/or what type of compression was used. Without >> this information, the document is suggesting the implementation of a >> non-interoperable compression mechanism. > > As above, yes. > > As for selecting a compression format, Section 9.1 states some desirable > properties of an IPFIX file compression algorithm. bzip2 meets these (it > is indeed mentioned as an example in 9.1), but has the disadvantage of > relatively slow compression, and an unclear reference to standardize > against (RFC4880 references the homepage, for example). gzip (RFC1952) > is more standards-friendly and in the general case faster to compress, > but may have resynchronization issues in the face of errors. > > It seems relatively easy to specify both (bz2 and gz streams can be > distinguished by their magic numbers), but I'm not certain which I would > recommend as mandatory. > > I'll say what I said here for encryption: it seems structurally the best > place to specify this would be a mention in 7.1 and 7.2, with further > elaboration (including appropriate parts of current section 9.1) in a > restructured section 9. > >> IMO, the three issues I have listed above should be resolved before >> this document is published. > > Agreed on all three points; hopefully these proposals will move us > toward their resolution. > > Thanks again, and best regards, > > Brian > From dromasca@avaya.com Thu Apr 23 10:24:11 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 9BB363A6D48 for ; Thu, 23 Apr 2009 10:24:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.513 X-Spam-Level: X-Spam-Status: No, score=-2.513 tagged_above=-999 required=5 tests=[AWL=0.086, 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 bb7o60JJDTYE for ; Thu, 23 Apr 2009 10:24:11 -0700 (PDT) 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 3638A3A72EA for ; Thu, 23 Apr 2009 10:24:05 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.40,236,1238990400"; d="scan'208";a="143940215" Received: from unknown (HELO nj300815-nj-erheast.avaya.com) ([198.152.6.5]) by de307622-de-outbound.net.avaya.com with ESMTP; 23 Apr 2009 13:25:21 -0400 Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.14]) by nj300815-nj-erheast-out.avaya.com with ESMTP; 23 Apr 2009 13:25:20 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Thu, 23 Apr 2009 19:25:18 +0200 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Both IPFIX documents in Revised ID status Thread-Index: AcnEOHjxZvlX3r65TLGuEyPvuPNzqQ== From: "Romascanu, Dan (Dan)" To: "IETF IPFIX Working Group" Subject: [IPFIX] Both IPFIX documents in Revised ID status 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, 23 Apr 2009 17:24:11 -0000 Both IPFIX documents that were today on the IESG agenda (draft-ietf-ipfix-exporting-type, draft-ietf-ipfix-file) were discussed and placed in Revised ID Needed status. This is no surprise I guess, as the DISCUSSes raised seem to need rather intensive edits. Please work to fix them, and issue revised versions as soon as possible.=20 Thanks and Regards, Dan From bclaise@cisco.com Mon Apr 27 01:28: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 C0E8F3A6F3B for ; Mon, 27 Apr 2009 01:28:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.514 X-Spam-Level: X-Spam-Status: No, score=-2.514 tagged_above=-999 required=5 tests=[AWL=0.084, BAYES_00=-2.599, HTML_MESSAGE=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 IWFx5RNQhruB for ; Mon, 27 Apr 2009 01:28:21 -0700 (PDT) Received: from av-tac-bru.cisco.com (weird-brew.cisco.com [144.254.15.118]) by core3.amsl.com (Postfix) with ESMTP id 78B773A6B69 for ; Mon, 27 Apr 2009 01:28:21 -0700 (PDT) X-TACSUNS: Virus Scanned Received: from strange-brew.cisco.com (localhost.cisco.com [127.0.0.1]) by av-tac-bru.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id n3R7qtIZ017313; Mon, 27 Apr 2009 09:52:55 +0200 (CEST) Received: from [10.55.43.55] (ams-bclaise-8716.cisco.com [10.55.43.55]) by strange-brew.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id n3R7qs60025892; Mon, 27 Apr 2009 09:52:54 +0200 (CEST) Message-ID: <49F56456.3000506@cisco.com> Date: Mon, 27 Apr 2009 09:52:54 +0200 From: Benoit Claise User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: ipfix-chairs@tools.ietf.org References: <49787312.3000305@cisco.com> In-Reply-To: <49787312.3000305@cisco.com> Content-Type: multipart/alternative; boundary="------------090006080702050407050400" Cc: ipfix@ietf.org Subject: Re: [IPFIX] draft-ietf-ipfix-export-per-sctp-stream version 1 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, 27 Apr 2009 08:28:22 -0000 This is a multi-part message in MIME format. --------------090006080702050407050400 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Dear IPFIX-chairs, Can we please progress this draft: this I-D was not yet submitted by the WG to the IESG. This draft has been untouched for 3 months, as there is nothing more to be done on the authors side. Regards, Benoit. > Dear all, > > >From the last IPFIX meeting minutes at > http://www.ietf.org/proceedings/08nov/minutes/ipfix.txt, there was > only a single concern regarding the > draft-ietf-ipfix-export-per-sctp-stream draft after the WGLC: > > - draft-ietf-ipfix-export-per-sctp-stream-00 > ============================================ > Benoit: > WGLC finished. > Clarifications on the interaction with RFC5101. > Only one opern issues left: There is a normative reference to > SCTP-RESET draft (draft-stewart-tsvwg-sctpstrrst-00.txt) from the > Transport WG. This ID describes allows the addition of streams within > an existing SCTP association as this functionality is required. > > Dan (AD): > This draft cannot be a normative reference as long as it is > not adopted by a the TSVWG. Suggestion: describe the mechanism in the > normative part of the text and add an informative reference to the > SCTP-RESET document. Once the document is included in the Transport WG > charter it can be used as a normative reference. > > Juergen: > Authors of draft-stewart-tsvwg-sctpstrrst-00.txt should review the > inserted text. > > > A new version of the draft has been posted, which addresses this > issue. Obviously the authors from > draft-stewart-tsvwg-sctpstrrst-00.txt were involved in the process. > This draft can now move to the next step towards RFC... > > Regards, Benoit. > ------------------------------------------------------------------------ > > _______________________________________________ > IPFIX mailing list > IPFIX@ietf.org > https://www.ietf.org/mailman/listinfo/ipfix > --------------090006080702050407050400 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Dear IPFIX-chairs,

Can we please progress this draft: this I-D was not yet submitted by the WG to the IESG.
This draft has been untouched for 3 months, as there is nothing more to be done on the authors side.

Regards, Benoit.
Dear all,

>From the last IPFIX meeting minutes at http://www.ietf.org/proceedings/08nov/minutes/ipfix.txt, there was only a single concern regarding the draft-ietf-ipfix-export-per-sctp-stream draft after the WGLC: 
- draft-ietf-ipfix-export-per-sctp-stream-00
============================================
Benoit:
WGLC finished.
Clarifications on the interaction with RFC5101.
Only one opern issues left: There is a normative reference to 
SCTP-RESET draft (draft-stewart-tsvwg-sctpstrrst-00.txt) from the 
Transport WG. This ID describes allows the addition of streams within 
an existing SCTP association as this functionality is required.

Dan (AD): 
This draft cannot be a normative reference as long as it is
not adopted by a the TSVWG. Suggestion: describe the mechanism in the 
normative part of the text and add an informative reference to the 
SCTP-RESET document. Once the document is included in the Transport WG 
charter it can be used as a normative reference. 

Juergen:
Authors of draft-stewart-tsvwg-sctpstrrst-00.txt should review the 
inserted text.
A new version of the draft has been posted, which addresses this issue. Obviously the authors from draft-stewart-tsvwg-sctpstrrst-00.txt were involved in the process.
This draft can now move to the next step towards RFC...

Regards, Benoit.

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

--------------090006080702050407050400-- From Quittek@nw.neclab.eu Mon Apr 27 01:44:56 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 F1EDA3A6F5D for ; Mon, 27 Apr 2009 01:44:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pEAyIz1CbNVe for ; Mon, 27 Apr 2009 01:44:56 -0700 (PDT) Received: from smtp0.neclab.eu (smtp0.neclab.eu [195.37.70.41]) by core3.amsl.com (Postfix) with ESMTP id C56D73A6F51 for ; Mon, 27 Apr 2009 01:44:55 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp0.neclab.eu (Postfix) with ESMTP id 349C22C0008EB; Mon, 27 Apr 2009 10:46:16 +0200 (CEST) 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 Wc0ckZbGVhvF; Mon, 27 Apr 2009 10:46:16 +0200 (CEST) Received: from VENUS.office (mx2.office [192.168.24.15]) by smtp0.neclab.eu (Postfix) with ESMTP id EFAC22C000305; Mon, 27 Apr 2009 10:46:00 +0200 (CEST) Received: from 10.1.2.178 ([10.1.2.178]) by VENUS.office ([192.168.24.102]) with Microsoft Exchange Server HTTP-DAV ; Mon, 27 Apr 2009 08:46:00 +0000 MIME-Version: 1.0 Content-class: urn:content-classes:message Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="B_3323673958_17647250" X-MimeOLE: Produced By Microsoft Exchange V6.5 Date: Mon, 27 Apr 2009 10:45:57 +0200 Message-ID: In-Reply-To: <49F56456.3000506@cisco.com> X-MS-Has-Attach: yes X-MS-TNEF-Correlator: Thread-Topic: [IPFIX] draft-ietf-ipfix-export-per-sctp-stream version 1 Thread-Index: AcnHFJUCfRbFCR2KXE6EGbrwNNACgg== From: "Juergen Quittek" To: "Benoit Claise" , Cc: IETF IPFIX Working Group Subject: Re: [IPFIX] draft-ietf-ipfix-export-per-sctp-stream version 1 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, 27 Apr 2009 08:44:57 -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_3323673958_17647250 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Dear Benoit, Sorry, this is my fault. Also the session minutes are late. I have time scheduled for these issues this week. Juergen On 27.04.09 09:52 "Benoit Claise" wrote: > Dear IPFIX-chairs, > > Can we please progress this draft: this I-D was not yet submitted by the > WG to the IESG. > This draft has been untouched for 3 months, as there is nothing more to > be done on the authors side. > > Regards, Benoit. >> Dear all, >> >>> From the last IPFIX meeting minutes at >> http://www.ietf.org/proceedings/08nov/minutes/ipfix.txt, there was >> only a single concern regarding the >> draft-ietf-ipfix-export-per-sctp-stream draft after the WGLC: >> >> - draft-ietf-ipfix-export-per-sctp-stream-00 >> ============================================ >> Benoit: >> WGLC finished. >> Clarifications on the interaction with RFC5101. >> Only one opern issues left: There is a normative reference to >> SCTP-RESET draft (draft-stewart-tsvwg-sctpstrrst-00.txt) from the >> Transport WG. This ID describes allows the addition of streams within >> an existing SCTP association as this functionality is required. >> >> Dan (AD): >> This draft cannot be a normative reference as long as it is >> not adopted by a the TSVWG. Suggestion: describe the mechanism in the >> normative part of the text and add an informative reference to the >> SCTP-RESET document. Once the document is included in the Transport WG >> charter it can be used as a normative reference. >> >> Juergen: >> Authors of draft-stewart-tsvwg-sctpstrrst-00.txt should review the >> inserted text. >> >> >> A new version of the draft has been posted, which addresses this >> issue. Obviously the authors from >> draft-stewart-tsvwg-sctpstrrst-00.txt were involved in the process. >> This draft can now move to the next step towards RFC... >> >> Regards, Benoit. >> ------------------------------------------------------------------------ >> >> _______________________________________________ >> IPFIX mailing list >> IPFIX@ietf.org >> https://www.ietf.org/mailman/listinfo/ipfix >> > --B_3323673958_17647250 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 YWIuZXUCBA0uKwcwCQYFKw4DAhoFAKBdMCMGCSqGSIb3DQEJBDEWBBR/gmENq2ySIzq9djRc E4qXzdqmiDAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0wOTA0 MjcwODQ1NThaMA0GCSqGSIb3DQEBAQUABIIBABtR/clSpXb+88fdOWd5wBCHsexDvliKmIs9 oDToLr/oK0ugCoyY4W1bim1bGrhA9CEkWaD1lRztV8s16CmN6rst6nbJnsW1g0wjkuF55H0n 2NRuA87vLijEImi4MyWBMQLB3iFGQm0RNmdTVQTYX6Qzdf52glD9IrFrO1YYCMEP9RYK96W/ +EBvt3cUBpFzEzODil19LwSUC3m9Cvt1ve1G6zJmHQYlN46noFvUFOaYvvlW4mFtgLO0izF/ GmflS45AsoQ0fxL4hgk+UhGahbw3av8oyagSj7sr1vUzYQf/q7AeL16/MNCw40Kw5G78qRGN xqaAtMCnl4eew5JzQGI= --B_3323673958_17647250-- From root@core3.amsl.com Thu Apr 30 03: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 6385A3A71DC; Thu, 30 Apr 2009 03:45:01 -0700 (PDT) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20090430104501.6385A3A71DC@core3.amsl.com> Date: Thu, 30 Apr 2009 03:45:01 -0700 (PDT) Cc: ipfix@ietf.org Subject: [IPFIX] I-D Action:draft-ietf-ipfix-mediators-problem-statement-03.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, 30 Apr 2009 10: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-03.txt Pages : 32 Date : 2009-04-30 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. IPFIX Mediation covers two classes of mediation: context mediation for traffic data and transport mediation for transport protocols. This document describes the IPFIX Mediation applicability examples, along with some problems that network administrators have been facing. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ipfix-mediators-problem-statement-03.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-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2009-04-30033220.I-D@ietf.org> --NextPart-- From akoba@nttv6.net Thu Apr 30 04:46:14 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 6FDBB3A6AF4 for ; Thu, 30 Apr 2009 04:46:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.201 X-Spam-Level: X-Spam-Status: No, score=-1.201 tagged_above=-999 required=5 tests=[AWL=1.399, 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 unwyxOTEveVk for ; Thu, 30 Apr 2009 04:46:13 -0700 (PDT) Received: from mail.nttv6.net (mail.nttv6.net [IPv6:2001:fa8::25]) by core3.amsl.com (Postfix) with ESMTP id CF99928C312 for ; Thu, 30 Apr 2009 04:45:43 -0700 (PDT) Received: from [192.47.163.152] ([IPv6:2001:fa8:1000:0:d497:ad17:b433:6f12]) by mail.nttv6.net (8.14.3/8.14.3) with ESMTP id n3UBl1mE081620 for ; Thu, 30 Apr 2009 20:47:05 +0900 (JST) (envelope-from akoba@nttv6.net) Date: Thu, 30 Apr 2009 20:45:59 +0900 From: Atsushi Kobayashi To: ipfix@ietf.org In-Reply-To: <20090430104501.6385A3A71DC@core3.amsl.com> References: <20090430104501.6385A3A71DC@core3.amsl.com> Message-Id: <20090430194648.87E2.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.0.1 (mail.nttv6.net [IPv6:2001:fa8::25]); Thu, 30 Apr 2009 20:47:05 +0900 (JST) Subject: Re: [IPFIX] I-D Action:draft-ietf-ipfix-mediators-problem-statement-03.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, 30 Apr 2009 11:46:14 -0000 Hi all, We finished up new version -03 mediation problem statement draft. Although it is later than expected in SF meeting, we authors have sufficiently discussed its wording, terminologies and technical issues. All of issues are already solved, then it is ready for WG last call. Improvements are following: - Overall wording - Terminology IPFIX concentrator have modification, correlation function for Data Record them other than aggregation. - In section 5, each implementation analysis describes more specific mediation type(Concentrator, Dstributor, Proxy and Masquerading Proxy). - In subsection 5.2, as an availability of hierarchical collecting infrastructure, the variety of treatment on data record was added. - In subsection 5.3, correlation function is divided by 3 types. - In subsection 5.7, data retension subsection was improved as general description. - Subsection 6.6 "Consideration for Network Topology" is added. - Subsection 6.7 "Exporting the Function Item" is added. - Subsection 6.8 "Consideration for Aggregation" is added. Best Regards, Atsushi KOBAYASHI On Thu, 30 Apr 2009 03:45:01 -0700 (PDT) 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-03.txt > Pages : 32 > Date : 2009-04-30 > > 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. IPFIX Mediation covers two classes of mediation: > context mediation for traffic data and transport mediation for > transport protocols. This document describes the IPFIX Mediation > applicability examples, along with some problems that network > administrators have been facing. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-ipfix-mediators-problem-statement-03.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