From lorenzo.peluso@unina.it Tue Jun 1 11:27:57 2010 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 583DA3A6860 for ; Tue, 1 Jun 2010 11:27:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 3.88 X-Spam-Level: *** X-Spam-Status: No, score=3.88 tagged_above=-999 required=5 tests=[BAYES_80=2, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245] 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 6uPPARu6OywP for ; Tue, 1 Jun 2010 11:27:56 -0700 (PDT) Received: from webmail.unina.it (webmail.unina.it [192.132.34.212]) by core3.amsl.com (Postfix) with ESMTP id 006873A6359 for ; Tue, 1 Jun 2010 11:27:53 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by webmail.unina.it (8.14.0/8.14.0) with ESMTP id o51IRcvR025457; Tue, 1 Jun 2010 20:27:39 +0200 Received: from host250-144-dynamic.232-95-r.retail.telecomitalia.it (host250-144-dynamic.232-95-r.retail.telecomitalia.it [95.232.144.250]) by webmail.unina.it (Horde MIME library) with HTTP; Tue, 01 Jun 2010 20:27:38 +0200 Message-ID: <20100601202738.c5vuosda844ogss4@webmail.unina.it> Date: Tue, 01 Jun 2010 20:27:38 +0200 From: lorenzo.peluso@unina.it To: ipfix@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; DelSp="Yes"; format="flowed" Content-Disposition: inline Content-Transfer-Encoding: 7bit User-Agent: Internet Messaging Program (IMP) H3 (4.1.6) X-Virus-Scanned: ClamAV 0.94.2/9751/Thu Aug 27 19:08:53 2009 on webmail.unina.it X-Virus-Status: Clean Subject: [IPFIX] Flow selection draft update 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, 01 Jun 2010 18:30:20 -0000 Dear IPFIXers, I uploaded a new version of the Internet Draft on flow selection techniques. According to the feedback received during the last meeting the structure of the document has been modified and the use of flow selection as a function of the mediation framework has been addressed. I kindly ask you to provide us with your feedback in order to get to the final version of the ID we plan to present at the next meeting in Maastricht. Thanks a lot in advance. Best regards Lorenzo. From root@core3.amsl.com Tue Jun 1 13:15:09 2010 Return-Path: X-Original-To: ipfix@ietf.org Delivered-To: ipfix@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id D5F8D3A6ADA; Tue, 1 Jun 2010 13:15:08 -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: <20100601201508.D5F8D3A6ADA@core3.amsl.com> Date: Tue, 1 Jun 2010 13:15:08 -0700 (PDT) Cc: ipfix@ietf.org Subject: [IPFIX] I-D ACTION:draft-ietf-ipfix-export-per-sctp-stream-08.txt X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Jun 2010 20:15:09 -0000 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IP Flow Information Export Working Group of the IETF. Title : IPFIX Export per SCTP Stream Author(s) : B. Claise, P. Aitken, A. Johnson, G. Muenz Filename : draft-ietf-ipfix-export-per-sctp-stream-08.txt Pages : 23 Date : 2010-5-31 This document specifies an extension to the specifications in RFC5101, IP Flow Information Export (IPFIX), when using the Partial Reliability extension of SCTP (PR-SCTP, Partial Reliability Stream Control Transmission Protocol). When implemented at both the Exporting and Collecting Processes, this method offers several advantages such as the ability to calculate Data Record losses for PR-SCTP, immediate export of Template Withdrawal Messages, immediate reuse of Template IDs within an SCTP stream, reduced likelihood of Data Record loss, and reduced demands on the Collecting Process. When implemented in only the Collecting or Exporting Process then normal IPFIX behavior will be seen without these additional benefits. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ipfix-export-per-sctp-stream-08.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-export-per-sctp-stream-08.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2010-6-1130617.I-D@ietf.org> --NextPart-- From root@core3.amsl.com Tue Jun 1 13:30:07 2010 Return-Path: X-Original-To: ipfix@ietf.org Delivered-To: ipfix@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id 2C41D28C102; Tue, 1 Jun 2010 13:30:06 -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: <20100601203007.2C41D28C102@core3.amsl.com> Date: Tue, 1 Jun 2010 13:30:06 -0700 (PDT) Cc: ipfix@ietf.org Subject: [IPFIX] I-D ACTION:draft-ietf-ipfix-flow-selection-tech-02.txt X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Jun 2010 20:30:07 -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 : Flow Selection Techniques Author(s) : L. Peluso, S. D'Antonio, T. Zseby, M. Molina Filename : draft-ietf-ipfix-flow-selection-tech-02.txt Pages : 25 Date : 2010-6-1 Flow selection is the process of selecting a subset of flows from all flows observed at an observation point. The objective of flow selection is to reduce the effort for post-processing flow data and for transferring flow records. The flow selection process can be enabled at different stages of the measurement process. It can be applied directly after classification or at recording/exporting time by limiting the number of flows to be stored and/or exported to the collecting process. This document describes motivations for flow selection and presents flow selection techniques. It furthermore provides an information model for configuring flow selection techniques and discusses what information about a flow selection process is beneficial to be exported by adopting a suitable information model. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ipfix-flow-selection-tech-02.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-flow-selection-tech-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2010-6-1131557.I-D@ietf.org> --NextPart-- From n.brownlee@auckland.ac.nz Thu Jun 3 14:40:47 2010 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 6A1103A6A4D for ; Thu, 3 Jun 2010 14:40:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.999 X-Spam-Level: X-Spam-Status: No, score=-5.999 tagged_above=-999 required=5 tests=[AWL=2.000, BAYES_50=0.001, GB_I_INVITATION=-2, GB_I_LETTER=-2, 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 OxdH-JPm12VG for ; Thu, 3 Jun 2010 14:40:45 -0700 (PDT) Received: from mailhost.auckland.ac.nz (curly.its.auckland.ac.nz [130.216.12.36]) by core3.amsl.com (Postfix) with ESMTP id 0E60F3A6A4C for ; Thu, 3 Jun 2010 14:40:40 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by mailhost.auckland.ac.nz (Postfix) with ESMTP id BFDE69CAC8 for ; Fri, 4 Jun 2010 09:40:17 +1200 (NZST) X-Virus-Scanned: by amavisd-new at mailhost.auckland.ac.nz Received: from mailhost.auckland.ac.nz ([127.0.0.1]) by localhost (curly.its.auckland.ac.nz [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dk3fYTG7qltW for ; Fri, 4 Jun 2010 09:40:17 +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 937229CA81 for ; Fri, 4 Jun 2010 09:40:17 +1200 (NZST) Message-ID: <4C08213D.8050509@auckland.ac.nz> Date: Fri, 04 Jun 2010 09:40:13 +1200 From: Nevil Brownlee User-Agent: Thunderbird 2.0.0.12 (Macintosh/20080213) MIME-Version: 1.0 To: IPFIX Working Group Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Subject: [IPFIX] [Fwd: IETF 78 - Meeting and Sponsorship Information] X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Jun 2010 21:40:47 -0000 -------- Original Message -------- Subject: IETF 78 - Meeting and Sponsorship Information Date: Fri, 4 Jun 2010 07:51:40 +1200 From: IETF Secretariat To: Working Group Chairs Working Group Chairs, Can you please forward this message to your individual working group emails lists. We want to ensure that as many people as possible are aware of the sponsorship opportunities available at IETF meetings. Thank you. ========================================== 78th IETF Meeting Maastricht, Netherlands July 25-30, 2010 1. Sponsorship Opportunities 2. Registration Types 3. Visas and Letters of Invitation 4. Accommodations & Breakfast Information 5. IETF 79 (Beijing) Visa Information 1) Sponsorship Opportunities There are still sponsorship opportunities and benefits for high profile company/organizational exposure at the upcoming IETF meeting in Maastricht, Netherlands from July 25-30, 2010. All sponsorship fees go directly to fund the operations of the IETF. See the options at: http://www.ietf.org/meeting/78/index.html �Sponsorship Opportunities� under �General�. Each of the sponsorship options provide extended and repeat exposure at this weeklong meeting. Please contact Drew Dvorshak, dvorshak@isoc.org, with any questions and/or to reserve your organization�s spot. Thanks in advance for supporting the critical work of the IETF! 2) Register online at: http://www.ietf.org/meetings/78/ 3) Letters of Invitation and Visas Letters of Invitation After you complete the meeting registration process, you will be given the option to request a letter of invitation. You can request the Letter of Invitation as soon as you finish registration, or at a later time by following the link provided in the confirmation email. Visas Please check the Netherlands Ministry of Foreign Affairs site (http://www.minbuza.nl/en/Services/Consular_Services/Visa) for list of countries with visa exemptions. We recommend you give yourself at least one month to complete the visa process. 4) Accommodations & Breakfast Information http://www.ietf.org/meeting/78/hotel.html 5) If you want to start planning for your trip to IETF 79 in Beijing, we have visa information online here: http://www.ietf.org/meeting/79/visa.html Only 52 days until IETF 78! -- --------------------------------------------------------------------- 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 paitken@cisco.com Fri Jun 4 01:26:15 2010 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 3F62C3A67EB for ; Fri, 4 Jun 2010 01:26:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.999 X-Spam-Level: X-Spam-Status: No, score=-7.999 tagged_above=-999 required=5 tests=[BAYES_50=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 15nrgvTvd4Kk for ; Fri, 4 Jun 2010 01:26:13 -0700 (PDT) Received: from rtp-iport-2.cisco.com (rtp-iport-2.cisco.com [64.102.122.149]) by core3.amsl.com (Postfix) with ESMTP id 08AA33A688B for ; Fri, 4 Jun 2010 01:26:12 -0700 (PDT) Authentication-Results: rtp-iport-2.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AkcFAIdUCExAZnwN/2dsb2JhbACeQGsGpCiaDYUXBA X-IronPort-AV: E=Sophos;i="4.53,360,1272844800"; d="scan'208";a="118017992" Received: from rtp-core-2.cisco.com ([64.102.124.13]) by rtp-iport-2.cisco.com with ESMTP; 04 Jun 2010 08:25:58 +0000 Received: from cisco.com (mrwint.cisco.com [64.103.71.48]) by rtp-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id o548PwKt029254 for ; Fri, 4 Jun 2010 08:25:58 GMT Received: from [10.61.100.41] (dhcp-10-61-100-41.cisco.com [10.61.100.41]) by cisco.com (8.11.7p3+Sun/8.8.8) with ESMTP id o548Pu625772 for ; Fri, 4 Jun 2010 09:25:57 +0100 (BST) Message-ID: <4C08B894.2060000@cisco.com> Date: Fri, 04 Jun 2010 09:25:56 +0100 From: Paul Aitken User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-GB; rv:1.8.1.22) Gecko/20090605 SeaMonkey/1.1.17 (Ubuntu-1.1.17+nobinonly-0ubuntu0.9.04.1) MIME-Version: 1.0 To: "ipfix@ietf.org" Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [IPFIX] IPv6 mobility header added to ipv6ExtensionHeaders X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Jun 2010 08:26:15 -0000 Dear all, The RFC 3775 IPv6 mobility header has been added to IE #64, ipv6ExtensionHeaders: -------- Original Message -------- From: Amanda Baber via RT To: paitken@cisco.com Subject: [IANA #331692] General Request for Assignments (ipfix) Date: Fri, 4 Jun 2010 00:51:06 +0000 Hi Paul, This update is complete. Please see http://www.iana.org/assignments/ipfix/ipfix.xhtml Best regards, Amanda Baber IANA On Tue Jun 01 12:56:28 2010, paitken@cisco.com wrote: > Contact Name : > Paul Aitken > > Contact Email : > paitken@cisco.com > > Type of Assignment : > IPFIX Information Elements > > Registry : > IPFIX Information Elements > > http://www.iana.org/assignments/ipfix/ipfix.xhtml > > Description : > Request that Information Element #64 (ipv6ExtensionHeaders) be > extended to include a bit for the IPv6 mobility header per RFC 3775: > > 8 9 10 11 12 13 14 15 > +-----+-----+-----+-----+-----+-----+-----+-----+ > ... | Reserved | MOB | ESP | AH | PAY | ... > +-----+-----+-----+-----+-----+-----+-----+-----+ > > Bit IPv6 Option Description > > 12, MOB 135 IPv6 mobility (RFC 3775). > > > Additional Info : > RFC 5102, RFC 3775. -- Paul Aitken Cisco Systems, Edinburgh, Scotland. From wwwrun@core3.amsl.com Mon Jun 7 10:20:17 2010 Return-Path: X-Original-To: ipfix@ietf.org Delivered-To: ipfix@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 30) id 00C893A6E9E; Mon, 7 Jun 2010 10:20:16 -0700 (PDT) X-idtracker: yes From: The IESG To: IETF-Announce Message-Id: <20100607172017.00C893A6E9E@core3.amsl.com> Date: Mon, 7 Jun 2010 10:20:16 -0700 (PDT) Cc: Internet Architecture Board , ipfix chair , ipfix mailing list , RFC Editor Subject: [IPFIX] Document Action: 'IPFIX Mediation: Problem Statement' to Informational RFC 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, 07 Jun 2010 17:20:17 -0000 The IESG has approved the following document: - 'IPFIX Mediation: Problem Statement ' as an Informational RFC 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-mediators-problem-statement-09.txt Technical Summary This document specifies an improvement to the PR-SCTP export specified in the IPFIX specifications in RFC5101. This method offers several advantages such as the ability to calculate Data Record losses for PR-SCTP, immediate export of Template Withdrawal Messages, immediate reuse of Template IDs within an SCTP stream, and reduced demands on the Collecting Process. Working Group Summary Flow-based measurement is a popular method for various network monitoring usages. The sharing of flow-based information for monitoring applications having different requirements raises some open issues in terms of measurement system scalability, flow-based measurement flexibility, and export reliability that IPFIX Mediation may help resolve. This document describes some problems related to flow-based measurement that network administrators have been facing, and then describes IPFIX Mediation applicability examples along with the problems. The WG reached consensus for publication. Document Quality The document underwent two WG last call in the IPFIX WG. Personnel Juergen Quittek is shepherding this document. Dan Romascanu is the responsible Area director. From wwwrun@core3.amsl.com Tue Jun 8 07:45:36 2010 Return-Path: X-Original-To: ipfix@ietf.org Delivered-To: ipfix@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 30) id 447E728C1DE; Tue, 8 Jun 2010 07:45:35 -0700 (PDT) X-idtracker: yes From: The IESG To: IETF-Announce Message-Id: <20100608144536.447E728C1DE@core3.amsl.com> Date: Tue, 8 Jun 2010 07:45:36 -0700 (PDT) Cc: Internet Architecture Board , ipfix chair , ipfix mailing list , RFC Editor Subject: [IPFIX] CORRECTED Document Action: 'IPFIX Mediation: Problem Statement' X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Jun 2010 14:45:36 -0000 to Informational RFC The IESG has approved the following document: - 'IPFIX Mediation: Problem Statement ' as an Informational RFC 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-mediators-problem-statement-09.txt Technical Summary Flow-based measurement is a popular method for various network monitoring usages. The sharing of flow-based information for monitoring applications having different requirements raises some open issues in terms of measurement system scalability, flow-based measurement flexibility, and export reliability that IPFIX Mediation may help resolve. This document describes some problems related to flow-based measurement that network administrators have been facing, and then describes IPFIX Mediation applicability examples along with the problems. Working Group Summary Flow-based measurement is a popular method for various network monitoring usages. The sharing of flow-based information for monitoring applications having different requirements raises some open issues in terms of measurement system scalability, flow-based measurement flexibility, and export reliability that IPFIX Mediation may help resolve. This document describes some problems related to flow-based measurement that network administrators have been facing, and then describes IPFIX Mediation applicability examples along with the problems. The WG reached consensus for publication. Document Quality The document underwent two WG last calls in the IPFIX WG. Personnel Juergen Quittek is shepherding this document. Dan Romascanu is the responsible Area director. From akoba@nttv6.net Fri Jun 11 01:08:00 2010 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 A073C3A67F5 for ; Fri, 11 Jun 2010 01:08:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 3.811 X-Spam-Level: *** X-Spam-Status: No, score=3.811 tagged_above=-999 required=5 tests=[BAYES_50=0.001, HOST_MISMATCH_COM=0.311, J_CHICKENPOX_24=0.6, RDNS_DYNAMIC=0.1, SUBJ_RE_NUM=2.799] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LEImJ0Zp2BRH for ; Fri, 11 Jun 2010 01:07:59 -0700 (PDT) Received: from mail.nttv6.net (mail.nttv6.net [IPv6:2001:fa8::25]) by core3.amsl.com (Postfix) with ESMTP id C09933A677D for ; Fri, 11 Jun 2010 01:07:57 -0700 (PDT) Received: from [127.0.0.1] (dhcp-3-152.nttv6.com [192.47.163.152]) by mail.nttv6.net (8.14.4/8.14.3) with ESMTP id o5B87uCx049464; Fri, 11 Jun 2010 17:07:58 +0900 (JST) (envelope-from akoba@nttv6.net) Date: Fri, 11 Jun 2010 16:59:22 +0900 From: Atsushi Kobayashi To: Christoph Sommer In-Reply-To: <4BFFEB83.4060006@informatik.uni-erlangen.de> References: <20100526122347.8209.17391CF2@nttv6.net> <4BFFEB83.4060006@informatik.uni-erlangen.de> Message-Id: <20100611151542.9968.17391CF2@nttv6.net> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Becky! ver. 2.50.05 [ja] (Unregistered) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.3 (mail.nttv6.net [192.16.178.5]); Fri, 11 Jun 2010 17:07:58 +0900 (JST) Cc: IETF IPFIX Working Group Subject: Re: [IPFIX] WG last call on draft-ietf-ipfix-mediators-framework-06 X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Jun 2010 08:08:00 -0000 Hi Christoph, Thank you for your feedback. Sorry for late reply. Please see in-line as usual. On Fri, 28 May 2010 12:12:51 -0400 Christoph Sommer wrote: > Dear all, > > Atsushi Kobayashi wrote: > > Could you please read the framework draft and put your feedbacks in ipfix mailing list. > > I really like how the current draft spells out very clearly what IPFIX > Mediation is (the manipulation of a record stream) and how this is > achieved (via Intermediate Processes)! > > What worries me a bit, however, is that after reading the draft I don't > have a solid grasp on just what an IPFIX Mediator is and where > Intermediate Processes can be used. > > Is an IPFIX Mediator a device that *does* IPFIX Mediation? > > Is an IPFIX Mediator a device that *can do* IPFIX Mediation? > > More generally, is an IPFIX Mediator *required* to host: > - a Collecting Process? > - an Intermediate Process? > - an Exporting Process? > > What is the relationship of an IPFIX Mediator and an IPFIX > Collector/Exporter? > > Or, even more generally -- with "C", "I", and "E" being one or more > (active) Collecting, Intermediate, and Exporting Processes, respectively > -- which of the following are IPFIX Mediators, IPFIX Collectors and/or > IPFIX Exporters: > > || > > |C| > > |I| > > |E| > > |CI| > > |IE| > > |CIE| > > > Lastly, here are some random thoughts I had while reading the draft: > > - Figure A and Figure I are conflicting. It seems like most of the > document outright forbids running an Intermediate Process on anything > other than a Mediator or Exporter, yet Figure I shows a device that does > just that. > This document does not intend to forbid an Intermediate process is hosted in devices other than collector and exporter. Simply, although Collector can host an Intermediate process, it does not export any data to other devices. It is out of scope of this document, because Collector does not have something to use IPFIX Protocol. Figure I shows the relation between an Intermediate process and IPFIX File Writer, which operates as an Exporting Process according to RFC5655. In that case, the device hosts CP, IP, and specifc EP(File Writer); exports data to File system using IPFIX protocol. Thus, the document covers the condition. Is it OK? > - Figure A labels the devices "Collector 1 .. N", "Exporter 1 .. N", and > "Source 1 .. N". However, Mediators are labeled "Mediator 1 .. N and M > .. Z". > Ok, I will improve them to "Mediator 1 .. N". > - Figure B does not seem to allow the Intermediate Process to receive > data from sources other than the Collecting Process. > Other cases are allowed in Figure C-E. Figure B shows typical case. > - I didn't understand what Section 7, Paragraph "Sequence Number" means. I mean: Even if an IPFIX Mediator relays a one-to-one Transport Session, relays incoming IPFIX messages, and operates only message level, the IPFIX Mediator needs to handle the Sequence Number properly. When the incoming session shuts down and re-starts, the sequence number in outgoing session is not allowed to be initialized. Is it OK? > > - Section 9, Paragraph "Certification" states that all Mediators are > *recommended* to export an additional x.509 certificate, but in certain > cases do not *need* to. Also, I think it might be worthwhile to state > the reason for this recommendation and the exception more clearly. > In the case where an IPFIX Mediator acts as the proxy of Exporter, it does not need to export an additional x.509 certificate. And I will replace *recommended* with *may*. In this section, Brian suggested entire descriptions, as follows. I will improve according to it. Thank you, Brian. In Section 9.3, your question about exporting "Certification" is described. 9. Security Considerations As they act as both IPFIX Collecting Processes and Exporting Processes, the Security Considerations for IPFIX [RFC5101] apply as well to Mediators. The Security Considerations for IPFIX Files [RFC5655] apply as well to IPFIX Mediators that write IPFIX Files or use them for internal storage. However, there are a few specific considerations that IPFIX Mediator implementations must take into account in addition. By design, IPFIX Mediators are "men-in-the-middle": they intercede in the communication between an Original Exporter (or another upstream Mediator) and a downstream Collecting Process. TLS provides no way to connect the session between the Mediator and the Original Exporter to the session between the Mediator and the downstream Collecting Process; indeed, this is by design. This has important implications for the level of confidentiality provided across an IPFIX Mediator, and the ability to protect data integrity and Original Exporter authenticity across a Mediator. In general, a Mediator SHOULD maintain the same level of integrity and confidentiality protection on both sides of the mediation operation, except in situations where the Mediator is explicitly deployed as a gateway between trusted and untrusted networks. Subsequent subsections deal with specific security issues raised by mediation. 9.1. Avoiding Security Level Downgrade An IPFIX Mediator that accepts IPFIX Messages over a Transport Session protected by TLS or DTLS, and which then exports IPFIX Messages derived therefrom in cleartext, is a potentially serious vulnerability in an IPFIX infrastructure. An IPFIX Mediator MAY export records derived from protected records in cleartext, but only in the case that it acts as a proxy between an external (untrusted) network and an internal (trusted) network, when the path to the downstream collector is on a physically protected, separated network (e.g., in the same locked equipment rack) such that the additional overhead of a TLS session is unnecessary. In other words, an IPFIX Mediator that receives IPFIX Messages from an upstream Exporting Process protected using TLS or DTLS MUST provide for sending of IPFIX Messages resulting from the operation of the Intermediate Process(es) to a downstream Collecting Process using TLS or DTLS. It MAY allow for the configuration of unprotected export of such IPFIX Messages, but in this case it MUST warn the administrator that the exported IPFIX Messages will not be protected, and that this could result in the leakage of information deemed by the Original Exporter to be worth protecting. 9.2. Avoiding Security Level Downgrade There is a similar problem in the opposite direction: as an IPFIX Mediator's signature on a TLS session to a downstream Collecting Process acts as an implicit assertion of the trustworthiness of the data within the session, a poorly deployed IPFIX Mediator could be used to "legitimize" records derived from untrusted sources. Unprotected sessions from the Original Exporter are in the general case untrusted, because they could have been tampered with or forged by an unauthorized third party. An IPFIX Mediator MAY export signed Messgaes containing records derived from records received in cleartext, but only in the case that it acts as a proxy between an internal (trusted) and an external (untrusted) network, when the path from the Original Exporter is on a physically protected, separated network, such that the additional overhead of an TLS session is unnecessary. In other words, an IPFIX Mediator that receives IPFIX Messages from an upstream Exporting Process in cleartext MUST default to sending IPFIX Messages resulting from the operation of the Intermediate Process(es) to the downstream Collecting Process in cleartext. It SHOULD allow for the configuration of export of such IPFIX Messages protected by TLS or DTLS, but in this case it MUST warn the administrator that the exported IPFIX Messages will be signed as trusted by the Mediator, and that this could result in downstream Collecting Process trusting data derived from unprotected sources. 9.3. Approximating End-to-End Assertions for Mediators Because the Transport Session between an IPFIX Mediator and an Original Exporter is independent from the Transport Session between the Mediator and the downstream Collecting Process, there exists no method via TLS to assert the identity of the original Exporting Process downstream. However, an IPFIX Mediator, which modifies the stream of IPFIX Messages sent to it, is by definition a trusted entity in the infrastructure. Therefore, the IPFIX Mediator's signature on an outgoing Transport Session can be treated as an implicit assertion that the Original Exporter was positively identified by the Mediator and that the source information it received was trustworthy. However, IPFIX Mediators must in this circumstance take care not to provide an inappropriate upgrade of trust. Therefore, an IPFIX Mediator SHOULD NOT sign a Transport Session to a downstream Collector unless ALL the Original Exporters from which the information to be exported is derived were positively identified by the Mediator by its certificate. An exception to this case is the reverse of the special case in the previous subsection: an IPFIX Mediator that accepts information from within a trusted domain via an internal network protected by other means MAY use TLS or DTLS to protect the Transport Session to a downstream Collector outside the domain. If the X.509 certificates used to protect a Transport Session between an Original Exporter and an IPFIX Mediator are required downstream, an IPFIX Mediator MAY use the exporterCertificate and the collectorCertificate Information Elements with the Export Session Details Options Template defined in Section 8.1.3 of [RFC5655] or the Message Details Options Template defined in Section 8.1.4 of [RFC5655] in order to export this information downstream. However, in this case, the IPFIX Mediator is making an implicit assertion that the upstream Session was properly protected and therefore trustworthy, and as such MUST protect the Transport Session to the downstream Collector using TLS or DTLS, as well. 9.4. Multiple Tenancy An IPFIX Mediator handling traffic data from multiple separate sources or for multiple separate purposes MUST provide for keeping these data separate. Though the details of this are application- specific, this generally entails separating Transport Sessions within the Mediator, and associating them with information related to the source or purpose, e.g., network or hardware address range, virtual LAN tag, interface identifiers, and so on. Information from multiple sources MAY only be combined within a Mediator when that Mediator is applied for that specific purpose (e.g., aggregation or concentration of records). 9.5. Configuration Protection Due to their trusted position within the infrastructure, Mediators MUST provide for the protection of their configuration information, requiring positive authentication and authorization of administrators for configuration tasks. > All in all, I'm very happy with the draft and excited to see how, after > five years, it now smoothly integrates all of our different ideas on > correlation, aggregation, and anonymization. Thanks for all your hard work! > Thank you very much. I appreciate your contribution. Regards, Atsushi > > Best regards, > > Christoph > > -- > Christoph Sommer > Dept. of Electrical and Computer Eng. > Carnegie Mellon University, Pittsburgh, PA > Phone: +1 412 268-4212 / Fax: +1 412 268-2860 > http://www.andrew.cmu.edu/~csommer/ > _______________________________________________ > IPFIX mailing list > IPFIX@ietf.org > https://www.ietf.org/mailman/listinfo/ipfix > --- Atsushi KOBAYASHI NTT Information Sharing Platform Lab. tel:+81-(0)422-59-3978 fax:+81-(0)422-59-5637 From n.brownlee@auckland.ac.nz Tue Jun 22 13:06:57 2010 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 273F63A69D9 for ; Tue, 22 Jun 2010 13:06:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.299 X-Spam-Level: X-Spam-Status: No, score=-5.299 tagged_above=-999 required=5 tests=[AWL=1.300, 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 PC8xCPQIh6I5 for ; Tue, 22 Jun 2010 13:06:55 -0700 (PDT) Received: from mailhost.auckland.ac.nz (curly.its.auckland.ac.nz [130.216.12.36]) by core3.amsl.com (Postfix) with ESMTP id 8C2BE3A69D2 for ; Tue, 22 Jun 2010 13:06:55 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by mailhost.auckland.ac.nz (Postfix) with ESMTP id 5387C9CD0C for ; Wed, 23 Jun 2010 08:06:50 +1200 (NZST) X-Virus-Scanned: by amavisd-new at mailhost.auckland.ac.nz Received: from mailhost.auckland.ac.nz ([127.0.0.1]) by localhost (curly.its.auckland.ac.nz [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Hy7wtj6NEajm for ; Wed, 23 Jun 2010 08:06:50 +1200 (NZST) Received: from [192.168.0.6] (121-98-151-149.bitstream.orcon.net.nz [121.98.151.149]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailhost.auckland.ac.nz (Postfix) with ESMTP id DFB199CB20 for ; Wed, 23 Jun 2010 08:06:45 +1200 (NZST) Message-ID: <4C2117D1.9010601@auckland.ac.nz> Date: Tue, 22 Jun 2010 13:06:41 -0700 From: Nevil Brownlee User-Agent: Thunderbird 2.0.0.24 (X11/20100411) MIME-Version: 1.0 To: IPFIX list Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [IPFIX] [Fwd: FW: Nomcom 2010-2011: Second Call for Volunteers] 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, 22 Jun 2010 20:06:57 -0000 -------- Original Message -------- Subject: FW: Nomcom 2010-2011: Second Call for Volunteers Date: Tue, 22 Jun 2010 19:30:14 +1200 From: Romascanu, Dan (Dan) To: ops-chairs@ietf.org OPS Area Chairs, Please forward this message to your WG mail lists. Participation in the Nomcom process is an opportunity for any IETF participant to support the IETF and influence its future by selecting the next generation of IETF leaders and by receiving and processing the inputs of the community about the IETF work and processes. Regards, Dan -----Original Message----- From: ietf-announce-bounces@ietf.org [mailto:ietf-announce-bounces@ietf.org] On Behalf Of NomCom Chair Sent: Tuesday, June 22, 2010 12:49 AM To: IETF Announcement list Subject: Nomcom 2010-2011: Second Call for Volunteers Hi all, This is the Second call for Volunteers for the 2010-11 nomcom. We are just about halfway through the volunteer period so if you are considering volunteering please do so very soon. I am pleased to report that we have 29 volunteers thus far whose qualifications have been confirmed by the secretariat. I have notified each of these volunteers by email. If you volunteered before 08:00 PDT (15:00 UTC) on June 21 to serve as a voting member and have not received a confirmation email from me, please re-submit and bring to my attention right away! However, we need many more volunteers. You have until 17:00 PDT (24:00 UTC) on July 8, 2010 to volunteer for nomcom but it is much better if you volunteer as early as possible. The more volunteers, the better chance we have of choosing a random yet representative cross section of the IETF pouplation. As a reminder, volunteers must have attended 3 of the past 5 IETF meetings - per RFC 3777, which means 3 of the following meetings: IETF-73, IETF-74, IETF-75, IETF-76 and IETF-77. If you qualify, and are willing to forgo appointment to any of the positions for which the nominating committee is responsible, please volunteer. The 10 nominating committee members are selected randomly from a pool of volunteers. The details of the operation of nomcom may be found in RFC 3777. The process on how to volunteer for nomcom is in the initial announcement: https://datatracker.ietf.org/ann/nomcom/2330/ The lists of open positions and people whose terms end in March 2011 and thus the positions for which the nominating committee is responsible are summarized in the initial announcement: https://datatracker.ietf.org/ann/nomcom/2330/ The 29 volunteers who have thus far been qualified by the secretariat are: Fred Baker, Cisco Systems Stephan Wenger, Vidyo, Inc. Marc Blanchet, Viagenie Lixia Zhang, UCLA John Drake, Juniper Networks Ole Troan, Cisco Jiankang Yao, CNNIC Wassim Haddad, Ericsson Yi Zhao, Huawei USA Teemu Savolainen, Nokia Jouni Korhonen, Nokia Siemens Networks Mehmet Ersue, Nokia Siemens Networks Christian Schmidt, Nokia Siemens Networks Stephen Hanna, Juniper Networks Suresh Krishnan, Ericsson Eric Gray, Ericsson David Sinicrope, Ericsson Jan Melen, Ericsson Richard Barnes, BBN Technologies Hugo Salgado Hernandez, NIC Chile Ning Zong, Huawei Technologies Qin Wu, Huawei Technologies Karen Seo, BBN Technologies Haibin Song, Huawei Technologies Susan Hares, Huawei Technologies Tony Hansen. AT&T Labs Fuqing Huang, Huawei Technologies Co., Ltd. Huub van Helvoort, Huawei Technologies Miya Kohno, Juniper Networks The primary activity for this nomcom will begin just prior to IETF-78 in Maastricht and should be completed in early January 2011. The nomcom will be collecting requirements from the community, as well as talking to candidates and to community members about candidates. There will be weekly conference calls to ensure progress. Thus, being a nomcom member does require some time commitment. While, there is no requirement in RFC 3777 that a participant attend IETF meetings while serving on nomcom, please consider that during the IETF meetings, people that do not attend would be expected to remotely participate during the day in the time zones of the meeting locations - Maastricht at the end of July and Beijing in November. If you are not yet sure you would like to volunteer, please consider that nomcom members play a very important role in shaping the leadership of the IETF. Ensuring the leadership of the IETF is fair and balanced and comprised of those who can lead the IETF in the right direction is an important responsibility that rests on the IETF participants at large. Volunteering for the nomcom is a good way of contributing in that direction. Please volunteer by sending an email before: 17:00 PDT (24:00 UTC) July 8, 2010 as follows: To: nomcom-chair@ietf.org Subject: Nomcom 2010-11 Volunteer Please include the following information in the body: // As you enter in the IETF Registration Form, // First/Given name followed by Last/Family Name // typically what goes in the Company field // in the IETF Registration Form [] // // For confirmation if selected Please expect an email response from me within 3 days stating whether or not you are qualified. If you don't receive a response, please re-send your email with the tag "Duplicate:" added to the subject line. Thank you and I hope to hear from you, Thomas Walsh Chair, Nomcom 2010-11 Email: nomcom-chair@ietf.org _______________________________________________ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce -- --------------------------------------------------------------------- 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 Jun 29 15:50:39 2010 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 1B71828C0E2 for ; Tue, 29 Jun 2010 15:50:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id u5oL33FINX7I for ; Tue, 29 Jun 2010 15:50:37 -0700 (PDT) Received: from mx2-int.auckland.ac.nz (mx2-int.auckland.ac.nz [130.216.12.41]) by core3.amsl.com (Postfix) with ESMTP id 830AC28C0E3 for ; Tue, 29 Jun 2010 15:50:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=auckland.ac.nz; i=n.brownlee@auckland.ac.nz; q=dns/txt; s=uoa; t=1277851845; x=1309387845; h=message-id:date:from:mime-version:to:subject: content-transfer-encoding; z=Message-ID:=20<4C2A7884.1040707@auckland.ac.nz>|Date:=20 Wed,=2030=20Jun=202010=2010:49:40=20+1200|From:=20Nevil =20Brownlee=20|MIME-Version: =201.0|To:=20IPFIX=20Working=20Group=20 |Subject:=20[Fwd:=20FW:=20Third=20Call=20for=20Nomcom=202 010-11=20Volunteers]|Content-Transfer-Encoding:=207bit; bh=RlUTscUpi5SK/VtMxeeyHSYioXl22hrITGVrn/pQhew=; b=sjSE2uTld++YMUmq9rhzZkURno8PukPLpQvmC3BI08az9Q8l3S2/4qoe fikn5b4owMdN9XACVu8oMHSXjl9k7P99YCL05Z6G0jFUB6NtwlpIsi15n lKQt/9vvPHRUOrLHsoNUjwcGWWSF7HkXJN3Xi2G6r1aHjyAraHbO5Z+7r o=; X-IronPort-AV: E=Sophos;i="4.53,507,1272801600"; d="scan'208";a="13214901" X-Ironport-HAT: UNIVERSITY - $RELAY-THROTTLE X-Ironport-Source: 130.216.38.130 - Outgoing - Outgoing-SSL Received: from nevil-laptop.sfac.auckland.ac.nz ([130.216.38.130]) by mx2-int.auckland.ac.nz with ESMTP; 30 Jun 2010 10:49:45 +1200 Message-ID: <4C2A7884.1040707@auckland.ac.nz> Date: Wed, 30 Jun 2010 10:49:40 +1200 From: Nevil Brownlee User-Agent: Thunderbird 2.0.0.12 (Macintosh/20080213) MIME-Version: 1.0 To: IPFIX Working Group Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [IPFIX] [Fwd: FW: Third Call for Nomcom 2010-11 Volunteers] 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, 29 Jun 2010 22:50:39 -0000 -------- Original Message -------- Subject: FW: Third Call for Nomcom 2010-11 Volunteers Date: Wed, 30 Jun 2010 09:36:26 +1200 From: Romascanu, Dan (Dan) To: ops-chairs@ietf.org Please send this third call for volunteers for NomComm to your WG lists. Participating in NomComm is an important contribution to the future of the IETF. Regards, Dan -----Original Message----- From: ietf-bounces@ietf.org [mailto:ietf-bounces@ietf.org] On Behalf Of Thomas Walsh Sent: Wednesday, June 30, 2010 12:31 AM To: ietf@ietf.org Subject: FW: Third Call for Nomcom 2010-11 Volunteers Please volunteer if you are eligible. You must have attended 3 of the last 5 IETF meetings to be eligible. -----Original Message----- From: ietf-announce-bounces@ietf.org [mailto:ietf-announce-bounces@ietf.org] On Behalf Of NomCom Chair Sent: Monday, June 28, 2010 4:58 PM To: IETF Announcement list Subject: Third Call for Nomcom 2010-11 Volunteers Hi all, This is the Third call for Volunteers for the 2010-2011 Nomcom. We are now 2/3 of the way through the volunteer period so if you are considering volunteering please do so now as the time in which you may volunteer is beginning to run short. The call for volunteers remains open until 17:00 PDT (24:00 UTC) on July 8, 2010. I am pleased to report that we currently have 65 volunteers thus far whose qualifications have been confirmed by the secretariat. I have notified each of these volunteers by email. I will publish the current list of volunteers in a separate message. If you volunteered before 12:00 PDT (19:00 UTC) on June 28 to serve as a voting member and have not received a confirmation email from me, please re-submit and bring to my attention right away! We still need additional volunteers, please! If you have attended at least 3 of the last 5 IETF meetings you are eligible to volunteer. The 10 nominating committee members are selected randomly from a pool of volunteers. The details of the operation of Nomcom may be found in RFC 3777. The process on how to volunteer for Nomcom is in the initial announcement: https://datatracker.ietf.org/ann/nomcom/2330/ The lists of open positions and people whose terms end in March 2011 and thus the positions for which the nominating committee is responsible are summarized in the initial announcement: https://datatracker.ietf.org/ann/nomcom/2330/ Please volunteer by sending an email before: 17:00 PDT (24:00 UTC) July 8, 2010 as follows: To: nomcom-chair@ietf.org Subject: Nomcom 2010-11 Volunteer Please include the following information in the body: // As you enter in the IETF Registration Form, // First/Given name followed by Last/Family Name // typically what goes in the Company field // in the IETF Registration Form // // For confirmation if selected Please expect an email response from me within 3 days stating whether or not you are qualified. If you don't receive a response, please re-send your email with the tag "Duplicate:" added to the subject line. Thank you and I hope to hear from you, Thomas Walsh Chair, Nomcom 2010-11 Email: nomcom-chair@ietf.org _______________________________________________ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce _______________________________________________ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf -- --------------------------------------------------------------------- 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 Jun 30 02:42:20 2010 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 3A6753A69A1 for ; Wed, 30 Jun 2010 02:42:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.165 X-Spam-Level: X-Spam-Status: No, score=0.165 tagged_above=-999 required=5 tests=[BAYES_40=-0.185, 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 YvZoNZp9JIdB for ; Wed, 30 Jun 2010 02:42:19 -0700 (PDT) Received: from mail-out2.informatik.tu-muenchen.de (mail-out2.informatik.tu-muenchen.de [131.159.0.36]) by core3.amsl.com (Postfix) with ESMTP id EE6663A699E for ; Wed, 30 Jun 2010 02:42:18 -0700 (PDT) Received: from [131.159.20.248] (vpn-4.net.in.tum.de [131.159.20.248]) by mail.net.in.tum.de (Postfix) with ESMTPSA id 2E60621CBCDE; Wed, 30 Jun 2010 11:42:28 +0200 (CEST) Message-ID: <4C2B118B.4050601@net.in.tum.de> Date: Wed, 30 Jun 2010 11:42:35 +0200 From: Gerhard Muenz User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 To: Benoit Claise References: <4B9AC2F8.1090504@cisco.com> <4B9B87BD.7020201@net.in.tum.de> <4BA5584E.3060508@auckland.ac.nz> <4BA5611F.90309@cisco.com> <4BA6A547.7050503@cisco.com> In-Reply-To: <4BA6A547.7050503@cisco.com> Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms030407090701070807050100" X-Virus-Scanned: ClamAV using ClamSMTP Cc: Nevil Brownlee , "ipfix@ietf.org" Subject: Re: [IPFIX] IPFIX errata 2052 to 2059 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, 30 Jun 2010 09:42:20 -0000 This is a cryptographically signed message in MIME format. --------------ms030407090701070807050100 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Dear all, I see unsigned64 as being verified in the errata, not unsigned32: http://www.rfc-editor.org/errata_search.php?rfc=3D5477 So, what's true now? Regards, Gerhard Benoit Claise wrote: > Nevil, >> Nevil, >> >>> I'm looking through our 'unverified' errata - do we have consensus >>> for Paul's Errata 2052, i.e. change SelectorId to unsigned64? >> The consensus seems to be a change to unsigned32. > It's true that unsigned64 would have been better, and Thomas highlighte= d=20 > a limitation with the MIB. > So let's go for unsigned32 then. >=20 > Regards, Benoit. >> Thanks, >> P. >> >=20 > _______________________________________________ > IPFIX mailing list > IPFIX@ietf.org > https://www.ietf.org/mailman/listinfo/ipfix --=20 Dr.-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 --------------ms030407090701070807050100 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 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIO5jCC BEYwggOvoAMCAQICEGb9R+PCGeToms2Z3fU6yyQwDQYJKoZIhvcNAQEFBQAwXzELMAkGA1UE BhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMTcwNQYDVQQLEy5DbGFzcyAxIFB1Ymxp YyBQcmltYXJ5IENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA1MTAyODAwMDAwMFoXDTE1 MTAyNzIzNTk1OVowgd0xCzAJBgNVBAYTAlVTMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEf MB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazE7MDkGA1UECxMyVGVybXMgb2YgdXNl IGF0IGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9ycGEgKGMpMDUxHjAcBgNVBAsTFVBlcnNv bmEgTm90IFZhbGlkYXRlZDE3MDUGA1UEAxMuVmVyaVNpZ24gQ2xhc3MgMSBJbmRpdmlkdWFs IFN1YnNjcmliZXIgQ0EgLSBHMjCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMnf rOfq+PgDFMQAktXBfjbCPO98chXLwKuMPRyVzm8eECw/AO2XJua2x+atQx0/pIdHR0w+VPhs +Mf8sZ69MHC8l7EDBeqV8a1AxUR6SwWi8mD81zplYu//EHuiVrvFTnAt1qIfPO2wQuhejVch rKaZ2RHp0hoHwHRHQgv8xTTq/ea6JNEdCBU3otdzzwFBL2OyOj++pRpu9MlKWz2VphW7NQIZ +dTvvI8OcXZZu0u2Ptb8Whb01g6J8kn+bAztFenZiHWcec5gJ925rXXOL3OVekA6hXVJsLjf aLyrzROChRFQo+A8C67AClPN1zBvhTJGG+RJEMJs4q8fef/btLUCAwEAAaOB/zCB/DASBgNV HRMBAf8ECDAGAQH/AgEAMEQGA1UdIAQ9MDswOQYLYIZIAYb4RQEHFwEwKjAoBggrBgEFBQcC ARYcaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYTALBgNVHQ8EBAMCAQYwEQYJYIZIAYb4 QgEBBAQDAgEGMC4GA1UdEQQnMCWkIzAhMR8wHQYDVQQDExZQcml2YXRlTGFiZWwzLTIwNDgt MTU1MB0GA1UdDgQWBBQRfV4ZfTwE32ps1qKKGj8x2DuUUjAxBgNVHR8EKjAoMCagJKAihiBo dHRwOi8vY3JsLnZlcmlzaWduLmNvbS9wY2ExLmNybDANBgkqhkiG9w0BAQUFAAOBgQA8o9oC YzrEk6qrctPcrVA4HgyeFkqIt+7r2f8PjZWg1rv6aguuYYTYaEeJ70+ssh9JQZtJM3aTi55u uUMcYL3C3Ioth8FFwBFyBBprJCpsb+f8BxMp0Hc6I+f1wYVoGb/GAVQgGa41gsxiPGEJxvTV 67APpp8zhZrTcY5Qj5ndYjCCBUowggQyoAMCAQICEF0kYdlVNx5E1qcmxun5IrswDQYJKoZI hvcNAQEFBQAwgd0xCzAJBgNVBAYTAlVTMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0G A1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazE7MDkGA1UECxMyVGVybXMgb2YgdXNlIGF0 IGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9ycGEgKGMpMDUxHjAcBgNVBAsTFVBlcnNvbmEg Tm90IFZhbGlkYXRlZDE3MDUGA1UEAxMuVmVyaVNpZ24gQ2xhc3MgMSBJbmRpdmlkdWFsIFN1 YnNjcmliZXIgQ0EgLSBHMjAeFw0xMDAxMDIwMDAwMDBaFw0xMTAxMDIyMzU5NTlaMIIBEzEX MBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0IE5ldHdv cmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEgSW5jb3JwLiBi eSBSZWYuLExJQUIuTFREKGMpOTgxHjAcBgNVBAsTFVBlcnNvbmEgTm90IFZhbGlkYXRlZDEz MDEGA1UECxMqRGlnaXRhbCBJRCBDbGFzcyAxIC0gTmV0c2NhcGUgRnVsbCBTZXJ2aWNlMRYw FAYDVQQDFA1HZXJoYXJkIE11ZW56MSIwIAYJKoZIhvcNAQkBFhNtdWVuekBuZXQuaW4udHVt LmRlMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAl/YDW9cnAXJjesGhwtGwj9JN IHWXQ7QA18s+wGZNsQY0k4eKBeLTk/RAiC1hP+uQAXLoGQHQF/ljjQCQeRmnsN6w04iAzKVo Ru+NP7Y6ipn8uztx+z0Y3w43CO+LWUudp3PIF3+Fm2zwsAFXj/IYy/8Kq6m9+nQgYO/D4HoN DDR3//GepXghK0x93gR0GCkm8pgKINHNBD47/IZbDe/cIpAC9HaoxCeLiB1QaCDIYPIrJ0Vx kk0crAA0tPaMDjdSQTmNRAn2P+7Wg7K+DLvauBHfxLs8PrsolI+XdwiBu6henK9nPxvtoHmm mfxcdslKLbS9Xz2rHxi6PVVgv1ubWwIDAQABo4HMMIHJMAkGA1UdEwQCMAAwRAYDVR0gBD0w OzA5BgtghkgBhvhFAQcXATAqMCgGCCsGAQUFBwIBFhxodHRwczovL3d3dy52ZXJpc2lnbi5j b20vcnBhMAsGA1UdDwQEAwIFoDAdBgNVHSUEFjAUBggrBgEFBQcDBAYIKwYBBQUHAwIwSgYD VR0fBEMwQTA/oD2gO4Y5aHR0cDovL0luZEMxRGlnaXRhbElELWNybC52ZXJpc2lnbi5jb20v SW5kQzFEaWdpdGFsSUQuY3JsMA0GCSqGSIb3DQEBBQUAA4IBAQBPU7OeWNo2LRzsdu/RuuAk L5cj/RzeZ0xv9q4K/eosy9dRu45XACpPvb0fjc3u/dsY4m3jDqzUsB02IrrnF9jpEo10BJPw b/RZ7NaU7jC/gEknL3bSXiD2PVwL4ZI5ChH5+TJUboWhVh+FpOwOfP/yKk7wQM/46iXXzRIz enk0rcJp71k4aQgQTML3/8MDeD6TUipuQwQMY9n6T6DsNd/6JpGa+x9ZX4HIEG6+EWwQ85G5 vGfDBaq3dFrksHE75u7b7pf75wm9HIFU2SDHP2tymTHJt/XM9sqP1URIC57s+uZV0/d5KRc1 uPcJ0FAnAiC9o7ybPIh27shiq0FvOEwfMIIFSjCCBDKgAwIBAgIQXSRh2VU3HkTWpybG6fki uzANBgkqhkiG9w0BAQUFADCB3TELMAkGA1UEBhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJ bmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTswOQYDVQQLEzJUZXJtcyBv ZiB1c2UgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYSAoYykwNTEeMBwGA1UECxMV UGVyc29uYSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5WZXJpU2lnbiBDbGFzcyAxIEluZGl2 aWR1YWwgU3Vic2NyaWJlciBDQSAtIEcyMB4XDTEwMDEwMjAwMDAwMFoXDTExMDEwMjIzNTk1 OVowggETMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1 c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJ bmNvcnAuIGJ5IFJlZi4sTElBQi5MVEQoYyk5ODEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFs aWRhdGVkMTMwMQYDVQQLEypEaWdpdGFsIElEIENsYXNzIDEgLSBOZXRzY2FwZSBGdWxsIFNl cnZpY2UxFjAUBgNVBAMUDUdlcmhhcmQgTXVlbnoxIjAgBgkqhkiG9w0BCQEWE211ZW56QG5l dC5pbi50dW0uZGUwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCX9gNb1ycBcmN6 waHC0bCP0k0gdZdDtADXyz7AZk2xBjSTh4oF4tOT9ECILWE/65ABcugZAdAX+WONAJB5Gaew 3rDTiIDMpWhG740/tjqKmfy7O3H7PRjfDjcI74tZS52nc8gXf4WbbPCwAVeP8hjL/wqrqb36 dCBg78Pgeg0MNHf/8Z6leCErTH3eBHQYKSbymAog0c0EPjv8hlsN79wikAL0dqjEJ4uIHVBo IMhg8isnRXGSTRysADS09owON1JBOY1ECfY/7taDsr4Mu9q4Ed/Euzw+uyiUj5d3CIG7qF6c r2c/G+2geaaZ/Fx2yUottL1fPasfGLo9VWC/W5tbAgMBAAGjgcwwgckwCQYDVR0TBAIwADBE BgNVHSAEPTA7MDkGC2CGSAGG+EUBBxcBMCowKAYIKwYBBQUHAgEWHGh0dHBzOi8vd3d3LnZl cmlzaWduLmNvbS9ycGEwCwYDVR0PBAQDAgWgMB0GA1UdJQQWMBQGCCsGAQUFBwMEBggrBgEF BQcDAjBKBgNVHR8EQzBBMD+gPaA7hjlodHRwOi8vSW5kQzFEaWdpdGFsSUQtY3JsLnZlcmlz aWduLmNvbS9JbmRDMURpZ2l0YWxJRC5jcmwwDQYJKoZIhvcNAQEFBQADggEBAE9Ts55Y2jYt HOx279G64CQvlyP9HN5nTG/2rgr96izL11G7jlcAKk+9vR+Nze792xjibeMOrNSwHTYiuucX 2OkSjXQEk/Bv9Fns1pTuML+ASScvdtJeIPY9XAvhkjkKEfn5MlRuhaFWH4Wk7A58//IqTvBA z/jqJdfNEjN6eTStwmnvWThpCBBMwvf/wwN4PpNSKm5DBAxj2fpPoOw13/omkZr7H1lfgcgQ br4RbBDzkbm8Z8MFqrd0WuSwcTvm7tvul/vnCb0cgVTZIMc/a3KZMcm39cz2yo/VREgLnuz6 5lXT93kpFzW49wnQUCcCIL2jvJs8iHbuyGKrQW84TB8xggTsMIIE6AIBATCB8jCB3TELMAkG A1UEBhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBU cnVzdCBOZXR3b3JrMTswOQYDVQQLEzJUZXJtcyBvZiB1c2UgYXQgaHR0cHM6Ly93d3cudmVy aXNpZ24uY29tL3JwYSAoYykwNTEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTcw NQYDVQQDEy5WZXJpU2lnbiBDbGFzcyAxIEluZGl2aWR1YWwgU3Vic2NyaWJlciBDQSAtIEcy AhBdJGHZVTceRNanJsbp+SK7MAkGBSsOAwIaBQCgggLOMBgGCSqGSIb3DQEJAzELBgkqhkiG 9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTEwMDYzMDA5NDIzNVowIwYJKoZIhvcNAQkEMRYEFEpp q1gHoPQQ0BhRjUOQlfe4+q+2MF8GCSqGSIb3DQEJDzFSMFAwCwYJYIZIAWUDBAECMAoGCCqG SIb3DQMHMA4GCCqGSIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG 9w0DAgIBKDCCAQMGCSsGAQQBgjcQBDGB9TCB8jCB3TELMAkGA1UEBhMCVVMxFzAVBgNVBAoT DlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTswOQYD VQQLEzJUZXJtcyBvZiB1c2UgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYSAoYykw NTEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5WZXJpU2lnbiBD bGFzcyAxIEluZGl2aWR1YWwgU3Vic2NyaWJlciBDQSAtIEcyAhBdJGHZVTceRNanJsbp+SK7 MIIBBQYLKoZIhvcNAQkQAgsxgfWggfIwgd0xCzAJBgNVBAYTAlVTMRcwFQYDVQQKEw5WZXJp U2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazE7MDkGA1UECxMy VGVybXMgb2YgdXNlIGF0IGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9ycGEgKGMpMDUxHjAc BgNVBAsTFVBlcnNvbmEgTm90IFZhbGlkYXRlZDE3MDUGA1UEAxMuVmVyaVNpZ24gQ2xhc3Mg MSBJbmRpdmlkdWFsIFN1YnNjcmliZXIgQ0EgLSBHMgIQXSRh2VU3HkTWpybG6fkiuzANBgkq hkiG9w0BAQEFAASCAQAuEcB0rPkPgX2vZpFKR7OLfJQ3tOv8b2BRbOzRvVDlRd5VFLDfbKXu TCOYMAnEpjwPn4ZuuA0Q4cOxyvFCw46Fzxv3/pSNHIE0kUQ0FN2daw7ONsrahr/UZrX/mS16 ZF1FrF2ksUQotBCvXqSD5DkrEvABYw8eDNQIn66hKNbW1Ztmkx6B24WvZKz8DndEplHw/9Nm a58fLeQWZyAit+oUhaKzEZB10Em7fQEQgX/v3VNEvxR3iq6p9MjExSbQMLwpPwZVHnReV8vu wRjYyg56lf/wsb+UXd2MFgH8YmoVn8uOLlOQm+x7fbMshcJyUVEuJi92R6n8b5OnlGL2XVR8 AAAAAAAA --------------ms030407090701070807050100-- From n.brownlee@auckland.ac.nz Wed Jun 30 22:52:17 2010 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 947F43A6828 for ; Wed, 30 Jun 2010 22:52:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.67 X-Spam-Level: X-Spam-Status: No, score=-1.67 tagged_above=-999 required=5 tests=[AWL=-0.930, BAYES_20=-0.74] 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 oHpHKkc9HqsK for ; Wed, 30 Jun 2010 22:52:13 -0700 (PDT) Received: from mx2-int.auckland.ac.nz (mx2-int.auckland.ac.nz [130.216.12.41]) by core3.amsl.com (Postfix) with ESMTP id DB06C3A68B1 for ; Wed, 30 Jun 2010 22:50:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=auckland.ac.nz; i=n.brownlee@auckland.ac.nz; q=dns/txt; s=uoa; t=1277963468; x=1309499468; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; z=Message-ID:=20<4C2C2C7F.8090202@auckland.ac.nz>|Date:=20 Thu,=2001=20Jul=202010=2017:49:51=20+1200|From:=20Nevil =20Brownlee=20|MIME-Version: =201.0|To:=20Gerhard=20Muenz=20|CC: =20Benoit=20Claise=20,=20Paul=20Aitken =20,=20=0D=0A=20"ipfix@ietf.org"=20|Subject:=20Re:=20[IPFIX]=20IPFIX=20errata =202052=20to=202059|References:=20<4B9AC2F8.1090504@cisco .com>=09<4B9B87BD.7020201@net.in.tum.de>=09<4BA5584E.3060 508@auckland.ac.nz>=09<4BA5611F.90309@cisco.com>=20<4BA6A 547.7050503@cisco.com>=20<4C2B118B.4050601@net.in.tum.de> |In-Reply-To:=20<4C2B118B.4050601@net.in.tum.de> |Content-Transfer-Encoding:=207bit; bh=XmdVIpea6S9cJrOop3+2sGm51TbEmJjhxaWHy5Rxwgo=; b=oyXBLgwwzSwXKhbmWIXBwSfxM8976AAz8aK9jeOoKqKVtXgSZflhNZsz 1wT/R74mc41xI9CB5fXMDm4PA/vP9OdwfAzzarp821psuxitDOwXpIWYO h0Z14pm6UHR4xMAi/H4cpMRnZmLdcEQrLdsWN+JrXBfSrVh9nguubcrN3 I=; X-IronPort-AV: E=Sophos;i="4.53,517,1272801600"; d="scan'208";a="13450007" X-Ironport-HAT: UNIVERSITY - $RELAY-THROTTLE X-Ironport-Source: 130.216.38.130 - Outgoing - Outgoing-SSL Received: from nevil-laptop.sfac.auckland.ac.nz ([130.216.38.130]) by mx2-int.auckland.ac.nz with ESMTP; 01 Jul 2010 17:49:53 +1200 Message-ID: <4C2C2C7F.8090202@auckland.ac.nz> Date: Thu, 01 Jul 2010 17:49:51 +1200 From: Nevil Brownlee User-Agent: Thunderbird 2.0.0.12 (Macintosh/20080213) MIME-Version: 1.0 To: Gerhard Muenz References: <4B9AC2F8.1090504@cisco.com> <4B9B87BD.7020201@net.in.tum.de> <4BA5584E.3060508@auckland.ac.nz> <4BA5611F.90309@cisco.com> <4BA6A547.7050503@cisco.com> <4C2B118B.4050601@net.in.tum.de> In-Reply-To: <4C2B118B.4050601@net.in.tum.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "ipfix@ietf.org" Subject: Re: [IPFIX] IPFIX errata 2052 to 2059 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, 01 Jul 2010 05:52:18 -0000 Hi Gerhard: Oh, Oh, .. looking back I see that when I asked Dan to verify these errata, I gave him a confusing message, so it's been verified incorrectly - consensus was (as you say below) for unsigned32. I'll work out the best way to get errata 2052 corrected. Cheers, Nevil Gerhard Muenz wrote: > Dear all, > > I see unsigned64 as being verified in the errata, not unsigned32: > http://www.rfc-editor.org/errata_search.php?rfc=5477 > > So, what's true now? > > Regards, > Gerhard > > Benoit Claise wrote: >> Nevil, >>> Nevil, >>> >>>> I'm looking through our 'unverified' errata - do we have consensus >>>> for Paul's Errata 2052, i.e. change SelectorId to unsigned64? >>> The consensus seems to be a change to unsigned32. >> It's true that unsigned64 would have been better, and Thomas highlighted >> a limitation with the MIB. >> So let's go for unsigned32 then. >> >> Regards, Benoit. >>> Thanks, >>> P. >>> >> _______________________________________________ >> IPFIX mailing list >> IPFIX@ietf.org >> https://www.ietf.org/mailman/listinfo/ipfix > -- --------------------------------------------------------------------- Nevil Brownlee Computer Science Department | ITS Phone: +64 9 373 7599 x88941 The University of Auckland FAX: +64 9 373 7453 Private Bag 92019, Auckland 1142, New Zealand From dromasca@avaya.com Wed Jun 30 23:54:25 2010 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 96EC43A67C3 for ; Wed, 30 Jun 2010 23:54:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.02 X-Spam-Level: X-Spam-Status: No, score=-2.02 tagged_above=-999 required=5 tests=[AWL=0.579, 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 xs2T-tQL45nH for ; Wed, 30 Jun 2010 23:54:24 -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 88A7E3A67A1 for ; Wed, 30 Jun 2010 23:54:24 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.53,518,1272859200"; d="scan'208";a="196061063" Received: from unknown (HELO co300216-co-erhwest.avaya.com) ([198.152.7.5]) by de307622-de-outbound.net.avaya.com with ESMTP; 01 Jul 2010 02:54:34 -0400 X-IronPort-AV: E=Sophos;i="4.53,518,1272859200"; d="scan'208";a="487905194" Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.14]) by co300216-co-erhwest-out.avaya.com with ESMTP; 01 Jul 2010 02:54:33 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Date: Thu, 1 Jul 2010 08:54:12 +0200 Message-ID: In-Reply-To: <4C2C2C7F.8090202@auckland.ac.nz> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [IPFIX] IPFIX errata 2052 to 2059 Thread-Index: AcsY4b1g/cn99n/9TsyAdfhSk6xVHwACCCGA References: <4B9AC2F8.1090504@cisco.com> <4B9B87BD.7020201@net.in.tum.de> <4BA5584E.3060508@auckland.ac.nz> <4BA5611F.90309@cisco.com><4BA6A547.7050503@cisco.com> <4C2B118B.4050601@net.in.tum.de> <4C2C2C7F.8090202@auckland.ac.nz> From: "Romascanu, Dan (Dan)" To: "Nevil Brownlee" , "Gerhard Muenz" Cc: ipfix@ietf.org Subject: Re: [IPFIX] IPFIX errata 2052 to 2059 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, 01 Jul 2010 06:54:25 -0000 Nevil, The way to do it is to 'unverify' errata 2052 - and I think that this can be done by the RFC Editor. Do you know anybody there? :-) Then I can reenter the proper resolution. Can you suggest the text that the WG reached consensus about?=20 Thanks and Regards, Dan > -----Original Message----- > From: ipfix-bounces@ietf.org [mailto:ipfix-bounces@ietf.org]=20 > On Behalf Of Nevil Brownlee > Sent: Thursday, July 01, 2010 8:50 AM > To: Gerhard Muenz > Cc: ipfix@ietf.org > Subject: Re: [IPFIX] IPFIX errata 2052 to 2059 >=20 >=20 > Hi Gerhard: >=20 > Oh, Oh, .. looking back I see that when I asked Dan to verify=20 > these errata, I gave him a confusing message, so it's been=20 > verified incorrectly - consensus was (as you say below) for=20 > unsigned32. >=20 > I'll work out the best way to get errata 2052 corrected. >=20 > Cheers, Nevil >=20 >=20 > Gerhard Muenz wrote: > > Dear all, > >=20 > > I see unsigned64 as being verified in the errata, not unsigned32: > > http://www.rfc-editor.org/errata_search.php?rfc=3D5477 > >=20 > > So, what's true now? > >=20 > > Regards, > > Gerhard > >=20 > > Benoit Claise wrote: > >> Nevil, > >>> Nevil, > >>> > >>>> I'm looking through our 'unverified' errata - do we have=20 > consensus=20 > >>>> for Paul's Errata 2052, i.e. change SelectorId to unsigned64? > >>> The consensus seems to be a change to unsigned32. > >> It's true that unsigned64 would have been better, and Thomas=20 > >> highlighted a limitation with the MIB. > >> So let's go for unsigned32 then. > >> > >> Regards, Benoit. > >>> Thanks, > >>> P. > >>> > >> _______________________________________________ > >> IPFIX mailing list > >> IPFIX@ietf.org > >> https://www.ietf.org/mailman/listinfo/ipfix > >=20 >=20 >=20 > -- > --------------------------------------------------------------------- > Nevil Brownlee Computer Science Department | ITS > Phone: +64 9 373 7599 x88941 The University of Auckland > FAX: +64 9 373 7453 Private Bag 92019, Auckland 1142, New Zealand > _______________________________________________ > IPFIX mailing list > IPFIX@ietf.org > https://www.ietf.org/mailman/listinfo/ipfix >=20