From Quittek@nw.neclab.eu Tue Sep 1 08:15: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 567C03A6403 for ; Tue, 1 Sep 2009 08:15:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.424 X-Spam-Level: X-Spam-Status: No, score=-2.424 tagged_above=-999 required=5 tests=[AWL=0.175, 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 FlEQu5OzAJqa for ; Tue, 1 Sep 2009 08:15:26 -0700 (PDT) Received: from smtp0.neclab.eu (smtp0.neclab.eu [195.37.70.41]) by core3.amsl.com (Postfix) with ESMTP id 93A423A6359 for ; Tue, 1 Sep 2009 08:15:25 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp0.neclab.eu (Postfix) with ESMTP id A82EA2C00C51F; Tue, 1 Sep 2009 17:15:38 +0200 (CEST) X-Virus-Scanned: Amavisd on Debian GNU/Linux (atlas2.office) Received: from smtp0.neclab.eu ([127.0.0.1]) by localhost (atlas2.office [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UTGMem62nxwl; Tue, 1 Sep 2009 17:15:38 +0200 (CEST) Received: from VENUS.office (mx1.office [192.168.24.3]) by smtp0.neclab.eu (Postfix) with ESMTP id 6CF512C0004DE; Tue, 1 Sep 2009 17:15:18 +0200 (CEST) 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 ; Tue, 1 Sep 2009 15:15:15 +0000 MIME-Version: 1.0 Content-class: urn:content-classes:message Content-Type: multipart/signed; boundary="B_3334670116_6591855"; protocol="application/pkcs7-signature"; micalg=sha1 Date: Tue, 1 Sep 2009 17:15:15 +0200 Message-ID: In-Reply-To: X-MS-Has-Attach: yes X-MS-TNEF-Correlator: Thread-Topic: IPFIX re-chartering request Thread-Index: Acon2B+YWibFz1WBS0eXLAaP5MeKoACbSjIAADRuY5A= From: "Juergen Quittek" To: "Dan Romascanu" , "Ronald Bonica" , Cc: IETF IPFIX Working Group Subject: Re: [IPFIX] IPFIX re-chartering request X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Sep 2009 15:15:27 -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_3334670116_6591855 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Hi Dan, On 31.08.09 16:15 "Dan Romascanu" wrote: > Juergen, > > These look fine to me. > > Can you please generate a new charter text will all these changes so > that I can distribute it for internal review by the IESG and IAB? Please find the new charter text below. Thanks, Juergen IPFIX charter proposal ====================== IP Flow Information Export (ipfix) Chair(s): * Nevil Brownlee * Juergen Quittek Operations and Management Area Director(s): * Dan Romascanu * Ronald Bonica Operations and Management Area Advisor: * Dan Romascanu Mailing Lists: General Discussion: ipfix@ietf.org To Subscribe: http://www.ietf.org/mailman/listinfo/ipfix Archive: http://www.ietf.org/mail-archive/web/ipfix Description of Working Group: The IPFIX working group has specified the Information Model (to describe IP flows) and the IPFIX protocol (to transfer IP flow data from IPFIX exporters to collectors). Several implementers have already built applications using the IPFIX protocol. As a result of a series of IPFIX interoperability testing events the WG has produced guidelines for IPFIX implementation and testing as well as recommendations for handling special cases such as bidirectional flow reporting and reducing redundancy in flow records. Practical experiences with IPFIX implementations exposed new requirements for the IPFIX protocol that so far have not been addressed by the WG. The major current goal of the WG is developing solutions that meet the new requirements without modifying the core IPFIX protocol specifications. 1. The IPFIX WG has developed a MIB module for monitoring IPFIX implementations. Means for configuring these devices have not been standardized yet. The WG will develop an XML-based configuration data model that can be used for configuring IPFIX devices and for storing, modifying and managing IPFIX configurations parameter sets. This work will be performed in close collaboration with the NETCONF WG. 2. First applications of IPFIX at large operator networks showed the need for mediation of flow information, for example, for aggregating huge amounts of flow data and for anomymization of flow information. The IPFIX WG will investigate this issue and produce a problem statement and a framework for IPFIX flow mediation. 3. The PSAMP WG has developed a protocol for reporting observed packets. The PSAMP protocol is an extension of the IPFIX protocol. The IPFIX WG will develop a MIB module for monitoring PSAMP implementations. The new MIB module will be an extension of the IPFIX MIB module. 4. Anonymization of flow information has been identified as a requirement for flow information export already in RFC 3917. However, technologies for flow anonymization are still a research issue and have so far not been considered to be mature enough for standardization. As one step in this direction, the IPFIX WG will develop guidelines for the implementation of anonymized data export and storage over IPFIX and define an information model for configuring and reporting anonymization applied at IPFIX devices. 5. The IPFIX and PSAMP WGs have defined standards for selecting observed IP packets and collecting information in flow records. In order to reduce the amount of data to be processed, packet selection methods have been defined. Another method for reducing flow data is flow selection. The IPFIX WG will define methods for flow selection and provide an information model for configuring and reporting flow selection applied at IPFIX devices. 6. Being designed for the export of flow records the IPFIX protocol provides very limited means for structuring information elements within IPFIX records. With the increasing number of IPFIX applications there is a need for exporting more complex information. The IPFIX WG will develop an extension of the IPFIX protocol that supports hierarchically structured data and lists (sequences) of Information Elements in data records. Goals and Milestones: Oct 2009 Submit Mediation Problem Statement I-D to IESG for publication as Informational RFC Oct 2009 Submit initial draft on anonymization support Oct 2009 Submit initial draft on flow selection Oct 2009 Submit initial draft on structuring information elements Jan 2009 Submit Configuration Data Model draft to IESG for publication as Standards track RFC Jan 2009 Submit Mediation Framework I-D to IESG for publication as Informational RFC Jan 2010 Submit final version of PSAMP MIB module Jun 2010 Submit anonymization support I-D to IESG for publication as Experimental RFC Jun 2010 Submit flow selection I-D to IESG for publication as Standards Track RFC Jun 2010 Submit structuring information elements I-D to IESG for publication as Standards Track RFC --B_3334670116_6591855 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 YWIuZXUCBA0uKwcwCQYFKw4DAhoFAKBdMCMGCSqGSIb3DQEJBDEWBBSMAJxvuHYiAAdh9Esp X+ul/ylRETAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0wOTA5 MDExNTE1MTZaMA0GCSqGSIb3DQEBAQUABIIBAHMtDVIyshdMThVa6tznH5wo4G/gp+ytbQqQ B8gkTnf0DB2DRhSucKbVJduLMMM8TsYdQnT1n7jEKQu/ZyHq6EiviTKd8XjCTMOXUJ+lPG7L SaAUHJh8ecX3OZwY2G9AivVbu+xCetlWSg47jGfdxa0dOg1+EdPyCahWu+rnPru81hqH1HHg yzU/jsPmYVumIvLHBtZBURuFt1u1bIq0igwfZUmNI1Zv0LIY4wdyrRU46CI5NiNHYsVWQBPN X/r6R4hS0a26jm3XsK27/psn6h7lNU1bo2m1+vjudXpPvWlIyGqQOyMGFUTgPqPDBS/INJ92 X3NX328EeymzE6mTO18= --B_3334670116_6591855-- From Quittek@nw.neclab.eu Thu Sep 3 10:08:39 2009 Return-Path: X-Original-To: ipfix@core3.amsl.com Delivered-To: ipfix@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 120EE3A6D96 for ; Thu, 3 Sep 2009 10:08:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.442 X-Spam-Level: X-Spam-Status: No, score=-2.442 tagged_above=-999 required=5 tests=[AWL=0.157, 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 YLcA8fzr5Ee7 for ; Thu, 3 Sep 2009 10:08:37 -0700 (PDT) Received: from smtp0.neclab.eu (smtp0.neclab.eu [195.37.70.41]) by core3.amsl.com (Postfix) with ESMTP id 2A0773A6D0D for ; Thu, 3 Sep 2009 10:06:53 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp0.neclab.eu (Postfix) with ESMTP id A6E192C0012C5; Thu, 3 Sep 2009 19:05:25 +0200 (CEST) X-Virus-Scanned: Amavisd on Debian GNU/Linux (atlas2.office) Received: from smtp0.neclab.eu ([127.0.0.1]) by localhost (atlas2.office [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Yru0RNp5-e1d; Thu, 3 Sep 2009 19:05:25 +0200 (CEST) Received: from VENUS.office (mx2.office [192.168.24.15]) by smtp0.neclab.eu (Postfix) with ESMTP id 634C82C0004DB; Thu, 3 Sep 2009 19:05:05 +0200 (CEST) Received: from 10.7.0.54 ([10.7.0.54]) by VENUS.office ([192.168.24.102]) with Microsoft Exchange Server HTTP-DAV ; Thu, 3 Sep 2009 17:04:33 +0000 MIME-Version: 1.0 Content-class: urn:content-classes:message Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="B_3334778854_8975459" X-MimeOLE: Produced By Microsoft Exchange V6.5 Date: Thu, 3 Sep 2009 19:04:33 +0200 Message-ID: In-Reply-To: X-MS-Has-Attach: yes X-MS-TNEF-Correlator: Thread-Topic: [IPFIX] IPFIX re-chartering request Thread-Index: Acon2B+YWibFz1WBS0eXLAaP5MeKoACbSjIAADRuY5AAP0tfTw== From: "Juergen Quittek" To: "Dan Romascanu" , "Ronald Bonica" , Cc: IETF IPFIX Working Group Subject: Re: [IPFIX] IPFIX re-chartering request X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Sep 2009 17:08:39 -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_3334778854_8975459 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Hi Dan, Brian found two typos in the milestone section. Two deadlines are in the past: "Jan 2009" should obviously be "Jan 2010". Sorry, Juergen On 01.09.09 17:15 "Juergen Quittek" wrote: > Hi Dan, > > On 31.08.09 16:15 "Dan Romascanu" wrote: >> Juergen, >> >> These look fine to me. >> >> Can you please generate a new charter text will all these changes so >> that I can distribute it for internal review by the IESG and IAB? > > Please find the new charter text below. > > Thanks, > > Juergen > > > IPFIX charter proposal > ====================== > > IP Flow Information Export (ipfix) > > Chair(s): > > * Nevil Brownlee > * Juergen Quittek > > Operations and Management Area Director(s): > > * Dan Romascanu > * Ronald Bonica > > Operations and Management Area Advisor: > > * Dan Romascanu > > Mailing Lists: > General Discussion: ipfix@ietf.org > To Subscribe: http://www.ietf.org/mailman/listinfo/ipfix > Archive: http://www.ietf.org/mail-archive/web/ipfix > > Description of Working Group: > > The IPFIX working group has specified the Information Model (to > describe IP flows) and the IPFIX protocol (to transfer IP flow data > from IPFIX exporters to collectors). Several implementers have already > built applications using the IPFIX protocol. As a result of a series > of IPFIX interoperability testing events the WG has produced > guidelines for IPFIX implementation and testing as well as > recommendations for handling special cases such as bidirectional flow > reporting and reducing redundancy in flow records. > > Practical experiences with IPFIX implementations exposed new > requirements for the IPFIX protocol that so far have not been > addressed by the WG. The major current goal of the WG is developing > solutions that meet the new requirements without modifying the core > IPFIX protocol specifications. > > 1. The IPFIX WG has developed a MIB module for monitoring IPFIX > implementations. Means for configuring these devices have not been > standardized yet. The WG will develop an XML-based configuration data > model that can be used for configuring IPFIX devices and for storing, > modifying and managing IPFIX configurations parameter sets. This work > will be performed in close collaboration with the NETCONF WG. > > 2. First applications of IPFIX at large operator networks showed the > need for mediation of flow information, for example, for aggregating > huge amounts of flow data and for anomymization of flow information. > The IPFIX WG will investigate this issue and produce a problem > statement and a framework for IPFIX flow mediation. > > 3. The PSAMP WG has developed a protocol for reporting > observed packets. The PSAMP protocol is an extension of > the IPFIX protocol. The IPFIX WG will develop a MIB module > for monitoring PSAMP implementations. The new MIB module > will be an extension of the IPFIX MIB module. > > 4. Anonymization of flow information has been identified as a > requirement for flow information export already in RFC 3917. However, > technologies for flow anonymization are still a research issue and have > so far not been considered to be mature enough for standardization. > As one step in this direction, the IPFIX WG will develop guidelines for > the implementation of anonymized data export and storage over IPFIX > and define an information model for configuring and reporting > anonymization applied at IPFIX devices. > > 5. The IPFIX and PSAMP WGs have defined standards for selecting > observed IP packets and collecting information in flow records. > In order to reduce the amount of data to be processed, packet selection > methods have been defined. Another method for reducing flow data is > flow selection. The IPFIX WG will define methods for flow selection and > provide an information model for configuring and reporting flow selection > applied at IPFIX devices. > > 6. Being designed for the export of flow records the IPFIX protocol > provides very limited means for structuring information elements within > IPFIX records. With the increasing number of IPFIX applications there is > a need for exporting more complex information. The IPFIX WG will develop > an extension of the IPFIX protocol that supports hierarchically > structured data and lists (sequences) of Information Elements in data > records. > > Goals and Milestones: > > Oct 2009 Submit Mediation Problem Statement I-D to IESG > for publication as Informational RFC > Oct 2009 Submit initial draft on anonymization support > Oct 2009 Submit initial draft on flow selection > Oct 2009 Submit initial draft on structuring information elements > Jan 2009 Submit Configuration Data Model draft to IESG > for publication as Standards track RFC > Jan 2009 Submit Mediation Framework I-D to IESG > for publication as Informational RFC > Jan 2010 Submit final version of PSAMP MIB module > Jun 2010 Submit anonymization support I-D to IESG > for publication as Experimental RFC > Jun 2010 Submit flow selection I-D to IESG > for publication as Standards Track RFC > Jun 2010 Submit structuring information elements I-D to IESG > for publication as Standards Track RFC > _______________________________________________ > IPFIX mailing list > IPFIX@ietf.org > https://www.ietf.org/mailman/listinfo/ipfix --B_3334778854_8975459 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 YWIuZXUCBA0uKwcwCQYFKw4DAhoFAKBdMCMGCSqGSIb3DQEJBDEWBBRLOvGpYpbU3bl2nngD JMfbdeMBnDAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0wOTA5 MDIyMTI3MzRaMA0GCSqGSIb3DQEBAQUABIIBAKEiz+vBrnjYzCW4ZUgjedin+7o0nsT67m2m 7zjF5qo7jdzqFXlttJCuf4AULFidO2udrE5lrzCGuFOu5GxqLabL3LYPyvXQTETKa8u0sNU+ CJtgsvuyu70a6EQKsztxoOoJxiCE4fLZ9UFhfD0MK+TMV4dUTLzYV8Dz2wTfCnIxDWGszoxR FWSU+Pfh45uLOHYonNRaQFB4OrcWq61HOeJvJ2cIYp0L3LPEEjdVT8IkK9UgPyJHBWLLTwXn NzWz3zDfqqXG2jWlVetvd6Af+dl2reo/sIZIJePTcsHnA1alkpMSLJRZB/PELgaIdlXhEJE8 KGrISX6S/8tcVfQrTR0= --B_3334778854_8975459-- From dromasca@avaya.com Fri Sep 4 01:14:26 2009 Return-Path: X-Original-To: ipfix@core3.amsl.com Delivered-To: ipfix@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 37D973A6965 for ; Fri, 4 Sep 2009 01:14:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.444 X-Spam-Level: X-Spam-Status: No, score=-2.444 tagged_above=-999 required=5 tests=[AWL=0.155, 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 RHq-JUEKldQ1 for ; Fri, 4 Sep 2009 01:14:25 -0700 (PDT) Received: from de307622-de-outbound.net.avaya.com (de307622-de-outbound.net.avaya.com [198.152.71.100]) by core3.amsl.com (Postfix) with ESMTP id 8C4613A683F for ; Fri, 4 Sep 2009 01:14:24 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.44,330,1249272000"; d="scan'208";a="155888346" Received: from unknown (HELO nj300815-nj-erheast.avaya.com) ([198.152.6.5]) by de307622-de-outbound.net.avaya.com with ESMTP; 04 Sep 2009 04:12:24 -0400 Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.16]) by nj300815-nj-erheast-out.avaya.com with ESMTP; 04 Sep 2009 04:12:23 -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: Fri, 4 Sep 2009 10:12:21 +0200 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [IPFIX] IPFIX re-chartering request thread-index: Acon2B+YWibFz1WBS0eXLAaP5MeKoACbSjIAADRuY5AAP0tfTwBIxYLQ References: From: "Romascanu, Dan (Dan)" To: "Juergen Quittek" , "Ronald Bonica" , Cc: IETF IPFIX Working Group Subject: Re: [IPFIX] IPFIX re-chartering request X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Sep 2009 08:14:26 -0000 Thanks. I will correct these on the version that will be sent for external review.=20 Dan =20 > -----Original Message----- > From: Juergen Quittek [mailto:Quittek@nw.neclab.eu]=20 > Sent: Thursday, September 03, 2009 8:05 PM > To: Romascanu, Dan (Dan); Ronald Bonica; ron@bonica.org > Cc: IETF IPFIX Working Group > Subject: Re: [IPFIX] IPFIX re-chartering request >=20 > Hi Dan, >=20 > Brian found two typos in the milestone section. > Two deadlines are in the past: "Jan 2009" should obviously be=20 > "Jan 2010". >=20 > Sorry, >=20 > Juergen=20 >=20 >=20 > On 01.09.09 17:15 "Juergen Quittek" wrote: >=20 > > Hi Dan, > >=20 > > On 31.08.09 16:15 "Dan Romascanu" wrote: > >> Juergen, > >>=20 > >> These look fine to me. > >>=20 > >> Can you please generate a new charter text will all these=20 > changes so=20 > >> that I can distribute it for internal review by the IESG and IAB? > >=20 > > Please find the new charter text below. > >=20 > > Thanks, > >=20 > > Juergen > >=20 > >=20 > > IPFIX charter proposal > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > >=20 > > IP Flow Information Export (ipfix) > >=20 > > Chair(s): > >=20 > > * Nevil Brownlee > > * Juergen Quittek > >=20 > > Operations and Management Area Director(s): > >=20 > > * Dan Romascanu > > * Ronald Bonica > >=20 > > Operations and Management Area Advisor: > >=20 > > * Dan Romascanu > >=20 > > Mailing Lists: > > General Discussion: ipfix@ietf.org > > To Subscribe: http://www.ietf.org/mailman/listinfo/ipfix > > Archive: http://www.ietf.org/mail-archive/web/ipfix > >=20 > > Description of Working Group: > >=20 > > The IPFIX working group has specified the Information Model (to=20 > > describe IP flows) and the IPFIX protocol (to transfer IP flow data=20 > > from IPFIX exporters to collectors). Several implementers=20 > have already=20 > > built applications using the IPFIX protocol. As a result of=20 > a series=20 > > of IPFIX interoperability testing events the WG has produced=20 > > guidelines for IPFIX implementation and testing as well as=20 > > recommendations for handling special cases such as=20 > bidirectional flow=20 > > reporting and reducing redundancy in flow records. > >=20 > > Practical experiences with IPFIX implementations exposed new=20 > > requirements for the IPFIX protocol that so far have not been=20 > > addressed by the WG. The major current goal of the WG is developing=20 > > solutions that meet the new requirements without modifying the core=20 > > IPFIX protocol specifications. > >=20 > > 1. The IPFIX WG has developed a MIB module for monitoring IPFIX=20 > > implementations. Means for configuring these devices have not been=20 > > standardized yet. The WG will develop an XML-based=20 > configuration data=20 > > model that can be used for configuring IPFIX devices and=20 > for storing,=20 > > modifying and managing IPFIX configurations parameter sets.=20 > This work=20 > > will be performed in close collaboration with the NETCONF WG. > >=20 > > 2. First applications of IPFIX at large operator networks=20 > showed the=20 > > need for mediation of flow information, for example, for=20 > aggregating=20 > > huge amounts of flow data and for anomymization of flow information. > > The IPFIX WG will investigate this issue and produce a problem=20 > > statement and a framework for IPFIX flow mediation. > >=20 > > 3. The PSAMP WG has developed a protocol for reporting observed=20 > > packets. The PSAMP protocol is an extension of the IPFIX=20 > protocol. The=20 > > IPFIX WG will develop a MIB module for monitoring PSAMP=20 > > implementations. The new MIB module will be an extension of=20 > the IPFIX=20 > > MIB module. > >=20 > > 4. Anonymization of flow information has been identified as a=20 > > requirement for flow information export already in RFC=20 > 3917. However,=20 > > technologies for flow anonymization are still a research issue and=20 > > have so far not been considered to be mature enough for=20 > standardization. > > As one step in this direction, the IPFIX WG will develop guidelines=20 > > for the implementation of anonymized data export and storage over=20 > > IPFIX and define an information model for configuring and reporting=20 > > anonymization applied at IPFIX devices. > >=20 > > 5. The IPFIX and PSAMP WGs have defined standards for selecting=20 > > observed IP packets and collecting information in flow records. > > In order to reduce the amount of data to be processed, packet=20 > > selection methods have been defined. Another method for=20 > reducing flow=20 > > data is flow selection. The IPFIX WG will define methods for flow=20 > > selection and provide an information model for configuring and=20 > > reporting flow selection applied at IPFIX devices. > >=20 > > 6. Being designed for the export of flow records the IPFIX protocol=20 > > provides very limited means for structuring information elements=20 > > within IPFIX records. With the increasing number of IPFIX=20 > applications=20 > > there is a need for exporting more complex information. The=20 > IPFIX WG=20 > > will develop an extension of the IPFIX protocol that supports=20 > > hierarchically structured data and lists (sequences) of Information=20 > > Elements in data records. > >=20 > > Goals and Milestones: > >=20 > > Oct 2009 Submit Mediation Problem Statement I-D to IESG > > for publication as Informational RFC > > Oct 2009 Submit initial draft on anonymization support > > Oct 2009 Submit initial draft on flow selection > > Oct 2009 Submit initial draft on structuring information elements > > Jan 2009 Submit Configuration Data Model draft to IESG > > for publication as Standards track RFC > > Jan 2009 Submit Mediation Framework I-D to IESG > > for publication as Informational RFC > > Jan 2010 Submit final version of PSAMP MIB module > > Jun 2010 Submit anonymization support I-D to IESG > > for publication as Experimental RFC > > Jun 2010 Submit flow selection I-D to IESG > > for publication as Standards Track RFC > > Jun 2010 Submit structuring information elements I-D to IESG > > for publication as Standards Track RFC=20 > > _______________________________________________ > > IPFIX mailing list > > IPFIX@ietf.org > > https://www.ietf.org/mailman/listinfo/ipfix >=20 From Sujay_Gupta@infosys.com Mon Sep 7 21:46:10 2009 Return-Path: X-Original-To: ipfix@core3.amsl.com Delivered-To: ipfix@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4FBF93A67F9 for ; Mon, 7 Sep 2009 21:46:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.998 X-Spam-Level: X-Spam-Status: No, score=-0.998 tagged_above=-999 required=5 tests=[BAYES_50=0.001, HTML_MESSAGE=0.001, 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 yU70-8ckHs8Q for ; Mon, 7 Sep 2009 21:46:09 -0700 (PDT) Received: from kecgate02.infosys.com (kecgate02.infosys.com [61.95.162.76]) by core3.amsl.com (Postfix) with ESMTP id 968493A6873 for ; Mon, 7 Sep 2009 21:46:08 -0700 (PDT) X-TM-IMSS-Message-ID: <1f328b6b000285cd@kecgate02.infosys.com> Received: from blrkechub03.ad.infosys.com ([10.66.236.43]) by kecgate02.infosys.com ([61.95.162.76]) with ESMTP (TREND IMSS SMTP Service 7.0) id 1f328b6b000285cd ; Tue, 8 Sep 2009 10:13:40 +0530 Received: from BLRKECMBX10.ad.infosys.com ([20.20.20.43]) by blrkechub03.ad.infosys.com ([10.66.236.43]) with mapi; Tue, 8 Sep 2009 10:16:33 +0530 From: Sujay Gupta To: "ipfix@ietf.org" Date: Tue, 8 Sep 2009 10:16:26 +0530 Thread-Topic: Sampler Info IE Thread-Index: AcowP1L10u9F/b+lT5+Jywjmf5PPGQ== Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-cr-puzzleid: {8397B053-32FD-4E63-AF3A-4872BD5A291E} x-cr-hashedpuzzle: hA0= s/A= ACEJ A7yR BaDh CkmC DLS9 DRQI D5wZ Eb6O FxrS HGNr HdGL Hjk7 IHMt J1fM; 1; aQBwAGYAaQB4AEAAaQBlAHQAZgAuAG8AcgBnAA==; Sosha1_v1; 7; {8397B053-32FD-4E63-AF3A-4872BD5A291E}; cwB1AGoAYQB5AF8AZwB1AHAAdABhAEAAaQBuAGYAbwBzAHkAcwAuAGMAbwBtAA==; Tue, 08 Sep 2009 04:46:26 GMT;UwBhAG0AcABsAGUAcgAgAEkAbgBmAG8AIABJAEUA acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_D83DA0FBF870784BAFF69D2B3643A80457B68AC3BLRKECMBX10adin_" MIME-Version: 1.0 Subject: [IPFIX] Sampler Info IE X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Sep 2009 04:47:06 -0000 --_000_D83DA0FBF870784BAFF69D2B3643A80457B68AC3BLRKECMBX10adin_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Group, Do we have a Sampler Config Info IE, in RFC 5102? Where I would like to sen= d the sampler algorithm type/ rate etc.? TIA, -Sujay --_000_D83DA0FBF870784BAFF69D2B3643A80457B68AC3BLRKECMBX10adin_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Group,

 

Do we have a Sampler Config Info IE, in RFC 5102? Wher= e I would like to send the sampler algorithm type/ rate etc.?

 

TIA,

-Sujay

--_000_D83DA0FBF870784BAFF69D2B3643A80457B68AC3BLRKECMBX10adin_-- From muenz@net.in.tum.de Tue Sep 8 01:31: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 B092428C0DB for ; Tue, 8 Sep 2009 01:31:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.811 X-Spam-Level: X-Spam-Status: No, score=-0.811 tagged_above=-999 required=5 tests=[AWL=-1.162, 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 A9JpfevEUTpV for ; Tue, 8 Sep 2009 01:31:47 -0700 (PDT) Received: from mail-out1.informatik.tu-muenchen.de (mail-out1.informatik.tu-muenchen.de [131.159.0.8]) by core3.amsl.com (Postfix) with ESMTP id B46263A693A for ; Tue, 8 Sep 2009 01:31:47 -0700 (PDT) Received: from phoenix.net.informatik.tu-muenchen.de (phoenix.net.in.tum.de [131.159.14.1]) by services.net.informatik.tu-muenchen.de (Postix Mailer @ mail) with ESMTP id 3BA6747CF3; Tue, 8 Sep 2009 10:32:11 +0200 (CEST) Received: from [131.159.20.108] (repulse.net.in.tum.de [131.159.20.108]) by phoenix.net.informatik.tu-muenchen.de (Postfix) with ESMTP id 24DDB54CE; Tue, 8 Sep 2009 10:32:11 +0200 (CEST) Message-ID: <4AA6168C.6040103@net.in.tum.de> Date: Tue, 08 Sep 2009 10:32:12 +0200 From: Gerhard Muenz User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Sujay Gupta References: In-Reply-To: Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms040000020407020307040903" X-Virus-Scanned: ClamAV using ClamSMTP Cc: "ipfix@ietf.org" Subject: Re: [IPFIX] Sampler Info IE X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Sep 2009 08:31:48 -0000 This is a cryptographically signed message in MIME format. --------------ms040000020407020307040903 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable Hi, The reporting of selector parameters and statistics using Options is=20 specified in the PSAMP protocol. See: http://tools.ietf.org/html/rfc5476#section-6.5 Regards, Gerhard Sujay Gupta wrote: > Hi Group, >=20 > =20 >=20 > Do we have a Sampler Config Info IE, in RFC 5102? Where I would like to= =20 > send the sampler algorithm type/ rate etc.? >=20 > =20 >=20 > TIA, >=20 > -Sujay >=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) Technische Universit=E4t M=FCnchen - Department of Informatics Boltzmannstr. 3, 85748 Garching bei M=FCnchen, Germany Phone: +49 89 289-18008 Fax: +49 89 289-18033 E-mail: muenz@net.in.tum.de WWW: http://www.net.in.tum.de/~muenz --------------ms040000020407020307040903 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIJ6TCC Az8wggKooAMCAQICAQ0wDQYJKoZIhvcNAQEFBQAwgdExCzAJBgNVBAYTAlpBMRUwEwYDVQQI EwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEaMBgGA1UEChMRVGhhd3RlIENv bnN1bHRpbmcxKDAmBgNVBAsTH0NlcnRpZmljYXRpb24gU2VydmljZXMgRGl2aXNpb24xJDAi BgNVBAMTG1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBDQTErMCkGCSqGSIb3DQEJARYccGVy c29uYWwtZnJlZW1haWxAdGhhd3RlLmNvbTAeFw0wMzA3MTcwMDAwMDBaFw0xMzA3MTYyMzU5 NTlaMGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBM dGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQTCBnzAN BgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAxKY8VXNV+065yplaHmjAdQRwnd/p/6Me7L3N9Vvy Gna9fww6YfK/Uc4B1OVQCjDXAmNaLIkVcI7dyfArhVqqP3FWy688Cwfn8R+RNiQqE88r1fOC dz0Dviv+uxg+B79AgAJk16emu59l0cUqVIUPSAR/p7bRPGEEQB5kGXJgt/sCAwEAAaOBlDCB kTASBgNVHRMBAf8ECDAGAQH/AgEAMEMGA1UdHwQ8MDowOKA2oDSGMmh0dHA6Ly9jcmwudGhh d3RlLmNvbS9UaGF3dGVQZXJzb25hbEZyZWVtYWlsQ0EuY3JsMAsGA1UdDwQEAwIBBjApBgNV HREEIjAgpB4wHDEaMBgGA1UEAxMRUHJpdmF0ZUxhYmVsMi0xMzgwDQYJKoZIhvcNAQEFBQAD gYEASIzRUIPqCy7MDaNmrGcPf6+svsIXoUOWlJ1/TCG4+DYfqi2fNi/A9BxQIJNwPP2t4WFi w9k6GX6EsZkbAMUaC4J0niVQlGLH2ydxVyWN3amcOY6MIE9lX5Xa9/eH1sYITq726jTlEBpb NU1341YheILcIRk13iSx0x1G/11fZU8wggNPMIICuKADAgECAhAqxerdN2XVRkUZsuk5IKdP MA0GCSqGSIb3DQEBBQUAMGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3Vs dGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNz dWluZyBDQTAeFw0wOTAyMTkxMDI5NDVaFw0xMDAyMTkxMDI5NDVaMIGQMQ4wDAYDVQQEEwVN dWVuejEQMA4GA1UEKhMHR2VyaGFyZDEWMBQGA1UEAxMNR2VyaGFyZCBNdWVuejEwMC4GCSqG SIb3DQEJARYhbXVlbnpAaW5mb3JtYXRpay51bmktdHVlYmluZ2VuLmRlMSIwIAYJKoZIhvcN AQkBFhNtdWVuekBuZXQuaW4udHVtLmRlMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKC AQEAxC8p+6KRpyQyKvT9LAxUB2m8azrci+c5oQUYac2A4WsjoqiCqi2k/wgCrCIHrN0USQeH LmcbtSWT5O+1kMai28KGUdZG5xmJ7PLuLejKlYIu2TkR8tI1Q4gyu1Gs45yn9Rf+EGWmqa/s ebjMV3tc/zrpEN2b1ls8U9rM2/h0NcUUU+g170e8DlXNOL7+bsQD+tLH5G3nlV9mZntMQ68t PaaLG4MtupHuS99YGoo0yB4rzuTxiWRKTJgqjboQL0eS9+6dxsrT01g7sOc2QtXbO45PBnsG Ra5CAMpGLrqGT1ISZIpqYrGuMH9Rv7HTR3rLygL81WMDtNCa6W5/PPMlSwIDAQABo1MwUTBB BgNVHREEOjA4gSFtdWVuekBpbmZvcm1hdGlrLnVuaS10dWViaW5nZW4uZGWBE211ZW56QG5l dC5pbi50dW0uZGUwDAYDVR0TAQH/BAIwADANBgkqhkiG9w0BAQUFAAOBgQBOkMsohjpIH4Mr 33zNnhc5PkzAi0RZ6UAOB28nTtfjVZ25UVLWqmLgYEszbloTd07y5PcUZhSuPuwGzEwn4XdX i3VWl6qk5VcPpyP7+b5XEY5CU1A8cqeaXS88qWyshu1dXm2ToqueRPv+E2b3GJHAciNt2Qfc T4SNWymkvUyPSjCCA08wggK4oAMCAQICECrF6t03ZdVGRRmy6Tkgp08wDQYJKoZIhvcNAQEF BQAwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0 ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA5 MDIxOTEwMjk0NVoXDTEwMDIxOTEwMjk0NVowgZAxDjAMBgNVBAQTBU11ZW56MRAwDgYDVQQq EwdHZXJoYXJkMRYwFAYDVQQDEw1HZXJoYXJkIE11ZW56MTAwLgYJKoZIhvcNAQkBFiFtdWVu ekBpbmZvcm1hdGlrLnVuaS10dWViaW5nZW4uZGUxIjAgBgkqhkiG9w0BCQEWE211ZW56QG5l dC5pbi50dW0uZGUwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDELyn7opGnJDIq 9P0sDFQHabxrOtyL5zmhBRhpzYDhayOiqIKqLaT/CAKsIges3RRJB4cuZxu1JZPk77WQxqLb woZR1kbnGYns8u4t6MqVgi7ZORHy0jVDiDK7UazjnKf1F/4QZaapr+x5uMxXe1z/OukQ3ZvW WzxT2szb+HQ1xRRT6DXvR7wOVc04vv5uxAP60sfkbeeVX2Zme0xDry09posbgy26ke5L31ga ijTIHivO5PGJZEpMmCqNuhAvR5L37p3GytPTWDuw5zZC1ds7jk8GewZFrkIAykYuuoZPUhJk impisa4wf1G/sdNHesvKAvzVYwO00Jrpbn888yVLAgMBAAGjUzBRMEEGA1UdEQQ6MDiBIW11 ZW56QGluZm9ybWF0aWsudW5pLXR1ZWJpbmdlbi5kZYETbXVlbnpAbmV0LmluLnR1bS5kZTAM BgNVHRMBAf8EAjAAMA0GCSqGSIb3DQEBBQUAA4GBAE6QyyiGOkgfgyvffM2eFzk+TMCLRFnp QA4HbydO1+NVnblRUtaqYuBgSzNuWhN3TvLk9xRmFK4+7AbMTCfhd1eLdVaXqqTlVw+nI/v5 vlcRjkJTUDxyp5pdLzypbKyG7V1ebZOiq55E+/4TZvcYkcByI23ZB9xPhI1bKaS9TI9KMYID cTCCA20CAQEwdjBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcg KFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3Vpbmcg Q0ECECrF6t03ZdVGRRmy6Tkgp08wCQYFKw4DAhoFAKCCAdAwGAYJKoZIhvcNAQkDMQsGCSqG SIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMDkwOTA4MDgzMjEyWjAjBgkqhkiG9w0BCQQxFgQU S00kRv9TYHvLn1hPwcOaBfhL7qMwXwYJKoZIhvcNAQkPMVIwUDALBglghkgBZQMEAQIwCgYI KoZIhvcNAwcwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqG SIb3DQMCAgEoMIGFBgkrBgEEAYI3EAQxeDB2MGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxU aGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwg RnJlZW1haWwgSXNzdWluZyBDQQIQKsXq3Tdl1UZFGbLpOSCnTzCBhwYLKoZIhvcNAQkQAgsx eKB2MGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBM dGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQQIQKsXq 3Tdl1UZFGbLpOSCnTzANBgkqhkiG9w0BAQEFAASCAQAyRQ+UIpFo8T04uWqYV5XbxzS0fqvt l2WTm3JOjqxAwMptcWGECG4h33KNfQcnK/gVub9AjbPKtJCe1H+V9FnU+SP5YGjn59Ja0rMH XOkwFRaUavUzQeBDTIt7ZHAs7LMDHglMw1qTivvzIA1GXuC2YGD1lAKjEwtLB1AZyl07GWZc vHT8yoyBfCuGIC2CBj/meNsJSAWkp5rMymslTUwxTwK+4sQZTSRP/R7MhY9O86Xdyi0ymC3d eI3z7LQiw1N6k3ZQbs7k3pAELg+Mxhh/toL2Tx7UOV3YaapEUtqnEU1WSxUa8rAB2k78kcbu xsmHYQJcO70dBNyRKXywP4sTAAAAAAAA --------------ms040000020407020307040903-- From Sujay_Gupta@infosys.com Tue Sep 8 04:39: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 6AE583A6900 for ; Tue, 8 Sep 2009 04:39:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.108 X-Spam-Level: X-Spam-Status: No, score=-2.108 tagged_above=-999 required=5 tests=[AWL=0.491, 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 y-aCS2FEoqIP for ; Tue, 8 Sep 2009 04:39:43 -0700 (PDT) Received: from KECGATE08.infosys.com (Kecgate08.infosysconsulting.com [122.98.10.33]) by core3.amsl.com (Postfix) with ESMTP id 381663A63EC for ; Tue, 8 Sep 2009 04:39:42 -0700 (PDT) X-TM-IMSS-Message-ID: <2096ab050002d5f9@KECGATE08.infosys.com> Received: from blrkechub04.ad.infosys.com ([10.66.236.44]) by KECGATE08.infosys.com ([122.98.10.33]) with ESMTP (TREND IMSS SMTP Service 7.0) id 2096ab050002d5f9 ; Tue, 8 Sep 2009 17:09:44 +0530 Received: from BLRKECMBX10.ad.infosys.com ([20.20.20.43]) by blrkechub04.ad.infosys.com ([10.66.236.44]) with mapi; Tue, 8 Sep 2009 17:10:09 +0530 From: Sujay Gupta To: Gerhard Muenz Date: Tue, 8 Sep 2009 17:10:05 +0530 Thread-Topic: [IPFIX] Sampler Info IE Thread-Index: AcowXuEctVhw38rmTfaLXXIgaAzVpwAGZKMA Message-ID: References: <4AA6168C.6040103@net.in.tum.de> In-Reply-To: <4AA6168C.6040103@net.in.tum.de> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "ipfix@ietf.org" Subject: Re: [IPFIX] Sampler Info IE X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Sep 2009 11:39:44 -0000 Thanks Gerhard, So is there a reason why we don't refer to these elements in the IPFIX RFC? Do I have to read both the specs, to filter out all what's possible? BR, -Sujay -----Original Message----- From: Gerhard Muenz [mailto:muenz@net.in.tum.de]=20 Sent: Tuesday, September 08, 2009 2:02 PM To: Sujay Gupta Cc: ipfix@ietf.org Subject: Re: [IPFIX] Sampler Info IE Hi, The reporting of selector parameters and statistics using Options is=20 specified in the PSAMP protocol. See: http://tools.ietf.org/html/rfc5476#section-6.5 Regards, Gerhard Sujay Gupta wrote: > Hi Group, >=20 > =20 >=20 > Do we have a Sampler Config Info IE, in RFC 5102? Where I would like to=20 > send the sampler algorithm type/ rate etc.? >=20 > =20 >=20 > TIA, >=20 > -Sujay >=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) Technische Universit=E4t M=FCnchen - Department of Informatics Boltzmannstr. 3, 85748 Garching bei M=FCnchen, Germany Phone: +49 89 289-18008 Fax: +49 89 289-18033 E-mail: muenz@net.in.tum.de WWW: http://www.net.in.tum.de/~muenz From trammell@tik.ee.ethz.ch Tue Sep 8 04:57:34 2009 Return-Path: X-Original-To: ipfix@core3.amsl.com Delivered-To: ipfix@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BCB8B3A698E for ; Tue, 8 Sep 2009 04:57:34 -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 VNxDZyUUIoDE for ; Tue, 8 Sep 2009 04:57:33 -0700 (PDT) Received: from smtp.ee.ethz.ch (smtp.ee.ethz.ch [129.132.2.219]) by core3.amsl.com (Postfix) with ESMTP id 9224A3A66B4 for ; Tue, 8 Sep 2009 04:57:33 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by smtp.ee.ethz.ch (Postfix) with ESMTP id E3D5DD939D; Tue, 8 Sep 2009 13:58:01 +0200 (MEST) X-Virus-Scanned: by amavisd-new on smtp.ee.ethz.ch Received: from smtp.ee.ethz.ch ([127.0.0.1]) by localhost (.ee.ethz.ch [127.0.0.1]) (amavisd-new, port 10024) with LMTP id S6oXt5hKbjxU; Tue, 8 Sep 2009 13:58:01 +0200 (MEST) Received: from pb-10072.ethz.ch (pb-10072.ethz.ch [82.130.103.195]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: briant) by smtp.ee.ethz.ch (Postfix) with ESMTP id 83B11D9324; Tue, 8 Sep 2009 13:58:01 +0200 (MEST) Message-Id: <60A0D946-DD71-4D20-B896-00014D5A3044@tik.ee.ethz.ch> From: Brian Trammell To: Sujay Gupta In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed; delsp=yes Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Apple Message framework v936) Date: Tue, 8 Sep 2009 13:58:00 +0200 References: <4AA6168C.6040103@net.in.tum.de> X-Mailer: Apple Mail (2.936) Cc: "ipfix@ietf.org" Subject: Re: [IPFIX] Sampler Info IE X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Sep 2009 11:57:34 -0000 hi, Sujay, When looking for an information element for a given task, the primary =20= reference is the IANA registry, http://www.iana.org/assignments/=20 ipfix/; you can then have a look at the referenced RFCs for more =20 details. 5102 is not intended as a complete reference to all IPFIX =20 IEs, just the "core", as IPFIX was designed to be extensible. =20 Additional IEs have to date been added by other RFCs: 5103, 5477, =20 5610; drafts: RFC-to-be-ipfix-file; as well as directly by Cisco. This =20= list is likely to grow in the future, as well. Hope this helps, best regards, Brian On Sep 8, 2009, at 1:40 PM, Sujay Gupta wrote: > Thanks Gerhard, > > So is there a reason why we don't refer to these elements in the =20 > IPFIX RFC? > Do I have to read both the specs, to filter out all what's possible? > > BR, > -Sujay > > -----Original Message----- > From: Gerhard Muenz [mailto:muenz@net.in.tum.de] > Sent: Tuesday, September 08, 2009 2:02 PM > To: Sujay Gupta > Cc: ipfix@ietf.org > Subject: Re: [IPFIX] Sampler Info IE > > > Hi, > > The reporting of selector parameters and statistics using Options is > specified in the PSAMP protocol. See: > http://tools.ietf.org/html/rfc5476#section-6.5 > > Regards, > Gerhard > > Sujay Gupta wrote: >> Hi Group, >> >> >> >> Do we have a Sampler Config Info IE, in RFC 5102? Where I would =20 >> like to >> send the sampler algorithm type/ rate etc.? >> >> >> >> TIA, >> >> -Sujay >> >> >> = ------------------------------------------------------------------------ >> >> _______________________________________________ >> 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) > Technische Universit=E4t M=FCnchen - Department of Informatics > Boltzmannstr. 3, 85748 Garching bei M=FCnchen, Germany > Phone: +49 89 289-18008 Fax: +49 89 289-18033 > E-mail: muenz@net.in.tum.de WWW: http://www.net.in.tum.de/~muenz > > > _______________________________________________ > IPFIX mailing list > IPFIX@ietf.org > https://www.ietf.org/mailman/listinfo/ipfix From Sujay_Gupta@infosys.com Tue Sep 8 05:14: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 1644C3A6A3C for ; Tue, 8 Sep 2009 05:14:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.472 X-Spam-Level: X-Spam-Status: No, score=-2.472 tagged_above=-999 required=5 tests=[AWL=0.527, BAYES_00=-2.599, J_CHICKENPOX_72=0.6, 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 ZuZVZTSv1ugW for ; Tue, 8 Sep 2009 05:14:12 -0700 (PDT) Received: from kecgate06.infosys.com (kecgate06.infosys.com [61.95.162.82]) by core3.amsl.com (Postfix) with ESMTP id 396723A699D for ; Tue, 8 Sep 2009 05:14:10 -0700 (PDT) X-TM-IMSS-Message-ID: <20c4d7940000076c@kecgate06.infosys.com> Received: from blrkechub04.ad.infosys.com ([10.66.236.44]) by kecgate06.infosys.com ([61.95.162.82]) with ESMTP (TREND IMSS SMTP Service 7.0) id 20c4d7940000076c ; Tue, 8 Sep 2009 17:44:00 +0530 Received: from BLRKECMBX10.ad.infosys.com ([20.20.20.43]) by blrkechub04.ad.infosys.com ([10.66.236.44]) with mapi; Tue, 8 Sep 2009 17:44:36 +0530 From: Sujay Gupta To: Brian Trammell Date: Tue, 8 Sep 2009 17:44:33 +0530 Thread-Topic: [IPFIX] Sampler Info IE Thread-Index: Acowe6BhosAmEZFWQTaeN9EB5lylrwAAYv/g Message-ID: References: <4AA6168C.6040103@net.in.tum.de> <60A0D946-DD71-4D20-B896-00014D5A3044@tik.ee.ethz.ch> In-Reply-To: <60A0D946-DD71-4D20-B896-00014D5A3044@tik.ee.ethz.ch> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "ipfix@ietf.org" Subject: Re: [IPFIX] Sampler Info IE X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Sep 2009 12:14:13 -0000 Thanks=20that=20was=20useful. (It=20would=20be=20nice=20to=20have=20this=20info=20added=20in=20the=20In= troduction=20section(or=20Section=207.1,'IANA=20considerations')=20of=20R= FC5102.) BR, -Sujay -----Original=20Message----- From:=20Brian=20Trammell=20[mailto:trammell@tik.ee.ethz.ch]=20 Sent:=20Tuesday,=20September=2008,=202009=205:28=20PM To:=20Sujay=20Gupta Cc:=20Gerhard=20Muenz;=20ipfix@ietf.org Subject:=20Re:=20[IPFIX]=20Sampler=20Info=20IE hi,=20Sujay, When=20looking=20for=20an=20information=20element=20for=20a=20given=20tas= k,=20the=20primary=20=20 reference=20is=20the=20IANA=20registry,=20http://www.iana.org/assignments= /=20 ipfix/;=20you=20can=20then=20have=20a=20look=20at=20the=20referenced=20RF= Cs=20for=20more=20=20 details.=205102=20is=20not=20intended=20as=20a=20complete=20reference=20t= o=20all=20IPFIX=20=20 IEs,=20just=20the=20"core",=20as=20IPFIX=20was=20designed=20to=20be=20ext= ensible.=20=20 Additional=20IEs=20have=20to=20date=20been=20added=20by=20other=20RFCs:= =205103,=205477,=20=20 5610;=20drafts:=20RFC-to-be-ipfix-file;=20as=20well=20as=20directly=20by= =20Cisco.=20This=20=20 list=20is=20likely=20to=20grow=20in=20the=20future,=20as=20well. Hope=20this=20helps,=20best=20regards, Brian On=20Sep=208,=202009,=20at=201:40=20PM,=20Sujay=20Gupta=20wrote: >=20Thanks=20Gerhard, > >=20So=20is=20there=20a=20reason=20why=20we=20don't=20refer=20to=20these= =20elements=20in=20the=20=20 >=20IPFIX=20RFC? >=20Do=20I=20have=20to=20read=20both=20the=20specs,=20to=20filter=20out= =20all=20what's=20possible? > >=20BR, >=20-Sujay > >=20-----Original=20Message----- >=20From:=20Gerhard=20Muenz=20[mailto:muenz@net.in.tum.de] >=20Sent:=20Tuesday,=20September=2008,=202009=202:02=20PM >=20To:=20Sujay=20Gupta >=20Cc:=20ipfix@ietf.org >=20Subject:=20Re:=20[IPFIX]=20Sampler=20Info=20IE > > >=20Hi, > >=20The=20reporting=20of=20selector=20parameters=20and=20statistics=20usi= ng=20Options=20is >=20specified=20in=20the=20PSAMP=20protocol.=20See: >=20http://tools.ietf.org/html/rfc5476#section-6.5 > >=20Regards, >=20Gerhard > >=20Sujay=20Gupta=20wrote: >>=20Hi=20Group, >> >> >> >>=20Do=20we=20have=20a=20Sampler=20Config=20Info=20IE,=20in=20RFC=205102= ?=20Where=20I=20would=20=20 >>=20like=20to >>=20send=20the=20sampler=20algorithm=20type/=20rate=20etc.? >> >> >> >>=20TIA, >> >>=20-Sujay >> >> >>=20--------------------------------------------------------------------= ---- >> >>=20_______________________________________________ >>=20IPFIX=20mailing=20list >>=20IPFIX@ietf.org >>=20https://www.ietf.org/mailman/listinfo/ipfix > >=20--=20 >=20Dipl.-Ing.=20Gerhard=20M=FCnz >=20Chair=20for=20Network=20Architectures=20and=20Services=20(I8) >=20Technische=20Universit=E4t=20M=FCnchen=20-=20Department=20of=20Inform= atics >=20Boltzmannstr.=203,=2085748=20Garching=20bei=20M=FCnchen,=20Germany >=20Phone:=20=20+49=2089=20289-18008=20=20=20=20=20=20=20Fax:=20+49=2089= =20289-18033 >=20E-mail:=20muenz@net.in.tum.de=20=20=20=20WWW:=20http://www.net.in.tum= .de/~muenz > > >=20_______________________________________________ >=20IPFIX=20mailing=20list >=20IPFIX@ietf.org >=20https://www.ietf.org/mailman/listinfo/ipfix ****************=20CAUTION=20-=20Disclaimer=20***************** This=20e-mail=20contains=20PRIVILEGED=20AND=20CONFIDENTIAL=20INFORMATION= =20intended=20solely=20 for=20the=20use=20of=20the=20addressee(s).=20If=20you=20are=20not=20the= =20intended=20recipient,=20please=20 notify=20the=20sender=20by=20e-mail=20and=20delete=20the=20original=20mes= sage.=20Further,=20you=20are=20not=20 to=20copy,=20disclose,=20or=20distribute=20this=20e-mail=20or=20its=20con= tents=20to=20any=20other=20person=20and=20 any=20such=20actions=20are=20unlawful.=20This=20e-mail=20may=20contain=20= viruses.=20Infosys=20has=20taken=20 every=20reasonable=20precaution=20to=20minimize=20this=20risk,=20but=20is= =20not=20liable=20for=20any=20damage=20 you=20may=20sustain=20as=20a=20result=20of=20any=20virus=20in=20this=20e-= mail.=20You=20should=20carry=20out=20your=20 own=20virus=20checks=20before=20opening=20the=20e-mail=20or=20attachment.= =20Infosys=20reserves=20the=20 right=20to=20monitor=20and=20review=20the=20content=20of=20all=20messages= =20sent=20to=20or=20from=20this=20e-mail=20 address.=20Messages=20sent=20to=20or=20from=20this=20e-mail=20address=20m= ay=20be=20stored=20on=20the=20 Infosys=20e-mail=20system. ***INFOSYS********=20End=20of=20Disclaimer=20********INFOSYS*** From muenz@net.in.tum.de Tue Sep 8 05:26:21 2009 Return-Path: X-Original-To: ipfix@core3.amsl.com Delivered-To: ipfix@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EB05F3A68AE for ; Tue, 8 Sep 2009 05:26:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.047 X-Spam-Level: X-Spam-Status: No, score=-2.047 tagged_above=-999 required=5 tests=[AWL=0.202, 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 fTn-GoeSKE6G for ; Tue, 8 Sep 2009 05:26:21 -0700 (PDT) Received: from mail-out1.informatik.tu-muenchen.de (mail-out1.informatik.tu-muenchen.de [131.159.0.8]) by core3.amsl.com (Postfix) with ESMTP id B6FCE3A681E for ; Tue, 8 Sep 2009 05:26:20 -0700 (PDT) Received: from phoenix.net.informatik.tu-muenchen.de (phoenix.net.in.tum.de [131.159.14.1]) by services.net.informatik.tu-muenchen.de (Postix Mailer @ mail) with ESMTP id C98A547CF3; Tue, 8 Sep 2009 14:26:42 +0200 (CEST) Received: from [131.159.20.108] (repulse.net.in.tum.de [131.159.20.108]) by phoenix.net.informatik.tu-muenchen.de (Postfix) with ESMTP id B79EF50B1; Tue, 8 Sep 2009 14:26:42 +0200 (CEST) Message-ID: <4AA64D85.2090809@net.in.tum.de> Date: Tue, 08 Sep 2009 14:26:45 +0200 From: Gerhard Muenz User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Sujay Gupta References: <4AA6168C.6040103@net.in.tum.de> In-Reply-To: Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms080406020603010401040405" X-Virus-Scanned: ClamAV using ClamSMTP Cc: "ipfix@ietf.org" Subject: Re: [IPFIX] Sampler Info IE X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Sep 2009 12:26:22 -0000 This is a cryptographically signed message in MIME format. --------------ms080406020603010401040405 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable Sujay, For newbies, the scattering of IPFIX/PSAMP information in various RFCs=20 may appear arbitrary. However, the historical reason is that IPFIX and=20 PSAMP were separate working groups. As a result, IPFIX did not specify=20 anything which was related to packet selection. This work was left to=20 PSAMP. Now, the PSAMP working group has been closed, which means that=20 future work on sampling and filtering will be conducted under the=20 umbrella of the IPFIX working group. As Brian told you, all standard IEs can be found in the IANA registry.=20 The usage of IEs in specific reports (i.e., Options), however, is=20 explained in the corresponding RFCs. Regards, Gerhard Sujay Gupta wrote: > Thanks Gerhard, >=20 > So is there a reason why we don't refer to these elements in the IPFIX = RFC? > Do I have to read both the specs, to filter out all what's possible? >=20 > BR, > -Sujay >=20 > -----Original Message----- > From: Gerhard Muenz [mailto:muenz@net.in.tum.de]=20 > Sent: Tuesday, September 08, 2009 2:02 PM > To: Sujay Gupta > Cc: ipfix@ietf.org > Subject: Re: [IPFIX] Sampler Info IE >=20 >=20 > Hi, >=20 > The reporting of selector parameters and statistics using Options is=20 > specified in the PSAMP protocol. See: > http://tools.ietf.org/html/rfc5476#section-6.5 >=20 > Regards, > Gerhard >=20 > Sujay Gupta wrote: >> Hi Group, >> >> =20 >> >> Do we have a Sampler Config Info IE, in RFC 5102? Where I would like t= o=20 >> send the sampler algorithm type/ rate etc.? >> >> =20 >> >> TIA, >> >> -Sujay >> >> >> ----------------------------------------------------------------------= -- >> >> _______________________________________________ >> IPFIX mailing list >> IPFIX@ietf.org >> https://www.ietf.org/mailman/listinfo/ipfix >=20 --=20 Dipl.-Ing. Gerhard M=FCnz Chair for Network Architectures and Services (I8) Technische Universit=E4t M=FCnchen - Department of Informatics Boltzmannstr. 3, 85748 Garching bei M=FCnchen, Germany Phone: +49 89 289-18008 Fax: +49 89 289-18033 E-mail: muenz@net.in.tum.de WWW: http://www.net.in.tum.de/~muenz --------------ms080406020603010401040405 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIJ6TCC Az8wggKooAMCAQICAQ0wDQYJKoZIhvcNAQEFBQAwgdExCzAJBgNVBAYTAlpBMRUwEwYDVQQI EwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEaMBgGA1UEChMRVGhhd3RlIENv bnN1bHRpbmcxKDAmBgNVBAsTH0NlcnRpZmljYXRpb24gU2VydmljZXMgRGl2aXNpb24xJDAi BgNVBAMTG1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBDQTErMCkGCSqGSIb3DQEJARYccGVy c29uYWwtZnJlZW1haWxAdGhhd3RlLmNvbTAeFw0wMzA3MTcwMDAwMDBaFw0xMzA3MTYyMzU5 NTlaMGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBM dGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQTCBnzAN BgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAxKY8VXNV+065yplaHmjAdQRwnd/p/6Me7L3N9Vvy Gna9fww6YfK/Uc4B1OVQCjDXAmNaLIkVcI7dyfArhVqqP3FWy688Cwfn8R+RNiQqE88r1fOC dz0Dviv+uxg+B79AgAJk16emu59l0cUqVIUPSAR/p7bRPGEEQB5kGXJgt/sCAwEAAaOBlDCB kTASBgNVHRMBAf8ECDAGAQH/AgEAMEMGA1UdHwQ8MDowOKA2oDSGMmh0dHA6Ly9jcmwudGhh d3RlLmNvbS9UaGF3dGVQZXJzb25hbEZyZWVtYWlsQ0EuY3JsMAsGA1UdDwQEAwIBBjApBgNV HREEIjAgpB4wHDEaMBgGA1UEAxMRUHJpdmF0ZUxhYmVsMi0xMzgwDQYJKoZIhvcNAQEFBQAD gYEASIzRUIPqCy7MDaNmrGcPf6+svsIXoUOWlJ1/TCG4+DYfqi2fNi/A9BxQIJNwPP2t4WFi w9k6GX6EsZkbAMUaC4J0niVQlGLH2ydxVyWN3amcOY6MIE9lX5Xa9/eH1sYITq726jTlEBpb NU1341YheILcIRk13iSx0x1G/11fZU8wggNPMIICuKADAgECAhAqxerdN2XVRkUZsuk5IKdP MA0GCSqGSIb3DQEBBQUAMGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3Vs dGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNz dWluZyBDQTAeFw0wOTAyMTkxMDI5NDVaFw0xMDAyMTkxMDI5NDVaMIGQMQ4wDAYDVQQEEwVN dWVuejEQMA4GA1UEKhMHR2VyaGFyZDEWMBQGA1UEAxMNR2VyaGFyZCBNdWVuejEwMC4GCSqG SIb3DQEJARYhbXVlbnpAaW5mb3JtYXRpay51bmktdHVlYmluZ2VuLmRlMSIwIAYJKoZIhvcN AQkBFhNtdWVuekBuZXQuaW4udHVtLmRlMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKC AQEAxC8p+6KRpyQyKvT9LAxUB2m8azrci+c5oQUYac2A4WsjoqiCqi2k/wgCrCIHrN0USQeH LmcbtSWT5O+1kMai28KGUdZG5xmJ7PLuLejKlYIu2TkR8tI1Q4gyu1Gs45yn9Rf+EGWmqa/s ebjMV3tc/zrpEN2b1ls8U9rM2/h0NcUUU+g170e8DlXNOL7+bsQD+tLH5G3nlV9mZntMQ68t PaaLG4MtupHuS99YGoo0yB4rzuTxiWRKTJgqjboQL0eS9+6dxsrT01g7sOc2QtXbO45PBnsG Ra5CAMpGLrqGT1ISZIpqYrGuMH9Rv7HTR3rLygL81WMDtNCa6W5/PPMlSwIDAQABo1MwUTBB BgNVHREEOjA4gSFtdWVuekBpbmZvcm1hdGlrLnVuaS10dWViaW5nZW4uZGWBE211ZW56QG5l dC5pbi50dW0uZGUwDAYDVR0TAQH/BAIwADANBgkqhkiG9w0BAQUFAAOBgQBOkMsohjpIH4Mr 33zNnhc5PkzAi0RZ6UAOB28nTtfjVZ25UVLWqmLgYEszbloTd07y5PcUZhSuPuwGzEwn4XdX i3VWl6qk5VcPpyP7+b5XEY5CU1A8cqeaXS88qWyshu1dXm2ToqueRPv+E2b3GJHAciNt2Qfc T4SNWymkvUyPSjCCA08wggK4oAMCAQICECrF6t03ZdVGRRmy6Tkgp08wDQYJKoZIhvcNAQEF BQAwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0 ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA5 MDIxOTEwMjk0NVoXDTEwMDIxOTEwMjk0NVowgZAxDjAMBgNVBAQTBU11ZW56MRAwDgYDVQQq EwdHZXJoYXJkMRYwFAYDVQQDEw1HZXJoYXJkIE11ZW56MTAwLgYJKoZIhvcNAQkBFiFtdWVu ekBpbmZvcm1hdGlrLnVuaS10dWViaW5nZW4uZGUxIjAgBgkqhkiG9w0BCQEWE211ZW56QG5l dC5pbi50dW0uZGUwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDELyn7opGnJDIq 9P0sDFQHabxrOtyL5zmhBRhpzYDhayOiqIKqLaT/CAKsIges3RRJB4cuZxu1JZPk77WQxqLb woZR1kbnGYns8u4t6MqVgi7ZORHy0jVDiDK7UazjnKf1F/4QZaapr+x5uMxXe1z/OukQ3ZvW WzxT2szb+HQ1xRRT6DXvR7wOVc04vv5uxAP60sfkbeeVX2Zme0xDry09posbgy26ke5L31ga ijTIHivO5PGJZEpMmCqNuhAvR5L37p3GytPTWDuw5zZC1ds7jk8GewZFrkIAykYuuoZPUhJk impisa4wf1G/sdNHesvKAvzVYwO00Jrpbn888yVLAgMBAAGjUzBRMEEGA1UdEQQ6MDiBIW11 ZW56QGluZm9ybWF0aWsudW5pLXR1ZWJpbmdlbi5kZYETbXVlbnpAbmV0LmluLnR1bS5kZTAM BgNVHRMBAf8EAjAAMA0GCSqGSIb3DQEBBQUAA4GBAE6QyyiGOkgfgyvffM2eFzk+TMCLRFnp QA4HbydO1+NVnblRUtaqYuBgSzNuWhN3TvLk9xRmFK4+7AbMTCfhd1eLdVaXqqTlVw+nI/v5 vlcRjkJTUDxyp5pdLzypbKyG7V1ebZOiq55E+/4TZvcYkcByI23ZB9xPhI1bKaS9TI9KMYID cTCCA20CAQEwdjBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcg KFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3Vpbmcg Q0ECECrF6t03ZdVGRRmy6Tkgp08wCQYFKw4DAhoFAKCCAdAwGAYJKoZIhvcNAQkDMQsGCSqG SIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMDkwOTA4MTIyNjQ1WjAjBgkqhkiG9w0BCQQxFgQU O/Ki9jCuwv4MEBIwEa8BSAziCqEwXwYJKoZIhvcNAQkPMVIwUDALBglghkgBZQMEAQIwCgYI KoZIhvcNAwcwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqG SIb3DQMCAgEoMIGFBgkrBgEEAYI3EAQxeDB2MGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxU aGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwg RnJlZW1haWwgSXNzdWluZyBDQQIQKsXq3Tdl1UZFGbLpOSCnTzCBhwYLKoZIhvcNAQkQAgsx eKB2MGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBM dGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQQIQKsXq 3Tdl1UZFGbLpOSCnTzANBgkqhkiG9w0BAQEFAASCAQAjKjRZnJ9zHrKkrfShUCXvni3qg0zy sA/rck9U5WGcEJ+SdZbrwBcwR+5kW3HX4TJQU51rXgOlz3HrP6hV5lhXGPgPKCqzGfVzOu6u /K8m8bn00YTMDPnd4S3lhfKp7iLpCmmTeYM5Y/uQ+GyDX4XNeGDKKcC4ixhyDiOO/OXmDgJ5 8TMOVu544E35s1bnqZDzbzc517S9lTUWMc/UQXfn7/kjRIUykRnhmAW+/6czXPcnNc/icHqY RFvv45JF4nAk57j8nYapPsb/TYIpEu+5dsY9G3iwgkCJbJUBl4ZRVoFpwKvOP/7zKonOwgAK F0Tc9k4vOUxlMiQ1N/p2G9IIAAAAAAAA --------------ms080406020603010401040405-- From n.brownlee@auckland.ac.nz Wed Sep 9 21:35:57 2009 Return-Path: X-Original-To: ipfix@core3.amsl.com Delivered-To: ipfix@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E2A9C3A68A9 for ; Wed, 9 Sep 2009 21:35:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.926 X-Spam-Level: X-Spam-Status: No, score=-5.926 tagged_above=-999 required=5 tests=[AWL=0.673, 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 iPFoxjf-+IRW for ; Wed, 9 Sep 2009 21:35:56 -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 6854B3A684B for ; Wed, 9 Sep 2009 21:35:54 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by mailhost.auckland.ac.nz (Postfix) with ESMTP id B3B76171C7A for ; Thu, 10 Sep 2009 16:36:17 +1200 (NZST) X-Virus-Scanned: by amavisd-new at mailhost.auckland.ac.nz Received: from mailhost.auckland.ac.nz ([127.0.0.1]) by localhost (moe.its.auckland.ac.nz [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SA-nUROb500O for ; Thu, 10 Sep 2009 16:36:17 +1200 (NZST) Received: from nevil-laptop.sfac.auckland.ac.nz (nevil-laptop.sfac.auckland.ac.nz [130.216.38.130]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailhost.auckland.ac.nz (Postfix) with ESMTP id 6639417063E for ; Thu, 10 Sep 2009 16:36:15 +1200 (NZST) Message-ID: <4AA8823F.2030303@auckland.ac.nz> Date: Thu, 10 Sep 2009 16:36:15 +1200 From: Nevil Brownlee User-Agent: Thunderbird 2.0.0.12 (Macintosh/20080213) MIME-Version: 1.0 To: IPFIX Working Group Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [IPFIX] [Fwd: FW: Nomcom 2009-10: Important Reminder: Call for Nominations, Local Office hours, Nominee Questionnaires available] X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Sep 2009 04:35:58 -0000 Hi all: NomCom are looking for more input - if you can take s little time to help them, that would be much appreciated. Cheers, Nevil -------- Original Message -------- Subject: FW: Nomcom 2009-10: Important Reminder: Call for Nominations, Local Office hours, Nominee Questionnaires available Date: Wed, 9 Sep 2009 09:46:38 -0500 From: Mary Barnes To: Working Group Chairs Hi all, Thanks to the ADs and chairs that forwarded the previous reminder to their mailing lists. I would appreciate it if other chairs and ADs could do so, since we are really in need of more nominations. Thanks, Mary. -----Original Message----- From: ietf-announce-bounces@ietf.org [mailto:ietf-announce-bounces@ietf.org] On Behalf Of Barnes, Mary (RICH2:AR00) Sent: Wednesday, September 09, 2009 9:38 AM To: IETF Announcement list Cc: ietf@ietf.org Subject: Nomcom 2009-10: Important Reminder: Call for Nominations, Local Office hours, Nominee Questionnaires available Hi all, This is a 2nd reminder of the Call for Nominations that is underway. We *really* need more nominations in order to properly execute the task of selecting candidates for the open positions. At this time, the number of nominations for all the positions is about 1/2 of what is necessary for the Nomcom to do a conscientious job of evaluating the nominees and we are over 2/3 of the way through the nominations period. Nomcom cannot do their job without this important input from the community. So, please consider making nominations for the open positions - it takes just a few minutes of your time - the details are below. Right now, we just need the names/email addresses for the nominees - we'll be soliciting feedback later. Also, consider that over 1/2 the nominees are not able to accept the nominations for a variety of reasons - e.g., lack of funding, lack of sponsor support, etc. Thus, please consider nominating more than one individual for each of the positions. As well as the reminder for the call for nominations, this email also serves as a reminder for: 2) Local Office Hours 3) Questionnaires available for nominees Best Regards, Mary Barnes nomcom-chair@ietf.org mary.h.barnes@gmail.com mary.barnes@nortel.com ======================================================================== = 1) Call for Nominations ------------------------ The nomination period ends in less than 2 weeks on Sept. 18th, 2009. We appreciate the folks that have taken the time to make nominations thus far. But, we do need more nominations. Please use the online tool to nominate - it's fast, easy and secure: https://wiki.tools.ietf.org/group/nomcom/09/nominate Details on the open positions, as well as other details and options for making nominations are available on the Nomcom homepage: https://wiki.tools.ietf.org/group/nomcom/09/ Please consider that the sooner you make the nominations, the more time your nominee(s) will have to complete the necessary questionnaire (item 3 below). As well, please consider nominating more than one person for a particular position. You will have the opportunity to provide additional feedback later and it's important to consider that not all nominees will be able to accept the nomination. 2) Local office hours ----------------------- In order facilitate additional feedback, the Nomcom has decided to make themselves available for office areas at various geographic locations for 3 weeks in September, starting on the 8th. Below please find the list of locations where Nomcom members will be available for these f2f meetings . Unless dates are identified below, the Nomcom member is generally available for part of the day during the weeks of Sept 8-11, Sept 14-18 and Sept 21-25. Also, languages other than English in which the Nomcom member is fluent are identfied. Please contact a Nomcom member in a specific geographic location to arrange a convenient meeting time and place. Most Nomcom members are flexible as to meeting locations - i.e., we can travel to your office, meet at our offices or somewhere in between. As a reminder folks can always contact any Nomcom member to provide feedback at anytime - i.e., you don't need to participate in these f2f sessions to provide feedback. Belgium: Dimitri Papadimitriou - dimitri.papadimitriou@alcatel-lucent.be (Sept 21-25) (Languages: French) Boston, Mass, USA: Stephen Kent - kent@bbn.com (Sept 16-18) Boulder, CO, USA: Wassim Haddad - wmhaddad@gmail.com (Sept 14-18) Dallas/Ft. Worth, TX, USA: Mary Barnes - mary.h.barnes@gmail.com Lucy Yong - lucyyong@huawei.com (Languages: Chinese) Helsinki, Finland: Simo Veikkolainen - simo.veikkolainen@nokia.com (Languages: Finnish) Ithaca, NY, USA: Scott Brim - scott.brim@gmail.com Montevideo, Uruguay: Roque Gagliano - roque@lacnic.net (Sept 14-18, 21-25) (Languages: Spanish, Portuguese) Montreal, Quebec, Canada Wassim Haddad - wmhaddad@gmail.com (Sept 8-11) -- Can also be available in Ottawa if folks are interested Paris, France: Dimitri Papadimitriou - dimitri.papadimitriou@alcatel-lucent.be (Sept 15-18) (Languages: French) San Diego, CA, USA: Randall Gellens - rg+ietf@qualcomm.com Dave Crocker - dcrocker@bbiw.net (Sept 16-18) Silicon Valley/SF Bay, CA, USA: Dave Crocker - dcrocker@bbiw.net (Sept 8-11, Sept 14-15, Sept 21-25) Dorothy Gellert - Dorothy.gellert@gmail.com 3) Questionnaires available for nominees: For folks that have been notified that they have been nominated for any of the positions, the questionnaires are now available on the Nomcom09 tools website: https://wiki.tools.ietf.org/group/nomcom/09/iab-questionnaire https://wiki.tools.ietf.org/group/nomcom/09/iaoc-questionnaire https://wiki.tools.ietf.org/group/nomcom/09/iesg-questionnaire If you have any questions, please let me know. I will be contacting everyone individually, as well as sending reminders. _______________________________________________ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce -- --------------------------------------------------------------------- Nevil Brownlee Computer Science Department | ITS Phone: +64 9 373 7599 x88941 The University of Auckland FAX: +64 9 373 7453 Private Bag 92019, Auckland 1142, New Zealand From root@core3.amsl.com Tue Sep 15 11: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 8606D28C169; Tue, 15 Sep 2009 11:00:01 -0700 (PDT) From: IESG Secretary To: ietf-announce@ietf.org Content-Type: text/plain; charset="utf-8" Mime-Version: 1.0 Message-Id: <20090915180001.8606D28C169@core3.amsl.com> Date: Tue, 15 Sep 2009 11:00:01 -0700 (PDT) Cc: n.brownlee@auckland.ac.nz, ipfix@ietf.org, quittek@netlab.nec.de Subject: [IPFIX] WG Review: Recharter of IP Flow Information Export (ipfix) X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: iesg@ietf.org List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Sep 2009 18:00:01 -0000 A modified charter has been submitted for the IP Flow Information Export (ipfix) working group in the Operations and Management Area of the IETF. The IESG has not made any determination as yet. The modified charter is provided below for informational purposes only. Please send your comments to the IESG mailing list (iesg@ietf.org) by Tuesday, September 22, 2009 IP Flow Information Export (ipfix) -------------------------------------------- Current Status: Active Working Group Last Modified: 2009-09-01 Chair(s): * Nevil Brownlee (n.brownlee@auckland.ac.nz) * Juergen Quittek (quittek@netlab.nec.de) Operations and Management Area Director(s): * Dan Romascanu (dromasca@avaya.com) * Ronald Bonica (rbonica@juniper.net) Operations and Management Area Advisor: * Dan Romascanu (dromasca@avaya.com) Mailing Lists: General Discussion: ipfix@ietf.org To Subscribe: http://www.ietf.org/mailman/listinfo/ipfix Archive: http://www.ietf.org/mail-archive/web/ipfix Description of Working Group: The IPFIX working group has specified the Information Model (to describe IP flows) and the IPFIX protocol (to transfer IP flow data from IPFIX exporters to collectors). Several implementers have already built applications using the IPFIX protocol. As a result of a series of IPFIX interoperability testing events the WG has produced guidelines for IPFIX implementation and testing as well as recommendations for handling special cases such as bidirectional flow reporting and reducing redundancy in flow records. Practical experiences with IPFIX implementations exposed new requirements for the IPFIX protocol that so far have not been addressed by the WG. The major current goal of the WG is developing solutions that meet the new requirements without modifying the core IPFIX protocol specifications. 1. The IPFIX WG has developed a MIB module for monitoring IPFIX implementations. Means for configuring these devices have not been standardized yet. The WG will develop an XML-based configuration data model that can be used for configuring IPFIX devices and for storing, modifying and managing IPFIX configurations parameter sets. This work will be performed in close collaboration with the NETCONF WG. 2. First applications of IPFIX at large operator networks showed the need for mediation of flow information, for example, for aggregating huge amounts of flow data and for anomymization of flow information. The IPFIX WG will investigate this issue and produce a problem Statement and a framework for IPFIX flow mediation. 3. The PSAMP WG has developed a protocol for reporting observed packets. The PSAMP protocol is an extension of the IPFIX protocol. The IPFIX WG will develop a MIB module for monitoring PSAMP implementations. The new MIB module will be an extension of the IPFIX MIB module. 4. Anonymization of flow information has been identified as a requirement for flow information export already in RFC 3917. However, technologies for flow anonymization are still a research issue and have so far not been considered to be mature enough for standardization. As one step in this direction, the IPFIX WG will develop guidelines for the implementation of anonymized data export and storage over IPFIX and define an information model for configuring and reporting anonymization applied at IPFIX devices. 5. The IPFIX and PSAMP WGs have defined standards for selecting observed IP packets and collecting information in flow records. In order to reduce the amount of data to be processed, packet selection methods have been defined. Another method for reducing flow data is flow selection. The IPFIX WG will define methods for flow selection and provide an information model for configuring and reporting flow selection applied at IPFIX devices. 6. Being designed for the export of flow records the IPFIX protocol provides very limited means for structuring information elements within IPFIX records. With the increasing number of IPFIX applications there is a need for exporting more complex information. The IPFIX WG will develop an extension of the IPFIX protocol that supports hierarchically structured data and lists (sequences) of Information Elements in data records. Goals and Milestones: Oct 2009 Submit Mediation Problem Statement I-D to IESG for publication as Informational RFC Oct 2009 Submit initial draft on anonymization support Oct 2009 Submit initial draft on flow selection Oct 2009 Submit initial draft on structuring information elements Jan 2010 Submit Configuration Data Model draft to IESG for publication as Standards track RFC Jan 2010 Submit Mediation Framework I-D to IESG for publication as Informational RFC Jan 2010 Submit final version of PSAMP MIB module Jun 2010 Submit anonymization support I-D to IESG for publication as Experimental RFC Jun 2010 Submit flow selection I-D to IESG for publication as Standards Track RFC Jun 2010 Submit structuring information elements I-D to IESG for publication as Standards Track RFC From ericko0@yahoo.com Thu Sep 17 23:33:40 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 723533A67EC for ; Thu, 17 Sep 2009 23:33:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.298 X-Spam-Level: X-Spam-Status: No, score=-2.298 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_35=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BeMmMm+UUoFH for ; Thu, 17 Sep 2009 23:33:39 -0700 (PDT) Received: from web45508.mail.sp1.yahoo.com (web45508.mail.sp1.yahoo.com [68.180.197.116]) by core3.amsl.com (Postfix) with SMTP id 072CE3A6AA3 for ; Thu, 17 Sep 2009 23:33:39 -0700 (PDT) Received: (qmail 84565 invoked by uid 60001); 18 Sep 2009 06:34:28 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1253255668; bh=YcdjeFFvA8iz2He0JXzPzkGNFtJ+Mffgfk4wEn0DLb8=; h=Message-ID:X-YMail-OSG:Received:X-Mailer:References:Date:From:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=RWC5dxByG6EjP4el8AExZLilTGwdERRIIMOtUMCmFP4Y2yr9yUKkTe7/GAT6fUV6DjwNvaqB/cR5ntIHKGnOIUENJOoJX+UDGzoAyazp0NomdW4rSCjm0dMgBmMpu9xstgSw/J/5PnXCq7bloIjzu/42Sl1537ilm3196kvP+2Q= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:X-YMail-OSG:Received:X-Mailer:References:Date:From:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=ubFNVE1NxdWAE+xETN66k9CZLDcLNwIRRY8qQmUrlqU60lbeZPjAW9I0IELuICZAltTIQgChY81DCavMSRgaRj8KB30XGLs9ezY2G7VxTMHzAh8e47vYEsmG216YRkkrxPv288SXJUs26kmkbx/6QkR2kLKPhw8yfBAkBuM0jic=; Message-ID: <587230.84105.qm@web45508.mail.sp1.yahoo.com> X-YMail-OSG: oHADBLAVM1mmsg3A.6UvOWC9G5G3A6jX4mRmLqxUHQgLW7_.b5nOvJ5xpOkYDH.rSrfs.ZiF9aA_28aZWMTnCmfgzDajixYNE5R7qqibTBoM6vy7OHPLM_ryHEEVJ5yojxFoMuNXh.7Ot0vdWI0zrmIATdQLKE7sK0.bUsdxrHv5XSCj46vEtrGmV37COuAMo3o.jFMazLTQRUHSyy..R8c54sqOcnnO0SXRP06WYHKQsGQiWl8- Received: from [68.106.217.192] by web45508.mail.sp1.yahoo.com via HTTP; Thu, 17 Sep 2009 23:34:27 PDT X-Mailer: YahooMailRC/157.18 YahooMailWebService/0.7.347.2 References: <4A6EB9BB.9040002@net.in.tum.de> <000401ca111a$3bb01da0$0601a8c0@allison> Date: Thu, 17 Sep 2009 23:34:27 -0700 (PDT) From: Erick O To: "tom.petch" , Gerhard Muenz , syslog@ietf.org, ipfix@ietf.org, tls@ietf.org In-Reply-To: <000401ca111a$3bb01da0$0601a8c0@allison> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="0-1333662422-1253255667=:84105" X-Mailman-Approved-At: Fri, 18 Sep 2009 00:21:58 -0700 Cc: Michael Tuexen , Daniel Mentz Subject: Re: [IPFIX] [TLS] [Syslog] Missing dead peer detection in DTLS X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Sep 2009 06:33:40 -0000 --0-1333662422-1253255667=:84105 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable =0A=0A=0A=0A=0A________________________________=0AFrom: tom.petch =0ATo: Gerhard Muenz ; syslog@ietf.org; = ipfix@ietf.org; tls@ietf.org=0ACc: Michael Tuexen ; = Daniel Mentz =0ASent: Thursday, July 30, 2009 2:44:11 AM= =0ASubject: Re: [TLS] [Syslog] Missing dead peer detection in DTLS=0A=0AGer= hard=0A=0AThank you for pointing this out; it had escaped me.=0A=0AWhat I h= ad thought though was that the lack of flow control with DTLS over UDP=0Ais= a problem, and that the lack of this with syslog over UDP led the syslog R= FC=0A[RFC5424] to make syslog over TLS the RECOMMENDED transport, not, as m= ight be=0Aexpected, syslog over UDP.=0A=0AThis in turn led me to expect tha= t syslog over DTLS over UDP would not be=0Aacceptable to the IESG, rather t= hat syslog over DTLS over SCTP would become the=0ARECOMMENDED transport.=0A= =0ASo; several thoughts.=0A=0AThis is an update to the extensions RFC, RFC4= 366, which itself is being updated=0Aby the TLS working group (hence my add= ition of them to the list) and I would=0Amuch rather have one extensions RF= C rather than several.=A0 This is a good concept=0Aand fills a need; perhap= s the TLS working group would take this on.=0A=0AFlow control remains an is= sue which I do not think that this extension=0Aaddresses.=0A=0AIs this a se= curity exposure? or just, like syslog over UDP, an inconvenient=0Atruth?=0A= =0AThe petch-gerhards draft allows the recipient of the unidirectional flow= to=0Ainitiate the DTLS 'connection', and so enables it to re-establish the= connection=0Awhen anything goes wrong.=A0 This would seem an alternative t= o consider.=0A=0ATom Petch=0A=0A----- Original Message -----=0AFrom: "Gerha= rd Muenz" =0ATo: ; = =0ACc: "Michael Tuexen" ; "Robin Seggelmann"=0A; "Daniel Mentz" =0ASent: Tuesday, J= uly 28, 2009 10:41 AM=0ASubject: [Syslog] Missing dead peer detection in DT= LS=0A=0A=0AHi,=0A=0AThis mail goes to the ipfix and syslog mailing lists in= order to=0Asummarize the common issues regarding DTLS.=0A=0AIPFIX specifie= s support of DTLS as mandatory for transport over UDP and=0ASCTP in RFC5101= . In SYSLOG, it is intended to standardize DTLS for=0Atransport over UDP.= =0A=0AIn IPFIX, we have a first implementation of IPFIX-over-DTLS/UDP, and = we=0Awill have a first implementation of IPFIX-over-DTLS/SCTP very soon.=0A= During this implementation effort, we found that the current=0Aspecificatio= n of DTLS/UDP has a severe flaw when used with=0Aunidirectional protocols (= like IPFIX): The sender cannot recognize if=0Athe receiver has crashed and = lost the DTLS state.=0A=0AWe discuss this issue in a draft:=0Ahttp://tools.= ietf.org/html/draft-mentz-ipfix-dtls-recommendations-00=0Ahttp://www.ietf.o= rg/proceedings/75/slides/ipfix-6.pdf=0A=0AI've had a look at draft-feng-sys= log-transport-dtls-01 and=0Adraft-petch-gerhards-syslog-transport-dtls-02. = It seems that this=0Aproblem has not yet been covered, although the problem= should be the=0Asame for SYSLOG.=0A=0AAs a solution, the DTLS Heartbeat Ex= tension has been proposed very recently:=0Ahttp://tools.ietf.org/html/draft= -seggelmann-tls-dtls-heartbeat-00=0AA feature patch for OpenSSL is availabl= e:=0Ahttp://sctp.fh-muenster.de/dtls-patches.html#features=0A=0ASo, I think= that we should support this standardization initiative as it=0Asolves our = problem. For IPFIX and SYSLOG over DTLS/UDP, we then can=0Aspecify that the= DTLS Heartbeat Extension MUST be implemented.=0A=0ADan suggested to have a= single document solving the DTLS issues=0Aregarding unidirectional protoco= ls. I think that such a document is not=0Aneeded if we have DTLS Heartbeat = Extension.=0A=0ARegards,=0AGerhard=0A=0ADipl.-Ing. Gerhard M=FCnz=0AChair f= or Network Architectures and Services (I8)=0ADepartment of Informatics=0ATe= chnische Universit=E4t M=FCnchen=0ABoltzmannstr. 3, 85748 Garching bei M=FC= nchen, Germany=0APhone:=A0 +49 89 289-18008=A0 =A0 =A0 Fax: +49 89 289-1803= 3=0AE-mail: muenz@net.in.tum.de=A0 =A0 WWW: http://www.net.in.tum.de/~muenz= =0A=0A=0A=0A_______________________________________________=0ATLS mailing l= ist=0ATLS@ietf.org=0Ahttps://www.ietf.org/mailman/listinfo/tls=0A=0A=0A=0A = --0-1333662422-1253255667=:84105 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable

=0A

=0A
=0A
=0AFrom: tom.petch <cfinss@dial.pipex.com>
To: Gerhard Muenz <muenz@net.in.tum.de>; syslog@iet= f.org; ipfix@ietf.org; tls@ietf.org
Cc: Michael Tuexen <tuexen@fh-muenster.de>; Daniel Mentz = <mentz@in.tum.de>
Sent: Thursday, July 30, 2009 2:44:11 AM
Subject: Re: [TLS] [Syslog] Missing dead peer detection in= DTLS

Gerhard

Thank you for pointing this out; it had = escaped me.

What I had thought though was that the lack of flow cont= rol with DTLS over UDP
is a problem, and that the lack of this with sysl= og over UDP led the syslog RFC
[RFC5424] to make syslog over TLS the REC= OMMENDED transport, not, as might be
expected, syslog over UDP.

T= his in turn led me to expect that syslog over DTLS over UDP would not be
acceptable to the IE= SG, rather that syslog over DTLS over SCTP would become the
RECOMMENDED = transport.

So; several thoughts.

This is an update to the ext= ensions RFC, RFC4366, which itself is being updated
by the TLS working g= roup (hence my addition of them to the list) and I would
much rather hav= e one extensions RFC rather than several.  This is a good concept
a= nd fills a need; perhaps the TLS working group would take this on.

F= low control remains an issue which I do not think that this extension
ad= dresses.

Is this a security exposure? or just, like syslog over UDP,= an inconvenient
truth?

The petch-gerhards draft allows the recip= ient of the unidirectional flow to
initiate the DTLS 'connection', and s= o enables it to re-establish the connection
when anything goes wrong.&nb= sp; This would seem an alternative to consider.

Tom Petch

----- Original Message -----
From: "Gerhard Muenz" <= muenz@net.in.tum.de>
To: <syslog@ietf.org>; <ipfix@ietf.org&= gt;
Cc: "Michael Tuexen" <tuexen@fh-muenster.de>; "Robi= n Seggelmann"
<seggelmann@fh-muenster.de>; "D= aniel Mentz" <mentz@in.tum.de>
Sent: Tuesday, July 28, 2009 10:41 A= M
Subject: [Syslog] Missing dead peer detection in DTLS


Hi,
This mail goes to the ipfix and syslog mailing lists in order to
s= ummarize the common issues regarding DTLS.

IPFIX specifies support of DTLS as mandatory= for transport over UDP and
SCTP in RFC5101. In SYSLOG, it is intended t= o standardize DTLS for
transport over UDP.

In IPFIX, we have a fi= rst implementation of IPFIX-over-DTLS/UDP, and we
will have a first impl= ementation of IPFIX-over-DTLS/SCTP very soon.
During this implementation= effort, we found that the current
specification of DTLS/UDP has a sever= e flaw when used with
unidirectional protocols (like IPFIX): The sender = cannot recognize if
the receiver has crashed and lost the DTLS state.
We discuss this issue in a draft:
http://tools.ietf.org/html/draft-= mentz-ipfix-dtls-recommendations-00
http://www.ietf.org/proceedings/75/s= lides/ipfix-6.pdf

I've had a look at draft-feng-syslog-transport-dtl= s-01 and
draft-petch-gerhards-syslog-transport-dtls-02. It seems that th= is
problem has not yet been covered, although the problem should be the
same for SYSLOG.

As a solution, the DTLS Heartbeat Extens= ion has been proposed very recently:
http://tools.ietf.org/html/draft-se= ggelmann-tls-dtls-heartbeat-00
A feature patch for OpenSSL is available:=
http://sctp.fh-muenster.de/dtls-patches.html#features

So, I thin= k that we should support this standardization initiative as it
solves ou= r problem. For IPFIX and SYSLOG over DTLS/UDP, we then can
specify that = the DTLS Heartbeat Extension MUST be implemented.

Dan suggested to h= ave a single document solving the DTLS issues
regarding unidirectional p= rotocols. I think that such a document is not
needed if we have DTLS Hea= rtbeat Extension.

Regards,
Gerhard

Dipl.-Ing. Gerhard M=FC= nz
Chair for Network Architectures and Services (I8)
Department of In= formatics
Technische Universit=E4t M=FCnchen
Boltzmannstr. 3, 85748 G= arching bei M=FCnchen, Germany
Phone:  +49 89 289-18008      Fax: +49 89 289-18033
E-mail: muenz@net.in.tum.de&= nbsp;   WWW: http://www.net.in.tum.de/~muenz



__________= _____________________________________
TLS mailing list
TLS@ietf.org
https://ww= w.ietf.org/mailman/listinfo/tls

=0A=0A --0-1333662422-1253255667=:84105-- From tuexen@fh-muenster.de Thu Sep 17 23:58: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 032503A6AF0; Thu, 17 Sep 2009 23:58:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 4.545 X-Spam-Level: **** X-Spam-Status: No, score=4.545 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, J_CHICKENPOX_35=0.6, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_XBL=3.033, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Mp8YwjhvWzhN; Thu, 17 Sep 2009 23:58:18 -0700 (PDT) Received: from mail-n.franken.de (drew.ipv6.franken.de [IPv6:2001:638:a02:a001:20e:cff:fe4a:feaa]) by core3.amsl.com (Postfix) with ESMTP id 24A493A6AF5; Thu, 17 Sep 2009 23:58:17 -0700 (PDT) Received: from [10.12.253.227] (unknown [212.44.18.222]) by mail-n.franken.de (Postfix) with ESMTP id 45C981C0B462B; Fri, 18 Sep 2009 08:59:07 +0200 (CEST) Message-Id: From: Michael Tuexen To: Erick O In-Reply-To: <587230.84105.qm@web45508.mail.sp1.yahoo.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed; delsp=yes Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Apple Message framework v936) Date: Fri, 18 Sep 2009 07:59:06 +0100 References: <4A6EB9BB.9040002@net.in.tum.de> <000401ca111a$3bb01da0$0601a8c0@allison> <587230.84105.qm@web45508.mail.sp1.yahoo.com> X-Mailer: Apple Mail (2.936) X-Mailman-Approved-At: Fri, 18 Sep 2009 00:21:58 -0700 Cc: ipfix@ietf.org, Daniel Mentz , "tom.petch" , syslog@ietf.org, tls@ietf.org Subject: Re: [IPFIX] [TLS] [Syslog] Missing dead peer detection in DTLS X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Sep 2009 06:58:20 -0000 Hi Eric, See a comment in-line. Best regards Michael On Sep 18, 2009, at 7:34 AM, Erick O wrote: > > > From: tom.petch > To: Gerhard Muenz ; syslog@ietf.org; = ipfix@ietf.org=20 > ; tls@ietf.org > Cc: Michael Tuexen ; Daniel Mentz = > > Sent: Thursday, July 30, 2009 2:44:11 AM > Subject: Re: [TLS] [Syslog] Missing dead peer detection in DTLS > > Gerhard > > Thank you for pointing this out; it had escaped me. > > What I had thought though was that the lack of flow control with =20 > DTLS over UDP > is a problem, and that the lack of this with syslog over UDP led the =20= > syslog RFC > [RFC5424] to make syslog over TLS the RECOMMENDED transport, not, as =20= > might be > expected, syslog over UDP. > > This in turn led me to expect that syslog over DTLS over UDP would =20 > not be > acceptable to the IESG, rather that syslog over DTLS over SCTP would =20= > become the > RECOMMENDED transport. > > So; several thoughts. > > This is an update to the extensions RFC, RFC4366, which itself is =20 > being updated > by the TLS working group (hence my addition of them to the list) and =20= > I would > much rather have one extensions RFC rather than several. This is a =20= > good concept > and fills a need; perhaps the TLS working group would take this on. > > Flow control remains an issue which I do not think that this extension > addresses. There can be only one HB in flight, so this extension neither overloads the receiver nor the network. Times are exponentially back offed. So for the messages introduced in this ID, we have a simple congestion and flow control. > > Is this a security exposure? or just, like syslog over UDP, an =20 > inconvenient > truth? > > The petch-gerhards draft allows the recipient of the unidirectional =20= > flow to > initiate the DTLS 'connection', and so enables it to re-establish =20 > the connection > when anything goes wrong. This would seem an alternative to consider. > > Tom Petch > > ----- Original Message ----- > From: "Gerhard Muenz" > To: ; > Cc: "Michael Tuexen" ; "Robin Seggelmann" > ; "Daniel Mentz" > Sent: Tuesday, July 28, 2009 10:41 AM > Subject: [Syslog] Missing dead peer detection in DTLS > > > Hi, > > This mail goes to the ipfix and syslog mailing lists in order to > summarize the common issues regarding DTLS. > > IPFIX specifies support of DTLS as mandatory for transport over UDP =20= > and > SCTP in RFC5101. In SYSLOG, it is intended to standardize DTLS for > transport over UDP. > > In IPFIX, we have a first implementation of IPFIX-over-DTLS/UDP, and =20= > we > will have a first implementation of IPFIX-over-DTLS/SCTP very soon. > During this implementation effort, we found that the current > specification of DTLS/UDP has a severe flaw when used with > unidirectional protocols (like IPFIX): The sender cannot recognize if > the receiver has crashed and lost the DTLS state. > > We discuss this issue in a draft: > http://tools.ietf.org/html/draft-mentz-ipfix-dtls-recommendations-00 > http://www.ietf.org/proceedings/75/slides/ipfix-6.pdf > > I've had a look at draft-feng-syslog-transport-dtls-01 and > draft-petch-gerhards-syslog-transport-dtls-02. It seems that this > problem has not yet been covered, although the problem should be the > same for SYSLOG. > > As a solution, the DTLS Heartbeat Extension has been proposed very =20 > recently: > http://tools.ietf.org/html/draft-seggelmann-tls-dtls-heartbeat-00 > A feature patch for OpenSSL is available: > http://sctp.fh-muenster.de/dtls-patches.html#features > > So, I think that we should support this standardization initiative =20 > as it > solves our problem. For IPFIX and SYSLOG over DTLS/UDP, we then can > specify that the DTLS Heartbeat Extension MUST be implemented. > > Dan suggested to have a single document solving the DTLS issues > regarding unidirectional protocols. I think that such a document is =20= > not > needed if we have DTLS Heartbeat Extension. > > Regards, > Gerhard > > 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 > > > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls From ericko0@yahoo.com Fri Sep 18 07:32: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 AF9B728C162 for ; Fri, 18 Sep 2009 07:32:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.205 X-Spam-Level: X-Spam-Status: No, score=-2.205 tagged_above=-999 required=5 tests=[AWL=-0.207, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_35=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EyI3sEeKye9Z for ; Fri, 18 Sep 2009 07:32:44 -0700 (PDT) Received: from web45505.mail.sp1.yahoo.com (web45505.mail.sp1.yahoo.com [68.180.197.89]) by core3.amsl.com (Postfix) with SMTP id 57ADB28C167 for ; Fri, 18 Sep 2009 07:32:44 -0700 (PDT) Received: (qmail 12143 invoked by uid 60001); 18 Sep 2009 14:33:36 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1253284416; bh=lVozXTdlBLPkpbDDpLmxEPtffK+xfgF1EIC9zDHbS3I=; h=Message-ID:X-YMail-OSG:Received:X-Mailer:References:Date:From:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=P1ohhFdpejNmntXUkmqjF3W+HlnIUuzQ1hiMubxc/pVZbAmiyUucXlBQqqPGRV1nQmHEoITTjjhtmc+XUmEtkVnuYSAz+dlfuAznyCl+eY4elwSRP9VNC/u8FZHH2T2fsAvPHIRCRGZISRK85gDSBDiEF/HivyFpLuhwvPCh3sY= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:X-YMail-OSG:Received:X-Mailer:References:Date:From:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=2jEgCsFPLj7VqqoE+Nxmoa90PRTWZP5hJCbTMDgf2ahGhFv0mIT8nkGqDJnNM0wV33ik/jVMdQ10rRdueeZ+FGkyECTMZsoIv9UR7mW04b42+VvFfN+Nbo8UGHwK2hBlMQFJDK7tNOv4PE6h+sV0hGYPo1IwI1P3sNe3oYhZs2I=; Message-ID: <443305.4608.qm@web45505.mail.sp1.yahoo.com> X-YMail-OSG: bS2GhIUVM1kVy.LhlrRoJDT8VgmWKcvgKPjKrTAo4vvD9INZp2ct_WTKM31dWxq.J1iB9wCKjziyqSjMld6NLpsRO54WaMreQ9xhypDvVDrythoBGx0BO9fcJnb1C1Tmogb_Zr931_CD2q9kGdJPKcfw847On9y0Tm6wY7879tbHv2gEd3f1.VGP1YQ9F2p__3vr.kFRA2Nrl_otFzu3np4684WJMUchwpnAPaxElpspXXVvKr0- Received: from [68.106.217.192] by web45505.mail.sp1.yahoo.com via HTTP; Fri, 18 Sep 2009 07:33:36 PDT X-Mailer: YahooMailRC/157.18 YahooMailWebService/0.7.347.2 References: <4A6EB9BB.9040002@net.in.tum.de> <000401ca111a$3bb01da0$0601a8c0@allison> <587230.84105.qm@web45508.mail.sp1.yahoo.com> Date: Fri, 18 Sep 2009 07:33:36 -0700 (PDT) From: Erick O To: Michael Tuexen In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="0-1490659396-1253284416=:4608" X-Mailman-Approved-At: Fri, 18 Sep 2009 09:01:58 -0700 Cc: ipfix@ietf.org, Daniel Mentz , "tom.petch" , syslog@ietf.org, tls@ietf.org Subject: Re: [IPFIX] [TLS] [Syslog] Missing dead peer detection in DTLS X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Sep 2009 14:32:45 -0000 --0-1490659396-1253284416=:4608 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable =0A=0A=0A=0A=0A________________________________=0AFrom: Michael Tuexen =0ATo: Erick O =0ACc: tom.petch ; Gerhard Muenz ; syslog@ietf.org; i= pfix@ietf.org; tls@ietf.org; Daniel Mentz =0ASent: Thursda= y, September 17, 2009 11:59:06 PM=0ASubject: Re: [TLS] [Syslog] Missing dea= d peer detection in DTLS=0A=0AHi Eric,=0A=0ASee a comment in-line.=0A=0ABes= t regards=0AMichael=0A=0AOn Sep 18, 2009, at 7:34 AM, Erick O wrote:=0A=0A>= =0A> =0A> From: tom.petch =0A> To: Gerhard Muenz ; syslog@ietf.org; ipfix@ietf.org; tls@ietf.org=0A> Cc: = Michael Tuexen ; Daniel Mentz =0A> = Sent: Thursday, July 30, 2009 2:44:11 AM=0A> Subject: Re: [TLS] [Syslog] Mi= ssing dead peer detection in DTLS=0A> =0A> Gerhard=0A> =0A> Thank you for p= ointing this out; it had escaped me.=0A> =0A> What I had thought though was= that the lack of flow control with DTLS over UDP=0A> is a problem, and tha= t the lack of this with syslog over UDP led the syslog RFC=0A> [RFC5424] to= make syslog over TLS the RECOMMENDED transport, not, as might be=0A> expec= ted, syslog over UDP.=0A> =0A> This in turn led me to expect that syslog ov= er DTLS over UDP would not be=0A> acceptable to the IESG, rather that syslo= g over DTLS over SCTP would become the=0A> RECOMMENDED transport.=0A> =0A> = So; several thoughts.=0A> =0A> This is an update to the extensions RFC, RFC= 4366, which itself is being updated=0A> by the TLS working group (hence my = addition of them to the list) and I would=0A> much rather have one extensio= ns RFC rather than several.=A0 This is a good concept=0A> and fills a need;= perhaps the TLS working group would take this on.=0A> =0A> Flow control re= mains an issue which I do not think that this extension=0A> addresses.=0ATh= ere can be only one HB in flight, so this extension neither overloads=0Athe= receiver nor the network. Times are exponentially back offed.=0ASo for the= messages introduced in this ID, we have a simple congestion=0Aand flow con= trol.=0A> =0A> Is this a security exposure? or just, like syslog over UDP, = an inconvenient=0A> truth?=0A> =0A> The petch-gerhards draft allows the rec= ipient of the unidirectional flow to=0A> initiate the DTLS 'connection', an= d so enables it to re-establish the connection=0A> when anything goes wrong= .=A0 This would seem an alternative to consider.=0A> =0A> Tom Petch=0A> =0A= > ----- Original Message -----=0A> From: "Gerhard Muenz" =0A> To: ; =0A> Cc: "Michael Tuexen" ; "Robin Seggelmann"=0A> ; = "Daniel Mentz" =0A> Sent: Tuesday, July 28, 2009 10:41 AM= =0A> Subject: [Syslog] Missing dead peer detection in DTLS=0A> =0A> =0A> Hi= ,=0A> =0A> This mail goes to the ipfix and syslog mailing lists in order to= =0A> summarize the common issues regarding DTLS.=0A> =0A> IPFIX specifies s= upport of DTLS as mandatory for transport over UDP and=0A> SCTP in RFC5101.= In SYSLOG, it is intended to standardize DTLS for=0A> transport over UDP.= =0A> =0A> In IPFIX, we have a first implementation of IPFIX-over-DTLS/UDP, = and we=0A> will have a first implementation of IPFIX-over-DTLS/SCTP very so= on.=0A> During this implementation effort, we found that the current=0A> sp= ecification of DTLS/UDP has a severe flaw when used with=0A> unidirectional= protocols (like IPFIX): The sender cannot recognize if=0A> the receiver ha= s crashed and lost the DTLS state.=0A> =0A> We discuss this issue in a draf= t:=0A> http://tools.ietf.org/html/draft-mentz-ipfix-dtls-recommendations-00= =0A> http://www.ietf.org/proceedings/75/slides/ipfix-6.pdf=0A> =0A> I've ha= d a look at draft-feng-syslog-transport-dtls-01 and=0A> draft-petch-gerhard= s-syslog-transport-dtls-02. It seems that this=0A> problem has not yet been= covered, although the problem should be the=0A> same for SYSLOG.=0A> =0A> = As a solution, the DTLS Heartbeat Extension has been proposed very recently= :=0A> http://tools.ietf.org/html/draft-seggelmann-tls-dtls-heartbeat-00=0A>= A feature patch for OpenSSL is available:=0A> http://sctp.fh-muenster.de/d= tls-patches.html#features=0A> =0A> So, I think that we should support this = standardization initiative as it=0A> solves our problem. For IPFIX and SYSL= OG over DTLS/UDP, we then can=0A> specify that the DTLS Heartbeat Extension= MUST be implemented.=0A> =0A> Dan suggested to have a single document solv= ing the DTLS issues=0A> regarding unidirectional protocols. I think that su= ch a document is not=0A> needed if we have DTLS Heartbeat Extension.=0A> = =0A> Regards,=0A> Gerhard=0A> =0A> Dipl.-Ing. Gerhard M=FCnz=0A> Chair for = Network Architectures and Services (I8)=0A> Department of Informatics=0A> T= echnische Universit=E4t M=FCnchen=0A> Boltzmannstr. 3, 85748 Garching bei M= =FCnchen, Germany=0A> Phone:=A0 +49 89 289-18008=A0 =A0 =A0 Fax: +49 89 289= -18033=0A> E-mail: muenz@net.in.tum.de=A0 =A0 WWW: http://www.net.in.tum.de= /~muenz=0A> =0A> =0A> =0A> _______________________________________________= =0A> TLS mailing list=0A> TLS@ietf.org=0A> https://www.ietf.org/mailman/lis= tinfo/tls=0A> =0A> _______________________________________________=0A> TLS = mailing list=0A> TLS@ietf.org=0A> https://www.ietf.org/mailman/listinfo/tls= =0A=0A=0A --0-1490659396-1253284416=:4608 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable

=0A

=0A
=0A
=0AFrom: Michael Tuexen <tuexen@fh-muenster.de>
To: Erick O <ericko0@yahoo.com>
Cc: tom.petch <cfinss@dial.pipex.co= m>; Gerhard Muenz <muenz@net.in.tum.de>; syslog@ietf.org; ipfix@ie= tf.org; tls@ietf.org; Daniel Mentz <mentz@in.tum.de>
Sent: Thursday, September 17, 2009 11:59= :06 PM
Subject: Re: [TLS= ] [Syslog] Missing dead peer detection in DTLS

Hi Eric,
See a comment in-line.

Best regards
Michael

On Sep 18, 2= 009, at 7:34 AM, Erick O wrote:

>
>
> From: tom.pet= ch <cfinss@dial.pipex.com>
> To: Gerhard Muenz <<= A href=3D"mailto:muenz@net.in.tum.de" ymailto=3D"mailto:muenz@net.in.tum.de"= >muenz@net.in.tum.de>; syslog@ietf.org; ipfix@ietf.org; tls@ietf.org
> Cc= : Michael Tuexen <tuexen@fh-muenster.de>; Daniel Mentz <= ;ment= z@in.tum.de>
> Sent: Thursday, July 30, 2009 2:44:11 AM
>= ; Subject: Re: [TLS] [Syslog] Missing dead peer detection in DTLS
> <= BR>> Gerhard
>
> Thank you for pointing this out; it had es= caped me.
>
> What I had thought though was that the lack of f= low control with DTLS over UDP
> is a problem, and that the lack of t= his with syslog over UDP led the syslog RFC
> [RFC5424] to make syslog over TLS the = RECOMMENDED transport, not, as might be
> expected, syslog over UDP.<= BR>>
> This in turn led me to expect that syslog over DTLS over U= DP would not be
> acceptable to the IESG, rather that syslog over DTL= S over SCTP would become the
> RECOMMENDED transport.
>
>= ; So; several thoughts.
>
> This is an update to the extension= s RFC, RFC4366, which itself is being updated
> by the TLS working gr= oup (hence my addition of them to the list) and I would
> much rather= have one extensions RFC rather than several.  This is a good concept<= BR>> and fills a need; perhaps the TLS working group would take this on.=
>
> Flow control remains an issue which I do not think that t= his extension
> addresses.
There can be only one HB in flight, so = this extension neither overloads
the receiver nor the network. Times are exponentially back offed.
So for the messages introduced in t= his ID, we have a simple congestion
and flow control.
>
> I= s this a security exposure? or just, like syslog over UDP, an inconvenient<= BR>> truth?
>
> The petch-gerhards draft allows the recipie= nt of the unidirectional flow to
> initiate the DTLS 'connection', an= d so enables it to re-establish the connection
> when anything goes w= rong.  This would seem an alternative to consider.
>
> To= m Petch
>
> ----- Original Message -----
> From: "Gerhar= d Muenz" <muenz@net.in.tum.de>
> To: <syslog@ietf.org&= gt;; <ipfix@ietf.org>
> Cc: "Michael Tuexen" <tuexen@fh-muenster.de>; "Robin Seggelmann"
> <seggelmann@fh-muenster.de>; "Daniel Mentz" <mentz@in.tum.de>
> Sent: Tuesday, July 28, 2009 10:41 AM
> Subject: [Syslo= g] Missing dead peer detection in DTLS
>
>
> Hi,
>= ;
> This mail goes to the ipfix and syslog mailing lists in order to=
> summarize the common issues regarding DTLS.
>
> IPFIX= specifies support of DTLS as mandatory for transport over UDP and
> = SCTP in RFC5101. In SYSLOG, it is intended to standardize DTLS for
> = transport over UDP.
>
> In IPFIX, we have a first implementati= on of IPFIX-over-DTLS/UDP, and we
> will have a first implementation = of IPFIX-over-DTLS/SCTP very soon.
> During this implementation effort,= we found that the current
> specification of DTLS/UDP has a severe f= law when used with
> unidirectional protocols (like IPFIX): The sende= r cannot recognize if
> the receiver has crashed and lost the DTLS st= ate.
>
> We discuss this issue in a draft:
> http://tool= s.ietf.org/html/draft-mentz-ipfix-dtls-recommendations-00
> http://ww= w.ietf.org/proceedings/75/slides/ipfix-6.pdf
>
> I've had a lo= ok at draft-feng-syslog-transport-dtls-01 and
> draft-petch-gerhards-= syslog-transport-dtls-02. It seems that this
> problem has not yet be= en covered, although the problem should be the
> same for SYSLOG.
= >
> As a solution, the DTLS Heartbeat Extension has been proposed= very recently:
> http://tools.ietf.org/html/draft-seggelmann-tls-dtl= s-heartbeat-00
> A feature patch for OpenSSL is available:
> http://sctp.fh-muenster.de/dtls-patches.html#features>
> So, I think that we should support this standardization ini= tiative as it
> solves our problem. For IPFIX and SYSLOG over DTLS/UD= P, we then can
> specify that the DTLS Heartbeat Extension MUST be im= plemented.
>
> Dan suggested to have a single document solving= the DTLS issues
> regarding unidirectional protocols. I think that s= uch a document is not
> needed if we have DTLS Heartbeat Extension.>
> Regards,
> Gerhard
>
> Dipl.-Ing. Gerhar= d 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:&nbs= p; +49 89 289-18008      Fax: +49 89 289-18033
> E-mai= l: muenz@net.in.tum.de   = ; WWW: http://www.net.in.tum.de/~muenz
>
>
>
> _= ______________________________________________
> TLS mailing list
= > TLS@ie= tf.org
> https://www.ietf.org/mailman/listinfo/tls
>
>= ; _______________________________________________
> TLS mailing list<= BR>> TLS= @ietf.org
> https://www.ietf.org/mailman/listinfo/tls


=0A=0A --0-1490659396-1253284416=:4608-- From ericko0@yahoo.com Fri Sep 18 07:34: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 CFDF33A6B0A for ; Fri, 18 Sep 2009 07:34:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.213 X-Spam-Level: X-Spam-Status: No, score=-2.213 tagged_above=-999 required=5 tests=[AWL=-0.215, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_35=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RUd9g9jJJpUh for ; Fri, 18 Sep 2009 07:34:36 -0700 (PDT) Received: from web45513.mail.sp1.yahoo.com (web45513.mail.sp1.yahoo.com [68.180.197.161]) by core3.amsl.com (Postfix) with SMTP id 977D628C162 for ; Fri, 18 Sep 2009 07:34:19 -0700 (PDT) Received: (qmail 86955 invoked by uid 60001); 18 Sep 2009 14:35:01 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1253284501; bh=SUzTzHgOCjuEy3oqHBcQkhQezJKIqueeqWA3odmEQqQ=; h=Message-ID:X-YMail-OSG:Received:X-Mailer:References:Date:From:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=GAcQXG3roDDwhULVkRMbn2npqLuphKdVBRM5+Pcr5FBcb6pT7vJk+lqW2jeb8hoFSHCwdEsnvPdDnqLw86W92Lpbo567tmIjeBOAQRC4HSqbxl/rGWVvWwM6d+GoDhDORJeVtbmZSWDzpQajttBPvFD+G7/KBpFXFCHCGIrnmk8= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:X-YMail-OSG:Received:X-Mailer:References:Date:From:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=SANlV6NukQvMrMzpha83yqgnz656DBnxjraxKaIh2X5zjDkYayr0MVAjrg0a9cP7U5BsYb4KTeCLOtd1PugwL9bGTqzQxzR3KtgJCgJBmxRSV1vPO4rS/CyNzGbpVGncjBnaNVOPa3phEeW2RoE5ZeUz1xTo6HqCpO2InS9wjFw=; Message-ID: <176544.85122.qm@web45513.mail.sp1.yahoo.com> X-YMail-OSG: sgmRthsVM1nZbDYq.OOGwKz2gk06ppjs839F_BTlK2vI8QqRj15y.8FGgppHol9ypWdvE7dXBav.6qLZCfZtnrMdicQIkn2UTB3qx0HNi2UyyFz_6FmvJr_QLl_wedqfGIjcANkvhAaUsGaorrmrE4.0x55I6Of2ddBfCYdq5.jasCE.zSO5GnMkcvtAAIBoPT9GZ33pl._QOn3iZahn4p1Jc05iNKbWNywqa6FZDn9R Received: from [68.106.217.192] by web45513.mail.sp1.yahoo.com via HTTP; Fri, 18 Sep 2009 07:35:00 PDT X-Mailer: YahooMailRC/157.18 YahooMailWebService/0.7.347.2 References: <4A6EB9BB.9040002@net.in.tum.de> <000401ca111a$3bb01da0$0601a8c0@allison> <587230.84105.qm@web45508.mail.sp1.yahoo.com> Date: Fri, 18 Sep 2009 07:35:00 -0700 (PDT) From: Erick O To: Erick O , "tom.petch" , Gerhard Muenz , syslog@ietf.org, ipfix@ietf.org, tls@ietf.org In-Reply-To: <587230.84105.qm@web45508.mail.sp1.yahoo.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="0-859172981-1253284500=:85122" X-Mailman-Approved-At: Fri, 18 Sep 2009 09:01:58 -0700 Cc: Michael Tuexen , Daniel Mentz Subject: Re: [IPFIX] [TLS] [Syslog] Missing dead peer detection in DTLS X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Sep 2009 14:34:37 -0000 --0-859172981-1253284500=:85122 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable =0A=0A=0A=0A=0A________________________________=0AFrom: Erick O =0ATo: tom.petch ; Gerhard Muenz ; syslog@ietf.org; ipfix@ietf.org; tls@ietf.org=0ACc: Michael Tue= xen ; Daniel Mentz =0ASent: Thursda= y, September 17, 2009 11:34:27 PM=0ASubject: Re: [TLS] [Syslog] Missing dea= d peer detection in DTLS=0A=0A=0A=0A=0A=0A=0A=0A___________________________= _____=0AFrom: tom.petch =0ATo: Gerhard Muenz ; syslog@ietf.org; ipfix@ietf.org; tls@ietf.org=0ACc: Michael= Tuexen ; Daniel Mentz =0ASent: Thu= rsday, July 30, 2009 2:44:11 AM=0ASubject: Re: [TLS] [Syslog] Missing dead = peer detection in DTLS=0A=0AGerhard=0A=0AThank you for pointing this out; i= t had escaped me.=0A=0AWhat I had thought though was that the lack of flow = control with DTLS over UDP=0Ais a problem, and that the lack of this with s= yslog over UDP led the syslog RFC=0A[RFC5424] to make syslog over TLS the R= ECOMMENDED transport, not, as might be=0Aexpected, syslog over UDP.=0A=0ATh= is in turn led me to expect that syslog over DTLS over UDP would not be=0Aa= cceptable to the IESG, rather that syslog over DTLS over SCTP would become = the=0ARECOMMENDED transport.=0A=0ASo; several thoughts.=0A=0AThis is an upd= ate to the extensions RFC, RFC4366, which itself is being updated=0Aby the = TLS working group (hence my addition of them to the list) and I would=0Amuc= h rather have one extensions RFC rather than several.=A0 This is a good con= cept=0Aand fills a need; perhaps the TLS working group would take this on.= =0A=0AFlow control remains an issue which I do not think that this extensio= n=0Aaddresses.=0A=0AIs this a security exposure? or just, like syslog over = UDP, an inconvenient=0Atruth?=0A=0AThe petch-gerhards draft allows the reci= pient of the unidirectional flow to=0Ainitiate the DTLS 'connection', and s= o enables it to re-establish the connection=0Awhen anything goes wrong.=A0 = This would seem an alternative to consider.=0A=0ATom Petch=0A=0A----- Origi= nal Message -----=0AFrom: "Gerhard Muenz" =0ATo: ; =0ACc: "Michael Tuexen" ; "Robin Seggelmann"=0A; "Daniel Mentz" =0ASent: Tuesday, July 28, 2009 10:41 AM=0ASubject: [Syslog] Mis= sing dead peer detection in DTLS=0A=0A=0AHi,=0A=0AThis mail goes to the ipf= ix and syslog mailing lists in order to=0Asummarize the common issues regar= ding DTLS.=0A=0AIPFIX specifies support of DTLS as mandatory for transport = over UDP and=0ASCTP in RFC5101. In SYSLOG, it is intended to standardize DT= LS for=0Atransport over UDP.=0A=0AIn IPFIX, we have a first implementation = of IPFIX-over-DTLS/UDP, and we=0Awill have a first implementation of IPFIX-= over-DTLS/SCTP very soon.=0ADuring this implementation effort, we found tha= t the current=0Aspecification of DTLS/UDP has a severe flaw when used with= =0Aunidirectional protocols (like IPFIX): The sender cannot recognize if=0A= the receiver has crashed and lost the DTLS state.=0A=0AWe discuss this issu= e in a draft:=0Ahttp://tools.ietf.org/html/draft-mentz-ipfix-dtls-recommend= ations-00=0Ahttp://www.ietf.org/proceedings/75/slides/ipfix-6.pdf=0A=0AI've= had a look at draft-feng-syslog-transport-dtls-01 and=0Adraft-petch-gerhar= ds-syslog-transport-dtls-02. It seems that this=0Aproblem has not yet been = covered, although the problem should be the=0Asame for SYSLOG.=0A=0AAs a so= lution, the DTLS Heartbeat Extension has been proposed very recently:=0Ahtt= p://tools.ietf.org/html/draft-seggelmann-tls-dtls-heartbeat-00=0AA feature = patch for OpenSSL is available:=0Ahttp://sctp.fh-muenster.de/dtls-patches.h= tml#features=0A=0ASo, I think that we should support this standardization i= nitiative as it=0Asolves our problem. For IPFIX and SYSLOG over DTLS/UDP, w= e then can=0Aspecify that the DTLS Heartbeat Extension MUST be implemented.= =0A=0ADan suggested to have a single document solving the DTLS issues=0Areg= arding unidirectional protocols. I think that such a document is not=0Aneed= ed if we have DTLS Heartbeat Extension.=0A=0ARegards,=0AGerhard=0A=0ADipl.-= Ing. Gerhard M=FCnz=0AChair for Network Architectures and Services (I8)=0AD= epartment of Informatics=0ATechnische Universit=E4t M=FCnchen=0ABoltzmannst= r. 3, 85748 Garching bei M=FCnchen, Germany=0APhone:=A0 +49 89 289-18008=A0= =A0 =A0 Fax: +49 89 289-18033=0AE-mail: muenz@net.in.tum.de=A0 =A0 WWW: ht= tp://www.net.in.tum.de/~muenz=0A=0A=0A=0A__________________________________= _____________=0ATLS mailing list=0ATLS@ietf.org=0Ahttps://www.ietf.org/mail= man/listinfo/tls=0A=0A=0A --0-859172981-1253284500=:85122 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable

=0A

=0A
=0A
=0AFrom= : Erick O <ericko0@yahoo.com>
To: tom.petch <cfinss@dial.pipex.com>; Gerhard= Muenz <muenz@net.in.tum.de>; syslog@ietf.org; ipfix@ietf.org; tls@ie= tf.org
Cc: Michael Tuexe= n <tuexen@fh-muenster.de>; Daniel Mentz <mentz@in.tum.de>
Sent: Thursday, September 17,= 2009 11:34:27 PM
Subject: Re: [TLS] [Syslog] Missing dead peer detection in DTLS

=0A=
=0A

=0A

=0A
=0A
=0AFrom: t= om.petch <cfinss@dial.pipex.com>
To: Gerhard Muenz <muenz@net.in.tum.de>; syslog@ietf.o= rg; ipfix@ietf.org; tls@ietf.org
Cc= : Michael Tuexen <tuexen@fh-muenster.de>; Daniel Mentz <= ;mentz@in.tum.de>
Sent: Thursday, July 30, 2009 2:44:11 AM
Subject: Re: [TLS] [Syslog] Missing dead peer detection in DT= LS

Gerhard

Thank you for pointing this out; it had esc= aped me.

What I had thought though was that the lack of flow control= with DTLS over UDP
is a problem, and that the lack of this with syslog = over UDP led the syslog RFC
[RFC5424] to make syslog over TLS the RECOMM= ENDED transport, not, as might be
expected, syslog over UDP.

This= in turn led me to expect that syslog over DTLS over UDP would not be
acceptable to the IE= SG, rather that syslog over DTLS over SCTP would become the
RECOMMENDED = transport.

So; several thoughts.

This is an update to the ext= ensions RFC, RFC4366, which itself is being updated
by the TLS working g= roup (hence my addition of them to the list) and I would
much rather hav= e one extensions RFC rather than several.  This is a good concept
a= nd fills a need; perhaps the TLS working group would take this on.

F= low control remains an issue which I do not think that this extension
ad= dresses.

Is this a security exposure? or just, like syslog over UDP,= an inconvenient
truth?

The petch-gerhards draft allows the recip= ient of the unidirectional flow to
initiate the DTLS 'connection', and s= o enables it to re-establish the connection
when anything goes wrong.&nb= sp; This would seem an alternative to consider.

Tom Petch

----- Original Message -----
From: "Gerhard Muenz" <muenz@net.in.tum.de>
To: <syslog@ietf.org>; <= ipfix@ietf.org>
Cc: "Michael Tuexen" <tuexen@fh-muenster.de>; "Robin Seggelmann"
<seggelmann@fh-muenster.de>= ; "Daniel Mentz" <mentz@in.tum.de>
S= ent: Tuesday, July 28, 2009 10:41 AM
Subject: [Syslog] Missing dead peer detection in DTLS


Hi,=

This mail goes to the ipfix and syslog mailing lists in order tosummarize the common issues regarding DTLS.

IPFIX specifies support= of DTLS as mandatory for transport over UDP and
SCTP in RFC5101. In SYS= LOG, it is intended to standardize DTLS for
transport over UDP.

I= n IPFIX, we have a first implementation of IPFIX-over-DTLS/UDP, and we
w= ill have a first implementation of IPFIX-over-DTLS/SCTP very soon.
Durin= g this implementation effort, we found that the current
specification of= DTLS/UDP has a severe flaw when used with
unidirectional protocols (lik= e IPFIX): The sender cannot recognize if
the receiver has crashed and lo= st the DTLS state.

We discuss this issue in a draft:
http://tools= .ietf.org/html/draft-mentz-ipfix-dtls-recommendations-00
http://www.ietf= .org/proceedings/75/slides/ipfix-6.pdf

I've had a look at draft-feng-syslog-transport-dtls-01 and
draft-petch-gerhards-syslog-tra= nsport-dtls-02. It seems that this
problem has not yet been covered, alt= hough the problem should be the
same for SYSLOG.

As a solution, t= he DTLS Heartbeat Extension has been proposed very recently:
http://tool= s.ietf.org/html/draft-seggelmann-tls-dtls-heartbeat-00
A feature patch f= or OpenSSL is available:
http://sctp.fh-muenster.de/dtls-patches.html#fe= atures

So, I think that we should support this standardization initi= ative as it
solves our problem. For IPFIX and SYSLOG over DTLS/UDP, we t= hen can
specify that the DTLS Heartbeat Extension MUST be implemented.
Dan suggested to have a single document solving the DTLS issues
re= garding unidirectional protocols. I think that such a document is not
ne= eded if we have DTLS Heartbeat Extension.

Regards,
Gerhard
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-mai= l: muenz@net.in.tum.de    W= WW: http://www.net.in.tum.de/~muenz



________________________= _______________________
TLS mailing list
TLS@ietf= .org
https://www.ietf.org/mailman/listinfo/tls


=0A=0A=0A=0A --0-859172981-1253284500=:85122-- From boschie@tik.ee.ethz.ch Fri Sep 25 07:37:19 2009 Return-Path: X-Original-To: ipfix@core3.amsl.com Delivered-To: ipfix@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DCA9C3A688F for ; Fri, 25 Sep 2009 07:37:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.05 X-Spam-Level: X-Spam-Status: No, score=-5.05 tagged_above=-999 required=5 tests=[AWL=-1.051, 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 ULU-p2Vp5eSq for ; Fri, 25 Sep 2009 07:37:19 -0700 (PDT) Received: from smtp.ee.ethz.ch (smtp.ee.ethz.ch [129.132.2.219]) by core3.amsl.com (Postfix) with ESMTP id D26043A69AB for ; Fri, 25 Sep 2009 07:37:18 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by smtp.ee.ethz.ch (Postfix) with ESMTP id EA924D93BA for ; Fri, 25 Sep 2009 16:38:27 +0200 (MEST) X-Virus-Scanned: by amavisd-new on smtp.ee.ethz.ch Received: from smtp.ee.ethz.ch ([127.0.0.1]) by localhost (.ee.ethz.ch [127.0.0.1]) (amavisd-new, port 10024) with LMTP id A5yHB6IzPdj2 for ; Fri, 25 Sep 2009 16:38:27 +0200 (MEST) Received: from [82.130.102.89] (nb-5442.ethz.ch [82.130.102.89]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: boschie) by smtp.ee.ethz.ch (Postfix) with ESMTP id BB5F6D9385 for ; Fri, 25 Sep 2009 16:38:27 +0200 (MEST) Message-ID: <4ABCD5E3.9070005@tik.ee.ethz.ch> Date: Fri, 25 Sep 2009 16:38:27 +0200 From: Elisa Boschi User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: ipfix@ietf.org References: <20090727124958.66FA.17391CF2@nttv6.net> <68C3A7FA-1002-434A-BF36-FB158824FA5D@tik.ee.ethz.ch> <20090727153415.66FD.17391CF2@nttv6.net> <4A6D6919.2050602@net.in.tum.de> <4A6D6E81.7020905@cisco.com> <3618EC7E-1182-45A6-91CD-BD607102E602@tik.ee.ethz.ch> In-Reply-To: <3618EC7E-1182-45A6-91CD-BD607102E602@tik.ee.ethz.ch> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [IPFIX] CFP: 2nd Workshop on Traffic Monitoring and Analysis 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, 25 Sep 2009 14:37:20 -0000 Dear all, this CfP for the 2^ TMA Workshop is surely of interest for those working hands-on in monitoring/measurements: http://www.pam2010.ethz.ch/TMA/cfp.html this year the workshop will be co-located with PAM'2010. Please consider submitting your work and help us distribute the CfP among interested colleagues Regards, Elisa From root@core3.amsl.com Tue Sep 29 11: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 A525E3A6904; Tue, 29 Sep 2009 11:30:01 -0700 (PDT) From: IESG Secretary To: ietf-announce@ietf.org Content-Type: text/plain; charset="utf-8" Mime-Version: 1.0 Message-Id: <20090929183002.A525E3A6904@core3.amsl.com> Date: Tue, 29 Sep 2009 11:30:02 -0700 (PDT) Cc: n.brownlee@auckland.ac.nz, ipfix@ietf.org, quittek@netlab.nec.de Subject: [IPFIX] WG Action: RECHARTER: IP Flow Information Export (ipfix) X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Sep 2009 18:30:02 -0000 The IP Flow Information Export (ipfix) working group in the Operations and Management Area of the IETF has been rechartered. For additional information, please contact the Area Directors or the working group Chairs. IP Flow Information Export (ipfix) --------------------------------------------------- Current Status: Active Working Group Chairs: Nevil Brownlee (n.brownlee@auckland.ac.nz) Juergen Quittek (quittek@netlab.nec.de) Operations and Management Area Directors: Dan Romascanu (dromasca@avaya.com) Ronald Bonica (rbonica@juniper.net) Operations and Management Area Advisor: Dan Romascanu (dromasca@avaya.com) Mailing Lists: General Discussion: ipfix@ietf.org To Subscribe: http://www.ietf.org/mailman/listinfo/ipfix Archive: http://www.ietf.org/mail-archive/web/ipfix Description of Working Group: The IPFIX working group has specified the Information Model (to describe IP flows) and the IPFIX protocol (to transfer IP flow data from IPFIX exporters to collectors). Several implementers have already built applications using the IPFIX protocol. As a result of a series of IPFIX interoperability testing events the WG has produced guidelines for IPFIX implementation and testing as well as recommendations for handling special cases such as bidirectional flow reporting and reducing redundancy in flow records. Practical experiences with IPFIX implementations exposed new requirements for the IPFIX protocol that so far have not been addressed by the WG. The major current goal of the WG is developing solutions that meet the new requirements without modifying the core IPFIX protocol specifications. 1. The IPFIX WG has developed a MIB module for monitoring IPFIX implementations. Means for configuring these devices have not been standardized yet. The WG will develop an XML-based configuration data model that can be used for configuring IPFIX devices and for storing, modifying and managing IPFIX configurations parameter sets. This work will be performed in close collaboration with the NETCONF WG. 2. First applications of IPFIX at large operator networks showed the need for mediation of flow information, for example, for aggregating huge amounts of flow data and for anomymization of flow information. The IPFIX WG will investigate this issue and produce a problem statement and a framework for IPFIX flow mediation. 3. The PSAMP WG has developed a protocol for reporting observed packets. The PSAMP protocol is an extension of the IPFIX protocol. The IPFIX WG will develop a MIB module for monitoring PSAMP implementations. The new MIB module will be an extension of the IPFIX MIB module. 4. Anonymization of flow information has been identified as a requirement for flow information export already in RFC 3917. However, technologies for flow anonymization are still a research issue and have so far not been considered to be mature enough for standardization. As one step in this direction, the IPFIX WG will develop guidelines for the implementation of anonymized data export and storage over IPFIX and define an information model for configuring and reporting anonymization applied at IPFIX devices. 5. The IPFIX and PSAMP WGs have defined standards for selecting observed IP packets and collecting information in flow records. In order to reduce the amount of data to be processed, packet selection methods have been defined. Another method for reducing flow data is flow selection. The IPFIX WG will define methods for flow selection and provide an information model for configuring and reporting flow selection applied at IPFIX devices. 6. Being designed for the export of flow records the IPFIX protocol provides very limited means for structuring information elements within IPFIX records. With the increasing number of IPFIX applications there is a need for exporting more complex information. The IPFIX WG will develop an extension of the IPFIX protocol that supports hierarchically structured data and lists (sequences) of Information Elements in data records. Goals and Milestones: Oct 2009 Submit Mediation Problem Statement I-D to IESG for publication as Informational RFC Oct 2009 Submit initial draft on anonymization support Oct 2009 Submit initial draft on flow selection Oct 2009 Submit initial draft on structuring information elements Jan 2010 Submit Configuration Data Model draft to IESG for publication as Standards track RFC Jan 2010 Submit Mediation Framework I-D to IESG for publication as Informational RFC Jan 2010 Submit final version of PSAMP MIB module Jun 2010 Submit anonymization support I-D to IESG for publication as Experimental RFC Jun 2010 Submit flow selection I-D to IESG for publication as Standards Track RFC Jun 2010 Submit structuring information elements I-D to IESG for publication as Standards Track RFC From Quittek@nw.neclab.eu Wed Sep 30 00:45:15 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 E61DC3A6A19; Wed, 30 Sep 2009 00:45:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.36 X-Spam-Level: X-Spam-Status: No, score=-2.36 tagged_above=-999 required=5 tests=[AWL=0.239, 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 MGVj3YX--+dG; Wed, 30 Sep 2009 00:45:14 -0700 (PDT) Received: from smtp0.neclab.eu (smtp0.neclab.eu [195.37.70.41]) by core3.amsl.com (Postfix) with ESMTP id 2DD573A68F6; Wed, 30 Sep 2009 00:45:14 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp0.neclab.eu (Postfix) with ESMTP id C768C2C0008E0; Wed, 30 Sep 2009 09:46:33 +0200 (CEST) X-Virus-Scanned: Amavisd on Debian GNU/Linux (atlas2.office) Received: from smtp0.neclab.eu ([127.0.0.1]) by localhost (atlas2.office [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id P7ce4EVGRTKs; Wed, 30 Sep 2009 09:46:33 +0200 (CEST) Received: from VENUS.office (mx1.office [192.168.24.3]) by smtp0.neclab.eu (Postfix) with ESMTP id 85A522C0002FC; Wed, 30 Sep 2009 09:46:13 +0200 (CEST) X-MIMEOLE: Produced By Microsoft Exchange V6.5 Received: from 10.1.2.178 ([10.1.2.178]) by VENUS.office ([192.168.24.102]) with Microsoft Exchange Server HTTP-DAV ; Wed, 30 Sep 2009 07:46:13 +0000 MIME-Version: 1.0 Content-class: urn:content-classes:message Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="B_3337148780_6973966" Date: Wed, 30 Sep 2009 09:46:20 +0200 Message-ID: In-Reply-To: <20090929183002.A525E3A6904@core3.amsl.com> X-MS-Has-Attach: yes X-MS-TNEF-Correlator: Thread-Topic: WG Action: RECHARTER: IP Flow Information Export (ipfix) Thread-Index: AcpBohlkQwSySp/yqkCP6UsmESpnFw== From: "Juergen Quittek" To: "IESG Secretary" , Cc: Nevil Brownlee , IETF IPFIX Working Group , Juergen Quittek Subject: Re: [IPFIX] WG Action: RECHARTER: IP Flow Information Export (ipfix) X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Sep 2009 07:45:16 -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_3337148780_6973966 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Dear all, As you can see, our new charter is in place. Thanks to everybody who contributed to proposals for new work items. I look forward to seeing -00 drafts on - anonymization support - flow selection - structuring information elements Thank you, Juergen On 29.09.09 20:30 "IESG Secretary" wrote: > The IP Flow Information Export (ipfix) working group in the Operations and > Management Area of the IETF has been rechartered. For additional > information, please contact the Area Directors or the working group > Chairs. > > IP Flow Information Export (ipfix) > --------------------------------------------------- > Current Status: Active Working Group > > Chairs: > Nevil Brownlee (n.brownlee@auckland.ac.nz) > Juergen Quittek (quittek@netlab.nec.de) > > > Operations and Management Area Directors: > Dan Romascanu (dromasca@avaya.com) > Ronald Bonica (rbonica@juniper.net) > > Operations and Management Area Advisor: > Dan Romascanu (dromasca@avaya.com) > > Mailing Lists: > General Discussion: ipfix@ietf.org > To Subscribe: http://www.ietf.org/mailman/listinfo/ipfix > Archive: http://www.ietf.org/mail-archive/web/ipfix > > Description of Working Group: > > The IPFIX working group has specified the Information Model (to describe > IP flows) and the IPFIX protocol (to transfer IP flow data from IPFIX > exporters to collectors). Several implementers have already built > applications using the IPFIX protocol. As a result of a series of IPFIX > interoperability testing events the WG has produced guidelines for IPFIX > implementation and testing as well as recommendations for handling special > cases such as bidirectional flow reporting and reducing redundancy in flow > records. > > Practical experiences with IPFIX implementations exposed new requirements > for the IPFIX protocol that so far have not been addressed by the WG. The > major current goal of the WG is developing solutions that meet the new > requirements without modifying the core IPFIX protocol specifications. > > 1. The IPFIX WG has developed a MIB module for monitoring IPFIX > implementations. Means for configuring these devices have not been > standardized yet. The WG will develop an XML-based configuration data > model that can be used for configuring IPFIX devices and for storing, > modifying and managing IPFIX configurations parameter sets. This work will > be performed in close collaboration with the NETCONF WG. > > 2. First applications of IPFIX at large operator networks showed the need > for mediation of flow information, for example, for aggregating huge > amounts of flow data and for anomymization of flow information. The IPFIX > WG will investigate this issue and produce a problem statement and a > framework for IPFIX flow mediation. > > 3. The PSAMP WG has developed a protocol for reporting observed packets. > The PSAMP protocol is an extension of the IPFIX protocol. The IPFIX WG > will develop a MIB module for monitoring PSAMP implementations. The new > MIB module will be an extension of the IPFIX MIB module. > > 4. Anonymization of flow information has been identified as a requirement > for flow information export already in RFC 3917. However, technologies for > flow anonymization are still a research issue and have so far not been > considered to be mature enough for standardization. As one step in this > direction, the IPFIX WG will develop guidelines for the implementation of > anonymized data export and storage over IPFIX and define an information > model for configuring and reporting anonymization applied at IPFIX > devices. > > 5. The IPFIX and PSAMP WGs have defined standards for selecting observed > IP packets and collecting information in flow records. In order to reduce > the amount of data to be processed, packet selection methods have been > defined. Another method for reducing flow data is flow selection. The > IPFIX WG will define methods for flow selection and provide an information > model for configuring and reporting flow selection applied at IPFIX > devices. > > 6. Being designed for the export of flow records the IPFIX protocol > provides very limited means for structuring information elements within > IPFIX records. With the increasing number of IPFIX applications there is a > need for exporting more complex information. The IPFIX WG will develop an > extension of the IPFIX protocol that supports hierarchically structured > data and lists (sequences) of Information Elements in data records. > > Goals and Milestones: > > Oct 2009 Submit Mediation Problem Statement I-D to IESG for > publication as Informational RFC > Oct 2009 Submit initial draft on anonymization support > Oct 2009 Submit initial draft on flow selection > Oct 2009 Submit initial draft on structuring information elements > Jan 2010 Submit Configuration Data Model draft to IESG for publication > as Standards track RFC > Jan 2010 Submit Mediation Framework I-D to IESG for publication as > Informational RFC > Jan 2010 Submit final version of PSAMP MIB module > Jun 2010 Submit anonymization support I-D to IESG for publication as > Experimental RFC > Jun 2010 Submit flow selection I-D to IESG for publication as > Standards Track RFC > Jun 2010 Submit structuring information elements I-D to IESG for > publication as Standards Track RFC --B_3337148780_6973966 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 YWIuZXUCBA0uKwcwCQYFKw4DAhoFAKBdMCMGCSqGSIb3DQEJBDEWBBR6WgIsLKYwqYrN7Vvm 0e+PhwdCUjAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0wOTA5 MzAwNzQ2MjBaMA0GCSqGSIb3DQEBAQUABIIBAJ/iDBRi9nIiqa96r+ntOjfcoTqr5X5TgXmm Daenrax5zRjsi90B5lJN+Li6t5LnTHTvxBgpd0c4MwLgNkQJKybrsLlhDuKzZXnUSszP1edy glL+z6LlJw3rXqMCMM0DeI9YVAT1sIOcoKd+R8ESeSbCr0jJRutAgt5pClSMmbk1svpMnBOs 8PfKSUd89kA/vz5t0w5uiH/glVtnTUFY/bCEbb96xB3dreDXJwfK7b9rMct80JIfdf/pO9Q0 6tcnIuHkyHBbYnrE2tT/DHpAJs9nRQxbwdTYArzBt0LPgzZ1djnoHrZMUMj8xFLGg3K+leR0 1LyZxG/VdK++nq2Nt2E= --B_3337148780_6973966--