From bclaise@cisco.com Wed Mar 4 00:14: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 9E4E93A68DA for ; Wed, 4 Mar 2009 00:14:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.336 X-Spam-Level: X-Spam-Status: No, score=-2.336 tagged_above=-999 required=5 tests=[AWL=0.262, 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 pBIVnXjq-l4O for ; Wed, 4 Mar 2009 00:14:31 -0800 (PST) Received: from av-tac-bru.cisco.com (odd-brew.cisco.com [144.254.15.119]) by core3.amsl.com (Postfix) with ESMTP id E72833A67C0 for ; Wed, 4 Mar 2009 00:14:30 -0800 (PST) X-TACSUNS: Virus Scanned Received: from strange-brew.cisco.com (localhost [127.0.0.1]) by av-tac-bru.cisco.com (8.11.7p3+Sun/8.11.7) with ESMTP id n248Ewa09697 for ; Wed, 4 Mar 2009 09:14:58 +0100 (CET) Received: from [10.55.43.54] (ams-bclaise-8715.cisco.com [10.55.43.54]) by strange-brew.cisco.com (8.11.7p3+Sun/8.11.7) with ESMTP id n248Evt18137 for ; Wed, 4 Mar 2009 09:14:57 +0100 (CET) Message-ID: <49AE3881.3050909@cisco.com> Date: Wed, 04 Mar 2009 09:14:57 +0100 From: Benoit Claise User-Agent: Thunderbird 2.0.0.19 (Windows/20081209) MIME-Version: 1.0 To: "ipfix@ietf.org" Content-Type: multipart/alternative; boundary="------------090001070702040708010703" Subject: [IPFIX] [Fwd: I-D ACTION:draft-claise-structured-data-in-ipfix-00.txt] X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Mar 2009 08:14:35 -0000 This is a multi-part message in MIME format. --------------090001070702040708010703 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Dear all, Here is a new IPFIX draft. I think that the abstract is quite clear about its goal. Regards, Benoit. -------- Original Message -------- Subject: I-D ACTION:draft-claise-structured-data-in-ipfix-00.txt Date: Tue, 3 Mar 2009 15:15:01 -0800 (PST) From: Internet-Drafts@ietf.org Reply-To: internet-drafts@ietf.org To: i-d-announce@ietf.org A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Export of Structured Data in IPFIX Author(s) : B. Claise, G. Dhandapani, S. Yates, P. Aitken Filename : draft-claise-structured-data-in-ipfix-00.txt Pages : 36 Date : 2009-3-3 This document specifies an extension to IP Flow Information eXport (IPFIX) protocol specification in [RFC5101] and the IPFIX information model specified in [RFC5102] to support hierarchical structured data and lists (sequences) of Information Elements in data records. This extension allows definition of complex data structures such as variable-length lists and specification of hierarchical containment relationships between Templates. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-claise-structured-data-in-ipfix-00.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --------------090001070702040708010703 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Dear all,

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

Regards, Benoit.

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


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


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

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-claise-structured-data-in-ipfix-00.txt

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.
--------------090001070702040708010703-- From bclaise@cisco.com Wed Mar 4 00:15:20 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 977F428C2CF for ; Wed, 4 Mar 2009 00:15:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.389 X-Spam-Level: X-Spam-Status: No, score=-2.389 tagged_above=-999 required=5 tests=[AWL=0.211, 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 RB5rJB+IoYNx for ; Wed, 4 Mar 2009 00:15:20 -0800 (PST) Received: from av-tac-bru.cisco.com (odd-brew.cisco.com [144.254.15.119]) by core3.amsl.com (Postfix) with ESMTP id 7D33928C313 for ; Wed, 4 Mar 2009 00:15:19 -0800 (PST) X-TACSUNS: Virus Scanned Received: from strange-brew.cisco.com (localhost [127.0.0.1]) by av-tac-bru.cisco.com (8.11.7p3+Sun/8.11.7) with ESMTP id n248FkE09766; Wed, 4 Mar 2009 09:15:46 +0100 (CET) Received: from [10.55.43.54] (ams-bclaise-8715.cisco.com [10.55.43.54]) by strange-brew.cisco.com (8.11.7p3+Sun/8.11.7) with ESMTP id n248Fjt19379; Wed, 4 Mar 2009 09:15:46 +0100 (CET) Message-ID: <49AE38B1.8070301@cisco.com> Date: Wed, 04 Mar 2009 09:15:45 +0100 From: Benoit Claise User-Agent: Thunderbird 2.0.0.19 (Windows/20081209) MIME-Version: 1.0 To: Nevil Brownlee References: <499E3B56.1050207@auckland.ac.nz> In-Reply-To: <499E3B56.1050207@auckland.ac.nz> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: IPFIX Working Group Subject: Re: [IPFIX] DRAFT Agenda for San Francisco IETF 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, 04 Mar 2009 08:15:20 -0000 Nevil, I would like to request a slot to present draft-claise-structured-data-in-ipfix-00.txt Thank you. Regards, Benoit. > Hi all: > > A first draft agenda for our IPFIX session in San Francisco is > appended below. Please send any additional agenda items, or > suggestions for improvements to me. > > Cheers, Nevil > From akoba@nttv6.net Fri Mar 6 04:34: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 A2A743A6B09 for ; Fri, 6 Mar 2009 04:34:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.199 X-Spam-Level: X-Spam-Status: No, score=0.199 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001, SUBJ_RE_NUM=2.799] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Qj3DNoe30oFq for ; Fri, 6 Mar 2009 04:34:27 -0800 (PST) Received: from mail.nttv6.net (mail.nttv6.net [IPv6:2001:fa8::25]) by core3.amsl.com (Postfix) with ESMTP id 770423A6826 for ; Fri, 6 Mar 2009 04:34:26 -0800 (PST) Received: from [192.47.163.152] ([IPv6:2001:fa8:1000:0:9939:5c71:9bde:126f]) by mail.nttv6.net (8.14.3/8.14.3) with ESMTP id n26CYYtN033940; Fri, 6 Mar 2009 21:34:34 +0900 (JST) (envelope-from akoba@nttv6.net) Date: Fri, 06 Mar 2009 21:36:10 +0900 From: Atsushi Kobayashi To: Benoit Claise In-Reply-To: <49AE38B1.8070301@cisco.com> References: <499E3B56.1050207@auckland.ac.nz> <49AE38B1.8070301@cisco.com> Message-Id: <20090306211330.3EBA.17391CF2@nttv6.net> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Becky! ver. 2.48.02 [ja] X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.0.1 (mail.nttv6.net [IPv6:2001:fa8::25]); Fri, 06 Mar 2009 21:34:34 +0900 (JST) Cc: Nevil Brownlee , IPFIX Working Group Subject: Re: [IPFIX] DRAFT Agenda for San Francisco IETF 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, 06 Mar 2009 12:34:27 -0000 Hi Nevil and Benoit, Nevil, thank you for assignment for 60 min time slot for IPFIX Mediation. But, the agenda shows the total time slot for current WG drafts is 40 min. Which one is correct? I think that 60 min time slot is enough for IPFIX Mediation. Maybe 40 min is appropriate for me. Spare time can be assigned for new draft. 5. Current WG drafts = 40 min a) IPFIX Per-Stream SCTP reporting (Benoit CLaise) ( 5 min) - draft-ietf-ipfix-export-per-sctp-stream-02.txt 26 Jan 09 b) Configuration Data Model (10 min) - draft-ietf-ipfix-configuration-model-01.txt 3 Nov 08 c) IPFIX Mediation: (Kobayashi Atsushi) (25 min) - draft-ietf-ipfix-mediators-problem-statement-02.txt 4 Feb 09 - draft-ietf-ipfix-mediators-framework-02.txt (35 min) On Wed, 04 Mar 2009 09:15:45 +0100 Benoit Claise wrote: > Nevil, > > I would like to request a slot to present > draft-claise-structured-data-in-ipfix-00.txt > Thank you. > > Regards, Benoit. > > Hi all: > > > > A first draft agenda for our IPFIX session in San Francisco is > > appended below. Please send any additional agenda items, or > > suggestions for improvements to me. > > > > Cheers, Nevil > > > > _______________________________________________ > 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 muenz@net.in.tum.de Fri Mar 6 05:01: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 172AE28C28D for ; Fri, 6 Mar 2009 05:01:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.199 X-Spam-Level: X-Spam-Status: No, score=-2.199 tagged_above=-999 required=5 tests=[AWL=0.050, 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 7MogGmNOkbsy for ; Fri, 6 Mar 2009 05:01:41 -0800 (PST) Received: from mail-out2.informatik.tu-muenchen.de (maildmz2.informatik.tu-muenchen.de [131.159.0.15]) by core3.amsl.com (Postfix) with ESMTP id 24A4F3A69BA for ; Fri, 6 Mar 2009 05:01:40 -0800 (PST) Received: from phoenix.net.informatik.tu-muenchen.de (phoenix.net.informatik.tu-muenchen.de [131.159.14.1]) by services.net.informatik.tu-muenchen.de (Postix Mailer @ mail) with ESMTP id B4FF1483D4; Fri, 6 Mar 2009 14:02:09 +0100 (CET) Received: from [131.159.20.108] (repulse.net.informatik.tu-muenchen.de [131.159.20.108]) by phoenix.net.informatik.tu-muenchen.de (Postfix) with ESMTP id A4338930; Fri, 6 Mar 2009 14:02:09 +0100 (CET) Message-ID: <49B11ED6.9070706@net.in.tum.de> Date: Fri, 06 Mar 2009 14:02:14 +0100 From: Gerhard Muenz User-Agent: Thunderbird 2.0.0.19 (Windows/20081209) MIME-Version: 1.0 To: Brian Trammell References: <49B10249.9040500@cisco.com> In-Reply-To: <49B10249.9040500@cisco.com> Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms060509070105030307050008" X-Virus-Scanned: ClamAV using ClamSMTP Cc: "ipfix@ietf.org" Subject: [IPFIX] IPFIX configuration: (D)TLS 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, 06 Mar 2009 13:01:42 -0000 This is a cryptographically signed message in MIME format. --------------ms060509070105030307050008 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi Brian, Benoit reminded me that you promised some input regarding (D)TLS parameters that might be included into the configuration data model. http://www.ietf.org/proceedings/08nov/minutes/ipfix.txt Do you can still remember what you were thinking of? Probably the Fully Qualified Domain Name? If you are into this topic, maybe you can send a list with all common parameters - just to get an overview - and those that are interesting to have in the configuration data model. For example, I assume that it is not interesting to configure certificates - these are probably provided by different means to the devices. Gerhard --=20 Dipl.-Ing. Gerhard M=FCnz Chair for Network Architectures and Services (I8) Department of Informatics Technische Universit=E4t M=FCnchen Boltzmannstr. 3, 85748 Garching bei M=FCnchen, Germany Phone: +49 89 289-18008 Fax: +49 89 289-18033 E-mail: muenz@net.in.tum.de WWW: http://www.net.in.tum.de/~muenz --------------ms060509070105030307050008 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 SIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMDkwMzA2MTMwMjE0WjAjBgkqhkiG9w0BCQQxFgQU j7EuRH2zfhL2qB4gMlQBdoc0BMowUgYJKoZIhvcNAQkPMUUwQzAKBggqhkiG9w0DBzAOBggq hkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwICASgwgYUG CSsGAQQBgjcQBDF4MHYwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0 aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1 aW5nIENBAhAqxerdN2XVRkUZsuk5IKdPMIGHBgsqhkiG9w0BCRACCzF4oHYwYjELMAkGA1UE BhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMT I1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBAhAqxerdN2XVRkUZsuk5IKdP MA0GCSqGSIb3DQEBAQUABIIBAImHzG1wPIAo0NSrN6i194WxIHiWdCId5MCf+4Ynx7mvdQOK lXWcqps+K317cHsS825fnoA3k7dA9qxIZIVaetJ36pldTw/koA81Z+0TPqzQPYkBPYKmvprw 7GsBDs/O/6HuDaHZIb8reiDhRL3ekapmhh8pb4XhF9t/TXXb7xpFcUbCRlo3+COB68c9Qtbm y6zfk3QwxGqLujbNw1xUM3r3FQXfrf3EyBIBqWYlauROTSZJuBg/HOh6LXrb31wmnilFapfk UKgJtER55QJIBYX4QfU0toWO8L9ZX5dNtgf5nsSgCCp9z5MRBewHmkYwh7cYfo7Yu1Hhvby+ fGFlu00AAAAAAAA= --------------ms060509070105030307050008-- From trammell@tik.ee.ethz.ch Fri Mar 6 05:39:23 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 584513A6900 for ; Fri, 6 Mar 2009 05:39:23 -0800 (PST) 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 yIOFjZz5rE1M for ; Fri, 6 Mar 2009 05:39:22 -0800 (PST) Received: from smtp.ee.ethz.ch (smtp.ee.ethz.ch [129.132.2.219]) by core3.amsl.com (Postfix) with ESMTP id 2EB653A68F0 for ; Fri, 6 Mar 2009 05:39:21 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by smtp.ee.ethz.ch (Postfix) with ESMTP id 2BE38D93ED; Fri, 6 Mar 2009 14:39:49 +0100 (MET) 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 1-a3dcyAkc4Y; Fri, 6 Mar 2009 14:39:48 +0100 (MET) 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 83FB0D93E6; Fri, 6 Mar 2009 14:39:48 +0100 (MET) Message-Id: From: Brian Trammell To: Gerhard Muenz In-Reply-To: <49B11ED6.9070706@net.in.tum.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed; delsp=yes Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Apple Message framework v930.3) Date: Fri, 6 Mar 2009 14:39:48 +0100 References: <49B10249.9040500@cisco.com> <49B11ED6.9070706@net.in.tum.de> X-Mailer: Apple Mail (2.930.3) Cc: "ipfix@ietf.org Working Group" Subject: Re: [IPFIX] IPFIX configuration: (D)TLS 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, 06 Mar 2009 13:39:23 -0000 Hi, Gerhard, The main parameters I was thinking of are keying and identity =20 parameters. Perhaps we can state that CPs and EPs will be keyed =20 offline, but at least it might be nice to change the names of the =20 peers a device is willing to communicate with. For TLS, at minimum, an EP or CP must know: 1. its CA certificates (PEM/DER) 2. CA certificates for its peers' certificates (PEM/DER) (if not using =20= a single CA for all) 3. its own certificate and private key (PKCS#12) 4. the names of the peers it is willing to communicate with =20 (subjectName string) (if not assuming signature by a known CA is =20 sufficient) 5. CRL or OCSP peer for revocation, if supported (which it should be, =20= though 5101 doesn't state this directly) How much of that to support in config is an open question. Beyond that =20= it gets a bit implementation-specific. I hope to do a thorough review of the config work by San Francisco, =20 though no promises, as it's a bit mad here at the moment. Will you be =20= at the meeting? Cheers, Brian On Mar 6, 2009, at 2:02 PM, Gerhard Muenz wrote: > > Hi Brian, > > Benoit reminded me that you promised some input regarding (D)TLS > parameters that might be included into the configuration data model. > http://www.ietf.org/proceedings/08nov/minutes/ipfix.txt > > Do you can still remember what you were thinking of? > Probably the Fully Qualified Domain Name? > > If you are into this topic, maybe you can send a list with all common > parameters - just to get an overview - and those that are =20 > interesting to > have in the configuration data model. For example, I assume that it is > not interesting to configure certificates - these are probably =20 > provided > by different means to the devices. > > Gerhard > > --=20 > Dipl.-Ing. Gerhard M=FCnz > Chair for Network Architectures and Services (I8) > Department of Informatics > Technische Universit=E4t M=FCnchen > Boltzmannstr. 3, 85748 Garching bei M=FCnchen, Germany > Phone: +49 89 289-18008 Fax: +49 89 289-18033 > E-mail: muenz@net.in.tum.de WWW: http://www.net.in.tum.de/~muenz > > From muenz@net.in.tum.de Fri Mar 6 06:15:17 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 BA02C28C1CC for ; Fri, 6 Mar 2009 06:15:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.203 X-Spam-Level: X-Spam-Status: No, score=-2.203 tagged_above=-999 required=5 tests=[AWL=0.046, 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 6iysi152V7Uy for ; Fri, 6 Mar 2009 06:15:16 -0800 (PST) Received: from mail-out1.informatik.tu-muenchen.de (maildmz1.informatik.tu-muenchen.de [131.159.0.3]) by core3.amsl.com (Postfix) with ESMTP id 6E8CF3A6768 for ; Fri, 6 Mar 2009 06:15:16 -0800 (PST) Received: from phoenix.net.informatik.tu-muenchen.de (phoenix.net.informatik.tu-muenchen.de [131.159.14.1]) by services.net.informatik.tu-muenchen.de (Postix Mailer @ mail) with ESMTP id DA06D46F56; Fri, 6 Mar 2009 15:15:44 +0100 (CET) Received: from [131.159.20.108] (repulse.net.informatik.tu-muenchen.de [131.159.20.108]) by phoenix.net.informatik.tu-muenchen.de (Postfix) with ESMTP id C68382518; Fri, 6 Mar 2009 15:15:44 +0100 (CET) Message-ID: <49B13015.6070001@net.in.tum.de> Date: Fri, 06 Mar 2009 15:15:49 +0100 From: Gerhard Muenz User-Agent: Thunderbird 2.0.0.19 (Windows/20081209) MIME-Version: 1.0 To: Brian Trammell References: <49B10249.9040500@cisco.com> <49B11ED6.9070706@net.in.tum.de> In-Reply-To: Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms090606010902090605020808" X-Virus-Scanned: ClamAV using ClamSMTP Cc: "ipfix@ietf.org Working Group" Subject: Re: [IPFIX] IPFIX configuration: (D)TLS 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, 06 Mar 2009 14:15:17 -0000 This is a cryptographically signed message in MIME format. --------------ms090606010902090605020808 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi Brian, Brian Trammell wrote: > Hi, Gerhard, >=20 > The main parameters I was thinking of are keying and identity > parameters. Perhaps we can state that CPs and EPs will be keyed offline= , > but at least it might be nice to change the names of the peers a device= > is willing to communicate with. Who should restrict its willingness to communicate? The CP or the EP or both? Just using the name does not seem to be sufficient because the same name could be used with several certificates, right? So, it would be necessary to say: "CP accepts data from EP with name=3DX authorized by certificate/CA Y". Transporting certificates and keys to the devices does not seem to be useful. However, if the device has several keys, it would be useful to choose one of them. It seems that we need kind of abstract identifiers for keys and certificates saved on a device in order to refer to them in the configuration. > For TLS, at minimum, an EP or CP must know: >=20 > 1. its CA certificates (PEM/DER) > 2. CA certificates for its peers' certificates (PEM/DER) (if not using = a > single CA for all) > 3. its own certificate and private key (PKCS#12) > 4. the names of the peers it is willing to communicate with (subjectNam= e > string) (if not assuming signature by a known CA is sufficient) > 5. CRL or OCSP peer for revocation, if supported (which it should be, > though 5101 doesn't state this directly) >=20 > How much of that to support in config is an open question. Beyond that > it gets a bit implementation-specific. >=20 > I hope to do a thorough review of the config work by San Francisco, > though no promises, as it's a bit mad here at the moment. Will you be a= t > the meeting? No, unfortunately not. Cheers, Gerhard >=20 > Cheers, >=20 > Brian >=20 > On Mar 6, 2009, at 2:02 PM, Gerhard Muenz wrote: >=20 >> >> Hi Brian, >> >> Benoit reminded me that you promised some input regarding (D)TLS >> parameters that might be included into the configuration data model. >> http://www.ietf.org/proceedings/08nov/minutes/ipfix.txt >> >> Do you can still remember what you were thinking of? >> Probably the Fully Qualified Domain Name? >> >> If you are into this topic, maybe you can send a list with all common >> parameters - just to get an overview - and those that are interesting = to >> have in the configuration data model. For example, I assume that it is= >> not interesting to configure certificates - these are probably provide= d >> by different means to the devices. >> >> Gerhard >> >> --=20 >> Dipl.-Ing. Gerhard M=FCnz >> Chair for Network Architectures and Services (I8) >> Department of Informatics >> Technische Universit=E4t M=FCnchen >> Boltzmannstr. 3, 85748 Garching bei M=FCnchen, Germany >> Phone: +49 89 289-18008 Fax: +49 89 289-18033 >> E-mail: muenz@net.in.tum.de WWW: http://www.net.in.tum.de/~muenz >> >> >=20 --=20 Dipl.-Ing. Gerhard M=FCnz Chair for Network Architectures and Services (I8) Department of Informatics Technische Universit=E4t M=FCnchen Boltzmannstr. 3, 85748 Garching bei M=FCnchen, Germany Phone: +49 89 289-18008 Fax: +49 89 289-18033 E-mail: muenz@net.in.tum.de WWW: http://www.net.in.tum.de/~muenz --------------ms090606010902090605020808 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 SIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMDkwMzA2MTQxNTQ5WjAjBgkqhkiG9w0BCQQxFgQU dj4X7PA6l6nRED1zdZJPRoxVnJwwUgYJKoZIhvcNAQkPMUUwQzAKBggqhkiG9w0DBzAOBggq hkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwICASgwgYUG CSsGAQQBgjcQBDF4MHYwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0 aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1 aW5nIENBAhAqxerdN2XVRkUZsuk5IKdPMIGHBgsqhkiG9w0BCRACCzF4oHYwYjELMAkGA1UE BhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMT I1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBAhAqxerdN2XVRkUZsuk5IKdP MA0GCSqGSIb3DQEBAQUABIIBAEytOSoofTHGcc7jx+20ZyFk+Boy2JVBJ8rVoaxzFn77Bpro vDvC/YTFgCffyJ99Pb6AEk0w+JsfkOyQqZL4c6dtXnga0dSn7ygXsMRAaexnLNpOsGRANrBS AZEhLowvYdtRw0xzDOTFchjYPmraF1hgHgKQfP/hSoVJXMDQsM+84SnswfUVM8i9vduH8gk2 +hM3qwmJzxKMy21jESGUTYGLIoCHX4gCiXSqNEwAgFTnMmvH0MxpC2i5UIKSWebqYOpJzkz+ ag3I95zGOUnax4UDtEooRDZ9r6tofAII/1hzr8j7dIcFNBiQHyCX2UllWtEYJ+CWvemTJ58r 3IOPrngAAAAAAAA= --------------ms090606010902090605020808-- From trammell@tik.ee.ethz.ch Fri Mar 6 06:30:06 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 CA00B3A6C7C for ; Fri, 6 Mar 2009 06:30:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.299 X-Spam-Level: X-Spam-Status: No, score=-6.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_27=0.6, 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 mtht1ro+YN0v for ; Fri, 6 Mar 2009 06:30:05 -0800 (PST) Received: from smtp.ee.ethz.ch (smtp.ee.ethz.ch [129.132.2.219]) by core3.amsl.com (Postfix) with ESMTP id 789E33A6970 for ; Fri, 6 Mar 2009 06:30:05 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by smtp.ee.ethz.ch (Postfix) with ESMTP id 7D74DD93EA; Fri, 6 Mar 2009 15:30:34 +0100 (MET) 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 VQqOLGFwm+pJ; Fri, 6 Mar 2009 15:30:34 +0100 (MET) 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 3DEF3D9364; Fri, 6 Mar 2009 15:30:34 +0100 (MET) Message-Id: <1E797ED7-797A-4169-822B-45E674A912D1@tik.ee.ethz.ch> From: Brian Trammell To: Gerhard Muenz In-Reply-To: <49B13015.6070001@net.in.tum.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed; delsp=yes Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Apple Message framework v930.3) Date: Fri, 6 Mar 2009 15:30:33 +0100 References: <49B10249.9040500@cisco.com> <49B11ED6.9070706@net.in.tum.de> <49B13015.6070001@net.in.tum.de> X-Mailer: Apple Mail (2.930.3) Cc: "ipfix@ietf.org Working Group" Subject: Re: [IPFIX] IPFIX configuration: (D)TLS 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, 06 Mar 2009 14:30:06 -0000 On Mar 6, 2009, at 3:15 PM, Gerhard Muenz wrote: > > Hi Brian, > > Brian Trammell wrote: >> Hi, Gerhard, >> >> The main parameters I was thinking of are keying and identity >> parameters. Perhaps we can state that CPs and EPs will be keyed =20 >> offline, >> but at least it might be nice to change the names of the peers a =20 >> device >> is willing to communicate with. > > Who should restrict its willingness to communicate? The CP or the EP =20= > or > both? Per 5101, both. > Just using the name does not seem to be sufficient because the same =20= > name > could be used with several certificates, right? > So, it would be necessary to say: "CP accepts data from EP with name=3DX= > authorized by certificate/CA Y". By "name" I mean the Subject DN (Distinguished Name) defined by X.509 =20= is suited for this purpose (see 4, below). An example DN (from your =20 Thawte cert :) follows: SN=3DMuenz, GN=3DGerhard, CN=3DGerhard = Muenz/emailAddress=3Dmuenz@informatik.uni-tuebingen.de=20 /emailAddress=3Dmuenz@net.in.tum.de A CA SHOULD _never_ sign two different certificates with the same =20 validity for the same subject without an intervening revocation; =20 likewise nobody should ever treat the same certificate as useful for =20 multiple entities at the DN level. > Transporting certificates and keys to the devices does not seem to be > useful. However, if the device has several keys, it would be useful to > choose one of them. > > It seems that we need kind of abstract identifiers for keys and > certificates saved on a device in order to refer to them in the > configuration. X.509 DNs are used for this purpose. CNs (Common Names) can be used =20 for this in practice, but this is not recommended. Cheers, Brian >> For TLS, at minimum, an EP or CP must know: >> >> 1. its CA certificates (PEM/DER) >> 2. CA certificates for its peers' certificates (PEM/DER) (if not =20 >> using a >> single CA for all) >> 3. its own certificate and private key (PKCS#12) >> 4. the names of the peers it is willing to communicate with =20 >> (subjectName >> string) (if not assuming signature by a known CA is sufficient) >> 5. CRL or OCSP peer for revocation, if supported (which it should be, >> though 5101 doesn't state this directly) >> >> How much of that to support in config is an open question. Beyond =20 >> that >> it gets a bit implementation-specific. >> >> I hope to do a thorough review of the config work by San Francisco, >> though no promises, as it's a bit mad here at the moment. Will you =20= >> be at >> the meeting? > > No, unfortunately not. > > Cheers, > Gerhard > >> >> Cheers, >> >> Brian >> >> On Mar 6, 2009, at 2:02 PM, Gerhard Muenz wrote: >> >>> >>> Hi Brian, >>> >>> Benoit reminded me that you promised some input regarding (D)TLS >>> parameters that might be included into the configuration data model. >>> http://www.ietf.org/proceedings/08nov/minutes/ipfix.txt >>> >>> Do you can still remember what you were thinking of? >>> Probably the Fully Qualified Domain Name? >>> >>> If you are into this topic, maybe you can send a list with all =20 >>> common >>> parameters - just to get an overview - and those that are =20 >>> interesting to >>> have in the configuration data model. For example, I assume that =20 >>> it is >>> not interesting to configure certificates - these are probably =20 >>> provided >>> by different means to the devices. >>> >>> Gerhard >>> >>> --=20 >>> Dipl.-Ing. Gerhard M=FCnz >>> Chair for Network Architectures and Services (I8) >>> Department of Informatics >>> Technische Universit=E4t M=FCnchen >>> Boltzmannstr. 3, 85748 Garching bei M=FCnchen, Germany >>> Phone: +49 89 289-18008 Fax: +49 89 289-18033 >>> E-mail: muenz@net.in.tum.de WWW: http://www.net.in.tum.de/~muenz >>> >>> >> > > --=20 > Dipl.-Ing. Gerhard M=FCnz > Chair for Network Architectures and Services (I8) > Department of Informatics > Technische Universit=E4t M=FCnchen > Boltzmannstr. 3, 85748 Garching bei M=FCnchen, Germany > Phone: +49 89 289-18008 Fax: +49 89 289-18033 > E-mail: muenz@net.in.tum.de WWW: http://www.net.in.tum.de/~muenz > > From muenz@net.in.tum.de Fri Mar 6 07:08:11 2009 Return-Path: X-Original-To: ipfix@core3.amsl.com Delivered-To: ipfix@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CCFCD3A685C for ; Fri, 6 Mar 2009 07:08:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.606 X-Spam-Level: X-Spam-Status: No, score=-1.606 tagged_above=-999 required=5 tests=[AWL=-0.557, BAYES_00=-2.599, HELO_EQ_DE=0.35, J_CHICKENPOX_25=0.6, J_CHICKENPOX_27=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 r6BlFaZALMn1 for ; Fri, 6 Mar 2009 07:08:10 -0800 (PST) Received: from mail-out1.informatik.tu-muenchen.de (maildmz1.informatik.tu-muenchen.de [131.159.0.3]) by core3.amsl.com (Postfix) with ESMTP id 912413A6A3B for ; Fri, 6 Mar 2009 07:08:10 -0800 (PST) Received: from phoenix.net.informatik.tu-muenchen.de (phoenix.net.informatik.tu-muenchen.de [131.159.14.1]) by services.net.informatik.tu-muenchen.de (Postix Mailer @ mail) with ESMTP id EEF08483D4; Fri, 6 Mar 2009 16:08:32 +0100 (CET) Received: from [131.159.20.108] (repulse.net.informatik.tu-muenchen.de [131.159.20.108]) by phoenix.net.informatik.tu-muenchen.de (Postfix) with ESMTP id DC4C84458; Fri, 6 Mar 2009 16:08:32 +0100 (CET) Message-ID: <49B13C75.70004@net.in.tum.de> Date: Fri, 06 Mar 2009 16:08:37 +0100 From: Gerhard Muenz User-Agent: Thunderbird 2.0.0.19 (Windows/20081209) MIME-Version: 1.0 To: Brian Trammell References: <49B10249.9040500@cisco.com> <49B11ED6.9070706@net.in.tum.de> <49B13015.6070001@net.in.tum.de> <1E797ED7-797A-4169-822B-45E674A912D1@tik.ee.ethz.ch> In-Reply-To: <1E797ED7-797A-4169-822B-45E674A912D1@tik.ee.ethz.ch> Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms000301070406060107090103" X-Virus-Scanned: ClamAV using ClamSMTP Cc: "ipfix@ietf.org Working Group" Subject: Re: [IPFIX] IPFIX configuration: (D)TLS 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, 06 Mar 2009 15:08:11 -0000 This is a cryptographically signed message in MIME format. --------------ms000301070406060107090103 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi, >>> The main parameters I was thinking of are keying and identity >>> parameters. Perhaps we can state that CPs and EPs will be keyed offli= ne, >>> but at least it might be nice to change the names of the peers a devi= ce >>> is willing to communicate with. >> >> Who should restrict its willingness to communicate? The CP or the EP o= r >> both? >=20 > Per 5101, both. Ok. Own name and accepted peer names could be configured per CP/EP. >> Just using the name does not seem to be sufficient because the same na= me >> could be used with several certificates, right? >> So, it would be necessary to say: "CP accepts data from EP with name=3D= X >> authorized by certificate/CA Y". >=20 > By "name" I mean the Subject DN (Distinguished Name) defined by X.509 i= s > suited for this purpose (see 4, below). An example DN (from your Thawte= > cert :) follows: >=20 > SN=3DMuenz, GN=3DGerhard, CN=3DGerhard > Muenz/emailAddress=3Dmuenz@informatik.uni-tuebingen.de/emailAddress=3Dm= uenz@net.in.tum.de >=20 > A CA SHOULD _never_ sign two different certificates with the same > validity for the same subject without an intervening revocation; > likewise nobody should ever treat the same certificate as useful for > multiple entities at the DN level. Ok, as long you have a single CA. With two CAs, there can be two certificates with the same name for different subjects. But you usually trust the CAs and their practice to issue certificates :)= Gerhard >> Transporting certificates and keys to the devices does not seem to be >> useful. However, if the device has several keys, it would be useful to= >> choose one of them. >> >> It seems that we need kind of abstract identifiers for keys and >> certificates saved on a device in order to refer to them in the >> configuration. >=20 > X.509 DNs are used for this purpose. CNs (Common Names) can be used for= > this in practice, but this is not recommended. >=20 > Cheers, >=20 > Brian >=20 --=20 Dipl.-Ing. Gerhard M=FCnz Chair for Network Architectures and Services (I8) Department of Informatics Technische Universit=E4t M=FCnchen Boltzmannstr. 3, 85748 Garching bei M=FCnchen, Germany Phone: +49 89 289-18008 Fax: +49 89 289-18033 E-mail: muenz@net.in.tum.de WWW: http://www.net.in.tum.de/~muenz --------------ms000301070406060107090103 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 SIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMDkwMzA2MTUwODM3WjAjBgkqhkiG9w0BCQQxFgQU CrznVJtKLNk6Hqhyzi/FPSclYGQwUgYJKoZIhvcNAQkPMUUwQzAKBggqhkiG9w0DBzAOBggq hkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwICASgwgYUG CSsGAQQBgjcQBDF4MHYwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0 aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1 aW5nIENBAhAqxerdN2XVRkUZsuk5IKdPMIGHBgsqhkiG9w0BCRACCzF4oHYwYjELMAkGA1UE BhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMT I1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBAhAqxerdN2XVRkUZsuk5IKdP MA0GCSqGSIb3DQEBAQUABIIBAGF7+k4URcfK7EVyXWpbcyelopvDVhCaoHQU1BC87tifEqsH tOYV7KaNLnntGmAtQigZDhBc7spC5NgQAzdSCcC8tO2+WesXLvuZ1KFgA9dA78MZqu/a35Px EF45/Nzky4K3QclE0/fNOusslqb89IoMfl1ryImXrgZobSO+jL55DXdfxtD1c2lqN+Kid/sE qAMthP6UCxlxkdW5P5hcDRPr1ESuG8pD2eXlesbF8y++sOY3/SeACzswLVE0mn9FRMMluQQg XB1T6bslDYsrqRo9UHzaQUcGDvpAEgA07f2lsp9yQCGCZfsKjrRLP/1e1OCSMVC6WS9T3xN8 MB3ExbgAAAAAAAA= --------------ms000301070406060107090103-- From trammell@tik.ee.ethz.ch Fri Mar 6 07:10:36 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 9CD0A3A6C52 for ; Fri, 6 Mar 2009 07:10:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.924 X-Spam-Level: X-Spam-Status: No, score=-5.924 tagged_above=-999 required=5 tests=[AWL=-0.525, BAYES_00=-2.599, J_CHICKENPOX_25=0.6, J_CHICKENPOX_27=0.6, 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 z6c98poOMBUu for ; Fri, 6 Mar 2009 07:10:35 -0800 (PST) Received: from smtp.ee.ethz.ch (smtp.ee.ethz.ch [129.132.2.219]) by core3.amsl.com (Postfix) with ESMTP id 70F4C3A685C for ; Fri, 6 Mar 2009 07:10:35 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by smtp.ee.ethz.ch (Postfix) with ESMTP id 75E7CD93E2; Fri, 6 Mar 2009 16:11:04 +0100 (MET) 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 W8MnH1WuAM8v; Fri, 6 Mar 2009 16:11:04 +0100 (MET) 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 34140D93DD; Fri, 6 Mar 2009 16:11:04 +0100 (MET) Message-Id: <2A9198A6-8FF0-471D-A8F0-D605A3CEE707@tik.ee.ethz.ch> From: Brian Trammell To: Gerhard Muenz In-Reply-To: <49B13C75.70004@net.in.tum.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed; delsp=yes Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Apple Message framework v930.3) Date: Fri, 6 Mar 2009 16:11:03 +0100 References: <49B10249.9040500@cisco.com> <49B11ED6.9070706@net.in.tum.de> <49B13015.6070001@net.in.tum.de> <1E797ED7-797A-4169-822B-45E674A912D1@tik.ee.ethz.ch> <49B13C75.70004@net.in.tum.de> X-Mailer: Apple Mail (2.930.3) Cc: "ipfix@ietf.org Working Group" Subject: Re: [IPFIX] IPFIX configuration: (D)TLS 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, 06 Mar 2009 15:10:36 -0000 On Mar 6, 2009, at 4:08 PM, Gerhard Muenz wrote: > > Hi, > >>>> The main parameters I was thinking of are keying and identity >>>> parameters. Perhaps we can state that CPs and EPs will be keyed =20 >>>> offline, >>>> but at least it might be nice to change the names of the peers a =20= >>>> device >>>> is willing to communicate with. >>> >>> Who should restrict its willingness to communicate? The CP or the =20= >>> EP or >>> both? >> >> Per 5101, both. > > Ok. Own name and accepted peer names could be configured per CP/EP. > >>> Just using the name does not seem to be sufficient because the =20 >>> same name >>> could be used with several certificates, right? >>> So, it would be necessary to say: "CP accepts data from EP with =20 >>> name=3DX >>> authorized by certificate/CA Y". >> >> By "name" I mean the Subject DN (Distinguished Name) defined by X.=20 >> 509 is >> suited for this purpose (see 4, below). An example DN (from your =20 >> Thawte >> cert :) follows: >> >> SN=3DMuenz, GN=3DGerhard, CN=3DGerhard >> = Muenz/emailAddress=3Dmuenz@informatik.uni-tuebingen.de/emailAddress=3Dmuen= z@net.in.tum.de >> >> A CA SHOULD _never_ sign two different certificates with the same >> validity for the same subject without an intervening revocation; >> likewise nobody should ever treat the same certificate as useful for >> multiple entities at the DN level. > > Ok, as long you have a single CA. With two CAs, there can be two > certificates with the same name for different subjects. > But you usually trust the CAs and their practice to issue =20 > certificates :) In this case, you can qualify the DN of the Subject with the DN of the =20= Issuer (CA), and you have a (theoretically :) ) globally unique =20 identifier... > > Gerhard > >>> Transporting certificates and keys to the devices does not seem to =20= >>> be >>> useful. However, if the device has several keys, it would be =20 >>> useful to >>> choose one of them. >>> >>> It seems that we need kind of abstract identifiers for keys and >>> certificates saved on a device in order to refer to them in the >>> configuration. >> >> X.509 DNs are used for this purpose. CNs (Common Names) can be used =20= >> for >> this in practice, but this is not recommended. >> >> Cheers, >> >> Brian >> > > --=20 > Dipl.-Ing. Gerhard M=FCnz > Chair for Network Architectures and Services (I8) > Department of Informatics > Technische Universit=E4t M=FCnchen > Boltzmannstr. 3, 85748 Garching bei M=FCnchen, Germany > Phone: +49 89 289-18008 Fax: +49 89 289-18033 > E-mail: muenz@net.in.tum.de WWW: http://www.net.in.tum.de/~muenz > > From n.brownlee@auckland.ac.nz Sun Mar 8 20:44:43 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 BE61D3A6A7C for ; Sun, 8 Mar 2009 20:44:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.099 X-Spam-Level: X-Spam-Status: No, score=-5.099 tagged_above=-999 required=5 tests=[AWL=-1.500, 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 nf2vMdNSyeaR for ; Sun, 8 Mar 2009 20:44:42 -0700 (PDT) Received: from mailhost.auckland.ac.nz (curly.its.auckland.ac.nz [130.216.12.33]) by core3.amsl.com (Postfix) with ESMTP id 385953A694E for ; Sun, 8 Mar 2009 20:44:40 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by mailhost.auckland.ac.nz (Postfix) with ESMTP id F281B9E615 for ; Mon, 9 Mar 2009 16:45:12 +1300 (NZDT) 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 TlVsE58cqMyE for ; Mon, 9 Mar 2009 16:45:12 +1300 (NZDT) 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 BE1159E00D for ; Mon, 9 Mar 2009 16:45:08 +1300 (NZDT) Message-ID: <49B490C4.4000407@auckland.ac.nz> Date: Mon, 09 Mar 2009 16:45:08 +1300 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] Updated agenda for San Francisco meeting 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, 09 Mar 2009 03:44:43 -0000 Hi all: If you have any further changes, please send them to me pronto :-) Cheers, Nevil ====================================================== Ip Flow Information Export WG (ipfix) IETF #74, San Francisco Monday, 23 Mar 09 at 1300-1500 ====================================================== Chairs: Juergen Quittek Nevil Brownlee >>> DRAFT <<< AGENDA: 1. Agenda review WG Status = 5 min 2. Internet-Draft status = 5 min [In RFC Editor queue: - draft-ietf-ipfix-architecture-12.txt - draft-ietf-ipfix-as-12.txt - draft-ietf-ipfix-reducing-redundancy-04.txt - draft-ietf-ipfix-testing-04.txt - draft-ietf-psamp-framework-13.txt - draft-ietf-psamp-sample-tech-10.txt - draft-ietf-psamp-protocol-09.txt - draft-ietf-psamp-info-11.txt] 3. Information Element Registry status = 5 min IANA's XML page for this are now at http://www.iana.org/assignments/ipfix/ipfix.xhtml We are now handling errata found in RFC 5102, IANA should change the registry for such changes; We need to establish a procedure for handling changes in other IEs 4. Drafts submitted to IESG = 15 min a) IPFIX File Format (Brian Trammell) ( 3 min) - draft-ietf-ipfix-file-03.txt 24 Oct 08 b) Exporting Type Information for IPFIX IEs (Elisa Boschi) - draft-ietf-ipfix-exporting-type-02.txt 14 Jul 08 ( 3 min) c) IPFIX MIB (Thomas Dietz) - draft-dietz-ipfix-mib-05.txt 3 Nov 08 MIB Doctors have requested a revised draft ( 9 min) 5. Current WG drafts = 50 min a) IPFIX Per-Stream SCTP reporting (Benoit CLaise) ( 5 min) - draft-ietf-ipfix-export-per-sctp-stream-02.txt 26 Jan 09 b) Configuration Data Model ( 5 min) - draft-ietf-ipfix-configuration-model-01.txt 3 Nov 08 c) IPFIX Mediation: (Kobayashi Atsushi) (15 min) - draft-ietf-ipfix-mediators-problem-statement-02.txt 4 Feb 09 - draft-ietf-ipfix-mediators-framework-02.txt (25 min) 10 Feb 09 6. Other drafts = 30 min a) Flow Selection (Lorenzo Peluso, Tanja Zseby) (10 min) - draft-peluso-flowselection-tech-02 b) IP Flow Anonymization Support (Elisa Bschi, Brian Trammel) - draft-boschi-ipfix-anon-02 12 Jan 09 (10 min) c) Handling Structured Data (Benoit Claise) - draft-claise-structured-data-in-ipfix-00.txt (10 min) 7. Any Other Drafts ??? = 10 min Presentation slides will be available at https://datatracker.ietf.org/public/meeting_materials.cgi?meeting_num=74 (search for IPFIX in the Operations and Management Area) Participation via jabber is offered at ipfix@jabber.ietf.org -- --------------------------------------------------------------------- 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 root@core3.amsl.com Mon Mar 9 04:00: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 D67E03A6C36; Mon, 9 Mar 2009 04:00: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: <20090309110001.D67E03A6C36@core3.amsl.com> Date: Mon, 9 Mar 2009 04:00:01 -0700 (PDT) Cc: ipfix@ietf.org Subject: [IPFIX] I-D Action:draft-ietf-ipfix-mib-06.txt X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Mar 2009 11:00:01 -0000 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IP Flow Information Export Working Group of the IETF. Title : Definitions of Managed Objects for IP Flow Information Export Author(s) : T. Dietz, et al. Filename : draft-ietf-ipfix-mib-06.txt Pages : 63 Date : 2009-03-09 This document defines managed objects for IP Flow Information Export (IPFIX). These objects provide information for monitoring IPFIX Exporters and IPFIX Collectors including the basic configuration information. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ipfix-mib-06.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-ipfix-mib-06.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2009-03-09035911.I-D@ietf.org> --NextPart-- From Thomas.Dietz@nw.neclab.eu Mon Mar 9 04:25:29 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 3325728C0FF; Mon, 9 Mar 2009 04:25:29 -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 g-5kFFb6wAHQ; Mon, 9 Mar 2009 04:25:20 -0700 (PDT) Received: from smtp0.neclab.eu (smtp0.neclab.eu [195.37.70.41]) by core3.amsl.com (Postfix) with ESMTP id D377328C16E; Mon, 9 Mar 2009 04:25:19 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp0.neclab.eu (Postfix) with ESMTP id 6CF7F2C01CA1A; Mon, 9 Mar 2009 12:25:53 +0100 (CET) X-Virus-Scanned: Amavisd on Debian GNU/Linux (atlas2.office) Received: from smtp0.neclab.eu ([127.0.0.1]) by localhost (atlas2.office [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VuUBbEH3lqmX; Mon, 9 Mar 2009 12:25:53 +0100 (CET) Received: from VENUS.office (mx2.office [192.168.24.15]) by smtp0.neclab.eu (Postfix) with ESMTP id 428402C00030D; Mon, 9 Mar 2009 12:25:38 +0100 (CET) Content-class: urn:content-classes:message MIME-Version: 1.0 X-MimeOLE: Produced By Microsoft Exchange V6.5 Date: Mon, 9 Mar 2009 12:25:36 +0100 Content-Type: multipart/signed; micalg=SHA1; boundary="----=_NextPart_000_03FE_01C9A0B2.260B2FE0"; protocol="application/x-pkcs7-signature" Message-ID: <547F018265F92642B577B986577D671C7009CF@VENUS.office> In-Reply-To: X-MS-Has-Attach: yes X-MS-TNEF-Correlator: Thread-Topic: [IPFIX] AD review of draft-ietf-ipfix-mib-05.txt thread-index: AcmRHJmf24PVuTAzTrOZoe2H0CfpvQPihcJA References: From: "Thomas Dietz" To: "Romascanu, Dan \(Dan\)" , "IETF IPFIX Working Group" Cc: "MIB Doctors \(E-mail\)" Subject: Re: [IPFIX] AD review of draft-ietf-ipfix-mib-05.txt 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, 09 Mar 2009 11:25:29 -0000 This is a multipart message in MIME format. ------=_NextPart_000_03FE_01C9A0B2.260B2FE0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Dear Dan, all, find my comments inline... -- Thomas Dietz E-mail: Thomas.Dietz@nw.neclab.eu NEC Europe Ltd. Phone: +49 6221 4342-128 NEC Laboratories Europe Fax: +49 6221 4342-155 Network Research Division Kurfuersten-Anlage 36 69115 Heidelberg, Germany http://www.nw.neclab.eu NEC Europe Limited Registered in England 2832014 Registered Office: NEC House, 1 Victoria Road, London W3 6BL > -----Original Message----- > From: ipfix-bounces@ietf.org [mailto:ipfix-bounces@ietf.org] On Behalf > Of Romascanu, Dan (Dan) > Sent: Dienstag, 17. Februar 2009 17:27 > To: IETF IPFIX Working Group > Cc: MIB Doctors (E-mail) > Subject: [IPFIX] AD review of draft-ietf-ipfix-mib-05.txt > > Please find below the AD (and MIB doctor) review of > draft-ietf-ipfix-mib-05.txt. This I-D is not ready yet for IETF Last > Call. Please address the issues below and issue a new I-D. > > Part of the comments were contributed by Bert Wijnen. > > I have divided the comments into Technical and Editorial. > > Thanks and Regards, > > Dan > > > T1. INET-ADDRESS-MIB is IMPORT-ed from RFC 4001and not from RFC 3291 Fixed. > > T2. There is no real justification for defining a new TC for > IpfixFunctionAvailability. As per RFC 4181, use TruthValue instead. > You are right. Fixed. > T3. The top level structure of the MIB does not follow the > recommendation in Appendix D of RFC 4181 concerning the OID layout: > > xxxMIB > | > +-- xxxNotifications(0) > +-- xxxObjects(1) > +-- xxxConformance(2) > | > +-- xxxCompliances(1) > +-- xxxGroups(2) > Fixed as well. > T4. The object iffixTransportSessionProtocol uses only 3 out of the 255 > possible values in the range (6, 17, 132). A better SYNTAX would be > just > INTEGER and then enumerate the three values in the MODULE-COMPLIANCE > clause. This would allow future changes by just another > MODULE-COMPLIANCE if there is a need to add a new protocol. If you > believe that another transport will be never added the appropriate > SYNTAX would be INTEGER (6|17|132). Also provide > http://www.iana.org/assignments/protocol-numbers/protocol-numbers.xhtml > as REFERENCE. > I have put that into the module compliance section. > T5. There is only one InetAddressType object for both source and > destination addresses. Does this mean that an IPFIX session is only > IPv4 > to IPv4 or IPv6 to IPv6? This is a question, I apologize if it is a > layman one. In any case, it would be good to write an explanation, as > users of the RFC 4001 addresses TCs are used to always encounter pairs > of type-address objects. Just a mistake by myself. I added a object for source and destination address. > > T6. Why are the address type and addresses objects only valid for UDP > and TCP, and not for SCTP? Are not STCP session also conducted between > IP hosts that can be described by IP addresses? > Because we use the SCTP Association Id defined in the SCTP MIB for that. Thus the SCTP MIB holds IPs and ports for the association Id. Clarified that in the description. > T7. What does 'this object is only valid' mean for the address type and > addresses objects? What is returned by the agent in this case on a Get > operation on these objects? > Also made this clear. > T8. The InetPort TC IMPORT-ed from RFC 4001 looks like a more > appropriate SYNTAX for the ipfixTransportSessionSourcePort and > ipfixTransportSessionDestinationPort objects > You are right again. Fixed. > T9. I cannot figure out what is the role of all the DEFVAL clauses in > this MIB module. All the MIB is read-only and there is no dynamic row > creation. Why are they needed? > You are right again. Since we first discussed if the MIB should be writable or not this is a remainder of these times. > T10. Many of the objects in the MIB modules - especially counters and > gauges - would benefit from defining UNITS clauses. In some places they > are mentioned in the DESCRIPTION clauses, but using explicit UNITS > clauses wherever possible is better. > Added where I thought it is applicable. > T11. Some object names in table do not respect the naming conventions > that recommends that table names and objects have an identical suffix - > ipfixObservationDomainId, ipfixObservationPointGroupReference, > ipfixPhysicalEntity, ipfixPhysicalEntityDirection > Fixed. > T12. Some objects are completely missing REFERENCE clauses - especially > in the first tables o the MIB. Some other clauses could benefit from > more exact referencing, saying just [RFC5101] without mentioning the > exact section is not very useful. > Added where applicable. Improved if possible. > T13. Why is the range of ipfixTemplateDefinitionLength 1..2147483547)? > According to RFC 5101, section 7, page 31 it looks like it should be > (0..65535) > Fixed. > T14. Give http://www.iana.org/assignments/enterprise-numbers/ as > REFERENCE for ipfixTemplateDefinitionEnterprise > Done. > T15. Use hex notations for describing values in the DESCRIPTION clause > of ipfixTemplateDefintionFlags - the decimal values do not correspond > to > the bits positions > Done. > T16. ipfixExportEntry leads to a warning in the smicng compilation > > W: f(ipfix.mi2), (676,12) Row "ipfixExportEntry" does not have a > consistent indexing scheme - index items from current table must come > after index items from other tables > Since I have only libsmi (which does not catch this) I did not realize it. Fixed. > T17. A couple of enumerated objects start to value 0 which is not > recommended unless special cases. Are there special cases here for > ipfixExportMemberType and ipfixPhysicalEntityDirection > Well, those cases indicate an unknown value which I think is a special case and the same as in the TC InetAddressType. > T18. Unsigned32 seems to be a better SYNTAX than Integer32 (see RFC > 4181) for the following objects: ipfixMeteringProcessId, > ipfixObservationPointGroupReference, ipfixObservationPointIndex, > ipfixTransportSessionRate > Changed all types to Unsigned32 where possible. > T19. I cannot understand what useful information carries > ipfixmeteringProcessId - it is not an index and its value is > implementation dependent. We wanted to give a kind of ID to make it possible to identify the process that creates the Flow Records. This may be a process id or something similar. Maybe we should specify it as process id. This needs further discussion. > > T20. Does it make sense for the ipfixSelectorFunction to point to a > function that is not available? > Basically it doesn't. But we wanted to have the possibility to have a list of Selector Functions that are basically available (and thus present in the MIB tree) but may be disabled somehow. > T21. I assume that selection functions will be added in the future. If > I > am wrong please delete all mention of extensibility and take out the > ipfixSelectorFunctions group. If I am right, I suggest to put > ipfixSelectorFunctions in a separate MIB module that will be IANA > maintained, so that new functions can be added in the future without > the > need to revise the MIB module and the RFC. The separate MIB module will > become the initial version of the IANA maintained module, and new > selector functions will be added using for example Expert Review > policy. > > I personally think this makes sense to put it in a separate MIB module which is maintained by IANA but this needs further discussion on the list which I will start soon. > T22. it looks like Gauge32 would be a better SYNTAX for the following > objects: ipfixTransportSessionRate, > ipfixMeteringProcessCacheActiveFlows, ipfixMetering > ProcessCacheInactiveFlows > Changed whereever applicable. > T23. How is ipfixTransportSessionRate computed? Every second? Every T > seconds? T=? > I fixed this to one second intervals. Benoit, Atsushi any objections?? > T24. I am wondering whether more counters in this MIB module need to be > Counter64 rather than Counter32 - especially the bytes and packets > counters > Made all Counters Counter64. > T25. There is no definition of the discontinuity behavior of all the > counter objects or definition of discontinuity objects. > > T26. It looks like Counter32 (or Counter64) with the appropriate > discontinuity objects are better SYNTAX for > ipfixSelectorStatsPacketsObserved and ipfixSelectorStatspacketsDropped. > Added discontinuity objects and fixed the two issues above. > T27. Some of the DESCRIPTION clauses of the OBJECT-GROUPs contain > statements about the mandatory or optional characteristics of the > objects. This is inappropriate, such statements must be made in > MODULE-COMPLIANCE definitions, not in OBJECT-GROUP. > Fixed. > T.28. Security Consideration sections - The description of the > vulnerability of objects in the tables should be more precise than > 'contains configuration data that might be sensitive'. > Changed. I also fixed the text issues below. Dan, please review version 06 if all your issues are fixed except those which I marked under discussion above. Thanks, Thomas > > E1. Section 5.1 s/is defined in the MIB/is defined in the MIB module/ > > E2. The language in the sub-section of section 5 may be polished - for > example in section 5.3 and 5.4 s/may want to export/is configured to > export/ > > E3. Section 5.6 s/consists of a set of function/consists of a set of > functions/ > > E4. Section 5.6 - 'the Metering Process table (ipfixMetering > ProcessTable) is grouped by maintained by ...' - this phrase needs to > be > fixed. > > E5. Section 6.1 - s/they should also implement the ENTITY MIB/they > SHOULD also implement the ENTITY MIB/ > > E6. Section 6.1 s/all entries in the Observation Point Table contain an > ipfixPhysicalEntity of zero(0)/all values of the ipfixPhysicalEntity > columns in the ipfixObservationPointTable are 0 and the values of the > ipfixPhysicalEntityDirection columns are none(0). > > E7. The DESCRIPTION clause and the name of the object > ipfixTransportSessionMode seem mis-leading. I think that this object > describes the device role in a session, not the mode of the session in > other words it's an attribute of the device that runs the agent and not > of the session. > > E8. The DESCRIPTION clause of the ipfixTemplateAccessTime object is > confusing. The second and third paragraph seem to duplicate the content > of the first paragraph. The last phrase of the clause seems to belong > rather in the DESCRIPTION clause of the table than here. > > E9. DESCRIPTION clause of ipfixObservationPointIndex - is this > 'management system' or rather 'management agent'? > > E10. DESCRIPTION clause of ipfixPhysicalEntity s/the object contains > 0/the value of the object is 0/ > > E11. What does 'a direction is not applicable' mean in the DESCRIPTION > clause of ipfixPhysicalEntityDirection? > > > _______________________________________________ > IPFIX mailing list > IPFIX@ietf.org > https://www.ietf.org/mailman/listinfo/ipfix ------=_NextPart_000_03FE_01C9A0B2.260B2FE0 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIISNzCCA58w ggKHoAMCAQICASYwDQYJKoZIhvcNAQEFBQAwcTELMAkGA1UEBhMCREUxHDAaBgNVBAoTE0RldXRz Y2hlIFRlbGVrb20gQUcxHzAdBgNVBAsTFlQtVGVsZVNlYyBUcnVzdCBDZW50ZXIxIzAhBgNVBAMT GkRldXRzY2hlIFRlbGVrb20gUm9vdCBDQSAyMB4XDTk5MDcwOTEyMTEwMFoXDTE5MDcwOTIzNTkw MFowcTELMAkGA1UEBhMCREUxHDAaBgNVBAoTE0RldXRzY2hlIFRlbGVrb20gQUcxHzAdBgNVBAsT FlQtVGVsZVNlYyBUcnVzdCBDZW50ZXIxIzAhBgNVBAMTGkRldXRzY2hlIFRlbGVrb20gUm9vdCBD QSAyMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAqwujNeCLKRSxFIWvPBDkOW81XUqu 3ephjZVJ9G9koxpgZqSpQCKE2dSl5XiTDmgBrblNXDrO07ioQkDfz6O6gllqkhusHJraCCslJ/lp I0fx4Ossepv1EwLQfjR8wp48AFmr9doM9TI8K6xQ2tbD3oOUyqgMmTIOCEhWW2r72uFYWAFJX3JB PBUGAY5draq4k7TNnuun6GotUjTbOu9cdVHa2/Mx+e5xmDLEVBVEDPmbVe2t3xgIoKOGiknuUwWP GUzV3lh5m9JqHEKrxdWnz2gPluThYZh2YciRfNY+AOKRUIfhnQrmrZfSHcY6fcu82gM01Y5bAfVq B7cWtm5KfwIDAQABo0IwQDAdBgNVHQ4EFgQUMcN5G7r1U9cX4Il6LRdsCrMrnTMwDwYDVR0TBAgw BgEB/wIBBTAOBgNVHQ8BAf8EBAMCAQYwDQYJKoZIhvcNAQEFBQADggEBAJRkWa05ZOcp6xP+WsOL E1fIBCTwdHfAYONn++mJpoO/loJ8btTDPe+egG67KbSYerE7VOs5F0d+Go4L/B8xWTEEss4X8yzH YjZV4iLYiVW0mEiqZPrWHDbYRHhaWiM6V5f1ejBPrp9qTEsrjqAD4z7gqdTSe9KzqOJyPK2e/4BZ 5JtFtPY7sM05GZgy5eohYZDkMSGONLH3LzVKhRDa54o3Ib5ZY+DyhYgxU9RUFIVwefQuBncndS8f uIr5/sW62Dbkg+znZbe/Y1rzRq+BlDfUQYzWI9Yez/VoG0Rjolq6pzVZoeVwBZsOI1eZlAptujlj KIaS8xiE2PvRzwVWZFcwggQhMIIDCaADAgECAgIAxzANBgkqhkiG9w0BAQUFADBxMQswCQYDVQQG EwJERTEcMBoGA1UEChMTRGV1dHNjaGUgVGVsZWtvbSBBRzEfMB0GA1UECxMWVC1UZWxlU2VjIFRy dXN0IENlbnRlcjEjMCEGA1UEAxMaRGV1dHNjaGUgVGVsZWtvbSBSb290IENBIDIwHhcNMDYxMjE5 MTAyOTAwWhcNMTkwNjMwMjM1OTAwWjBaMQswCQYDVQQGEwJERTETMBEGA1UEChMKREZOLVZlcmVp bjEQMA4GA1UECxMHREZOLVBLSTEkMCIGA1UEAxMbREZOLVZlcmVpbiBQQ0EgR2xvYmFsIC0gRzAx MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA6ZvDZ4X5Da71jVTDllA1PWLpbkztlNcA W5UidNQg6zSP1uzAMQQLmYHiphTSUqAoI4SLdIkEXlvg4njBeMsWyyg1OXstkEXQ7aAAeny/Sg4b AMOG6VwrMRF7DPOCJEOMHDiLamgAmu7cT3ir0sYTm3at7t4m6O8Br3QPwQmi9mvOvdPNFDBP9eXj pMhim4IaAycwDQJlYE3t0QkjKpY1WCfTdsZxtpAdxO3/NYZ9bzOz2w/FEcKKg6GUXUFr2NIQ9Uz9 ylGs2b3vkoO72uuLFlZWQ8/h1RM9ph8nMM1JVNvJEzSacXXFbOqnC5j5IZ0nrz6jOTlIaoytyZn7 wxLyvQIDAQABo4HZMIHWMHAGA1UdHwRpMGcwZaBjoGGGX2h0dHA6Ly9wa2kudGVsZXNlYy5kZS9j Z2ktYmluL3NlcnZpY2UvYWZfRG93bmxvYWRBUkwuY3JsPy1jcmxfZm9ybWF0PVhfNTA5Ji1pc3N1 ZXI9RFRfUk9PVF9DQV8yMB0GA1UdDgQWBBRJt8bP6D0ff+pEexMp9/EKcD7eZDAfBgNVHSMEGDAW gBQxw3kbuvVT1xfgiXotF2wKsyudMzAOBgNVHQ8BAf8EBAMCAQYwEgYDVR0TAQH/BAgwBgEB/wIB AjANBgkqhkiG9w0BAQUFAAOCAQEAO+Fad8BIF9ypGOyBr1qJ8L0okqbKWRgScOwo8ueuf5Ys5/Jd GTH2Eyt0vb2Asrn3Z8k5onk74RER7mt4kTN+O18mJ3VTZY4zY+7Pc8OwkiNJIVB1I6EfGOKUhT0/ M+l3II2iveahhSlA9j9zMlgNCWum2oVswD+7jWZkViROrg0/MjUBW+mMgtlyWU+xhoXxdIVW5cP4 XPON7kezUwVw5+VNimmDKOETCYaeXsjqWB4MH/mk1FoEaP0oPosCtli19qEsN1cAZ6sjaI1jpe+Z a1z9S1b2q0CHNNQRkmzsh8UKCwczcrRvDB1ULNhRx8y/MNNDcvEyv4zOSWOoAPfyHDCCBS8wggQX oAMCAQICBA0hCkcwDQYJKoZIhvcNAQEFBQAwWjELMAkGA1UEBhMCREUxEzARBgNVBAoTCkRGTi1W ZXJlaW4xEDAOBgNVBAsTB0RGTi1QS0kxJDAiBgNVBAMTG0RGTi1WZXJlaW4gUENBIEdsb2JhbCAt IEcwMTAeFw0wODEwMjQwODUyMDhaFw0xOTA2MzAwMDAwMDBaMIGQMQswCQYDVQQGEwJERTEYMBYG A1UEChMPTkVDIEV1cm9wZSBMdGQuMSAwHgYDVQQLExdORUMgTGFib3JhdG9yaWVzIEV1cm9wZTES MBAGA1UEAxMJTkVDTEFCLUNBMTEwLwYJKoZIhvcNAQkBFiJ6ZXJ0aWZpemllcnVuZ3NzdGVsbGVA bncubmVjbGFiLmV1MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAnvIVsbURqjIOcbnf ruYkRceWOZpyvM2ebnYpbd1cP+zdWm6yR7HSO9ppOe1ZZFIasArqQpedPEFvcncSG94FRuW3ND4r Rcq08mbpUTmpWmXfdYlJpQezbsOHCWR74NXoEEbK6TPZIMFpJr6dzQDAxnRc7UOgO6JQ1V42Z39B PhIbPIWz64t8svafxbORmxulJn7F5zDLDcR1AEGyn+L9b645AGwapoKNh7cSQFTqdb6kGyPQjLWf tv09dvmBDKesrcyLZXuDWJ1LMeizSjUEygdSszNXD3gePgJaVaZDS3o923W5gAyPCTSxpAFj8XJ+ /7Ap5jJwYhjJgJ8khFR7JQIDAQABo4IBxDCCAcAwEgYDVR0TAQH/BAgwBgEB/wIBATALBgNVHQ8E BAMCAQYwHQYDVR0OBBYEFE8ch3od4C+Z9r4VqtE1nQ5K5ro2MB8GA1UdIwQYMBaAFEm3xs/oPR9/ 6kR7Eyn38QpwPt5kMC0GA1UdEQQmMCSBInplcnRpZml6aWVydW5nc3N0ZWxsZUBudy5uZWNsYWIu ZXUwgYgGA1UdHwSBgDB+MD2gO6A5hjdodHRwOi8vY2RwMS5wY2EuZGZuLmRlL2dsb2JhbC1yb290 LWNhL3B1Yi9jcmwvY2FjcmwuY3JsMD2gO6A5hjdodHRwOi8vY2RwMi5wY2EuZGZuLmRlL2dsb2Jh bC1yb290LWNhL3B1Yi9jcmwvY2FjcmwuY3JsMIGiBggrBgEFBQcBAQSBlTCBkjBHBggrBgEFBQcw AoY7aHR0cDovL2NkcDEucGNhLmRmbi5kZS9nbG9iYWwtcm9vdC1jYS9wdWIvY2FjZXJ0L2NhY2Vy dC5jcnQwRwYIKwYBBQUHMAKGO2h0dHA6Ly9jZHAyLnBjYS5kZm4uZGUvZ2xvYmFsLXJvb3QtY2Ev cHViL2NhY2VydC9jYWNlcnQuY3J0MA0GCSqGSIb3DQEBBQUAA4IBAQBsMQ+dD0mmi48dgDU4R6Q/ eXcY0zQcHNp1Vu1s3kwO0WahWB0tiqVBodvfTAWG44xuw0I7NXSTwQ68FU5P0GIQnvRFZyVJlDjr SNlLYxjqfmgb+KVm67o383cZIuDakEE0f29kULIEn2fg/HsDiBAXTsb4I19XaN0TXLI+PMhU+GDp sGCJrydeugEV7qi15q8yymjSAsYgnrc2wJuXpyQ9r3qCtP6aedAPSHqOT8ga1dLT2YRZFs3vNm7T HSr5JJymWMbfpD6OcbRTnNAjSMDHwJxgRBAflA6WzDVm7fk4jiWyLvJwWTMk19t8QLiKG7D0nYvj cEUYyiOSE+SFUTEdMIIFODCCBCCgAwIBAgIEDTI0WzANBgkqhkiG9w0BAQUFADCBkDELMAkGA1UE BhMCREUxGDAWBgNVBAoTD05FQyBFdXJvcGUgTHRkLjEgMB4GA1UECxMXTkVDIExhYm9yYXRvcmll cyBFdXJvcGUxEjAQBgNVBAMTCU5FQ0xBQi1DQTExMC8GCSqGSIb3DQEJARYiemVydGlmaXppZXJ1 bmdzc3RlbGxlQG53Lm5lY2xhYi5ldTAeFw0wODExMDYwOTIwMTFaFw0xMTExMDYwOTIwMTFaMGAx CzAJBgNVBAYTAkRFMRgwFgYDVQQKEw9ORUMgRXVyb3BlIEx0ZC4xIDAeBgNVBAsTF05FQyBMYWJv cmF0b3JpZXMgRXVyb3BlMRUwEwYDVQQDEwxUaG9tYXMgRGlldHowggEiMA0GCSqGSIb3DQEBAQUA A4IBDwAwggEKAoIBAQCniLuqlMflMs7ag3idESVRwfZ9nrdIyUmq5Tget4k9APGSPo2GZ1f1hr8y MuJIGowc/HzS1laVSICclOXju1xW93Tm+Vco5gwkRqHXY3Rmda0r2jlb8niVie4qXQgXPzunFRqk yNmbwYep3oD5Kq0GfB6EuZ7X6cYH5A7erAMeeQPhoDQDIfR79lRHlcMtanJZyORYNQONPEa+L4AF v5f3nAsmY7ZLJ72wX7X8BtcF6Vdkr0T2b1YrPl8Qir7e0TKY9Rf0q5DKu3QdLnXk0Rb+63V/4vLS PZ3XQVdwHzLiOhIZJVVMJE7TmJI0DFeDFn99O/F/Le/sJOJjNO4n6KMLAgMBAAGjggHHMIIBwzAJ BgNVHRMEAjAAMAsGA1UdDwQEAwIF4DApBgNVHSUEIjAgBggrBgEFBQcDAgYIKwYBBQUHAwQGCisG AQQBgjcUAgIwHQYDVR0OBBYEFLkbmpJJpIXhIR9JFttGC+KHW5g5MB8GA1UdIwQYMBaAFE8ch3od 4C+Z9r4VqtE1nQ5K5ro2MCQGA1UdEQQdMBuBGVRob21hcy5EaWV0ekBudy5uZWNsYWIuZXUwfQYD VR0fBHYwdDA4oDagNIYyaHR0cDovL2NkcDEucGNhLmRmbi5kZS9uZWNsYWItY2EvcHViL2NybC9j YWNybC5jcmwwOKA2oDSGMmh0dHA6Ly9jZHAyLnBjYS5kZm4uZGUvbmVjbGFiLWNhL3B1Yi9jcmwv Y2FjcmwuY3JsMIGYBggrBgEFBQcBAQSBizCBiDBCBggrBgEFBQcwAoY2aHR0cDovL2NkcDEucGNh LmRmbi5kZS9uZWNsYWItY2EvcHViL2NhY2VydC9jYWNlcnQuY3J0MEIGCCsGAQUFBzAChjZodHRw Oi8vY2RwMi5wY2EuZGZuLmRlL25lY2xhYi1jYS9wdWIvY2FjZXJ0L2NhY2VydC5jcnQwDQYJKoZI hvcNAQEFBQADggEBAEbKwRBhNxAzsH6kAYRBoIziyI2IY2QnZGeiGitOfkLKcFNIBH3ZfQXH4j20 4BP34Vzzob17EgsbLbNkMlxh2M7tenXH9vA4MiN5yPPBKoR7SfI6mIaIr+7kewOizJ8D5dvpdfP5 HbAUTZVSYHqixgBWJyNp7sXWVQtOo+eOv8qKUeiodClanKuCnGD42Bl6EQR486dlXvOronEikRYX Xg6gFrhO+DonUYluMZpNdabnybKozchSdHcceOKd0JFMmyiSNG944ystXbR7QZqfNSh/Pbyc5QRp Z1vdFZLFh907iS3KxueDYKDPWmlsPt/QnmXmF4A9/5OrmVS1C45k5rcxggQ4MIIENAIBATCBmTCB kDELMAkGA1UEBhMCREUxGDAWBgNVBAoTD05FQyBFdXJvcGUgTHRkLjEgMB4GA1UECxMXTkVDIExh Ym9yYXRvcmllcyBFdXJvcGUxEjAQBgNVBAMTCU5FQ0xBQi1DQTExMC8GCSqGSIb3DQEJARYiemVy dGlmaXppZXJ1bmdzc3RlbGxlQG53Lm5lY2xhYi5ldQIEDTI0WzAJBgUrDgMCGgUAoIICczAYBgkq hkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0wOTAzMDkxMTI1MzVaMCMGCSqG SIb3DQEJBDEWBBSY+oTMMJRCiwKoSEOe4A3kUOwcKzCBqgYJKwYBBAGCNxAEMYGcMIGZMIGQMQsw CQYDVQQGEwJERTEYMBYGA1UEChMPTkVDIEV1cm9wZSBMdGQuMSAwHgYDVQQLExdORUMgTGFib3Jh dG9yaWVzIEV1cm9wZTESMBAGA1UEAxMJTkVDTEFCLUNBMTEwLwYJKoZIhvcNAQkBFiJ6ZXJ0aWZp emllcnVuZ3NzdGVsbGVAbncubmVjbGFiLmV1AgQNMjRbMIGsBgsqhkiG9w0BCRACCzGBnKCBmTCB kDELMAkGA1UEBhMCREUxGDAWBgNVBAoTD05FQyBFdXJvcGUgTHRkLjEgMB4GA1UECxMXTkVDIExh Ym9yYXRvcmllcyBFdXJvcGUxEjAQBgNVBAMTCU5FQ0xBQi1DQTExMC8GCSqGSIb3DQEJARYiemVy dGlmaXppZXJ1bmdzc3RlbGxlQG53Lm5lY2xhYi5ldQIEDTI0WzCBtwYJKoZIhvcNAQkPMYGpMIGm MAsGCWCGSAFlAwQBKjALBglghkgBZQMEARYwCgYIKoZIhvcNAwcwCwYJYIZIAWUDBAECMA4GCCqG SIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDAHBgUrDgMC GjALBglghkgBZQMEAgMwCwYJYIZIAWUDBAICMAsGCWCGSAFlAwQCATAKBggqhkiG9w0CBTANBgkq hkiG9w0BAQEFAASCAQA8l+tUHplqbQCCcQjoIQmsKiDVfr4F8V1XJFYZ1emOpdIR8VPqV2O783c7 STPmhK9qW0UK8q3UeGNy5IL8tvUip9w81UnBkkkhxPcHQqoGL6f7BPuZ2tgNpxdAfFIoDs7iyPhF tdOr4fwQ4PP7BvnOBlODwThQlr+bOJQZgDIejSiCzzGNmdIB4KemCh/DD3Re0kvV3nk4SjT5t1MP x/JK7ghqoXIrgBIyCMWpCTRp+L23qrOcSa2OpevAd7Ok4GJVVq5YqQiVO7WkKqSmqQArp5DaLRry jU7iBJqR9PVgYHjbCeXusudBphAgOtmxP1cNMhqrUoJJKrChG6YaF+zpAAAAAAAA ------=_NextPart_000_03FE_01C9A0B2.260B2FE0-- From Thomas.Dietz@nw.neclab.eu Mon Mar 9 04:29:11 2009 Return-Path: X-Original-To: ipfix@core3.amsl.com Delivered-To: ipfix@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5685D3A67EA for ; Mon, 9 Mar 2009 04:29:11 -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 KtnWrC9wKisb for ; Mon, 9 Mar 2009 04:29:10 -0700 (PDT) Received: from smtp0.neclab.eu (smtp0.neclab.eu [195.37.70.41]) by core3.amsl.com (Postfix) with ESMTP id A55E23A6A7E for ; Mon, 9 Mar 2009 04:29:09 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp0.neclab.eu (Postfix) with ESMTP id 3B6A62C01CA1D; Mon, 9 Mar 2009 12:29:43 +0100 (CET) X-Virus-Scanned: Amavisd on Debian GNU/Linux (atlas2.office) Received: from smtp0.neclab.eu ([127.0.0.1]) by localhost (atlas2.office [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Od+LYADfh-G6; Mon, 9 Mar 2009 12:29:43 +0100 (CET) Received: from VENUS.office (mx2.office [192.168.24.15]) by smtp0.neclab.eu (Postfix) with ESMTP id 05A3F2C01CA1B; Mon, 9 Mar 2009 12:29:33 +0100 (CET) Content-class: urn:content-classes:message MIME-Version: 1.0 X-MimeOLE: Produced By Microsoft Exchange V6.5 Date: Mon, 9 Mar 2009 12:29:31 +0100 Content-Type: multipart/signed; micalg=SHA1; boundary="----=_NextPart_000_040B_01C9A0B2.B28C6CE0"; protocol="application/x-pkcs7-signature" Message-ID: <547F018265F92642B577B986577D671C7009D3@VENUS.office> In-Reply-To: <49A55194.1090609@net.in.tum.de> X-MS-Has-Attach: yes X-MS-TNEF-Correlator: Thread-Topic: [IPFIX] IPFIX-MIB: ipfixMeteringProcessMessages, ipfixMeteringProcessErrors, ipfixMeteringProcessDataRecords thread-index: AcmXUwEZORo6PSQqRq+XItS05rEz8gJVyD3Q References: <49A55194.1090609@net.in.tum.de> From: "Thomas Dietz" To: "Gerhard Muenz" , Subject: Re: [IPFIX] IPFIX-MIB: ipfixMeteringProcessMessages, ipfixMeteringProcessErrors, ipfixMeteringProcessDataRecords 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, 09 Mar 2009 11:29:11 -0000 This is a multipart message in MIME format. ------=_NextPart_000_040B_01C9A0B2.B28C6CE0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Dear Benoit, Atsushi, all, I think Gerhard is right. If nobody objects I will remove those objects = in the upcoming version 07. Best Regards, Thomas --=20 Thomas Dietz E-mail: Thomas.Dietz@nw.neclab.eu NEC Europe Ltd. Phone: +49 6221 4342-128 NEC Laboratories Europe Fax: +49 6221 4342-155 Network Research Division Kurfuersten-Anlage 36 69115 Heidelberg, Germany http://www.nw.neclab.eu NEC Europe Limited Registered in England 2832014 Registered Office: NEC House, 1 Victoria Road, London W3 6BL > -----Original Message----- > From: ipfix-bounces@ietf.org [mailto:ipfix-bounces@ietf.org] On Behalf > Of Gerhard Muenz > Sent: Mittwoch, 25. Februar 2009 15:12 > To: ipfix@ietf.org > Subject: [IPFIX] IPFIX-MIB: ipfixMeteringProcessMessages, > ipfixMeteringProcessErrors, ipfixMeteringProcessDataRecords >=20 >=20 > Thomas, Benoit, >=20 > I do not understand why the following statistics are associated to the > Metering Process: >=20 > ipfixMeteringProcessMessages OBJECT-TYPE > SYNTAX Counter32 > MAX-ACCESS read-only > STATUS current > DESCRIPTION > "The number of IPFIX messages transmitted." > ::=3D { ipfixMeteringProcessStatsEntry 3 } >=20 > ipfixMeteringProcessErrors OBJECT-TYPE > SYNTAX Counter32 > MAX-ACCESS read-only > STATUS current > DESCRIPTION > "The number of messages that could not be sent due to e.g. > internal buffer overflows or network congestion." > ::=3D { ipfixMeteringProcessStatsEntry 4 } >=20 > The Metering Process does not generate or transmit any IPFIX Messages. > Also, IPFIX Messages including Data Records of a specific Metering > Process can be sent to different collectors resulting in different > Message errors. >=20 > I think the two counters should be removed. The Transport Session > statistics are sufficient. >=20 > It is interesting to count the Data Records *generated* (not > transmitted) by a Metering Process. Therefore, the following > DESCRIPTION > should be changed: >=20 > ipfixMeteringProcessDataRecords OBJECT-TYPE > SYNTAX Counter32 > MAX-ACCESS read-only > STATUS current > DESCRIPTION > "The number of Data Records transmitted." > ::=3D { ipfixMeteringProcessStatsEntry 5 } >=20 > Regards, > Gerhard >=20 > -- > Dipl.-Ing. Gerhard M=FCnz > Chair for Network Architectures and Services (I8) > Department of Informatics > Technische Universit=E4t M=FCnchen > Boltzmannstr. 3, 85748 Garching bei M=FCnchen, Germany > Phone: +49 89 289-18008 Fax: +49 89 289-18033 > E-mail: muenz@net.in.tum.de WWW: http://www.net.in.tum.de/~muenz >=20 ------=_NextPart_000_040B_01C9A0B2.B28C6CE0 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIISNzCCA58w ggKHoAMCAQICASYwDQYJKoZIhvcNAQEFBQAwcTELMAkGA1UEBhMCREUxHDAaBgNVBAoTE0RldXRz Y2hlIFRlbGVrb20gQUcxHzAdBgNVBAsTFlQtVGVsZVNlYyBUcnVzdCBDZW50ZXIxIzAhBgNVBAMT GkRldXRzY2hlIFRlbGVrb20gUm9vdCBDQSAyMB4XDTk5MDcwOTEyMTEwMFoXDTE5MDcwOTIzNTkw MFowcTELMAkGA1UEBhMCREUxHDAaBgNVBAoTE0RldXRzY2hlIFRlbGVrb20gQUcxHzAdBgNVBAsT FlQtVGVsZVNlYyBUcnVzdCBDZW50ZXIxIzAhBgNVBAMTGkRldXRzY2hlIFRlbGVrb20gUm9vdCBD QSAyMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAqwujNeCLKRSxFIWvPBDkOW81XUqu 3ephjZVJ9G9koxpgZqSpQCKE2dSl5XiTDmgBrblNXDrO07ioQkDfz6O6gllqkhusHJraCCslJ/lp I0fx4Ossepv1EwLQfjR8wp48AFmr9doM9TI8K6xQ2tbD3oOUyqgMmTIOCEhWW2r72uFYWAFJX3JB PBUGAY5draq4k7TNnuun6GotUjTbOu9cdVHa2/Mx+e5xmDLEVBVEDPmbVe2t3xgIoKOGiknuUwWP GUzV3lh5m9JqHEKrxdWnz2gPluThYZh2YciRfNY+AOKRUIfhnQrmrZfSHcY6fcu82gM01Y5bAfVq B7cWtm5KfwIDAQABo0IwQDAdBgNVHQ4EFgQUMcN5G7r1U9cX4Il6LRdsCrMrnTMwDwYDVR0TBAgw BgEB/wIBBTAOBgNVHQ8BAf8EBAMCAQYwDQYJKoZIhvcNAQEFBQADggEBAJRkWa05ZOcp6xP+WsOL E1fIBCTwdHfAYONn++mJpoO/loJ8btTDPe+egG67KbSYerE7VOs5F0d+Go4L/B8xWTEEss4X8yzH YjZV4iLYiVW0mEiqZPrWHDbYRHhaWiM6V5f1ejBPrp9qTEsrjqAD4z7gqdTSe9KzqOJyPK2e/4BZ 5JtFtPY7sM05GZgy5eohYZDkMSGONLH3LzVKhRDa54o3Ib5ZY+DyhYgxU9RUFIVwefQuBncndS8f uIr5/sW62Dbkg+znZbe/Y1rzRq+BlDfUQYzWI9Yez/VoG0Rjolq6pzVZoeVwBZsOI1eZlAptujlj KIaS8xiE2PvRzwVWZFcwggQhMIIDCaADAgECAgIAxzANBgkqhkiG9w0BAQUFADBxMQswCQYDVQQG EwJERTEcMBoGA1UEChMTRGV1dHNjaGUgVGVsZWtvbSBBRzEfMB0GA1UECxMWVC1UZWxlU2VjIFRy dXN0IENlbnRlcjEjMCEGA1UEAxMaRGV1dHNjaGUgVGVsZWtvbSBSb290IENBIDIwHhcNMDYxMjE5 MTAyOTAwWhcNMTkwNjMwMjM1OTAwWjBaMQswCQYDVQQGEwJERTETMBEGA1UEChMKREZOLVZlcmVp bjEQMA4GA1UECxMHREZOLVBLSTEkMCIGA1UEAxMbREZOLVZlcmVpbiBQQ0EgR2xvYmFsIC0gRzAx MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA6ZvDZ4X5Da71jVTDllA1PWLpbkztlNcA W5UidNQg6zSP1uzAMQQLmYHiphTSUqAoI4SLdIkEXlvg4njBeMsWyyg1OXstkEXQ7aAAeny/Sg4b AMOG6VwrMRF7DPOCJEOMHDiLamgAmu7cT3ir0sYTm3at7t4m6O8Br3QPwQmi9mvOvdPNFDBP9eXj pMhim4IaAycwDQJlYE3t0QkjKpY1WCfTdsZxtpAdxO3/NYZ9bzOz2w/FEcKKg6GUXUFr2NIQ9Uz9 ylGs2b3vkoO72uuLFlZWQ8/h1RM9ph8nMM1JVNvJEzSacXXFbOqnC5j5IZ0nrz6jOTlIaoytyZn7 wxLyvQIDAQABo4HZMIHWMHAGA1UdHwRpMGcwZaBjoGGGX2h0dHA6Ly9wa2kudGVsZXNlYy5kZS9j Z2ktYmluL3NlcnZpY2UvYWZfRG93bmxvYWRBUkwuY3JsPy1jcmxfZm9ybWF0PVhfNTA5Ji1pc3N1 ZXI9RFRfUk9PVF9DQV8yMB0GA1UdDgQWBBRJt8bP6D0ff+pEexMp9/EKcD7eZDAfBgNVHSMEGDAW gBQxw3kbuvVT1xfgiXotF2wKsyudMzAOBgNVHQ8BAf8EBAMCAQYwEgYDVR0TAQH/BAgwBgEB/wIB AjANBgkqhkiG9w0BAQUFAAOCAQEAO+Fad8BIF9ypGOyBr1qJ8L0okqbKWRgScOwo8ueuf5Ys5/Jd GTH2Eyt0vb2Asrn3Z8k5onk74RER7mt4kTN+O18mJ3VTZY4zY+7Pc8OwkiNJIVB1I6EfGOKUhT0/ M+l3II2iveahhSlA9j9zMlgNCWum2oVswD+7jWZkViROrg0/MjUBW+mMgtlyWU+xhoXxdIVW5cP4 XPON7kezUwVw5+VNimmDKOETCYaeXsjqWB4MH/mk1FoEaP0oPosCtli19qEsN1cAZ6sjaI1jpe+Z a1z9S1b2q0CHNNQRkmzsh8UKCwczcrRvDB1ULNhRx8y/MNNDcvEyv4zOSWOoAPfyHDCCBS8wggQX oAMCAQICBA0hCkcwDQYJKoZIhvcNAQEFBQAwWjELMAkGA1UEBhMCREUxEzARBgNVBAoTCkRGTi1W ZXJlaW4xEDAOBgNVBAsTB0RGTi1QS0kxJDAiBgNVBAMTG0RGTi1WZXJlaW4gUENBIEdsb2JhbCAt IEcwMTAeFw0wODEwMjQwODUyMDhaFw0xOTA2MzAwMDAwMDBaMIGQMQswCQYDVQQGEwJERTEYMBYG A1UEChMPTkVDIEV1cm9wZSBMdGQuMSAwHgYDVQQLExdORUMgTGFib3JhdG9yaWVzIEV1cm9wZTES MBAGA1UEAxMJTkVDTEFCLUNBMTEwLwYJKoZIhvcNAQkBFiJ6ZXJ0aWZpemllcnVuZ3NzdGVsbGVA bncubmVjbGFiLmV1MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAnvIVsbURqjIOcbnf ruYkRceWOZpyvM2ebnYpbd1cP+zdWm6yR7HSO9ppOe1ZZFIasArqQpedPEFvcncSG94FRuW3ND4r Rcq08mbpUTmpWmXfdYlJpQezbsOHCWR74NXoEEbK6TPZIMFpJr6dzQDAxnRc7UOgO6JQ1V42Z39B PhIbPIWz64t8svafxbORmxulJn7F5zDLDcR1AEGyn+L9b645AGwapoKNh7cSQFTqdb6kGyPQjLWf tv09dvmBDKesrcyLZXuDWJ1LMeizSjUEygdSszNXD3gePgJaVaZDS3o923W5gAyPCTSxpAFj8XJ+ /7Ap5jJwYhjJgJ8khFR7JQIDAQABo4IBxDCCAcAwEgYDVR0TAQH/BAgwBgEB/wIBATALBgNVHQ8E BAMCAQYwHQYDVR0OBBYEFE8ch3od4C+Z9r4VqtE1nQ5K5ro2MB8GA1UdIwQYMBaAFEm3xs/oPR9/ 6kR7Eyn38QpwPt5kMC0GA1UdEQQmMCSBInplcnRpZml6aWVydW5nc3N0ZWxsZUBudy5uZWNsYWIu ZXUwgYgGA1UdHwSBgDB+MD2gO6A5hjdodHRwOi8vY2RwMS5wY2EuZGZuLmRlL2dsb2JhbC1yb290 LWNhL3B1Yi9jcmwvY2FjcmwuY3JsMD2gO6A5hjdodHRwOi8vY2RwMi5wY2EuZGZuLmRlL2dsb2Jh bC1yb290LWNhL3B1Yi9jcmwvY2FjcmwuY3JsMIGiBggrBgEFBQcBAQSBlTCBkjBHBggrBgEFBQcw AoY7aHR0cDovL2NkcDEucGNhLmRmbi5kZS9nbG9iYWwtcm9vdC1jYS9wdWIvY2FjZXJ0L2NhY2Vy dC5jcnQwRwYIKwYBBQUHMAKGO2h0dHA6Ly9jZHAyLnBjYS5kZm4uZGUvZ2xvYmFsLXJvb3QtY2Ev cHViL2NhY2VydC9jYWNlcnQuY3J0MA0GCSqGSIb3DQEBBQUAA4IBAQBsMQ+dD0mmi48dgDU4R6Q/ eXcY0zQcHNp1Vu1s3kwO0WahWB0tiqVBodvfTAWG44xuw0I7NXSTwQ68FU5P0GIQnvRFZyVJlDjr SNlLYxjqfmgb+KVm67o383cZIuDakEE0f29kULIEn2fg/HsDiBAXTsb4I19XaN0TXLI+PMhU+GDp sGCJrydeugEV7qi15q8yymjSAsYgnrc2wJuXpyQ9r3qCtP6aedAPSHqOT8ga1dLT2YRZFs3vNm7T HSr5JJymWMbfpD6OcbRTnNAjSMDHwJxgRBAflA6WzDVm7fk4jiWyLvJwWTMk19t8QLiKG7D0nYvj cEUYyiOSE+SFUTEdMIIFODCCBCCgAwIBAgIEDTI0WzANBgkqhkiG9w0BAQUFADCBkDELMAkGA1UE BhMCREUxGDAWBgNVBAoTD05FQyBFdXJvcGUgTHRkLjEgMB4GA1UECxMXTkVDIExhYm9yYXRvcmll cyBFdXJvcGUxEjAQBgNVBAMTCU5FQ0xBQi1DQTExMC8GCSqGSIb3DQEJARYiemVydGlmaXppZXJ1 bmdzc3RlbGxlQG53Lm5lY2xhYi5ldTAeFw0wODExMDYwOTIwMTFaFw0xMTExMDYwOTIwMTFaMGAx CzAJBgNVBAYTAkRFMRgwFgYDVQQKEw9ORUMgRXVyb3BlIEx0ZC4xIDAeBgNVBAsTF05FQyBMYWJv cmF0b3JpZXMgRXVyb3BlMRUwEwYDVQQDEwxUaG9tYXMgRGlldHowggEiMA0GCSqGSIb3DQEBAQUA A4IBDwAwggEKAoIBAQCniLuqlMflMs7ag3idESVRwfZ9nrdIyUmq5Tget4k9APGSPo2GZ1f1hr8y MuJIGowc/HzS1laVSICclOXju1xW93Tm+Vco5gwkRqHXY3Rmda0r2jlb8niVie4qXQgXPzunFRqk yNmbwYep3oD5Kq0GfB6EuZ7X6cYH5A7erAMeeQPhoDQDIfR79lRHlcMtanJZyORYNQONPEa+L4AF v5f3nAsmY7ZLJ72wX7X8BtcF6Vdkr0T2b1YrPl8Qir7e0TKY9Rf0q5DKu3QdLnXk0Rb+63V/4vLS PZ3XQVdwHzLiOhIZJVVMJE7TmJI0DFeDFn99O/F/Le/sJOJjNO4n6KMLAgMBAAGjggHHMIIBwzAJ BgNVHRMEAjAAMAsGA1UdDwQEAwIF4DApBgNVHSUEIjAgBggrBgEFBQcDAgYIKwYBBQUHAwQGCisG AQQBgjcUAgIwHQYDVR0OBBYEFLkbmpJJpIXhIR9JFttGC+KHW5g5MB8GA1UdIwQYMBaAFE8ch3od 4C+Z9r4VqtE1nQ5K5ro2MCQGA1UdEQQdMBuBGVRob21hcy5EaWV0ekBudy5uZWNsYWIuZXUwfQYD VR0fBHYwdDA4oDagNIYyaHR0cDovL2NkcDEucGNhLmRmbi5kZS9uZWNsYWItY2EvcHViL2NybC9j YWNybC5jcmwwOKA2oDSGMmh0dHA6Ly9jZHAyLnBjYS5kZm4uZGUvbmVjbGFiLWNhL3B1Yi9jcmwv Y2FjcmwuY3JsMIGYBggrBgEFBQcBAQSBizCBiDBCBggrBgEFBQcwAoY2aHR0cDovL2NkcDEucGNh LmRmbi5kZS9uZWNsYWItY2EvcHViL2NhY2VydC9jYWNlcnQuY3J0MEIGCCsGAQUFBzAChjZodHRw Oi8vY2RwMi5wY2EuZGZuLmRlL25lY2xhYi1jYS9wdWIvY2FjZXJ0L2NhY2VydC5jcnQwDQYJKoZI hvcNAQEFBQADggEBAEbKwRBhNxAzsH6kAYRBoIziyI2IY2QnZGeiGitOfkLKcFNIBH3ZfQXH4j20 4BP34Vzzob17EgsbLbNkMlxh2M7tenXH9vA4MiN5yPPBKoR7SfI6mIaIr+7kewOizJ8D5dvpdfP5 HbAUTZVSYHqixgBWJyNp7sXWVQtOo+eOv8qKUeiodClanKuCnGD42Bl6EQR486dlXvOronEikRYX Xg6gFrhO+DonUYluMZpNdabnybKozchSdHcceOKd0JFMmyiSNG944ystXbR7QZqfNSh/Pbyc5QRp Z1vdFZLFh907iS3KxueDYKDPWmlsPt/QnmXmF4A9/5OrmVS1C45k5rcxggQ4MIIENAIBATCBmTCB kDELMAkGA1UEBhMCREUxGDAWBgNVBAoTD05FQyBFdXJvcGUgTHRkLjEgMB4GA1UECxMXTkVDIExh Ym9yYXRvcmllcyBFdXJvcGUxEjAQBgNVBAMTCU5FQ0xBQi1DQTExMC8GCSqGSIb3DQEJARYiemVy dGlmaXppZXJ1bmdzc3RlbGxlQG53Lm5lY2xhYi5ldQIEDTI0WzAJBgUrDgMCGgUAoIICczAYBgkq hkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0wOTAzMDkxMTI5MzFaMCMGCSqG SIb3DQEJBDEWBBT0F4cDiuGIkXsHgPEGWKbAdxwBwjCBqgYJKwYBBAGCNxAEMYGcMIGZMIGQMQsw CQYDVQQGEwJERTEYMBYGA1UEChMPTkVDIEV1cm9wZSBMdGQuMSAwHgYDVQQLExdORUMgTGFib3Jh dG9yaWVzIEV1cm9wZTESMBAGA1UEAxMJTkVDTEFCLUNBMTEwLwYJKoZIhvcNAQkBFiJ6ZXJ0aWZp emllcnVuZ3NzdGVsbGVAbncubmVjbGFiLmV1AgQNMjRbMIGsBgsqhkiG9w0BCRACCzGBnKCBmTCB kDELMAkGA1UEBhMCREUxGDAWBgNVBAoTD05FQyBFdXJvcGUgTHRkLjEgMB4GA1UECxMXTkVDIExh Ym9yYXRvcmllcyBFdXJvcGUxEjAQBgNVBAMTCU5FQ0xBQi1DQTExMC8GCSqGSIb3DQEJARYiemVy dGlmaXppZXJ1bmdzc3RlbGxlQG53Lm5lY2xhYi5ldQIEDTI0WzCBtwYJKoZIhvcNAQkPMYGpMIGm MAsGCWCGSAFlAwQBKjALBglghkgBZQMEARYwCgYIKoZIhvcNAwcwCwYJYIZIAWUDBAECMA4GCCqG SIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDAHBgUrDgMC GjALBglghkgBZQMEAgMwCwYJYIZIAWUDBAICMAsGCWCGSAFlAwQCATAKBggqhkiG9w0CBTANBgkq hkiG9w0BAQEFAASCAQCQUin8gE6rbTEObqi0gApa7g6znTXx7ep4MUQTZrKCEEZAvKZNDmjKN2I5 iNml/i9lADA0R1jnpwZSlu/IGrH8FMKVKmAn1BEnYRz1hHUuideyBUe2Vqg3epLcCMMJW1YIedE+ dIEsSBK6O7joLHWTXxgj5SSTgmbtfDF5YmP1hLo9mFtB1cm4pITB87f6yeviSSpOzgNIuazv4Jkp tktHIX3+FlvpN6XyltVgmdA+6qLFXvcrHQbfRzeNQ98cyqeOnB043icyd1d5fUL0YbdXdqvyKe64 nGXDE5oAfB2Sgp07AC7AeLPcp9lXNtfdqB3A1SohNmkuiMfX+iPUNTebAAAAAAAA ------=_NextPart_000_040B_01C9A0B2.B28C6CE0-- From Thomas.Dietz@nw.neclab.eu Mon Mar 9 04:35:50 2009 Return-Path: X-Original-To: ipfix@core3.amsl.com Delivered-To: ipfix@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 20D4228C0FF for ; Mon, 9 Mar 2009 04:35:50 -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 SZ1ZyWetyQTu for ; Mon, 9 Mar 2009 04:35:49 -0700 (PDT) Received: from smtp0.neclab.eu (smtp0.neclab.eu [195.37.70.41]) by core3.amsl.com (Postfix) with ESMTP id A6AD228C12E for ; Mon, 9 Mar 2009 04:35:48 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp0.neclab.eu (Postfix) with ESMTP id 4158E2C01CA1D for ; Mon, 9 Mar 2009 12:36:22 +0100 (CET) X-Virus-Scanned: Amavisd on Debian GNU/Linux (atlas2.office) Received: from smtp0.neclab.eu ([127.0.0.1]) by localhost (atlas2.office [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SMlaM-VHVJ6r for ; Mon, 9 Mar 2009 12:36:22 +0100 (CET) Received: from VENUS.office (mx2.office [192.168.24.15]) by smtp0.neclab.eu (Postfix) with ESMTP id 106F52C01CA19 for ; Mon, 9 Mar 2009 12:36:17 +0100 (CET) Content-class: urn:content-classes:message MIME-Version: 1.0 X-MimeOLE: Produced By Microsoft Exchange V6.5 Date: Mon, 9 Mar 2009 12:36:15 +0100 Content-Type: multipart/signed; micalg=SHA1; boundary="----=_NextPart_000_040F_01C9A0B3.A318EE40"; protocol="application/x-pkcs7-signature" Message-ID: <547F018265F92642B577B986577D671C7009D8@VENUS.office> X-MS-Has-Attach: yes X-MS-TNEF-Correlator: Thread-Topic: IPFIX-MIB: Separation of MIB modules (was: T21 from AD review) thread-index: Acmgq0FQuKveo+V5QUKVbP7Jo3uh0g== From: "Thomas Dietz" To: Subject: [IPFIX] IPFIX-MIB: Separation of MIB modules (was: T21 from AD review) 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, 09 Mar 2009 11:35:50 -0000 This is a multipart message in MIME format. ------=_NextPart_000_040F_01C9A0B3.A318EE40 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Dear all, Dan raised the following issue in the AD review: > T21. I assume that selection functions will be added in the future. If I > am wrong please delete all mention of extensibility and take out the > ipfixSelectorFunctions group. If I am right, I suggest to put > ipfixSelectorFunctions in a separate MIB module that will be IANA > maintained, so that new functions can be added in the future without the > need to revise the MIB module and the RFC. The separate MIB module will > become the initial version of the IANA maintained module, and new > selector functions will be added using for example Expert Review policy. I personally think it is a good idea to put the selector functions in a separate MIB module (still defined in the same draft) and put that module under control of IANA. I would propose further to make additions subject to Expert Review policy. If you agree with this procedure I would make those changes for the upcoming version 07. If you think different please speak up. Best Regards, Thomas -- Thomas Dietz E-mail: Thomas.Dietz@nw.neclab.eu NEC Europe Ltd. Phone: +49 6221 4342-128 NEC Laboratories Europe Fax: +49 6221 4342-155 Network Research Division Kurfuersten-Anlage 36 69115 Heidelberg, Germany http://www.nw.neclab.eu NEC Europe Limited Registered in England 2832014 Registered Office: NEC House, 1 Victoria Road, London W3 6BL ------=_NextPart_000_040F_01C9A0B3.A318EE40 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIISNzCCA58w ggKHoAMCAQICASYwDQYJKoZIhvcNAQEFBQAwcTELMAkGA1UEBhMCREUxHDAaBgNVBAoTE0RldXRz Y2hlIFRlbGVrb20gQUcxHzAdBgNVBAsTFlQtVGVsZVNlYyBUcnVzdCBDZW50ZXIxIzAhBgNVBAMT GkRldXRzY2hlIFRlbGVrb20gUm9vdCBDQSAyMB4XDTk5MDcwOTEyMTEwMFoXDTE5MDcwOTIzNTkw MFowcTELMAkGA1UEBhMCREUxHDAaBgNVBAoTE0RldXRzY2hlIFRlbGVrb20gQUcxHzAdBgNVBAsT FlQtVGVsZVNlYyBUcnVzdCBDZW50ZXIxIzAhBgNVBAMTGkRldXRzY2hlIFRlbGVrb20gUm9vdCBD QSAyMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAqwujNeCLKRSxFIWvPBDkOW81XUqu 3ephjZVJ9G9koxpgZqSpQCKE2dSl5XiTDmgBrblNXDrO07ioQkDfz6O6gllqkhusHJraCCslJ/lp I0fx4Ossepv1EwLQfjR8wp48AFmr9doM9TI8K6xQ2tbD3oOUyqgMmTIOCEhWW2r72uFYWAFJX3JB PBUGAY5draq4k7TNnuun6GotUjTbOu9cdVHa2/Mx+e5xmDLEVBVEDPmbVe2t3xgIoKOGiknuUwWP GUzV3lh5m9JqHEKrxdWnz2gPluThYZh2YciRfNY+AOKRUIfhnQrmrZfSHcY6fcu82gM01Y5bAfVq B7cWtm5KfwIDAQABo0IwQDAdBgNVHQ4EFgQUMcN5G7r1U9cX4Il6LRdsCrMrnTMwDwYDVR0TBAgw BgEB/wIBBTAOBgNVHQ8BAf8EBAMCAQYwDQYJKoZIhvcNAQEFBQADggEBAJRkWa05ZOcp6xP+WsOL E1fIBCTwdHfAYONn++mJpoO/loJ8btTDPe+egG67KbSYerE7VOs5F0d+Go4L/B8xWTEEss4X8yzH YjZV4iLYiVW0mEiqZPrWHDbYRHhaWiM6V5f1ejBPrp9qTEsrjqAD4z7gqdTSe9KzqOJyPK2e/4BZ 5JtFtPY7sM05GZgy5eohYZDkMSGONLH3LzVKhRDa54o3Ib5ZY+DyhYgxU9RUFIVwefQuBncndS8f uIr5/sW62Dbkg+znZbe/Y1rzRq+BlDfUQYzWI9Yez/VoG0Rjolq6pzVZoeVwBZsOI1eZlAptujlj KIaS8xiE2PvRzwVWZFcwggQhMIIDCaADAgECAgIAxzANBgkqhkiG9w0BAQUFADBxMQswCQYDVQQG EwJERTEcMBoGA1UEChMTRGV1dHNjaGUgVGVsZWtvbSBBRzEfMB0GA1UECxMWVC1UZWxlU2VjIFRy dXN0IENlbnRlcjEjMCEGA1UEAxMaRGV1dHNjaGUgVGVsZWtvbSBSb290IENBIDIwHhcNMDYxMjE5 MTAyOTAwWhcNMTkwNjMwMjM1OTAwWjBaMQswCQYDVQQGEwJERTETMBEGA1UEChMKREZOLVZlcmVp bjEQMA4GA1UECxMHREZOLVBLSTEkMCIGA1UEAxMbREZOLVZlcmVpbiBQQ0EgR2xvYmFsIC0gRzAx MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA6ZvDZ4X5Da71jVTDllA1PWLpbkztlNcA W5UidNQg6zSP1uzAMQQLmYHiphTSUqAoI4SLdIkEXlvg4njBeMsWyyg1OXstkEXQ7aAAeny/Sg4b AMOG6VwrMRF7DPOCJEOMHDiLamgAmu7cT3ir0sYTm3at7t4m6O8Br3QPwQmi9mvOvdPNFDBP9eXj pMhim4IaAycwDQJlYE3t0QkjKpY1WCfTdsZxtpAdxO3/NYZ9bzOz2w/FEcKKg6GUXUFr2NIQ9Uz9 ylGs2b3vkoO72uuLFlZWQ8/h1RM9ph8nMM1JVNvJEzSacXXFbOqnC5j5IZ0nrz6jOTlIaoytyZn7 wxLyvQIDAQABo4HZMIHWMHAGA1UdHwRpMGcwZaBjoGGGX2h0dHA6Ly9wa2kudGVsZXNlYy5kZS9j Z2ktYmluL3NlcnZpY2UvYWZfRG93bmxvYWRBUkwuY3JsPy1jcmxfZm9ybWF0PVhfNTA5Ji1pc3N1 ZXI9RFRfUk9PVF9DQV8yMB0GA1UdDgQWBBRJt8bP6D0ff+pEexMp9/EKcD7eZDAfBgNVHSMEGDAW gBQxw3kbuvVT1xfgiXotF2wKsyudMzAOBgNVHQ8BAf8EBAMCAQYwEgYDVR0TAQH/BAgwBgEB/wIB AjANBgkqhkiG9w0BAQUFAAOCAQEAO+Fad8BIF9ypGOyBr1qJ8L0okqbKWRgScOwo8ueuf5Ys5/Jd GTH2Eyt0vb2Asrn3Z8k5onk74RER7mt4kTN+O18mJ3VTZY4zY+7Pc8OwkiNJIVB1I6EfGOKUhT0/ M+l3II2iveahhSlA9j9zMlgNCWum2oVswD+7jWZkViROrg0/MjUBW+mMgtlyWU+xhoXxdIVW5cP4 XPON7kezUwVw5+VNimmDKOETCYaeXsjqWB4MH/mk1FoEaP0oPosCtli19qEsN1cAZ6sjaI1jpe+Z a1z9S1b2q0CHNNQRkmzsh8UKCwczcrRvDB1ULNhRx8y/MNNDcvEyv4zOSWOoAPfyHDCCBS8wggQX oAMCAQICBA0hCkcwDQYJKoZIhvcNAQEFBQAwWjELMAkGA1UEBhMCREUxEzARBgNVBAoTCkRGTi1W ZXJlaW4xEDAOBgNVBAsTB0RGTi1QS0kxJDAiBgNVBAMTG0RGTi1WZXJlaW4gUENBIEdsb2JhbCAt IEcwMTAeFw0wODEwMjQwODUyMDhaFw0xOTA2MzAwMDAwMDBaMIGQMQswCQYDVQQGEwJERTEYMBYG A1UEChMPTkVDIEV1cm9wZSBMdGQuMSAwHgYDVQQLExdORUMgTGFib3JhdG9yaWVzIEV1cm9wZTES MBAGA1UEAxMJTkVDTEFCLUNBMTEwLwYJKoZIhvcNAQkBFiJ6ZXJ0aWZpemllcnVuZ3NzdGVsbGVA bncubmVjbGFiLmV1MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAnvIVsbURqjIOcbnf ruYkRceWOZpyvM2ebnYpbd1cP+zdWm6yR7HSO9ppOe1ZZFIasArqQpedPEFvcncSG94FRuW3ND4r Rcq08mbpUTmpWmXfdYlJpQezbsOHCWR74NXoEEbK6TPZIMFpJr6dzQDAxnRc7UOgO6JQ1V42Z39B PhIbPIWz64t8svafxbORmxulJn7F5zDLDcR1AEGyn+L9b645AGwapoKNh7cSQFTqdb6kGyPQjLWf tv09dvmBDKesrcyLZXuDWJ1LMeizSjUEygdSszNXD3gePgJaVaZDS3o923W5gAyPCTSxpAFj8XJ+ /7Ap5jJwYhjJgJ8khFR7JQIDAQABo4IBxDCCAcAwEgYDVR0TAQH/BAgwBgEB/wIBATALBgNVHQ8E BAMCAQYwHQYDVR0OBBYEFE8ch3od4C+Z9r4VqtE1nQ5K5ro2MB8GA1UdIwQYMBaAFEm3xs/oPR9/ 6kR7Eyn38QpwPt5kMC0GA1UdEQQmMCSBInplcnRpZml6aWVydW5nc3N0ZWxsZUBudy5uZWNsYWIu ZXUwgYgGA1UdHwSBgDB+MD2gO6A5hjdodHRwOi8vY2RwMS5wY2EuZGZuLmRlL2dsb2JhbC1yb290 LWNhL3B1Yi9jcmwvY2FjcmwuY3JsMD2gO6A5hjdodHRwOi8vY2RwMi5wY2EuZGZuLmRlL2dsb2Jh bC1yb290LWNhL3B1Yi9jcmwvY2FjcmwuY3JsMIGiBggrBgEFBQcBAQSBlTCBkjBHBggrBgEFBQcw AoY7aHR0cDovL2NkcDEucGNhLmRmbi5kZS9nbG9iYWwtcm9vdC1jYS9wdWIvY2FjZXJ0L2NhY2Vy dC5jcnQwRwYIKwYBBQUHMAKGO2h0dHA6Ly9jZHAyLnBjYS5kZm4uZGUvZ2xvYmFsLXJvb3QtY2Ev cHViL2NhY2VydC9jYWNlcnQuY3J0MA0GCSqGSIb3DQEBBQUAA4IBAQBsMQ+dD0mmi48dgDU4R6Q/ eXcY0zQcHNp1Vu1s3kwO0WahWB0tiqVBodvfTAWG44xuw0I7NXSTwQ68FU5P0GIQnvRFZyVJlDjr SNlLYxjqfmgb+KVm67o383cZIuDakEE0f29kULIEn2fg/HsDiBAXTsb4I19XaN0TXLI+PMhU+GDp sGCJrydeugEV7qi15q8yymjSAsYgnrc2wJuXpyQ9r3qCtP6aedAPSHqOT8ga1dLT2YRZFs3vNm7T HSr5JJymWMbfpD6OcbRTnNAjSMDHwJxgRBAflA6WzDVm7fk4jiWyLvJwWTMk19t8QLiKG7D0nYvj cEUYyiOSE+SFUTEdMIIFODCCBCCgAwIBAgIEDTI0WzANBgkqhkiG9w0BAQUFADCBkDELMAkGA1UE BhMCREUxGDAWBgNVBAoTD05FQyBFdXJvcGUgTHRkLjEgMB4GA1UECxMXTkVDIExhYm9yYXRvcmll cyBFdXJvcGUxEjAQBgNVBAMTCU5FQ0xBQi1DQTExMC8GCSqGSIb3DQEJARYiemVydGlmaXppZXJ1 bmdzc3RlbGxlQG53Lm5lY2xhYi5ldTAeFw0wODExMDYwOTIwMTFaFw0xMTExMDYwOTIwMTFaMGAx CzAJBgNVBAYTAkRFMRgwFgYDVQQKEw9ORUMgRXVyb3BlIEx0ZC4xIDAeBgNVBAsTF05FQyBMYWJv cmF0b3JpZXMgRXVyb3BlMRUwEwYDVQQDEwxUaG9tYXMgRGlldHowggEiMA0GCSqGSIb3DQEBAQUA A4IBDwAwggEKAoIBAQCniLuqlMflMs7ag3idESVRwfZ9nrdIyUmq5Tget4k9APGSPo2GZ1f1hr8y MuJIGowc/HzS1laVSICclOXju1xW93Tm+Vco5gwkRqHXY3Rmda0r2jlb8niVie4qXQgXPzunFRqk yNmbwYep3oD5Kq0GfB6EuZ7X6cYH5A7erAMeeQPhoDQDIfR79lRHlcMtanJZyORYNQONPEa+L4AF v5f3nAsmY7ZLJ72wX7X8BtcF6Vdkr0T2b1YrPl8Qir7e0TKY9Rf0q5DKu3QdLnXk0Rb+63V/4vLS PZ3XQVdwHzLiOhIZJVVMJE7TmJI0DFeDFn99O/F/Le/sJOJjNO4n6KMLAgMBAAGjggHHMIIBwzAJ BgNVHRMEAjAAMAsGA1UdDwQEAwIF4DApBgNVHSUEIjAgBggrBgEFBQcDAgYIKwYBBQUHAwQGCisG AQQBgjcUAgIwHQYDVR0OBBYEFLkbmpJJpIXhIR9JFttGC+KHW5g5MB8GA1UdIwQYMBaAFE8ch3od 4C+Z9r4VqtE1nQ5K5ro2MCQGA1UdEQQdMBuBGVRob21hcy5EaWV0ekBudy5uZWNsYWIuZXUwfQYD VR0fBHYwdDA4oDagNIYyaHR0cDovL2NkcDEucGNhLmRmbi5kZS9uZWNsYWItY2EvcHViL2NybC9j YWNybC5jcmwwOKA2oDSGMmh0dHA6Ly9jZHAyLnBjYS5kZm4uZGUvbmVjbGFiLWNhL3B1Yi9jcmwv Y2FjcmwuY3JsMIGYBggrBgEFBQcBAQSBizCBiDBCBggrBgEFBQcwAoY2aHR0cDovL2NkcDEucGNh LmRmbi5kZS9uZWNsYWItY2EvcHViL2NhY2VydC9jYWNlcnQuY3J0MEIGCCsGAQUFBzAChjZodHRw Oi8vY2RwMi5wY2EuZGZuLmRlL25lY2xhYi1jYS9wdWIvY2FjZXJ0L2NhY2VydC5jcnQwDQYJKoZI hvcNAQEFBQADggEBAEbKwRBhNxAzsH6kAYRBoIziyI2IY2QnZGeiGitOfkLKcFNIBH3ZfQXH4j20 4BP34Vzzob17EgsbLbNkMlxh2M7tenXH9vA4MiN5yPPBKoR7SfI6mIaIr+7kewOizJ8D5dvpdfP5 HbAUTZVSYHqixgBWJyNp7sXWVQtOo+eOv8qKUeiodClanKuCnGD42Bl6EQR486dlXvOronEikRYX Xg6gFrhO+DonUYluMZpNdabnybKozchSdHcceOKd0JFMmyiSNG944ystXbR7QZqfNSh/Pbyc5QRp Z1vdFZLFh907iS3KxueDYKDPWmlsPt/QnmXmF4A9/5OrmVS1C45k5rcxggQ4MIIENAIBATCBmTCB kDELMAkGA1UEBhMCREUxGDAWBgNVBAoTD05FQyBFdXJvcGUgTHRkLjEgMB4GA1UECxMXTkVDIExh Ym9yYXRvcmllcyBFdXJvcGUxEjAQBgNVBAMTCU5FQ0xBQi1DQTExMC8GCSqGSIb3DQEJARYiemVy dGlmaXppZXJ1bmdzc3RlbGxlQG53Lm5lY2xhYi5ldQIEDTI0WzAJBgUrDgMCGgUAoIICczAYBgkq hkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0wOTAzMDkxMTM2MTVaMCMGCSqG SIb3DQEJBDEWBBTsY3sy7B04Ur3sMqOHGWvi069PMjCBqgYJKwYBBAGCNxAEMYGcMIGZMIGQMQsw CQYDVQQGEwJERTEYMBYGA1UEChMPTkVDIEV1cm9wZSBMdGQuMSAwHgYDVQQLExdORUMgTGFib3Jh dG9yaWVzIEV1cm9wZTESMBAGA1UEAxMJTkVDTEFCLUNBMTEwLwYJKoZIhvcNAQkBFiJ6ZXJ0aWZp emllcnVuZ3NzdGVsbGVAbncubmVjbGFiLmV1AgQNMjRbMIGsBgsqhkiG9w0BCRACCzGBnKCBmTCB kDELMAkGA1UEBhMCREUxGDAWBgNVBAoTD05FQyBFdXJvcGUgTHRkLjEgMB4GA1UECxMXTkVDIExh Ym9yYXRvcmllcyBFdXJvcGUxEjAQBgNVBAMTCU5FQ0xBQi1DQTExMC8GCSqGSIb3DQEJARYiemVy dGlmaXppZXJ1bmdzc3RlbGxlQG53Lm5lY2xhYi5ldQIEDTI0WzCBtwYJKoZIhvcNAQkPMYGpMIGm MAsGCWCGSAFlAwQBKjALBglghkgBZQMEARYwCgYIKoZIhvcNAwcwCwYJYIZIAWUDBAECMA4GCCqG SIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDAHBgUrDgMC GjALBglghkgBZQMEAgMwCwYJYIZIAWUDBAICMAsGCWCGSAFlAwQCATAKBggqhkiG9w0CBTANBgkq hkiG9w0BAQEFAASCAQAAoQOMhAjUPxNTXDuM7qHQX0R24fn5BqVN7D+dEzbzTvljxWfuV83TaWmi 7kmNj2cHO4EYk9ZZpe1DLJdgzCQuCUCXZ3JCtocvjA/kuTVPke5jDQwMR5LwYH0g3of1Hm7iyneQ i9fzIvcBE0nYuCaKXdwEzTfJ5fJHKv2oE+JjBEjEYKsRDMNWvYGYwjpu/w5HrTCW4LGysAsi6XMR QeFLjb4SLTyJaNkuoHARg8DXQh5axeAUDy2ulUgfX0YLOTso5KTyNbnk8hgaOsozQitDC8YwYSwy kD4tb7WZfd2utr7JmHZtWNNCGZ1940u3GZl90k0VupAfOLWbnJVGVWcdAAAAAAAA ------=_NextPart_000_040F_01C9A0B3.A318EE40-- From akoba@nttv6.net Mon Mar 9 05:35: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 2F40D3A6A89; Mon, 9 Mar 2009 05:35:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.199 X-Spam-Level: X-Spam-Status: No, score=0.199 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001, SUBJ_RE_NUM=2.799] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wG+2+tv++4xu; Mon, 9 Mar 2009 05:35:34 -0700 (PDT) Received: from mail.nttv6.net (mail.nttv6.net [IPv6:2001:fa8::25]) by core3.amsl.com (Postfix) with ESMTP id B59B63A69D2; Mon, 9 Mar 2009 05:35:33 -0700 (PDT) Received: from [192.47.163.152] ([IPv6:2001:fa8:1000:0:d501:48e8:3902:9e29]) by mail.nttv6.net (8.14.3/8.14.3) with ESMTP id n29Ca3YN056372; Mon, 9 Mar 2009 21:36:03 +0900 (JST) (envelope-from akoba@nttv6.net) Date: Mon, 09 Mar 2009 21:38:09 +0900 From: Atsushi Kobayashi To: "Thomas Dietz" In-Reply-To: <547F018265F92642B577B986577D671C7009CF@VENUS.office> References: <547F018265F92642B577B986577D671C7009CF@VENUS.office> Message-Id: <20090309212840.93C9.17391CF2@nttv6.net> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Becky! ver. 2.48.02 [ja] X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.0.1 (mail.nttv6.net [IPv6:2001:fa8::25]); Mon, 09 Mar 2009 21:36:03 +0900 (JST) Cc: IETF IPFIX Working Group , "MIB Doctors \(E-mail\)" Subject: Re: [IPFIX] AD review of draft-ietf-ipfix-mib-05.txt X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Mar 2009 12:35:35 -0000 Dear Thomas and all, Thomas, thank you for your effort. > > T21. I assume that selection functions will be added in the future. If > > I > > am wrong please delete all mention of extensibility and take out the > > ipfixSelectorFunctions group. If I am right, I suggest to put > > ipfixSelectorFunctions in a separate MIB module that will be IANA > > maintained, so that new functions can be added in the future without > > the > > need to revise the MIB module and the RFC. The separate MIB module will > > become the initial version of the IANA maintained module, and new > > selector functions will be added using for example Expert Review > > policy. > > > > > > I personally think this makes sense to put it in a separate MIB module which > is maintained by IANA but this needs further discussion on the list which I > will start soon. > I agree selection function MIB separated from main MIB module. It would come more flexible. > > T23. How is ipfixTransportSessionRate computed? Every second? Every T > > seconds? T=? > > > > I fixed this to one second intervals. Benoit, Atsushi any objections?? > No. I don't have strong opinion. From root@core3.amsl.com Mon Mar 9 10:30:02 2009 Return-Path: X-Original-To: ipfix@ietf.org Delivered-To: ipfix@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id 0CD643A6CF9; Mon, 9 Mar 2009 10:30: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: <20090309173002.0CD643A6CF9@core3.amsl.com> Date: Mon, 9 Mar 2009 10:30:02 -0700 (PDT) Cc: ipfix@ietf.org Subject: [IPFIX] I-D Action:draft-ietf-ipfix-configuration-model-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: Mon, 09 Mar 2009 17:30:02 -0000 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IP Flow Information Export Working Group of the IETF. Title : Configuration Data Model for IPFIX and PSAMP Author(s) : G. Muenz, B. Claise Filename : draft-ietf-ipfix-configuration-model-02.txt Pages : 68 Date : 2009-03-09 This document specifies a data model for the configuration of selection processes, caches, exporting processes, and collecting processes of IPFIX and PSAMP compliant monitoring devices. The configuration data is encoded in Extensible Markup Language (XML). The structure of the data model is specified in a YANG module to ensure compatibility with the NETCONF protocol. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ipfix-configuration-model-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-configuration-model-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2009-03-09101930.I-D@ietf.org> --NextPart-- From n.brownlee@auckland.ac.nz Mon Mar 9 20:52:44 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 BAE183A6C53 for ; Mon, 9 Mar 2009 20:52:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.605 X-Spam-Level: X-Spam-Status: No, score=-3.605 tagged_above=-999 required=5 tests=[AWL=-1.495, BAYES_05=-1.11, 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 uVWyJnyC-pKD for ; Mon, 9 Mar 2009 20:52:43 -0700 (PDT) Received: from mailhost.auckland.ac.nz (curly.its.auckland.ac.nz [130.216.12.33]) by core3.amsl.com (Postfix) with ESMTP id A17FE3A6A90 for ; Mon, 9 Mar 2009 20:52:41 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by mailhost.auckland.ac.nz (Postfix) with ESMTP id 59C179D7EC; Tue, 10 Mar 2009 16:53:15 +1300 (NZDT) 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 pnDFNGs78HMq; Tue, 10 Mar 2009 16:53:15 +1300 (NZDT) 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 C02FE9DF27; Tue, 10 Mar 2009 16:53:12 +1300 (NZDT) Message-ID: <49B5E427.6050809@auckland.ac.nz> Date: Tue, 10 Mar 2009 16:53:11 +1300 From: Nevil Brownlee User-Agent: Thunderbird 2.0.0.12 (Macintosh/20080213) MIME-Version: 1.0 To: Paul Aitken References: <49B490C4.4000407@auckland.ac.nz> <49B573DA.4030500@cisco.com> In-Reply-To: <49B573DA.4030500@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: IPFIX Working Group Subject: Re: [IPFIX] Updated agenda for San Francisco meeting 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, 10 Mar 2009 03:52:44 -0000 Hi Paul: I agree that we need to agree on a process for correcting mistakes in the Information Element Registry. For IEs in the registry that came from and RFC it's easy - we discuss them on the IPFIX list, reach consensus on the change needed, post them using the RFC Editor's Errata web page, then ask IANA to make the change as documented in the errata (i.e. giving OLD vs NEW text). For other ('new') IEs that don't come from and RFC, we need a similar process. I suggest i. Discuss/reach consensus on the list (as above) ii. Submit the proposed change to IANA as though it were a request for a new IE iii. IANA can pass the proposed change to the Expert Panel as usual iV. Once approved by the Experts, IANA can make the change We need to get IANA to agree to this, of course; so let's start that discussion. Anyone have any comments/suggestions for improvement on this suggestion? Meanwhile, perhaps Paul could start by posting a list of the RFC5101 errata to the IPFIX list, please? Cheers, Nevil Paul Aitken wrote: > Nevil, > >> If you have any further changes, please send them to me pronto :-) > > What about the fields whose bit-ordering is reversed? > > We keep overlooking that, yet it's not an insignificant and unimportant > issue. > > It should be highlighted to the WG and addressed immediately, to ensure > that all existing and future exporter and collector are correct. > > Indeed, making this correction may introduce a backwards-incompatibility > in some exporters and/or collectors. -- --------------------------------------------------------------------- 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 Mon Mar 9 21:08:46 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 E93F13A6891 for ; Mon, 9 Mar 2009 21:08:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.606 X-Spam-Level: X-Spam-Status: No, score=-4.606 tagged_above=-999 required=5 tests=[AWL=0.504, 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 GTlmZV6QMDgr for ; Mon, 9 Mar 2009 21:08:46 -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 2FE503A6405 for ; Mon, 9 Mar 2009 21:08:46 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by mailhost.auckland.ac.nz (Postfix) with ESMTP id 3F2154805A6 for ; Tue, 10 Mar 2009 17:09:20 +1300 (NZDT) 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 WTeI1eDCAO8x for ; Tue, 10 Mar 2009 17:09:20 +1300 (NZDT) 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 2306B480436 for ; Tue, 10 Mar 2009 17:09:20 +1300 (NZDT) Message-ID: <49B5E7EF.4010004@auckland.ac.nz> Date: Tue, 10 Mar 2009 17:09:19 +1300 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] ANother IPFIX agenda 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, 10 Mar 2009 04:08:47 -0000 Todays update is on the meeting agenda page, i.e. at http://www.ietf.org/proceedings/09mar/agenda/ipfix.txt Cheers, Nevil -- --------------------------------------------------------------------- Nevil Brownlee Computer Science Department | ITS Phone: +64 9 373 7599 x88941 The University of Auckland FAX: +64 9 373 7453 Private Bag 92019, Auckland 1142, New Zealand From akoba@nttv6.net Mon Mar 9 22:38:25 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 776E33A6A0A for ; Mon, 9 Mar 2009 22:38:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.201 X-Spam-Level: X-Spam-Status: No, score=-1.201 tagged_above=-999 required=5 tests=[AWL=1.399, BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FsLC+4rupyIg for ; Mon, 9 Mar 2009 22:38:24 -0700 (PDT) Received: from mail.nttv6.net (mail.nttv6.net [IPv6:2001:fa8::25]) by core3.amsl.com (Postfix) with ESMTP id 312403A6C5B for ; Mon, 9 Mar 2009 22:38:23 -0700 (PDT) Received: from [192.47.163.152] ([IPv6:2001:fa8:1000:0:61a0:b7e4:1216:d611]) by mail.nttv6.net (8.14.3/8.14.3) with ESMTP id n2A5cvUA010440 for ; Tue, 10 Mar 2009 14:38:57 +0900 (JST) (envelope-from akoba@nttv6.net) Date: Tue, 10 Mar 2009 14:40:07 +0900 From: Atsushi Kobayashi To: IETF IPFIX Working Group Message-Id: <20090310143843.EFCF.17391CF2@nttv6.net> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Becky! ver. 2.48.02 [ja] X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.0.1 (mail.nttv6.net [IPv6:2001:fa8::25]); Tue, 10 Mar 2009 14:38:57 +0900 (JST) Subject: [IPFIX] draft-boschi-ipfix-anon-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: Tue, 10 Mar 2009 05:38:25 -0000 Dear Elisa, Brian and all, This draft well categorizes anonymization techniques. It is very useful of even those who are not familiar with this techniques. In last meeting, we decided that mediation drafts should add the summary of anonymization draft. According to it, I put the anonymization summary in the IPFIX Mediator problem statement draft, as follows. Let me know your comments, if you have different idea. http://tools.ietf.org/html/draft-ietf-ipfix-mediators-problem-statement-02#section-5.9 5.9. IPFIX Export Across Domains IPFIX exports across administrative domains can be used to measure traffic for wide-area traffic engineering or to analyze Internet traffic trends. In such cases, administrators need to adhere to privacy protection policies and prevent access to confidential traffic measurements by other people. Typically, anonymization techniques enables the provision of traffic data to other people without violating these policies. Generally, anonymization modifies a data set to protect the identity of the people or entities described by the data set from being disclosed. It also attempts to preserve sets of network traffic properties useful for a given analysis while ensuring the data cannot be traced back to the specific networks, hosts, or users generating the traffic. For example, IP address anonymization is particularly important for avoiding the identification of the users, hosts, and routers in a network domain. The details of these anonymization techniques are out of the scope of this document. Implementation analysis: One possible implementation for this case uses an anonymization function at the Original Exporter. However, this increases the load of the Metering Process at the Original Exporter. A more flexible implementation uses an IPFIX Masquerading Proxy between the Original Exporter and Collector. --- Atsushi KOBAYASHI NTT Information Sharing Platform Lab. tel:+81-(0)422-59-3978 fax:+81-(0)422-59-5637 From wwwrun@core3.amsl.com Tue Mar 10 07:41:33 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 2DFFD3A6908; Tue, 10 Mar 2009 07:41:32 -0700 (PDT) X-idtracker: yes To: IETF-Announce From: The IESG Message-Id: <20090310144133.2DFFD3A6908@core3.amsl.com> Date: Tue, 10 Mar 2009 07:41:33 -0700 (PDT) Cc: ipfix@ietf.org Subject: [IPFIX] Last Call: draft-ietf-ipfix-exporting-type (Exporting Type Information for IPFIX Information Elements) to Proposed Standard X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: ietf@ietf.org List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Mar 2009 14:41:33 -0000 The IESG has received a request from the IP Flow Information Export WG (ipfix) to consider the following document: - 'Exporting Type Information for IPFIX Information Elements ' as a Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2009-03-24. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. The file can be obtained via http://www.ietf.org/internet-drafts/draft-ietf-ipfix-exporting-type-02.txt IESG discussion can be tracked via https://datatracker.ietf.org/public/pidtracker.cgi?command=view_id&dTag=16889&rfc_flag=0 The following IPR Declarations may be related to this I-D: From akoba@nttv6.net Wed Mar 11 01:05:44 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 E3CFE28C101 for ; Wed, 11 Mar 2009 01:05:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.667 X-Spam-Level: X-Spam-Status: No, score=-1.667 tagged_above=-999 required=5 tests=[AWL=0.933, BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ph2FcQZ3AAW5 for ; Wed, 11 Mar 2009 01:05:44 -0700 (PDT) Received: from mail.nttv6.net (mail.nttv6.net [IPv6:2001:fa8::25]) by core3.amsl.com (Postfix) with ESMTP id 76E1D3A6A3A for ; Wed, 11 Mar 2009 01:05:43 -0700 (PDT) Received: from [192.47.163.152] ([IPv6:2001:fa8:1000:0:d068:49dc:3bcd:9d82]) by mail.nttv6.net (8.14.3/8.14.3) with ESMTP id n2B86HNF032699 for ; Wed, 11 Mar 2009 17:06:17 +0900 (JST) (envelope-from akoba@nttv6.net) Date: Wed, 11 Mar 2009 17:07:48 +0900 From: Atsushi Kobayashi To: IETF IPFIX Working Group Message-Id: <20090311170006.4A93.17391CF2@nttv6.net> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Becky! ver. 2.48.02 [ja] X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.0.1 (mail.nttv6.net [IPv6:2001:fa8::25]); Wed, 11 Mar 2009 17:06:18 +0900 (JST) Subject: [IPFIX] IPFIX Mediation comments 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, 11 Mar 2009 08:05:45 -0000 Dear Gerhard, Benoit, Christoph and all, I arranged the comments received from you. Almost comments have been finished so far, but some technical comments need more discussion and some editing comments are not done yet. I would like to get your feedback about some technical issues and remaing issues. Your feedbacks would be very appreciated. Problem statement comments: http://www.nttv6.net/~akoba/ps-01.html Technical issues are 1, 2, 12, 24. Still remaining comments are 4, 11, 28, 29, 44. Framework comments: http://www.nttv6.net/~akoba/fk-01.html Technical issues are 1, 8, 12. Best Regards, Atsushi Kobayashi --- Atsushi KOBAYASHI NTT Information Sharing Platform Lab. tel:+81-(0)422-59-3978 fax:+81-(0)422-59-5637 From trammell@tik.ee.ethz.ch Wed Mar 11 01:33:29 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 7AC113A69FE for ; Wed, 11 Mar 2009 01:33:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.419 X-Spam-Level: X-Spam-Status: No, score=-6.419 tagged_above=-999 required=5 tests=[AWL=0.180, 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 gJJ7tSYzI9et for ; Wed, 11 Mar 2009 01:33:28 -0700 (PDT) Received: from smtp.ee.ethz.ch (smtp.ee.ethz.ch [129.132.2.219]) by core3.amsl.com (Postfix) with ESMTP id B0EBF3A6880 for ; Wed, 11 Mar 2009 01:33:27 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by smtp.ee.ethz.ch (Postfix) with ESMTP id 03408D9399; Wed, 11 Mar 2009 09:34:02 +0100 (MET) 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 j2z+cW5lxgjP; Wed, 11 Mar 2009 09:34:01 +0100 (MET) 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 64A11D9382; Wed, 11 Mar 2009 09:34:01 +0100 (MET) Message-Id: <19D8A87F-E605-4B19-A8BD-CB35DCA7D96B@tik.ee.ethz.ch> From: Brian Trammell To: Atsushi Kobayashi In-Reply-To: <20090310143843.EFCF.17391CF2@nttv6.net> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v930.3) Date: Wed, 11 Mar 2009 09:34:00 +0100 References: <20090310143843.EFCF.17391CF2@nttv6.net> X-Mailer: Apple Mail (2.930.3) Cc: IETF IPFIX Working Group Subject: Re: [IPFIX] draft-boschi-ipfix-anon-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: Wed, 11 Mar 2009 08:33:29 -0000 Dear Kobayashi-san, all, On first glance, this looks good. I might have a couple of edits, but I'd like to have a look over the whole document in San Francisco. We'll have an updated revision of the anonymisation draft, with a few more details on the implementation of anonymisation export within IPFIX available shortly, but this new revision shouldn't have any impact on the interaction with the mediation draft at this time... Kind regards, Brian On Mar 10, 2009, at 6:40 AM, Atsushi Kobayashi wrote: > > Dear Elisa, Brian and all, > > This draft well categorizes anonymization techniques. It is very > useful > of even those who are not familiar with this techniques. > > In last meeting, we decided that mediation drafts should add the > summary > of anonymization draft. > > According to it, I put the anonymization summary in the IPFIX > Mediator problem statement draft, as follows. > > Let me know your comments, if you have different idea. > > http://tools.ietf.org/html/draft-ietf-ipfix-mediators-problem-statement-02#section-5.9 > > 5.9. IPFIX Export Across Domains > > IPFIX exports across administrative domains can be used to measure > traffic for wide-area traffic engineering or to analyze Internet > traffic trends. In such cases, administrators need to adhere to > privacy protection policies and prevent access to confidential > traffic measurements by other people. Typically, anonymization > techniques enables the provision of traffic data to other people > without violating these policies. > > Generally, anonymization modifies a data set to protect the identity > of the people or entities described by the data set from being > disclosed. It also attempts to preserve sets of network traffic > properties useful for a given analysis while ensuring the data > cannot > be traced back to the specific networks, hosts, or users generating > the traffic. For example, IP address anonymization is particularly > important for avoiding the identification of the users, hosts, and > routers in a network domain. The details of these anonymization > techniques are out of the scope of this document. > > Implementation analysis: > > One possible implementation for this case uses an anonymization > function at the Original Exporter. However, this increases the > load of the Metering Process at the Original Exporter. A more > flexible implementation uses an IPFIX Masquerading Proxy between > the Original Exporter and Collector. > > --- > Atsushi KOBAYASHI > NTT Information Sharing Platform Lab. > tel:+81-(0)422-59-3978 fax:+81-(0)422-59-5637 > > _______________________________________________ > IPFIX mailing list > IPFIX@ietf.org > https://www.ietf.org/mailman/listinfo/ipfix From akoba@nttv6.net Wed Mar 11 02:34:50 2009 Return-Path: X-Original-To: ipfix@core3.amsl.com Delivered-To: ipfix@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 78C0628C1C4 for ; Wed, 11 Mar 2009 02:34:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.501 X-Spam-Level: X-Spam-Status: No, score=-0.501 tagged_above=-999 required=5 tests=[AWL=-0.700, BAYES_00=-2.599, NO_RELAYS=-0.001, SUBJ_RE_NUM=2.799] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Q+LRd7QWl1Jt for ; Wed, 11 Mar 2009 02:34:49 -0700 (PDT) Received: from mail.nttv6.net (mail.nttv6.net [IPv6:2001:fa8::25]) by core3.amsl.com (Postfix) with ESMTP id 2FFF828C1C8 for ; Wed, 11 Mar 2009 02:34:48 -0700 (PDT) Received: from [192.47.163.152] ([IPv6:2001:fa8:1000:0:6494:5b3e:7b38:8bdd]) by mail.nttv6.net (8.14.3/8.14.3) with ESMTP id n2B9ZNUd033195; Wed, 11 Mar 2009 18:35:24 +0900 (JST) (envelope-from akoba@nttv6.net) Date: Wed, 11 Mar 2009 18:36:31 +0900 From: Atsushi Kobayashi To: Brian Trammell In-Reply-To: <19D8A87F-E605-4B19-A8BD-CB35DCA7D96B@tik.ee.ethz.ch> References: <20090310143843.EFCF.17391CF2@nttv6.net> <19D8A87F-E605-4B19-A8BD-CB35DCA7D96B@tik.ee.ethz.ch> Message-Id: <20090311182458.81CD.17391CF2@nttv6.net> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Becky! ver. 2.48.02 [ja] X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.0.1 (mail.nttv6.net [IPv6:2001:fa8::25]); Wed, 11 Mar 2009 18:35:24 +0900 (JST) Cc: IETF IPFIX Working Group Subject: Re: [IPFIX] draft-boschi-ipfix-anon-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: Wed, 11 Mar 2009 09:34:50 -0000 Dear Brian, On Wed, 11 Mar 2009 09:34:00 +0100 Brian Trammell wrote: > Dear Kobayashi-san, all, > > On first glance, this looks good. I might have a couple of edits, but > I'd like to have a look over the whole document in San Francisco. Thank you. Your feedbacks welcome. Atsushi KOBAYASHI > > We'll have an updated revision of the anonymisation draft, with a few > more details on the implementation of anonymisation export within > IPFIX available shortly, but this new revision shouldn't have any > impact on the interaction with the mediation draft at this time... > > Kind regards, > > Brian > > On Mar 10, 2009, at 6:40 AM, Atsushi Kobayashi wrote: > > > > > Dear Elisa, Brian and all, > > > > This draft well categorizes anonymization techniques. It is very > > useful > > of even those who are not familiar with this techniques. > > > > In last meeting, we decided that mediation drafts should add the > > summary > > of anonymization draft. > > > > According to it, I put the anonymization summary in the IPFIX > > Mediator problem statement draft, as follows. > > > > Let me know your comments, if you have different idea. > > > > http://tools.ietf.org/html/draft-ietf-ipfix-mediators-problem-statement-02#section-5.9 > > > > 5.9. IPFIX Export Across Domains > > > > IPFIX exports across administrative domains can be used to measure > > traffic for wide-area traffic engineering or to analyze Internet > > traffic trends. In such cases, administrators need to adhere to > > privacy protection policies and prevent access to confidential > > traffic measurements by other people. Typically, anonymization > > techniques enables the provision of traffic data to other people > > without violating these policies. > > > > Generally, anonymization modifies a data set to protect the identity > > of the people or entities described by the data set from being > > disclosed. It also attempts to preserve sets of network traffic > > properties useful for a given analysis while ensuring the data > > cannot > > be traced back to the specific networks, hosts, or users generating > > the traffic. For example, IP address anonymization is particularly > > important for avoiding the identification of the users, hosts, and > > routers in a network domain. The details of these anonymization > > techniques are out of the scope of this document. > > > > Implementation analysis: > > > > One possible implementation for this case uses an anonymization > > function at the Original Exporter. However, this increases the > > load of the Metering Process at the Original Exporter. A more > > flexible implementation uses an IPFIX Masquerading Proxy between > > the Original Exporter and Collector. > > > > --- > > Atsushi KOBAYASHI > > NTT Information Sharing Platform Lab. > > tel:+81-(0)422-59-3978 fax:+81-(0)422-59-5637 > > > > _______________________________________________ > > 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 Elisa.Boschi@Hitachi-eu.com Thu Mar 12 06:23: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 E962728C100 for ; Thu, 12 Mar 2009 06:23:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[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 qwEh07ABsV2k for ; Thu, 12 Mar 2009 06:23:03 -0700 (PDT) Received: from gatekeeper.hitachi-eu.com (gatekeeper.hitachi-eu.com [194.36.128.25]) by core3.amsl.com (Postfix) with ESMTP id 7F9423A6901 for ; Thu, 12 Mar 2009 06:23:02 -0700 (PDT) X-ASG-Debug-ID: 1236864218-38cd033b0000-urGyNO X-Barracuda-URL: http://mhd-bar.hitachi-eu.com:8000/cgi-bin/mark.cgi Received: from mhd-mta-int.hitachi-eu.com (localhost [127.0.0.1]) by gatekeeper.hitachi-eu.com (Spam Firewall) with ESMTP id E1953199152 for ; Thu, 12 Mar 2009 13:23:38 +0000 (GMT) Received: from mhd-mta-int.hitachi-eu.com ([193.39.225.234]) by gatekeeper.hitachi-eu.com with ESMTP id xRFpx994kdnCDL0u for ; Thu, 12 Mar 2009 13:23:38 +0000 (GMT) X-ASG-Whitelist: Client Received: from MHDEXC99.adhel.hitachi-eu.com (Not Verified[193.39.227.52]) by mhd-mta-int.hitachi-eu.com with MailMarshal (v6, 2, 1, 3252) id ; Thu, 12 Mar 2009 13:23:38 +0000 Received: from mhdexcb.adhel.hitachi-eu.com ([193.39.227.47]) by MHDEXC99.adhel.hitachi-eu.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 12 Mar 2009 13:23:38 +0000 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C9A315.C0808908" X-ASG-Orig-Subj: Re: [IPFIX] Updated agenda for San Francisco meeting Date: Thu, 12 Mar 2009 13:23:37 -0000 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [IPFIX] Updated agenda for San Francisco meeting Thread-Index: AcmjFN/z7D5/1m5QQkCrfwviU8/+Ag== From: "Boschi, Elisa" To: , X-OriginalArrivalTime: 12 Mar 2009 13:23:38.0061 (UTC) FILETIME=[C0C5F7D0:01C9A315] X-Barracuda-Connect: UNKNOWN[193.39.225.234] X-Barracuda-Start-Time: 1236864218 X-Barracuda-Virus-Scanned: by HEU SPAM Firewall - MHD at hitachi-eu.com Subject: Re: [IPFIX] Updated agenda for San Francisco meeting 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, 12 Mar 2009 13:23:05 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01C9A315.C0808908 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Nevil, all, we have a new revision of the anonymisation draft, which we would like to= =20present and discuss at the meeting: draft-boschi-ipfix-anon-03.txt Unfortunately we missed the submission deadline, but the document can be = accessed here: http://people.ee.ethz.ch/~boschie/draft-boschi-ipfix-anon-03.txt thanks, Elisa Nevil Brownlee wrote: > Hi all: >=20 > If you have any further changes, please send them to me > pronto :-) >=20 > Cheers, Nevil >=20 >=20 > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D > Ip Flow Information Export WG (ipfix) > IETF #74, San Francisco > Monday, 23 Mar 09 at 1300-1500 > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D >=20 > Chairs: > Juergen Quittek > Nevil Brownlee >=20 > >>> DRAFT <<< AGENDA: >=20 > 1. Agenda review WG Status =3D 5 min >=20 > 2. Internet-Draft status =3D 5 min > [In RFC Editor queue: > - draft-ietf-ipfix-architecture-12.txt > - draft-ietf-ipfix-as-12.txt > - draft-ietf-ipfix-reducing-redundancy-04.txt > - draft-ietf-ipfix-testing-04.txt > - draft-ietf-psamp-framework-13.txt > - draft-ietf-psamp-sample-tech-10.txt > - draft-ietf-psamp-protocol-09.txt > - draft-ietf-psamp-info-11.txt] >=20 > 3. Information Element Registry status =3D 5 min > IANA's XML page for this are now at > http://www.iana.org/assignments/ipfix/ipfix.xhtml > We are now handling errata found in RFC 5102, IANA should > change the registry for such changes; We need to establish > a procedure for handling changes in other IEs >=20 > 4. Drafts submitted to IESG =3D 15 min > a) IPFIX File Format (Brian Trammell) ( 3 min) > - draft-ietf-ipfix-file-03.txt 24 Oct 08 > b) Exporting Type Information for IPFIX IEs (Elisa Boschi) > - draft-ietf-ipfix-exporting-type-02.txt 14 Jul 08 ( 3 min) >=20 > c) IPFIX MIB (Thomas Dietz) > - draft-dietz-ipfix-mib-05.txt 3 Nov 08 > MIB Doctors have requested a revised draft ( 9 min) >=20 > 5. Current WG drafts =3D 50 min > a) IPFIX Per-Stream SCTP reporting (Benoit CLaise) ( 5 min) > - draft-ietf-ipfix-export-per-sctp-stream-02.txt > 26 Jan 09 > b) Configuration Data Model ( 5 min) > - draft-ietf-ipfix-configuration-model-01.txt > 3 Nov 08 > c) IPFIX Mediation: (Kobayashi Atsushi) (15 min) > - draft-ietf-ipfix-mediators-problem-statement-02.txt > 4 Feb 09 > - draft-ietf-ipfix-mediators-framework-02.txt (25 min) > 10 Feb 09 >=20 > 6. Other drafts =3D 30 min > a) Flow Selection (Lorenzo Peluso, Tanja Zseby) (10 min) > - draft-peluso-flowselection-tech-02 >=20 > b) IP Flow Anonymization Support (Elisa Bschi, Brian Trammel) > - draft-boschi-ipfix-anon-02 12 Jan 09 (10 min) >=20 > c) Handling Structured Data (Benoit Claise) > - draft-claise-structured-data-in-ipfix-00.txt (10 min) >=20 > 7. Any Other Drafts ??? =3D 10 min >=20 >=20 > Presentation slides will be available at > https://datatracker.ietf.org/public/meeting_materials.cgi?meeting_num=3D= 74 > (search for IPFIX in the Operations and Management Area) >=20 > Participation via jabber is offered at ipfix@jabber.ietf.org >=20 *************************************************************************= *************************=20 E-mail Confidentiality Notice and Disclaimer.=20 This e-mail and any files transmitted with it are confidential and are in= tended solely for the use=20 of the individual or entity to which they are addressed. Access to this e= -mail by anyone else is=20 unauthorised. If you are not the intended recipient, any disclosure, copy= ing, distribution or any action taken or omitted to be taken in reliance on it, is prohibited. E-m= ail messages are not=20 necessarily secure. Hitachi does not accept responsibility for any change= s made to this message=20 after it was sent.=20 Hitachi checks outgoing e-mail messages for the presence of computer viru= ses.=20 *************************************************************************= ************************* ------_=_NextPart_001_01C9A315.C0808908 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Re: [IPFIX] Updated agenda for San Francisco meeting

Nevil, all,

we have a new revision of the anonymisation draft, which we would like to= =20present and discuss at the meeting:
draft-boschi-ipfix-anon-03.txt
Unfortunately we missed the submission deadline, but the document can be = accessed here:
http://people.ee.ethz.ch/~boschie/draft-boschi-ipfix-anon-03.txt<= BR>
thanks,
Elisa

Nevil Brownlee wrote:
> Hi all:
>
> If you have any further changes, please send them to me
> pronto :-)
>
> Cheers, Nevil
>
>
> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D
> Ip Flow Information Export WG (ipfix)
> IETF #74, San Francisco
> Monday, 23 Mar 09 at 1300-1500
> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D
>
> Chairs:
> Juergen Quittek <quittek@netlab.nec.de>
> Nevil Brownlee  <n.brownlee@auckland.ac.nz>
>
>  >>> DRAFT <<<  AGENDA:
>
> 1. Agenda review WG Status       =             &= nbsp;          =3D 5 min
= >
> 2. Internet-Draft status       &n= bsp;           &nb= sp;            =3D= =205 min
>      [In RFC Editor queue:
>        - draft-ietf-ipfix-archite= cture-12.txt
>        - draft-ietf-ipfix-as-12.t= xt
>        - draft-ietf-ipfix-reducin= g-redundancy-04.txt
>        - draft-ietf-ipfix-testing= -04.txt
>        - draft-ietf-psamp-framewo= rk-13.txt
>        - draft-ietf-psamp-sample-= tech-10.txt
>        - draft-ietf-psamp-protoco= l-09.txt
>        - draft-ietf-psamp-info-11= .txt]
>
> 3. Information Element Registry status     =             =3D 5 = min
>       IANA's XML page for this are now= =20at
>         http://www.iana.org/assignments= /ipfix/ipfix.xhtml
>       We are now handling errata found= =20in RFC 5102, IANA should
>       change the registry for such cha= nges;  We need to establish
>       a procedure for handling changes= =20in other IEs
>
> 4. Drafts submitted to IESG       = ;            =           =3D 15 min
>    a) IPFIX File Format (Brian Trammell)  &= nbsp;           &n= bsp;     ( 3 min)
>       - draft-ietf-ipfix-file-03.txt&n= bsp; 24 Oct 08
>    b) Exporting Type Information for IPFIX IEs (Elisa= =20Boschi)
>       - draft-ietf-ipfix-exporting-typ= e-02.txt  14 Jul 08   ( 3 min)
>
>    c) IPFIX MIB (Thomas Dietz)
>       - draft-dietz-ipfix-mib-05.txt&n= bsp; 3 Nov 08
>           MIB Doct= ors have requested a revised draft      &nb= sp; ( 9 min)
>
> 5. Current WG drafts        =             &= nbsp;           &n= bsp;   =3D 50 min
>    a) IPFIX Per-Stream SCTP reporting (Benoit CLaise)=        ( 5 min)
>       - draft-ietf-ipfix-export-per-sc= tp-stream-02.txt
>           26 Jan 0= 9
>    b) Configuration Data Model    = ;            =             &= nbsp; ( 5 min)
>       - draft-ietf-ipfix-configuration= -model-01.txt
>            3 = Nov 08
>    c) IPFIX Mediation: (Kobayashi Atsushi)  = ;            =     (15 min)
>       - draft-ietf-ipfix-mediators-pro= blem-statement-02.txt
>            4 = Feb 09
>       - draft-ietf-ipfix-mediators-fra= mework-02.txt         (25 min) >           10 Feb 0= 9
>
> 6. Other drafts         = ;            =             &= nbsp;       =3D 30 min
>    a) Flow Selection (Lorenzo Peluso, Tanja Zseby)&nb= sp;         (10 min)
>        - draft-peluso-flowselecti= on-tech-02
>
>    b) IP Flow Anonymization Support (Elisa Bschi, Bri= an Trammel)
>        - draft-boschi-ipfix-anon-= 02  12 Jan 09         &= nbsp;    (10 min)
>
>    c) Handling Structured Data (Benoit Claise)
>        - draft-claise-structured-= data-in-ipfix-00.txt       (10 min)
>
> 7. Any Other Drafts ???       &nb= sp;           &nbs= p;            = ; =3D 10 min
>
>
> Presentation slides will be available at
>  https://datatracker.ietf.org/public/meeting_mate= rials.cgi?meeting_num=3D74
>  (search for IPFIX in the Operations and Management Area)
>
> Participation via jabber is offered at ipfix@jabber.ietf.org
>

************= *************************************************************************= *************
E-mail=20 Confidentiality Notice and Disclaimer.

This e-mail and any files transmitted with it are confiden= tial and=20 are intended solely for the use of the individual or entity to which they= =20are=20 addressed. Access to this e-mail by anyone else is unauthorised. If you a= re not=20 the intended recipient, any disclosure, copying, distribution or any acti= on=20 taken or omitted to be taken in reliance on it, is prohibited.
E-mail= =20 messages are not necessarily secure.
Hitachi does not accept responsi= bility=20 for any changes made to this message after it was sent.
Hitachi checks= =20 outgoing e-mail messages for the presence of computer viruses.=20
*********************************************************************= *****************************=20

------_=_NextPart_001_01C9A315.C0808908-- From ralbrigh@cisco.com Thu Mar 12 12:23:13 2009 Return-Path: X-Original-To: ipfix@core3.amsl.com Delivered-To: ipfix@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 410DC3A68F2 for ; Thu, 12 Mar 2009 12:23:13 -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 MrE4j1vKyCQG for ; Thu, 12 Mar 2009 12:23:12 -0700 (PDT) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by core3.amsl.com (Postfix) with ESMTP id F20C13A6962 for ; Thu, 12 Mar 2009 12:23:11 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.38,352,1233532800"; d="scan'208";a="266346900" Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-6.cisco.com with ESMTP; 12 Mar 2009 19:23:49 +0000 Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id n2CJNm8P010982 for ; Thu, 12 Mar 2009 12:23:48 -0700 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-5.cisco.com (8.13.8/8.13.8) with ESMTP id n2CJNm1b012261 for ; Thu, 12 Mar 2009 19:23:48 GMT Received: from xmb-sjc-229.amer.cisco.com ([128.107.191.122]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 12 Mar 2009 12:23:48 -0700 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, 12 Mar 2009 12:23:48 -0700 Message-ID: <3E461BB921259141B8D244D10C1D331D05BC5CC6@xmb-sjc-229.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: IPR Statement RE: draft-claise-structured-data-in-ipfix-00 Thread-Index: AcmiiG5DW9fX3G9XRM+JiUnxOiT8YAAv5P9w From: "Rachel Albright -X (ralbrigh - Unknown at Cisco)" To: X-OriginalArrivalTime: 12 Mar 2009 19:23:48.0693 (UTC) FILETIME=[11B6B850:01C9A348] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=1847; t=1236885828; x=1237749828; c=relaxed/simple; s=sjdkim1004; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=ralbrigh@cisco.com; z=From:=20=22Rachel=20Albright=20-X=20(ralbrigh=20-=20Unknow n=20at=20Cisco)=22=20 |Subject:=20FW=3A=20IPR=20Statement=20RE=3A=20draft-claise- structured-data-in-ipfix-00 |Sender:=20; bh=TfEwfHyB42p0G10Lm4YsqV1hj6XmzUrdsFzXalV1PWU=; b=JCHgPalXMsZXF1lD++SLcmJT40suH1rHr0kjyrNxd6LAlcdKmKW5O03Qqo xGf/JYvJA01t+2NbBErRhQFpJ0Gk/FjOztLvlf2lUU9b7wRs+9+/GJNoMmgx AFVyw+g7+80SqjukFnVzVHvY9bdKtAV4ZivaiWmujwXTDDiadP3zk=; Authentication-Results: sj-dkim-1; header.From=ralbrigh@cisco.com; dkim=pass ( sig from cisco.com/sjdkim1004 verified; ); X-Mailman-Approved-At: Thu, 12 Mar 2009 13:31:53 -0700 Subject: [IPFIX] FW: IPR Statement RE: draft-claise-structured-data-in-ipfix-00 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, 12 Mar 2009 19:23:13 -0000 =20 From: Rachel Albright (ralbrigh)=20 Sent: Wednesday, March 11, 2009 1:32 PM To: ietf-ipr@ietf.org Cc: Benoit Claise (bclaise); Gowri Dhandapani (gowri); Stan Yates (syates); Paul Aitken (paitken) Subject: IPR Statement RE: draft-claise-structured-data-in-ipfix-00 Cisco is the owner of one or more pending unpublished patent applications relating to the subject matter of "Export of Structured Data in IPFIX" .=20 =20 If technology in this document is included in a standard adopted by IETF and any claims of any Cisco patents are necessary for practicing the standard, any party will have the right to use any such patent claims under reasonable, non-discriminatory terms, with reciprocity, to implement and fully comply with the standard. =20 The reasonable non-discriminatory terms are: =20 If this standard is adopted, Cisco will not assert any patents owned or controlled by Cisco against any party for making, using, selling, importing or offering for sale a product that implements the standard, provided, however that Cisco retains the right to assert its patents (including the right to claim past royalties) against any party that asserts a patent it owns or controls (either directly or indirectly) against Cisco or any of Cisco's affiliates or successors in title or against any products of Cisco or any products of any of Cisco's affiliates either alone or in combination with other products; and Cisco retains the right to assert its patents against any product or portion thereof that is not necessary for compliance with the standard. =20 Royalty-bearing licenses will be available to anyone who prefers that option. For information contact: =20 Dan Lang Director, Intellectual Property Cisco Systems +1 408-526-6672 standards-ipr@cisco.com From wwwrun@core3.amsl.com Thu Mar 12 15:53:24 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 4B40B3A6C1E; Thu, 12 Mar 2009 15:53:24 -0700 (PDT) To: bclaise@cisco.com, paitken@cisco.com, muenz@informatik.uni-tuebingen.de, andrjohn@cisco.com From: IETF Secretariat Message-Id: <20090312225324.4B40B3A6C1E@core3.amsl.com> Date: Thu, 12 Mar 2009 15:53:24 -0700 (PDT) X-Mailman-Approved-At: Thu, 12 Mar 2009 16:25:43 -0700 Cc: , "quittek@netlab.nec.deipr-announce"@ietf.org, ipfix@ietf.org, rbonica@juniper.net, n.brownlee@auckland.ac.nz Subject: [IPFIX] Posting of IPR Disclosure related to Cisco's Statement of IPR relating to draft-ietf-ipfix-export-per-sctp-stream-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: Thu, 12 Mar 2009 22:53:24 -0000 Dear Benoit Claise, Paul Aitken, Gerhard Muenz, Andrew Johnson: An IPR disclosure that pertains to your Internet-Draft entitled "IPFIX Export per SCTP Stream" (draft-ietf-ipfix-export-per-sctp-stream) was submitted to the IETF Secretariat on 2009-03-11 and has been posted on the "IETF Page of Intellectual Property Rights Disclosures" (https://datatracker.ietf.org/ipr/1112/). The title of the IPR disclosure is "Cisco's Statement of IPR relating to draft-ietf-ipfix-export-per-sctp-stream-02." The IETF Secretariat From dromasca@avaya.com Wed Mar 18 06:56: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 2025C3A6B54; Wed, 18 Mar 2009 06:56:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.528 X-Spam-Level: X-Spam-Status: No, score=-2.528 tagged_above=-999 required=5 tests=[AWL=0.071, 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 9QVb1COJqjNc; Wed, 18 Mar 2009 06:56:47 -0700 (PDT) Received: from nj300815-nj-outbound.net.avaya.com (nj300815-nj-outbound.net.avaya.com [198.152.12.100]) by core3.amsl.com (Postfix) with ESMTP id 0A8553A6AB6; Wed, 18 Mar 2009 06:56:46 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.38,384,1233550800"; d="scan'208";a="155694481" Received: from unknown (HELO co300216-co-erhwest.avaya.com) ([198.152.7.5]) by nj300815-nj-outbound.net.avaya.com with ESMTP; 18 Mar 2009 09:57:30 -0400 Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.12]) by co300216-co-erhwest-out.avaya.com with ESMTP; 18 Mar 2009 09:57:28 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Wed, 18 Mar 2009 14:57:16 +0100 Message-ID: In-Reply-To: <547F018265F92642B577B986577D671C7009CF@VENUS.office> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [IPFIX] AD review of draft-ietf-ipfix-mib-05.txt Thread-Index: AcmRHJmf24PVuTAzTrOZoe2H0CfpvQPihcJAAcqLQMA= References: <547F018265F92642B577B986577D671C7009CF@VENUS.office> From: "Romascanu, Dan (Dan)" To: "Thomas Dietz" , "IETF IPFIX Working Group" Cc: "MIB Doctors \(E-mail\)" Subject: Re: [IPFIX] AD review of draft-ietf-ipfix-mib-05.txt X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Mar 2009 13:56:49 -0000 Thank you for addressing my comments. Most of the issues were acknowledged and fixed accordingly. T19 and T21 still need discussion, while T23 needs to be acknowledged by the other editors.=20 My question to the WG chairs is whether we should send the document to IETF Last Call, considering the open issues as Last Call issues, to be answered and resolved together with other Last Call comments we receive. Dan =20 > -----Original Message----- > From: Thomas Dietz [mailto:Thomas.Dietz@nw.neclab.eu]=20 > Sent: Monday, March 09, 2009 1:26 PM > To: Romascanu, Dan (Dan); IETF IPFIX Working Group > Cc: MIB Doctors (E-mail) > Subject: RE: [IPFIX] AD review of draft-ietf-ipfix-mib-05.txt >=20 > Dear Dan, all, >=20 > find my comments inline... >=20 > --=20 > Thomas Dietz E-mail: Thomas.Dietz@nw.neclab.eu > NEC Europe Ltd. Phone: +49 6221 4342-128 > NEC Laboratories Europe Fax: +49 6221 4342-155 > Network Research Division > Kurfuersten-Anlage 36 > 69115 Heidelberg, Germany http://www.nw.neclab.eu >=20 > NEC Europe Limited Registered in England 2832014 > Registered Office: NEC House, 1 Victoria Road, London W3 6BL >=20 > > -----Original Message----- > > From: ipfix-bounces@ietf.org=20 > [mailto:ipfix-bounces@ietf.org] On Behalf=20 > > Of Romascanu, Dan (Dan) > > Sent: Dienstag, 17. Februar 2009 17:27 > > To: IETF IPFIX Working Group > > Cc: MIB Doctors (E-mail) > > Subject: [IPFIX] AD review of draft-ietf-ipfix-mib-05.txt > >=20 > > Please find below the AD (and MIB doctor) review of=20 > > draft-ietf-ipfix-mib-05.txt. This I-D is not ready yet for=20 > IETF Last=20 > > Call. Please address the issues below and issue a new I-D. > >=20 > > Part of the comments were contributed by Bert Wijnen. > >=20 > > I have divided the comments into Technical and Editorial. > >=20 > > Thanks and Regards, > >=20 > > Dan > >=20 > >=20 > > T1. INET-ADDRESS-MIB is IMPORT-ed from RFC 4001and not from RFC 3291 >=20 > Fixed. >=20 > >=20 > > T2. There is no real justification for defining a new TC for=20 > > IpfixFunctionAvailability. As per RFC 4181, use TruthValue instead. > >=20 >=20 > You are right. Fixed. >=20 > > T3. The top level structure of the MIB does not follow the=20 > > recommendation in Appendix D of RFC 4181 concerning the OID layout: > >=20 > > xxxMIB > > | > > +-- xxxNotifications(0) > > +-- xxxObjects(1) > > +-- xxxConformance(2) > > | > > +-- xxxCompliances(1) > > +-- xxxGroups(2) > >=20 >=20 > Fixed as well. >=20 > > T4. The object iffixTransportSessionProtocol uses only 3 out of the=20 > > 255 possible values in the range (6, 17, 132). A better=20 > SYNTAX would=20 > > be just INTEGER and then enumerate the three values in the=20 > > MODULE-COMPLIANCE clause. This would allow future changes by just=20 > > another MODULE-COMPLIANCE if there is a need to add a new=20 > protocol. If=20 > > you believe that another transport will be never added the=20 > appropriate=20 > > SYNTAX would be INTEGER (6|17|132). Also provide=20 > >=20 > http://www.iana.org/assignments/protocol-numbers/protocol-numbers.xhtm > > l > > as REFERENCE. > >=20 >=20 > I have put that into the module compliance section. >=20 > > T5. There is only one InetAddressType object for both source and=20 > > destination addresses. Does this mean that an IPFIX session is only > > IPv4 > > to IPv4 or IPv6 to IPv6? This is a question, I apologize if it is a=20 > > layman one. In any case, it would be good to write an=20 > explanation, as=20 > > users of the RFC 4001 addresses TCs are used to always=20 > encounter pairs=20 > > of type-address objects. >=20 > Just a mistake by myself. I added a object for source and=20 > destination address. >=20 >=20 > >=20 > > T6. Why are the address type and addresses objects only=20 > valid for UDP=20 > > and TCP, and not for SCTP? Are not STCP session also=20 > conducted between=20 > > IP hosts that can be described by IP addresses? > >=20 >=20 > Because we use the SCTP Association Id defined in the SCTP=20 > MIB for that. > Thus the SCTP MIB holds IPs and ports for the association Id.=20 > Clarified that in the description. >=20 > > T7. What does 'this object is only valid' mean for the address type=20 > > and addresses objects? What is returned by the agent in=20 > this case on a=20 > > Get operation on these objects? > >=20 >=20 > Also made this clear. >=20 > > T8. The InetPort TC IMPORT-ed from RFC 4001 looks like a more=20 > > appropriate SYNTAX for the ipfixTransportSessionSourcePort and=20 > > ipfixTransportSessionDestinationPort objects > >=20 >=20 > You are right again. Fixed. >=20 > > T9. I cannot figure out what is the role of all the DEFVAL=20 > clauses in=20 > > this MIB module. All the MIB is read-only and there is no=20 > dynamic row=20 > > creation. Why are they needed? > >=20 >=20 > You are right again. Since we first discussed if the MIB=20 > should be writable or not this is a remainder of these times. >=20 > > T10. Many of the objects in the MIB modules - especially=20 > counters and=20 > > gauges - would benefit from defining UNITS clauses. In some places=20 > > they are mentioned in the DESCRIPTION clauses, but using explicit=20 > > UNITS clauses wherever possible is better. > >=20 >=20 > Added where I thought it is applicable. >=20 > > T11. Some object names in table do not respect the naming=20 > conventions=20 > > that recommends that table names and objects have an=20 > identical suffix=20 > > - ipfixObservationDomainId, ipfixObservationPointGroupReference, > > ipfixPhysicalEntity, ipfixPhysicalEntityDirection > >=20 >=20 > Fixed. >=20 > > T12. Some objects are completely missing REFERENCE clauses -=20 > > especially in the first tables o the MIB. Some other clauses could=20 > > benefit from more exact referencing, saying just [RFC5101] without=20 > > mentioning the exact section is not very useful. > >=20 >=20 > Added where applicable. Improved if possible. >=20 > > T13. Why is the range of ipfixTemplateDefinitionLength=20 > 1..2147483547)? > > According to RFC 5101, section 7, page 31 it looks like it should be > > (0..65535) > >=20 >=20 > Fixed. >=20 > > T14. Give http://www.iana.org/assignments/enterprise-numbers/ as=20 > > REFERENCE for ipfixTemplateDefinitionEnterprise > >=20 >=20 > Done. >=20 > > T15. Use hex notations for describing values in the=20 > DESCRIPTION clause=20 > > of ipfixTemplateDefintionFlags - the decimal values do not=20 > correspond=20 > > to the bits positions > >=20 >=20 > Done. >=20 > > T16. ipfixExportEntry leads to a warning in the smicng compilation > >=20 > > W: f(ipfix.mi2), (676,12) Row "ipfixExportEntry" does not have a=20 > > consistent indexing scheme - index items from current table=20 > must come=20 > > after index items from other tables > >=20 >=20 > Since I have only libsmi (which does not catch this) I did=20 > not realize it. > Fixed. >=20 > > T17. A couple of enumerated objects start to value 0 which is not=20 > > recommended unless special cases. Are there special cases here for=20 > > ipfixExportMemberType and ipfixPhysicalEntityDirection > >=20 >=20 > Well, those cases indicate an unknown value which I think is=20 > a special case and the same as in the TC InetAddressType. >=20 > > T18. Unsigned32 seems to be a better SYNTAX than Integer32 (see RFC > > 4181) for the following objects: ipfixMeteringProcessId,=20 > > ipfixObservationPointGroupReference, ipfixObservationPointIndex,=20 > > ipfixTransportSessionRate > >=20 >=20 > Changed all types to Unsigned32 where possible. >=20 > > T19. I cannot understand what useful information carries=20 > > ipfixmeteringProcessId - it is not an index and its value is=20 > > implementation dependent. >=20 > We wanted to give a kind of ID to make it possible to=20 > identify the process that creates the Flow Records. This may=20 > be a process id or something similar. Maybe we should specify=20 > it as process id. This needs further discussion. >=20 > >=20 > > T20. Does it make sense for the ipfixSelectorFunction to point to a=20 > > function that is not available? > >=20 >=20 > Basically it doesn't. But we wanted to have the possibility=20 > to have a list of Selector Functions that are basically=20 > available (and thus present in the MIB tree) but may be=20 > disabled somehow. >=20 > > T21. I assume that selection functions will be added in the=20 > future. If=20 > > I am wrong please delete all mention of extensibility and=20 > take out the=20 > > ipfixSelectorFunctions group. If I am right, I suggest to put=20 > > ipfixSelectorFunctions in a separate MIB module that will be IANA=20 > > maintained, so that new functions can be added in the=20 > future without=20 > > the need to revise the MIB module and the RFC. The separate=20 > MIB module=20 > > will become the initial version of the IANA maintained=20 > module, and new=20 > > selector functions will be added using for example Expert Review=20 > > policy. > >=20 > >=20 >=20 > I personally think this makes sense to put it in a separate=20 > MIB module which is maintained by IANA but this needs further=20 > discussion on the list which I will start soon. >=20 > > T22. it looks like Gauge32 would be a better SYNTAX for the=20 > following > > objects: ipfixTransportSessionRate, > > ipfixMeteringProcessCacheActiveFlows, ipfixMetering=20 > > ProcessCacheInactiveFlows > >=20 >=20 > Changed whereever applicable. >=20 > > T23. How is ipfixTransportSessionRate computed? Every=20 > second? Every T=20 > > seconds? T=3D? > >=20 >=20 > I fixed this to one second intervals. Benoit, Atsushi any objections?? >=20 > > T24. I am wondering whether more counters in this MIB=20 > module need to=20 > > be > > Counter64 rather than Counter32 - especially the bytes and packets=20 > > counters > >=20 >=20 > Made all Counters Counter64. >=20 > > T25. There is no definition of the discontinuity behavior=20 > of all the=20 > > counter objects or definition of discontinuity objects. > >=20 > > T26. It looks like Counter32 (or Counter64) with the appropriate=20 > > discontinuity objects are better SYNTAX for=20 > > ipfixSelectorStatsPacketsObserved and=20 > ipfixSelectorStatspacketsDropped. > >=20 >=20 > Added discontinuity objects and fixed the two issues above. >=20 > > T27. Some of the DESCRIPTION clauses of the OBJECT-GROUPs contain=20 > > statements about the mandatory or optional characteristics of the=20 > > objects. This is inappropriate, such statements must be made in=20 > > MODULE-COMPLIANCE definitions, not in OBJECT-GROUP. > >=20 >=20 > Fixed. >=20 > > T.28. Security Consideration sections - The description of the=20 > > vulnerability of objects in the tables should be more precise than=20 > > 'contains configuration data that might be sensitive'. > >=20 >=20 > Changed. >=20 > I also fixed the text issues below. Dan, please review=20 > version 06 if all your issues are fixed except those which I=20 > marked under discussion above. >=20 > Thanks, >=20 > Thomas >=20 > >=20 > > E1. Section 5.1 s/is defined in the MIB/is defined in the=20 > MIB module/ > >=20 > > E2. The language in the sub-section of section 5 may be=20 > polished - for=20 > > example in section 5.3 and 5.4 s/may want to export/is=20 > configured to=20 > > export/ > >=20 > > E3. Section 5.6 s/consists of a set of function/consists of=20 > a set of=20 > > functions/ > >=20 > > E4. Section 5.6 - 'the Metering Process table (ipfixMetering > > ProcessTable) is grouped by maintained by ...' - this=20 > phrase needs to=20 > > be fixed. > >=20 > > E5. Section 6.1 - s/they should also implement the ENTITY MIB/they=20 > > SHOULD also implement the ENTITY MIB/ > >=20 > > E6. Section 6.1 s/all entries in the Observation Point=20 > Table contain=20 > > an ipfixPhysicalEntity of zero(0)/all values of the=20 > > ipfixPhysicalEntity columns in the ipfixObservationPointTable are 0=20 > > and the values of the ipfixPhysicalEntityDirection columns=20 > are none(0). > >=20 > > E7. The DESCRIPTION clause and the name of the object=20 > > ipfixTransportSessionMode seem mis-leading. I think that=20 > this object=20 > > describes the device role in a session, not the mode of the=20 > session in=20 > > other words it's an attribute of the device that runs the agent and=20 > > not of the session. > >=20 > > E8. The DESCRIPTION clause of the ipfixTemplateAccessTime object is=20 > > confusing. The second and third paragraph seem to duplicate the=20 > > content of the first paragraph. The last phrase of the=20 > clause seems to=20 > > belong rather in the DESCRIPTION clause of the table than here. > >=20 > > E9. DESCRIPTION clause of ipfixObservationPointIndex - is this=20 > > 'management system' or rather 'management agent'? > >=20 > > E10. DESCRIPTION clause of ipfixPhysicalEntity s/the object=20 > contains=20 > > 0/the value of the object is 0/ > >=20 > > E11. What does 'a direction is not applicable' mean in the=20 > DESCRIPTION=20 > > clause of ipfixPhysicalEntityDirection? > >=20 > >=20 > > _______________________________________________ > > IPFIX mailing list > > IPFIX@ietf.org > > https://www.ietf.org/mailman/listinfo/ipfix >=20 From Quittek@nw.neclab.eu Thu Mar 19 18:11:33 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 2FFFB3A684E; Thu, 19 Mar 2009 18:11:33 -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 0PGKw6VD0KgE; Thu, 19 Mar 2009 18:11:31 -0700 (PDT) Received: from smtp0.neclab.eu (smtp0.neclab.eu [195.37.70.41]) by core3.amsl.com (Postfix) with ESMTP id B239D3A67F0; Thu, 19 Mar 2009 18:11:30 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp0.neclab.eu (Postfix) with ESMTP id 614F52C00035A; Fri, 20 Mar 2009 02:12:16 +0100 (CET) X-Virus-Scanned: Amavisd on Debian GNU/Linux (atlas2.office) Received: from smtp0.neclab.eu ([127.0.0.1]) by localhost (atlas2.office [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id X8mmkRDydJua; Fri, 20 Mar 2009 02:12:16 +0100 (CET) Received: from VENUS.office (mx2.office [192.168.24.15]) by smtp0.neclab.eu (Postfix) with ESMTP id 2CC8E2C0000EB; Fri, 20 Mar 2009 02:12:01 +0100 (CET) X-MimeOLE: Produced By Microsoft Exchange V6.5 Received: from 10.7.0.54 ([10.7.0.54]) by VENUS.office ([192.168.24.102]) with Microsoft Exchange Server HTTP-DAV ; Fri, 20 Mar 2009 01:12:01 +0000 MIME-Version: 1.0 Content-class: urn:content-classes:message Content-Type: multipart/signed; micalg=sha1; boundary="B_3320359927_499550"; protocol="application/pkcs7-signature" Date: Fri, 20 Mar 2009 02:12:06 +0100 Message-ID: In-Reply-To: X-MS-Has-Attach: yes X-MS-TNEF-Correlator: Thread-Topic: [IPFIX] AD review of draft-ietf-ipfix-mib-05.txt thread-index: AcmRHJmf24PVuTAzTrOZoe2H0CfpvQPihcJAAcqLQMAASgEtkA== From: "Juergen Quittek" To: "Dan Romascanu" , "Thomas Dietz" , "IETF IPFIX Working Group" Cc: "MIB Doctors \(E-mail\)" Subject: Re: [IPFIX] AD review of draft-ietf-ipfix-mib-05.txt X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Mar 2009 01:11:33 -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_3320359927_499550 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Dear Dan, I would support sending the document to IETF last call. The open issues are not critical for this review and we would speed up the process of completing this document. Thanks, Juergen On 18.03.09 14:57 "Dan Romascanu" wrote: > Thank you for addressing my comments. Most of the issues were > acknowledged and fixed accordingly. T19 and T21 still need discussion, > while T23 needs to be acknowledged by the other editors. > > My question to the WG chairs is whether we should send the document to > IETF Last Call, considering the open issues as Last Call issues, to be > answered and resolved together with other Last Call comments we receive. > > > Dan > > >> -----Original Message----- >> From: Thomas Dietz [mailto:Thomas.Dietz@nw.neclab.eu] >> Sent: Monday, March 09, 2009 1:26 PM >> To: Romascanu, Dan (Dan); IETF IPFIX Working Group >> Cc: MIB Doctors (E-mail) >> Subject: RE: [IPFIX] AD review of draft-ietf-ipfix-mib-05.txt >> >> Dear Dan, all, >> >> find my comments inline... >> >> -- >> Thomas Dietz E-mail: Thomas.Dietz@nw.neclab.eu >> NEC Europe Ltd. Phone: +49 6221 4342-128 >> NEC Laboratories Europe Fax: +49 6221 4342-155 >> Network Research Division >> Kurfuersten-Anlage 36 >> 69115 Heidelberg, Germany http://www.nw.neclab.eu >> >> NEC Europe Limited Registered in England 2832014 >> Registered Office: NEC House, 1 Victoria Road, London W3 6BL >> >>> -----Original Message----- >>> From: ipfix-bounces@ietf.org >> [mailto:ipfix-bounces@ietf.org] On Behalf >>> Of Romascanu, Dan (Dan) >>> Sent: Dienstag, 17. Februar 2009 17:27 >>> To: IETF IPFIX Working Group >>> Cc: MIB Doctors (E-mail) >>> Subject: [IPFIX] AD review of draft-ietf-ipfix-mib-05.txt >>> >>> Please find below the AD (and MIB doctor) review of >>> draft-ietf-ipfix-mib-05.txt. This I-D is not ready yet for >> IETF Last >>> Call. Please address the issues below and issue a new I-D. >>> >>> Part of the comments were contributed by Bert Wijnen. >>> >>> I have divided the comments into Technical and Editorial. >>> >>> Thanks and Regards, >>> >>> Dan >>> >>> >>> T1. INET-ADDRESS-MIB is IMPORT-ed from RFC 4001and not from RFC 3291 >> >> Fixed. >> >>> >>> T2. There is no real justification for defining a new TC for >>> IpfixFunctionAvailability. As per RFC 4181, use TruthValue instead. >>> >> >> You are right. Fixed. >> >>> T3. The top level structure of the MIB does not follow the >>> recommendation in Appendix D of RFC 4181 concerning the OID layout: >>> >>> xxxMIB >>> | >>> +-- xxxNotifications(0) >>> +-- xxxObjects(1) >>> +-- xxxConformance(2) >>> | >>> +-- xxxCompliances(1) >>> +-- xxxGroups(2) >>> >> >> Fixed as well. >> >>> T4. The object iffixTransportSessionProtocol uses only 3 out of the >>> 255 possible values in the range (6, 17, 132). A better >> SYNTAX would >>> be just INTEGER and then enumerate the three values in the >>> MODULE-COMPLIANCE clause. This would allow future changes by just >>> another MODULE-COMPLIANCE if there is a need to add a new >> protocol. If >>> you believe that another transport will be never added the >> appropriate >>> SYNTAX would be INTEGER (6|17|132). Also provide >>> >> http://www.iana.org/assignments/protocol-numbers/protocol-numbers.xhtm >>> l >>> as REFERENCE. >>> >> >> I have put that into the module compliance section. >> >>> T5. There is only one InetAddressType object for both source and >>> destination addresses. Does this mean that an IPFIX session is only >>> IPv4 >>> to IPv4 or IPv6 to IPv6? This is a question, I apologize if it is a >>> layman one. In any case, it would be good to write an >> explanation, as >>> users of the RFC 4001 addresses TCs are used to always >> encounter pairs >>> of type-address objects. >> >> Just a mistake by myself. I added a object for source and >> destination address. >> >> >>> >>> T6. Why are the address type and addresses objects only >> valid for UDP >>> and TCP, and not for SCTP? Are not STCP session also >> conducted between >>> IP hosts that can be described by IP addresses? >>> >> >> Because we use the SCTP Association Id defined in the SCTP >> MIB for that. >> Thus the SCTP MIB holds IPs and ports for the association Id. >> Clarified that in the description. >> >>> T7. What does 'this object is only valid' mean for the address type >>> and addresses objects? What is returned by the agent in >> this case on a >>> Get operation on these objects? >>> >> >> Also made this clear. >> >>> T8. The InetPort TC IMPORT-ed from RFC 4001 looks like a more >>> appropriate SYNTAX for the ipfixTransportSessionSourcePort and >>> ipfixTransportSessionDestinationPort objects >>> >> >> You are right again. Fixed. >> >>> T9. I cannot figure out what is the role of all the DEFVAL >> clauses in >>> this MIB module. All the MIB is read-only and there is no >> dynamic row >>> creation. Why are they needed? >>> >> >> You are right again. Since we first discussed if the MIB >> should be writable or not this is a remainder of these times. >> >>> T10. Many of the objects in the MIB modules - especially >> counters and >>> gauges - would benefit from defining UNITS clauses. In some places >>> they are mentioned in the DESCRIPTION clauses, but using explicit >>> UNITS clauses wherever possible is better. >>> >> >> Added where I thought it is applicable. >> >>> T11. Some object names in table do not respect the naming >> conventions >>> that recommends that table names and objects have an >> identical suffix >>> - ipfixObservationDomainId, ipfixObservationPointGroupReference, >>> ipfixPhysicalEntity, ipfixPhysicalEntityDirection >>> >> >> Fixed. >> >>> T12. Some objects are completely missing REFERENCE clauses - >>> especially in the first tables o the MIB. Some other clauses could >>> benefit from more exact referencing, saying just [RFC5101] without >>> mentioning the exact section is not very useful. >>> >> >> Added where applicable. Improved if possible. >> >>> T13. Why is the range of ipfixTemplateDefinitionLength >> 1..2147483547)? >>> According to RFC 5101, section 7, page 31 it looks like it should be >>> (0..65535) >>> >> >> Fixed. >> >>> T14. Give http://www.iana.org/assignments/enterprise-numbers/ as >>> REFERENCE for ipfixTemplateDefinitionEnterprise >>> >> >> Done. >> >>> T15. Use hex notations for describing values in the >> DESCRIPTION clause >>> of ipfixTemplateDefintionFlags - the decimal values do not >> correspond >>> to the bits positions >>> >> >> Done. >> >>> T16. ipfixExportEntry leads to a warning in the smicng compilation >>> >>> W: f(ipfix.mi2), (676,12) Row "ipfixExportEntry" does not have a >>> consistent indexing scheme - index items from current table >> must come >>> after index items from other tables >>> >> >> Since I have only libsmi (which does not catch this) I did >> not realize it. >> Fixed. >> >>> T17. A couple of enumerated objects start to value 0 which is not >>> recommended unless special cases. Are there special cases here for >>> ipfixExportMemberType and ipfixPhysicalEntityDirection >>> >> >> Well, those cases indicate an unknown value which I think is >> a special case and the same as in the TC InetAddressType. >> >>> T18. Unsigned32 seems to be a better SYNTAX than Integer32 (see RFC >>> 4181) for the following objects: ipfixMeteringProcessId, >>> ipfixObservationPointGroupReference, ipfixObservationPointIndex, >>> ipfixTransportSessionRate >>> >> >> Changed all types to Unsigned32 where possible. >> >>> T19. I cannot understand what useful information carries >>> ipfixmeteringProcessId - it is not an index and its value is >>> implementation dependent. >> >> We wanted to give a kind of ID to make it possible to >> identify the process that creates the Flow Records. This may >> be a process id or something similar. Maybe we should specify >> it as process id. This needs further discussion. >> >>> >>> T20. Does it make sense for the ipfixSelectorFunction to point to a >>> function that is not available? >>> >> >> Basically it doesn't. But we wanted to have the possibility >> to have a list of Selector Functions that are basically >> available (and thus present in the MIB tree) but may be >> disabled somehow. >> >>> T21. I assume that selection functions will be added in the >> future. If >>> I am wrong please delete all mention of extensibility and >> take out the >>> ipfixSelectorFunctions group. If I am right, I suggest to put >>> ipfixSelectorFunctions in a separate MIB module that will be IANA >>> maintained, so that new functions can be added in the >> future without >>> the need to revise the MIB module and the RFC. The separate >> MIB module >>> will become the initial version of the IANA maintained >> module, and new >>> selector functions will be added using for example Expert Review >>> policy. >>> >>> >> >> I personally think this makes sense to put it in a separate >> MIB module which is maintained by IANA but this needs further >> discussion on the list which I will start soon. >> >>> T22. it looks like Gauge32 would be a better SYNTAX for the >> following >>> objects: ipfixTransportSessionRate, >>> ipfixMeteringProcessCacheActiveFlows, ipfixMetering >>> ProcessCacheInactiveFlows >>> >> >> Changed whereever applicable. >> >>> T23. How is ipfixTransportSessionRate computed? Every >> second? Every T >>> seconds? T=? >>> >> >> I fixed this to one second intervals. Benoit, Atsushi any objections?? >> >>> T24. I am wondering whether more counters in this MIB >> module need to >>> be >>> Counter64 rather than Counter32 - especially the bytes and packets >>> counters >>> >> >> Made all Counters Counter64. >> >>> T25. There is no definition of the discontinuity behavior >> of all the >>> counter objects or definition of discontinuity objects. >>> >>> T26. It looks like Counter32 (or Counter64) with the appropriate >>> discontinuity objects are better SYNTAX for >>> ipfixSelectorStatsPacketsObserved and >> ipfixSelectorStatspacketsDropped. >>> >> >> Added discontinuity objects and fixed the two issues above. >> >>> T27. Some of the DESCRIPTION clauses of the OBJECT-GROUPs contain >>> statements about the mandatory or optional characteristics of the >>> objects. This is inappropriate, such statements must be made in >>> MODULE-COMPLIANCE definitions, not in OBJECT-GROUP. >>> >> >> Fixed. >> >>> T.28. Security Consideration sections - The description of the >>> vulnerability of objects in the tables should be more precise than >>> 'contains configuration data that might be sensitive'. >>> >> >> Changed. >> >> I also fixed the text issues below. Dan, please review >> version 06 if all your issues are fixed except those which I >> marked under discussion above. >> >> Thanks, >> >> Thomas >> >>> >>> E1. Section 5.1 s/is defined in the MIB/is defined in the >> MIB module/ >>> >>> E2. The language in the sub-section of section 5 may be >> polished - for >>> example in section 5.3 and 5.4 s/may want to export/is >> configured to >>> export/ >>> >>> E3. Section 5.6 s/consists of a set of function/consists of >> a set of >>> functions/ >>> >>> E4. Section 5.6 - 'the Metering Process table (ipfixMetering >>> ProcessTable) is grouped by maintained by ...' - this >> phrase needs to >>> be fixed. >>> >>> E5. Section 6.1 - s/they should also implement the ENTITY MIB/they >>> SHOULD also implement the ENTITY MIB/ >>> >>> E6. Section 6.1 s/all entries in the Observation Point >> Table contain >>> an ipfixPhysicalEntity of zero(0)/all values of the >>> ipfixPhysicalEntity columns in the ipfixObservationPointTable are 0 >>> and the values of the ipfixPhysicalEntityDirection columns >> are none(0). >>> >>> E7. The DESCRIPTION clause and the name of the object >>> ipfixTransportSessionMode seem mis-leading. I think that >> this object >>> describes the device role in a session, not the mode of the >> session in >>> other words it's an attribute of the device that runs the agent and >>> not of the session. >>> >>> E8. The DESCRIPTION clause of the ipfixTemplateAccessTime object is >>> confusing. The second and third paragraph seem to duplicate the >>> content of the first paragraph. The last phrase of the >> clause seems to >>> belong rather in the DESCRIPTION clause of the table than here. >>> >>> E9. DESCRIPTION clause of ipfixObservationPointIndex - is this >>> 'management system' or rather 'management agent'? >>> >>> E10. DESCRIPTION clause of ipfixPhysicalEntity s/the object >> contains >>> 0/the value of the object is 0/ >>> >>> E11. What does 'a direction is not applicable' mean in the >> DESCRIPTION >>> clause of ipfixPhysicalEntityDirection? >>> >>> >>> _______________________________________________ >>> 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 --B_3320359927_499550 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 YWIuZXUCBA0uKwcwCQYFKw4DAhoFAKBdMCMGCSqGSIb3DQEJBDEWBBRpmqyWY9ijsnqGTATJ v/O588zeBzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0wOTAz MjAwMTEyMDZaMA0GCSqGSIb3DQEBAQUABIIBAIuqwr8VQSxGHC5q0DhD6/Hi2raXxM7sAaG+ 7X2dfYf4xPNTIyAsDlZPVIy1KNuQ7t6sySzJhGxjctRM9o3Y5jbtkeP0LeRs3ibgfCu0b4f6 3oax6qFaMB8CUtZ7QIKDDJmqOLoMETzUSsQ61vawpmfZb4MU6Me6YKN9/14V9v/Qqsq6MJ1X HjCa1Xw0MWsI5H3fW23rhrOXdgZVq3AdEY8i3LQivvpXGjfYGt3l2g/lvJDIHfLjmGrNtjjN L86FV73A4rqato5tfVU8e1suDB/ivaADDPjqhfsvRTneaATs1uOs2QgEYnn269XSVybqCf4A HMNSnbIhGgU4mhzTdhk= --B_3320359927_499550-- From wwwrun@core3.amsl.com Fri Mar 20 09:42:45 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 4FF3E3A6903; Fri, 20 Mar 2009 09:42:44 -0700 (PDT) X-idtracker: yes To: IETF-Announce From: The IESG Message-Id: <20090320164245.4FF3E3A6903@core3.amsl.com> Date: Fri, 20 Mar 2009 09:42:45 -0700 (PDT) Cc: ipfix@ietf.org Subject: [IPFIX] Last Call: draft-ietf-ipfix-mib (Definitions of Managed Objects for IP Flow Information Export) to Proposed Standard X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: ietf@ietf.org List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Mar 2009 16:42:45 -0000 The IESG has received a request from the IP Flow Information Export WG (ipfix) to consider the following document: - 'Definitions of Managed Objects for IP Flow Information Export ' as a Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2009-04-03. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. The file can be obtained via http://www.ietf.org/internet-drafts/draft-ietf-ipfix-mib-06.txt IESG discussion can be tracked via https://datatracker.ietf.org/public/pidtracker.cgi?command=view_id&dTag=15723&rfc_flag=0 The following IPR Declarations may be related to this I-D: https://datatracker.ietf.org/ipr/308/ https://datatracker.ietf.org/ipr/419/ https://datatracker.ietf.org/ipr/418/ https://datatracker.ietf.org/ipr/432/ https://datatracker.ietf.org/ipr/431/ https://datatracker.ietf.org/ipr/599/ https://datatracker.ietf.org/ipr/782/ https://datatracker.ietf.org/ipr/783/ https://datatracker.ietf.org/ipr/784/ https://datatracker.ietf.org/ipr/785/ https://datatracker.ietf.org/ipr/1112/ From wwwrun@core3.amsl.com Fri Mar 20 09:43:34 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 605CB28C1BA; Fri, 20 Mar 2009 09:43:33 -0700 (PDT) X-idtracker: yes To: IETF-Announce From: The IESG Message-Id: <20090320164334.605CB28C1BA@core3.amsl.com> Date: Fri, 20 Mar 2009 09:43:34 -0700 (PDT) Cc: ipfix@ietf.org Subject: [IPFIX] Last Call: draft-ietf-ipfix-file (Specification of the IPFIX File Format) to Proposed Standard X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: ietf@ietf.org List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Mar 2009 16:43:34 -0000 The IESG has received a request from the IP Flow Information Export WG (ipfix) to consider the following document: - 'Specification of the IPFIX File Format ' as a Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2009-04-03. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. The file can be obtained via http://www.ietf.org/internet-drafts/draft-ietf-ipfix-file-03.txt IESG discussion can be tracked via https://datatracker.ietf.org/public/pidtracker.cgi?command=view_id&dTag=16834&rfc_flag=0 The following IPR Declarations may be related to this I-D: https://datatracker.ietf.org/ipr/308/ https://datatracker.ietf.org/ipr/419/ https://datatracker.ietf.org/ipr/418/ https://datatracker.ietf.org/ipr/432/ https://datatracker.ietf.org/ipr/431/ https://datatracker.ietf.org/ipr/599/ https://datatracker.ietf.org/ipr/782/ https://datatracker.ietf.org/ipr/783/ https://datatracker.ietf.org/ipr/784/ https://datatracker.ietf.org/ipr/785/ https://datatracker.ietf.org/ipr/1112/ From andy@netconfcentral.com Fri Mar 20 18:32:03 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 CB7283A6959 for ; Fri, 20 Mar 2009 18:32:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.968 X-Spam-Level: X-Spam-Status: No, score=-0.968 tagged_above=-999 required=5 tests=[AWL=-1.303, BAYES_50=0.001, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WWiw7HyfF7Pd for ; Fri, 20 Mar 2009 18:32:03 -0700 (PDT) Received: from smtp126.sbc.mail.sp1.yahoo.com (smtp126.sbc.mail.sp1.yahoo.com [69.147.65.185]) by core3.amsl.com (Postfix) with SMTP id 2A64D28C2A3 for ; Fri, 20 Mar 2009 18:32:03 -0700 (PDT) Received: (qmail 30299 invoked from network); 21 Mar 2009 01:32:50 -0000 Received: from unknown (HELO ?127.0.0.1?) (andy@67.127.165.174 with plain) by smtp126.sbc.mail.sp1.yahoo.com with SMTP; 21 Mar 2009 01:32:49 -0000 X-YMail-OSG: GuWx8VYVM1nBt1lxBHQik6AIc8J7yXC9OHVpBH4ormh8AOJ9u3gKFRPFQEqzhJW3kpORtLnBy0E.Imz29xkBJMNjWB1FgZ.Ax62zV8YGdIVcg3yV.I3UDpII5wWLtEewfdPRmxZsGKS_xaTgVwLk1iqenzq_MpJjaGueBxWkKgOKM4ePwVc8qZrtpGIHNz.rmzTMicSakZui0lw0QLLF5OFHwdKg9ORf3oDflT3_H7MD0K47V_cWEA0lEEcBbnY- X-Yahoo-Newman-Property: ymail-3 Message-ID: <49C443BE.8010103@netconfcentral.com> Date: Fri, 20 Mar 2009 18:32:46 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: "ipfix@ietf.org" Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [IPFIX] minor comments on ipfix-psamp.yang 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: Sat, 21 Mar 2009 01:32:03 -0000 Hi, These are just some bugfix comments for the ipfix-psamp YANG module. Half of them are due to recent changes in YANG syntax. - module name: should be changed from ipfix-psamp to ietf-ipfix-psamp - imports: s/yang-types/ietf-yang-types/ s/inet-types/ietf-inet-types/ - leaf startAS, leaf stopAS: s/autonomous-system-number/as-number/ - grouping transportSessionParameters; after description-stmt: extra tokens '";' - most must-stmts: need single quotes around string values OLD: must "../cacheType!=permanent"; NEW: must "../cacheType!='permanent'"; - should fill in many missing description statements before RFC publication FYI, an updated version can be found here: http://www.netconfcentral.com/src/ipfix-psamp.2009-03-02.yang Andy From muenz@net.in.tum.de Sat Mar 21 05:48:08 2009 Return-Path: X-Original-To: ipfix@core3.amsl.com Delivered-To: ipfix@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A456A3A6A74 for ; Sat, 21 Mar 2009 05:48:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.169 X-Spam-Level: X-Spam-Status: No, score=-2.169 tagged_above=-999 required=5 tests=[AWL=0.080, 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 rwuawfpHE4tG for ; Sat, 21 Mar 2009 05:48:07 -0700 (PDT) Received: from mail-out1.informatik.tu-muenchen.de (maildmz1.informatik.tu-muenchen.de [131.159.0.3]) by core3.amsl.com (Postfix) with ESMTP id ACC3F3A6A71 for ; Sat, 21 Mar 2009 05:48:06 -0700 (PDT) Received: from phoenix.net.informatik.tu-muenchen.de (phoenix.net.informatik.tu-muenchen.de [131.159.14.1]) by services.net.informatik.tu-muenchen.de (Postix Mailer @ mail) with ESMTP id E92FC483DE; Sat, 21 Mar 2009 13:48:40 +0100 (CET) Received: from [127.0.0.1] (ldap [131.159.14.1]) by phoenix.net.informatik.tu-muenchen.de (Postfix) with ESMTP id 937C6E7A; Sat, 21 Mar 2009 13:48:40 +0100 (CET) Message-ID: <49C4E22D.70408@net.in.tum.de> Date: Sat, 21 Mar 2009 13:48:45 +0100 From: Gerhard Muenz User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: Andy Bierman References: <49C443BE.8010103@netconfcentral.com> In-Reply-To: <49C443BE.8010103@netconfcentral.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV using ClamSMTP Cc: "ipfix@ietf.org" Subject: Re: [IPFIX] minor comments on ipfix-psamp.yang 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: Sat, 21 Mar 2009 12:48:08 -0000 Hi Andy, Thanks a lot for validating the module. Your improvements will be adopted in the next draft version. Regards, Gerhard Andy Bierman wrote: > Hi, > > These are just some bugfix comments for the ipfix-psamp YANG module. > Half of them are due to recent changes in YANG syntax. > > - module name: > should be changed from ipfix-psamp to ietf-ipfix-psamp > > - imports: > s/yang-types/ietf-yang-types/ > s/inet-types/ietf-inet-types/ > > - leaf startAS, leaf stopAS: > s/autonomous-system-number/as-number/ > > - grouping transportSessionParameters; > after description-stmt: extra tokens '";' > > - most must-stmts: > need single quotes around string values > OLD: > must "../cacheType!=permanent"; > NEW: > must "../cacheType!='permanent'"; > > - should fill in many missing description statements > before RFC publication > > FYI, an updated version can be found here: > > http://www.netconfcentral.com/src/ipfix-psamp.2009-03-02.yang > > > Andy > > > > _______________________________________________ > IPFIX mailing list > IPFIX@ietf.org > https://www.ietf.org/mailman/listinfo/ipfix From andy@netconfcentral.com Sat Mar 21 08:00:30 2009 Return-Path: X-Original-To: ipfix@core3.amsl.com Delivered-To: ipfix@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 367E23A6AF6 for ; Sat, 21 Mar 2009 08:00:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.43 X-Spam-Level: X-Spam-Status: No, score=-1.43 tagged_above=-999 required=5 tests=[AWL=-0.654, BAYES_05=-1.11, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id f7fCGSmH+7uV for ; Sat, 21 Mar 2009 08:00:29 -0700 (PDT) Received: from smtp124.sbc.mail.sp1.yahoo.com (smtp124.sbc.mail.sp1.yahoo.com [69.147.64.97]) by core3.amsl.com (Postfix) with SMTP id 8A5E83A6A0D for ; Sat, 21 Mar 2009 08:00:29 -0700 (PDT) Received: (qmail 22844 invoked from network); 21 Mar 2009 15:01:17 -0000 Received: from unknown (HELO ?127.0.0.1?) (andy@67.127.165.174 with plain) by smtp124.sbc.mail.sp1.yahoo.com with SMTP; 21 Mar 2009 15:01:16 -0000 X-YMail-OSG: 1tGCLq0VM1njvo3491tw4j8ymwoKfi7fFVa54k9gfCiP8tZK3LOTVQMVeIrLOTkvCrO97MoBZOqC8tyM5pTv9q1XG4Ts.dMT2mDl1bEPP.2ix15GJR0bwCWfGgR7lbilcCqGi8IXImHQ1uQxZ3JWLnhB X-Yahoo-Newman-Property: ymail-3 Message-ID: <49C5013B.6050805@netconfcentral.com> Date: Sat, 21 Mar 2009 08:01:15 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: Gerhard Muenz References: <49C443BE.8010103@netconfcentral.com> <49C4E22D.70408@net.in.tum.de> In-Reply-To: <49C4E22D.70408@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] minor comments on ipfix-psamp.yang 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: Sat, 21 Mar 2009 15:00:30 -0000 Gerhard Muenz wrote: > Hi Andy, > > Thanks a lot for validating the module. Your improvements will be > adopted in the next draft version. > no problem. thanks for providing a 'real' data model to test with. forgot 1 more: s/keyref/leafref/ > Regards, > Gerhard Andy From bclaise@cisco.com Sat Mar 21 16:23:50 2009 Return-Path: X-Original-To: ipfix@core3.amsl.com Delivered-To: ipfix@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2E8183A69C0 for ; Sat, 21 Mar 2009 16:23:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[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 5MLAHyGThFox for ; Sat, 21 Mar 2009 16:23:49 -0700 (PDT) Received: from av-tac-bru.cisco.com (odd-brew.cisco.com [144.254.15.119]) by core3.amsl.com (Postfix) with ESMTP id DAE063A68A4 for ; Sat, 21 Mar 2009 16:23:48 -0700 (PDT) X-TACSUNS: Virus Scanned Received: from strange-brew.cisco.com (localhost [127.0.0.1]) by av-tac-bru.cisco.com (8.11.7p3+Sun/8.11.7) with ESMTP id n2LNOZs26593; Sun, 22 Mar 2009 00:24:35 +0100 (CET) Received: from [128.107.115.186] ([128.107.115.186]) by strange-brew.cisco.com (8.11.7p3+Sun/8.11.7) with ESMTP id n2LNOXt13056; Sun, 22 Mar 2009 00:24:33 +0100 (CET) Message-ID: <49C57730.9010303@cisco.com> Date: Sat, 21 Mar 2009 16:24:32 -0700 From: Benoit Claise User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: Thomas Dietz References: <547F018265F92642B577B986577D671C7009D8@VENUS.office> In-Reply-To: <547F018265F92642B577B986577D671C7009D8@VENUS.office> Content-Type: multipart/alternative; boundary="------------030103000301030103050404" Cc: ipfix@ietf.org Subject: Re: [IPFIX] IPFIX-MIB: Separation of MIB modules (was: T21 from AD review) 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: Sat, 21 Mar 2009 23:23:50 -0000 This is a multi-part message in MIME format. --------------030103000301030103050404 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Thomas, This makes a lot of sense to me. Regards, Benoit. > Dear all, > > Dan raised the following issue in the AD review: > > >> T21. I assume that selection functions will be added in the future. If I >> am wrong please delete all mention of extensibility and take out the >> ipfixSelectorFunctions group. If I am right, I suggest to put >> ipfixSelectorFunctions in a separate MIB module that will be IANA >> maintained, so that new functions can be added in the future without the >> need to revise the MIB module and the RFC. The separate MIB module will >> become the initial version of the IANA maintained module, and new >> selector functions will be added using for example Expert Review policy. >> > > I personally think it is a good idea to put the selector functions in a > separate MIB module (still defined in the same draft) and put that module > under control of IANA. I would propose further to make additions subject to > Expert Review policy. > > If you agree with this procedure I would make those changes for the upcoming > version 07. If you think different please speak up. > > Best Regards, > > Thomas > > > ------------------------------------------------------------------------ > > _______________________________________________ > IPFIX mailing list > IPFIX@ietf.org > https://www.ietf.org/mailman/listinfo/ipfix > --------------030103000301030103050404 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Thomas,

This makes a lot of sense to me.

Regards, Benoit.
Dear all,

Dan raised the following issue in the AD review:

  
T21. I assume that selection functions will be added in the future. If I
am wrong please delete all mention of extensibility and take out the
ipfixSelectorFunctions group. If I am right, I suggest to put
ipfixSelectorFunctions in a separate MIB module that will be IANA
maintained, so that new functions can be added in the future without the
need to revise the MIB module and the RFC. The separate MIB module will
become the initial version of the IANA maintained module, and new
selector functions will be added using for example Expert Review policy.
    

I personally think it is a good idea to put the selector functions in a
separate MIB module (still defined in the same draft) and put that module
under control of IANA. I would propose further to make additions subject to
Expert Review policy.

If you agree with this procedure I would make those changes for the upcoming
version 07. If you think different please speak up.

Best Regards,

Thomas

  

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

--------------030103000301030103050404-- From bclaise@cisco.com Sat Mar 21 16:27:22 2009 Return-Path: X-Original-To: ipfix@core3.amsl.com Delivered-To: ipfix@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2474E3A6A7D; Sat, 21 Mar 2009 16:27:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[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 UcCXi-8WoH20; Sat, 21 Mar 2009 16:27:21 -0700 (PDT) Received: from av-tac-bru.cisco.com (odd-brew.cisco.com [144.254.15.119]) by core3.amsl.com (Postfix) with ESMTP id C27963A6AFF; Sat, 21 Mar 2009 16:27:20 -0700 (PDT) X-TACSUNS: Virus Scanned Received: from strange-brew.cisco.com (localhost [127.0.0.1]) by av-tac-bru.cisco.com (8.11.7p3+Sun/8.11.7) with ESMTP id n2LNS8r26865; Sun, 22 Mar 2009 00:28:08 +0100 (CET) Received: from [128.107.115.186] ([128.107.115.186]) by strange-brew.cisco.com (8.11.7p3+Sun/8.11.7) with ESMTP id n2LNS5t14925; Sun, 22 Mar 2009 00:28:07 +0100 (CET) Message-ID: <49C57804.7030500@cisco.com> Date: Sat, 21 Mar 2009 16:28:04 -0700 From: Benoit Claise User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: Atsushi Kobayashi References: <547F018265F92642B577B986577D671C7009CF@VENUS.office> <20090309212840.93C9.17391CF2@nttv6.net> In-Reply-To: <20090309212840.93C9.17391CF2@nttv6.net> Content-Type: multipart/alternative; boundary="------------070509080301030703000103" Cc: IETF IPFIX Working Group , "MIB Doctors \(E-mail\)" Subject: Re: [IPFIX] AD review of draft-ietf-ipfix-mib-05.txt X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 21 Mar 2009 23:27:22 -0000 This is a multi-part message in MIME format. --------------070509080301030703000103 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Thomas, > >>> T23. How is ipfixTransportSessionRate computed? Every second? Every T >>> seconds? T=? >>> >>> >> I fixed this to one second intervals. Benoit, Atsushi any objections?? >> >> > > No. I don't have strong opinion. > Every second is fine with me. Regards, Benoit. > _______________________________________________ > IPFIX mailing list > IPFIX@ietf.org > https://www.ietf.org/mailman/listinfo/ipfix > --------------070509080301030703000103 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Thomas, 
  
T23. How is ipfixTransportSessionRate computed? Every second? Every T
seconds? T=?

      
I fixed this to one second intervals. Benoit, Atsushi any objections??

    

No. I don't have strong opinion.
Every second is fine with me.

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

--------------070509080301030703000103-- From bclaise@cisco.com Sat Mar 21 16:35: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 7ACED3A6B47 for ; Sat, 21 Mar 2009 16:35:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[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 NdCasddnEfdV for ; Sat, 21 Mar 2009 16:35:55 -0700 (PDT) Received: from av-tac-bru.cisco.com (odd-brew.cisco.com [144.254.15.119]) by core3.amsl.com (Postfix) with ESMTP id 4A5D33A6B0F for ; Sat, 21 Mar 2009 16:35:55 -0700 (PDT) X-TACSUNS: Virus Scanned Received: from strange-brew.cisco.com (localhost [127.0.0.1]) by av-tac-bru.cisco.com (8.11.7p3+Sun/8.11.7) with ESMTP id n2LNagW27518; Sun, 22 Mar 2009 00:36:42 +0100 (CET) Received: from [128.107.115.186] ([128.107.115.186]) by strange-brew.cisco.com (8.11.7p3+Sun/8.11.7) with ESMTP id n2LNact19891; Sun, 22 Mar 2009 00:36:38 +0100 (CET) Message-ID: <49C57A05.1070208@cisco.com> Date: Sat, 21 Mar 2009 16:36:37 -0700 From: Benoit Claise User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: Thomas Dietz References: <49A55194.1090609@net.in.tum.de> <547F018265F92642B577B986577D671C7009D3@VENUS.office> In-Reply-To: <547F018265F92642B577B986577D671C7009D3@VENUS.office> Content-Type: multipart/alternative; boundary="------------020003060000090403020308" Cc: ipfix@ietf.org Subject: Re: [IPFIX] IPFIX-MIB: ipfixMeteringProcessMessages, ipfixMeteringProcessErrors, ipfixMeteringProcessDataRecords 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: Sat, 21 Mar 2009 23:35:56 -0000 This is a multi-part message in MIME format. --------------020003060000090403020308 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Dear all, Gerhard is right. First of all, the Metering Process doesn't "transmit" or "sent". Secondly, we have the ipfixTransportSessionMessages and ipfixTransportSessionDiscardedMessages counters, which do the job So I'm in favor of removing ipfixMeteringProcessMessages and ipfixMeteringProcessErrors Regards, Benoit. > Dear Benoit, Atsushi, all, > > I think Gerhard is right. If nobody objects I will remove those objects in > the upcoming version 07. > > Best Regards, > > Thomas > > > ------------------------------------------------------------------------ > > _______________________________________________ > IPFIX mailing list > IPFIX@ietf.org > https://www.ietf.org/mailman/listinfo/ipfix > --------------020003060000090403020308 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Dear all,

Gerhard is right.
First of all, the Metering Process doesn't "transmit" or "sent".
Secondly, we have the ipfixTransportSessionMessages and ipfixTransportSessionDiscardedMessages counters, which do the job
So I'm in favor of removing ipfixMeteringProcessMessages and ipfixMeteringProcessErrors

Regards, Benoit.
Dear Benoit, Atsushi, all,

I think Gerhard is right. If nobody objects I will remove those objects in
the upcoming version 07.

Best Regards,

Thomas

  

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

--------------020003060000090403020308-- From bclaise@cisco.com Sat Mar 21 16:48:28 2009 Return-Path: X-Original-To: ipfix@core3.amsl.com Delivered-To: ipfix@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CF19B3A6B46 for ; Sat, 21 Mar 2009 16:48:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[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 kO-uynm6O7nF for ; Sat, 21 Mar 2009 16:48:27 -0700 (PDT) Received: from av-tac-bru.cisco.com (odd-brew.cisco.com [144.254.15.119]) by core3.amsl.com (Postfix) with ESMTP id 66ED83A6858 for ; Sat, 21 Mar 2009 16:48:27 -0700 (PDT) X-TACSUNS: Virus Scanned Received: from strange-brew.cisco.com (localhost [127.0.0.1]) by av-tac-bru.cisco.com (8.11.7p3+Sun/8.11.7) with ESMTP id n2LNdox27659; Sun, 22 Mar 2009 00:39:50 +0100 (CET) Received: from [128.107.115.186] ([128.107.115.186]) by strange-brew.cisco.com (8.11.7p3+Sun/8.11.7) with ESMTP id n2LNdnt22557; Sun, 22 Mar 2009 00:39:49 +0100 (CET) Message-ID: <49C57AC4.9030606@cisco.com> Date: Sat, 21 Mar 2009 16:39:48 -0700 From: Benoit Claise User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: Gerhard Muenz References: <49A6632A.2040201@net.in.tum.de> <49A6D65A.8000008@net.in.tum.de> In-Reply-To: <49A6D65A.8000008@net.in.tum.de> Content-Type: multipart/alternative; boundary="------------050507070200090109070405" Cc: "ipfix@ietf.org" Subject: Re: [IPFIX] IPFIX-MIB: comments to AD review 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: Sat, 21 Mar 2009 23:48:28 -0000 This is a multi-part message in MIME format. --------------050507070200090109070405 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Gerhard, Personally, I have a small preference for "parallel" Regards, Benoit. > One more: > > ipfixExportMemberType OBJECT-TYPE > SYNTAX INTEGER { > unknown(0), > primary(1), > secondary(2), > parallel(3), > loadBalancing(4) > } > MAX-ACCESS read-only > STATUS current > DESCRIPTION > "The type of a member Transport Session in a Transport > Session group (identified by the value of ipfixExportIndex, > ipfixObservationDomainId and ipfixMeteringProcessCacheId). > The following values are valid: > > unknown(0) > This value MUST be used if the status of the group > membership cannot be detected by the equipment. This > value should be avoided as far as possible. > > > > primary(1) > This value is used for a group member that is used as > the primary target of an Exporter. Other group members > (with the same ipfixExportIndex and > ipfixMeteringProcessCacheId) MUST NOT have the value > primary(1) but MUST have the value secondary(2). > This value MUST also be specified if the Exporter does > not support Transport Session grouping.In this case the > group contains only one Transport Session. > > secondary(2) > This value is used for a group member that is used as a > secondary target of an Exporter. The Exporter will use > one of the targets specified as secondary(2) within the > same Transport Session group when the primary target is > not reachable. > > duplicate(3) > This value is used for a group member that is used for > duplicate exporting i.e., all group members identified > by the ipfixExportIndex are exporting the same Records > in parallel. This implies that all group members MUST > have the the same membertype duplicate(3). > > loadBalancing(4) > This value is used for a group member that is used as > as one target for load-balancing. This means that a > Record is sent to one of the group members in this > group identified by ipfixExportIndex. > This implies that all group members MUST have the same > membertype load-balancing(4)." > ::= { ipfixExportEntry 2 } > > > Do you prefer duplicate or parallel for value 3? > > > ------------------------------------------------------------------------ > > _______________________________________________ > IPFIX mailing list > IPFIX@ietf.org > https://www.ietf.org/mailman/listinfo/ipfix > --------------050507070200090109070405 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Gerhard,

Personally, I have a small preference for "parallel"

Regards, Benoit.
One more:

ipfixExportMemberType OBJECT-TYPE
    SYNTAX      INTEGER {
                    unknown(0),
                    primary(1),
                    secondary(2),
                    parallel(3),
                    loadBalancing(4)
                }
    MAX-ACCESS  read-only
    STATUS      current
    DESCRIPTION
        "The type of a member Transport Session in a Transport
        Session group (identified by the value of ipfixExportIndex,
        ipfixObservationDomainId and ipfixMeteringProcessCacheId).
        The following values are valid:

        unknown(0)
            This value MUST be used if the status of the group
            membership cannot be detected by the equipment. This
            value should be avoided as far as possible.



        primary(1)
            This value is used for a group member that is used as
            the primary target of an Exporter. Other group members
            (with the same ipfixExportIndex and
            ipfixMeteringProcessCacheId) MUST NOT have the value
            primary(1) but MUST have the value secondary(2).
            This value MUST also be specified if the Exporter does
            not support Transport Session grouping.In this case the
            group contains only one Transport Session.

        secondary(2)
            This value is used for a group member that is used as a
            secondary target of an Exporter. The Exporter will use
            one of the targets specified as secondary(2) within the
            same Transport Session group when the primary target is
            not reachable.

        duplicate(3)
            This value is used for a group member that is used for
            duplicate exporting i.e., all group members identified
            by the ipfixExportIndex are exporting the same Records
            in parallel. This implies that all group members MUST
            have the the same membertype duplicate(3).

        loadBalancing(4)
            This value is used for a group member that is used as
            as one target for load-balancing. This means that a
            Record is sent to one of the group members in this
            group identified by ipfixExportIndex.
            This implies that all group members MUST have the same
            membertype load-balancing(4)."
    ::= { ipfixExportEntry 2 }


Do you prefer duplicate or parallel for value 3?

  

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

--------------050507070200090109070405-- From muenz@net.in.tum.de Sun Mar 22 04:28:58 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 A0D6F3A6AF8 for ; Sun, 22 Mar 2009 04:28:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.174 X-Spam-Level: X-Spam-Status: No, score=-2.174 tagged_above=-999 required=5 tests=[AWL=0.075, 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 It4G2H15LibG for ; Sun, 22 Mar 2009 04:28:57 -0700 (PDT) Received: from mail-out1.informatik.tu-muenchen.de (maildmz1.informatik.tu-muenchen.de [131.159.0.3]) by core3.amsl.com (Postfix) with ESMTP id 9DC733A67EF for ; Sun, 22 Mar 2009 04:28:56 -0700 (PDT) Received: from phoenix.net.informatik.tu-muenchen.de (phoenix.net.informatik.tu-muenchen.de [131.159.14.1]) by services.net.informatik.tu-muenchen.de (Postix Mailer @ mail) with ESMTP id AFE4547C81; Sun, 22 Mar 2009 12:29:43 +0100 (CET) Received: from [127.0.0.1] (ldap [131.159.14.1]) by phoenix.net.informatik.tu-muenchen.de (Postfix) with ESMTP id 4F94E998; Sun, 22 Mar 2009 12:29:43 +0100 (CET) Message-ID: <49C62127.5030305@net.in.tum.de> Date: Sun, 22 Mar 2009 12:29:43 +0100 From: Gerhard Muenz User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: Benoit Claise References: <49A6632A.2040201@net.in.tum.de> <49A6D65A.8000008@net.in.tum.de> <49C57AC4.9030606@cisco.com> In-Reply-To: <49C57AC4.9030606@cisco.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV using ClamSMTP Cc: "ipfix@ietf.org" Subject: Re: [IPFIX] IPFIX-MIB: comments to AD review 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: Sun, 22 Mar 2009 11:28:58 -0000 Benoit, > Personally, I have a small preference for "parallel" Yes, "parallel" is better because "duplicate" suggests that there are two collectors (although there might be several ones). My main point was that it is currently not consistent in SYNTAX and DESCRIPTION. Cheers, Gerhard > > Regards, Benoit. >> One more: >> >> ipfixExportMemberType OBJECT-TYPE >> SYNTAX INTEGER { >> unknown(0), >> primary(1), >> secondary(2), >> parallel(3), >> loadBalancing(4) >> } >> MAX-ACCESS read-only >> STATUS current >> DESCRIPTION >> "The type of a member Transport Session in a Transport >> Session group (identified by the value of ipfixExportIndex, >> ipfixObservationDomainId and ipfixMeteringProcessCacheId). >> The following values are valid: >> >> unknown(0) >> This value MUST be used if the status of the group >> membership cannot be detected by the equipment. This >> value should be avoided as far as possible. >> >> >> >> primary(1) >> This value is used for a group member that is used as >> the primary target of an Exporter. Other group members >> (with the same ipfixExportIndex and >> ipfixMeteringProcessCacheId) MUST NOT have the value >> primary(1) but MUST have the value secondary(2). >> This value MUST also be specified if the Exporter does >> not support Transport Session grouping.In this case the >> group contains only one Transport Session. >> >> secondary(2) >> This value is used for a group member that is used as a >> secondary target of an Exporter. The Exporter will use >> one of the targets specified as secondary(2) within the >> same Transport Session group when the primary target is >> not reachable. >> >> duplicate(3) >> This value is used for a group member that is used for >> duplicate exporting i.e., all group members identified >> by the ipfixExportIndex are exporting the same Records >> in parallel. This implies that all group members MUST >> have the the same membertype duplicate(3). >> >> loadBalancing(4) >> This value is used for a group member that is used as >> as one target for load-balancing. This means that a >> Record is sent to one of the group members in this >> group identified by ipfixExportIndex. >> This implies that all group members MUST have the same >> membertype load-balancing(4)." >> ::= { ipfixExportEntry 2 } >> >> >> Do you prefer duplicate or parallel for value 3? >> >> >> ------------------------------------------------------------------------ >> >> _______________________________________________ >> IPFIX mailing list >> IPFIX@ietf.org >> https://www.ietf.org/mailman/listinfo/ipfix >> > From bclaise@cisco.com Sun Mar 22 08:45:32 2009 Return-Path: X-Original-To: ipfix@core3.amsl.com Delivered-To: ipfix@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3F49D28C24B for ; Sun, 22 Mar 2009 08:45:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.494 X-Spam-Level: X-Spam-Status: No, score=-2.494 tagged_above=-999 required=5 tests=[AWL=0.105, 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 HnC2Wcc2vGpd for ; Sun, 22 Mar 2009 08:45:31 -0700 (PDT) Received: from av-tac-bru.cisco.com (odd-brew.cisco.com [144.254.15.119]) by core3.amsl.com (Postfix) with ESMTP id 29BCE28C243 for ; Sun, 22 Mar 2009 08:45:31 -0700 (PDT) X-TACSUNS: Virus Scanned Received: from strange-brew.cisco.com (localhost [127.0.0.1]) by av-tac-bru.cisco.com (8.11.7p3+Sun/8.11.7) with ESMTP id n2MFkJd06530 for ; Sun, 22 Mar 2009 16:46:19 +0100 (CET) Received: from [10.21.77.54] ([10.21.77.54]) by strange-brew.cisco.com (8.11.7p3+Sun/8.11.7) with ESMTP id n2MFkFt11023 for ; Sun, 22 Mar 2009 16:46:15 +0100 (CET) Message-ID: <49C65D46.5070906@cisco.com> Date: Sun, 22 Mar 2009 08:46:14 -0700 From: Benoit Claise User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: "ipfix@ietf.org" Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [IPFIX] RFC 5101 errata: Option Template -> Options Template 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: Sun, 22 Mar 2009 15:45:32 -0000 Dear all, While the definition says "Options Template", there are still some instances of "Option Template". Drafts such [IPFIX-MIB], [IPFIX-CONF], [IPFIX-MD], etc. should use "Options ..." Regards, Benoit. From bclaise@cisco.com Sun Mar 22 08:50:18 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 514D328C11F for ; Sun, 22 Mar 2009 08:50:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.503 X-Spam-Level: X-Spam-Status: No, score=-2.503 tagged_above=-999 required=5 tests=[AWL=0.095, 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 MSfBS+ipGAJY for ; Sun, 22 Mar 2009 08:50:17 -0700 (PDT) Received: from av-tac-bru.cisco.com (odd-brew.cisco.com [144.254.15.119]) by core3.amsl.com (Postfix) with ESMTP id 18B7028C0F4 for ; Sun, 22 Mar 2009 08:50:16 -0700 (PDT) X-TACSUNS: Virus Scanned Received: from strange-brew.cisco.com (localhost [127.0.0.1]) by av-tac-bru.cisco.com (8.11.7p3+Sun/8.11.7) with ESMTP id n2MFp5r06856; Sun, 22 Mar 2009 16:51:05 +0100 (CET) Received: from [10.21.77.54] ([10.21.77.54]) by strange-brew.cisco.com (8.11.7p3+Sun/8.11.7) with ESMTP id n2MFp2t14352; Sun, 22 Mar 2009 16:51:02 +0100 (CET) Message-ID: <49C65E65.6050402@cisco.com> Date: Sun, 22 Mar 2009 08:51:01 -0700 From: Benoit Claise User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: Thomas Dietz Content-Type: multipart/alternative; boundary="------------090603030305070902030601" Cc: "ipfix@ietf.org" Subject: [IPFIX] [Fwd: RFC 5101 errata: Option Template -> Options Template] -> IPFIX MIB 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: Sun, 22 Mar 2009 15:50:18 -0000 This is a multi-part message in MIME format. --------------090603030305070902030601 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Thomas, Specifically on the MIB, there are some instances of "Option Template" Also, ipfixTransportSessionOptionTemplates, ipfixTransportSessionOptionTemplateRefreshTimeout, ipfixTransportSessionOptionTemplateRefreshPacket, ipfixTransportSessionOptionTemplates should be changed. This would then be in line with [IFPIX-CONF] Regards, Benoit. -------- Original Message -------- Subject: [IPFIX] RFC 5101 errata: Option Template -> Options Template Date: Sun, 22 Mar 2009 08:46:14 -0700 From: Benoit Claise To: ipfix@ietf.org Dear all, While the definition says "Options Template", there are still some instances of "Option Template". Drafts such [IPFIX-MIB], [IPFIX-CONF], [IPFIX-MD], etc. should use "Options ..." Regards, Benoit. _______________________________________________ IPFIX mailing list IPFIX@ietf.org https://www.ietf.org/mailman/listinfo/ipfix --------------090603030305070902030601 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Thomas,

Specifically on the MIB, there are some instances of "Option Template"
Also,  ipfixTransportSessionOptionTemplates, ipfixTransportSessionOptionTemplateRefreshTimeout, ipfixTransportSessionOptionTemplateRefreshPacket, ipfixTransportSessionOptionTemplates should be changed.
This would then be in line with [IFPIX-CONF]

Regards, Benoit.


-------- Original Message --------
Subject: [IPFIX] RFC 5101 errata: Option Template -> Options Template
Date: Sun, 22 Mar 2009 08:46:14 -0700
From: Benoit Claise <bclaise@cisco.com>
To: ipfix@ietf.org <ipfix@ietf.org> 


Dear all,

While the definition says "Options Template", there are still some 
instances of "Option Template".
Drafts such [IPFIX-MIB], [IPFIX-CONF], [IPFIX-MD], etc. should use 
"Options ..."

Regards, Benoit.
_______________________________________________
IPFIX mailing list
IPFIX@ietf.org
https://www.ietf.org/mailman/listinfo/ipfix
--------------090603030305070902030601-- From bclaise@cisco.com Sun Mar 22 17:03:43 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 4B3C63A680F for ; Sun, 22 Mar 2009 17:03:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.511 X-Spam-Level: X-Spam-Status: No, score=-2.511 tagged_above=-999 required=5 tests=[AWL=0.087, 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 hvAtESV5tk-Z for ; Sun, 22 Mar 2009 17:03:40 -0700 (PDT) Received: from av-tac-bru.cisco.com (odd-brew.cisco.com [144.254.15.119]) by core3.amsl.com (Postfix) with ESMTP id E21F73A659B for ; Sun, 22 Mar 2009 17:03:39 -0700 (PDT) X-TACSUNS: Virus Scanned Received: from strange-brew.cisco.com (localhost [127.0.0.1]) by av-tac-bru.cisco.com (8.11.7p3+Sun/8.11.7) with ESMTP id n2N04Se11476 for ; Mon, 23 Mar 2009 01:04:28 +0100 (CET) Received: from [10.21.81.73] (sjc-vpn4-329.cisco.com [10.21.81.73]) by strange-brew.cisco.com (8.11.7p3+Sun/8.11.7) with ESMTP id n2N04Nt22220 for ; Mon, 23 Mar 2009 01:04:25 +0100 (CET) Message-ID: <49C6D207.2050107@cisco.com> Date: Sun, 22 Mar 2009 17:04:23 -0700 From: Benoit Claise User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: "ipfix@ietf.org" Content-Type: multipart/alternative; boundary="------------030406040505090304090508" Subject: [IPFIX] IPFIX-MIB: ipfixMeteringProcessId (was T19 from AD review) 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, 23 Mar 2009 00:03:43 -0000 This is a multi-part message in MIME format. --------------030406040505090304090508 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Dear all, From AD review: T19. I cannot understand what useful information carries > > ipfixmeteringProcessId - it is not an index and its value is > > implementation dependent. > > We wanted to give a kind of ID to make it possible to > identify the process that creates the Flow Records. This may > be a process id or something similar. Maybe we should specify > it as process id. This needs further discussion. Discussing some more with Gerhard (as the consistency between the IPFIX MIB and IPFIX Configuration Model is key), we came to the following observations and conclusions. he following IDs have a meaning for the IPFIX Protocol: Selector ID, Selection Sequence ID, Observation Point ID, Observation Domain ID. These IDs don't: Exporting Process ID, Collecting Process ID, Metering Process ID. It is weird that we have: - MPID in the MIB, but not EPID and CPID - EPID and CPID in IPFIX-CONF, but not in the MPID. Regarding the MIB, I think that it makes sense to remove MPID unless we also add EPID and CPID. Regarding IPFIX-CONF, we have problems to add MPID because the boundaries of a single MPID are not defined. I've mentioned this problem in previous mails. So, either we live with only EPID and CPID in IPFIX-CONF or we remove these two as well. Actually, we do not see a good reason for configuring these IDs anyway! The logical conclusion seems to be: no MPID, EPID, CPID in [IPFIX-MIB] and [IPFIX-CONF] Regards, Gerhard & Benoit. -------- Original Message -------- Subject: Re: [IPFIX] AD review of draft-ietf-ipfix-mib-05.txt Date: Wed, 18 Mar 2009 14:57:16 +0100 From: Romascanu, Dan (Dan) To: Thomas Dietz , IETF IPFIX Working Group CC: MIB Doctors (E-mail) References: <547F018265F92642B577B986577D671C7009CF@VENUS.office> Thank you for addressing my comments. Most of the issues were acknowledged and fixed accordingly. T19 and T21 still need discussion, while T23 needs to be acknowledged by the other editors. My question to the WG chairs is whether we should send the document to IETF Last Call, considering the open issues as Last Call issues, to be answered and resolved together with other Last Call comments we receive. Dan > -----Original Message----- > From: Thomas Dietz [mailto:Thomas.Dietz@nw.neclab.eu] > Sent: Monday, March 09, 2009 1:26 PM > To: Romascanu, Dan (Dan); IETF IPFIX Working Group > Cc: MIB Doctors (E-mail) > Subject: RE: [IPFIX] AD review of draft-ietf-ipfix-mib-05.txt > > Dear Dan, all, > > find my comments inline... > > -- > Thomas Dietz E-mail: Thomas.Dietz@nw.neclab.eu > NEC Europe Ltd. Phone: +49 6221 4342-128 > NEC Laboratories Europe Fax: +49 6221 4342-155 > Network Research Division > Kurfuersten-Anlage 36 > 69115 Heidelberg, Germany http://www.nw.neclab.eu > > NEC Europe Limited Registered in England 2832014 > Registered Office: NEC House, 1 Victoria Road, London W3 6BL > > > -----Original Message----- > > From: ipfix-bounces@ietf.org > [mailto:ipfix-bounces@ietf.org] On Behalf > > Of Romascanu, Dan (Dan) > > Sent: Dienstag, 17. Februar 2009 17:27 > > To: IETF IPFIX Working Group > > Cc: MIB Doctors (E-mail) > > Subject: [IPFIX] AD review of draft-ietf-ipfix-mib-05.txt > > > > Please find below the AD (and MIB doctor) review of > > draft-ietf-ipfix-mib-05.txt. This I-D is not ready yet for > IETF Last > > Call. Please address the issues below and issue a new I-D. > > > > Part of the comments were contributed by Bert Wijnen. > > > > I have divided the comments into Technical and Editorial. > > > > Thanks and Regards, > > > > Dan > > > > > > T1. INET-ADDRESS-MIB is IMPORT-ed from RFC 4001and not from RFC 3291 > > Fixed. > > > > > T2. There is no real justification for defining a new TC for > > IpfixFunctionAvailability. As per RFC 4181, use TruthValue instead. > > > > You are right. Fixed. > > > T3. The top level structure of the MIB does not follow the > > recommendation in Appendix D of RFC 4181 concerning the OID layout: > > > > xxxMIB > > | > > +-- xxxNotifications(0) > > +-- xxxObjects(1) > > +-- xxxConformance(2) > > | > > +-- xxxCompliances(1) > > +-- xxxGroups(2) > > > > Fixed as well. > > > T4. The object iffixTransportSessionProtocol uses only 3 out of the > > 255 possible values in the range (6, 17, 132). A better > SYNTAX would > > be just INTEGER and then enumerate the three values in the > > MODULE-COMPLIANCE clause. This would allow future changes by just > > another MODULE-COMPLIANCE if there is a need to add a new > protocol. If > > you believe that another transport will be never added the > appropriate > > SYNTAX would be INTEGER (6|17|132). Also provide > > > http://www.iana.org/assignments/protocol-numbers/protocol-numbers.xhtm > > l > > as REFERENCE. > > > > I have put that into the module compliance section. > > > T5. There is only one InetAddressType object for both source and > > destination addresses. Does this mean that an IPFIX session is only > > IPv4 > > to IPv4 or IPv6 to IPv6? This is a question, I apologize if it is a > > layman one. In any case, it would be good to write an > explanation, as > > users of the RFC 4001 addresses TCs are used to always > encounter pairs > > of type-address objects. > > Just a mistake by myself. I added a object for source and > destination address. > > > > > > T6. Why are the address type and addresses objects only > valid for UDP > > and TCP, and not for SCTP? Are not STCP session also > conducted between > > IP hosts that can be described by IP addresses? > > > > Because we use the SCTP Association Id defined in the SCTP > MIB for that. > Thus the SCTP MIB holds IPs and ports for the association Id. > Clarified that in the description. > > > T7. What does 'this object is only valid' mean for the address type > > and addresses objects? What is returned by the agent in > this case on a > > Get operation on these objects? > > > > Also made this clear. > > > T8. The InetPort TC IMPORT-ed from RFC 4001 looks like a more > > appropriate SYNTAX for the ipfixTransportSessionSourcePort and > > ipfixTransportSessionDestinationPort objects > > > > You are right again. Fixed. > > > T9. I cannot figure out what is the role of all the DEFVAL > clauses in > > this MIB module. All the MIB is read-only and there is no > dynamic row > > creation. Why are they needed? > > > > You are right again. Since we first discussed if the MIB > should be writable or not this is a remainder of these times. > > > T10. Many of the objects in the MIB modules - especially > counters and > > gauges - would benefit from defining UNITS clauses. In some places > > they are mentioned in the DESCRIPTION clauses, but using explicit > > UNITS clauses wherever possible is better. > > > > Added where I thought it is applicable. > > > T11. Some object names in table do not respect the naming > conventions > > that recommends that table names and objects have an > identical suffix > > - ipfixObservationDomainId, ipfixObservationPointGroupReference, > > ipfixPhysicalEntity, ipfixPhysicalEntityDirection > > > > Fixed. > > > T12. Some objects are completely missing REFERENCE clauses - > > especially in the first tables o the MIB. Some other clauses could > > benefit from more exact referencing, saying just [RFC5101] without > > mentioning the exact section is not very useful. > > > > Added where applicable. Improved if possible. > > > T13. Why is the range of ipfixTemplateDefinitionLength > 1..2147483547)? > > According to RFC 5101, section 7, page 31 it looks like it should be > > (0..65535) > > > > Fixed. > > > T14. Give http://www.iana.org/assignments/enterprise-numbers/ as > > REFERENCE for ipfixTemplateDefinitionEnterprise > > > > Done. > > > T15. Use hex notations for describing values in the > DESCRIPTION clause > > of ipfixTemplateDefintionFlags - the decimal values do not > correspond > > to the bits positions > > > > Done. > > > T16. ipfixExportEntry leads to a warning in the smicng compilation > > > > W: f(ipfix.mi2), (676,12) Row "ipfixExportEntry" does not have a > > consistent indexing scheme - index items from current table > must come > > after index items from other tables > > > > Since I have only libsmi (which does not catch this) I did > not realize it. > Fixed. > > > T17. A couple of enumerated objects start to value 0 which is not > > recommended unless special cases. Are there special cases here for > > ipfixExportMemberType and ipfixPhysicalEntityDirection > > > > Well, those cases indicate an unknown value which I think is > a special case and the same as in the TC InetAddressType. > > > T18. Unsigned32 seems to be a better SYNTAX than Integer32 (see RFC > > 4181) for the following objects: ipfixMeteringProcessId, > > ipfixObservationPointGroupReference, ipfixObservationPointIndex, > > ipfixTransportSessionRate > > > > Changed all types to Unsigned32 where possible. > > > T19. I cannot understand what useful information carries > > ipfixmeteringProcessId - it is not an index and its value is > > implementation dependent. > > We wanted to give a kind of ID to make it possible to > identify the process that creates the Flow Records. This may > be a process id or something similar. Maybe we should specify > it as process id. This needs further discussion. > > > > > T20. Does it make sense for the ipfixSelectorFunction to point to a > > function that is not available? > > > > Basically it doesn't. But we wanted to have the possibility > to have a list of Selector Functions that are basically > available (and thus present in the MIB tree) but may be > disabled somehow. > > > T21. I assume that selection functions will be added in the > future. If > > I am wrong please delete all mention of extensibility and > take out the > > ipfixSelectorFunctions group. If I am right, I suggest to put > > ipfixSelectorFunctions in a separate MIB module that will be IANA > > maintained, so that new functions can be added in the > future without > > the need to revise the MIB module and the RFC. The separate > MIB module > > will become the initial version of the IANA maintained > module, and new > > selector functions will be added using for example Expert Review > > policy. > > > > > > I personally think this makes sense to put it in a separate > MIB module which is maintained by IANA but this needs further > discussion on the list which I will start soon. > > > T22. it looks like Gauge32 would be a better SYNTAX for the > following > > objects: ipfixTransportSessionRate, > > ipfixMeteringProcessCacheActiveFlows, ipfixMetering > > ProcessCacheInactiveFlows > > > > Changed whereever applicable. > > > T23. How is ipfixTransportSessionRate computed? Every > second? Every T > > seconds? T=? > > > > I fixed this to one second intervals. Benoit, Atsushi any objections?? > > > T24. I am wondering whether more counters in this MIB > module need to > > be > > Counter64 rather than Counter32 - especially the bytes and packets > > counters > > > > Made all Counters Counter64. > > > T25. There is no definition of the discontinuity behavior > of all the > > counter objects or definition of discontinuity objects. > > > > T26. It looks like Counter32 (or Counter64) with the appropriate > > discontinuity objects are better SYNTAX for > > ipfixSelectorStatsPacketsObserved and > ipfixSelectorStatspacketsDropped. > > > > Added discontinuity objects and fixed the two issues above. > > > T27. Some of the DESCRIPTION clauses of the OBJECT-GROUPs contain > > statements about the mandatory or optional characteristics of the > > objects. This is inappropriate, such statements must be made in > > MODULE-COMPLIANCE definitions, not in OBJECT-GROUP. > > > > Fixed. > > > T.28. Security Consideration sections - The description of the > > vulnerability of objects in the tables should be more precise than > > 'contains configuration data that might be sensitive'. > > > > Changed. > > I also fixed the text issues below. Dan, please review > version 06 if all your issues are fixed except those which I > marked under discussion above. > > Thanks, > > Thomas > > > > > E1. Section 5.1 s/is defined in the MIB/is defined in the > MIB module/ > > > > E2. The language in the sub-section of section 5 may be > polished - for > > example in section 5.3 and 5.4 s/may want to export/is > configured to > > export/ > > > > E3. Section 5.6 s/consists of a set of function/consists of > a set of > > functions/ > > > > E4. Section 5.6 - 'the Metering Process table (ipfixMetering > > ProcessTable) is grouped by maintained by ...' - this > phrase needs to > > be fixed. > > > > E5. Section 6.1 - s/they should also implement the ENTITY MIB/they > > SHOULD also implement the ENTITY MIB/ > > > > E6. Section 6.1 s/all entries in the Observation Point > Table contain > > an ipfixPhysicalEntity of zero(0)/all values of the > > ipfixPhysicalEntity columns in the ipfixObservationPointTable are 0 > > and the values of the ipfixPhysicalEntityDirection columns > are none(0). > > > > E7. The DESCRIPTION clause and the name of the object > > ipfixTransportSessionMode seem mis-leading. I think that > this object > > describes the device role in a session, not the mode of the > session in > > other words it's an attribute of the device that runs the agent and > > not of the session. > > > > E8. The DESCRIPTION clause of the ipfixTemplateAccessTime object is > > confusing. The second and third paragraph seem to duplicate the > > content of the first paragraph. The last phrase of the > clause seems to > > belong rather in the DESCRIPTION clause of the table than here. > > > > E9. DESCRIPTION clause of ipfixObservationPointIndex - is this > > 'management system' or rather 'management agent'? > > > > E10. DESCRIPTION clause of ipfixPhysicalEntity s/the object > contains > > 0/the value of the object is 0/ > > > > E11. What does 'a direction is not applicable' mean in the > DESCRIPTION > > clause of ipfixPhysicalEntityDirection? > > > > > > _______________________________________________ > > 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 --------------030406040505090304090508 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Dear all,

>From AD review:
T19. I cannot understand what useful information carries 
> > ipfixmeteringProcessId - it is not an index and its value is 
> > implementation dependent.
  
> 
> We wanted to give a kind of ID to make it possible to 
> identify the process that creates the Flow Records. This may 
> be a process id or something similar. Maybe we should specify 
> it as process id. This needs further discussion.

Discussing some more with Gerhard (as the consistency between the IPFIX MIB and IPFIX Configuration Model is key), we came to the following observations and conclusions.

he following IDs have a meaning for the IPFIX Protocol: Selector ID, Selection Sequence ID, Observation Point ID, Observation Domain ID.

These IDs don't: Exporting Process ID, Collecting Process ID, Metering Process ID.

It is weird that we have:
- MPID in the MIB, but not EPID and CPID
- EPID and CPID in IPFIX-CONF, but not in the MPID.

Regarding the MIB, I think that it makes sense to remove MPID unless we also add EPID and CPID.

Regarding IPFIX-CONF, we have problems to add MPID because the boundaries of a single MPID are not defined. I've mentioned this problem in previous mails. So, either we live with only EPID and CPID in IPFIX-CONF or we remove these two as well. Actually, we do not see a good reason for configuring these IDs anyway!
The logical conclusion seems to be: no MPID, EPID, CPID in [IPFIX-MIB] and [IPFIX-CONF]

Regards, Gerhard & Benoit.

-------- Original Message --------
Subject: Re: [IPFIX] AD review of draft-ietf-ipfix-mib-05.txt
Date: Wed, 18 Mar 2009 14:57:16 +0100
From: Romascanu, Dan (Dan) <dromasca@avaya.com>
To: Thomas Dietz <Thomas.Dietz@nw.neclab.eu>, IETF IPFIX Working Group <ipfix@ietf.org>
CC: MIB Doctors (E-mail) <mib-doctors@ietf.org>
References: <EDC652A26FB23C4EB6384A4584434A04013E05ED@307622ANEX5.global.avaya.com> <547F018265F92642B577B986577D671C7009CF@VENUS.office> 


Thank you for addressing my comments. Most of the issues were
acknowledged and fixed accordingly. T19 and T21 still need discussion,
while T23 needs to be acknowledged by the other editors. 

My question to the WG chairs is whether we should send the document to
IETF Last Call, considering the open issues as Last Call issues, to be
answered and resolved together with other Last Call comments we receive.


Dan
 

> -----Original Message-----
> From: Thomas Dietz [mailto:Thomas.Dietz@nw.neclab.eu] 
> Sent: Monday, March 09, 2009 1:26 PM
> To: Romascanu, Dan (Dan); IETF IPFIX Working Group
> Cc: MIB Doctors (E-mail)
> Subject: RE: [IPFIX] AD review of draft-ietf-ipfix-mib-05.txt
> 
> Dear Dan, all,
> 
> find my comments inline...
> 
> -- 
> Thomas Dietz                 E-mail: Thomas.Dietz@nw.neclab.eu
> NEC Europe Ltd.              Phone:  +49 6221 4342-128
> NEC Laboratories Europe      Fax:    +49 6221 4342-155
> Network Research Division
> Kurfuersten-Anlage 36
> 69115 Heidelberg, Germany    http://www.nw.neclab.eu
> 
> NEC Europe Limited           Registered in England 2832014
> Registered Office: NEC House, 1 Victoria Road, London W3 6BL
> 
> > -----Original Message-----
> > From: ipfix-bounces@ietf.org 
> [mailto:ipfix-bounces@ietf.org] On Behalf 
> > Of Romascanu, Dan (Dan)
> > Sent: Dienstag, 17. Februar 2009 17:27
> > To: IETF IPFIX Working Group
> > Cc: MIB Doctors (E-mail)
> > Subject: [IPFIX] AD review of draft-ietf-ipfix-mib-05.txt
> > 
> > Please find below the AD (and MIB doctor) review of 
> > draft-ietf-ipfix-mib-05.txt. This I-D is not ready yet for 
> IETF Last 
> > Call. Please address the issues below and issue a new I-D.
> > 
> > Part of the comments were contributed by Bert Wijnen.
> > 
> > I have divided the comments into Technical and Editorial.
> > 
> > Thanks and Regards,
> > 
> > Dan
> > 
> > 
> > T1. INET-ADDRESS-MIB is IMPORT-ed from RFC 4001and not from RFC 3291
> 
> Fixed.
> 
> > 
> > T2. There is no real justification for defining a new TC for 
> > IpfixFunctionAvailability. As per RFC 4181, use TruthValue instead.
> > 
> 
> You are right. Fixed.
> 
> > T3. The top level structure of the MIB does not follow the 
> > recommendation in Appendix D of RFC 4181 concerning the OID layout:
> > 
> >   xxxMIB
> >          |
> >          +-- xxxNotifications(0)
> >          +-- xxxObjects(1)
> >          +-- xxxConformance(2)
> >              |
> >              +-- xxxCompliances(1)
> >              +-- xxxGroups(2)
> > 
> 
> Fixed as well.
> 
> > T4. The object iffixTransportSessionProtocol uses only 3 out of the 
> > 255 possible values in the range (6, 17, 132). A better 
> SYNTAX would 
> > be just INTEGER and then enumerate the three values in the 
> > MODULE-COMPLIANCE clause. This would allow future changes by just 
> > another MODULE-COMPLIANCE if there is a need to add a new 
> protocol. If 
> > you believe that another transport will be never added the 
> appropriate 
> > SYNTAX would be INTEGER (6|17|132). Also provide 
> > 
> http://www.iana.org/assignments/protocol-numbers/protocol-numbers.xhtm
> > l
> > as REFERENCE.
> > 
> 
> I have put that into the module compliance section.
> 
> > T5. There is only one InetAddressType object for both source and 
> > destination addresses. Does this mean that an IPFIX session is only
> > IPv4
> > to IPv4 or IPv6 to IPv6? This is a question, I apologize if it is a 
> > layman one. In any case, it would be good to write an 
> explanation, as 
> > users of the RFC 4001 addresses TCs are used to always 
> encounter pairs 
> > of type-address objects.
> 
> Just a mistake by myself. I added a object for source and 
> destination address.
> 
> 
> > 
> > T6. Why are the address type and addresses objects only 
> valid for UDP 
> > and TCP, and not for SCTP? Are not STCP session also 
> conducted between 
> > IP hosts that can be described by IP addresses?
> > 
> 
> Because we use the SCTP Association Id defined in the SCTP 
> MIB for that.
> Thus the SCTP MIB holds IPs and ports for the association Id. 
> Clarified that in the description.
> 
> > T7. What does 'this object is only valid' mean for the address type 
> > and addresses objects? What is returned by the agent in 
> this case on a 
> > Get operation on these objects?
> > 
> 
> Also made this clear.
> 
> > T8. The InetPort TC IMPORT-ed from RFC 4001 looks like a more 
> > appropriate SYNTAX for the ipfixTransportSessionSourcePort and 
> > ipfixTransportSessionDestinationPort objects
> > 
> 
> You are right again. Fixed.
> 
> > T9. I cannot figure out what is the role of all the DEFVAL 
> clauses in 
> > this MIB module. All the MIB is read-only and there is no 
> dynamic row 
> > creation. Why are they needed?
> > 
> 
> You are right again. Since we first discussed if the MIB 
> should be writable or not this is a remainder of these times.
> 
> > T10. Many of the objects in the MIB modules - especially 
> counters and 
> > gauges - would benefit from defining UNITS clauses. In some places 
> > they are mentioned in the DESCRIPTION clauses, but using explicit 
> > UNITS clauses wherever possible is better.
> > 
> 
> Added where I thought it is applicable.
> 
> > T11. Some object names in table do not respect the naming 
> conventions 
> > that recommends that table names and objects have an 
> identical suffix 
> > - ipfixObservationDomainId,  ipfixObservationPointGroupReference,
> > ipfixPhysicalEntity, ipfixPhysicalEntityDirection
> > 
> 
> Fixed.
> 
> > T12. Some objects are completely missing REFERENCE clauses - 
> > especially in the first tables o the MIB. Some other clauses could 
> > benefit from more exact referencing, saying just [RFC5101] without 
> > mentioning the exact section is not very useful.
> > 
> 
> Added where applicable. Improved if possible.
> 
> > T13. Why is the range of ipfixTemplateDefinitionLength 
> 1..2147483547)?
> > According to RFC 5101, section 7, page 31 it looks like it should be
> > (0..65535)
> > 
> 
> Fixed.
> 
> > T14. Give http://www.iana.org/assignments/enterprise-numbers/ as 
> > REFERENCE for ipfixTemplateDefinitionEnterprise
> > 
> 
> Done.
> 
> > T15. Use hex notations for describing values in the 
> DESCRIPTION clause 
> > of ipfixTemplateDefintionFlags - the decimal values do not 
> correspond 
> > to the bits positions
> > 
> 
> Done.
> 
> > T16. ipfixExportEntry leads to a warning in the smicng compilation
> > 
> > W: f(ipfix.mi2), (676,12) Row "ipfixExportEntry" does not have a 
> > consistent indexing scheme - index items from current table 
> must come 
> > after index items from other tables
> > 
> 
> Since I have only libsmi (which does not catch this) I did 
> not realize it.
> Fixed.
> 
> > T17. A couple of enumerated objects start to value 0 which is not 
> > recommended unless special cases. Are there special cases here for 
> > ipfixExportMemberType and ipfixPhysicalEntityDirection
> > 
> 
> Well, those cases indicate an unknown value which I think is 
> a special case and the same as in the TC InetAddressType.
> 
> > T18. Unsigned32 seems to be a better SYNTAX than Integer32 (see RFC
> > 4181) for the following objects: ipfixMeteringProcessId, 
> > ipfixObservationPointGroupReference, ipfixObservationPointIndex, 
> > ipfixTransportSessionRate
> > 
> 
> Changed all types to Unsigned32 where possible.
> 
> > T19. I cannot understand what useful information carries 
> > ipfixmeteringProcessId - it is not an index and its value is 
> > implementation dependent.
> 
> We wanted to give a kind of ID to make it possible to 
> identify the process that creates the Flow Records. This may 
> be a process id or something similar. Maybe we should specify 
> it as process id. This needs further discussion.
> 
> > 
> > T20. Does it make sense for the ipfixSelectorFunction to point to a 
> > function that is not available?
> > 
> 
> Basically it doesn't. But we wanted to have the possibility 
> to have a list of Selector Functions that are basically 
> available (and thus present in the MIB tree) but may be 
> disabled somehow.
> 
> > T21. I assume that selection functions will be added in the 
> future. If 
> > I am wrong please delete all mention of extensibility and 
> take out the 
> > ipfixSelectorFunctions group. If I am right, I suggest to put 
> > ipfixSelectorFunctions in a separate MIB module that will be IANA 
> > maintained, so that new functions can be added in the 
> future without 
> > the need to revise the MIB module and the RFC. The separate 
> MIB module 
> > will become the initial version of the IANA maintained 
> module, and new 
> > selector functions will be added using for example Expert Review 
> > policy.
> > 
> > 
> 
> I personally think this makes sense to put it in a separate 
> MIB module which is maintained by IANA but this needs further 
> discussion on the list which I will start soon.
> 
> > T22. it looks like Gauge32 would be a better SYNTAX for the 
> following
> > objects: ipfixTransportSessionRate,
> > ipfixMeteringProcessCacheActiveFlows, ipfixMetering 
> > ProcessCacheInactiveFlows
> > 
> 
> Changed whereever applicable.
> 
> > T23. How is ipfixTransportSessionRate computed? Every 
> second? Every T 
> > seconds? T=?
> > 
> 
> I fixed this to one second intervals. Benoit, Atsushi any objections??
> 
> > T24. I am wondering whether more counters in this MIB 
> module need to 
> > be
> > Counter64 rather than Counter32 - especially the bytes and packets 
> > counters
> > 
> 
> Made all Counters Counter64.
> 
> > T25. There is no definition of the discontinuity behavior 
> of all the 
> > counter objects or definition of discontinuity objects.
> > 
> > T26. It looks like Counter32 (or Counter64) with the appropriate 
> > discontinuity objects are better SYNTAX for 
> > ipfixSelectorStatsPacketsObserved and 
> ipfixSelectorStatspacketsDropped.
> > 
> 
> Added discontinuity objects and fixed the two issues above.
> 
> > T27. Some of the DESCRIPTION clauses of the OBJECT-GROUPs contain 
> > statements about the mandatory or optional characteristics of the 
> > objects. This is inappropriate, such statements must be made in 
> > MODULE-COMPLIANCE definitions, not in OBJECT-GROUP.
> > 
> 
> Fixed.
> 
> > T.28. Security Consideration sections - The description of the 
> > vulnerability of objects in the tables should be more precise than 
> > 'contains configuration data that might be sensitive'.
> > 
> 
> Changed.
> 
> I also fixed the text issues below. Dan, please review 
> version 06 if all your issues are fixed except those which I 
> marked under discussion above.
> 
> Thanks,
> 
> Thomas
> 
> > 
> > E1. Section 5.1 s/is defined in the MIB/is defined in the 
> MIB module/
> > 
> > E2. The language in the sub-section of section 5 may be 
> polished - for 
> > example in section 5.3 and 5.4 s/may want to export/is 
> configured to 
> > export/
> > 
> > E3. Section 5.6 s/consists of a set of function/consists of 
> a set of 
> > functions/
> > 
> > E4. Section 5.6 - 'the Metering Process table (ipfixMetering
> > ProcessTable) is grouped by maintained by ...' - this 
> phrase needs to 
> > be fixed.
> > 
> > E5. Section 6.1 - s/they should also implement the ENTITY MIB/they 
> > SHOULD also implement the ENTITY MIB/
> > 
> > E6. Section 6.1 s/all entries in the Observation Point 
> Table contain 
> > an ipfixPhysicalEntity of zero(0)/all values of the 
> > ipfixPhysicalEntity columns in the ipfixObservationPointTable are 0 
> > and the values of the ipfixPhysicalEntityDirection columns 
> are none(0).
> > 
> > E7. The DESCRIPTION clause and the name of the object 
> > ipfixTransportSessionMode seem mis-leading. I think that 
> this object 
> > describes the device role in a session, not the mode of the 
> session in 
> > other words it's an attribute of the device that runs the agent and 
> > not of the session.
> > 
> > E8. The DESCRIPTION clause of the ipfixTemplateAccessTime object is 
> > confusing. The second and third paragraph seem to duplicate the 
> > content of the first paragraph. The last phrase of the 
> clause seems to 
> > belong rather in the DESCRIPTION clause of the table than here.
> > 
> > E9. DESCRIPTION clause of ipfixObservationPointIndex - is this 
> > 'management system' or rather 'management agent'?
> > 
> > E10. DESCRIPTION clause of ipfixPhysicalEntity s/the object 
> contains 
> > 0/the value of the object is 0/
> > 
> > E11. What does 'a direction is not applicable' mean in the 
> DESCRIPTION 
> > clause of ipfixPhysicalEntityDirection?
> > 
> > 
> > _______________________________________________
> > 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
--------------030406040505090304090508-- From n.brownlee@auckland.ac.nz Sun Mar 22 21:59: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 1A7E43A67B5 for ; Sun, 22 Mar 2009 21:59:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.177 X-Spam-Level: X-Spam-Status: No, score=-4.177 tagged_above=-999 required=5 tests=[AWL=-0.178, BAYES_50=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 beNls9uByntS for ; Sun, 22 Mar 2009 21:59:00 -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 418C93A67A7 for ; Sun, 22 Mar 2009 21:58:58 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by mailhost.auckland.ac.nz (Postfix) with ESMTP id D0B8519A85 for ; Mon, 23 Mar 2009 17:59:46 +1300 (NZDT) 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 ATc8gRK5Ehg6 for ; Mon, 23 Mar 2009 17:59:46 +1300 (NZDT) 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 B262719A84 for ; Mon, 23 Mar 2009 17:59:46 +1300 (NZDT) Message-ID: <49C71742.90007@auckland.ac.nz> Date: Mon, 23 Mar 2009 17:59:46 +1300 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] Slides for IPFIX session 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, 23 Mar 2009 04:59:01 -0000 Hi all: Will presenters please email their slides to ipfix-chairs@tools.ietf.org Jeurgen or I will put them on the meeting agenda page as soon as we can. Also, for the meeting, we'll need a jabber scribe - please let Jeurgen know if you could do that. Cheers, Nevil -- --------------------------------------------------------------------- Nevil Brownlee Computer Science Department | ITS Phone: +64 9 373 7599 x88941 The University of Auckland FAX: +64 9 373 7453 Private Bag 92019, Auckland 1142, New Zealand From irino.hitoshi@lab.ntt.co.jp Sun Mar 22 23:40:07 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 67BB43A685D for ; Sun, 22 Mar 2009 23:40:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.51 X-Spam-Level: ** X-Spam-Status: No, score=2.51 tagged_above=-999 required=5 tests=[BAYES_50=0.001, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id A1a6dBBopHuU for ; Sun, 22 Mar 2009 23:40:06 -0700 (PDT) Received: from tama500.ecl.ntt.co.jp (tama500.ecl.ntt.co.jp [129.60.39.148]) by core3.amsl.com (Postfix) with ESMTP id 811A43A67B5 for ; Sun, 22 Mar 2009 23:40:05 -0700 (PDT) Received: from mfs6.rdh.ecl.ntt.co.jp (mfs6.rdh.ecl.ntt.co.jp [129.60.39.149]) by tama500.ecl.ntt.co.jp (8.14.2/8.14.2) with ESMTP id n2N6et06003172 for ; Mon, 23 Mar 2009 15:40:55 +0900 (JST) Received: from mfs6.rdh.ecl.ntt.co.jp (localhost [127.0.0.1]) by mfs6.rdh.ecl.ntt.co.jp (Postfix) with ESMTP id 028F76603 for ; Mon, 23 Mar 2009 15:40:55 +0900 (JST) Received: from imm.m.ecl.ntt.co.jp (imm0.m.ecl.ntt.co.jp [129.60.5.151]) by mfs6.rdh.ecl.ntt.co.jp (Postfix) with ESMTP id EE6466600 for ; Mon, 23 Mar 2009 15:40:54 +0900 (JST) Received: from [127.0.0.1] ([129.60.80.56]) by imm.m.ecl.ntt.co.jp (8.13.8/8.13.8) with ESMTP id n2N6ekIs000352 for ; Mon, 23 Mar 2009 15:40:54 +0900 (JST) Message-ID: <49C72F0A.9090305@lab.ntt.co.jp> Date: Mon, 23 Mar 2009 15:41:14 +0900 From: Hitoshi Irino Organization: NTT User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: ipfix@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [IPFIX] about Collecting Process MIB objects X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Mar 2009 06:40:07 -0000 Dear IPFIX-MIB authors and all, I'd like to propose to add MIB objects about collecting process, if you agree and if you can. (I am sorry for my very late opinion, I hit on this recently.) Collected information will be passed to another process (e.g., File Writer, Metering Process in Mediators and/or any applications for analyzing and/or displaying graphical view in Collectors) from collecting process generally, I think. If the number of processed packets, bytes, and messages in Collecting Process (which I call them as ipfixCollectingProcessProcessedPackets/Bytes/Messages in this mail temporarily) can be got, I think these objects are useful to detect failure in Collectors (or Mediators) by comparing ipfixTransportSessionPackets/Bytes/Messages and these objects. Therefore I'd like to add ipfixCollectingProcessProcessedPackets/Bytes/Messages. An example situation: If a Collector's disk is full filled and File Writer will fail in writing, ipfixTransportSessionPackets/Bytes/Messages will be increased but ipfixCollectingProcessProcessedPackets/Bytes/Messages will not be increased when a Collecting Process receives new IPFIX Message. regards, Hitoshi IRINO -- Hitoshi Irino NTT Network Service Systems Laboratories 9-11 Midori-cho 3-Chome, Musashino-shi, Tokyo 180-8585 Japan Tel: +81-422-59-4403 Fax: +81-422-59-4549 From Thomas.Dietz@nw.neclab.eu Mon Mar 23 02:07:11 2009 Return-Path: X-Original-To: ipfix@core3.amsl.com Delivered-To: ipfix@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 15B173A6B2C for ; Mon, 23 Mar 2009 02:07:11 -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=[AWL=0.000, 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 69Faon2cS0SP for ; Mon, 23 Mar 2009 02:07:10 -0700 (PDT) Received: from smtp0.neclab.eu (smtp0.neclab.eu [195.37.70.41]) by core3.amsl.com (Postfix) with ESMTP id 9AABE3A69EC for ; Mon, 23 Mar 2009 02:07:09 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp0.neclab.eu (Postfix) with ESMTP id 1DB3F2C0004DA; Mon, 23 Mar 2009 10:07:59 +0100 (CET) X-Virus-Scanned: Amavisd on Debian GNU/Linux (atlas2.office) Received: from smtp0.neclab.eu ([127.0.0.1]) by localhost (atlas2.office [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UI5Ye4OvvopK; Mon, 23 Mar 2009 10:07:58 +0100 (CET) Received: from VENUS.office (mx2.office [192.168.24.15]) by smtp0.neclab.eu (Postfix) with ESMTP id DACDC2C0000EB; Mon, 23 Mar 2009 10:07:48 +0100 (CET) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Mon, 23 Mar 2009 10:07:47 +0100 Content-Type: multipart/signed; micalg=SHA1; boundary="----=_NextPart_000_00CA_01C9AB9F.37477730"; protocol="application/x-pkcs7-signature" Message-ID: <547F018265F92642B577B986577D671C785BB0@VENUS.office> In-Reply-To: <49C72F0A.9090305@lab.ntt.co.jp> X-MS-Has-Attach: yes X-MS-TNEF-Correlator: Thread-Topic: [IPFIX] about Collecting Process MIB objects thread-index: Acmrgl+/c8+wwcISTkiJTtYfmemHdgAFBmgg References: <49C72F0A.9090305@lab.ntt.co.jp> From: "Thomas Dietz" To: "Hitoshi Irino" , Subject: Re: [IPFIX] about Collecting Process MIB objects X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Mar 2009 09:07:11 -0000 This is a multi-part message in MIME format. ------=_NextPart_000_00CA_01C9AB9F.37477730 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Dear Hitoshi, since we don't have any reference to the collecting process in the MIB = and we just agreed to remove even the Metering Process ID (see previous mail = on the list) I don't see any chance to include such objects. Sorry to say = so. Best Regards, Thomas --=20 Thomas Dietz E-mail: Thomas.Dietz@nw.neclab.eu NEC Europe Ltd. Phone: +49 6221 4342-128 NEC Laboratories Europe Fax: +49 6221 4342-155 Network Research Division Kurfuersten-Anlage 36 69115 Heidelberg, Germany http://www.nw.neclab.eu NEC Europe Limited Registered in England 2832014 Registered Office: NEC House, 1 Victoria Road, London W3 6BL > -----Original Message----- > From: ipfix-bounces@ietf.org [mailto:ipfix-bounces@ietf.org] On Behalf > Of Hitoshi Irino > Sent: Montag, 23. M=E4rz 2009 07:41 > To: ipfix@ietf.org > Subject: [IPFIX] about Collecting Process MIB objects >=20 > Dear IPFIX-MIB authors and all, >=20 > I'd like to propose to add MIB objects about collecting process, if = you > agree > and if you can. (I am sorry for my very late opinion, I hit on this > recently.) >=20 > Collected information will be passed to another process (e.g., File > Writer, > Metering Process in Mediators and/or any applications for analyzing > and/or > displaying graphical view in Collectors) from collecting process > generally, I > think. >=20 > If the number of processed packets, bytes, and messages in Collecting > Process > (which I call them as > ipfixCollectingProcessProcessedPackets/Bytes/Messages in > this mail temporarily) can be got, I think these objects are useful to > detect > failure in Collectors (or Mediators) by comparing > ipfixTransportSessionPackets/Bytes/Messages and these objects. > Therefore I'd > like to add ipfixCollectingProcessProcessedPackets/Bytes/Messages. >=20 > An example situation: If a Collector's disk is full filled and File > Writer > will fail in writing, ipfixTransportSessionPackets/Bytes/Messages will > be > increased but ipfixCollectingProcessProcessedPackets/Bytes/Messages > will not > be increased when a Collecting Process receives new IPFIX Message. >=20 > regards, > Hitoshi IRINO >=20 > -- > Hitoshi Irino > NTT Network Service Systems Laboratories > 9-11 Midori-cho 3-Chome, Musashino-shi, Tokyo 180-8585 Japan > Tel: +81-422-59-4403 Fax: +81-422-59-4549 >=20 >=20 > _______________________________________________ > IPFIX mailing list > IPFIX@ietf.org > https://www.ietf.org/mailman/listinfo/ipfix ------=_NextPart_000_00CA_01C9AB9F.37477730 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIISNzCCA58w ggKHoAMCAQICASYwDQYJKoZIhvcNAQEFBQAwcTELMAkGA1UEBhMCREUxHDAaBgNVBAoTE0RldXRz Y2hlIFRlbGVrb20gQUcxHzAdBgNVBAsTFlQtVGVsZVNlYyBUcnVzdCBDZW50ZXIxIzAhBgNVBAMT GkRldXRzY2hlIFRlbGVrb20gUm9vdCBDQSAyMB4XDTk5MDcwOTEyMTEwMFoXDTE5MDcwOTIzNTkw MFowcTELMAkGA1UEBhMCREUxHDAaBgNVBAoTE0RldXRzY2hlIFRlbGVrb20gQUcxHzAdBgNVBAsT FlQtVGVsZVNlYyBUcnVzdCBDZW50ZXIxIzAhBgNVBAMTGkRldXRzY2hlIFRlbGVrb20gUm9vdCBD QSAyMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAqwujNeCLKRSxFIWvPBDkOW81XUqu 3ephjZVJ9G9koxpgZqSpQCKE2dSl5XiTDmgBrblNXDrO07ioQkDfz6O6gllqkhusHJraCCslJ/lp I0fx4Ossepv1EwLQfjR8wp48AFmr9doM9TI8K6xQ2tbD3oOUyqgMmTIOCEhWW2r72uFYWAFJX3JB PBUGAY5draq4k7TNnuun6GotUjTbOu9cdVHa2/Mx+e5xmDLEVBVEDPmbVe2t3xgIoKOGiknuUwWP GUzV3lh5m9JqHEKrxdWnz2gPluThYZh2YciRfNY+AOKRUIfhnQrmrZfSHcY6fcu82gM01Y5bAfVq B7cWtm5KfwIDAQABo0IwQDAdBgNVHQ4EFgQUMcN5G7r1U9cX4Il6LRdsCrMrnTMwDwYDVR0TBAgw BgEB/wIBBTAOBgNVHQ8BAf8EBAMCAQYwDQYJKoZIhvcNAQEFBQADggEBAJRkWa05ZOcp6xP+WsOL E1fIBCTwdHfAYONn++mJpoO/loJ8btTDPe+egG67KbSYerE7VOs5F0d+Go4L/B8xWTEEss4X8yzH YjZV4iLYiVW0mEiqZPrWHDbYRHhaWiM6V5f1ejBPrp9qTEsrjqAD4z7gqdTSe9KzqOJyPK2e/4BZ 5JtFtPY7sM05GZgy5eohYZDkMSGONLH3LzVKhRDa54o3Ib5ZY+DyhYgxU9RUFIVwefQuBncndS8f uIr5/sW62Dbkg+znZbe/Y1rzRq+BlDfUQYzWI9Yez/VoG0Rjolq6pzVZoeVwBZsOI1eZlAptujlj KIaS8xiE2PvRzwVWZFcwggQhMIIDCaADAgECAgIAxzANBgkqhkiG9w0BAQUFADBxMQswCQYDVQQG EwJERTEcMBoGA1UEChMTRGV1dHNjaGUgVGVsZWtvbSBBRzEfMB0GA1UECxMWVC1UZWxlU2VjIFRy dXN0IENlbnRlcjEjMCEGA1UEAxMaRGV1dHNjaGUgVGVsZWtvbSBSb290IENBIDIwHhcNMDYxMjE5 MTAyOTAwWhcNMTkwNjMwMjM1OTAwWjBaMQswCQYDVQQGEwJERTETMBEGA1UEChMKREZOLVZlcmVp bjEQMA4GA1UECxMHREZOLVBLSTEkMCIGA1UEAxMbREZOLVZlcmVpbiBQQ0EgR2xvYmFsIC0gRzAx MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA6ZvDZ4X5Da71jVTDllA1PWLpbkztlNcA W5UidNQg6zSP1uzAMQQLmYHiphTSUqAoI4SLdIkEXlvg4njBeMsWyyg1OXstkEXQ7aAAeny/Sg4b AMOG6VwrMRF7DPOCJEOMHDiLamgAmu7cT3ir0sYTm3at7t4m6O8Br3QPwQmi9mvOvdPNFDBP9eXj pMhim4IaAycwDQJlYE3t0QkjKpY1WCfTdsZxtpAdxO3/NYZ9bzOz2w/FEcKKg6GUXUFr2NIQ9Uz9 ylGs2b3vkoO72uuLFlZWQ8/h1RM9ph8nMM1JVNvJEzSacXXFbOqnC5j5IZ0nrz6jOTlIaoytyZn7 wxLyvQIDAQABo4HZMIHWMHAGA1UdHwRpMGcwZaBjoGGGX2h0dHA6Ly9wa2kudGVsZXNlYy5kZS9j Z2ktYmluL3NlcnZpY2UvYWZfRG93bmxvYWRBUkwuY3JsPy1jcmxfZm9ybWF0PVhfNTA5Ji1pc3N1 ZXI9RFRfUk9PVF9DQV8yMB0GA1UdDgQWBBRJt8bP6D0ff+pEexMp9/EKcD7eZDAfBgNVHSMEGDAW gBQxw3kbuvVT1xfgiXotF2wKsyudMzAOBgNVHQ8BAf8EBAMCAQYwEgYDVR0TAQH/BAgwBgEB/wIB AjANBgkqhkiG9w0BAQUFAAOCAQEAO+Fad8BIF9ypGOyBr1qJ8L0okqbKWRgScOwo8ueuf5Ys5/Jd GTH2Eyt0vb2Asrn3Z8k5onk74RER7mt4kTN+O18mJ3VTZY4zY+7Pc8OwkiNJIVB1I6EfGOKUhT0/ M+l3II2iveahhSlA9j9zMlgNCWum2oVswD+7jWZkViROrg0/MjUBW+mMgtlyWU+xhoXxdIVW5cP4 XPON7kezUwVw5+VNimmDKOETCYaeXsjqWB4MH/mk1FoEaP0oPosCtli19qEsN1cAZ6sjaI1jpe+Z a1z9S1b2q0CHNNQRkmzsh8UKCwczcrRvDB1ULNhRx8y/MNNDcvEyv4zOSWOoAPfyHDCCBS8wggQX oAMCAQICBA0hCkcwDQYJKoZIhvcNAQEFBQAwWjELMAkGA1UEBhMCREUxEzARBgNVBAoTCkRGTi1W ZXJlaW4xEDAOBgNVBAsTB0RGTi1QS0kxJDAiBgNVBAMTG0RGTi1WZXJlaW4gUENBIEdsb2JhbCAt IEcwMTAeFw0wODEwMjQwODUyMDhaFw0xOTA2MzAwMDAwMDBaMIGQMQswCQYDVQQGEwJERTEYMBYG A1UEChMPTkVDIEV1cm9wZSBMdGQuMSAwHgYDVQQLExdORUMgTGFib3JhdG9yaWVzIEV1cm9wZTES MBAGA1UEAxMJTkVDTEFCLUNBMTEwLwYJKoZIhvcNAQkBFiJ6ZXJ0aWZpemllcnVuZ3NzdGVsbGVA bncubmVjbGFiLmV1MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAnvIVsbURqjIOcbnf ruYkRceWOZpyvM2ebnYpbd1cP+zdWm6yR7HSO9ppOe1ZZFIasArqQpedPEFvcncSG94FRuW3ND4r Rcq08mbpUTmpWmXfdYlJpQezbsOHCWR74NXoEEbK6TPZIMFpJr6dzQDAxnRc7UOgO6JQ1V42Z39B PhIbPIWz64t8svafxbORmxulJn7F5zDLDcR1AEGyn+L9b645AGwapoKNh7cSQFTqdb6kGyPQjLWf tv09dvmBDKesrcyLZXuDWJ1LMeizSjUEygdSszNXD3gePgJaVaZDS3o923W5gAyPCTSxpAFj8XJ+ /7Ap5jJwYhjJgJ8khFR7JQIDAQABo4IBxDCCAcAwEgYDVR0TAQH/BAgwBgEB/wIBATALBgNVHQ8E BAMCAQYwHQYDVR0OBBYEFE8ch3od4C+Z9r4VqtE1nQ5K5ro2MB8GA1UdIwQYMBaAFEm3xs/oPR9/ 6kR7Eyn38QpwPt5kMC0GA1UdEQQmMCSBInplcnRpZml6aWVydW5nc3N0ZWxsZUBudy5uZWNsYWIu ZXUwgYgGA1UdHwSBgDB+MD2gO6A5hjdodHRwOi8vY2RwMS5wY2EuZGZuLmRlL2dsb2JhbC1yb290 LWNhL3B1Yi9jcmwvY2FjcmwuY3JsMD2gO6A5hjdodHRwOi8vY2RwMi5wY2EuZGZuLmRlL2dsb2Jh bC1yb290LWNhL3B1Yi9jcmwvY2FjcmwuY3JsMIGiBggrBgEFBQcBAQSBlTCBkjBHBggrBgEFBQcw AoY7aHR0cDovL2NkcDEucGNhLmRmbi5kZS9nbG9iYWwtcm9vdC1jYS9wdWIvY2FjZXJ0L2NhY2Vy dC5jcnQwRwYIKwYBBQUHMAKGO2h0dHA6Ly9jZHAyLnBjYS5kZm4uZGUvZ2xvYmFsLXJvb3QtY2Ev cHViL2NhY2VydC9jYWNlcnQuY3J0MA0GCSqGSIb3DQEBBQUAA4IBAQBsMQ+dD0mmi48dgDU4R6Q/ eXcY0zQcHNp1Vu1s3kwO0WahWB0tiqVBodvfTAWG44xuw0I7NXSTwQ68FU5P0GIQnvRFZyVJlDjr SNlLYxjqfmgb+KVm67o383cZIuDakEE0f29kULIEn2fg/HsDiBAXTsb4I19XaN0TXLI+PMhU+GDp sGCJrydeugEV7qi15q8yymjSAsYgnrc2wJuXpyQ9r3qCtP6aedAPSHqOT8ga1dLT2YRZFs3vNm7T HSr5JJymWMbfpD6OcbRTnNAjSMDHwJxgRBAflA6WzDVm7fk4jiWyLvJwWTMk19t8QLiKG7D0nYvj cEUYyiOSE+SFUTEdMIIFODCCBCCgAwIBAgIEDTI0WzANBgkqhkiG9w0BAQUFADCBkDELMAkGA1UE BhMCREUxGDAWBgNVBAoTD05FQyBFdXJvcGUgTHRkLjEgMB4GA1UECxMXTkVDIExhYm9yYXRvcmll cyBFdXJvcGUxEjAQBgNVBAMTCU5FQ0xBQi1DQTExMC8GCSqGSIb3DQEJARYiemVydGlmaXppZXJ1 bmdzc3RlbGxlQG53Lm5lY2xhYi5ldTAeFw0wODExMDYwOTIwMTFaFw0xMTExMDYwOTIwMTFaMGAx CzAJBgNVBAYTAkRFMRgwFgYDVQQKEw9ORUMgRXVyb3BlIEx0ZC4xIDAeBgNVBAsTF05FQyBMYWJv cmF0b3JpZXMgRXVyb3BlMRUwEwYDVQQDEwxUaG9tYXMgRGlldHowggEiMA0GCSqGSIb3DQEBAQUA A4IBDwAwggEKAoIBAQCniLuqlMflMs7ag3idESVRwfZ9nrdIyUmq5Tget4k9APGSPo2GZ1f1hr8y MuJIGowc/HzS1laVSICclOXju1xW93Tm+Vco5gwkRqHXY3Rmda0r2jlb8niVie4qXQgXPzunFRqk yNmbwYep3oD5Kq0GfB6EuZ7X6cYH5A7erAMeeQPhoDQDIfR79lRHlcMtanJZyORYNQONPEa+L4AF v5f3nAsmY7ZLJ72wX7X8BtcF6Vdkr0T2b1YrPl8Qir7e0TKY9Rf0q5DKu3QdLnXk0Rb+63V/4vLS PZ3XQVdwHzLiOhIZJVVMJE7TmJI0DFeDFn99O/F/Le/sJOJjNO4n6KMLAgMBAAGjggHHMIIBwzAJ BgNVHRMEAjAAMAsGA1UdDwQEAwIF4DApBgNVHSUEIjAgBggrBgEFBQcDAgYIKwYBBQUHAwQGCisG AQQBgjcUAgIwHQYDVR0OBBYEFLkbmpJJpIXhIR9JFttGC+KHW5g5MB8GA1UdIwQYMBaAFE8ch3od 4C+Z9r4VqtE1nQ5K5ro2MCQGA1UdEQQdMBuBGVRob21hcy5EaWV0ekBudy5uZWNsYWIuZXUwfQYD VR0fBHYwdDA4oDagNIYyaHR0cDovL2NkcDEucGNhLmRmbi5kZS9uZWNsYWItY2EvcHViL2NybC9j YWNybC5jcmwwOKA2oDSGMmh0dHA6Ly9jZHAyLnBjYS5kZm4uZGUvbmVjbGFiLWNhL3B1Yi9jcmwv Y2FjcmwuY3JsMIGYBggrBgEFBQcBAQSBizCBiDBCBggrBgEFBQcwAoY2aHR0cDovL2NkcDEucGNh LmRmbi5kZS9uZWNsYWItY2EvcHViL2NhY2VydC9jYWNlcnQuY3J0MEIGCCsGAQUFBzAChjZodHRw Oi8vY2RwMi5wY2EuZGZuLmRlL25lY2xhYi1jYS9wdWIvY2FjZXJ0L2NhY2VydC5jcnQwDQYJKoZI hvcNAQEFBQADggEBAEbKwRBhNxAzsH6kAYRBoIziyI2IY2QnZGeiGitOfkLKcFNIBH3ZfQXH4j20 4BP34Vzzob17EgsbLbNkMlxh2M7tenXH9vA4MiN5yPPBKoR7SfI6mIaIr+7kewOizJ8D5dvpdfP5 HbAUTZVSYHqixgBWJyNp7sXWVQtOo+eOv8qKUeiodClanKuCnGD42Bl6EQR486dlXvOronEikRYX Xg6gFrhO+DonUYluMZpNdabnybKozchSdHcceOKd0JFMmyiSNG944ystXbR7QZqfNSh/Pbyc5QRp Z1vdFZLFh907iS3KxueDYKDPWmlsPt/QnmXmF4A9/5OrmVS1C45k5rcxggQ4MIIENAIBATCBmTCB kDELMAkGA1UEBhMCREUxGDAWBgNVBAoTD05FQyBFdXJvcGUgTHRkLjEgMB4GA1UECxMXTkVDIExh Ym9yYXRvcmllcyBFdXJvcGUxEjAQBgNVBAMTCU5FQ0xBQi1DQTExMC8GCSqGSIb3DQEJARYiemVy dGlmaXppZXJ1bmdzc3RlbGxlQG53Lm5lY2xhYi5ldQIEDTI0WzAJBgUrDgMCGgUAoIICczAYBgkq hkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0wOTAzMjMwOTA3NDdaMCMGCSqG SIb3DQEJBDEWBBR3+K9Wy73XiosR1NKzMiIWWLUNmTCBqgYJKwYBBAGCNxAEMYGcMIGZMIGQMQsw CQYDVQQGEwJERTEYMBYGA1UEChMPTkVDIEV1cm9wZSBMdGQuMSAwHgYDVQQLExdORUMgTGFib3Jh dG9yaWVzIEV1cm9wZTESMBAGA1UEAxMJTkVDTEFCLUNBMTEwLwYJKoZIhvcNAQkBFiJ6ZXJ0aWZp emllcnVuZ3NzdGVsbGVAbncubmVjbGFiLmV1AgQNMjRbMIGsBgsqhkiG9w0BCRACCzGBnKCBmTCB kDELMAkGA1UEBhMCREUxGDAWBgNVBAoTD05FQyBFdXJvcGUgTHRkLjEgMB4GA1UECxMXTkVDIExh Ym9yYXRvcmllcyBFdXJvcGUxEjAQBgNVBAMTCU5FQ0xBQi1DQTExMC8GCSqGSIb3DQEJARYiemVy dGlmaXppZXJ1bmdzc3RlbGxlQG53Lm5lY2xhYi5ldQIEDTI0WzCBtwYJKoZIhvcNAQkPMYGpMIGm MAsGCWCGSAFlAwQBKjALBglghkgBZQMEARYwCgYIKoZIhvcNAwcwCwYJYIZIAWUDBAECMA4GCCqG SIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDAHBgUrDgMC GjALBglghkgBZQMEAgMwCwYJYIZIAWUDBAICMAsGCWCGSAFlAwQCATAKBggqhkiG9w0CBTANBgkq hkiG9w0BAQEFAASCAQBMzY2HSlEp7VCyKnwE1xhmk2EctbeG5KPKn3vCzLA+IsbfljT46NIlS1GY RgtfUyAj1BIWjv/MKgvisc9T6Eeg7s7+fwHNjI9EHZtmW7BLPnqzwYHW1Gc1/KBlwMen9yofpTAI b8V9El7VYz52CjX4kbHGC7F0HGzFz8uy7DTs67VM/BZJaWU2xBUrXHKDS1PQMuvt6fW7mt/UE9b8 IhiukH/l9BskGK9XTU627O5ywTQ9Mex19z7Ps6RzHghlLrzgw3EoqBjuept6lV+1zJQdfZ30f5pd MvqRtpadIherJeANsFhsRq0CY+Un58Dh5MA/mK/lWmTsshorZhYz+lK4AAAAAAAA ------=_NextPart_000_00CA_01C9AB9F.37477730-- From muenz@net.in.tum.de Mon Mar 23 03:16: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 B76893A6999 for ; Mon, 23 Mar 2009 03:16:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.878 X-Spam-Level: X-Spam-Status: No, score=-0.878 tagged_above=-999 required=5 tests=[AWL=-1.229, BAYES_50=0.001, 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 n5Y6+CktZppG for ; Mon, 23 Mar 2009 03:16:41 -0700 (PDT) Received: from mail-out2.informatik.tu-muenchen.de (maildmz2.informatik.tu-muenchen.de [131.159.0.15]) by core3.amsl.com (Postfix) with ESMTP id 875743A6998 for ; Mon, 23 Mar 2009 03:16:41 -0700 (PDT) Received: from phoenix.net.informatik.tu-muenchen.de (phoenix.net.informatik.tu-muenchen.de [131.159.14.1]) by services.net.informatik.tu-muenchen.de (Postix Mailer @ mail) with ESMTP id EE35447F33 for ; Mon, 23 Mar 2009 11:17:26 +0100 (CET) Received: from [131.159.20.108] (repulse.net.informatik.tu-muenchen.de [131.159.20.108]) by phoenix.net.informatik.tu-muenchen.de (Postfix) with ESMTP id DFEFD2766 for ; Mon, 23 Mar 2009 11:17:26 +0100 (CET) Message-ID: <49C761B8.5090208@net.in.tum.de> Date: Mon, 23 Mar 2009 11:17:28 +0100 From: Gerhard Muenz User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: "ipfix@ietf.org" Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms030107040206040208030507" X-Virus-Scanned: ClamAV using ClamSMTP Subject: [IPFIX] IPFIX-MIB: ipfixTransportSessionDeviceMode <-> ipfixTransportSessionMode 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, 23 Mar 2009 10:16:42 -0000 This is a cryptographically signed message in MIME format. --------------ms030107040206040208030507 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi Thomas, Sorry, if this one was already reported: ipfixTransportSessionDeviceMode <-> ipfixTransportSessionMode Choose one and replace the other in the text. Regards, Gerhard --=20 Dipl.-Ing. Gerhard M=FCnz Chair for Network Architectures and Services (I8) Department of Informatics Technische Universit=E4t M=FCnchen Boltzmannstr. 3, 85748 Garching bei M=FCnchen, Germany Phone: +49 89 289-18008 Fax: +49 89 289-18033 E-mail: muenz@net.in.tum.de WWW: http://www.net.in.tum.de/~muenz --------------ms030107040206040208030507 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 SIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMDkwMzIzMTAxNzI4WjAjBgkqhkiG9w0BCQQxFgQU 7tgsIyJAYf11Hnze2n3PDyGBug4wUgYJKoZIhvcNAQkPMUUwQzAKBggqhkiG9w0DBzAOBggq hkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwICASgwgYUG CSsGAQQBgjcQBDF4MHYwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0 aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1 aW5nIENBAhAqxerdN2XVRkUZsuk5IKdPMIGHBgsqhkiG9w0BCRACCzF4oHYwYjELMAkGA1UE BhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMT I1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBAhAqxerdN2XVRkUZsuk5IKdP MA0GCSqGSIb3DQEBAQUABIIBADUMczzdIUKIVIDgIzUbhPYNiHmXCkp1g7wuz5aTSpREY/nw mVpopC7eQxMCohn/gv8Vj9ERZDxUKIArQZ7SVPHZkX2PP44P9mMK46lng64KI7BpdX/flrw4 Z6qZHGT9O3TwPsGUCSsSw0dc78jo7ljB8o6onsPmU7WZ/NWkVWvgxkpj10SoX9SBLZPcF6oF ruyS15r8noc7WPIOc5wsWPhGHToUJYTdZkNu+QQqoOFXNzLBrECuxCP3ZUY6NxLv8BfsmRg/ V24+EL8wG7F9umizOHpcHcbn9yDpSRh8Rzj+5ujYJPTH1v24V7mSe/9zON0FPFsxDpqfrheB iyyGtQUAAAAAAAA= --------------ms030107040206040208030507-- From muenz@net.in.tum.de Mon Mar 23 03:23:25 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 C889A3A692A for ; Mon, 23 Mar 2009 03:23:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.11 X-Spam-Level: X-Spam-Status: No, score=-2.11 tagged_above=-999 required=5 tests=[AWL=0.139, 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 uxf33wtYERvx for ; Mon, 23 Mar 2009 03:23:25 -0700 (PDT) Received: from mail-out1.informatik.tu-muenchen.de (maildmz1.informatik.tu-muenchen.de [131.159.0.3]) by core3.amsl.com (Postfix) with ESMTP id B8D1A3A6827 for ; Mon, 23 Mar 2009 03:23:24 -0700 (PDT) Received: from phoenix.net.informatik.tu-muenchen.de (phoenix.net.informatik.tu-muenchen.de [131.159.14.1]) by services.net.informatik.tu-muenchen.de (Postix Mailer @ mail) with ESMTP id DF5FA47F33; Mon, 23 Mar 2009 11:24:04 +0100 (CET) Received: from [131.159.20.108] (repulse.net.informatik.tu-muenchen.de [131.159.20.108]) by phoenix.net.informatik.tu-muenchen.de (Postfix) with ESMTP id BFCF52A7F; Mon, 23 Mar 2009 11:24:04 +0100 (CET) Message-ID: <49C76346.3020401@net.in.tum.de> Date: Mon, 23 Mar 2009 11:24:06 +0100 From: Gerhard Muenz User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: Thomas Dietz References: <49C72F0A.9090305@lab.ntt.co.jp> <547F018265F92642B577B986577D671C785BB0@VENUS.office> In-Reply-To: <547F018265F92642B577B986577D671C785BB0@VENUS.office> Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms070605090909080209050605" X-Virus-Scanned: ClamAV using ClamSMTP Cc: ipfix@ietf.org Subject: Re: [IPFIX] about Collecting Process MIB objects X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Mar 2009 10:23:25 -0000 This is a cryptographically signed message in MIME format. --------------ms070605090909080209050605 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi Hitoshi, =46rom an architectural point of view, a File Writer is an Exporting Process. So, ipfixTransportSessionStatsTable is the right place to count the number of records, messages etc. written to the file. ipfixTransportSessionDeviceMode would be set to "exporting". The problem is that IPFIX-FILE is not considered by the MIB. You would need to extend the Transport Session Table such that a file can be specified as export destination. I do not think that we want to delay IPFIX-MIB any further. However, we can adapt IPFIX-CONF to allow monitoring the statistics you are proposing via Netconf. Regards, Gerhard Thomas Dietz wrote: > Dear Hitoshi, >=20 > since we don't have any reference to the collecting process in the MIB = and > we just agreed to remove even the Metering Process ID (see previous mai= l on > the list) I don't see any chance to include such objects. Sorry to say = so. >=20 > Best Regards, >=20 > Thomas >=20 >> Dear IPFIX-MIB authors and all, >>=20 >> I'd like to propose to add MIB objects about collecting process, if yo= u agree and if you can. (I am sorry for my very late opinion, I hit on th= is recently.) >>=20 >> Collected information will be passed to another process (e.g., File Wr= iter, Metering Process in Mediators and/or any applications for analyzing= and/or displaying graphical view in Collectors) from collecting process = generally, I think. >>=20 >> If the number of processed packets, bytes, and messages in Collecting = Process (which I call them as ipfixCollectingProcessProcessedPackets/Byte= s/Messages in this mail temporarily) can be got, I think these objects ar= e useful to detect failure in Collectors (or Mediators) by comparing ipfi= xTransportSessionPackets/Bytes/Messages and these objects. Therefore I'd = like to add ipfixCollectingProcessProcessedPackets/Bytes/Messages. >>=20 >> An example situation: If a Collector's disk is full filled and File Wr= iter will fail in writing, ipfixTransportSessionPackets/Bytes/Messages wi= ll be increased but ipfixCollectingProcessProcessedPackets/Bytes/Messages= will not be increased when a Collecting Process receives new IPFIX Messa= ge. >>=20 >> regards, >> Hitoshi IRINO --=20 Dipl.-Ing. Gerhard M=FCnz Chair for Network Architectures and Services (I8) Department of Informatics Technische Universit=E4t M=FCnchen Boltzmannstr. 3, 85748 Garching bei M=FCnchen, Germany Phone: +49 89 289-18008 Fax: +49 89 289-18033 E-mail: muenz@net.in.tum.de WWW: http://www.net.in.tum.de/~muenz --------------ms070605090909080209050605 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 SIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMDkwMzIzMTAyNDA2WjAjBgkqhkiG9w0BCQQxFgQU kwPIbXPZUw82ZnaS9U5W5nCQ0WEwUgYJKoZIhvcNAQkPMUUwQzAKBggqhkiG9w0DBzAOBggq hkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwICASgwgYUG CSsGAQQBgjcQBDF4MHYwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0 aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1 aW5nIENBAhAqxerdN2XVRkUZsuk5IKdPMIGHBgsqhkiG9w0BCRACCzF4oHYwYjELMAkGA1UE BhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMT I1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBAhAqxerdN2XVRkUZsuk5IKdP MA0GCSqGSIb3DQEBAQUABIIBAFdH6kr0UkWjq9HPd/xZtjVvqpZv8ag6jaTKn30LdcmV6CVd vmm+OnxyDNaEPqZ62BJNJG/ccSMiEQlHB3B1fHUuupKDSprbyCUL6QaBfD5dsiBkCHd2FjGS nq7SIzcWn9lVox57xbTO2gBGMcQAXXyiXzJPIsX4MATZRuONS6eof/WqckpfXf1Duo5uM15B D0YwS+z72acj/WwGtPY6wjc2dBL4TjeXBBQgg6r9my3xSdT85PP+WWEDnvjZyB2vXIAgyV7M 2RfVeGMCtBK2KmpmslZFBvEgev5XfAytjK8Wixv+Jfvp6xLrmYjkPs2B8YDqbDAH0c/T36xy 8vMEmkcAAAAAAAA= --------------ms070605090909080209050605-- From akoba@nttv6.net Mon Mar 23 04:31: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 B49773A6B05 for ; Mon, 23 Mar 2009 04:31:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.595 X-Spam-Level: X-Spam-Status: No, score=0.595 tagged_above=-999 required=5 tests=[AWL=-1.515, BAYES_00=-2.599, HELO_EQ_LOCALHOST=0.457, HELO_LOCALHOST=3.941, HOST_MISMATCH_NET=0.311] 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 LPsJVy8g9F1a for ; Mon, 23 Mar 2009 04:31:06 -0700 (PDT) Received: from mail.nttv6.net (mail.nttv6.net [IPv6:2001:fa8::25]) by core3.amsl.com (Postfix) with ESMTP id 217263A6AD3 for ; Mon, 23 Mar 2009 04:31:05 -0700 (PDT) Received: from localhost (mail.nttv6.net [192.16.178.5]) by mail.nttv6.net (8.14.3/8.14.3) with ESMTP id n2NBVkYn074288 for ; Mon, 23 Mar 2009 20:31:47 +0900 (JST) (envelope-from akoba@nttv6.net) Date: Mon, 23 Mar 2009 20:31:48 +0900 From: Atsushi Kobayashi To: ipfix@ietf.org Message-Id: <20090323201533.B669.17391CF2@nttv6.net> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Becky! ver. 2.46 [ja] X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.0.1 (mail.nttv6.net [192.16.178.5]); Mon, 23 Mar 2009 20:31:47 +0900 (JST) Subject: [IPFIX] Repeating mediation terminologies 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, 23 Mar 2009 11:31:14 -0000 Dear all, In IPFIX terminologies related to RFC5101, we decided the same terminologies should not be repeated in Mediation drafts. What do you think about IPFIX Mediation terminologies defined in Mediation problem statement draft? Should Mediation framework draft repeat them again, or not? IMHO, first reader would have a look at framework draft, not problem statement draft. Therefore, I think it is better that framework draft repeats them. Regards, Atsushi KOBAYASHI -- Atsushi Kobayashi From muenz@net.in.tum.de Mon Mar 23 05:57:11 2009 Return-Path: X-Original-To: ipfix@core3.amsl.com Delivered-To: ipfix@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 428793A69D7 for ; Mon, 23 Mar 2009 05:57:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.117 X-Spam-Level: X-Spam-Status: No, score=-2.117 tagged_above=-999 required=5 tests=[AWL=0.132, 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 j73QymjFeqCC for ; Mon, 23 Mar 2009 05:57:10 -0700 (PDT) Received: from mail-out2.informatik.tu-muenchen.de (maildmz2.informatik.tu-muenchen.de [131.159.0.15]) by core3.amsl.com (Postfix) with ESMTP id EFDD83A6B03 for ; Mon, 23 Mar 2009 05:57:08 -0700 (PDT) Received: from phoenix.net.informatik.tu-muenchen.de (phoenix.net.informatik.tu-muenchen.de [131.159.14.1]) by services.net.informatik.tu-muenchen.de (Postix Mailer @ mail) with ESMTP id 9B2F847DFE; Mon, 23 Mar 2009 13:57:57 +0100 (CET) Received: from [131.159.20.108] (repulse.net.informatik.tu-muenchen.de [131.159.20.108]) by phoenix.net.informatik.tu-muenchen.de (Postfix) with ESMTP id 8BCCF2766; Mon, 23 Mar 2009 13:57:57 +0100 (CET) Message-ID: <49C78756.3030204@net.in.tum.de> Date: Mon, 23 Mar 2009 13:57:58 +0100 From: Gerhard Muenz User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: Benoit Claise References: <49AE3881.3050909@cisco.com> In-Reply-To: <49AE3881.3050909@cisco.com> Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms090201070506000706070606" X-Virus-Scanned: ClamAV using ClamSMTP Cc: "ipfix@ietf.org" Subject: Re: [IPFIX] [Fwd: I-D ACTION:draft-claise-structured-data-in-ipfix-00.txt] X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Mar 2009 12:57:11 -0000 This is a cryptographically signed message in MIME format. --------------ms090201070506000706070606 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi Benoit, Gowri, Stan, Paul, I like your approach of structured data types. Such types, especially the list type, are urgently needed in the context of PSAMP! Interestingly, you do not mention these applications in the draft. So, I'll briefly sketch them: 1) PSAMP Selection Sequence Report Interpretation ------------------------------------------------- Here, RFC5476 explicitly mentions the need for list types: Scope: selectionSequenceId Non-Scope: one Information Element mapping the Observation Point selectorId (one or more) An Information Element representing the Observation Point would typically be taken from the ingressInterface, egressInterface, lineCardId, exporterIPv4Address, or exporterIPv6Address Information Elements (specified in [RFC5102]), but is not limited to those: any Information Element specified in [RFC5102] or [RFC5477] can potentially be used. In case of more complex Observation Points (such as a list of interfaces, a bus, etc.), a new Information ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ Element describing the new type of Observation Point must be specified, along with an Options Template Record describing it in more detail (if necessary). In fact, this is the business case that you pretend not to see for Options Templates in 5.2 of your draft ;) 2) PSAMP Property Match Filtering --------------------------------- =46rom RFC75476: When multiple different Information Elements are defined, the filter acts as a logical AND. Note that the logical OR is not covered by these PSAMP specifications. In practice, a logical OR is urgently needed. See my recent discussion with Andrew on the ML: http://www.ietf.org/mail-archive/web/ipfix/current/msg04802.html In draft-sommer-ipfix-mediator-ext-01, we proposed ADTs orderedList, orderedPair, and portRanges which allow the definition new IEs for port ranges etc. Your proposal is more generic as it does not require the specification of a new IE for every purpose where a list is needed. The OR-semantic of a filter could be solved with a new Information Element anyList which is derived from the ADT basicList. In contrast to IE basicList, anyList introduces the semantic that exactly one of the reported values was observed. As a consequence, we can export an anyList of port numbers in Property Match Filtering in order to describe a filter that selects packets given a list of port numbers. I would appreciate if the above issues were addressed in a future version of your draft! Further comments: > 3.1. IPFIX Limitations=20 > ... > To export this information in IPFIX, the data would need to be=20 > flattened (thus losing the hierarchical relationships) and a new = > IPFIX Template created for each alert, according to the number of= =20 > applicationID elements in each target, the number of targets and = > attackers in each participant and the number of participants in=20 > each alert. Clearly each Template will be unique to each alert, = > and a large amount of CPU, memory and export bandwith will be=20 bandwidth > wasted creating, exporting, maintaining, and withdrawing the=20 > Templates. =20 > 4.4.1. basicList=20 > ... > BasicList Content > =20 > A Collection Process decodes list elements from the BasicList= =20 > Content until no further data remains. A record count is not= =20 > included but can be derived when the Information Element is=20 > decoded.=20 Replace record count by field count? > 5.2. Structured Data Information Elements Applicability in Options= =20 > Template Sets=20 >=20 > All the examples in this document uses the Structured Data=20 use > Information Elements, abstract data types, and data type semantic= =20 > in Template Sets. However, they could also be used in and Option= s=20 remove "and" > Template Sets.=20 > 8.1. Encoding BasicList=20 >=20 > Consider encoding an user_record containing the following data:=20 a user_record Regards, Gerhard Benoit Claise wrote: > Dear all, >=20 > Here is a new IPFIX draft. > I think that the abstract is quite clear about its goal. >=20 > Regards, Benoit. >=20 > -------- Original Message -------- > Subject: I-D ACTION:draft-claise-structured-data-in-ipfix-00.txt > Date: Tue, 3 Mar 2009 15:15:01 -0800 (PST) > From: Internet-Drafts@ietf.org > Reply-To: internet-drafts@ietf.org > To: i-d-announce@ietf.org >=20 >=20 >=20 > A New Internet-Draft is available from the on-line Internet-Drafts=20 > directories. >=20 >=20 > Title : Export of Structured Data in IPFIX > Author(s) : B. Claise, G. Dhandapani, S. Yates, P. Aitken > Filename : draft-claise-structured-data-in-ipfix-00.txt > Pages : 36 > Date : 2009-3-3 > =09 > This document specifies an extension to IP Flow Information=20 > eXport (IPFIX) protocol specification in [RFC5101] and the IPFI= X=20 > information model specified in [RFC5102] to support hierarchica= l=20 > structured data and lists (sequences) of Information Elements i= n=20 > data records. This extension allows definition of complex data= =20 > structures such as variable-length lists and specification of=20 > hierarchical containment relationships between Templates.=20 >=20 > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-claise-structured-data-in-ipf= ix-00.txt >=20 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ >=20 > Below is the data which will enable a MIME compliant mail reader > implementation to automatically retrieve the ASCII version of the > Internet-Draft. >=20 >=20 >=20 > -----------------------------------------------------------------------= - >=20 > _______________________________________________ > IPFIX mailing list > IPFIX@ietf.org > https://www.ietf.org/mailman/listinfo/ipfix --=20 Dipl.-Ing. Gerhard M=FCnz Chair for Network Architectures and Services (I8) Department of Informatics Technische Universit=E4t M=FCnchen Boltzmannstr. 3, 85748 Garching bei M=FCnchen, Germany Phone: +49 89 289-18008 Fax: +49 89 289-18033 E-mail: muenz@net.in.tum.de WWW: http://www.net.in.tum.de/~muenz --------------ms090201070506000706070606 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 SIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMDkwMzIzMTI1NzU4WjAjBgkqhkiG9w0BCQQxFgQU GhmZKVSuMmgOKZj7J64U2VJ0UCQwUgYJKoZIhvcNAQkPMUUwQzAKBggqhkiG9w0DBzAOBggq hkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwICASgwgYUG CSsGAQQBgjcQBDF4MHYwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0 aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1 aW5nIENBAhAqxerdN2XVRkUZsuk5IKdPMIGHBgsqhkiG9w0BCRACCzF4oHYwYjELMAkGA1UE BhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMT I1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBAhAqxerdN2XVRkUZsuk5IKdP MA0GCSqGSIb3DQEBAQUABIIBACWttGvcrHV5dqezBOFfXWG88eHlM995JiGWPpTbRWzMJXJH qXZGe005JelfYQmVoZpkbFzcr+Br/K0S/BLtPt3SbcO7Xru6QiMTSTQd0N4IaSy2AUDwIipB pAf7O4GxZ1H2FONzIKTYdG1W9HMMqx2UgCFIyiIJnOONTASjM+ICmhn6dm1SbS6qTktJ/UIq 8kV8xZebYiCR4q3zyyZbir4uYZipDDfdPvgfebz/sL1q//gKaX9p7MEiqD7nuMvkGajwKhdA O8dqElJI/cWK/jp+1aVF8NKYHuyy5rrekgfMij2xokYZE7NyirmF56al28LF0uqKDEnWQJwV KiNIy9UAAAAAAAA= --------------ms090201070506000706070606-- From akoba@nttv6.net Mon Mar 23 06:59: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 05A8B3A67D6 for ; Mon, 23 Mar 2009 06:59:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.199 X-Spam-Level: X-Spam-Status: No, score=0.199 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001, SUBJ_RE_NUM=2.799] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZM79QhPwvaU5 for ; Mon, 23 Mar 2009 06:59:13 -0700 (PDT) Received: from mail.nttv6.net (mail.nttv6.net [IPv6:2001:fa8::25]) by core3.amsl.com (Postfix) with ESMTP id 0A1303A69CD for ; Mon, 23 Mar 2009 06:59:11 -0700 (PDT) Received: from [192.47.163.152] ([IPv6:2001:fa8:1000:0:b962:a6c:5ffc:2e9b]) by mail.nttv6.net (8.14.3/8.14.3) with ESMTP id n2NDxM55074963; Mon, 23 Mar 2009 22:59:22 +0900 (JST) (envelope-from akoba@nttv6.net) Date: Mon, 23 Mar 2009 23:00:01 +0900 From: Atsushi Kobayashi To: Gerhard Muenz In-Reply-To: <49C78756.3030204@net.in.tum.de> References: <49AE3881.3050909@cisco.com> <49C78756.3030204@net.in.tum.de> Message-Id: <20090323223212.CE35.17391CF2@nttv6.net> MIME-Version: 1.0 Content-Type: text/plain; charset="ISO-2022-JP" Content-Transfer-Encoding: 7bit X-Mailer: Becky! ver. 2.48.02 [ja] X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.0.1 (mail.nttv6.net [IPv6:2001:fa8::25]); Mon, 23 Mar 2009 22:59:22 +0900 (JST) Cc: "ipfix@ietf.org" Subject: Re: [IPFIX] [Fwd: I-D ACTION:draft-claise-structured-data-in-ipfix-00.txt] X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Mar 2009 13:59:14 -0000 Dear Gerhard, Benoit, Gowri, Stan, Paul, Gerhard, good point. I hope logical OR. I think BasicList also allows to encode the egress interface indexes of multicast packets/flows, and the BGP communities of specific destination IP address. Even AS path can be encoded in a Flow Records. It can be considered more sophisticated way than traditional one. I hope that the examples about Flow Records in the draft are rich to be easy to understand. And also, in QoS performance measurement, Exporter or Mediator creates some metrics every 1 or 2 seconds, so they need to export data record every 1 or 2 seconds. BasicList allows to encode metrics list during some periods, such as 60 sec. It can reduce redundancy. Regards, Atsushi KOBAYASHI On Mon, 23 Mar 2009 13:57:58 +0100 Gerhard Muenz wrote: > > Hi Benoit, Gowri, Stan, Paul, > > I like your approach of structured data types. Such types, especially > the list type, are urgently needed in the context of PSAMP! > Interestingly, you do not mention these applications in the draft. So, > I'll briefly sketch them: > > 1) PSAMP Selection Sequence Report Interpretation > ------------------------------------------------- > > Here, RFC5476 explicitly mentions the need for list types: > > Scope: selectionSequenceId > Non-Scope: one Information Element mapping the Observation Point > selectorId (one or more) > > An Information Element representing the Observation Point would > typically be taken from the ingressInterface, egressInterface, > lineCardId, exporterIPv4Address, or exporterIPv6Address Information > Elements (specified in [RFC5102]), but is not limited to those: any > Information Element specified in [RFC5102] or [RFC5477] can > potentially be used. In case of more complex Observation Points > (such as a list of interfaces, a bus, etc.), a new Information > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > Element describing the new type of Observation Point must be > specified, along with an Options Template Record describing it in > more detail (if necessary). > > In fact, this is the business case that you pretend not to see for > Options Templates in 5.2 of your draft ;) > > > 2) PSAMP Property Match Filtering > --------------------------------- > > From RFC75476: > > When multiple different Information Elements are defined, the filter > acts as a logical AND. Note that the logical OR is not covered by > these PSAMP specifications. > > In practice, is urgently needed. See my recent discussion > with Andrew on the ML: > http://www.ietf.org/mail-archive/web/ipfix/current/msg04802.html > > In draft-sommer-ipfix-mediator-ext-01, we proposed ADTs orderedList, > orderedPair, and portRanges which allow the definition new IEs for port > ranges etc. Your proposal is more generic as it does not require the > specification of a new IE for every purpose where a list is needed. > > The OR-semantic of a filter could be solved with a new Information > Element anyList which is derived from the ADT basicList. In contrast to > IE basicList, anyList introduces the semantic that exactly one of the > reported values was observed. As a consequence, we can export an anyList > of port numbers in Property Match Filtering in order to describe a > filter that selects packets given a list of port numbers. > > > I would appreciate if the above issues were addressed in a future > version of your draft! > > > Further comments: > > > 3.1. IPFIX Limitations > > ... > > To export this information in IPFIX, the data would need to be > > flattened (thus losing the hierarchical relationships) and a new > > IPFIX Template created for each alert, according to the number of > > applicationID elements in each target, the number of targets and > > attackers in each participant and the number of participants in > > each alert. Clearly each Template will be unique to each alert, > > and a large amount of CPU, memory and export bandwith will be > > bandwidth > > > wasted creating, exporting, maintaining, and withdrawing the > > Templates. > > > 4.4.1. basicList > > ... > > BasicList Content > > > > A Collection Process decodes list elements from the BasicList > > Content until no further data remains. A record count is not > > included but can be derived when the Information Element is > > decoded. > > Replace record count by field count? > > > 5.2. Structured Data Information Elements Applicability in Options > > Template Sets > > > > All the examples in this document uses the Structured Data > > use > > > Information Elements, abstract data types, and data type semantic > > in Template Sets. However, they could also be used in and Options > > remove "and" > > > Template Sets. > > > > 8.1. Encoding BasicList > > > > Consider encoding an user_record containing the following data: > > a user_record > > > Regards, > Gerhard > > > Benoit Claise wrote: > > Dear all, > > > > Here is a new IPFIX draft. > > I think that the abstract is quite clear about its goal. > > > > Regards, Benoit. > > > > -------- Original Message -------- > > Subject: I-D ACTION:draft-claise-structured-data-in-ipfix-00.txt > > Date: Tue, 3 Mar 2009 15:15:01 -0800 (PST) > > From: Internet-Drafts@ietf.org > > Reply-To: internet-drafts@ietf.org > > To: i-d-announce@ietf.org > > > > > > > > A New Internet-Draft is available from the on-line Internet-Drafts > > directories. > > > > > > Title : Export of Structured Data in IPFIX > > Author(s) : B. Claise, G. Dhandapani, S. Yates, P. Aitken > > Filename : draft-claise-structured-data-in-ipfix-00.txt > > Pages : 36 > > Date : 2009-3-3 > > > > This document specifies an extension to IP Flow Information > > eXport (IPFIX) protocol specification in [RFC5101] and the IPFIX > > information model specified in [RFC5102] to support hierarchical > > structured data and lists (sequences) of Information Elements in > > data records. This extension allows definition of complex data > > structures such as variable-length lists and specification of > > hierarchical containment relationships between Templates. > > > > A URL for this Internet-Draft is: > > http://www.ietf.org/internet-drafts/draft-claise-structured-data-in-ipfix-00.txt > > > > Internet-Drafts are also available by anonymous FTP at: > > ftp://ftp.ietf.org/internet-drafts/ > > > > Below is the data which will enable a MIME compliant mail reader > > implementation to automatically retrieve the ASCII version of the > > Internet-Draft. > > > > > > > > ------------------------------------------------------------------------ > > > > _______________________________________________ > > IPFIX mailing list > > IPFIX@ietf.org > > https://www.ietf.org/mailman/listinfo/ipfix > > -- > Dipl.-Ing. Gerhard M$B".(Bz > Chair for Network Architectures and Services (I8) > Department of Informatics > Technische Universit$BgU(B M$B".(Bchen > Boltzmannstr. 3, 85748 Garching bei M$B".(Bchen, Germany > Phone: +49 89 289-18008 Fax: +49 89 289-18033 > E-mail: muenz@net.in.tum.de WWW: http://www.net.in.tum.de/~muenz > > --- Atsushi KOBAYASHI NTT Information Sharing Platform Lab. tel:+81-(0)422-59-3978 fax:+81-(0)422-59-5637 From Quittek@nw.neclab.eu Mon Mar 23 08:41:08 2009 Return-Path: X-Original-To: ipfix@core3.amsl.com Delivered-To: ipfix@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 067803A6B2A for ; Mon, 23 Mar 2009 08:41:08 -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=[AWL=0.000, 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 7qOFm327tImi for ; Mon, 23 Mar 2009 08:41:07 -0700 (PDT) Received: from smtp0.neclab.eu (smtp0.neclab.eu [195.37.70.41]) by core3.amsl.com (Postfix) with ESMTP id 1356B3A68CC for ; Mon, 23 Mar 2009 08:41:07 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp0.neclab.eu (Postfix) with ESMTP id B65872C01CA0C for ; Mon, 23 Mar 2009 16:41:56 +0100 (CET) X-Virus-Scanned: Amavisd on Debian GNU/Linux (atlas2.office) Received: from smtp0.neclab.eu ([127.0.0.1]) by localhost (atlas2.office [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Dm5RmjDZwzZB for ; Mon, 23 Mar 2009 16:41:56 +0100 (CET) Received: from VENUS.office (mx2.office [192.168.24.15]) by smtp0.neclab.eu (Postfix) with ESMTP id 81B6B2C01C9AB for ; Mon, 23 Mar 2009 16:41:51 +0100 (CET) X-MimeOLE: Produced By Microsoft Exchange V6.5 Received: from 10.7.0.54 ([10.7.0.54]) by VENUS.office ([192.168.24.102]) with Microsoft Exchange Server HTTP-DAV ; Mon, 23 Mar 2009 15:41:51 +0000 MIME-Version: 1.0 Content-Type: multipart/signed; micalg=sha1; boundary="B_3320642518_5314214"; protocol="application/pkcs7-signature" Content-class: urn:content-classes:message Date: Mon, 23 Mar 2009 16:41:58 +0100 Message-ID: X-MS-Has-Attach: yes X-MS-TNEF-Correlator: Thread-Topic: Presentations for our session today thread-index: AcmrzeZ3wD+4fqfPJUe5M+dO4Zijiw== From: "Juergen Quittek" To: "IETF IPFIX Working Group" Subject: [IPFIX] Presentations for our session today 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, 23 Mar 2009 15:41:08 -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_3320642518_5314214 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Dear presenters at the IPFIX session today, If you have not already done so, please send me your slides until lunch time. Thank you, Juergen --B_3320642518_5314214 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 YWIuZXUCBA0uKwcwCQYFKw4DAhoFAKBdMCMGCSqGSIb3DQEJBDEWBBTdMw0umLX9rTclahqh VjcNiC705zAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0wOTAz MjMxNTQxNThaMA0GCSqGSIb3DQEBAQUABIIBAJT9H6IqOO5W9oqEkOifNrwAwX+r9DJ/BTNQ NEuDzxU5RHtmLyOCD7VH/+9vCQoDlJh1zHAXBy82TX2+PlK2fTj5oOVZHSy1BV1LkW1F+De3 uTa7xHUnzvoZTvbzfpos+sDyVleSWZsBVpPocthcYyYw9IEhdg9r3ZRQCsp4tOAstJD9iMfM P0o9eSptp3Teau/yfw9IUAQmzXfw5ie5BiyJyCLJJCwUaeEL9GzDhpM8HexzVujm+2RfMSrV XQosThImB8mtwFdtoGoo4pDEErpxn/DTCABQzPlzuGVWoEIKQmQ+CfYAao6eR+kdjqpW2OLM xT2fHPsEHzMF7GctLEU= --B_3320642518_5314214-- From acmorton@att.com Mon Mar 23 15:51:13 2009 Return-Path: X-Original-To: ipfix@core3.amsl.com Delivered-To: ipfix@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0D2C43A6ACB for ; Mon, 23 Mar 2009 15:51:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.586 X-Spam-Level: X-Spam-Status: No, score=-105.586 tagged_above=-999 required=5 tests=[AWL=0.210, BAYES_00=-2.599, MSGID_FROM_MTA_HEADER=0.803, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CDQLnr3cfQ23 for ; Mon, 23 Mar 2009 15:51:11 -0700 (PDT) Received: from mail146.messagelabs.com (mail146.messagelabs.com [216.82.241.147]) by core3.amsl.com (Postfix) with ESMTP id 15D463A698D for ; Mon, 23 Mar 2009 15:51:11 -0700 (PDT) X-VirusChecked: Checked X-Env-Sender: acmorton@att.com X-Msg-Ref: server-2.tower-146.messagelabs.com!1237848721!11327925!1 X-StarScan-Version: 6.0.0; banners=-,-,- X-Originating-IP: [144.160.128.141] Received: (qmail 10737 invoked from network); 23 Mar 2009 22:52:02 -0000 Received: from sbcsmtp9.sbc.com (HELO flph161.enaf.ffdc.sbc.com) (144.160.128.141) by server-2.tower-146.messagelabs.com with AES256-SHA encrypted SMTP; 23 Mar 2009 22:52:02 -0000 Received: from enaf.ffdc.sbc.com (localhost.localdomain [127.0.0.1]) by flph161.enaf.ffdc.sbc.com (8.14.3/8.14.3) with ESMTP id n2NMpxLf018755 for ; Mon, 23 Mar 2009 15:51:59 -0700 Received: from klph001.kcdc.att.com (klph001.kcdc.att.com [135.188.3.11]) by flph161.enaf.ffdc.sbc.com (8.14.3/8.14.3) with ESMTP id n2NMpt6a018721 for ; Mon, 23 Mar 2009 15:51:55 -0700 Received: from kcdc.att.com (localhost.localdomain [127.0.0.1]) by klph001.kcdc.att.com (8.14.0/8.14.0) with ESMTP id n2NMptqB008897 for ; Mon, 23 Mar 2009 17:51:55 -0500 Received: from maillennium.att.com (mailgw1.maillennium.att.com [135.25.114.99]) by klph001.kcdc.att.com (8.14.0/8.14.0) with ESMTP id n2NMprce008883 for ; Mon, 23 Mar 2009 17:51:54 -0500 Message-Id: <200903232251.n2NMprce008883@klph001.kcdc.att.com> Received: from acmt.att.com (vpn-135-70-98-98.vpn.swst.att.com[135.70.98.98](misconfigured sender)) by maillennium.att.com (mailgw1) with SMTP id <20090323225139gw1000u6dje>; Mon, 23 Mar 2009 22:51:53 +0000 X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Mon, 23 Mar 2009 18:51:38 -0400 To: ipfix@ietf.org From: Al Morton Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Mailman-Approved-At: Mon, 23 Mar 2009 16:03:56 -0700 Subject: [IPFIX] Link to IPFIX Benchmarking Draft 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, 23 Mar 2009 22:51:13 -0000 As requested: http://tools.ietf.org/html/draft-novak-bmwg-ipflow-meth-02 BMWG will discuss this in the 1400-1500 hour on Thursday in Franciscan A. Please give this a look and tell BMWG if this draft meets the needs of people in the IPFIX community. thanks, Al bmwg chair From irino.hitoshi@lab.ntt.co.jp Mon Mar 23 23:36:48 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 86BF228C1A9 for ; Mon, 23 Mar 2009 23:36:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.21 X-Spam-Level: * X-Spam-Status: No, score=1.21 tagged_above=-999 required=5 tests=[AWL=1.300, BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ng3HKZSoKNQZ for ; Mon, 23 Mar 2009 23:36:47 -0700 (PDT) Received: from tama500.ecl.ntt.co.jp (tama500.ecl.ntt.co.jp [129.60.39.148]) by core3.amsl.com (Postfix) with ESMTP id 9991028C15F for ; Mon, 23 Mar 2009 23:36:47 -0700 (PDT) Received: from mfs5.rdh.ecl.ntt.co.jp (mfs5.rdh.ecl.ntt.co.jp [129.60.39.144]) by tama500.ecl.ntt.co.jp (8.14.2/8.14.2) with ESMTP id n2O6bbeU022185; Tue, 24 Mar 2009 15:37:37 +0900 (JST) Received: from mfs5.rdh.ecl.ntt.co.jp (localhost [127.0.0.1]) by mfs5.rdh.ecl.ntt.co.jp (Postfix) with ESMTP id BCB296B79; Tue, 24 Mar 2009 15:37:37 +0900 (JST) Received: from imm.m.ecl.ntt.co.jp (imm0.m.ecl.ntt.co.jp [129.60.5.151]) by mfs5.rdh.ecl.ntt.co.jp (Postfix) with ESMTP id 9A42A6AA5; Tue, 24 Mar 2009 15:37:37 +0900 (JST) Received: from [127.0.0.1] ([129.60.80.56]) by imm.m.ecl.ntt.co.jp (8.13.8/8.13.8) with ESMTP id n2O6bTjh007387; Tue, 24 Mar 2009 15:37:37 +0900 (JST) Message-ID: <49C87FC4.8020702@lab.ntt.co.jp> Date: Tue, 24 Mar 2009 15:37:56 +0900 From: Hitoshi Irino Organization: NTT User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: Gerhard Muenz References: <49C72F0A.9090305@lab.ntt.co.jp> <547F018265F92642B577B986577D671C785BB0@VENUS.office> <49C76346.3020401@net.in.tum.de> In-Reply-To: <49C76346.3020401@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] about Collecting Process MIB objects X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Mar 2009 06:36:48 -0000 Hello Thomas, Gerhard, Thank you for reply. Thomas, >> I don't see any chance to include such objects. Sorry to say so. O.K. I understand. Gerhard, > However, we > can adapt IPFIX-CONF to allow monitoring the statistics you are > proposing via Netconf. Your comment means that it is able to get statistical IPFIX-CONF Data Model (e.g., rate, packets, bytes, messages, etc in Transport Session Class) by using "get-config" method of Netconf. Is it right? Best regards, Hitoshi IRINO (2009/03/23 19:24), Gerhard Muenz wrote: > Hi Hitoshi, > > From an architectural point of view, a File Writer is an Exporting > Process. So, ipfixTransportSessionStatsTable is the right place to count > the number of records, messages etc. written to the file. > ipfixTransportSessionDeviceMode would be set to "exporting". > > The problem is that IPFIX-FILE is not considered by the MIB. You would > need to extend the Transport Session Table such that a file can be > specified as export destination. > > I do not think that we want to delay IPFIX-MIB any further. However, we > can adapt IPFIX-CONF to allow monitoring the statistics you are > proposing via Netconf. > > Regards, > Gerhard > > > Thomas Dietz wrote: >> Dear Hitoshi, >> >> since we don't have any reference to the collecting process in the MIB and >> we just agreed to remove even the Metering Process ID (see previous mail on >> the list) I don't see any chance to include such objects. Sorry to say so. >> >> Best Regards, >> >> Thomas >> > >>> Dear IPFIX-MIB authors and all, >>> >>> I'd like to propose to add MIB objects about collecting process, if you agree and if you can. (I am sorry for my very late opinion, I hit on this recently.) >>> >>> Collected information will be passed to another process (e.g., File Writer, Metering Process in Mediators and/or any applications for analyzing and/or displaying graphical view in Collectors) from collecting process generally, I think. >>> >>> If the number of processed packets, bytes, and messages in Collecting Process (which I call them as ipfixCollectingProcessProcessedPackets/Bytes/Messages in this mail temporarily) can be got, I think these objects are useful to detect failure in Collectors (or Mediators) by comparing ipfixTransportSessionPackets/Bytes/Messages and these objects. Therefore I'd like to add ipfixCollectingProcessProcessedPackets/Bytes/Messages. >>> >>> An example situation: If a Collector's disk is full filled and File Writer will fail in writing, ipfixTransportSessionPackets/Bytes/Messages will be increased but ipfixCollectingProcessProcessedPackets/Bytes/Messages will not be increased when a Collecting Process receives new IPFIX Message. >>> >>> regards, >>> Hitoshi IRINO > > -- Hitoshi Irino NTT Network Service Systems Laboratories 9-11 Midori-cho 3-Chome, Musashino-shi, Tokyo 180-8585 Japan Tel: +81-422-59-4403 Fax: +81-422-59-4549 From muenz@net.in.tum.de Tue Mar 24 01:44: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 07B633A6B03 for ; Tue, 24 Mar 2009 01:44:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.138 X-Spam-Level: X-Spam-Status: No, score=-2.138 tagged_above=-999 required=5 tests=[AWL=0.111, 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 gLguugwfO+vU for ; Tue, 24 Mar 2009 01:44:41 -0700 (PDT) Received: from mail-out1.informatik.tu-muenchen.de (maildmz1.informatik.tu-muenchen.de [131.159.0.3]) by core3.amsl.com (Postfix) with ESMTP id 9C4333A6A29 for ; Tue, 24 Mar 2009 01:44:40 -0700 (PDT) Received: from phoenix.net.informatik.tu-muenchen.de (phoenix.net.informatik.tu-muenchen.de [131.159.14.1]) by services.net.informatik.tu-muenchen.de (Postix Mailer @ mail) with ESMTP id 46CFB47BD3; Tue, 24 Mar 2009 09:45:07 +0100 (CET) Received: from [131.159.20.108] (repulse.net.informatik.tu-muenchen.de [131.159.20.108]) by phoenix.net.informatik.tu-muenchen.de (Postfix) with ESMTP id 334C64845; Tue, 24 Mar 2009 09:45:07 +0100 (CET) Message-ID: <49C89D94.40407@net.in.tum.de> Date: Tue, 24 Mar 2009 09:45:08 +0100 From: Gerhard Muenz User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: Hitoshi Irino References: <49C72F0A.9090305@lab.ntt.co.jp> <547F018265F92642B577B986577D671C785BB0@VENUS.office> <49C76346.3020401@net.in.tum.de> <49C87FC4.8020702@lab.ntt.co.jp> In-Reply-To: <49C87FC4.8020702@lab.ntt.co.jp> Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms020603020906040200060709" X-Virus-Scanned: ClamAV using ClamSMTP Cc: ipfix@ietf.org Subject: Re: [IPFIX] about Collecting Process MIB objects X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Mar 2009 08:44:42 -0000 This is a cryptographically signed message in MIME format. --------------ms020603020906040200060709 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi, Hitoshi Irino wrote: >> However, we >> can adapt IPFIX-CONF to allow monitoring the statistics you are >> proposing via Netconf. >=20 > Your comment means that it is able to get statistical IPFIX-CONF Data > Model (e.g., rate, packets, bytes, messages, etc in Transport Session > Class) by using "get-config" method of Netconf. Is it right? Yes and no. Yes, because IPFIX-CONF already includes all IPFIX-MIB parameters. My proposal is to extend to model such that the Transport Session state parameters may also describe Transport Sessions from/to an IPFIX File. No, because Netconf retrieves configuration data only. You have to use instead. Regards, Gerhard >=20 > Best regards, > Hitoshi IRINO >=20 > (2009/03/23 19:24), Gerhard Muenz wrote: >> Hi Hitoshi, >> >> From an architectural point of view, a File Writer is an Exporting >> Process. So, ipfixTransportSessionStatsTable is the right place to cou= nt >> the number of records, messages etc. written to the file. >> ipfixTransportSessionDeviceMode would be set to "exporting". >> >> The problem is that IPFIX-FILE is not considered by the MIB. You would= >> need to extend the Transport Session Table such that a file can be >> specified as export destination. >> >> I do not think that we want to delay IPFIX-MIB any further. However, w= e >> can adapt IPFIX-CONF to allow monitoring the statistics you are >> proposing via Netconf. >> >> Regards, >> Gerhard >> >> >> Thomas Dietz wrote: >>> Dear Hitoshi, >>> >>> since we don't have any reference to the collecting process in the >>> MIB and >>> we just agreed to remove even the Metering Process ID (see previous >>> mail on >>> the list) I don't see any chance to include such objects. Sorry to >>> say so. >>> >>> Best Regards, >>> >>> Thomas >>> >> >>>> Dear IPFIX-MIB authors and all, >>>> >>>> I'd like to propose to add MIB objects about collecting process, if >>>> you agree and if you can. (I am sorry for my very late opinion, I >>>> hit on this recently.) >>>> >>>> Collected information will be passed to another process (e.g., File >>>> Writer, Metering Process in Mediators and/or any applications for >>>> analyzing and/or displaying graphical view in Collectors) from >>>> collecting process generally, I think. >>>> >>>> If the number of processed packets, bytes, and messages in >>>> Collecting Process (which I call them as >>>> ipfixCollectingProcessProcessedPackets/Bytes/Messages in this mail >>>> temporarily) can be got, I think these objects are useful to detect >>>> failure in Collectors (or Mediators) by comparing >>>> ipfixTransportSessionPackets/Bytes/Messages and these objects. >>>> Therefore I'd like to add >>>> ipfixCollectingProcessProcessedPackets/Bytes/Messages. >>>> >>>> An example situation: If a Collector's disk is full filled and File >>>> Writer will fail in writing, >>>> ipfixTransportSessionPackets/Bytes/Messages will be increased but >>>> ipfixCollectingProcessProcessedPackets/Bytes/Messages will not be >>>> increased when a Collecting Process receives new IPFIX Message. >>>> >>>> regards, >>>> Hitoshi IRINO >> >> >=20 >=20 --=20 Dipl.-Ing. Gerhard M=FCnz Chair for Network Architectures and Services (I8) Department of Informatics Technische Universit=E4t M=FCnchen Boltzmannstr. 3, 85748 Garching bei M=FCnchen, Germany Phone: +49 89 289-18008 Fax: +49 89 289-18033 E-mail: muenz@net.in.tum.de WWW: http://www.net.in.tum.de/~muenz --------------ms020603020906040200060709 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 SIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMDkwMzI0MDg0NTA4WjAjBgkqhkiG9w0BCQQxFgQU FypeBqP3tBTbT09PAw2rtiwMw4QwUgYJKoZIhvcNAQkPMUUwQzAKBggqhkiG9w0DBzAOBggq hkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwICASgwgYUG CSsGAQQBgjcQBDF4MHYwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0 aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1 aW5nIENBAhAqxerdN2XVRkUZsuk5IKdPMIGHBgsqhkiG9w0BCRACCzF4oHYwYjELMAkGA1UE BhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMT I1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBAhAqxerdN2XVRkUZsuk5IKdP MA0GCSqGSIb3DQEBAQUABIIBAKiR6IlIwPC3tCXGTNs4hLETgLr4SDQu5KUJESFNq2bRY/Cp gd7VRyga6BRO8Fxzw7MhoMdPp82Bj53guY0eqZdgiK2xDN/BPljynN92AeIraWuIsEnkHuHG 4iYYCnWd50ua7RAVUqiSRoqotFkpJi3IcqEdalcT1wUWtcTGkxMkFSd7KqUoE1wBpcxzE1j+ eXNDAtCHdhtbSXO/JIb3R9y+RwXx24KpGRfrU+GkuRe4BVsEQ3BmEgJ25yFAR7Qq089NZlOr DJc2ZF7hZrRMTTyZ5MIMlebWWZTBcc6VjSn4HnChp9nZidyDV0KO6ZAYzmmaPadICvrpOdnc wcisGxIAAAAAAAA= --------------ms020603020906040200060709-- From web-usrn@ISI.EDU Tue Mar 24 09:43:46 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 1F3813A6D3F for ; Tue, 24 Mar 2009 09:43:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.217 X-Spam-Level: X-Spam-Status: No, score=-17.217 tagged_above=-999 required=5 tests=[AWL=0.382, 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 M4W5gNy-RED7 for ; Tue, 24 Mar 2009 09:43:45 -0700 (PDT) Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) by core3.amsl.com (Postfix) with ESMTP id EAEA03A6CC2 for ; Tue, 24 Mar 2009 09:43:44 -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 n2OGgsIK014558 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 24 Mar 2009 09:42:55 -0700 (PDT) Received: (from web-usrn@localhost) by boreas.isi.edu (8.13.8/8.13.8/Submit) id n2OGgpT2014527; Tue, 24 Mar 2009 09:42:51 -0700 (PDT) Date: Tue, 24 Mar 2009 09:42:51 -0700 (PDT) Message-Id: <200903241642.n2OGgpT2014527@boreas.isi.edu> To: quittek@netlab.nec.de, stbryant@cisco.com, bclaise@cisco.com, paitken@cisco.com, jemeyer@paypal.com, dromasca@avaya.com, rbonica@juniper.net, n.brownlee@auckland.ac.nz, quittek@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: ipfix@ietf.org, rfc-editor@rfc-editor.org Subject: [IPFIX] [Technical Errata Reported] RFC5102 (1736) 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, 24 Mar 2009 16:43:46 -0000 The following errata report has been submitted for RFC5102, "Information Model for IP Flow Information Export". -------------------------------------- You may review the report below and at: http://www.rfc-editor.org/errata_search.php?rfc=5102&eid=1736 -------------------------------------- Type: Technical Reported by: Paul Aitken Section: 5.4.22. Original Text ------------- 0 1 2 3 4 5 6 7 +------+------+------+------+------+------+------+------+ | MCv4 | RES. | RES. | T | IPv6 multicast scope | +------+------+------+------+------+------+------+------+ Corrected Text -------------- 0 1 2 3 4 5 6 7 +------+------+------+------+------+------+------+------+ | IPv6 multicast scope | T | RES. | RES. | MCv4 | +------+------+------+------+------+------+------+------+ Notes ----- The diagram is back to front. Instructions: ------------- This errata is currently posted as "Reported". If necessary, please use "Reply All" to discuss whether it should be verified or rejected. When a decision is reached, the verifying party (IESG) can log in to change the status and edit the report, if necessary. -------------------------------------- RFC5102 (draft-ietf-ipfix-info-15) -------------------------------------- Title : Information Model for IP Flow Information Export Publication Date : January 2008 Author(s) : J. Quittek, S. Bryant, B. Claise, P. Aitken, J. Meyer Category : PROPOSED STANDARD Source : IP Flow Information Export Area : Operations and Management Stream : IETF Verifying Party : IESG From web-usrn@ISI.EDU Tue Mar 24 09:45:00 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 A82F13A6D47 for ; Tue, 24 Mar 2009 09:45:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.22 X-Spam-Level: X-Spam-Status: No, score=-17.22 tagged_above=-999 required=5 tests=[AWL=0.379, 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 m4e4LhUBidtB for ; Tue, 24 Mar 2009 09:44:59 -0700 (PDT) Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) by core3.amsl.com (Postfix) with ESMTP id 9661D3A6977 for ; Tue, 24 Mar 2009 09:44:59 -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 n2OGiLwF015622 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 24 Mar 2009 09:44:22 -0700 (PDT) Received: (from web-usrn@localhost) by boreas.isi.edu (8.13.8/8.13.8/Submit) id n2OGiLjv015621; Tue, 24 Mar 2009 09:44:21 -0700 (PDT) Date: Tue, 24 Mar 2009 09:44:21 -0700 (PDT) Message-Id: <200903241644.n2OGiLjv015621@boreas.isi.edu> To: quittek@netlab.nec.de, stbryant@cisco.com, bclaise@cisco.com, paitken@cisco.com, jemeyer@paypal.com, dromasca@avaya.com, rbonica@juniper.net, n.brownlee@auckland.ac.nz, quittek@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: ipfix@ietf.org, rfc-editor@rfc-editor.org Subject: [IPFIX] [Technical Errata Reported] RFC5102 (1737) 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, 24 Mar 2009 16:45:00 -0000 The following errata report has been submitted for RFC5102, "Information Model for IP Flow Information Export". -------------------------------------- You may review the report below and at: http://www.rfc-editor.org/errata_search.php?rfc=5102&eid=1737 -------------------------------------- Type: Technical Reported by: Paul Aitken Section: 5.8.5. Original Text ------------- 0 1 2 3 4 5 6 7 +------+------+------+------+------+------+------+------+ | EOOL | NOP | SEC | LSR | TS |E-SEC |CIPSO | RR | ... +------+------+------+------+------+------+------+------+ 8 9 10 11 12 13 14 15 +------+------+------+------+------+------+------+------+ ... | SID | SSR | ZSU | MTUP | MTUR | FINN | VISA |ENCODE| ... +------+------+------+------+------+------+------+------+ 16 17 18 19 20 21 22 23 +------+------+------+------+------+------+------+------+ ... |IMITD | EIP | TR |ADDEXT|RTRALT| SDB |NSAPA | DPS | ... +------+------+------+------+------+------+------+------+ 24 25 26 27 28 29 30 31 +------+------+------+------+------+------+------+------+ ... | UMP | QS | to be assigned by IANA | EXP | | +------+------+------+------+------+------+------+------+ Corrected Text -------------- 0 1 2 3 4 5 6 7 +------+------+------+------+------+------+------+------+ | RR |CIPSO |E-SEC | TS | LSR | SEC | NOP | EOOL | ... +------+------+------+------+------+------+------+------+ 8 9 10 11 12 13 14 15 +------+------+------+------+------+------+------+------+ ... |ENCODE| VISA | FINN | MTUR | MTUP | ZSU | SSR | SID | ... +------+------+------+------+------+------+------+------+ 16 17 18 19 20 21 22 23 +------+------+------+------+------+------+------+------+ ... | DPS |NSAPA | SDB |RTRALT|ADDEXT| TR | EIP |IMITD | ... +------+------+------+------+------+------+------+------+ 24 25 26 27 28 29 30 31 +------+------+------+------+------+------+------+------+ ... | | EXP | to be assigned by IANA | QS | UMP | +------+------+------+------+------+------+------+------+ Notes ----- The diagram is back to front. Instructions: ------------- This errata is currently posted as "Reported". If necessary, please use "Reply All" to discuss whether it should be verified or rejected. When a decision is reached, the verifying party (IESG) can log in to change the status and edit the report, if necessary. -------------------------------------- RFC5102 (draft-ietf-ipfix-info-15) -------------------------------------- Title : Information Model for IP Flow Information Export Publication Date : January 2008 Author(s) : J. Quittek, S. Bryant, B. Claise, P. Aitken, J. Meyer Category : PROPOSED STANDARD Source : IP Flow Information Export Area : Operations and Management Stream : IETF Verifying Party : IESG From web-usrn@ISI.EDU Tue Mar 24 09:47:17 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 DBAF43A6D3C for ; Tue, 24 Mar 2009 09:47:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.223 X-Spam-Level: X-Spam-Status: No, score=-17.223 tagged_above=-999 required=5 tests=[AWL=0.376, 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 6LI0ArYkYsW3 for ; Tue, 24 Mar 2009 09:47:16 -0700 (PDT) Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) by core3.amsl.com (Postfix) with ESMTP id CBDE43A6977 for ; Tue, 24 Mar 2009 09:47:16 -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 n2OGjZq5016065 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 24 Mar 2009 09:45:36 -0700 (PDT) Received: (from web-usrn@localhost) by boreas.isi.edu (8.13.8/8.13.8/Submit) id n2OGjZW3016064; Tue, 24 Mar 2009 09:45:35 -0700 (PDT) Date: Tue, 24 Mar 2009 09:45:35 -0700 (PDT) Message-Id: <200903241645.n2OGjZW3016064@boreas.isi.edu> To: quittek@netlab.nec.de, stbryant@cisco.com, bclaise@cisco.com, paitken@cisco.com, jemeyer@paypal.com, dromasca@avaya.com, rbonica@juniper.net, n.brownlee@auckland.ac.nz, quittek@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: ipfix@ietf.org, rfc-editor@rfc-editor.org Subject: [IPFIX] [Technical Errata Reported] RFC5102 (1738) 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, 24 Mar 2009 16:47:17 -0000 The following errata report has been submitted for RFC5102, "Information Model for IP Flow Information Export". -------------------------------------- You may review the report below and at: http://www.rfc-editor.org/errata_search.php?rfc=5102&eid=1738 -------------------------------------- Type: Technical Reported by: Paul Aitken Section: 5.8.6. Original Text ------------- 0 1 2 3 4 5 6 7 +-----+-----+-----+-----+-----+-----+-----+-----+ | Res | FRA1| RH | FRA0| UNK | Res | HOP | DST | ... +-----+-----+-----+-----+-----+-----+-----+-----+ 8 9 10 11 12 13 14 15 +-----+-----+-----+-----+-----+-----+-----+-----+ ... | PAY | AH | ESP | Reserved | ... +-----+-----+-----+-----+-----+-----+-----+-----+ 16 17 18 19 20 21 22 23 +-----+-----+-----+-----+-----+-----+-----+-----+ ... | Reserved | ... +-----+-----+-----+-----+-----+-----+-----+-----+ 24 25 26 27 28 29 30 31 +-----+-----+-----+-----+-----+-----+-----+-----+ ... | Reserved | +-----+-----+-----+-----+-----+-----+-----+-----+ Corrected Text -------------- 0 1 2 3 4 5 6 7 +-----+-----+-----+-----+-----+-----+-----+-----+ | DST | HOP | Res | UNK | FRA0| RH | FRA1| Res | ... +-----+-----+-----+-----+-----+-----+-----+-----+ 8 9 10 11 12 13 14 15 +-----+-----+-----+-----+-----+-----+-----+-----+ ... | Reserved | ESP | AH | PAY |... +-----+-----+-----+-----+-----+-----+-----+-----+ 16 17 18 19 20 21 22 23 +-----+-----+-----+-----+-----+-----+-----+-----+ ... | Reserved | ... +-----+-----+-----+-----+-----+-----+-----+-----+ 24 25 26 27 28 29 30 31 +-----+-----+-----+-----+-----+-----+-----+-----+ ... | Reserved | +-----+-----+-----+-----+-----+-----+-----+-----+ Notes ----- The diagram is back to front. Instructions: ------------- This errata is currently posted as "Reported". If necessary, please use "Reply All" to discuss whether it should be verified or rejected. When a decision is reached, the verifying party (IESG) can log in to change the status and edit the report, if necessary. -------------------------------------- RFC5102 (draft-ietf-ipfix-info-15) -------------------------------------- Title : Information Model for IP Flow Information Export Publication Date : January 2008 Author(s) : J. Quittek, S. Bryant, B. Claise, P. Aitken, J. Meyer Category : PROPOSED STANDARD Source : IP Flow Information Export Area : Operations and Management Stream : IETF Verifying Party : IESG From web-usrn@ISI.EDU Tue Mar 24 09:48:36 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 5D9403A6D48 for ; Tue, 24 Mar 2009 09:48:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -16.075 X-Spam-Level: X-Spam-Status: No, score=-16.075 tagged_above=-999 required=5 tests=[AWL=-0.776, BAYES_00=-2.599, MANGLED_SAVELE=2.3, 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 xa2FrHnkhBDL for ; Tue, 24 Mar 2009 09:48:35 -0700 (PDT) Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) by core3.amsl.com (Postfix) with ESMTP id 9923A3A6D4D for ; Tue, 24 Mar 2009 09:47:48 -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 n2OGkXQY016473 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 24 Mar 2009 09:46:34 -0700 (PDT) Received: (from web-usrn@localhost) by boreas.isi.edu (8.13.8/8.13.8/Submit) id n2OGkXQH016470; Tue, 24 Mar 2009 09:46:33 -0700 (PDT) Date: Tue, 24 Mar 2009 09:46:33 -0700 (PDT) Message-Id: <200903241646.n2OGkXQH016470@boreas.isi.edu> To: quittek@netlab.nec.de, stbryant@cisco.com, bclaise@cisco.com, paitken@cisco.com, jemeyer@paypal.com, dromasca@avaya.com, rbonica@juniper.net, n.brownlee@auckland.ac.nz, quittek@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: ipfix@ietf.org, rfc-editor@rfc-editor.org Subject: [IPFIX] [Editorial Errata Reported] RFC5102 (1739) 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, 24 Mar 2009 16:48:36 -0000 The following errata report has been submitted for RFC5102, "Information Model for IP Flow Information Export". -------------------------------------- You may review the report below and at: http://www.rfc-editor.org/errata_search.php?rfc=5102&eid=1739 -------------------------------------- Type: Editorial Reported by: Paul Aitken Section: 5.8.8. Original Text ------------- 0 1 2 3 4 5 6 7 +-----+-----+-----+-----+-----+-----+-----+-----+ | 0 | 1 | 2 | 3 | 4 | 5 | 6 | 7 | ... +-----+-----+-----+-----+-----+-----+-----+-----+ 8 9 10 11 12 13 14 15 +-----+-----+-----+-----+-----+-----+-----+-----+ ... | 8 | 9 | 10 | 11 | 12 | 13 | 14 | 15 |... +-----+-----+-----+-----+-----+-----+-----+-----+ 16 17 18 19 20 21 22 23 +-----+-----+-----+-----+-----+-----+-----+-----+ ... | 16 | 17 | 18 | 19 | 20 | 21 | 22 | 23 |... +-----+-----+-----+-----+-----+-----+-----+-----+ . . . 56 57 58 59 60 61 62 63 +-----+-----+-----+-----+-----+-----+-----+-----+ ... | 56 | 57 | 58 | 59 | 60 | 61 | 62 | 63 | +-----+-----+-----+-----+-----+-----+-----+-----+ Corrected Text -------------- 0 1 2 3 4 5 6 7 +-----+-----+-----+-----+-----+-----+-----+-----+ | 7 | 6 | 5 | 4 | 3 | 2 | 1 | 0 | ... +-----+-----+-----+-----+-----+-----+-----+-----+ 8 9 10 11 12 13 14 15 +-----+-----+-----+-----+-----+-----+-----+-----+ ... | 15 | 14 | 13 | 12 | 11 | 10 | 9 | 8 |... +-----+-----+-----+-----+-----+-----+-----+-----+ 16 17 18 19 20 21 22 23 +-----+-----+-----+-----+-----+-----+-----+-----+ ... | 23 | 22 | 21 | 20 | 19 | 18 | 17 | 16 |... +-----+-----+-----+-----+-----+-----+-----+-----+ . . . 56 57 58 59 60 61 62 63 +-----+-----+-----+-----+-----+-----+-----+-----+ ... | 63 | 62 | 61 | 60 | 59 | 58 | 57 | 56 | +-----+-----+-----+-----+-----+-----+-----+-----+ Notes ----- The diagram is back to front. Instructions: ------------- This errata is currently posted as "Reported". If necessary, please use "Reply All" to discuss whether it should be verified or rejected. When a decision is reached, the verifying party (IESG) can log in to change the status and edit the report, if necessary. -------------------------------------- RFC5102 (draft-ietf-ipfix-info-15) -------------------------------------- Title : Information Model for IP Flow Information Export Publication Date : January 2008 Author(s) : J. Quittek, S. Bryant, B. Claise, P. Aitken, J. Meyer Category : PROPOSED STANDARD Source : IP Flow Information Export Area : Operations and Management Stream : IETF Verifying Party : IESG From paitken@cisco.com Tue Mar 24 09:49: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 EAF9128C2C1 for ; Tue, 24 Mar 2009 09:49:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.149 X-Spam-Level: X-Spam-Status: No, score=-9.149 tagged_above=-999 required=5 tests=[AWL=-1.450, BAYES_00=-2.599, J_CHICKENPOX_37=0.6, MANGLED_SAVELE=2.3, 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 kJ5IDNnxXDaL for ; Tue, 24 Mar 2009 09:49:11 -0700 (PDT) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by core3.amsl.com (Postfix) with ESMTP id 0AFC93A67CC for ; Tue, 24 Mar 2009 09:49:10 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.38,413,1233532800"; d="scan'208";a="36750320" Received: from ams-dkim-2.cisco.com ([144.254.224.139]) by ams-iport-1.cisco.com with ESMTP; 24 Mar 2009 16:50:01 +0000 Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by ams-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id n2OGo159006663; Tue, 24 Mar 2009 17:50:01 +0100 Received: from [10.61.86.211] (ams3-vpn-dhcp5844.cisco.com [10.61.86.211]) by ams-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id n2OGo0K3024218; Tue, 24 Mar 2009 16:50:00 GMT Message-ID: <49C90F38.9000002@cisco.com> Date: Tue, 24 Mar 2009 16:50:00 +0000 From: Paul Aitken User-Agent: Mozilla/5.0 (X11; U; Linux i686 (x86_64); en-GB; rv:1.8.1.21) Gecko/20090303 SeaMonkey/1.1.15 MIME-Version: 1.0 To: ipfix-chairs@tools.ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=8184; t=1237913401; x=1238777401; c=relaxed/simple; s=amsdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=paitken@cisco.com; z=From:=20Paul=20Aitken=20 |Subject:=20RFC5102=20errata |Sender:=20; bh=f2J+kjIjgMmFWO+w7fra4rOZUJn7UxeRsCXMJtdJiBQ=; b=O9FMMMOvprSdZU5wFv5dUI3AHpw18+GJfvoULJJvjFwWwpoaBW9jbjWiRB gNyrRacpat7netKo9USs1JUW8Hq6eYOhd+EDZEl1RcMR6ycubnGd/2sHp4o9 jfxpN2S9ho; Authentication-Results: ams-dkim-2; header.From=paitken@cisco.com; dkim=pass ( sig from cisco.com/amsdkim2001 verified; ); Cc: "ipfix@ietf.org" Subject: [IPFIX] RFC5102 errata 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, 24 Mar 2009 16:49:13 -0000 Dear Chairs, While this issue was briefly discussed yesterday, I believe Benoit was caught unexpectedly and wasn't prepared to discuss the issue fully. And being remote on jabber, it was difficult for me to jump in with a brief summary at the time. However, I believe the conclusion reached in the WG yesterday (ie, to deprecate the IEs and create new ones) is not the correct solution. From my perspective, 1. Several IEs are incorrectly described, not just isMulticast. Specifically: isMulticast, ipv4Options, ipv6ExtensionHeaders, tcpOptions. 2. The main issue is that the RFC 5102 diagrams conflict with the text. 3. There are backwards compatibility issues with NFv9. Note that I first announced these issues eight months ago: http://www.ietf.org/mail-archive/web/ipfix/current/msg04383.html I've just submitted four errata to allow the issues to be tracked. Before the details, let's first ensure that we agree the bit ordering in RFCs. Per appendix B of RFC 791: Whenever an octet represents a numeric quantity the left most bit in the diagram is the high order or most significant bit. That is, the bit labeled 0 is the most significant bit. And again: Similarly, whenever a multi-octet field represents a numeric quantity the left most bit of the whole field is the most significant bit. When a multi-octet quantity is transmitted the most significant octet is transmitted first. So, with that in mind, I examined the following fields: * isMulticast For backwards compatibility with NFv9, the "MCv4" bit should have the values 0 and 1 - ie, it should be in the LSB position. Since RFC 791 specifies that "the bit labeled 0 is the most significant bit", the diagram depicting the bits is reversed. It should be: 0 1 2 3 4 5 6 7 +------+------+------+------+------+------+------+------+ | IPv6 multicast scope | T | RES. | RES. | MCv4 | +------+------+------+------+------+------+------+------+ Unfortunately the T bit now ends up offset by one from its position in RFC 4291. Too bad. * fragmentFlags The RS, DF and MF flags come directly from RFC 791, where they're in the same format and position. So this is fine. * mplsTopLabelExp, postMplsTopLabelExp No problem, except that this is offset by one bit (the "S" bit) from the position shown in RFC 3032. * mplsTopLabelStackSection Exactly as shown in RFC 3032, so no issue. * ipv4Options While all the text is good, since RFC 791 specifies that "the bit labeled 0 is the most significant bit", the diagram depicting the bits is reversed. It should be: 0 1 2 3 4 5 6 7 +------+------+------+------+------+------+------+------+ | RR |CIPSO |E-SEC | TS | LSR | SEC | NOP | EOOL | ... +------+------+------+------+------+------+------+------+ 8 9 10 11 12 13 14 15 +------+------+------+------+------+------+------+------+ ... |ENCODE| VISA | FINN | MTUR | MTUP | ZSU | SSR | SID | ... +------+------+------+------+------+------+------+------+ 16 17 18 19 20 21 22 23 +------+------+------+------+------+------+------+------+ ... | DPS |NSAPA | SDB |RTRALT|ADDEXT| TR | EIP |IMITD | ... +------+------+------+------+------+------+------+------+ 24 25 26 27 28 29 30 31 +------+------+------+------+------+------+------+------+ ... | | EXP | to be assigned by IANA | QS | UMP | +------+------+------+------+------+------+------+------+ Because RFC 791 defines: EOOL = 0 NOP = 1 SEC = 2 LSR = 3 ... * ipv6ExtensionHeaders RFC 5102 says: For each IPv6 option header, there is a bit in this set. The bit is set to 1 if any observed packet of this Flow contains the corresponding IPv6 extension header. While all the text is good, since RFC 791 specifies that "the bit labeled 0 is the most significant bit", the diagram depicting the bits is reversed. It should be: 0 1 2 3 4 5 6 7 +-----+-----+-----+-----+-----+-----+-----+-----+ | DST | HOP | Res | UNK | FRA0| RH | FRA1| Res | ... +-----+-----+-----+-----+-----+-----+-----+-----+ 8 9 10 11 12 13 14 15 +-----+-----+-----+-----+-----+-----+-----+-----+ ... | Reserved | ESP | AH | PAY |... +-----+-----+-----+-----+-----+-----+-----+-----+ So, eg, when a HBH head (value 6) is seen, bit 2^6 will be set, ie ipv6ExtensionHeaders = 32. Now, comparing RFC 5102, IANA and IOS: RFC 5102 specifies: Bit IPv6 Option Description 0, Res Reserved 1, FRA1 44 Fragmentation header - not first fragment 2, RH 43 Routing header 3, FRA0 44 Fragment header - first fragment 4, UNK Unknown Layer 4 header (compressed, encrypted, not supported) 5, Res Reserved 6, HOP 0 Hop-by-hop option header 7, DST 60 Destination option header 8, PAY 108 Payload compression header 9, AH 51 Authentication Header 10, ESP 50 Encrypted security payload 11 to 31 Reserved Whereas http://www.iana.org/assignments/ipv6-parameters section "5.a. Header types" specifies: 00 = Hop-by-Hop Options 41 = ipv6 43 = Routing 44 = Fragment 51 = Authentication 60 = Destination Options 50 = Encapsulating Security Payload xx = Upper Layer Header 58 = Internet Control Message Protocol (ICMP) 59 - no next header Therefore 41, 58, 59 are not provided for in RFC 5102. Also, 108 "Payload compression header" is defined in RFC 5102, coming from RFC 2393. This is missing from section 5.a of http://www.iana.org/assignments/ipv6-parameters. Finally, we should define bit 11 for the IPv6 mobility header (RFC 3775). ie: Bit IPv6 Option Description 11, MOB 135 IPv6 mobility (RFC 3775). * tcpControlBits Identical to RFC 793, so no issue. * tcpOptions While all the text is good, since RFC 791 specifies that "the bit labeled 0 is the most significant bit", the diagram depicting the bits is reversed. It should be: 0 1 2 3 4 5 6 7 +-----+-----+-----+-----+-----+-----+-----+-----+ | 7 | 6 | 5 | 4 | 3 | 2 | 1 | 0 | ... +-----+-----+-----+-----+-----+-----+-----+-----+ 8 9 10 11 12 13 14 15 +-----+-----+-----+-----+-----+-----+-----+-----+ ... | 15 | 14 | 13 | 12 | 11 | 10 | 9 | 8 |... +-----+-----+-----+-----+-----+-----+-----+-----+ 16 17 18 19 20 21 22 23 +-----+-----+-----+-----+-----+-----+-----+-----+ ... | 23 | 22 | 21 | 20 | 19 | 18 | 17 | 16 |... +-----+-----+-----+-----+-----+-----+-----+-----+ . . . 56 57 58 59 60 61 62 63 +-----+-----+-----+-----+-----+-----+-----+-----+ ... | 63 | 62 | 61 | 60 | 59 | 58 | 57 | 56 | +-----+-----+-----+-----+-----+-----+-----+-----+ Thanks. -- Paul Aitken Cisco Systems Ltd, Edinburgh, Scotland. From akoba@nttv6.net Wed Mar 25 05:14:37 2009 Return-Path: X-Original-To: ipfix@core3.amsl.com Delivered-To: ipfix@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 590703A695B for ; Wed, 25 Mar 2009 05:14:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.847 X-Spam-Level: X-Spam-Status: No, score=0.847 tagged_above=-999 required=5 tests=[AWL=-1.263, BAYES_00=-2.599, HELO_EQ_LOCALHOST=0.457, HELO_LOCALHOST=3.941, HOST_MISMATCH_NET=0.311] 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 MMpJbvOWBwMV for ; Wed, 25 Mar 2009 05:14:36 -0700 (PDT) Received: from mail.nttv6.net (mail.nttv6.net [IPv6:2001:fa8::25]) by core3.amsl.com (Postfix) with ESMTP id C812B3A68F0 for ; Wed, 25 Mar 2009 05:14:35 -0700 (PDT) Received: from localhost (mail.nttv6.net [192.16.178.5]) by mail.nttv6.net (8.14.3/8.14.3) with ESMTP id n2PCFPEr026100 for ; Wed, 25 Mar 2009 21:15:26 +0900 (JST) (envelope-from akoba@nttv6.net) Date: Wed, 25 Mar 2009 21:15:28 +0900 From: Atsushi Kobayashi To: ipfix@ietf.org Message-Id: <20090325210731.3D33.17391CF2@nttv6.net> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Becky! ver. 2.46 [ja] X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.0.1 (mail.nttv6.net [192.16.178.5]); Wed, 25 Mar 2009 21:15:26 +0900 (JST) Subject: [IPFIX] Multipurpose Traffic Measurement with IPFIX/PSAMP/xFlow 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, 25 Mar 2009 12:14:37 -0000 Dear all, Sunday morning, I presented about "Multipurpose Traffic Measurement with IPFIX/PSAMP/xFlow" at IEPG meeting. These slide is available on the following web site. http://www.nttv6.net/~akoba/iepg_ipfix.pdf Any feedback is welcome. Regards, Atsushi KOBAYASHI -- Atsushi Kobayashi From bclaise@cisco.com Wed Mar 25 14:34:53 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 A814D3A6B91 for ; Wed, 25 Mar 2009 14:34:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.533 X-Spam-Level: X-Spam-Status: No, score=-2.533 tagged_above=-999 required=5 tests=[AWL=0.066, 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 fIAckCMBEvS0 for ; Wed, 25 Mar 2009 14:34:52 -0700 (PDT) Received: from av-tac-bru.cisco.com (odd-brew.cisco.com [144.254.15.119]) by core3.amsl.com (Postfix) with ESMTP id 5AF6C3A6B3A for ; Wed, 25 Mar 2009 14:34:52 -0700 (PDT) X-TACSUNS: Virus Scanned Received: from strange-brew.cisco.com (localhost [127.0.0.1]) by av-tac-bru.cisco.com (8.11.7p3+Sun/8.11.7) with ESMTP id n2PLZhY27841; Wed, 25 Mar 2009 22:35:43 +0100 (CET) Received: from [10.21.149.30] (sjc-vpn7-1310.cisco.com [10.21.149.30]) by strange-brew.cisco.com (8.11.7p3+Sun/8.11.7) with ESMTP id n2PLZft21401; Wed, 25 Mar 2009 22:35:42 +0100 (CET) Message-ID: <49CAA3AC.2070107@cisco.com> Date: Wed, 25 Mar 2009 14:35:40 -0700 From: Benoit Claise User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: Atsushi Kobayashi References: <20090323201533.B669.17391CF2@nttv6.net> In-Reply-To: <20090323201533.B669.17391CF2@nttv6.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: ipfix@ietf.org Subject: Re: [IPFIX] Repeating mediation terminologies 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, 25 Mar 2009 21:34:53 -0000 Kobayashi-san, > Dear all, > > In IPFIX terminologies related to RFC5101, we decided the same > terminologies should not be repeated in Mediation drafts. > > What do you think about IPFIX Mediation terminologies defined in > Mediation problem statement draft? > > Should Mediation framework draft repeat them again, or not? > IMHO, first reader would have a look at framework draft, not problem > statement draft. Therefore, I think it is better that framework draft > repeats them. > I agree. If we make the comparison with: IPFIX Requirements (RFC3917) IPFIX Architecture We mainly look at the architecture, and rarely at requirements ... unless we have something to check. So I would make the Mediation framework an independent document. Regards, Benoit. > Regards, > Atsushi KOBAYASHI > > From bclaise@cisco.com Mon Mar 30 04:02: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 D662D3A69C5 for ; Mon, 30 Mar 2009 04:02:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.54 X-Spam-Level: X-Spam-Status: No, score=-2.54 tagged_above=-999 required=5 tests=[AWL=0.059, 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 1kcwg7plWGOn for ; Mon, 30 Mar 2009 04:02:27 -0700 (PDT) Received: from av-tac-bru.cisco.com (odd-brew.cisco.com [144.254.15.119]) by core3.amsl.com (Postfix) with ESMTP id 8D76E3A67B1 for ; Mon, 30 Mar 2009 04:02:26 -0700 (PDT) X-TACSUNS: Virus Scanned Received: from strange-brew.cisco.com (localhost [127.0.0.1]) by av-tac-bru.cisco.com (8.11.7p3+Sun/8.11.7) with ESMTP id n2UB3M100057; Mon, 30 Mar 2009 13:03:22 +0200 (CEST) Received: from [10.55.43.53] (ams-bclaise-8714.cisco.com [10.55.43.53]) by strange-brew.cisco.com (8.11.7p3+Sun/8.11.7) with ESMTP id n2UB3Kt24693; Mon, 30 Mar 2009 13:03:22 +0200 (CEST) Message-ID: <49D0A6F8.60903@cisco.com> Date: Mon, 30 Mar 2009 13:03:20 +0200 From: Benoit Claise User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: Hitoshi Irino References: <49C72F0A.9090305@lab.ntt.co.jp> In-Reply-To: <49C72F0A.9090305@lab.ntt.co.jp> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: ipfix@ietf.org Subject: Re: [IPFIX] about Collecting Process MIB objects X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Mar 2009 11:02:27 -0000 Hitoshi-san, What you trying to achieve is basically a way to have the application-level acknowledgements, i.e. knowing when the transport protocol is able to transmit the data, while the collector is not able to write them down. A few points: - We discussed that capability a long time ago in the WG, and my recollection is that it was deemed unnecessary to overload the IPFIX protocol with that mechanism. - If the Collector can detect that, it might be interesting to flag that - However, I guess that we don't want to postpone the MIB anymore, as it was mentioned. So if the group wants to do something, this might be in the configuration data model (even there is nothing to configure in this case) - Furthermore, the proposed mechanism, i.e. compare the packets/bytes/messages from one table to the sum of the transport sessionS stats for whatever Template Records/Flow Records are written into a File is not intuitive. If we want to do something, I'm in favor of a very simple flag expressing: "I can't deal with all the Flow Records". Then it's up to the sys admin to investigate the causes. Regards, Benoit. > Dear IPFIX-MIB authors and all, > > I'd like to propose to add MIB objects about collecting process, if > you agree and if you can. (I am sorry for my very late opinion, I hit > on this recently.) > > Collected information will be passed to another process (e.g., File > Writer, Metering Process in Mediators and/or any applications for > analyzing and/or displaying graphical view in Collectors) from > collecting process generally, I think. > > If the number of processed packets, bytes, and messages in Collecting > Process (which I call them as > ipfixCollectingProcessProcessedPackets/Bytes/Messages in this mail > temporarily) can be got, I think these objects are useful to detect > failure in Collectors (or Mediators) by comparing > ipfixTransportSessionPackets/Bytes/Messages and these objects. > Therefore I'd like to add > ipfixCollectingProcessProcessedPackets/Bytes/Messages. > > An example situation: If a Collector's disk is full filled and File > Writer will fail in writing, > ipfixTransportSessionPackets/Bytes/Messages will be increased but > ipfixCollectingProcessProcessedPackets/Bytes/Messages will not be > increased when a Collecting Process receives new IPFIX Message. > > regards, > Hitoshi IRINO > From muenz@net.in.tum.de Tue Mar 31 01:22:05 2009 Return-Path: X-Original-To: ipfix@core3.amsl.com Delivered-To: ipfix@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BC7133A68CD; Tue, 31 Mar 2009 01:22:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.843 X-Spam-Level: X-Spam-Status: No, score=-1.843 tagged_above=-999 required=5 tests=[AWL=-0.194, BAYES_00=-2.599, HELO_EQ_DE=0.35, J_CHICKENPOX_55=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 TmzwFQ3lVzdN; Tue, 31 Mar 2009 01:22:04 -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 3C45F3A6358; Tue, 31 Mar 2009 01:22:03 -0700 (PDT) Received: from phoenix.net.informatik.tu-muenchen.de (phoenix.net.informatik.tu-muenchen.de [131.159.14.1]) by services.net.informatik.tu-muenchen.de (Postix Mailer @ mail) with ESMTP id 5D8D447F33; Tue, 31 Mar 2009 10:23:00 +0200 (CEST) Received: from [131.159.20.108] (repulse.net.informatik.tu-muenchen.de [131.159.20.108]) by phoenix.net.informatik.tu-muenchen.de (Postfix) with ESMTP id 44E27A9B; Tue, 31 Mar 2009 10:23:00 +0200 (CEST) Message-ID: <49D1D2E5.3010007@net.in.tum.de> Date: Tue, 31 Mar 2009 10:23:01 +0200 From: Gerhard Muenz User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: psamp , "ipfix@ietf.org" Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms020801050408000105030103" X-Virus-Scanned: ClamAV using ClamSMTP Subject: [IPFIX] IPFIX/PSAMP-MIB: parameters of Property Match Filtering 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, 31 Mar 2009 08:22:05 -0000 This is a cryptographically signed message in MIME format. --------------ms020801050408000105030103 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi all, Regarding consistency of property match filtering parameters in RFC5475 (psamp-tech), RFC5476 (psamp-proto), PSAMP-MIB, and IPFIX-MIB: =46rom RFC5475: A packet is selected if Field=3DValue. Masks and ranges are only supported to the extent to which [RFC5102] allows them, e.g., by providing explicit fields like the netmasks for source and destination addresses. This is consistent with RFC5476. =46rom psamp-mib-06: The match filtering method has no capabilities defined and contains four parameters in the psampFilterMatchParamSetTable: The psampFilterMatchFieldId contain the PSAMP or IPFIX field id defined in the information model as reference what to match. The psampFilterMatchStartValue and psampFilterMatchStopValue contain the start and stop value to match the content against. In this way you can match e.g., a range x-z of transport protocol ports by specifying the field id that represents the transport protocol port and giving x as start value and y as stop value. If a single value should be matched than start and stop value must be equal. A mask psampFilterMatchMask can be applied if it is applicable for the field id. The encoding of the values is dependent on the field id and has to be done according to the PSAMP protocol document. However, defining a range (startValue, stopValue) and mask is not consistent with RFC5475/5476. So, what are the plans for PSAMP-MIB? Replace psampFilterMatchStartValue, psampFilterMatchStopvalue, and psampFilterMatchMask by a single psampFilterMatchValue? RFC5475/5476 allow multiple Field=3DValue conditions in a single Selector= (AND semantic. If PSAMP-MIB is changed as sketched above, every Field=3DValue condition corresponds to a row in psampFilterMatchParamSetTable. In this case, there are consequences for IPFIX-MIB: The ipfixSelectorTable in IPFIX-MIB should be changed to enable the linkage between one Selector ID and multiple rows in psampFilterMatchParamSetTable. At the moment, the ipfixSelectorTable only allows linking the Selector ID to a single OID (ipfixSelectorFunction) only, which restricts property match filtering to a single Field=3DValue condition per Selector. Regards, Gerhard --=20 Dipl.-Ing. Gerhard M=FCnz Chair for Network Architectures and Services (I8) Department of Informatics Technische Universit=E4t M=FCnchen Boltzmannstr. 3, 85748 Garching bei M=FCnchen, Germany Phone: +49 89 289-18008 Fax: +49 89 289-18033 E-mail: muenz@net.in.tum.de WWW: http://www.net.in.tum.de/~muenz --------------ms020801050408000105030103 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 SIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMDkwMzMxMDgyMzAxWjAjBgkqhkiG9w0BCQQxFgQU BTrz69KuyM7fMPPjrlKmOLn7NBMwUgYJKoZIhvcNAQkPMUUwQzAKBggqhkiG9w0DBzAOBggq hkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwICASgwgYUG CSsGAQQBgjcQBDF4MHYwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0 aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1 aW5nIENBAhAqxerdN2XVRkUZsuk5IKdPMIGHBgsqhkiG9w0BCRACCzF4oHYwYjELMAkGA1UE BhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMT I1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBAhAqxerdN2XVRkUZsuk5IKdP MA0GCSqGSIb3DQEBAQUABIIBAEfSSofQjhcLJaGSRpTaKa6zLn9h3tPE5a4bGtURW+N1Vmhs 8F94v+6w1cNA3x7p29ZWb9k8+XJZg9W8bokn0S1kMSMbjgWpnyfUbPoGTa6lOxYj+gXFBHDj pv/Xs0y5V0Ar/eM9R+fa4Zrb8ldtL6Xx+xK6K+IAk5H11obcL5mWWCdyGhfJv5IeCCFR6hT8 IJgeR9ZSBrFMLwxpK/UJf552OzSdziGsLRxJY8sq7l1sjORD7Buw7ctJEuiQNC+hi3gYUYD8 j2NgyUz2cvzYxJtoeK/0ZMWmrlILTS8WD+qCnh5mzzRvUbI1jv61iMjfkGfyGQ34FV96BKBv O0TSS3YAAAAAAAA= --------------ms020801050408000105030103-- From rfc-editor@rfc-editor.org Tue Mar 31 16:56:30 2009 Return-Path: X-Original-To: ipfix@core3.amsl.com Delivered-To: ipfix@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 592683A68D0; Tue, 31 Mar 2009 16:56:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.228 X-Spam-Level: X-Spam-Status: No, score=-17.228 tagged_above=-999 required=5 tests=[AWL=0.371, 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 W69EmFY5k12W; Tue, 31 Mar 2009 16:56:29 -0700 (PDT) Received: from bosco.isi.edu (bosco.isi.edu [128.9.168.207]) by core3.amsl.com (Postfix) with ESMTP id C24223A687E; Tue, 31 Mar 2009 16:56:28 -0700 (PDT) Received: by bosco.isi.edu (Postfix, from userid 70) id 4BB3026B7A5; Tue, 31 Mar 2009 16:56:52 -0700 (PDT) To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org From: rfc-editor@rfc-editor.org Message-Id: <20090331235652.4BB3026B7A5@bosco.isi.edu> Date: Tue, 31 Mar 2009 16:56:52 -0700 (PDT) Cc: ipfix@ietf.org, rfc-editor@rfc-editor.org Subject: [IPFIX] RFC 5470 on Architecture for IP Flow Information Export 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, 31 Mar 2009 23:56:30 -0000 A new Request for Comments is now available in online RFC libraries. RFC 5470 Title: Architecture for IP Flow Information Export Author: G. Sadasivan, N. Brownlee, B. Claise, J. Quittek Status: Informational Date: March 2009 Mailbox: gsadasiv@rohati.com, n.brownlee@auckland.ac.nz, bclaise@cisco.com, quittek@nw.neclab.eu Pages: 31 Characters: 65717 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-ietf-ipfix-architecture-12.txt URL: http://www.rfc-editor.org/rfc/rfc5470.txt This memo defines the IP Flow Information eXport (IPFIX) architecture for the selective monitoring of IP Flows, and for the export of measured IP Flow information from an IPFIX Device to a Collector. This memo provides information for the Internet community. This document is a product of the IP Flow Information Export Working Group of the IETF. INFORMATIONAL: This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce and rfc-dist lists. To subscribe or unsubscribe, see http://www.ietf.org/mailman/listinfo/ietf-announce http://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see http://www.rfc-editor.org/rfcsearch.html. For downloading RFCs, see http://www.rfc-editor.org/rfc.html. Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-editor@rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team USC/Information Sciences Institute From rfc-editor@rfc-editor.org Tue Mar 31 16:56: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 F05693A6AE9; Tue, 31 Mar 2009 16:56:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.23 X-Spam-Level: X-Spam-Status: No, score=-17.23 tagged_above=-999 required=5 tests=[AWL=0.369, 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 OnTGyKT0Cd7x; Tue, 31 Mar 2009 16:56:45 -0700 (PDT) Received: from bosco.isi.edu (bosco.isi.edu [128.9.168.207]) by core3.amsl.com (Postfix) with ESMTP id 8798D3A6AA2; Tue, 31 Mar 2009 16:56:43 -0700 (PDT) Received: by bosco.isi.edu (Postfix, from userid 70) id 1C77526B7AB; Tue, 31 Mar 2009 16:57:07 -0700 (PDT) To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org From: rfc-editor@rfc-editor.org Message-Id: <20090331235707.1C77526B7AB@bosco.isi.edu> Date: Tue, 31 Mar 2009 16:57:07 -0700 (PDT) Cc: ipfix@ietf.org, rfc-editor@rfc-editor.org Subject: [IPFIX] RFC 5471 on Guidelines for IP Flow Information Export (IPFIX) Testing 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, 31 Mar 2009 23:56:46 -0000 A new Request for Comments is now available in online RFC libraries. RFC 5471 Title: Guidelines for IP Flow Information Export (IPFIX) Testing Author: C. Schmoll, P. Aitken, B. Claise Status: Informational Date: March 2009 Mailbox: carsten.schmoll@fokus.fraunhofer.de, paitken@cisco.com, bclaise@cisco.com Pages: 32 Characters: 69313 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-ietf-ipfix-testing-05.txt URL: http://www.rfc-editor.org/rfc/rfc5471.txt This document presents a list of tests for implementers of IP Flow Information eXport (IPFIX) compliant Exporting Processes and Collecting Processes. This document specifies guidelines for a series of tests that can be run on the IPFIX Exporting Process and Collecting Process in order to probe the conformity and robustness of the IPFIX protocol implementations. These tests cover all important functions, in order to gain a level of confidence in the IPFIX implementation. Therefore, they allow the implementer to perform interoperability or plug tests with other IPFIX Exporting Processes and Collecting Processes. This memo provides information for the Internet community. This document is a product of the IP Flow Information Export Working Group of the IETF. INFORMATIONAL: This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce and rfc-dist lists. To subscribe or unsubscribe, see http://www.ietf.org/mailman/listinfo/ietf-announce http://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see http://www.rfc-editor.org/rfcsearch.html. For downloading RFCs, see http://www.rfc-editor.org/rfc.html. Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-editor@rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team USC/Information Sciences Institute From rfc-editor@rfc-editor.org Tue Mar 31 16:57:05 2009 Return-Path: X-Original-To: ipfix@core3.amsl.com Delivered-To: ipfix@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 013B83A6B80; Tue, 31 Mar 2009 16:57:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.232 X-Spam-Level: X-Spam-Status: No, score=-17.232 tagged_above=-999 required=5 tests=[AWL=0.367, 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 UBbhFQkqBJVR; Tue, 31 Mar 2009 16:57:04 -0700 (PDT) Received: from bosco.isi.edu (bosco.isi.edu [128.9.168.207]) by core3.amsl.com (Postfix) with ESMTP id 6B3183A6B69; Tue, 31 Mar 2009 16:56:59 -0700 (PDT) Received: by bosco.isi.edu (Postfix, from userid 70) id F34D526B7B3; Tue, 31 Mar 2009 16:57:22 -0700 (PDT) To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org From: rfc-editor@rfc-editor.org Message-Id: <20090331235722.F34D526B7B3@bosco.isi.edu> Date: Tue, 31 Mar 2009 16:57:22 -0700 (PDT) Cc: ipfix@ietf.org, rfc-editor@rfc-editor.org Subject: [IPFIX] RFC 5472 on IP Flow Information Export (IPFIX) Applicability 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, 31 Mar 2009 23:57:05 -0000 A new Request for Comments is now available in online RFC libraries. RFC 5472 Title: IP Flow Information Export (IPFIX) Applicability Author: T. Zseby, E. Boschi, N. Brownlee, B. Claise Status: Informational Date: March 2009 Mailbox: tanja.zseby@fokus.fraunhofer.de, elisa.boschi@hitachi-eu.com, nevil@caida.org, bclaise@cisco.com Pages: 31 Characters: 71379 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-ietf-ipfix-as-12.txt URL: http://www.rfc-editor.org/rfc/rfc5472.txt In this document, we describe the applicability of the IP Flow Information eXport (IPFIX) protocol for a variety of applications. We show how applications can use IPFIX, describe the relevant Information Elements (IEs) for those applications, and present opportunities and limitations of the protocol. Furthermore, we describe relations of the IPFIX framework to other architectures and frameworks. This memo provides information for the Internet community. This document is a product of the IP Flow Information Export Working Group of the IETF. INFORMATIONAL: This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce and rfc-dist lists. To subscribe or unsubscribe, see http://www.ietf.org/mailman/listinfo/ietf-announce http://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see http://www.rfc-editor.org/rfcsearch.html. For downloading RFCs, see http://www.rfc-editor.org/rfc.html. Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-editor@rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team USC/Information Sciences Institute From rfc-editor@rfc-editor.org Tue Mar 31 16:57:17 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 9576428C1C5; Tue, 31 Mar 2009 16:57:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.234 X-Spam-Level: X-Spam-Status: No, score=-17.234 tagged_above=-999 required=5 tests=[AWL=0.365, 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 Ju1opbeP3Amn; Tue, 31 Mar 2009 16:57:16 -0700 (PDT) Received: from bosco.isi.edu (bosco.isi.edu [128.9.168.207]) by core3.amsl.com (Postfix) with ESMTP id 35CCB28C1BF; Tue, 31 Mar 2009 16:57:11 -0700 (PDT) Received: by bosco.isi.edu (Postfix, from userid 70) id BE2AE26B7B7; Tue, 31 Mar 2009 16:57:34 -0700 (PDT) To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org From: rfc-editor@rfc-editor.org Message-Id: <20090331235734.BE2AE26B7B7@bosco.isi.edu> Date: Tue, 31 Mar 2009 16:57:34 -0700 (PDT) Cc: ipfix@ietf.org, rfc-editor@rfc-editor.org Subject: [IPFIX] RFC 5473 on Reducing Redundancy in IP Flow Information Export (IPFIX) and Packet Sampling (PSAMP) Reports X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 Mar 2009 23:57:17 -0000 A new Request for Comments is now available in online RFC libraries. RFC 5473 Title: Reducing Redundancy in IP Flow Information Export (IPFIX) and Packet Sampling (PSAMP) Reports Author: E. Boschi, L. Mark, B. Claise Status: Informational Date: March 2009 Mailbox: elisa.boschi@hitachi-eu.com, lutz.mark@ifam.fraunhofer.de, bclaise@cisco.com Pages: 27 Characters: 64654 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-ietf-ipfix-reducing-redundancy-04.txt URL: http://www.rfc-editor.org/rfc/rfc5473.txt This document describes a bandwidth saving method for exporting Flow or packet information using the IP Flow Information eXport (IPFIX) protocol. As the Packet Sampling (PSAMP) protocol is based on IPFIX, these considerations are valid for PSAMP exports as well. This method works by separating information common to several Flow Records from information specific to an individual Flow Record. Common Flow information is exported only once in a Data Record defined by an Options Template, while the rest of the specific Flow information is associated with the common information via a unique identifier. This memo provides information for the Internet community. This document is a product of the IP Flow Information Export Working Group of the IETF. INFORMATIONAL: This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce and rfc-dist lists. To subscribe or unsubscribe, see http://www.ietf.org/mailman/listinfo/ietf-announce http://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see http://www.rfc-editor.org/rfcsearch.html. For downloading RFCs, see http://www.rfc-editor.org/rfc.html. Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-editor@rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team USC/Information Sciences Institute