From Quittek@nw.neclab.eu Mon Nov 2 02:22:30 2009 Return-Path: X-Original-To: ipfix@core3.amsl.com Delivered-To: ipfix@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 474B83A67CC for ; Mon, 2 Nov 2009 02:22:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.537 X-Spam-Level: X-Spam-Status: No, score=-2.537 tagged_above=-999 required=5 tests=[AWL=0.062, 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 CHAs6c1XtAr2 for ; Mon, 2 Nov 2009 02:22:29 -0800 (PST) Received: from smtp0.neclab.eu (smtp0.neclab.eu [195.37.70.41]) by core3.amsl.com (Postfix) with ESMTP id 0433D3A67AD for ; Mon, 2 Nov 2009 02:22:29 -0800 (PST) Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp0.neclab.eu (Postfix) with ESMTP id 7CB9A2C01D46B; Mon, 2 Nov 2009 11:22:48 +0100 (CET) X-Virus-Scanned: Amavisd on Debian GNU/Linux (atlas2.office) Received: from smtp0.neclab.eu ([127.0.0.1]) by localhost (atlas2.office [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SrTgAoviOaH9; Mon, 2 Nov 2009 11:22:48 +0100 (CET) Received: from VENUS.office (mx1.office [192.168.24.3]) by smtp0.neclab.eu (Postfix) with ESMTP id 485CA2C01918D; Mon, 2 Nov 2009 11:22:38 +0100 (CET) Received: from VENUS.office ([192.168.24.102]) by VENUS.office with Microsoft SMTPSVC(6.0.3790.3959); Mon, 2 Nov 2009 11:22:38 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Received: from 10.7.0.54 ([10.7.0.54]) by VENUS.office ([192.168.24.102]) with Microsoft Exchange Server HTTP-DAV ; Mon, 2 Nov 2009 10:22:38 +0000 MIME-Version: 1.0 Content-class: urn:content-classes:message Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="B_3340005750_35017596" Date: Mon, 2 Nov 2009 11:22:30 +0100 Message-ID: In-Reply-To: X-MS-Has-Attach: yes X-MS-TNEF-Correlator: Thread-Topic: [IPFIX] WG last call on draft-ietf-ipfix-mediators-problem-statement-06 thread-index: AcpbpmH6098zR/0lckuFvHF365XRpA== From: "Juergen Quittek" To: "sujay gupta" X-OriginalArrivalTime: 02 Nov 2009 10:22:38.0562 (UTC) FILETIME=[67152C20:01CA5BA6] Cc: IETF IPFIX Working Group Subject: Re: [IPFIX] WG last call on draft-ietf-ipfix-mediators-problem-statement-06 X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Nov 2009 10:22:30 -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_3340005750_35017596 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable Hi Sujay, Thank you for the review. On 31.10.09 08:27 "sujay gupta" wrote: > Hi, > A few comments. > 1) I have a slight problem overall with the language structuring > especially from section 1 to 4. It could be made simple. Would you have concrete suggestions? This would be helpful. Thanks, Juergen > 2) IPFIX mediation as a service or device? is intermixed, can we > differentiate that? also can we call the different type of mediators > as services? > 3) Is there any line of thought of having the mediation device > incorporate record compression to reduce b/w?( > draft-muenz-ipfix-compression) as another service, or deal with > compressed data from the original exporter? > BR, > -Sujay >=20 >=20 > On Mon, Oct 19, 2009 at 10:32 AM, Juergen Quittek > wrote: >> Dear all, >>=20 >> At our session in Stockholm we agreed to start the 2nd working group >> last call on the mediation problem state as soon as a new version >> of it would be available. The new version is >>=20 >> http://www.ietf.org/internet-drafts/draft-ietf-ipfix-mediators-problem-s= tate >> ment-06.txt >>=20 >> The call starts today and will last until Friday October 30. >>=20 >> Please read the draft! >> Please send your comments to this mailing list! >> Please also send a message if you are fine with the draft as it is! >>=20 >> Thank you, >>=20 >> =A0 =A0Juergen >>=20 >> _______________________________________________ >> IPFIX mailing list >> IPFIX@ietf.org >> https://www.ietf.org/mailman/listinfo/ipfix >>=20 >>=20 --B_3340005750_35017596 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 YWIuZXUCBA0uKwcwCQYFKw4DAhoFAKBdMCMGCSqGSIb3DQEJBDEWBBQyDICa7JM0FKgr5czx UiB0azKD/TAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0wOTEx MDIxMDIyMzBaMA0GCSqGSIb3DQEBAQUABIIBABJtWoKFNEhgsgPTy3B0HVFs1F+lbC+dD+wB 2mYAcrLomNKFnBRdIra/hq++9fWlMJkJXTrZoWA1HnKpsM1C7y9IKcDD4W9odQjZDzoSWIA2 yH21GOcEp2J4k5fHec1t6cg0jSHx6qI4W2+EGhpxMXPhLjhlvCGxFa2yRetrTEdn/WCH3XmV LyNXTfJzF4kG0kPJ69JOGn/EksllEIEan1CtFNXo9oCiW5ePg2bUshfu/WyNXoMoYy39BHhR OfrlRKExpCbtLx5PsRkQoGyo4jpkbyRqnfenaDWZvNfNHwYE7Ac5cBEi4DiljlyirvN476Df cSdYvIIY5xY+Wsv567k= --B_3340005750_35017596-- From Thomas.Dietz@nw.neclab.eu Mon Nov 2 07:53:11 2009 Return-Path: X-Original-To: ipfix@core3.amsl.com Delivered-To: ipfix@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 20E153A6A42 for ; Mon, 2 Nov 2009 07:53:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NC1ueM9r8ZKE for ; Mon, 2 Nov 2009 07:53:10 -0800 (PST) Received: from smtp0.neclab.eu (smtp0.neclab.eu [195.37.70.41]) by core3.amsl.com (Postfix) with ESMTP id 932B83A6A3D for ; Mon, 2 Nov 2009 07:53:09 -0800 (PST) Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp0.neclab.eu (Postfix) with ESMTP id 460D32C01D46B for ; Mon, 2 Nov 2009 16:53:29 +0100 (CET) X-Virus-Scanned: Amavisd on Debian GNU/Linux (atlas2.office) Received: from smtp0.neclab.eu ([127.0.0.1]) by localhost (atlas2.office [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MpF+pLzk9AJq for ; Mon, 2 Nov 2009 16:53:29 +0100 (CET) Received: from VENUS.office (mx1.office [192.168.24.3]) by smtp0.neclab.eu (Postfix) with ESMTP id 180CD2C01C99C for ; Mon, 2 Nov 2009 16:53:24 +0100 (CET) Received: from VENUS.office ([192.168.24.102]) by VENUS.office with Microsoft SMTPSVC(6.0.3790.3959); Mon, 2 Nov 2009 16:53:24 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Mon, 2 Nov 2009 16:53:21 +0100 Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_011E_01CA5BDC.FC40D340" Message-ID: <547F018265F92642B577B986577D671CE3872F@VENUS.office> In-Reply-To: <20091026160001.C2E1D3A6841@core3.amsl.com> X-MS-Has-Attach: yes X-MS-TNEF-Correlator: Thread-Topic: [IPFIX] I-D Action:draft-ietf-ipfix-mib-08.txt thread-index: AcpWVXi7xpZ+dEE+RUyj5P1v/e/LWAFfOtVQ References: <20091026160001.C2E1D3A6841@core3.amsl.com> From: "Thomas Dietz" To: X-OriginalArrivalTime: 02 Nov 2009 15:53:24.0145 (UTC) FILETIME=[9BF8D210:01CA5BD4] Subject: Re: [IPFIX] I-D Action:draft-ietf-ipfix-mib-08.txt X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Nov 2009 15:53:11 -0000 This is a multi-part message in MIME format. ------=_NextPart_000_011E_01CA5BDC.FC40D340 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Dear all, as you may have seen a new version of draft-ietf-ipfix-mib was published. Changes in this version are: - removed global ipfixExportVersion - added version information per Transport Session - removed ipfixTemplateObservationDomainId and ipfixTemplateId as index in the ipfixExportTable - minor editorial fixes One point that recently was raised by Gerhard is still open: - add Observation Domain Id into the Observation Point table if possible Best Regards, Thomas -- Thomas Dietz E-mail: Thomas.Dietz@nw.neclab.eu NEC Europe Ltd. Phone: +49 6221 4342-128 NEC Laboratories Europe Fax: +49 6221 4342-155 Network Research Division Kurfuersten-Anlage 36 69115 Heidelberg, Germany http://www.nw.neclab.eu NEC Europe Limited Registered in England 2832014 Registered Office: NEC House, 1 Victoria Road, London W3 6BL > -----Original Message----- > From: ipfix-bounces@ietf.org [mailto:ipfix-bounces@ietf.org] On Behalf > Of Internet-Drafts@ietf.org > Sent: Montag, 26. Oktober 2009 17:00 > To: i-d-announce@ietf.org > Cc: ipfix@ietf.org > Subject: [IPFIX] I-D Action:draft-ietf-ipfix-mib-08.txt > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > This draft is a work item of the IP Flow Information Export Working > Group of the IETF. > > > Title : Definitions of Managed Objects for IP Flow > Information Export > Author(s) : T. Dietz, et al. > Filename : draft-ietf-ipfix-mib-08.txt > Pages : 67 > Date : 2009-10-26 > > This document defines managed objects for IP Flow Information Export > (IPFIX). These objects provide information for monitoring IPFIX > Exporters and IPFIX Collectors including the basic configuration > information. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-ipfix-mib-08.txt > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > Below is the data which will enable a MIME compliant mail reader > implementation to automatically retrieve the ASCII version of the > Internet-Draft. ------=_NextPart_000_011E_01CA5BDC.FC40D340 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIISNzCCA58w ggKHoAMCAQICASYwDQYJKoZIhvcNAQEFBQAwcTELMAkGA1UEBhMCREUxHDAaBgNVBAoTE0RldXRz Y2hlIFRlbGVrb20gQUcxHzAdBgNVBAsTFlQtVGVsZVNlYyBUcnVzdCBDZW50ZXIxIzAhBgNVBAMT GkRldXRzY2hlIFRlbGVrb20gUm9vdCBDQSAyMB4XDTk5MDcwOTEyMTEwMFoXDTE5MDcwOTIzNTkw MFowcTELMAkGA1UEBhMCREUxHDAaBgNVBAoTE0RldXRzY2hlIFRlbGVrb20gQUcxHzAdBgNVBAsT FlQtVGVsZVNlYyBUcnVzdCBDZW50ZXIxIzAhBgNVBAMTGkRldXRzY2hlIFRlbGVrb20gUm9vdCBD QSAyMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAqwujNeCLKRSxFIWvPBDkOW81XUqu 3ephjZVJ9G9koxpgZqSpQCKE2dSl5XiTDmgBrblNXDrO07ioQkDfz6O6gllqkhusHJraCCslJ/lp I0fx4Ossepv1EwLQfjR8wp48AFmr9doM9TI8K6xQ2tbD3oOUyqgMmTIOCEhWW2r72uFYWAFJX3JB PBUGAY5draq4k7TNnuun6GotUjTbOu9cdVHa2/Mx+e5xmDLEVBVEDPmbVe2t3xgIoKOGiknuUwWP GUzV3lh5m9JqHEKrxdWnz2gPluThYZh2YciRfNY+AOKRUIfhnQrmrZfSHcY6fcu82gM01Y5bAfVq B7cWtm5KfwIDAQABo0IwQDAdBgNVHQ4EFgQUMcN5G7r1U9cX4Il6LRdsCrMrnTMwDwYDVR0TBAgw BgEB/wIBBTAOBgNVHQ8BAf8EBAMCAQYwDQYJKoZIhvcNAQEFBQADggEBAJRkWa05ZOcp6xP+WsOL E1fIBCTwdHfAYONn++mJpoO/loJ8btTDPe+egG67KbSYerE7VOs5F0d+Go4L/B8xWTEEss4X8yzH YjZV4iLYiVW0mEiqZPrWHDbYRHhaWiM6V5f1ejBPrp9qTEsrjqAD4z7gqdTSe9KzqOJyPK2e/4BZ 5JtFtPY7sM05GZgy5eohYZDkMSGONLH3LzVKhRDa54o3Ib5ZY+DyhYgxU9RUFIVwefQuBncndS8f uIr5/sW62Dbkg+znZbe/Y1rzRq+BlDfUQYzWI9Yez/VoG0Rjolq6pzVZoeVwBZsOI1eZlAptujlj KIaS8xiE2PvRzwVWZFcwggQhMIIDCaADAgECAgIAxzANBgkqhkiG9w0BAQUFADBxMQswCQYDVQQG EwJERTEcMBoGA1UEChMTRGV1dHNjaGUgVGVsZWtvbSBBRzEfMB0GA1UECxMWVC1UZWxlU2VjIFRy dXN0IENlbnRlcjEjMCEGA1UEAxMaRGV1dHNjaGUgVGVsZWtvbSBSb290IENBIDIwHhcNMDYxMjE5 MTAyOTAwWhcNMTkwNjMwMjM1OTAwWjBaMQswCQYDVQQGEwJERTETMBEGA1UEChMKREZOLVZlcmVp bjEQMA4GA1UECxMHREZOLVBLSTEkMCIGA1UEAxMbREZOLVZlcmVpbiBQQ0EgR2xvYmFsIC0gRzAx MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA6ZvDZ4X5Da71jVTDllA1PWLpbkztlNcA W5UidNQg6zSP1uzAMQQLmYHiphTSUqAoI4SLdIkEXlvg4njBeMsWyyg1OXstkEXQ7aAAeny/Sg4b AMOG6VwrMRF7DPOCJEOMHDiLamgAmu7cT3ir0sYTm3at7t4m6O8Br3QPwQmi9mvOvdPNFDBP9eXj pMhim4IaAycwDQJlYE3t0QkjKpY1WCfTdsZxtpAdxO3/NYZ9bzOz2w/FEcKKg6GUXUFr2NIQ9Uz9 ylGs2b3vkoO72uuLFlZWQ8/h1RM9ph8nMM1JVNvJEzSacXXFbOqnC5j5IZ0nrz6jOTlIaoytyZn7 wxLyvQIDAQABo4HZMIHWMHAGA1UdHwRpMGcwZaBjoGGGX2h0dHA6Ly9wa2kudGVsZXNlYy5kZS9j Z2ktYmluL3NlcnZpY2UvYWZfRG93bmxvYWRBUkwuY3JsPy1jcmxfZm9ybWF0PVhfNTA5Ji1pc3N1 ZXI9RFRfUk9PVF9DQV8yMB0GA1UdDgQWBBRJt8bP6D0ff+pEexMp9/EKcD7eZDAfBgNVHSMEGDAW gBQxw3kbuvVT1xfgiXotF2wKsyudMzAOBgNVHQ8BAf8EBAMCAQYwEgYDVR0TAQH/BAgwBgEB/wIB AjANBgkqhkiG9w0BAQUFAAOCAQEAO+Fad8BIF9ypGOyBr1qJ8L0okqbKWRgScOwo8ueuf5Ys5/Jd GTH2Eyt0vb2Asrn3Z8k5onk74RER7mt4kTN+O18mJ3VTZY4zY+7Pc8OwkiNJIVB1I6EfGOKUhT0/ M+l3II2iveahhSlA9j9zMlgNCWum2oVswD+7jWZkViROrg0/MjUBW+mMgtlyWU+xhoXxdIVW5cP4 XPON7kezUwVw5+VNimmDKOETCYaeXsjqWB4MH/mk1FoEaP0oPosCtli19qEsN1cAZ6sjaI1jpe+Z a1z9S1b2q0CHNNQRkmzsh8UKCwczcrRvDB1ULNhRx8y/MNNDcvEyv4zOSWOoAPfyHDCCBS8wggQX oAMCAQICBA0hCkcwDQYJKoZIhvcNAQEFBQAwWjELMAkGA1UEBhMCREUxEzARBgNVBAoTCkRGTi1W ZXJlaW4xEDAOBgNVBAsTB0RGTi1QS0kxJDAiBgNVBAMTG0RGTi1WZXJlaW4gUENBIEdsb2JhbCAt IEcwMTAeFw0wODEwMjQwODUyMDhaFw0xOTA2MzAwMDAwMDBaMIGQMQswCQYDVQQGEwJERTEYMBYG A1UEChMPTkVDIEV1cm9wZSBMdGQuMSAwHgYDVQQLExdORUMgTGFib3JhdG9yaWVzIEV1cm9wZTES MBAGA1UEAxMJTkVDTEFCLUNBMTEwLwYJKoZIhvcNAQkBFiJ6ZXJ0aWZpemllcnVuZ3NzdGVsbGVA bncubmVjbGFiLmV1MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAnvIVsbURqjIOcbnf ruYkRceWOZpyvM2ebnYpbd1cP+zdWm6yR7HSO9ppOe1ZZFIasArqQpedPEFvcncSG94FRuW3ND4r Rcq08mbpUTmpWmXfdYlJpQezbsOHCWR74NXoEEbK6TPZIMFpJr6dzQDAxnRc7UOgO6JQ1V42Z39B PhIbPIWz64t8svafxbORmxulJn7F5zDLDcR1AEGyn+L9b645AGwapoKNh7cSQFTqdb6kGyPQjLWf tv09dvmBDKesrcyLZXuDWJ1LMeizSjUEygdSszNXD3gePgJaVaZDS3o923W5gAyPCTSxpAFj8XJ+ /7Ap5jJwYhjJgJ8khFR7JQIDAQABo4IBxDCCAcAwEgYDVR0TAQH/BAgwBgEB/wIBATALBgNVHQ8E BAMCAQYwHQYDVR0OBBYEFE8ch3od4C+Z9r4VqtE1nQ5K5ro2MB8GA1UdIwQYMBaAFEm3xs/oPR9/ 6kR7Eyn38QpwPt5kMC0GA1UdEQQmMCSBInplcnRpZml6aWVydW5nc3N0ZWxsZUBudy5uZWNsYWIu ZXUwgYgGA1UdHwSBgDB+MD2gO6A5hjdodHRwOi8vY2RwMS5wY2EuZGZuLmRlL2dsb2JhbC1yb290 LWNhL3B1Yi9jcmwvY2FjcmwuY3JsMD2gO6A5hjdodHRwOi8vY2RwMi5wY2EuZGZuLmRlL2dsb2Jh bC1yb290LWNhL3B1Yi9jcmwvY2FjcmwuY3JsMIGiBggrBgEFBQcBAQSBlTCBkjBHBggrBgEFBQcw AoY7aHR0cDovL2NkcDEucGNhLmRmbi5kZS9nbG9iYWwtcm9vdC1jYS9wdWIvY2FjZXJ0L2NhY2Vy dC5jcnQwRwYIKwYBBQUHMAKGO2h0dHA6Ly9jZHAyLnBjYS5kZm4uZGUvZ2xvYmFsLXJvb3QtY2Ev cHViL2NhY2VydC9jYWNlcnQuY3J0MA0GCSqGSIb3DQEBBQUAA4IBAQBsMQ+dD0mmi48dgDU4R6Q/ eXcY0zQcHNp1Vu1s3kwO0WahWB0tiqVBodvfTAWG44xuw0I7NXSTwQ68FU5P0GIQnvRFZyVJlDjr SNlLYxjqfmgb+KVm67o383cZIuDakEE0f29kULIEn2fg/HsDiBAXTsb4I19XaN0TXLI+PMhU+GDp sGCJrydeugEV7qi15q8yymjSAsYgnrc2wJuXpyQ9r3qCtP6aedAPSHqOT8ga1dLT2YRZFs3vNm7T HSr5JJymWMbfpD6OcbRTnNAjSMDHwJxgRBAflA6WzDVm7fk4jiWyLvJwWTMk19t8QLiKG7D0nYvj cEUYyiOSE+SFUTEdMIIFODCCBCCgAwIBAgIEDTI0WzANBgkqhkiG9w0BAQUFADCBkDELMAkGA1UE BhMCREUxGDAWBgNVBAoTD05FQyBFdXJvcGUgTHRkLjEgMB4GA1UECxMXTkVDIExhYm9yYXRvcmll cyBFdXJvcGUxEjAQBgNVBAMTCU5FQ0xBQi1DQTExMC8GCSqGSIb3DQEJARYiemVydGlmaXppZXJ1 bmdzc3RlbGxlQG53Lm5lY2xhYi5ldTAeFw0wODExMDYwOTIwMTFaFw0xMTExMDYwOTIwMTFaMGAx CzAJBgNVBAYTAkRFMRgwFgYDVQQKEw9ORUMgRXVyb3BlIEx0ZC4xIDAeBgNVBAsTF05FQyBMYWJv cmF0b3JpZXMgRXVyb3BlMRUwEwYDVQQDEwxUaG9tYXMgRGlldHowggEiMA0GCSqGSIb3DQEBAQUA A4IBDwAwggEKAoIBAQCniLuqlMflMs7ag3idESVRwfZ9nrdIyUmq5Tget4k9APGSPo2GZ1f1hr8y MuJIGowc/HzS1laVSICclOXju1xW93Tm+Vco5gwkRqHXY3Rmda0r2jlb8niVie4qXQgXPzunFRqk yNmbwYep3oD5Kq0GfB6EuZ7X6cYH5A7erAMeeQPhoDQDIfR79lRHlcMtanJZyORYNQONPEa+L4AF v5f3nAsmY7ZLJ72wX7X8BtcF6Vdkr0T2b1YrPl8Qir7e0TKY9Rf0q5DKu3QdLnXk0Rb+63V/4vLS PZ3XQVdwHzLiOhIZJVVMJE7TmJI0DFeDFn99O/F/Le/sJOJjNO4n6KMLAgMBAAGjggHHMIIBwzAJ BgNVHRMEAjAAMAsGA1UdDwQEAwIF4DApBgNVHSUEIjAgBggrBgEFBQcDAgYIKwYBBQUHAwQGCisG AQQBgjcUAgIwHQYDVR0OBBYEFLkbmpJJpIXhIR9JFttGC+KHW5g5MB8GA1UdIwQYMBaAFE8ch3od 4C+Z9r4VqtE1nQ5K5ro2MCQGA1UdEQQdMBuBGVRob21hcy5EaWV0ekBudy5uZWNsYWIuZXUwfQYD VR0fBHYwdDA4oDagNIYyaHR0cDovL2NkcDEucGNhLmRmbi5kZS9uZWNsYWItY2EvcHViL2NybC9j YWNybC5jcmwwOKA2oDSGMmh0dHA6Ly9jZHAyLnBjYS5kZm4uZGUvbmVjbGFiLWNhL3B1Yi9jcmwv Y2FjcmwuY3JsMIGYBggrBgEFBQcBAQSBizCBiDBCBggrBgEFBQcwAoY2aHR0cDovL2NkcDEucGNh LmRmbi5kZS9uZWNsYWItY2EvcHViL2NhY2VydC9jYWNlcnQuY3J0MEIGCCsGAQUFBzAChjZodHRw Oi8vY2RwMi5wY2EuZGZuLmRlL25lY2xhYi1jYS9wdWIvY2FjZXJ0L2NhY2VydC5jcnQwDQYJKoZI hvcNAQEFBQADggEBAEbKwRBhNxAzsH6kAYRBoIziyI2IY2QnZGeiGitOfkLKcFNIBH3ZfQXH4j20 4BP34Vzzob17EgsbLbNkMlxh2M7tenXH9vA4MiN5yPPBKoR7SfI6mIaIr+7kewOizJ8D5dvpdfP5 HbAUTZVSYHqixgBWJyNp7sXWVQtOo+eOv8qKUeiodClanKuCnGD42Bl6EQR486dlXvOronEikRYX Xg6gFrhO+DonUYluMZpNdabnybKozchSdHcceOKd0JFMmyiSNG944ystXbR7QZqfNSh/Pbyc5QRp Z1vdFZLFh907iS3KxueDYKDPWmlsPt/QnmXmF4A9/5OrmVS1C45k5rcxggQ4MIIENAIBATCBmTCB kDELMAkGA1UEBhMCREUxGDAWBgNVBAoTD05FQyBFdXJvcGUgTHRkLjEgMB4GA1UECxMXTkVDIExh Ym9yYXRvcmllcyBFdXJvcGUxEjAQBgNVBAMTCU5FQ0xBQi1DQTExMC8GCSqGSIb3DQEJARYiemVy dGlmaXppZXJ1bmdzc3RlbGxlQG53Lm5lY2xhYi5ldQIEDTI0WzAJBgUrDgMCGgUAoIICczAYBgkq hkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0wOTExMDIxNTUzMjFaMCMGCSqG SIb3DQEJBDEWBBRuk4kOZsue5dglqql1ms10qMcjKDCBqgYJKwYBBAGCNxAEMYGcMIGZMIGQMQsw CQYDVQQGEwJERTEYMBYGA1UEChMPTkVDIEV1cm9wZSBMdGQuMSAwHgYDVQQLExdORUMgTGFib3Jh dG9yaWVzIEV1cm9wZTESMBAGA1UEAxMJTkVDTEFCLUNBMTEwLwYJKoZIhvcNAQkBFiJ6ZXJ0aWZp emllcnVuZ3NzdGVsbGVAbncubmVjbGFiLmV1AgQNMjRbMIGsBgsqhkiG9w0BCRACCzGBnKCBmTCB kDELMAkGA1UEBhMCREUxGDAWBgNVBAoTD05FQyBFdXJvcGUgTHRkLjEgMB4GA1UECxMXTkVDIExh Ym9yYXRvcmllcyBFdXJvcGUxEjAQBgNVBAMTCU5FQ0xBQi1DQTExMC8GCSqGSIb3DQEJARYiemVy dGlmaXppZXJ1bmdzc3RlbGxlQG53Lm5lY2xhYi5ldQIEDTI0WzCBtwYJKoZIhvcNAQkPMYGpMIGm MAsGCWCGSAFlAwQBKjALBglghkgBZQMEARYwCgYIKoZIhvcNAwcwCwYJYIZIAWUDBAECMA4GCCqG SIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDAHBgUrDgMC GjALBglghkgBZQMEAgMwCwYJYIZIAWUDBAICMAsGCWCGSAFlAwQCATAKBggqhkiG9w0CBTANBgkq hkiG9w0BAQEFAASCAQCi/5bUIWLyLQd9k1WYCeQmot5WlxY2oeRhd3czAJWF/Z8Xt4EsrvX43F8s ffYvemlYebCcda4U78gsPki9FHyDtXpMUZYn7+YouQzhttUkVP9dgv7q+xo8CQnWNBdYT0VhXCLz i1wzIUW2ljOghiUwUWKkmoHWpMvbnaUevPXNM0h24y3C70r498lb4Gdn4b3vIJ458oZ/p9owaIGm 6RiheL4k1n2TLNfgYuxfbo3QZMnocGzNeO5dqmqo2fTU+hlmVgMX1ID4PvyKOzvKfy+uxV9g7QC5 QWaTzZfmykLjVfietg+ROhktGiDWaa7TO+of7V3HPI90G1c2UPlqk6VaAAAAAAAA ------=_NextPart_000_011E_01CA5BDC.FC40D340-- From akoba@nttv6.net Mon Nov 2 09:51: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 1376F3A6911 for ; Mon, 2 Nov 2009 09:51:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.245 X-Spam-Level: X-Spam-Status: No, score=-0.245 tagged_above=-999 required=5 tests=[AWL=-2.355, BAYES_00=-2.599, HELO_EQ_LOCALHOST=0.457, HELO_LOCALHOST=3.941, HOST_MISMATCH_NET=0.311] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id anOHr9jG3-iK for ; Mon, 2 Nov 2009 09:51:44 -0800 (PST) Received: from mail.nttv6.net (mail.nttv6.net [IPv6:2001:fa8::25]) by core3.amsl.com (Postfix) with ESMTP id B1A713A68CD for ; Mon, 2 Nov 2009 09:51:43 -0800 (PST) Received: from localhost (mail.nttv6.net [192.16.178.5]) by mail.nttv6.net (8.14.3/8.14.3) with ESMTP id nA2Hpws0028538; Tue, 3 Nov 2009 02:52:00 +0900 (JST) (envelope-from akoba@nttv6.net) Date: Tue, 03 Nov 2009 02:52:01 +0900 From: Atsushi Kobayashi To: Brian Trammell In-Reply-To: References: <4AE5CF2F.1000702@cisco.com> Message-Id: <20091103013945.A518.17391CF2@nttv6.net> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Becky! ver. 2.46 [ja] X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.3 (mail.nttv6.net [192.16.178.5]); Tue, 03 Nov 2009 02:52:00 +0900 (JST) Cc: "ipfix@ietf.org Working Group" Subject: Re: [IPFIX] WGLC comments on draft-ietf-ipfix-mediators-problem-statement-06 X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Nov 2009 17:51:48 -0000 Hi Brian, all, Thank you for the review. On Tue, 27 Oct 2009 11:16:05 +0100 Brian Trammell wrote: > Greetings, all, > > Please find below my WGLC comments on the Mediator PS draft. > > The Implementation Analyses in Section 5.x are in my opinion still too > tied to specific mediator devices. We're talking about Concentrators > and Masquerading Proxies and Distributors as if there was a > substantive difference among them. There isn't. There are Mediators. > They run Intermediate Functions. They accept IPFIX, or something like > it (e.g. NetFlow). They produce IPFIX. They might change the content > or framing based on configuration and state. Drawing more restrictive > labeled boxes around specific types of intermediate functions risks > limiting flexibility and provides the impression that complicated > mediation might require multiple devices. > To state the applicability of mediator, it would be preferable to mention more concrete device and specific scenario. Although we can replace all of specific mediator with mediator, but we should say somewhere what is the difference between mediator and concentrator/proxy in RFC3917. > However, we've had this discussion for a very long time without coming > to agreement, and it's a relatively minor point, so I'm willing to let > these sections go as they are. However, I will state that I find the > Intermediate Process and Mediator definitions in the Terminology to be > quite useful (as they should be considering the amount of work we put > into them before and during the Stockholm meeting :) ), but the > others, not so much. > > The Security Considerations section is a little week; I suspect the > IESG in particular will require a more in-depth analysis of Mediator- > specific attacks. Mitigation could, of course, also be handled in the > Mediator Protocol draft. One thing that came up in the 5655 review is > the issue of chains of trust, so I suspect there will also be > questions about how a final collector will be able to authenticate an > Original Exporter across a Mediator. But these can be handled at the > IESG stage. > Thank you for your suggestion. Security Considerations section in RFC 5655 could be applied to Exporter-Mediator-Collector structure. I would add the following paragraph by its reference, is it fine? o End-to-End Assertions Note that End-to-End channel that is Exporter-to-Collector via Mediator channel may be untrusted, even though the Mediator-to-Collector channel is trusted. When the Mediator-to-Collector channel is trusted and the Exporter and the Mediator are identified by their certificates, the Data Records may be implicitly asserted to be trusted. > (Also, one very minor nit, in the Acknowledgments sections, my last > name is spelled Trammell.) > Sorry for that. Regards, Atsushi > Best regards, > > Brian > _______________________________________________ > IPFIX mailing list > IPFIX@ietf.org > https://www.ietf.org/mailman/listinfo/ipfix -- Atsushi Kobayashi From akoba@nttv6.net Mon Nov 2 09:59:14 2009 Return-Path: X-Original-To: ipfix@core3.amsl.com Delivered-To: ipfix@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 21FDF3A6994 for ; Mon, 2 Nov 2009 09:59:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.932 X-Spam-Level: X-Spam-Status: No, score=0.932 tagged_above=-999 required=5 tests=[AWL=-1.177, BAYES_00=-2.599, HELO_EQ_LOCALHOST=0.457, HELO_LOCALHOST=3.941, HOST_MISMATCH_NET=0.311] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ySyZKjDt94Rp for ; Mon, 2 Nov 2009 09:59:13 -0800 (PST) Received: from mail.nttv6.net (mail.nttv6.net [IPv6:2001:fa8::25]) by core3.amsl.com (Postfix) with ESMTP id A12E13A682A for ; Mon, 2 Nov 2009 09:59:12 -0800 (PST) Received: from localhost (mail.nttv6.net [192.16.178.5]) by mail.nttv6.net (8.14.3/8.14.3) with ESMTP id nA2HxVF4028573; Tue, 3 Nov 2009 02:59:31 +0900 (JST) (envelope-from akoba@nttv6.net) Date: Tue, 03 Nov 2009 02:59:32 +0900 From: Atsushi Kobayashi To: Keisuke ISHIBASHI In-Reply-To: <20091028.092728.74746876.ishibashi.keisuke@lab.ntt.co.jp> References: <20091028.092728.74746876.ishibashi.keisuke@lab.ntt.co.jp> Message-Id: <20091103025456.A51B.17391CF2@nttv6.net> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Becky! ver. 2.46 [ja] X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.3 (mail.nttv6.net [192.16.178.5]); Tue, 03 Nov 2009 02:59:31 +0900 (JST) Cc: ipfix@ietf.org Subject: Re: [IPFIX] WGLC comments on draft-ietf-ipfix-mediators-problem-statement-06 X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Nov 2009 17:59:14 -0000 Hi Ishibashi-san, Thank you for the review. On Wed, 28 Oct 2009 09:27:28 +0900 (JST) Keisuke ISHIBASHI wrote: > Hi all, > > Although it's about specific mediator devices, I'm bit uncertain of > the hierachical collection system built with IPFIX Concentrators in > Section 5.2. > If the Cocentrators only aggregate the flow records from original > Exporters, then, from the Collector's point of view, there is no > difference from the case that the original Exporters gererate > aggregated flow records. I don't have a image that this type of > mediator provide a solution to the problem stated in Section 4.1. > What about an example that those Concentrators have retention > capabilities of original Flow Records, as follow: > > To cope with the increase of IPFIX Exporters and traffic, one > possible implementation uses IPFIX Concentrators with Collecting > Process to build a hierarchical collection system. > It's fine with me. > , which is similar to the last implementation example in Section 5.7. > This is a very minor comment, however, I'm willing to go on as they > are. > > > The Security Considerations section is a little week; I suspect the > > IESG in particular will require a more in-depth analysis of Mediator- > > specific attacks. > > Yes, for example, weakening of the trust chain by supporting legacy > protocols may be one of the above case? > Could you please see my proposal in another mail. Regards, Atsushi > Best regards, > Keisuke ISHIBASHI > NTT Information Sharing Platform Labs. > > > From: Brian Trammell > Subject: [IPFIX] WGLC comments on > draft-ietf-ipfix-mediators-problem-statement-06 > Date: Tue, 27 Oct 2009 11:16:05 +0100 > Message-ID: > > > Greetings, all, > > > > Please find below my WGLC comments on the Mediator PS draft. > > > > The Implementation Analyses in Section 5.x are in my opinion still too > > tied to specific mediator devices. We're talking about Concentrators > > and Masquerading Proxies and Distributors as if there was a > > substantive difference among them. There isn't. There are Mediators. > > They run Intermediate Functions. They accept IPFIX, or something like > > it (e.g. NetFlow). They produce IPFIX. They might change the content > > or framing based on configuration and state. Drawing more restrictive > > labeled boxes around specific types of intermediate functions risks > > limiting flexibility and provides the impression that complicated > > mediation might require multiple devices. > > > > However, we've had this discussion for a very long time without coming > > to agreement, and it's a relatively minor point, so I'm willing to let > > these sections go as they are. However, I will state that I find the > > Intermediate Process and Mediator definitions in the Terminology to be > > quite useful (as they should be considering the amount of work we put > > into them before and during the Stockholm meeting :) ), but the > > others, not so much. > > > > The Security Considerations section is a little week; I suspect the > > IESG in particular will require a more in-depth analysis of Mediator- > > specific attacks. Mitigation could, of course, also be handled in the > > Mediator Protocol draft. One thing that came up in the 5655 review is > > the issue of chains of trust, so I suspect there will also be > > questions about how a final collector will be able to authenticate an > > Original Exporter across a Mediator. But these can be handled at the > > IESG stage. > > > > (Also, one very minor nit, in the Acknowledgments sections, my last > > name is spelled Trammell.) > > > > Best regards, > > > > Brian > > _______________________________________________ > > IPFIX mailing list > > IPFIX@ietf.org > > https://www.ietf.org/mailman/listinfo/ipfix > _______________________________________________ > IPFIX mailing list > IPFIX@ietf.org > https://www.ietf.org/mailman/listinfo/ipfix -- Atsushi Kobayashi From sujay.ietf@gmail.com Tue Nov 3 10:14: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 C37B728C14D for ; Tue, 3 Nov 2009 10:14:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tyk2QQ9JdNLQ for ; Tue, 3 Nov 2009 10:14:47 -0800 (PST) Received: from mail-px0-f171.google.com (mail-px0-f171.google.com [209.85.216.171]) by core3.amsl.com (Postfix) with ESMTP id 223CE3A6A10 for ; Tue, 3 Nov 2009 10:14:38 -0800 (PST) Received: by pxi1 with SMTP id 1so4628270pxi.32 for ; Tue, 03 Nov 2009 10:14:55 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=Wx42rbj8zUKDVXyo/6kWLlgRlgVFqqbThY0vFEUPbRo=; b=DeS2l1Gu2zcaTsareuPErVcUZvK25G8SLUC/4a8jBhGCW3DBeXjGZN6eTt5PF7HQvG fJprXASe7mF7z45mxqmpIFy+sKG7Bsc/UEC3DeBv4YHX/0y5arQ7mWi/D4Nb1H3j68lJ g7q5ulJwqfXu/eK48flcOGU15YUPltkl/ESXA= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=g5C1wNfaW00VjK14CAhtDjT9img4fOQ0EcoYvVCqHCqaNHJqYKM1AIsGJ86H/nX1bG WK0Op4Cpy7Wsx0MNHnGcMQ+O58bN8TofE31u25G1A1W1N3JyQMsO5yIWqcdf45HneTJy Bkb4Yzo1K6Ms2AX0IMNa75LlyDl/1cgnkUuF4= MIME-Version: 1.0 Received: by 10.142.249.40 with SMTP id w40mr32372wfh.344.1257272095631; Tue, 03 Nov 2009 10:14:55 -0800 (PST) In-Reply-To: References: Date: Tue, 3 Nov 2009 23:44:55 +0530 Message-ID: From: sujay gupta To: Juergen Quittek Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: IETF IPFIX Working Group Subject: Re: [IPFIX] WG last call on draft-ietf-ipfix-mediators-problem-statement-06 X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Nov 2009 18:14:49 -0000 Hi, I am overall fine with the doc. small changes however would help such as; section 4.1, last para mentions the need of system not relying on data reduction techniques, section 4.4 contradicts it. section 1, first para, between first and second line could mention that "traffic monitoring is taxing on the resources" and hence the need for optimization( ie the 2nd line). last line in the para says "platform", is it required? perhaps having a figure showing the position of ipfix-med amongst other layers( section 2) would be a nice addition. BR, -Sujay On Mon, Nov 2, 2009 at 3:52 PM, Juergen Quittek wrot= e: > Hi Sujay, > > Thank you for the review. > > On 31.10.09 08:27 =A0"sujay gupta" wrote: > >> Hi, >> A few comments. >> 1) I have a slight problem overall with the language structuring >> especially from section 1 to 4. It could be made simple. > > Would you have concrete suggestions? This would be helpful. > > Thanks, > > =A0 =A0Juergen > > >> 2) IPFIX mediation as a service or device? is intermixed, can we >> differentiate that? also can we call the different type of mediators >> as services? >> 3) Is there any line of thought of having the mediation device >> incorporate record compression to reduce b/w?( >> draft-muenz-ipfix-compression) as another service, or deal with >> compressed data from the original exporter? >> BR, >> -Sujay >> >> >> On Mon, Oct 19, 2009 at 10:32 AM, Juergen Quittek >> wrote: >>> Dear all, >>> >>> At our session in Stockholm we agreed to start the 2nd working group >>> last call on the mediation problem state as soon as a new version >>> of it would be available. The new version is >>> >>> http://www.ietf.org/internet-drafts/draft-ietf-ipfix-mediators-problem-= state >>> ment-06.txt >>> >>> The call starts today and will last until Friday October 30. >>> >>> Please read the draft! >>> Please send your comments to this mailing list! >>> Please also send a message if you are fine with the draft as it is! >>> >>> Thank you, >>> >>> =A0 =A0Juergen >>> >>> _______________________________________________ >>> IPFIX mailing list >>> IPFIX@ietf.org >>> https://www.ietf.org/mailman/listinfo/ipfix >>> >>> > From limmer@informatik.uni-erlangen.de Tue Nov 3 11:38: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 55A413A6908 for ; Tue, 3 Nov 2009 11:38:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.249 X-Spam-Level: X-Spam-Status: No, score=-2.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GcaGgxfgg98L for ; Tue, 3 Nov 2009 11:38:12 -0800 (PST) Received: from faui45.informatik.uni-erlangen.de (faui45.informatik.uni-erlangen.de [131.188.34.45]) by core3.amsl.com (Postfix) with ESMTP id 315543A690D for ; Tue, 3 Nov 2009 11:38:11 -0800 (PST) Received: from faui7as (faui7as.informatik.uni-erlangen.de [131.188.37.230]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by faui45.informatik.uni-erlangen.de (Postfix) with ESMTPS id 20AB3462A; Tue, 3 Nov 2009 20:38:31 +0100 (MET) Received: from faui7ma3.informatik.uni-erlangen.de (faui7ma3.informatik.uni-erlangen.de [131.188.37.40]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by faui7as (Postfix) with ESMTPSA id ED7794382FA; Tue, 3 Nov 2009 20:38:30 +0100 (CET) From: Tobias Limmer To: Benoit Claise In-Reply-To: <4AEABCFB.70505@cisco.com> References: <7A07131A-78E8-44DA-85A7-FF7D839A6AA8@tik.ee.ethz.ch> <4AEABCFB.70505@cisco.com> Message-Id: <978917B0-172E-4DB1-AE06-03B9A107F446@informatik.uni-erlangen.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed; delsp=yes Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Apple Message framework v936) Date: Tue, 3 Nov 2009 20:38:30 +0100 X-Mailer: Apple Mail (2.936) Cc: ipfix@ietf.org Subject: Re: [IPFIX] Fwd: I-D ACTION:draft-ietf-ipfix-export-per-sctp-stream-04.txt X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Nov 2009 19:38:13 -0000 Hi Benoit, all, I've also got a few comments on the draft ipfix-export-per-sctp-=20 stream-04: 2.3. Limitations: "This method requires multiple SCTP streams in the association between =20= the Exporting and Collecting Process, ideally one per Template." No - if we had only one Template in the association, we would not need =20= multiple SCTP streams. 3.1.1. IPFIX Protocol Specifications Limitation: "Note that a workaround allowed by the IPFIX specifications [RFC5101] =20= is to use only one Template Record per SCTP Transport Session, at the =20= cost of multiplying the number of SCTP Transport Sessions when =20 multiple Template Records are required." This paragraph sounds a little misplaced, as it already mentions the =20 performance impact. After reading it, I was wondering what other =20 method would be proposed in this draft. 4.2. Template Management: "Any Data Sets associated with a Template Record MUST be sent on the =20 same SCTP stream on which the Template Record was sent." According to rfc5101, an Options Template Record is a Template Record. =20= Later in the same section you specify: "When the Options Template and =20= associated Data Records are sent in different SCTP streams, [...]". Isn't this a contradiction, or am I missing something here? 4.5. The Collecting Process's Side: "3. A Data Record is received unreliably although it is expected to be =20= sent reliably (due to a previously received Data Record associated =20 with the Data Record Reliability Options Template)." Is it possible for the receiving side of a SCTP connection to =20 determine which SCTP messages were sent unreliably? I did not find any =20= indication of that in rfc3758. T=10he receiving side only knows if =20 complete messages or fragments are skipped. 4.5. The Collecting Process's Side: "In the case where the Exporting Process does not support the [...]" This paragraph is a duplicate. 6. Examples: In Figure 3, you seem to use the Options Reliability Template 257 =20 (defined in Figure 1) that was received in another stream. A small =20 remark would be good which indicates, that all streams belong to the =20 same SCTP association. Thanks, Tobi -- Dipl.-Inf. Tobias Limmer Chair for Computer Networks and Communication Systems Universit=E4t Erlangen-N=FCrnberg Martensstr. 3, D-91058 Erlangen, Germany Phone: +49-9131-8527931 Fax: +49-9131-8527409 eMail: limmer .at. informatik.uni-erlangen.de URL: http://www7.informatik.uni-erlangen.de/~limmer From muenz@net.in.tum.de Wed Nov 4 00:54: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 CFD103A68BA for ; Wed, 4 Nov 2009 00:54:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.219 X-Spam-Level: X-Spam-Status: No, score=-2.219 tagged_above=-999 required=5 tests=[AWL=0.030, 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 EI6BAwtQ4gPn for ; Wed, 4 Nov 2009 00:54:47 -0800 (PST) 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 66D1B3A6A91 for ; Wed, 4 Nov 2009 00:54:38 -0800 (PST) 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 AC15B4834B; Wed, 4 Nov 2009 09:54:56 +0100 (CET) Received: from [131.159.20.108] (repulse.net.in.tum.de [131.159.20.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by phoenix.net.informatik.tu-muenchen.de (Postfix) with ESMTP id 9B60E509D; Wed, 4 Nov 2009 09:54:56 +0100 (CET) Message-ID: <4AF1419F.2000008@net.in.tum.de> Date: Wed, 04 Nov 2009 09:55:59 +0100 From: Gerhard Muenz User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Tobias Limmer References: <7A07131A-78E8-44DA-85A7-FF7D839A6AA8@tik.ee.ethz.ch> <4AEABCFB.70505@cisco.com> <978917B0-172E-4DB1-AE06-03B9A107F446@informatik.uni-erlangen.de> In-Reply-To: <978917B0-172E-4DB1-AE06-03B9A107F446@informatik.uni-erlangen.de> Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms060000020307050806010703" X-Virus-Scanned: ClamAV using ClamSMTP Cc: ipfix@ietf.org Subject: Re: [IPFIX] Fwd: I-D ACTION:draft-ietf-ipfix-export-per-sctp-stream-04.txt X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Nov 2009 08:54:48 -0000 This is a cryptographically signed message in MIME format. --------------ms060000020307050806010703 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable Hi Tobias, Thanks for your comments. Some replies inline. Tobias Limmer wrote: > Hi Benoit, all, >=20 > I've also got a few comments on the draft ipfix-export-per-sctp-=20 > stream-04: >=20 >=20 > 2.3. Limitations: > "This method requires multiple SCTP streams in the association between = =20 > the Exporting and Collecting Process, ideally one per Template." >=20 > No - if we had only one Template in the association, we would not need = =20 > multiple SCTP streams. Indeed, this formulation can be relaxed a little bit. > 3.1.1. IPFIX Protocol Specifications Limitation: > "Note that a workaround allowed by the IPFIX specifications [RFC5101] = > is to use only one Template Record per SCTP Transport Session, at the = > cost of multiplying the number of SCTP Transport Sessions when =20 > multiple Template Records are required." >=20 > This paragraph sounds a little misplaced, as it already mentions the =20 > performance impact. After reading it, I was wondering what other =20 > method would be proposed in this draft. Not sure if you got the paragraph right. It talks about SCTP Transport=20 Sessions, not SCTP streams. Using different Transport Sessions requires=20 indeed much more overhead (e.g., multiple sockets) than just having=20 multiple streams in one Transport Session. > 4.2. Template Management: > "Any Data Sets associated with a Template Record MUST be sent on the =20 > same SCTP stream on which the Template Record was sent." >=20 > According to rfc5101, an Options Template Record is a Template Record. = =20 > Later in the same section you specify: "When the Options Template and = > associated Data Records are sent in different SCTP streams, [...]". > Isn't this a contradiction, or am I missing something here? This is a flaw of IPFIX terminology. In the text, we tried to consistently use "(Options) Template" if we=20 talk about both Options and non-Options Templates. The sentence above is = just about non-Options Templates. Not sure, how we can make this more comprehensible. Maybe a note in the=20 terminology section? > 4.5. The Collecting Process's Side: > "3. A Data Record is received unreliably although it is expected to be = =20 > sent reliably (due to a previously received Data Record associated =20 > with the Data Record Reliability Options Template)." >=20 > Is it possible for the receiving side of a SCTP connection to =20 > determine which SCTP messages were sent unreliably? I did not find any = =20 > indication of that in rfc3758. T=10he receiving side only knows if =20 > complete messages or fragments are skipped. I think you are right. We need to check. Regards, Gerhard > 4.5. The Collecting Process's Side: > "In the case where the Exporting Process does not support the [...]" >=20 > This paragraph is a duplicate. > > 6. Examples: > In Figure 3, you seem to use the Options Reliability Template 257 =20 > (defined in Figure 1) that was received in another stream. A small =20 > remark would be good which indicates, that all streams belong to the =20 > same SCTP association. >=20 >=20 > Thanks, > Tobi >=20 >=20 >=20 > -- > Dipl.-Inf. Tobias Limmer > Chair for Computer Networks and Communication Systems > Universit=E4t Erlangen-N=FCrnberg > Martensstr. 3, D-91058 Erlangen, Germany > Phone: +49-9131-8527931 Fax: +49-9131-8527409 > eMail: limmer .at. informatik.uni-erlangen.de > URL: http://www7.informatik.uni-erlangen.de/~limmer >=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 --------------ms060000020307050806010703 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 SIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMDkxMTA0MDg1NTU5WjAjBgkqhkiG9w0BCQQxFgQU G78b6U71nZ4gihib8J5kSFowdv4wXwYJKoZIhvcNAQkPMVIwUDALBglghkgBZQMEAQIwCgYI KoZIhvcNAwcwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqG SIb3DQMCAgEoMIGFBgkrBgEEAYI3EAQxeDB2MGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxU aGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwg RnJlZW1haWwgSXNzdWluZyBDQQIQKsXq3Tdl1UZFGbLpOSCnTzCBhwYLKoZIhvcNAQkQAgsx eKB2MGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBM dGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQQIQKsXq 3Tdl1UZFGbLpOSCnTzANBgkqhkiG9w0BAQEFAASCAQCyXq7AepQPdh2rollE6vm6LKd8qUmk xU0j53ozkNQN0s1bzIGPQsHn35y2AV+g9arLd1hoXWkrTKezO6VcEhwviHRqxoGnn62MrfEE 2up0GlBdV+i4aJb9EwqK5lebiV7s5prXEptMINRnMcvvDsJMz7SUmGZsHMc7YmA+4p/fpZoQ 9kpEibak9sMvVFxAQl1AMUq2JEwmuQEfb33t9NaEfMFn+6ZKeJFE7PlOT2jpJ3hdIKVrMXRr Iavp1unSlM13kTNQLH2Dj7AqoHbprynhcNt6SN9KKhZrAJgfBD0i4bSdcLmM0w9gaAdnXNFs DXADdwRUcPvqaOf2MhGh0HgSAAAAAAAA --------------ms060000020307050806010703-- From trammell@tik.ee.ethz.ch Wed Nov 4 01:30: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 678B23A68B8 for ; Wed, 4 Nov 2009 01:30:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=-0.001, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9emoo58HQS8w for ; Wed, 4 Nov 2009 01:30:11 -0800 (PST) Received: from smtp.ee.ethz.ch (smtp.ee.ethz.ch [129.132.2.219]) by core3.amsl.com (Postfix) with ESMTP id 5E5D13A683B for ; Wed, 4 Nov 2009 01:30:11 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by smtp.ee.ethz.ch (Postfix) with ESMTP id 2EED1D9360; Wed, 4 Nov 2009 10:30:31 +0100 (MET) X-Virus-Scanned: by amavisd-new on smtp.ee.ethz.ch Received: from smtp.ee.ethz.ch ([127.0.0.1]) by localhost (.ee.ethz.ch [127.0.0.1]) (amavisd-new, port 10024) with LMTP id DBh1p03+CK5o; Wed, 4 Nov 2009 10:30:30 +0100 (MET) Received: from pb-10072.ethz.ch (pb-10072.ethz.ch [82.130.103.195]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: briant) by smtp.ee.ethz.ch (Postfix) with ESMTP id A3B89D9326; Wed, 4 Nov 2009 10:30:30 +0100 (MET) Mime-Version: 1.0 (Apple Message framework v1076) Content-Type: multipart/alternative; boundary=Apple-Mail-39--153043846 From: Brian Trammell In-Reply-To: <20091103013945.A518.17391CF2@nttv6.net> Date: Wed, 4 Nov 2009 10:30:30 +0100 Message-Id: <4DC61418-D84B-470F-8956-D8DE7F986E2B@tik.ee.ethz.ch> References: <4AE5CF2F.1000702@cisco.com> <20091103013945.A518.17391CF2@nttv6.net> To: Atsushi Kobayashi X-Mailer: Apple Mail (2.1076) Cc: "ipfix@ietf.org Working Group" Subject: Re: [IPFIX] WGLC comments on draft-ietf-ipfix-mediators-problem-statement-06 X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Nov 2009 09:30:13 -0000 --Apple-Mail-39--153043846 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii; format=flowed; delsp=yes hi Atsushi, replies as always inline... On Nov 2, 2009, at 6:52 PM, Atsushi Kobayashi wrote: > Hi Brian, all, > > Thank you for the review. > > On Tue, 27 Oct 2009 11:16:05 +0100 > Brian Trammell wrote: > >> Greetings, all, >> >> Please find below my WGLC comments on the Mediator PS draft. >> >> The Implementation Analyses in Section 5.x are in my opinion still >> too >> tied to specific mediator devices. We're talking about Concentrators >> and Masquerading Proxies and Distributors as if there was a >> substantive difference among them. There isn't. There are Mediators. >> They run Intermediate Functions. They accept IPFIX, or something like >> it (e.g. NetFlow). They produce IPFIX. They might change the content >> or framing based on configuration and state. Drawing more restrictive >> labeled boxes around specific types of intermediate functions risks >> limiting flexibility and provides the impression that complicated >> mediation might require multiple devices. >> > > To state the applicability of mediator, it would be preferable to > mention more concrete device and specific scenario. > Although we can replace all of specific mediator with mediator, but we > should say somewhere what is the difference between mediator and > concentrator/proxy in RFC3917. I think a statement in the Terminology section for Mediator could easily state "Note that the Mediator is a generalization of the Concentrator and Proxy elements envisioned in the IPFIX Requirements [RFC3917]; Mediators running appropriate Intermediate Processes provide the functionality specified therein." and then we can dispense with the 3917-legacy language. But only if we want to go that route. At this point, as I said, it's not really important and we've burned enough time on it, so I'm happy letting it go as is. >> However, we've had this discussion for a very long time without >> coming >> to agreement, and it's a relatively minor point, so I'm willing to >> let >> these sections go as they are. However, I will state that I find the >> Intermediate Process and Mediator definitions in the Terminology to >> be >> quite useful (as they should be considering the amount of work we put >> into them before and during the Stockholm meeting :) ), but the >> others, not so much. >> >> The Security Considerations section is a little week; I suspect the >> IESG in particular will require a more in-depth analysis of Mediator- >> specific attacks. Mitigation could, of course, also be handled in the >> Mediator Protocol draft. One thing that came up in the 5655 review is >> the issue of chains of trust, so I suspect there will also be >> questions about how a final collector will be able to authenticate an >> Original Exporter across a Mediator. But these can be handled at the >> IESG stage. >> > > Thank you for your suggestion. > Security Considerations section in RFC 5655 could be applied to > Exporter-Mediator-Collector structure. I would add the following > paragraph by its reference, is it fine? > > o End-to-End Assertions > > Note that End-to-End channel that is Exporter-to-Collector via > Mediator > channel may be untrusted, even though the Mediator-to-Collector > channel > is trusted. When the Mediator-to-Collector channel is trusted and the > Exporter and the Mediator are identified by their certificates, > the Data Records may be implicitly asserted to be trusted. hm, not exactly... While the problem is analogous, the end-to-end assertion language was a direct reply to a question raised by Sam Hartman about the applicability of an EP->CP->File path for law enforcement applications, where certain chain of evidence requirements are imposed on what the File knows about the EP. The problem with mediators is a general case of this. Further, the Collector cannot know a priori that the Mediator got a good certificate from the Exporter. We can use a similar approach to File, and state that a Mediator must not sign a TLS session when the data source was not verified; of course, this breaks the potential use case where a Mediator is used to retransmit non-encrypted UDP messages from a private messages to the open internet over DTLS/SCTP or TLS/ TCP. So we have to be careful there. Actually, on second thought, _solving_ this problem should be done in the Framework, not the Problem Statement. So I'd defer the hard work of actually making this consistent to the later draft. > >> (Also, one very minor nit, in the Acknowledgments sections, my last >> name is spelled Trammell.) >> > > Sorry for that. No problem. :) I lose the second 'L' about a quarter of the time. Best regards, Brian --Apple-Mail-39--153043846 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii hi = Atsushi,

replies as always = inline...

On Nov 2, 2009, at 6:52 PM, = Atsushi Kobayashi wrote:

Hi = Brian, all,

Thank you for the review.

On Tue, 27 Oct 2009 = 11:16:05 +0100
Brian Trammell <trammell@tik.ee.ethz.ch> = wrote:

Greetings, = all,

Please find = below my WGLC comments on the Mediator PS = draft.

The = Implementation Analyses in Section 5.x are in my opinion still too =  
tied to specific = mediator devices. We're talking about Concentrators =  
and Masquerading = Proxies and Distributors as if there was a =  
substantive difference = among them. There isn't. There are Mediators. =  
They run Intermediate = Functions. They accept IPFIX, or something like =  
it (e.g. NetFlow). They = produce IPFIX. They might change the content =  
or framing based on = configuration and state. Drawing more restrictive =  
labeled boxes around = specific types of intermediate functions risks =  
limiting flexibility = and provides the impression that complicated =  
mediation might require = multiple devices.


To state the applicability of = mediator, it would be preferable to
mention more concrete device and = specific scenario.
Although we can replace all of specific mediator = with mediator, but we
should say somewhere what is the difference = between mediator and
concentrator/proxy in = RFC3917.

I think a statement = in the Terminology section for Mediator could easily state "Note that = the Mediator is a generalization of the Concentrator and Proxy elements = envisioned in the IPFIX Requirements [RFC3917]; Mediators running = appropriate Intermediate Processes provide the functionality specified = therein." and then we can dispense with the 3917-legacy language. But = only if we want to go that route. At this point, as I said, it's not = really important and we've burned enough time on it, so I'm happy = letting it go as is.

However, we've had this discussion for a very long time = without coming  
to = agreement, and it's a relatively minor point, so I'm willing to let =  
these sections go as = they are. However, I will state that I find the =  
Intermediate Process = and Mediator definitions in the Terminology to be =  
quite useful (as they = should be considering the amount of work we put =  
into them before and = during the Stockholm meeting :) ), but the =  
others, not so = much.

The Security = Considerations section is a little week; I suspect the =  
IESG in particular will = require a more in-depth analysis of Mediator- =
specific attacks. Mitigation = could, of course, also be handled in the =  
Mediator Protocol = draft. One thing that came up in the 5655 review is =  
the issue of chains of = trust, so I suspect there will also be =  
questions about how a = final collector will be able to authenticate an =  
Original Exporter = across a Mediator. But these can be handled at the =  
IESG = stage.


Thank you for your suggestion. =
Security Considerations section in RFC 5655 could be applied = to
Exporter-Mediator-Collector structure. I would add the following =
paragraph by its reference, is it fine?

o  End-to-End = Assertions

Note that End-to-End channel that is = Exporter-to-Collector via Mediator
channel may be untrusted, even = though the Mediator-to-Collector channel
is trusted. When the = Mediator-to-Collector channel is trusted and the
Exporter and the = Mediator are identified by their certificates,
the Data Records may = be implicitly asserted to be = trusted.

hm, not exactly... = While the problem is analogous, the end-to-end assertion language was a = direct reply to a question raised by Sam Hartman about the applicability = of an EP->CP->File path for law enforcement applications, where = certain chain of evidence requirements are imposed on what the File = knows about the EP. The problem with mediators is a general case of = this. 

Further, the Collector cannot know = a priori that the Mediator got a good certificate from the Exporter. We = can use a similar approach to File, and state that a Mediator must not = sign a TLS session when the data source was not verified; of course, = this breaks the potential use case where a Mediator is used to = retransmit non-encrypted UDP messages from a private messages to the = open internet over DTLS/SCTP or TLS/TCP. So we have to be careful = there.

Actually, on second thought, _solving_ = this problem should be done in the Framework, not the Problem Statement. = So I'd defer the hard work of actually making this consistent to the = later draft.


(Also, one very minor nit, in the Acknowledgments = sections, my last  
name = is spelled Trammell.)


Sorry for = that.

No problem. :) I lose = the second 'L' about a quarter of the = time. 

Best = regards,

Brian

= = --Apple-Mail-39--153043846-- From limmer@informatik.uni-erlangen.de Wed Nov 4 01:51: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 2781A3A67B8 for ; Wed, 4 Nov 2009 01:51:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.249 X-Spam-Level: X-Spam-Status: No, score=-2.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id REp3-Gsg+1Et for ; Wed, 4 Nov 2009 01:51:47 -0800 (PST) Received: from faui45.informatik.uni-erlangen.de (faui45.informatik.uni-erlangen.de [131.188.34.45]) by core3.amsl.com (Postfix) with ESMTP id 23B1B3A67AE for ; Wed, 4 Nov 2009 01:51:46 -0800 (PST) Received: from faui7as (faui7as.informatik.uni-erlangen.de [131.188.37.230]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by faui45.informatik.uni-erlangen.de (Postfix) with ESMTPS id A174447BB; Wed, 4 Nov 2009 10:52:06 +0100 (MET) Received: from faui7ma3.informatik.uni-erlangen.de (faui7ma3.informatik.uni-erlangen.de [131.188.37.40]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by faui7as (Postfix) with ESMTPSA id 7EC514401E3; Wed, 4 Nov 2009 10:52:06 +0100 (CET) From: Tobias Limmer To: Gerhard Muenz In-Reply-To: <4AF1419F.2000008@net.in.tum.de> References: <7A07131A-78E8-44DA-85A7-FF7D839A6AA8@tik.ee.ethz.ch> <4AEABCFB.70505@cisco.com> <978917B0-172E-4DB1-AE06-03B9A107F446@informatik.uni-erlangen.de> <4AF1419F.2000008@net.in.tum.de> Message-Id: <5FB55758-05FE-47AE-BE8B-9F4E48C1FC75@informatik.uni-erlangen.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed; delsp=yes Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Apple Message framework v936) Date: Wed, 4 Nov 2009 10:52:06 +0100 X-Mailer: Apple Mail (2.936) Cc: ipfix@ietf.org Subject: Re: [IPFIX] Fwd: I-D ACTION:draft-ietf-ipfix-export-per-sctp-stream-04.txt X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Nov 2009 09:51:48 -0000 Hi Gerhard, comments inline! On 04.11.2009, at 09:55, Gerhard Muenz wrote: > Tobias Limmer wrote: >> 3.1.1. IPFIX Protocol Specifications Limitation: >> "Note that a workaround allowed by the IPFIX specifications =20 >> [RFC5101] is to use only one Template Record per SCTP Transport =20 >> Session, at the cost of multiplying the number of SCTP Transport =20 >> Sessions when multiple Template Records are required." >> This paragraph sounds a little misplaced, as it already mentions =20 >> the performance impact. After reading it, I was wondering what =20 >> other method would be proposed in this draft. > > Not sure if you got the paragraph right. It talks about SCTP =20 > Transport Sessions, not SCTP streams. Using different Transport =20 > Sessions requires indeed much more overhead (e.g., multiple sockets) =20= > than just having multiple streams in one Transport Session. Oh right, I misunderstood. But then you should always use the term =20 'SCTP association' instead of 'SCTP transport session', as you've =20 already done in the rest of the document, except section 2.2. ("[...] =20= active within a single SCTP Transport Session and [...]"). >> 4.2. Template Management: >> "Any Data Sets associated with a Template Record MUST be sent on =20 >> the same SCTP stream on which the Template Record was sent." >> According to rfc5101, an Options Template Record is a Template =20 >> Record. Later in the same section you specify: "When the Options =20 >> Template and associated Data Records are sent in different SCTP =20 >> streams, [...]". >> Isn't this a contradiction, or am I missing something here? > > This is a flaw of IPFIX terminology. > > In the text, we tried to consistently use "(Options) Template" if we =20= > talk about both Options and non-Options Templates. The sentence =20 > above is just about non-Options Templates. > > Not sure, how we can make this more comprehensible. Maybe a note in =20= > the terminology section? Yes, I agree, as you are using this terminology in the whole document. Regards, Tobi -- Dipl.-Inf. Tobias Limmer Chair for Computer Networks and Communication Systems Universit=E4t Erlangen-N=FCrnberg Martensstr. 3, D-91058 Erlangen, Germany Phone: +49-9131-8527931 Fax: +49-9131-8527409 eMail: limmer .at. informatik.uni-erlangen.de URL: http://www7.informatik.uni-erlangen.de/~limmer From akoba@nttv6.net Wed Nov 4 09:17:41 2009 Return-Path: X-Original-To: ipfix@core3.amsl.com Delivered-To: ipfix@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 047EE3A65A6 for ; Wed, 4 Nov 2009 09:17:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.199 X-Spam-Level: X-Spam-Status: No, score=0.199 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001, SUBJ_RE_NUM=2.799] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id z-sbyJAZ2eL9 for ; Wed, 4 Nov 2009 09:17:40 -0800 (PST) Received: from mail.nttv6.net (mail.nttv6.net [IPv6:2001:fa8::25]) by core3.amsl.com (Postfix) with ESMTP id 5036A3A681C for ; Wed, 4 Nov 2009 09:17:39 -0800 (PST) Received: from [10.10.10.20] ([IPv6:2001:fa8:1000:0:68fd:6a2a:87d9:e00c]) by mail.nttv6.net (8.14.3/8.14.3) with ESMTP id nA4HHxjF043943; Thu, 5 Nov 2009 02:17:59 +0900 (JST) (envelope-from akoba@nttv6.net) Date: Thu, 05 Nov 2009 02:07:52 +0900 From: Atsushi Kobayashi To: Brian Trammell In-Reply-To: <4DC61418-D84B-470F-8956-D8DE7F986E2B@tik.ee.ethz.ch> References: <20091103013945.A518.17391CF2@nttv6.net> <4DC61418-D84B-470F-8956-D8DE7F986E2B@tik.ee.ethz.ch> Message-Id: <20091105014539.9968.17391CF2@nttv6.net> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Becky! ver. 2.50.05 [ja] (Unregistered) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.3 (mail.nttv6.net [IPv6:2001:fa8::25]); Thu, 05 Nov 2009 02:17:59 +0900 (JST) Cc: "ipfix@ietf.org Working Group" Subject: Re: [IPFIX] WGLC comments on draft-ietf-ipfix-mediators-problem-statement-06 X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Nov 2009 17:17:41 -0000 Hi Brian, On Wed, 4 Nov 2009 10:30:30 +0100 Brian Trammell wrote: > hi Atsushi, > > replies as always inline... > > On Nov 2, 2009, at 6:52 PM, Atsushi Kobayashi wrote: > > > Hi Brian, all, > > > > Thank you for the review. > > > > On Tue, 27 Oct 2009 11:16:05 +0100 > > Brian Trammell wrote: > > > >> Greetings, all, > >> > >> Please find below my WGLC comments on the Mediator PS draft. > >> > >> The Implementation Analyses in Section 5.x are in my opinion still > >> too > >> tied to specific mediator devices. We're talking about Concentrators > >> and Masquerading Proxies and Distributors as if there was a > >> substantive difference among them. There isn't. There are Mediators. > >> They run Intermediate Functions. They accept IPFIX, or something like > >> it (e.g. NetFlow). They produce IPFIX. They might change the content > >> or framing based on configuration and state. Drawing more restrictive > >> labeled boxes around specific types of intermediate functions risks > >> limiting flexibility and provides the impression that complicated > >> mediation might require multiple devices. > >> > > > > To state the applicability of mediator, it would be preferable to > > mention more concrete device and specific scenario. > > Although we can replace all of specific mediator with mediator, but we > > should say somewhere what is the difference between mediator and > > concentrator/proxy in RFC3917. > > I think a statement in the Terminology section for Mediator could > easily state "Note that the Mediator is a generalization of the > Concentrator and Proxy elements envisioned in the IPFIX Requirements > [RFC3917]; Mediators running appropriate Intermediate Processes > provide the functionality specified therein." and then we can dispense > with the 3917-legacy language. But only if we want to go that route. > At this point, as I said, it's not really important and we've burned > enough time on it, so I'm happy letting it go as is. You and Gerhard share same opinion. If other members including co-authors agree so, I will try to follow the above suggestion. > > >> However, we've had this discussion for a very long time without > >> coming > >> to agreement, and it's a relatively minor point, so I'm willing to > >> let > >> these sections go as they are. However, I will state that I find the > >> Intermediate Process and Mediator definitions in the Terminology to > >> be > >> quite useful (as they should be considering the amount of work we put > >> into them before and during the Stockholm meeting :) ), but the > >> others, not so much. > >> > >> The Security Considerations section is a little week; I suspect the > >> IESG in particular will require a more in-depth analysis of Mediator- > >> specific attacks. Mitigation could, of course, also be handled in the > >> Mediator Protocol draft. One thing that came up in the 5655 review is > >> the issue of chains of trust, so I suspect there will also be > >> questions about how a final collector will be able to authenticate an > >> Original Exporter across a Mediator. But these can be handled at the > >> IESG stage. > >> > > > > Thank you for your suggestion. > > Security Considerations section in RFC 5655 could be applied to > > Exporter-Mediator-Collector structure. I would add the following > > paragraph by its reference, is it fine? > > > > o End-to-End Assertions > > > > Note that End-to-End channel that is Exporter-to-Collector via > > Mediator > > channel may be untrusted, even though the Mediator-to-Collector > > channel > > is trusted. When the Mediator-to-Collector channel is trusted and the > > Exporter and the Mediator are identified by their certificates, > > the Data Records may be implicitly asserted to be trusted. > > hm, not exactly... While the problem is analogous, the end-to-end > assertion language was a direct reply to a question raised by Sam > Hartman about the applicability of an EP->CP->File path for law > enforcement applications, where certain chain of evidence requirements > are imposed on what the File knows about the EP. The problem with > mediators is a general case of this. > If we consider more general case, it is a little bit hard work at this stage. > Further, the Collector cannot know a priori that the Mediator got a > good certificate from the Exporter. We can use a similar approach to > File, and state that a Mediator must not sign a TLS session when the > data source was not verified; of course, this breaks the potential use > case where a Mediator is used to retransmit non-encrypted UDP messages > from a private messages to the open internet over DTLS/SCTP or TLS/ > TCP. So we have to be careful there. > Yes, above use case is conceivable. As you mentioned, applicable use cases and security requirement seem a contradictory argument. > Actually, on second thought, _solving_ this problem should be done in > the Framework, not the Problem Statement. So I'd defer the hard work > of actually making this consistent to the later draft. > Ok. Could you please continue to post the relevant suggestion. > > > >> (Also, one very minor nit, in the Acknowledgments sections, my last > >> name is spelled Trammell.) > >> > > > > Sorry for that. > > No problem. :) I lose the second 'L' about a quarter of the time. > I'm looking forward to meeting you at Hiroshima. Regards, Atsushi > Best regards, > > Brian > --- Atsushi KOBAYASHI NTT Information Sharing Platform Lab. tel:+81-(0)422-59-3978 fax:+81-(0)422-59-5637 From muenz@net.in.tum.de Fri Nov 6 08:49:42 2009 Return-Path: X-Original-To: ipfix@core3.amsl.com Delivered-To: ipfix@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 13F033A6904 for ; Fri, 6 Nov 2009 08:49:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.479 X-Spam-Level: X-Spam-Status: No, score=-1.479 tagged_above=-999 required=5 tests=[AWL=-0.719, BAYES_05=-1.11, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2ib3vFD-MtGK for ; Fri, 6 Nov 2009 08:49:40 -0800 (PST) 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 98CA13A68FA for ; Fri, 6 Nov 2009 08:49:40 -0800 (PST) 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 7919E48481 for ; Fri, 6 Nov 2009 17:50:02 +0100 (CET) Received: from [131.159.20.108] (repulse.net.in.tum.de [131.159.20.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by phoenix.net.informatik.tu-muenchen.de (Postfix) with ESMTP id 5CFD73822 for ; Fri, 6 Nov 2009 17:50:02 +0100 (CET) Message-ID: <4AF453FB.8020408@net.in.tum.de> Date: Fri, 06 Nov 2009 17:51:07 +0100 From: Gerhard Muenz User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: ipfix@ietf.org References: <20091026160001.C2E1D3A6841@core3.amsl.com> <547F018265F92642B577B986577D671CE3872F@VENUS.office> In-Reply-To: <547F018265F92642B577B986577D671CE3872F@VENUS.office> Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms050909060106090503010805" X-Virus-Scanned: ClamAV using ClamSMTP Subject: Re: [IPFIX] I-D Action:draft-ietf-ipfix-mib-08.txt X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Nov 2009 16:49:42 -0000 This is a cryptographically signed message in MIME format. --------------ms050909060106090503010805 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable Dear all, Thomas Dietz wrote: > Dear all,=20 >=20 > as you may have seen a new version of draft-ietf-ipfix-mib was publishe= d. > Changes in this version are: >=20 > - removed global ipfixExportVersion > - added version information per Transport Session > - removed ipfixTemplateObservationDomainId and ipfixTemplateId as index= in > the ipfixExportTable > - minor editorial fixes >=20 > One point that recently was raised by Gerhard is still open: >=20 > - add Observation Domain Id into the Observation Point table if possibl= e Let me explain this issue a bit more. We have the following Observation Point table: ipfixObservationPointTable(6) | +-ipfixObservationPointEntry(1)=20 [ipfixObservationPointGroupId,ipfixObservationPointIndex] | + Unsigned32 ipfixObservationPointGroupId(1) + Unsigned32 ipfixObservationPointIndex(2) + PhysicalIndexOrZero ipfixObservationPointPhysicalEntity(3) + Enumeration ipfixObservationPointPhysicalEntityDirection(4) From this table, it is not possible to retrieve the Observation Domain=20 ID of an Observation Point. If an IPFIX Exporter establishes a Transport Session to a Collector,=20 there is an entry in the Transport Session table. Associated to this=20 entry, we have the Templates in the Template table. There, we can=20 finally find the Observation Domain ID. This procedure is quite complicated and does not work if no Transport=20 Sessions are established. Possible solutions: 1) We do not care because nobody is interested in the mapping between=20 Observation Points and Observation Domains. 2) We add ipfixObservationPointObservationDomainId to the Observation=20 Point table (as a normal parameter, not as an index). Personally, I prefer solution 2. There is a related issue regarding the relationship between Observation=20 Domain and Metering Process. RFC5101 says: Observation Domain An Observation Domain is the largest set of Observation Points for= which Flow information can be aggregated by a Metering Process. Some people interpreted this definition as if only packets of a single=20 Observation Domain may enter a Metering Process/Cache. In this case, it = follows that Observations Points sharing the same=20 ipfixObservationPointGroupId must have identical Observation Domain ID=20 values. This fact could be added in the description clause of=20 ipfixObservationPointGroupId: "All Observation Points belonging to the same group must belong to the= same Observation Domain." However, I understand the definition differently. IMO, it does not say=20 that packets from different Observation Domains must not enter the same=20 Metering Process. It just says that a single Flow Record only accounts=20 packets of a single Observation Domain. To achieve this, it is=20 sufficient that the Metering Process/Cache treats the Observation Domain = ID as an additional Flow Key. It would be nice to get to an agreement regarding the understanding of=20 the relationship between Observation Domain and Metering Process. The outcome does not only concern the IPFIX-MIB, but also the=20 configuration data model. Best regards, Gerhard --=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 --------------ms050909060106090503010805 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 SIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMDkxMTA2MTY1MTA3WjAjBgkqhkiG9w0BCQQxFgQU 8HnBobvz41fz9rLwM1nU75g0gLswXwYJKoZIhvcNAQkPMVIwUDALBglghkgBZQMEAQIwCgYI KoZIhvcNAwcwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqG SIb3DQMCAgEoMIGFBgkrBgEEAYI3EAQxeDB2MGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxU aGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwg RnJlZW1haWwgSXNzdWluZyBDQQIQKsXq3Tdl1UZFGbLpOSCnTzCBhwYLKoZIhvcNAQkQAgsx eKB2MGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBM dGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQQIQKsXq 3Tdl1UZFGbLpOSCnTzANBgkqhkiG9w0BAQEFAASCAQA1qYdz0sM4tCgPKBf9FCn1yUe38Cv1 yCKbfdVRqRHkTQCKzzWqvBIzcYZSPAp2nQIhRI5YkOeP7DpBMJBKi57CQKeCgCQKvtzt2JFH JCSRuQSMSsypzeJhn93L0Uy2f4Yv8a85H+DXoqowci/lhLi0EegjXFX4Qp1xvzP/dADazOUF fRFVYH5WJTltSs+sGP/YaeEl16hELatWHF/je1ulGEYqvqWjYzoZfirCGE2MuNsG0CA/6g3t EroUTn89BZPLU3QC1klyqRfSQr5u5AkfpABQx4JL69OqkgydV1gUHx2CFKP/5Uay8Q2FNGQ5 wAh6G0vlDptPj9rTUGGoHSj/AAAAAAAA --------------ms050909060106090503010805-- From muenz@net.in.tum.de Sun Nov 8 13:17:04 2009 Return-Path: X-Original-To: ipfix@core3.amsl.com Delivered-To: ipfix@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AD48E3A6782 for ; Sun, 8 Nov 2009 13:17:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.351 X-Spam-Level: X-Spam-Status: No, score=0.351 tagged_above=-999 required=5 tests=[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 G6+Trdju-9eL for ; Sun, 8 Nov 2009 13:17:04 -0800 (PST) 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 CEC803A685B for ; Sun, 8 Nov 2009 13:17:02 -0800 (PST) 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 3617E48652 for ; Sun, 8 Nov 2009 22:17:16 +0100 (CET) Received: from [192.168.128.99] (ppp-93-104-84-182.dynamic.mnet-online.de [93.104.84.182]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by phoenix.net.informatik.tu-muenchen.de (Postfix) with ESMTP id DCD18B41 for ; Sun, 8 Nov 2009 22:17:15 +0100 (CET) Message-ID: <4AF73525.8050009@net.in.tum.de> Date: Sun, 08 Nov 2009 22:16:21 +0100 From: Gerhard Muenz User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: ipfix@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV using ClamSMTP Subject: [IPFIX] Semantic and structured data X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 08 Nov 2009 21:17:04 -0000 Dear all, Regarding draft-ietf-ipfix-structured-data, I see the risk that the semantic of the exported structured data is not clear. How do you interpret the manifold occurrence of the same Information Element (basicList) or the same group of Information Elements (subTemplateList) in one record? What does it mean if basicList, subTemplateList, or subTemplateMultiList is used for a Flow Key field? Or non-key field? Some Examples: - BasicList of egress interfaces in a Flow Record How should a Flow Record be interpreted which contains a list of egress interfaces and a packet counter? Has every counted packet been sent on every egress interface? => multicast case, AND semantic (see example in section 8.1) Has every counted packet been sent on any one of the egress interfaces? => load balancing case, OR semantic Can it be used as a Flow Key or not? - BasicList of destination ports in a Flow Record As every packet has only one destination port, the only reasonable interpretation is that the Flow contains packets having one of the reported port numbers. => OR semantic This would be a non-key field. I think there are two solutions: 1. We decide that the semantic of list content is out of scope of draft-ietf-ipfix-structured-data. We add a note to the draft that the semantic must be clear from the context or the definition of the Information Elements used within the lists. 2. We define semantic lists, such as - andBasicList, andSubTemplateList, andSubTemplateMultiList - orBasicList, orSubTemplateList, orSubTempalteMultiList describing AND and OR semantic of the contained IEs/Templates, respectively. As I wrote in an earlier mail, I see a good use case for orBasicList. It could be used in the Selector Report Interpretation of Property Match Filtering to report a filter like "port 80 or port 443". http://www.ietf.org/mail-archive/web/ipfix/current/msg04856.html At the moment, the Selector Report Interpretation is limited to AND. However, if we also want to express a NOT, we still need another solution... Regards, Gerhard From andy@netconfcentral.com Mon Nov 9 12:53: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 97CB43A6BBF for ; Mon, 9 Nov 2009 12:53:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.505 X-Spam-Level: X-Spam-Status: No, score=-1.505 tagged_above=-999 required=5 tests=[AWL=-0.441, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, J_CHICKENPOX_22=0.6, J_CHICKENPOX_64=0.6, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lwQqGpbe2IF8 for ; Mon, 9 Nov 2009 12:53:15 -0800 (PST) Received: from smtp127.sbc.mail.sp1.yahoo.com (smtp127.sbc.mail.sp1.yahoo.com [69.147.65.186]) by core3.amsl.com (Postfix) with SMTP id 094F03A6A25 for ; Mon, 9 Nov 2009 12:53:15 -0800 (PST) Received: (qmail 17147 invoked from network); 9 Nov 2009 20:53:39 -0000 Received: from adsl-67-125-158-26.dsl.irvnca.pacbell.net (andy@67.125.158.26 with plain) by smtp127.sbc.mail.sp1.yahoo.com with SMTP; 09 Nov 2009 12:53:39 -0800 PST X-Yahoo-SMTP: Z6xhxCCswBAlhcxjVNwaQtp4EKpLdTUUf5Nx_pGy81o- X-YMail-OSG: pXuwwSAVM1kg6RLHLSxsu8fAWaECTy1gu6w9lOzvj.26ux7Brmgt4Oq01PL7Tk0phNSkbiFeqmRC0ttSht2ORiaqLIykruqk5X_E7ICCnQ2qAc7gT4LAtEO9u._58lZn65aR8Qs_7Rs79UxKpr.IzF.7tUWC5..gz6RoYyiiRAk0GjfjThXT2KkZV5.TE.21T7sBkFyis_zBqMR00lNUwMuzg9tFbh0DRLOPF7fHJt3P_HtTYGW9Xdr52jSQ1LJB X-Yahoo-Newman-Property: ymail-3 Message-ID: <4AF88164.1000001@netconfcentral.com> Date: Mon, 09 Nov 2009 12:53:56 -0800 From: Andy Bierman User-Agent: Thunderbird 2.0.0.23 (X11/20090817) MIME-Version: 1.0 To: IPFIX Working Group Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: NETMOD Working Group Subject: [IPFIX] 2 bugs in ietf-ipfix-psamp.yang X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Nov 2009 20:53:15 -0000 Hi, I use your data model to test my YANG compiler. It is complaining about the latest version. In 'list selectionProcess', the must-stmt has an extra right parenthesis at the end. Within that list, 'list selector' has a unique-stmt for a non-config leaf (selectorId), even though that list is config=true. I am not sure this is an error though. I cc:ed the NETMOD WG because it is not clear if yang-08, sec 8.* covers this usage. I think a config=true node can only define constraints on other config=true nodes. If this is not the case, then the YANG draft (sec 8.1) should make that clear. The data-not-unique error does not apply, but the YANG text in sec. 13.1 does not make that clear. thanks, Andy From mbj@tail-f.com Mon Nov 9 15:31:30 2009 Return-Path: X-Original-To: ipfix@core3.amsl.com Delivered-To: ipfix@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5D9193A68A0; Mon, 9 Nov 2009 15:31:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.398 X-Spam-Level: X-Spam-Status: No, score=-1.398 tagged_above=-999 required=5 tests=[AWL=-0.552, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, J_CHICKENPOX_22=0.6, J_CHICKENPOX_64=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 GLoWtyXVf4Il; Mon, 9 Nov 2009 15:31:29 -0800 (PST) Received: from mail.tail-f.com (de-0316.d.ipeer.se [213.180.79.212]) by core3.amsl.com (Postfix) with ESMTP id 87B663A6819; Mon, 9 Nov 2009 15:31:29 -0800 (PST) Received: from localhost (c213-100-167-236.swipnet.se [213.100.167.236]) by mail.tail-f.com (Postfix) with ESMTPSA id 408B5616001; Tue, 10 Nov 2009 00:31:55 +0100 (CET) Date: Tue, 10 Nov 2009 00:31:54 +0100 (CET) Message-Id: <20091110.003154.65949736.mbj@tail-f.com> To: andy@netconfcentral.com From: Martin Bjorklund In-Reply-To: <4AF88164.1000001@netconfcentral.com> References: <4AF88164.1000001@netconfcentral.com> X-Mailer: Mew version 6.2.51 on Emacs 22.2 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Mon, 09 Nov 2009 15:37:12 -0800 Cc: netmod@ietf.org, ipfix@ietf.org Subject: Re: [IPFIX] [netmod] 2 bugs in ietf-ipfix-psamp.yang X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Nov 2009 23:31:30 -0000 Andy Bierman wrote: > Within that list, 'list selector' has a unique-stmt > for a non-config leaf (selectorId), even though that > list is config=true. > > I am not sure this is an error though. No it is ok. > I cc:ed the NETMOD WG because it > is not clear if yang-08, sec 8.* covers this usage. Section 7.8.3. says: If one of the referenced leafs represents configuration data, then all of the referenced leafs MUST represent configuration data. This requirment is clearly fulfilled in this case. Section 8.1 says: o If the constraint is defined on state data, it MUST be true in a reply to the command. This constraint is defined for state data, so it is ok. > I think a config=true node can only define constraints > on other config=true nodes. If this is not the case, > then the YANG draft (sec 8.1) should make that clear. > The data-not-unique error does not apply, > but the YANG text in sec. 13.1 does not make that clear. I will fork this thread here, since I suspect that the discussion on these details might not be of general interest. So I will respond to this on the NETMOD list only. /martin From n.brownlee@auckland.ac.nz Mon Nov 9 15:46:36 2009 Return-Path: X-Original-To: ipfix@core3.amsl.com Delivered-To: ipfix@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BB4783A67B6 for ; Mon, 9 Nov 2009 15:46:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.175 X-Spam-Level: X-Spam-Status: No, score=-5.175 tagged_above=-999 required=5 tests=[AWL=-0.990, BAYES_40=-0.185, 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 lEmv9yJw+8kR for ; Mon, 9 Nov 2009 15:46:36 -0800 (PST) Received: from mailhost.auckland.ac.nz (larry.its.auckland.ac.nz [130.216.12.34]) by core3.amsl.com (Postfix) with ESMTP id EF7703A6828 for ; Mon, 9 Nov 2009 15:46:35 -0800 (PST) Received: from localhost (localhost.localdomain [127.0.0.1]) by mailhost.auckland.ac.nz (Postfix) with ESMTP id 43FBD1AF67 for ; Tue, 10 Nov 2009 12:47:01 +1300 (NZDT) X-Virus-Scanned: by amavisd-new at mailhost.auckland.ac.nz Received: from mailhost.auckland.ac.nz ([127.0.0.1]) by localhost (larry.its.auckland.ac.nz [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id b1zP+hJUM34k for ; Tue, 10 Nov 2009 12:47:01 +1300 (NZDT) Received: from nevil-laptop.sfac.auckland.ac.nz (nevil-laptop.sfac.auckland.ac.nz [130.216.38.130]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailhost.auckland.ac.nz (Postfix) with ESMTP id 2532E1AF62 for ; Tue, 10 Nov 2009 12:46:57 +1300 (NZDT) Message-ID: <4AF8A9F1.8070800@auckland.ac.nz> Date: Tue, 10 Nov 2009 12:46:57 +1300 From: Nevil Brownlee User-Agent: Thunderbird 2.0.0.12 (Macintosh/20080213) MIME-Version: 1.0 To: IPFIX Working Group Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [IPFIX] Slides for presentations, please X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Nov 2009 23:46:36 -0000 Hi all: Those who are presenting at the IPFIX session on Wednesday, please email a copy of their slides to ipfix-chairs@tools.ietf.org so that we can put them on the Meeting Materials page. Thanks, Nevil -- --------------------------------------------------------------------- Nevil Brownlee Computer Science Department | ITS Phone: +64 9 373 7599 x88941 The University of Auckland FAX: +64 9 373 7453 Private Bag 92019, Auckland 1142, New Zealand From bclaise@cisco.com Mon Nov 9 21:26:30 2009 Return-Path: X-Original-To: ipfix@core3.amsl.com Delivered-To: ipfix@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2E6D53A6905 for ; Mon, 9 Nov 2009 21:26:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.486 X-Spam-Level: X-Spam-Status: No, score=-2.486 tagged_above=-999 required=5 tests=[AWL=0.113, 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 kLSKYN12qk3f for ; Mon, 9 Nov 2009 21:26:29 -0800 (PST) Received: from av-tac-bru.cisco.com (weird-brew.cisco.com [144.254.15.118]) by core3.amsl.com (Postfix) with ESMTP id D1EB43A67CF for ; Mon, 9 Nov 2009 21:26:28 -0800 (PST) X-TACSUNS: Virus Scanned Received: from strange-brew.cisco.com (localhost.cisco.com [127.0.0.1]) by av-tac-bru.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id nAA5QsFm026933; Tue, 10 Nov 2009 06:26:54 +0100 (CET) Received: from [10.70.230.178] (tky-vpn-client-230-178.cisco.com [10.70.230.178]) by strange-brew.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id nAA5Qo5t026003; Tue, 10 Nov 2009 06:26:51 +0100 (CET) Message-ID: <4AF8F999.3000207@cisco.com> Date: Tue, 10 Nov 2009 06:26:49 +0100 From: Benoit Claise User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Gerhard Muenz References: <4AF73525.8050009@net.in.tum.de> In-Reply-To: <4AF73525.8050009@net.in.tum.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: ipfix@ietf.org Subject: Re: [IPFIX] Semantic and structured data X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Nov 2009 05:26:30 -0000 Gerhard, Thanks for your email. I have no strong feelings about the two solutions you proposed. From a pure router point of view, I don't see any use cases for logical OR in exporting flow records. However, from a IPFIX Mediator point of view, I see some use cases. I mean that it requires an Intermediate Aggregation Process or Intermediate Correlation Process to express: I've seen this flow record OR that flow record. Now, it's true that even routers will have mediation functions... I'm inclined to add orBasicList, orSubTemplateList, orSubTempalteMultiList to the draft (This is a small addition after all) and to express that, by default, a logical AND is assumed... specifically if the structured data is used in the IPFIX Mediation Protocol. I'm not convinced by the NOT in the context of structured data, as we don't even have a concept of NOT for a single information element! I would like to get some more feedback from others. Regards, Benoit. > Dear all, > > Regarding draft-ietf-ipfix-structured-data, I see the risk that the > semantic of the exported structured data is not clear. > > How do you interpret the manifold occurrence of the same Information > Element (basicList) or the same group of Information Elements > (subTemplateList) in one record? > > What does it mean if basicList, subTemplateList, or subTemplateMultiList > is used for a Flow Key field? Or non-key field? > > Some Examples: > > - BasicList of egress interfaces in a Flow Record > How should a Flow Record be interpreted which contains a list of > egress interfaces and a packet counter? > Has every counted packet been sent on every egress interface? > => multicast case, AND semantic (see example in section 8.1) > Has every counted packet been sent on any one of the egress > interfaces? > => load balancing case, OR semantic > Can it be used as a Flow Key or not? > > - BasicList of destination ports in a Flow Record > As every packet has only one destination port, the only reasonable > interpretation is that the Flow contains packets having one of > the reported port numbers. > => OR semantic > This would be a non-key field. > > > I think there are two solutions: > > 1. We decide that the semantic of list content is out of scope of > draft-ietf-ipfix-structured-data. We add a note to the draft that > the semantic must be clear from the context or the definition of the > Information Elements used within the lists. > > 2. We define semantic lists, such as > - andBasicList, andSubTemplateList, andSubTemplateMultiList > - orBasicList, orSubTemplateList, orSubTempalteMultiList > describing AND and OR semantic of the contained IEs/Templates, > respectively. > > > As I wrote in an earlier mail, I see a good use case for orBasicList. It > could be used in the Selector Report Interpretation of Property Match > Filtering to report a filter like "port 80 or port 443". > http://www.ietf.org/mail-archive/web/ipfix/current/msg04856.html > At the moment, the Selector Report Interpretation is limited to AND. > However, if we also want to express a NOT, we still need another solution... > > Regards, > Gerhard > > _______________________________________________ > IPFIX mailing list > IPFIX@ietf.org > https://www.ietf.org/mailman/listinfo/ipfix > From akoba@nttv6.net Mon Nov 9 22:51:24 2009 Return-Path: X-Original-To: ipfix@core3.amsl.com Delivered-To: ipfix@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6C4C73A6824 for ; Mon, 9 Nov 2009 22:51:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.874 X-Spam-Level: X-Spam-Status: No, score=-1.874 tagged_above=-999 required=5 tests=[AWL=2.414, BAYES_00=-2.599, GB_I_LETTER=-2, HOST_MISMATCH_NET=0.311] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HXhUkQNhHySO for ; Mon, 9 Nov 2009 22:51:20 -0800 (PST) Received: from mail.nttv6.net (mail.nttv6.net [IPv6:2001:fa8::25]) by core3.amsl.com (Postfix) with ESMTP id 5F3E43A68C4 for ; Mon, 9 Nov 2009 22:51:15 -0800 (PST) Received: from [127.0.0.1] (mail.nttv6.net [192.16.178.5]) by mail.nttv6.net (8.14.3/8.14.3) with ESMTP id nAA6pbnO026676; Tue, 10 Nov 2009 15:51:40 +0900 (JST) (envelope-from akoba@nttv6.net) Date: Tue, 10 Nov 2009 15:51:40 +0900 From: Atsushi Kobayashi To: Gerhard Muenz In-Reply-To: <4AEAB7D3.9090608@net.in.tum.de> References: <4AEAB7D3.9090608@net.in.tum.de> Message-Id: <20091110090506.659C.17391CF2@nttv6.net> MIME-Version: 1.0 Content-Type: text/plain; charset="ISO-2022-JP" Content-Transfer-Encoding: 7bit X-Mailer: Becky! ver. 2.46 [ja] X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.3 (mail.nttv6.net [192.16.178.5]); Tue, 10 Nov 2009 15:51:40 +0900 (JST) Cc: IETF IPFIX Working Group Subject: Re: [IPFIX] WG last call on draft-ietf-ipfix-mediators-problem-statement-06 X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Nov 2009 06:51:24 -0000 Hi Gerhard, Thank you for your feedback. I didn't have much time to check in detail your feedbacks. Sorry for late reply. My answers are in-line. On Fri, 30 Oct 2009 10:54:27 +0100 Gerhard Muenz wrote: > > Hi, > > Here is my review of draft-ietf-ipfix-mediators-problem-statement-06. > > The main content is ok. Some parts of the text still need revision. > > I'm not sure if we need to define Mediator types like IPFIX Proxy, IPFIX > Concentrator, IPFIX Distributor, IPFIX Masquerading Proxy in the > terminology section. Why not just talk about IPFIX Mediators? > IMO, I prefer these terms. but, I don't adhere my opinion. I will try to remove the Mediator types. > Regards, > Gerhard > > > > > Abstract > > > > Flow-based measurement is a popular method for various network > > monitoring usages. The sharing of flow-based information for > > monitoring applications having different requirements raises some > > open issues in terms of measurement system scalability, flow-based > > measurement flexibility, and export reliability that IPFIX Mediation > > may help resolve. This document describes the IPFIX Mediation > > applicability examples, along with some problems that network > > administrators have been facing. > > Shouldn't it be the other way round: > - first problems > - then applicability examples > ? > I will change it as follows. Is it OK? This document describes some problems related to flow-based measurement that network administrators have been facing, and then describes IPFIX Mediation applicability examples along with the problems. > > 1. Introduction > > > > One advantage of Flow-based measurement results from easily offering > > the traffic monitoring of a huge amount of traffic. While the usage > > is applied to any networks and to multiple measurement applications, > > network administrators need to optimize the resource of metering > > devices and of multiple measurement applications. IP traffic growth > > and a wide variety of measurement application make the optimization > > further difficult. To achieve system optimization, an intermediate > > device can generally be applied to the system platform. > > Sorry, I can only guess what this paragraph is supposed to say. > Please rewrite in a better understandable and readable way. > > BTW, I would be careful with terms like "optimize" and "optimization". > I will change it as follows. Could you please rewrite it by your word, if not fine. 1. Introduction One advantage of Flow-based measurement results from easily offering the traffic monitoring of a huge amount of traffic. While the usage is applied to any networks and to multiple measurement applications, network administrators need to adjust some parameters of metering devices and of multiple measurement applications to these resources. IP traffic growth and a wide variety of measurement application make the adjustment further difficult. To make a measurement system flexible and scalable, an intermediate device can generally be applied to the system platform. > > > The IPFIX requirements defined in [RFC3917] mention examples of > > intermediate devices, such as IPFIX Proxies or Concentrators, there > > missing conjunction, such as "but", "yet", or something like that > > The term "intermediate" or "intermediate device" does not appear in > RFC3917. So, explain why you call these devices like this. > (For example, because they are located between Exporters and Collectors.) Is it OK? The IPFIX requirements defined in [RFC3917] mention examples of intermediate devices located between Exporters and Collectors, such as IPFIX proxies or concentrators. But, there are no documents defining a generalized concept for such intermediate devices. This > > > are no documents defining a generalized concept for such intermediate > > devices. This document addresses that issue by defining IPFIX > > Mediation, a generalized intermediate device concept for IPFIX, and > > examining in detail the motivations behind its application. > > > > This document is structured as follows: section 2 describes the > > terminology used in this document, section 3 gives an IPFIX/PSAMP > > document overview, section 4 introduces general problems related to > > flow-based measurement, section 5 describes some applicability > > examples where IPFIX Mediations would be beneficial, and, finally, > > section 6 describes some problems an IPFIX Mediation implementation > > might face. > > > > 2. Terminology and Definitions > > > > The IPFIX-specific and PSAMP-specific terminology used in this > > document is defined in [RFC5101] and [RFC5476], respectively. In > > this document, as in [RFC5101] and [RFC5476], the first letter of > > each IPFIX-specific and PSAMP-specific term is capitalized along with > > the IPFIX Mediation-specific term defined here. > > > > In this document, we use the generic term "record stream" to denote a > > I would not call "record stream" a "term" unless it appears in the list > below with capitalized first letter. > > > set of flow- or packet-based data records with their additional > > I would not say that the records are flow-based or packet-based. They > contain flow or packet information. > Actually, I am not sure how to say that. It seems hard to include "record stream" in capitalized terms, because it covers everything, such as IPFIX Flow Record, PSAMP Packet Record, NF flow record, and something else. Could you put your suggestion? Is the following paragraph fine? In this document, we use "record stream" to denote a set of flow- or packet-based information with their additional information that flows from data sources, whether encoded in IPFIX protocol as IPFIX Data Records, or non-IPFIX protocols. In IPFIX protocol, we use the generic term Data Records for IPFIX Flow Records, PSAMP Packet Reports, and Data Records defined by Options Templates, unless an explicit distinction is required. > > information that flows from data sources, whether encoded in IPFIX > > protocol as IPFIX Data Records, or non-IPFIX protocols. In IPFIX > > protocol, we use the generic term Data Records for IPFIX Flow > > Records, PSAMP Packet Reports, and Data Records defined by Options > > Templates, unless an explicit distinction is required. > > Do we need the last sentence? I think Yes. It indicates the usage of term Data Records to prevent readers from confusing it with IPFIX Flow Record and PSAMP packet report. > > > Original Exporter > > > > An Original Exporter is an IPFIX Device that hosts the Observation > > Points where the metered IP packets are observed. > > > > IPFIX Mediation > > > > IPFIX Mediation is the manipulation and conversion of a record > > stream for subsequent export using the IPFIX protocol. > > > > The following terms are used in this document to describe the > > architectural entities used by IPFIX Mediation. > > > > Intermediate Process > > > > An Intermediate Process takes a record stream as its input from > > Collecting Processes, Metering Processes, IPFIX File Readers, > > other Intermediate Processes, or other record sources; performs > > some transformations on this stream, based upon the content of > > each record, states maintained across multiple records, or other > > data sources; and passes the transformed record stream as its > > output to Exporting Processes, IPFIX File Writers, or other > > Intermediate Processes, in order to perform IPFIX Mediation. > > Typically, an Intermediate Process is hosted by an IPFIX Mediator. > > Alternatively, an Intermediate Process may be hosted by an > > Original Exporter. > > > > IPFIX Mediator > > > > An IPFIX Mediator is an IPFIX Device that provides IPFIX Mediation > > by receiving a record stream from some data sources, hosting one > > or more Intermediate Processes to transform that stream, and > > exporting the transformed record stream into IPFIX Messages via an > > Exporting Process. In the common case, an IPFIX Mediator receives > > a record stream from a Collecting Process, but it could also > > receive a record stream from data sources not encoded using IPFIX, > > e.g., in the case of conversion from the NetFlow V9 protocol > > [RFC3954] to IPFIX protocol. > > > > Specific types of IPFIX Mediators are defined below. > > > > IPFIX Proxy > > > > An IPFIX Proxy is an IPFIX Mediator that converts a record stream > > for the purpose of protocol conversion. > > > > IPFIX Concentrator > > > > An IPFIX Concentrator is an IPFIX Mediator that receives a record > > stream from one or more Exporters and performs correlation, > > aggregation, and/or modification. > > > > IPFIX Distributor > > > > An IPFIX Distributor is an IPFIX Mediator that receives a record > > stream from one or more Exporters and exports each record to one > > or more Collectors, deciding to which Collector(s) to export each > > record depending on the decision of an Intermediate Process. > > > > IPFIX Masquerading Proxy > > > > An IPFIX Masquerading Proxy is an IPFIX Mediator that receives a > > record stream from one or more Exporters to screen out parts of > > records according to configured policies in order to protect the > > privacy of the network's end users or to retain sensitive data of > > the exporting organization. > > Do we really need these four terms? > I think that they can be removed. As Brian said, it is difficult to > classify IPFIX Mediators according to these types. > All later occurrences of these terms can be replaced by "IPFIX Mediator". > > In my opinion, I would like to keep these terms to show more concrete examples. But, I don't adhere to my opinion. In problem statement at this level, we can remove the above terms, if no one are against it. > > 4. Problem Statement > > > > Network administrators generally face the problems of measurement > > system scalability, flow-based measurement flexibility, and export > > reliability, even if some techniques, such as Sampling, Filtering, > > Data Records aggregation and export replication, have already been > > developed. The problems consist of optimizing the resources of the > > How can you "optimize the resources"? > I will change it as follows. The problems consist of adjusting some parameters of metering device to the resources of the measurement system while fulfilling appropriate conditions: data accuracy, flow granularity, and export reliability. These conditions depend on two factors. > > measurement system while fulfilling appropriate conditions: data > > accuracy, flow granularity, and export reliability. These conditions > > depend on two factors. > > > > o measurement system capacity: > > This consists of the bandwidth of the management network, the > > storage capacity, and the performances of the collecting devices > > and exporting devices. > > > > o application requirements: > > Different applications, such as traffic engineering, detecting > > traffic anomalies, and accounting, etc., impose different Flow > > remove "etc." > Ok. > > Record granularities, and data accuracies. > > > > The sustained growth of IP traffic has been overwhelming the > > measurement system capacities. Furthermore, a large variety of > > applications (e.g., QoS measurement, traffic engineering, security > > monitoring) and the deployment of measurement system in heterogeneous > > environments have been increasing the demand and complexity of IP > > traffic measurements. > > > > 4.1. Coping with IP Traffic Growth > > > > Enterprise or service provider networks already have multiple 10 Gb/s > > links, their total traffic exceeding 100 Gb/s. In the near future, > > broadband users' traffic will increase by approximately 40% every > > year according to [TRAFGRW]. When operators monitor traffic of 500 > > Gb/s with a packet sampling rate of 1/1000, the amount of exported > > Flow Records from Exporters could exceed 50 kFlows/s. This value is > > beyond the ability of a single Collector. > > This paragraph describes the situation today. Are we sure that these > numbers are still valid next year? Maybe we are then able to process > 50kFlows/s. > I would remove all these figures. > This figure shows the situation at current level. In my opinion, these figures don't block the later work. I will change this subsection as follows. 4.1. Coping with IP Traffic Growth Enterprise or service provider networks already have multiple 10 Gb/s links, their total traffic exceeding 100 Gb/s. In the near future, broadband users' traffic will increase by approximately 40% every year according to [TRAFGRW]. When administrators monitor IP traffic sustaining its growth with existing packet sampling rate at multiple Exporters, the amount of exported Flow Records from Exporters could exceed the ability of single Collector. To deal with this problem, current data reduction techniques (packet Sampling and Filtering in [RFC5475], and aggregation of measurement data) have been generally implemented on Exporters. Note that packet Sampling leads to potential loss of small Flows. With both packet Sampling and aggregation techniques, administrators might no longer be able to detect and investigate subtle traffic changes and anomalies as this requires detailed Flow information. With Filtering, only a subset of the Data Records are exported. Considering the potential drawbacks of packet Sampling, Filtering, and Data Records aggregation, there is a need for a large-scale collecting infrastructure that does not rely on data reduction techniques. > > To deal with this problem, current data reduction techniques > > (Sampling and Filtering in [RFC5475], and aggregation of measurement > > "packet Sampling and Filtering"? Ok. > > > data) have been generally implemented on Exporters. Note that > > Sampling technique leads to potential loss of small Flows. With both > > "packet Sampling leads to..." > Ok. > > Sampling and aggregation techniques, administrators might no longer > > be able to detect and investigate subtle traffic changes and > > anomalies as this requires detailed Flow information. With > > Filtering, only a subset of the Data Records are exported. > > > > Considering the potential drawbacks of Sampling, Filtering, and Data > > Records aggregation, there is a need for a large-scale collecting > > infrastructure that does not rely on data reduction techniques. > > Hm, I do not see this problem if a Collector receives data from a single > Exporter. You should say that these problems arise if multiple Exporters > send data to a single Collector. Please see the above subsection. > > > 4.2. Coping with Multipurpose Traffic Measurement > > > > Different monitoring applications impose different requirements on > > the monitoring infrastructure. Some of them require traffic > > monitoring at a Flow level while others need information about > > individual packets or just Flow aggregates. > > > > To fulfill these divers requirements, an Exporter would need to > > perform various complex metering tasks in parallel, which is a > > problem due to limited resources. Hence, it can be advantageous to > > run the Exporter with a much simpler setup and to perform appropriate > > post-processing of the exported Data Records at a later stage. > > > > 4.3. Coping with Heterogeneous Environments > > > > Network administrators use IPFIX Devices and PSAMP Devices from > > various vendors, various software versions, various device types > > (router, switch, or probe) in a single network domain. Even legacy > > flow export protocols are still deployed in current network. This > > heterogeneous environment leads to differences in Metering Process > > capabilities, Exporting Process capacity (export rate, cache memory, > > etc.), and data format. For example, probes and switches cannot > > retrieve some derived packet properties in [RFC5102] from a routing > > table. > > remove "in [RFC5102]" > Ok. > > To deal with this problem, the measurement system needs to mediate > > the differences. However, equipping all collecting devices with this > > absorption function is difficult. > > > > 4.4. Summary > > > > In optimizing the resources of a measurement system, it is important > > I still do not understand what "optimize the resources" is supposed to mean. > I will change it as follows. 4.4. Summary In adjusting some parameters to the resources of a measurement system, it is important to use traffic data reduction techniques as early as possible, e.g., at the Exporter. However, this implementation is made difficult by heterogeneous environment of exporting devices to meet the requirements of different monitoring applications. > > to use traffic data reduction techniques as early as possible, e.g., > > at the Exporter. However, this implementation is made difficult by > > heterogeneous environment of exporting devices. > > Please revise the entire paragraph above. It only talks about data > reduction. I do not think that this is the core of mediation. > No. It imply the distribution of traffic data in heterogeneous enviroment. Please suggest your idea. > > This implies that a new Mediation function is required in typical > > Exporter-Collector architectures. Based on some applicability > > examples, the next section shows the limitation of the typical > > Exporter-Collector architecture model and the IPFIX Mediation > > benefits. > > > > 5. Mediation Applicability Examples > > > > 5.1. Adjusting Flow Granularity > > > > A set of common properties of simplest Flow type is a fixed 5-tuple > > of protocol, source and destination IP addresses, and source and > > As you talk about "Flow Keys", you should use this term and not invent a > new one! Actually, when I started to write this subsection, it implied covering IPFIX and NetFlow. I will change subsection as follows. 5.1. Adjusting Flow Granularity A simplest set Flow Keys is a fixed 5-tuple of protocol, source and destination IP addresses, and source and destination port numbers. A shorter set of Flow Keys, such as a triple, a double, or a single property, (for example network prefix, peering autonomous system number, or BGP Next-Hop fields), creates more aggregated Flow Records. This is especially useful for measuring router-level traffic matrices in a core network domain and for easily adjusting the performance of Exporters and Collectors. Implementation analysis: Implementations for this case depend on where Flow granularity is adjusted. More suitable implementations use configurable Metering Processes in Original Exporters. The cache in the Metering Process can specify its own set of Flow Keys and extra fields. The Original Exporter thus generates Flow Records of the desired Flow granularity. In the case where a Metering Process hosting no ability to change the Flow Keys in Original Exporter creates Flow Records, or PSAMP Packet Reports, an IPFIX Mediator can aggregate Data Records based on a new set of Flow Keys. Even in the case where the Metering Process hosting this ability, an IPFIX Mediator can further aggregate the Flow Records. > > > destination port numbers. A shorter set of common properties, such > > as a triple, a double, or a single property, (for example network > > prefix, peering autonomous system number, or BGP Next-Hop fields), > > creates more aggregated Flow Records. This is especially useful for > > measuring traffic exchange in an entire network domain and for easily > > What do you mean by "traffic exchange in an entire network domain"? > It is router-level traffic matrices indicates traffic volumes transmitted between every pair of end routers in core network. Please see above subsection. > > adjusting the performance of Exporters and Collectors. > > > > Implementation analysis: > > > > Implementations for this case depend on where Flow granularity is > > adjusted. More suitable implementations use configurable Metering > > Processes in Original Exporters. The cache in the Metering > > Process can specify its own set of common properties (Flow Keys) > > and extra fields. The Original Exporter thus creates directly > > aggregated Flow Records. > > IMO, "aggregated Flow Record" is non-sense. If you look at the > definition of "Flow", you see that this is a normal Flow Record. Yes. I understood it. But, aggregated Flow Records is more intuitive. > I would say that the Original Exporter generates Flow Records of the > desired Flow granularity. > > > In the case where the Original Exporter contains a Metering > > Process that creates fixed tuple Flow Records (no ability to > > Replace "fixed tuple Flow Records" by correct IPFIX language. > Please see above subsection. > > change the Flow Keys), or PSAMP Packet Reports, an IPFIX > > Concentrator can aggregate Data Records based on a new set of Flow > > Keys. Even in the case where the Original Exporter contains a > > Metering Process for which the Flow Keys can be configured, an > > IPFIX Concentrator can further aggregate the Flow Records. > > > > 5.2. Hierarchical Collecting Infrastructure > > > > The increase of IPFIX Exporters, the increase of the traffic, and the > > variety of treatments expected to be performed over the Data Records > > over => on > Ok. > > is more and more difficult to handle within a single Collector. > > Hence to increase the collecting (e.g., the bandwidth capacity) and > > processing capacity, distributed Collectors must be deployed. As a > > possible approach, a hierarchical structure is useful for increasing > > I don't understand how the collecting and processing capacity increases > thanks to a hierarchical structure. > > The capacity increases because I implement more resources in the > network, e.g. more Collectors. Although increasing number of Collectors operated independently makes it more capacity, we cannot measure the all of amount of traffic data. > > > the measurement systems capacity, both in export bandwidth capacity > > and in collecting capacity. > > > > Implementation analysis: > > > > To cope with the increase of IPFIX Exporters and traffic, one > > "number of IPFIX Exporters" (only IPFIX?) Ok. > > > possible implementation uses IPFIX Concentrators to build a > > hierarchical collection system. To cope with the variety of > > treatments, one possible implementation uses IPFIX Distributors to > > build a distributed collection system. More specific cases are > > described in section 5.9. > > > > 5.3. Correlation for Data Records > > > > The correlation amongst Data Records or between Data Record and meta > > data provides new metrics or information, including the following. > > > > o One-to-one correlation between Data Records > > > > * One way delay from the correlation of PSAMP Packet Reports from > > different Exporters along a specific path, packet inter-arrival > > time, etc. > > "packet inter-arrival times from the correlation of PSAMP Packet Reports > generated by a single Exporter, etc." > Ok. I will change it as follows. o One-to-one correlation between Data Records * One way delay from the correlation of PSAMP Packet Reports from different Exporters along a specific path. * Packet inter-arrival time from the correlation of sequential PSAMP Packet Reports from a Exporter. > > * Treatment from the correlation of Data Records with the common > > remove "the" in front of "common" > Ok. > > properties, observed at incoming/outgoing interfaces. Examples > > are the rate-limiting ratio, the compression ratio, the > > optimization ratio, etc. > > > > o Correlation amongst Data Records > > > > Average/maximum/minimum values from correlating multiple Data > > Records. Examples are the average/maximum/minimum number of > > packets of the measured Flows, the average/maximum/minimum one way > > delay, the average/maximum/minimum number of lost packets, etc. > > > > o Correlation between Data Record and other meta data > > > > Examples are some BGP attributes associated with Data Record by > > looking up the routing table. > > > > Implementation analysis: > > > > One possible implementation for this case uses an IPFIX > > Concentrator located between the Metering Processes and Exporting > > IPFIX Concentrator => Intermediate Process > Yes. > > Processes on the Original Exporter, or alternatively a separate > > IPFIX Concentrator located between the Original Exporters and > > IPFIX Collectors. > > > > 5.4. Time Composition > > > > Time composition is defined as the aggregation of consecutive Data > > Records with common properties. It leads to the same output as > > applies to Flow Records only? No, I use "Data Record". Data Records with identical Flow Keys implies it applies Flow Record only. It applies Packet Reports with common properties as well. I will keep it. > common properties => Flow Keys? > > > setting a longer active interval timer on Original Exporters with one > > active timeouts? Yes. > > > advantage: the creation of new metrics such as average, maximum and > > minimum values from Flow Records with a shorter time interval enables > > administrators to keep track of changes that might have happened > > during the time interval. > > Hm, changes can be much better detected by looking at the short-lived > values directly instead of looking at the long-term average, maximum, or > minimum. > No. The advantage is that changes can be detected without increasing the number of output Flow Records. > > > > Implementation analysis: > > > > One possible implementation for this case uses an IPFIX > > Concentrator located between the Metering Processes and Exporting > > Intermediate Process Yes. > > Processes on the Original Exporter, or alternatively a separate > > IPFIX Concentrator located between the Original Exporters and > > IPFIX Collectors. > > I will change as follows. > > 5.5. Spatial Composition > > > > Spatial composition is defined as the aggregation of Data Records in > > a set of Observation Points within an Observation Domain, across > > multiple Observation Domains from a single Exporter, or even across > > multiple Exporters. The spatial composition is divided into four > > types. > > > > o Case 1: Spatial Composition within one Observation Domain > > > > For example, in the case where a link aggregation exists, Data > > remove "a" > Ok. > > Records metered at physical interfaces belonging to the same trunk > > can be merged. > > > > o Case 2: Spatial Composition across Observation Domains, but within > > a single Exporter > > Original Exporter? Yes. > > > For example, in the case where a link aggregation exists, Data > > remove "a" > Ok. > > Records metered at physical interfaces belonging to a same trunk > > grouping beyond the line interface module can be merged. > > "line card"? > Ok. > > > > o Case 3: Spatial Composition across Exporters > > > > Data Records metered within an administrative domain, such as the > > west area and east area of an ISP network, can be merged. > > > > o Case 4: Spatial Composition across administrative domains > > > > Data Records metered across administrative domains, such as across > > different customer networks or different ISP networks, can be > > merged. > > Are more cases thinkable? Maybe yes. > If yes, I would call the above "cases" "examples". > Ok. > > Implementation analysis: > > > > One possible implementation for the cases 1 and 2 uses an IPFIX > > Concentrator located between the Metering Processes and Exporting > > Intermediate Process > Yes. > > Processes on the Original Exporter. A separate IPFIX Concentrator > > located between the Original Exporters and IPFIX Collector is a > > valid solution for the cases 1, 2, 3, and 4. > > > > > > 5.6. Data Record Anonymization > > > > IPFIX exports across administrative domains can be used to measure > > traffic for wide-area traffic engineering or to analyze Internet > > traffic trends, as described in the spatial composition across > > administrative domains in the previous subsection. > > In such a case, administrators need to adhere to privacy protection > > policies and prevent access to confidential traffic measurements by > > other people. Typically, anonymization techniques enables the > > enable > Yes. > > provision of traffic data to other people without violating these > > policies. > > > > Generally, anonymization modifies a data set to protect the identity > > of the people or entities described by the data set from being > > disclosed. It also attempts to preserve sets of network traffic > > properties useful for a given analysis while ensuring the data cannot > > be traced back to the specific networks, hosts, or users generating > > the traffic. For example, IP address anonymization is particularly > > important for avoiding the identification of the users, hosts, and > > remove second "the" > Yes. > > routers. As another example, when ISP provides a traffic monitoring > > an ISP > Yes. > > service to end customers by their own Exporters, even in case of > > exporting interface index fields, network administrators take care of > > anonymizing its fields to avoid disclosing the vulnerability. > > Why does an interface represent a vulnerability? > Interface indexes assignment policies in several vendors are different. Some vender indexes show upper bytes indicating line card, lower byte indicating interfaces. By recognizing its policy, we can presume the vendors of Exporter. > > Implementation analysis: > > > > One possible implementation for this case uses an anonymization > > function at the Original Exporter. However, this increases the > > load on the Original Exporter. A more flexible implementation > > uses a separate IPFIX Masquerading Proxy between the Original > > Exporter and Collector. > > > > > > 5.10. Flow-based Sampling and Selection > > > > Generally, the distribution of the number of packets per Flow seems > > to be heavy-tailed. Most types of Flow Records are likely to be > > small Flows consisting of a small number of packets. The measurement > > system is overwhelmed with a huge amount of these small Flows. If > > statistics information of small Flows is exported as merged data by > > applying a policy or threshold, the load on the Exporter is reduced. > > Furthermore, if the flow distribution is known, exporting only a > > subset of the Data Records might be sufficient. > > > > Implementation analysis: > > > > One possible implementation for this case uses an IPFIX > > Concentrator located between the Metering Processes and Exporting > > Intermediate Process Ok. > > > Processes on the Original Exporter, or alternatively a separate > > IPFIX Concentrator located between the Original Exporters and > > IPFIX Collectors. A set of IPFIX Mediation functions, such as > > filtering, selecting and aggregation is used in the IPFIX > > Concentrator. > > > > 6. IPFIX Mediators Implementation Specific Problems > > > > 6.1. Loss of Original Exporter Information > > > > Both the Exporter IP address indicated by the source IP address of > > the IPFIX Transport Session and the Observation Domain ID included in > > the IPFIX Message header are likely to be lost during IPFIX > > Mediation. In some cases, a IPFIX Masquerading Proxy might drop the > > a => an > Ok. > > information deliberately. In general, however, the Collector must > > recognize the origin of the measurement information, such as the IP > > address of the Original Exporter, the Observation Domain ID, or even > > the Observation Point ID. Note that, if an IPFIX Mediator can not > > cannot > Ok. > > communicate the Original Exporter IP address, then the IPFIX > > Collector will wrongly deduce that the IP address of the IPFIX > > Mediator is that of the Original Exporter. > > > > In the following figure, a Collector can identify two IP addresses: > > 10.1.1.3 (IPFIX Mediator) and 10.1.1.2 (Exporter#2), respectively. > > The Collector, however, needs to somehow recognize both Exporter#1 > > and Exporter#2, which are the Original Exporters. The IPFIX Mediator > > must be able to notify the Collector about the IP address of the > > Original Exporter. > > > > .----------. .--------. > > |IPFIX | |IPFIX | > > |Exporter#1|--------->|Mediator|---+ > > | | | | | > > '----------' '--------' | .---------. > > IP:10.1.1.1 IP:10.1.1.3 '----->|IPFIX | > > ODID:10 ODID:0 |Collector| > > +----->| | > > .----------. | '---------' > > |IPFIX | | > > |Exporter#2|-----------------------' > > | | > > '----------' > > IP:10.1.1.2 > > ODID:20 > > > > Figure B: Loss of Original Exporter Information. > > > > 6.2. Loss of Base Time Information > > > > The Export Time field included in the IPFIX Message header represents > > a reference timestamp for Data Records. Some IPFIX Information > > Elements, described in [RFC5102], carry delta timestamps that > > indicate the time difference from the value of the Export Time field. > > If the Data Records include any delta time fields and the IPFIX > > Mediator overwrites the Export Time field when sending IPFIX > > Messages, the delta time fields become meaningless and, because > > Collectors cannot recognize this situation, wrong time values are > > propagated. > > > > 6.3. Transport Sessions Management > > > > Maintaining relationships between the incoming Transport Sessions and > > the outgoing ones depends on the Mediator's implementation. If an > > IPFIX Mediator relays multiple incoming Transport Sessions to a > > single outgoing Transport Session, and if the IPFIX Mediators shuts > > down its outgoing Transport Session, Data Records of the incoming > > Transport Sessions would not be relayed any more. In the case of > > resetting an incoming session, the behavior of the IPFIX Mediator > > Transport Session > Ok. > > needs to be specified. > > > > 6.7. Exporting the Function Item > > > > In some case, the IPFIX Collector needs to recognize which specific > > function(s) the IPFIX Mediation has executed on the Data Records. > > remove first "the" Ok. > > > The IPFIX Collector cannot distinguish between time composition, > > spatial composition, and Flow Key aggregation, if the IPFIX Mediator > > What is "Flow Key aggregation"? Is this a good expression? > Usually, some Flow Key fields are just dropped or replaced by non-key > fields. > I will remove "Flow Key aggregation". > > does not export the applied function. Some parameters related to the > > function also would need to be exported. For example, in case of > > time composition, the active time of original Flow Records is > > "active timeout"? > Yes. > > required to interpret the minimum/maximum counter correctly. In case > > of spatial composition, spatial area information on which Data > > Records is aggregated is required. > > > > 6.8. Consideration for Aggregation > > > > Whether the aggregation is based on time or spatial composition, > > caution should be taken on how to aggregate non-key fields in IPFIX > > Mediation. The IPFIX information model [RFC5102] specifies that the > > value of non-key fields, which are derived from fields of packets or > > from packet treatment and for which the value may change from packet > > to packet within a single Flow, is determined by the first packet > > observed for the corresponding Flow, unless the description of the > > Information Element explicitly specifies a different semantics. > > > > However, this simple rule might not be appropriate when aggregating > > Flow Records which have different values in a non-key field. For > > example, if two Flows with identical Flow Key values are measured at > > different Observation Points, they may contain identical packets > > observed at different locations in the network and at different > > points in time. On their way from the first to the second > > Observation Point, some of the packet fields, such as the DSCP, may > > have changed. Hence, if the Information Element ipDiffServCodePoint > > is included as a non-key field, it can be useful to include the DSCP > > value observed at either the first or the second Observation Point in > > the resulting Flow Record, depending on the application. > > > > Other potential solutions include: removing the Information Element > > ipDiffServCodePoint from the Data Record when re-exporting the > > aggregate Flow Record, changing the Information Element > > ipDiffServCodePoint from a non key-field to a Flow Key when re- > > exporting the aggregated Flow Record, or assigning a non valid value > > for the Information Element to express to the Collector that this > > Information Element is meaningless. > > > > Furthermore, rules must be specify on how to aggregate the new > > Configured Selection Fraction an IPFIX Mediator should report when > > What about: > "If packet Sampling or Filtering is applied, the IPFIX Mediator must > report an adjusted PSAMP Configured Selection Fraction when aggregating..." > Ok. > > aggregating IPFIX Flow Records with different sampling rates. > > Finally, special care must be taken when aggregating Flow Records > > resulting from different Sampling techniques such as Systematic > > Count-Based Sampling and Random n-out-of-N Sampling for example. > > > > > > 7. Summary and Conclusion > > > > This document described the problems that network administrators have > > been facing, the applicability of IPFIX Mediation to these problems, > > and the problems related to the implementation of IPFIX Mediators. > > To assist the operations of the Exporters and Collectors, there are > > various IPFIX Mediations from which the administrators may select. > > Examples of the applicability of IPFIX Mediation are as follows. > > > > o Regarding large-scale measurement system, IPFIX Concentrators or > > IPFIX Distributors help to achieve traffic analysis with high data > > accuracy and fine flow granularity even as IP traffic grows. As > > IPFIX Mediation capabilities, Flow sampling, aggregation, and > > composition are effective. > > Sampling and aggregation reduce the accuracy or granularity. > Correlation seems to be appropriate. > I means as follows. o Regarding large-scale measurement system, IPFIX Mediator with IPFIX File Writer helps to achieve traffic analysis with high data accuracy and fine flow granularity even as IP traffic grows. As IPFIX Mediation capabilities, Flow sampling, aggregation, and composition are effective. > > o Regarding data retention, IPFIX Mediators enhance the export > > reliability, and the storage of the measurement system. > > > > o Regarding the distribution of Data Records, IPFIX Distributors > > help to achieve multipurpose traffic analysis for different > > organizations, or help to achieve respective traffic analysis > > remove "respective"? > Ok. > > based on Data Record types(IPv4, IPv6, MPLS, and VPN). > > > > o Regarding the IPFIX export across domains, IPFIX Masquerading > > Proxies help administrators to anonymize or filter Data Records, > > preventing privacy violations. > > > > o Regarding interoperability, IPFIX Proxies provide interoperability > > between legacy protocols and IPFIX, even during the migration > > even => for example Ok. > > period to IPFIX. > > > > As a result, the IPFIX Mediation benefits become apparent. However, > > there are still some open issues with the use of IPFIX Mediators. > > > > o Both Observation Point and IPFIX Message header information, such > > as the Exporter IP address, Observation Domain ID, and Export Time > > field, might be lost. This data should therefore be communicated > > between the Original Exporter and Collector via the IPFIX > > Mediator. > > > > o IPFIX Mediators are required to manage Transport Sessions, > > Template IDs, and Observation Domain IDs. Otherwise, anomalous > > IPFIX Messages could be created. > > > > o Data Records defined by Options Templates, such as those reporting > > the Sampling rate and Sampling algorithm used, might be lost > > during IPFIX Mediation. If a Collector is not informed of current > > Sampling rates, traffic information might become worthless. > > > > These problems stem from the fact that no standards regarding IPFIX > > Mediation have been set. In particular, the minimum set of > > information that should be communicated between Original Exporters > > and Collectors, the management between different IPFIX Transport > > Sessions, and the internal components of IPFIX Mediators should be > > standardized. > > > There is a lot of repetition in this section. > You means this section should be removed. > > 8. Security Considerations > > > > A flow-based measurement system must prevent potential security > > threats: the disclosure of confidential traffic data, injection of > > incorrect data, and unauthorized access to traffic data. These > > security threats of the IPFIX protocol are covered by the security > > considerations section in [RFC5101] and are still valid for IPFIX > > Mediators. > > > > And a measurement system must also prevent the following security > > remove "And" > Ok. > > threats related to IPFIX Mediation: > > > > o Attacks against IPFIX Mediator > > > > IPFIX Mediators can be considered as a prime target for attacks, > > as an alternative to IPFIX Exporters and Collectors. IPFIX > > Proxies or Masquerading Proxies need to prevent unauthorized > > access or denial-of-service (DoS) attacks from untrusted public > > networks. > > > > o Man-in-the-middle attack by untrusted IPFIX Mediator > > > > The Exporter-Mediator-Collector structure model would increase the > > risk of the man-in-the-middle attack. > > "would increase the risk of..." => "could be misused for > man-in-the-middle attacks" > Good. > > o Configuration on IPFIX Mediation > > > > In the case of IPFIX Distributors and IPFIX Masquerading Proxies, > > an accidental misconfiguration and unauthorized access to > > configuration data could lead to the crucial problem of disclosure > > of confidential traffic data. > > -- > Dipl.-Ing. Gerhard M$B".(Bz > Chair for Network Architectures and Services (I8) > Technische Universit$BgU(B M$B".(Bchen - Department of Informatics > Boltzmannstr. 3, 85748 Garching bei M$B".(Bchen, Germany > Phone: +49 89 289-18008 Fax: +49 89 289-18033 > E-mail: muenz@net.in.tum.de WWW: http://www.net.in.tum.de/~muenz > > -- Atsushi Kobayashi From muenz@net.in.tum.de Tue Nov 10 01:16:24 2009 Return-Path: X-Original-To: ipfix@core3.amsl.com Delivered-To: ipfix@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 857973A687E; Tue, 10 Nov 2009 01:16:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.543 X-Spam-Level: X-Spam-Status: No, score=-1.543 tagged_above=-999 required=5 tests=[AWL=-0.494, BAYES_00=-2.599, HELO_EQ_DE=0.35, J_CHICKENPOX_22=0.6, J_CHICKENPOX_64=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 CKJrxhJGPvAx; Tue, 10 Nov 2009 01:16:23 -0800 (PST) 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 B71C93A6844; Tue, 10 Nov 2009 01:16:23 -0800 (PST) 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 461F9485A0; Tue, 10 Nov 2009 10:16:46 +0100 (CET) Received: from [131.159.20.108] (repulse.net.in.tum.de [131.159.20.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by phoenix.net.informatik.tu-muenchen.de (Postfix) with ESMTP id 311ECB41; Tue, 10 Nov 2009 10:16:46 +0100 (CET) Message-ID: <4AF92FC4.1050708@net.in.tum.de> Date: Tue, 10 Nov 2009 10:17:56 +0100 From: Gerhard Muenz User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Andy Bierman References: <4AF88164.1000001@netconfcentral.com> In-Reply-To: <4AF88164.1000001@netconfcentral.com> Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms050308060601080400010503" X-Virus-Scanned: ClamAV using ClamSMTP Cc: NETMOD Working Group , IPFIX Working Group Subject: Re: [IPFIX] 2 bugs in ietf-ipfix-psamp.yang X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Nov 2009 09:16:24 -0000 This is a cryptographically signed message in MIME format. --------------ms050308060601080400010503 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Hi Andy, Andy Bierman wrote: > Hi, > > I use your data model to test my YANG compiler. > It is complaining about the latest version. > > In 'list selectionProcess', the must-stmt has an > extra right parenthesis at the end. Thanks. There should be a left parenthesis before "count" in the same must statement. Regards, Gerhard > Within that list, 'list selector' has a unique-stmt > for a non-config leaf (selectorId), even though that > list is config=true. > > I am not sure this is an error though. > I cc:ed the NETMOD WG because it > is not clear if yang-08, sec 8.* covers this usage. > > I think a config=true node can only define constraints > on other config=true nodes. If this is not the case, > then the YANG draft (sec 8.1) should make that clear. > The data-not-unique error does not apply, > but the YANG text in sec. 13.1 does not make that clear. > > > thanks, > Andy > --------------ms050308060601080400010503 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 SIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMDkxMTEwMDkxNzU2WjAjBgkqhkiG9w0BCQQxFgQU u9BPKOZE5ZUhqj97Vi/nxR43FK0wXwYJKoZIhvcNAQkPMVIwUDALBglghkgBZQMEAQIwCgYI KoZIhvcNAwcwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqG SIb3DQMCAgEoMIGFBgkrBgEEAYI3EAQxeDB2MGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxU aGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwg RnJlZW1haWwgSXNzdWluZyBDQQIQKsXq3Tdl1UZFGbLpOSCnTzCBhwYLKoZIhvcNAQkQAgsx eKB2MGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBM dGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQQIQKsXq 3Tdl1UZFGbLpOSCnTzANBgkqhkiG9w0BAQEFAASCAQCIMZL5/OwRaKiBq3+2lezOwFXWCN62 sqA+DkUIAxMyah4YSdmhfy3AhCUHKQ/Kd80hOOVqisfP0SJOsG3DQ9dD5veeR30fx7seHpk0 5crRPXSCStP8YADnZIpQ8yjyoqRrTI2uJ6ElxFbV4cvaWeBv2iNdI7EhtUJxO1tzvMpcJHbC 2Bi/rK3tpSmE1nJeFHQ4rmVgUikgCkXw+HrJUMvBtZZxjAYb/XvMPEbNGMScFZZgZNpanTqW P6mfWrCcS3dlZiqZ8kUiDjUN/W+9TbnmX5QQBmCtarL6bmGIYQx1EIrRUn7SZzzC9I8k5nOh EDh+yaJnotU/PUuQwAcnrY0HAAAAAAAA --------------ms050308060601080400010503-- From akoba@nttv6.net Tue Nov 10 03:24: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 A1E533A681D for ; Tue, 10 Nov 2009 03:24:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.199 X-Spam-Level: X-Spam-Status: No, score=0.199 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001, SUBJ_RE_NUM=2.799] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xp5aOyANeYnD for ; Tue, 10 Nov 2009 03:24:18 -0800 (PST) Received: from mail.nttv6.net (mail.nttv6.net [IPv6:2001:fa8::25]) by core3.amsl.com (Postfix) with ESMTP id 5E8033A695A for ; Tue, 10 Nov 2009 03:24:16 -0800 (PST) Received: from [10.10.10.20] ([IPv6:2001:fa8:1000:0:2937:72ff:5f41:d58f]) by mail.nttv6.net (8.14.3/8.14.3) with ESMTP id nAABOcI9028643; Tue, 10 Nov 2009 20:24:39 +0900 (JST) (envelope-from akoba@nttv6.net) Date: Tue, 10 Nov 2009 20:14:16 +0900 From: Atsushi Kobayashi To: sujay gupta In-Reply-To: References: Message-Id: <20091110192704.13D7.17391CF2@nttv6.net> MIME-Version: 1.0 Content-Type: text/plain; charset="ISO-2022-JP" Content-Transfer-Encoding: 7bit X-Mailer: Becky! ver. 2.50.05 [ja] (Unregistered) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.3 (mail.nttv6.net [IPv6:2001:fa8::25]); Tue, 10 Nov 2009 20:24:39 +0900 (JST) Cc: IETF IPFIX Working Group , Juergen Quittek Subject: Re: [IPFIX] WG last call on draft-ietf-ipfix-mediators-problem-statement-06 X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Nov 2009 11:24:19 -0000 Hi Sujay, Thank you for your feedback. Please see in-line. On Tue, 3 Nov 2009 23:44:55 +0530 sujay gupta wrote: > Hi, > > I am overall fine with the doc. > > small changes however would help such as; > section 4.1, last para mentions the need of system not relying on > data reduction techniques, section 4.4 contradicts it. > I will change section 4.4 last para. Is it OK? 4.4. Summary In adjusting some parameters to the resources of a measurement system, it is important to use traffic data reduction techniques as early as possible, e.g., at the Exporter. However, this implementation is made difficult by heterogeneous environment of exporting devices. On the other hand, keeping data accuracy and flow granularity to meet the requirements of different monitoring applications requires a scalable and flexible collecting infrastructure. > section 1, first para, between first and second line could mention > that "traffic monitoring is taxing on the resources" and hence the need > for optimization( ie the 2nd line). > last line in the para says "platform", is it required? > I will change as follows. Is it OK? 1. Introduction One advantage of Flow-based measurement results from easily offering the traffic monitoring of a huge amount of traffic. While the usage is applied to any networks and to multiple measurement applications taxing on the resources of the measurement system, network administrators need to adjust some parameters of metering devices and of multiple measurement applications to these resources. IP traffic growth and a wide variety of measurement application make the adjustment further difficult. To make a measurement system flexible and scalable, an intermediate device can generally be applied to the system. > perhaps having a figure showing the position of ipfix-med amongst > other layers( section 2) > would be a nice addition. Does your suggestion imply the Figure B in framework draft? http://tools.ietf.org/html/draft-ietf-ipfix-mediators-framework-04 Regards, Atsushi > > BR, > -Sujay > > > On Mon, Nov 2, 2009 at 3:52 PM, Juergen Quittek wrote: > > Hi Sujay, > > > > Thank you for the review. > > > > On 31.10.09 08:27 ?"sujay gupta" wrote: > > > >> Hi, > >> A few comments. > >> 1) I have a slight problem overall with the language structuring > >> especially from section 1 to 4. It could be made simple. > > > > Would you have concrete suggestions? This would be helpful. > > > > Thanks, > > > > ? ?Juergen > > > > > >> 2) IPFIX mediation as a service or device? is intermixed, can we > >> differentiate that? also can we call the different type of mediators > >> as services? > >> 3) Is there any line of thought of having the mediation device > >> incorporate record compression to reduce b/w?( > >> draft-muenz-ipfix-compression) as another service, or deal with > >> compressed data from the original exporter? > >> BR, > >> -Sujay > >> > >> > >> On Mon, Oct 19, 2009 at 10:32 AM, Juergen Quittek > >> wrote: > >>> Dear all, > >>> > >>> At our session in Stockholm we agreed to start the 2nd working group > >>> last call on the mediation problem state as soon as a new version > >>> of it would be available. The new version is > >>> > >>> http://www.ietf.org/internet-drafts/draft-ietf-ipfix-mediators-problem-state > >>> ment-06.txt > >>> > >>> The call starts today and will last until Friday October 30. > >>> > >>> Please read the draft! > >>> Please send your comments to this mailing list! > >>> Please also send a message if you are fine with the draft as it is! > >>> > >>> Thank you, > >>> > >>> ? ?Juergen > >>> > >>> _______________________________________________ > >>> IPFIX mailing list > >>> IPFIX@ietf.org > >>> https://www.ietf.org/mailman/listinfo/ipfix > >>> > >>> > > > _______________________________________________ > IPFIX mailing list > IPFIX@ietf.org > https://www.ietf.org/mailman/listinfo/ipfix --- Atsushi KOBAYASHI NTT Information Sharing Platform Lab. tel:+81-(0)422-59-3978 fax:+81-(0)422-59-5637 From akoba@nttv6.net Tue Nov 10 03:57:05 2009 Return-Path: X-Original-To: ipfix@core3.amsl.com Delivered-To: ipfix@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 608453A696D for ; Tue, 10 Nov 2009 03:57:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.201 X-Spam-Level: X-Spam-Status: No, score=-1.201 tagged_above=-999 required=5 tests=[AWL=1.399, BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0+jBQpiD--s2 for ; Tue, 10 Nov 2009 03:57:04 -0800 (PST) Received: from mail.nttv6.net (mail.nttv6.net [IPv6:2001:fa8::25]) by core3.amsl.com (Postfix) with ESMTP id DC8F83A687F for ; Tue, 10 Nov 2009 03:57:03 -0800 (PST) Received: from [10.10.10.20] ([IPv6:2001:fa8:1000:0:2937:72ff:5f41:d58f]) by mail.nttv6.net (8.14.3/8.14.3) with ESMTP id nAABvRPn028832; Tue, 10 Nov 2009 20:57:27 +0900 (JST) (envelope-from akoba@nttv6.net) Date: Tue, 10 Nov 2009 20:47:04 +0900 From: Atsushi Kobayashi To: "Juergen Quittek" In-Reply-To: References: Message-Id: <20091110203738.13DA.17391CF2@nttv6.net> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Becky! ver. 2.50.05 [ja] (Unregistered) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.3 (mail.nttv6.net [IPv6:2001:fa8::25]); Tue, 10 Nov 2009 20:57:28 +0900 (JST) Cc: IETF IPFIX Working Group Subject: Re: [IPFIX] WG last call on draft-ietf-ipfix-mediators-problem-statement-06 X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Nov 2009 11:57:05 -0000 Hi all and co-authors, I had the feedbacks from Brian, Gerhard, Ishibashi-san, and Sujay during WGLC. Thank you very much. I improved it as the next version of problem statement as follows. http://www.nttv6.net/~akoba/draft-ietf-ipfix-mediators-problem-statement-07-00.txt You can see the difference between current version(-06) and new version(-07). http://www.nttv6.net/~akoba/diff-mediators-ps-06-07.htm If you have additional comments and suggestions, let me know. Regards, Atsushi On Mon, 19 Oct 2009 07:02:06 +0200 "Juergen Quittek" wrote: > Dear all, > > At our session in Stockholm we agreed to start the 2nd working group > last call on the mediation problem state as soon as a new version > of it would be available. The new version is > > http://www.ietf.org/internet-drafts/draft-ietf-ipfix-mediators-problem-state > ment-06.txt > > The call starts today and will last until Friday October 30. > > Please read the draft! > Please send your comments to this mailing list! > Please also send a message if you are fine with the draft as it is! > > Thank you, > > Juergen --- Atsushi KOBAYASHI NTT Information Sharing Platform Lab. tel:+81-(0)422-59-3978 fax:+81-(0)422-59-5637 From trammell@tik.ee.ethz.ch Tue Nov 10 04:07:58 2009 Return-Path: X-Original-To: ipfix@core3.amsl.com Delivered-To: ipfix@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id ACFBB3A687F for ; Tue, 10 Nov 2009 04:07:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=0.000, 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 VqgBNcrgWG9e for ; Tue, 10 Nov 2009 04:07:57 -0800 (PST) Received: from smtp.ee.ethz.ch (smtp.ee.ethz.ch [129.132.2.219]) by core3.amsl.com (Postfix) with ESMTP id 8D4183A683C for ; Tue, 10 Nov 2009 04:07:57 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by smtp.ee.ethz.ch (Postfix) with ESMTP id 0B183D93D5; Tue, 10 Nov 2009 13:08:22 +0100 (MET) X-Virus-Scanned: by amavisd-new on smtp.ee.ethz.ch Received: from smtp.ee.ethz.ch ([127.0.0.1]) by localhost (.ee.ethz.ch [127.0.0.1]) (amavisd-new, port 10024) with LMTP id fEPWS07J5GBk; Tue, 10 Nov 2009 13:08:21 +0100 (MET) Received: from pb-10072.ethz.ch (pb-10072.ethz.ch [82.130.103.195]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: briant) by smtp.ee.ethz.ch (Postfix) with ESMTP id A7CB2D936E; Tue, 10 Nov 2009 13:08:21 +0100 (MET) Mime-Version: 1.0 (Apple Message framework v1076) Content-Type: text/plain; charset=us-ascii; format=flowed; delsp=yes From: Brian Trammell In-Reply-To: <4AF8F999.3000207@cisco.com> Date: Tue, 10 Nov 2009 13:08:21 +0100 Content-Transfer-Encoding: 7bit Message-Id: References: <4AF73525.8050009@net.in.tum.de> <4AF8F999.3000207@cisco.com> To: Benoit Claise X-Mailer: Apple Mail (2.1076) Cc: ipfix@ietf.org Subject: Re: [IPFIX] Semantic and structured data X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Nov 2009 12:07:58 -0000 hi Benoit, Gerhard, In this case I'm strongly in favor of leaving semantics out of structured data. Structured data defines containers. The semantics of the containers as a whole and the elements change based upon the information elements within the container and within the record containing it. Wedging semantics into the structured data elements 1. risks further proliferation of (potentially non-interoperable) ways to represent the same thing, 2. gives us more ways to represent nonsensical things (an OR basicList of MPLS stack entries...means...what?), and 3. risks defining an inadequate semantic representation mechanism (what about semantics for records not using structured data? what about ordered versus unordered sets? what about OR basicList vs AND basicList vs nested AND and OR basicLists vs just three identical IEs?). If we really want an unambiguous semantic framework for IPFIX (and here I'm not convinced either way) that's best done on its own, addressing things at the information element and record level. Doing it here confuses the issue. Regards, Brian On Nov 10, 2009, at 6:26 AM, Benoit Claise wrote: > Gerhard, > > Thanks for your email. > I have no strong feelings about the two solutions you proposed. > > From a pure router point of view, I don't see any use cases for > logical OR in exporting flow records. > However, from a IPFIX Mediator point of view, I see some use cases. > I mean that it requires an Intermediate Aggregation Process or > Intermediate Correlation Process to express: I've seen this flow > record OR that flow record. > Now, it's true that even routers will have mediation functions... > > I'm inclined to add orBasicList, orSubTemplateList, > orSubTempalteMultiList to the draft (This is a small addition after > all) and to express that, by default, a logical AND is assumed... > specifically if the structured data is used in the IPFIX Mediation > Protocol. > > I'm not convinced by the NOT in the context of structured data, as > we don't even have a concept of NOT for a single information element! > > I would like to get some more feedback from others. > > Regards, Benoit. > >> Dear all, >> >> Regarding draft-ietf-ipfix-structured-data, I see the risk that the >> semantic of the exported structured data is not clear. >> >> How do you interpret the manifold occurrence of the same Information >> Element (basicList) or the same group of Information Elements >> (subTemplateList) in one record? >> >> What does it mean if basicList, subTemplateList, or >> subTemplateMultiList >> is used for a Flow Key field? Or non-key field? >> >> Some Examples: >> >> - BasicList of egress interfaces in a Flow Record >> How should a Flow Record be interpreted which contains a list of >> egress interfaces and a packet counter? >> Has every counted packet been sent on every egress interface? >> => multicast case, AND semantic (see example in section 8.1) >> Has every counted packet been sent on any one of the egress >> interfaces? >> => load balancing case, OR semantic >> Can it be used as a Flow Key or not? >> >> - BasicList of destination ports in a Flow Record >> As every packet has only one destination port, the only reasonable >> interpretation is that the Flow contains packets having one of >> the reported port numbers. >> => OR semantic >> This would be a non-key field. >> >> >> I think there are two solutions: >> >> 1. We decide that the semantic of list content is out of scope of >> draft-ietf-ipfix-structured-data. We add a note to the draft that >> the semantic must be clear from the context or the definition of >> the >> Information Elements used within the lists. >> >> 2. We define semantic lists, such as >> - andBasicList, andSubTemplateList, andSubTemplateMultiList >> - orBasicList, orSubTemplateList, orSubTempalteMultiList >> describing AND and OR semantic of the contained IEs/Templates, >> respectively. >> >> >> As I wrote in an earlier mail, I see a good use case for >> orBasicList. It >> could be used in the Selector Report Interpretation of Property Match >> Filtering to report a filter like "port 80 or port 443". >> http://www.ietf.org/mail-archive/web/ipfix/current/msg04856.html >> At the moment, the Selector Report Interpretation is limited to AND. >> However, if we also want to express a NOT, we still need another >> solution... >> >> Regards, >> Gerhard >> >> _______________________________________________ >> IPFIX mailing list >> IPFIX@ietf.org >> https://www.ietf.org/mailman/listinfo/ipfix >> > > _______________________________________________ > IPFIX mailing list > IPFIX@ietf.org > https://www.ietf.org/mailman/listinfo/ipfix From muenz@net.in.tum.de Tue Nov 10 07:06: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 4EF3C3A6A8C for ; Tue, 10 Nov 2009 07:06:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.094 X-Spam-Level: X-Spam-Status: No, score=-2.094 tagged_above=-999 required=5 tests=[AWL=0.155, 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 UoRweq7ecPpE for ; Tue, 10 Nov 2009 07:06:12 -0800 (PST) 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 434053A689F for ; Tue, 10 Nov 2009 07:06:10 -0800 (PST) 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 E8193485A0 for ; Tue, 10 Nov 2009 16:06:35 +0100 (CET) Received: from [131.159.20.108] (repulse.net.in.tum.de [131.159.20.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by phoenix.net.informatik.tu-muenchen.de (Postfix) with ESMTP id D268BB41 for ; Tue, 10 Nov 2009 16:06:35 +0100 (CET) Message-ID: <4AF981C2.6080102@net.in.tum.de> Date: Tue, 10 Nov 2009 16:07:46 +0100 From: Gerhard Muenz User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: ipfix@ietf.org References: <20091026160001.C2E1D3A6841@core3.amsl.com> <547F018265F92642B577B986577D671CE3872F@VENUS.office> <4AF453FB.8020408@net.in.tum.de> In-Reply-To: <4AF453FB.8020408@net.in.tum.de> Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms070804020005060000060706" X-Virus-Scanned: ClamAV using ClamSMTP Subject: Re: [IPFIX] I-D Action:draft-ietf-ipfix-mib-08.txt X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Nov 2009 15:06:13 -0000 This is a cryptographically signed message in MIME format. --------------ms070804020005060000060706 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable Hi again, Discussing this issue with Benoit, I would like to comment my own=20 statements inline: Gerhard Muenz wrote: > Dear all, >=20 > Thomas Dietz wrote: >> Dear all,=20 >> >> as you may have seen a new version of draft-ietf-ipfix-mib was publish= ed. >> Changes in this version are: >> >> - removed global ipfixExportVersion >> - added version information per Transport Session >> - removed ipfixTemplateObservationDomainId and ipfixTemplateId as inde= x in >> the ipfixExportTable >> - minor editorial fixes >> >> One point that recently was raised by Gerhard is still open: >> >> - add Observation Domain Id into the Observation Point table if possib= le >=20 > Let me explain this issue a bit more. >=20 > We have the following Observation Point table: >=20 >=20 > ipfixObservationPointTable(6) > | > +-ipfixObservationPointEntry(1)=20 > [ipfixObservationPointGroupId,ipfixObservationPointIndex] > | > + Unsigned32 ipfixObservationPointGroupId(1) > + Unsigned32 ipfixObservationPointIndex(2) > + PhysicalIndexOrZero ipfixObservationPointPhysicalEntity(3) > + Enumeration ipfixObservationPointPhysicalEntityDirection(4= ) >=20 >=20 > From this table, it is not possible to retrieve the Observation Domain= =20 > ID of an Observation Point. To understand why this might be interesting, consider the following use=20 case: You receive an IPFIX message with an Observation Domain ID value in the=20 message header. Now, you want to query the IPFIX-MIB which are the=20 Observation Points. > If an IPFIX Exporter establishes a Transport Session to a Collector,=20 > there is an entry in the Transport Session table. Associated to this=20 > entry, we have the Templates in the Template table. There, we can=20 > finally find the Observation Domain ID. >=20 > This procedure is quite complicated and does not work if no Transport=20 > Sessions are established. Stating that there exists a complicated solution was a mistake! In fact, it is not possible to get the information in the general case. Explanation: From ipfixTransportSessionTable, we can get the=20 ipfixObservationDomainId per ipfixTemplateEntry used in a given=20 Transport Session (using ipfixTransportSessionIndex as common index). On the other hand, we can link the ipfixTransportSessionEntry to one or=20 multiple ipfixMeteringProcessCacheIds with help of the ipfixExportTable. = Only if the Transport Session is linked to a single Metering Process, we = can go further and find the ipfixMeteringProcessObservationPointGroupRef = in the ipfixMeteringProcessTable. If ipfixExportTable relates one ipfixTransportSessionEntry to multiple=20 ipfixMeteringProcessCacheIds, we may find several=20 ipfixMeteringProcessObservationPointGroupRef values pointing to multiple = ipfixObservationPointGroupEntries. Then, we do not know how to do a=20 one-to-one-mapping between multiple Observation Domain IDs and multiple=20 Observation Point groups. So, in summary, the IPFIX MIB is useless for the use case mentioned=20 above. Adding ipfixObservationPointObservationDomainId solves this proble= m. Regards, Gerhard >=20 >=20 > Possible solutions: >=20 > 1) We do not care because nobody is interested in the mapping between=20 > Observation Points and Observation Domains. >=20 > 2) We add ipfixObservationPointObservationDomainId to the Observation=20 > Point table (as a normal parameter, not as an index). >=20 >=20 > Personally, I prefer solution 2. >=20 >=20 > There is a related issue regarding the relationship between Observation= =20 > Domain and Metering Process. >=20 >=20 > RFC5101 says: >=20 > Observation Domain >=20 > An Observation Domain is the largest set of Observation Points f= or > which Flow information can be aggregated by a Metering Process. >=20 >=20 > Some people interpreted this definition as if only packets of a single = > Observation Domain may enter a Metering Process/Cache. In this case, i= t=20 > follows that Observations Points sharing the same=20 > ipfixObservationPointGroupId must have identical Observation Domain ID = > values. This fact could be added in the description clause of=20 > ipfixObservationPointGroupId: > "All Observation Points belonging to the same group must belong to t= he > same Observation Domain." >=20 > However, I understand the definition differently. IMO, it does not say= =20 > that packets from different Observation Domains must not enter the same= =20 > Metering Process. It just says that a single Flow Record only accounts= =20 > packets of a single Observation Domain. To achieve this, it is=20 > sufficient that the Metering Process/Cache treats the Observation Domai= n=20 > ID as an additional Flow Key. >=20 >=20 > It would be nice to get to an agreement regarding the understanding of = > the relationship between Observation Domain and Metering Process. >=20 > The outcome does not only concern the IPFIX-MIB, but also the=20 > configuration data model. >=20 > Best regards, > Gerhard >=20 >=20 >=20 >=20 > -----------------------------------------------------------------------= - >=20 > _______________________________________________ > IPFIX mailing list > IPFIX@ietf.org > https://www.ietf.org/mailman/listinfo/ipfix --=20 Dipl.-Ing. Gerhard M=FCnz Chair for Network Architectures and Services (I8) 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 --------------ms070804020005060000060706 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 SIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMDkxMTEwMTUwNzQ2WjAjBgkqhkiG9w0BCQQxFgQU LWvJfUB8wdwlO2gzgCc2QTPVm5gwXwYJKoZIhvcNAQkPMVIwUDALBglghkgBZQMEAQIwCgYI KoZIhvcNAwcwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqG SIb3DQMCAgEoMIGFBgkrBgEEAYI3EAQxeDB2MGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxU aGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwg RnJlZW1haWwgSXNzdWluZyBDQQIQKsXq3Tdl1UZFGbLpOSCnTzCBhwYLKoZIhvcNAQkQAgsx eKB2MGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBM dGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQQIQKsXq 3Tdl1UZFGbLpOSCnTzANBgkqhkiG9w0BAQEFAASCAQCVGf9RJaflqij6ksgLuxeslRQ4ilKV j40iAK+HumN4JJvNkam5Ae7DPzwAtWMl44O3OcPswKvnSZ+xD0dbr0gigv/Qkp9v8TcXuOlq mJlQz6NoFezh9qucHBOZNgS+v5BB8XoFt5jdDQmYtQ41y+3Uts++eN+dV5SHzSgCe6HM5w8Q cDpWDw2lFQFKP7euGHsbH98HGK2W1MmbbjvXOhqA+h8YyYJkobeQ6jLTzzr6MOWzUh/u2Pvi oEWhEQ+XJR9x/GqZDyQJsQpVhIarJV+h1xz6GbaWYAGIsAAPgctYkeccMRCNVSiFZ2NGrSNk 2ygszZ5dc9V1bJQEBBrWe+ZWAAAAAAAA --------------ms070804020005060000060706-- From sujay.ietf@gmail.com Tue Nov 10 08:01:17 2009 Return-Path: X-Original-To: ipfix@core3.amsl.com Delivered-To: ipfix@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D41433A696A for ; Tue, 10 Nov 2009 08:01:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YMHXl3J-ymvy for ; Tue, 10 Nov 2009 08:01:16 -0800 (PST) Received: from mail-pw0-f50.google.com (mail-pw0-f50.google.com [209.85.160.50]) by core3.amsl.com (Postfix) with ESMTP id DDE4F3A67B3 for ; Tue, 10 Nov 2009 08:01:16 -0800 (PST) Received: by pwi6 with SMTP id 6so97884pwi.29 for ; Tue, 10 Nov 2009 08:01:40 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=XTefoyMdB0bx7ribHEbec5eLBIVWRGKkON9N+WRKNBA=; b=dpuio8DKaX7ipGHHSOzBOAdC7SmJHunxBGKevteWhm+SxXKa2N8nq2M6tluiCPEcAs ArS4STEFZa8rP32JgPDhtKzsnTM3lt4iNUNxrgQEG0hqAaEF/VwOSyTHDdgreh3BcoJ5 Yeo4vf/9hy09htjDg9irgb34nJUek/HRioSaU= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=PuFbTBY2A5HZPzdiLH3Fd9XZZM74wXSTZaEJTHAnIcqtKWwesoxwySiybIdalP3+El oT+6+KCAVNrduTX3pa0AuEYstoLtk0WPtPckLdJEOO8h5iHozl+LP3NeeNQ/mcjvdOpD tVG7Nl3M5wBXaTpMQWg8Z8KZMGzYmrcS2faEc= MIME-Version: 1.0 Received: by 10.143.24.41 with SMTP id b41mr23046wfj.238.1257868900562; Tue, 10 Nov 2009 08:01:40 -0800 (PST) In-Reply-To: <20091110192704.13D7.17391CF2@nttv6.net> References: <20091110192704.13D7.17391CF2@nttv6.net> Date: Tue, 10 Nov 2009 21:31:40 +0530 Message-ID: From: sujay gupta To: Atsushi Kobayashi Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: IETF IPFIX Working Group , Juergen Quittek Subject: Re: [IPFIX] WG last call on draft-ietf-ipfix-mediators-problem-statement-06 X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Nov 2009 16:01:17 -0000 Hi Atsushi, I am fine with the changes, Yes I was suggesting the figure in .04 version, but it seems it was removed for a good reason in the later drafts. The description text is also sufficient to visualize it. BR, -Sujay 2009/11/10 Atsushi Kobayashi : > > Hi Sujay, > > Thank you for your feedback. > Please see in-line. > > On Tue, 3 Nov 2009 23:44:55 +0530 > sujay gupta wrote: > >> Hi, >> >> I am overall fine with the doc. >> >> small changes however would help such as; >> section 4.1, last para mentions the need of system not relying on >> data reduction techniques, section 4.4 contradicts it. >> > > I will change section 4.4 last para. Is it OK? > > 4.4. =A0Summary > > =A0 In adjusting some parameters to the resources of a measurement > =A0 system, it is important to use traffic data reduction techniques as > =A0 early as possible, e.g., at the Exporter. =A0However, this > =A0 implementation is made difficult by heterogeneous environment of > =A0 exporting devices. =A0On the other hand, keeping data accuracy and fl= ow > =A0 granularity to meet the requirements of different monitoring > =A0 applications requires a scalable and flexible collecting > =A0 infrastructure. > >> section 1, first para, between first and second line could mention >> that "traffic monitoring is taxing on the resources" and hence the need >> for optimization( ie the 2nd line). >> last line in the para says "platform", is it required? >> > > I will change as follows. Is it OK? > > 1. =A0Introduction > > =A0 One advantage of Flow-based measurement results from easily offering > =A0 the traffic monitoring of a huge amount of traffic. =A0While the usag= e > =A0 is applied to any networks and to multiple measurement applications > =A0 taxing on the resources of the measurement system, network > =A0 administrators need to adjust some parameters of metering devices and > =A0 of multiple measurement applications to these resources. =A0IP traffi= c > =A0 growth and a wide variety of measurement application make the > =A0 adjustment further difficult. =A0To make a measurement system flexibl= e > =A0 and scalable, an intermediate device can generally be applied to the > =A0 system. > >> perhaps having a figure showing the position of ipfix-med amongst >> other layers( section 2) >> would be a nice addition. > > Does your suggestion imply the Figure B in framework draft? > http://tools.ietf.org/html/draft-ietf-ipfix-mediators-framework-04 > > Regards, > Atsushi >> >> BR, >> -Sujay >> >> >> On Mon, Nov 2, 2009 at 3:52 PM, Juergen Quittek w= rote: >> > Hi Sujay, >> > >> > Thank you for the review. >> > >> > On 31.10.09 08:27 ?"sujay gupta" wrote: >> > >> >> Hi, >> >> A few comments. >> >> 1) I have a slight problem overall with the language structuring >> >> especially from section 1 to 4. It could be made simple. >> > >> > Would you have concrete suggestions? This would be helpful. >> > >> > Thanks, >> > >> > ? ?Juergen >> > >> > >> >> 2) IPFIX mediation as a service or device? is intermixed, can we >> >> differentiate that? also can we call the different type of mediators >> >> as services? >> >> 3) Is there any line of thought of having the mediation device >> >> incorporate record compression to reduce b/w?( >> >> draft-muenz-ipfix-compression) as another service, or deal with >> >> compressed data from the original exporter? >> >> BR, >> >> -Sujay >> >> >> >> >> >> On Mon, Oct 19, 2009 at 10:32 AM, Juergen Quittek >> >> wrote: >> >>> Dear all, >> >>> >> >>> At our session in Stockholm we agreed to start the 2nd working group >> >>> last call on the mediation problem state as soon as a new version >> >>> of it would be available. The new version is >> >>> >> >>> http://www.ietf.org/internet-drafts/draft-ietf-ipfix-mediators-probl= em-state >> >>> ment-06.txt >> >>> >> >>> The call starts today and will last until Friday October 30. >> >>> >> >>> Please read the draft! >> >>> Please send your comments to this mailing list! >> >>> Please also send a message if you are fine with the draft as it is! >> >>> >> >>> Thank you, >> >>> >> >>> ? ?Juergen >> >>> >> >>> _______________________________________________ >> >>> IPFIX mailing list >> >>> IPFIX@ietf.org >> >>> https://www.ietf.org/mailman/listinfo/ipfix >> >>> >> >>> >> > >> _______________________________________________ >> IPFIX mailing list >> IPFIX@ietf.org >> https://www.ietf.org/mailman/listinfo/ipfix > > --- > Atsushi KOBAYASHI =A0 > NTT Information Sharing Platform Lab. > tel:+81-(0)422-59-3978 fax:+81-(0)422-59-5637 > > From pwildi@cisco.com Tue Nov 10 11:39:06 2009 Return-Path: X-Original-To: ipfix@core3.amsl.com Delivered-To: ipfix@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AF6C828C230 for ; Tue, 10 Nov 2009 11:39:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jFpoHEfQrhWQ for ; Tue, 10 Nov 2009 11:39:06 -0800 (PST) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by core3.amsl.com (Postfix) with ESMTP id F0B7328C22F for ; Tue, 10 Nov 2009 11:39:05 -0800 (PST) Authentication-Results: sj-iport-6.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEAF5Q+UqrR7H+/2dsb2JhbADHCZgzhD4E X-IronPort-AV: E=Sophos;i="4.44,717,1249257600"; d="scan'208";a="429342546" Received: from sj-core-2.cisco.com ([171.71.177.254]) by sj-iport-6.cisco.com with ESMTP; 10 Nov 2009 19:39:33 +0000 Received: from [171.69.69.160] (dhcp-171-69-69-160.cisco.com [171.69.69.160]) by sj-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id nAAJdXbs005186 for ; Tue, 10 Nov 2009 19:39:33 GMT Message-ID: <4AF9C175.8050506@cisco.com> Date: Tue, 10 Nov 2009 11:39:33 -0800 From: Patrick Wildi User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: ipfix@ietf.org References: <4ADDB836.80603@cisco.com> In-Reply-To: <4ADDB836.80603@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Tue, 10 Nov 2009 12:22:08 -0800 Subject: Re: [IPFIX] [Fwd: I-D ACTION:draft-claise-ipfix-mediation-protocol-00.txt] X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Nov 2009 19:39:06 -0000 I read the draft, I support it, and I don't have any issues with it Patrick Wildi > > > -------- Original Message -------- > Subject: I-D ACTION:draft-claise-ipfix-mediation-protocol-00.txt > Date: Mon, 19 Oct 2009 14:15:03 -0700 (PDT) > From: Internet-Drafts@ietf.org > Reply-To: internet-drafts@ietf.org > To: i-d-announce@ietf.org > > > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > > > Title : Specification of the Protocol for IPFIX Mediations > Author(s) : B. Claise, A. Kobayashi, B. Trammell > Filename : draft-claise-ipfix-mediation-protocol-00.txt > Pages : 17 > Date : 2009-10-19 > > This document specifies the IP Flow Information Export > (IPFIX) protocol specific to the Mediation. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-claise-ipfix-mediation-protocol-00.txt > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > Below is the data which will enable a MIME compliant mail reader > implementation to automatically retrieve the ASCII version of the > Internet-Draft. > > From vdharani@gmail.com Tue Nov 10 14:58:59 2009 Return-Path: X-Original-To: ipfix@core3.amsl.com Delivered-To: ipfix@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CD94D3A6960 for ; Tue, 10 Nov 2009 14:58:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RqCNpvAzsVNz for ; Tue, 10 Nov 2009 14:58:59 -0800 (PST) Received: from mail-pz0-f204.google.com (mail-pz0-f204.google.com [209.85.222.204]) by core3.amsl.com (Postfix) with ESMTP id 27C2E3A6931 for ; Tue, 10 Nov 2009 14:58:59 -0800 (PST) Received: by pzk42 with SMTP id 42so381748pzk.31 for ; Tue, 10 Nov 2009 14:59:24 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:date:message-id:subject :from:to:content-type; bh=KUHnBjR6/hhtPj+qr8BiQ7W4aGZwJufSh9lh8lJyLnA=; b=J61YiKyMjy/7xHYcupPYVZwzQoasHVYcXcOI330uF3jWLk8fh4BMmhizDiJIpCRWlz NyGaKd7B45ZupreN3p3soFcJvtNbS4TwU655SoTjG+MQCNt3XyeCnn6BKGMbNkD/yo6E MElyrxSIfbIURuWgel9Z0x1rF50+lu20Z6gXU= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=i2AMx908HwIFvOoIQf/4/+5craGx/GJE7ryHdEKGm4WC2LezqqCTyMu9/NMxaHDgdd QB/FrZ/2VxWX47uD9LjCUMC3QhKJKMMrZzShxRN+BgXVfsf4qTY4Mwyv0Ry3MQqvTkYN aUKcGxLse+zSLf77uX2xmVyqr1JySwb1Lm/ts= MIME-Version: 1.0 Received: by 10.142.9.34 with SMTP id 34mr78163wfi.114.1257893963965; Tue, 10 Nov 2009 14:59:23 -0800 (PST) Date: Tue, 10 Nov 2009 14:59:23 -0800 Message-ID: From: Tharaneedharan Vilwanathan To: ipfix@ietf.org Content-Type: multipart/alternative; boundary=00504502b738e3237704780c429f Subject: [IPFIX] Sample IPFIX file X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Nov 2009 22:58:59 -0000 --00504502b738e3237704780c429f Content-Type: text/plain; charset=ISO-8859-1 Hi All, I am currently going through IPFIX file format spec ( http://tools.ietf.org/html/rfc5655). I am wondering if I there are sample IPFIX files that I can play with. Any pointers? Thanks in advance. Regards dharani --00504502b738e3237704780c429f Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi All,
=A0
I am currently going through IPFIX file format spec (http://tools.ietf.org/html/rfc5655). I am= wondering if I there are sample IPFIX files that I can play with. Any poin= ters?=20
=A0
Thanks in advance.
=A0
Regards
dharani
=A0
--00504502b738e3237704780c429f-- From bclaise@cisco.com Tue Nov 10 17:46:08 2009 Return-Path: X-Original-To: ipfix@core3.amsl.com Delivered-To: ipfix@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BDB9F28C205 for ; Tue, 10 Nov 2009 17:46:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.49 X-Spam-Level: X-Spam-Status: No, score=-2.49 tagged_above=-999 required=5 tests=[AWL=0.109, 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 WbQoJ2NB1OP6 for ; Tue, 10 Nov 2009 17:46:08 -0800 (PST) Received: from av-tac-bru.cisco.com (weird-brew.cisco.com [144.254.15.118]) by core3.amsl.com (Postfix) with ESMTP id 9E0213A69E6 for ; Tue, 10 Nov 2009 17:46:07 -0800 (PST) X-TACSUNS: Virus Scanned Received: from strange-brew.cisco.com (localhost.cisco.com [127.0.0.1]) by av-tac-bru.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id nAB1gnGb008655 for ; Wed, 11 Nov 2009 02:42:49 +0100 (CET) Received: from [10.70.230.14] (tky-vpn-client-230-14.cisco.com [10.70.230.14]) by strange-brew.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id nAB1gjb1014123; Wed, 11 Nov 2009 02:42:46 +0100 (CET) Message-ID: <4AFA1694.2090406@cisco.com> Date: Wed, 11 Nov 2009 10:42:44 +0900 From: Benoit Claise User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Patrick Wildi References: <4ADDB836.80603@cisco.com> <4AF9C175.8050506@cisco.com> In-Reply-To: <4AF9C175.8050506@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: ipfix@ietf.org Subject: Re: [IPFIX] [Fwd: I-D ACTION:draft-claise-ipfix-mediation-protocol-00.txt] X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Nov 2009 01:46:08 -0000 Patrick, Knowing the draft that you have reviewed (as we discussed it together privately), your comment concerns the Working Group Last Call on the Mediation Problem Statement: draft-ietf-ipfix-mediators-problem-statement-06... and not draft-claise-ipfix-mediation-protocol-00.txt as the subject expresses. Regards, Benoit. > I read the draft, I support it, and I don't have any issues with it > > Patrick Wildi > >> >> >> -------- Original Message -------- >> Subject: I-D ACTION:draft-claise-ipfix-mediation-protocol-00.txt >> Date: Mon, 19 Oct 2009 14:15:03 -0700 (PDT) >> From: Internet-Drafts@ietf.org >> Reply-To: internet-drafts@ietf.org >> To: i-d-announce@ietf.org >> >> >> >> A New Internet-Draft is available from the on-line Internet-Drafts >> directories. >> >> >> Title : Specification of the Protocol for IPFIX Mediations >> Author(s) : B. Claise, A. Kobayashi, B. Trammell >> Filename : draft-claise-ipfix-mediation-protocol-00.txt >> Pages : 17 >> Date : 2009-10-19 >> >> This document specifies the IP Flow Information Export >> (IPFIX) protocol specific to the Mediation. >> A URL for this Internet-Draft is: >> http://www.ietf.org/internet-drafts/draft-claise-ipfix-mediation-protocol-00.txt >> >> >> Internet-Drafts are also available by anonymous FTP at: >> ftp://ftp.ietf.org/internet-drafts/ >> >> Below is the data which will enable a MIME compliant mail reader >> implementation to automatically retrieve the ASCII version of the >> Internet-Draft. >> >> > > _______________________________________________ > IPFIX mailing list > IPFIX@ietf.org > https://www.ietf.org/mailman/listinfo/ipfix From pwildi@cisco.com Tue Nov 10 17:46:41 2009 Return-Path: X-Original-To: ipfix@core3.amsl.com Delivered-To: ipfix@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 40AE328C22E for ; Tue, 10 Nov 2009 17:46:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rw7jbpZdk+6x for ; Tue, 10 Nov 2009 17:46:40 -0800 (PST) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by core3.amsl.com (Postfix) with ESMTP id 7E54A28C22C for ; Tue, 10 Nov 2009 17:46:40 -0800 (PST) Authentication-Results: sj-iport-6.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-AV: E=Sophos;i="4.44,719,1249257600"; d="scan'208";a="429581915" Received: from sj-core-5.cisco.com ([171.71.177.238]) by sj-iport-6.cisco.com with ESMTP; 11 Nov 2009 01:47:01 +0000 Received: from [10.19.28.221] (sjc-pwildi-87112.cisco.com [10.19.28.221]) by sj-core-5.cisco.com (8.13.8/8.14.3) with ESMTP id nAB1l1ct010058; Wed, 11 Nov 2009 01:47:01 GMT Message-ID: <4AFA1796.1080109@cisco.com> Date: Tue, 10 Nov 2009 17:47:02 -0800 From: Patrick Wildi User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Benoit Claise References: <4ADDB836.80603@cisco.com> <4AF9C175.8050506@cisco.com> <4AFA1694.2090406@cisco.com> In-Reply-To: <4AFA1694.2090406@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: ipfix@ietf.org Subject: Re: [IPFIX] [Fwd: I-D ACTION:draft-claise-ipfix-mediation-protocol-00.txt] X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Nov 2009 01:46:41 -0000 Benoit Claise wrote: > Patrick, > > Knowing the draft that you have reviewed (as we discussed it together > privately), your comment concerns the Working Group Last Call on the > Mediation Problem Statement: > draft-ietf-ipfix-mediators-problem-statement-06... and not > draft-claise-ipfix-mediation-protocol-00.txt as the subject expresses. That is correct. Thanks for catching my mistake of replying to the wrong message. Patrick > > Regards, Benoit. >> I read the draft, I support it, and I don't have any issues with it >> >> Patrick Wildi >> >>> >>> >>> -------- Original Message -------- >>> Subject: I-D ACTION:draft-claise-ipfix-mediation-protocol-00.txt >>> Date: Mon, 19 Oct 2009 14:15:03 -0700 (PDT) >>> From: Internet-Drafts@ietf.org >>> Reply-To: internet-drafts@ietf.org >>> To: i-d-announce@ietf.org >>> >>> >>> >>> A New Internet-Draft is available from the on-line Internet-Drafts >>> directories. >>> >>> >>> Title : Specification of the Protocol for IPFIX >>> Mediations Author(s) : B. Claise, A. Kobayashi, B. Trammell >>> Filename : draft-claise-ipfix-mediation-protocol-00.txt >>> Pages : 17 >>> Date : 2009-10-19 >>> This document specifies the IP Flow Information Export >>> (IPFIX) protocol specific to the Mediation. >>> A URL for this Internet-Draft is: >>> http://www.ietf.org/internet-drafts/draft-claise-ipfix-mediation-protocol-00.txt >>> >>> >>> Internet-Drafts are also available by anonymous FTP at: >>> ftp://ftp.ietf.org/internet-drafts/ >>> >>> Below is the data which will enable a MIME compliant mail reader >>> implementation to automatically retrieve the ASCII version of the >>> Internet-Draft. >>> >>> >> >> _______________________________________________ >> IPFIX mailing list >> IPFIX@ietf.org >> https://www.ietf.org/mailman/listinfo/ipfix From bclaise@cisco.com Tue Nov 10 18:12:56 2009 Return-Path: X-Original-To: ipfix@core3.amsl.com Delivered-To: ipfix@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2C7EC28C23D for ; Tue, 10 Nov 2009 18:12:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.493 X-Spam-Level: X-Spam-Status: No, score=-2.493 tagged_above=-999 required=5 tests=[AWL=0.106, 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 AwVQXgKgo0VG for ; Tue, 10 Nov 2009 18:12:54 -0800 (PST) Received: from av-tac-bru.cisco.com (weird-brew.cisco.com [144.254.15.118]) by core3.amsl.com (Postfix) with ESMTP id 4DA513A6811 for ; Tue, 10 Nov 2009 18:12:54 -0800 (PST) X-TACSUNS: Virus Scanned Received: from strange-brew.cisco.com (localhost.cisco.com [127.0.0.1]) by av-tac-bru.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id nAB1vCgt014646 for ; Wed, 11 Nov 2009 02:57:12 +0100 (CET) Received: from [10.70.230.14] (tky-vpn-client-230-14.cisco.com [10.70.230.14]) by strange-brew.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id nAB1vAWk022971; Wed, 11 Nov 2009 02:57:11 +0100 (CET) Message-ID: <4AFA19F5.1040800@cisco.com> Date: Wed, 11 Nov 2009 10:57:09 +0900 From: Benoit Claise User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Patrick Wildi References: <4ADDB836.80603@cisco.com> <4AF9C175.8050506@cisco.com> <4AFA1694.2090406@cisco.com> <4AFA1796.1080109@cisco.com> In-Reply-To: <4AFA1796.1080109@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: ipfix@ietf.org Subject: Re: [IPFIX] [Fwd: I-D ACTION:draft-claise-ipfix-mediation-protocol-00.txt] X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Nov 2009 02:12:56 -0000 Patrick, Don't worry. ;-) Thanks for your review. Regards, Benoit. > Benoit Claise wrote: >> Patrick, >> >> Knowing the draft that you have reviewed (as we discussed it together >> privately), your comment concerns the Working Group Last Call on the >> Mediation Problem Statement: >> draft-ietf-ipfix-mediators-problem-statement-06... and not >> draft-claise-ipfix-mediation-protocol-00.txt as the subject expresses. > > That is correct. Thanks for catching my mistake of replying to the > wrong message. > > Patrick > >> >> Regards, Benoit. >>> I read the draft, I support it, and I don't have any issues with it >>> >>> Patrick Wildi >>> >>>> >>>> >>>> -------- Original Message -------- >>>> Subject: I-D ACTION:draft-claise-ipfix-mediation-protocol-00.txt >>>> Date: Mon, 19 Oct 2009 14:15:03 -0700 (PDT) >>>> From: Internet-Drafts@ietf.org >>>> Reply-To: internet-drafts@ietf.org >>>> To: i-d-announce@ietf.org >>>> >>>> >>>> >>>> A New Internet-Draft is available from the on-line Internet-Drafts >>>> directories. >>>> >>>> >>>> Title : Specification of the Protocol for IPFIX >>>> Mediations Author(s) : B. Claise, A. Kobayashi, B. Trammell >>>> Filename : draft-claise-ipfix-mediation-protocol-00.txt >>>> Pages : 17 >>>> Date : 2009-10-19 >>>> This document specifies the IP Flow Information Export >>>> (IPFIX) protocol specific to the Mediation. >>>> A URL for this Internet-Draft is: >>>> http://www.ietf.org/internet-drafts/draft-claise-ipfix-mediation-protocol-00.txt >>>> >>>> >>>> Internet-Drafts are also available by anonymous FTP at: >>>> ftp://ftp.ietf.org/internet-drafts/ >>>> >>>> Below is the data which will enable a MIME compliant mail reader >>>> implementation to automatically retrieve the ASCII version of the >>>> Internet-Draft. >>>> >>>> >>> >>> _______________________________________________ >>> IPFIX mailing list >>> IPFIX@ietf.org >>> https://www.ietf.org/mailman/listinfo/ipfix From bclaise@cisco.com Tue Nov 10 19:09: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 6907628C284 for ; Tue, 10 Nov 2009 19:09:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.496 X-Spam-Level: X-Spam-Status: No, score=-2.496 tagged_above=-999 required=5 tests=[AWL=0.103, 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 6orTxx1LqS9w for ; Tue, 10 Nov 2009 19:09:12 -0800 (PST) Received: from av-tac-bru.cisco.com (weird-brew.cisco.com [144.254.15.118]) by core3.amsl.com (Postfix) with ESMTP id CD2FF28C249 for ; Tue, 10 Nov 2009 19:09:11 -0800 (PST) X-TACSUNS: Virus Scanned Received: from strange-brew.cisco.com (localhost.cisco.com [127.0.0.1]) by av-tac-bru.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id nAB2Ut1d028571; Wed, 11 Nov 2009 03:30:55 +0100 (CET) Received: from [10.70.230.14] (tky-vpn-client-230-14.cisco.com [10.70.230.14]) by strange-brew.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id nAB2Uo51017037; Wed, 11 Nov 2009 03:30:51 +0100 (CET) Message-ID: <4AFA21DA.4090200@cisco.com> Date: Wed, 11 Nov 2009 11:30:50 +0900 From: Benoit Claise User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Tobias Limmer References: <7A07131A-78E8-44DA-85A7-FF7D839A6AA8@tik.ee.ethz.ch> <4AEABCFB.70505@cisco.com> <978917B0-172E-4DB1-AE06-03B9A107F446@informatik.uni-erlangen.de> <4AF1419F.2000008@net.in.tum.de> <5FB55758-05FE-47AE-BE8B-9F4E48C1FC75@informatik.uni-erlangen.de> In-Reply-To: <5FB55758-05FE-47AE-BE8B-9F4E48C1FC75@informatik.uni-erlangen.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: ipfix@ietf.org Subject: Re: [IPFIX] Fwd: I-D ACTION:draft-ietf-ipfix-export-per-sctp-stream-04.txt X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Nov 2009 03:09:13 -0000 Hi Tobias, Thanks for your review. > Hi Gerhard, > > comments inline! > > On 04.11.2009, at 09:55, Gerhard Muenz wrote: >> Tobias Limmer wrote: >>> 3.1.1. IPFIX Protocol Specifications Limitation: >>> "Note that a workaround allowed by the IPFIX specifications >>> [RFC5101] is to use only one Template Record per SCTP Transport >>> Session, at the cost of multiplying the number of SCTP Transport >>> Sessions when multiple Template Records are required." >>> This paragraph sounds a little misplaced, as it already mentions >>> the performance impact. After reading it, I was wondering what >>> other method would be proposed in this draft. >> >> Not sure if you got the paragraph right. It talks about SCTP >> Transport Sessions, not SCTP streams. Using different Transport >> Sessions requires indeed much more overhead (e.g., multiple sockets) >> than just having multiple streams in one Transport Session. > > Oh right, I misunderstood. But then you should always use the term > 'SCTP association' instead of 'SCTP transport session', as you've > already done in the rest of the document, except section 2.2. ("[...] > active within a single SCTP Transport Session and [...]"). > >>> 4.2. Template Management: >>> "Any Data Sets associated with a Template Record MUST be sent on >>> the same SCTP stream on which the Template Record was sent." >>> According to rfc5101, an Options Template Record is a Template >>> Record. Later in the same section you specify: "When the Options >>> Template and associated Data Records are sent in different SCTP >>> streams, [...]". >>> Isn't this a contradiction, or am I missing something here? >> >> This is a flaw of IPFIX terminology. >> >> In the text, we tried to consistently use "(Options) Template" if we >> talk about both Options and non-Options Templates. The sentence above >> is just about non-Options Templates. >> >> Not sure, how we can make this more comprehensible. Maybe a note in >> the terminology section? > > Yes, I agree, as you are using this terminology in the whole document. I'm not sure what is the agreement, and if we should add something in the terminology. If yes, what do you suggest? Regards, Benoit. > > > Regards, > Tobi > > -- > Dipl.-Inf. Tobias Limmer > Chair for Computer Networks and Communication Systems > Universität Erlangen-Nürnberg > Martensstr. 3, D-91058 Erlangen, Germany > Phone: +49-9131-8527931 Fax: +49-9131-8527409 > eMail: limmer .at. informatik.uni-erlangen.de > URL: http://www7.informatik.uni-erlangen.de/~limmer > From limmer@informatik.uni-erlangen.de Thu Nov 12 07:17:16 2009 Return-Path: X-Original-To: ipfix@core3.amsl.com Delivered-To: ipfix@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CC3443A6BC6 for ; Thu, 12 Nov 2009 07:17:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.569 X-Spam-Level: X-Spam-Status: No, score=-1.569 tagged_above=-999 required=5 tests=[AWL=0.680, 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 WT9UTnFue6si for ; Thu, 12 Nov 2009 07:17:16 -0800 (PST) Received: from faui45.informatik.uni-erlangen.de (faui45.informatik.uni-erlangen.de [131.188.34.45]) by core3.amsl.com (Postfix) with ESMTP id D6E3228C0E2 for ; Thu, 12 Nov 2009 07:17:15 -0800 (PST) Received: from faui7as (faui7as.informatik.uni-erlangen.de [131.188.37.230]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by faui45.informatik.uni-erlangen.de (Postfix) with ESMTPS id 288A7497E; Thu, 12 Nov 2009 16:17:43 +0100 (MET) Received: from faui7ma3.informatik.uni-erlangen.de (faui7ma3.informatik.uni-erlangen.de [131.188.37.40]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by faui7as (Postfix) with ESMTPSA id 00F7C4382A9; Thu, 12 Nov 2009 16:17:42 +0100 (CET) From: Tobias Limmer To: Benoit Claise In-Reply-To: <4AFA21DA.4090200@cisco.com> References: <7A07131A-78E8-44DA-85A7-FF7D839A6AA8@tik.ee.ethz.ch> <4AEABCFB.70505@cisco.com> <978917B0-172E-4DB1-AE06-03B9A107F446@informatik.uni-erlangen.de> <4AF1419F.2000008@net.in.tum.de> <5FB55758-05FE-47AE-BE8B-9F4E48C1FC75@informatik.uni-erlangen.de> <4AFA21DA.4090200@cisco.com> Message-Id: <2AB3F5EF-DF15-4638-AB4D-9BC48C68858C@informatik.uni-erlangen.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed; delsp=yes Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Apple Message framework v936) Date: Thu, 12 Nov 2009 16:17:42 +0100 X-Mailer: Apple Mail (2.936) Cc: ipfix@ietf.org Subject: Re: [IPFIX] Fwd: I-D ACTION:draft-ietf-ipfix-export-per-sctp-stream-04.txt X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Nov 2009 15:17:16 -0000 Hi Benoit, On 11.11.2009, at 03:30, Benoit Claise wrote: >>> This is a flaw of IPFIX terminology. >>> >>> In the text, we tried to consistently use "(Options) Template" if =20= >>> we talk about both Options and non-Options Templates. The sentence =20= >>> above is just about non-Options Templates. >>> Not sure, how we can make this more comprehensible. Maybe a note =20 >>> in the terminology section? >> >> Yes, I agree, as you are using this terminology in the whole =20 >> document. > I'm not sure what is the agreement, and if we should add something =20 > in the terminology. > If yes, what do you suggest? Maybe something like: Term Template has been ambiguously defined in [RFC5101]. In this =20 document, Template and Options Template describe disjoint sets, and =20 Template is not used as generic term for Options Template. Bye, Tobi -- Dipl.-Inf. Tobias Limmer Chair for Computer Networks and Communication Systems Universit=E4t Erlangen-N=FCrnberg Martensstr. 3, D-91058 Erlangen, Germany Phone: +49-9131-8527931 Fax: +49-9131-8527409 eMail: limmer .at. informatik.uni-erlangen.de URL: http://www7.informatik.uni-erlangen.de/~limmer From trammell@tik.ee.ethz.ch Thu Nov 12 07:24:50 2009 Return-Path: X-Original-To: ipfix@core3.amsl.com Delivered-To: ipfix@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 065903A6ACC for ; Thu, 12 Nov 2009 07:24:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=0.000, 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 hX39E2ZLMk1U for ; Thu, 12 Nov 2009 07:24:46 -0800 (PST) Received: from smtp.ee.ethz.ch (smtp.ee.ethz.ch [129.132.2.219]) by core3.amsl.com (Postfix) with ESMTP id C9FC93A6ABD for ; Thu, 12 Nov 2009 07:24:45 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by smtp.ee.ethz.ch (Postfix) with ESMTP id 49849D93BD; Thu, 12 Nov 2009 16:25:13 +0100 (MET) X-Virus-Scanned: by amavisd-new on smtp.ee.ethz.ch Received: from smtp.ee.ethz.ch ([127.0.0.1]) by localhost (.ee.ethz.ch [127.0.0.1]) (amavisd-new, port 10024) with LMTP id ES6nXlZXbSYv; Thu, 12 Nov 2009 16:25:13 +0100 (MET) Received: from pb-10072.ethz.ch (pb-10072.ethz.ch [82.130.103.195]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: briant) by smtp.ee.ethz.ch (Postfix) with ESMTP id F2A8CD9382; Thu, 12 Nov 2009 16:25:12 +0100 (MET) Mime-Version: 1.0 (Apple Message framework v1076) Content-Type: text/plain; charset=iso-8859-1; format=flowed; delsp=yes From: Brian Trammell In-Reply-To: <2AB3F5EF-DF15-4638-AB4D-9BC48C68858C@informatik.uni-erlangen.de> Date: Thu, 12 Nov 2009 16:25:12 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <247849B0-55E5-49A8-B422-59E2DBE597B5@tik.ee.ethz.ch> References: <7A07131A-78E8-44DA-85A7-FF7D839A6AA8@tik.ee.ethz.ch> <4AEABCFB.70505@cisco.com> <978917B0-172E-4DB1-AE06-03B9A107F446@informatik.uni-erlangen.de> <4AF1419F.2000008@net.in.tum.de> <5FB55758-05FE-47AE-BE8B-9F4E48C1FC75@informatik.uni-erlangen.de> <4AFA21DA.4090200@cisco.com> <2AB3F5EF-DF15-4638-AB4D-9BC48C68858C@informatik.uni-erlangen.de> To: Tobias Limmer X-Mailer: Apple Mail (2.1076) Cc: ipfix@ietf.org Subject: Re: [IPFIX] Fwd: I-D ACTION:draft-ietf-ipfix-export-per-sctp-stream-04.txt X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Nov 2009 15:24:50 -0000 greetings Tobi, Benoit, all, Template and Options Template aren't disjoint sets, and are not =20 defined ambiguously. An Options Template is essentially a subclass of =20= Template. There's simply no abstract superclass by which we can refer =20= to "Template but not Options Template" as separate from "Template =20 including Options Template". So introducing this language here risks =20 confusing the point more, I think. Suggest instead "Note that in this document, "'(Options) Template' is =20= used in this document to refer to Templates and Options Templates." Regards, Brian On Nov 12, 2009, at 4:17 PM, Tobias Limmer wrote: > Hi Benoit, > > On 11.11.2009, at 03:30, Benoit Claise wrote: >>>> This is a flaw of IPFIX terminology. >>>> >>>> In the text, we tried to consistently use "(Options) Template" if =20= >>>> we talk about both Options and non-Options Templates. The =20 >>>> sentence above is just about non-Options Templates. >>>> Not sure, how we can make this more comprehensible. Maybe a note =20= >>>> in the terminology section? >>> >>> Yes, I agree, as you are using this terminology in the whole =20 >>> document. >> I'm not sure what is the agreement, and if we should add something =20= >> in the terminology. >> If yes, what do you suggest? > > Maybe something like: > > Term Template has been ambiguously defined in [RFC5101]. In this =20 > document, Template and Options Template describe disjoint sets, and =20= > Template is not used as generic term for Options Template. > > > Bye, > Tobi > > > -- > Dipl.-Inf. Tobias Limmer > Chair for Computer Networks and Communication Systems > Universit=E4t Erlangen-N=FCrnberg > Martensstr. 3, D-91058 Erlangen, Germany > Phone: +49-9131-8527931 Fax: +49-9131-8527409 > eMail: limmer .at. informatik.uni-erlangen.de > URL: http://www7.informatik.uni-erlangen.de/~limmer > > _______________________________________________ > IPFIX mailing list > IPFIX@ietf.org > https://www.ietf.org/mailman/listinfo/ipfix From bclaise@cisco.com Thu Nov 12 08:21:24 2009 Return-Path: X-Original-To: ipfix@core3.amsl.com Delivered-To: ipfix@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 52FE03A689B for ; Thu, 12 Nov 2009 08:21:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.499 X-Spam-Level: X-Spam-Status: No, score=-2.499 tagged_above=-999 required=5 tests=[AWL=0.100, 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 9v3Qa1+LTDM1 for ; Thu, 12 Nov 2009 08:21:23 -0800 (PST) Received: from av-tac-bru.cisco.com (weird-brew.cisco.com [144.254.15.118]) by core3.amsl.com (Postfix) with ESMTP id 039BF3A6A6C for ; Thu, 12 Nov 2009 08:21:22 -0800 (PST) X-TACSUNS: Virus Scanned Received: from strange-brew.cisco.com (localhost.cisco.com [127.0.0.1]) by av-tac-bru.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id nACFX34B007666; Thu, 12 Nov 2009 16:33:04 +0100 (CET) Received: from [10.70.230.251] (tky-vpn-client-230-251.cisco.com [10.70.230.251]) by strange-brew.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id nACFX1Wq014524; Thu, 12 Nov 2009 16:33:02 +0100 (CET) Message-ID: <4AFC2AAC.9000109@cisco.com> Date: Fri, 13 Nov 2009 00:33:00 +0900 From: Benoit Claise User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Brian Trammell References: <7A07131A-78E8-44DA-85A7-FF7D839A6AA8@tik.ee.ethz.ch> <4AEABCFB.70505@cisco.com> <978917B0-172E-4DB1-AE06-03B9A107F446@informatik.uni-erlangen.de> <4AF1419F.2000008@net.in.tum.de> <5FB55758-05FE-47AE-BE8B-9F4E48C1FC75@informatik.uni-erlangen.de> <4AFA21DA.4090200@cisco.com> <2AB3F5EF-DF15-4638-AB4D-9BC48C68858C@informatik.uni-erlangen.de> <247849B0-55E5-49A8-B422-59E2DBE597B5@tik.ee.ethz.ch> In-Reply-To: <247849B0-55E5-49A8-B422-59E2DBE597B5@tik.ee.ethz.ch> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: Tobias Limmer , ipfix@ietf.org Subject: Re: [IPFIX] Fwd: I-D ACTION:draft-ietf-ipfix-export-per-sctp-stream-04.txt X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Nov 2009 16:21:24 -0000 Tobias, Brian, > greetings Tobi, Benoit, all, > > Template and Options Template aren't disjoint sets, and are not > defined ambiguously. An Options Template is essentially a subclass of > Template. There's simply no abstract superclass by which we can refer > to "Template but not Options Template" as separate from "Template > including Options Template". So introducing this language here risks > confusing the point more, I think. > > Suggest instead "Note that in this document, "'(Options) Template' is > used in this document to refer to Templates and Options Templates." I like what Brian proposal because, when I read "In this document, Template and Options Template describe disjoint sets, and Template is not used as generic term for Options Template.", it seems that there is something wrong with the terminology... and this is not the case. Brian's proposal is actually a clarification, which is always good! Regards, Benoit. > > Regards, > > Brian > > On Nov 12, 2009, at 4:17 PM, Tobias Limmer wrote: > >> Hi Benoit, >> >> On 11.11.2009, at 03:30, Benoit Claise wrote: >>>>> This is a flaw of IPFIX terminology. >>>>> >>>>> In the text, we tried to consistently use "(Options) Template" if >>>>> we talk about both Options and non-Options Templates. The sentence >>>>> above is just about non-Options Templates. >>>>> Not sure, how we can make this more comprehensible. Maybe a note >>>>> in the terminology section? >>>> >>>> Yes, I agree, as you are using this terminology in the whole document. >>> I'm not sure what is the agreement, and if we should add something >>> in the terminology. >>> If yes, what do you suggest? >> >> Maybe something like: >> >> Term Template has been ambiguously defined in [RFC5101]. In this >> document, Template and Options Template describe disjoint sets, and >> Template is not used as generic term for Options Template. >> >> >> Bye, >> Tobi >> >> >> -- >> Dipl.-Inf. Tobias Limmer >> Chair for Computer Networks and Communication Systems >> Universität Erlangen-Nürnberg >> Martensstr. 3, D-91058 Erlangen, Germany >> Phone: +49-9131-8527931 Fax: +49-9131-8527409 >> eMail: limmer .at. informatik.uni-erlangen.de >> URL: http://www7.informatik.uni-erlangen.de/~limmer >> >> _______________________________________________ >> IPFIX mailing list >> IPFIX@ietf.org >> https://www.ietf.org/mailman/listinfo/ipfix > From limmer@informatik.uni-erlangen.de Thu Nov 12 08:39:36 2009 Return-Path: X-Original-To: ipfix@core3.amsl.com Delivered-To: ipfix@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4AA5A3A6878 for ; Thu, 12 Nov 2009 08:39:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.739 X-Spam-Level: X-Spam-Status: No, score=-1.739 tagged_above=-999 required=5 tests=[AWL=0.510, 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 G94GbqaqQQZq for ; Thu, 12 Nov 2009 08:39:35 -0800 (PST) Received: from faui45.informatik.uni-erlangen.de (faui45.informatik.uni-erlangen.de [131.188.34.45]) by core3.amsl.com (Postfix) with ESMTP id 484F03A6860 for ; Thu, 12 Nov 2009 08:39:35 -0800 (PST) Received: from faui7as (faui7as.informatik.uni-erlangen.de [131.188.37.230]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by faui45.informatik.uni-erlangen.de (Postfix) with ESMTPS id 67F444B5F; Thu, 12 Nov 2009 17:40:03 +0100 (MET) Received: from faui7ma3.informatik.uni-erlangen.de (faui7ma3.informatik.uni-erlangen.de [131.188.37.40]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by faui7as (Postfix) with ESMTPSA id 3DBE1438035; Thu, 12 Nov 2009 17:40:03 +0100 (CET) From: Tobias Limmer To: Benoit Claise In-Reply-To: <4AFC2AAC.9000109@cisco.com> References: <7A07131A-78E8-44DA-85A7-FF7D839A6AA8@tik.ee.ethz.ch> <4AEABCFB.70505@cisco.com> <978917B0-172E-4DB1-AE06-03B9A107F446@informatik.uni-erlangen.de> <4AF1419F.2000008@net.in.tum.de> <5FB55758-05FE-47AE-BE8B-9F4E48C1FC75@informatik.uni-erlangen.de> <4AFA21DA.4090200@cisco.com> <2AB3F5EF-DF15-4638-AB4D-9BC48C68858C@informatik.uni-erlangen.de> <247849B0-55E5-49A8-B422-59E2DBE597B5@tik.ee.ethz.ch> <4AFC2AAC.9000109@cisco.com> Message-Id: 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: Thu, 12 Nov 2009 17:40:03 +0100 X-Mailer: Apple Mail (2.936) Cc: ipfix@ietf.org Subject: Re: [IPFIX] Fwd: I-D ACTION:draft-ietf-ipfix-export-per-sctp-stream-04.txt X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Nov 2009 16:39:36 -0000 Benoit, Brian, On 12.11.2009, at 16:33, Benoit Claise wrote: >> Template and Options Template aren't disjoint sets, and are not =20 >> defined ambiguously. An Options Template is essentially a subclass =20= >> of Template. There's simply no abstract superclass by which we can =20= >> refer to "Template but not Options Template" as separate from =20 >> "Template including Options Template". So introducing this language =20= >> here risks confusing the point more, I think. >> >> Suggest instead "Note that in this document, "'(Options) Template' =20= >> is used in this document to refer to Templates and Options =20 >> Templates." > I like what Brian proposal because, when I read "In this document, =20 > Template and Options Template describe disjoint sets, and Template =20 > is not used as generic term for Options Template.", it seems that =20 > there is something wrong with the terminology... and this is not the =20= > case. > Brian's proposal is actually a clarification, which is always good! Hm. Brian's proposal is very vague about my main issue, that Options =20 Template is not a subclass of Template. In my opinion, this is a small =20= ambiguity in in the terminology of rfc5101, and I wanted to explicitly =20= clarify this problem. But maybe it's just my way of thinking that's getting in the way here? Bye, Tobi -- Dipl.-Inf. Tobias Limmer Chair for Computer Networks and Communication Systems Universit=E4t Erlangen-N=FCrnberg Martensstr. 3, D-91058 Erlangen, Germany Phone: +49-9131-8527931 Fax: +49-9131-8527409 eMail: limmer .at. informatik.uni-erlangen.de URL: http://www7.informatik.uni-erlangen.de/~limmer From muenz@net.in.tum.de Thu Nov 12 08:47:00 2009 Return-Path: X-Original-To: ipfix@core3.amsl.com Delivered-To: ipfix@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9F16C3A6A7A for ; Thu, 12 Nov 2009 08:47:00 -0800 (PST) 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.141, 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 PJPCEbIn8tAz for ; Thu, 12 Nov 2009 08:46:59 -0800 (PST) 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 F06C13A68BB for ; Thu, 12 Nov 2009 08:46:58 -0800 (PST) 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 4791C48324; Thu, 12 Nov 2009 17:47:26 +0100 (CET) Received: from [131.159.20.108] (repulse.net.in.tum.de [131.159.20.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by phoenix.net.informatik.tu-muenchen.de (Postfix) with ESMTP id 3AD1F44E4; Thu, 12 Nov 2009 17:47:26 +0100 (CET) Message-ID: <4AFC3C66.3010104@net.in.tum.de> Date: Thu, 12 Nov 2009 17:48:38 +0100 From: Gerhard Muenz User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Tobias Limmer References: <7A07131A-78E8-44DA-85A7-FF7D839A6AA8@tik.ee.ethz.ch> <4AEABCFB.70505@cisco.com> <978917B0-172E-4DB1-AE06-03B9A107F446@informatik.uni-erlangen.de> <4AF1419F.2000008@net.in.tum.de> <5FB55758-05FE-47AE-BE8B-9F4E48C1FC75@informatik.uni-erlangen.de> <4AFA21DA.4090200@cisco.com> <2AB3F5EF-DF15-4638-AB4D-9BC48C68858C@informatik.uni-erlangen.de> <247849B0-55E5-49A8-B422-59E2DBE597B5@tik.ee.ethz.ch> <4AFC2AAC.9000109@cisco.com> In-Reply-To: Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms090707060808010809090507" X-Virus-Scanned: ClamAV using ClamSMTP Cc: ipfix@ietf.org Subject: Re: [IPFIX] Fwd: I-D ACTION:draft-ietf-ipfix-export-per-sctp-stream-04.txt X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Nov 2009 16:47:00 -0000 This is a cryptographically signed message in MIME format. --------------ms090707060808010809090507 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable Hi all, The original issue was this one: >>> 4.2. Template Management: >>> "Any Data Sets associated with a Template Record MUST be sent on >>> the same SCTP stream on which the Template Record was sent." >>> According to rfc5101, an Options Template Record is a Template >>> Record. Later in the same section you specify: "When the Options >>> Template and associated Data Records are sent in different SCTP >>> streams, [...]". >>> Isn't this a contradiction, or am I missing something here? Even if we can add Brian's sentence to the terminology section, this=20 does not help here. So, in addition to Brian's proposal, we could replace "Template Record"=20 by "non-Option Template Record" in the first sentence. Of course, the=20 sentence becomes messy :( Regards, Gerhard Tobias Limmer wrote: > Benoit, Brian, >=20 > On 12.11.2009, at 16:33, Benoit Claise wrote: >>> Template and Options Template aren't disjoint sets, and are not =20 >>> defined ambiguously. An Options Template is essentially a subclass =20 >>> of Template. There's simply no abstract superclass by which we can =20 >>> refer to "Template but not Options Template" as separate from =20 >>> "Template including Options Template". So introducing this language = >>> here risks confusing the point more, I think. >>> >>> Suggest instead "Note that in this document, "'(Options) Template' =20 >>> is used in this document to refer to Templates and Options =20 >>> Templates." >> I like what Brian proposal because, when I read "In this document, =20 >> Template and Options Template describe disjoint sets, and Template =20 >> is not used as generic term for Options Template.", it seems that =20 >> there is something wrong with the terminology... and this is not the = >> case. >> Brian's proposal is actually a clarification, which is always good! >=20 > Hm. Brian's proposal is very vague about my main issue, that Options =20 > Template is not a subclass of Template. In my opinion, this is a small = =20 > ambiguity in in the terminology of rfc5101, and I wanted to explicitly = =20 > clarify this problem. >=20 > But maybe it's just my way of thinking that's getting in the way here? >=20 > Bye, > Tobi >=20 > -- > Dipl.-Inf. Tobias Limmer > Chair for Computer Networks and Communication Systems > Universit=E4t Erlangen-N=FCrnberg > Martensstr. 3, D-91058 Erlangen, Germany > Phone: +49-9131-8527931 Fax: +49-9131-8527409 > eMail: limmer .at. informatik.uni-erlangen.de > URL: http://www7.informatik.uni-erlangen.de/~limmer >=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 --------------ms090707060808010809090507 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 SIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMDkxMTEyMTY0ODM4WjAjBgkqhkiG9w0BCQQxFgQU uWC3L6QA6NXT4sRtCxmsmTUz1cowXwYJKoZIhvcNAQkPMVIwUDALBglghkgBZQMEAQIwCgYI KoZIhvcNAwcwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqG SIb3DQMCAgEoMIGFBgkrBgEEAYI3EAQxeDB2MGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxU aGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwg RnJlZW1haWwgSXNzdWluZyBDQQIQKsXq3Tdl1UZFGbLpOSCnTzCBhwYLKoZIhvcNAQkQAgsx eKB2MGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBM dGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQQIQKsXq 3Tdl1UZFGbLpOSCnTzANBgkqhkiG9w0BAQEFAASCAQB0odHY6zvLuQD6Tsehxi4cgDYi4TFD kTrN5I24ww00Ctcy5hbD+rUoTMB1rPDLyRlsRU/9WigX5ozNYfLXrrayK7vl3iwOB47EO2YG MNAddkBlijsNKUtRpenSeJ6D9Oli7CJEc9s63X57IxS6l9OtSIBlZbVvEqDuXl3i+J3VrD4x OD4iJV6x5FY93AQ8HvxYKAnzmXeXl0ISqxuo3Bncq/fpZEtHLo02oN+wZZowg0AghAVSkHCX L00o0CBBbScTCWJ6flQ0+UIYKg6NYsVPlXYX2KwrrtYIYar/zezNedLDYxK9/OACEHbXfc0g B3lsYq2+35E8avaMLi4XeLAwAAAAAAAA --------------ms090707060808010809090507-- From limmer@informatik.uni-erlangen.de Thu Nov 12 09:34:51 2009 Return-Path: X-Original-To: ipfix@core3.amsl.com Delivered-To: ipfix@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2ED0F3A697F for ; Thu, 12 Nov 2009 09:34:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.841 X-Spam-Level: X-Spam-Status: No, score=-1.841 tagged_above=-999 required=5 tests=[AWL=0.408, 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 y4nnb7UH6ZBg for ; Thu, 12 Nov 2009 09:34:50 -0800 (PST) Received: from faui45.informatik.uni-erlangen.de (faui45.informatik.uni-erlangen.de [131.188.34.45]) by core3.amsl.com (Postfix) with ESMTP id 2FD1C3A688B for ; Thu, 12 Nov 2009 09:34:49 -0800 (PST) Received: from faui7as (faui7as.informatik.uni-erlangen.de [131.188.37.230]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by faui45.informatik.uni-erlangen.de (Postfix) with ESMTPS id AFA1849C7; Thu, 12 Nov 2009 18:35:17 +0100 (MET) Received: from faui7ma3.informatik.uni-erlangen.de (faui7ma3.informatik.uni-erlangen.de [131.188.37.40]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by faui7as (Postfix) with ESMTPSA id 898534382F2; Thu, 12 Nov 2009 18:35:17 +0100 (CET) From: Tobias Limmer To: Tharaneedharan Vilwanathan In-Reply-To: References: Message-Id: <77ADE572-13BF-49B2-A44A-EB7D13BB89B0@informatik.uni-erlangen.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed; delsp=yes Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Apple Message framework v936) Date: Thu, 12 Nov 2009 18:35:17 +0100 X-Mailer: Apple Mail (2.936) Cc: ipfix@ietf.org Subject: Re: [IPFIX] Sample IPFIX file X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Nov 2009 17:34:51 -0000 Hi Dharani, actually I would be interested in some sample files, too. We =20 implemented a module for Vermont that writes IPFIX records to files =20 according to rfc5655, but were not able to compare it with other =20 implementations. A sample file can be found here: This is an anonymized dump coming from our laboratory. bye, Tobi On 10.11.2009, at 23:59, Tharaneedharan Vilwanathan wrote: > Hi All, > > I am currently going through IPFIX file format spec ( > http://tools.ietf.org/html/rfc5655). I am wondering if I there are =20 > sample > IPFIX files that I can play with. Any pointers? > > Thanks in advance. > > Regards > dharani > _______________________________________________ > IPFIX mailing list > IPFIX@ietf.org > https://www.ietf.org/mailman/listinfo/ipfix -- Dipl.-Inf. Tobias Limmer Chair for Computer Networks and Communication Systems Universit=E4t Erlangen-N=FCrnberg Martensstr. 3, D-91058 Erlangen, Germany Phone: +49-9131-8527931 Fax: +49-9131-8527409 eMail: limmer .at. informatik.uni-erlangen.de URL: http://www7.informatik.uni-erlangen.de/~limmer From trammell@tik.ee.ethz.ch Fri Nov 13 06:10: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 71A153A687B for ; Fri, 13 Nov 2009 06:10:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=0.000, 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 XEBg8TxwdC52 for ; Fri, 13 Nov 2009 06:10:13 -0800 (PST) Received: from smtp.ee.ethz.ch (smtp.ee.ethz.ch [129.132.2.219]) by core3.amsl.com (Postfix) with ESMTP id 9A3853A6844 for ; Fri, 13 Nov 2009 06:10:13 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by smtp.ee.ethz.ch (Postfix) with ESMTP id 91B6CD9451; Fri, 13 Nov 2009 15:10:41 +0100 (MET) X-Virus-Scanned: by amavisd-new on smtp.ee.ethz.ch Received: from smtp.ee.ethz.ch ([127.0.0.1]) by localhost (.ee.ethz.ch [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 8-tR7BbO9U6o; Fri, 13 Nov 2009 15:10:41 +0100 (MET) Received: from pb-10072.ethz.ch (pb-10072.ethz.ch [82.130.103.195]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: briant) by smtp.ee.ethz.ch (Postfix) with ESMTP id 4A4B4D9455; Fri, 13 Nov 2009 15:10:41 +0100 (MET) Mime-Version: 1.0 (Apple Message framework v1076) Content-Type: text/plain; charset=iso-8859-1; format=flowed; delsp=yes From: Brian Trammell In-Reply-To: <4AFC3C66.3010104@net.in.tum.de> Date: Fri, 13 Nov 2009 15:10:40 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <55F57539-1938-40CD-9EE3-D09BE0BD627B@tik.ee.ethz.ch> References: <7A07131A-78E8-44DA-85A7-FF7D839A6AA8@tik.ee.ethz.ch> <4AEABCFB.70505@cisco.com> <978917B0-172E-4DB1-AE06-03B9A107F446@informatik.uni-erlangen.de> <4AF1419F.2000008@net.in.tum.de> <5FB55758-05FE-47AE-BE8B-9F4E48C1FC75@informatik.uni-erlangen.de> <4AFA21DA.4090200@cisco.com> <2AB3F5EF-DF15-4638-AB4D-9BC48C68858C@informatik.uni-erlangen.de> <247849B0-55E5-49A8-B422-59E2DBE597B5@tik.ee.ethz.ch> <4AFC2AAC.9000109@cisco.com> <4AFC3C66.3010104@net.in.tum.de> To: Gerhard Muenz X-Mailer: Apple Mail (2.1076) Cc: Tobias Limmer , ipfix@ietf.org Subject: Re: [IPFIX] Fwd: I-D ACTION:draft-ietf-ipfix-export-per-sctp-stream-04.txt X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Nov 2009 14:10:15 -0000 How about, to maximize clarity: Terminology: Note that in this document, '(Options) Template' is used in this =20 document to refer to Templates and Options Templates. Unless otherwise =20= specified, 'Template' alone refers to Templates exclusive of Options =20 Templates. 4.2 paragraph 3: OLD: Any Data Sets associated with a Template Record MUST be sent on the =20 same SCTP stream on which the Template Record was sent. NEW: Data Sets associated with a Template Record MUST be sent on the same =20 SCTP stream on which the Template Record was sent. Options MAY be sent =20= on SCTP streams other than that on which the Options Template Record =20 associated with them was sent. Regards, Brian On Nov 12, 2009, at 5:48 PM, Gerhard Muenz wrote: > > Hi all, > > The original issue was this one: > > >>> 4.2. Template Management: > >>> "Any Data Sets associated with a Template Record MUST be sent on > >>> the same SCTP stream on which the Template Record was sent." > >>> According to rfc5101, an Options Template Record is a Template > >>> Record. Later in the same section you specify: "When the Options > >>> Template and associated Data Records are sent in different SCTP > >>> streams, [...]". > >>> Isn't this a contradiction, or am I missing something here? > > Even if we can add Brian's sentence to the terminology section, this =20= > does not help here. > > So, in addition to Brian's proposal, we could replace "Template =20 > Record" by "non-Option Template Record" in the first sentence. Of =20 > course, the sentence becomes messy :( > > Regards, > Gerhard > > > > Tobias Limmer wrote: >> Benoit, Brian, >> On 12.11.2009, at 16:33, Benoit Claise wrote: >>>> Template and Options Template aren't disjoint sets, and are not =20= >>>> defined ambiguously. An Options Template is essentially a =20 >>>> subclass of Template. There's simply no abstract superclass by =20 >>>> which we can refer to "Template but not Options Template" as =20 >>>> separate from "Template including Options Template". So =20 >>>> introducing this language here risks confusing the point more, I =20= >>>> think. >>>> >>>> Suggest instead "Note that in this document, "'(Options) =20 >>>> Template' is used in this document to refer to Templates and =20 >>>> Options Templates." >>> I like what Brian proposal because, when I read "In this =20 >>> document, Template and Options Template describe disjoint sets, =20 >>> and Template is not used as generic term for Options Template.", =20= >>> it seems that there is something wrong with the terminology... =20 >>> and this is not the case. >>> Brian's proposal is actually a clarification, which is always good! >> Hm. Brian's proposal is very vague about my main issue, that =20 >> Options Template is not a subclass of Template. In my opinion, =20 >> this is a small ambiguity in in the terminology of rfc5101, and I =20= >> wanted to explicitly clarify this problem. >> But maybe it's just my way of thinking that's getting in the way =20 >> here? >> Bye, >> Tobi >> -- >> Dipl.-Inf. Tobias Limmer >> Chair for Computer Networks and Communication Systems >> Universit=E4t Erlangen-N=FCrnberg >> Martensstr. 3, D-91058 Erlangen, Germany >> Phone: +49-9131-8527931 Fax: +49-9131-8527409 >> eMail: limmer .at. informatik.uni-erlangen.de >> URL: http://www7.informatik.uni-erlangen.de/~limmer >> _______________________________________________ >> 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 bclaise@cisco.com Fri Nov 13 06:15:24 2009 Return-Path: X-Original-To: ipfix@core3.amsl.com Delivered-To: ipfix@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F3DA23A683C for ; Fri, 13 Nov 2009 06:15:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.482 X-Spam-Level: X-Spam-Status: No, score=-2.482 tagged_above=-999 required=5 tests=[AWL=0.073, BAYES_00=-2.599, DATE_IN_PAST_03_06=0.044] 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 aca3gWqkpjFE for ; Fri, 13 Nov 2009 06:15:23 -0800 (PST) Received: from av-tac-bru.cisco.com (weird-brew.cisco.com [144.254.15.118]) by core3.amsl.com (Postfix) with ESMTP id 0FA823A6774 for ; Fri, 13 Nov 2009 06:15:22 -0800 (PST) X-TACSUNS: Virus Scanned Received: from strange-brew.cisco.com (localhost.cisco.com [127.0.0.1]) by av-tac-bru.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id nADE4aL3019154; Fri, 13 Nov 2009 15:04:36 +0100 (CET) Received: from [10.70.230.2] (tky-vpn-client-230-2.cisco.com [10.70.230.2]) by strange-brew.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id nADE4WPN026097; Fri, 13 Nov 2009 15:04:33 +0100 (CET) Message-ID: <4AFD3756.20808@cisco.com> Date: Fri, 13 Nov 2009 19:39:18 +0900 From: Benoit Claise User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Michael Tuexen , Randall Stewart References: <7A07131A-78E8-44DA-85A7-FF7D839A6AA8@tik.ee.ethz.ch> <4AEABCFB.70505@cisco.com> <978917B0-172E-4DB1-AE06-03B9A107F446@informatik.uni-erlangen.de> <4AF1419F.2000008@net.in.tum.de> In-Reply-To: <4AF1419F.2000008@net.in.tum.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Tobias Limmer , ipfix@ietf.org Subject: Re: [IPFIX] Fwd: I-D ACTION:draft-ietf-ipfix-export-per-sctp-stream-04.txt X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Nov 2009 14:15:24 -0000 Randy, Michael, As SCTP experts, are you able to help on this one below. Thanks and regards, Benoit. > > >> 4.5. The Collecting Process's Side: >> "3. A Data Record is received unreliably although it is expected to >> be sent reliably (due to a previously received Data Record >> associated with the Data Record Reliability Options Template)." >> >> Is it possible for the receiving side of a SCTP connection to >> determine which SCTP messages were sent unreliably? I did not find >> any indication of that in rfc3758. The receiving side only knows >> if complete messages or fragments are skipped. > > I think you are right. We need to check. > > Regards, > Gerhard From bclaise@cisco.com Fri Nov 13 06:24: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 3F4023A68B3 for ; Fri, 13 Nov 2009 06:24:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.484 X-Spam-Level: X-Spam-Status: No, score=-2.484 tagged_above=-999 required=5 tests=[AWL=0.071, BAYES_00=-2.599, DATE_IN_PAST_03_06=0.044] 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 rv-8zuMGnOaZ for ; Fri, 13 Nov 2009 06:24:14 -0800 (PST) Received: from av-tac-bru.cisco.com (weird-brew.cisco.com [144.254.15.118]) by core3.amsl.com (Postfix) with ESMTP id 28CD63A688D for ; Fri, 13 Nov 2009 06:24:14 -0800 (PST) X-TACSUNS: Virus Scanned Received: from strange-brew.cisco.com (localhost.cisco.com [127.0.0.1]) by av-tac-bru.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id nADE4Qgb019092; Fri, 13 Nov 2009 15:04:26 +0100 (CET) Received: from [10.70.230.2] (tky-vpn-client-230-2.cisco.com [10.70.230.2]) by strange-brew.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id nADE4OvR025980; Fri, 13 Nov 2009 15:04:25 +0100 (CET) Message-ID: <4AFD31DF.70204@cisco.com> Date: Fri, 13 Nov 2009 19:15:59 +0900 From: Benoit Claise User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Brian Trammell References: <7A07131A-78E8-44DA-85A7-FF7D839A6AA8@tik.ee.ethz.ch> <4AEABCFB.70505@cisco.com> In-Reply-To: <4AEABCFB.70505@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: ipfix@ietf.org Subject: Re: [IPFIX] Fwd: I-D ACTION:draft-ietf-ipfix-export-per-sctp-stream-04.txt X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Nov 2009 14:24:15 -0000 Brian, >> >> >> A suggestion not strictly limited to applicability: >> >> >> 4.1 dataRecordsReliability Information Element >> >> [This information element is specified to only apply to Template ID >> scopes. Could it not also be scoped to other things (SCTP Stream ID, >> for instance) for a generalization of the approach? suggest the >> following:] >> >> OLD: >> dataRecordsReliability >> >> Description: >> The Data Records reliability associated with this >> Template ID. The true value means that the Data Records >> are sent reliably, while the false value means that the >> Data Records are not sent reliably. >> >> NEW: >> dataRecordsReliability >> >> Description: >> >> The Data Records reliability associated with the elements in >> the Options Template scope, usually a templateID. A true value >> means that the Data Records are sent reliably, while a false >> value >> means that the Data Records are not sent reliably. > Great suggestion. Actually, you took the dataRecordsReliability definition from draft-ietf-ipfix-export-per-sctp-stream-03 and not from draft-ietf-ipfix-export-per-sctp-stream-04. This is the change I applied. OLD: 4.1. New Information Element dataRecordsReliability Description: The reliability of the export of Data Records, within this SCTP stream, for all Data Records associated with a given Template ID. A value of 'true' means that the Exporting Process MUST send any Data Records associated with the Template ID reliably within this SCTP stream. A value of 'false' means that the Exporting Process MAY send any Data Records associated with the Template ID unreliably within this SCTP stream. NEW: 4.1. New Information Element dataRecordsReliability Description: The reliability of the export of Data Records, within this SCTP stream, for the element(s) in the Options Template scope, usually a templateID. A value of 'true' means that the Exporting Process MUST send any Data Records associated with the Template ID reliably within this SCTP stream. A value of 'false' means that the Exporting Process MAY send any Data Records associated with the Template ID unreliably within this SCTP stream. Regards, Benoit. From trammell@tik.ee.ethz.ch Fri Nov 13 06:28:51 2009 Return-Path: X-Original-To: ipfix@core3.amsl.com Delivered-To: ipfix@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BCF613A689E for ; Fri, 13 Nov 2009 06:28:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=0.000, 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 cl5dytUhZEBk for ; Fri, 13 Nov 2009 06:28:51 -0800 (PST) Received: from smtp.ee.ethz.ch (smtp.ee.ethz.ch [129.132.2.219]) by core3.amsl.com (Postfix) with ESMTP id A72443A688D for ; Fri, 13 Nov 2009 06:28:50 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by smtp.ee.ethz.ch (Postfix) with ESMTP id 3332ED94AA; Fri, 13 Nov 2009 15:29:19 +0100 (MET) X-Virus-Scanned: by amavisd-new on smtp.ee.ethz.ch Received: from smtp.ee.ethz.ch ([127.0.0.1]) by localhost (.ee.ethz.ch [127.0.0.1]) (amavisd-new, port 10024) with LMTP id HXArZmlkMfRG; Fri, 13 Nov 2009 15:29:19 +0100 (MET) Received: from pb-10072.ethz.ch (pb-10072.ethz.ch [82.130.103.195]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: briant) by smtp.ee.ethz.ch (Postfix) with ESMTP id EE9B4D9458; Fri, 13 Nov 2009 15:29:18 +0100 (MET) Mime-Version: 1.0 (Apple Message framework v1076) Content-Type: text/plain; charset=us-ascii; format=flowed; delsp=yes From: Brian Trammell In-Reply-To: <4AFD31DF.70204@cisco.com> Date: Fri, 13 Nov 2009 15:29:18 +0100 Content-Transfer-Encoding: 7bit Message-Id: <72EB0889-B9E0-4FE7-96F5-2A24CFE786B4@tik.ee.ethz.ch> References: <7A07131A-78E8-44DA-85A7-FF7D839A6AA8@tik.ee.ethz.ch> <4AEABCFB.70505@cisco.com> <4AFD31DF.70204@cisco.com> To: Benoit Claise X-Mailer: Apple Mail (2.1076) Cc: ipfix@ietf.org Subject: Re: [IPFIX] Fwd: I-D ACTION:draft-ietf-ipfix-export-per-sctp-stream-04.txt X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Nov 2009 14:28:51 -0000 hi Benoit, This change looks good. Best regards, Brian On Nov 13, 2009, at 11:15 AM, Benoit Claise wrote: > Brian, >>> >>> >>> A suggestion not strictly limited to applicability: >>> >>> >>> 4.1 dataRecordsReliability Information Element >>> >>> [This information element is specified to only apply to Template >>> ID scopes. Could it not also be scoped to other things (SCTP >>> Stream ID, for instance) for a generalization of the approach? >>> suggest the following:] >>> >>> OLD: >>> dataRecordsReliability >>> >>> Description: >>> The Data Records reliability associated with this >>> Template ID. The true value means that the Data >>> Records >>> are sent reliably, while the false value means that the >>> Data Records are not sent reliably. >>> >>> NEW: >>> dataRecordsReliability >>> >>> Description: >>> >>> The Data Records reliability associated with the elements in >>> the Options Template scope, usually a templateID. A true value >>> means that the Data Records are sent reliably, while a false >>> value >>> means that the Data Records are not sent reliably. >> Great suggestion. > Actually, you took the dataRecordsReliability definition from draft- > ietf-ipfix-export-per-sctp-stream-03 > and not from draft-ietf-ipfix-export-per-sctp-stream-04. > This is the change I applied. > > OLD: > 4.1. New Information Element > > dataRecordsReliability > Description: > The reliability of the export of Data Records, within > this SCTP stream, for all Data Records associated with a > given Template ID. A value of 'true' means that the > Exporting Process MUST send any Data Records associated > with the Template ID reliably within this SCTP > stream. A value of 'false' means that the Exporting > Process MAY > send any Data Records associated with the Template ID > unreliably within this SCTP stream. > > > NEW: > 4.1. New Information Element > > dataRecordsReliability > Description: > The reliability of the export of Data Records, within > this SCTP stream, for the element(s) in the Options > Template > scope, usually a templateID. A value of 'true' means > that the > Exporting Process MUST send any Data Records associated > with the Template ID reliably within this SCTP > stream. A value of 'false' means that the Exporting > Process MAY > send any Data Records associated with the Template ID > unreliably within this SCTP stream. > Regards, Benoit. From muenz@net.in.tum.de Sat Nov 14 14:30:35 2009 Return-Path: X-Original-To: ipfix@core3.amsl.com Delivered-To: ipfix@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 074BC3A67EC for ; Sat, 14 Nov 2009 14:30:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.649 X-Spam-Level: X-Spam-Status: No, score=-1.649 tagged_above=-999 required=5 tests=[BAYES_50=0.001, GB_I_LETTER=-2, 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 mibNWDOOi5tx for ; Sat, 14 Nov 2009 14:30:31 -0800 (PST) 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 AA7C13A657C for ; Sat, 14 Nov 2009 14:30:30 -0800 (PST) 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 B03DB48324; Sat, 14 Nov 2009 23:30:59 +0100 (CET) Received: from [192.168.128.99] (ppp-82-135-94-213.dynamic.mnet-online.de [82.135.94.213]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by phoenix.net.informatik.tu-muenchen.de (Postfix) with ESMTP id 356DB44E4; Sat, 14 Nov 2009 23:30:58 +0100 (CET) Message-ID: <4AFF2FD0.7020704@net.in.tum.de> Date: Sat, 14 Nov 2009 23:31:44 +0100 From: Gerhard Muenz User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Atsushi Kobayashi References: <4AEAB7D3.9090608@net.in.tum.de> <20091110090506.659C.17391CF2@nttv6.net> In-Reply-To: <20091110090506.659C.17391CF2@nttv6.net> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Virus-Scanned: ClamAV using ClamSMTP Cc: IETF IPFIX Working Group Subject: Re: [IPFIX] WG last call on draft-ietf-ipfix-mediators-problem-statement-06 X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 14 Nov 2009 22:30:35 -0000 Hi Atsushi, comments inline. Regards, Gerhard Atsushi Kobayashi wrote: > Hi Gerhard, > > Thank you for your feedback. > I didn't have much time to check in detail your feedbacks. Sorry for > late reply. My answers are in-line. > > On Fri, 30 Oct 2009 10:54:27 +0100 > Gerhard Muenz wrote: > >> Hi, >> >> Here is my review of draft-ietf-ipfix-mediators-problem-statement-06. >> >> The main content is ok. Some parts of the text still need revision. >> >> I'm not sure if we need to define Mediator types like IPFIX Proxy, IPFIX >> Concentrator, IPFIX Distributor, IPFIX Masquerading Proxy in the >> terminology section. Why not just talk about IPFIX Mediators? >> > > IMO, I prefer these terms. but, I don't adhere my opinion. I will try to > remove the Mediator types. > >> Regards, >> Gerhard >> >> >> >>> Abstract >>> >>> Flow-based measurement is a popular method for various network >>> monitoring usages. The sharing of flow-based information for >>> monitoring applications having different requirements raises some >>> open issues in terms of measurement system scalability, flow-based >>> measurement flexibility, and export reliability that IPFIX Mediation >>> may help resolve. This document describes the IPFIX Mediation >>> applicability examples, along with some problems that network >>> administrators have been facing. >> Shouldn't it be the other way round: >> - first problems >> - then applicability examples >> ? >> > > I will change it as follows. Is it OK? > > This document describes some problems related to > flow-based measurement that network administrators have been facing, > and then describes IPFIX Mediation applicability examples along with > the problems. ok >>> 1. Introduction >>> >>> One advantage of Flow-based measurement results from easily offering >>> the traffic monitoring of a huge amount of traffic. While the usage >>> is applied to any networks and to multiple measurement applications, >>> network administrators need to optimize the resource of metering >>> devices and of multiple measurement applications. IP traffic growth >>> and a wide variety of measurement application make the optimization >>> further difficult. To achieve system optimization, an intermediate >>> device can generally be applied to the system platform. >> Sorry, I can only guess what this paragraph is supposed to say. >> Please rewrite in a better understandable and readable way. >> >> BTW, I would be careful with terms like "optimize" and "optimization". >> > > I will change it as follows. Could you please rewrite it by your word, > if not fine. As I do not know what you want to say, it is difficult for me to rewrite it in my own words. > > 1. Introduction > > One advantage of Flow-based measurement results from easily offering > the traffic monitoring of a huge amount of traffic. While the usage > is applied to any networks and to multiple measurement applications, You could start like this: An advantage of Flow-based measurement is that it allows monitoring hugh amounts of traffic observed at distributed observation points. Flow-based measurement may serve various purposes and applications with very different requirements. > network administrators need to adjust some parameters of metering > devices and of multiple measurement applications to these resources. I do not understand this semi-phrase. What do you mean by "to these resources"? > IP traffic growth and a wide variety of measurement application make > the adjustment further difficult. To make a measurement system Why is it more difficult to adjust parameters in the presence of IP traffic growth? In the first sentence, you write that Flow-based measurement can monitor huge amounts of traffic, so traffic growth should not be a problem. > flexible and scalable, an intermediate device can generally be > applied to the system platform. Maybe you can discuss and clarify this paragraph with your co-authors. I can hardly guess what the reasoning is supposed to be. > >>> The IPFIX requirements defined in [RFC3917] mention examples of >>> intermediate devices, such as IPFIX Proxies or Concentrators, there >> missing conjunction, such as "but", "yet", or something like that >> >> The term "intermediate" or "intermediate device" does not appear in >> RFC3917. So, explain why you call these devices like this. >> (For example, because they are located between Exporters and Collectors.) > > Is it OK? > > The IPFIX requirements defined in [RFC3917] mention examples of > intermediate devices located between Exporters and Collectors, such > as IPFIX proxies or concentrators. But, there are no documents > defining a generalized concept for such intermediate devices. This ok. > >>> are no documents defining a generalized concept for such intermediate >>> devices. This document addresses that issue by defining IPFIX >>> Mediation, a generalized intermediate device concept for IPFIX, and >>> examining in detail the motivations behind its application. >>> >>> This document is structured as follows: section 2 describes the >>> terminology used in this document, section 3 gives an IPFIX/PSAMP >>> document overview, section 4 introduces general problems related to >>> flow-based measurement, section 5 describes some applicability >>> examples where IPFIX Mediations would be beneficial, and, finally, >>> section 6 describes some problems an IPFIX Mediation implementation >>> might face. >> >>> 2. Terminology and Definitions >>> >>> The IPFIX-specific and PSAMP-specific terminology used in this >>> document is defined in [RFC5101] and [RFC5476], respectively. In >>> this document, as in [RFC5101] and [RFC5476], the first letter of >>> each IPFIX-specific and PSAMP-specific term is capitalized along with >>> the IPFIX Mediation-specific term defined here. >>> >>> In this document, we use the generic term "record stream" to denote a >> I would not call "record stream" a "term" unless it appears in the list >> below with capitalized first letter. >> >>> set of flow- or packet-based data records with their additional >> I would not say that the records are flow-based or packet-based. They >> contain flow or packet information. >> > > Actually, I am not sure how to say that. > It seems hard to include "record stream" in capitalized terms, because > it covers everything, such as IPFIX Flow Record, PSAMP Packet Record, NF > flow record, and something else. Could you put your suggestion? > > Is the following paragraph fine? > > In this document, we use "record stream" to denote a set of flow- or > packet-based information with their additional information that flows > from data sources, whether encoded in IPFIX protocol as IPFIX Data > Records, or non-IPFIX protocols. In IPFIX protocol, we use the > generic term Data Records for IPFIX Flow Records, PSAMP Packet > Reports, and Data Records defined by Options Templates, unless an > explicit distinction is required. What about: In this document, we call "record stream" a stream of records carrying flow- or packet-based information. The records may be encoded as IPFIX Data Records in any other format. >>> information that flows from data sources, whether encoded in IPFIX >>> protocol as IPFIX Data Records, or non-IPFIX protocols. In IPFIX >>> protocol, we use the generic term Data Records for IPFIX Flow >>> Records, PSAMP Packet Reports, and Data Records defined by Options >>> Templates, unless an explicit distinction is required. >> Do we need the last sentence? > > I think Yes. It indicates the usage of term Data Records to prevent > readers from confusing it with IPFIX Flow Record and PSAMP packet report. I think the contrary. This sentence may confuse the reader. "In IPFIX protocol" is wrong because the "PSAMP Packet Report" does not appear in RFC5101. Therefore, it seems that you redefine the term Data Record, also this is not what you want to do. If you really think that the sentence is necessary, maybe you like this: "Note that the term Data Records comprises IPFIX Flow Records, PSAMP Packet Reports, and Data Records defined by Options Templates." BTW: In IPFIX-CONFIG, I also use this term in the same way without providing any further explanation. >>> Original Exporter >>> >>> An Original Exporter is an IPFIX Device that hosts the Observation >>> Points where the metered IP packets are observed. >>> >>> IPFIX Mediation >>> >>> IPFIX Mediation is the manipulation and conversion of a record >>> stream for subsequent export using the IPFIX protocol. >>> >>> The following terms are used in this document to describe the >>> architectural entities used by IPFIX Mediation. >>> >>> Intermediate Process >>> >>> An Intermediate Process takes a record stream as its input from >>> Collecting Processes, Metering Processes, IPFIX File Readers, >>> other Intermediate Processes, or other record sources; performs >>> some transformations on this stream, based upon the content of >>> each record, states maintained across multiple records, or other >>> data sources; and passes the transformed record stream as its >>> output to Exporting Processes, IPFIX File Writers, or other >>> Intermediate Processes, in order to perform IPFIX Mediation. >>> Typically, an Intermediate Process is hosted by an IPFIX Mediator. >>> Alternatively, an Intermediate Process may be hosted by an >>> Original Exporter. >>> >>> IPFIX Mediator >>> >>> An IPFIX Mediator is an IPFIX Device that provides IPFIX Mediation >>> by receiving a record stream from some data sources, hosting one >>> or more Intermediate Processes to transform that stream, and >>> exporting the transformed record stream into IPFIX Messages via an >>> Exporting Process. In the common case, an IPFIX Mediator receives >>> a record stream from a Collecting Process, but it could also >>> receive a record stream from data sources not encoded using IPFIX, >>> e.g., in the case of conversion from the NetFlow V9 protocol >>> [RFC3954] to IPFIX protocol. >>> >>> Specific types of IPFIX Mediators are defined below. >>> >>> IPFIX Proxy >>> >>> An IPFIX Proxy is an IPFIX Mediator that converts a record stream >>> for the purpose of protocol conversion. >>> >>> IPFIX Concentrator >>> >>> An IPFIX Concentrator is an IPFIX Mediator that receives a record >>> stream from one or more Exporters and performs correlation, >>> aggregation, and/or modification. >>> >>> IPFIX Distributor >>> >>> An IPFIX Distributor is an IPFIX Mediator that receives a record >>> stream from one or more Exporters and exports each record to one >>> or more Collectors, deciding to which Collector(s) to export each >>> record depending on the decision of an Intermediate Process. >>> >>> IPFIX Masquerading Proxy >>> >>> An IPFIX Masquerading Proxy is an IPFIX Mediator that receives a >>> record stream from one or more Exporters to screen out parts of >>> records according to configured policies in order to protect the >>> privacy of the network's end users or to retain sensitive data of >>> the exporting organization. >> Do we really need these four terms? >> I think that they can be removed. As Brian said, it is difficult to >> classify IPFIX Mediators according to these types. >> All later occurrences of these terms can be replaced by "IPFIX Mediator". >> >> > In my opinion, I would like to keep these terms to show more concrete > examples. But, I don't adhere to my opinion. In problem statement at > this level, we can remove the above terms, if no one are against it. > >>> 4. Problem Statement >>> >>> Network administrators generally face the problems of measurement >>> system scalability, flow-based measurement flexibility, and export >>> reliability, even if some techniques, such as Sampling, Filtering, >>> Data Records aggregation and export replication, have already been >>> developed. The problems consist of optimizing the resources of the >> How can you "optimize the resources"? >> > > I will change it as follows. > > The problems consist of adjusting some parameters of > metering device to the resources of the measurement system while > fulfilling appropriate conditions: data accuracy, flow granularity, > and export reliability. These conditions depend on two factors. nice. >>> measurement system while fulfilling appropriate conditions: data >>> accuracy, flow granularity, and export reliability. These conditions >>> depend on two factors. >>> >>> o measurement system capacity: >>> This consists of the bandwidth of the management network, the >>> storage capacity, and the performances of the collecting devices >>> and exporting devices. >>> >>> o application requirements: >>> Different applications, such as traffic engineering, detecting >>> traffic anomalies, and accounting, etc., impose different Flow >> remove "etc." >> > Ok. > >>> Record granularities, and data accuracies. >>> >>> The sustained growth of IP traffic has been overwhelming the >>> measurement system capacities. Furthermore, a large variety of >>> applications (e.g., QoS measurement, traffic engineering, security >>> monitoring) and the deployment of measurement system in heterogeneous >>> environments have been increasing the demand and complexity of IP >>> traffic measurements. >>> >>> 4.1. Coping with IP Traffic Growth >>> >>> Enterprise or service provider networks already have multiple 10 Gb/s >>> links, their total traffic exceeding 100 Gb/s. In the near future, >>> broadband users' traffic will increase by approximately 40% every >>> year according to [TRAFGRW]. When operators monitor traffic of 500 >>> Gb/s with a packet sampling rate of 1/1000, the amount of exported >>> Flow Records from Exporters could exceed 50 kFlows/s. This value is >>> beyond the ability of a single Collector. >> This paragraph describes the situation today. Are we sure that these >> numbers are still valid next year? Maybe we are then able to process >> 50kFlows/s. >> I would remove all these figures. >> > This figure shows the situation at current level. In my opinion, these > figures don't block the later work. > > I will change this subsection as follows. > > 4.1. Coping with IP Traffic Growth > > Enterprise or service provider networks already have multiple 10 Gb/s > links, their total traffic exceeding 100 Gb/s. In the near future, > broadband users' traffic will increase by approximately 40% every > year according to [TRAFGRW]. When administrators monitor IP traffic > sustaining its growth with existing packet sampling rate at multiple > Exporters, the amount of exported Flow Records from Exporters could > exceed the ability of single Collector. > > To deal with this problem, current data reduction techniques (packet > Sampling and Filtering in [RFC5475], and aggregation of measurement > data) have been generally implemented on Exporters. Note that packet > Sampling leads to potential loss of small Flows. With both packet > Sampling and aggregation techniques, administrators might no longer > be able to detect and investigate subtle traffic changes and > anomalies as this requires detailed Flow information. With > Filtering, only a subset of the Data Records are exported. > > Considering the potential drawbacks of packet Sampling, Filtering, > and Data Records aggregation, there is a need for a large-scale > collecting infrastructure that does not rely on data reduction > techniques. ok. > > >>> To deal with this problem, current data reduction techniques >>> (Sampling and Filtering in [RFC5475], and aggregation of measurement >> "packet Sampling and Filtering"? > > Ok. >>> data) have been generally implemented on Exporters. Note that >>> Sampling technique leads to potential loss of small Flows. With both >> "packet Sampling leads to..." >> > Ok. > >>> Sampling and aggregation techniques, administrators might no longer >>> be able to detect and investigate subtle traffic changes and >>> anomalies as this requires detailed Flow information. With >>> Filtering, only a subset of the Data Records are exported. >>> >>> Considering the potential drawbacks of Sampling, Filtering, and Data >>> Records aggregation, there is a need for a large-scale collecting >>> infrastructure that does not rely on data reduction techniques. >> Hm, I do not see this problem if a Collector receives data from a single >> Exporter. You should say that these problems arise if multiple Exporters >> send data to a single Collector. > > Please see the above subsection. ok >>> 4.2. Coping with Multipurpose Traffic Measurement >>> >>> Different monitoring applications impose different requirements on >>> the monitoring infrastructure. Some of them require traffic >>> monitoring at a Flow level while others need information about >>> individual packets or just Flow aggregates. >>> >>> To fulfill these divers requirements, an Exporter would need to >>> perform various complex metering tasks in parallel, which is a >>> problem due to limited resources. Hence, it can be advantageous to >>> run the Exporter with a much simpler setup and to perform appropriate >>> post-processing of the exported Data Records at a later stage. >>> >>> 4.3. Coping with Heterogeneous Environments >>> >>> Network administrators use IPFIX Devices and PSAMP Devices from >>> various vendors, various software versions, various device types >>> (router, switch, or probe) in a single network domain. Even legacy >>> flow export protocols are still deployed in current network. This >>> heterogeneous environment leads to differences in Metering Process >>> capabilities, Exporting Process capacity (export rate, cache memory, >>> etc.), and data format. For example, probes and switches cannot >>> retrieve some derived packet properties in [RFC5102] from a routing >>> table. >> remove "in [RFC5102]" >> > Ok. > >>> To deal with this problem, the measurement system needs to mediate >>> the differences. However, equipping all collecting devices with this >>> absorption function is difficult. >>> >>> 4.4. Summary >>> >>> In optimizing the resources of a measurement system, it is important >> I still do not understand what "optimize the resources" is supposed to mean. >> > > I will change it as follows. > > 4.4. Summary > > In adjusting some parameters to the resources of a measurement > system, it is important to use traffic data reduction techniques as > early as possible, e.g., at the Exporter. However, this I do not understand. Maybe you want to say: Due to resource limitations of the measurement system, it is important to... > implementation is made difficult by heterogeneous environment of > exporting devices to meet the requirements of different monitoring > applications. > > >>> to use traffic data reduction techniques as early as possible, e.g., >>> at the Exporter. However, this implementation is made difficult by >>> heterogeneous environment of exporting devices. >> Please revise the entire paragraph above. It only talks about data >> reduction. I do not think that this is the core of mediation. >> > No. It imply the distribution of traffic data in heterogeneous > enviroment. Please suggest your idea. The summary covers 4.1 and 4.3. I miss the problem mentioned in 4.2. > >>> This implies that a new Mediation function is required in typical >>> Exporter-Collector architectures. Based on some applicability >>> examples, the next section shows the limitation of the typical >>> Exporter-Collector architecture model and the IPFIX Mediation >>> benefits. >> >>> 5. Mediation Applicability Examples >>> >>> 5.1. Adjusting Flow Granularity >>> >>> A set of common properties of simplest Flow type is a fixed 5-tuple >>> of protocol, source and destination IP addresses, and source and >> As you talk about "Flow Keys", you should use this term and not invent a >> new one! > > Actually, when I started to write this subsection, it implied covering > IPFIX and NetFlow. > > I will change subsection as follows. > > 5.1. Adjusting Flow Granularity > > A simplest set Flow Keys is a fixed 5-tuple of protocol, source and > destination IP addresses, and source and destination port numbers. A > shorter set of Flow Keys, such as a triple, a double, or a single > property, (for example network prefix, peering autonomous system > number, or BGP Next-Hop fields), creates more aggregated Flow > Records. This is especially useful for measuring router-level > traffic matrices in a core network domain and for easily adjusting > the performance of Exporters and Collectors. > > Implementation analysis: > > Implementations for this case depend on where Flow granularity is > adjusted. More suitable implementations use configurable Metering > Processes in Original Exporters. The cache in the Metering > Process can specify its own set of Flow Keys and extra fields. > The Original Exporter thus generates Flow Records of the desired > Flow granularity. > > In the case where a Metering Process hosting no ability to change > the Flow Keys in Original Exporter creates Flow Records, or PSAMP > Packet Reports, an IPFIX Mediator can aggregate Data Records based > on a new set of Flow Keys. Even in the case where the Metering Even in the case of a Metering Process... > Process hosting this ability, an IPFIX Mediator can further > aggregate the Flow Records. fine. > >>> destination port numbers. A shorter set of common properties, such >>> as a triple, a double, or a single property, (for example network >>> prefix, peering autonomous system number, or BGP Next-Hop fields), >>> creates more aggregated Flow Records. This is especially useful for >>> measuring traffic exchange in an entire network domain and for easily >> What do you mean by "traffic exchange in an entire network domain"? >> > It is router-level traffic matrices indicates traffic volumes > transmitted between every pair of end routers in core network. > Please see above subsection. ok. > >>> adjusting the performance of Exporters and Collectors. >>> >>> Implementation analysis: >>> >>> Implementations for this case depend on where Flow granularity is >>> adjusted. More suitable implementations use configurable Metering >>> Processes in Original Exporters. The cache in the Metering >>> Process can specify its own set of common properties (Flow Keys) >>> and extra fields. The Original Exporter thus creates directly >>> aggregated Flow Records. >> IMO, "aggregated Flow Record" is non-sense. If you look at the >> definition of "Flow", you see that this is a normal Flow Record. > > Yes. I understood it. But, aggregated Flow Records is more intuitive. ok > >> I would say that the Original Exporter generates Flow Records of the >> desired Flow granularity. >> >>> In the case where the Original Exporter contains a Metering >>> Process that creates fixed tuple Flow Records (no ability to >> Replace "fixed tuple Flow Records" by correct IPFIX language. >> > Please see above subsection. ok > > >>> change the Flow Keys), or PSAMP Packet Reports, an IPFIX >>> Concentrator can aggregate Data Records based on a new set of Flow >>> Keys. Even in the case where the Original Exporter contains a >>> Metering Process for which the Flow Keys can be configured, an >>> IPFIX Concentrator can further aggregate the Flow Records. >>> >>> 5.2. Hierarchical Collecting Infrastructure >>> >>> The increase of IPFIX Exporters, the increase of the traffic, and the increasing number of exporters? >>> variety of treatments expected to be performed over the Data Records >> over => on >> > Ok. > >>> is more and more difficult to handle within a single Collector. >>> Hence to increase the collecting (e.g., the bandwidth capacity) and >>> processing capacity, distributed Collectors must be deployed. As a >>> possible approach, a hierarchical structure is useful for increasing >> I don't understand how the collecting and processing capacity increases >> thanks to a hierarchical structure. >> >> The capacity increases because I implement more resources in the >> network, e.g. more Collectors. > > Although increasing number of Collectors operated independently makes it > more capacity, we cannot measure the all of amount of traffic data. Still not sure what you mean. The original exporter measures traffic, not the collector. If you cannot measure all the traffic, you need more powerful routers. IMO, the hierarchy is useful to gather data which has been collected at different places in the network. But the hierarchy is not needed to deploy distributed collectors. >>> the measurement systems capacity, both in export bandwidth capacity >>> and in collecting capacity. >>> >>> Implementation analysis: >>> >>> To cope with the increase of IPFIX Exporters and traffic, one >> "number of IPFIX Exporters" (only IPFIX?) > Ok. > >>> possible implementation uses IPFIX Concentrators to build a >>> hierarchical collection system. To cope with the variety of >>> treatments, one possible implementation uses IPFIX Distributors to >>> build a distributed collection system. More specific cases are >>> described in section 5.9. >> >>> 5.3. Correlation for Data Records >>> >>> The correlation amongst Data Records or between Data Record and meta >>> data provides new metrics or information, including the following. >>> >>> o One-to-one correlation between Data Records >>> >>> * One way delay from the correlation of PSAMP Packet Reports from >>> different Exporters along a specific path, packet inter-arrival >>> time, etc. >> "packet inter-arrival times from the correlation of PSAMP Packet Reports >> generated by a single Exporter, etc." >> > > Ok. > I will change it as follows. > > o One-to-one correlation between Data Records > > * One way delay from the correlation of PSAMP Packet Reports from > different Exporters along a specific path. > > * Packet inter-arrival time from the correlation of sequential > PSAMP Packet Reports from a Exporter. ok > > > >>> * Treatment from the correlation of Data Records with the common >> remove "the" in front of "common" >> > Ok. > >>> properties, observed at incoming/outgoing interfaces. Examples >>> are the rate-limiting ratio, the compression ratio, the >>> optimization ratio, etc. >>> >>> o Correlation amongst Data Records >>> >>> Average/maximum/minimum values from correlating multiple Data >>> Records. Examples are the average/maximum/minimum number of >>> packets of the measured Flows, the average/maximum/minimum one way >>> delay, the average/maximum/minimum number of lost packets, etc. >>> >>> o Correlation between Data Record and other meta data >>> >>> Examples are some BGP attributes associated with Data Record by >>> looking up the routing table. >>> >>> Implementation analysis: >>> >>> One possible implementation for this case uses an IPFIX >>> Concentrator located between the Metering Processes and Exporting >> IPFIX Concentrator => Intermediate Process >> > Yes. > >>> Processes on the Original Exporter, or alternatively a separate >>> IPFIX Concentrator located between the Original Exporters and >>> IPFIX Collectors. >>> >>> 5.4. Time Composition >>> >>> Time composition is defined as the aggregation of consecutive Data >>> Records with common properties. It leads to the same output as >> applies to Flow Records only? > > No, I use "Data Record". Data Records with identical Flow Keys implies it > applies Flow Record only. It applies Packet Reports with common > properties as well. I will keep it. > >> common properties => Flow Keys? >> >>> setting a longer active interval timer on Original Exporters with one >> active timeouts? > > Yes. >>> advantage: the creation of new metrics such as average, maximum and >>> minimum values from Flow Records with a shorter time interval enables >>> administrators to keep track of changes that might have happened >>> during the time interval. >> Hm, changes can be much better detected by looking at the short-lived >> values directly instead of looking at the long-term average, maximum, or >> minimum. >> > > No. The advantage is that changes can be detected without increasing the > number of output Flow Records. ok > >>> Implementation analysis: >>> >>> One possible implementation for this case uses an IPFIX >>> Concentrator located between the Metering Processes and Exporting >> Intermediate Process > > Yes. > >>> Processes on the Original Exporter, or alternatively a separate >>> IPFIX Concentrator located between the Original Exporters and >>> IPFIX Collectors. >>> > > I will change as follows. > > >>> 5.5. Spatial Composition >>> >>> Spatial composition is defined as the aggregation of Data Records in >>> a set of Observation Points within an Observation Domain, across >>> multiple Observation Domains from a single Exporter, or even across >>> multiple Exporters. The spatial composition is divided into four >>> types. >>> >>> o Case 1: Spatial Composition within one Observation Domain >>> >>> For example, in the case where a link aggregation exists, Data >> remove "a" >> > Ok. > >>> Records metered at physical interfaces belonging to the same trunk >>> can be merged. >>> >>> o Case 2: Spatial Composition across Observation Domains, but within >>> a single Exporter >> Original Exporter? > > Yes. > >>> For example, in the case where a link aggregation exists, Data >> remove "a" >> > Ok. > >>> Records metered at physical interfaces belonging to a same trunk >>> grouping beyond the line interface module can be merged. >> "line card"? >> > Ok. > >>> o Case 3: Spatial Composition across Exporters >>> >>> Data Records metered within an administrative domain, such as the >>> west area and east area of an ISP network, can be merged. >>> >>> o Case 4: Spatial Composition across administrative domains >>> >>> Data Records metered across administrative domains, such as across >>> different customer networks or different ISP networks, can be >>> merged. >> Are more cases thinkable? > > Maybe yes. >> If yes, I would call the above "cases" "examples". >> > Ok. > >>> Implementation analysis: >>> >>> One possible implementation for the cases 1 and 2 uses an IPFIX >>> Concentrator located between the Metering Processes and Exporting >> Intermediate Process >> > Yes. > >>> Processes on the Original Exporter. A separate IPFIX Concentrator >>> located between the Original Exporters and IPFIX Collector is a >>> valid solution for the cases 1, 2, 3, and 4. >>> >>> >>> 5.6. Data Record Anonymization >>> >>> IPFIX exports across administrative domains can be used to measure >>> traffic for wide-area traffic engineering or to analyze Internet >>> traffic trends, as described in the spatial composition across >>> administrative domains in the previous subsection. >>> In such a case, administrators need to adhere to privacy protection >>> policies and prevent access to confidential traffic measurements by >>> other people. Typically, anonymization techniques enables the >> enable >> > Yes. > >>> provision of traffic data to other people without violating these >>> policies. >>> >>> Generally, anonymization modifies a data set to protect the identity >>> of the people or entities described by the data set from being >>> disclosed. It also attempts to preserve sets of network traffic >>> properties useful for a given analysis while ensuring the data cannot >>> be traced back to the specific networks, hosts, or users generating >>> the traffic. For example, IP address anonymization is particularly >>> important for avoiding the identification of the users, hosts, and >> remove second "the" >> > Yes. > >>> routers. As another example, when ISP provides a traffic monitoring >> an ISP >> > Yes. > >>> service to end customers by their own Exporters, even in case of >>> exporting interface index fields, network administrators take care of >>> anonymizing its fields to avoid disclosing the vulnerability. >> Why does an interface represent a vulnerability? >> > > Interface indexes assignment policies in several vendors are different. > Some vender indexes show upper bytes indicating line card, lower byte > indicating interfaces. > By recognizing its policy, we can presume the vendors of Exporter. Ok. But I would not say that disclosing an interface index automatically discloses a vulnerability. "vulnerability" => "information" > >>> Implementation analysis: >>> >>> One possible implementation for this case uses an anonymization >>> function at the Original Exporter. However, this increases the >>> load on the Original Exporter. A more flexible implementation >>> uses a separate IPFIX Masquerading Proxy between the Original >>> Exporter and Collector. >> >> >> >>> 5.10. Flow-based Sampling and Selection >>> >>> Generally, the distribution of the number of packets per Flow seems >>> to be heavy-tailed. Most types of Flow Records are likely to be >>> small Flows consisting of a small number of packets. The measurement >>> system is overwhelmed with a huge amount of these small Flows. If >>> statistics information of small Flows is exported as merged data by >>> applying a policy or threshold, the load on the Exporter is reduced. >>> Furthermore, if the flow distribution is known, exporting only a >>> subset of the Data Records might be sufficient. >>> >>> Implementation analysis: >>> >>> One possible implementation for this case uses an IPFIX >>> Concentrator located between the Metering Processes and Exporting >> Intermediate Process > > Ok. >>> Processes on the Original Exporter, or alternatively a separate >>> IPFIX Concentrator located between the Original Exporters and >>> IPFIX Collectors. A set of IPFIX Mediation functions, such as >>> filtering, selecting and aggregation is used in the IPFIX >>> Concentrator. >> >>> 6. IPFIX Mediators Implementation Specific Problems >>> >>> 6.1. Loss of Original Exporter Information >>> >>> Both the Exporter IP address indicated by the source IP address of >>> the IPFIX Transport Session and the Observation Domain ID included in >>> the IPFIX Message header are likely to be lost during IPFIX >>> Mediation. In some cases, a IPFIX Masquerading Proxy might drop the >> a => an >> > Ok. > >>> information deliberately. In general, however, the Collector must >>> recognize the origin of the measurement information, such as the IP >>> address of the Original Exporter, the Observation Domain ID, or even >>> the Observation Point ID. Note that, if an IPFIX Mediator can not >> cannot >> > Ok. > >>> communicate the Original Exporter IP address, then the IPFIX >>> Collector will wrongly deduce that the IP address of the IPFIX >>> Mediator is that of the Original Exporter. >>> >>> In the following figure, a Collector can identify two IP addresses: >>> 10.1.1.3 (IPFIX Mediator) and 10.1.1.2 (Exporter#2), respectively. >>> The Collector, however, needs to somehow recognize both Exporter#1 >>> and Exporter#2, which are the Original Exporters. The IPFIX Mediator >>> must be able to notify the Collector about the IP address of the >>> Original Exporter. >>> >>> .----------. .--------. >>> |IPFIX | |IPFIX | >>> |Exporter#1|--------->|Mediator|---+ >>> | | | | | >>> '----------' '--------' | .---------. >>> IP:10.1.1.1 IP:10.1.1.3 '----->|IPFIX | >>> ODID:10 ODID:0 |Collector| >>> +----->| | >>> .----------. | '---------' >>> |IPFIX | | >>> |Exporter#2|-----------------------' >>> | | >>> '----------' >>> IP:10.1.1.2 >>> ODID:20 >>> >>> Figure B: Loss of Original Exporter Information. >>> >>> 6.2. Loss of Base Time Information >>> >>> The Export Time field included in the IPFIX Message header represents >>> a reference timestamp for Data Records. Some IPFIX Information >>> Elements, described in [RFC5102], carry delta timestamps that >>> indicate the time difference from the value of the Export Time field. >>> If the Data Records include any delta time fields and the IPFIX >>> Mediator overwrites the Export Time field when sending IPFIX >>> Messages, the delta time fields become meaningless and, because >>> Collectors cannot recognize this situation, wrong time values are >>> propagated. >>> >>> 6.3. Transport Sessions Management >>> >>> Maintaining relationships between the incoming Transport Sessions and >>> the outgoing ones depends on the Mediator's implementation. If an >>> IPFIX Mediator relays multiple incoming Transport Sessions to a >>> single outgoing Transport Session, and if the IPFIX Mediators shuts >>> down its outgoing Transport Session, Data Records of the incoming >>> Transport Sessions would not be relayed any more. In the case of >>> resetting an incoming session, the behavior of the IPFIX Mediator >> Transport Session >> > Ok. > >>> needs to be specified. >> >>> 6.7. Exporting the Function Item >>> >>> In some case, the IPFIX Collector needs to recognize which specific >>> function(s) the IPFIX Mediation has executed on the Data Records. >> remove first "the" > > Ok. >>> The IPFIX Collector cannot distinguish between time composition, >>> spatial composition, and Flow Key aggregation, if the IPFIX Mediator >> What is "Flow Key aggregation"? Is this a good expression? >> Usually, some Flow Key fields are just dropped or replaced by non-key >> fields. >> > > I will remove "Flow Key aggregation". > >>> does not export the applied function. Some parameters related to the >>> function also would need to be exported. For example, in case of >>> time composition, the active time of original Flow Records is >> "active timeout"? >> > Yes. > >>> required to interpret the minimum/maximum counter correctly. In case >>> of spatial composition, spatial area information on which Data >>> Records is aggregated is required. >>> >>> 6.8. Consideration for Aggregation >>> >>> Whether the aggregation is based on time or spatial composition, >>> caution should be taken on how to aggregate non-key fields in IPFIX >>> Mediation. The IPFIX information model [RFC5102] specifies that the >>> value of non-key fields, which are derived from fields of packets or >>> from packet treatment and for which the value may change from packet >>> to packet within a single Flow, is determined by the first packet >>> observed for the corresponding Flow, unless the description of the >>> Information Element explicitly specifies a different semantics. >>> >>> However, this simple rule might not be appropriate when aggregating >>> Flow Records which have different values in a non-key field. For >>> example, if two Flows with identical Flow Key values are measured at >>> different Observation Points, they may contain identical packets >>> observed at different locations in the network and at different >>> points in time. On their way from the first to the second >>> Observation Point, some of the packet fields, such as the DSCP, may >>> have changed. Hence, if the Information Element ipDiffServCodePoint >>> is included as a non-key field, it can be useful to include the DSCP >>> value observed at either the first or the second Observation Point in >>> the resulting Flow Record, depending on the application. >>> >>> Other potential solutions include: removing the Information Element >>> ipDiffServCodePoint from the Data Record when re-exporting the >>> aggregate Flow Record, changing the Information Element >>> ipDiffServCodePoint from a non key-field to a Flow Key when re- >>> exporting the aggregated Flow Record, or assigning a non valid value >>> for the Information Element to express to the Collector that this >>> Information Element is meaningless. >>> >>> Furthermore, rules must be specify on how to aggregate the new >>> Configured Selection Fraction an IPFIX Mediator should report when >> What about: >> "If packet Sampling or Filtering is applied, the IPFIX Mediator must >> report an adjusted PSAMP Configured Selection Fraction when aggregating..." >> > Ok. > >>> aggregating IPFIX Flow Records with different sampling rates. >>> Finally, special care must be taken when aggregating Flow Records >>> resulting from different Sampling techniques such as Systematic >>> Count-Based Sampling and Random n-out-of-N Sampling for example. >>> >>> >>> 7. Summary and Conclusion >>> >>> This document described the problems that network administrators have >>> been facing, the applicability of IPFIX Mediation to these problems, >>> and the problems related to the implementation of IPFIX Mediators. >>> To assist the operations of the Exporters and Collectors, there are >>> various IPFIX Mediations from which the administrators may select. >>> Examples of the applicability of IPFIX Mediation are as follows. >>> >>> o Regarding large-scale measurement system, IPFIX Concentrators or >>> IPFIX Distributors help to achieve traffic analysis with high data >>> accuracy and fine flow granularity even as IP traffic grows. As >>> IPFIX Mediation capabilities, Flow sampling, aggregation, and >>> composition are effective. >> Sampling and aggregation reduce the accuracy or granularity. >> Correlation seems to be appropriate. >> > > I means as follows. > > o Regarding large-scale measurement system, IPFIX Mediator with > IPFIX File Writer helps to achieve traffic analysis with high data > accuracy and fine flow granularity even as IP traffic grows. As > IPFIX Mediation capabilities, Flow sampling, aggregation, and > composition are effective. Flow sampling => Flow selection ? > >>> o Regarding data retention, IPFIX Mediators enhance the export >>> reliability, and the storage of the measurement system. >>> >>> o Regarding the distribution of Data Records, IPFIX Distributors >>> help to achieve multipurpose traffic analysis for different >>> organizations, or help to achieve respective traffic analysis >> remove "respective"? >> > Ok. > >>> based on Data Record types(IPv4, IPv6, MPLS, and VPN). >>> >>> o Regarding the IPFIX export across domains, IPFIX Masquerading >>> Proxies help administrators to anonymize or filter Data Records, >>> preventing privacy violations. >>> >>> o Regarding interoperability, IPFIX Proxies provide interoperability >>> between legacy protocols and IPFIX, even during the migration >> even => for example > Ok. > >>> period to IPFIX. >>> >>> As a result, the IPFIX Mediation benefits become apparent. However, >>> there are still some open issues with the use of IPFIX Mediators. >>> >>> o Both Observation Point and IPFIX Message header information, such >>> as the Exporter IP address, Observation Domain ID, and Export Time >>> field, might be lost. This data should therefore be communicated >>> between the Original Exporter and Collector via the IPFIX >>> Mediator. >>> >>> o IPFIX Mediators are required to manage Transport Sessions, >>> Template IDs, and Observation Domain IDs. Otherwise, anomalous >>> IPFIX Messages could be created. >>> >>> o Data Records defined by Options Templates, such as those reporting >>> the Sampling rate and Sampling algorithm used, might be lost >>> during IPFIX Mediation. If a Collector is not informed of current >>> Sampling rates, traffic information might become worthless. >>> >>> These problems stem from the fact that no standards regarding IPFIX >>> Mediation have been set. In particular, the minimum set of >>> information that should be communicated between Original Exporters >>> and Collectors, the management between different IPFIX Transport >>> Sessions, and the internal components of IPFIX Mediators should be >>> standardized. >> >> There is a lot of repetition in this section. >> > > You means this section should be removed. If it just repeats what has already been set, then probably yes. >>> 8. Security Considerations >>> >>> A flow-based measurement system must prevent potential security >>> threats: the disclosure of confidential traffic data, injection of >>> incorrect data, and unauthorized access to traffic data. These >>> security threats of the IPFIX protocol are covered by the security >>> considerations section in [RFC5101] and are still valid for IPFIX >>> Mediators. >>> >>> And a measurement system must also prevent the following security >> remove "And" >> > Ok. >>> threats related to IPFIX Mediation: >>> >>> o Attacks against IPFIX Mediator >>> >>> IPFIX Mediators can be considered as a prime target for attacks, >>> as an alternative to IPFIX Exporters and Collectors. IPFIX >>> Proxies or Masquerading Proxies need to prevent unauthorized >>> access or denial-of-service (DoS) attacks from untrusted public >>> networks. >>> >>> o Man-in-the-middle attack by untrusted IPFIX Mediator >>> >>> The Exporter-Mediator-Collector structure model would increase the >>> risk of the man-in-the-middle attack. >> "would increase the risk of..." => "could be misused for >> man-in-the-middle attacks" >> > Good. > >>> o Configuration on IPFIX Mediation >>> >>> In the case of IPFIX Distributors and IPFIX Masquerading Proxies, >>> an accidental misconfiguration and unauthorized access to >>> configuration data could lead to the crucial problem of disclosure >>> of confidential traffic data. -- Dipl.-Ing. Gerhard Münz Chair for Network Architectures and Services (I8) Technische Universität München - Department of Informatics Boltzmannstr. 3, 85748 Garching bei München, Germany Phone: +49 89 289-18008 Fax: +49 89 289-18033 E-mail: muenz@net.in.tum.de WWW: http://www.net.in.tum.de/~muenz From bclaise@cisco.com Sun Nov 15 07:50:33 2009 Return-Path: X-Original-To: ipfix@core3.amsl.com Delivered-To: ipfix@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CD6DA3A6774 for ; Sun, 15 Nov 2009 07:50:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.486 X-Spam-Level: X-Spam-Status: No, score=-2.486 tagged_above=-999 required=5 tests=[AWL=0.069, BAYES_00=-2.599, DATE_IN_PAST_03_06=0.044] 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 Soj8njy8ljqg for ; Sun, 15 Nov 2009 07:50:32 -0800 (PST) Received: from av-tac-bru.cisco.com (weird-brew.cisco.com [144.254.15.118]) by core3.amsl.com (Postfix) with ESMTP id 7ADF73A69A2 for ; Sun, 15 Nov 2009 07:50:32 -0800 (PST) X-TACSUNS: Virus Scanned Received: from strange-brew.cisco.com (localhost.cisco.com [127.0.0.1]) by av-tac-bru.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id nAFF0Dab016055; Sun, 15 Nov 2009 16:00:13 +0100 (CET) Received: from [10.61.77.94] (ams3-vpn-dhcp3422.cisco.com [10.61.77.94]) by strange-brew.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id nAFF0CLS012337; Sun, 15 Nov 2009 16:00:13 +0100 (CET) Message-ID: <4AFFC790.6060002@cisco.com> Date: Sun, 15 Nov 2009 10:19:12 +0100 From: Benoit Claise User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Gerhard Muenz References: <7A07131A-78E8-44DA-85A7-FF7D839A6AA8@tik.ee.ethz.ch> <4AEABCFB.70505@cisco.com> <978917B0-172E-4DB1-AE06-03B9A107F446@informatik.uni-erlangen.de> <4AF1419F.2000008@net.in.tum.de> <5FB55758-05FE-47AE-BE8B-9F4E48C1FC75@informatik.uni-erlangen.de> <4AFA21DA.4090200@cisco.com> <2AB3F5EF-DF15-4638-AB4D-9BC48C68858C@informatik.uni-erlangen.de> <247849B0-55E5-49A8-B422-59E2DBE597B5@tik.ee.ethz.ch> <4AFC2AAC.9000109@cisco.com> <4AFC3C66.3010104@net.in.tum.de> In-Reply-To: <4AFC3C66.3010104@net.in.tum.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: Tobias Limmer , ipfix@ietf.org Subject: Re: [IPFIX] Fwd: I-D ACTION:draft-ietf-ipfix-export-per-sctp-stream-04.txt X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 15 Nov 2009 15:50:33 -0000 Gerhard, > > Hi all, > > The original issue was this one: > > >>> 4.2. Template Management: > >>> "Any Data Sets associated with a Template Record MUST be sent on > >>> the same SCTP stream on which the Template Record was sent." > >>> According to rfc5101, an Options Template Record is a Template > >>> Record. Later in the same section you specify: "When the Options > >>> Template and associated Data Records are sent in different SCTP > >>> streams, [...]". > >>> Isn't this a contradiction, or am I missing something here? > > Even if we can add Brian's sentence to the terminology section, this > does not help here. You're right. I should have paid more attention to Tobi's problem description. Regards, Benoit. > > So, in addition to Brian's proposal, we could replace "Template > Record" by "non-Option Template Record" in the first sentence. Of > course, the sentence becomes messy :( > > Regards, > Gerhard > > > > Tobias Limmer wrote: >> Benoit, Brian, >> >> On 12.11.2009, at 16:33, Benoit Claise wrote: >>>> Template and Options Template aren't disjoint sets, and are not >>>> defined ambiguously. An Options Template is essentially a subclass >>>> of Template. There's simply no abstract superclass by which we can >>>> refer to "Template but not Options Template" as separate from >>>> "Template including Options Template". So introducing this >>>> language here risks confusing the point more, I think. >>>> >>>> Suggest instead "Note that in this document, "'(Options) Template' >>>> is used in this document to refer to Templates and Options >>>> Templates." >>> I like what Brian proposal because, when I read "In this document, >>> Template and Options Template describe disjoint sets, and Template >>> is not used as generic term for Options Template.", it seems that >>> there is something wrong with the terminology... and this is not >>> the case. >>> Brian's proposal is actually a clarification, which is always good! >> >> Hm. Brian's proposal is very vague about my main issue, that Options >> Template is not a subclass of Template. In my opinion, this is a >> small ambiguity in in the terminology of rfc5101, and I wanted to >> explicitly clarify this problem. >> >> But maybe it's just my way of thinking that's getting in the way here? >> >> Bye, >> Tobi >> >> -- >> Dipl.-Inf. Tobias Limmer >> Chair for Computer Networks and Communication Systems >> Universität Erlangen-Nürnberg >> Martensstr. 3, D-91058 Erlangen, Germany >> Phone: +49-9131-8527931 Fax: +49-9131-8527409 >> eMail: limmer .at. informatik.uni-erlangen.de >> URL: http://www7.informatik.uni-erlangen.de/~limmer >> >> _______________________________________________ >> IPFIX mailing list >> IPFIX@ietf.org >> https://www.ietf.org/mailman/listinfo/ipfix > From tuexen@fh-muenster.de Fri Nov 13 07:27:05 2009 Return-Path: X-Original-To: ipfix@core3.amsl.com Delivered-To: ipfix@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D977D3A6A0A for ; Fri, 13 Nov 2009 07:27:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.738 X-Spam-Level: * X-Spam-Status: No, score=1.738 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HOST_EQ_DIP_TDIAL=2.144, HOST_MISMATCH_NET=0.311, RCVD_IN_PBL=0.905, RCVD_IN_SORBS_DUL=0.877, RDNS_DYNAMIC=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PJZLQ2ez03Zy for ; Fri, 13 Nov 2009 07:27:05 -0800 (PST) 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 BCA253A6A08 for ; Fri, 13 Nov 2009 07:27:04 -0800 (PST) Received: from [192.168.1.100] (p508FF0ED.dip.t-dialin.net [80.143.240.237]) by mail-n.franken.de (Postfix) with ESMTP id 6EF6F1C0C0BEA; Fri, 13 Nov 2009 16:27:31 +0100 (CET) Mime-Version: 1.0 (Apple Message framework v1077) Content-Type: text/plain; charset=us-ascii From: Michael Tuexen In-Reply-To: <4AFD3756.20808@cisco.com> Date: Fri, 13 Nov 2009 16:27:30 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <7A07131A-78E8-44DA-85A7-FF7D839A6AA8@tik.ee.ethz.ch> <4AEABCFB.70505@cisco.com> <978917B0-172E-4DB1-AE06-03B9A107F446@informatik.uni-erlangen.de> <4AF1419F.2000008@net.in.tum.de> <4AFD3756.20808@cisco.com> To: Benoit Claise X-Mailer: Apple Mail (2.1077) X-Mailman-Approved-At: Sun, 15 Nov 2009 12:47:04 -0800 Cc: Tobias Limmer , ipfix@ietf.org Subject: Re: [IPFIX] Fwd: I-D ACTION:draft-ietf-ipfix-export-per-sctp-stream-04.txt X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Nov 2009 15:27:05 -0000 Hi Benoit, if a message is received, the receiver has no indication whether it was = sent reliably or not. Best regards Michael On Nov 13, 2009, at 11:39 AM, Benoit Claise wrote: > Randy, Michael, >=20 > As SCTP experts, are you able to help on this one below. >=20 > Thanks and regards, Benoit. >>=20 >>=20 >>> 4.5. The Collecting Process's Side: >>> "3. A Data Record is received unreliably although it is expected to = be sent reliably (due to a previously received Data Record associated = with the Data Record Reliability Options Template)." >>>=20 >>> Is it possible for the receiving side of a SCTP connection to = determine which SCTP messages were sent unreliably? I did not find any = indication of that in rfc3758. T=10he receiving side only knows if = complete messages or fragments are skipped. >>=20 >> I think you are right. We need to check. >>=20 >> Regards, >> Gerhard=20 >=20 >=20 >=20 From root@core3.amsl.com Wed Nov 18 11:15:01 2009 Return-Path: X-Original-To: ipfix@ietf.org Delivered-To: ipfix@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id 520FC3A6808; Wed, 18 Nov 2009 11:15:01 -0800 (PST) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20091118191501.520FC3A6808@core3.amsl.com> Date: Wed, 18 Nov 2009 11:15:01 -0800 (PST) Cc: ipfix@ietf.org Subject: [IPFIX] I-D ACTION:draft-ietf-ipfix-export-per-sctp-stream-05.txt X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Nov 2009 19:15:01 -0000 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IP Flow Information Export Working Group of the IETF. Title : IPFIX Export per SCTP Stream Author(s) : B. Claise, P. Aitken, A. Johnson, G. Muenz Filename : draft-ietf-ipfix-export-per-sctp-stream-05.txt Pages : 23 Date : 2009-11-18 This document specifies an extension to the specifications in RFC5101, IP Flow Information Export (IPFIX), when using the Partial Reliability extension of SCTP (PR-SCTP, Partial Reliability Stream Control Transmission Protocol). When implemented at both the Exporting and Collecting Processes, this method offers several advantages such as the ability to calculate Data Record losses for PR-SCTP, immediate export of Template Withdrawal Messages, immediate reuse of Template IDs within an SCTP stream, reduced likelihood of Data Record loss, and reduced demands on the Collecting Process. When implemented in only the Collecting or Exporting Process then normal IPFIX behavior will be seen without these additional benefits. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ipfix-export-per-sctp-stream-05.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-ipfix-export-per-sctp-stream-05.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2009-11-18110444.I-D@ietf.org> --NextPart-- From root@core3.amsl.com Thu Nov 19 09: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 81D523A6985; Thu, 19 Nov 2009 09:00:01 -0800 (PST) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20091119170001.81D523A6985@core3.amsl.com> Date: Thu, 19 Nov 2009 09:00:01 -0800 (PST) Cc: ipfix@ietf.org Subject: [IPFIX] I-D Action:draft-ietf-ipfix-anon-01.txt X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Nov 2009 17:00:01 -0000 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IP Flow Information Export Working Group of the IETF. Title : IP Flow Anonymisation Support Author(s) : E. Boschi, B. Trammell Filename : draft-ietf-ipfix-anon-01.txt Pages : 37 Date : 2009-11-19 This document describes anonymisation techniques for IP flow data and the export of anonymised data using the IPFIX protocol. It provides a categorization of common anonymisation schemes and defines the parameters needed to describe them. It provides guidelines for the implementation of anonymised data export and storage over IPFIX, and describes an Options-based method for anonymisation metadata export within the IPFIX protocol, providing the basis for the definition of information models for configuring anonymisation techniques within an IPFIX Metering or Exporting Process, and for reporting the technique in use to an IPFIX Collecting Process. Status of this Memo This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on May 23, 2010. Copyright Notice Copyright (c) 2009 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the BSD License. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ipfix-anon-01.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-ipfix-anon-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2009-11-19085327.I-D@ietf.org> --NextPart-- From trammell@tik.ee.ethz.ch Thu Nov 19 09:44:32 2009 Return-Path: X-Original-To: ipfix@core3.amsl.com Delivered-To: ipfix@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6F99D3A6844 for ; Thu, 19 Nov 2009 09:44:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6yC6s5IoxlQk for ; Thu, 19 Nov 2009 09:44:31 -0800 (PST) Received: from smtp.ee.ethz.ch (smtp.ee.ethz.ch [129.132.2.219]) by core3.amsl.com (Postfix) with ESMTP id 66E483A66B4 for ; Thu, 19 Nov 2009 09:44:31 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by smtp.ee.ethz.ch (Postfix) with ESMTP id 90C9FD93CD for ; Thu, 19 Nov 2009 18:44:27 +0100 (MET) X-Virus-Scanned: by amavisd-new on smtp.ee.ethz.ch Received: from smtp.ee.ethz.ch ([127.0.0.1]) by localhost (.ee.ethz.ch [127.0.0.1]) (amavisd-new, port 10024) with LMTP id XqXYdOAjxAiB for ; Thu, 19 Nov 2009 18:44:27 +0100 (MET) Received: from pb-10072.ethz.ch (pb-10072.ethz.ch [82.130.103.195]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: briant) by smtp.ee.ethz.ch (Postfix) with ESMTP id 46BDAD93AD for ; Thu, 19 Nov 2009 18:44:27 +0100 (MET) From: Brian Trammell Content-Type: multipart/alternative; boundary=Apple-Mail-6--974890844 Date: Thu, 19 Nov 2009 18:44:26 +0100 References: <26657224E98F5C48AA53BD2B7E6382710D1A5622@HEUMHDEXC01.adhel.hitachi-eu.com> To: "ipfix@ietf.org Working Group" Message-Id: Mime-Version: 1.0 (Apple Message framework v1076) X-Mailer: Apple Mail (2.1076) Subject: [IPFIX] Fwd: New Version Notification for draft-ietf-ipfix-anon-01 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, 19 Nov 2009 17:44:32 -0000 --Apple-Mail-6--974890844 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii; format=flowed; delsp=yes Greetings, all, We've posted a -01 revision of the anon draft. Changes from -00 include: 1. Added new sections on reverse truncation anonymisation for address information, and corresponding value of the anonymisationTechnique IE. 2. Extended the anonymisationStability IE to provide special-purpose modification flags, now renamed anonymisationFlags. 3. Added section on perimeter-based anonymisation, allowing different policies for internal and external addresses without requiring perimeter biflows (via anonymisationFlags) 4. Added ability to note a value is partially anonymised, with low order bits left real to adapt to linear pattern recognition attacks due to scan traffic (via anonymisationFlags) 5. Added guidelines on special use address space 6. We have examples now The document is now structurally complete. Please have a look; comments are of course as always welcome. Best regards, Brian Begin forwarded message: > A new version of I-D, draft-ietf-ipfix-anon-01.txt has been > successfuly submitted by Brian Trammell and posted to the IETF > repository. > > Filename: draft-ietf-ipfix-anon > Revision: 01 > Title: IP Flow Anonymisation Support > Creation_date: 2009-11-19 > WG ID: ipfix > Number_of_pages: 37 > > Abstract: > This document describes anonymisation techniques for IP flow data and > the export of anonymised data using the IPFIX protocol. It provides > a categorization of common anonymisation schemes and defines the > parameters needed to describe them. It provides guidelines for the > implementation of anonymised data export and storage over IPFIX, and > describes an Options-based method for anonymisation metadata export > within the IPFIX protocol, providing the basis for the definition of > information models for configuring anonymisation techniques within an > IPFIX Metering or Exporting Process, and for reporting the technique > in use to an IPFIX Collecting Process. --Apple-Mail-6--974890844 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii
A new version of I-D, draft-ietf-ipfix-anon-01.txt = has been successfuly submitted by Brian Trammell and posted to the IETF = repository.

Filename: =        draft-ietf-ipfix-anon
Revisio= n:        01
Title: =           IP Flow = Anonymisation Support
Creation_date:   2009-11-19
WG ID: =           ipfix
Numbe= r_of_pages: 37

Abstract:
This document describes anonymisation = techniques for IP flow data and
the export of anonymised data using = the IPFIX protocol.  It provides
a categorization of common = anonymisation schemes and defines the
parameters needed to describe = them.  It provides guidelines for the
implementation of = anonymised data export and storage over IPFIX, and
describes an = Options-based method for anonymisation metadata export
within the = IPFIX protocol, providing the basis for the definition of
information = models for configuring anonymisation techniques within an
IPFIX = Metering or Exporting Process, and for reporting the technique
in use = to an IPFIX Collecting Process.
= = --Apple-Mail-6--974890844-- From root@core3.amsl.com Thu Nov 19 14:30: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 76C1F28C104; Thu, 19 Nov 2009 14:30:01 -0800 (PST) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20091119223001.76C1F28C104@core3.amsl.com> Date: Thu, 19 Nov 2009 14:30:01 -0800 (PST) Cc: ipfix@ietf.org Subject: [IPFIX] I-D ACTION:draft-ietf-ipfix-export-per-sctp-stream-06.txt X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Nov 2009 22:30:01 -0000 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IP Flow Information Export Working Group of the IETF. Title : IPFIX Export per SCTP Stream Author(s) : B. Claise, P. Aitken, A. Johnson, G. Muenz Filename : draft-ietf-ipfix-export-per-sctp-stream-06.txt Pages : 23 Date : 2009-11-19 This document specifies an extension to the specifications in RFC5101, IP Flow Information Export (IPFIX), when using the Partial Reliability extension of SCTP (PR-SCTP, Partial Reliability Stream Control Transmission Protocol). When implemented at both the Exporting and Collecting Processes, this method offers several advantages such as the ability to calculate Data Record losses for PR-SCTP, immediate export of Template Withdrawal Messages, immediate reuse of Template IDs within an SCTP stream, reduced likelihood of Data Record loss, and reduced demands on the Collecting Process. When implemented in only the Collecting or Exporting Process then normal IPFIX behavior will be seen without these additional benefits. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ipfix-export-per-sctp-stream-06.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-ipfix-export-per-sctp-stream-06.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2009-11-19141806.I-D@ietf.org> --NextPart-- From bclaise@cisco.com Thu Nov 26 06:44:41 2009 Return-Path: X-Original-To: ipfix@core3.amsl.com Delivered-To: ipfix@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E14B03A6A3B for ; Thu, 26 Nov 2009 06:44:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.196 X-Spam-Level: X-Spam-Status: No, score=-2.196 tagged_above=-999 required=5 tests=[AWL=0.403, 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 NRqrWGmGhHK9 for ; Thu, 26 Nov 2009 06:44:41 -0800 (PST) Received: from av-tac-bru.cisco.com (weird-brew.cisco.com [144.254.15.118]) by core3.amsl.com (Postfix) with ESMTP id F3A283A6765 for ; Thu, 26 Nov 2009 06:44:40 -0800 (PST) X-TACSUNS: Virus Scanned Received: from strange-brew.cisco.com (localhost.cisco.com [127.0.0.1]) by av-tac-bru.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id nAQEiYvg008011 for ; Thu, 26 Nov 2009 15:44:34 +0100 (CET) Received: from [10.55.43.59] (ams-bclaise-87110.cisco.com [10.55.43.59]) by strange-brew.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id nAQEiXb4019748 for ; Thu, 26 Nov 2009 15:44:34 +0100 (CET) Message-ID: <4B0E9451.6070400@cisco.com> Date: Thu, 26 Nov 2009 15:44:33 +0100 From: Benoit Claise User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: "ipfix@ietf.org" Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [IPFIX] draft-ietf-ipfix-export-per-sctp-stream-06.txt X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Nov 2009 14:44:42 -0000 Dear all, After discussing the version 04 at the last IETF meeting, we included in version 05 some more improvements as suggested by Brian, Toby, and others. The version 6 addressed a small technical correction that we overlooked. Please review this. According to the conclusions in our last IETF76 IPFIX meeting, one week is allowed to give feedback before moving on this draft back to IESG. Note: I sent that email one week ago, but only to the Cisco internal IPFIX mailing list :-( Regards, Benoit. From Quittek@nw.neclab.eu Fri Nov 27 04:57:29 2009 Return-Path: X-Original-To: ipfix@core3.amsl.com Delivered-To: ipfix@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4158C3A67A5 for ; Fri, 27 Nov 2009 04:57:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qNyFIldoi+hO for ; Fri, 27 Nov 2009 04:57:28 -0800 (PST) Received: from smtp0.neclab.eu (smtp0.neclab.eu [195.37.70.41]) by core3.amsl.com (Postfix) with ESMTP id 24A013A6912 for ; Fri, 27 Nov 2009 04:57:28 -0800 (PST) Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp0.neclab.eu (Postfix) with ESMTP id 613A82C017B2F for ; Fri, 27 Nov 2009 13:57:22 +0100 (CET) X-Virus-Scanned: Amavisd on Debian GNU/Linux (atlas2.office) Received: from smtp0.neclab.eu ([127.0.0.1]) by localhost (atlas2.office [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SeLqISvBYPLB for ; Fri, 27 Nov 2009 13:57:22 +0100 (CET) Received: from VENUS.office (mx1.office [192.168.24.3]) by smtp0.neclab.eu (Postfix) with ESMTP id 970332C0012CA for ; Fri, 27 Nov 2009 13:57:15 +0100 (CET) Received: from 10.1.2.178 ([10.1.2.178]) by VENUS.office ([192.168.24.102]) with Microsoft Exchange Server HTTP-DAV ; Fri, 27 Nov 2009 12:57:15 +0000 MIME-Version: 1.0 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-Type: multipart/signed; boundary="B_3342175014_40459426"; protocol="application/pkcs7-signature"; micalg=sha1 Content-class: urn:content-classes:message Date: Fri, 27 Nov 2009 13:56:54 +0100 Message-ID: X-MS-Has-Attach: yes X-MS-TNEF-Correlator: Thread-Topic: WG last call on draft-ietf-ipfix-configuration-model-04 Thread-Index: AcpvYRgUQbW+SV772Um/x/s4lgl5tQ== From: "Juergen Quittek" To: "IETF IPFIX Working Group" Subject: [IPFIX] WG last call on draft-ietf-ipfix-configuration-model-04 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, 27 Nov 2009 12:57:29 -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_3342175014_40459426 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Dear all, At our session at Hiroshima we agreed to have working group last call on draft-ietf-ipfix-configuration-model-04. The call starts today and will last until Friday December 11. A URL for this Internet-Draft is: http://www.ietf.org/id/draft-ietf-ipfix-configuration-model-04.txt I will ask the NETMOD WG to also review the draft as soon as the YANG specification is final. Please read the draft! Please send your comments to this mailing list! Please also send a message if you are fine with the draft as it is! Thank you, Juergen --B_3342175014_40459426 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 YWIuZXUCBA0uKwcwCQYFKw4DAhoFAKBdMCMGCSqGSIb3DQEJBDEWBBSRTEvCjvFqAKw/tXi/ +p95PEEhBzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0wOTEx MjcxMjU2NTRaMA0GCSqGSIb3DQEBAQUABIIBAJmRIuurX5eUEM6uEow/+VcxmiuhLHrs8CVc SJT/yqgYwOYtIKUXxitfpjnKuZyiZTngWr78JByW6pKME6bAC/tPnfGbIn+ERheG+14HrXDH esQivs5apAsJh57U7LHVw6ooeVKT5yq+nQbg5eQoS/YQtX6MpPPh1C6R5LxJ/8kLCPF1oU4k kETAlteCaqafiPBP04Vzf5imJYQEfYB1M9srWif0AbPkaxR98mS7tPBICGXBiFM+6ZAsyrug u/ZnbxtS4w2wvq6l+ohv3HJpBHwW6iimTcfVWu5EjvazoRSOao5e0LLsBBYVElxYYJYCO5xO VMZ009PhhoR7rLtaGzY= --B_3342175014_40459426--