From Quittek@nw.neclab.eu Mon May 4 02:56: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 0671E3A69B8; Mon, 4 May 2009 02:56:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 63cy0EYWaEPi; Mon, 4 May 2009 02:56:34 -0700 (PDT) Received: from smtp0.neclab.eu (smtp0.neclab.eu [195.37.70.41]) by core3.amsl.com (Postfix) with ESMTP id 924FC3A699E; Mon, 4 May 2009 02:56:17 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp0.neclab.eu (Postfix) with ESMTP id 11F832C01918D; Mon, 4 May 2009 11:57:43 +0200 (CEST) X-Virus-Scanned: Amavisd on Debian GNU/Linux (atlas2.office) Received: from smtp0.neclab.eu ([127.0.0.1]) by localhost (atlas2.office [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ikt98NP9qGJ7; Mon, 4 May 2009 11:57:42 +0200 (CEST) Received: from VENUS.office (mx2.office [192.168.24.15]) by smtp0.neclab.eu (Postfix) with ESMTP id CA5432C017B31; Mon, 4 May 2009 11:57:22 +0200 (CEST) X-MimeOLE: Produced By Microsoft Exchange V6.5 Received: from 10.1.2.178 ([10.1.2.178]) by VENUS.office ([192.168.24.102]) with Microsoft Exchange Server HTTP-DAV ; Mon, 4 May 2009 09:57:22 +0000 MIME-Version: 1.0 Content-class: urn:content-classes:message Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="B_3324283038_31696033" Date: Mon, 4 May 2009 11:57:18 +0200 Message-ID: X-MS-Has-Attach: yes X-MS-TNEF-Correlator: Thread-Topic: write-up for draft-ietf-ipfix-export-per-sctp-stream-02 Thread-Index: AcnMnrWTRKXg246VwEe7eU4YwzVvxw== From: "Juergen Quittek" To: "Dan Romascanu" , "IESG Secretary" , "IETF IPFIX Working Group" Cc: Ronald Bonica Subject: [IPFIX] write-up for draft-ietf-ipfix-export-per-sctp-stream-02 X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 May 2009 09:56:42 -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_3324283038_31696033 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Dear Dan and dear IESG Secretary, Below please find the write up for draft-ietf-ipfix-export-per-sctp-stream-02. The draft is ready for forwarding to the IESG for publication. Best regards, Juergen -- Juergen Quittek quittek@nw.neclab.eu Tel: +49 6221 4342-115 NEC Europe Limited, Network Laboratories Fax: +49 6221 4342-155 Kurfuersten-Anlage 36, 69115 Heidelberg, Germany http://www.netlab.nec.de Registered Office: NEC House, 1 Victoria Road, London W3 6BL, UK Registered in England 2832014 ========================================================================== Write-up for draft-ietf-ipfix-export-per-sctp-stream-02 ======================================================= (1.a) Who is the Document Shepherd for this document? Has the Document Shepherd personally reviewed this version of the document and, in particular, does he or she believe this version is ready for forwarding to the IESG for publication? Juergen Quittek is the document shepherd. He has reviewed it personally and believes that this version is ready for forwarding to the IESG for publication. (1.b) Has the document had adequate review both from key WG members and from key non-WG members? Does the Document Shepherd have any concerns about the depth or breadth of the reviews that have been performed? The document had multiple individual reviews from key WG members. The shepherd has no concern about the depth or breadth of the reviews. (1.c) Does the Document Shepherd have concerns that the document needs more review from a particular or broader perspective, e.g., security, operational complexity, someone familiar with AAA, internationalization, or XML? The document shepherd sees no need for an additional particular review. Particular issues of SCTP have been checked by the TSVWG. (1.d) Does the Document Shepherd have any specific concerns or issues with this document that the Responsible Area Director and/or the IESG should be aware of? For example, perhaps he or she is uncomfortable with certain parts of the document, or has concerns whether there really is a need for it. In any event, if the WG has discussed those issues and has indicated that it still wishes to advance the document, detail those concerns here. Has an IPR disclosure related to this document been filed? If so, please include a reference to the disclosure and summarize the WG discussion and conclusion on this issue. There is no such concern. (1.e) How solid is the WG consensus behind this document? Does it represent the strong concurrence of a few individuals, with others being silent, or does the WG as a whole understand and agree with it? There is a strong consensus in the IPFIX WG to publish this version of the document. There are no particular issues in the document without strong consensus in the IPFIX WG. (1.f) Has anyone threatened an appeal or otherwise indicated extreme discontent? If so, please summarize the areas of conflict in separate email messages to the Responsible Area Director. (It should be in a separate email because this questionnaire is entered into the ID Tracker.) There was no appeal. (1.g) Has the Document Shepherd personally verified that the document satisfies all ID nits? (See http://www.ietf.org/ID-Checklist.html and http://tools.ietf.org/tools/idnits/.) Boilerplate checks are not enough; this check needs to be thorough. Has the document met all formal review criteria it needs to, such as the MIB Doctor, media type, and URI type reviews? If the document does not already indicate its intended status at the top of the first page, please indicate the intended status here. The document shepherd checked for ID nits. The IETF Trust Provisions Section needs to be updated, since it changed after the current version was posted. Also some references need to be updated, because they have been published recently as RFCs. All of these changes can be made in the next update that is expected after IETF last call. (1.h) Has the document split its references into normative and informative? Are there normative references to documents that are not ready for advancement or are otherwise in an unclear state? If such normative references exist, what is the strategy for their completion? Are there normative references that are downward references, as described in [RFC3967]? If so, list these downward references to support the Area Director in the Last Call procedure for them [RFC3967]. Six reference have been outdated since the document was submitted. Five of them are PSAMP and IPFIX documents that have been published as RFCs. The remaining one is a draft from the TSVWG for which an update has been posted. This should be fixed after IETF last call. More references may need an update by then. (1.i) Has the Document Shepherd verified that the document's IANA Considerations section exists and is consistent with the body of the document? If the document specifies protocol extensions, are reservations requested in appropriate IANA registries? Are the IANA registries clearly identified? If the document creates a new registry, does it define the proposed initial contents of the registry and an allocation procedure for future registrations? Does it suggest a reasonable name for the new registry? See [RFC2434]. If the document describes an Expert Review process, has the Document Shepherd conferred with the Responsible Area Director so that the IESG can appoint the needed Expert during IESG Evaluation? IANA considerations have been checked. (1.j) Has the Document Shepherd verified that sections of the document that are written in a formal language, such as XML code, BNF rules, MIB definitions, etc., validate correctly in an automated checker? No. (1.k) The IESG approval announcement includes a Document Announcement Write-Up. Please provide such a Document Announcement Write-Up. Recent examples can be found in the "Action" announcements for approved documents. The approval announcement contains the following sections: Technical Summary This document specifies an improvement to the PR-SCTP export specified in the IPFIX specifications in RFC5101. This method offers several advantages such as the ability to calculate Data Record losses for PR-SCTP, immediate export of Template Withdrawal Messages, immediate reuse of Template IDs within an SCTP stream, and reduced demands on the Collecting Process. Working Group Summary This document describes an extension to the IPFIX protocol. It was motivated by experiences made with early IPFIX implementations. It was accepted with consensus as WG work item and progressed within the WG. WG last call was conducted in August 2008. Modifications based on received comments were applied until November 2008. No more issues were brought up since then and at the IETF meeting in March 2009 the WG confirmed at the session that the document is ready for requesting publication. Document Quality The document underwent several reviews and a WG last call in the IPFIX WG. This way, a high document quality has been achieved already. Personnel Juergen Quittek is shepherding this document. Dan Romascanu is the responsible Area director. --B_3324283038_31696033 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 YWIuZXUCBA0uKwcwCQYFKw4DAhoFAKBdMCMGCSqGSIb3DQEJBDEWBBSxHfFhettS+T1g8D8A Y6FaDJhzWTAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0wOTA1 MDQwOTU3MThaMA0GCSqGSIb3DQEBAQUABIIBAEgongtMzyrBYmL2SrU88kFQcqzjn6+e2VSY QVyPDVHIOjIZ5XxQo0z3iPnjLzjVZMhxsBVstMqBI8hbUVHqBRHqJhZaWivElxrjMifJQNFK 8zVyWia62XzVSibTaJkAY1dhtofH7ixz7ntTbeK90GJXlOTPK9L5y5Y/JQespq82009V/BIr 7L/i6THCKCai63/FxEg8HonN8+AjqJxOEZB0jSpmd6lM+naXBCVVze0J3M5g31yi1xNPmlMy RbQzEeJl9BnPjig2heI9L1ESobUqih7bJaIdY/3JJJbVo2Vpsz6DnU6EJCu7awuUH8r28ZqG 116CTAJ2o3g33yWkW+c= --B_3324283038_31696033-- From akoba@nttv6.net Thu May 7 22:46:39 2009 Return-Path: X-Original-To: ipfix@core3.amsl.com Delivered-To: ipfix@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D84DA3A6B79; Thu, 7 May 2009 22:46:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.501 X-Spam-Level: X-Spam-Status: No, score=-0.501 tagged_above=-999 required=5 tests=[AWL=-0.700, BAYES_00=-2.599, NO_RELAYS=-0.001, SUBJ_RE_NUM=2.799] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lAVSRvaHYKt1; Thu, 7 May 2009 22:46:38 -0700 (PDT) Received: from mail.nttv6.net (mail.nttv6.net [IPv6:2001:fa8::25]) by core3.amsl.com (Postfix) with ESMTP id 59EBC3A68B8; Thu, 7 May 2009 22:46:08 -0700 (PDT) Received: from [192.47.163.152] ([IPv6:2001:fa8:1000:0:49ce:9676:5145:369a]) by mail.nttv6.net (8.14.3/8.14.3) with ESMTP id n485lTSw046940; Fri, 8 May 2009 14:47:30 +0900 (JST) (envelope-from akoba@nttv6.net) Date: Fri, 08 May 2009 14:46:10 +0900 From: Atsushi Kobayashi To: "Thomas Dietz" In-Reply-To: <547F018265F92642B577B986577D671C7009CF@VENUS.office> References: <547F018265F92642B577B986577D671C7009CF@VENUS.office> Message-Id: <20090508135102.D54A.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.2 (mail.nttv6.net [IPv6:2001:fa8::25]); Fri, 08 May 2009 14:47:30 +0900 (JST) Cc: IETF IPFIX Working Group , "MIB Doctors \(E-mail\)" Subject: Re: [IPFIX] AD review of draft-ietf-ipfix-mib-05.txt (ipfixExportEntry) 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, 08 May 2009 05:46:40 -0000 Dear Thomas, Benoit, Gerhard and all, Sorry for late reply. I have concerns about the modification for the following comment. The MIB draft -06 was modified for the ipfixExportIndex to be located at the end of indexes. But, I wonder the order of these indexes is difficult to represent the Transport Session group. I prefer to keep the order of 3 tuple indexes (ipfixMeteringProcessCacheId, ipfixTemplateObservationDomainId, ipfixExportGroupIndex) in order to understand easily the result of snmpwalk, even if the MIB structure changes a little bit. > > T16. ipfixExportEntry leads to a warning in the smicng compilation > > > > W: f(ipfix.mi2), (676,12) Row "ipfixExportEntry" does not have a > > consistent indexing scheme - index items from current table must come > > after index items from other tables > > > > Since I have only libsmi (which does not catch this) I did not realize it. > Fixed. I propose to add ExportGroupTable as follows. What do you think about it? -------------------------------------------------------------------- -- 1.1.5: Export Group Table -------------------------------------------------------------------- ipfixExportGroupTable OBJECT-TYPE SYNTAX SEQUENCE OF IpfixExportGroupEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "This table lists all export groups. On Collectors this table is not needed." ::= { ipfixMainObjects 5 } ipfixExportGroupEntry OBJECT-TYPE SYNTAX IpfixExportGroupEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "Defines an entry in the ipfixExportGroupTable" INDEX { ipfixMeteringProcessCacheId, ipfixTemplateObservationDomainId, ipfixExportGroupIndex } ::= { ipfixExportGroupTable 1 } IpfixExportGroupEntry ::= SEQUENCE { ipfixExportGroupIndex Unsigned32, ipfixExportGroupType INTEGER } ipfixExportGroupIndex OBJECT-TYPE SYNTAX Unsigned32 (1..4294967295) MAX-ACCESS not-accessible STATUS current DESCRIPTION "Locally arbitrary, but unique identifier of an entry in the ipfixExportGroupTable. The value is expected to remain constant from a re-initialization of the entity's network management agent to the next re-initialization. A common ipfixExportGroupIndex between two entries from ipfix Export table expresses that there is a relationship between the Transport Sessions in ipfixTransportSessionIndex. The type of Trasport Session group is expressed by the value of ipfixExportMemberType." ::= { ipfixExportGroupEntry 1 } ipfixExportGroupType OBJECT-TYPE SYNTAX INTEGER { unknown(0), failover(1), duplicate(2), loadBalancing(3) } MAX-ACCESS read-only STATUS current DESCRIPTION "The type of a Transport Session group (identified by the value of ipfixExportGroupIndex, ipfixObservationDomainId and ipfixMeteringProcessCacheId). The following values are valid: unknown(0) This value MUST be used if the status of the group membership cannot be detected by the equipment. This value should be avoided as far as possible. failover(1) This value is used for a group member that is used as the primary or secondary target of an Exporter. This value MUST also be specified if the Exporter does not support Transport Session grouping. In this case the group contains only one Transport Session. duplicate(2) This value is used for a group member that is used for duplicate exporting i.e., all group members identified by the ipfixExportIndex are exporting the same Records in parallel. This implies that all group members MUST have the the same membertype duplicate(3). loadBalancing(3) This value is used for a group member that is used as as one target for load-balancing. This means that a Record is sent to one of the group members in this group identified by ipfixExportIndex. This implies that all group members MUST have the same membertype load-balancing(4)." ::= { ipfixExportGroupEntry 2 } -------------------------------------------------------------------- -- 1.1.6: Export Table -------------------------------------------------------------------- ipfixExportTable OBJECT-TYPE SYNTAX SEQUENCE OF IpfixExportEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "This table lists all exports of an IPFIX device. On Exporters this table contains all exports grouped by Transport Session, Observation Domain Id, Template Id and Metering Process represented by the ipfixMeteringProcessCacheId. Thanks to the ipfixExportGroupIndex the exports can group one or more Transport Sessions to achieve a special functionality like failover management, load-balancing etc. The entries with the same ipfixExportGroupIndex, the same ipfixObservationDomainId and the same ipfixMeteringProcessCacheId define a Transport Session group. If the Exporter does not use Transport Session grouping then each ipfixGroupExportIndex contains a single ipfixMeteringProcessCacheId and thus a singe Transport Session and this session MUST have the member type primary(1). Transport Sessions referenced in this table MUST have the ipfixTransportSessionMode exporting(1). On Collectors this table is not needed." ::= { ipfixMainObjects 6 } ipfixExportEntry OBJECT-TYPE SYNTAX IpfixExportEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "Defines an entry in the ipfixExportTable" INDEX { ipfixMeteringProcessCacheId, ipfixTemplateObservationDomainId, ipfixExportGroupIndex, ipfixTransportSessionIndex, ipfixTemplateId } ::= { ipfixExportTable 1 } IpfixExportEntry ::= SEQUENCE { ipfixExportMemberType INTEGER } ipfixExportMemberType OBJECT-TYPE SYNTAX INTEGER { unknown(0), primary(1), secondary(2) } MAX-ACCESS read-only STATUS current DESCRIPTION "The type of a member Transport Session in a Transport Session group (identified by the value of ipfixExportIndex, ipfixObservationDomainId and ipfixMeteringProcessCacheId). The following values are valid: unknown(0) If the Transport Session group uses duplicate or load balancing, the type of a member Transport Session MUST have the member type unknown(0). primary(1) This value is used for a group member that is used as the primary target of an Exporter. Other group members (with the same ipfixExportIndex and ipfixMeteringProcessCacheId) MUST NOT have the value primary(1) but MUST have the value secondary(2). secondary(2) This value is used for a group member that is used as a secondary target of an Exporter. The Exporter will use one of the targets specified as secondary(2) within the same Transport Session group when the primary target is not reachable." ::= { ipfixExportEntry 1 } --- Atsushi KOBAYASHI NTT Information Sharing Platform Lab. tel:+81-(0)422-59-3978 fax:+81-(0)422-59-5637 From akoba@nttv6.net Fri May 8 00:06:39 2009 Return-Path: X-Original-To: ipfix@core3.amsl.com Delivered-To: ipfix@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7FE7F3A6A15 for ; Fri, 8 May 2009 00:06:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.268 X-Spam-Level: X-Spam-Status: No, score=-0.268 tagged_above=-999 required=5 tests=[AWL=-0.467, 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 L9+OD5KsI+ON for ; Fri, 8 May 2009 00:06:38 -0700 (PDT) Received: from mail.nttv6.net (mail.nttv6.net [IPv6:2001:fa8::25]) by core3.amsl.com (Postfix) with ESMTP id BB1BE28C0E2 for ; Fri, 8 May 2009 00:05:54 -0700 (PDT) Received: from [192.47.163.152] ([IPv6:2001:fa8:1000:0:49ce:9676:5145:369a]) by mail.nttv6.net (8.14.3/8.14.3) with ESMTP id n4877JQB047528; Fri, 8 May 2009 16:07:19 +0900 (JST) (envelope-from akoba@nttv6.net) Date: Fri, 08 May 2009 16:05:59 +0900 From: Atsushi Kobayashi To: Atsushi Kobayashi In-Reply-To: <20090430194648.87E2.17391CF2@nttv6.net> References: <20090430104501.6385A3A71DC@core3.amsl.com> <20090430194648.87E2.17391CF2@nttv6.net> Message-Id: <20090508155450.D550.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.2 (mail.nttv6.net [IPv6:2001:fa8::25]); Fri, 08 May 2009 16:07:19 +0900 (JST) Cc: ipfix@ietf.org Subject: Re: [IPFIX] I-D Action:draft-ietf-ipfix-mediators-problem-statement-03.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, 08 May 2009 07:06:39 -0000 Dear IPFIX-chairs, Could you please call WG Last Call for the draft. I would like to submit the revised version including the feedbacks on WG Last Call until next IETF meeting. Regards, Atsushi KOBAYASHI On Thu, 30 Apr 2009 20:45:59 +0900 Atsushi Kobayashi wrote: > > Hi all, > > We finished up new version -03 mediation problem statement draft. > Although it is later than expected in SF meeting, we authors have > sufficiently discussed its wording, terminologies and technical issues. > All of issues are already solved, then it is ready for WG last call. > > Improvements are following: > > - Overall wording > - Terminology IPFIX concentrator have modification, correlation function > for Data Record them other than aggregation. > - In section 5, each implementation analysis describes more specific > mediation type(Concentrator, Dstributor, Proxy and Masquerading Proxy). > - In subsection 5.2, as an availability of hierarchical collecting > infrastructure, the variety of treatment on data record was added. > - In subsection 5.3, correlation function is divided by 3 types. > - In subsection 5.7, data retension subsection was improved as general > description. > - Subsection 6.6 "Consideration for Network Topology" is added. > - Subsection 6.7 "Exporting the Function Item" is added. > - Subsection 6.8 "Consideration for Aggregation" is added. > > Best Regards, > Atsushi KOBAYASHI > > On Thu, 30 Apr 2009 03:45:01 -0700 (PDT) > Internet-Drafts@ietf.org wrote: > > > 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 Mediation: Problem Statement > > Author(s) : A. Kobayashi, et al. > > Filename : draft-ietf-ipfix-mediators-problem-statement-03.txt > > Pages : 32 > > Date : 2009-04-30 > > > > 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. IPFIX Mediation covers two classes of mediation: > > context mediation for traffic data and transport mediation for > > transport protocols. This document describes the IPFIX Mediation > > applicability examples, along with some problems that network > > administrators have been facing. > > > > A URL for this Internet-Draft is: > > http://www.ietf.org/internet-drafts/draft-ietf-ipfix-mediators-problem-statement-03.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. > > --- > Atsushi KOBAYASHI > NTT Information Sharing Platform Lab. > tel:+81-(0)422-59-3978 fax:+81-(0)422-59-5637 > > _______________________________________________ > IPFIX mailing list > IPFIX@ietf.org > https://www.ietf.org/mailman/listinfo/ipfix --- Atsushi KOBAYASHI NTT Information Sharing Platform Lab. tel:+81-(0)422-59-3978 fax:+81-(0)422-59-5637 From muenz@net.in.tum.de Fri May 8 02:26: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 C2A1B28C261; Fri, 8 May 2009 02:26:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.155 X-Spam-Level: X-Spam-Status: No, score=-2.155 tagged_above=-999 required=5 tests=[AWL=0.094, 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 sZ-LakSvbrpO; Fri, 8 May 2009 02:26:50 -0700 (PDT) Received: from mail-out1.informatik.tu-muenchen.de (mail-out1.informatik.tu-muenchen.de [131.159.0.8]) by core3.amsl.com (Postfix) with ESMTP id 0DED93A6CF3; Fri, 8 May 2009 02:26:40 -0700 (PDT) Received: from phoenix.net.informatik.tu-muenchen.de (phoenix.net.informatik.tu-muenchen.de [131.159.14.1]) by services.net.informatik.tu-muenchen.de (Postix Mailer @ mail) with ESMTP id 71DCF47F7E; Fri, 8 May 2009 11:28:04 +0200 (CEST) Received: from [131.159.20.108] (repulse.net.informatik.tu-muenchen.de [131.159.20.108]) by phoenix.net.informatik.tu-muenchen.de (Postfix) with ESMTP id 5CC6A503D; Fri, 8 May 2009 11:28:04 +0200 (CEST) Message-ID: <4A03FB4D.1020007@net.in.tum.de> Date: Fri, 08 May 2009 11:28:45 +0200 From: Gerhard Muenz User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: Atsushi Kobayashi References: <547F018265F92642B577B986577D671C7009CF@VENUS.office> <20090508135102.D54A.17391CF2@nttv6.net> In-Reply-To: <20090508135102.D54A.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 , "MIB Doctors \(E-mail\)" Subject: Re: [IPFIX] AD review of draft-ietf-ipfix-mib-05.txt (ipfixExportEntry) 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, 08 May 2009 09:26:51 -0000 Dear Atsushi, You propose to split ipfixExportMemberType from -06 into two objects ipfixExportGroupType and ipfixExportMemberType with several interdependencies specified in the description clauses. At first sight, this does not seem to be easier to understand than the table structure in -06. Regards, Gerhard Atsushi Kobayashi wrote: > Dear Thomas, Benoit, Gerhard and all, > > Sorry for late reply. > > I have concerns about the modification for the following comment. > The MIB draft -06 was modified for the ipfixExportIndex to be located at > the end of indexes. But, I wonder the order of these indexes is > difficult to represent the Transport Session group. > > I prefer to keep the order of 3 tuple indexes > (ipfixMeteringProcessCacheId, ipfixTemplateObservationDomainId, > ipfixExportGroupIndex) in order to understand easily the result of > snmpwalk, even if the MIB structure changes a little bit. > >>> T16. ipfixExportEntry leads to a warning in the smicng compilation >>> >>> W: f(ipfix.mi2), (676,12) Row "ipfixExportEntry" does not have a >>> consistent indexing scheme - index items from current table must come >>> after index items from other tables >>> >> Since I have only libsmi (which does not catch this) I did not realize it. >> Fixed. > > I propose to add ExportGroupTable as follows. What do you think about it? > > -------------------------------------------------------------------- > -- 1.1.5: Export Group Table > -------------------------------------------------------------------- > ipfixExportGroupTable OBJECT-TYPE > SYNTAX SEQUENCE OF IpfixExportGroupEntry > MAX-ACCESS not-accessible > STATUS current > DESCRIPTION > "This table lists all export groups. > On Collectors this table is not needed." > ::= { ipfixMainObjects 5 } > > ipfixExportGroupEntry OBJECT-TYPE > SYNTAX IpfixExportGroupEntry > MAX-ACCESS not-accessible > STATUS current > DESCRIPTION > "Defines an entry in the ipfixExportGroupTable" > INDEX { > ipfixMeteringProcessCacheId, > ipfixTemplateObservationDomainId, > ipfixExportGroupIndex > } > ::= { ipfixExportGroupTable 1 } > > IpfixExportGroupEntry ::= > SEQUENCE { > ipfixExportGroupIndex Unsigned32, > ipfixExportGroupType INTEGER > } > > ipfixExportGroupIndex OBJECT-TYPE > SYNTAX Unsigned32 (1..4294967295) > MAX-ACCESS not-accessible > STATUS current > DESCRIPTION > "Locally arbitrary, but unique identifier of an entry in > the ipfixExportGroupTable. The value is expected > to remain constant from a re-initialization of the entity's > network management agent to the next re-initialization. > > A common ipfixExportGroupIndex between two entries from ipfix > Export table expresses that there is a relationship between the > Transport Sessions in ipfixTransportSessionIndex. The type > of Trasport Session group is expressed by the value of > ipfixExportMemberType." > ::= { ipfixExportGroupEntry 1 } > > ipfixExportGroupType OBJECT-TYPE > SYNTAX INTEGER { > unknown(0), > failover(1), > duplicate(2), > loadBalancing(3) > } > MAX-ACCESS read-only > STATUS current > DESCRIPTION > "The type of a Transport Session group > (identified by the value of ipfixExportGroupIndex, > ipfixObservationDomainId and ipfixMeteringProcessCacheId). > The following values are valid: > > unknown(0) > This value MUST be used if the status of the group > membership cannot be detected by the equipment. This > value should be avoided as far as possible. > > failover(1) > This value is used for a group member that is used as > the primary or secondary target of an Exporter. > This value MUST also be specified if the Exporter does > not support Transport Session grouping. In this case the > group contains only one Transport Session. > > duplicate(2) > This value is used for a group member that is used for > duplicate exporting i.e., all group members identified > by the ipfixExportIndex are exporting the same Records > in parallel. This implies that all group members MUST > have the the same membertype duplicate(3). > > loadBalancing(3) > This value is used for a group member that is used as > as one target for load-balancing. This means that a > Record is sent to one of the group members in this > group identified by ipfixExportIndex. > This implies that all group members MUST have the same > membertype load-balancing(4)." > ::= { ipfixExportGroupEntry 2 } > > > -------------------------------------------------------------------- > -- 1.1.6: Export Table > -------------------------------------------------------------------- > ipfixExportTable OBJECT-TYPE > SYNTAX SEQUENCE OF IpfixExportEntry > MAX-ACCESS not-accessible > STATUS current > DESCRIPTION > "This table lists all exports of an IPFIX device. > > On Exporters this table contains all exports grouped by > Transport Session, Observation Domain Id, Template Id and > Metering Process represented by the > ipfixMeteringProcessCacheId. Thanks to the ipfixExportGroupIndex > the exports can group one or more Transport Sessions to > achieve a special functionality like failover management, > load-balancing etc. The entries with the same > ipfixExportGroupIndex, the same ipfixObservationDomainId > and the same ipfixMeteringProcessCacheId define a Transport > Session group. If the Exporter does not use Transport > Session grouping then each ipfixGroupExportIndex contains a > single ipfixMeteringProcessCacheId and thus a singe > Transport Session and this session MUST have the member > type primary(1). Transport Sessions referenced in this > table MUST have the ipfixTransportSessionMode exporting(1). > > On Collectors this table is not needed." > ::= { ipfixMainObjects 6 } > > ipfixExportEntry OBJECT-TYPE > SYNTAX IpfixExportEntry > MAX-ACCESS not-accessible > STATUS current > DESCRIPTION > "Defines an entry in the ipfixExportTable" > INDEX { > ipfixMeteringProcessCacheId, > ipfixTemplateObservationDomainId, > ipfixExportGroupIndex, > ipfixTransportSessionIndex, > ipfixTemplateId > } > ::= { ipfixExportTable 1 } > > IpfixExportEntry ::= > SEQUENCE { > ipfixExportMemberType INTEGER > } > > ipfixExportMemberType OBJECT-TYPE > SYNTAX INTEGER { > unknown(0), > primary(1), > secondary(2) > } > MAX-ACCESS read-only > STATUS current > DESCRIPTION > "The type of a member Transport Session in a Transport > Session group (identified by the value of ipfixExportIndex, > ipfixObservationDomainId and ipfixMeteringProcessCacheId). > The following values are valid: > > unknown(0) > If the Transport Session group uses duplicate or load > balancing, the type of a member Transport Session MUST > have the member type unknown(0). > > primary(1) > This value is used for a group member that is used as > the primary target of an Exporter. Other group members > (with the same ipfixExportIndex and > ipfixMeteringProcessCacheId) MUST NOT have the value > primary(1) but MUST have the value secondary(2). > > secondary(2) > This value is used for a group member that is used as a > secondary target of an Exporter. The Exporter will use > one of the targets specified as secondary(2) within the > same Transport Session group when the primary target is > not reachable." > > ::= { ipfixExportEntry 1 } > > --- > Atsushi KOBAYASHI > NTT Information Sharing Platform Lab. > tel:+81-(0)422-59-3978 fax:+81-(0)422-59-5637 > > _______________________________________________ > IPFIX mailing list > IPFIX@ietf.org > https://www.ietf.org/mailman/listinfo/ipfix -- Dipl.-Ing. Gerhard Münz Chair for Network Architectures and Services (I8) Department of Informatics Technische Universität München 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 akoba@nttv6.net Fri May 8 04:06:38 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 475E83A682A; Fri, 8 May 2009 04:06:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.151 X-Spam-Level: X-Spam-Status: No, score=-0.151 tagged_above=-999 required=5 tests=[AWL=-0.350, 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 7QlOmjfWebIG; Fri, 8 May 2009 04:06:37 -0700 (PDT) Received: from mail.nttv6.net (mail.nttv6.net [IPv6:2001:fa8::25]) by core3.amsl.com (Postfix) with ESMTP id 1BABC3A6AA6; Fri, 8 May 2009 04:05:47 -0700 (PDT) Received: from [192.47.163.152] ([IPv6:2001:fa8:1000:0:49ce:9676:5145:369a]) by mail.nttv6.net (8.14.3/8.14.3) with ESMTP id n48B7CLt049205; Fri, 8 May 2009 20:07:13 +0900 (JST) (envelope-from akoba@nttv6.net) Date: Fri, 08 May 2009 20:05:52 +0900 From: Atsushi Kobayashi To: Gerhard Muenz In-Reply-To: <4A03FB4D.1020007@net.in.tum.de> References: <20090508135102.D54A.17391CF2@nttv6.net> <4A03FB4D.1020007@net.in.tum.de> Message-Id: <20090508194822.D55E.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.2 (mail.nttv6.net [IPv6:2001:fa8::25]); Fri, 08 May 2009 20:07:13 +0900 (JST) Cc: IETF IPFIX Working Group , "MIB Doctors \(E-mail\)" Subject: Re: [IPFIX] AD review of draft-ietf-ipfix-mib-05.txt (ipfixExportEntry) 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, 08 May 2009 11:06:38 -0000 Hi Gerhard, On Fri, 08 May 2009 11:28:45 +0200 Gerhard Muenz wrote: > You propose to split ipfixExportMemberType from -06 into two objects > ipfixExportGroupType and ipfixExportMemberType with several > interdependencies specified in the description clauses. > At first sight, this does not seem to be easier to understand than the > table structure in -06. Yes. Section 5.4 mentions tuple (ipfixExportIndex, ipfixMeteringProcessCacheId, ipfixTemplateObservationDomainId) indicates transport session group, but section 7 MIB structure does not seem to indicate what transport session group is. Although DESCRIPTION in ipfixExportTable mentions that "Thanks to the ipfixExportIndex the exports can group one or more Transport Sessions to achieve a special functionality like failover management, load-balancing etc.", actual table structure does not seem to group transport sessions by ipfixExportIndex. When I would like to look for which transport sessions belong to some specified transport session group, I have to see all of export table. For example, all of transport sessions belonging to the following transport session group (9:ipfixMeteringProcessCacheId, 3:ipfixTemplateObservationDomainId, 7:ipfixExportIndex) may be scattered in the export table. It does not allow us to utilize indexes of MIB structure. ipfixExportTable (5) | +- ipfixExportEntry (1) | +- index (9) (ipfixMeteringProcessCacheId) +- index (3) (ipfixTemplateObservationDomainId) +- index (257) (ipfixTemplateId) | +- index (5) (ipfixTransportSessionIndex) | +- index (7) (ipfixExportIndex) | +- ipfixExportIndex (1) = 7 | +- ipfixExportMemberType (2) = 1 (primary) | +- index (257) (ipfixTemplateId) | +- index (6) (ipfixTransportSessionIndex) | +- index (9) (ipfixExportIndex) | +- ipfixExportIndex (1) = 9 | +- ipfixExportMemberType (2) = 1 (primary) | +- index (264) (ipfixTemplateId) | +- index (5) (ipfixTransportSessionIndex) | +- index (8) (ipfixExportIndex) | +- ipfixExportIndex (1) = 8 | +- ipfixExportMemberType (2) = 2 (secondary) | +- index (273) (ipfixTemplateId) | +- index (11) (ipfixTransportSessionIndex) | +- index (7) (ipfixExportIndex) | +- ipfixExportIndex (1) = 7 | +- ipfixExportMemberType (2) = 2 (secondary) | +- index (289) (ipfixTemplateId) +- index (11) (ipfixTransportSessionIndex) +- index (8) (ipfixExportIndex) +- ipfixExportIndex (1) = 8 +- ipfixExportMemberType (2) = 1 (primary) Regards, Atsushi KOBAYASHI --- Atsushi KOBAYASHI NTT Information Sharing Platform Lab. tel:+81-(0)422-59-3978 fax:+81-(0)422-59-5637 From randy_presuhn@mindspring.com Fri May 8 10:28:38 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 95B6A3A6961; Fri, 8 May 2009 10:28:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.229 X-Spam-Level: X-Spam-Status: No, score=-1.229 tagged_above=-999 required=5 tests=[AWL=-1.044, BAYES_40=-0.185] 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 Kf8tmw2VdG-9; Fri, 8 May 2009 10:28:37 -0700 (PDT) Received: from elasmtp-kukur.atl.sa.earthlink.net (elasmtp-kukur.atl.sa.earthlink.net [209.86.89.65]) by core3.amsl.com (Postfix) with ESMTP id C5CFE3A67F1; Fri, 8 May 2009 10:28:37 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=mindspring.com; b=IJWCfVkLwtfWKcD9LE52EwFk4B/VKOmswIZyKUX4NfpXzC9g8NKH8rRI2GUutan1; h=Received:Message-ID:From:To:Cc:References:Subject:Date:MIME-Version:Content-Type:Content-Transfer-Encoding:X-Priority:X-MSMail-Priority:X-Mailer:X-MimeOLE:X-ELNK-Trace:X-Originating-IP; Received: from [69.3.146.20] (helo=oemcomputer) by elasmtp-kukur.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1M2TtZ-0002cg-JT; Fri, 08 May 2009 13:30:01 -0400 Message-ID: <006601c9d003$0b7eabe0$6801a8c0@oemcomputer> From: "Randy Presuhn" To: "Atsushi Kobayashi" , "Thomas Dietz" References: <547F018265F92642B577B986577D671C7009CF@VENUS.office> <20090508135102.D54A.17391CF2@nttv6.net> Date: Fri, 8 May 2009 10:33:03 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1478 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1478 X-ELNK-Trace: 4488c18417c9426da92b9037bc8bcf44d4c20f6b8d69d88884f945684cbf69683cca9fb0c540676be3bb7c24594fc7ac350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 69.3.146.20 X-Mailman-Approved-At: Fri, 08 May 2009 15:23:40 -0700 Cc: "MIB Doctors \(E-mail\)" , IETF IPFIX Working Group Subject: Re: [IPFIX] [MIB-DOCTORS] AD review of draft-ietf-ipfix-mib-05.txt(ipfixExportEntry) 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, 08 May 2009 17:28:38 -0000 Hi - > From: "Atsushi Kobayashi" > To: "Thomas Dietz" > Cc: "IETF IPFIX Working Group" ; "MIB Doctors (E-mail)" > Sent: Thursday, May 07, 2009 10:46 PM > Subject: Re: [MIB-DOCTORS] [IPFIX] AD review of draft-ietf-ipfix-mib-05.txt(ipfixExportEntry) ... > > > T16. ipfixExportEntry leads to a warning in the smicng compilation > > > > > > W: f(ipfix.mi2), (676,12) Row "ipfixExportEntry" does not have a > > > consistent indexing scheme - index items from current table must come > > > after index items from other tables > > > > > > > Since I have only libsmi (which does not catch this) I did not realize it. > > Fixed. This smicng warning can be misleading. There is no SMI requirement, nor is there even a recommendation, for having "a consistent indexing scheme." The order of indexes should be determined by: (1) the use cases for retrieving subsets of the table (2) ease of access control policy formulation. Making index order "consistent" can potentially defeat both of these objectives. Randy From akoba@nttv6.net Sun May 10 12:14:34 2009 Return-Path: X-Original-To: ipfix@core3.amsl.com Delivered-To: ipfix@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1F56D3A6E22; Sun, 10 May 2009 12:14:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.849 X-Spam-Level: X-Spam-Status: No, score=0.849 tagged_above=-999 required=5 tests=[AWL=-1.209, BAYES_20=-0.74, 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 XM9fyC0-VoPs; Sun, 10 May 2009 12:14:33 -0700 (PDT) Received: from mail.nttv6.net (mail.nttv6.net [IPv6:2001:fa8::25]) by core3.amsl.com (Postfix) with ESMTP id CCC663A6AFA; Sun, 10 May 2009 12:14:32 -0700 (PDT) Received: from [192.47.163.152] ([IPv6:2001:fa8:1000:0:ede3:e8cc:e1f:47bd]) by mail.nttv6.net (8.14.3/8.14.3) with ESMTP id n4AJFxWC020992; Mon, 11 May 2009 04:16:00 +0900 (JST) (envelope-from akoba@nttv6.net) Date: Mon, 11 May 2009 04:14:33 +0900 From: Atsushi Kobayashi To: "Randy Presuhn" In-Reply-To: <006601c9d003$0b7eabe0$6801a8c0@oemcomputer> References: <20090508135102.D54A.17391CF2@nttv6.net> <006601c9d003$0b7eabe0$6801a8c0@oemcomputer> Message-Id: <20090511034951.D567.17391CF2@nttv6.net> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable X-Mailer: Becky! ver. 2.50.05 [ja] (Unregistered) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.2 (mail.nttv6.net [IPv6:2001:fa8::25]); Mon, 11 May 2009 04:16:00 +0900 (JST) Cc: IETF IPFIX Working Group , "MIB Doctors \(E-mail\)" Subject: Re: [IPFIX] [MIB-DOCTORS] AD review of draft-ietf-ipfix-mib-05.txt(ipfixExportEntry) 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, 10 May 2009 19:14:34 -0000 Hi Randy, Gerhard, Thomas and all, > > > > T16. ipfixExportEntry leads to a warning in the smicng compilation > > > >=20 > > > > W: f(ipfix.mi2), (676,12) Row "ipfixExportEntry" does not have a > > > > consistent indexing scheme - index items from current table must co= me > > > > after index items from other tables > > > >=20 > > >=20 > > > Since I have only libsmi (which does not catch this) I did not realiz= e it. > > > Fixed. >=20 > This smicng warning can be misleading. There is no SMI requirement, nor = is > there even a recommendation, for having "a consistent indexing scheme." > The order of indexes should be determined by: > (1) the use cases for retrieving subsets of the table > (2) ease of access control policy formulation. >=20 > Making index order "consistent" can potentially defeat both of these > objectives. >=20 Thank you for your comments. =46rom viewpoint of (1), my conclusion is to keep the order of 3 indexes like that in -05 draft. - ipfixExportIndex, - ipfixMeteringProcessCacheId, - ipfixTemplateObservationDomainId, It is more suitable than my proposal. Regards, Atsushi KOBAYASHI ---=20 Atsushi KOBAYASHI NTT Information Sharing Platform Lab. tel:+81-(0)422-59-3978 fax:+81-(0)422-59-5637 From paitken@cisco.com Thu May 14 02:36: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 239B43A6A15 for ; Thu, 14 May 2009 02:36:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.106 X-Spam-Level: X-Spam-Status: No, score=-10.106 tagged_above=-999 required=5 tests=[AWL=0.493, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1BMDzy9XVuVY for ; Thu, 14 May 2009 02:36:16 -0700 (PDT) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by core3.amsl.com (Postfix) with ESMTP id 11ABC28C19B for ; Thu, 14 May 2009 02:36:11 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.41,193,1241395200"; d="scan'208";a="40561698" Received: from ams-dkim-2.cisco.com ([144.254.224.139]) by ams-iport-1.cisco.com with ESMTP; 14 May 2009 09:37:43 +0000 Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by ams-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id n4E9bh0X021845 for ; Thu, 14 May 2009 11:37:43 +0200 Received: from [10.61.88.40] (ams3-vpn-dhcp6185.cisco.com [10.61.88.40]) by ams-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id n4E9bhGT021149 for ; Thu, 14 May 2009 09:37:43 GMT Message-ID: <4A0BE667.7000000@cisco.com> Date: Thu, 14 May 2009 10:37:43 +0100 From: Paul Aitken User-Agent: Mozilla/5.0 (X11; U; Linux i686 (x86_64); en-GB; rv:1.8.1.21) Gecko/20090303 SeaMonkey/1.1.15 MIME-Version: 1.0 To: "ipfix@ietf.org" References: <4A060EBE.6060305@auckland.ac.nz> In-Reply-To: <4A060EBE.6060305@auckland.ac.nz> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=818; t=1242293863; x=1243157863; c=relaxed/simple; s=amsdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=paitken@cisco.com; z=From:=20Paul=20Aitken=20 |Subject:=20Re=3A=20IE=20errata |Sender:=20; bh=OrpWG37WYO6/t/TQ5SbqHIOyivIepvsjJFZIbDbPfjU=; b=V1Nv1VYBJF3bw3CpdkgurLTnL2z1EM9UPELzH3yoTByKVPHRfVlO/BhJCl Ef/UsJbrh9wPn8bo9p/oB3ZOpSw1FbqnIURctwcgrp+e51w81Iuks6613Pb7 zexSK3rj41; Authentication-Results: ams-dkim-2; header.From=paitken@cisco.com; dkim=pass ( sig from cisco.com/amsdkim2001 verified; ); Subject: Re: [IPFIX] IE errata X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 May 2009 09:36:17 -0000 Nevil Brownlee wrote: > Paul, can you post a list of the errata in those from > draft-aitken-ipfix-new-infos-03 to the IPFIX list, please? About a year ago, I realised that some of the RFC 5102 figures are back to front: http://www.ietf.org/mail-archive/web/ipfix/current/msg04383.html In March I opened four errata to track this: http://www.rfc-editor.org/errata_search.php?eid=1736 http://www.rfc-editor.org/errata_search.php?eid=1737 http://www.rfc-editor.org/errata_search.php?eid=1738 http://www.rfc-editor.org/errata_search.php?eid=1739 Subsequent thinking is that the diagrams are actually back to front *and* upside down. draft-aitken-ipfix-new-infos requires no further IANA actions. Thanks. -- Paul Aitken Cisco Systems Ltd, Edinburgh, Scotland. From Quittek@nw.neclab.eu Tue May 19 02:56:18 2009 Return-Path: X-Original-To: ipfix@core3.amsl.com Delivered-To: ipfix@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2E40D3A6C52 for ; Tue, 19 May 2009 02:56:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.634 X-Spam-Level: X-Spam-Status: No, score=-2.634 tagged_above=-999 required=5 tests=[AWL=-0.035, 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 bnSQp+G2Numc for ; Tue, 19 May 2009 02:56:17 -0700 (PDT) Received: from smtp0.neclab.eu (smtp0.neclab.eu [195.37.70.41]) by core3.amsl.com (Postfix) with ESMTP id D8DE03A70A1 for ; Tue, 19 May 2009 02:56:01 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp0.neclab.eu (Postfix) with ESMTP id 1FAC22C00C51C for ; Tue, 19 May 2009 11:57:38 +0200 (CEST) X-Virus-Scanned: Amavisd on Debian GNU/Linux (atlas2.office) Received: from smtp0.neclab.eu ([127.0.0.1]) by localhost (atlas2.office [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WPsFFZ4oB+GD for ; Tue, 19 May 2009 11:57:37 +0200 (CEST) Received: from VENUS.office (mx1.office [192.168.24.3]) by smtp0.neclab.eu (Postfix) with ESMTP id E030F2C00035C for ; Tue, 19 May 2009 11:57:32 +0200 (CEST) Received: from 10.1.2.178 ([10.1.2.178]) by VENUS.office ([192.168.24.102]) with Microsoft Exchange Server HTTP-DAV ; Tue, 19 May 2009 09:57:32 +0000 MIME-Version: 1.0 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-Type: multipart/signed; boundary="B_3325579055_7823434"; protocol="application/pkcs7-signature"; micalg=sha1 Content-class: urn:content-classes:message Date: Tue, 19 May 2009 11:57:35 +0200 Message-ID: X-MS-Has-Attach: yes X-MS-TNEF-Correlator: Thread-Topic: WG last call on draft-ietf-ipfix-mediators-problem-statement-03 Thread-Index: AcnYaDvn4EBxu9OTsESRV/uE9TH3/w== From: "Juergen Quittek" To: "IETF IPFIX Working Group" Subject: [IPFIX] WG last call on draft-ietf-ipfix-mediators-problem-statement-03 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, 19 May 2009 09:56:18 -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_3325579055_7823434 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Dear all, At our session on Monday we agreed to have working group last call on the next revision of the IPFIX mediation problem statement draft. Now it is available as draft-ietf-ipfix-mediators-problem-statement-03 and ready for WG last call. The call starts today and will last until Friday June 5. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ipfix-mediators-problem-state ment-03.txt 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_3325579055_7823434 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 YWIuZXUCBA0uKwcwCQYFKw4DAhoFAKBdMCMGCSqGSIb3DQEJBDEWBBQ5grdneAncVKpCqiZc wrxn99OCvTAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0wOTA1 MTkwOTU3MzVaMA0GCSqGSIb3DQEBAQUABIIBACXIFKihKuB0d0oUGE2ocaGa8i0OidZDiPK9 2B9V2+DwbqJtdprMMme6/sLoheSPG1r5/Wph/RpLT/eGrl2fPY0htljrZCErrl57+mQ5uC9j U64xzCkIj7AfbSVqkejImFTvUHYMv7neMHZkJL+DcLZ0zGqnr8aj2sdQVqppWKmaKvIb/+Z3 Dl+Ss4AoT7Y2hpnJPpnI+ngAUhkqWgW8eQ0zdU1VOZBPb6e53qXkZz5dz5l0xMTcDUvp4JXc dtFQk9J/3x7HDE9CRzipnjRIpYuXtPryBGmh29iJDyQDaW/KmafiYb35TOWY2SqnOqRj6H+2 LPKjtlh0x3grJdKxln0= --B_3325579055_7823434-- From Quittek@nw.neclab.eu Tue May 19 23:30: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 F105A28C137 for ; Tue, 19 May 2009 23:30:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.632 X-Spam-Level: X-Spam-Status: No, score=-2.632 tagged_above=-999 required=5 tests=[AWL=-0.033, 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 tAjykiYMhSBh for ; Tue, 19 May 2009 23:30:11 -0700 (PDT) Received: from smtp0.neclab.eu (smtp0.neclab.eu [195.37.70.41]) by core3.amsl.com (Postfix) with ESMTP id E209928C0FF for ; Tue, 19 May 2009 23:30:10 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp0.neclab.eu (Postfix) with ESMTP id 6035B2C01C8EC for ; Wed, 20 May 2009 08:31:47 +0200 (CEST) X-Virus-Scanned: Amavisd on Debian GNU/Linux (atlas2.office) Received: from smtp0.neclab.eu ([127.0.0.1]) by localhost (atlas2.office [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eX6my4tyJzqL for ; Wed, 20 May 2009 08:31:47 +0200 (CEST) Received: from VENUS.office (mx1.office [192.168.24.3]) by smtp0.neclab.eu (Postfix) with ESMTP id 2B9242C01918D for ; Wed, 20 May 2009 08:31:42 +0200 (CEST) Received: from 10.1.2.178 ([10.1.2.178]) by VENUS.office ([192.168.24.102]) with Microsoft Exchange Server HTTP-DAV ; Wed, 20 May 2009 06:31:42 +0000 MIME-Version: 1.0 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-Type: multipart/signed; boundary="B_3325653105_9538475"; protocol="application/pkcs7-signature"; micalg=sha1 Content-class: urn:content-classes:message Date: Wed, 20 May 2009 08:31:45 +0200 Message-ID: X-MS-Has-Attach: yes X-MS-TNEF-Correlator: Thread-Topic: IETF74 meeting minutes available Thread-Index: AcnZFKUkfOtLpNKj40Kd8dklrBKvkg== From: "Juergen Quittek" To: "IETF IPFIX Working Group" Subject: [IPFIX] IETF74 meeting minutes available X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 May 2009 06:30:12 -0000 > This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --B_3325653105_9538475 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Dear all, The minutes of our session in San Francisco are now available. Many thanks to Matt for taking them. Please check them at http://www.ietf.org/proceedings/09mar/minutes/ipfix.txt Thanks, Juergen --B_3325653105_9538475 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 YWIuZXUCBA0uKwcwCQYFKw4DAhoFAKBdMCMGCSqGSIb3DQEJBDEWBBSPJVU9EUXp1k5Ef/YN MVvOOnpp5TAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0wOTA1 MjAwNjMxNDVaMA0GCSqGSIb3DQEBAQUABIIBAJMGKTxjzbVMPCYWr3kp4BRWIYawWZaqYMUB URI3/TWM4Jw6XbgYeWBR2v7rVUwlAuZhTvce00CFxV2Wvx0tBNCuSbBXrDXpqJGFUE0Ym/ah pzz74S1bkxhyc5QZNISw8qB8tEcBZN8/VmA28G51mTJwaV8sVb4iJqu4xtEYmmYHJpHDDye0 ZruzA4FquFgR3l8SRJM36isFE3dMZGKsdcnQ6cHj3DRWmjZ0CQpa7gPkensYp0/tMYl/iFZ/ z+aMLCHjit7kunRl5oRoYLzxObKbZbPFfReHJWH82NnIUpYTQ+AheWOkSYhkY8XCuT1qg1AE phpcvmKapvg1zS8F8rI= --B_3325653105_9538475-- From root@core3.amsl.com Wed May 20 09:00:06 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 487BF28C2C5; Wed, 20 May 2009 09:00:01 -0700 (PDT) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20090520160006.487BF28C2C5@core3.amsl.com> Date: Wed, 20 May 2009 09:00:01 -0700 (PDT) Cc: ipfix@ietf.org Subject: [IPFIX] I-D Action:draft-ietf-ipfix-exporting-type-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, 20 May 2009 16:00:06 -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 : Exporting Type Information for IPFIX Information Elements Author(s) : E. Boschi, et al. Filename : draft-ietf-ipfix-exporting-type-04.txt Pages : 20 Date : 2009-05-20 This document describes an extension to the IP Flow Information Export (IPFIX) protocol, which is used to represent and transmit data from IP flow measurement devices for collection, storage and analysis, to allow the encoding of IPFIX Information Model properties within an IPFIX Message stream. This enables the export of extended type information for enterprise-specific Information Elements, and the storage of such information within IPFIX Files, facilitating interoperability and reusability among a wide variety of applications and tools. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ipfix-exporting-type-04.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-exporting-type-04.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2009-05-20085751.I-D@ietf.org> --NextPart-- From j.schoenwaelder@jacobs-university.de Wed May 20 15:00: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 069423A6C57 for ; Wed, 20 May 2009 15:00:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.093 X-Spam-Level: X-Spam-Status: No, score=-2.093 tagged_above=-999 required=5 tests=[AWL=0.156, 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 sBJ+Uy0rV6Z2 for ; Wed, 20 May 2009 15:00:06 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id 2F4253A6CB3 for ; Wed, 20 May 2009 15:00:06 -0700 (PDT) Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id EEBE0C0081; Thu, 21 May 2009 00:01:42 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius2.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id 09okPybRqh-Z; Thu, 21 May 2009 00:01:41 +0200 (CEST) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 8098EC0028; Thu, 21 May 2009 00:01:41 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id D02E9B1B942; Thu, 21 May 2009 00:01:40 +0200 (CEST) Date: Thu, 21 May 2009 00:01:40 +0200 From: Juergen Schoenwaelder To: Juergen Quittek Message-ID: <20090520220140.GA6311@elstar.local> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.19 (2009-01-05) Cc: IETF IPFIX Working Group Subject: Re: [IPFIX] WG last call on draft-ietf-ipfix-mediators-problem-statement-03 X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 May 2009 22:00:13 -0000 On Tue, May 19, 2009 at 11:57:35AM +0200, Juergen Quittek wrote: > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-ipfix-mediators-problem-state > ment-03.txt > > Please read the draft! I have read the draft and I think it is basically ready to go. There are a few sentences that I found difficult to read and later on I started to write down some nits. * 5.1: s/Even if the case/Even in the case/ * 5.8: s/if multiple Flow Records type/if multiple Flow Records types/ * 6.1: s/a specific way to the/a specific way to pass the/ * 6.6: s/the summing up the/summing up the/ * 6.8: I am not how to read 'when aggregation resulting from Sampling' in this sentence: There is no obvious rules of how to compute Configured Selection Fraction, and whether a Mediator should report Configured Selection Fraction, when aggregation resulting from Sampling. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From muenz@net.in.tum.de Tue May 26 05:47:10 2009 Return-Path: X-Original-To: ipfix@core3.amsl.com Delivered-To: ipfix@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A6FD83A70C3 for ; Tue, 26 May 2009 05:47:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.858 X-Spam-Level: X-Spam-Status: No, score=-1.858 tagged_above=-999 required=5 tests=[AWL=-0.209, 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 hNN-+3yN5Yu9 for ; Tue, 26 May 2009 05:47:00 -0700 (PDT) Received: from mail-out1.informatik.tu-muenchen.de (mail-out1.informatik.tu-muenchen.de [131.159.0.8]) by core3.amsl.com (Postfix) with ESMTP id 714863A70DD for ; Tue, 26 May 2009 05:46:15 -0700 (PDT) Received: from phoenix.net.informatik.tu-muenchen.de (phoenix.net.informatik.tu-muenchen.de [131.159.14.1]) by services.net.informatik.tu-muenchen.de (Postix Mailer @ mail) with ESMTP id 54D4548784 for ; Tue, 26 May 2009 14:47:13 +0200 (CEST) Received: from [131.159.20.108] (repulse.net.informatik.tu-muenchen.de [131.159.20.108]) by phoenix.net.informatik.tu-muenchen.de (Postfix) with ESMTP id 3B01049B2 for ; Tue, 26 May 2009 14:47:13 +0200 (CEST) Message-ID: <4A1BE50E.6040407@net.in.tum.de> Date: Tue, 26 May 2009 14:48:14 +0200 From: Gerhard Muenz User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: IETF IPFIX Working Group References: In-Reply-To: Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms090204060304030906090205" X-Virus-Scanned: ClamAV using ClamSMTP Subject: Re: [IPFIX] WG last call on draft-ietf-ipfix-mediators-problem-statement-03 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, 26 May 2009 12:47:10 -0000 This is a cryptographically signed message in MIME format. --------------ms090204060304030906090205 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Dear Atsushi, all, Find below my comments for draft-ietf-ipfix-mediators-problem-statement-0= 3 I think the purpose of the document is much clearer now. Apart from the terminology and the introduction, which should be rewritten, the document is in a good shape. In my opinion, the terminology related to Mediation must be rethought another time before publishing this problem statement as an RFC. The current terminology section defines the following terms: *IPFIX Mediation* =3D a function *IPFIX Concentrator, IPFIX (Masq.) Proxy, IPFIX Distributor* =3D specific types of IPFIX Mediation *IPFIX Mediator* =3D devices that implements IPFIX Mediation This terminology has several flaws: - On the one hand, you have troubles to distinguish between IPFIX Mediation implemented at an "Original Exporter" and IPFIX Mediation implemented at a "separate IPFIX Mediator/Concentrator/...". - On the other hand, the terms do not fit into the current terminology scheme of IPFIX and PSAMP, where we are used to "XXX Process" when we talk about the instantiation of a specific function. - Finally, the definition of IPFIX Concentrator does not correspond to the usage of this term in RFC3917. There, a Concentrator is a device, not a function. I like the approach that has been chosen by PSAMP. There, we distinguish between "Selectors" (which are abstract selection functions) and "Selection Processes" (which are instantiations of Selectors). Selection Processes are finally part of Devices (i.e., PSAMP Exporters). I suggest to apply this approach to Mediation as well. In the case of Mediation, we would have abstract Mediation Functions (anonymization, aggregation, sampling, proxy, distribution). These would be instantiated in a Mediation Process. A Mediation Process can then be part of an Exporter (Original Exporter), Collector, or Mediator. Regards, Gerhard > Abstract >=20 > 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. IPFIX Mediation covers two classes of mediation: > context mediation for traffic data and transport mediation for content mediation > transport protocols. This document describes the IPFIX Mediation > applicability examples, along with some problems that network > administrators have been facing. > 1. Introduction >=20 > While the IPFIX requirements defined in [RFC3917] mention an > intermediate function, such as an IPFIX Proxy or an IPFIX > Concentrator, there are no documents defining the function called > IPFIX Mediation. IPFIX Mediation is a generic function that covers > the manipulation of IPFIX Flow Records, PSAMP Packet Reports, entire= > IPFIX Messages, or their transmission. This document describes > general problems, applicability examples, and defines the terminolog= y > (IPFIX Proxy, Concentrator, etc.) for referring to different use > cases for IPFIX Mediation. Furthermore, some specific problems > related to the IPFIX protocol [RFC5101] when applying IPFIX Mediatio= n > are addressed. The only motivation for IPFIX Mediation given in this introduction is that the term has not yet defined in any document. This cannot be a reason for publishing an RFC ;) I would like to see a much stronger motivation elaborating the arguments and problems of the abstract. > 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 Definition Definitions > The terms in this section are in line with those in the IPFIX > Protocol specifications [RFC5101] and the PSAMP specification > document [RFC5476]. The terms Observation Point, Observation Domain= , > Flow Key, Flow Record, Data Record, Exporting Process, Exporter, > IPFIX Device, Collecting Process, Collector, IPFIX Message, Metering= > Process, Transport Session, Information Element, and Template > Withdrawal Message, are defined in the IPFIX protocol specifications= > [RFC5101]. The terms Packet Report, Sampling, Filtering, PSAMP > Device, and Configured Selection Fraction are defined in the PSAMP > specification document [RFC5476]. Furthermore, new terminology to b= e > used in the context of IPFIX Mediation is defined in this section. > All these terms have an initial capital letter in this document. > > While IPFIX Mediation can process both Flow Records and Packet > Reports, this document prefers the more generic "Data Record" term a= s > this is a more generic term, unless the reference to the IPFIX Flow > Record or PSAMP Packet Report is required. > this is a more generic term, unless the reference to the IPFIX Flow > Record or PSAMP Packet Report is required. better: "IPFIX Mediation can process IPFIX Flow Records, PSAMP Packet Reports, and Data Records defined by Options Templates. In this document, we use the generic term "Data Record" for all of these unless an explicit distinction is required." > IPFIX Mediation >=20 > IPFIX Mediation is a generic function that covers the manipulatio= n remove "generic" ? > of IPFIX Flow Records, PSAMP Packet Reports, or entire IPFIX > Messages, or their transmission. The IPFIX Mediation offers one Could be read as "covers the transmission of...", which would make an Exporting Process a Mediation function. Also, you sentence does not include "Options Data Records" (I put this in quotes because it is not an official term). maybe: "...covers the manipulation of the content and transmission of Data Records and IPFIX Messages." > or multiple of the following capabilities: >=20 > * content mediation that changes Flow Records/Packet Reports > information >=20 > + aggregating Flow Records/Packet Reports based on a new set > of Flow Key fields >=20 > + correlating a set of Flow Records/Packet Reports >=20 > + filtering and selecting Flow Records/Packet Reports >=20 > + modifying Flow Records/Packet Reports, including: >=20 > - changing the value of specified Information Elements >=20 > - adding new Information Elements by deriving further Flow= > or packet properties from existing fields (for example: > calculating new metrics or new counters) >=20 > - deleting specified Information Elements in the whole definition: s/Flow Records\/Packet Reports/Data Records > * transport mediation >=20 > + changing the transport protocol that carries IPFIX Messages= >=20 > + rerouting entire IPFIX Messages to an appropriate Collectin= g > Process rerouting =3D> relaying ? > + replicating Flow Records/Packet Reports (or the entire IPFI= X > Messages) s/Flow Records\/Packet Reports/Data Records > IPFIX Mediator >=20 > An IPFIX Mediator is an IPFIX Device that implements one or more > IPFIX Mediation capabilities. Examples are devices such as > routers, switches, network management systems (NMS), etc. >=20 > Original Exporter >=20 > An Original Exporter is an IPFIX Device that hosts the Observatio= n > Points where the metered IP packets are observed. >=20 > IPFIX Proxy >=20 > An IPFIX Proxy is a type of IPFIX Mediation that relays incoming remove "An" > Transport Sessions to one or multiple Collectors. The protocols > used at the input and the output can be different, which implies > that IPFIX Messages, Data Records, and Template Records need to b= e > encoded, e.g., for converting from a legacy protocol to IPFIX. A= n > IPFIX Proxy is not implemented on the Original Exporter, but as a= > separate Mediator. I would remove the last sentence. Otherwise, you need to explain what you mean by "separate Mediator". > IPFIX Concentrator >=20 > An IPFIX Concentrator is a type of IPFIX Mediation that receives > Flow Records/Packet Reports, correlates them, aggregates them, or= s/Flow Records\/Packet Reports/Data Records > modifies them, then exports the new Data Records. >=20 > IPFIX Distributor >=20 > An IPFIX Distributor is a type of IPFIX Mediation that distribute= s > Data Records to one or multiple IPFIX Collectors. The decision a= s > to which IPFIX Collector a Data Record is exported can be > determined by filtering certain field values or other properties > derived from the Data Record. >=20 > IPFIX Masquerading Proxy >=20 > An IPFIX Masquerading Proxy is a type of IPFIX Mediation that > screens out parts of input Flow Records/Packet Reports according s/Flow Records\/Packet Reports/Data Records > to configured policies. It can thus, for example, hide the > network topology information or customers' IP addresses. > 3. IPFIX/PSAMP Documents Overview >=20 > 3.1. IPFIX Documents Overview >=20 > The IPFIX protocol [RFC5101] provides network administrators with > access to IP flow information. The architecture for the export of > measured IP flow information out of an IPFIX Exporting Process to a > Collecting Process is defined in [RFC5470], per the requirements > defined in [RFC3917]. The IPFIX protocol [RFC5101] specifies how > IPFIX Data Records and Templates are carried via a number of > transport protocols from IPFIX Exporting Processes to IPFIX > Collecting Processes. IPFIX has a formal description of IPFIX > Information Elements, their names, types, and additional semantic > information, as specified in [RFC5102]. [I-D.ietf-ipfix-mib] > specifies the IPFIX Management Information Base. Finally, [RFC5472]= > describes what types of applications can use the IPFIX protocol and > how they can use the information provided. It furthermore shows how= > the IPFIX framework relates to other architectures and frameworks. > The storage of IPFIX Messages in a file is specified in > [I-D.ietf-ipfix-file]. >=20 > 3.2. PSAMP Documents Overview >=20 > The framework for packet selection and reporting [RFC5474] enables > network elements to select subsets of packets by statistical and > other methods and to export a stream of reports on the selected > packets to a Collector. The set of packet selection techniques > (Sampling, Filtering, and Hashing) standardized by PSAMP are > described in [RFC5475]. The PSAMP protocol [RFC5476] specifies the > export of packet information from a PSAMP Exporting Process to a > Collector. Like IPFIX, PSAMP has a formal description of its > Information Elements, their names, types and additional semantic > information. The PSAMP information model is defined in [RFC5477]. > [I-D.ietf-psamp-mib] describes the PSAMP Management Information Base= =2E > 4. Problem Statement >=20 > 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 > measurement system while pursuing appropriate conditions: data pursuing =3D> fulfilling ? > accuracy, flow granularity, and export reliability. These condition= s > depend on two factors. >=20 > o measurement systems capacity: > This consists of the bandwidth of the management network, the > storage capacity, and the performances of the collecting devices > and exporting devices. >=20 > o applications requirements: > Different applications, such as traffic engineering, detecting > anomaly traffic, and accounting, etc., impose different Flow traffic anomalies > Record granularity, and data accuracy. >=20 > The recent continued IP traffic growth has been overwhelming the "The sustained growth of IP traffic..." ? > measurement system capacity, and multi-purposing applications, along= multi-purpose? Yet, it is not clear to me what you mean. > with the heterogeneous environments, have further been contributing > to a complex situation. The following sub-sections explain differen= t > problems in more details. >=20 > 4.1. Coping with IP Traffic Growth >=20 > 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 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. >=20 > To deal with this problem, current data reduction techniques, such a= s > Sampling, Filtering, Data Records aggregation have been generally For me, "aggregation" refers to the semantic level of exported information. Therefore, I would call it "flow aggregation" instead of "Data Record aggregation". > implemented on Exporters. Note that Sampling technique leads to Sampling technique =3D> packet sampling ? > potential loss of small Flows. With both Sampling and aggregation > techniques, administrators might no longer be able to investigate > very granular traffic change and anomaly detection, both of which ca= n "...able to detect and investigate subtle traffic changes and anomalies as this requires detailed flow information." ? > currently be detected. With Filtering, only a subset of the Flow Data Records > Records are exported. >=20 > 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. >=20 > 4.2. Coping with Multipurpose Traffic Measurement >=20 > A set of conditions (flow granularity and data accuracy) may meet th= e "conditions" does not seem to be an appropriate word. > requirements of some applications, such as traffic engineering, but > may not meet the requirements of other applications, such as > accounting, QoS performance, or even security. Therefore, with a > single set of conditions, multipurpose traffic measurements cannot b= e > accomplished. > > To cope with the issue, an Exporter needs to export traffic data wit= h > strictest condition (fine flow granularity and high data accuracy) > required by the set of applications. However, this implies an > increased load on both the Exporter and Collector. I would change the whole section to something like: "Different monitoring applications, such as ..., 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 >=20 > 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 > capability, Exporting Process capacity (export rate, cache memory, capabilities > etc.), and data format. For example, probes and switches cannot > retrieve packet property information from a route table. Do you mean AS information? > To deal with this problem, the collecting infrastructure needs to > absorb the differences. However, equipping all collecting devices absorb =3D> mediate? > with this absorption function is difficult. >=20 > 4.4. Summary >=20 > In optimizing the resources of a measurement system, it is important= > to use traffic data reduction techniques at the possible initial "at the possible initial phase" =3D> "as early as possible" > phase, e.g., at the Exporter. However, this implementation is made > difficult by heterogeneous environment of exporting devices. >=20 > This implies that a new Mediation functional block is required in Mediation function > 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 Mediatio= n > benefits. > 5. Mediation Applicability Examples >=20 > 5.1. Adjusting Flow Granularity >=20 > The simplest types of Flows are those comprised of packets all havin= g > a fixed IP-quintuple of protocol, source and destination IP > addresses, and source and destination port numbers. However, a > shorter set of Flow Keys, such as a triple, a double, or a single > Flow Key, (for example network prefix, peering AS number, or BGP > Next-Hop fields), creates more aggregated Flow Records. This is > especially useful for measuring traffic exchange in an entire networ= k > domain and for easily adjusting the performance of Exporters and > Collectors. >=20 > Implementation analysis: >=20 > Implementations for this case depend on where Flow granularity is= > adjusted. More suitable implementations use configurable Meterin= g > 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 creates directly aggregated Flow > Records. >=20 > In the case where the Original Exporter contains a Metering > Process that creates fixed tuple Flow Records (no possibility to > change the Flow Keys), an IPFIX Concentrator can adjust the Flow > Keys by aggregation Flow Records. Even if 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. >=20 > 5.2. Hierarchical Collecting Infrastructure >=20 > The increase of IPFIX Exporters, the increase of the traffic over over =3D> in ? > large-scale networks, and the variety of treatments expected to be > performed over the Data Records is more and more difficult to handle= > within a single Collector. Hence to increase the collecting (e.g. > the bandwidth capacity) and processing capacity must be distributed Something is missing in this sentence. What about: "Hence to increase the collecting (e.g., the bandwidth capacity) and processing capacity, distributed Collectors must be deployed." > over several IPFIX entities. As a possible approach, a hierarchical= > structure is useful for increasing the measurement systems capacity,= > both in export bandwidth capacity and in collecting capacity. >=20 > Implementation analysis: >=20 > To cope with the increase of IPFIX Exporters and traffic, one > possible implementation uses IPFIX Concentrators to build a > hierarchical collection system. To cope with the variety of > treatments, one possible implementation uses IPFIX Distributors t= o > build a distributed collection system. More specific cases are > described in section 5.9. >=20 > 5.3. Correlation for Data Records >=20 > The correlation amongst Data Records or between Data record and meta= Record > data provides new metrics or information, including the following. >=20 > o One-to-one correlation between Data Records >=20 > * One way delay and packet arrival interval time etc. One way packet arrival interval time =3D> packet inter-arrival time ? > delay from the correlation of Packet Reports from different PSAMP Packet Reports? > Exporters along a specific path. >=20 > * Treatment from the correlation of Data Records with the same IPFIX Flow Records? > Flow Key(s) observed at incoming/outgoing interfaces. Example= s > are the rate-limiting ratio, the compression ratio, the > optimization ratio, etc. At the recent TMA workshop, it was proposed to correlate Flow Records from ingress and egress routers to determine packet loss on the path (A. Friedl et al.: "Realistic Passive Packet Loss Measurement for High-Speed Networks") This could be another use-case for correlating Flow Records. > o Correlation amongst Data Records >=20 > Average/maximum/minimum values from correlating multiple Data > Records. Examples are the average/maximum/minimum packets of number of packets of the measured Flows > Flow, the average/maximum/minimum one way delay, the average/ > maximum/minimum packet loss, etc. number of lost packets > o Correlation between Data Record and other meta data >=20 > Examples are some BGP attributes associated with Data Record by > looking up routing table. the routing table ? > Implementation analysis: >=20 > One possible implementation for the case uses an IPFIX this case > Concentrator located between the Metering Processes and Exporting= > Processes on the Original Exporter, or alternatively a separate > IPFIX Concentrator located between the Original Exporters and > IPFIX Collectors. >=20 > 5.4. Time Composition >=20 > Time composition is defined as the aggregation of consecutive Data in this case: IPFIX Flow Records > Records with identical Flow Keys. It leads to the same output as > setting a longer active interval timer on Original Exporters with on= e > advantage: the creation of new metrics such as average, maximum and > minimum values from Flow Records with a shorter time interval enable= s > administrators to keep track of changes that might have happened > during the time interval. >=20 > Implementation analysis: >=20 > One possible implementation for this case uses an IPFIX > Concentrator located between the Metering Processes and Exporting= > Processes on the Original Exporter, or alternatively as a separat= e remove "as" > IPFIX Concentrator located between the Original Exporters and > IPFIX Collectors. >=20 > 5.5. Spatial Composition >=20 > 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. >=20 > o Case 1: Spatial Composition within one Observation Domain >=20 > For example, in the case where a link aggregation exists, Data > Records observed at physical interfaces belonging to the same You do not "observe" Data Records. Maybe: "...Data Records with information measured at..." > trunk can be merged. >=20 > o Case 2: Spatial Composition across Observation Domains, but withi= n > a single Exporter >=20 > For example, in the case where a link aggregation exists, Data > Records observed at physical interfaces belonging to a same trunk= "...Data Records with information measured at..." > grouping beyond the line interface module can be merged. >=20 > o Case 3: Spatial Composition across Exporters >=20 > Data Records observed within an administrative domain, such as th= e "...Data Records with information measured at..." > west area and east area of an ISP network, can be merged. >=20 > o Case 4: Spatial Composition across administrative domains >=20 > Data Records observed across administrative domains, such as "...Data Records with information measured at..." > across different customer networks or different ISP networks, can= > be merged. >=20 > Implementation analysis: >=20 > One possible implementation for the case 1 and 2 uses an IPFIX cases > Concentrator located between the Metering Processes and Exporting= > Processes on the Original Exporter. A separate IPFIX Concentrato= r > located between the Original Exporters and IPFIX Collector is a > valid solution for the case 1, 2, 3, and 4. cases > 5.6. Data Record Anonymization >=20 > 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 as described in the previous subsection on "spacial composition across administrative domaines". > administrative domains in the previous subsection. > In such case, administrators need to adhere to privacy protection In such a case... > policies and prevent access to confidential traffic measurements by > other people. Typically, anonymization techniques enables the > provision of traffic data to other people without violating these > policies. >=20 > 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 canno= t > be traced back to the specific networks, hosts, or users generating > the traffic. For example, IP address anonymization is particularly > important for avoiding the identification of the users, hosts, and > routers. >=20 > Implementation analysis: >=20 > 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. >=20 > 5.7. Data Retention >=20 > Data retention refers to the storage of traffic data by service > providers and commercial organizations. Network administrators administrators =3D> operators ? > should retain both IP and voice traffic data, in wired and wireless "should retain" sounds like "SHOULD retain", which is definitively not what we want to specify in an IETF standard. Better something like: "Legislative regulations often require that network operators retain..." What do you mean by "voice traffic data"? As far as I known, records of VoIP connections are to be retained, but not the voice data. I assume that wiretapping telephone calls must be explicitly requested by a judge in must democratic countries. It does not fall under the general data retention policies. > networks, generated by end users while using a service provider's > services. The traffic data is required for the purpose of the > investigation, detection and prosecution of serious crime, if > necessary. Data retention services examples are the following: >=20 > o Fixed telephony (includes fixed voice calls, voicemail, and > conference and data calls) >=20 > o Mobile telephony (includes mobile voice calls, voicemail, > conference and data calls, SMS, and MMS) >=20 > o Internet telephony (includes every multimedia session associated > with IP multimedia services) >=20 > o Internet e-mail >=20 > o Internet access >=20 > Data retention for Internet access services in particular requires a= > measurement system with reliable export and huge storage as the data= > must be available for a long period of time, typically a couple of > years. A couple of years sounds unrealistic. As far as I know, it's six months in the EU. Longer retention times are usually prevented by privacy laws.= > Implementation analysis: >=20 > Regarding export reliability requirement, the most suitable > implementation uses the SCTP transport protocol between the > Original Exporter and Collector. If a unreliable transport an unreliable > protocol such as UDP is used, a legacy exporting device exports > Data Records to a nearby IPFIX Proxy through UDP, and then an > IPFIX Proxy could reliably export them to the top IPFIX Collector= > through SCTP. If a unreliable transport protocol such as UDP is > used and if there is no IPFIX Proxy, the legacy exporting device > must duplicate the exports to several Collectors. I would remove the last sentence. Losses are provoked by congestion. Doubling the exported data increases the risk of congestion. > Regarding huge storage requirement, one possible implementation > uses a decentralized set of Collectors. If administrators need t= o > retrieve specific Data Records, these Collectors would need to be= > equipped with IPFIX Mediations. >=20 > 5.8. IPFIX Export from a Branch Office >=20 > Generally, in large enterprise networks, Data Records from branch > offices are gathered in a central office. However, in the long > distance branch office case, the bandwidth for transport IPFIX is > limited. Therefore, even if multiple Flow Records type should be of= Data Record types? > interest to the Collector (Flow Records in both directions, Flow "(e.g., IPFIX Flow Records for both directions,...)" > Records before and after WAN optimization techniques, performance > metrics associated with the Flow Records exported on regular > interval), the export bandwidth limitation is an important factor to= > pay attention to. >=20 > Implementation analysis: >=20 > One possible implementation for the case uses an IPFIX this case > Concentrator located in a branch office. The IPFIX Concentrator > would aggregate and correlate Flow Records to cope with the expor= t Data Records? > bandwidth limitation. >=20 > 5.9. Distributing Data Records >=20 > Recently, several networks have shifted towards integrated networks,= > such as the pure IP and MPLS, which includes IPv4, IPv6, and VPN "pure IP and MPLS networks"? > traffic. Data Record types (IPv4, IPv6, MPLS, and VPN) need to be > analyzed separately and from different perspectives for different > organizations. A single Collector handling all Data Record types > might become a bottleneck in the collecting infrastructure. Data > Records distributed based on their respective types can be exported > to the appropriate Collector, resulting in the load distribution > amongst multiple Collectors. >=20 > Implementation analysis: >=20 > One possible implementation for this case uses the replications o= f > the IPFIX Message in an Original Exporter for multiple IPFIX > Collectors. Each Collector then extracts the Data Record require= d > by its own applications. However, the replication increases the > load of the Exporting Process and the waste of the bandwidth > between the Exporter and Collector. >=20 > A more sophisticated implementation uses an IPFIX Distributor > located between the Metering Processes and Exporting Processes in= > an Original Exporter. The IPFIX Distributor determines > respectively to which Collector a Data Record is exported by remove "respectively"? > filtering certain field values. If a Original Exporter does not "by filtering..." =3D> "depending on certain field values" > have IPFIX Distributor capability, it exports Data Records to a > nearby separate IPFIX Distributor, and then the IPFIX Distributor= > could distribute them to the appropriate IPFIX Collectors. >=20 > For example, in the case of distributing a specific customer's > Data Records, an IPFIX Distributor needs to identify the customer= > networks. The Route Distinguisher (RD), ingress interface, > peering AS number, or BGP Next-Hop, or simply the network prefix > may be evaluated to distinguish different customer networks. In > the following figure, the IPFIX Distributor reroutes Data Records= > on the basis of the RD value. This system enables each customer'= s > traffic to be inspected independently. >=20 > .---------. > |Traffic | > .---->|Collector|<=3D=3D>Custo= mer#A > | |#1 | > | '---------' > RD=3D100:1 > .----------. .-----------. | > |IPFIX | |IPFIX |----' .---------. > |Exporter#1| |Distributor| RD=3D100:2 |Traffic | > | |------->| |--------->|Collector|<=3D=3D>Custo= mer#B > | | | | |#2 | > | | | |----. '---------' > '----------' '-----------' | > RD=3D100:3 > | .---------. > | |Traffic | > '---->|Collector|<=3D=3D>Custo= mer#C > |#3 | > '---------' >=20 > Figure A: Distributing Data Records to Collectors using IPFIX > Distributor >=20 > 5.10. Flow-based Sampling and Selection >=20 > 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 measuremen= t > 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. >=20 > Implementation analysis: >=20 > One possible implementation for this case uses an IPFIX > Concentrator located between the Metering Processes and Exporting= > Processes on the Original Exporter, or alternatively as a separat= e > 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 Filtering, Sampling ? > Concentrator. >=20 > 5.11. Interoperability between Legacy Protocols and IPFIX >=20 > During the migration process from a legacy protocol such as NetFlow > [RFC3954] to IPFIX, both NetFlow exporting devices and IPFIX > Exporters are likely to coexist in the same network. Operators need= > to continue measuring the traffic data from legacy exporting devices= , > even after introducing IPFIX Collectors. >=20 > Implementation analysis: >=20 > One possible implementation for this case uses an IPFIX Proxy tha= t > converts a legacy protocol to IPFIX. > 6. IPFIX Mediators Implementation Specific Problems >=20 > 6.1. Loss of Original Exporter Information >=20 > Both the Exporter IP address indicated by the source IP address of > the IPFIX Transport Session and the Observation Domain ID included i= n > the IPFIX Message header are likely to be lost by an IPFIX Mediator "lost during IPFIX Mediation."? > such as IPFIX Concentrator too. In some cases, a IPFIX Masquerading= remove "such as IPFIX Concentrator" > Proxy might drop the information. In other cases, the Collector mus= t "...might drop the information deliberately" ? > recognize the Original Exporter (and potentially the Observation > Domain and Observation Point as well) whether Data Records go throug= h rephrase: "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." > an IPFIX Mediator or not. Note that, if the Mediator can not > communicate the Original Exporter IP address, then the top level > Collector will wrongly deduce that the IP address of the IPFIX > Mediator is that of the Original Exporter. >=20 > 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 Mediato= r > must have a specific way to the Original Exporter IP address to the "must be able to notify the Collector about the IP address of the Original Exporter." > IPFIX Collector. >=20 > .----------. .--------. > |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 >=20 > Figure B: Loss of Original Exporter Information. >=20 > 6.2. Loss of Base Time Information >=20 > The Export Time field included in the IPFIX Message header indicates= > the base time for Data Records. IPFIX Information Elements, "...indicates the base time" =3D> "...represents a reference timestamp...= " " _Some_ IPFIX Information Elements..." > described in [RFC5102], have delta time fields that indicate the tim= e "have delta time fields" =3D> "carry delta timestamps" ? > 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. >=20 > 6.3. Transport Sessions Management >=20 > Maintaining relationships between the incoming Transport Sessions an= d > the outgoing ones depends on the Mediator's implementation. If Better: "If an IPFIX Mediator relays multiple incoming Transport Sessions to a single outgoing Transport Session, ..." > multiple incoming Transport Sessions are relayed to a single outgoin= g > Transport Session, and if the IPFIX Mediators shuts down its outgoin= g > Transport Session, Data Records on other incoming Transport Sessions= "... Data Records of the incoming Transport Sessions would not be relayed any more." > would not be relayed at all. In the case of resetting of an incomin= g remove "of" > session, the behavior of the IPFIX Mediator needs to be specified. >=20 > 6.4. Loss of Option Template Information >=20 > In some cases, depending on the implementation of the IPFIX > Mediators, the information that is reported by the Option Templates "...reported in the Data Records defined by Option Templates..." > could also be lost. If, for example, the Sampling rate is not > communicated from the Mediator to the Collector, the Collector would= > miscalculate the traffic volume. This might lead to crucial > problems. Even if an IPFIX Mediator was to simply relay received > Option Template Information, the values of its scope fields could "Option Data Records"? Yet this is not an official term either. > become meaningless in the context of a different Transport Sessions.= > The minimal information to be communicated by an IPFIX Mediator must= > be specified. >=20 > 6.5. Template ID Management >=20 > The Template ID is unique on the basis of the Transport Session and > Observation Domain ID. If Mediations are not able to manage the "Mediations are" =3D> "IPFIX Mediation is" > relations amongst the Template IDs and the incoming Transport Sessio= n > information, and if the Template ID is used in the Options Template > scope, the Mediators would, for example, relay wrong values in the "the Mediators" =3D> "IPFIX Mediators" > scope field and in the Template Withdrawal Message. The Collector > would thus not be able to interpret the Template ID in the Template > Withdrawal Message and in the Options Template scope. As a > consequence, there is a risk that the Collector would then shut down= > the IPFIX Transport Session. >=20 > For example, an IPFIX Distributor must maintain the state of the > incoming Transport Sessions in order to manage the Template ID on it= s > outgoing Transport Session correctly. In the following figure, even= The rest of the paragraph is unclear: > if the Transport Session from Exporter re-initializes, the IPFIX > Distributor must manage the association of Template IDs in specific > Transport Session. Typically, when the Exporter#1 Transport Session= > re-initialized, the Template ID 256 replaced the previous Template I= D > 258, while the IPFIX Distributor will keep exporting the Template ID= > 256 to the Collector. Are all Templates identical? Or how comes that there is only one Template in the outgoing Transport Session? Please explain better. >=20 >=20 > .----------. OLD: Template ID 258 > |IPFIX | NEW: Template ID 256 > |Exporter#1|----+ > | | | > '----------' X > .----------. | .-----------. .----------.= > |IPFIX | '---------->| | | |= > |Exporter#2|--------------->|IPFIX |-------X------>|IPFIX |= > | |Template ID 257 |Distributor|Template ID 256| Collector|= > '----------' +---------->| | | |= > .----------. | '-----------' '----------'= > |IPFIX | | > |Exporter#3|----' > | | Template ID 256 > '----------' >=20 > Figure C: Relaying from Multiple Transport Sessions to Single > Transport Session. >=20 > 6.6. Consideration for Network Topology >=20 > While IPFIX Mediation can be applied anywhere, caution should be > taken as how to aggregate the counters, as there is a potential risk= > of double-counting. For example, if three Exporters export Flow > Records related to the same Flow, the one-way delay can be > calculated, while the summing up the number of packets and bytes doe= s > not make sense. Alternatively, if three Exporters export Flow Howerver, we could calculate packet losses on the path. See comment above= =2E > Records entering an administrative domain, then the sum of the > packets and bytes is a valid operation. Therefore, the possible > function to be applied to Flow Records must take into consideration > the measurement topology. The information such as the network > topology, or at least the Observation Point and measurement > direction, is required on the IPFIX Mediation. "on the" =3D> "for" ? > 6.7. Exporting the Function Item >=20 > In some case, the top IPFIX Collector needs to recognize which remove "top"? I know what you mean, but it does not have to be clear to all readers. > specific function(s) the IPFIX Mediation has executed on the Data > Records. The IPFIX Collector cannot distinguish between Time > Composition, Spatial Composition, and Flow Key aggregation, if the > IPFIX Mediator does not export the applied function. Some parameter= s > related to the function also would need to be exported. For example= , > in case of Time Composition, the active time of original Flow Record= s > is required to interpret the minimum/maximum counter correctly. In > case of Spatial Composition, spatial area information on which Data > Records is aggregated is required. >=20 > 6.8. Consideration for Aggregation >=20 > In case of Flow Key aggregation, Time Composition, and Spatial > Composition, there are the following considerations: >=20 > o Aggregation rule for non Flow Keys "non Flow Keys" =3D> "non-key fields" > There are no obvious rules of non Flow Keys. For example, if an "non Flow Keys" =3D> "non-key fields" > IPFIX Mediation receives two Flow Records with different DSCP > values, and this DSCP field is not a Flow Key, those two Flow > Records can be aggregated based on the Flow Keys value. However,= > there is no rules for what the DSCP value should be for the > aggregated Data Record. Potential solutions are: the value of Actually, there is a rule! Unless specified differently, the value of the first packet must be included in the record. Hence, as long as timestamps are present and allow to determine which one of the Flow Records includes the earliest packet, the decision is evident! > single of the two DSCP, the value 0 (in this case, the value 0 is= > a valid DSCP value), or removing a DSCP field in its Data Record.= >=20 > o Configured Selection Fraction on aggregation >=20 > There is no obvious rules of how to compute Configured Selection > Fraction, and whether a Mediator should report Configured remove ", and whether....," It is obvious, that Configured or Attained Selection Fraction is necessary to interpret the Flow Records. > Selection Fraction, when aggregation resulting from Sampling. Fo= r "...when aggregating IPFIX Flow Records of sampled packets." > example, special care must be taken in the following: aggregation= > resulting from the different Configured Selection Fraction, > aggregation resulting from different Sampling techniques, such as= > Systematic Count-Based Sampling and Random n-out-of-N Sampling > etc. > 7. Summary and Conclusion >=20 > This document described the problems that network administrators hav= e > 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. >=20 > o Regarding large-scale measurement system, IPFIX Concentrators or > IPFIX Distributors help to achieve traffic analysis with high dat= a > accuracy and fine flow granularity even as IP traffic grows. As > IPFIX Mediation capabilities, Flow selection Sampling, flow sampling? > aggregation, and composition are effective. >=20 > o Regarding data retention, IPFIX Mediators enhance the export > reliability, and the storage of the measurement system. >=20 > 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 > based on Data Record types(IPv4, IPv6, MPLS, and VPN). >=20 > o Regarding IPFIX Exporting across domains, IPFIX Masquerading exporting > Proxies help administrators to anonymize or filter Flow Records/ Data Records > Packet Reports, preventing privacy violations. >=20 > o Regarding interoperability, IPFIX Proxies provide interoperabilit= y > between legacy protocols and IPFIX, even during the migration > period to IPFIX. >=20 > As a result, the IPFIX Mediation benefits become apparent. However,= > there are still some open issues with the use of IPFIX Mediators. >=20 > o Both Observation Point and IPFIX Message header information, such= > as the Exporter IP address, Observation Domain ID, and Export Tim= e > field, might be lost. This data should therefore be communicated= > between the Original Exporter and Collector via the IPFIX > Mediator. >=20 > o IPFIX Mediators are required to manage Transport Sessions, > Template IDs, and Observation Domain IDs. Otherwise, anomalous > IPFIX messages could be created. >=20 > o Data advertised by Option Templates from the Original Exporter, _Options_ Templates better: "Options Data Records exported by the Original Exporter, such as those reporting the Sampling rate...." Maybe the term "Options Data Record" should be introduced to simplify things. BTW, we had the same problem in per-sctp-stream, and always wrote "Data Record defined by an Options Template Record", which is not very easy to read. > such as the Sampling rate and Sampling algorithm used, might be > lost. If a Collector is not informed of current Sampling rates, > traffic information might become worthless. >=20 > 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. > 8. Security Considerations >=20 > 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. >=20 > And a measurement system must also prevent following security threat= s "...the following..." > related to IPFIX Mediation: >=20 > o Attacks against IPFIX Mediator >=20 > 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. >=20 > o Man-in-the-middle attack by untrusted IPFIX Mediator >=20 > The Collector-Mediator-Exporter structure model would increase th= e > risk of the man-in-the-middle attack. >=20 > o Configuration on IPFIX Mediation >=20 > 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 disclosur= e > of confidential traffic data. --=20 Dipl.-Ing. Gerhard M=FCnz Chair for Network Architectures and Services (I8) Department of Informatics Technische Universit=E4t M=FCnchen Boltzmannstr. 3, 85748 Garching bei M=FCnchen, Germany Phone: +49 89 289-18008 Fax: +49 89 289-18033 E-mail: muenz@net.in.tum.de WWW: http://www.net.in.tum.de/~muenz --------------ms090204060304030906090205 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIJ6TCC Az8wggKooAMCAQICAQ0wDQYJKoZIhvcNAQEFBQAwgdExCzAJBgNVBAYTAlpBMRUwEwYDVQQI EwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEaMBgGA1UEChMRVGhhd3RlIENv bnN1bHRpbmcxKDAmBgNVBAsTH0NlcnRpZmljYXRpb24gU2VydmljZXMgRGl2aXNpb24xJDAi BgNVBAMTG1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBDQTErMCkGCSqGSIb3DQEJARYccGVy c29uYWwtZnJlZW1haWxAdGhhd3RlLmNvbTAeFw0wMzA3MTcwMDAwMDBaFw0xMzA3MTYyMzU5 NTlaMGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBM dGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQTCBnzAN BgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAxKY8VXNV+065yplaHmjAdQRwnd/p/6Me7L3N9Vvy Gna9fww6YfK/Uc4B1OVQCjDXAmNaLIkVcI7dyfArhVqqP3FWy688Cwfn8R+RNiQqE88r1fOC dz0Dviv+uxg+B79AgAJk16emu59l0cUqVIUPSAR/p7bRPGEEQB5kGXJgt/sCAwEAAaOBlDCB kTASBgNVHRMBAf8ECDAGAQH/AgEAMEMGA1UdHwQ8MDowOKA2oDSGMmh0dHA6Ly9jcmwudGhh d3RlLmNvbS9UaGF3dGVQZXJzb25hbEZyZWVtYWlsQ0EuY3JsMAsGA1UdDwQEAwIBBjApBgNV HREEIjAgpB4wHDEaMBgGA1UEAxMRUHJpdmF0ZUxhYmVsMi0xMzgwDQYJKoZIhvcNAQEFBQAD gYEASIzRUIPqCy7MDaNmrGcPf6+svsIXoUOWlJ1/TCG4+DYfqi2fNi/A9BxQIJNwPP2t4WFi w9k6GX6EsZkbAMUaC4J0niVQlGLH2ydxVyWN3amcOY6MIE9lX5Xa9/eH1sYITq726jTlEBpb NU1341YheILcIRk13iSx0x1G/11fZU8wggNPMIICuKADAgECAhAqxerdN2XVRkUZsuk5IKdP MA0GCSqGSIb3DQEBBQUAMGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3Vs dGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNz dWluZyBDQTAeFw0wOTAyMTkxMDI5NDVaFw0xMDAyMTkxMDI5NDVaMIGQMQ4wDAYDVQQEEwVN dWVuejEQMA4GA1UEKhMHR2VyaGFyZDEWMBQGA1UEAxMNR2VyaGFyZCBNdWVuejEwMC4GCSqG SIb3DQEJARYhbXVlbnpAaW5mb3JtYXRpay51bmktdHVlYmluZ2VuLmRlMSIwIAYJKoZIhvcN AQkBFhNtdWVuekBuZXQuaW4udHVtLmRlMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKC AQEAxC8p+6KRpyQyKvT9LAxUB2m8azrci+c5oQUYac2A4WsjoqiCqi2k/wgCrCIHrN0USQeH LmcbtSWT5O+1kMai28KGUdZG5xmJ7PLuLejKlYIu2TkR8tI1Q4gyu1Gs45yn9Rf+EGWmqa/s ebjMV3tc/zrpEN2b1ls8U9rM2/h0NcUUU+g170e8DlXNOL7+bsQD+tLH5G3nlV9mZntMQ68t PaaLG4MtupHuS99YGoo0yB4rzuTxiWRKTJgqjboQL0eS9+6dxsrT01g7sOc2QtXbO45PBnsG Ra5CAMpGLrqGT1ISZIpqYrGuMH9Rv7HTR3rLygL81WMDtNCa6W5/PPMlSwIDAQABo1MwUTBB BgNVHREEOjA4gSFtdWVuekBpbmZvcm1hdGlrLnVuaS10dWViaW5nZW4uZGWBE211ZW56QG5l dC5pbi50dW0uZGUwDAYDVR0TAQH/BAIwADANBgkqhkiG9w0BAQUFAAOBgQBOkMsohjpIH4Mr 33zNnhc5PkzAi0RZ6UAOB28nTtfjVZ25UVLWqmLgYEszbloTd07y5PcUZhSuPuwGzEwn4XdX i3VWl6qk5VcPpyP7+b5XEY5CU1A8cqeaXS88qWyshu1dXm2ToqueRPv+E2b3GJHAciNt2Qfc T4SNWymkvUyPSjCCA08wggK4oAMCAQICECrF6t03ZdVGRRmy6Tkgp08wDQYJKoZIhvcNAQEF BQAwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0 ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA5 MDIxOTEwMjk0NVoXDTEwMDIxOTEwMjk0NVowgZAxDjAMBgNVBAQTBU11ZW56MRAwDgYDVQQq EwdHZXJoYXJkMRYwFAYDVQQDEw1HZXJoYXJkIE11ZW56MTAwLgYJKoZIhvcNAQkBFiFtdWVu ekBpbmZvcm1hdGlrLnVuaS10dWViaW5nZW4uZGUxIjAgBgkqhkiG9w0BCQEWE211ZW56QG5l dC5pbi50dW0uZGUwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDELyn7opGnJDIq 9P0sDFQHabxrOtyL5zmhBRhpzYDhayOiqIKqLaT/CAKsIges3RRJB4cuZxu1JZPk77WQxqLb woZR1kbnGYns8u4t6MqVgi7ZORHy0jVDiDK7UazjnKf1F/4QZaapr+x5uMxXe1z/OukQ3ZvW WzxT2szb+HQ1xRRT6DXvR7wOVc04vv5uxAP60sfkbeeVX2Zme0xDry09posbgy26ke5L31ga ijTIHivO5PGJZEpMmCqNuhAvR5L37p3GytPTWDuw5zZC1ds7jk8GewZFrkIAykYuuoZPUhJk impisa4wf1G/sdNHesvKAvzVYwO00Jrpbn888yVLAgMBAAGjUzBRMEEGA1UdEQQ6MDiBIW11 ZW56QGluZm9ybWF0aWsudW5pLXR1ZWJpbmdlbi5kZYETbXVlbnpAbmV0LmluLnR1bS5kZTAM BgNVHRMBAf8EAjAAMA0GCSqGSIb3DQEBBQUAA4GBAE6QyyiGOkgfgyvffM2eFzk+TMCLRFnp QA4HbydO1+NVnblRUtaqYuBgSzNuWhN3TvLk9xRmFK4+7AbMTCfhd1eLdVaXqqTlVw+nI/v5 vlcRjkJTUDxyp5pdLzypbKyG7V1ebZOiq55E+/4TZvcYkcByI23ZB9xPhI1bKaS9TI9KMYID ZDCCA2ACAQEwdjBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcg KFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3Vpbmcg Q0ECECrF6t03ZdVGRRmy6Tkgp08wCQYFKw4DAhoFAKCCAcMwGAYJKoZIhvcNAQkDMQsGCSqG SIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMDkwNTI2MTI0ODE0WjAjBgkqhkiG9w0BCQQxFgQU xrIoVd9b14Lcu6mzwb9hlcxSLHswUgYJKoZIhvcNAQkPMUUwQzAKBggqhkiG9w0DBzAOBggq hkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwICASgwgYUG CSsGAQQBgjcQBDF4MHYwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0 aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1 aW5nIENBAhAqxerdN2XVRkUZsuk5IKdPMIGHBgsqhkiG9w0BCRACCzF4oHYwYjELMAkGA1UE BhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMT I1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBAhAqxerdN2XVRkUZsuk5IKdP MA0GCSqGSIb3DQEBAQUABIIBAKt+1MpYPMmzte+Qn8jgSQjvDluEEamTbk7Gxrng2YvkStUM bc9YHCUU87AKqUClyLrfpDXvE4UQ4PENmmHcyrqv+UE9WEvph1aGnurcNNrVsqpCvsuw4MyL Il5OZIvwa5h1Itgj/ER0VFy3FXqiuIYSRq7+FsHRpIZYY2NOyDRc+ozjCGbari2xxpPEes8W tZWWqf0ta7joONv2Z0qIHnzXUdcRCcKS4AlsvlwmJ9cD+22zCIU4JDPErAkQSZoeg6wfWsdk lBR3ayB9wlvpVQBBg7ok3wxFWbLWIH7fw3JZGQW+pDaINlGRIcncZBiiw5GIxVJ+GEGqCqBW swbyEBQAAAAAAAA= --------------ms090204060304030906090205-- From muenz@net.in.tum.de Thu May 28 12:50:44 2009 Return-Path: X-Original-To: ipfix@core3.amsl.com Delivered-To: ipfix@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B680A3A6CBF for ; Thu, 28 May 2009 12:50:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.107 X-Spam-Level: X-Spam-Status: No, score=-1.107 tagged_above=-999 required=5 tests=[AWL=-0.947, BAYES_05=-1.11, HELO_EQ_DE=0.35, J_CHICKENPOX_22=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 5kGNabebswA9 for ; Thu, 28 May 2009 12:50:38 -0700 (PDT) Received: from mail-out1.informatik.tu-muenchen.de (mail-out1.informatik.tu-muenchen.de [131.159.0.8]) by core3.amsl.com (Postfix) with ESMTP id 3258B3A6DE4 for ; Thu, 28 May 2009 12:50:38 -0700 (PDT) Received: from phoenix.net.informatik.tu-muenchen.de (phoenix.net.informatik.tu-muenchen.de [131.159.14.1]) by services.net.informatik.tu-muenchen.de (Postix Mailer @ mail) with ESMTP id 4E5AF481D8 for ; Thu, 28 May 2009 21:52:17 +0200 (CEST) Received: from [131.159.20.108] (repulse.net.informatik.tu-muenchen.de [131.159.20.108]) by phoenix.net.informatik.tu-muenchen.de (Postfix) with ESMTP id 3FC735106; Thu, 28 May 2009 21:52:17 +0200 (CEST) Message-ID: <4A1EEBB0.3040201@net.in.tum.de> Date: Thu, 28 May 2009 21:53:20 +0200 From: Gerhard Muenz User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: "ipfix@ietf.org Working Group" References: <49B10249.9040500@cisco.com> <49B11ED6.9070706@net.in.tum.de> <49B13015.6070001@net.in.tum.de> <1E797ED7-797A-4169-822B-45E674A912D1@tik.ee.ethz.ch> <49B13C75.70004@net.in.tum.de> <2A9198A6-8FF0-471D-A8F0-D605A3CEE707@tik.ee.ethz.ch> In-Reply-To: <2A9198A6-8FF0-471D-A8F0-D605A3CEE707@tik.ee.ethz.ch> Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms010108050907050902000208" X-Virus-Scanned: ClamAV using ClamSMTP Cc: Daniel Mentz Subject: [IPFIX] IPFIX configuration: (D)TLS authentication 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, 28 May 2009 19:50:44 -0000 This is a cryptographically signed message in MIME format. --------------ms010108050907050902000208 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi all, Regarding the configuration of (D)TLS, one of my students pointed out that RFC 5101 specifies to authenticate Exporting and Collecting Processes by FQDNs: 11.3. Authentication IPFIX Exporting Processes and IPFIX Collecting Processes are identified by the fully qualified domain name of the interface on which IPFIX Messages are sent or received, for purposes of X.509 client and server certificates as in [RFC3280]. The FQDN can be stored in a subjectAltName extension or the Common Name field of the X.509 certificate. subjectAltName seems to be the preferred solution. RFC 5101 says: Each of the IPFIX Exporting and Collecting Processes MUST verify the identity of its peer against its authorized certificates, and MUST verify that the peer's certificate matches its fully qualified domain name, or, in the case of SCTP, the fully qualified domain name of one of its endpoints. I assume that the configuration data model should enable the configuration of which certificates are "authorized". In general, I see three cases: 1) any valid certificate is authorized 2) only a valid certificate issued by one out of a given list of CAs is authorized 3) only a valid certificate for one out of a given list of FQDNs issued by one out of a given list of CAs is accepted So, I would add the following parameters at appropriate places to the Exporting Process and Collecting Process parameter sets: - certificateAuthority: Common Name of the accepted CA - [collectingProcess|exportingProcess]DomainName: FQDN of accepted CP|EP (without specifying if the FQDN is expected to appear in the CN field of the Subject or in the subjectAltName extension) I hope that the Common Name is enough to identify the CA unambiguously. How about endpoints that have multiple certificates available (e.g., issued by different CAs)? In this case, it might be interesting to configure which certificate(s) the endpoint should offer the other endpoint for identification. So, we would be able to specify both certificates _used_ and certificates _accepted_ by an Exporting Process or Collection Process. Opinions? BTW, the second part of the above quote from RFC5101 ("MUST verify that the peer's certificate matches its fully qualified domain name") seems to require a DNS lookup, or how is it supposed to work? Regards, Gerhard --=20 Dipl.-Ing. Gerhard M=FCnz Chair for Network Architectures and Services (I8) Department of Informatics Technische Universit=E4t M=FCnchen Boltzmannstr. 3, 85748 Garching bei M=FCnchen, Germany Phone: +49 89 289-18008 Fax: +49 89 289-18033 E-mail: muenz@net.in.tum.de WWW: http://www.net.in.tum.de/~muenz --------------ms010108050907050902000208 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIJ6TCC Az8wggKooAMCAQICAQ0wDQYJKoZIhvcNAQEFBQAwgdExCzAJBgNVBAYTAlpBMRUwEwYDVQQI EwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEaMBgGA1UEChMRVGhhd3RlIENv bnN1bHRpbmcxKDAmBgNVBAsTH0NlcnRpZmljYXRpb24gU2VydmljZXMgRGl2aXNpb24xJDAi BgNVBAMTG1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBDQTErMCkGCSqGSIb3DQEJARYccGVy c29uYWwtZnJlZW1haWxAdGhhd3RlLmNvbTAeFw0wMzA3MTcwMDAwMDBaFw0xMzA3MTYyMzU5 NTlaMGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBM dGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQTCBnzAN BgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAxKY8VXNV+065yplaHmjAdQRwnd/p/6Me7L3N9Vvy Gna9fww6YfK/Uc4B1OVQCjDXAmNaLIkVcI7dyfArhVqqP3FWy688Cwfn8R+RNiQqE88r1fOC dz0Dviv+uxg+B79AgAJk16emu59l0cUqVIUPSAR/p7bRPGEEQB5kGXJgt/sCAwEAAaOBlDCB kTASBgNVHRMBAf8ECDAGAQH/AgEAMEMGA1UdHwQ8MDowOKA2oDSGMmh0dHA6Ly9jcmwudGhh d3RlLmNvbS9UaGF3dGVQZXJzb25hbEZyZWVtYWlsQ0EuY3JsMAsGA1UdDwQEAwIBBjApBgNV HREEIjAgpB4wHDEaMBgGA1UEAxMRUHJpdmF0ZUxhYmVsMi0xMzgwDQYJKoZIhvcNAQEFBQAD gYEASIzRUIPqCy7MDaNmrGcPf6+svsIXoUOWlJ1/TCG4+DYfqi2fNi/A9BxQIJNwPP2t4WFi w9k6GX6EsZkbAMUaC4J0niVQlGLH2ydxVyWN3amcOY6MIE9lX5Xa9/eH1sYITq726jTlEBpb NU1341YheILcIRk13iSx0x1G/11fZU8wggNPMIICuKADAgECAhAqxerdN2XVRkUZsuk5IKdP MA0GCSqGSIb3DQEBBQUAMGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3Vs dGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNz dWluZyBDQTAeFw0wOTAyMTkxMDI5NDVaFw0xMDAyMTkxMDI5NDVaMIGQMQ4wDAYDVQQEEwVN dWVuejEQMA4GA1UEKhMHR2VyaGFyZDEWMBQGA1UEAxMNR2VyaGFyZCBNdWVuejEwMC4GCSqG SIb3DQEJARYhbXVlbnpAaW5mb3JtYXRpay51bmktdHVlYmluZ2VuLmRlMSIwIAYJKoZIhvcN AQkBFhNtdWVuekBuZXQuaW4udHVtLmRlMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKC AQEAxC8p+6KRpyQyKvT9LAxUB2m8azrci+c5oQUYac2A4WsjoqiCqi2k/wgCrCIHrN0USQeH LmcbtSWT5O+1kMai28KGUdZG5xmJ7PLuLejKlYIu2TkR8tI1Q4gyu1Gs45yn9Rf+EGWmqa/s ebjMV3tc/zrpEN2b1ls8U9rM2/h0NcUUU+g170e8DlXNOL7+bsQD+tLH5G3nlV9mZntMQ68t PaaLG4MtupHuS99YGoo0yB4rzuTxiWRKTJgqjboQL0eS9+6dxsrT01g7sOc2QtXbO45PBnsG Ra5CAMpGLrqGT1ISZIpqYrGuMH9Rv7HTR3rLygL81WMDtNCa6W5/PPMlSwIDAQABo1MwUTBB BgNVHREEOjA4gSFtdWVuekBpbmZvcm1hdGlrLnVuaS10dWViaW5nZW4uZGWBE211ZW56QG5l dC5pbi50dW0uZGUwDAYDVR0TAQH/BAIwADANBgkqhkiG9w0BAQUFAAOBgQBOkMsohjpIH4Mr 33zNnhc5PkzAi0RZ6UAOB28nTtfjVZ25UVLWqmLgYEszbloTd07y5PcUZhSuPuwGzEwn4XdX i3VWl6qk5VcPpyP7+b5XEY5CU1A8cqeaXS88qWyshu1dXm2ToqueRPv+E2b3GJHAciNt2Qfc T4SNWymkvUyPSjCCA08wggK4oAMCAQICECrF6t03ZdVGRRmy6Tkgp08wDQYJKoZIhvcNAQEF BQAwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0 ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA5 MDIxOTEwMjk0NVoXDTEwMDIxOTEwMjk0NVowgZAxDjAMBgNVBAQTBU11ZW56MRAwDgYDVQQq EwdHZXJoYXJkMRYwFAYDVQQDEw1HZXJoYXJkIE11ZW56MTAwLgYJKoZIhvcNAQkBFiFtdWVu ekBpbmZvcm1hdGlrLnVuaS10dWViaW5nZW4uZGUxIjAgBgkqhkiG9w0BCQEWE211ZW56QG5l dC5pbi50dW0uZGUwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDELyn7opGnJDIq 9P0sDFQHabxrOtyL5zmhBRhpzYDhayOiqIKqLaT/CAKsIges3RRJB4cuZxu1JZPk77WQxqLb woZR1kbnGYns8u4t6MqVgi7ZORHy0jVDiDK7UazjnKf1F/4QZaapr+x5uMxXe1z/OukQ3ZvW WzxT2szb+HQ1xRRT6DXvR7wOVc04vv5uxAP60sfkbeeVX2Zme0xDry09posbgy26ke5L31ga ijTIHivO5PGJZEpMmCqNuhAvR5L37p3GytPTWDuw5zZC1ds7jk8GewZFrkIAykYuuoZPUhJk impisa4wf1G/sdNHesvKAvzVYwO00Jrpbn888yVLAgMBAAGjUzBRMEEGA1UdEQQ6MDiBIW11 ZW56QGluZm9ybWF0aWsudW5pLXR1ZWJpbmdlbi5kZYETbXVlbnpAbmV0LmluLnR1bS5kZTAM BgNVHRMBAf8EAjAAMA0GCSqGSIb3DQEBBQUAA4GBAE6QyyiGOkgfgyvffM2eFzk+TMCLRFnp QA4HbydO1+NVnblRUtaqYuBgSzNuWhN3TvLk9xRmFK4+7AbMTCfhd1eLdVaXqqTlVw+nI/v5 vlcRjkJTUDxyp5pdLzypbKyG7V1ebZOiq55E+/4TZvcYkcByI23ZB9xPhI1bKaS9TI9KMYID ZDCCA2ACAQEwdjBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcg KFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3Vpbmcg Q0ECECrF6t03ZdVGRRmy6Tkgp08wCQYFKw4DAhoFAKCCAcMwGAYJKoZIhvcNAQkDMQsGCSqG SIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMDkwNTI4MTk1MzIwWjAjBgkqhkiG9w0BCQQxFgQU FBzsor0s6eKILJc4upyg+ymHwAAwUgYJKoZIhvcNAQkPMUUwQzAKBggqhkiG9w0DBzAOBggq hkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwICASgwgYUG CSsGAQQBgjcQBDF4MHYwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0 aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1 aW5nIENBAhAqxerdN2XVRkUZsuk5IKdPMIGHBgsqhkiG9w0BCRACCzF4oHYwYjELMAkGA1UE BhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMT I1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBAhAqxerdN2XVRkUZsuk5IKdP MA0GCSqGSIb3DQEBAQUABIIBAGwTQdCnVomkSkeQcaxvKelWGXkrBjk+qcXK9G9oqetkxme3 3xGoyyZr/Ko5YTdGhG0KgkH7BULmkZ/+fRCnbwgisQwdHk2oy/eI1rq8HeXD/G6wvxiSuyjj GLdiqd32TROHOycfEHS8kqhGzc+REdxEEHaDUi+l8HkvAyd6VSWAq0VCrEhpgITM1bbsWODx KMWRLKTntaiEhIfcKr5uPvLv3DWZkdB01eYdeYLvUEJkRpA6MAr4TTCt7gJ804Z9ebmuuu+G bo3/pDMEB6otmjcSm/VLp1lc6AkcqP2RUgn7l8T6tqb8sJvA8vZ8bxldGaJottDZB9nPITMw U6moOUwAAAAAAAA= --------------ms010108050907050902000208--