From cfinss@dial.pipex.com Sun Aug 2 03:19: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 F1E5B3A690C; Sun, 2 Aug 2009 03:19:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.451 X-Spam-Level: X-Spam-Status: No, score=-1.451 tagged_above=-999 required=5 tests=[AWL=-0.941, BAYES_05=-1.11, J_CHICKENPOX_35=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lxn2lNfMndAD; Sun, 2 Aug 2009 03:19:34 -0700 (PDT) Received: from mk-outboundfilter-2.mail.uk.tiscali.com (mk-outboundfilter-2.mail.uk.tiscali.com [212.74.114.38]) by core3.amsl.com (Postfix) with ESMTP id A0B693A68B3; Sun, 2 Aug 2009 03:19:33 -0700 (PDT) X-Trace: 238410600/mk-outboundfilter-2.mail.uk.tiscali.com/PIPEX/$PIPEX-ACCEPTED/pipex-customers/62.188.105.192/None/cfinss@dial.pipex.com X-SBRS: None X-RemoteIP: 62.188.105.192 X-IP-MAIL-FROM: cfinss@dial.pipex.com X-SMTP-AUTH: X-MUA: Microsoft Outlook Express 6.00.2800.1106Produced By Microsoft MimeOLE V6.00.2800.1106 X-IP-BHB: Once X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ArcEAPMEdUo+vGnA/2dsb2JhbACDLTyMZ8ByCYQPBQ X-IronPort-AV: E=Sophos;i="4.43,308,1246834800"; d="scan'208";a="238410600" X-IP-Direction: IN Received: from 1cust192.tnt2.lnd9.gbr.da.uu.net (HELO allison) ([62.188.105.192]) by smtp.pipex.tiscali.co.uk with SMTP; 02 Aug 2009 11:19:33 +0100 Message-ID: <000201ca1352$42b53ba0$0601a8c0@allison> From: "tom.petch" To: "Michael Tuexen" References: <4A6EB9BB.9040002@net.in.tum.de> <000401ca111a$3bb01da0$0601a8c0@allison> Date: Sun, 2 Aug 2009 11:11:03 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Mailman-Approved-At: Sun, 02 Aug 2009 09:35:56 -0700 Cc: Robin Seggelmann , ipfix@ietf.org, Daniel Mentz , syslog , tls@ietf.org Subject: Re: [IPFIX] [Syslog] Missing dead peer detection in DTLS X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: "tom.petch" List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 02 Aug 2009 10:19:35 -0000 Reply inline, twice Tom Petch ----- Original Message ----- From: "Michael Tuexen" To: "tom.petch" Sent: Thursday, July 30, 2009 5:24 PM a question in-line. Michael On Jul 30, 2009, at 11:44 AM, tom.petch wrote: > Gerhard > > Thank you for pointing this out; it had escaped me. > > What I had thought though was that the lack of flow control with > DTLS over UDP > is a problem, and that the lack of this with syslog over UDP led the > syslog RFC > [RFC5424] to make syslog over TLS the RECOMMENDED transport, not, as > might be > expected, syslog over UDP. So I think it is actually congestion control what you are looking for, which is provided by TCP when using SYSLOG/TLS/TCP/IP, right? For myself, no, I was not looking for or caring about congestion control, rather security. But when the syslog I-D got to the IESG, they did care about congestion, and so the syslog I-D was modified to make syslog over TLS the RECOMMENDED transport, not because it might or might not improve security but because it offered congestion control, which UDP by itself does not. > > This in turn led me to expect that syslog over DTLS over UDP would > not be > acceptable to the IESG, rather that syslog over DTLS over SCTP would > become the > RECOMMENDED transport. This would mean, that * SYSLOG/TLS/TCP/IP * SYSLOG/DTLS/SCTP/IP * SYSLOG/DTLS/DCCP/IP are in principle acceptable, whereas * SYSLOG/DTLS/UDP/IP is not. You would (from the congestion control perspective) have the same classification when taking out the DTLS or TLS layer, right? I am unclear about your second sentence, but the first one, yes, I would expect the first three to be acceptable to the IESG (which is rather important if you want an I-D to become an RFC) and the last one not to be. TLS (by using TCP), SCTP, DCCP have acceptable congestion control, DTLS and UDP do not. Tom Petch > So; several thoughts. > > This is an update to the extensions RFC, RFC4366, which itself is > being updated > by the TLS working group (hence my addition of them to the list) and > I would > much rather have one extensions RFC rather than several. This is a > good concept > and fills a need; perhaps the TLS working group would take this on. > > Flow control remains an issue which I do not think that this extension > addresses. > > Is this a security exposure? or just, like syslog over UDP, an > inconvenient > truth? > > The petch-gerhards draft allows the recipient of the unidirectional > flow to > initiate the DTLS 'connection', and so enables it to re-establish > the connection > when anything goes wrong. This would seem an alternative to consider. > > Tom Petch From web-usrn@ISI.EDU Tue Aug 4 01:51: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 DFFF23A6F16 for ; Tue, 4 Aug 2009 01:51:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -16.707 X-Spam-Level: X-Spam-Status: No, score=-16.707 tagged_above=-999 required=5 tests=[AWL=0.892, BAYES_00=-2.599, USER_IN_DEF_WHITELIST=-15] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id i2aMIZ0eD1Ei for ; Tue, 4 Aug 2009 01:51:56 -0700 (PDT) Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) by core3.amsl.com (Postfix) with ESMTP id ED8A63A696C for ; Tue, 4 Aug 2009 01:51:55 -0700 (PDT) Received: from boreas.isi.edu (localhost [127.0.0.1]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id n748pIdk001950 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 4 Aug 2009 01:51:18 -0700 (PDT) Received: (from web-usrn@localhost) by boreas.isi.edu (8.13.8/8.13.8/Submit) id n748pF8G001948; Tue, 4 Aug 2009 01:51:15 -0700 (PDT) Date: Tue, 4 Aug 2009 01:51:15 -0700 (PDT) Message-Id: <200908040851.n748pF8G001948@boreas.isi.edu> To: elisa.boschi@hitachi-eu.com, brian.trammell@hitachi-eu.com, lutz.mark@ifam.fraunhofer.de, tanja.zseby@fokus.fraunhofer.de, dromasca@avaya.com, rbonica@juniper.net, n.brownlee@auckland.ac.nz, quittek@netlab.nec.de From: RFC Errata System X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: web-usrn@boreas.isi.edu Cc: rfc-editor@rfc-editor.org, ipfix@ietf.org Subject: [IPFIX] [Editorial Errata Reported] RFC5610 (1822) 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, 04 Aug 2009 08:51:57 -0000 The following errata report has been submitted for RFC5610, "Exporting Type Information for IP Flow Information Export (IPFIX) Information Elements". -------------------------------------- You may review the report below and at: http://www.rfc-editor.org/errata_search.php?rfc=5610&eid=1822 -------------------------------------- Type: Editorial Reported by: Brian Trammell Section: 3.7 Original Text ------------- These types are registered in the IANA IPFIX Information Element Units subregistry; new types may be added on a First Come First Served [RFC5226] basis. Corrected Text -------------- These units are registered in the IANA IPFIX Information Element Units subregistry; new units may be added on an Expert Review [RFC5226] basis. Notes ----- The text in the IANA Considerations (section 5) and in the IANA registry created therefrom (http://www.iana.org/assignments/ipfix/ipfix.xhtml#informationElementUnits) specifies Expert Review, which was the intent of the WG. The text in section 3.7 is an editorial hold-over from an older version of the document. Instructions: ------------- This errata is currently posted as "Reported". If necessary, please use "Reply All" to discuss whether it should be verified or rejected. When a decision is reached, the verifying party (IESG) can log in to change the status and edit the report, if necessary. -------------------------------------- RFC5610 (draft-ietf-ipfix-exporting-type-05) -------------------------------------- Title : Exporting Type Information for IP Flow Information Export (IPFIX) Information Elements Publication Date : July 2009 Author(s) : E. Boschi, B. Trammell, L. Mark, T. Zseby Category : PROPOSED STANDARD Source : IP Flow Information Export Area : Operations and Management Stream : IETF Verifying Party : IESG From tuexen@fh-muenster.de Wed Aug 5 05:35: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 EFEFB3A6B84; Wed, 5 Aug 2009 05:35:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.169 X-Spam-Level: X-Spam-Status: No, score=0.169 tagged_above=-999 required=5 tests=[AWL=-2.169, BAYES_00=-2.599, HOST_EQ_DIP_TDIAL=2.144, HOST_MISMATCH_NET=0.311, J_CHICKENPOX_35=0.6, RCVD_IN_PBL=0.905, RCVD_IN_SORBS_DUL=0.877, RDNS_DYNAMIC=0.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 9gOAb9nhQ9-O; Wed, 5 Aug 2009 05:35:13 -0700 (PDT) Received: from mail-n.franken.de (drew.ipv6.franken.de [IPv6:2001:638:a02:a001:20e:cff:fe4a:feaa]) by core3.amsl.com (Postfix) with ESMTP id 9F7823A6B82; Wed, 5 Aug 2009 05:35:09 -0700 (PDT) Received: from [192.168.1.100] (p508FD425.dip.t-dialin.net [80.143.212.37]) by mail-n.franken.de (Postfix) with ESMTP id 4919A1C0B4619; Wed, 5 Aug 2009 14:35:09 +0200 (CEST) From: Michael Tuexen To: "tom.petch" In-Reply-To: <000201ca1352$42b53ba0$0601a8c0@allison> X-Priority: 3 References: <4A6EB9BB.9040002@net.in.tum.de> <000401ca111a$3bb01da0$0601a8c0@allison> <000201ca1352$42b53ba0$0601a8c0@allison> Message-Id: <2534D5E9-2595-427A-86FD-562890F0D74B@fh-muenster.de> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v935.3) Date: Wed, 5 Aug 2009 14:35:07 +0200 X-Mailer: Apple Mail (2.935.3) X-Mailman-Approved-At: Wed, 05 Aug 2009 06:11:42 -0700 Cc: Robin Seggelmann , ipfix@ietf.org, Daniel Mentz , syslog , tls@ietf.org Subject: Re: [IPFIX] [Syslog] Missing dead peer detection in DTLS 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, 05 Aug 2009 12:35:19 -0000 Hi Tom, understood. Thanks for the clarification. Best regards Michael On Aug 2, 2009, at 11:11 AM, tom.petch wrote: > Reply inline, twice > > Tom Petch > > ----- Original Message ----- > From: "Michael Tuexen" > To: "tom.petch" > Sent: Thursday, July 30, 2009 5:24 PM > > a question in-line. > > Michael > > On Jul 30, 2009, at 11:44 AM, tom.petch wrote: > >> Gerhard >> >> Thank you for pointing this out; it had escaped me. >> >> What I had thought though was that the lack of flow control with >> DTLS over UDP >> is a problem, and that the lack of this with syslog over UDP led the >> syslog RFC >> [RFC5424] to make syslog over TLS the RECOMMENDED transport, not, as >> might be >> expected, syslog over UDP. > > So I think it is actually congestion control what you are looking > for, which is provided by TCP when using SYSLOG/TLS/TCP/IP, right? > > > For myself, no, I was not looking for or caring about congestion > control, rather > security. > > But when the syslog I-D got to the IESG, they did care about > congestion, and so > the syslog I-D was modified to make syslog over TLS the RECOMMENDED > transport, > not because it might or might not improve security but because it > offered congestion control, which UDP by itself does not. > >> >> This in turn led me to expect that syslog over DTLS over UDP would >> not be >> acceptable to the IESG, rather that syslog over DTLS over SCTP would >> become the >> RECOMMENDED transport. > > This would mean, that > * SYSLOG/TLS/TCP/IP > * SYSLOG/DTLS/SCTP/IP > * SYSLOG/DTLS/DCCP/IP > are in principle acceptable, whereas > * SYSLOG/DTLS/UDP/IP > is not. > You would (from the congestion control perspective) have the same > classification when taking out the DTLS or TLS layer, right? > > > I am unclear about your second sentence, but the first one, yes, I > would expect > the first three to be acceptable to the IESG (which is rather > important if you > want an I-D to become an RFC) and the last one not to be. TLS (by > using TCP), > SCTP, DCCP have acceptable congestion control, DTLS and UDP do not. > > Tom Petch > >> So; several thoughts. >> >> This is an update to the extensions RFC, RFC4366, which itself is >> being updated >> by the TLS working group (hence my addition of them to the list) and >> I would >> much rather have one extensions RFC rather than several. This is a >> good concept >> and fills a need; perhaps the TLS working group would take this on. >> >> Flow control remains an issue which I do not think that this >> extension >> addresses. >> >> Is this a security exposure? or just, like syslog over UDP, an >> inconvenient >> truth? >> >> The petch-gerhards draft allows the recipient of the unidirectional >> flow to >> initiate the DTLS 'connection', and so enables it to re-establish >> the connection >> when anything goes wrong. This would seem an alternative to >> consider. >> >> Tom Petch > > > From root@core3.amsl.com Thu Aug 6 10:15: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 B129B3A6E23; Thu, 6 Aug 2009 10:15: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: <20090806171501.B129B3A6E23@core3.amsl.com> Date: Thu, 6 Aug 2009 10:15:01 -0700 (PDT) Cc: ipfix@ietf.org Subject: [IPFIX] I-D Action:draft-ietf-ipfix-file-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, 06 Aug 2009 17:15: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 : Specification of the IPFIX File Format Author(s) : B. Trammell, et al. Filename : draft-ietf-ipfix-file-05.txt Pages : 66 Date : 2009-08-06 This document describes a file format for the storage of flow data based upon the IPFIX Protocol. It proposes a set of requirements for flat-file, binary flow data file formats, then specifies the IPFIX 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. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ipfix-file-05.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-file-05.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2009-08-06100320.I-D@ietf.org> --NextPart-- From bclaise@cisco.com Mon Aug 10 01:48: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 DB88D3A6DBC for ; Mon, 10 Aug 2009 01:48:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.558 X-Spam-Level: X-Spam-Status: No, score=-2.558 tagged_above=-999 required=5 tests=[AWL=0.041, 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 hqpFwNS+3Te4 for ; Mon, 10 Aug 2009 01:48:04 -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 F1A833A69D7 for ; Mon, 10 Aug 2009 01:48:03 -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 n7A8m6g2019962 for ; Mon, 10 Aug 2009 10:48:06 +0200 (CEST) Received: from [10.55.43.52] (ams-bclaise-8713.cisco.com [10.55.43.52]) by strange-brew.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id n7A8m5fK020689 for ; Mon, 10 Aug 2009 10:48:06 +0200 (CEST) Message-ID: <4A7FDEC5.4050301@cisco.com> Date: Mon, 10 Aug 2009 10:48:05 +0200 From: Benoit Claise User-Agent: Thunderbird 2.0.0.22 (Windows/20090605) MIME-Version: 1.0 To: "ipfix@ietf.org" Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [IPFIX] draft-claise-structured-data-in-ipfix-02 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, 10 Aug 2009 08:48:04 -0000 Dear all, A new version of the draft has been posted, with two important changes: 1. the subTemplateMultiList encoding is now consistent with Set Header specified in [RFC5101], as requested by Brian Trammell the example has been adapted. 2. a confusing mistake (Length encoding) in one of the subTemplateMultiList example (independent of the change 1.) Enjoy, Benoit. From Quittek@nw.neclab.eu Thu Aug 13 05:29:52 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 B1FAB3A6A63 for ; Thu, 13 Aug 2009 05:29:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.617 X-Spam-Level: X-Spam-Status: No, score=-2.617 tagged_above=-999 required=5 tests=[AWL=-0.018, 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 lYRExwrPHWmK for ; Thu, 13 Aug 2009 05:29:51 -0700 (PDT) Received: from smtp0.neclab.eu (smtp0.neclab.eu [195.37.70.41]) by core3.amsl.com (Postfix) with ESMTP id 5BB583A6877 for ; Thu, 13 Aug 2009 05:28:53 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp0.neclab.eu (Postfix) with ESMTP id EFE002C0004DE for ; Thu, 13 Aug 2009 09:40:41 +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 GDdV1997rIAv for ; Thu, 13 Aug 2009 09:40:41 +0200 (CEST) Received: from VENUS.office (mx1.office [192.168.24.3]) by smtp0.neclab.eu (Postfix) with ESMTP id A6BDF2C0004DB for ; Thu, 13 Aug 2009 09:40:36 +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 ; Thu, 13 Aug 2009 07:40:36 +0000 MIME-Version: 1.0 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-Type: multipart/signed; boundary="B_3333001238_4622206"; protocol="application/pkcs7-signature"; micalg=sha1 Content-class: urn:content-classes:message Date: Thu, 13 Aug 2009 09:40:38 +0200 Message-ID: X-MS-Has-Attach: yes X-MS-TNEF-Correlator: Thread-Topic: Call for consensus: changing Intended Status of draft-ietf-ipfix-export-per-sctp-stream from Informational to Standards Track Thread-Index: Acob6Vm3KSSzZtZ+u0Cg+9QVx+eqbA== From: "Juergen Quittek" To: "IETF IPFIX Working Group" Subject: [IPFIX] Call for consensus: changing Intended Status of draft-ietf-ipfix-export-per-sctp-stream from Informational to Standards Track 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, 13 Aug 2009 12:29:52 -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_3333001238_4622206 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Dear all, draft-ietf-ipfix-export-per-sctp-stream is currently under IESG review. Its Intended Status is 'Informational'. Since it uses normative language in some paragraphs, IESG members suggested changing the Intended Status to 'Standards Track'. In the IPFIX WG had consensus about 'Informational' for this draft, because it had a normative reference to a draft in the transport area for which it was unclear if it ever would become a normative RFC. This situation has changed. The draft has been accepted as WG document, see http://www.ietf.org/id/draft-ietf-tsvwg-sctp-strrst-00.txt of the TSVWG and is progressing. We can now use it as normative reference in a 'Standards Track' document. We still would have to wait until probably early 2010 until it gets published, but this seems to be a manageable period of time. Would anyone in the IPFIX WG see a problem with changing the Intended Status of draft-ietf-ipfix-export-per-sctp-stream from 'Informational' to 'Standards Track'? Thanks, Juergen --B_3333001238_4622206 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 YWIuZXUCBA0uKwcwCQYFKw4DAhoFAKBdMCMGCSqGSIb3DQEJBDEWBBT+BEPooQzKJUpWzaGw 1lwraj3odzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0wOTA4 MTMwNzQwMzhaMA0GCSqGSIb3DQEBAQUABIIBAB9gHntwjURjq84eYJMeO6K6VaBumQxjheQ1 neR8+XoL+eDIsEWN38osrRFgQsUALXGnILKU6uTXzk1BE9ka1deDGbkrinEiCqdr5n845FHO Oz5Rtc9KFbCpf4qzSUyKvOrji/X78u67mSNRYpUPNoxOjMQ9yiW/d0pJXtElvk3tiB1DoHjc 9mw6e+DKSs1eqZr3oQ+Ny1PhC25ANPxuDpXjD52BNideBht1M8YqcjgNJ1Bwm3e/ImkEmeiz 9+iRHNLHeqp+yqxRy7u27Nj/8ENnHBWO8i9QrAUEQWQZQ+4hy2pCUndadZLfqRes27/EikY5 X3vKK0z8MgjDbUMnQNU= --B_3333001238_4622206-- From n.brownlee@auckland.ac.nz Tue Aug 18 15:49:45 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 70A083A6828 for ; Tue, 18 Aug 2009 15:49:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.653 X-Spam-Level: X-Spam-Status: No, score=-4.653 tagged_above=-999 required=5 tests=[AWL=-1.946, BAYES_50=0.001, MISSING_HEADERS=1.292, 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 dmo2ozpVazd9 for ; Tue, 18 Aug 2009 15:49:44 -0700 (PDT) Received: from mailhost.auckland.ac.nz (larry.its.auckland.ac.nz [130.216.12.34]) by core3.amsl.com (Postfix) with ESMTP id 71F7E3A69AE for ; Tue, 18 Aug 2009 15:49:42 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by mailhost.auckland.ac.nz (Postfix) with ESMTP id 8EB4D414067 for ; Wed, 19 Aug 2009 10:49:37 +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 (larry.its.auckland.ac.nz [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bBUidrZ-J4DA for ; Wed, 19 Aug 2009 10:49:37 +1200 (NZST) Received: from nevil-laptop.sfac.auckland.ac.nz (nevil-laptop.sfac.auckland.ac.nz [130.216.38.130]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailhost.auckland.ac.nz (Postfix) with ESMTP id 63672414075 for ; Wed, 19 Aug 2009 10:49:35 +1200 (NZST) Message-ID: <4A8B2FFE.1050303@auckland.ac.nz> Date: Wed, 19 Aug 2009 10:49:34 +1200 From: Nevil Brownlee User-Agent: Thunderbird 2.0.0.12 (Macintosh/20080213) MIME-Version: 1.0 CC: IETF IPFIX Working Group References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [IPFIX] Call for consensus: changing Intended Status of draft-ietf-ipfix-export-per-sctp-stream from Informational to Standards Track 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, 18 Aug 2009 22:49:45 -0000 Hi all: I think that Gerhard summed up the discussion on this rather nicely. Further, it seems to me that the per-stream draft spells out a particular way of using the transport layer (SCTP in this case). If we want that to depend on having the SCTP Stream Reset extension (and I believe that we do), that's a good reason for making it a standards-track document. In short, I support this change of status for the draft. Cheers, Nevil Juergen Quittek wrote: > Dear all, > > draft-ietf-ipfix-export-per-sctp-stream is currently under IESG review. > Its Intended Status is 'Informational'. > > Since it uses normative language in some paragraphs, IESG members > suggested changing the Intended Status to 'Standards Track'. > > In the IPFIX WG had consensus about 'Informational' for this draft, > because it had a normative reference to a draft in the transport area > for which it was unclear if it ever would become a normative RFC. > > This situation has changed. The draft has been accepted as WG document, > see http://www.ietf.org/id/draft-ietf-tsvwg-sctp-strrst-00.txt of the > TSVWG and is progressing. We can now use it as normative reference in a > 'Standards Track' document. We still would have to wait until probably > early 2010 until it gets published, but this seems to be a manageable > period of time. > > Would anyone in the IPFIX WG see a problem with changing the Intended > Status of draft-ietf-ipfix-export-per-sctp-stream from 'Informational' > to 'Standards Track'? > > Thanks, > > Juergen -- --------------------------------------------------------------------- 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 n.brownlee@auckland.ac.nz Tue Aug 18 15:55: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 524423A69AE for ; Tue, 18 Aug 2009 15:55:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.881 X-Spam-Level: X-Spam-Status: No, score=-4.881 tagged_above=-999 required=5 tests=[AWL=0.229, BAYES_05=-1.11, 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 iE-eriKPje+8 for ; Tue, 18 Aug 2009 15:55:01 -0700 (PDT) Received: from mailhost.auckland.ac.nz (moe.its.auckland.ac.nz [130.216.12.35]) by core3.amsl.com (Postfix) with ESMTP id 6A1953A67B4 for ; Tue, 18 Aug 2009 15:55:01 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by mailhost.auckland.ac.nz (Postfix) with ESMTP id C218E1713FE for ; Wed, 19 Aug 2009 10:55:05 +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 (moe.its.auckland.ac.nz [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id q1pfnzn6L51Q for ; Wed, 19 Aug 2009 10:55:05 +1200 (NZST) Received: from nevil-laptop.sfac.auckland.ac.nz (nevil-laptop.sfac.auckland.ac.nz [130.216.38.130]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailhost.auckland.ac.nz (Postfix) with ESMTP id 59411171406 for ; Wed, 19 Aug 2009 10:55:05 +1200 (NZST) Message-ID: <4A8B3148.4090803@auckland.ac.nz> Date: Wed, 19 Aug 2009 10:55:04 +1200 From: Nevil Brownlee User-Agent: Thunderbird 2.0.0.12 (Macintosh/20080213) MIME-Version: 1.0 To: IETF IPFIX Working Group References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [IPFIX] new work items for the IPFIX charter 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, 18 Aug 2009 22:55:02 -0000 Hi all: I think that all three of these should be accepted as new work items for IPFIX. Cheers, Nevil Juergen Quittek wrote: > Dear all, > > At our session on Monday there were three drafts presented > for which there was a consensus to accept them as working > group documents. Now we need confirmation on this list. > > The drafts are > > - Export of Structured Data in IPFIX > http://tools.ietf.org/html/draft-claise-structured-data-in-ipfix > - IP Flow Anonymisation Support > http://tools.ietf.org/html/draft-boschi-ipfix-anon > - Flow Selection Techniques > http://tools.ietf.org/html/draft-peluso-flowselection-tech > > If you see any problem with adding these three items to the > IPFIX agenda, please make your point on this list within the > next two weeks. > > Thanks, > > Juergen -- --------------------------------------------------------------------- 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 muenz@net.in.tum.de Wed Aug 19 01:40:09 2009 Return-Path: X-Original-To: ipfix@core3.amsl.com Delivered-To: ipfix@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BE3A628C0E7 for ; Wed, 19 Aug 2009 01:40:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.092 X-Spam-Level: X-Spam-Status: No, score=-2.092 tagged_above=-999 required=5 tests=[AWL=0.157, 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 0L9OpqFUSqQw for ; Wed, 19 Aug 2009 01:40:07 -0700 (PDT) Received: from mail-out1.informatik.tu-muenchen.de (mail-out1.informatik.tu-muenchen.de [131.159.0.8]) by core3.amsl.com (Postfix) with ESMTP id 814403A6CE0 for ; Wed, 19 Aug 2009 01:40:06 -0700 (PDT) Received: from phoenix.net.informatik.tu-muenchen.de (phoenix.net.in.tum.de [131.159.14.1]) by services.net.informatik.tu-muenchen.de (Postix Mailer @ mail) with ESMTP id CE8CB480F0; Wed, 19 Aug 2009 10:40:09 +0200 (CEST) Received: from [131.159.20.108] (repulse.net.in.tum.de [131.159.20.108]) by phoenix.net.informatik.tu-muenchen.de (Postfix) with ESMTP id BE9DA540F; Wed, 19 Aug 2009 10:40:09 +0200 (CEST) Message-ID: <4A8BBA6A.7020302@net.in.tum.de> Date: Wed, 19 Aug 2009 10:40:10 +0200 From: Gerhard Muenz User-Agent: Thunderbird 2.0.0.22 (Windows/20090605) MIME-Version: 1.0 To: Nevil Brownlee References: <4A8B2FFE.1050303@auckland.ac.nz> In-Reply-To: <4A8B2FFE.1050303@auckland.ac.nz> Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms050401020506060700040703" X-Virus-Scanned: ClamAV using ClamSMTP Cc: IETF IPFIX Working Group Subject: Re: [IPFIX] Call for consensus: changing Intended Status of draft-ietf-ipfix-export-per-sctp-stream from Informational to Standards Track 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, 19 Aug 2009 08:40:09 -0000 This is a cryptographically signed message in MIME format. --------------ms050401020506060700040703 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Dear all, For completeness, here is the excerpt of the e-mail Nevil seems to be referring to. I had sent this e-mail to our WG chairs and Ron Romascanu. "Informational" was decided at IETF 69: http://tools.ietf.org/wg/ipfix/minutes?item=3Dminutes69.html (I remember this meeting very well because there were hot discussions about the SCTP stream issues.) The majority of the WG believed that per-sctp-stream should be Informational or Experimental: "There was support for this as a WG item, with the suggestion that it should become either an Informational of an Experimental RFC. If it becomes widely used, it could later become an option in a revised Protocol RFC." (I assume "of" =3D> "or") It is important to understand the context. The preliminary decision to adopt this draft as a WG item fell together with a very late but major change in the IPFIX protocol draft, which concerned the removal of any SCTP stream usage restrictions. Before, the IPFIX protocol said to send Templates on stream 0 only, which was non-sense. This late change of the IPFIX protocol specification seemed to cover the "normative" content of per-sctp-stream. So, per-sctp-stream appeared to be just a specific utilization of the IPFIX protocol, which would at no point touch the later RFC5101. Note that at that point, dataRecordsReliability did not exist. The authors thought that no additional Information Elements and Reports where necessary to inform the Collector. Later, we recognized that we could not do without a kind of signalization between Exporter and Collector. The proposed solution is the Data Record Reliability Option Template using the dataRecordsReliability Information Element. Looking at the document now, I also think that Standard Track is more appropriate because it is not just adding new Information Elements like RFC5473. It also specifies specific behavior regarding the SCTP stream usage. Regards, Gerhard Nevil Brownlee wrote: > Hi all: >=20 > >=20 > I think that Gerhard summed up the discussion on this rather nicely. >=20 > Further, it seems to me that the per-stream draft spells out a > particular way of using the transport layer (SCTP in this case). > If we want that to depend on having the SCTP Stream Reset extension > (and I believe that we do), that's a good reason for making it a > standards-track document. >=20 > In short, I support this change of status for the draft. >=20 > >=20 > Cheers, Nevil >=20 >=20 > Juergen Quittek wrote: >> Dear all, >> >> draft-ietf-ipfix-export-per-sctp-stream is currently under IESG review= =2E >> Its Intended Status is 'Informational'. >> =20 >> Since it uses normative language in some paragraphs, IESG members >> suggested changing the Intended Status to 'Standards Track'. >> >> In the IPFIX WG had consensus about 'Informational' for this draft, >> because it had a normative reference to a draft in the transport area >> for which it was unclear if it ever would become a normative RFC. >> >> This situation has changed. The draft has been accepted as WG document= , >> see http://www.ietf.org/id/draft-ietf-tsvwg-sctp-strrst-00.txt of the >> TSVWG and is progressing. We can now use it as normative reference in = a >> 'Standards Track' document. We still would have to wait until probably= >> early 2010 until it gets published, but this seems to be a manageable >> period of time. >> Would anyone in the IPFIX WG see a problem with changing the Intended >> Status of draft-ietf-ipfix-export-per-sctp-stream from 'Informational'= >> to 'Standards Track'? >> >> Thanks, >> >> Juergen >=20 --=20 Dipl.-Ing. Gerhard M=FCnz Chair for Network Architectures and Services (I8) Technische Universit=E4t M=FCnchen - Department of Informatics Boltzmannstr. 3, 85748 Garching bei M=FCnchen, Germany Phone: +49 89 289-18008 Fax: +49 89 289-18033 E-mail: muenz@net.in.tum.de WWW: http://www.net.in.tum.de/~muenz --------------ms050401020506060700040703 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 SIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMDkwODE5MDg0MDEwWjAjBgkqhkiG9w0BCQQxFgQU YlI4hLE9YkOVKkfVZkRrbvW54rIwUgYJKoZIhvcNAQkPMUUwQzAKBggqhkiG9w0DBzAOBggq hkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwICASgwgYUG CSsGAQQBgjcQBDF4MHYwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0 aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1 aW5nIENBAhAqxerdN2XVRkUZsuk5IKdPMIGHBgsqhkiG9w0BCRACCzF4oHYwYjELMAkGA1UE BhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMT I1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBAhAqxerdN2XVRkUZsuk5IKdP MA0GCSqGSIb3DQEBAQUABIIBAJKvF0BChvQ1+e9IB8Ygx8rdLEmPWJUAs49uB78/4Z0ufgE4 d3Q3leYdg8YBjxT4gAL388OObizo1WVo65KEsFZSyF78Azh7VwI7ZoSKFvhwlpb0fsWrAgxw tvkMbo+RSDMAibJfAEWuHpbF00iNxCL4pxKAPRr/DLt5IBliRXyEqmU070xfzDc6Z2UOOn8z nQUT+vyxq6h+nI/efRfP8geQO8XVxE10Dx9zcRW++2W2X1/ot4LZbduMA7Suv/uobwK93IHV 1lbszKf6FkN2czousLW5n7Y10cy2vqwYcueEWpdfZyA03z3cNVyj+qpPFV/mphYXwcjThSCH VK2/u58AAAAAAAA= --------------ms050401020506060700040703-- From trammell@tik.ee.ethz.ch Wed Aug 19 04:55:10 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 98B333A6BCB for ; Wed, 19 Aug 2009 04:55:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GcldCIOJSYqt for ; Wed, 19 Aug 2009 04:55:09 -0700 (PDT) Received: from smtp.ee.ethz.ch (smtp.ee.ethz.ch [129.132.2.219]) by core3.amsl.com (Postfix) with ESMTP id 2ACD53A6AD0 for ; Wed, 19 Aug 2009 04:55:08 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by smtp.ee.ethz.ch (Postfix) with ESMTP id 6AECAD939B; Wed, 19 Aug 2009 13:55:12 +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 q75qJ+vuNImZ; Wed, 19 Aug 2009 13:55:12 +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 2314BD9396; Wed, 19 Aug 2009 13:55:12 +0200 (MEST) Message-Id: From: Brian Trammell To: Nevil Brownlee In-Reply-To: <4A8B2FFE.1050303@auckland.ac.nz> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Wed, 19 Aug 2009 13:55:11 +0200 References: <4A8B2FFE.1050303@auckland.ac.nz> X-Mailer: Apple Mail (2.936) Cc: IETF IPFIX Working Group Subject: Re: [IPFIX] Call for consensus: changing Intended Status of draft-ietf-ipfix-export-per-sctp-stream from Informational to Standards Track 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, 19 Aug 2009 11:55:10 -0000 Greetings, Nevil, all, As the draft stands right now, I'm concerned that it may not be appropriate for the standards track. The biggest problem is one of interoperability. As strictly specified, SCTP per-stream (SPS)-compliant CPs will not properly interoperate with 5101-compliant EPs: an EP that sends template withdrawals, or data sets on unexpected streams will cause errors at the CP side. Or rather, _may_ cause errors at the CP side: 4.5 states what to do for TW messages, but it is not clear what the CP should do in case of an unanticipated data set. More troublingly, SPS-compliant EPs that use the Template Withdrawal mechanism specified in Section 4.4 will _probably_ interoperate with 5101-compliant CPs in most cases, but may fail in a very difficult to detect way. Specifically, since 5101 section 8 paragraph 10 specifies that "[t]he Template ID from a withdrawn Template MUST NOT be reused until sufficient time has elapsed to allow for the Collecting Process to receive and process the Template Withdrawal Message.", 5101- compliant CPs are _not_ obliged to immediately process template withdrawals in order on the same stream. Indeed, section 4.4 paragraph 5 _directly_ contradicts this MUST NOT, as "[t]he Template ID from a withdrawn Template MAY be reused on the same stream immediately after the Template Withdrawal Message is sent". Problems here: 1. The EP cannot know at runtime whether the CP is SPS- compliant or not, and so cannot know whether or not immediate reuse is safe; 2. assuming immediate reuse is safe when it isn't may cause data to be unframed improperly, in a way not detectable until later analysis; and 3. it is unclear whether we can say this _at all_ in a Standards Track draft without updating 5101 to strike the MUST NOT. This is a terrible idea, as that MUST NOT is there for a reason: namely, to make Template Withdrawals work at all in the general case. It is unclear how to address the fast Template reuse issue, but it must be addressed, even without an change of status. In any case, since SPS and 5101 are not completely and in all situations interoperable, the draft needs a very clear specification of the handshake between the EP and CP, by which they agree they are operating by the SPS rules. The minimum requirements of this handshake would seem to be: 1. A Collecting Process maintains a SPS mode state per Transport Session. 2. All Transport Sessions begin with SPS mode off. 3. When a Collecting Process determines that a Transport Session is operating according to SPS, it sets the SPS mode to on for that session, and begins operating according to SPS rules (e.g., smaller buffers, immediate template withdrawal). 4. Any receipt of a SPS-illegal template withdrawal or data set (i.e., on the wrong stream) causes the Collecting Process to log an error and set the SPS mode to cancelled. Cancelled SPS mode cannot be reset without a Transport Session reset. 5. An SPS-compatible Exporting Process MUST provide a way to disable SPS mode on a per-Collecting Process basis. Otherwise, an administrator has no way to make that Exporting Process work with 5101 Collecting Processes that cannot handle fast Template reuse. Complicated? Yes, very. But I can't see another way to guarantee SPS interoperability with 5101. A second problem is one of applicability. Presently, the draft is not particularly clear that it is recommended for use only when ALL of the following conditions hold: 1. There is a definite mapping between applications and templates (multi-template export for data structure variability and export efficiency within the same logical application, with sharing of common templates across logical applications, for example, breaks the assumptions in perstream). 2. There are few enough applications to fit in the number of streams supported at each endpoint. 3. Messages are exported using SCTP partial reliability. 4. The underlying PR-SCTP implementation supports SCTP-RESET. 5. There is a requirement for per-application record loss accounting. Therefore, as a new implementor coming upon IPFIX for the first time, seeing this as a Standards Track draft, I might think that I _must_ implement it in order to be compliant, even if it has no benefits for my application (or actively complicates it, as with the example 1. above). The draft needs a very clear, _exclusive_ statement of the situations in which it applies, and guidance that it should not be applied where not applicable. (I'm also not entirely convinced that dataRecordsReliability should be used as an indication that SPS is in effect, as it appears to have some applicability outside SPS. It's also unclear what an EP should do if it wants to reserve the right to send a Template unreliably in the future, or what a CP should to if it detects inconsistency in the use of the IE. But these are side issues.) Once these issues are addressed, then perhaps it will be appropriate to discuss an intended status change. Best regards, Brian On Aug 19, 2009, at 12:49 AM, Nevil Brownlee wrote: > Hi all: > > > > I think that Gerhard summed up the discussion on this rather nicely. > > Further, it seems to me that the per-stream draft spells out a > particular way of using the transport layer (SCTP in this case). > If we want that to depend on having the SCTP Stream Reset extension > (and I believe that we do), that's a good reason for making it a > standards-track document. > > In short, I support this change of status for the draft. > > > > Cheers, Nevil > > > Juergen Quittek wrote: >> Dear all, >> draft-ietf-ipfix-export-per-sctp-stream is currently under IESG >> review. >> Its Intended Status is 'Informational'. >> Since it uses normative language in some paragraphs, IESG members >> suggested changing the Intended Status to 'Standards Track'. >> In the IPFIX WG had consensus about 'Informational' for this draft, >> because it had a normative reference to a draft in the transport area >> for which it was unclear if it ever would become a normative RFC. >> This situation has changed. The draft has been accepted as WG >> document, >> see http://www.ietf.org/id/draft-ietf-tsvwg-sctp-strrst-00.txt of the >> TSVWG and is progressing. We can now use it as normative reference >> in a >> 'Standards Track' document. We still would have to wait until >> probably >> early 2010 until it gets published, but this seems to be a manageable >> period of time. Would anyone in the IPFIX WG see a problem with >> changing the Intended >> Status of draft-ietf-ipfix-export-per-sctp-stream from >> 'Informational' >> to 'Standards Track'? >> Thanks, >> Juergen > > -- > --------------------------------------------------------------------- > Nevil Brownlee Computer Science Department | ITS > Phone: +64 9 373 7599 x88941 The University of Auckland > FAX: +64 9 373 7453 Private Bag 92019, Auckland 1142, New Zealand > _______________________________________________ > IPFIX mailing list > IPFIX@ietf.org > https://www.ietf.org/mailman/listinfo/ipfix From muenz@net.in.tum.de Wed Aug 19 05:41:27 2009 Return-Path: X-Original-To: ipfix@core3.amsl.com Delivered-To: ipfix@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1E8A93A6D66 for ; Wed, 19 Aug 2009 05:41:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.103 X-Spam-Level: X-Spam-Status: No, score=-2.103 tagged_above=-999 required=5 tests=[AWL=0.146, 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 jkpLf7i0oeBi for ; Wed, 19 Aug 2009 05:41:25 -0700 (PDT) Received: from smtp.cs.uni-tuebingen.de (u-173-c156.cs.uni-tuebingen.de [134.2.173.156]) by core3.amsl.com (Postfix) with ESMTP id 696313A680D for ; Wed, 19 Aug 2009 05:41:23 -0700 (PDT) Received: from [131.159.14.149] by smtp.cs.uni-tuebingen.de with esmtpsa (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.69) (envelope-from ) id 1MdkTh-0006Fh-22; Wed, 19 Aug 2009 14:41:21 +0200 Message-ID: <4A8BF2EA.4070907@net.in.tum.de> Date: Wed, 19 Aug 2009 14:41:14 +0200 From: Gerhard Muenz User-Agent: Thunderbird 2.0.0.22 (Windows/20090605) MIME-Version: 1.0 To: Brian Trammell References: <4A8B2FFE.1050303@auckland.ac.nz> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Cc: Nevil Brownlee , IETF IPFIX Working Group Subject: Re: [IPFIX] Call for consensus: changing Intended Status of draft-ietf-ipfix-export-per-sctp-stream from Informational to Standards Track 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, 19 Aug 2009 12:41:27 -0000 Brian, Thanks for your feedback. Brian Trammell wrote: > Greetings, Nevil, all, > > As the draft stands right now, I'm concerned that it may not be > appropriate for the standards track. > > The biggest problem is one of interoperability. > > As strictly specified, SCTP per-stream (SPS)-compliant CPs will not > properly interoperate with 5101-compliant EPs: an EP that sends template > withdrawals, or data sets on unexpected streams will cause errors at the > CP side. Or rather, _may_ cause errors at the CP side: 4.5 states what > to do for TW messages, but it is not clear what the CP should do in case > of an unanticipated data set. You are right. It should be clarified that the CP must not assume per-stream if the EP behaves in a non-compliant way. > More troublingly, SPS-compliant EPs that use the Template Withdrawal > mechanism specified in Section 4.4 will _probably_ interoperate with > 5101-compliant CPs in most cases, but may fail in a very difficult to > detect way. Specifically, since 5101 section 8 paragraph 10 specifies > that "[t]he Template ID from a withdrawn Template MUST NOT be reused > until sufficient time has elapsed to allow for the Collecting Process to > receive and process the Template Withdrawal Message.", 5101-compliant > CPs are _not_ obliged to immediately process template withdrawals in > order on the same stream. Indeed, section 4.4 paragraph 5 _directly_ > contradicts this MUST NOT, as "[t]he Template ID from a withdrawn > Template MAY be reused on the same stream immediately after the Template > Withdrawal Message is sent". I assume that IPFIX processes messages in the order provided by the transport layer, just like any other protocol. It is strange that you assume that a CP would process IPFIX Messages in a different order. RFC5101 Section 9 says that the CP must delete the Template if it receives the withdrawal messages. It does not give room for an unspecified additional "processing time": If a Collecting Process receives a Template Withdrawal Message, the Collecting Process MUST delete the corresponding Template Records associated with the specific SCTP association and specific Observation Domain, and stop decoding IPFIX Messages that use the withdrawn Templates. > Problems here: 1. The EP cannot know at runtime whether the CP is > SPS-compliant or not, and so cannot know whether or not immediate reuse > is safe; 2. assuming immediate reuse is safe when it isn't may cause > data to be unframed improperly, in a way not detectable until later > analysis; and 3. it is unclear whether we can say this _at all_ in a > Standards Track draft without updating 5101 to strike the MUST NOT. This > is a terrible idea, as that MUST NOT is there for a reason: namely, to > make Template Withdrawals work at all in the general case. > > It is unclear how to address the fast Template reuse issue, but it must > be addressed, even without an change of status. > > In any case, since SPS and 5101 are not completely and in all situations > interoperable, the draft needs a very clear specification of the > handshake between the EP and CP, by which they agree they are operating > by the SPS rules. The minimum requirements of this handshake would seem > to be: > > 1. A Collecting Process maintains a SPS mode state per Transport Session. > > 2. All Transport Sessions begin with SPS mode off. > > 3. When a Collecting Process determines that a Transport Session is > operating according to SPS, it sets the SPS mode to on for that session, > and begins operating according to SPS rules (e.g., smaller buffers, > immediate template withdrawal). > > 4. Any receipt of a SPS-illegal template withdrawal or data set (i.e., > on the wrong stream) causes the Collecting Process to log an error and > set the SPS mode to cancelled. Cancelled SPS mode cannot be reset > without a Transport Session reset. Agreed. We should clarify this behavior in 4.5. > 5. An SPS-compatible Exporting Process MUST provide a way to disable SPS > mode on a per-Collecting Process basis. Otherwise, an administrator has > no way to make that Exporting Process work with 5101 Collecting > Processes that cannot handle fast Template reuse. Not sure because I do not understand the interoperability problem between per-stream-EP and 5101-CP. > Complicated? Yes, very. But I can't see another way to guarantee SPS > interoperability with 5101. > > > A second problem is one of applicability. Presently, the draft is not > particularly clear that it is recommended for use only when ALL of the > following conditions hold: > > 1. There is a definite mapping between applications and templates > (multi-template export for data structure variability and export > efficiency within the same logical application, with sharing of common > templates across logical applications, for example, breaks the > assumptions in perstream). I do not understand this point. per-stream works regardless of any application that uses IPFIX. If the application does not need per-stream, it does not have to use it. > 2. There are few enough applications to fit in the number of streams > supported at each endpoint. That is not a problem because multiple Templates can be grouped on one stream as specified in the draft. > 3. Messages are exported using SCTP partial reliability. > > 4. The underlying PR-SCTP implementation supports SCTP-RESET. I think, this is a MAY, not a MUST. > 5. There is a requirement for per-application record loss accounting. > > Therefore, as a new implementor coming upon IPFIX for the first time, > seeing this as a Standards Track draft, I might think that I _must_ > implement it in order to be compliant, even if it has no benefits for my > application (or actively complicates it, as with the example 1. above). > The draft needs a very clear, _exclusive_ statement of the situations in > which it applies, and guidance that it should not be applied where not > applicable. per-stream will be standardized as an extension of RFC5101. It does not have to be implemented if the benefits of the extension are not needed. > (I'm also not entirely convinced that dataRecordsReliability should be > used as an indication that SPS is in effect, as it appears to have some > applicability outside SPS. The definition of dataRecordsReliability does not mention any per-stream context. However, it has a specific meaning if SPS is used. This meaning should probably be mentioned in the definition. > It's also unclear what an EP should do if it > wants to reserve the right to send a Template unreliably in the future, > or what a CP should to if it detects inconsistency in the use of the IE. Sending Templates unreliably is against RFC5101 anyway. Gerhard > But these are side issues.) > > Once these issues are addressed, then perhaps it will be appropriate to > discuss an intended status change. > > Best regards, > > Brian > -- Dipl.-Ing. Gerhard Münz Chair for Network Architectures and Services (I8) Technische Universität München - Department of Informatics Boltzmannstr. 3, 85748 Garching bei München, 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 From trammell@tik.ee.ethz.ch Wed Aug 19 06: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 652E43A6DB8 for ; Wed, 19 Aug 2009 06:32:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id N2d1K-gjT0ca for ; Wed, 19 Aug 2009 06:32:00 -0700 (PDT) Received: from smtp.ee.ethz.ch (smtp.ee.ethz.ch [129.132.2.219]) by core3.amsl.com (Postfix) with ESMTP id C5E943A6AFB for ; Wed, 19 Aug 2009 06:31:59 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by smtp.ee.ethz.ch (Postfix) with ESMTP id 7900FD93A5; Wed, 19 Aug 2009 15:32:03 +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 tUD7QZMfek5X; Wed, 19 Aug 2009 15:32:03 +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 09EEAD9399; Wed, 19 Aug 2009 15:32:03 +0200 (MEST) Message-Id: <4EA60422-905F-40F2-A6C8-B82B9F60FD11@tik.ee.ethz.ch> From: Brian Trammell To: Gerhard Muenz In-Reply-To: <4A8BF2EA.4070907@net.in.tum.de> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Wed, 19 Aug 2009 15:32:02 +0200 References: <4A8B2FFE.1050303@auckland.ac.nz> <4A8BF2EA.4070907@net.in.tum.de> X-Mailer: Apple Mail (2.936) Cc: Nevil Brownlee , IETF IPFIX Working Group Subject: Re: [IPFIX] Call for consensus: changing Intended Status of draft-ietf-ipfix-export-per-sctp-stream from Informational to Standards Track 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, 19 Aug 2009 13:32:01 -0000 hi, Gerhard, Replies inline, redundancy eliminated to conserve electrons. :) Regards, Brian On Aug 19, 2009, at 2:41 PM, Gerhard Muenz wrote: >> More troublingly, SPS-compliant EPs that use the Template Withdrawal >> mechanism specified in Section 4.4 will _probably_ interoperate with >> 5101-compliant CPs in most cases, but may fail in a very difficult to >> detect way. Specifically, since 5101 section 8 paragraph 10 specifies >> that "[t]he Template ID from a withdrawn Template MUST NOT be reused >> until sufficient time has elapsed to allow for the Collecting >> Process to >> receive and process the Template Withdrawal Message.", 5101-compliant >> CPs are _not_ obliged to immediately process template withdrawals in >> order on the same stream. Indeed, section 4.4 paragraph 5 _directly_ >> contradicts this MUST NOT, as "[t]he Template ID from a withdrawn >> Template MAY be reused on the same stream immediately after the >> Template >> Withdrawal Message is sent". > > I assume that IPFIX processes messages in the order provided by the > transport layer, just like any other protocol. It is strange that you > assume that a CP would process IPFIX Messages in a different order. If I have a multithreaded application, with one thread receiving, one per stream deframing, one thread handling the control side, and multiple threads handling deframed data (for example), and I follow 5101 section 8 paragraph 10, I presume explicitly that the EP will hold off on immediate reuse. So I don't necessarily have to lock down _the entire CP_ (which could be rather expensive) in order to process a withdrawal. Okay, I would not implement things this way. But, as 5101 does not _require_ the immediate processing of templates or withdrawals in order, it does not suffice merely to presume an implementation would do so just because all the implementations I can imagine writing would. And there are a lot of engineers out there younger than I am who are a lot thread-happier. :) > RFC5101 Section 9 says that the CP must delete the Template if it > receives the withdrawal messages. It does not give room for an > unspecified additional "processing time": > > If a Collecting Process receives a Template Withdrawal Message, the > Collecting Process MUST delete the corresponding Template Records > associated with the specific SCTP association and specific > Observation Domain, and stop decoding IPFIX Messages that use the > withdrawn Templates. The delay is implicit from 5101 section 8 paragraph 10, which reads, in full: The Template ID from a withdrawn Template MUST NOT be reused until sufficient time has elapsed to allow for the Collecting Process to receive and process the Template Withdrawal Message. Or are you arguing that 5101 sections 8 and 9 are not consistent? I believe they are. >> 5. An SPS-compatible Exporting Process MUST provide a way to >> disable SPS >> mode on a per-Collecting Process basis. Otherwise, an administrator >> has >> no way to make that Exporting Process work with 5101 Collecting >> Processes that cannot handle fast Template reuse. > > Not sure because I do not understand the interoperability problem > between per-stream-EP and 5101-CP. (imagine a sequence diagram here; my ASCII art skills leave something to be desired. :) ) 1. A SPS EP connects to a 5101 CP 2. The EP sends a template A tid 257 on stream 1 3. The EP sends a template B tid 258 on stream 2 4. The EP sends data sets simultaneously on streams 1 and 2, according to templates A and B respectively 5. The EP sends a Template Withdrawal for 257 followed immediately by a template C tid 257 on stream 1, according to SPS section 3.2.2 paragraph 2 (and in violation of 5101 section 8 paragraph 10) 6. The EP starts sending data according to template C on stream 1 7. The CP, not expecting immediate retransmit (because 5101 says it doesn't have to), does... what? with the template C data: 7a. it decodes it correctly? 7b. it buffers it, waiting for the template to be processed? 7c. it decodes it according to template A? Is case 7c always detectable? What if templates A and C have the same length? >> Complicated? Yes, very. But I can't see another way to guarantee SPS >> interoperability with 5101. >> >> >> A second problem is one of applicability. Presently, the draft is not >> particularly clear that it is recommended for use only when ALL of >> the >> following conditions hold: >> >> 1. There is a definite mapping between applications and templates >> (multi-template export for data structure variability and export >> efficiency within the same logical application, with sharing of >> common >> templates across logical applications, for example, breaks the >> assumptions in perstream). > > I do not understand this point. per-stream works regardless of any > application that uses IPFIX. Example: YAF (tools.netsa.cert.org/yaf) uses a stack of... I think 64 templates (it's been a year since I've hacked it), depending on whether the flow is a uniflow or biflow, IPv4 or v6, TCP or not, has payload entropy calculation or not, and so on... The relationship among these templates may or may not be "application" related. Following the per-stream specification for YAF would result in a far more complicated implementation (not to mention requiring people to recompile SCTP to handle 64 streams). There's an implicit assumption in SPS that application <-> template, or application <-> set of templates. It does not hold in the general case. > If the application does not need per-stream, it does not have to use > it. > >> 2. There are few enough applications to fit in the number of streams >> supported at each endpoint. > > That is not a problem because multiple Templates can be grouped on one > stream as specified in the draft. > >> 3. Messages are exported using SCTP partial reliability. >> >> 4. The underlying PR-SCTP implementation supports SCTP-RESET. > > I think, this is a MAY, not a MUST. Hm, true. >> 5. There is a requirement for per-application record loss accounting. >> >> Therefore, as a new implementor coming upon IPFIX for the first time, >> seeing this as a Standards Track draft, I might think that I _must_ >> implement it in order to be compliant, even if it has no benefits >> for my >> application (or actively complicates it, as with the example 1. >> above). >> The draft needs a very clear, _exclusive_ statement of the >> situations in >> which it applies, and guidance that it should not be applied where >> not >> applicable. > > per-stream will be standardized as an extension of RFC5101. It does > not > have to be implemented if the benefits of the extension are not > needed. Excellent. Make it clear in the draft. It doesn't read as such to me, yet. >> (I'm also not entirely convinced that das taRecordsReliability >> should be >> used as an indication that SPS is in effect, as it appears to have >> some >> applicability outside SPS. > > The definition of dataRecordsReliability does not mention any per- > stream > context. However, it has a specific meaning if SPS is used. This > meaning > should probably be mentioned in the definition. > >> It's also unclear what an EP should do if it >> wants to reserve the right to send a Template unreliably in the >> future, >> or what a CP should to if it detects inconsistency in the use of >> the IE. > > Sending Templates unreliably is against RFC5101 anyway. Of course. Typo. s/Template/Data Sets described by a Template/. The point stands... From muenz@net.in.tum.de Wed Aug 19 07:29:27 2009 Return-Path: X-Original-To: ipfix@core3.amsl.com Delivered-To: ipfix@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 65CBF3A6E9D for ; Wed, 19 Aug 2009 07:29:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.113 X-Spam-Level: X-Spam-Status: No, score=-2.113 tagged_above=-999 required=5 tests=[AWL=0.136, 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 TgJV1Gfm2BIt for ; Wed, 19 Aug 2009 07:29:26 -0700 (PDT) Received: from smtp.cs.uni-tuebingen.de (u-173-c156.cs.uni-tuebingen.de [134.2.173.156]) by core3.amsl.com (Postfix) with ESMTP id 6933B3A6F4F for ; Wed, 19 Aug 2009 07:29:17 -0700 (PDT) Received: from [131.159.14.149] by smtp.cs.uni-tuebingen.de with esmtpsa (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.69) (envelope-from ) id 1MdmA8-0006Gc-9C; Wed, 19 Aug 2009 16:29:16 +0200 Message-ID: <4A8C0C38.3070306@net.in.tum.de> Date: Wed, 19 Aug 2009 16:29:12 +0200 From: Gerhard Muenz User-Agent: Thunderbird 2.0.0.22 (Windows/20090605) MIME-Version: 1.0 To: Brian Trammell References: <4A8B2FFE.1050303@auckland.ac.nz> <4A8BF2EA.4070907@net.in.tum.de> <4EA60422-905F-40F2-A6C8-B82B9F60FD11@tik.ee.ethz.ch> In-Reply-To: <4EA60422-905F-40F2-A6C8-B82B9F60FD11@tik.ee.ethz.ch> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Cc: Nevil Brownlee , IETF IPFIX Working Group Subject: Re: [IPFIX] Call for consensus: changing Intended Status of draft-ietf-ipfix-export-per-sctp-stream from Informational to Standards Track 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, 19 Aug 2009 14:29:27 -0000 Hi Brian, Brian Trammell wrote: > On Aug 19, 2009, at 2:41 PM, Gerhard Muenz wrote: > >>> More troublingly, SPS-compliant EPs that use the Template Withdrawal >>> mechanism specified in Section 4.4 will _probably_ interoperate with >>> 5101-compliant CPs in most cases, but may fail in a very difficult to >>> detect way. Specifically, since 5101 section 8 paragraph 10 specifies >>> that "[t]he Template ID from a withdrawn Template MUST NOT be reused >>> until sufficient time has elapsed to allow for the Collecting Process to >>> receive and process the Template Withdrawal Message.", 5101-compliant >>> CPs are _not_ obliged to immediately process template withdrawals in >>> order on the same stream. Indeed, section 4.4 paragraph 5 _directly_ >>> contradicts this MUST NOT, as "[t]he Template ID from a withdrawn >>> Template MAY be reused on the same stream immediately after the Template >>> Withdrawal Message is sent". >> >> I assume that IPFIX processes messages in the order provided by the >> transport layer, just like any other protocol. It is strange that you >> assume that a CP would process IPFIX Messages in a different order. > > If I have a multithreaded application, with one thread receiving, one > per stream deframing, one thread handling the control side, and multiple > threads handling deframed data (for example), and I follow 5101 section > 8 paragraph 10, I presume explicitly that the EP will hold off on > immediate reuse. So I don't necessarily have to lock down _the entire > CP_ (which could be rather expensive) in order to process a withdrawal. There is no problem to process incoming IPFIX Messages in multiple threads as long as one SCTP stream is processed by a single thread. Not sure what you mean by "control side". Do you suggest that Set ID 2 and 3 are processed by different threads than other Set IDs? This would be non-sense because RFC5101 does not specify a time gap between Template and associated Data Sets. The only reason for having specified the gap between withdrawal message and template id reuse in RFC5101 is the out-of-order problem which occurs if the messages are sent on different streams. This problem does not occur with per-stream any more. > Okay, I would not implement things this way. But, as 5101 does not > _require_ the immediate processing of templates or withdrawals in order, > it does not suffice merely to presume an implementation would do so just > because all the implementations I can imagine writing would. And there > are a lot of engineers out there younger than I am who are a lot > thread-happier. :) It seems very strange to me that you think that we cannot expect protocol implementations to process incoming messages in order unless this is explicitly specified in the corresponding RFC. It would be worth checking if this behavior has been specified for other protocols where this is necessary. >> RFC5101 Section 9 says that the CP must delete the Template if it >> receives the withdrawal messages. It does not give room for an >> unspecified additional "processing time": >> >> If a Collecting Process receives a Template Withdrawal Message, the >> Collecting Process MUST delete the corresponding Template Records >> associated with the specific SCTP association and specific >> Observation Domain, and stop decoding IPFIX Messages that use the >> withdrawn Templates. > > The delay is implicit from 5101 section 8 paragraph 10, which reads, in > full: > > The Template ID from a withdrawn Template MUST NOT be reused > until sufficient time has elapsed to allow for the Collecting > Process to receive and process the Template Withdrawal Message. > > Or are you arguing that 5101 sections 8 and 9 are not consistent? I > believe they are. Still, I do not see any hint that allows the CP to process IPFIX Messages in arbitrary order. >>> 5. An SPS-compatible Exporting Process MUST provide a way to disable SPS >>> mode on a per-Collecting Process basis. Otherwise, an administrator has >>> no way to make that Exporting Process work with 5101 Collecting >>> Processes that cannot handle fast Template reuse. >> >> Not sure because I do not understand the interoperability problem >> between per-stream-EP and 5101-CP. > > (imagine a sequence diagram here; my ASCII art skills leave something to > be desired. :) ) > > 1. A SPS EP connects to a 5101 CP > > 2. The EP sends a template A tid 257 on stream 1 > > 3. The EP sends a template B tid 258 on stream 2 > > 4. The EP sends data sets simultaneously on streams 1 and 2, according > to templates A and B respectively > > 5. The EP sends a Template Withdrawal for 257 followed immediately by a > template C tid 257 on stream 1, according to SPS section 3.2.2 paragraph > 2 (and in violation of 5101 section 8 paragraph 10) > > 6. The EP starts sending data according to template C on stream 1 > > 7. The CP, not expecting immediate retransmit (because 5101 says it > doesn't have to), does... what? with the template C data: > > 7a. it decodes it correctly? > > 7b. it buffers it, waiting for the template to be processed? > > 7c. it decodes it according to template A? > > Is case 7c always detectable? What if templates A and C have the same > length? > > >>> Complicated? Yes, very. But I can't see another way to guarantee SPS >>> interoperability with 5101. >>> >>> >>> A second problem is one of applicability. Presently, the draft is not >>> particularly clear that it is recommended for use only when ALL of the >>> following conditions hold: >>> >>> 1. There is a definite mapping between applications and templates >>> (multi-template export for data structure variability and export >>> efficiency within the same logical application, with sharing of common >>> templates across logical applications, for example, breaks the >>> assumptions in perstream). >> >> I do not understand this point. per-stream works regardless of any >> application that uses IPFIX. > > Example: YAF (tools.netsa.cert.org/yaf) uses a stack of... I think 64 > templates (it's been a year since I've hacked it), depending on whether > the flow is a uniflow or biflow, IPv4 or v6, TCP or not, has payload > entropy calculation or not, and so on... The relationship among these > templates may or may not be "application" related. Following the > per-stream specification for YAF would result in a far more complicated > implementation (not to mention requiring people to recompile SCTP to > handle 64 streams). > > There's an implicit assumption in SPS that application <-> template, or > application <-> set of templates. It does not hold in the general case. per-stream is not talking about applications, and we do not assume such a mapping. per-stream allows calculating loss per Template ID or group of Template IDs. If this does not make sense for the application, then it does not have to use per-stream. >> If the application does not need per-stream, it does not have to use it. >> >>> 2. There are few enough applications to fit in the number of streams >>> supported at each endpoint. >> >> That is not a problem because multiple Templates can be grouped on one >> stream as specified in the draft. >> >>> 3. Messages are exported using SCTP partial reliability. >>> >>> 4. The underlying PR-SCTP implementation supports SCTP-RESET. >> >> I think, this is a MAY, not a MUST. > > Hm, true. > >>> 5. There is a requirement for per-application record loss accounting. >>> >>> Therefore, as a new implementor coming upon IPFIX for the first time, >>> seeing this as a Standards Track draft, I might think that I _must_ >>> implement it in order to be compliant, even if it has no benefits for my >>> application (or actively complicates it, as with the example 1. above). >>> The draft needs a very clear, _exclusive_ statement of the situations in >>> which it applies, and guidance that it should not be applied where not >>> applicable. >> >> per-stream will be standardized as an extension of RFC5101. It does not >> have to be implemented if the benefits of the extension are not needed. > > Excellent. Make it clear in the draft. It doesn't read as such to me, yet. Yes, this was also discussed in the IESG evaluation. >>> (I'm also not entirely convinced that das taRecordsReliability should be >>> used as an indication that SPS is in effect, as it appears to have some >>> applicability outside SPS. >> >> The definition of dataRecordsReliability does not mention any per-stream >> context. However, it has a specific meaning if SPS is used. This meaning >> should probably be mentioned in the definition. >> >>> It's also unclear what an EP should do if it >>> wants to reserve the right to send a Template unreliably in the future, >>> or what a CP should to if it detects inconsistency in the use of the IE. >> >> Sending Templates unreliably is against RFC5101 anyway. > > Of course. Typo. s/Template/Data Sets described by a Template/. The > point stands... Ah, ok. Now, I understand this point. In this case, the EP should start a new Template Session if it does not want to use per-stream any more. Regards, Gerhard -- Dipl.-Ing. Gerhard Münz Chair for Network Architectures and Services (I8) Technische Universität München - Department of Informatics Boltzmannstr. 3, 85748 Garching bei München, 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 From n.brownlee@auckland.ac.nz Thu Aug 20 14:58:51 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 4AB993A6EE3 for ; Thu, 20 Aug 2009 14:58:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.702 X-Spam-Level: X-Spam-Status: No, score=-5.702 tagged_above=-999 required=5 tests=[AWL=0.897, 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 0tBUi1Rmws3q for ; Thu, 20 Aug 2009 14:58:50 -0700 (PDT) Received: from mailhost.auckland.ac.nz (larry.its.auckland.ac.nz [130.216.12.34]) by core3.amsl.com (Postfix) with ESMTP id B19F03A6D39 for ; Thu, 20 Aug 2009 14:58:47 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by mailhost.auckland.ac.nz (Postfix) with ESMTP id 27C6441CAB1; Fri, 21 Aug 2009 09:58:41 +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 (larry.its.auckland.ac.nz [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GEl7BCNFc0H2; Fri, 21 Aug 2009 09:58:39 +1200 (NZST) Received: from nevil-laptop.sfac.auckland.ac.nz (nevil-laptop.sfac.auckland.ac.nz [130.216.38.130]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailhost.auckland.ac.nz (Postfix) with ESMTP id 7AC3F41CAA4; Fri, 21 Aug 2009 09:58:34 +1200 (NZST) Message-ID: <4A8DC70A.703@auckland.ac.nz> Date: Fri, 21 Aug 2009 09:58:34 +1200 From: Nevil Brownlee User-Agent: Thunderbird 2.0.0.12 (Macintosh/20080213) MIME-Version: 1.0 To: Brian Trammell References: <4A8B2FFE.1050303@auckland.ac.nz> 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] Call for consensus: changing Intended Status ofdraft-ietf-ipfix-export-per-sctp-stream from Informational to Standards Track 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, 20 Aug 2009 21:58:51 -0000 Hi Brian: My goodness, seeing your detailed comments on this, I feel that I rather under-estimated the difficulties involved with this. I guess that's because I haven't tried to implement it myself, sigh. Still, my post prompted your elucidation, which can only be good. And yes, clearly these details do need to be worked through before we can decide whether changing the draft's intended status. Cheers, Nevil Brian Trammell wrote: > Greetings, Nevil, all, > > As the draft stands right now, I'm concerned that it may not be > appropriate for the standards track. > > The biggest problem is one of interoperability. > > As strictly specified, SCTP per-stream (SPS)-compliant CPs will not > properly interoperate with 5101-compliant EPs: an EP that sends template > withdrawals, or data sets on unexpected streams will cause errors at the > CP side. Or rather, _may_ cause errors at the CP side: 4.5 states what > to do for TW messages, but it is not clear what the CP should do in case > of an unanticipated data set. > > More troublingly, SPS-compliant EPs that use the Template Withdrawal > mechanism specified in Section 4.4 will _probably_ interoperate with > 5101-compliant CPs in most cases, but may fail in a very difficult to > detect way. Specifically, since 5101 section 8 paragraph 10 specifies > that "[t]he Template ID from a withdrawn Template MUST NOT be reused > until sufficient time has elapsed to allow for the Collecting Process to > receive and process the Template Withdrawal Message.", 5101-compliant > CPs are _not_ obliged to immediately process template withdrawals in > order on the same stream. Indeed, section 4.4 paragraph 5 _directly_ > contradicts this MUST NOT, as "[t]he Template ID from a withdrawn > Template MAY be reused on the same stream immediately after the Template > Withdrawal Message is sent". > > Problems here: 1. The EP cannot know at runtime whether the CP is > SPS-compliant or not, and so cannot know whether or not immediate reuse > is safe; 2. assuming immediate reuse is safe when it isn't may cause > data to be unframed improperly, in a way not detectable until later > analysis; and 3. it is unclear whether we can say this _at all_ in a > Standards Track draft without updating 5101 to strike the MUST NOT. This > is a terrible idea, as that MUST NOT is there for a reason: namely, to > make Template Withdrawals work at all in the general case. > > It is unclear how to address the fast Template reuse issue, but it must > be addressed, even without an change of status. > > In any case, since SPS and 5101 are not completely and in all situations > interoperable, the draft needs a very clear specification of the > handshake between the EP and CP, by which they agree they are operating > by the SPS rules. The minimum requirements of this handshake would seem > to be: > > 1. A Collecting Process maintains a SPS mode state per Transport Session. > > 2. All Transport Sessions begin with SPS mode off. > > 3. When a Collecting Process determines that a Transport Session is > operating according to SPS, it sets the SPS mode to on for that session, > and begins operating according to SPS rules (e.g., smaller buffers, > immediate template withdrawal). > > 4. Any receipt of a SPS-illegal template withdrawal or data set (i.e., > on the wrong stream) causes the Collecting Process to log an error and > set the SPS mode to cancelled. Cancelled SPS mode cannot be reset > without a Transport Session reset. > > 5. An SPS-compatible Exporting Process MUST provide a way to disable SPS > mode on a per-Collecting Process basis. Otherwise, an administrator has > no way to make that Exporting Process work with 5101 Collecting > Processes that cannot handle fast Template reuse. > > Complicated? Yes, very. But I can't see another way to guarantee SPS > interoperability with 5101. > > > A second problem is one of applicability. Presently, the draft is not > particularly clear that it is recommended for use only when ALL of the > following conditions hold: > > 1. There is a definite mapping between applications and templates > (multi-template export for data structure variability and export > efficiency within the same logical application, with sharing of common > templates across logical applications, for example, breaks the > assumptions in perstream). > > 2. There are few enough applications to fit in the number of streams > supported at each endpoint. > > 3. Messages are exported using SCTP partial reliability. > > 4. The underlying PR-SCTP implementation supports SCTP-RESET. > > 5. There is a requirement for per-application record loss accounting. > > Therefore, as a new implementor coming upon IPFIX for the first time, > seeing this as a Standards Track draft, I might think that I _must_ > implement it in order to be compliant, even if it has no benefits for my > application (or actively complicates it, as with the example 1. above). > The draft needs a very clear, _exclusive_ statement of the situations in > which it applies, and guidance that it should not be applied where not > applicable. > > (I'm also not entirely convinced that dataRecordsReliability should be > used as an indication that SPS is in effect, as it appears to have some > applicability outside SPS. It's also unclear what an EP should do if it > wants to reserve the right to send a Template unreliably in the future, > or what a CP should to if it detects inconsistency in the use of the IE. > But these are side issues.) > > Once these issues are addressed, then perhaps it will be appropriate to > discuss an intended status change. > > Best regards, > > Brian > > > On Aug 19, 2009, at 12:49 AM, Nevil Brownlee wrote: > >> Hi all: >> >> >> >> I think that Gerhard summed up the discussion on this rather nicely. >> >> Further, it seems to me that the per-stream draft spells out a >> particular way of using the transport layer (SCTP in this case). >> If we want that to depend on having the SCTP Stream Reset extension >> (and I believe that we do), that's a good reason for making it a >> standards-track document. >> >> In short, I support this change of status for the draft. >> >> >> >> Cheers, Nevil >> >> >> Juergen Quittek wrote: >>> Dear all, >>> draft-ietf-ipfix-export-per-sctp-stream is currently under IESG review. >>> Its Intended Status is 'Informational'. >>> Since it uses normative language in some paragraphs, IESG members >>> suggested changing the Intended Status to 'Standards Track'. >>> In the IPFIX WG had consensus about 'Informational' for this draft, >>> because it had a normative reference to a draft in the transport area >>> for which it was unclear if it ever would become a normative RFC. >>> This situation has changed. The draft has been accepted as WG document, >>> see http://www.ietf.org/id/draft-ietf-tsvwg-sctp-strrst-00.txt of the >>> TSVWG and is progressing. We can now use it as normative reference in a >>> 'Standards Track' document. We still would have to wait until probably >>> early 2010 until it gets published, but this seems to be a manageable >>> period of time. Would anyone in the IPFIX WG see a problem with >>> changing the Intended >>> Status of draft-ietf-ipfix-export-per-sctp-stream from 'Informational' >>> to 'Standards Track'? >>> Thanks, >>> Juergen >> >> -- >> --------------------------------------------------------------------- >> Nevil Brownlee Computer Science Department | ITS >> Phone: +64 9 373 7599 x88941 The University of Auckland >> FAX: +64 9 373 7453 Private Bag 92019, Auckland 1142, New Zealand >> _______________________________________________ >> IPFIX mailing list >> IPFIX@ietf.org >> https://www.ietf.org/mailman/listinfo/ipfix > -- --------------------------------------------------------------------- Nevil Brownlee Computer Science Department | ITS Phone: +64 9 373 7599 x88941 The University of Auckland FAX: +64 9 373 7453 Private Bag 92019, Auckland 1142, New Zealand From trammell@tik.ee.ethz.ch Fri Aug 21 04:51:49 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 E3D5C3A6DD0 for ; Fri, 21 Aug 2009 04:51:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1uQQghz0LhrK for ; Fri, 21 Aug 2009 04:51:48 -0700 (PDT) Received: from smtp.ee.ethz.ch (smtp.ee.ethz.ch [129.132.2.219]) by core3.amsl.com (Postfix) with ESMTP id 676153A6DB5 for ; Fri, 21 Aug 2009 04:51:47 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by smtp.ee.ethz.ch (Postfix) with ESMTP id EFB9AD9361; Fri, 21 Aug 2009 13:51:51 +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 FYjCuFZWUtPD; Fri, 21 Aug 2009 13:51:49 +0200 (MEST) Received: from [10.0.1.11] (80-218-68-125.dclient.hispeed.ch [80.218.68.125]) (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 381BBD9370; Fri, 21 Aug 2009 13:51:49 +0200 (MEST) Message-Id: From: Brian Trammell To: Nevil Brownlee In-Reply-To: <4A8DC70A.703@auckland.ac.nz> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Fri, 21 Aug 2009 13:51:47 +0200 References: <4A8B2FFE.1050303@auckland.ac.nz> <4A8DC70A.703@auckland.ac.nz> X-Mailer: Apple Mail (2.936) Cc: IETF IPFIX Working Group Subject: Re: [IPFIX] Call for consensus: changing Intended Status ofdraft-ietf-ipfix-export-per-sctp-stream from Informational to Standards Track 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, 21 Aug 2009 11:51:50 -0000 hi, Nevil, Indeed... though I believe this is quite doable, as the problems enumerated are easily resolvable (1. addition of clearer guidelines for applicability, 2. a clear procedure for ensuring SCTP per-stream export interoperates with "vanilla" 5101 while maximizing its advantages, and 3. a fix for the fast template reuse contradiction), and we have a fair amount of time in which to get them done given the SCTP-RESET normative. Cheers, Brian On Aug 20, 2009, at 11:58 PM, Nevil Brownlee wrote: > Hi Brian: > > My goodness, seeing your detailed comments on this, I feel that > I rather under-estimated the difficulties involved with this. > I guess that's because I haven't tried to implement it myself, > sigh. Still, my post prompted your elucidation, which can only > be good. And yes, clearly these details do need to be worked > through before we can decide whether changing the draft's > intended status. > > Cheers, Nevil > > Brian Trammell wrote: >> Greetings, Nevil, all, >> As the draft stands right now, I'm concerned that it may not be >> appropriate for the standards track. >> The biggest problem is one of interoperability. >> As strictly specified, SCTP per-stream (SPS)-compliant CPs will not >> properly interoperate with 5101-compliant EPs: an EP that sends >> template withdrawals, or data sets on unexpected streams will cause >> errors at the CP side. Or rather, _may_ cause errors at the CP >> side: 4.5 states what to do for TW messages, but it is not clear >> what the CP should do in case of an unanticipated data set. >> More troublingly, SPS-compliant EPs that use the Template >> Withdrawal mechanism specified in Section 4.4 will _probably_ >> interoperate with 5101-compliant CPs in most cases, but may fail in >> a very difficult to detect way. Specifically, since 5101 section 8 >> paragraph 10 specifies that "[t]he Template ID from a withdrawn >> Template MUST NOT be reused until sufficient time has elapsed to >> allow for the Collecting Process to receive and process the >> Template Withdrawal Message.", 5101-compliant CPs are _not_ obliged >> to immediately process template withdrawals in order on the same >> stream. Indeed, section 4.4 paragraph 5 _directly_ contradicts this >> MUST NOT, as "[t]he Template ID from a withdrawn Template MAY be >> reused on the same stream immediately after the Template Withdrawal >> Message is sent". >> Problems here: 1. The EP cannot know at runtime whether the CP is >> SPS-compliant or not, and so cannot know whether or not immediate >> reuse is safe; 2. assuming immediate reuse is safe when it isn't >> may cause data to be unframed improperly, in a way not detectable >> until later analysis; and 3. it is unclear whether we can say this >> _at all_ in a Standards Track draft without updating 5101 to strike >> the MUST NOT. This is a terrible idea, as that MUST NOT is there >> for a reason: namely, to make Template Withdrawals work at all in >> the general case. >> It is unclear how to address the fast Template reuse issue, but it >> must be addressed, even without an change of status. >> In any case, since SPS and 5101 are not completely and in all >> situations interoperable, the draft needs a very clear >> specification of the handshake between the EP and CP, by which they >> agree they are operating by the SPS rules. The minimum requirements >> of this handshake would seem to be: >> 1. A Collecting Process maintains a SPS mode state per Transport >> Session. >> 2. All Transport Sessions begin with SPS mode off. >> 3. When a Collecting Process determines that a Transport Session is >> operating according to SPS, it sets the SPS mode to on for that >> session, and begins operating according to SPS rules (e.g., smaller >> buffers, immediate template withdrawal). >> 4. Any receipt of a SPS-illegal template withdrawal or data set >> (i.e., on the wrong stream) causes the Collecting Process to log an >> error and set the SPS mode to cancelled. Cancelled SPS mode cannot >> be reset without a Transport Session reset. >> 5. An SPS-compatible Exporting Process MUST provide a way to >> disable SPS mode on a per-Collecting Process basis. Otherwise, an >> administrator has no way to make that Exporting Process work with >> 5101 Collecting Processes that cannot handle fast Template reuse. >> Complicated? Yes, very. But I can't see another way to guarantee >> SPS interoperability with 5101. >> A second problem is one of applicability. Presently, the draft is >> not particularly clear that it is recommended for use only when ALL >> of the following conditions hold: >> 1. There is a definite mapping between applications and templates >> (multi-template export for data structure variability and export >> efficiency within the same logical application, with sharing of >> common templates across logical applications, for example, breaks >> the assumptions in perstream). >> 2. There are few enough applications to fit in the number of >> streams supported at each endpoint. >> 3. Messages are exported using SCTP partial reliability. >> 4. The underlying PR-SCTP implementation supports SCTP-RESET. >> 5. There is a requirement for per-application record loss accounting. >> Therefore, as a new implementor coming upon IPFIX for the first >> time, seeing this as a Standards Track draft, I might think that I >> _must_ implement it in order to be compliant, even if it has no >> benefits for my application (or actively complicates it, as with >> the example 1. above). The draft needs a very clear, _exclusive_ >> statement of the situations in which it applies, and guidance that >> it should not be applied where not applicable. >> (I'm also not entirely convinced that dataRecordsReliability should >> be used as an indication that SPS is in effect, as it appears to >> have some applicability outside SPS. It's also unclear what an EP >> should do if it wants to reserve the right to send a Template >> unreliably in the future, or what a CP should to if it detects >> inconsistency in the use of the IE. But these are side issues.) >> Once these issues are addressed, then perhaps it will be >> appropriate to discuss an intended status change. >> Best regards, >> Brian >> On Aug 19, 2009, at 12:49 AM, Nevil Brownlee wrote: >>> Hi all: >>> >>> >>> >>> I think that Gerhard summed up the discussion on this rather nicely. >>> >>> Further, it seems to me that the per-stream draft spells out a >>> particular way of using the transport layer (SCTP in this case). >>> If we want that to depend on having the SCTP Stream Reset extension >>> (and I believe that we do), that's a good reason for making it a >>> standards-track document. >>> >>> In short, I support this change of status for the draft. >>> >>> >>> >>> Cheers, Nevil >>> >>> >>> Juergen Quittek wrote: >>>> Dear all, >>>> draft-ietf-ipfix-export-per-sctp-stream is currently under IESG >>>> review. >>>> Its Intended Status is 'Informational'. >>>> Since it uses normative language in some paragraphs, IESG members >>>> suggested changing the Intended Status to 'Standards Track'. >>>> In the IPFIX WG had consensus about 'Informational' for this draft, >>>> because it had a normative reference to a draft in the transport >>>> area >>>> for which it was unclear if it ever would become a normative RFC. >>>> This situation has changed. The draft has been accepted as WG >>>> document, >>>> see http://www.ietf.org/id/draft-ietf-tsvwg-sctp-strrst-00.txt of >>>> the >>>> TSVWG and is progressing. We can now use it as normative >>>> reference in a >>>> 'Standards Track' document. We still would have to wait until >>>> probably >>>> early 2010 until it gets published, but this seems to be a >>>> manageable >>>> period of time. Would anyone in the IPFIX WG see a problem with >>>> changing the Intended >>>> Status of draft-ietf-ipfix-export-per-sctp-stream from >>>> 'Informational' >>>> to 'Standards Track'? >>>> Thanks, >>>> Juergen >>> >>> -- >>> --------------------------------------------------------------------- >>> Nevil Brownlee Computer Science Department | ITS >>> Phone: +64 9 373 7599 x88941 The University of Auckland >>> FAX: +64 9 373 7453 Private Bag 92019, Auckland 1142, New Zealand >>> _______________________________________________ >>> IPFIX mailing list >>> IPFIX@ietf.org >>> https://www.ietf.org/mailman/listinfo/ipfix > > -- > --------------------------------------------------------------------- > 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 bclaise@cisco.com Fri Aug 21 06:59:42 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 413C53A6926 for ; Fri, 21 Aug 2009 06:59:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.562 X-Spam-Level: X-Spam-Status: No, score=-2.562 tagged_above=-999 required=5 tests=[AWL=0.037, 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 hRcYxvwWHtVH for ; Fri, 21 Aug 2009 06:59:40 -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 52D9E3A6A11 for ; Fri, 21 Aug 2009 06:59:19 -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 n7LDRF4K019470; Fri, 21 Aug 2009 15:27:15 +0200 (CEST) Received: from [10.55.43.51] (ams-bclaise-8712.cisco.com [10.55.43.51]) by strange-brew.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id n7LDREJg000720; Fri, 21 Aug 2009 15:27:14 +0200 (CEST) Message-ID: <4A8EA0B1.9070309@cisco.com> Date: Fri, 21 Aug 2009 15:27:13 +0200 From: Benoit Claise User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Brian Trammell References: <4A8B2FFE.1050303@auckland.ac.nz> <4A8DC70A.703@auckland.ac.nz> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Nevil Brownlee , IETF IPFIX Working Group Subject: Re: [IPFIX] Call for consensus: changing Intended Status ofdraft-ietf-ipfix-export-per-sctp-stream from Informational to Standards Track 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, 21 Aug 2009 13:59:42 -0000 Dear all, A couple of points (some of which have been discussed already): - the per-stream functionality should be considered as an protocol extension, i.e. a more constraint implementation, that you might use if you see a benefit. This should be made clear in the draft. So a couple of specifications will be to modify. For example: if this per-sctp extension is supported, then CP SHOULD treat a Template Withdrawal on a different stream as an error and log it as such - The Data Record Reliability Option Template, which contains the following Information Elements: SCOPE: Template ID NOT-SCOPE: dataRecordsReliability ... is the condition for the CP to know that EP support the per-stream I realize it's not clearly mentioned in the draft - The different compliance cases and the different fall back conditions from per-stream to RFC5101 will have to specified: EP per-stream compliant with CP per-stream compliant EP not per-stream compliant with CP per-stream compliant EP per-stream compliant with CP not per-stream compliant - A mechanism for disabling the per-stream extension might be needed. Potentially with the dataRecordsReliability = FALSE. Note this is not described in the draft right now. - If we go the Intended Status change, this implies another WG last call. Therefore, everybody's feedback will have to take into account. Brian's concerns will obviously have to be addressed. - Practically, when I look at https://datatracker.ietf.org/idtracker/draft-ietf-ipfix-export-per-sctp-stream/, I believe that the standard track is the way to go. However, before re-applying the changes (see http://tools.ietf.org/rfcdiff?url2=draft-ietf-ipfix-export-per-sctp-stream-02.txt), of putting [SCTP-RESET] as a normative reference, I would like to get a kind of consensus that this whole approach is the way to go. Regards, Benoit. > > > Indeed... though I believe this is quite doable, as the problems > enumerated are easily resolvable (1. addition of clearer guidelines > for applicability, 2. a clear procedure for ensuring SCTP per-stream > export interoperates with "vanilla" 5101 while maximizing its > advantages, and 3. a fix for the fast template reuse contradiction), > and we have a fair amount of time in which to get them done given the > SCTP-RESET normative. > > Cheers, > > Brian > > On Aug 20, 2009, at 11:58 PM, Nevil Brownlee wrote: > >> Hi Brian: >> >> My goodness, seeing your detailed comments on this, I feel that >> I rather under-estimated the difficulties involved with this. >> I guess that's because I haven't tried to implement it myself, >> sigh. Still, my post prompted your elucidation, which can only >> be good. And yes, clearly these details do need to be worked >> through before we can decide whether changing the draft's >> intended status. >> >> Cheers, Nevil >> >> Brian Trammell wrote: >>> Greetings, Nevil, all, >>> As the draft stands right now, I'm concerned that it may not be >>> appropriate for the standards track. >>> The biggest problem is one of interoperability. >>> As strictly specified, SCTP per-stream (SPS)-compliant CPs will not >>> properly interoperate with 5101-compliant EPs: an EP that sends >>> template withdrawals, or data sets on unexpected streams will cause >>> errors at the CP side. Or rather, _may_ cause errors at the CP side: >>> 4.5 states what to do for TW messages, but it is not clear what the >>> CP should do in case of an unanticipated data set. >>> More troublingly, SPS-compliant EPs that use the Template Withdrawal >>> mechanism specified in Section 4.4 will _probably_ interoperate with >>> 5101-compliant CPs in most cases, but may fail in a very difficult >>> to detect way. Specifically, since 5101 section 8 paragraph 10 >>> specifies that "[t]he Template ID from a withdrawn Template MUST NOT >>> be reused until sufficient time has elapsed to allow for the >>> Collecting Process to receive and process the Template Withdrawal >>> Message.", 5101-compliant CPs are _not_ obliged to immediately >>> process template withdrawals in order on the same stream. Indeed, >>> section 4.4 paragraph 5 _directly_ contradicts this MUST NOT, as >>> "[t]he Template ID from a withdrawn Template MAY be reused on the >>> same stream immediately after the Template Withdrawal Message is sent". >>> Problems here: 1. The EP cannot know at runtime whether the CP is >>> SPS-compliant or not, and so cannot know whether or not immediate >>> reuse is safe; 2. assuming immediate reuse is safe when it isn't may >>> cause data to be unframed improperly, in a way not detectable until >>> later analysis; and 3. it is unclear whether we can say this _at >>> all_ in a Standards Track draft without updating 5101 to strike the >>> MUST NOT. This is a terrible idea, as that MUST NOT is there for a >>> reason: namely, to make Template Withdrawals work at all in the >>> general case. >>> It is unclear how to address the fast Template reuse issue, but it >>> must be addressed, even without an change of status. >>> In any case, since SPS and 5101 are not completely and in all >>> situations interoperable, the draft needs a very clear specification >>> of the handshake between the EP and CP, by which they agree they are >>> operating by the SPS rules. The minimum requirements of this >>> handshake would seem to be: >>> 1. A Collecting Process maintains a SPS mode state per Transport >>> Session. >>> 2. All Transport Sessions begin with SPS mode off. >>> 3. When a Collecting Process determines that a Transport Session is >>> operating according to SPS, it sets the SPS mode to on for that >>> session, and begins operating according to SPS rules (e.g., smaller >>> buffers, immediate template withdrawal). >>> 4. Any receipt of a SPS-illegal template withdrawal or data set >>> (i.e., on the wrong stream) causes the Collecting Process to log an >>> error and set the SPS mode to cancelled. Cancelled SPS mode cannot >>> be reset without a Transport Session reset. >>> 5. An SPS-compatible Exporting Process MUST provide a way to disable >>> SPS mode on a per-Collecting Process basis. Otherwise, an >>> administrator has no way to make that Exporting Process work with >>> 5101 Collecting Processes that cannot handle fast Template reuse. >>> Complicated? Yes, very. But I can't see another way to guarantee SPS >>> interoperability with 5101. >>> A second problem is one of applicability. Presently, the draft is >>> not particularly clear that it is recommended for use only when ALL >>> of the following conditions hold: >>> 1. There is a definite mapping between applications and templates >>> (multi-template export for data structure variability and export >>> efficiency within the same logical application, with sharing of >>> common templates across logical applications, for example, breaks >>> the assumptions in perstream). >>> 2. There are few enough applications to fit in the number of streams >>> supported at each endpoint. >>> 3. Messages are exported using SCTP partial reliability. >>> 4. The underlying PR-SCTP implementation supports SCTP-RESET. >>> 5. There is a requirement for per-application record loss accounting. >>> Therefore, as a new implementor coming upon IPFIX for the first >>> time, seeing this as a Standards Track draft, I might think that I >>> _must_ implement it in order to be compliant, even if it has no >>> benefits for my application (or actively complicates it, as with the >>> example 1. above). The draft needs a very clear, _exclusive_ >>> statement of the situations in which it applies, and guidance that >>> it should not be applied where not applicable. >>> (I'm also not entirely convinced that dataRecordsReliability should >>> be used as an indication that SPS is in effect, as it appears to >>> have some applicability outside SPS. It's also unclear what an EP >>> should do if it wants to reserve the right to send a Template >>> unreliably in the future, or what a CP should to if it detects >>> inconsistency in the use of the IE. But these are side issues.) >>> Once these issues are addressed, then perhaps it will be appropriate >>> to discuss an intended status change. >>> Best regards, >>> Brian >>> On Aug 19, 2009, at 12:49 AM, Nevil Brownlee wrote: >>>> Hi all: >>>> >>>> >>>> >>>> I think that Gerhard summed up the discussion on this rather nicely. >>>> >>>> Further, it seems to me that the per-stream draft spells out a >>>> particular way of using the transport layer (SCTP in this case). >>>> If we want that to depend on having the SCTP Stream Reset extension >>>> (and I believe that we do), that's a good reason for making it a >>>> standards-track document. >>>> >>>> In short, I support this change of status for the draft. >>>> >>>> >>>> >>>> Cheers, Nevil >>>> >>>> >>>> Juergen Quittek wrote: >>>>> Dear all, >>>>> draft-ietf-ipfix-export-per-sctp-stream is currently under IESG >>>>> review. >>>>> Its Intended Status is 'Informational'. >>>>> Since it uses normative language in some paragraphs, IESG members >>>>> suggested changing the Intended Status to 'Standards Track'. >>>>> In the IPFIX WG had consensus about 'Informational' for this draft, >>>>> because it had a normative reference to a draft in the transport area >>>>> for which it was unclear if it ever would become a normative RFC. >>>>> This situation has changed. The draft has been accepted as WG >>>>> document, >>>>> see http://www.ietf.org/id/draft-ietf-tsvwg-sctp-strrst-00.txt of the >>>>> TSVWG and is progressing. We can now use it as normative reference >>>>> in a >>>>> 'Standards Track' document. We still would have to wait until >>>>> probably >>>>> early 2010 until it gets published, but this seems to be a manageable >>>>> period of time. Would anyone in the IPFIX WG see a problem with >>>>> changing the Intended >>>>> Status of draft-ietf-ipfix-export-per-sctp-stream from >>>>> 'Informational' >>>>> to 'Standards Track'? >>>>> Thanks, >>>>> Juergen >>>> >>>> -- >>>> --------------------------------------------------------------------- >>>> Nevil Brownlee Computer Science Department | ITS >>>> Phone: +64 9 373 7599 x88941 The University of Auckland >>>> FAX: +64 9 373 7453 Private Bag 92019, Auckland 1142, New Zealand >>>> _______________________________________________ >>>> IPFIX mailing list >>>> IPFIX@ietf.org >>>> https://www.ietf.org/mailman/listinfo/ipfix >> >> -- >> --------------------------------------------------------------------- >> Nevil Brownlee Computer Science Department | ITS >> Phone: +64 9 373 7599 x88941 The University of Auckland >> FAX: +64 9 373 7453 Private Bag 92019, Auckland 1142, New Zealand > > _______________________________________________ > IPFIX mailing list > IPFIX@ietf.org > https://www.ietf.org/mailman/listinfo/ipfix From wwwrun@core3.amsl.com Tue Aug 25 07:01:41 2009 Return-Path: X-Original-To: ipfix@ietf.org Delivered-To: ipfix@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 30) id 085563A6E76; Tue, 25 Aug 2009 07:01:40 -0700 (PDT) X-idtracker: yes From: The IESG To: IETF-Announce Message-Id: <20090825140141.085563A6E76@core3.amsl.com> Date: Tue, 25 Aug 2009 07:01:41 -0700 (PDT) Cc: Internet Architecture Board , ipfix chair , ipfix mailing list , RFC Editor Subject: [IPFIX] Protocol Action: 'Specification of the IPFIX File Format' 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, 25 Aug 2009 14:01:41 -0000 The IESG has approved the following document: - 'Specification of the IPFIX File Format ' as a Proposed Standard This document is the product of the IP Flow Information Export Working Group. The IESG contact persons are Dan Romascanu and Ron Bonica. A URL of this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ipfix-file-05.txt Technical Summary This document describes a file format for the storage of flow data based upon the IPFIX Protocol. It proposes a set of requirements for flat-file, binary flow data file formats, then specifies the IPFIX 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 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 Section 9.1: OLD: eContentType id-ct-anyContentType, -- (1.2.840.113549.1.9.16.1.0) NEW: eContentType id-data, -- (1.2.840.113549.1.7.1) Section 9.1.4: OLD: The EncapsulatedContentInfo structure contains a content type identifier. Since a detached signature is being created, it does not encapsulate the Internet-Draft. The fields of EncapsulatedContentInfo are as follows: eContentType is an object identifier that uniquely specifies the content type. The content type associated with the plain text file MUST be id-ct-anyContentType (1.2.840.113549.1.9.16.1.0). NEW: The EncapsulatedContentInfo structure contains a content type identifier. Since a detached signature is being created, it does not encapsulate the IPFIX File. The fields of EncapsulatedContentInfo are as follows: eContentType is an object identifier that uniquely specifies the content type. The content type associated with IPFIX File MUST be id-data (1.2.840.113549.1.7.1). From Quittek@nw.neclab.eu Wed Aug 26 03:54:59 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 529BD3A6B16 for ; Wed, 26 Aug 2009 03:54:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.41 X-Spam-Level: X-Spam-Status: No, score=-2.41 tagged_above=-999 required=5 tests=[AWL=0.189, 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 m-Oo9RmwUja6 for ; Wed, 26 Aug 2009 03:54:58 -0700 (PDT) Received: from smtp0.neclab.eu (smtp0.neclab.eu [195.37.70.41]) by core3.amsl.com (Postfix) with ESMTP id E1B213A6B6F for ; Wed, 26 Aug 2009 03:54:57 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp0.neclab.eu (Postfix) with ESMTP id 0E4A42C0012C4 for ; Wed, 26 Aug 2009 11:57:05 +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 tc4NsOUqHq1O for ; Wed, 26 Aug 2009 11:57:04 +0200 (CEST) Received: from VENUS.office (mx1.office [192.168.24.3]) by smtp0.neclab.eu (Postfix) with ESMTP id CF2BD2C0001AA for ; Wed, 26 Aug 2009 11:56:59 +0200 (CEST) Received: from 10.7.0.54 ([10.7.0.54]) by VENUS.office ([192.168.24.102]) with Microsoft Exchange Server HTTP-DAV ; Wed, 26 Aug 2009 09:56:55 +0000 MIME-Version: 1.0 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-Type: multipart/signed; boundary="B_3334124808_2260387"; protocol="application/pkcs7-signature"; micalg=sha1 Content-class: urn:content-classes:message Date: Wed, 26 Aug 2009 11:56:55 +0200 Message-ID: In-Reply-To: X-MS-Has-Attach: yes X-MS-TNEF-Correlator: Thread-Topic: [IPFIX] new work items for the IPFIX charter Thread-Index: AcoREuMPI1q++yG27keilphWGxsLQwVDnqS9 From: "Juergen Quittek" To: "IETF IPFIX Working Group" Subject: Re: [IPFIX] new work items for the IPFIX charter 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, 26 Aug 2009 10:54:59 -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_3334124808_2260387 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Dear all, I have not received any concern about adding these items to our agenda. We have consensus and can request an update of our charter. Below please find a first draft of the new charter items and milestones. Please review them and provide your comments. Thanks, Juergen -- Anonymization of flow information has been identified as a requirement for flow information export already in RFC 3917. However, technologies for flow anonymization are still a research issue and have so far not been considered to be mature enough for standardization. As one step in this direction, the IPFIX WG will develop guidelines for the implementation of anonymised data export and storage over IPFIX and define an information model for configuring and reporting anonymization applied at IPFIX devices. -- The IPFIX and PSAMP WGs have defined standards for selecting observed IP packets and collecting information in flow records. In order to reduce the amount of data to be processed, packet selection methods have been defined. Another method for reducing flow data is flow selection. The IPFIX WG will define methods for flow selection and provide an information model for configuring and reporting flow selection applied at IPFIX devices. -- Being designed for the export of flow records the IPFIX protocol provides very limited means for structuring information elements within IPFIX records. With the increasing number of IPFIX applications there is a need for exporting more complex information. The IPFIX WG will develop an extension of the IPFIX protocol that supports hierarchically structured data and lists (sequences) of Information Elements in data records. Oct 2009 Submit initial draft on anonymization support Oct 2009 Submit initial draft on flow selection Oct 2009 Submit initial draft on structuring information elements Jun 2010 Submit anonymization support I-D to IESG for publication as Experimental RFC Jun 2010 Submit flow selection I-D to IESG for publication as Standards Track RFC Jun 2010 Submit structuring information elements I-D to IESG for publication as Standards Track RFC On 30.07.09 14:40 "Juergen Quittek" wrote: > Dear all, > > At our session on Monday there were three drafts presented > for which there was a consensus to accept them as working > group documents. Now we need confirmation on this list. > > The drafts are > > - Export of Structured Data in IPFIXDear > http://tools.ietf.org/html/draft-claise-structured-data-in-ipfix > - IP Flow Anonymisation Support > http://tools.ietf.org/html/draft-boschi-ipfix-anon > - Flow Selection Techniques > http://tools.ietf.org/html/draft-peluso-flowselection-tech > > If you see any problem with adding these three items to the > IPFIX agenda, please make your point on this list within the > next two weeks. > > Thanks, > > Juergen > > > > _______________________________________________ > IPFIX mailing list > IPFIX@ietf.org > https://www.ietf.org/mailman/listinfo/ipfix --B_3334124808_2260387 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 YWIuZXUCBA0uKwcwCQYFKw4DAhoFAKBdMCMGCSqGSIb3DQEJBDEWBBQaRwxsHhRWNs85YYCE s8HcvcfcUTAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0wOTA4 MjYwNzQ2NDhaMA0GCSqGSIb3DQEBAQUABIIBAGQ6eK174bN8o2aFT3VKDlUfY7oLGKCG7L2F zYN0RKd2W892oPNquJCezzs65a6xE3NEeU30tYHFzwogOswdAeDR9v3/Hme3yylA35h0Fm1p Bip/gXaWLKHW0XX+RIP0vJNTeJUY+J1y+KCtXpb6XuTNOz9Syj+XJfX3J+RmgalF+L+OEhHZ ApRHTUeo+HVoj6ktGGtZXl1cvejvF6McSfSZakoAKbMNVR6X7DhQxrbP18VmNEE7nfor59wW wtU8Egcqo6xOOV6+j53UznQ07U5mjeG/adfpJaqAGECrjXOWSp3pnvrNe2Wm9C8LEkVD/sMI rkcz8zBu8q1kep90etI= --B_3334124808_2260387-- From Tanja.Zseby9ab33xy531fokus.fraunhofer.de@bounce.antispameurope.com Wed Aug 26 04:09:52 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 0A1813A6940 for ; Wed, 26 Aug 2009 04:09:52 -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 MMdAQGX+LpCW for ; Wed, 26 Aug 2009 04:09:51 -0700 (PDT) Received: from relay03-haj2.antispameurope.com (relay03-haj2.antispameurope.com [83.246.65.53]) by core3.amsl.com (Postfix) with ESMTP id B45CE3A693C for ; Wed, 26 Aug 2009 04:09:50 -0700 (PDT) Received: by relay03-haj2.antispameurope.com (ASE-Secure-MTA, from userid 1000) id 5C76363C14B; Wed, 26 Aug 2009 13:09:32 +0200 (CEST) Received: from pluto.fokus.fraunhofer.de (pluto.fokus.fraunhofer.de [195.37.77.164]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by relay03-haj2.antispameurope.com (ASE-Secure-MTA) with ESMTP id F025363C088; Wed, 26 Aug 2009 13:09:30 +0200 (CEST) Received: from EXCHSRV.fokus.fraunhofer.de (bohr.fokus.fraunhofer.de [10.147.9.231]) by pluto.fokus.fraunhofer.de (8.14.2/8.14.2) with SMTP id n7QB9VJZ001662; Wed, 26 Aug 2009 13:09:31 +0200 (MEST) x-mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Wed, 26 Aug 2009 13:09:29 +0200 Message-ID: <804B13F8F3D94A4AB18B9B01ACB68FA102DA6AA1@EXCHSRV.fokus.fraunhofer.de> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [IPFIX] new work items for the IPFIX charter Thread-Index: AcoREuMPI1q++yG27keilphWGxsLQwVDnqS9AAcPITA= References: From: "Zseby, Tanja" To: "Juergen Quittek" , "IETF IPFIX Working Group" Subject: Re: [IPFIX] new work items for the IPFIX charter 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, 26 Aug 2009 11:09:52 -0000 Hi Juergen, the description looks good for me. Kind regards Tanja > -----Urspr=FCngliche Nachricht----- > Von: ipfix-bounces@ietf.org [mailto:ipfix-bounces@ietf.org] Im Auftrag > von Juergen Quittek > Gesendet: Mittwoch, 26. August 2009 11:57 > An: IETF IPFIX Working Group > Betreff: Re: [IPFIX] new work items for the IPFIX charter >=20 > Dear all, >=20 > I have not received any concern about adding these items to our = agenda. > We have consensus and can request an update of our charter. >=20 > Below please find a first draft of the new charter items and > milestones. > Please review them and provide your comments. >=20 > Thanks, >=20 > Juergen >=20 >=20 > -- Anonymization of flow information has been identified as a > requirement for flow information export already in RFC 3917. However, > technologies for flow anonymization are still a research issue and = have > so far not been considered to be mature enough for standardization. > As one step in this direction, the IPFIX WG will develop guidelines = for > the implementation of anonymised data export and storage over IPFIX = and > define an information model for configuring and reporting = anonymization > applied at IPFIX devices. >=20 > -- The IPFIX and PSAMP WGs have defined standards for selecting > observed IP packets and collecting information in flow records. > In order to reduce the amount of data to be processed, packet = selection > methods have been defined. Another method for reducing flow data is > flow selection. The IPFIX WG will define methods for flow selection = and > provide an information model for configuring and reporting flow > selection applied at IPFIX devices. >=20 > -- Being designed for the export of flow records the IPFIX protocol > provides very limited means for structuring information elements = within > IPFIX records. With the increasing number of IPFIX applications there > is a need for exporting more complex information. The IPFIX WG will > develop an extension of the IPFIX protocol that supports = hierarchically > structured data and lists (sequences) of Information Elements in data > records. >=20 >=20 > Oct 2009 Submit initial draft on anonymization support > Oct 2009 Submit initial draft on flow selection > Oct 2009 Submit initial draft on structuring information elements > Jun 2010 Submit anonymization support I-D to IESG for publication > as Experimental RFC > Jun 2010 Submit flow selection I-D to IESG for publication > as Standards Track RFC > Jun 2010 Submit structuring information elements I-D to IESG > for publication as Standards Track RFC >=20 >=20 > On 30.07.09 14:40 "Juergen Quittek" wrote: >=20 > > Dear all, > > > > At our session on Monday there were three drafts presented for which > > there was a consensus to accept them as working group documents. Now > > we need confirmation on this list. > > > > The drafts are > > > > - Export of Structured Data in IPFIXDear > > http://tools.ietf.org/html/draft-claise-structured-data-in-ipfix > > - IP Flow Anonymisation Support > > http://tools.ietf.org/html/draft-boschi-ipfix-anon > > - Flow Selection Techniques > > http://tools.ietf.org/html/draft-peluso-flowselection-tech > > > > If you see any problem with adding these three items to the IPFIX > > agenda, please make your point on this list within the next two > weeks. > > > > Thanks, > > > > Juergen > > > > > > > > _______________________________________________ > > IPFIX mailing list > > IPFIX@ietf.org > > https://www.ietf.org/mailman/listinfo/ipfix From bclaise@cisco.com Thu Aug 27 04:04:49 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 B2B4A3A68F8 for ; Thu, 27 Aug 2009 04:04:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.565 X-Spam-Level: X-Spam-Status: No, score=-2.565 tagged_above=-999 required=5 tests=[AWL=0.033, 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 WdsvuOXMrgc9 for ; Thu, 27 Aug 2009 04:04:48 -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 50FA93A6D01 for ; Thu, 27 Aug 2009 04:04:48 -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 n7RB18dj022281; Thu, 27 Aug 2009 13:01:09 +0200 (CEST) Received: from [10.55.43.56] (ams-bclaise-8717.cisco.com [10.55.43.56]) by strange-brew.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id n7RB18ix024278; Thu, 27 Aug 2009 13:01:08 +0200 (CEST) Message-ID: <4A966774.4080900@cisco.com> Date: Thu, 27 Aug 2009 13:01:08 +0200 From: Benoit Claise User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Juergen Quittek References: In-Reply-To: Content-Type: multipart/alternative; boundary="------------080109050305050409080905" Cc: IETF IPFIX Working Group Subject: Re: [IPFIX] new work items for the IPFIX charter 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, 27 Aug 2009 11:04:49 -0000 This is a multi-part message in MIME format. --------------080109050305050409080905 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Juergen, This looks good. Regards, Benoit. > Dear all, > > I have not received any concern about adding these items to our agenda. > We have consensus and can request an update of our charter. > > Below please find a first draft of the new charter items and milestones. > Please review them and provide your comments. > > Thanks, > > Juergen > > > -- Anonymization of flow information has been identified as a > requirement for flow information export already in RFC 3917. However, > technologies for flow anonymization are still a research issue and have > so far not been considered to be mature enough for standardization. > As one step in this direction, the IPFIX WG will develop guidelines for > the implementation of anonymised data export and storage over IPFIX > and define an information model for configuring and reporting > anonymization applied at IPFIX devices. > > -- The IPFIX and PSAMP WGs have defined standards for selecting > observed IP packets and collecting information in flow records. > In order to reduce the amount of data to be processed, packet selection > methods have been defined. Another method for reducing flow data is flow > selection. The IPFIX WG will define methods for flow selection and provide > an information model for configuring and reporting flow selection applied > at IPFIX devices. > > -- Being designed for the export of flow records the IPFIX protocol > provides very limited means for structuring information elements within > IPFIX records. With the increasing number of IPFIX applications there is > a need for exporting more complex information. The IPFIX WG will develop > an extension of the IPFIX protocol that supports hierarchically structured > data and lists (sequences) of Information Elements in data records. > > > Oct 2009 Submit initial draft on anonymization support > Oct 2009 Submit initial draft on flow selection > Oct 2009 Submit initial draft on structuring information elements > Jun 2010 Submit anonymization support I-D to IESG for publication > as Experimental RFC > Jun 2010 Submit flow selection I-D to IESG for publication > as Standards Track RFC > Jun 2010 Submit structuring information elements I-D to IESG > for publication as Standards Track RFC > > > On 30.07.09 14:40 "Juergen Quittek" wrote: > > >> Dear all, >> >> At our session on Monday there were three drafts presented >> for which there was a consensus to accept them as working >> group documents. Now we need confirmation on this list. >> >> The drafts are >> >> - Export of Structured Data in IPFIXDear >> http://tools.ietf.org/html/draft-claise-structured-data-in-ipfix >> - IP Flow Anonymisation Support >> http://tools.ietf.org/html/draft-boschi-ipfix-anon >> - Flow Selection Techniques >> http://tools.ietf.org/html/draft-peluso-flowselection-tech >> >> If you see any problem with adding these three items to the >> IPFIX agenda, please make your point on this list within the >> next two weeks. >> >> Thanks, >> >> Juergen >> >> >> >> _______________________________________________ >> IPFIX mailing list >> IPFIX@ietf.org >> https://www.ietf.org/mailman/listinfo/ipfix >> >> ------------------------------------------------------------------------ >> >> _______________________________________________ >> IPFIX mailing list >> IPFIX@ietf.org >> https://www.ietf.org/mailman/listinfo/ipfix >> --------------080109050305050409080905 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Juergen,

This looks good.

Regards, Benoit.
Dear all,

I have not received any concern about adding these items to our agenda.
We have consensus and can request an update of our charter.

Below please find a first draft of the new charter items and milestones.
Please review them and provide your comments.

Thanks,

    Juergen


-- Anonymization of flow information has been identified as a
requirement for flow information export already in RFC 3917. However,
technologies for flow anonymization are still a research issue and have
so far not been considered to be mature enough for standardization.
As one step in this direction, the IPFIX WG will develop guidelines for
the implementation of anonymised data export and storage over IPFIX
and define an information model for configuring and reporting
anonymization applied at IPFIX devices.

-- The IPFIX and PSAMP WGs have defined standards for selecting
observed IP packets and collecting information in flow records.
In order to reduce the amount of data to be processed, packet selection
methods have been defined. Another method for reducing flow data is flow
selection. The IPFIX WG will define methods for flow selection and provide
an information model for configuring and reporting flow selection applied
at IPFIX devices.

-- Being designed for the export of flow records the IPFIX protocol
provides very limited means for structuring information elements within
IPFIX records. With the increasing number of IPFIX applications there is
a need for exporting more complex information. The IPFIX WG will develop
an extension of the IPFIX protocol that supports hierarchically structured
data and lists (sequences) of Information Elements in data records.


Oct 2009   Submit initial draft on anonymization support
Oct 2009   Submit initial draft on flow selection
Oct 2009   Submit initial draft on structuring information elements
Jun 2010   Submit anonymization support I-D to IESG for publication
           as Experimental RFC
Jun 2010   Submit flow selection I-D to IESG for publication
           as Standards Track RFC
Jun 2010   Submit structuring information elements I-D to IESG
           for publication as Standards Track RFC


On 30.07.09 14:40  "Juergen Quittek" <Quittek@nw.neclab.eu> wrote:

  
Dear all,

At our session on Monday there were three drafts presented
for which there was a consensus to accept them as working
group documents. Now we need confirmation on this list.

The drafts are

  - Export of Structured Data in IPFIXDear
    http://tools.ietf.org/html/draft-claise-structured-data-in-ipfix
  - IP Flow Anonymisation Support
    http://tools.ietf.org/html/draft-boschi-ipfix-anon
  - Flow Selection Techniques
    http://tools.ietf.org/html/draft-peluso-flowselection-tech

If you see any problem with adding these three items to the
IPFIX agenda, please make your point on this list within the
next two weeks.

Thanks,

    Juergen 


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

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

--------------080109050305050409080905-- From boschie@tik.ee.ethz.ch Thu Aug 27 07:16:51 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 5E18E28C5F2 for ; Thu, 27 Aug 2009 07:16:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.226 X-Spam-Level: X-Spam-Status: No, score=-6.226 tagged_above=-999 required=5 tests=[AWL=0.372, BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 aQOH1vF9kbNE for ; Thu, 27 Aug 2009 07:16:50 -0700 (PDT) Received: from smtp.ee.ethz.ch (smtp.ee.ethz.ch [129.132.2.219]) by core3.amsl.com (Postfix) with ESMTP id E867228C5F8 for ; Thu, 27 Aug 2009 07:15:38 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by smtp.ee.ethz.ch (Postfix) with ESMTP id CE8A1D9343 for ; Thu, 27 Aug 2009 16:15:43 +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 AhaMZvZBJfgn for ; Thu, 27 Aug 2009 16:15:43 +0200 (MEST) Received: from [82.130.102.89] (nb-5442.ethz.ch [82.130.102.89]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: boschie) by smtp.ee.ethz.ch (Postfix) with ESMTP id 4493BD9462 for ; Thu, 27 Aug 2009 16:15:43 +0200 (MEST) Message-ID: <4A96950F.3090808@tik.ee.ethz.ch> Date: Thu, 27 Aug 2009 16:15:43 +0200 From: Elisa Boschi User-Agent: Thunderbird 2.0.0.22 (Windows/20090605) MIME-Version: 1.0 To: IETF IPFIX Working Group Content-Type: multipart/alternative; boundary="------------050004070401010902050200" Subject: Re: [IPFIX] new work items for the IPFIX charter 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, 27 Aug 2009 14:16:51 -0000 This is a multi-part message in MIME format. --------------050004070401010902050200 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Jürgen, the text is fine for me thanks, Elisa Juergen Quittek wrote: > Dear all, > > I have not received any concern about adding these items to our agenda. > We have consensus and can request an update of our charter. > > Below please find a first draft of the new charter items and milestones. > Please review them and provide your comments. > > Thanks, > > Juergen > > > -- Anonymization of flow information has been identified as a > requirement for flow information export already in RFC 3917. However, > technologies for flow anonymization are still a research issue and have > so far not been considered to be mature enough for standardization. > As one step in this direction, the IPFIX WG will develop guidelines for > the implementation of anonymised data export and storage over IPFIX > and define an information model for configuring and reporting > anonymization applied at IPFIX devices. > > -- The IPFIX and PSAMP WGs have defined standards for selecting > observed IP packets and collecting information in flow records. > In order to reduce the amount of data to be processed, packet selection > methods have been defined. Another method for reducing flow data is flow > selection. The IPFIX WG will define methods for flow selection and provide > an information model for configuring and reporting flow selection applied > at IPFIX devices. > > -- Being designed for the export of flow records the IPFIX protocol > provides very limited means for structuring information elements within > IPFIX records. With the increasing number of IPFIX applications there is > a need for exporting more complex information. The IPFIX WG will develop > an extension of the IPFIX protocol that supports hierarchically structured > data and lists (sequences) of Information Elements in data records. > > > Oct 2009 Submit initial draft on anonymization support > Oct 2009 Submit initial draft on flow selection > Oct 2009 Submit initial draft on structuring information elements > Jun 2010 Submit anonymization support I-D to IESG for publication > as Experimental RFC > Jun 2010 Submit flow selection I-D to IESG for publication > as Standards Track RFC > Jun 2010 Submit structuring information elements I-D to IESG > for publication as Standards Track RFC > > > On 30.07.09 14:40 "Juergen Quittek" wrote: > > >> Dear all, >> >> At our session on Monday there were three drafts presented >> for which there was a consensus to accept them as working >> group documents. Now we need confirmation on this list. >> >> The drafts are >> >> - Export of Structured Data in IPFIXDear >> http://tools.ietf.org/html/draft-claise-structured-data-in-ipfix >> - IP Flow Anonymisation Support >> http://tools.ietf.org/html/draft-boschi-ipfix-anon >> - Flow Selection Techniques >> http://tools.ietf.org/html/draft-peluso-flowselection-tech >> >> If you see any problem with adding these three items to the >> IPFIX agenda, please make your point on this list within the >> next two weeks. >> >> Thanks, >> >> Juergen >> >> >> >> _______________________________________________ >> IPFIX mailing list >> IPFIX@ietf.org >> https://www.ietf.org/mailman/listinfo/ipfix >> >> ------------------------------------------------------------------------ >> >> _______________________________________________ >> IPFIX mailing list >> IPFIX@ietf.org >> https://www.ietf.org/mailman/listinfo/ipfix >> --------------050004070401010902050200 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Jürgen,

the text is fine for me

thanks,
Elisa

Juergen Quittek wrote: 
Dear all,

I have not received any concern about adding these items to our agenda.
We have consensus and can request an update of our charter.

Below please find a first draft of the new charter items and milestones.
Please review them and provide your comments.

Thanks,

    Juergen


-- Anonymization of flow information has been identified as a
requirement for flow information export already in RFC 3917. However,
technologies for flow anonymization are still a research issue and have
so far not been considered to be mature enough for standardization.
As one step in this direction, the IPFIX WG will develop guidelines for
the implementation of anonymised data export and storage over IPFIX
and define an information model for configuring and reporting
anonymization applied at IPFIX devices.

-- The IPFIX and PSAMP WGs have defined standards for selecting
observed IP packets and collecting information in flow records.
In order to reduce the amount of data to be processed, packet selection
methods have been defined. Another method for reducing flow data is flow
selection. The IPFIX WG will define methods for flow selection and provide
an information model for configuring and reporting flow selection applied
at IPFIX devices.

-- Being designed for the export of flow records the IPFIX protocol
provides very limited means for structuring information elements within
IPFIX records. With the increasing number of IPFIX applications there is
a need for exporting more complex information. The IPFIX WG will develop
an extension of the IPFIX protocol that supports hierarchically structured
data and lists (sequences) of Information Elements in data records.


Oct 2009   Submit initial draft on anonymization support
Oct 2009   Submit initial draft on flow selection
Oct 2009   Submit initial draft on structuring information elements
Jun 2010   Submit anonymization support I-D to IESG for publication
           as Experimental RFC
Jun 2010   Submit flow selection I-D to IESG for publication
           as Standards Track RFC
Jun 2010   Submit structuring information elements I-D to IESG
           for publication as Standards Track RFC


On 30.07.09 14:40  "Juergen Quittek" <Quittek@nw.neclab.eu> wrote:

  
Dear all,

At our session on Monday there were three drafts presented
for which there was a consensus to accept them as working
group documents. Now we need confirmation on this list.

The drafts are

  - Export of Structured Data in IPFIXDear
    http://tools.ietf.org/html/draft-claise-structured-data-in-ipfix
  - IP Flow Anonymisation Support
    http://tools.ietf.org/html/draft-boschi-ipfix-anon
  - Flow Selection Techniques
    http://tools.ietf.org/html/draft-peluso-flowselection-tech

If you see any problem with adding these three items to the
IPFIX agenda, please make your point on this list within the
next two weeks.

Thanks,

    Juergen 


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

_______________________________________________
IPFIX mailing list
IPFIX@ietf.org
https://www.ietf.org/mailman/listinfo/ipfix
--------------050004070401010902050200-- From Quittek@nw.neclab.eu Fri Aug 28 05:42: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 20DAE28C376 for ; Fri, 28 Aug 2009 05:42:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.437 X-Spam-Level: X-Spam-Status: No, score=-2.437 tagged_above=-999 required=5 tests=[AWL=0.162, 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 4R6jviPidUi2 for ; Fri, 28 Aug 2009 05:42:10 -0700 (PDT) Received: from smtp0.neclab.eu (smtp0.neclab.eu [195.37.70.41]) by core3.amsl.com (Postfix) with ESMTP id 1037028C373 for ; Fri, 28 Aug 2009 05:42:10 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp0.neclab.eu (Postfix) with ESMTP id 5CAB72C0004DB; Fri, 28 Aug 2009 14:42: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 4POrN0dyoBIx; Fri, 28 Aug 2009 14:42:16 +0200 (CEST) Received: from VENUS.office (mx1.office [192.168.24.3]) by smtp0.neclab.eu (Postfix) with ESMTP id 226992C0012C3; Fri, 28 Aug 2009 14:41:56 +0200 (CEST) Received: from 10.7.0.54 ([10.7.0.54]) by VENUS.office ([192.168.24.102]) with Microsoft Exchange Server HTTP-DAV ; Fri, 28 Aug 2009 12:41:55 +0000 MIME-Version: 1.0 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-Type: multipart/signed; boundary="B_3334313253_4631688"; protocol="application/pkcs7-signature"; micalg=sha1 Content-class: urn:content-classes:message Date: Fri, 28 Aug 2009 14:41:55 +0200 Message-ID: X-MS-Has-Attach: yes X-MS-TNEF-Correlator: Thread-Topic: IPFIX re-chartering request Thread-Index: Acon2B+YWibFz1WBS0eXLAaP5MeKoA== From: "Juergen Quittek" To: "Dan Romascanu" , "Ronald Bonica" , Cc: IETF IPFIX Working Group Subject: [IPFIX] IPFIX re-chartering request 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, 28 Aug 2009 12:42:12 -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_3334313253_4631688 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Dear Dan and Ron, Three new work items for the IPFIX WG have been discussed at the IPFIX session in Stockholm and on the IPFIX mailing list: - Export of Structured Data in IPFIX http://tools.ietf.org/html/draft-claise-structured-data-in-ipfix - IP Flow Anonymisation Support http://tools.ietf.org/html/draft-boschi-ipfix-anon - Flow Selection Techniques http://tools.ietf.org/html/draft-peluso-flowselection-tech There was consensus at the session as well as on the mailing list to accept these items. This is a request to add the items to the IPFIX charter. At the same time, I would suggest removing items from the charter that correspond to achieved milestones. Please find the full set of suggested changes below. Thank you, Juergen remove completed items: OLD: 2. There is a need for storing measured flow information and for exchanging this information between different systems and organizations. The WG will develop a common IPFIX file format for storing flow data in order to facilitate interoperability and reusability among a wide variety of flow storage, processing, and analysis tools. It will be a flat-file format using binary encodings that are based on the IPFIX message format. 3. When dealing with enterprise-specific information elements in IPFIX flow records, it often occurs that the receiver of the record does not know the definition of the information element. For processing such information elements it would be desirable for the receiver to know at least the data types of the enterprise-specific information elements. The WG will develop an extension to IPFIX that provides means for the encoding of IPFIX data type information within an IPFIX Message stream. 4. Another requirement resulting from practical use of IPFIX is reporting IPFIX template records and corresponding data records within the same SCTP stream. The IPFIX WG will develop guidelines for this use case. re-number existing items: OLD: 5. First applications of IPFIX at large operator networks showed the NEW: 2. First applications of IPFIX at large operator networks showed the OLD: 6. The PSAMP WG has developed a protocol for reporting NEW: 3. The PSAMP WG has developed a protocol for reporting add new items: NEW: 4. Anonymization of flow information has been identified as a requirement for flow information export already in RFC 3917. However, technologies for flow anonymization are still a research issue and have so far not been considered to be mature enough for standardization. As one step in this direction, the IPFIX WG will develop guidelines for the implementation of anonymised data export and storage over IPFIX and define an information model for configuring and reporting anonymization applied at IPFIX devices. 5. The IPFIX and PSAMP WGs have defined standards for selecting observed IP packets and collecting information in flow records. In order to reduce the amount of data to be processed, packet selection methods have been defined. Another method for reducing flow data is flow selection. The IPFIX WG will define methods for flow selection and provide an information model for configuring and reporting flow selection applied at IPFIX devices. 6. Being designed for the export of flow records the IPFIX protocol provides very limited means for structuring information elements within IPFIX records. With the increasing number of IPFIX applications there is a need for exporting more complex information. The IPFIX WG will develop an extension of the IPFIX protocol that supports hierarchically structured data and lists (sequences) of Information Elements in data records. add new milestones: NEW: Oct 2009 Submit initial draft on anonymization support Oct 2009 Submit initial draft on flow selection Oct 2009 Submit initial draft on structuring information elements Jun 2010 Submit anonymization support I-D to IESG for publication as Experimental RFC Jun 2010 Submit flow selection I-D to IESG for publication as Standards Track RFC Jun 2010 Submit structuring information elements I-D to IESG for publication as Standards Track RFC update existing milestones: OLD: Jul 2009 Submit Mediation Problem Statement I-D to IESG for publication as Informational RFC Sep 2009 Submit Configuration Data Model draft to IESG for publication as Standards track RFC Sep 2009 Submit Mediation Framework I-D to IESG for publication as Informational RFC NEW: Oct 2009 Submit Mediation Problem Statement I-D to IESG for publication as Informational RFC Jan 2009 Submit Configuration Data Model draft to IESG for publication as Standards track RFC Jan 2009 Submit Mediation Framework I-D to IESG for publication as Informational RFC --B_3334313253_4631688 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 YWIuZXUCBA0uKwcwCQYFKw4DAhoFAKBdMCMGCSqGSIb3DQEJBDEWBBQKRvm4udJqrDaLO6qW zO+g+aFKhzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0wOTA4 MjgxMjA3MzNaMA0GCSqGSIb3DQEBAQUABIIBAEMDZ4Y9o+Rxzu4628YooV9KxJZ4eBnVc/7N vv5ENEDQkxXyXILoigB8cALlGKVolEXRJvImYFMaSTMRFfUeEAQGhdqhycwFacB7J8NrtpwO WyVfm+O3oxDDIvzekJIagXUc+sMji9ytoOObU7yrf1IfMCOAyMQ9Vls797G/HfD6RHSdB72m QNLEBmBfzLVWMsXsokyT6+I9U5ycqlRcSGnZPhvicraxOkJC2pzB8yl5smNbcx4LsjH2CMD/ oEhcjS0bABc0NtX1jTWGY2jAgYQXzuVAiRqislkdZjcq8XPfvz7u+/ZfEDqxpYE1NEpb0Tiu qSgnP7NmsXsTQ/+bf4I= --B_3334313253_4631688-- From Quittek@nw.neclab.eu Fri Aug 28 06:02: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 D60093A7124 for ; Fri, 28 Aug 2009 06:02:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.022 X-Spam-Level: X-Spam-Status: No, score=-2.022 tagged_above=-999 required=5 tests=[AWL=-0.293, BAYES_00=-2.599, SARE_MLH_Stock1=0.87] 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 W9PFX-coKRlS for ; Fri, 28 Aug 2009 06:02:14 -0700 (PDT) Received: from smtp0.neclab.eu (smtp0.neclab.eu [195.37.70.41]) by core3.amsl.com (Postfix) with ESMTP id D45E03A6DDF for ; Fri, 28 Aug 2009 06:02:13 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp0.neclab.eu (Postfix) with ESMTP id 680C12C00C524 for ; Fri, 28 Aug 2009 15:02:20 +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 3X1-q5Ctn-Co for ; Fri, 28 Aug 2009 15:02:20 +0200 (CEST) Received: from VENUS.office (mx1.office [192.168.24.3]) by smtp0.neclab.eu (Postfix) with ESMTP id 36CF82C0012C8 for ; Fri, 28 Aug 2009 15:02:15 +0200 (CEST) Received: from 10.7.0.54 ([10.7.0.54]) by VENUS.office ([192.168.24.102]) with Microsoft Exchange Server HTTP-DAV ; Fri, 28 Aug 2009 13:02:15 +0000 MIME-Version: 1.0 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-Type: multipart/signed; boundary="B_3334316533_4778669"; protocol="application/pkcs7-signature"; micalg=sha1 Content-class: urn:content-classes:message Date: Fri, 28 Aug 2009 15:02:13 +0200 Message-ID: X-MS-Has-Attach: yes X-MS-TNEF-Correlator: Thread-Topic: minutes of our session at IETF#75 in Stockholm Thread-Index: Acon38Kg5dl54DzcPUuOiBupalvmrQ== From: "Juergen Quittek" To: "IETF IPFIX Working Group" Subject: [IPFIX] minutes of our session at IETF#75 in Stockholm 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, 28 Aug 2009 13:02:14 -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_3334316533_4778669 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Dear all, Please find a draft of the minutes of our session at Stockholm at http://www.ietf.org/proceedings/75/minutes/ipfix.txt Please check them and send your comments to this list. Many thanks to Ralf Wolter for taking the minutes. Thanks, Juergen --B_3334316533_4778669 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 YWIuZXUCBA0uKwcwCQYFKw4DAhoFAKBdMCMGCSqGSIb3DQEJBDEWBBSc88HbiZdFybnSFd8+ GtJr+faqlDAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0wOTA4 MjgxMzAyMTNaMA0GCSqGSIb3DQEBAQUABIIBABYLx4+LAoKJSjamjQlllbJ7klRSVyLgOUhP 4WW/cv4ztEi6+2Qs6eFL2SUuaGz9z0NK1SYLtyHwMcNN2LKyAY25A3cNq8csikFEAGN5lajv WPOGIvXXDLoWh5C+fJ6IGz+PpXCXpgJPrTS8N3vOamwh8JpYQ5+1EVCTRx/6alNiYyk2e+EB 4odowVyjHqpC+MVZkvnuIPWAWdHDy+NcsMKLrE82CTck99/7OBqvj/7f6mK4o/Ie5d3BQ3tX cHW2UIV0qqvK+oyCMzozCnxl5OYFKQYOWnOtwK6c+XlYw6fqvZacgtO393Y8RKoYow06jQo+ w6X0UJqwGeHJ869fhG0= --B_3334316533_4778669-- From dromasca@avaya.com Mon Aug 31 07:15:34 2009 Return-Path: X-Original-To: ipfix@core3.amsl.com Delivered-To: ipfix@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5E6C628C289 for ; Mon, 31 Aug 2009 07:15:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.42 X-Spam-Level: X-Spam-Status: No, score=-2.42 tagged_above=-999 required=5 tests=[AWL=0.179, 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 4qjlBGtIik5U for ; Mon, 31 Aug 2009 07:15:33 -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 D86FB28C286 for ; Mon, 31 Aug 2009 07:15:32 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.44,305,1249272000"; d="scan'208";a="155437140" Received: from unknown (HELO co300216-co-erhwest.avaya.com) ([198.152.7.5]) by de307622-de-outbound.net.avaya.com with ESMTP; 31 Aug 2009 10:15:42 -0400 Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.16]) by co300216-co-erhwest-out.avaya.com with ESMTP; 31 Aug 2009 10:15:41 -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, 31 Aug 2009 16:15:19 +0200 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: IPFIX re-chartering request Thread-Index: Acon2B+YWibFz1WBS0eXLAaP5MeKoACbSjIA References: From: "Romascanu, Dan (Dan)" To: "Juergen Quittek" , "Ronald Bonica" , Cc: IETF IPFIX Working Group Subject: Re: [IPFIX] IPFIX re-chartering request 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, 31 Aug 2009 14:15:34 -0000 Juergen, These look fine to me.=20 Can you please generate a new charter text will all these changes so that I can distribute it for internal review by the IESG and IAB?=20 Thanks and Regards, Dan =20 > -----Original Message----- > From: Juergen Quittek [mailto:Quittek@nw.neclab.eu]=20 > Sent: Friday, August 28, 2009 3:42 PM > To: Romascanu, Dan (Dan); Ronald Bonica; ron@bonica.org > Cc: IETF IPFIX Working Group > Subject: IPFIX re-chartering request >=20 > Dear Dan and Ron, >=20 > Three new work items for the IPFIX WG have been discussed at=20 > the IPFIX session in Stockholm and on the IPFIX mailing list: >=20 > - Export of Structured Data in IPFIX > http://tools.ietf.org/html/draft-claise-structured-data-in-ipfix > - IP Flow Anonymisation Support > http://tools.ietf.org/html/draft-boschi-ipfix-anon > - Flow Selection Techniques > http://tools.ietf.org/html/draft-peluso-flowselection-tech >=20 > There was consensus at the session as well as on the mailing=20 > list to accept these items. >=20 > This is a request to add the items to the IPFIX charter. > At the same time, I would suggest removing items from the=20 > charter that correspond to achieved milestones. Please find=20 > the full set of suggested changes below. >=20 > Thank you, >=20 > Juergen >=20 >=20 > remove completed items: > OLD: > 2. There is a need for storing measured flow information and for > exchanging this information between different systems and > organizations. The WG will develop a common IPFIX file format for > storing flow data in order to facilitate interoperability and > reusability among a wide variety of flow storage, processing, and > analysis tools. It will be a flat-file format using binary=20 > encodings > that are based on the IPFIX message format. >=20 > 3. When dealing with enterprise-specific information=20 > elements in IPFIX > flow records, it often occurs that the receiver of the=20 > record does not > know the definition of the information element. For processing such > information elements it would be desirable for the=20 > receiver to know at > least the data types of the enterprise-specific=20 > information elements. > The WG will develop an extension to IPFIX that provides=20 > means for the > encoding of IPFIX data type information within an IPFIX Message > stream. >=20 > 4. Another requirement resulting from practical use of IPFIX is > reporting IPFIX template records and corresponding data=20 > records within > the same SCTP stream. The IPFIX WG will develop guidelines for this > use case. >=20 >=20 > re-number existing items: > OLD: > 5. First applications of IPFIX at large operator networks=20 > showed the > NEW: > 2. First applications of IPFIX at large operator networks=20 > showed the >=20 > OLD: > 6. The PSAMP WG has developed a protocol for reporting > NEW: > 3. The PSAMP WG has developed a protocol for reporting >=20 >=20 > add new items: > NEW: > 4. Anonymization of flow information has been identified as a > requirement for flow information export already in RFC=20 > 3917. However, > technologies for flow anonymization are still a research=20 > issue and have > so far not been considered to be mature enough for standardization. > As one step in this direction, the IPFIX WG will develop=20 > guidelines for > the implementation of anonymised data export and storage over IPFIX > and define an information model for configuring and reporting > anonymization applied at IPFIX devices. >=20 > 5. The IPFIX and PSAMP WGs have defined standards for selecting > observed IP packets and collecting information in flow records. > In order to reduce the amount of data to be processed,=20 > packet selection > methods have been defined. Another method for reducing flow data is > flow selection. The IPFIX WG will define methods for flow=20 > selection and > provide an information model for configuring and reporting=20 > flow selection > applied at IPFIX devices. >=20 > 6. Being designed for the export of flow records the IPFIX protocol > provides very limited means for structuring information=20 > elements within > IPFIX records. With the increasing number of IPFIX=20 > applications there is > a need for exporting more complex information. The IPFIX=20 > WG will develop > an extension of the IPFIX protocol that supports hierarchically > structured data and lists (sequences) of Information=20 > Elements in data > records. =20 >=20 >=20 > add new milestones: > NEW: > Oct 2009 Submit initial draft on anonymization support > Oct 2009 Submit initial draft on flow selection > Oct 2009 Submit initial draft on structuring information elements > Jun 2010 Submit anonymization support I-D to IESG for publication > as Experimental RFC > Jun 2010 Submit flow selection I-D to IESG for publication > as Standards Track RFC > Jun 2010 Submit structuring information elements I-D to IESG > for publication as Standards Track RFC >=20 >=20 > update existing milestones: > OLD: > Jul 2009 Submit Mediation Problem Statement I-D to IESG > for publication as Informational RFC > Sep 2009 Submit Configuration Data Model draft to IESG > for publication as Standards track RFC > Sep 2009 Submit Mediation Framework I-D to IESG > for publication as Informational RFC > NEW: > Oct 2009 Submit Mediation Problem Statement I-D to IESG > for publication as Informational RFC > Jan 2009 Submit Configuration Data Model draft to IESG > for publication as Standards track RFC > Jan 2009 Submit Mediation Framework I-D to IESG > for publication as Informational RFC >=20 > =20 >=20