From trammell@tik.ee.ethz.ch Fri Oct 1 05:14:37 2010 Return-Path: X-Original-To: ipfix@core3.amsl.com Delivered-To: ipfix@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5A7143A6EAC for ; Fri, 1 Oct 2010 05:14:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.499 X-Spam-Level: X-Spam-Status: No, score=-6.499 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YCAVn99NJ5WN for ; Fri, 1 Oct 2010 05:14:35 -0700 (PDT) Received: from smtp.ee.ethz.ch (smtp.ee.ethz.ch [129.132.2.219]) by core3.amsl.com (Postfix) with ESMTP id BC2423A6EAE for ; Fri, 1 Oct 2010 05:14:34 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by smtp.ee.ethz.ch (Postfix) with ESMTP id 0B2FCD9457 for ; Fri, 1 Oct 2010 14:15:22 +0200 (MEST) X-Virus-Scanned: by amavisd-new on smtp.ee.ethz.ch Received: from smtp.ee.ethz.ch ([127.0.0.1]) by localhost (.ee.ethz.ch [127.0.0.1]) (amavisd-new, port 10024) with LMTP id fiiuEzUdn-eF for ; Fri, 1 Oct 2010 14:15:21 +0200 (MEST) Received: from pb-10072.ethz.ch (pb-10072.ethz.ch [82.130.103.195]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: briant) by smtp.ee.ethz.ch (Postfix) with ESMTPSA id A0960D936A for ; Fri, 1 Oct 2010 14:15:21 +0200 (MEST) From: Brian Trammell Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Fri, 1 Oct 2010 14:15:21 +0200 References: <20101001120148.9042B3A74D4@core3.amsl.com> To: "ipfix@ietf.org Group" Message-Id: <6A7213D7-64ED-4D3B-AD8D-CBAD105F21B5@tik.ee.ethz.ch> Mime-Version: 1.0 (Apple Message framework v1081) X-Mailer: Apple Mail (2.1081) Subject: [IPFIX] Fwd: New Version Notification for draft-trammell-ipfix-ie-doctors-00 X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Oct 2010 12:14:37 -0000 Greetings, all: A first draft of the IE-Doctors draft discussed in Maastricht has been = posted; this presents a reasonably complete discussion of the issues = surrounding efficient extension of the Information Element registry and = definition of new IPFIX applications in Internet-Drafts. We intend to = discuss this as a future BCP at the meeting in Beijing. Reviews and = comments in the meantime are of course appreciated. :) Best regards, Brian Begin forwarded message: > From: IETF I-D Submission Tool > Date: October 1, 2010 2:01:48 PM GMT+02:00 > To: trammell@tik.ee.ethz.ch > Cc: bclaise@cisco.com > Subject: New Version Notification for = draft-trammell-ipfix-ie-doctors-00=20 >=20 >=20 > A new version of I-D, draft-trammell-ipfix-ie-doctors-00.txt has been = successfully submitted by Brian Trammell and posted to the IETF = repository. >=20 > Filename: draft-trammell-ipfix-ie-doctors > Revision: 00 > Title: Guidelines for Authors and Reviewers of IPFIX = Information Elements > Creation_date: 2010-10-01 > WG ID: Independent Submission > Number_of_pages: 22 >=20 > Abstract: > This document provides guidelines for the definition of IPFIX > Information Elements for addition to the IANA IPFIX Information > Element registry, in order to extend the applicability of the IPFIX > protocol to new operations and management areas. >=20 >=20 >=20 > The IETF Secretariat. >=20 From Quittek@neclab.eu Mon Oct 4 04:48:28 2010 Return-Path: X-Original-To: ipfix@core3.amsl.com Delivered-To: ipfix@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B87153A6F88; Mon, 4 Oct 2010 04:48:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.877 X-Spam-Level: X-Spam-Status: No, score=-101.877 tagged_above=-999 required=5 tests=[AWL=0.372, BAYES_00=-2.599, HELO_EQ_DE=0.35, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id r+sG6efeJGks; Mon, 4 Oct 2010 04:48:27 -0700 (PDT) Received: from smtp0.netlab.nec.de (smtp0.netlab.nec.de [195.37.70.40]) by core3.amsl.com (Postfix) with ESMTP id 863E83A6F86; Mon, 4 Oct 2010 04:48:26 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp0.netlab.nec.de (Postfix) with ESMTP id 6D9A528000188; Mon, 4 Oct 2010 13:49:21 +0200 (CEST) X-Virus-Scanned: Amavisd on Debian GNU/Linux (atlas1.office.hd) Received: from smtp0.netlab.nec.de ([127.0.0.1]) by localhost (atlas1.office.hd [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id L0CEnUDnH5sH; Mon, 4 Oct 2010 13:49:21 +0200 (CEST) Received: from ENCELADUS.office.hd (Enceladus.office.hd [192.168.24.52]) by smtp0.netlab.nec.de (Postfix) with ESMTP id 4977A28000183; Mon, 4 Oct 2010 13:49:01 +0200 (CEST) Received: from DAPHNIS.office.hd ([169.254.2.252]) by ENCELADUS.office.hd ([192.168.24.52]) with mapi id 14.01.0218.012; Mon, 4 Oct 2010 13:49:01 +0200 From: Juergen Quittek To: Dan Romascanu , IESG Secretary Thread-Topic: [IPFIX] write-up for draft-ietf-ipfix-mediators-framework-08 Thread-Index: Actjuh9GkTNyTuUuMUCR5YrD4kcMaw== Date: Mon, 4 Oct 2010 11:49:00 +0000 Message-ID: Accept-Language: de-DE, en-US Content-Language: de-DE X-MS-Has-Attach: yes X-MS-TNEF-Correlator: user-agent: Microsoft-Entourage/13.6.0.100712 x-originating-ip: [10.1.2.39] Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="B_3369044936_408263" MIME-Version: 1.0 Cc: Ronald Bonica , IETF IPFIX Working Group Subject: [IPFIX] write-up for draft-ietf-ipfix-mediators-framework-08 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 Oct 2010 11:48:28 -0000 --B_3369044936_408263 Content-type: multipart/mixed; boundary="B_3369044936_395426" --B_3369044936_395426 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-mediators-framework-08. 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-mediators-problem-statement-07 ============================================================ (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 during two WG last calls. Several comments were made and have been addressed when updating the document after the WGLCs. 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. (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. There is a capitalized "SHOUND" in section 9, 2nd paragraph, line 9, that needs to be changed to lower case "should". Some references need to be updated, because referenced documents have been updated or obsoleted. All of these changes can easily 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]. Four reference have been outdated since the document was submitted. 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? The document states correctly that there it has no actions for IANA. (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? There are no such sections. (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 describes a framework for IPFIX Mediation. This framework extends the IPFIX reference model by defining the IPFIX Mediator components. Working Group Summary The mediation framework was added to the IPIFX charter in 2008. The document was discussed at all meetings since then and had several revisions. There was nothing special about this document. Document Quality The document underwent two 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_3369044936_395426 Content-Type: text/plain; name="ATT83158.txt" Content-Description: ATT83158.txt Content-Disposition: attachment; filename="ATT83158.txt"; size=194; creation-date="Thu, 04 Mar 2010 02:53:58 GMT"; modification-date="Thu, 04 Mar 2010 02:53:58 GMT" Content-Transfer-Encoding: base64 X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCklQRklYIG1h aWxpbmcgbGlzdA0KSVBGSVhAaWV0Zi5vcmcNCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4v bGlzdGluZm8vaXBmaXgNCg== --B_3369044936_395426-- --B_3369044936_408263 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIIWIQYJKoZIhvcNAQcCoIIWEjCCFg4CAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3DQEHAaCC E8kwggU2MIIEHqADAgECAgQNLisHMA0GCSqGSIb3DQEBBQUAMIGQMQswCQYDVQQGEwJERTEY 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/IcMIIFMzCCBBugAwIBAgIED+0edzANBgkqhkiG9w0BAQUFADCBkDELMAkGA1UEBhMC REUxGDAWBgNVBAoTD05FQyBFdXJvcGUgTHRkLjEgMB4GA1UECxMXTkVDIExhYm9yYXRvcmll cyBFdXJvcGUxEjAQBgNVBAMTCU5FQ0xBQi1DQTExMC8GCSqGSIb3DQEJARYiemVydGlmaXpp ZXJ1bmdzc3RlbGxlQG53Lm5lY2xhYi5ldTAeFw0xMDA0MjAxMjQxMTJaFw0xMzA0MTkxMjQx MTJaMGMxCzAJBgNVBAYTAkRFMRgwFgYDVQQKEw9ORUMgRXVyb3BlIEx0ZC4xIDAeBgNVBAsT F05FQyBMYWJvcmF0b3JpZXMgRXVyb3BlMRgwFgYDVQQDEw9KdWVyZ2VuIFF1aXR0ZWswggEi MA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDYGuB3+Ykow4r2vPwU5WrZ1xZTlj36mb2O wFOm7QlChYmhsMrRWq+1wsEYIB3AnqHWGjGaA0UhBmPm0VA72sozbxU5IS9fRZs8YODD5kAP drXCG//iMpWQ+WJFZMPPP+s2+pPk/qPO+S5SwEe/X/IL5aGjzG8YgfCsELXZRgfTojdZN/uz YhEqVpsk/Flq1sOBe6nNFi12lrqr+v970aPoyUscjsHnxJ860aIwnjydmQ+JoDzELzBz6qHQ 4U7yAQbqWKALVud9NuFpy/zxx9+KUNGZnJc/Lv2KHJ3zBGKMiw1biSp0KMAxe+S1W5ypqV3w rHCnm0p3RaUgDT9k4iNnAgMBAAGjggG/MIIBuzAJBgNVHRMEAjAAMAsGA1UdDwQEAwIF4DAp BgNVHSUEIjAgBggrBgEFBQcDAgYIKwYBBQUHAwQGCisGAQQBgjcUAgIwHQYDVR0OBBYEFPVl D8YxQQLSTl8Se2oKl6Mxw8vYMB8GA1UdIwQYMBaAFE8ch3od4C+Z9r4VqtE1nQ5K5ro2MBwG A1UdEQQVMBOBEVF1aXR0ZWtAbmVjbGFiLmV1MH0GA1UdHwR2MHQwOKA2oDSGMmh0dHA6Ly9j ZHAxLnBjYS5kZm4uZGUvbmVjbGFiLWNhL3B1Yi9jcmwvY2FjcmwuY3JsMDigNqA0hjJodHRw Oi8vY2RwMi5wY2EuZGZuLmRlL25lY2xhYi1jYS9wdWIvY3JsL2NhY3JsLmNybDCBmAYIKwYB BQUHAQEEgYswgYgwQgYIKwYBBQUHMAKGNmh0dHA6Ly9jZHAxLnBjYS5kZm4uZGUvbmVjbGFi LWNhL3B1Yi9jYWNlcnQvY2FjZXJ0LmNydDBCBggrBgEFBQcwAoY2aHR0cDovL2NkcDIucGNh LmRmbi5kZS9uZWNsYWItY2EvcHViL2NhY2VydC9jYWNlcnQuY3J0MA0GCSqGSIb3DQEBBQUA A4IBAQB/VUWmfe/CzaHPnjP9pPzkGnzSZeFIyi44hJx/BQrqp7jV2TADnXH5zK0SitW5fhYQ st7I4ILLj+DWptqEsu0Q2FmIy2PzCjDzvzA/z6TUnuoKMePePMH41hpo+FM94KoA6L0BAth9 N43D13rSagU4qapn57zBaqM6Dec44hMybri6SzGDTzPhPuKUJy7UQITfeAtXvQu6D+um+2rO joFVQgqZROZZZ6CjOZ4LQBS+Rt8oJv62babXZmjYETuow19cPQDq7JkjxqfkvmETaJyhhKk6 JSabpRCQe6zHQFIprFKf6nc71q4SGegN34Mx8BYayB6lQZQy5ru3EB7v0DFBMYICIDCCAhwC AQEwgZkwgZAxCzAJBgNVBAYTAkRFMRgwFgYDVQQKEw9ORUMgRXVyb3BlIEx0ZC4xIDAeBgNV BAsTF05FQyBMYWJvcmF0b3JpZXMgRXVyb3BlMRIwEAYDVQQDEwlORUNMQUItQ0ExMTAvBgkq hkiG9w0BCQEWInplcnRpZml6aWVydW5nc3N0ZWxsZUBudy5uZWNsYWIuZXUCBA0uKwcwCQYF Kw4DAhoFAKBdMCMGCSqGSIb3DQEJBDEWBBTDLGnAodmwp0EeqEpfBmH2ldjczDAYBgkqhkiG 9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xMDEwMDQxMTQ4NTZaMA0GCSqG SIb3DQEBAQUABIIBAIaeyR5ELLvnzYWITK1framZgy5PeTugftTajqYNSysbLHG6fYN5Uvh3 dtIQwfFvVOJPgeOB3l+MhiouNz22SrFkP89IQmbWoWvtzb5rJNJYUHkZL7By8CRoES+d5qWX 042chntNfKpFUnUuBlINFSrdhwjxol/GsZaWsWXiI7vIQB5mqfMQM+sNdufT6muV5D4Jarit pEcv7L/1s2MnvfG6FhTnf179U10IfOb/V5wTFCUQ/FmNKiuXfS0h7qL+5A15wWj58IoZGCAD gjOt3wWbUcrbL+v5XhwuoUMZhflc+uPBAxL8hdxHsIbL0vaStqs2oHonRnQ/w6zvr4ave7E= --B_3369044936_408263-- From bclaise@cisco.com Wed Oct 6 00:34:35 2010 Return-Path: X-Original-To: ipfix@core3.amsl.com Delivered-To: ipfix@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4E8F13A7021 for ; Wed, 6 Oct 2010 00:34:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.467 X-Spam-Level: X-Spam-Status: No, score=-2.467 tagged_above=-999 required=5 tests=[AWL=0.131, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LAJ6aqIS+KFE for ; Wed, 6 Oct 2010 00:34:21 -0700 (PDT) Received: from av-tac-bru.cisco.com (weird-brew.cisco.com [144.254.15.118]) by core3.amsl.com (Postfix) with ESMTP id 0C3133A6EC6 for ; Wed, 6 Oct 2010 00:34:20 -0700 (PDT) X-TACSUNS: Virus Scanned Received: from strange-brew.cisco.com (localhost.cisco.com [127.0.0.1]) by av-tac-bru.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id o967ZJpM013615; Wed, 6 Oct 2010 09:35:19 +0200 (CEST) Received: from [10.55.43.51] (ams-bclaise-8712.cisco.com [10.55.43.51]) by strange-brew.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id o967ZIMC025093; Wed, 6 Oct 2010 09:35:18 +0200 (CEST) Message-ID: <4CAC26B6.9010003@cisco.com> Date: Wed, 06 Oct 2010 09:35:18 +0200 From: Benoit Claise User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-GB; rv:1.9.2.9) Gecko/20100915 Thunderbird/3.1.4 MIME-Version: 1.0 To: Brian Trammell References: <4C4E996E.2000300@net.in.tum.de> In-Reply-To: Content-Type: multipart/alternative; boundary="------------050200010602020508050406" Cc: IETF IPFIX Working Group Subject: Re: [IPFIX] Review: draft-ietf-ipfix-structured-data-02.txt X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Oct 2010 07:34:35 -0000 This is a multi-part message in MIME format. --------------050200010602020508050406 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Brian, Thanks for your review. Reply in line. > Hi, all, > > Here are the high points of my review of structured-data -03. Apologies for the short lead-time before today's meeting; I'll make the most important points at the mike today. > > Short, short version, I think we're getting there, but the specification still needs work. > > On Jul 27, 2010, at 10:31 AM, Gerhard Muenz wrote: > >> Dear Benoit, all, >> >> Here is my review of draft-ietf-ipfix-structured-data-02. It mainly >> consists of suggestions and comments regarding the comprehensibility and >> language. >> >> There is one suggestion about the specification itself. I think that it >> would be easier to understand if the meaning of the semantic of >> subTemplateList and subTemplateMultiList would be the same, namely that >> it specifies the semantic among the Data Records. At the moment, the >> draft specifies (although not very clearly) that the semantic refers to >> goups of Data Records associated to different Templates in the case of >> the subTemplateMultiList. I do not see a use-case for this. Also, no >> useful example is provided. On the contrary, it is always said that the >> semantic of subTemplateMultiList is not sufficient. > Agreed with Gerhard on this point, and this would be the most important comment in my own review. Semantics, as I understand them, bind to the set of _values_ within a list structure. The value in a subTemplateMultiList are the records (each of which, indeed, may be associated with a different Template). Binding semantics to templates breaks this clean design. Section 5.6 almost seems like a paean to why SubTemplateMultiList sucks, which if you're applying semantics at the template level, not the record level, it seems to. > > I see the primary use of subTemplateMultiList as semantically identical to subTemplateList, allowing the usage of different templates representing semantically similar but situationally different data (e.g., mixing v4 and v6 flows) within the same List. Here, Templates are (as in IPFIX itself) an encoding mechanism, not a semantic one. > > Given this confusion, I've not reviewed the rest of the subTemplateMultiList-relevant content. I would strongly suggest a statement up front of the universality of semantics - applying to list values in all cases - and a statement up front that subTemplateMultiList is a convenience for allowing different encoding of semantically similar information. We've been addressing this comment based on our post IPFIX meeting with Brian, Gerhard, Paul, Benoit. A separate email will be sent. > Second comment: the document is in places somewhat implementation-specific, but presents these implementation specific things as essential parts of the problem. The most glaring of these is the recommendation to use three-byte encoding for all varlen fields (Section 5.1, Page 26). It might be useful to note that certain lazy-evaluating exporters might do this, so that collectors won't assume they'll never see such inefficient things FF 00 01 as a length (i.e., a three byte encoding of "1") -- but if they're 5101-compliant, this won't cause any problems. :) We think the length of structured data isn't known ahead of time. It's not that exporters are lazy, but performance can also be a concern if the length needs to be computed ahead of time or the content needs to be copied back and forth to use 1 or 3 byte encoding based on length. Hence the recommendation, its not a MUST. So, exporters can choose to do otherwise. > I have some other "high-level" applicability concerns - it should be clear than IPFIX is still mostly useful in situations where _most_ things fit into the outer template, and SDIEs are used for additional sub-record-level structure. A guideline I'd like to see here: if you ever export a template just containing one subTemplateList, you should be exporting a Set instead. If you're ever exporting a template just containing one subTemplateMultiList, what you want is a Message. IPFIX records that are _just_ used as the root of a depth-first traversal of a semantic tree should be exported using something like XML instead. We understand where you come from. However, here is a valid use case: let's say that the subTemplateList is supposed to export more than one instance (the normal case), but actually there is only one (this is an exception). In this case, we don't want to change the exporter code just for this exception. On the top of that, it's interesting to convey that there is only one instance, which can be done with the subTemplateList encoding. > Editorial: I would suggest reworking the illustrations in section 4.5. I'll talk about basicList here but this applies generally. Figures C and D are not particularly useful, they just illustrate how varlen works. In addition, by overloading the term "basicList Content", they risk being confusing. At the same time, Figures A and B make basicList look like alignment poison. However, the alignment-brokenness of varlen encoding and the alignment-brokenness of semantic tagging cancel each other out. So combining these would make things more easily understandable, and certainly prettier: > > 0 1 2 3 > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | 255 | Length (0 to 65535) | Semantic | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | IE Number | Content . . . > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > Well, this is more of an aesthetic change. The figures today clearly illustrate encoding w/ and without enterprise number, 1 and 3 byte encoding. If we try to combine figures we may be losing some info - esp, that 1 or 3 byte encoding can be used. While working on the examples, we realized that the 1 or 3 bytes encoding could be a source of confusion for the readers who are not completely familiar with IPFIX. However, we took care of the "content" issue 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Length (< 255)| basicList Encoding ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ... continuing as needed | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure C: Variable-Length basicList Encoding (Length < 255 octets) 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 255 | Length (0 to 65535) | ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ... basicList Encoding | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure D: Variable-Length basicList Encoding (Length 0 to 65535 octets) > (While I recall commenting on this a long time ago, I rescind my much-earlier "but isn't this technically independent from valen encoding?" I cannot think of a realistic example where you'd do this -> it just buys you the pain of not having structured data while forcing you to pay for it.) > > Other specific points (copied from Gerhard's review) > >>> 6. Template Management >>> >>> This section introduces some more specific Template Management and >> _m_anagement done. >>> Template Withdrawal Message-related specifications compared to the >>> IPFIX protocol specification [RFC5101]. >>> >>> First of all, the Template ID uniqueness is unchanged compared to >>> [RFC5101]; the uniqueness is local to the Transport Session and >>> Observation Domain that generated the Template ID. In other >>> words, the Set ID used to export the Template Record does not >>> influence the Template ID uniqueness. >>> >>> While [RFC5101] mentions that: "If an Information Element is >>> required more than once in a Template, the different occurrences >>> of this Information Element SHOULD follow the logical order of >>> their treatments by the Metering Process.", this rule MAY not be >>> followed for the Structured Data Information Elements. > While technically 2119-correct, the English here is a little confusing. Suggest: > > "...this rule MAY be ignored within Structured Data Information Elements" Done. > This raises another point: there are now three ways to get multiple information elements into a Template: directly (in which case treatment-order is the only way to intepret), indirectly by a SDIE (in which case semantics rule; question: does "undefined" basicList default to allOf in treatment order?), directly with an SDIE (in subTemplateList/subTemplateMultiList, a Template containing multiple IEs directly still has those IEs interpreted as in treatment order, because the semantics apply only to the relationship among list members, not among IEs within list members). > > It would be nice to see this addressed somewhere. There are two big different cases in our view 1. The implementations that don't support IPFIX structured data -> they can only rely on RFC5101. 2. The implementations that do support IPFIX structured data 2.1 "undefined" "If the structured data contains the "undefined" structured data type semantic, the Collecting Process MAY attempt to draw its own conclusion in terms of the semantic contained in the Data Record." The typical example is an IPFIX Mediator that receives RFC5101 but wants to send IPFIX structured data 2.2.something different that "undefined" Hopefully this is clearly defined ;-) Note: the semantic of subTemplateMultiList will also be clarified. See our next email. >>> As specified in [RFC5101], Templates that are not used anymore >>> SHOULD be deleted. Before reusing a Template ID, the Template >>> MUST be deleted. In order to delete an allocated Template, the >>> Template is withdrawn through the use of a Template Withdrawal >>> Message. >> You might clarify that deleting a Template implies that it may not be >> used within subTemplateList and subTemplateMultiList any more. > Corrected. As specified in [RFC5101], Templates that are not used anymore SHOULD be deleted. _Deleting a Template implies that it may not be used within subTemplateList and subTemplateMultiList any more_. Before reusing a Template ID, the Template MUST be deleted. In order to delete an allocated Template, the Template is withdrawn through the use of a Template Withdrawal Message. Thanks for your feedback. Regards, Benoit > More to follow on the list, I'm sure; just wanted to make sure I got these points out before today's meeting. > > Regards, > > Brian > > _______________________________________________ > IPFIX mailing list > IPFIX@ietf.org > https://www.ietf.org/mailman/listinfo/ipfix --------------050200010602020508050406 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Brian,

Thanks for your review. Reply in line.
Hi, all,

Here are the high points of my review of structured-data -03. Apologies for the short lead-time before today's meeting; I'll make the most important points at the mike today.

Short, short version, I think we're getting there, but the specification still needs work.

On Jul 27, 2010, at 10:31 AM, Gerhard Muenz wrote:


Dear Benoit, all,

Here is my review of draft-ietf-ipfix-structured-data-02. It mainly
consists of suggestions and comments regarding the comprehensibility and
language.

There is one suggestion about the specification itself. I think that it
would be easier to understand if the meaning of the semantic of
subTemplateList and subTemplateMultiList would be the same, namely that
it specifies the semantic among the Data Records. At the moment, the
draft specifies (although not very clearly) that the semantic refers to
goups of Data Records associated to different Templates in the case of
the subTemplateMultiList. I do not see a use-case for this. Also, no
useful example is provided. On the contrary, it is always said that the
semantic of subTemplateMultiList is not sufficient.

Agreed with Gerhard on this point, and this would be the most important comment in my own review. Semantics, as I understand them, bind to the set of _values_ within a list structure. The value in a subTemplateMultiList are the records (each of which, indeed, may be associated with a different Template). Binding semantics to templates breaks this clean design. Section 5.6 almost seems like a paean to why SubTemplateMultiList sucks, which if you're applying semantics at the template level, not the record level, it seems to.

I see the primary use of subTemplateMultiList as semantically identical to subTemplateList, allowing the usage of different templates representing semantically similar but situationally different data (e.g., mixing v4 and v6 flows) within the same List. Here, Templates are (as in IPFIX itself) an encoding mechanism, not a semantic one.

Given this confusion, I've not reviewed the rest of the subTemplateMultiList-relevant content. I would strongly suggest a statement up front of the universality of semantics - applying to list values in all cases - and a statement up front that subTemplateMultiList is a convenience for allowing different encoding of semantically similar information.
We've been addressing this comment based on our post IPFIX meeting with Brian, Gerhard, Paul, Benoit. A separate email will be sent.
Second comment: the document is in places somewhat implementation-specific, but presents these implementation specific things as essential parts of the problem. The most glaring of these is the recommendation to use three-byte encoding for all varlen fields (Section 5.1, Page 26). It might be useful to note that certain lazy-evaluating exporters might do this, so that collectors won't assume they'll never see such inefficient things FF 00 01 as a length (i.e., a three byte encoding of "1") -- but if they're 5101-compliant, this won't cause any problems. :)

We think the length of structured data isn't known ahead of time.
It's not that exporters are lazy, but performance can also be a concern
if the length needs to be computed ahead of time or the content needs to
be copied back and forth to use 1 or 3 byte encoding based on length.
Hence the recommendation, its not a MUST. So, exporters can choose to do
otherwise. 

I have some other "high-level" applicability concerns - it should be clear than IPFIX is still mostly useful in situations where _most_ things fit into the outer template, and SDIEs are used for additional sub-record-level structure. A guideline I'd like to see here: if you ever export a template just containing one subTemplateList, you should be exporting a Set instead. If you're ever exporting a template just containing one subTemplateMultiList, what you want is a Message. IPFIX records that are _just_ used as the root of a depth-first traversal of a semantic tree should be exported using something like XML instead.

We understand where you come from. However, here is a valid use case: let's say that the subTemplateList is supposed to export more than one instance (the normal case), but actually there is only one (this is an exception). In this case, we don’t want to change the exporter code just for this exception. On the top of that, it's interesting to convey that there is only one instance, which can be done with the subTemplateList encoding. 
Editorial: I would suggest reworking the illustrations in section 4.5. I'll talk about basicList here but this applies generally. Figures C and D are not particularly useful, they just illustrate how varlen works. In addition, by overloading the term "basicList Content", they risk being confusing. At the same time, Figures A and B make basicList look like alignment poison. However, the alignment-brokenness of varlen encoding and the alignment-brokenness of semantic tagging cancel each other out. So combining these would make things more easily understandable, and certainly prettier:

      0                   1                   2                   3 
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
     |      255      |      Length (0 to 65535)      |   Semantic    | 
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
     |        IE Number              |          Content          . . . 
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Well, this is more of an aesthetic change. The figures today clearly illustrate encoding w/ and without enterprise number, 1 and 3 byte encoding.
If we try to combine figures we may be losing some info - esp, that 1 or 3 byte encoding can be used.
While working on the examples, we realized that the 1 or 3 bytes encoding could be a source of confusion for the readers who are not completely familiar with IPFIX.

However, we took care of the "content" issue



 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Length (< 255)|               basicList Encoding ...          |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                      ... continuing as needed                 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 
Figure C: Variable-Length basicList Encoding (Length < 255 octets)
 
 
 
 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|      255      |      Length (0 to 65535)      |      ...      |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                     ... basicList Encoding                    |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure D: Variable-Length basicList Encoding (Length 0 to 65535 octets) 

    

      
(While I recall commenting on this a long time ago, I rescind my much-earlier "but isn't this technically independent from valen encoding?" I cannot think of a realistic example where you'd do this -> it just buys you the pain of not having structured data while forcing you to pay for it.)

Other specific points (copied from Gerhard's review)



      

        

          
    6. Template Management  

     This section introduces some more specific Template Management and 


        

        
_m_anagement


      

    

    done.

    

      

        

        

          
     Template Withdrawal Message-related specifications compared to the 
     IPFIX protocol specification [RFC5101]. 

     First of all, the Template ID uniqueness is unchanged compared to 
     [RFC5101]; the uniqueness is local to the Transport Session and 
     Observation Domain that generated the Template ID.  In other 
     words, the Set ID used to export the Template Record does not 
     influence the Template ID uniqueness. 

     While [RFC5101] mentions that: "If an Information Element is 
     required more than once in a Template, the different occurrences 
     of this Information Element SHOULD follow the logical order of 
     their treatments by the Metering Process.", this rule MAY not be 
     followed for the Structured Data Information Elements.   


        

      

      
While technically 2119-correct, the English here is a little confusing. Suggest:

"...this rule MAY be ignored within Structured Data Information Elements"


    

    Done.

    

      
This raises another point: there are now three ways to get multiple information elements into a Template: directly (in which case treatment-order is the only way to intepret), indirectly by a SDIE (in which case semantics rule; question: does "undefined" basicList default to allOf in treatment order?), directly with an SDIE (in subTemplateList/subTemplateMultiList, a Template containing multiple IEs directly still has those IEs interpreted as in treatment order, because the semantics apply only to the relationship among list members, not among IEs within list members).

It would be nice to see this addressed somewhere.


    

    There are two big different cases in our view

    1. The implementations that don't support IPFIX structured data
    -> they can only rely on RFC5101. 

    2. The implementations that do support IPFIX structured data 

        2.1 "undefined" 

    
"If the structured data contains the
        "undefined" structured data type semantic, the Collecting
        Process MAY
        attempt to draw its own conclusion in terms of the semantic
        contained in the
        Data Record."

        The typical example is an IPFIX Mediator that receives RFC5101
        but wants to send IPFIX structured data

        

      

        2.2.something different that "undefined"  

    
 Hopefully this is clearly defined ;-)

      

      

    

    Note: the semantic of  subTemplateMultiList will also be clarified.
    See our next email.
    
    

      

      

        

          
     As specified in [RFC5101], Templates that are not used anymore 
     SHOULD be deleted.  Before reusing a Template ID, the Template 
     MUST be deleted.  In order to delete an allocated Template, the 
     Template is withdrawn through the use of a Template Withdrawal 
     Message.  


        

        
You might clarify that deleting a Template implies that it may not be
used within subTemplateList and subTemplateMultiList any more.


      

      



    

    Corrected.

    
    
As
      specified in
      [RFC5101], Templates that are not used anymore SHOULD be deleted.  Deleting a Template implies that it may
        not
        be used within subTemplateList and subTemplateMultiList any more.  Before reusing a Template ID, the Template
      MUST be deleted.  In order to delete an
      allocated Template, the Template is withdrawn through the use of a
      Template
      Withdrawal Message.  

    

    Thanks for your feedback.

    

    Regards, Benoit

    

      
More to follow on the list, I'm sure; just wanted to make sure I got these points out before today's meeting.

Regards,

Brian

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


    

    

  


--------------050200010602020508050406--

From paitken@cisco.com  Thu Oct  7 06:35:38 2010
Return-Path: 
X-Original-To: ipfix@core3.amsl.com
Delivered-To: ipfix@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B752F3A702C for ; Thu,  7 Oct 2010 06:35:38 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.599
X-Spam-Level: 
X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[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 zbJ37zClVBqZ for ; Thu,  7 Oct 2010 06:35:37 -0700 (PDT)
Received: from rtp-iport-2.cisco.com (rtp-iport-2.cisco.com [64.102.122.149]) by core3.amsl.com (Postfix) with ESMTP id ED1363A6FEA for ; Thu,  7 Oct 2010 06:35:35 -0700 (PDT)
Authentication-Results: rtp-iport-2.cisco.com; dkim=neutral (message not signed) header.i=none
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AvsEAJ9prUxAZnwM/2dsb2JhbACiRXGqLJxJhUcEikCDAg
X-IronPort-AV: E=Sophos;i="4.57,297,1283731200"; d="scan'208";a="168055498"
Received: from rtp-core-1.cisco.com ([64.102.124.12]) by rtp-iport-2.cisco.com with ESMTP; 07 Oct 2010 13:36:38 +0000
Received: from cisco.com (mrwint.cisco.com [64.103.71.48]) by rtp-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id o97DabGR020874; Thu, 7 Oct 2010 13:36:37 GMT
Received: from [10.61.84.18] (ams3-vpn-dhcp5139.cisco.com [10.61.84.18]) by cisco.com (8.11.7p3+Sun/8.8.8) with ESMTP id o97DaZ815832; Thu, 7 Oct 2010 14:36:36 +0100 (BST)
Message-ID: <4CADCCDE.2090802@cisco.com>
Date: Thu, 07 Oct 2010 14:36:30 +0100
From: Paul Aitken 
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-GB; rv:1.9.2.9) Gecko/20100915 Lightning/1.0b2 Thunderbird/3.1.4
MIME-Version: 1.0
To: ipfix-chairs@tools.ietf.org, ipfix@ietf.org
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Subject: [IPFIX] IANA IPFIX registry
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, 07 Oct 2010 13:35:38 -0000

Dear all,

I've been requesting new IPFIX Information Elements from IANA. And I 
realised that there's a problem: there are no details of changes in the 
registry.

So I think that the registry should include a version number and 
revision history that's updated with each new field.

Then one can claim their implementation is compatible with v123, and 
quickly see what needs to be done to be compatible with v456.

Or an exporter and a collector can quickly and easily be compared to 
ensure they support the same elements, or at least a common set of 
elements required for a particular application.

P.

From paitken@cisco.com  Thu Oct  7 11:14:51 2010
Return-Path: 
X-Original-To: ipfix@core3.amsl.com
Delivered-To: ipfix@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B987E3A6F75 for ; Thu,  7 Oct 2010 11:14:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.599
X-Spam-Level: 
X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[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 vUD7rWwr8KgU for ; Thu,  7 Oct 2010 11:14:49 -0700 (PDT)
Received: from rtp-iport-1.cisco.com (rtp-iport-1.cisco.com [64.102.122.148]) by core3.amsl.com (Postfix) with ESMTP id 4F18F3A6EC6 for ; Thu,  7 Oct 2010 11:14:49 -0700 (PDT)
Authentication-Results: rtp-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AvsEAMeqrUxAZnwN/2dsb2JhbACiRXGvTpxehUcEikCDAg
X-IronPort-AV: E=Sophos;i="4.57,298,1283731200"; d="scan'208";a="167952620"
Received: from rtp-core-2.cisco.com ([64.102.124.13]) by rtp-iport-1.cisco.com with ESMTP; 07 Oct 2010 18:15:51 +0000
Received: from cisco.com (mrwint.cisco.com [64.103.71.48]) by rtp-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id o97IFpfI001372; Thu, 7 Oct 2010 18:15:51 GMT
Received: from [10.55.94.52] (dhcp-10-55-94-52.cisco.com [10.55.94.52]) by cisco.com (8.11.7p3+Sun/8.8.8) with ESMTP id o97IFn806655; Thu, 7 Oct 2010 19:15:49 +0100 (BST)
Message-ID: <4CAE0E50.7050005@cisco.com>
Date: Thu, 07 Oct 2010 19:15:44 +0100
From: Paul Aitken 
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-GB; rv:1.9.2.9) Gecko/20100915 Lightning/1.0b2 Thunderbird/3.1.4
MIME-Version: 1.0
To: Brian Trammell 
References: 
In-Reply-To: 
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Cc: ipfix@ietf.org, ipfix-chairs@tools.ietf.org
Subject: Re: [IPFIX] IANA IPFIX registry
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, 07 Oct 2010 18:14:51 -0000

Brian,

There's currently no way to know what was added to the registry when,
which I think will be important in future for the reasons below.

So I'd like to see something added ASAP.

It could be as simple as recording the date and a list of fields added, 
modified or removed.

BTW, I do plan on reviewing the IE doctors draft.

P.


On 07/10/10 14:43, Brian Trammell wrote:
> Hi, Paul,
>
> Good idea. Have a look at the recently submitted
> draft-trammell-ipfix-ie-doctors; we don't currently specify
> versioning, but specifying (or, if we want to bring versioning online
> in less time than it takes to publish a draft, explaining and
> referencing) a policy for that would fit very nicely in a future
> version thereof...
>
> Cheers,
>
> Brian
>
> --- On Oct 7, 2010, at 3:36 PM, Paul Aitken wrote: ---
>
> Dear all,
>
> I've been requesting new IPFIX Information Elements from IANA. And I
> realised that there's a problem: there are no details of changes in
> the registry.
>
> So I think that the registry should include a version number and
> revision history that's updated with each new field.
>
> Then one can claim their implementation is compatible with v123, and
> quickly see what needs to be done to be compatible with v456.
>
> Or an exporter and a collector can quickly and easily be compared to
> ensure they support the same elements, or at least a common set of
> elements required for a particular application.
>
> P.
> _______________________________________________
> IPFIX mailing list
> IPFIX@ietf.org
> https://www.ietf.org/mailman/listinfo/ipfix


From britram@gmail.com  Thu Oct  7 06:42:58 2010
Return-Path: 
X-Original-To: ipfix@core3.amsl.com
Delivered-To: ipfix@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8EB553A6FC3 for ; Thu,  7 Oct 2010 06:42:58 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.92
X-Spam-Level: 
X-Spam-Status: No, score=-1.92 tagged_above=-999 required=5 tests=[AWL=0.057,  BAYES_00=-2.599, FM_FORGED_GMAIL=0.622]
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 1AXJey492D8m for ; Thu,  7 Oct 2010 06:42:56 -0700 (PDT)
Received: from mail-gx0-f172.google.com (mail-gx0-f172.google.com [209.85.161.172]) by core3.amsl.com (Postfix) with ESMTP id 8A3A03A6F33 for ; Thu,  7 Oct 2010 06:42:56 -0700 (PDT)
Received: by gxk20 with SMTP id 20so352021gxk.31 for ; Thu, 07 Oct 2010 06:43:58 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:sender:received:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=ATjZp4fwzf+ZDJ4jDayCUrbTgbAXeMesDA4tr/NdSqQ=; b=lEyw/+An7WW3m9689pvpSwPD1DG6awloPESgeSBulkgE1cDge98l18CH47s6IhcRti mKzYyJxNzefUKBj+2HCvEwjHBPYyIuKQP9w2bi+mngwK1AexTnh05ulJIbafRMN5hmEJ gVFnVsXx0myNpYZEwdJ/RDYQ3aViCIfCbA1EI=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:date:x-google-sender-auth:message-id:subject :from:to:cc:content-type; b=LUjaAeybEWpcKDMlWYKY9CGAYZMmBZroknOb4+uxNsTku/WczjbgYbN3M7VAM36ugY ugRgl7OtqnhJqMViSW2AgK1q7U4yZoa2Vu/lXEbQpqOqxGauXAAdsdH5SOhduDCLNXHA QvjkmzquNlQy0Lv4BsyAwPKWCmA/c5IOVVAH0=
MIME-Version: 1.0
Received: by 10.42.171.9 with SMTP id h9mr827449icz.2.1286459038556; Thu, 07 Oct 2010 06:43:58 -0700 (PDT)
Sender: britram@gmail.com
Received: by 10.42.1.9 with HTTP; Thu, 7 Oct 2010 06:43:58 -0700 (PDT)
Date: Thu, 7 Oct 2010 15:43:58 +0200
X-Google-Sender-Auth: esiCKmp61jxHl98yKCa8O-WKo2s
Message-ID: 
From: Brian Trammell 
To: Paul Aitken 
Content-Type: text/plain; charset=ISO-8859-1
X-Mailman-Approved-At: Thu, 07 Oct 2010 14:26:02 -0700
Cc: ipfix@ietf.org, ipfix-chairs@tools.ietf.org
Subject: Re: [IPFIX] IANA IPFIX registry
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, 07 Oct 2010 13:42:59 -0000

Hi, Paul,

Good idea. Have a look at the recently submitted
draft-trammell-ipfix-ie-doctors; we don't currently specify
versioning, but specifying (or, if we want to bring versioning online
in less time than it takes to publish a draft, explaining and
referencing) a policy for that would fit very nicely in a future
version thereof...

Cheers,

Brian

--- On Oct 7, 2010, at 3:36 PM, Paul Aitken wrote: ---

Dear all,

I've been requesting new IPFIX Information Elements from IANA. And I
realised that there's a problem: there are no details of changes in
the registry.

So I think that the registry should include a version number and
revision history that's updated with each new field.

Then one can claim their implementation is compatible with v123, and
quickly see what needs to be done to be compatible with v456.

Or an exporter and a collector can quickly and easily be compared to
ensure they support the same elements, or at least a common set of
elements required for a particular application.

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

From HKaplan@acmepacket.com  Thu Oct  7 16:04:33 2010
Return-Path: 
X-Original-To: ipfix@core3.amsl.com
Delivered-To: ipfix@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E639D3A6FF7 for ; Thu,  7 Oct 2010 16:04:33 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.484
X-Spam-Level: 
X-Spam-Status: No, score=-2.484 tagged_above=-999 required=5 tests=[AWL=0.115,  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 s7K2PjEgB5J9 for ; Thu,  7 Oct 2010 16:04:32 -0700 (PDT)
Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6]) by core3.amsl.com (Postfix) with ESMTP id E3E413A6FA3 for ; Thu,  7 Oct 2010 16:04:31 -0700 (PDT)
Received: from mail.acmepacket.com (216.41.24.7) by etmail.acmepacket.com (216.41.24.6) with Microsoft SMTP Server (TLS) id 8.2.254.0; Thu, 7 Oct 2010 19:05:35 -0400
Received: from mail.acmepacket.com ([127.0.0.1]) by mail ([127.0.0.1]) with mapi; Thu, 7 Oct 2010 19:05:34 -0400
From: Hadriel Kaplan 
To: Brian Trammell 
Date: Thu, 7 Oct 2010 19:05:33 -0400
Thread-Topic: [IPFIX] Fwd: New Version Notification for draft-trammell-ipfix-ie-doctors-00
Thread-Index: ActmdCUek1fEKLILTYywekpuVFHm5w==
Message-ID: <8FC4E1A0-0FCF-46A7-BDF2-AA3E2D21227D@acmepacket.com>
References: <20101001120148.9042B3A74D4@core3.amsl.com> <6A7213D7-64ED-4D3B-AD8D-CBAD105F21B5@tik.ee.ethz.ch>
In-Reply-To: <6A7213D7-64ED-4D3B-AD8D-CBAD105F21B5@tik.ee.ethz.ch>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: "ipfix@ietf.org Group" 
Subject: Re: [IPFIX] Fwd: New Version Notification for	draft-trammell-ipfix-ie-doctors-00
X-BeenThere: ipfix@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: IPFIX WG discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 07 Oct 2010 23:04:34 -0000

Hi Brian,
I read this draft, and most of it seems good/useful/motherhood-and-apple-pi=
e.

The only substantive comment/question I have is on section 9, the textual I=
ESpec stuff.  Do we really need yet another textual representation of meta-=
data?  Isn't there already an XML-based one from rfc5102? =20

I note your statement that the design goal was compactness and not needing =
XML support, but it's not clear why those properties matter when the meta-d=
ata is never on the wire in its textual form.  Don't get me wrong, I'm not =
an XML fan by any stretch, but I'd hate to have two textual representation =
formats for one protocol, and re-inventing the wheel with yet-another-new-f=
ormat seems silly. (Nevermind that the IETF already uses SMI/ASN.1 for SNMP=
, XML for DIAMETER, ABNF for a HTTP/SIP/RTSP/SMTP/etc., defacto-standards f=
or RADIUS and DNS, and who knows what else. :)

It's also kinda weird to have a new text format in a Guidelines doc.

-hadriel


On Oct 1, 2010, at 8:15 AM, Brian Trammell wrote:

> Greetings, all:
>=20
> A first draft of the IE-Doctors draft discussed in Maastricht has been po=
sted; this presents a reasonably complete discussion of the issues surround=
ing efficient extension of the Information Element registry and definition =
of new IPFIX applications in Internet-Drafts. We intend to discuss this as =
a future BCP at the meeting in Beijing. Reviews and comments in the meantim=
e are of course appreciated. :)
>=20
> Best regards,
>=20
> Brian
>=20
> Begin forwarded message:
>=20
>> From: IETF I-D Submission Tool 
>> Date: October 1, 2010 2:01:48 PM GMT+02:00
>> To: trammell@tik.ee.ethz.ch
>> Cc: bclaise@cisco.com
>> Subject: New Version Notification for draft-trammell-ipfix-ie-doctors-00=
=20
>>=20
>>=20
>> A new version of I-D, draft-trammell-ipfix-ie-doctors-00.txt has been su=
ccessfully submitted by Brian Trammell and posted to the IETF repository.
>>=20
>> Filename:	 draft-trammell-ipfix-ie-doctors
>> Revision:	 00
>> Title:		 Guidelines for Authors and Reviewers of IPFIX Information Eleme=
nts
>> Creation_date:	 2010-10-01
>> WG ID:		 Independent Submission
>> Number_of_pages: 22
>>=20
>> Abstract:
>> This document provides guidelines for the definition of IPFIX
>> Information Elements for addition to the IANA IPFIX Information
>> Element registry, in order to extend the applicability of the IPFIX
>> protocol to new operations and management areas.
>>=20
>>=20
>>=20
>> The IETF Secretariat.
>>=20
>=20
> _______________________________________________
> IPFIX mailing list
> IPFIX@ietf.org
> https://www.ietf.org/mailman/listinfo/ipfix


From trammell@tik.ee.ethz.ch  Thu Oct  7 23:38:40 2010
Return-Path: 
X-Original-To: ipfix@core3.amsl.com
Delivered-To: ipfix@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C19A33A6839 for ; Thu,  7 Oct 2010 23:38:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.599
X-Spam-Level: 
X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mLAfBStAwzj0 for ; Thu,  7 Oct 2010 23:38:38 -0700 (PDT)
Received: from smtp.ee.ethz.ch (smtp.ee.ethz.ch [129.132.2.219]) by core3.amsl.com (Postfix) with ESMTP id 72C133A67B2 for ; Thu,  7 Oct 2010 23:38:38 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by smtp.ee.ethz.ch (Postfix) with ESMTP id 7CE36D93D8; Fri,  8 Oct 2010 08:39:41 +0200 (MEST)
X-Virus-Scanned: by amavisd-new on smtp.ee.ethz.ch
Received: from smtp.ee.ethz.ch ([127.0.0.1]) by localhost (.ee.ethz.ch [127.0.0.1]) (amavisd-new, port 10024) with LMTP id TpmH7LTqdc4u; Fri,  8 Oct 2010 08:39:41 +0200 (MEST)
Received: from [192.168.0.188] (77-57-164-35.dclient.hispeed.ch [77.57.164.35]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: briant) by smtp.ee.ethz.ch (Postfix) with ESMTPSA id 20DACD93C3; Fri,  8 Oct 2010 08:39:41 +0200 (MEST)
Mime-Version: 1.0 (Apple Message framework v1081)
Content-Type: text/plain; charset=us-ascii
From: Brian Trammell 
In-Reply-To: <8FC4E1A0-0FCF-46A7-BDF2-AA3E2D21227D@acmepacket.com>
Date: Fri, 8 Oct 2010 08:39:41 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: 
References: <20101001120148.9042B3A74D4@core3.amsl.com> <6A7213D7-64ED-4D3B-AD8D-CBAD105F21B5@tik.ee.ethz.ch> <8FC4E1A0-0FCF-46A7-BDF2-AA3E2D21227D@acmepacket.com>
To: Hadriel Kaplan 
X-Mailer: Apple Mail (2.1081)
Cc: "ipfix@ietf.org Group" 
Subject: Re: [IPFIX] Fwd: New Version Notification for draft-trammell-ipfix-ie-doctors-00
X-BeenThere: ipfix@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: IPFIX WG discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 08 Oct 2010 06:38:40 -0000

Hi, Hadriel,

Thanks for the feedback.

The primary design goal of the IESpec format is human readability in the =
expression of information model extensions and templates, while =
maintaining simple machine readability. The idea is implementors can =
read an Internet Draft about an IPFIX application with example templates =
in IESpec form, copy and paste the example templates out of it into an =
implementation supporting IEspec, fill in the fields and go. For =
readability and compactness, it's intended to address shortcomings both =
in the XML format(s) already defined for IPFIX IEs, and in the =
traditional 32-bit-wide box-and-line diagrams, which make it difficult =
to fit a nontrivial template onto a single page, and require some manual =
work to turn into an implementation.

The XML format in 5102 has been partially superceded by the one used by =
IANA internally (I'm not sure the extent to which the one uses the =
elements from the other, it's been a while), and is specifically =
targeted only for defining Informatio=01n Elements to be added to the =
registry. (If you need to put IE metadata on the wire, e.g. to define =
enterprise-specific IEs in long-term storage, 5610 covers that.)

As to the structure, you have a point; it's a little tacked on. IESpec =
was formerly (well, currently; it's not expired yet) its own document, =
and integrated into ie-doctors on several suggestions in Maastricht; I'm =
not yet decided where it belongs...

Cheers,

Brian

On Oct 8, 2010, at 1:05 AM, Hadriel Kaplan wrote:

>=20
> Hi Brian,
> I read this draft, and most of it seems =
good/useful/motherhood-and-apple-pie.
>=20
> The only substantive comment/question I have is on section 9, the =
textual IESpec stuff.  Do we really need yet another textual =
representation of meta-data?  Isn't there already an XML-based one from =
rfc5102? =20
>=20
> I note your statement that the design goal was compactness and not =
needing XML support, but it's not clear why those properties matter when =
the meta-data is never on the wire in its textual form.  Don't get me =
wrong, I'm not an XML fan by any stretch, but I'd hate to have two =
textual representation formats for one protocol, and re-inventing the =
wheel with yet-another-new-format seems silly. (Nevermind that the IETF =
already uses SMI/ASN.1 for SNMP, XML for DIAMETER, ABNF for a =
HTTP/SIP/RTSP/SMTP/etc., defacto-standards for RADIUS and DNS, and who =
knows what else. :)
>=20
> It's also kinda weird to have a new text format in a Guidelines doc.
>=20
> -hadriel
>=20
>=20
> On Oct 1, 2010, at 8:15 AM, Brian Trammell wrote:
>=20
>> Greetings, all:
>>=20
>> A first draft of the IE-Doctors draft discussed in Maastricht has =
been posted; this presents a reasonably complete discussion of the =
issues surrounding efficient extension of the Information Element =
registry and definition of new IPFIX applications in Internet-Drafts. We =
intend to discuss this as a future BCP at the meeting in Beijing. =
Reviews and comments in the meantime are of course appreciated. :)
>>=20
>> Best regards,
>>=20
>> Brian
>>=20
>> Begin forwarded message:
>>=20
>>> From: IETF I-D Submission Tool 
>>> Date: October 1, 2010 2:01:48 PM GMT+02:00
>>> To: trammell@tik.ee.ethz.ch
>>> Cc: bclaise@cisco.com
>>> Subject: New Version Notification for =
draft-trammell-ipfix-ie-doctors-00=20
>>>=20
>>>=20
>>> A new version of I-D, draft-trammell-ipfix-ie-doctors-00.txt has =
been successfully submitted by Brian Trammell and posted to the IETF =
repository.
>>>=20
>>> Filename:	 draft-trammell-ipfix-ie-doctors
>>> Revision:	 00
>>> Title:		 Guidelines for Authors and Reviewers of IPFIX =
Information Elements
>>> Creation_date:	 2010-10-01
>>> WG ID:		 Independent Submission
>>> Number_of_pages: 22
>>>=20
>>> Abstract:
>>> This document provides guidelines for the definition of IPFIX
>>> Information Elements for addition to the IANA IPFIX Information
>>> Element registry, in order to extend the applicability of the IPFIX
>>> protocol to new operations and management areas.
>>>=20
>>>=20
>>>=20
>>> The IETF Secretariat.
>>>=20
>>=20
>> _______________________________________________
>> IPFIX mailing list
>> IPFIX@ietf.org
>> https://www.ietf.org/mailman/listinfo/ipfix


From root@core3.amsl.com  Fri Oct  8 04:45:01 2010
Return-Path: 
X-Original-To: ipfix@ietf.org
Delivered-To: ipfix@core3.amsl.com
Received: by core3.amsl.com (Postfix, from userid 0) id 950EF3A6884; Fri,  8 Oct 2010 04:45: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: <20101008114501.950EF3A6884@core3.amsl.com>
Date: Fri,  8 Oct 2010 04:45:01 -0700 (PDT)
Cc: ipfix@ietf.org
Subject: [IPFIX] I-D Action:draft-ietf-ipfix-anon-04.txt
X-BeenThere: ipfix@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: IPFIX WG discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 08 Oct 2010 11:45:01 -0000

--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the IP Flow Information Export Working Group of the IETF.


	Title           : IP Flow Anonymisation Support
	Author(s)       : E. Boschi, B. Trammell
	Filename        : draft-ietf-ipfix-anon-04.txt
	Pages           : 41
	Date            : 2010-10-08

This document describes anonymisation techniques for IP flow data and
the export of anonymised data using the IPFIX protocol.  It
categorizes common anonymisation schemes and defines the parameters
needed to describe them.  It provides guidelines for the
implementation of anonymised data export and storage over IPFIX, and
describes an information model and Options-based method for
anonymisation metadata export within the IPFIX protocol or storage in
IPFIX Files.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-ipfix-anon-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-anon-04.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID: <2010-10-08044500.I-D@ietf.org>


--NextPart--

From trammell@tik.ee.ethz.ch  Fri Oct  8 04:49:24 2010
Return-Path: 
X-Original-To: ipfix@core3.amsl.com
Delivered-To: ipfix@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AA52C3A6870 for ; Fri,  8 Oct 2010 04:49:24 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.505
X-Spam-Level: 
X-Spam-Status: No, score=-6.505 tagged_above=-999 required=5 tests=[AWL=0.092,  BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_HTML_MOSTLY=0.001, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xPxF8zDVZcIH for ; Fri,  8 Oct 2010 04:49:23 -0700 (PDT)
Received: from smtp.ee.ethz.ch (smtp.ee.ethz.ch [129.132.2.219]) by core3.amsl.com (Postfix) with ESMTP id 2C10D3A6884 for ; Fri,  8 Oct 2010 04:49:23 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by smtp.ee.ethz.ch (Postfix) with ESMTP id 5CBB5D936B for ; Fri,  8 Oct 2010 13:50:27 +0200 (MEST)
X-Virus-Scanned: by amavisd-new on smtp.ee.ethz.ch
Received: from smtp.ee.ethz.ch ([127.0.0.1]) by localhost (.ee.ethz.ch [127.0.0.1]) (amavisd-new, port 10024) with LMTP id M8uLdPPWlo5h for ; Fri,  8 Oct 2010 13:50:27 +0200 (MEST)
Received: from etx-public-dock-69-dhcp.ethz.ch (etx-public-dock-69-dhcp.ethz.ch [82.130.81.69]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: briant) by smtp.ee.ethz.ch (Postfix) with ESMTPSA id 0708BD93F3 for ; Fri,  8 Oct 2010 13:50:27 +0200 (MEST)
From: Brian Trammell 
Content-Type: multipart/alternative; boundary=Apple-Mail-20--1006218713
Date: Fri, 8 Oct 2010 13:50:26 +0200
References: <20101008114501.950EF3A6884@core3.amsl.com>
To: "ipfix@ietf.org Group" 
Message-Id: <253EF01E-3F20-4635-AA00-5B4DC76129DC@tik.ee.ethz.ch>
Mime-Version: 1.0 (Apple Message framework v1081)
X-Mailer: Apple Mail (2.1081)
Subject: [IPFIX] Fwd:  I-D Action:draft-ietf-ipfix-anon-04.txt
X-BeenThere: ipfix@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: IPFIX WG discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 08 Oct 2010 11:49:24 -0000

--Apple-Mail-20--1006218713
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=us-ascii

Greetings, all,

We've submitted a new revision -04 of the anon draft, addressing some =
IDNITS issues (address space, document formatting, and references =
obsoleted since the initial submission) and updating author addresses. =
There are no substantive content changes to the document.=20

Best regards,

Brian

Begin forwarded message:

> From: Internet-Drafts@ietf.org
> Date: October 8, 2010 1:45:01 PM GMT+02:00
> To: i-d-announce@ietf.org
> Cc: ipfix@ietf.org
> Subject: [IPFIX] I-D Action:draft-ietf-ipfix-anon-04.txt
>=20
> 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.
>=20
>=20
> 	Title           : IP Flow Anonymisation Support
> 	Author(s)       : E. Boschi, B. Trammell
> 	Filename        : draft-ietf-ipfix-anon-04.txt
> 	Pages           : 41
> 	Date            : 2010-10-08
>=20
> This document describes anonymisation techniques for IP flow data and
> the export of anonymised data using the IPFIX protocol.  It
> categorizes common anonymisation schemes and defines the parameters
> needed to describe them.  It provides guidelines for the
> implementation of anonymised data export and storage over IPFIX, and
> describes an information model and Options-based method for
> anonymisation metadata export within the IPFIX protocol or storage in
> IPFIX Files.
>=20
> A URL for this Internet-Draft is:
> http://www.ietf.org/internet-drafts/draft-ietf-ipfix-anon-04.txt
>=20
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/
>=20
> Below is the data which will enable a MIME compliant mail reader
> implementation to automatically retrieve the ASCII version of the
> Internet-Draft.
> _______________________________________________
> IPFIX mailing list
> IPFIX@ietf.org
> https://www.ietf.org/mailman/listinfo/ipfix


--Apple-Mail-20--1006218713
Content-Type: multipart/mixed;
	boundary=Apple-Mail-21--1006218713


--Apple-Mail-21--1006218713
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=us-ascii


Date: October 8, 2010 1:45:01 PM =
GMT+02:00
Subject: [IPFIX] I-D =
Action:draft-ietf-ipfix-anon-04.txt

A New =
Internet-Draft is available from the on-line Internet-Drafts =
directories.
This draft is a work item of the IP Flow Information =
Export Working Group of the IETF.


	Title =
          : IP Flow =
Anonymisation Support
	Author(s) =
      : E. Boschi, B. Trammell
	Filename =
       : =
draft-ietf-ipfix-anon-04.txt
	Pages =
          : =
41
	=
Date =
           : =
2010-10-08

This document describes anonymisation techniques for =
IP flow data and
the export of anonymised data using the IPFIX =
protocol.  It
categorizes common anonymisation schemes and =
defines the parameters
needed to describe them.  It provides =
guidelines for the
implementation of anonymised data export and =
storage over IPFIX, and
describes an information model and =
Options-based method for
anonymisation metadata export within the =
IPFIX protocol or storage in
IPFIX Files.

A URL for this =
Internet-Draft is:
=
http://www.ietf.org/internet-drafts/draft-ietf-ipfix-anon-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.
=

--Apple-Mail-21--1006218713
Content-Disposition: attachment;
	filename="Mail Attachment"
Content-Type: message/external-body;
	name="Mail Attachment"
Content-Transfer-Encoding: 7bit

Content-Type: text/plain
Content-ID: <2010-10-08044500.I-D@ietf.org>




--Apple-Mail-21--1006218713
Content-Transfer-Encoding: 7bit
Content-Type: text/html;
	charset=us-ascii


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


--Apple-Mail-21--1006218713--

--Apple-Mail-20--1006218713--

From HKaplan@acmepacket.com  Fri Oct  8 12:26:22 2010
Return-Path: 
X-Original-To: ipfix@core3.amsl.com
Delivered-To: ipfix@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2C42D3A68CE for ; Fri,  8 Oct 2010 12:26:22 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.035
X-Spam-Level: 
X-Spam-Status: No, score=-1.035 tagged_above=-999 required=5 tests=[AWL=-1.336, BAYES_00=-2.599, J_CHICKENPOX_52=0.6, MANGLED_PENIS=2.3]
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 BY4t+vJT55Jr for ; Fri,  8 Oct 2010 12:26:21 -0700 (PDT)
Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6]) by core3.amsl.com (Postfix) with ESMTP id C35B23A689D for ; Fri,  8 Oct 2010 12:26:20 -0700 (PDT)
Received: from mail.acmepacket.com (216.41.24.7) by etmail.acmepacket.com (216.41.24.6) with Microsoft SMTP Server (TLS) id 8.2.254.0; Fri, 8 Oct 2010 15:27:25 -0400
Received: from mail.acmepacket.com ([127.0.0.1]) by mail ([127.0.0.1]) with mapi; Fri, 8 Oct 2010 15:27:04 -0400
From: Hadriel Kaplan 
To: Brian Trammell 
Date: Fri, 8 Oct 2010 15:27:03 -0400
Thread-Topic: [IPFIX] Fwd: New Version Notification for draft-trammell-ipfix-ie-doctors-00
Thread-Index: ActnHsmcjZO1MeNHS+ylKa8Fv6Ramg==
Message-ID: <7A6C26A5-FC0E-466F-A1FE-D7E63271FE61@acmepacket.com>
References: <20101001120148.9042B3A74D4@core3.amsl.com> <6A7213D7-64ED-4D3B-AD8D-CBAD105F21B5@tik.ee.ethz.ch> <8FC4E1A0-0FCF-46A7-BDF2-AA3E2D21227D@acmepacket.com> 
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: "ipfix@ietf.org Group" 
Subject: Re: [IPFIX] Fwd: New Version Notification for draft-trammell-ipfix-ie-doctors-00
X-BeenThere: ipfix@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: IPFIX WG discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 08 Oct 2010 19:26:22 -0000

Hi Brian,
comments inline...

On Oct 8, 2010, at 2:39 AM, Brian Trammell wrote:

> Hi, Hadriel,
>=20
> Thanks for the feedback.
>=20
> The primary design goal of the IESpec format is human readability in the =
expression of information model extensions and templates, while maintaining=
 simple machine readability. The idea is implementors can read an Internet =
Draft about an IPFIX application with example templates in IESpec form, cop=
y and paste the example templates out of it into an implementation supporti=
ng IEspec, fill in the fields and go.

At the end of the day what we're talking about is a form of a "dictionary" =
file, similar to those used for other protocols, like for SNMP, DIAMETER, R=
ADIUS, etc.  Right?  Like not just for putting into a RFC, but more importa=
ntly for importing into a reader so it can decode and understand the IEs, r=
ight?

Again, I'm not a big fan of XML, but there are a ton of XML parser librarie=
s available, and the importing of that into a reader so it can understand t=
he new IEs is done rarely, and with a CPU (not an FPGA or network processor=
).  Libraries exist to not only read them, but verify their correctness usi=
ng a schema.  Further, they support comments and text descriptions, which a=
re useful for an IPFIX reader importing them.  An IPFIX reader can use thos=
e to display in a GUI as additional help, and a human can use them to under=
stand stuff when he/she reads the XML. =20

For example, suppose vendor BigCorp wants to give out such a "dictionary" f=
ile for some PEN IEs its BigBox generates, so that IPFIX Readers can decode=
 them.  One of those PEN IEs is for a "camFlowId".  In IESpec, it might be:
camFlowId(35566/123)[4]

That doesn't tell the human nor the IPFIX collector/reader much info.  In X=
ML it's a lot longer text, but it can include some more info like this:
       
         
           An identifier of a single Content Addressable Memory index alloc=
ated for the flow.  Two CAM entries are allocated, for each direction, unle=
ss the system is provisioned otherwise.
         
       
       
         
         See BigCorp User Manual chapter titled "Hardware Resources" for mo=
re information.
         
       

And the file can even have a "<-- BigCorp dictionary file for BigCorp BigBo=
x 10000 System, version 1.2.3. Created 2-10-2010 -->" comment at the top.



> For readability and compactness, it's intended to address shortcomings bo=
th in the XML format(s) already defined for IPFIX IEs

What shortcomings?  There're some fields I think it should have that it doe=
sn't, and the structure of it is weird, but  I'm a nitpicker.  Is there som=
ething fatally wrong with it?


> and in the traditional 32-bit-wide box-and-line diagrams, which make it d=
ifficult to fit a nontrivial template onto a single page, and require some =
manual work to turn into an implementation.

This is one of the things I was worried about - that we would be saying thi=
s would avoid showing things in 32-bit-wide box-and-line diagrams.  I find =
those drawings are really, really useful.  For example, I couldn't make hea=
ds or tails of the structured-data draft until I saw those examples. =20

Fitting them on a page is not a serious issue really, is it?  I mean if it =
crosses pages, people can deal.  I know it takes more work to draw them, bu=
t you're writing an RFC for others to be able to interop with you, so that'=
s life.  If a nontrivial template is difficult to draw, maybe that will enc=
ourage people to not make complicated templates. :)  I'm half joking, but m=
y point is the work to write the RFC is really moot compared to helping peo=
ple reading the RFC implementing it right. =20


> The XML format in 5102 has been partially superceded by the one used by I=
ANA internally (I'm not sure the extent to which the one uses the elements =
from the other, it's been a while), and is specifically targeted only for d=
efining Informatio=01n Elements to be added to the registry. (If you need t=
o put IE metadata on the wire, e.g. to define enterprise-specific IEs in lo=
ng-term storage, 5610 covers that.)

Right, I know 5610 puts the meta-data on the wire, and IESpec looks to me l=
ike basically just a text transformation of that.  But I see 5610 as a limi=
ted functionality, last-resort solution, in case the reader/collector has n=
o real dictionary file available. (it seems odd to me that there's really a=
 use-case for that in practice, but that's just me)  The point is because i=
t's on-the-wire it has to be terse and limited, but a real dictionary file =
shouldn't be.

-hadriel=

From HKaplan@acmepacket.com  Fri Oct  8 15:56:51 2010
Return-Path: 
X-Original-To: ipfix@core3.amsl.com
Delivered-To: ipfix@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 733663A6985 for ; Fri,  8 Oct 2010 15:56:51 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.475
X-Spam-Level: 
X-Spam-Status: No, score=-2.475 tagged_above=-999 required=5 tests=[AWL=0.124,  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 d1mqA290bhO8 for ; Fri,  8 Oct 2010 15:56:48 -0700 (PDT)
Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6]) by core3.amsl.com (Postfix) with ESMTP id F3A2F3A697E for ; Fri,  8 Oct 2010 15:56:47 -0700 (PDT)
Received: from mail.acmepacket.com (216.41.24.7) by etmail.acmepacket.com (216.41.24.6) with Microsoft SMTP Server (TLS) id 8.2.254.0; Fri, 8 Oct 2010 18:57:51 -0400
Received: from mail.acmepacket.com ([127.0.0.1]) by mail ([127.0.0.1]) with mapi; Fri, 8 Oct 2010 18:57:45 -0400
From: Hadriel Kaplan 
To: Benoit Claise 
Date: Fri, 8 Oct 2010 18:57:44 -0400
Thread-Topic: [IPFIX] Review: draft-ietf-ipfix-structured-data-02.txt
Thread-Index: ActnPDgfDSsHNQKUQze+KaR91G+dpA==
Message-ID: 
References: <4C4E996E.2000300@net.in.tum.de>  <4CAC26B6.9010003@cisco.com>
In-Reply-To: <4CAC26B6.9010003@cisco.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
Content-Type: text/plain; charset="Windows-1252"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: IETF IPFIX Working Group 
Subject: Re: [IPFIX] Review: draft-ietf-ipfix-structured-data-02.txt
X-BeenThere: ipfix@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: IPFIX WG discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 08 Oct 2010 22:56:51 -0000

Hi Benoit,=20
comments inline...

On Oct 6, 2010, at 3:35 AM, Benoit Claise wrote:

> Brian,
> Thanks for your review. Reply in line.
>> Second comment: the document is in places somewhat implementation-specif=
ic, but presents these implementation specific things as essential parts of=
 the problem. The most glaring of these is the recommendation to use three-=
byte encoding for all varlen fields (Section 5.1, Page 26). It might be use=
ful to note that certain lazy-evaluating exporters might do this, so that c=
ollectors won't assume they'll never see such inefficient things FF 00 01 a=
s a length (i.e., a three byte encoding of "1") -- but if they're 5101-comp=
liant, this won't cause any problems. :)
>>=20
> We think the length of structured data isn't known ahead of time.
> It's not that exporters are lazy, but performance can also be a concern
> if the length needs to be computed ahead of time or the content needs to
> be copied back and forth to use 1 or 3 byte encoding based on length.
> Hence the recommendation, its not a MUST. So, exporters can choose to do
> otherwise.=20

I think showing it with the 3-byte encoding is actually good, including and=
 especially for a case of the length being smaller than 255 bytes.  It's a =
good way to remind implementors they will see this, and will likely appear =
in practice. (when I encode a IPFIX data, I don't want to put an if() state=
ment in checking for greater than 255 then use 3 bytes - I'll ALWAYS use 3-=
byte encoding... and it's not laziness, it's less code to get wrong)


>> I have some other "high-level" applicability concerns - it should be cle=
ar than IPFIX is still mostly useful in situations where _most_ things fit =
into the outer template, and SDIEs are used for additional sub-record-level=
 structure. A guideline I'd like to see here: if you ever export a template=
 just containing one subTemplateList, you should be exporting a Set instead=
. If you're ever exporting a template just containing one subTemplateMultiL=
ist, what you want is a Message. IPFIX records that are _just_ used as the =
root of a depth-first traversal of a semantic tree should be exported using=
 something like XML instead.=20
>=20
> We understand where you come from. However, here is a valid use case: let=
's say that the subTemplateList is supposed to export more than one instanc=
e (the normal case), but actually there is only one (this is an exception).=
 In this case, we don=92t want to change the exporter code just for this ex=
ception. On the top of that, it's interesting to convey that there is only =
one instance, which can be done with the subTemplateList encoding.

I don't think Brian's talking about the case of an exporter only encoding o=
ne list entry for a specific Data Record - I think he means when someone cr=
eates a new Template and all it has in it is a single subTemplate*List IE, =
with no other IEs.  You wouldn't need to do that, because an IPFIX Set effe=
ctively is a subTemplateList (because all data records in it are the "list"=
 entries and follow the same template), and an IPFIX Message is a subTempla=
teMultiList (because each Set is an entry in the "list" and identifies its =
Template).  Right?

Having said that, subTemplate*List provide something new which Set and Mess=
age don't: the semantic indicator.


>> Editorial: I would suggest reworking the illustrations in section 4.5. I=
'll talk about basicList here but this applies generally. Figures C and D a=
re not particularly useful, they just illustrate how varlen works. In addit=
ion, by overloading the term "basicList Content", they risk being confusing=
. At the same time, Figures A and B make basicList look like alignment pois=
on. However, the alignment-brokenness of varlen encoding and the alignment-=
brokenness of semantic tagging cancel each other out. So combining these wo=
uld make things more easily understandable, and certainly prettier
> Well, this is more of an aesthetic change. The figures today clearly illu=
strate encoding w/ and without enterprise number, 1 and 3 byte encoding.=20
> If we try to combine figures we may be losing some info - esp, that 1 or =
3 byte encoding can be used.=20
> While working on the examples, we realized that the 1 or 3 bytes encoding=
 could be a source of confusion for the readers who are not completely fami=
liar with IPFIX.

Ironically, when I read the draft the first time I thought exactly what Bri=
an's saying: alignment poison.  I was shocked there was a 1-byte "semantic"=
 field, and was thinking how crazy it was to have this field for something =
so esoteric, and was thinking how there needs to be a basicBasicList.  Then=
 once I saw the examples of the messages and how it fit in the alignment, I=
 realized the error of my ways, and am now thinking how great this semantic=
 field is. :)
(Well, I still think it's weird, but I'll comment on that in a separate ema=
il)

-hadriel





From HKaplan@acmepacket.com  Sat Oct  9 09:16:28 2010
Return-Path: 
X-Original-To: ipfix@core3.amsl.com
Delivered-To: ipfix@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 03E743A68E1 for ; Sat,  9 Oct 2010 09:16:28 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.876
X-Spam-Level: 
X-Spam-Status: No, score=-1.876 tagged_above=-999 required=5 tests=[AWL=-0.477, BAYES_00=-2.599, J_CHICKENPOX_25=0.6, J_CHICKENPOX_29=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 gPBhadE85+4D for ; Sat,  9 Oct 2010 09:16:26 -0700 (PDT)
Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6]) by core3.amsl.com (Postfix) with ESMTP id 213713A68E0 for ; Sat,  9 Oct 2010 09:16:25 -0700 (PDT)
Received: from mail.acmepacket.com (216.41.24.7) by etmail.acmepacket.com (216.41.24.6) with Microsoft SMTP Server (TLS) id 8.2.254.0; Sat, 9 Oct 2010 12:17:31 -0400
Received: from mail.acmepacket.com ([127.0.0.1]) by mail ([127.0.0.1]) with mapi; Sat, 9 Oct 2010 12:17:31 -0400
From: Hadriel Kaplan 
To: IETF IPFIX Working Group 
Date: Sat, 9 Oct 2010 12:17:30 -0400
Thread-Topic: questions about structured-data draft
Thread-Index: ActnzXmPMyKMrvPkSgSuqNMJgrtYfg==
Message-ID: <646D5D04-3C32-4576-8925-550F3014B59E@acmepacket.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Subject: [IPFIX] questions about structured-data draft
X-BeenThere: ipfix@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: IPFIX WG discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sat, 09 Oct 2010 16:16:28 -0000

Hi,
I have some questions on the structured-data draft:
1) The structured-data draft defines three new abstract data types: basicLi=
st, subTemplateList, and subTemplateMultiList.  Are these allowed/expected =
to be used by a new IANA-assigned IE as its abstract data type?  Clearly th=
e draft revolves around using them for the new IEs of the same name, but I =
don't see any text that the new abstract types are unusable as types for a =
new IE.  Although one would think it would provide no advantage to do so, s=
ince the specific IE type of the list members has to be encoded inside the =
list anyway, it may improve interop to do so.  For example, specifying new =
IEs for bgpPathList, bgpSequenceList and bgpSetList, of abstract types and =
semantics basicList/ordered, basicList/ordered, and basicList/exactlyOneOf =
respectively.  That way ipfix readers can recognize it as a BGP Path/Seq/Se=
t more easily.

2) Along that same line of thought, encoding the structures as done in this=
 draft seems to lose the type information of the list itself.  It has to be=
 inferred, which is failure-prone.  For example, suppose you report a list =
of the ACL the flow matches, as well as a list of the packet's source IP he=
aders (it could be a list if it's IP-in-IP or IPsec tunnel mode).  The ACL =
may be just a basicList of sourceIPv4Address, as would the IP-in-IP list.  =
How does the ipfix collector/reader know which is which?  What if vendor X =
records the ACL first and the IP-in-IP second, while vendor Y does the oppo=
site?  Or vendor X may only report ACLs while vendor Y only reports IP-in-I=
P, but their reports look identical.  Or for another example, the draft tal=
ks about a multicast list being a list of egressInterfaces.  But how does t=
he ipfix reader know that a list of egress interfaces is a "multicast" list=
 and not a list of aggregated interfaces, or span ports?  The problem is th=
ese lists have no type.  They're just lists of types.  Anytime two lists of=
 different purposes happen to use the same member types there's a collision=
.  Or am I missing something? (could easily be)

3) If I define a Template, and I want to include multiple lists, like 3 bas=
icLists which are unrelated other than they all apply to the same flow, can=
 I do that by just specifying the basicList IE 3 times in my Template?  Or =
should I instead create a single list of lists?

4) This is just an observation, but it seems funny to me that a "basicList"=
 actually takes more bytes to encode than a subTemplateList, so that a basi=
cList of basicLists is even more expensive than a subTemplateList of subTem=
plateLists.  For example take the BGP Path example encoding AS1, AS2, AS3, =
{AS4, AS5}:=20

I would encode the following using basicList:
Template: ID=3D256
	sourceIPv4Address, destinationIPv4Address, basicList

Set: TemplateID=3D256
	Data-Record: 1.1.1.1, 2.2.2.2, {(length=3DXXX, ordered) IE=3DbasicList IEl=
ength=3D65535: {(length=3DYYY, ordered) IE=3DbgpAS IElength=3D2: AS1, AS2, =
AS3}, {(length=3DZZZ, exactlyOneOf) IE=3DbgpAS IElength=3D2: AS4, AS5}}

But the following using subTemplateList:
Template: ID=3D256
	sourceIPv4Address, destinationIPv4Address, subTemplateList

Template: ID=3D257
	subTemplateList

Template: ID=3D258
	bgpAS

Set: TemplateID=3D256
	Data-Record: 1.1.1.1, 2.2.2.2, {(length=3DXXX, ordered) TID=3D257: {(order=
ed) TID=3D258: AS1, AS2, AS3}, {(exactlyOneOf) TID=3D258: AS4, AS5}}


-hadriel


From paitken@cisco.com  Sat Oct  9 14:51:07 2010
Return-Path: 
X-Original-To: ipfix@core3.amsl.com
Delivered-To: ipfix@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BEC823A692E for ; Sat,  9 Oct 2010 14:51:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.599
X-Spam-Level: 
X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[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 92URyJ6XyBXl for ; Sat,  9 Oct 2010 14:51:06 -0700 (PDT)
Received: from rtp-iport-2.cisco.com (rtp-iport-2.cisco.com [64.102.122.149]) by core3.amsl.com (Postfix) with ESMTP id DA1833A68FB for ; Sat,  9 Oct 2010 14:51:05 -0700 (PDT)
Authentication-Results: rtp-iport-2.cisco.com; dkim=neutral (message not signed) header.i=none
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AvsEAKKAsExAZnwM/2dsb2JhbACiQ3GgEpwChUcEikCDAg
X-IronPort-AV: E=Sophos;i="4.57,309,1283731200"; d="scan'208";a="168898352"
Received: from rtp-core-1.cisco.com ([64.102.124.12]) by rtp-iport-2.cisco.com with ESMTP; 09 Oct 2010 21:52:13 +0000
Received: from cisco.com (mrwint.cisco.com [64.103.71.48]) by rtp-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id o99LqCMP003743; Sat, 9 Oct 2010 21:52:13 GMT
Received: from [10.61.83.104] (ams3-vpn-dhcp4969.cisco.com [10.61.83.104]) by cisco.com (8.11.7p3+Sun/8.8.8) with ESMTP id o99LqB809531; Sat, 9 Oct 2010 22:52:11 +0100 (BST)
Message-ID: <4CB0E3FC.7000700@cisco.com>
Date: Sat, 09 Oct 2010 22:51:56 +0100
From: Paul Aitken 
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-GB; rv:1.9.2.9) Gecko/20100915 Lightning/1.0b2 Thunderbird/3.1.4
MIME-Version: 1.0
To: Hadriel Kaplan 
References: <646D5D04-3C32-4576-8925-550F3014B59E@acmepacket.com>
In-Reply-To: <646D5D04-3C32-4576-8925-550F3014B59E@acmepacket.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Cc: IETF IPFIX Working Group 
Subject: Re: [IPFIX] questions about structured-data draft
X-BeenThere: ipfix@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: IPFIX WG discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sat, 09 Oct 2010 21:51:07 -0000

Hadriel,


> Hi,
> I have some questions on the structured-data draft:

We appreciate you reviewing the draft, thanks!


> 1) The structured-data draft defines three new abstract data types: basicList, subTemplateList, and subTemplateMultiList.  Are these allowed/expected to be used by a new IANA-assigned IE as its abstract data type?  Clearly the draft revolves around using them for the new IEs of the same name, but I don't see any text that the new abstract types are unusable as types for a new IE.  Although one would think it would provide no advantage to do so, since the specific IE type of the list members has to be encoded inside the list anyway, it may improve interop to do so.  For example, specifying new IEs for bgpPathList, bgpSequenceList and bgpSetList, of abstract types and semantics basicList/ordered, basicList/ordered, and basicList/exactlyOneOf respectively.  That way ipfix readers can recognize it as a BGP Path/Seq/Set more easily.

The new data types may be used by new IANA or Enterprise specific 
information elements as required. The new elements you propose sound 
useful and can be registered through the usual IANA process if required 
once this draft reaches RFC status.


> 2) Along that same line of thought, encoding the structures as done in this draft seems to lose the type information of the list itself.  It has to be inferred, which is failure-prone.  For example, suppose you report a list of the ACL the flow matches, as well as a list of the packet's source IP headers (it could be a list if it's IP-in-IP or IPsec tunnel mode).  The ACL may be just a basicList of sourceIPv4Address, as would the IP-in-IP list.  How does the ipfix collector/reader know which is which?  What if vendor X records the ACL first and the IP-in-IP second, while vendor Y does the opposite?  Or vendor X may only report ACLs while vendor Y only reports IP-in-IP, but their reports look identical.  Or for another example, the draft talks about a multicast list being a list of egressInterfaces.  But how does the ipfix reader know that a list of egress interfaces is a "multicast" list and not a list of aggregated interfaces, or span ports?  The problem is these lists hav
e
>   no type.  They're just lists of types.  Anytime two lists of different purposes happen to use the same member types there's a collision.  Or am I missing something? (could easily be)

New Information Elements should be defined for the ACL matches and 
source IP headers, allowing the lists to be distinguished from one 
another and from anything else. Per sections 4.3.x of the draft, the 
list elements we define in the draft are explicitly generic elements.

eg, "A basicList specifies a generic Information Element..."


> 3) If I define a Template, and I want to include multiple lists, like 3 basicLists which are unrelated other than they all apply to the same flow, can I do that by just specifying the basicList IE 3 times in my Template?  Or should I instead create a single list of lists?

We recommend creating three separate basicList elements inside the 
template, because a list of lists includes a top level semantic which 
incurs an extra overhead and implies a relationship between the lists.


> 4) This is just an observation, but it seems funny to me that a "basicList" actually takes more bytes to encode than a subTemplateList, so that a basicList of basicLists is even more expensive than a subTemplateList of subTemplateLists.  For example take the BGP Path example encoding AS1, AS2, AS3, {AS4, AS5}:

Not so, because the subTemplateList requires that a template also be 
defined so that the template ID can be specified in the list.

This exact situation is discussed in section 5.4 :

   A subTemplateList can represent the same simple list of single-value
   Information Elements as a basicList, if the Template referenced by
   the subTemplateList contains only one single-valued Information
   Element.  Although the encoding is more compact than a basicList by
   two bytes, using a subTemplateList in this case requires a new
   Template per Information Element.  The basicList requires no
   additional Template and is therefore RECOMMENDED in this case.


Thanks,
Gowri, Benoit and Paul.

From HKaplan@acmepacket.com  Sat Oct  9 20:05:35 2010
Return-Path: 
X-Original-To: ipfix@core3.amsl.com
Delivered-To: ipfix@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0CA2D3A6403 for ; Sat,  9 Oct 2010 20:05:35 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.172
X-Spam-Level: 
X-Spam-Status: No, score=-2.172 tagged_above=-999 required=5 tests=[AWL=-0.173, BAYES_00=-2.599, J_CHICKENPOX_37=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 nqKVssl9I8+L for ; Sat,  9 Oct 2010 20:05:34 -0700 (PDT)
Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6]) by core3.amsl.com (Postfix) with ESMTP id BC84B3A63D3 for ; Sat,  9 Oct 2010 20:05:33 -0700 (PDT)
Received: from mail.acmepacket.com (216.41.24.7) by etmail.acmepacket.com (216.41.24.6) with Microsoft SMTP Server (TLS) id 8.2.254.0; Sat, 9 Oct 2010 23:06:41 -0400
Received: from mail.acmepacket.com ([127.0.0.1]) by mail ([127.0.0.1]) with mapi; Sat, 9 Oct 2010 23:06:41 -0400
From: Hadriel Kaplan 
To: Paul Aitken 
Date: Sat, 9 Oct 2010 23:06:39 -0400
Thread-Topic: [IPFIX] questions about structured-data draft
Thread-Index: ActoKCka3u9qUcyASpS/QJuW4iQ6Tw==
Message-ID: <15772757-4B36-42E0-ACA6-F092B251E865@acmepacket.com>
References: <646D5D04-3C32-4576-8925-550F3014B59E@acmepacket.com> <4CB0E3FC.7000700@cisco.com>
In-Reply-To: <4CB0E3FC.7000700@cisco.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: IETF IPFIX Working Group 
Subject: Re: [IPFIX] questions about structured-data draft
X-BeenThere: ipfix@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: IPFIX WG discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sun, 10 Oct 2010 03:05:35 -0000

Hi Paul,
comments inline...
(and sorry if these questions/comments are naive - I'm relatively new to ip=
fix)

On Oct 9, 2010, at 5:51 PM, Paul Aitken wrote:

>> 1) The structured-data draft defines three new abstract data types: basi=
cList, subTemplateList, and subTemplateMultiList.  Are these allowed/expect=
ed to be used by a new IANA-assigned IE as its abstract data type?  Clearly=
 the draft revolves around using them for the new IEs of the same name, but=
 I don't see any text that the new abstract types are unusable as types for=
 a new IE.  Although one would think it would provide no advantage to do so=
, since the specific IE type of the list members has to be encoded inside t=
he list anyway, it may improve interop to do so.  For example, specifying n=
ew IEs for bgpPathList, bgpSequenceList and bgpSetList, of abstract types a=
nd semantics basicList/ordered, basicList/ordered, and basicList/exactlyOne=
Of respectively.  That way ipfix readers can recognize it as a BGP Path/Seq=
/Set more easily.
>=20
> The new data types may be used by new IANA or Enterprise specific=20
> information elements as required. The new elements you propose sound=20
> useful and can be registered through the usual IANA process if required=20
> once this draft reaches RFC status.

Ahhh.  That clears up a lot for me.  I was utterly confused how a record wi=
th arbitrary collection of data types would have any meaning to an ipfix re=
ader.  I think the draft should say something in section 4.1 along the line=
s of:
"Since this document defines the three new abstract data types below, new I=
nformation Elements can be created as these data types, just as they could =
have been for unsigned8, ipv4Address, and so on.  A Template Record contain=
ing such an IE would therefore indicate the new IE as a field in the Templa=
te and not the new IEs described in section 4.3, but its instance structure=
 within a Data Record would follow those described for the new IEs in secti=
on 5."


>=20
>> 2) Along that same line of thought, encoding the structures as done in t=
his draft seems to lose the type information of the list itself.  It has to=
 be inferred, which is failure-prone.  For example, suppose you report a li=
st of the ACL the flow matches, as well as a list of the packet's source IP=
 headers (it could be a list if it's IP-in-IP or IPsec tunnel mode).  The A=
CL may be just a basicList of sourceIPv4Address, as would the IP-in-IP list=
.  How does the ipfix collector/reader know which is which?  What if vendor=
 X records the ACL first and the IP-in-IP second, while vendor Y does the o=
pposite?  Or vendor X may only report ACLs while vendor Y only reports IP-i=
n-IP, but their reports look identical.  Or for another example, the draft =
talks about a multicast list being a list of egressInterfaces.  But how doe=
s the ipfix reader know that a list of egress interfaces is a "multicast" l=
ist and not a list of aggregated interfaces, or span ports?  The problem is=
 these lists hav
> e
>>  no type.  They're just lists of types.  Anytime two lists of different =
purposes happen to use the same member types there's a collision.  Or am I =
missing something? (could easily be)
>=20
> New Information Elements should be defined for the ACL matches and=20
> source IP headers, allowing the lists to be distinguished from one=20
> another and from anything else. Per sections 4.3.x of the draft, the=20
> list elements we define in the draft are explicitly generic elements.
>=20
> eg, "A basicList specifies a generic Information Element..."

OK, but for someone who doesn't live and breathe IPFIX but just reads the s=
pecs so he can encode some info to export (like me), the draft reads like a=
ll I have to do if I need a structure is to use one of these new IE types a=
nd any of the IANA-defined IEs, and if ipfix readers want to decode it for =
OAM reporting purposes they can.  But really they can't, if some other vend=
or does the same thing using the same IE types but for a different reason. =
 There is no XML/whatever dictionary I can give to the reader to distinguis=
h my structure's purpose from the other vendor's structure, because we both=
 happened to use the same IE types for our list members. =20

In fact, I still don't understand what purpose the new IEs serve.  I mean r=
eally these are new *data types*, just as an unsigned8 or octetArray is.  W=
hat would be the point of having an IANA defined IE named "unsigned8"?  It =
has no meaning between two different parties.  It's like a PEN, but without=
 the Enterprise number.  Or to put it in C programming terms, it's like def=
ining a new data type named "struct", instead of using a struct to define a=
 new data type.

-hadriel


From HKaplan@acmepacket.com  Sat Oct  9 20:51:52 2010
Return-Path: 
X-Original-To: ipfix@core3.amsl.com
Delivered-To: ipfix@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6982D3A6781 for ; Sat,  9 Oct 2010 20:51:52 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.471
X-Spam-Level: 
X-Spam-Status: No, score=-2.471 tagged_above=-999 required=5 tests=[AWL=0.128,  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 RPcmwSorsL0K for ; Sat,  9 Oct 2010 20:51:51 -0700 (PDT)
Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6]) by core3.amsl.com (Postfix) with ESMTP id 25F8A3A67A5 for ; Sat,  9 Oct 2010 20:51:51 -0700 (PDT)
Received: from mail.acmepacket.com (216.41.24.7) by etmail.acmepacket.com (216.41.24.6) with Microsoft SMTP Server (TLS) id 8.2.254.0; Sat, 9 Oct 2010 23:52:59 -0400
Received: from mail.acmepacket.com ([127.0.0.1]) by mail ([127.0.0.1]) with mapi; Sat, 9 Oct 2010 23:52:59 -0400
From: Hadriel Kaplan 
To: Paul Aitken 
Date: Sat, 9 Oct 2010 23:52:55 -0400
Thread-Topic: [IPFIX] questions about structured-data draft
Thread-Index: ActoLqCdiwbYYOVwRfe41FbK51iSPA==
Message-ID: <7071D8C4-FC3D-472F-A720-DBD52F17CA14@acmepacket.com>
References: <646D5D04-3C32-4576-8925-550F3014B59E@acmepacket.com> <4CB0E3FC.7000700@cisco.com>
In-Reply-To: <4CB0E3FC.7000700@cisco.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: IETF IPFIX Working Group 
Subject: Re: [IPFIX] questions about structured-data draft
X-BeenThere: ipfix@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: IPFIX WG discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sun, 10 Oct 2010 03:51:52 -0000

On Oct 9, 2010, at 5:51 PM, Paul Aitken wrote:

>=20
>> 4) This is just an observation, but it seems funny to me that a "basicLi=
st" actually takes more bytes to encode than a subTemplateList, so that a b=
asicList of basicLists is even more expensive than a subTemplateList of sub=
TemplateLists.  For example take the BGP Path example encoding AS1, AS2, AS=
3, {AS4, AS5}:
>=20
> Not so, because the subTemplateList requires that a template also be=20
> defined so that the template ID can be specified in the list.

Sure, but the Templates get sent/recorded once; and for the exporter, are p=
robably in a static form they can just send as a blob, and save the bytes f=
rom then on for that session/file.


> This exact situation is discussed in section 5.4 :
>=20
>   A subTemplateList can represent the same simple list of single-value
>   Information Elements as a basicList, if the Template referenced by
>   the subTemplateList contains only one single-valued Information
>   Element.  Although the encoding is more compact than a basicList by
>   two bytes, using a subTemplateList in this case requires a new
>   Template per Information Element.  The basicList requires no
>   additional Template and is therefore RECOMMENDED in this case.

This has probably been suggested and dismissed already, but have you though=
t of encoding a basicList as just a list of the data with the length/semant=
ic fields, and encoding the member IE type/length in the Template instead? =
 For example, reserve an IANA Enterprise Number such as 123456, and in the =
template encode the IANA-defined IE basicList using the IANA-define IE numb=
er but with that reserved PEN.  The reserved PEN 123456 means the IE is a l=
ist of that IE, following the structure of a basicList.

So for example, if you wanted to record multiple egressInterfaces (type 14)=
, the encoding would look like:
Template: ID=3D256
	sourceIPv4Address=3D8 length=3D4, destinationIPv4Address=3D12 length=3D4, =
listOf(egressInterface)=3D(pen:14/123456) length=3D65535

Set: TemplateID=3D256
	Data-Record: 1.1.1.1, 2.2.2.2, {(length=3D12, allOf) intf-1, intf-2, intf-=
3}

And if you wanted to have a basicList of subTemplateList or subTemplateMult=
iList, it would be the PEN 123456 with their respective IEs.=20

The advantages of this scheme are:
1) Follows the previous IPFIX model of encoding data types in Templates and=
 data values in records. (instead of encoding types in data records)
2) Makes it imminently clear that a basicList of IE type X is exactly the s=
ame meaning of IE type X individually.
3) Allows an ipfix reader to know the position relativity of lists for diff=
erent types from Templates in advance of Data Records (ie, that a list of e=
gressInterfaces will come before a list of foobar)
4) Saves 4 bytes per basicList.
5) Automatically allocates a basicList type for every current (and future) =
IANA-defined IE, but we can put into IANA if it makes sense for a given one=
 or not.

The one thing this does not allow is a real PEN IE to be used as a basicLis=
t member.  But doing so makes no sense anyway - a PEN's content is effectiv=
ely opaque data, so knowing something is a list of opaque data isn't useful=
.  Note this doesn't mean you can't encode a PEN IE who's content happens t=
o be a list; you just record your real PEN IE in the Template and encode it=
s data in the Data Record following the same list structure format (as you =
can already do today).  And we would still define a "basicList" abstract da=
ta type so that if the real PEN IE is described using RFC 5610 or XML or wh=
atever, it works and you can decode it all.

-hadriel



From bclaise@cisco.com  Mon Oct 11 02:19:32 2010
Return-Path: 
X-Original-To: ipfix@core3.amsl.com
Delivered-To: ipfix@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8BD6C3A690D for ; Mon, 11 Oct 2010 02:19:32 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.472
X-Spam-Level: 
X-Spam-Status: No, score=-2.472 tagged_above=-999 required=5 tests=[AWL=0.127,  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 05NPOiZun65a for ; Mon, 11 Oct 2010 02:19:31 -0700 (PDT)
Received: from av-tac-bru.cisco.com (weird-brew.cisco.com [144.254.15.118]) by core3.amsl.com (Postfix) with ESMTP id CA4B53A67EA for ; Mon, 11 Oct 2010 02:19:30 -0700 (PDT)
X-TACSUNS: Virus Scanned
Received: from strange-brew.cisco.com (localhost.cisco.com [127.0.0.1]) by av-tac-bru.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id o9B86BbP004252; Mon, 11 Oct 2010 10:06:11 +0200 (CEST)
Received: from [10.55.43.51] (ams-bclaise-8712.cisco.com [10.55.43.51]) by strange-brew.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id o9B86AdQ015591; Mon, 11 Oct 2010 10:06:11 +0200 (CEST)
Message-ID: <4CB2C572.4030602@cisco.com>
Date: Mon, 11 Oct 2010 10:06:10 +0200
From: Benoit Claise 
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-GB; rv:1.9.2.9) Gecko/20100915 Thunderbird/3.1.4
MIME-Version: 1.0
To: Hadriel Kaplan 
References: <4C4E996E.2000300@net.in.tum.de>  <4CAC26B6.9010003@cisco.com> 
In-Reply-To: 
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 8bit
Cc: IETF IPFIX Working Group 
Subject: Re: [IPFIX] Review: draft-ietf-ipfix-structured-data-02.txt
X-BeenThere: ipfix@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: IPFIX WG discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 11 Oct 2010 09:19:32 -0000

  Hadriel,

Thanks for reading the draft.
Just one quick comment inline.
> Hi Benoit,
> comments inline...
>
> On Oct 6, 2010, at 3:35 AM, Benoit Claise wrote:
>
>> Brian,
>> Thanks for your review. Reply in line.
>>> Second comment: the document is in places somewhat implementation-specific, but presents these implementation specific things as essential parts of the problem. The most glaring of these is the recommendation to use three-byte encoding for all varlen fields (Section 5.1, Page 26). It might be useful to note that certain lazy-evaluating exporters might do this, so that collectors won't assume they'll never see such inefficient things FF 00 01 as a length (i.e., a three byte encoding of "1") -- but if they're 5101-compliant, this won't cause any problems. :)
>>>
>> We think the length of structured data isn't known ahead of time.
>> It's not that exporters are lazy, but performance can also be a concern
>> if the length needs to be computed ahead of time or the content needs to
>> be copied back and forth to use 1 or 3 byte encoding based on length.
>> Hence the recommendation, its not a MUST. So, exporters can choose to do
>> otherwise.
> I think showing it with the 3-byte encoding is actually good, including and especially for a case of the length being smaller than 255 bytes.  It's a good way to remind implementors they will see this, and will likely appear in practice. (when I encode a IPFIX data, I don't want to put an if() statement in checking for greater than 255 then use 3 bytes - I'll ALWAYS use 3-byte encoding... and it's not laziness, it's less code to get wrong)
>
>
>>> I have some other "high-level" applicability concerns - it should be clear than IPFIX is still mostly useful in situations where _most_ things fit into the outer template, and SDIEs are used for additional sub-record-level structure. A guideline I'd like to see here: if you ever export a template just containing one subTemplateList, you should be exporting a Set instead. If you're ever exporting a template just containing one subTemplateMultiList, what you want is a Message. IPFIX records that are _just_ used as the root of a depth-first traversal of a semantic tree should be exported using something like XML instead.
>> We understand where you come from. However, here is a valid use case: let's say that the subTemplateList is supposed to export more than one instance (the normal case), but actually there is only one (this is an exception). In this case, we don’t want to change the exporter code just for this exception. On the top of that, it's interesting to convey that there is only one instance, which can be done with the subTemplateList encoding.
> I don't think Brian's talking about the case of an exporter only encoding one list entry for a specific Data Record - I think he means when someone creates a new Template and all it has in it is a single subTemplate*List IE, with no other IEs.  You wouldn't need to do that, because an IPFIX Set effectively is a subTemplateList (because all data records in it are the "list" entries and follow the same template), and an IPFIX Message is a subTemplateMultiList (because each Set is an entry in the "list" and identifies its Template).  Right?
>
> Having said that, subTemplate*List provide something new which Set and Message don't: the semantic indicator.
Exactly. The semantic is the reason why someone might be tempted to have 
the exact example you mentioned.

Regards, Benoit.
>
>>> Editorial: I would suggest reworking the illustrations in section 4.5. I'll talk about basicList here but this applies generally. Figures C and D are not particularly useful, they just illustrate how varlen works. In addition, by overloading the term "basicList Content", they risk being confusing. At the same time, Figures A and B make basicList look like alignment poison. However, the alignment-brokenness of varlen encoding and the alignment-brokenness of semantic tagging cancel each other out. So combining these would make things more easily understandable, and certainly prettier
>> Well, this is more of an aesthetic change. The figures today clearly illustrate encoding w/ and without enterprise number, 1 and 3 byte encoding.
>> If we try to combine figures we may be losing some info - esp, that 1 or 3 byte encoding can be used.
>> While working on the examples, we realized that the 1 or 3 bytes encoding could be a source of confusion for the readers who are not completely familiar with IPFIX.
> Ironically, when I read the draft the first time I thought exactly what Brian's saying: alignment poison.  I was shocked there was a 1-byte "semantic" field, and was thinking how crazy it was to have this field for something so esoteric, and was thinking how there needs to be a basicBasicList.  Then once I saw the examples of the messages and how it fit in the alignment, I realized the error of my ways, and am now thinking how great this semantic field is. :)
> (Well, I still think it's weird, but I'll comment on that in a separate email)
>
> -hadriel
>
>
>
>


From root@core3.amsl.com  Mon Oct 11 08:45:01 2010
Return-Path: 
X-Original-To: ipfix@ietf.org
Delivered-To: ipfix@core3.amsl.com
Received: by core3.amsl.com (Postfix, from userid 0) id E0CAE3A6A86; Mon, 11 Oct 2010 08:45: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: <20101011154501.E0CAE3A6A86@core3.amsl.com>
Date: Mon, 11 Oct 2010 08:45:01 -0700 (PDT)
Cc: ipfix@ietf.org
Subject: [IPFIX] I-D Action:draft-ietf-ipfix-structured-data-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: Mon, 11 Oct 2010 15:45:02 -0000

--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the IP Flow Information Export Working Group of the IETF.


	Title           : Export of Structured Data in IPFIX
	Author(s)       : S. Yates
	Filename        : draft-ietf-ipfix-structured-data-03.txt
	Pages           : 74
	Date            : 2010-10-11

This document specifies an extension to the IP Flow Information 

  eXport (IPFIX) protocol specification in [RFC5101] and the IPFIX 

  information model specified in [RFC5102] to support hierarchical 

  structured data and lists (sequences) of Information Elements in 

  data records.  This extension allows definition of complex data 

  structures such as variable-length lists and specification of 

  hierarchical containment relationships between Templates. 

  Finally, the semantics are provided in order to express the 

  relationship among multiple list elements in a structured data 

  record.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-ipfix-structured-data-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.

--NextPart
Content-Type: Message/External-body;
	name="draft-ietf-ipfix-structured-data-03.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID: <2010-10-11083725.I-D@ietf.org>


--NextPart--

From bclaise@cisco.com  Mon Oct 11 08:59:39 2010
Return-Path: 
X-Original-To: ipfix@core3.amsl.com
Delivered-To: ipfix@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EC59D3A6A86; Mon, 11 Oct 2010 08:59:39 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.473
X-Spam-Level: 
X-Spam-Status: No, score=-2.473 tagged_above=-999 required=5 tests=[AWL=0.125,  BAYES_00=-2.599, HTML_MESSAGE=0.001]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CSDRS4onoqez; Mon, 11 Oct 2010 08:59:39 -0700 (PDT)
Received: from av-tac-bru.cisco.com (weird-brew.cisco.com [144.254.15.118]) by core3.amsl.com (Postfix) with ESMTP id 9ADCA3A6A75; Mon, 11 Oct 2010 08:59:38 -0700 (PDT)
X-TACSUNS: Virus Scanned
Received: from strange-brew.cisco.com (localhost.cisco.com [127.0.0.1]) by av-tac-bru.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id o9BFv5kQ011043; Mon, 11 Oct 2010 17:57:05 +0200 (CEST)
Received: from [10.55.43.51] (ams-bclaise-8712.cisco.com [10.55.43.51]) by strange-brew.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id o9BFv4iK012063; Mon, 11 Oct 2010 17:57:05 +0200 (CEST)
Message-ID: <4CB333D0.3050008@cisco.com>
Date: Mon, 11 Oct 2010 17:57:04 +0200
From: Benoit Claise 
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-GB; rv:1.9.2.9) Gecko/20100915 Thunderbird/3.1.4
MIME-Version: 1.0
To: Internet-Drafts@ietf.org
References: <20101011154501.E0CAE3A6A86@core3.amsl.com>
In-Reply-To: <20101011154501.E0CAE3A6A86@core3.amsl.com>
Content-Type: multipart/alternative; boundary="------------010102030806030101020209"
Cc: ipfix@ietf.org, i-d-announce@ietf.org
Subject: Re: [IPFIX] I-D Action:draft-ietf-ipfix-structured-data-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: Mon, 11 Oct 2010 15:59:40 -0000

This is a multi-part message in MIME format.
--------------010102030806030101020209
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

  Dear all,

With this draft, we have addressed all the WGLC comments, received from 
Brian Trammell, Christoph Sommer, Rahul Patel, Gerhard Muenz, & Carsten 
Schmoll,

Regards, Benoit.
> 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           : Export of Structured Data in IPFIX
> 	Author(s)       : S. Yates
> 	Filename        : draft-ietf-ipfix-structured-data-03.txt
> 	Pages           : 74
> 	Date            : 2010-10-11
>
> This document specifies an extension to the IP Flow Information
>
>    eXport (IPFIX) protocol specification in [RFC5101] and the IPFIX
>
>    information model specified in [RFC5102] to support hierarchical
>
>    structured data and lists (sequences) of Information Elements in
>
>    data records.  This extension allows definition of complex data
>
>    structures such as variable-length lists and specification of
>
>    hierarchical containment relationships between Templates.
>
>    Finally, the semantics are provided in order to express the
>
>    relationship among multiple list elements in a structured data
>
>    record.
>
> A URL for this Internet-Draft is:
> http://www.ietf.org/internet-drafts/draft-ietf-ipfix-structured-data-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.
>
>
> _______________________________________________
> IPFIX mailing list
> IPFIX@ietf.org
> https://www.ietf.org/mailman/listinfo/ipfix


--------------010102030806030101020209
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit



  
    
    
  
  
    Dear all,

    

    With this draft, we have addressed all the WGLC comments, received
    from Brian Trammell, Christoph Sommer, Rahul Patel, Gerhard Muenz,
    & Carsten Schmoll, 

    

    Regards, Benoit.

    

      
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           : Export of Structured Data in IPFIX
	Author(s)       : S. Yates
	Filename        : draft-ietf-ipfix-structured-data-03.txt
	Pages           : 74
	Date            : 2010-10-11

This document specifies an extension to the IP Flow Information 

  eXport (IPFIX) protocol specification in [RFC5101] and the IPFIX 

  information model specified in [RFC5102] to support hierarchical 

  structured data and lists (sequences) of Information Elements in 

  data records.  This extension allows definition of complex data 

  structures such as variable-length lists and specification of 

  hierarchical containment relationships between Templates. 

  Finally, the semantics are provided in order to express the 

  relationship among multiple list elements in a structured data 

  record.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-ipfix-structured-data-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.


      

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


    

    

  


--------------010102030806030101020209--

From bclaise@cisco.com  Mon Oct 11 09:05:47 2010
Return-Path: 
X-Original-To: ipfix@core3.amsl.com
Delivered-To: ipfix@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CD9633A6B1A for ; Mon, 11 Oct 2010 09:05:47 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.475
X-Spam-Level: 
X-Spam-Status: No, score=-2.475 tagged_above=-999 required=5 tests=[AWL=0.123,  BAYES_00=-2.599, HTML_MESSAGE=0.001]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rRzqHYlFnxuE for ; Mon, 11 Oct 2010 09:05:46 -0700 (PDT)
Received: from av-tac-bru.cisco.com (weird-brew.cisco.com [144.254.15.118]) by core3.amsl.com (Postfix) with ESMTP id 662E93A6A00 for ; Mon, 11 Oct 2010 09:05:46 -0700 (PDT)
X-TACSUNS: Virus Scanned
Received: from strange-brew.cisco.com (localhost.cisco.com [127.0.0.1]) by av-tac-bru.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id o9BG6vNf013618 for ; Mon, 11 Oct 2010 18:06:57 +0200 (CEST)
Received: from [10.55.43.51] (ams-bclaise-8712.cisco.com [10.55.43.51]) by strange-brew.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id o9BG6uAA025247 for ; Mon, 11 Oct 2010 18:06:56 +0200 (CEST)
Message-ID: <4CB3361F.6030308@cisco.com>
Date: Mon, 11 Oct 2010 18:06:55 +0200
From: Benoit Claise 
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-GB; rv:1.9.2.9) Gecko/20100915 Thunderbird/3.1.4
MIME-Version: 1.0
To: "ipfix@ietf.org" 
Content-Type: multipart/alternative; boundary="------------030009060400050204090601"
Subject: [IPFIX]  I-D Action:draft-ietf-ipfix-structured-data-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: Mon, 11 Oct 2010 16:05:47 -0000

This is a multi-part message in MIME format.
--------------030009060400050204090601
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

  Dear all,

With this draft, we have addressed all the (WGLC) comments, received 
from Brian Trammell, Christoph Sommer, Rahul Patel, Gerhard Muenz, & 
Carsten Schmoll,

Regards, Benoit.
> 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           : Export of Structured Data in IPFIX
> 	Author(s)       : S. Yates
> 	Filename        : draft-ietf-ipfix-structured-data-03.txt
> 	Pages           : 74
> 	Date            : 2010-10-11
>
> This document specifies an extension to the IP Flow Information
>
>    eXport (IPFIX) protocol specification in [RFC5101] and the IPFIX
>
>    information model specified in [RFC5102] to support hierarchical
>
>    structured data and lists (sequences) of Information Elements in
>
>    data records.  This extension allows definition of complex data
>
>    structures such as variable-length lists and specification of
>
>    hierarchical containment relationships between Templates.
>
>    Finally, the semantics are provided in order to express the
>
>    relationship among multiple list elements in a structured data
>
>    record.
>
> A URL for this Internet-Draft is:
> http://www.ietf.org/internet-drafts/draft-ietf-ipfix-structured-data-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.
>
>
> _______________________________________________
> IPFIX mailing list
> IPFIX@ietf.org
> https://www.ietf.org/mailman/listinfo/ipfix


--------------030009060400050204090601
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit



  
    
    
  
  
    Dear all,

    

    With this draft, we have addressed all the (WGLC) comments, received
    from Brian Trammell, Christoph Sommer, Rahul Patel, Gerhard Muenz,
    & Carsten Schmoll, 

    

    Regards, Benoit.

    

      
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           : Export of Structured Data in IPFIX
	Author(s)       : S. Yates
	Filename        : draft-ietf-ipfix-structured-data-03.txt
	Pages           : 74
	Date            : 2010-10-11

This document specifies an extension to the IP Flow Information 

  eXport (IPFIX) protocol specification in [RFC5101] and the IPFIX 

  information model specified in [RFC5102] to support hierarchical 

  structured data and lists (sequences) of Information Elements in 

  data records.  This extension allows definition of complex data 

  structures such as variable-length lists and specification of 

  hierarchical containment relationships between Templates. 

  Finally, the semantics are provided in order to express the 

  relationship among multiple list elements in a structured data 

  record.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-ipfix-structured-data-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.


      

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


    

    

  


--------------030009060400050204090601--

From gowri@cisco.com  Mon Oct 11 09:13:34 2010
Return-Path: 
X-Original-To: ipfix@core3.amsl.com
Delivered-To: ipfix@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 478593A6B1C for ; Mon, 11 Oct 2010 09:13:34 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.598
X-Spam-Level: 
X-Spam-Status: No, score=-10.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RYN0MWTp3v8z for ; Mon, 11 Oct 2010 09:13:19 -0700 (PDT)
Received: from sj-iport-4.cisco.com (sj-iport-4.cisco.com [171.68.10.86]) by core3.amsl.com (Postfix) with ESMTP id 52A3C3A6A3B for ; Mon, 11 Oct 2010 09:13:19 -0700 (PDT)
Authentication-Results: sj-iport-4.cisco.com; dkim=neutral (message not signed) header.i=none
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AjsFAKbUskyrR7Hu/2dsb2JhbACBRaBJcaVmnECFSASEUoh4
X-IronPort-AV: E=Sophos;i="4.57,314,1283731200";  d="scan'208,217";a="198884055"
Received: from sj-core-5.cisco.com ([171.71.177.238]) by sj-iport-4.cisco.com with ESMTP; 11 Oct 2010 16:14:30 +0000
Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-5.cisco.com (8.13.8/8.14.3) with ESMTP id o9BGEUgE007050; Mon, 11 Oct 2010 16:14:30 GMT
Received: from xmb-sjc-232.amer.cisco.com ([128.107.191.41]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675);  Mon, 11 Oct 2010 09:14:30 -0700
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CB695F.624BA2E0"
Date: Mon, 11 Oct 2010 09:14:29 -0700
Message-ID: 
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: IPFIX Structured Data - comments related to semantic
Thread-Index: ActfsqoBqqNi6tA7Q1iAzh+Y1JD1DgE4DWLQAD48ifAA9IMYkA==
From: "Gowri Dhandapani (gowri)" 
To: 
X-OriginalArrivalTime: 11 Oct 2010 16:14:30.0599 (UTC) FILETIME=[62869D70:01CB695F]
Subject: [IPFIX] IPFIX Structured Data - comments related to semantic
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, 11 Oct 2010 16:13:34 -0000

This is a multi-part message in MIME format.

------_=_NextPart_001_01CB695F.624BA2E0
Content-Type: text/plain;
	charset="US-ASCII"
Content-Transfer-Encoding: quoted-printable

Hi all,

Please find the mail below summarizing issues related to the
Semanticfield and our responses, also, included answers for Gerhard's
and Brian's comments regarding semantic.=20

=20

During the last IETF meeting, there was a concern regarding semantic of
subTemplateMultiList as described in the draft. To provide some context,
a subTemplateMultiList contains Data Records corresponding to multiple
Template Records. The semantic in the subTemplateMultiList provides the
top-level relationship among the series of Data Records corresponding to
different Template Records. For example, if a subTemplateMultiList has a
semantic 'exactlyOneOf' and the elements are (A1, A2), (B1, B2, B3),
(C1) - this means the Data Record contains exactly one of the lists (A1,
A2) or (B1, B2, B3) or (C1).=20

=20

The concern was that the semantic should mean all Data Records
regardless of the Template. Benoit, Paul, Gerhard and Brian had a follow
up discussion and reached a closure on this, the consensus at the end of
that meeting is:

*        Keep the semantic of subTemplateMultiList as defined, however
explain the semantic at the beginning of the draft. So, we added this in
Section 2.4: "The three Structured Data Information Elements carry some
semantic information so that the Collecting Process can understand the
relationship between the different list elements. The semantic in the
Structured Data Information Elements is provided in order to express the
relationship among the multiple top-level list elements. As an example,
if a list is composed of elements (A,B,C), the semantic expresses the
relationship among A, B and C, regardless of whether A, B and C are
individual elements or list of elements."  To clarify, in a
subTemplateMultiList the elements could represent lists in turn A->(A1,
A2), B->(B1, B2, B3) etc. So, if a subTemplateMultiList has a semantic
'exactlyOneOf' and the elements are (A1, A2), (B1, B2, B3), (C1) - this
means the Data Record contains exactly one of the lists (A1, A2) or (B1,
B2, B3) or (C1).   The keyword "top-level" indicates that the semantic
represents the relationship among elements (A, B, C) and not at the next
level if these elements expand to lists inturn.=20

*        If we want the semantic of all Data Records in a
subTemplateMultiList, then according to Brian's suggestion we have added
the following text in Section 5.4: "Alternatively, if a semantic is
required to describe the relationship among all Data Records within a
subTemplateMultiList (regardless of the Template Record), an encoding
based on a subTemplateMultiList with one Data Record corresponding to a
single Template ID can be used."=20

=20

Also, please find responses to specific comments regarding semantic
below:

=20

There is one suggestion about the specification itself. I think that it
would be easier to understand if the meaning of the semantic of
subTemplateList and subTemplateMultiList would be the same, namely that
it specifies the semantic among the Data Records. At the moment, the
draft specifies (although not very clearly) that the semantic refers to
goups of Data Records associated to different Templates in the case of
the subTemplateMultiList. I do not see a use-case for this. Also, no
useful example is provided. On the contrary, it is always said that the
semantic of subTemplateMultiList is not sufficient.    =20
=20
Please refer to explanation above.=20

	      =20
	     4.5.3. subTemplateMultiList=20
	=20
	      Whereas each top-level element in a subTemplateList
Information=20

=20
what is meant by "top-level"? It means that there are levels below.
Remove?

=20

Yes, in a subTemplateMultiList there are two levels - the list contains
(A, B, C) where A could in turn be a list (A1, A2, A3). The semantic
provides the relationship among A, B, C and not at the next level. So,
the keyword "top-level" is required to highlight the distinction. =20

	=20

		      Element corresponds with a single Template ID and
therefore has=20

	=20
	"corresponds to"
	=20

		      the same data type, sometimes it is useful for a
list to contain=20

	=20
	Why "same data type"? Each element is a Data Record associated
to the
	same (Options) Template.
	Reference to "data type" removed. The section 4.5.3 now reads:
"Whereas each element in a subTemplateList Information Element
corresponds to a single Template, it is sometimes useful for a list to
contain elements corresponding to different Templates. "

	     =20
	       0                   1                   2
3=20
	       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8
9 0 1=20
=09
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=20
	      |    Semantic   |         Template ID X         |Data
Records...|=20
=09
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=20
	      | ... Length X  |        Data Record X.1 Content ...
|=20
=09
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=20
	      |                              ...
|=20
=09
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=20
	      |      ...      |        Data Record X.2 Content ...
|=20
=09
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=20
	      |                              ...
|=20
=09
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=20
	      |      ...      |        Data Record X.L Content ...
|=20
=09
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=20
	      |                              ...
| =20
=09
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=20
	      |      ...      |         Template ID Y         |Data
Records...| =20
=09
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=20
	      | ... Length Y  |        Data Record  Y.1 Content ...
|=20
=09
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=20
	      |                              ...
|=20
=09
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=20
	      |      ...      |        Data Record Y.2 Content ...
|=20
=09
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=20
	      |                              ...
|=20
=09
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=20
	      |      ...      |        Data Record Y.M Content ...
|=20
=09
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=20
	      |                              ...
|=20
=09
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=20
	      |      ...      |         Template ID Z         |Data
Records...|=20
=09
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=20
	      | ... Length Z  |        Data Record Z.1 Content ...
|=20
=09
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=20
	      |                              ...
|=20
=09
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=20
	      |      ...      |        Data Record Z.2 Content ...
|=20
=09
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=20
	      |                              ...
|=20
=09
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=20
	      |      ...      |        Data Record Z.N Content ...
|=20
=09
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=20
	      |                              ...
| =20
=09
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=20
	      |      ...      |   =20
	      +-+-+-+-+-+-+-+-+  =20
	      =20
	                   Figure H: subTemplateMultiList Encoding=20
	                                       =20
	      Semantic=20
	      =20
	          The Semantic indicates the top level semantic among
Template=20

=20
Remove "The" or "Semantic field"?

done.

=20
remove "top level"
As explained above, "top-level" is required to mark the distinction.=20
=20
"among the Data Records"?
Yes, should be Data Records corresponding to different Templates -
corrected.=20
=20
Comment added later: Now as I have read section 5.4, I understand that
you want to restrict to the semantic among sequences of Data Records
belonging to different Templates. This does not become clear. Wouldn't
it be simpler to say that Semantic defines the semantic among all Data
Records, regardless of the Template?
Refer to explanation at the beginning of the mail.=20

	=20

		          Records, i.e. the relationship among the
series of Data=20
		          Records from the different Template Records
within this=20

	=20
	"from" =3D> "associated with"

Changed.=20

	         =20
	          Note: if a semantic is required to describe the
relationship=20
	          among the different Data Records corresponding to a
single=20
	          Template ID within the subTemplateMultiList, then an
encoding=20
	          based on a basicList of subTemplateLists should be
used. Refer=20

=20
I would remove "basicList" because it does not support Templates. So, it
is not a general alternative.
"A basicList can contain individual IEs or any of the three Structured
Data IEs as list elements (note that the subTemplateList or
subTemplateMultiList contains multiple Data Records corresponding to one
or more Templates respectively). =20
As an example, consider a basicList of subTemplateLists:
     basicList (semantic) {=20
                               (subTemplateList1 w/ semantic-1),=20
                               (subTemplateList2 w/ semantic-2)}.=20
The top-level semantic would provide the relationship among the various
subTemplateLists while each subtemplateList can carry its own semantic
to describe the relationship among its list elements. Hope this is
clear.

	=20
	=20
	     5.4. Usage Guidelines for Equivalent Data Representations=20
	=20
	      Because basicList, subTemplateList, and
subTemplateMultiList are=20
	      all lists, in several cases there is more than one way to=20
	      represent what is effectively the same data structure.
However,=20
	      in some cases, one approach has an advantage over the
other e.g.=20
	      more compact, uses fewer resources, etc., and is therefore

	      preferred over an alternate representation.=20
	=20
	      A subTemplateList can represent the same simple list of
single-
	      value Information Elements as a basicList, if the Template

	      referenced by the subTemplateList contains only one
single-valued=20
	      Information Element.  Although the encoding is more
compact than a=20
	      basicList by two bytes, using a subTemplateList in this
case=20
	      requires a new Template per Information Element.  The
basicList=20
	      requires no additional Template and is therefore
RECOMMENDED in=20
	      this case. =20
	=20
	      Although a subTemplateMultiList with one Element can
represent the=20
	      contents of a subTemplateList, the subTemplateMultiList
carries=20
	      two additional bytes (Element Length).  It is also
potentially=20
	      useful to a Collecting Process to know in advance that a=20
	      subTemplateList directly indicates that list element types
are=20
	      consistent.  The subTemplateList Information Element is
therefore=20
	      RECOMMENDED in this case.=20
	=20
	      The Semantic in a subTemplateMultiList indicates the top
level=20

=20
Semantic field

Done.=20

=20

	      semantic among Template Records, i.e. the relationship
among the=20

=20
Template Records =3D> Data Records ?
=20
See comment above in section 4.5.3.
Yes, corrected to Data Records.=20
=20

	      series of Data Records from the different Template
Records, within=20
	      this Structured Data.  If a semantic is required to
describe the=20
	      relationship among the different Data Records
corresponding to a=20
	      single Template ID within the subTemplateMultiList, then
an=20
	      encoding based on a basicList of subTemplateLists should
be used.=20
	=20
	      Note that the referenced Information Element(s) in the
Structured=20
	      Data Information Elements can be taken from the IPFIX
information=20
	      model [RFC5102], the PSAMP information model [RFC5477], or
any of=20
	      the Information Elements defined in the IANA IPFIX
registry [IANA-
	      IPFIX].=20

	    =20
	=20
	Brian's comments regarding semantic:=20

	Agreed with Gerhard on this point, and this would be the most
important comment in my own review. Semantics, as I understand them,
bind to the set of _values_ within a list structure. The value in a
subTemplateMultiList are the records (each of which, indeed, may be
associated with a different Template). Binding semantics to templates
breaks this clean design. Section 5.6 almost seems like a paean to why
SubTemplateMultiList sucks, which if you're applying semantics at the
template level, not the record level, it seems to.

	=20

	I see the primary use of subTemplateMultiList as semantically
identical to subTemplateList, allowing the usage of different templates
representing semantically similar but situationally different data
(e.g., mixing v4 and v6 flows) within the same List. Here, Templates are
(as in IPFIX itself) an encoding mechanism, not a semantic one.

	=20

	Given this confusion, I've not reviewed the rest of the
subTemplateMultiList-relevant content. I would strongly suggest a
statement up front of the universality of semantics - applying to list
values in all cases - and a statement up front that subTemplateMultiList
is a convenience for allowing different encoding of semantically similar
information.

	=20
	Please refer to meeting consensus at the beginning of the mail.=20
	=20
	Thanks.=20
	      =20
	     =20


------_=_NextPart_001_01CB695F.624BA2E0
Content-Type: text/html;
	charset="US-ASCII"
Content-Transfer-Encoding: quoted-printable
















Hi =
all,



Please find the mail =
below
summarizing issues related to the Semanticfield and our responses, also,
included answers for Gerhard’s and Brian’s comments =
regarding semantic. 



 



During the last IETF =
meeting,
there was a concern regarding semantic of subTemplateMultiList as =
described in
the draft. To provide some context, a subTemplateMultiList contains Data
Records corresponding to multiple Template Records. The semantic in the
subTemplateMultiList provides the top-level relationship among the =
series of
Data Records corresponding to different Template Records. For example, =
if a
subTemplateMultiList has a semantic ‘exactlyOneOf’ and the =
elements are (A1, A2),
(B1, B2, B3), (C1) – this means the Data Record contains exactly =
one of the
lists (A1, A2) or (B1, B2, B3) or (C1). 



 



The concern was that =
the
semantic should mean all Data Records regardless of the Template. =
Benoit, Paul,
Gerhard and Brian had a follow up discussion and reached a closure on =
this, the
consensus at the end of that meeting is:



·       
Keep the =
semantic of
subTemplateMultiList as defined, however explain the semantic at the =
beginning
of the draft. So, we added this in Section 2.4: “The three =
Structured Data Information
Elements carry some semantic information so that the Collecting Process =
can
understand the relationship between the different list elements. The =
semantic
in the Structured Data Information Elements is provided in order to =
express the
relationship among the multiple top-level list elements. As an example, =
if a
list is composed of elements (A,B,C), the semantic expresses the =
relationship
among A, B and C, regardless of whether A, B and C are individual =
elements or
list of elements.”  To clarify, in a subTemplateMultiList the =
elements
could represent lists in turn A->(A1, A2), B->(B1, B2, B3) etc. =
So, if a
subTemplateMultiList has a semantic ‘exactlyOneOf’ and the =
elements are (A1,
A2), (B1, B2, B3), (C1) – this means the Data Record contains =
exactly one of
the lists (A1, A2) or (B1, B2, B3) or (C1).   The keyword =
“top-level”
indicates that the semantic represents the relationship among elements =
(A, B,
C) and not at the next level if these elements expand to lists inturn. =




·       
If we want =
the
semantic of all Data Records in a subTemplateMultiList, then according =
to
Brian’s suggestion we have added the following text in Section =
5.4:
“Alternatively, if a semantic is required to describe the =
relationship among
all Data Records within a subTemplateMultiList (regardless of the =
Template
Record), an encoding based on a subTemplateMultiList with one Data =
Record
corresponding to a single Template ID can be used.” =




 



Also, please find =
responses to
specific comments regarding semantic below:



 



There is one suggestion about the specification itself. I think =
that it
would be easier to understand if the =
meaning of the semantic of
subTemplateList and =
subTemplateMultiList would be the same, namely =
that
it specifies the semantic among the Data =
Records. At the moment, the
draft specifies =
(although not very clearly) that the semantic refers =
to
goups of Data Records associated to different =
Templates in the case of
the subTemplateMultiList. =
I do not see a use-case for this. Also, no
useful =
example is provided. On the contrary, it is always said that =
the
semantic of subTemplateMultiList is not =
sufficient.     
 
Please refer to explanation above. =




   &nb=
sp;   =

     4.5.3. =
subTemplateMultiList =

 
    =
;  Whereas each top-level element in a subTemplateList Information =




 
what is meant by "top-level"? =
It means that there are levels below. Remove?



 



Yes, in a subTemplateMultiList there are two levels =
– the list contains (A, B, C) where A could in turn be a list (A1, =
A2, A3). The semantic provides the relationship among A, B, C and not at =
the next level. So, the keyword “top-level” is required to =
highlight the distinction.  



 


   &nb=
sp;  Element corresponds with a single Template ID and therefore =
has 



 
"corresponds =
to"
 



   &nb=
sp;  the same data type, sometimes it is useful for a list to =
contain 



 
Why "same data type"? Each =
element is a Data Record associated to the
same =
(Options) Template.
Reference to =
“data type” removed. The section 4.5.3 now reads: =
“Whereas each element in a subTemplateList Information Element =
corresponds to a single Template, it is sometimes useful for a list to =
contain elements corresponding to different Templates. =
“



   =
   
     &nb=
sp; 0          &nb=
sp;        =
1            =
       =
2            =
       3 =

       0 1 2 3 =
4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 =

      +-+-+-+-+-+-+-+=
-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ =

      |  &n=
bsp; Semantic   =
|         Template ID =
X         |Data Records...| =

      +-+-+-+-+-+-+-+=
-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ =

      | ... Length =
X  |        Data Record X.1 =
Content =
...            | =

      +-+-+-+-+-+-+-+=
-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ =

      |  &n=
bsp;           &nb=
sp;           &nbs=
p;   =
...           &nbs=
p;            =
;      | =

      +-+-+-+-+-+-+-+=
-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ =

      |  &n=
bsp;   ...      =
|        Data Record X.2 Content =
...            | =

      +-+-+-+-+-+-+-+=
-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ =

      |  &n=
bsp;           &nb=
sp;           &nbs=
p;   =
...           &nbs=
p;            =
;      | =

      +-+-+-+-+-+-+-+=
-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ =

      |  &n=
bsp;   ...      =
|        Data Record X.L Content =
...            | =

      +-+-+-+-+-+-+-+=
-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ =

      |  &n=
bsp;           &nb=
sp;           &nbs=
p;   =
...           &nbs=
p;            =
;      |  =

      +-+-+-+-+-+-+-+=
-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ =

      |  &n=
bsp;   ...      =
|         Template ID =
Y         |Data =
Records...|  =

      +-+-+-+-+-+-+-+=
-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ =

      | ... Length =
Y  |        Data Record  =
Y.1 Content =
...           | =

      +-+-+-+-+-+-+-+=
-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ =

      |  &n=
bsp;           &nb=
sp;           &nbs=
p;   =
...           &nbs=
p;            =
;      | =

      +-+-+-+-+-+-+-+=
-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ =

      |  &n=
bsp;   ...      =
|        Data Record Y.2 Content =
...            | =

      +-+-+-+-+-+-+-+=
-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ =

      |  &n=
bsp;           &nb=
sp;           &nbs=
p;   =
...           &nbs=
p;            =
;      | =

      +-+-+-+-+-+-+-+=
-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ =

      |  &n=
bsp;   ...      =
|        Data Record Y.M Content =
...            | =

      +-+-+-+-+-+-+-+=
-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ =

      |  &n=
bsp;           &nb=
sp;           &nbs=
p;   =
...           &nbs=
p;            =
;      | =

      +-+-+-+-+-+-+-+=
-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ =

      |  &n=
bsp;   ...      =
|         Template ID =
Z         |Data Records...| =

      +-+-+-+-+-+-+-+=
-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ =

      | ... Length =
Z  |        Data Record Z.1 =
Content =
...            | =

      +-+-+-+-+-+-+-+=
-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ =

      |  &n=
bsp;           &nb=
sp;           &nbs=
p;   =
...           &nbs=
p;            =
;      | =

      +-+-+-+-+-+-+-+=
-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ =

      |  &n=
bsp;   ...      =
|        Data Record Z.2 Content =
...            | =

      +-+-+-+-+-+-+-+=
-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ =

      |  &n=
bsp;           &nb=
sp;           &nbs=
p;   =
...           &nbs=
p;            =
;      | =

      +-+-+-+-+-+-+-+=
-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ =

      |  &n=
bsp;   ...      =
|        Data Record Z.N Content =
...            | =

      +-+-+-+-+-+-+-+=
-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ =

      |  &n=
bsp;           &nb=
sp;           &nbs=
p;   =
...           &nbs=
p;            =
;      |  =

      +-+-+-+-+-+-+-+=
-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ =

      | =
     ...      =
|    =

      +-+-+-+-+-+-+-+=
-+   =

       
          =
         Figure H: =
subTemplateMultiList Encoding =

        &nb=
sp;           &nbs=
p;            =
;       
 &n=
bsp;    Semantic =

       
          =
The Semantic indicates the top level semantic among Template =




 
Remove "The" or =
"Semantic field"?



done.



 
remove "top =
level"
As explained above, =
“top-level” is required to mark the distinction. =

 
"among the =
Data Records"?
Yes, should be Data Records corresponding =
to different Templates – corrected. =

 
Comment added =
later: Now as I have read section 5.4, I understand =
that
you want to restrict to the semantic among =
sequences of Data Records
belonging to different =
Templates. This does not become clear. Wouldn't
it =
be simpler to say that Semantic defines the semantic among all =
Data
Records, regardless of the =
Template?
Refer to explanation at the beginning of =
the mail. 



 


   &nb=
sp;      Records, i.e. the relationship among =
the series of Data =

        &nb=
sp; Records from the different Template Records within this =




 
"from" =3D> =
"associated with"



Changed. 



   &nb=
sp;      =

        &nb=
sp; Note: if a semantic is required to describe the relationship =

        &nb=
sp; among the different Data Records corresponding to a single =

        &nb=
sp; Template ID within the subTemplateMultiList, then an encoding =

        &nb=
sp; based on a basicList of subTemplateLists should be used. Refer =




 
I would remove "basicList" =
because it does not support Templates. So, it
is =
not a general alternative.
“A basicList =
can contain individual IEs or any of the three Structured Data IEs as =
list elements (note that the subTemplateList or subTemplateMultiList =
contains multiple Data Records corresponding to one or more Templates =
respectively).  
As an example, consider a basicList of =
subTemplateLists:
     basicList =
(semantic) { 
       &=
nbsp;           &n=
bsp;           =
(subTemplateList1 w/ semantic-1), 
       &=
nbsp;           &n=
bsp;           =
(subTemplateList2 w/ semantic-2)}. 
The top-level semantic would provide the =
relationship among the various subTemplateLists while each =
subtemplateList can carry its own semantic to describe the relationship =
among its list elements. Hope this is clear.



 
 
 &n=
bsp;   5.4. Usage Guidelines for Equivalent Data =
Representations =

 
    =
;  Because basicList, subTemplateList, and subTemplateMultiList are =

      all lists, in =
several cases there is more than one way to =

      represent what =
is effectively the same data structure.  However, =

      in some cases, =
one approach has an advantage over the other e.g. =

      more compact, =
uses fewer resources, etc., and is therefore =

      preferred over =
an alternate representation. =

 
    =
;  A subTemplateList can represent the same simple list of =
single-
      value =
Information Elements as a basicList, if the Template =

      referenced by =
the subTemplateList contains only one single-valued =

      Information =
Element.  Although the encoding is more compact than a =

      basicList by =
two bytes, using a subTemplateList in this case =

      requires a new =
Template per Information Element.  The basicList =

      requires no =
additional Template and is therefore RECOMMENDED in =

      this =
case.  =

 
    =
;  Although a subTemplateMultiList with one Element can represent =
the 
      contents =
of a subTemplateList, the subTemplateMultiList carries =

      two additional =
bytes (Element Length).  It is also potentially =

      useful to a =
Collecting Process to know in advance that a =

      subTemplateList=
 directly indicates that list element types are =

      consistent.&nbs=
p; The subTemplateList Information Element is therefore =

      RECOMMENDED in =
this case. =

 
    =
;  The Semantic in a subTemplateMultiList indicates the top level =




 
Semantic field



Done.




 



   &nb=
sp;  semantic among Template Records, i.e. the relationship among =
the 



 
Template Records =3D> Data Records =
?
 
See comment above in =
section 4.5.3.
Yes, corrected to Data Records. =

 



   &nb=
sp;  series of Data Records from the different Template Records, =
within 
      this =
Structured Data.  If a semantic is required to describe the =

      relationship =
among the different Data Records corresponding to a =

      single =
Template ID within the subTemplateMultiList, then an =

      encoding based =
on a basicList of subTemplateLists should be used. =

 
    =
;  Note that the referenced Information Element(s) in the =
Structured =

      Data =
Information Elements can be taken from the IPFIX information =

      model =
[RFC5102], the PSAMP information model [RFC5477], or any of =

      the =
Information Elements defined in the IANA IPFIX registry =
[IANA-
      IPFIX]. 



   &nb=
sp; 
 
Brian’s comments regarding semantic: =




Agreed with Gerhard on this point, and this =
would be the
most important comment in my own review. Semantics, as I understand =
them, bind
to the set of _values_ within a list structure. The value in a
subTemplateMultiList are the records (each of which, indeed, may be =
associated
with a different Template). Binding semantics to templates breaks this =
clean
design. Section 5.6 almost seems like a paean to why =
SubTemplateMultiList
sucks, which if you're applying semantics at the template level, not the =
record
level, it seems to.



 



I see the primary use of subTemplateMultiList as
semantically identical to subTemplateList, allowing the usage of =
different
templates representing semantically similar but situationally different =
data
(e.g., mixing v4 and v6 flows) within the same List. Here, Templates are =
(as in
IPFIX itself) an encoding mechanism, not a semantic one.



 



Given this confusion, I've not reviewed the rest =
of the
subTemplateMultiList-relevant content. I would strongly suggest a =
statement up
front of the universality of semantics - applying to list values in all =
cases -
and a statement up front that subTemplateMultiList is a convenience for
allowing different encoding of semantically similar =
information.



 
Please refer to =
meeting consensus at the beginning of the mail. =

 
Thanks. =

       
      









------_=_NextPart_001_01CB695F.624BA2E0--

From bclaise@cisco.com  Mon Oct 11 09:24:02 2010
Return-Path: 
X-Original-To: ipfix@core3.amsl.com
Delivered-To: ipfix@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 40D0A3A6A3B for ; Mon, 11 Oct 2010 09:24:02 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.177
X-Spam-Level: 
X-Spam-Status: No, score=-2.177 tagged_above=-999 required=5 tests=[AWL=-0.178, BAYES_00=-2.599, J_CHICKENPOX_37=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 t3GjMyd3RxUl for ; Mon, 11 Oct 2010 09:24:01 -0700 (PDT)
Received: from av-tac-bru.cisco.com (weird-brew.cisco.com [144.254.15.118]) by core3.amsl.com (Postfix) with ESMTP id A59AB3A69CE for ; Mon, 11 Oct 2010 09:24:00 -0700 (PDT)
X-TACSUNS: Virus Scanned
Received: from strange-brew.cisco.com (localhost.cisco.com [127.0.0.1]) by av-tac-bru.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id o9BGHfTf016343; Mon, 11 Oct 2010 18:17:41 +0200 (CEST)
Received: from [10.55.43.51] (ams-bclaise-8712.cisco.com [10.55.43.51]) by strange-brew.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id o9BGHafj007636; Mon, 11 Oct 2010 18:17:37 +0200 (CEST)
Message-ID: <4CB338A0.40205@cisco.com>
Date: Mon, 11 Oct 2010 18:17:36 +0200
From: Benoit Claise 
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-GB; rv:1.9.2.9) Gecko/20100915 Thunderbird/3.1.4
MIME-Version: 1.0
To: Hadriel Kaplan 
References: <646D5D04-3C32-4576-8925-550F3014B59E@acmepacket.com>	<4CB0E3FC.7000700@cisco.com> <15772757-4B36-42E0-ACA6-F092B251E865@acmepacket.com>
In-Reply-To: <15772757-4B36-42E0-ACA6-F092B251E865@acmepacket.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: quoted-printable
Cc: IETF IPFIX Working Group 
Subject: Re: [IPFIX] questions about structured-data draft
X-BeenThere: ipfix@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: IPFIX WG discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 11 Oct 2010 16:24:02 -0000

  Hadriel,
> Hi Paul,
> comments inline...
> (and sorry if these questions/comments are naive - I'm relatively new t=
o ipfix)
Don't worry, we welcome new readers.
> On Oct 9, 2010, at 5:51 PM, Paul Aitken wrote:
>
>>> 1) The structured-data draft defines three new abstract data types: b=
asicList, subTemplateList, and subTemplateMultiList.  Are these allowed/e=
xpected to be used by a new IANA-assigned IE as its abstract data type?  =
Clearly the draft revolves around using them for the new IEs of the same =
name, but I don't see any text that the new abstract types are unusable a=
s types for a new IE.  Although one would think it would provide no advan=
tage to do so, since the specific IE type of the list members has to be e=
ncoded inside the list anyway, it may improve interop to do so.  For exam=
ple, specifying new IEs for bgpPathList, bgpSequenceList and bgpSetList, =
of abstract types and semantics basicList/ordered, basicList/ordered, and=
 basicList/exactlyOneOf respectively.  That way ipfix readers can recogni=
ze it as a BGP Path/Seq/Set more easily.
>> The new data types may be used by new IANA or Enterprise specific
>> information elements as required. The new elements you propose sound
>> useful and can be registered through the usual IANA process if require=
d
>> once this draft reaches RFC status.
> Ahhh.  That clears up a lot for me.  I was utterly confused how a recor=
d with arbitrary collection of data types would have any meaning to an ip=
fix reader.  I think the draft should say something in section 4.1 along =
the lines of:
> "Since this document defines the three new abstract data types below, n=
ew Information Elements can be created as these data types, just as they =
could have been for unsigned8, ipv4Address, and so on.  A Template Record=
 containing such an IE would therefore indicate the new IE as a field in =
the Template and not the new IEs described in section 4.3, but its instan=
ce structure within a Data Record would follow those described for the ne=
w IEs in section 5."
We have to pay attention to one thing. Your basicList examples (such as=20
bgpPathList) make perfect sense and could be easily specified in IPFIX IA=
NA.
However, we will have to decide how far we want to go in defining new=20
IEs based on subTemplateList and subTemplateMultiList...
>
>>> 2) Along that same line of thought, encoding the structures as done i=
n this draft seems to lose the type information of the list itself.  It h=
as to be inferred, which is failure-prone.  For example, suppose you repo=
rt a list of the ACL the flow matches, as well as a list of the packet's =
source IP headers (it could be a list if it's IP-in-IP or IPsec tunnel mo=
de).  The ACL may be just a basicList of sourceIPv4Address, as would the =
IP-in-IP list.  How does the ipfix collector/reader know which is which? =
 What if vendor X records the ACL first and the IP-in-IP second, while ve=
ndor Y does the opposite?  Or vendor X may only report ACLs while vendor =
Y only reports IP-in-IP, but their reports look identical.  Or for anothe=
r example, the draft talks about a multicast list being a list of egressI=
nterfaces.  But how does the ipfix reader know that a list of egress inte=
rfaces is a "multicast" list and not a list of aggregated interfaces, or =
span ports?  The problem is these lists ha
>   v
>> e
>>>   no type.  They're just lists of types.  Anytime two lists of differ=
ent purposes happen to use the same member types there's a collision.  Or=
 am I missing something? (could easily be)
>> New Information Elements should be defined for the ACL matches and
>> source IP headers, allowing the lists to be distinguished from one
>> another and from anything else. Per sections 4.3.x of the draft, the
>> list elements we define in the draft are explicitly generic elements.
>>
>> eg, "A basicList specifies a generic Information Element..."
> OK, but for someone who doesn't live and breathe IPFIX but just reads t=
he specs so he can encode some info to export (like me), the draft reads =
like all I have to do if I need a structure is to use one of these new IE=
 types and any of the IANA-defined IEs, and if ipfix readers want to deco=
de it for OAM reporting purposes they can.  But really they can't, if som=
e other vendor does the same thing using the same IE types but for a diff=
erent reason.  There is no XML/whatever dictionary I can give to the read=
er to distinguish my structure's purpose from the other vendor's structur=
e, because we both happened to use the same IE types for our list members=
=2E
> In fact, I still don't understand what purpose the new IEs serve.  I me=
an really these are new *data types*, just as an unsigned8 or octetArray =
is.  What would be the point of having an IANA defined IE named "unsigned=
8"?  It has no meaning between two different parties.  It's like a PEN, b=
ut without the Enterprise number.  Or to put it in C programming terms, i=
t's like defining a new data type named "struct", instead of using a stru=
ct to define a new data type.
You're right.
The goal of this draft is not defined an information model on the top of =

IEs. For example, we will not tell you that a list of IP address pairs=20
represent:
- 4 IP address of GRE tunnel
- versus IP accounting data
- versus an ACL

The goal of this draft, as you pointed out is to have new data types.

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



From gowri@cisco.com  Mon Oct 11 10:15:36 2010
Return-Path: 
X-Original-To: ipfix@core3.amsl.com
Delivered-To: ipfix@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9FF6E3A6B46 for ; Mon, 11 Oct 2010 10:15:35 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.598
X-Spam-Level: 
X-Spam-Status: No, score=-10.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9WPO1wTTea11 for ; Mon, 11 Oct 2010 10:15:18 -0700 (PDT)
Received: from sj-iport-4.cisco.com (sj-iport-4.cisco.com [171.68.10.86]) by core3.amsl.com (Postfix) with ESMTP id 4496E3A6B47 for ; Mon, 11 Oct 2010 10:15:18 -0700 (PDT)
Authentication-Results: sj-iport-4.cisco.com; dkim=neutral (message not signed) header.i=none
X-IronPort-AV: E=Sophos;i="4.57,315,1283731200";  d="scan'208,217";a="198930958"
Received: from sj-core-5.cisco.com ([171.71.177.238]) by sj-iport-4.cisco.com with ESMTP; 11 Oct 2010 17:16:22 +0000
Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-5.cisco.com (8.13.8/8.14.3) with ESMTP id o9BHGKHm003379; Mon, 11 Oct 2010 17:16:22 GMT
Received: from xmb-sjc-232.amer.cisco.com ([128.107.191.41]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675);  Mon, 11 Oct 2010 10:16:15 -0700
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CB6968.02ACD6F0"
Date: Mon, 11 Oct 2010 10:16:14 -0700
Message-ID: 
In-Reply-To: <7071D8C4-FC3D-472F-A720-DBD52F17CA14@acmepacket.com>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [IPFIX] questions about structured-data draft
Thread-Index: ActoLqCdiwbYYOVwRfe41FbK51iSPABMRF7g
References: <646D5D04-3C32-4576-8925-550F3014B59E@acmepacket.com><4CB0E3FC.7000700@cisco.com> <7071D8C4-FC3D-472F-A720-DBD52F17CA14@acmepacket.com>
From: "Gowri Dhandapani (gowri)" 
To: "Hadriel Kaplan" , "Paul Aitken (paitken)" 
X-OriginalArrivalTime: 11 Oct 2010 17:16:15.0743 (UTC) FILETIME=[02F6B8F0:01CB6968]
Cc: IETF IPFIX Working Group 
Subject: Re: [IPFIX] questions about structured-data draft
X-BeenThere: ipfix@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: IPFIX WG discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 11 Oct 2010 17:15:36 -0000

This is a multi-part message in MIME format.

------_=_NextPart_001_01CB6968.02ACD6F0
Content-Type: text/plain;
	charset="US-ASCII"
Content-Transfer-Encoding: quoted-printable

Hi Hadriel,
Thanks for your review, please see responses inline marked by ###.

-----Original Message-----
From: ipfix-bounces@ietf.org [mailto:ipfix-bounces@ietf.org] On Behalf
Of Hadriel Kaplan
Sent: Saturday, October 09, 2010 11:53 PM
To: Paul Aitken (paitken)
Cc: IETF IPFIX Working Group
Subject: Re: [IPFIX] questions about structured-data draft


On Oct 9, 2010, at 5:51 PM, Paul Aitken wrote:

>=20
>> 4) This is just an observation, but it seems funny to me that a
"basicList" actually takes more bytes to encode than a subTemplateList,
so that a basicList of basicLists is even more expensive than a
subTemplateList of subTemplateLists.  For example take the BGP Path
example encoding AS1, AS2, AS3, {AS4, AS5}:
>=20
> Not so, because the subTemplateList requires that a template also be=20
> defined so that the template ID can be specified in the list.

Sure, but the Templates get sent/recorded once; and for the exporter,
are probably in a static form they can just send as a blob, and save the
bytes from then on for that session/file.

### Yes, the Templates are sent only once, the concern isn't the
bandwidth. The overhead is defining and maintaining the template when
there is no need for one.=20

> This exact situation is discussed in section 5.4 :
>=20
>   A subTemplateList can represent the same simple list of single-value
>   Information Elements as a basicList, if the Template referenced by
>   the subTemplateList contains only one single-valued Information
>   Element.  Although the encoding is more compact than a basicList by
>   two bytes, using a subTemplateList in this case requires a new
>   Template per Information Element.  The basicList requires no
>   additional Template and is therefore RECOMMENDED in this case.

This has probably been suggested and dismissed already, but have you
thought of encoding a basicList as just a list of the data with the
length/semantic fields, and encoding the member IE type/length in the
Template instead?  For example, reserve an IANA Enterprise Number such
as 123456, and in the template encode the IANA-defined IE basicList
using the IANA-define IE number but with that reserved PEN.  The
reserved PEN 123456 means the IE is a list of that IE, following the
structure of a basicList.

So for example, if you wanted to record multiple egressInterfaces (type
14), the encoding would look like:
Template: ID=3D256
	sourceIPv4Address=3D8 length=3D4, destinationIPv4Address=3D12
length=3D4, listOf(egressInterface)=3D(pen:14/123456) length=3D65535

Set: TemplateID=3D256
	Data-Record: 1.1.1.1, 2.2.2.2, {(length=3D12, allOf) intf-1,
intf-2, intf-3}

And if you wanted to have a basicList of subTemplateList or
subTemplateMultiList, it would be the PEN 123456 with their respective
IEs.=20

### If I recall correctly, I believe we may have considered this in the
past, but was dropped due to consistency sake - all of the three
structured data IEs would look similar to any individual IEs in the
Template (anything specific to the list would be included in the Data
Record), this is also important for backward compatibility for
collectors who don't understand structured data.=20

Thanks.

The advantages of this scheme are:
1) Follows the previous IPFIX model of encoding data types in Templates
and data values in records. (instead of encoding types in data records)
2) Makes it imminently clear that a basicList of IE type X is exactly
the same meaning of IE type X individually.
3) Allows an ipfix reader to know the position relativity of lists for
different types from Templates in advance of Data Records (ie, that a
list of egressInterfaces will come before a list of foobar)
4) Saves 4 bytes per basicList.
5) Automatically allocates a basicList type for every current (and
future) IANA-defined IE, but we can put into IANA if it makes sense for
a given one or not.

The one thing this does not allow is a real PEN IE to be used as a
basicList member.  But doing so makes no sense anyway - a PEN's content
is effectively opaque data, so knowing something is a list of opaque
data isn't useful.  Note this doesn't mean you can't encode a PEN IE
who's content happens to be a list; you just record your real PEN IE in
the Template and encode its data in the Data Record following the same
list structure format (as you can already do today).  And we would still
define a "basicList" abstract data type so that if the real PEN IE is
described using RFC 5610 or XML or whatever, it works and you can decode
it all.

-hadriel


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

------_=_NextPart_001_01CB6968.02ACD6F0
Content-Type: text/html;
	charset="US-ASCII"
Content-Transfer-Encoding: quoted-printable






RE: [IPFIX] questions about structured-data draft





Hi =
Hadriel,



Thanks for =
your review, =
please see responses inline marked by ###.






-----Original Message-----

From: ipfix-bounces@ietf.org [mailto:ipfix-bounces@ietf.org]=
 On Behalf Of Hadriel Kaplan

Sent: Saturday, October 09, 2010 11:53 PM

To: Paul Aitken (paitken)

Cc: IETF IPFIX Working Group

Subject: Re: [IPFIX] questions about structured-data draft






On Oct 9, 2010, at 5:51 PM, Paul =
Aitken wrote:



> 



>> 4) This is just an =
observation, but it seems funny to me that a "basicList" =
actually takes more bytes to encode than a subTemplateList, so that a =
basicList of basicLists is even more expensive than a subTemplateList of =
subTemplateLists.  For example take the BGP Path example encoding =
AS1, AS2, AS3, {AS4, AS5}:



> 



> Not so, because the =
subTemplateList requires that a template also be 



> defined so that the template ID =
can be specified in the list.



Sure, but the Templates get =
sent/recorded once; and for the exporter, are probably in a static form =
they can just send as a blob, and save the bytes from then on for that =
session/file.






### Yes, the =
Templates are sent only once, the concern isn’t the =
bandwidth. =
The overhead =
is defining =
and maintaining the template when there is no need for one. 






> This exact situation is discussed =
in section 5.4 :



> 



>   A subTemplateList can =
represent the same simple list of single-value



>   Information Elements =
as a basicList, if the Template referenced by



>   the subTemplateList =
contains only one single-valued Information



>   Element.  =
Although the encoding is more compact than a basicList by



>   two bytes, using a =
subTemplateList in this case requires a new



>   Template per =
Information Element.  The basicList requires no



>   additional Template =
and is therefore RECOMMENDED in this case.



This has probably been suggested and =
dismissed already, but have you thought of encoding a basicList as just =
a list of the data with the length/semantic fields, and encoding the =
member IE type/length in the Template instead?  For example, =
reserve an IANA Enterprise Number such as 123456, and in the template =
encode the IANA-defined IE basicList using the IANA-define IE number but =
with that reserved PEN.  The reserved PEN 123456 means the IE is a =
list of that IE, following the structure of a basicList.



So for example, if you wanted to =
record multiple egressInterfaces (type 14), the encoding would look =
like:



Template: ID=3D256



        =
sourceIPv4Address=3D8 length=3D4, destinationIPv4Address=3D12 =
length=3D4, listOf(egressInterface)=3D(pen:14/123456) =
length=3D65535



Set: TemplateID=3D256



        Data-Record: =
1.1.1.1, 2.2.2.2, {(length=3D12, allOf) intf-1, intf-2, =
intf-3}



And if you wanted to have a basicList =
of subTemplateList or subTemplateMultiList, it would be the PEN 123456 =
with their respective IEs. 






### If I =
recall =
correctly, I believe we may have considered this in the past, but was =
dropped due to consistency sake – all of the three structured data IEs would look similar to =
any individual IEs in the Template (anything specific to the list =
would be included in the Data Record), this is also important for =
backward compatibility for collectors who don’t understand structured =
data. 






Thanks.






The advantages of this scheme =
are:



1) Follows the previous IPFIX model of =
encoding data types in Templates and data values in records. (instead of =
encoding types in data records)



2) Makes it imminently clear that a =
basicList of IE type X is exactly the same meaning of IE type X =
individually.



3) Allows an ipfix reader to know the =
position relativity of lists for different types from Templates in =
advance of Data Records (ie, that a list of egressInterfaces will come =
before a list of foobar)



4) Saves 4 bytes per =
basicList.



5) Automatically allocates a basicList =
type for every current (and future) IANA-defined IE, but we can put into =
IANA if it makes sense for a given one or not.



The one thing this does not allow is a =
real PEN IE to be used as a basicList member.  But doing so makes =
no sense anyway - a PEN's content is effectively opaque data, so knowing =
something is a list of opaque data isn't useful.  Note this doesn't =
mean you can't encode a PEN IE who's content happens to be a list; you =
just record your real PEN IE in the Template and encode its data in the =
Data Record following the same list structure format (as you can already =
do today).  And we would still define a "basicList" =
abstract data type so that if the real PEN IE is described using RFC =
5610 or XML or whatever, it works and you can decode it all.



-hadriel





_______________________________________________
=



IPFIX mailing list



IPFIX@ietf.org



https://www.ietf.org=
/mailman/listinfo/ipfix




------_=_NextPart_001_01CB6968.02ACD6F0--

From HKaplan@acmepacket.com  Mon Oct 11 11:09:58 2010
Return-Path: 
X-Original-To: ipfix@core3.amsl.com
Delivered-To: ipfix@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5C3F83A6B51 for ; Mon, 11 Oct 2010 11:09:58 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.973
X-Spam-Level: 
X-Spam-Status: No, score=-1.973 tagged_above=-999 required=5 tests=[AWL=-0.374, BAYES_00=-2.599, J_BACKHAIR_36=1]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Eh3kN25ZPawb for ; Mon, 11 Oct 2010 11:09:54 -0700 (PDT)
Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6]) by core3.amsl.com (Postfix) with ESMTP id 226B73A6B45 for ; Mon, 11 Oct 2010 11:09:53 -0700 (PDT)
Received: from mail.acmepacket.com (216.41.24.7) by etmail.acmepacket.com (216.41.24.6) with Microsoft SMTP Server (TLS) id 8.2.254.0; Mon, 11 Oct 2010 14:11:05 -0400
Received: from mail.acmepacket.com ([127.0.0.1]) by mail ([127.0.0.1]) with mapi; Mon, 11 Oct 2010 14:11:04 -0400
From: Hadriel Kaplan 
To: Benoit Claise 
Date: Mon, 11 Oct 2010 14:11:03 -0400
Thread-Topic: [IPFIX] questions about structured-data draft
Thread-Index: Actpb6sHqrun2lICRI+Mx0AGSr8qcA==
Message-ID: <0F683FA7-D364-4BAD-AB08-8D0212353E5D@acmepacket.com>
References: <646D5D04-3C32-4576-8925-550F3014B59E@acmepacket.com> <4CB0E3FC.7000700@cisco.com> <15772757-4B36-42E0-ACA6-F092B251E865@acmepacket.com> <4CB338A0.40205@cisco.com>
In-Reply-To: <4CB338A0.40205@cisco.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: IETF IPFIX Working Group 
Subject: Re: [IPFIX] questions about structured-data draft
X-BeenThere: ipfix@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: IPFIX WG discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 11 Oct 2010 18:09:58 -0000

On Oct 11, 2010, at 12:17 PM, Benoit Claise wrote:

> We have to pay attention to one thing. Your basicList examples (such as=20
> bgpPathList) make perfect sense and could be easily specified in IPFIX IA=
NA.
> However, we will have to decide how far we want to go in defining new=20
> IEs based on subTemplateList and subTemplateMultiList...

Yeah I can't grok how that would work.=20

So maybe I should describe the problem I'm trying to solve and see if struc=
tured-data is the solution or not.  (sorry about the email length)

We have this SIP-CLF proposal, where we export/record info about the SIP Me=
ssage. (as you well know :)
All the current mandatory fields we wish to export are either already exist=
ing IEs, such as sourceIPv4Address, or proposed new ones specific to SIP li=
ke sipToURI.  None of them can appear more than once in a SIP Message, so w=
e don't have to deal with lists.

We want to make it extensible, by letting vendors export additional info in=
 the record.  We could do that with vendor-specific PENs (and undoubtedly p=
eople will), but I was going to submit a draft for registering IEs for thin=
gs we expect to be somewhat popular to add, or at least that someone might =
want to add and having a defined IE for already would be useful.  For examp=
le, stuff from a SIP Contact, P-Asserted-Identity, or P-Preferred-Identity =
headers. =20

Some SIP header types can appear multiple times, some cannot.  So having a =
basicList for the ones that can solves that. =20

The tricky thing about SIP headers, though, is that their contents are not =
just a single "value".  They are really composed of distinct fields.  There=
's a list of zero or more header parameters, a header value, and within tha=
t header value there could be a URI, display-name, or some other combinatio=
n of discrete fields.  For reporting purposes, one generally wants to segre=
gate out such fields if possible, so that the collector/reader does not nee=
d to understand SIP ABNF rules and do that work itself.  But for some heade=
rs recording the whole field makes sense.

So as I was writing up the stuff people may want to record, it became obvio=
us that creating a unique IE for each and every field, of each and every SI=
P header, is untenable.  It would mean, for example, that you'd have a sipC=
ontactURI, sipContactDisplayName, sipContactParamName, sipContactParamValue=
, as well as a sipPAssertedIdURI, sipPAssertedIdDisplayName, sipPAssertedId=
ParamName, sipPAssertedIdParamValue, as well as sipPPreferredIdURI, sipPPre=
ferredIdDisplayName, sipPPreferredIdParamName, and sipPPreferredIdParamValu=
e.  And that's only the tip of iceberg.  There are currently *106* SIP head=
ers registered in IANA, and a half-dozen more in drafts at various stages. =
 Not all of them follow the pattern of having a URI and optional display na=
me (most don't, but many do); but even if you created a "Header=
Value" and "ParamName" and "ParamValue" IE type for=
 each, that's a lot. (and you'd exhaust your IE number space if you did thi=
s for other protocols like H.323 and HTTP and RTSP)

What you'd really want is to create a few new abstract data types of "sipGe=
nericHeader", "sipUriHeader" and "sipParam" in IANA, which would be a compo=
site of the pieces, and then define a sipHeader IE for each of the 10=
6 header types, based on their specific abstract data type.  For example a =
sipPAssertedIdHeader IE, which is of abstract type sipUriHeader, with a URI=
, display-name, and a basicList of sipParam (and sipParam would be a name/v=
alue pair). =20

Essentially, what this calls for is the ability to take *generic* data type=
s, such as URI or paramValue (both of which are based on string), and build=
 upon them to form more complex (and unique) data types to eventually yield=
 a sipContactHeader IE.  It's not clear to me if the structured-data draft =
is actually meant to accomplish that, or if it's just meant to take *specif=
ic* data type IEs and let them appear multiple times in a structure, but wi=
thout changing their meaning.=20

In other words, you can't record an ACL list as just a basicList of sourceI=
Pv4Address, because "sourceIPv4Address" has the meaning of being the source=
 IPv4 address of the flow's actual *packet*, not an access control it may o=
r may not match to.  You'd have to create an IE for aclSourceIPv4Address an=
d put it in a basicList.

-hadriel



From HKaplan@acmepacket.com  Mon Oct 11 11:15:17 2010
Return-Path: 
X-Original-To: ipfix@core3.amsl.com
Delivered-To: ipfix@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1DE1D3A6B52 for ; Mon, 11 Oct 2010 11:15:17 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.469
X-Spam-Level: 
X-Spam-Status: No, score=-2.469 tagged_above=-999 required=5 tests=[AWL=0.129,  BAYES_00=-2.599, HTML_MESSAGE=0.001]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FHidOvd7Ln0Z for ; Mon, 11 Oct 2010 11:15:15 -0700 (PDT)
Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6]) by core3.amsl.com (Postfix) with ESMTP id BB2053A6B53 for ; Mon, 11 Oct 2010 11:15:14 -0700 (PDT)
Received: from mail.acmepacket.com (216.41.24.7) by etmail.acmepacket.com (216.41.24.6) with Microsoft SMTP Server (TLS) id 8.2.254.0; Mon, 11 Oct 2010 14:16:26 -0400
Received: from mail.acmepacket.com ([127.0.0.1]) by mail ([127.0.0.1]) with mapi; Mon, 11 Oct 2010 14:16:26 -0400
From: Hadriel Kaplan 
To: "Gowri Dhandapani (gowri)" 
Date: Mon, 11 Oct 2010 14:16:25 -0400
Thread-Topic: [IPFIX] questions about structured-data draft
Thread-Index: ActpcGsKUpic2c4FSgCWy4xDj1Gc4A==
Message-ID: <3531A421-6111-4769-A8B5-23AE3921AFF3@acmepacket.com>
References: <646D5D04-3C32-4576-8925-550F3014B59E@acmepacket.com><4CB0E3FC.7000700@cisco.com> <7071D8C4-FC3D-472F-A720-DBD52F17CA14@acmepacket.com> 
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
Content-Type: multipart/alternative; boundary="_000_3531A42161114769A8B523AE3921AFF3acmepacketcom_"
MIME-Version: 1.0
Cc: IETF IPFIX Working Group 
Subject: Re: [IPFIX] questions about structured-data draft
X-BeenThere: ipfix@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: IPFIX WG discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 11 Oct 2010 18:15:17 -0000

--_000_3531A42161114769A8B523AE3921AFF3acmepacketcom_
Content-Type: text/plain; charset="Windows-1252"
Content-Transfer-Encoding: quoted-printable


Hi Gowri,
it would be backwards-compatible, because as far as a legacy reader knows t=
he Template just told it there was going to be a PEN IE in that position, a=
s either a variable length or a fixed length (note that the length in the T=
emplate would apply to the whole basicList, not the length of the specific =
IE in the list).

But anyway yeah the idea suffers from being different from the other list t=
ype syntaxes, and can't have a basicList of basicList, which is bad.  So ca=
ncel that idea. :)

-hadriel


On Oct 11, 2010, at 1:16 PM, Gowri Dhandapani (gowri) wrote:


Hi Hadriel,

Thanks for your review, please see responses inline marked by ###.


-----Original Message-----
From: ipfix-bounces@ietf.org [mailto:ipfix-b=
ounces@ietf.org] On Behalf Of Hadriel Kaplan
Sent: Saturday, October 09, 2010 11:53 PM
To: Paul Aitken (paitken)
Cc: IETF IPFIX Working Group
Subject: Re: [IPFIX] questions about structured-data draft


On Oct 9, 2010, at 5:51 PM, Paul Aitken wrote:

>

>> 4) This is just an observation, but it seems funny to me that a "basicLi=
st" actually takes more bytes to encode than a subTemplateList, so that a b=
asicList of basicLists is even more expensive than a subTemplateList of sub=
TemplateLists.  For example take the BGP Path example encoding AS1, AS2, AS=
3, {AS4, AS5}:

>

> Not so, because the subTemplateList requires that a template also be

> defined so that the template ID can be specified in the list.

Sure, but the Templates get sent/recorded once; and for the exporter, are p=
robably in a static form they can just send as a blob, and save the bytes f=
rom then on for that session/file.


### Yes, the Templates are sent only once, the concern isn=92t the bandwidt=
h. The overhead is defining and maintaining the template when there is no n=
eed for one.


> This exact situation is discussed in section 5.4 :

>

>   A subTemplateList can represent the same simple list of single-value

>   Information Elements as a basicList, if the Template referenced by

>   the subTemplateList contains only one single-valued Information

>   Element.  Although the encoding is more compact than a basicList by

>   two bytes, using a subTemplateList in this case requires a new

>   Template per Information Element.  The basicList requires no

>   additional Template and is therefore RECOMMENDED in this case.

This has probably been suggested and dismissed already, but have you though=
t of encoding a basicList as just a list of the data with the length/semant=
ic fields, and encoding the member IE type/length in the Template instead? =
 For example, reserve an IANA Enterprise Number such as 123456, and in the =
template encode the IANA-defined IE basicList using the IANA-define IE numb=
er but with that reserved PEN.  The reserved PEN 123456 means the IE is a l=
ist of that IE, following the structure of a basicList.

So for example, if you wanted to record multiple egressInterfaces (type 14)=
, the encoding would look like:

Template: ID=3D256

        sourceIPv4Address=3D8 length=3D4, destinationIPv4Address=3D12 lengt=
h=3D4, listOf(egressInterface)=3D(pen:14/123456) length=3D65535

Set: TemplateID=3D256

        Data-Record: 1.1.1.1, 2.2.2.2, {(length=3D12, allOf) intf-1, intf-2=
, intf-3}

And if you wanted to have a basicList of subTemplateList or subTemplateMult=
iList, it would be the PEN 123456 with their respective IEs.


### If I recall correctly, I believe we may have considered this in the pas=
t, but was dropped due to consistency sake =96 all of the three structured =
data IEs would look similar to any individual IEs in the Template (anything=
 specific to the list would be included in the Data Record), this is also i=
mportant for backward compatibility for collectors who don=92t understand s=
tructured data.


Thanks.


The advantages of this scheme are:

1) Follows the previous IPFIX model of encoding data types in Templates and=
 data values in records. (instead of encoding types in data records)

2) Makes it imminently clear that a basicList of IE type X is exactly the s=
ame meaning of IE type X individually.

3) Allows an ipfix reader to know the position relativity of lists for diff=
erent types from Templates in advance of Data Records (ie, that a list of e=
gressInterfaces will come before a list of foobar)

4) Saves 4 bytes per basicList.

5) Automatically allocates a basicList type for every current (and future) =
IANA-defined IE, but we can put into IANA if it makes sense for a given one=
 or not.

The one thing this does not allow is a real PEN IE to be used as a basicLis=
t member.  But doing so makes no sense anyway - a PEN's content is effectiv=
ely opaque data, so knowing something is a list of opaque data isn't useful=
.  Note this doesn't mean you can't encode a PEN IE who's content happens t=
o be a list; you just record your real PEN IE in the Template and encode it=
s data in the Data Record following the same list structure format (as you =
can already do today).  And we would still define a "basicList" abstract da=
ta type so that if the real PEN IE is described using RFC 5610 or XML or wh=
atever, it works and you can decode it all.

-hadriel


_______________________________________________

IPFIX mailing list

IPFIX@ietf.org

https://www.ietf.org/mailman/listinfo/ipfix


--_000_3531A42161114769A8B523AE3921AFF3acmepacketcom_
Content-Type: text/html; charset="Windows-1252"
Content-Transfer-Encoding: quoted-printable



Hi Gow=
ri,
it would be backwards-compatible, because as far as a legacy =
reader knows the Template just told it there was going to be a PEN IE in th=
at position, as either a variable length or a fixed length (note that the l=
ength in the Template would apply to the whole basicList, not the length of=
 the specific IE in the list).

But anyway yeah the=
 idea suffers from being different from the other list type syntaxes, and c=
an't have a basicList of basicList, which is bad.  So cancel that idea=
. :)

-hadriel


On=
 Oct 11, 2010, at 1:16 PM, Gowri Dhandapani (gowri) wrote:



=
Hi Hadriel,
Thanks for your review<=
span lang=3D"en-us">, please see responses inline marked by ###.

-----Original Message-----

From: ipfix-bounces@ietf.org =
[mailto:ipfix-bounces@ietf.org] On Behalf Of Hadriel Kaplan

Sent: Saturday, October 09, 2010 11:53 PM

To: Paul Aitken (paitken)

Cc: IETF IPFIX Working Group

Subject: Re: [IPFIX] questions about structured-data draft
On Oct 9, 2010, at 5:51 PM, Paul Aitken wr=
ote:
> 
>> 4) This is just an observation, but =
it seems funny to me that a "basicList" actually takes more bytes to encode=
 than a subTemplateList, so that a basicList of basicLists is even more exp=
ensive than a subTemplateList of subTemplateLists.  For example take t=
he BGP Path example encoding AS1, AS2, AS3, {AS4, AS5}:
> 
> Not so, because the subTemplateList requires that a template also =
be 
> defined so that the =
template ID can be specified in the list.
Sure, but the Templates get sent/recorded once; and for the ex=
porter, are probably in a static form they can just send as a blob, and sav=
e the bytes from then on for that session/file.

### Yes, the Templates are =
sent only once, the concern isn=92t the bandwidth. The overhead =
is defining and =
maintaining the template when there is no need for one. 
> This exact situation is discussed in=
 section 5.4 :
> 
>   A subTemplateList ca=
n represent the same simple list of single-value
<=
span lang=3D"en-us">>   Information Elements as a basicList, i=
f the Template referenced by
=
>   the subTemplateList contains only one single-valued Inform=
ation
>   Elemen=
t.  Although the encoding is more compact than a basicList by
>   two bytes, using a s=
ubTemplateList in this case requires a new
>   Template per Information Element.  The =
basicList requires no
>&nb=
sp;  additional Template and is therefore RECOMMENDED in this case.
This has probably been suggeste=
d and dismissed already, but have you thought of encoding a basicList as ju=
st a list of the data with the length/semantic fields, and encoding the mem=
ber IE type/length in the Template instead?  For example, reserve an I=
ANA Enterprise Number such as 123456, and in the template encode the IANA-d=
efined IE basicList using the IANA-define IE number but with that reserved =
PEN.  The reserved PEN 123456 means the IE is a list of that IE, follo=
wing the structure of a basicList.
So for example, if you wanted to record multiple egressInterfaces (ty=
pe 14), the encoding would look like:
Template: ID=3D256
        sourceIPv4Address=3D8 length=3D=
4, destinationIPv4Address=3D12 length=3D4, listOf(egressInterface)=3D(pen:1=
4/123456) length=3D65535
Set:=
 TemplateID=3D256
  =
;      Data-Record: 1.1.1.1, 2.2.2.2, {(length=3D1=
2, allOf) intf-1, intf-2, intf-3}
And if you wanted to have a basicList of subTemplateList or subTemplat=
eMultiList, it would be the PEN 123456 with their respective IEs. 

<=
/div>
### If I r=
ecall correctly,=
 I believe we may have considered this in the past, but was dropped due to =
consistency sake =96 all of the =
three structured data IEs would look similar to any individual IEs in the Template (anything specific to th=
e list would be included in the Data Record), this is also important for backward compatibility for collec=
tors who don=92<=
/font>t understand stru=
ctured data. 

Thanks.

The advantages of this scheme are:
1) Follows the previous IPFIX mo=
del of encoding data types in Templates and data values in records. (instea=
d of encoding types in data records)
2) Makes it imminently clear that a basicList of IE type X is exact=
ly the same meaning of IE type X individually.
3) Allows an ipfix reader to know the position relativity=
 of lists for different types from Templates in advance of Data Records (ie=
, that a list of egressInterfaces will come before a list of foobar)=

4) Saves 4 bytes per basicList.
5) Automatically allocates a bas=
icList type for every current (and future) IANA-defined IE, but we can put =
into IANA if it makes sense for a given one or not.
The one thing this does not allow is a real PEN IE t=
o be used as a basicList member.  But doing so makes no sense anyway -=
 a PEN's content is effectively opaque data, so knowing something is a list=
 of opaque data isn't useful.  Note this doesn't mean you can't encode=
 a PEN IE who's content happens to be a list; you just record your real PEN=
 IE in the Template and encode its data in the Data Record following the sa=
me list structure format (as you can already do today).  And we would =
still define a "basicList" abstract data type so that if the real PEN IE is=
 described using RFC 5610 or XML or whatever, it works and you can decode i=
t all.
-hadriel


___________________________________=
____________
IPFIX mailing li=
st
IPFIX@ietf.org
https://www.ietf.org/=
mailman/listinfo/ipfix






=

--_000_3531A42161114769A8B523AE3921AFF3acmepacketcom_--

From HKaplan@acmepacket.com  Mon Oct 11 11:46:01 2010
Return-Path: 
X-Original-To: ipfix@core3.amsl.com
Delivered-To: ipfix@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 30CB53A6B5B for ; Mon, 11 Oct 2010 11:46:01 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.471
X-Spam-Level: 
X-Spam-Status: No, score=-2.471 tagged_above=-999 required=5 tests=[AWL=0.128,  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 0vqjNgbGwBMK for ; Mon, 11 Oct 2010 11:46:00 -0700 (PDT)
Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6]) by core3.amsl.com (Postfix) with ESMTP id 13D463A6B46 for ; Mon, 11 Oct 2010 11:45:59 -0700 (PDT)
Received: from mail.acmepacket.com (216.41.24.7) by etmail.acmepacket.com (216.41.24.6) with Microsoft SMTP Server (TLS) id 8.2.254.0; Mon, 11 Oct 2010 14:47:12 -0400
Received: from mail.acmepacket.com ([127.0.0.1]) by mail ([127.0.0.1]) with mapi; Mon, 11 Oct 2010 14:46:50 -0400
From: Hadriel Kaplan 
To: IETF IPFIX Working Group 
Date: Mon, 11 Oct 2010 14:46:49 -0400
Thread-Topic: semantics in structured-data: one of these things is not like the others
Thread-Index: ActpdKpcxRUAal+QQZCgLLyoaHR2AA==
Message-ID: <6854E01D-36B4-45B5-A2EB-45FC75C551C3@acmepacket.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Subject: [IPFIX] semantics in structured-data: one of these things is not like the others
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, 11 Oct 2010 18:46:01 -0000

Hi,
I have a question on the "semantic" field in the structured-data draft.  I =
apologize if this has been brought up before.

ISTM the field is mixing-up/overloading two distinct types of information, =
or I'm not understanding it right.  One is list field *ordering* - whether =
the list's encoded order of members is significant or not (ie, the "ordered=
" semantic value).  The other is *applicability* - whether the lists member=
s apply to the flow or not (noneOf, exactlyOneOf, oneOrMoreOf, and allOf).

So what is the *applicability* of an "ordered" list?  Presumably allOf, rig=
ht?  In other words, if a list is marked "ordered", do all it's members app=
ly to the flow? =20

I ask because it's also possible for a list to have both a ordered and none=
Of semantic, or to have a ordered with oneOrMoreOf semantic.  For example, =
if you report an access control list that did not apply to the flow, that's=
 an ordered+noneOf.  Or if you report one that does match the flow, that wo=
uld arguably be an ordered+oneOrMoreOf.  You might want to think about maki=
ng "ordered" a bit-flag of the semantic field instead of one of the semanti=
c enumerations.=20

-hadriel


From paitken@cisco.com  Mon Oct 11 15:22:52 2010
Return-Path: 
X-Original-To: ipfix@core3.amsl.com
Delivered-To: ipfix@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6A0583A6B93 for ; Mon, 11 Oct 2010 15:22:52 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.599
X-Spam-Level: 
X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mWgqC7X6n+T4 for ; Mon, 11 Oct 2010 15:22:45 -0700 (PDT)
Received: from rtp-iport-1.cisco.com (rtp-iport-1.cisco.com [64.102.122.148]) by core3.amsl.com (Postfix) with ESMTP id B998A3A67E6 for ; Mon, 11 Oct 2010 15:22:44 -0700 (PDT)
Authentication-Results: rtp-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AvsEAF8rs0xAZnwM/2dsb2JhbACiDHGmepxsAoVGBIpBgwM
X-IronPort-AV: E=Sophos;i="4.57,316,1283731200";  d="scan'208,217";a="169311457"
Received: from rtp-core-1.cisco.com ([64.102.124.12]) by rtp-iport-1.cisco.com with ESMTP; 11 Oct 2010 22:23:56 +0000
Received: from cisco.com (mrwint.cisco.com [64.103.71.48]) by rtp-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id o9BMNuSS009790; Mon, 11 Oct 2010 22:23:56 GMT
Received: from [10.55.81.27] (dhcp-10-55-81-27.cisco.com [10.55.81.27]) by cisco.com (8.11.7p3+Sun/8.8.8) with ESMTP id o9BMNs819156; Mon, 11 Oct 2010 23:23:54 +0100 (BST)
Message-ID: <4CB38E78.5040403@cisco.com>
Date: Mon, 11 Oct 2010 23:23:52 +0100
From: Paul Aitken 
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-GB; rv:1.9.2.9) Gecko/20100915 Lightning/1.0b2 Thunderbird/3.1.4
MIME-Version: 1.0
To: IETF IPFIX Working Group , christoph.sommer@informatik.uni-erlangen.de
References: <20100712170001.B2D7C3A69C2@core3.amsl.com> <4C4930A9.7090707@informatik.uni-erlangen.de>
In-Reply-To: <4C4930A9.7090707@informatik.uni-erlangen.de>
Content-Type: multipart/alternative; boundary="------------030603040106090108020402"
Subject: Re: [IPFIX] I-D ACTION:draft-ietf-ipfix-structured-data-02.txt
X-BeenThere: ipfix@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: IPFIX WG discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 11 Oct 2010 22:22:52 -0000

This is a multi-part message in MIME format.
--------------030603040106090108020402
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit



Christoph,

Thanks for reviewing the structured data draft. Please find responses 
inline.

Thanks,
     Gowri, Benoit and Paul.


-----Original Message-----
> From: ipfix-bounces@ietf.org [mailto:ipfix-bounces@ietf.org] On Behalf 
> Of Christoph Sommer
> Sent: Friday, July 23, 2010 2:03 AM
> To: ipfix@ietf.org
> Subject: Re: [IPFIX] I-D ACTION:draft-ietf-ipfix-structured-data-02.txt
>
> Benoit, all,
>
> as promised, here are some comments on 
> draft-ietf-ipfix-structured-data-02:
>
>
> Section 4.5:
>
> > when representing variable-length data, hierarchical data, and
>
> >       repeated data with variable element counts, we RECOMMEND these are
>
> >       encoded as a Variable-Length Information Element
>
> The draft doesn't make very clear why this is recommended. It almost
>
> feels like the benefits of this are implementation specific...
>

Please see the revised text in section 5.1, "Length Encoding 
Considerations".


> Section 5.6:
>
> > The Exporter SHOULD NOT check all semantically meaningless
>
> >      combinations before exporting the Data Record.
>
> I didn't understand what is meant by this 'checking of combinations'. Is
>
> there a way to spell it out more clearly?
>

We clarified the text:

     It is not the Exporter's role to check the validity of the semantic 
representation of Data Records. Therefore, the Exporter SHOULD NOT check 
all semantically meaningless combinations before exporting the Data Record.


> Section 5.6:
>
> > in case of a single element in a Structured Data
>
> >      Information Element, the default "undefined" semantic SHOULD be
>
> >      used.
>
> Is this to promote a consistent encoding? I don't see any harm in using
>
> one of the other semantics - in fact, using the same semantic for the
>
> same field regardless of the number of encoded values should save both
>
> the exporter and data visualization tools some time.
>
> Also, there's an off chance that this recommendation might be
>
> misunderstood to imply that encoding one value with "noneOf" semantic
>
> should be done using "undefined", too :)
>

Note that this is a SHOULD, not a MUST.


> Section 7:
>
> > If the Structured Data contains the "undefined" Structured Data
>
> >      type semantic, the Collecting Process MAY attempt to draw its own
>
> >      conclusion in terms of the semantic contained in the Data Record,
>
> >      exactly as it would have done before the introduction of this
>
> >      specification.
>
> Collectors that are unaware of this specification would never be able to
>
> make any sense of structured data BLOBs, would they?
>

Yes, so we removed the text "exactly as it would have done before the 
introduction of this specification."


> Section 8.4:
>
> >      As explained in Section 4.4.3., a subTemplateMultiList is used
>
> that's section 4.1.3, no?
>

Thanks for pointing this out. Corrected to "Section 4.5.3".


> Section 8.4:
>
> >  Template for classification attributes: 259
>
> >   Template for sampling attributes: 260
>
> >   Template for Flow Record: 261
>
> Here, like in other parts of the draft, the indentation is a bit off. It
>
> might be taken to imply that templates 260 and 261 and dependant on 259.
>
> In fact, it's 261 that's dependant on 259 and 260.
>
The space has been removed.


> Section 9.2:
>
> > - this test should be expanded to include Data Records
>
> >    containing variable length basicList,
>
> >    subTemplateList, and subTemplateMultiList Information
>
> >    Elements.
>
> Maybe an explicit recommendation to test not only for variable length
>
> structured data, but also for fixed length structured data field
>
> containing variable-length IEs might be warranted.
>

Can you give an example use case?


Thanks.

> Cheers,
>
>    Christoph
>
>
> -- 
>
> Christoph Sommer
>
> Computer Networks and Communication Systems
>
> University of Erlangen-Nuremberg, Germany
>
> Phone: +49 9131 85-27993 / Fax: +49 9131 85-27409
>
> http://www7.informatik.uni-erlangen.de/~sommer/ 
> 
>
> _______________________________________________
>
> IPFIX mailing list
>
> IPFIX@ietf.org
>
> https://www.ietf.org/mailman/listinfo/ipfix
>


--------------030603040106090108020402
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit



  
    
    
    RE: [IPFIX] I-D
      ACTION:draft-ietf-ipfix-structured-data-02.txt
  
  
    
    
Christoph,

    
Thanks for reviewing the structured
        data draft. Please find responses inline.

    
Thanks,

            Gowri, Benoit and Paul.

      

    


        -----Original Message-----

        
 From: ipfix-bounces@ietf.org
            [mailto:ipfix-bounces@ietf.org]
            On Behalf Of Christoph Sommer

            Sent: Friday, July 23, 2010 2:03 AM

            To: ipfix@ietf.org

            Subject: Re: [IPFIX] I-D
            ACTION:draft-ietf-ipfix-structured-data-02.txt
          
Benoit, all,

          
as promised, here are some
              comments on draft-ietf-ipfix-structured-data-02:

          

          
Section 4.5:

          
> when representing
              variable-length data, hierarchical data, and

          
>       repeated data with
              variable element counts, we RECOMMEND these are

          
>       encoded as a
              Variable-Length Information Element

          
The draft doesn't make very
              clear why this is recommended. It almost 

          
feels like the benefits of
              this are implementation specific...

        

      

            Please see the revised text in section 5.1, "Length Encoding
            Considerations".

    

    


      
        

          

          
Section 5.6:

          
> The Exporter SHOULD NOT
              check all semantically meaningless

          
>      combinations before
              exporting the Data Record.

          
I didn't understand what is
              meant by this 'checking of combinations'. Is 

          
there a way to spell it out
              more clearly?

        

      
        


              We clarified the text:

              

               
              It is not the Exporter's role to check the validity of the
              semantic representation of Data Records. Therefore, the
              Exporter SHOULD NOT check all semantically meaningless
              combinations before exporting the Data Record.

            

        

        

          

          

          
Section 5.6:

          
> in case of a single
              element in a Structured Data

          
>      Information Element,
              the default "undefined" semantic SHOULD be

          
>      used.

          
Is this to promote a
              consistent encoding? I don't see any harm in using 

          
one of the other semantics -
              in fact, using the same semantic for the 

          
same field regardless of the
              number of encoded values should save both 

          
the exporter and data
              visualization tools some time.

          
Also, there's an off chance
              that this recommendation might be 

          
misunderstood to imply that
              encoding one value with "noneOf" semantic 

          
should be done using
              "undefined", too :)

        

        

      
        
Note that
              this is a SHOULD, not a MUST.

        

        

          

          

          
Section 7:

          
> If the Structured Data
              contains the "undefined" Structured Data

          
>      type semantic, the
              Collecting Process MAY attempt to draw its own

          
>      conclusion in terms
              of the semantic contained in the Data Record,

          
>      exactly as it would
              have done before the introduction of this

          
>      specification.

          
Collectors that are unaware of
              this specification would never be able to 

          
make any sense of structured
              data BLOBs, would they?

        

        

      
        
Yes, so we
              removed the text “exactly as it would have done before the
              introduction of this specification.”

      

    


        

          

          

          
Section 8.4:

          
>      As explained in
              Section 4.4.3., a subTemplateMultiList is used

          
that's section 4.1.3, no?

        

        

      
        
Thanks for
              pointing this out. Corrected to "Section 4.5.3".

      

    


        

          

          
Section 8.4:

          
>  Template for
              classification attributes: 259

          
>   Template for sampling
              attributes: 260

          
>   Template for Flow
              Record: 261

          
Here, like in other parts of
              the draft, the indentation is a bit off. It 

          
might be taken to imply that
              templates 260 and 261 and dependant on 259. 

          
In fact, it's 261 that's
              dependant on 259 and 260.

        

      

    

        
The space has been removed.

      

        

          

          

          
Section 9.2:

          
> - this test should be
              expanded to include Data Records

          
>    containing variable
              length basicList,

          
>    subTemplateList, and
              subTemplateMultiList Information

          
>    Elements.

          
Maybe an explicit
              recommendation to test not only for variable length 

          
structured data, but also for
              fixed length structured data field 

          
containing variable-length IEs
              might be warranted.

        

      
        


              Can you give an example use case?

            

        


              Thanks.

              

            

      

    

        

          
Cheers,

          
   Christoph

          

          
-- 

          
Christoph Sommer

          
Computer Networks and
              Communication Systems

          
University of
              Erlangen-Nuremberg, Germany

          
Phone: +49 9131 85-27993 /
              Fax: +49 9131 85-27409

          
http://www7.informatik.uni-erlangen.de/~sommer/

          
_______________________________________________

          
IPFIX mailing list

          
IPFIX@ietf.org

          
https://www.ietf.org/mailman/listinfo/ipfix

        

        

      

  


--------------030603040106090108020402--

From n.brownlee@auckland.ac.nz  Mon Oct 11 18:32:46 2010
Return-Path: 
X-Original-To: ipfix@core3.amsl.com
Delivered-To: ipfix@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CFEB73A6BB0 for ; Mon, 11 Oct 2010 18:32:46 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.99
X-Spam-Level: 
X-Spam-Status: No, score=-102.99 tagged_above=-999 required=5 tests=[AWL=0.609, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rabiL8k9vKkA for ; Mon, 11 Oct 2010 18:32:44 -0700 (PDT)
Received: from mx2-int.auckland.ac.nz (mx2-int.auckland.ac.nz [130.216.12.41]) by core3.amsl.com (Postfix) with ESMTP id 3091F3A688A for ; Mon, 11 Oct 2010 18:32:42 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=auckland.ac.nz; i=n.brownlee@auckland.ac.nz; q=dns/txt; s=uoa; t=1286847238; x=1318383238; h=message-id:date:from:mime-version:to:cc:subject: content-transfer-encoding; z=Message-ID:=20<4CB3BAF9.3090805@auckland.ac.nz>|Date:=20 Tue,=2012=20Oct=202010=2014:33:45=20+1300|From:=20Nevil =20Brownlee=20|MIME-Version: =201.0|To:=20"ipfix-ads@tools.ietf.org"=20|CC:=20IPFIX=20Working=20Group=20|Subject:=20Shepherd=20writeup=20for=20=20draft-ietf-i pfix-anon-04.txt|Content-Transfer-Encoding:=207bit; bh=LLIUgyDyLsMJkNbvUTYpISqiWcZ8MPVxsQ810KNBNyQ=; b=aB4YrM8yAL2BPD7cJ7Q5rytlHADTiBpq3v1RmJlKgml2zX+wf/SLKRE7 iDRki2mhja+zUPjFCZl/NML1bJYcuim3zlYQaZYd7HAr5kEG3mLVtRVzh AhCI1Eky3kcWodpQ0jZ29z9dBYdVmETNTyBfnIkCVvfC7ASEH4Ufyq6Oq Y=;
X-IronPort-AV: E=Sophos;i="4.57,317,1283688000"; d="scan'208";a="30795087"
X-Ironport-HAT: UNIVERSITY - $RELAY-THROTTLE
X-Ironport-Source: 130.216.38.131 - Outgoing - Outgoing-SSL
Received: from nevil-laptop1.sfac.auckland.ac.nz (HELO [130.216.38.131]) ([130.216.38.131]) by mx2-int.auckland.ac.nz with ESMTP; 12 Oct 2010 14:33:46 +1300
Message-ID: <4CB3BAF9.3090805@auckland.ac.nz>
Date: Tue, 12 Oct 2010 14:33:45 +1300
From: Nevil Brownlee 
User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.9) Gecko/20100915 Lightning/1.0b2 Thunderbird/3.1.4
MIME-Version: 1.0
To: "ipfix-ads@tools.ietf.org" 
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Cc: IPFIX Working Group 
Subject: [IPFIX] Shepherd writeup for  draft-ietf-ipfix-anon-04.txt
X-BeenThere: ipfix@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: IPFIX WG discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 12 Oct 2010 01:32:46 -0000

Hi Dan:

Herewith the writeup for this IPFIX work item, please submit it
to IESG for review.

Thanks, Nevil

-- 
---------------------------------------------------------------------
  Nevil Brownlee                    Computer Science Department | ITS
  Phone: +64 9 373 7599 x88941             The University of Auckland
  FAX: +64 9 373 7453   Private Bag 92019, Auckland 1142, New Zealand

Shepherd Document for draft-ietf-ipfix-anon-04.txt

   (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?

   Nevil Brownlee.  I have reviewed this draft, I believe it's ready
     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?

   Yes. It was developed over the last two years, and has had extensive
   discussion on the IPFIX list.  I have no concerns about its 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?

   No.  This is an Experimental draft; it simply explains
   the issues raised by the need to anonymise network trace data files,
   and sets out a method that can be used to describe how data carried
   via IPFIX was anonymised.

   (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.

   Anonymising network data is a 'hot topic' just now within the Network
   Research community.  This draft summarises the IPFIX WG's views on
   anonymisation, and how flow data could be anonymised within IPFIX.
   No IPR disclosure has been made for this draft.

   (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?

   The WG has reached full consensus on this draft.

   (1.f) Has anyone threatened an appeal or otherwise indicated extreme
         discontent? If so, please summarise 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.)

   No.

   (1.g) Has the Document Shepherd personally verified that the
         document satisfies all ID nits? (See the Internet-Drafts Checklist
         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?

   Yes.  The checker complains about addresses that appear in examples
   not being 'documentation' addresses, but these are meant to be
   examples of anonymised addresses.

   (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].

   Yes.  All the normative references are to RFCs, there are no
   downward references.

   (1.i) Has the Document Shepherd verified that the document IANA
         consideration 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 [RFC5226]. If the
         document describes an Expert Review process has Shepherd
         conferred with the Responsible Area Director so that the IESG
         can appoint the needed Expert during the IESG Evaluation?

   Yes.  The IANA Considerations section asks for two new IPFIX
   Information Elements; they will simply need to be added to IANA's
   IPFIX IE Registry.

   (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?

   There are no sections written in a formal language.

   (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 describes anonymisation techniques for IP flow data and
   the export of anonymised data using the IPFIX protocol.  It
   categorizes common anonymisation schemes and defines the parameters
   needed to describe them.  It provides guidelines for the
   implementation of anonymised data export and storage over IPFIX, and
   describes an information model and Options-based method for
   anonymisation metadata export within the IPFIX protocol or storage in
   IPFIX Files.

      Working Group Summary
   This draft has been worked on by WG members from ETH Zurich, and
   reviewed by other members, mostly European, who have similar research
   interests.  Although this seems a somewhat complicated way to transmit
   and store anonymised data, I believe it is a significant step towards
   a common (one day, Standard) way to carry metadata about how the
   anonymisation was done along with the data itself.  Although there was
   considerable discussion within the working group, consensus was
   reached without any problems.

      Document Quality
   This is an Experimental I-D, intended for the Network Research and
   Network Security communities.  It is submitted as an Experimental
   document; we do this as a way of encouraging multiple implementations,
   so as to gain experience with it.  When we have sufficient experience
   with this, we will bring it back to the Working Group to consider
   as a new Standards Track work item.

Nevil Brownlee
12 Oct 10

  - - - - - - - - - - -

From muenz@net.in.tum.de  Tue Oct 12 02:22:22 2010
Return-Path: 
X-Original-To: ipfix@core3.amsl.com
Delivered-To: ipfix@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0EF4A3A68F3 for ; Tue, 12 Oct 2010 02:22:22 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.701
X-Spam-Level: 
X-Spam-Status: No, score=-1.701 tagged_above=-999 required=5 tests=[AWL=0.548,  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 L4oTZVhtKjXa for ; Tue, 12 Oct 2010 02:22:21 -0700 (PDT)
Received: from mail-out1.informatik.tu-muenchen.de (mail-out1.informatik.tu-muenchen.de [131.159.0.8]) by core3.amsl.com (Postfix) with ESMTP id ECA423A68EE for ; Tue, 12 Oct 2010 02:22:20 -0700 (PDT)
Received: from [131.159.20.108] (repulse.net.in.tum.de [131.159.20.108]) by mail.net.in.tum.de (Postfix) with ESMTPSA id 7FD0E20C8D18; Tue, 12 Oct 2010 11:23:33 +0200 (CEST)
Message-ID: <4CB42936.2020208@net.in.tum.de>
Date: Tue, 12 Oct 2010 11:24:06 +0200
From: Gerhard Muenz 
User-Agent: Thunderbird 2.0.0.24 (Windows/20100228)
MIME-Version: 1.0
To: Hadriel Kaplan 
References: <6854E01D-36B4-45B5-A2EB-45FC75C551C3@acmepacket.com>
In-Reply-To: <6854E01D-36B4-45B5-A2EB-45FC75C551C3@acmepacket.com>
Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms030903000807030702020305"
Cc: IETF IPFIX Working Group 
Subject: Re: [IPFIX] semantics in structured-data: one of these things is not like the others
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, 12 Oct 2010 09:22:22 -0000

This is a cryptographically signed message in MIME format.

--------------ms030903000807030702020305
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit


Hi Hadriel,

IPFIX is not only about Flow Records. We also have Options data which
needs to be exported.

Semantic "Ordered" will be very helpful to describe a chain of IPFIX
Mediators or a sequence of specific packet/flow treatments.

Regards,
Gerhard


Hadriel Kaplan wrote:
> Hi, I have a question on the "semantic" field in the structured-data
> draft.  I apologize if this has been brought up before.
> 
> ISTM the field is mixing-up/overloading two distinct types of
> information, or I'm not understanding it right.  One is list field
> *ordering* - whether the list's encoded order of members is
> significant or not (ie, the "ordered" semantic value).  The other is
> *applicability* - whether the lists members apply to the flow or not
> (noneOf, exactlyOneOf, oneOrMoreOf, and allOf).
> 
> So what is the *applicability* of an "ordered" list?  Presumably
> allOf, right?  In other words, if a list is marked "ordered", do all
> it's members apply to the flow?
> 
> I ask because it's also possible for a list to have both a ordered
> and noneOf semantic, or to have a ordered with oneOrMoreOf semantic.
> For example, if you report an access control list that did not apply
> to the flow, that's an ordered+noneOf.  Or if you report one that
> does match the flow, that would arguably be an ordered+oneOrMoreOf.
> You might want to think about making "ordered" a bit-flag of the
> semantic field instead of one of the semantic enumerations.
> 
> -hadriel
> 

--------------ms030903000807030702020305
Content-Type: application/x-pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIO5jCC
BEYwggOvoAMCAQICEGb9R+PCGeToms2Z3fU6yyQwDQYJKoZIhvcNAQEFBQAwXzELMAkGA1UE
BhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMTcwNQYDVQQLEy5DbGFzcyAxIFB1Ymxp
YyBQcmltYXJ5IENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA1MTAyODAwMDAwMFoXDTE1
MTAyNzIzNTk1OVowgd0xCzAJBgNVBAYTAlVTMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEf
MB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazE7MDkGA1UECxMyVGVybXMgb2YgdXNl
IGF0IGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9ycGEgKGMpMDUxHjAcBgNVBAsTFVBlcnNv
bmEgTm90IFZhbGlkYXRlZDE3MDUGA1UEAxMuVmVyaVNpZ24gQ2xhc3MgMSBJbmRpdmlkdWFs
IFN1YnNjcmliZXIgQ0EgLSBHMjCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMnf
rOfq+PgDFMQAktXBfjbCPO98chXLwKuMPRyVzm8eECw/AO2XJua2x+atQx0/pIdHR0w+VPhs
+Mf8sZ69MHC8l7EDBeqV8a1AxUR6SwWi8mD81zplYu//EHuiVrvFTnAt1qIfPO2wQuhejVch
rKaZ2RHp0hoHwHRHQgv8xTTq/ea6JNEdCBU3otdzzwFBL2OyOj++pRpu9MlKWz2VphW7NQIZ
+dTvvI8OcXZZu0u2Ptb8Whb01g6J8kn+bAztFenZiHWcec5gJ925rXXOL3OVekA6hXVJsLjf
aLyrzROChRFQo+A8C67AClPN1zBvhTJGG+RJEMJs4q8fef/btLUCAwEAAaOB/zCB/DASBgNV
HRMBAf8ECDAGAQH/AgEAMEQGA1UdIAQ9MDswOQYLYIZIAYb4RQEHFwEwKjAoBggrBgEFBQcC
ARYcaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYTALBgNVHQ8EBAMCAQYwEQYJYIZIAYb4
QgEBBAQDAgEGMC4GA1UdEQQnMCWkIzAhMR8wHQYDVQQDExZQcml2YXRlTGFiZWwzLTIwNDgt
MTU1MB0GA1UdDgQWBBQRfV4ZfTwE32ps1qKKGj8x2DuUUjAxBgNVHR8EKjAoMCagJKAihiBo
dHRwOi8vY3JsLnZlcmlzaWduLmNvbS9wY2ExLmNybDANBgkqhkiG9w0BAQUFAAOBgQA8o9oC
YzrEk6qrctPcrVA4HgyeFkqIt+7r2f8PjZWg1rv6aguuYYTYaEeJ70+ssh9JQZtJM3aTi55u
uUMcYL3C3Ioth8FFwBFyBBprJCpsb+f8BxMp0Hc6I+f1wYVoGb/GAVQgGa41gsxiPGEJxvTV
67APpp8zhZrTcY5Qj5ndYjCCBUowggQyoAMCAQICEF0kYdlVNx5E1qcmxun5IrswDQYJKoZI
hvcNAQEFBQAwgd0xCzAJBgNVBAYTAlVTMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0G
A1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazE7MDkGA1UECxMyVGVybXMgb2YgdXNlIGF0
IGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9ycGEgKGMpMDUxHjAcBgNVBAsTFVBlcnNvbmEg
Tm90IFZhbGlkYXRlZDE3MDUGA1UEAxMuVmVyaVNpZ24gQ2xhc3MgMSBJbmRpdmlkdWFsIFN1
YnNjcmliZXIgQ0EgLSBHMjAeFw0xMDAxMDIwMDAwMDBaFw0xMTAxMDIyMzU5NTlaMIIBEzEX
MBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0IE5ldHdv
cmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEgSW5jb3JwLiBi
eSBSZWYuLExJQUIuTFREKGMpOTgxHjAcBgNVBAsTFVBlcnNvbmEgTm90IFZhbGlkYXRlZDEz
MDEGA1UECxMqRGlnaXRhbCBJRCBDbGFzcyAxIC0gTmV0c2NhcGUgRnVsbCBTZXJ2aWNlMRYw
FAYDVQQDFA1HZXJoYXJkIE11ZW56MSIwIAYJKoZIhvcNAQkBFhNtdWVuekBuZXQuaW4udHVt
LmRlMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAl/YDW9cnAXJjesGhwtGwj9JN
IHWXQ7QA18s+wGZNsQY0k4eKBeLTk/RAiC1hP+uQAXLoGQHQF/ljjQCQeRmnsN6w04iAzKVo
Ru+NP7Y6ipn8uztx+z0Y3w43CO+LWUudp3PIF3+Fm2zwsAFXj/IYy/8Kq6m9+nQgYO/D4HoN
DDR3//GepXghK0x93gR0GCkm8pgKINHNBD47/IZbDe/cIpAC9HaoxCeLiB1QaCDIYPIrJ0Vx
kk0crAA0tPaMDjdSQTmNRAn2P+7Wg7K+DLvauBHfxLs8PrsolI+XdwiBu6henK9nPxvtoHmm
mfxcdslKLbS9Xz2rHxi6PVVgv1ubWwIDAQABo4HMMIHJMAkGA1UdEwQCMAAwRAYDVR0gBD0w
OzA5BgtghkgBhvhFAQcXATAqMCgGCCsGAQUFBwIBFhxodHRwczovL3d3dy52ZXJpc2lnbi5j
b20vcnBhMAsGA1UdDwQEAwIFoDAdBgNVHSUEFjAUBggrBgEFBQcDBAYIKwYBBQUHAwIwSgYD
VR0fBEMwQTA/oD2gO4Y5aHR0cDovL0luZEMxRGlnaXRhbElELWNybC52ZXJpc2lnbi5jb20v
SW5kQzFEaWdpdGFsSUQuY3JsMA0GCSqGSIb3DQEBBQUAA4IBAQBPU7OeWNo2LRzsdu/RuuAk
L5cj/RzeZ0xv9q4K/eosy9dRu45XACpPvb0fjc3u/dsY4m3jDqzUsB02IrrnF9jpEo10BJPw
b/RZ7NaU7jC/gEknL3bSXiD2PVwL4ZI5ChH5+TJUboWhVh+FpOwOfP/yKk7wQM/46iXXzRIz
enk0rcJp71k4aQgQTML3/8MDeD6TUipuQwQMY9n6T6DsNd/6JpGa+x9ZX4HIEG6+EWwQ85G5
vGfDBaq3dFrksHE75u7b7pf75wm9HIFU2SDHP2tymTHJt/XM9sqP1URIC57s+uZV0/d5KRc1
uPcJ0FAnAiC9o7ybPIh27shiq0FvOEwfMIIFSjCCBDKgAwIBAgIQXSRh2VU3HkTWpybG6fki
uzANBgkqhkiG9w0BAQUFADCB3TELMAkGA1UEBhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJ
bmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTswOQYDVQQLEzJUZXJtcyBv
ZiB1c2UgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYSAoYykwNTEeMBwGA1UECxMV
UGVyc29uYSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5WZXJpU2lnbiBDbGFzcyAxIEluZGl2
aWR1YWwgU3Vic2NyaWJlciBDQSAtIEcyMB4XDTEwMDEwMjAwMDAwMFoXDTExMDEwMjIzNTk1
OVowggETMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1
c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJ
bmNvcnAuIGJ5IFJlZi4sTElBQi5MVEQoYyk5ODEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFs
aWRhdGVkMTMwMQYDVQQLEypEaWdpdGFsIElEIENsYXNzIDEgLSBOZXRzY2FwZSBGdWxsIFNl
cnZpY2UxFjAUBgNVBAMUDUdlcmhhcmQgTXVlbnoxIjAgBgkqhkiG9w0BCQEWE211ZW56QG5l
dC5pbi50dW0uZGUwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCX9gNb1ycBcmN6
waHC0bCP0k0gdZdDtADXyz7AZk2xBjSTh4oF4tOT9ECILWE/65ABcugZAdAX+WONAJB5Gaew
3rDTiIDMpWhG740/tjqKmfy7O3H7PRjfDjcI74tZS52nc8gXf4WbbPCwAVeP8hjL/wqrqb36
dCBg78Pgeg0MNHf/8Z6leCErTH3eBHQYKSbymAog0c0EPjv8hlsN79wikAL0dqjEJ4uIHVBo
IMhg8isnRXGSTRysADS09owON1JBOY1ECfY/7taDsr4Mu9q4Ed/Euzw+uyiUj5d3CIG7qF6c
r2c/G+2geaaZ/Fx2yUottL1fPasfGLo9VWC/W5tbAgMBAAGjgcwwgckwCQYDVR0TBAIwADBE
BgNVHSAEPTA7MDkGC2CGSAGG+EUBBxcBMCowKAYIKwYBBQUHAgEWHGh0dHBzOi8vd3d3LnZl
cmlzaWduLmNvbS9ycGEwCwYDVR0PBAQDAgWgMB0GA1UdJQQWMBQGCCsGAQUFBwMEBggrBgEF
BQcDAjBKBgNVHR8EQzBBMD+gPaA7hjlodHRwOi8vSW5kQzFEaWdpdGFsSUQtY3JsLnZlcmlz
aWduLmNvbS9JbmRDMURpZ2l0YWxJRC5jcmwwDQYJKoZIhvcNAQEFBQADggEBAE9Ts55Y2jYt
HOx279G64CQvlyP9HN5nTG/2rgr96izL11G7jlcAKk+9vR+Nze792xjibeMOrNSwHTYiuucX
2OkSjXQEk/Bv9Fns1pTuML+ASScvdtJeIPY9XAvhkjkKEfn5MlRuhaFWH4Wk7A58//IqTvBA
z/jqJdfNEjN6eTStwmnvWThpCBBMwvf/wwN4PpNSKm5DBAxj2fpPoOw13/omkZr7H1lfgcgQ
br4RbBDzkbm8Z8MFqrd0WuSwcTvm7tvul/vnCb0cgVTZIMc/a3KZMcm39cz2yo/VREgLnuz6
5lXT93kpFzW49wnQUCcCIL2jvJs8iHbuyGKrQW84TB8xggTsMIIE6AIBATCB8jCB3TELMAkG
A1UEBhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBU
cnVzdCBOZXR3b3JrMTswOQYDVQQLEzJUZXJtcyBvZiB1c2UgYXQgaHR0cHM6Ly93d3cudmVy
aXNpZ24uY29tL3JwYSAoYykwNTEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTcw
NQYDVQQDEy5WZXJpU2lnbiBDbGFzcyAxIEluZGl2aWR1YWwgU3Vic2NyaWJlciBDQSAtIEcy
AhBdJGHZVTceRNanJsbp+SK7MAkGBSsOAwIaBQCgggLOMBgGCSqGSIb3DQEJAzELBgkqhkiG
9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTEwMTAxMjA5MjQwNlowIwYJKoZIhvcNAQkEMRYEFGEA
dGgY79Bfo1YVBsqn1Ja3sBCjMF8GCSqGSIb3DQEJDzFSMFAwCwYJYIZIAWUDBAECMAoGCCqG
SIb3DQMHMA4GCCqGSIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG
9w0DAgIBKDCCAQMGCSsGAQQBgjcQBDGB9TCB8jCB3TELMAkGA1UEBhMCVVMxFzAVBgNVBAoT
DlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTswOQYD
VQQLEzJUZXJtcyBvZiB1c2UgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYSAoYykw
NTEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5WZXJpU2lnbiBD
bGFzcyAxIEluZGl2aWR1YWwgU3Vic2NyaWJlciBDQSAtIEcyAhBdJGHZVTceRNanJsbp+SK7
MIIBBQYLKoZIhvcNAQkQAgsxgfWggfIwgd0xCzAJBgNVBAYTAlVTMRcwFQYDVQQKEw5WZXJp
U2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazE7MDkGA1UECxMy
VGVybXMgb2YgdXNlIGF0IGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9ycGEgKGMpMDUxHjAc
BgNVBAsTFVBlcnNvbmEgTm90IFZhbGlkYXRlZDE3MDUGA1UEAxMuVmVyaVNpZ24gQ2xhc3Mg
MSBJbmRpdmlkdWFsIFN1YnNjcmliZXIgQ0EgLSBHMgIQXSRh2VU3HkTWpybG6fkiuzANBgkq
hkiG9w0BAQEFAASCAQCDL2bZsf62m9jawcXFoAYqaBoGI+1AGv7jTME0vAdzziJmNIa3drGZ
B4ZYlOHG8//R5GchvbqeECd4ipj3vVHwMM5KVZRH9iGcQslFU3m2baMNShf+tbkG5k7xLZ++
3uRInCd0Ll+Xehghe0nRFO9ZbQesPdQ0vokXMn4sc8OVoOywjtZpVsJb8B1Hy6XcKjhOPYMD
R/rFCQDjH4Ix5fsP58GEaasOM+1BBkEMmywXneCIWwze++yADfdsGLLxogqXFer9BPuaCRM1
tlPdLPylTPh0t0lY0wCEL7xdy1iW40b8rZraiNsCnJCWBCfqk9CyskiXHf4ULv4M6ZZXxMis
AAAAAAAA
--------------ms030903000807030702020305--

From muenz@net.in.tum.de  Tue Oct 12 02:36:24 2010
Return-Path: 
X-Original-To: ipfix@core3.amsl.com
Delivered-To: ipfix@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1D1D33A6783 for ; Tue, 12 Oct 2010 02:36:24 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.151
X-Spam-Level: 
X-Spam-Status: No, score=-1.151 tagged_above=-999 required=5 tests=[AWL=-0.102, BAYES_00=-2.599, HELO_EQ_DE=0.35, J_CHICKENPOX_25=0.6, J_CHICKENPOX_29=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 rg9nz49E10NQ for ; Tue, 12 Oct 2010 02:36:22 -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 990283A6765 for ; Tue, 12 Oct 2010 02:36:22 -0700 (PDT)
Received: from [131.159.20.108] (repulse.net.in.tum.de [131.159.20.108]) by mail.net.in.tum.de (Postfix) with ESMTPSA id EEF8420C8D18; Tue, 12 Oct 2010 11:37:35 +0200 (CEST)
Message-ID: <4CB42C81.3040305@net.in.tum.de>
Date: Tue, 12 Oct 2010 11:38:09 +0200
From: Gerhard Muenz 
User-Agent: Thunderbird 2.0.0.24 (Windows/20100228)
MIME-Version: 1.0
To: Hadriel Kaplan 
References: <646D5D04-3C32-4576-8925-550F3014B59E@acmepacket.com>
In-Reply-To: <646D5D04-3C32-4576-8925-550F3014B59E@acmepacket.com>
Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms070204030806050906050102"
X-Virus-Scanned: ClamAV using ClamSMTP
Cc: IETF IPFIX Working Group 
Subject: Re: [IPFIX] questions about structured-data draft
X-BeenThere: ipfix@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: IPFIX WG discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 12 Oct 2010 09:36:24 -0000

This is a cryptographically signed message in MIME format.

--------------ms070204030806050906050102
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit


Hi Hadriel,

Hadriel Kaplan wrote:
> 2) Along that same line of thought, encoding the structures as done
> in this draft seems to lose the type information of the list itself.
> It has to be inferred, which is failure-prone.  For example, suppose
> you report a list of the ACL the flow matches, as well as a list of
> the packet's source IP headers (it could be a list if it's IP-in-IP
> or IPsec tunnel mode).  The ACL may be just a basicList of
> sourceIPv4Address, as would the IP-in-IP list.  How does the ipfix
> collector/reader know which is which?  What if vendor X records the
> ACL first and the IP-in-IP second, while vendor Y does the opposite?
> Or vendor X may only report ACLs while vendor Y only reports
> IP-in-IP, but their reports look identical.  Or for another example,
> the draft talks about a multicast list being a list of
> egressInterfaces.  But how does the ipfix reader know that a list of
> egress interfaces is a "multicast" list and not a list of aggregated
> interfaces, or span ports?  The problem is these lists have no type.
> They're just lists of types.  Anytime two lists of different purposes
> happen to use the same member types there's a collision.  Or am I
> missing something? (could easily be)

Without any context information, the Collector will never know how to
interpret a Data Record.

For example, even if it looks like a Flow Record, it might be an PSAMP
Packet Report (unless a counter fields exists indicating that there is
more than one packet).

To some extend, context information can be exported in a standardized
way using Options, e.g. to describe the Metering Process. But there are
limitations.

My understanding is that IPFIX does not aim at exporting all kinds
context information because IPFIX will be implemented in environments
where you know what kind of device the Exporter is. So, you can assume
that a certain context is given so that the Collector is able to
interpret the exported data.

> 4) This is just an observation, but it seems funny to me that a
> "basicList" actually takes more bytes to encode than a
> subTemplateList, so that a basicList of basicLists is even more
> expensive than a subTemplateList of subTemplateLists.  For example
> take the BGP Path example encoding AS1, AS2, AS3, {AS4, AS5}:
> 
> I would encode the following using basicList: Template: ID=256 
> sourceIPv4Address, destinationIPv4Address, basicList
> 
> Set: TemplateID=256 Data-Record: 1.1.1.1, 2.2.2.2, {(length=XXX,
> ordered) IE=basicList IElength=65535: {(length=YYY, ordered) IE=bgpAS
> IElength=2: AS1, AS2, AS3}, {(length=ZZZ, exactlyOneOf) IE=bgpAS
> IElength=2: AS4, AS5}}
> 
> But the following using subTemplateList: Template: ID=256 
> sourceIPv4Address, destinationIPv4Address, subTemplateList
> 
> Template: ID=257 subTemplateList
> 
> Template: ID=258 bgpAS
> 
> Set: TemplateID=256 Data-Record: 1.1.1.1, 2.2.2.2, {(length=XXX,
> ordered) TID=257: {(ordered) TID=258: AS1, AS2, AS3}, {(exactlyOneOf)
> TID=258: AS4, AS5}}

Just a note: This is a good use-case where the IE representation
proposed in the IE doctors draft would be useful :) I think I would have
less problems to understand your example.

Regards,

Gerhard


--------------ms070204030806050906050102
Content-Type: application/x-pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIO5jCC
BEYwggOvoAMCAQICEGb9R+PCGeToms2Z3fU6yyQwDQYJKoZIhvcNAQEFBQAwXzELMAkGA1UE
BhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMTcwNQYDVQQLEy5DbGFzcyAxIFB1Ymxp
YyBQcmltYXJ5IENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA1MTAyODAwMDAwMFoXDTE1
MTAyNzIzNTk1OVowgd0xCzAJBgNVBAYTAlVTMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEf
MB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazE7MDkGA1UECxMyVGVybXMgb2YgdXNl
IGF0IGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9ycGEgKGMpMDUxHjAcBgNVBAsTFVBlcnNv
bmEgTm90IFZhbGlkYXRlZDE3MDUGA1UEAxMuVmVyaVNpZ24gQ2xhc3MgMSBJbmRpdmlkdWFs
IFN1YnNjcmliZXIgQ0EgLSBHMjCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMnf
rOfq+PgDFMQAktXBfjbCPO98chXLwKuMPRyVzm8eECw/AO2XJua2x+atQx0/pIdHR0w+VPhs
+Mf8sZ69MHC8l7EDBeqV8a1AxUR6SwWi8mD81zplYu//EHuiVrvFTnAt1qIfPO2wQuhejVch
rKaZ2RHp0hoHwHRHQgv8xTTq/ea6JNEdCBU3otdzzwFBL2OyOj++pRpu9MlKWz2VphW7NQIZ
+dTvvI8OcXZZu0u2Ptb8Whb01g6J8kn+bAztFenZiHWcec5gJ925rXXOL3OVekA6hXVJsLjf
aLyrzROChRFQo+A8C67AClPN1zBvhTJGG+RJEMJs4q8fef/btLUCAwEAAaOB/zCB/DASBgNV
HRMBAf8ECDAGAQH/AgEAMEQGA1UdIAQ9MDswOQYLYIZIAYb4RQEHFwEwKjAoBggrBgEFBQcC
ARYcaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYTALBgNVHQ8EBAMCAQYwEQYJYIZIAYb4
QgEBBAQDAgEGMC4GA1UdEQQnMCWkIzAhMR8wHQYDVQQDExZQcml2YXRlTGFiZWwzLTIwNDgt
MTU1MB0GA1UdDgQWBBQRfV4ZfTwE32ps1qKKGj8x2DuUUjAxBgNVHR8EKjAoMCagJKAihiBo
dHRwOi8vY3JsLnZlcmlzaWduLmNvbS9wY2ExLmNybDANBgkqhkiG9w0BAQUFAAOBgQA8o9oC
YzrEk6qrctPcrVA4HgyeFkqIt+7r2f8PjZWg1rv6aguuYYTYaEeJ70+ssh9JQZtJM3aTi55u
uUMcYL3C3Ioth8FFwBFyBBprJCpsb+f8BxMp0Hc6I+f1wYVoGb/GAVQgGa41gsxiPGEJxvTV
67APpp8zhZrTcY5Qj5ndYjCCBUowggQyoAMCAQICEF0kYdlVNx5E1qcmxun5IrswDQYJKoZI
hvcNAQEFBQAwgd0xCzAJBgNVBAYTAlVTMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0G
A1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazE7MDkGA1UECxMyVGVybXMgb2YgdXNlIGF0
IGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9ycGEgKGMpMDUxHjAcBgNVBAsTFVBlcnNvbmEg
Tm90IFZhbGlkYXRlZDE3MDUGA1UEAxMuVmVyaVNpZ24gQ2xhc3MgMSBJbmRpdmlkdWFsIFN1
YnNjcmliZXIgQ0EgLSBHMjAeFw0xMDAxMDIwMDAwMDBaFw0xMTAxMDIyMzU5NTlaMIIBEzEX
MBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0IE5ldHdv
cmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEgSW5jb3JwLiBi
eSBSZWYuLExJQUIuTFREKGMpOTgxHjAcBgNVBAsTFVBlcnNvbmEgTm90IFZhbGlkYXRlZDEz
MDEGA1UECxMqRGlnaXRhbCBJRCBDbGFzcyAxIC0gTmV0c2NhcGUgRnVsbCBTZXJ2aWNlMRYw
FAYDVQQDFA1HZXJoYXJkIE11ZW56MSIwIAYJKoZIhvcNAQkBFhNtdWVuekBuZXQuaW4udHVt
LmRlMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAl/YDW9cnAXJjesGhwtGwj9JN
IHWXQ7QA18s+wGZNsQY0k4eKBeLTk/RAiC1hP+uQAXLoGQHQF/ljjQCQeRmnsN6w04iAzKVo
Ru+NP7Y6ipn8uztx+z0Y3w43CO+LWUudp3PIF3+Fm2zwsAFXj/IYy/8Kq6m9+nQgYO/D4HoN
DDR3//GepXghK0x93gR0GCkm8pgKINHNBD47/IZbDe/cIpAC9HaoxCeLiB1QaCDIYPIrJ0Vx
kk0crAA0tPaMDjdSQTmNRAn2P+7Wg7K+DLvauBHfxLs8PrsolI+XdwiBu6henK9nPxvtoHmm
mfxcdslKLbS9Xz2rHxi6PVVgv1ubWwIDAQABo4HMMIHJMAkGA1UdEwQCMAAwRAYDVR0gBD0w
OzA5BgtghkgBhvhFAQcXATAqMCgGCCsGAQUFBwIBFhxodHRwczovL3d3dy52ZXJpc2lnbi5j
b20vcnBhMAsGA1UdDwQEAwIFoDAdBgNVHSUEFjAUBggrBgEFBQcDBAYIKwYBBQUHAwIwSgYD
VR0fBEMwQTA/oD2gO4Y5aHR0cDovL0luZEMxRGlnaXRhbElELWNybC52ZXJpc2lnbi5jb20v
SW5kQzFEaWdpdGFsSUQuY3JsMA0GCSqGSIb3DQEBBQUAA4IBAQBPU7OeWNo2LRzsdu/RuuAk
L5cj/RzeZ0xv9q4K/eosy9dRu45XACpPvb0fjc3u/dsY4m3jDqzUsB02IrrnF9jpEo10BJPw
b/RZ7NaU7jC/gEknL3bSXiD2PVwL4ZI5ChH5+TJUboWhVh+FpOwOfP/yKk7wQM/46iXXzRIz
enk0rcJp71k4aQgQTML3/8MDeD6TUipuQwQMY9n6T6DsNd/6JpGa+x9ZX4HIEG6+EWwQ85G5
vGfDBaq3dFrksHE75u7b7pf75wm9HIFU2SDHP2tymTHJt/XM9sqP1URIC57s+uZV0/d5KRc1
uPcJ0FAnAiC9o7ybPIh27shiq0FvOEwfMIIFSjCCBDKgAwIBAgIQXSRh2VU3HkTWpybG6fki
uzANBgkqhkiG9w0BAQUFADCB3TELMAkGA1UEBhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJ
bmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTswOQYDVQQLEzJUZXJtcyBv
ZiB1c2UgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYSAoYykwNTEeMBwGA1UECxMV
UGVyc29uYSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5WZXJpU2lnbiBDbGFzcyAxIEluZGl2
aWR1YWwgU3Vic2NyaWJlciBDQSAtIEcyMB4XDTEwMDEwMjAwMDAwMFoXDTExMDEwMjIzNTk1
OVowggETMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1
c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJ
bmNvcnAuIGJ5IFJlZi4sTElBQi5MVEQoYyk5ODEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFs
aWRhdGVkMTMwMQYDVQQLEypEaWdpdGFsIElEIENsYXNzIDEgLSBOZXRzY2FwZSBGdWxsIFNl
cnZpY2UxFjAUBgNVBAMUDUdlcmhhcmQgTXVlbnoxIjAgBgkqhkiG9w0BCQEWE211ZW56QG5l
dC5pbi50dW0uZGUwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCX9gNb1ycBcmN6
waHC0bCP0k0gdZdDtADXyz7AZk2xBjSTh4oF4tOT9ECILWE/65ABcugZAdAX+WONAJB5Gaew
3rDTiIDMpWhG740/tjqKmfy7O3H7PRjfDjcI74tZS52nc8gXf4WbbPCwAVeP8hjL/wqrqb36
dCBg78Pgeg0MNHf/8Z6leCErTH3eBHQYKSbymAog0c0EPjv8hlsN79wikAL0dqjEJ4uIHVBo
IMhg8isnRXGSTRysADS09owON1JBOY1ECfY/7taDsr4Mu9q4Ed/Euzw+uyiUj5d3CIG7qF6c
r2c/G+2geaaZ/Fx2yUottL1fPasfGLo9VWC/W5tbAgMBAAGjgcwwgckwCQYDVR0TBAIwADBE
BgNVHSAEPTA7MDkGC2CGSAGG+EUBBxcBMCowKAYIKwYBBQUHAgEWHGh0dHBzOi8vd3d3LnZl
cmlzaWduLmNvbS9ycGEwCwYDVR0PBAQDAgWgMB0GA1UdJQQWMBQGCCsGAQUFBwMEBggrBgEF
BQcDAjBKBgNVHR8EQzBBMD+gPaA7hjlodHRwOi8vSW5kQzFEaWdpdGFsSUQtY3JsLnZlcmlz
aWduLmNvbS9JbmRDMURpZ2l0YWxJRC5jcmwwDQYJKoZIhvcNAQEFBQADggEBAE9Ts55Y2jYt
HOx279G64CQvlyP9HN5nTG/2rgr96izL11G7jlcAKk+9vR+Nze792xjibeMOrNSwHTYiuucX
2OkSjXQEk/Bv9Fns1pTuML+ASScvdtJeIPY9XAvhkjkKEfn5MlRuhaFWH4Wk7A58//IqTvBA
z/jqJdfNEjN6eTStwmnvWThpCBBMwvf/wwN4PpNSKm5DBAxj2fpPoOw13/omkZr7H1lfgcgQ
br4RbBDzkbm8Z8MFqrd0WuSwcTvm7tvul/vnCb0cgVTZIMc/a3KZMcm39cz2yo/VREgLnuz6
5lXT93kpFzW49wnQUCcCIL2jvJs8iHbuyGKrQW84TB8xggTsMIIE6AIBATCB8jCB3TELMAkG
A1UEBhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBU
cnVzdCBOZXR3b3JrMTswOQYDVQQLEzJUZXJtcyBvZiB1c2UgYXQgaHR0cHM6Ly93d3cudmVy
aXNpZ24uY29tL3JwYSAoYykwNTEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTcw
NQYDVQQDEy5WZXJpU2lnbiBDbGFzcyAxIEluZGl2aWR1YWwgU3Vic2NyaWJlciBDQSAtIEcy
AhBdJGHZVTceRNanJsbp+SK7MAkGBSsOAwIaBQCgggLOMBgGCSqGSIb3DQEJAzELBgkqhkiG
9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTEwMTAxMjA5MzgwOVowIwYJKoZIhvcNAQkEMRYEFPQp
yulGuP/0f2xbQV/q5yJ8tEmbMF8GCSqGSIb3DQEJDzFSMFAwCwYJYIZIAWUDBAECMAoGCCqG
SIb3DQMHMA4GCCqGSIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG
9w0DAgIBKDCCAQMGCSsGAQQBgjcQBDGB9TCB8jCB3TELMAkGA1UEBhMCVVMxFzAVBgNVBAoT
DlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTswOQYD
VQQLEzJUZXJtcyBvZiB1c2UgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYSAoYykw
NTEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5WZXJpU2lnbiBD
bGFzcyAxIEluZGl2aWR1YWwgU3Vic2NyaWJlciBDQSAtIEcyAhBdJGHZVTceRNanJsbp+SK7
MIIBBQYLKoZIhvcNAQkQAgsxgfWggfIwgd0xCzAJBgNVBAYTAlVTMRcwFQYDVQQKEw5WZXJp
U2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazE7MDkGA1UECxMy
VGVybXMgb2YgdXNlIGF0IGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9ycGEgKGMpMDUxHjAc
BgNVBAsTFVBlcnNvbmEgTm90IFZhbGlkYXRlZDE3MDUGA1UEAxMuVmVyaVNpZ24gQ2xhc3Mg
MSBJbmRpdmlkdWFsIFN1YnNjcmliZXIgQ0EgLSBHMgIQXSRh2VU3HkTWpybG6fkiuzANBgkq
hkiG9w0BAQEFAASCAQB4UipiLf8sLGl0LfRAjgwBgNjPMVxfbZ0EB2lXnRhN/tGUi5mrPDCs
DdEscqw2eW9/NJ2fsyTpOGIc7mGhfUP6ndBn8O0vEy9JZARXZ8YesWVUBS/n3kUCapLJ378r
XnuhnYrSrgJNz18ZSm9V2HlBrptJl5CGPD+5RQ9duVnYZLZ+aywef0FlpkHNDSms7Qx9A7Hm
IvYlALgRf4qZ5qoaYdsZbwFFnnrxdfog840/vws8xzRanJYxOVBqLgGwBBIAEbOVaDge4qOg
3g4kmBjZ6LtbROuY5mHDtwDr+aEvzlChNQfy52dM+T/0xHkkpR0vpyke8u1x0YaJjFCFz+fj
AAAAAAAA
--------------ms070204030806050906050102--

From dromasca@avaya.com  Tue Oct 12 05:16:14 2010
Return-Path: 
X-Original-To: ipfix@core3.amsl.com
Delivered-To: ipfix@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4828D3A6930 for ; Tue, 12 Oct 2010 05:16:14 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.517
X-Spam-Level: 
X-Spam-Status: No, score=-102.517 tagged_above=-999 required=5 tests=[AWL=0.082, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ejaBlG6IbVwX for ; Tue, 12 Oct 2010 05:16:11 -0700 (PDT)
Received: from co300216-co-outbound.net.avaya.com (co300216-co-outbound.net.avaya.com [198.152.13.100]) by core3.amsl.com (Postfix) with ESMTP id 473F43A690C for ; Tue, 12 Oct 2010 05:16:11 -0700 (PDT)
X-IronPort-AV: E=Sophos;i="4.57,320,1283745600"; d="scan'208";a="242287991"
Received: from unknown (HELO co300216-co-erhwest.avaya.com) ([198.152.7.5]) by co300216-co-outbound.net.avaya.com with ESMTP; 12 Oct 2010 08:17:25 -0400
X-IronPort-AV: E=Sophos;i="4.57,320,1283745600"; d="scan'208";a="525678493"
Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.12]) by co300216-co-erhwest-out.avaya.com with ESMTP; 12 Oct 2010 08:17:24 -0400
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Date: Tue, 12 Oct 2010 14:17:12 +0200
Message-ID: 
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: AD Review of draft-ipfix-mediators-framework-08
Thread-Index: ActqB2Yxqtty17xJSaGSalPIt+oMBQ==
From: "Romascanu, Dan (Dan)" 
To: "IPFIX Working Group" 
Subject: [IPFIX] AD Review of draft-ipfix-mediators-framework-08
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, 12 Oct 2010 12:16:14 -0000

Please find below the AD review of=20

This document is in quite good shape. I would however suggest to deal
with the issues in this review before sending the document to the IETF
Last Call.=20

The technical comments are marked Tx and the editorial comments are
marked Ex.

T1. Sections 5.2, 5.3: It is not clear what you mean when you say 'This
function must be configurable' - does this mean that some parameters
related to this function are configurable (which ones?), or that
'Activation of this function must be configurable'?=20

T2. Same sections and phrase. This seems to me a very clear
architectural requirement where RFC 2119 capitalized MUST would fit.
Please consider this as a non-blocking comment.=20

T3. In 5.3 'This relation can be configurable' - same question as at T1.


T4. Section 5.3.2.1:=20

      Maintaining the mapping information about Transport Sessions,
      Observation Domain IDs, and Template IDs on the incoming and
      outgoing sides to ensure the appropriateness of the scope field
      values in Data Records defined by Options Templates and of IPFIX
      Template Withdrawal Messages.

I could not figure out what 'the appropriateness of the scope field
values' means.=20

T5. The 'must', 'should', 'may' in the Security Considerations section
seem appropriate for RFC 2119 keywords capitalization. Please consider
this as a non-blocking comment.=20


E1. idnits complains about=20

** The document seems to lack a both a reference to RFC 2119 and the
     recommended RFC 2119 boilerplate, even if it appears to use RFC
2119
     keywords.=20

     RFC 2119, paragraph 2:
     "The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL
NOT",
      "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in
      this document are to be interpreted as described in RFC 2119."

This is probably because of a SHOULD left capitalized in the Security
Considerations section. Change it into a 'should' unless you decide to
follow the recommendations in T2 and T5.=20

E2. idnits points to potential problems in references. Please confirm if
this is what you intended, or updates are needed.=20

  Checking references for intended status: Informational
=20
------------------------------------------------------------------------
----

  =3D=3D Outdated reference: =
draft-ietf-ipfix-mediators-problem-statement
has
     been published as RFC 5982

  =3D=3D Outdated reference: A later version (-01) exists of
     draft-ietf-ipfix-psamp-mib-00

  -- Obsolete informational reference (is this intentional?): RFC 3280
     (Obsoleted by RFC 5280)

  -- Obsolete informational reference (is this intentional?): RFC 4346
     (Obsoleted by RFC 5246)

E3. Section 1:=20

s/To fulfill application requirements with limited system resources,
IPFIX architecture needs to introduce/To fulfill application
requirements with limited system resources, the IPFIX architecture needs
to introduce/=20

E4. Section 2:=20

s/The use of the terms "must", "should", and "may" in this document are
informational only/The use of the terms "must", "should", and "may" in
this document is informational only/

E5. what does 'binning' mean in the context of this document?=20

E6. Figure F: IPFIX Mediation Functional Block - should be either
'Blocks' or 'Block Diagram'

E7. in 5.3.2.3 s/describied/described/








From HKaplan@acmepacket.com  Tue Oct 12 06:12:59 2010
Return-Path: 
X-Original-To: ipfix@core3.amsl.com
Delivered-To: ipfix@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1741E3A696F for ; Tue, 12 Oct 2010 06:12:59 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.472
X-Spam-Level: 
X-Spam-Status: No, score=-2.472 tagged_above=-999 required=5 tests=[AWL=0.127,  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 RyTdGRr2J6UE for ; Tue, 12 Oct 2010 06:12:57 -0700 (PDT)
Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6]) by core3.amsl.com (Postfix) with ESMTP id 6A2303A6961 for ; Tue, 12 Oct 2010 06:12:56 -0700 (PDT)
Received: from mail.acmepacket.com (216.41.24.7) by etmail.acmepacket.com (216.41.24.6) with Microsoft SMTP Server (TLS) id 8.2.254.0; Tue, 12 Oct 2010 09:14:10 -0400
Received: from mail.acmepacket.com ([127.0.0.1]) by mail ([127.0.0.1]) with mapi; Tue, 12 Oct 2010 09:14:01 -0400
From: Hadriel Kaplan 
To: Gerhard Muenz 
Date: Tue, 12 Oct 2010 09:14:00 -0400
Thread-Topic: [IPFIX] semantics in structured-data: one of these things is not like the others
Thread-Index: ActqD1X0HCp7PeoFQ3aQSZlGTDUJEg==
Message-ID: 
References: <6854E01D-36B4-45B5-A2EB-45FC75C551C3@acmepacket.com> <4CB42936.2020208@net.in.tum.de>
In-Reply-To: <4CB42936.2020208@net.in.tum.de>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: IETF IPFIX Working Group 
Subject: Re: [IPFIX] semantics in structured-data: one of these things is not like the others
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, 12 Oct 2010 13:12:59 -0000

Hi Gerhard,
yes I'm not arguing against the need for "ordered" - I'm just saying it's a=
 different type of semantic than the others, and it's not clear they're exc=
lusive of each other.

-hadriel

On Oct 12, 2010, at 5:24 AM, Gerhard Muenz wrote:

>=20
> Hi Hadriel,
>=20
> IPFIX is not only about Flow Records. We also have Options data which
> needs to be exported.
>=20
> Semantic "Ordered" will be very helpful to describe a chain of IPFIX
> Mediators or a sequence of specific packet/flow treatments.
>=20
> Regards,
> Gerhard
>=20
>=20
> Hadriel Kaplan wrote:
>> Hi, I have a question on the "semantic" field in the structured-data
>> draft.  I apologize if this has been brought up before.
>>=20
>> ISTM the field is mixing-up/overloading two distinct types of
>> information, or I'm not understanding it right.  One is list field
>> *ordering* - whether the list's encoded order of members is
>> significant or not (ie, the "ordered" semantic value).  The other is
>> *applicability* - whether the lists members apply to the flow or not
>> (noneOf, exactlyOneOf, oneOrMoreOf, and allOf).
>>=20
>> So what is the *applicability* of an "ordered" list?  Presumably
>> allOf, right?  In other words, if a list is marked "ordered", do all
>> it's members apply to the flow?
>>=20
>> I ask because it's also possible for a list to have both a ordered
>> and noneOf semantic, or to have a ordered with oneOrMoreOf semantic.
>> For example, if you report an access control list that did not apply
>> to the flow, that's an ordered+noneOf.  Or if you report one that
>> does match the flow, that would arguably be an ordered+oneOrMoreOf.
>> You might want to think about making "ordered" a bit-flag of the
>> semantic field instead of one of the semantic enumerations.
>>=20
>> -hadriel
>>=20
> 


From trammell@tik.ee.ethz.ch  Tue Oct 12 06:20:46 2010
Return-Path: 
X-Original-To: ipfix@core3.amsl.com
Delivered-To: ipfix@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 10FC43A696F for ; Tue, 12 Oct 2010 06:20:45 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.512
X-Spam-Level: 
X-Spam-Status: No, score=-6.512 tagged_above=-999 required=5 tests=[AWL=0.087,  BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KXPE7DiAK4nn for ; Tue, 12 Oct 2010 06:20:43 -0700 (PDT)
Received: from smtp.ee.ethz.ch (smtp.ee.ethz.ch [129.132.2.219]) by core3.amsl.com (Postfix) with ESMTP id ED24D3A67EA for ; Tue, 12 Oct 2010 06:20:42 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by smtp.ee.ethz.ch (Postfix) with ESMTP id B98ADD939B; Tue, 12 Oct 2010 15:21:56 +0200 (MEST)
X-Virus-Scanned: by amavisd-new on smtp.ee.ethz.ch
Received: from smtp.ee.ethz.ch ([127.0.0.1]) by localhost (.ee.ethz.ch [127.0.0.1]) (amavisd-new, port 10024) with LMTP id PWGhR2HYNEiP; Tue, 12 Oct 2010 15:21:56 +0200 (MEST)
Received: from mac-10243.ethz.ch (mac-10243.ethz.ch [82.130.102.152]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: briant) by smtp.ee.ethz.ch (Postfix) with ESMTPSA id 8500DD936D; Tue, 12 Oct 2010 15:21:56 +0200 (MEST)
Mime-Version: 1.0 (Apple Message framework v1081)
Content-Type: text/plain; charset=us-ascii
From: Brian Trammell 
In-Reply-To: 
Date: Tue, 12 Oct 2010 15:21:56 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: 
References: <6854E01D-36B4-45B5-A2EB-45FC75C551C3@acmepacket.com> <4CB42936.2020208@net.in.tum.de> 
To: Hadriel Kaplan 
X-Mailer: Apple Mail (2.1081)
Cc: IETF IPFIX Working Group 
Subject: Re: [IPFIX] semantics in structured-data: one of these things is not like the others
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, 12 Oct 2010 13:20:46 -0000

Hi, Hadriel,

This came up in discussions a while ago. The tradeoff here was between =
the perfectly orthogonal situation - an infinite line of  n-ary =
decisions we can combine into a "semantics" vector, which we then hope =
to fit into an (odd) number of bytes (to fix the alignment poison we =
have to swallow when using varlen) i.e., an ordered flag, a set-negate =
flag, a how-many 2-bit field, etc, etc, which we could extend in the =
future - and something that would be relatively simple to cover the =
cases we could currently envision. As I recall, tacking ordered on here =
was a way to support an explicit ordering assertion with a minimum of =
complexity. Ordered implies allOf: ordered anyOf or oneOrMoreOf seem not =
to make sense except in really weird circumstances, and ordered noneOf =
not at all. Keep in mind that allOf is NOT necessary allOf unordered: =
allOf makes no ordering assertion at all, either way. Explicitly =
asserting non-ordering seems to be another one of those weird corner =
cases...

Cheers,

Brian


On Oct 12, 2010, at 3:14 PM, Hadriel Kaplan wrote:

>=20
> Hi Gerhard,
> yes I'm not arguing against the need for "ordered" - I'm just saying =
it's a different type of semantic than the others, and it's not clear =
they're exclusive of each other.
>=20
> -hadriel
>=20
> On Oct 12, 2010, at 5:24 AM, Gerhard Muenz wrote:
>=20
>>=20
>> Hi Hadriel,
>>=20
>> IPFIX is not only about Flow Records. We also have Options data which
>> needs to be exported.
>>=20
>> Semantic "Ordered" will be very helpful to describe a chain of IPFIX
>> Mediators or a sequence of specific packet/flow treatments.
>>=20
>> Regards,
>> Gerhard
>>=20
>>=20
>> Hadriel Kaplan wrote:
>>> Hi, I have a question on the "semantic" field in the structured-data
>>> draft.  I apologize if this has been brought up before.
>>>=20
>>> ISTM the field is mixing-up/overloading two distinct types of
>>> information, or I'm not understanding it right.  One is list field
>>> *ordering* - whether the list's encoded order of members is
>>> significant or not (ie, the "ordered" semantic value).  The other is
>>> *applicability* - whether the lists members apply to the flow or not
>>> (noneOf, exactlyOneOf, oneOrMoreOf, and allOf).
>>>=20
>>> So what is the *applicability* of an "ordered" list?  Presumably
>>> allOf, right?  In other words, if a list is marked "ordered", do all
>>> it's members apply to the flow?
>>>=20
>>> I ask because it's also possible for a list to have both a ordered
>>> and noneOf semantic, or to have a ordered with oneOrMoreOf semantic.
>>> For example, if you report an access control list that did not apply
>>> to the flow, that's an ordered+noneOf.  Or if you report one that
>>> does match the flow, that would arguably be an ordered+oneOrMoreOf.
>>> You might want to think about making "ordered" a bit-flag of the
>>> semantic field instead of one of the semantic enumerations.
>>>=20
>>> -hadriel
>>>=20
>> 
>=20
> _______________________________________________
> IPFIX mailing list
> IPFIX@ietf.org
> https://www.ietf.org/mailman/listinfo/ipfix


From HKaplan@acmepacket.com  Tue Oct 12 09:09:19 2010
Return-Path: 
X-Original-To: ipfix@core3.amsl.com
Delivered-To: ipfix@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1F0943A68D5 for ; Tue, 12 Oct 2010 09:09:19 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.473
X-Spam-Level: 
X-Spam-Status: No, score=-2.473 tagged_above=-999 required=5 tests=[AWL=0.126,  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 a5XruM8vxxBj for ; Tue, 12 Oct 2010 09:09:17 -0700 (PDT)
Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6]) by core3.amsl.com (Postfix) with ESMTP id 7D98A3A6990 for ; Tue, 12 Oct 2010 09:09:17 -0700 (PDT)
Received: from mail.acmepacket.com (216.41.24.7) by etmail.acmepacket.com (216.41.24.6) with Microsoft SMTP Server (TLS) id 8.2.254.0; Tue, 12 Oct 2010 12:10:31 -0400
Received: from mail.acmepacket.com ([127.0.0.1]) by mail ([127.0.0.1]) with mapi; Tue, 12 Oct 2010 12:10:09 -0400
From: Hadriel Kaplan 
To: Gerhard Muenz 
Date: Tue, 12 Oct 2010 12:10:07 -0400
Thread-Topic: [IPFIX] questions about structured-data draft
Thread-Index: ActqJ/BdnemjXdKyQ/OQcP5cI9CYZw==
Message-ID: <960B3942-7C11-4AEC-A85A-C3905FAAD684@acmepacket.com>
References: <646D5D04-3C32-4576-8925-550F3014B59E@acmepacket.com> <4CB42C81.3040305@net.in.tum.de>
In-Reply-To: <4CB42C81.3040305@net.in.tum.de>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: IETF IPFIX Working Group 
Subject: Re: [IPFIX] questions about structured-data draft
X-BeenThere: ipfix@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: IPFIX WG discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 12 Oct 2010 16:09:19 -0000

Hi Gerhard,
with regards to the below, yes I gathered the context of the Data Record ha=
s to be known in advance (or rather, the ipfix-reader needs to generally kn=
ow what's going on), but that wasn't my point. =20

Let's assume all the exporters in a given deployment are purely flow inform=
ation exporters, reporting on IP flows.  But it's a mix of vendors.  Vendor=
 X reports multicast information as shown/described in the current structur=
ed-draft, using a basicList of egressInterface.  Vendor Y reports that the =
flow is egressing an ATM IMA bundle, by using a basicList of egressInterfac=
e.  Vendor Z reports that the flow is being mirrored on one or more span po=
rts, by using a basicList of egressInterface.  To the collector, all the re=
ports look the same.

I think the rationale for this is that the structured data is not changing =
or adding to the meaning of the individual IEs within the structure - it's =
not making a new data type out of the collection of IEs within it.  In othe=
r words, the draft should NOT describe a basicList of egressInterface as "m=
ulticast" info, because it's not "multicast" - it's just a list of egressIn=
terface.  No additional information is conveyed beyond that.  On the other =
hand, if we go create a new IE named "multicastEgressList" of type basicLis=
t, then that conveys it.

I know that sounds kinda nit-picky, but when I read the draft I really got =
the impression I could create/report new info by using the generic structur=
ed data.

-hadriel


On Oct 12, 2010, at 5:38 AM, Gerhard Muenz wrote:

> Hadriel Kaplan wrote:
>> 2) Along that same line of thought, encoding the structures as done
>> in this draft seems to lose the type information of the list itself.
>> It has to be inferred, which is failure-prone.  For example, suppose
>> you report a list of the ACL the flow matches, as well as a list of
>> the packet's source IP headers (it could be a list if it's IP-in-IP
>> or IPsec tunnel mode).  The ACL may be just a basicList of
>> sourceIPv4Address, as would the IP-in-IP list.  How does the ipfix
>> collector/reader know which is which?  What if vendor X records the
>> ACL first and the IP-in-IP second, while vendor Y does the opposite?
>> Or vendor X may only report ACLs while vendor Y only reports
>> IP-in-IP, but their reports look identical.  Or for another example,
>> the draft talks about a multicast list being a list of
>> egressInterfaces.  But how does the ipfix reader know that a list of
>> egress interfaces is a "multicast" list and not a list of aggregated
>> interfaces, or span ports?  The problem is these lists have no type.
>> They're just lists of types.  Anytime two lists of different purposes
>> happen to use the same member types there's a collision.  Or am I
>> missing something? (could easily be)
>=20
> Without any context information, the Collector will never know how to
> interpret a Data Record.
>=20
> For example, even if it looks like a Flow Record, it might be an PSAMP
> Packet Report (unless a counter fields exists indicating that there is
> more than one packet).
>=20
> To some extend, context information can be exported in a standardized
> way using Options, e.g. to describe the Metering Process. But there are
> limitations.
>=20
> My understanding is that IPFIX does not aim at exporting all kinds
> context information because IPFIX will be implemented in environments
> where you know what kind of device the Exporter is. So, you can assume
> that a certain context is given so that the Collector is able to
> interpret the exported data.


From dromasca@avaya.com  Thu Oct 14 11:44:45 2010
Return-Path: 
X-Original-To: ipfix@core3.amsl.com
Delivered-To: ipfix@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 24E203A6AC2 for ; Thu, 14 Oct 2010 11:44:45 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.517
X-Spam-Level: 
X-Spam-Status: No, score=-102.517 tagged_above=-999 required=5 tests=[AWL=0.082, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4gwH2zoGUBqC for ; Thu, 14 Oct 2010 11:44:43 -0700 (PDT)
Received: from p-us1-iereast-outbound-tmp.us1.avaya.com (p-us1-iereast-outbound-tmp.us1.avaya.com [135.11.29.16]) by core3.amsl.com (Postfix) with ESMTP id 074B23A69C4 for ; Thu, 14 Oct 2010 11:44:42 -0700 (PDT)
X-IronPort-AV: E=Sophos;i="4.57,331,1283745600"; d="scan'208";a="39081505"
Received: from unknown (HELO p-us1-erheast.us1.avaya.com) ([135.11.50.53]) by p-us1-iereast-outbound-tmp.us1.avaya.com with ESMTP; 14 Oct 2010 14:46:02 -0400
X-IronPort-AV: E=Sophos;i="4.57,331,1283745600"; d="scan'208";a="523004765"
Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.12]) by p-us1-erheast-out.us1.avaya.com with ESMTP; 14 Oct 2010 14:45:27 -0400
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Date: Thu, 14 Oct 2010 20:45:11 +0200
Message-ID: 
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: AD review on draft-ietf-ipfix-anon-04.txt
Thread-Index: Actrz+55LtoTJoOqTluVbszGLA9VUg==
From: "Romascanu, Dan (Dan)" 
To: "IPFIX Working Group" 
Subject: [IPFIX] AD review on draft-ietf-ipfix-anon-04.txt
X-BeenThere: ipfix@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: IPFIX WG discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 14 Oct 2010 18:44:45 -0000

Please find below the AD review of draft-ietf-ipfix-anon-04.txt. The
document is in quite good shape, however, there are a number of issued
that I suggest should be resolved by a revised ID before proceeding to
IETF Last Call.=20

Comments are marked T for Technical and E for Editorial.=20

T1. Section 4.2 - MAC Address Anonymisation

   Beyond
   this, the address is unstructured, and there is no particular
   relationship among the OUIs assigned to a given vendor.

This is not completely true. Actually some vendors keep a structure of
the OUIs (per family of products for example) or the relative values of
the OUIs may indicate a time relation. I suggest s/particular/standard/

T2. Same section.

It is not clear for me why the Truncation was not included as a scheme
for Anonymisation of MAC addresses. I actually believe that it can be
quite significant as the first 24 bits of an EUI-48 address provides
vendor information.=20

T3. Section 4.2.1=20

   Also note that the utility or removing
   manufacturer information is dubious, and not particularly well-
   covered by the literature.

I would argue against the 'dubious' characterization. Actually the
information may be important and need to be anonymized.=20

T4. In sections 5.3, 5.4, 5.5 the last phrase in each paragraph  that
makes recommendations about limiting exported information of various
sorts should be rephrased using 2119 capitalized SHOULD or SHOULD NOT

T5. Section 7.2.3 -=20

   Anonymisation of timestamps and the Export Time header field should
   take care to avoid times too far in the past or future

Please rephrase - header fields do not 'take care' of anything :-). Also
usage of 2119 capitalized keywords seems in place here.=20

T6. Section 7.2.4=20

   care should be taken while using
   them with anonymised data export and storage.

What does this exactly mean? Please rephrase, possibly using 2119
capitalized keywords.=20

T7. Same section

   care
   must be taken to ensure that Options described by this template are
   written using the anonymised timestamps instead of the original ones.

Please rephrase, possibly using 2119 capitalized keywords.=20

T8. Section 7.2.5

   When anonymising data for transport or storage using IPFIX containing
   anonymised IP addresses, and the analysis purpose permits doing so,
   it is recommended to filter out or leave unanonymised data containing

Using 2119 RECOMMENDED seems appropriate.=20


T9. Section 7.2.6

   The general ground rule is that information of similar type
   to that anonymised should not be made available to the receiver by
   any means, whether in the Data Records, in IPFIX protocol structures
   such as Message Headers, or out-of-band.

Using 2119 RECOMMENDED seems appropriate.=20



E1. Section 4.3.2 - please expand QoS and SLA at first occurrence

E2. Section 5.2.1 - in the first phrase that defines stability s/a
single given/the same given/

E3. Figure 3 - please expand FR, FW, EP, etc.=20


Thanks and Regards,

Dan





From n.brownlee@auckland.ac.nz  Sun Oct 17 18:41:10 2010
Return-Path: 
X-Original-To: ipfix@core3.amsl.com
Delivered-To: ipfix@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3CB4C3A6A63 for ; Sun, 17 Oct 2010 18:41:10 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -103.01
X-Spam-Level: 
X-Spam-Status: No, score=-103.01 tagged_above=-999 required=5 tests=[AWL=0.589, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DIdg6PmvmMsw for ; Sun, 17 Oct 2010 18:41:08 -0700 (PDT)
Received: from mx2-int.auckland.ac.nz (mx2-int.auckland.ac.nz [130.216.12.41]) by core3.amsl.com (Postfix) with ESMTP id F388A3A67FA for ; Sun, 17 Oct 2010 18:41:06 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=auckland.ac.nz; i=n.brownlee@auckland.ac.nz; q=dns/txt; s=uoa; t=1287366156; x=1318902156; h=message-id:date:from:mime-version:to:subject: content-transfer-encoding; z=Message-ID:=20<4CBBA607.7080404@auckland.ac.nz>|Date:=20 Mon,=2018=20Oct=202010=2014:42:31=20+1300|From:=20Nevil =20Brownlee=20|MIME-Version: =201.0|To:=20IPFIX=20Working=20Group=20 |Subject:=20Two=20WGLCs=20starting=20now |Content-Transfer-Encoding:=207bit; bh=lQprNgJw7h1iwajlQ5pz+530C+3VDVhZlfUA//duVBU=; b=Be63lWLf+YfMmfSIPtg256A4K0mw3cKHIHpiGpkZKgXxnkG1iqN1QCjY YszoEK3cyId6FhHidpQjg4BGdhGFe2ghGiv8+SBdfpzv8Vhju3MyV4xr9 QmpgCkafDHzc/kmbZz+erXPZCLt7xWfPDpVm34IKJcwwzNiqymKO+ouIH o=;
X-IronPort-AV: E=Sophos;i="4.57,344,1283688000"; d="scan'208";a="31680858"
X-Ironport-HAT: UNIVERSITY - $RELAY-THROTTLE
X-Ironport-Source: 130.216.38.131 - Outgoing - Outgoing-SSL
Received: from nevil-laptop1.sfac.auckland.ac.nz (HELO [130.216.38.131]) ([130.216.38.131]) by mx2-int.auckland.ac.nz with ESMTP; 18 Oct 2010 14:42:32 +1300
Message-ID: <4CBBA607.7080404@auckland.ac.nz>
Date: Mon, 18 Oct 2010 14:42:31 +1300
From: Nevil Brownlee 
User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.9) Gecko/20100915 Lightning/1.0b2 Thunderbird/3.1.4
MIME-Version: 1.0
To: IPFIX Working Group 
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Subject: [IPFIX] Two WGLCs starting now
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, 18 Oct 2010 01:41:10 -0000

Hi all:

We have two drafts waiting for Working Group Last Call.
Their WGLCs start now, and will finish on 3 November (the
Wednesday before the Beijing IETF).

The drafts are:
  1. draft-ietf-ipfix-structured-data-03.txt
        Second WGLC for this draft, the first was back in July
        for the -01 version.  There's been a *lot* of discussion
        on the mailing list since!)
  2. draft-ietf-ipfix-configuration-model-07.txt
        We were waiting for the YANG RFCs to be published for this one.

Cheers, Nevil  (IPFIX co-chair)

-- 
---------------------------------------------------------------------
  Nevil Brownlee                    Computer Science Department | ITS
  Phone: +64 9 373 7599 x88941             The University of Auckland
  FAX: +64 9 373 7453   Private Bag 92019, Auckland 1142, New Zealand

From trammell@tik.ee.ethz.ch  Sun Oct 17 23:39:20 2010
Return-Path: 
X-Original-To: ipfix@core3.amsl.com
Delivered-To: ipfix@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 698953A6874 for ; Sun, 17 Oct 2010 23:39:20 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.599
X-Spam-Level: 
X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aItrTaL4ATcQ for ; Sun, 17 Oct 2010 23:39:19 -0700 (PDT)
Received: from smtp.ee.ethz.ch (smtp.ee.ethz.ch [129.132.2.219]) by core3.amsl.com (Postfix) with ESMTP id 71A4C3A6C58 for ; Sun, 17 Oct 2010 23:39:14 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by smtp.ee.ethz.ch (Postfix) with ESMTP id DD8ABD93B1; Mon, 18 Oct 2010 08:40:27 +0200 (MEST)
X-Virus-Scanned: by amavisd-new on smtp.ee.ethz.ch
Received: from smtp.ee.ethz.ch ([127.0.0.1]) by localhost (.ee.ethz.ch [127.0.0.1]) (amavisd-new, port 10024) with LMTP id kvkf1giespOr; Mon, 18 Oct 2010 08:40:27 +0200 (MEST)
Received: from [192.168.0.188] (77-57-164-35.dclient.hispeed.ch [77.57.164.35]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: briant) by smtp.ee.ethz.ch (Postfix) with ESMTPSA id 7040BD9384; Mon, 18 Oct 2010 08:40:27 +0200 (MEST)
Mime-Version: 1.0 (Apple Message framework v1081)
Content-Type: text/plain; charset=us-ascii
From: Brian Trammell 
In-Reply-To: 
Date: Mon, 18 Oct 2010 08:40:26 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: <3F070565-6355-499B-B768-A76212988E0F@tik.ee.ethz.ch>
References: 
To: "Romascanu, Dan (Dan)" 
X-Mailer: Apple Mail (2.1081)
Cc: IPFIX Working Group 
Subject: Re: [IPFIX] AD review on draft-ietf-ipfix-anon-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: Mon, 18 Oct 2010 06:39:20 -0000

Hi, Dan,

Thanks for your review. We've prepared a -05, ready for submission after =
a final editorial pass. Comments on comments inline.

On Oct 14, 2010, at 8:45 PM, Romascanu, Dan (Dan) wrote:

> Please find below the AD review of draft-ietf-ipfix-anon-04.txt. The
> document is in quite good shape, however, there are a number of issued
> that I suggest should be resolved by a revised ID before proceeding to
> IETF Last Call.=20
>=20
> Comments are marked T for Technical and E for Editorial.=20
>=20
> T1. Section 4.2 - MAC Address Anonymisation
>=20
>   Beyond
>   this, the address is unstructured, and there is no particular
>   relationship among the OUIs assigned to a given vendor.
>=20
> This is not completely true. Actually some vendors keep a structure of
> the OUIs (per family of products for example) or the relative values =
of
> the OUIs may indicate a time relation. I suggest =
s/particular/standard/

Good point, thanks.

> T2. Same section.
>=20
> It is not clear for me why the Truncation was not included as a scheme
> for Anonymisation of MAC addresses. I actually believe that it can be
> quite significant as the first 24 bits of an EUI-48 address provides
> vendor information.=20

Removing vendor information would be served by reverse truncation. =
Normal truncation would remove information about the individual nodes =
(which may be preserved through IP addresses, for example) while =
preserving vendor information (which may have specific utility when =
researching vendor-specific phenomena). More discussion of these issues =
in the document wouldn't hurt in any event. Done.

> T3. Section 4.2.1=20
>=20
>   Also note that the utility or removing
>   manufacturer information is dubious, and not particularly well-
>   covered by the literature.
>=20
> I would argue against the 'dubious' characterization. Actually the
> information may be important and need to be anonymized.=20

Point taken. I would actually (on review) argue against calling it =
dubious in an RFC, even if it were. But it's certainly not well-covered =
by the literature. :) Fixed.

> T4. In sections 5.3, 5.4, 5.5 the last phrase in each paragraph  that
> makes recommendations about limiting exported information of various
> sorts should be rephrased using 2119 capitalized SHOULD or SHOULD NOT
>=20
> T5. Section 7.2.3 -=20
>=20
>   Anonymisation of timestamps and the Export Time header field should
>   take care to avoid times too far in the past or future
>=20
> Please rephrase - header fields do not 'take care' of anything :-). =
Also
> usage of 2119 capitalized keywords seems in place here.=20
>=20
> T6. Section 7.2.4=20
>=20
>   care should be taken while using
>   them with anonymised data export and storage.
>=20
> What does this exactly mean? Please rephrase, possibly using 2119
> capitalized keywords.=20
>=20
> T7. Same section
>=20
>   care
>   must be taken to ensure that Options described by this template are
>   written using the anonymised timestamps instead of the original =
ones.
>=20
> Please rephrase, possibly using 2119 capitalized keywords.=20
>=20
> T8. Section 7.2.5
>=20
>   When anonymising data for transport or storage using IPFIX =
containing
>   anonymised IP addresses, and the analysis purpose permits doing so,
>   it is recommended to filter out or leave unanonymised data =
containing
>=20
> Using 2119 RECOMMENDED seems appropriate.=20
>=20
>=20
> T9. Section 7.2.6
>=20
>   The general ground rule is that information of similar type
>   to that anonymised should not be made available to the receiver by
>   any means, whether in the Data Records, in IPFIX protocol structures
>   such as Message Headers, or out-of-band.
>=20
> Using 2119 RECOMMENDED seems appropriate.=20

Points on rephrasing and 2119 lanugage are taken; edited.

> E1. Section 4.3.2 - please expand QoS and SLA at first occurrence
>=20
> E2. Section 5.2.1 - in the first phrase that defines stability s/a
> single given/the same given/

The suggested correction reads to me as if there's no anonymisation at =
all. However, the present phrasing is also a little confusing. How about =
s/a single given/a given/ here?

> E3. Figure 3 - please expand FR, FW, EP, etc.=20

Done, in the introductory text.

Thanks again, best regards,

Brian=

From trammell@tik.ee.ethz.ch  Mon Oct 18 00:20:03 2010
Return-Path: 
X-Original-To: ipfix@core3.amsl.com
Delivered-To: ipfix@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6FBE33A6BAE for ; Mon, 18 Oct 2010 00:20:03 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.22
X-Spam-Level: 
X-Spam-Status: No, score=-4.22 tagged_above=-999 required=5 tests=[AWL=-2.380,  BAYES_20=-0.74, J_CHICKENPOX_52=0.6, MANGLED_PENIS=2.3, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TWCZLRC5OQdh for ; Mon, 18 Oct 2010 00:19:59 -0700 (PDT)
Received: from smtp.ee.ethz.ch (smtp.ee.ethz.ch [129.132.2.219]) by core3.amsl.com (Postfix) with ESMTP id 36AC33A6CAD for ; Mon, 18 Oct 2010 00:19:59 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by smtp.ee.ethz.ch (Postfix) with ESMTP id 2092CD938C; Mon, 18 Oct 2010 09:21:26 +0200 (MEST)
X-Virus-Scanned: by amavisd-new on smtp.ee.ethz.ch
Received: from smtp.ee.ethz.ch ([127.0.0.1]) by localhost (.ee.ethz.ch [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 5Il+8JocF69t; Mon, 18 Oct 2010 09:21:25 +0200 (MEST)
Received: from [192.168.0.188] (77-57-164-35.dclient.hispeed.ch [77.57.164.35]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: briant) by smtp.ee.ethz.ch (Postfix) with ESMTPSA id D467CD936B; Mon, 18 Oct 2010 09:21:24 +0200 (MEST)
Mime-Version: 1.0 (Apple Message framework v1081)
Content-Type: text/plain; charset=us-ascii
From: Brian Trammell 
In-Reply-To: <7A6C26A5-FC0E-466F-A1FE-D7E63271FE61@acmepacket.com>
Date: Mon, 18 Oct 2010 09:21:24 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: 
References: <20101001120148.9042B3A74D4@core3.amsl.com> <6A7213D7-64ED-4D3B-AD8D-CBAD105F21B5@tik.ee.ethz.ch> <8FC4E1A0-0FCF-46A7-BDF2-AA3E2D21227D@acmepacket.com>  <7A6C26A5-FC0E-466F-A1FE-D7E63271FE61@acmepacket.com>
To: Hadriel Kaplan 
X-Mailer: Apple Mail (2.1081)
Cc: "ipfix@ietf.org Group" 
Subject: Re: [IPFIX] Fwd: New Version Notification for draft-trammell-ipfix-ie-doctors-00
X-BeenThere: ipfix@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: IPFIX WG discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 18 Oct 2010 07:20:04 -0000

Hi, Hadriel,

Comments per tradition inline...

On Oct 8, 2010, at 9:27 PM, Hadriel Kaplan wrote:

>=20
> Hi Brian,
> comments inline...
>=20
> On Oct 8, 2010, at 2:39 AM, Brian Trammell wrote:
>=20
>> Hi, Hadriel,
>>=20
>> Thanks for the feedback.
>>=20
>> The primary design goal of the IESpec format is human readability in =
the expression of information model extensions and templates, while =
maintaining simple machine readability. The idea is implementors can =
read an Internet Draft about an IPFIX application with example templates =
in IESpec form, copy and paste the example templates out of it into an =
implementation supporting IEspec, fill in the fields and go.
>=20
> At the end of the day what we're talking about is a form of a =
"dictionary" file, similar to those used for other protocols, like for =
SNMP, DIAMETER, RADIUS, etc.  Right?  Like not just for putting into a =
RFC, but more importantly for importing into a reader so it can decode =
and understand the IEs, right?

There are two orthogonal dimensions here, on both of which we're getting =
confused... First there's the human-readable versus machine-readable =
issue, then the dictionary (Information Model) version template issue. =
On reflection, the primary application for iespec (and therefore the =
reason to include it in iedoctors) is human-readable templates with easy =
machine readability.

As a dictionary file, it's basically a human-editable subset of 5610, =
and as such only useful for the  and name information. But as a =
dictionary, the IANA registry is of course far preferable. So if the =
collector device is capable of doing so, I'd recommend downloading the =
IANA registry and parsing it at boot or pre-parsing it (maybe into 5610) =
 once per fortnight or so. As long as I don't have to _hand edit_ the =
IANA XML, I'm happy.

> Again, I'm not a big fan of XML, but there are a ton of XML parser =
libraries available, and the importing of that into a reader so it can =
understand the new IEs is done rarely, and with a CPU (not an FPGA or =
network processor).  Libraries exist to not only read them, but verify =
their correctness using a schema.  Further, they support comments and =
text descriptions, which are useful for an IPFIX reader importing them.  =
An IPFIX reader can use those to display in a GUI as additional help, =
and a human can use them to understand stuff when he/she reads the XML. =20=

>=20
> For example, suppose vendor BigCorp wants to give out such a =
"dictionary" file for some PEN IEs its BigBox generates, so that IPFIX =
Readers can decode them.  One of those PEN IEs is for a "camFlowId".  In =
IESpec, it might be:
> camFlowId(35566/123)[4]
>=20
> That doesn't tell the human nor the IPFIX collector/reader much info.  =
In XML it's a lot longer text, but it can include some more info like =
this:
>       
>         
>           An identifier of a single Content Addressable Memory index =
allocated for the flow.  Two CAM entries are allocated, for each =
direction, unless the system is provisioned otherwise.
>         
>       
>       
>         
>         See BigCorp User Manual chapter titled "Hardware Resources" =
for more information.
>         
>       
>=20
> And the file can even have a "<-- BigCorp dictionary file for BigCorp =
BigBox 10000 System, version 1.2.3. Created 2-10-2010 -->" comment at =
the top.
>=20
>=20
>=20
>> For readability and compactness, it's intended to address =
shortcomings both in the XML format(s) already defined for IPFIX IEs
>=20
> What shortcomings?  There're some fields I think it should have that =
it doesn't, and the structure of it is weird, but  I'm a nitpicker.  Is =
there something fatally wrong with it?

Eyeball-parsing the XML formats for dictionary purposes is daunting, and =
they're not at all adaptable to easily readable templates. Fortunately, =
IANA has the eyeball parsing problem fixed,=20

>> and in the traditional 32-bit-wide box-and-line diagrams, which make =
it difficult to fit a nontrivial template onto a single page, and =
require some manual work to turn into an implementation.
>=20
> This is one of the things I was worried about - that we would be =
saying this would avoid showing things in 32-bit-wide box-and-line =
diagrams.  I find those drawings are really, really useful.  For =
example, I couldn't make heads or tails of the structured-data draft =
until I saw those examples. =20

The thing is, they're useful primarily when describing the _framing_ of =
the protocol. Here's what a template looks like. Here's what a message =
looks like. Given a template, here's a record. Structured data is =
defining new _types_, with internal structure, and displaying that =
structure. Of course we need 32-bit box and line diagrams in that case. =
With respect to simple applications of IPFIX, just defining a new =
template doesn't change the framing. But I hadn't considered the =
possibility that I'm old and jaded, and that everyone else enjoys seeing =
the same boxes I'm getting bored with. :) So that's a valid argument =
against more compact templates in drafts...

The structured-data heirarchy extensions for IEspecs are meant to =
illustrate applications of structured-data, not the framing thereof. But =
there's a very valid point here -- structured-data is new enough that we =
really probably _do_ want to draw things out explicitly the first few =
times we use it.

> Fitting them on a page is not a serious issue really, is it?  I mean =
if it crosses pages, people can deal. =20

A thirty-element template (not unthinkable) crosses two pages. At some =
point there's a tradeoff between verbosity for clarity and so much =
verbosity that you need to tape things to the wall to have any hope of =
seeing what's going on.=20

> I know it takes more work to draw them, but you're writing an RFC for =
others to be able to interop with you, so that's life.  If a nontrivial =
template is difficult to draw, maybe that will encourage people to not =
make complicated templates. :)  I'm half joking, but my point is the =
work to write the RFC is really moot compared to helping people reading =
the RFC implementing it right. =20

I chose the word "non-trivial" poorly -- there's not really a complexity =
continuum in templates, it's either "long" or "short". It's hard to draw =
_long_ templates, and it's a bad idea to encourage people to use short =
templates when what they need is a long one. :)

The reason to reduce the amount of work to write an RFC, though, is not =
to make _my_ life easier. It's to make it easier for IPFIX _non_-experts =
to write RFCs describing new applications. Less work, and less chance of =
making a mistake leading to ambiguity, means better, more readable, more =
quickly and easily edited and published RFCs.

Regards,

Brian=

From dromasca@avaya.com  Mon Oct 18 02:07:44 2010
Return-Path: 
X-Original-To: ipfix@core3.amsl.com
Delivered-To: ipfix@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DE1943A6B13 for ; Mon, 18 Oct 2010 02:07:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.518
X-Spam-Level: 
X-Spam-Status: No, score=-102.518 tagged_above=-999 required=5 tests=[AWL=0.081, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XL2vou7cvLNY for ; Mon, 18 Oct 2010 02:07:43 -0700 (PDT)
Received: from p-us1-iereast-outbound-tmp.us1.avaya.com (nj300815-nj-outbound.net.avaya.com [135.11.29.16]) by core3.amsl.com (Postfix) with ESMTP id 69ED93A68BC for ; Mon, 18 Oct 2010 02:07:43 -0700 (PDT)
X-IronPort-AV: E=Sophos;i="4.57,345,1283745600"; d="scan'208";a="39462220"
Received: from unknown (HELO p-us1-erheast.us1.avaya.com) ([135.11.50.53]) by p-us1-iereast-outbound-tmp.us1.avaya.com with ESMTP; 18 Oct 2010 05:09:10 -0400
X-IronPort-AV: E=Sophos;i="4.57,345,1283745600"; d="scan'208";a="523890902"
Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.12]) by p-us1-erheast-out.us1.avaya.com with ESMTP; 18 Oct 2010 05:08:35 -0400
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Date: Mon, 18 Oct 2010 11:08:33 +0200
Message-ID: 
In-Reply-To: <3F070565-6355-499B-B768-A76212988E0F@tik.ee.ethz.ch>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [IPFIX] AD review on draft-ietf-ipfix-anon-04.txt
Thread-Index: Actuj2Ny9o3+faPaQhGZ9HeH6pO/bgAFJO0w
References:  <3F070565-6355-499B-B768-A76212988E0F@tik.ee.ethz.ch>
From: "Romascanu, Dan (Dan)" 
To: "Brian Trammell" 
Cc: IPFIX Working Group 
Subject: Re: [IPFIX] AD review on draft-ietf-ipfix-anon-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: Mon, 18 Oct 2010 09:07:45 -0000

Thanks, Brian. Please submit.=20

Regards,

Dan
=20

> -----Original Message-----
> From: Brian Trammell [mailto:trammell@tik.ee.ethz.ch]=20
> Sent: Monday, October 18, 2010 8:40 AM
> To: Romascanu, Dan (Dan)
> Cc: IPFIX Working Group
> Subject: Re: [IPFIX] AD review on draft-ietf-ipfix-anon-04.txt
>=20
> Hi, Dan,
>=20
> Thanks for your review. We've prepared a -05, ready for=20
> submission after a final editorial pass. Comments on comments inline.
>=20
> On Oct 14, 2010, at 8:45 PM, Romascanu, Dan (Dan) wrote:
>=20
> > Please find below the AD review of=20
> draft-ietf-ipfix-anon-04.txt. The=20
> > document is in quite good shape, however, there are a=20
> number of issued=20
> > that I suggest should be resolved by a revised ID before=20
> proceeding to=20
> > IETF Last Call.
> >=20
> > Comments are marked T for Technical and E for Editorial.=20
> >=20
> > T1. Section 4.2 - MAC Address Anonymisation
> >=20
> >   Beyond
> >   this, the address is unstructured, and there is no particular
> >   relationship among the OUIs assigned to a given vendor.
> >=20
> > This is not completely true. Actually some vendors keep a=20
> structure of=20
> > the OUIs (per family of products for example) or the=20
> relative values=20
> > of the OUIs may indicate a time relation. I suggest=20
> > s/particular/standard/
>=20
> Good point, thanks.
>=20
> > T2. Same section.
> >=20
> > It is not clear for me why the Truncation was not included=20
> as a scheme=20
> > for Anonymisation of MAC addresses. I actually believe that=20
> it can be=20
> > quite significant as the first 24 bits of an EUI-48 address=20
> provides=20
> > vendor information.
>=20
> Removing vendor information would be served by reverse=20
> truncation. Normal truncation would remove information about=20
> the individual nodes (which may be preserved through IP=20
> addresses, for example) while preserving vendor information=20
> (which may have specific utility when researching=20
> vendor-specific phenomena). More discussion of these issues=20
> in the document wouldn't hurt in any event. Done.
>=20
> > T3. Section 4.2.1
> >=20
> >   Also note that the utility or removing
> >   manufacturer information is dubious, and not particularly well-
> >   covered by the literature.
> >=20
> > I would argue against the 'dubious' characterization. Actually the=20
> > information may be important and need to be anonymized.
>=20
> Point taken. I would actually (on review) argue against=20
> calling it dubious in an RFC, even if it were. But it's=20
> certainly not well-covered by the literature. :) Fixed.
>=20
> > T4. In sections 5.3, 5.4, 5.5 the last phrase in each=20
> paragraph  that=20
> > makes recommendations about limiting exported information=20
> of various=20
> > sorts should be rephrased using 2119 capitalized SHOULD or=20
> SHOULD NOT
> >=20
> > T5. Section 7.2.3 -
> >=20
> >   Anonymisation of timestamps and the Export Time header=20
> field should
> >   take care to avoid times too far in the past or future
> >=20
> > Please rephrase - header fields do not 'take care' of anything :-).=20
> > Also usage of 2119 capitalized keywords seems in place here.
> >=20
> > T6. Section 7.2.4
> >=20
> >   care should be taken while using
> >   them with anonymised data export and storage.
> >=20
> > What does this exactly mean? Please rephrase, possibly using 2119=20
> > capitalized keywords.
> >=20
> > T7. Same section
> >=20
> >   care
> >   must be taken to ensure that Options described by this=20
> template are
> >   written using the anonymised timestamps instead of the=20
> original ones.
> >=20
> > Please rephrase, possibly using 2119 capitalized keywords.=20
> >=20
> > T8. Section 7.2.5
> >=20
> >   When anonymising data for transport or storage using=20
> IPFIX containing
> >   anonymised IP addresses, and the analysis purpose permits=20
> doing so,
> >   it is recommended to filter out or leave unanonymised data=20
> > containing
> >=20
> > Using 2119 RECOMMENDED seems appropriate.=20
> >=20
> >=20
> > T9. Section 7.2.6
> >=20
> >   The general ground rule is that information of similar type
> >   to that anonymised should not be made available to the receiver by
> >   any means, whether in the Data Records, in IPFIX protocol=20
> structures
> >   such as Message Headers, or out-of-band.
> >=20
> > Using 2119 RECOMMENDED seems appropriate.=20
>=20
> Points on rephrasing and 2119 lanugage are taken; edited.
>=20
> > E1. Section 4.3.2 - please expand QoS and SLA at first occurrence
> >=20
> > E2. Section 5.2.1 - in the first phrase that defines stability s/a=20
> > single given/the same given/
>=20
> The suggested correction reads to me as if there's no=20
> anonymisation at all. However, the present phrasing is also a=20
> little confusing. How about s/a single given/a given/ here?
>=20
> > E3. Figure 3 - please expand FR, FW, EP, etc.=20
>=20
> Done, in the introductory text.
>=20
> Thanks again, best regards,
>=20
> Brian
>=20

From rahulp@cisco.com  Mon Oct 18 07:27:24 2010
Return-Path: 
X-Original-To: ipfix@core3.amsl.com
Delivered-To: ipfix@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F1D463A6AED for ; Mon, 18 Oct 2010 07:27:23 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.289
X-Spam-Level: 
X-Spam-Status: No, score=-10.289 tagged_above=-999 required=5 tests=[AWL=0.310, 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 xJ2XT39PS+3B for ; Mon, 18 Oct 2010 07:27:23 -0700 (PDT)
Received: from rtp-iport-1.cisco.com (rtp-iport-1.cisco.com [64.102.122.148]) by core3.amsl.com (Postfix) with ESMTP id 080573A6A09 for ; Mon, 18 Oct 2010 07:27:22 -0700 (PDT)
Authentication-Results: rtp-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AvsEAAP3u0ytJV2Z/2dsb2JhbAChLHGhbpwzAoVHBIRUiQGIHg
X-IronPort-AV: E=Sophos;i="4.57,345,1283731200"; d="scan'208";a="171842112"
Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by rtp-iport-1.cisco.com with ESMTP; 18 Oct 2010 14:28:36 +0000
Received: from xbh-rcd-202.cisco.com (xbh-rcd-202.cisco.com [72.163.62.201]) by rcdn-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id o9IESafs029253;  Mon, 18 Oct 2010 14:28:36 GMT
Received: from xmb-rcd-213.cisco.com ([72.163.62.220]) by xbh-rcd-202.cisco.com with Microsoft SMTPSVC(6.0.3790.4675);  Mon, 18 Oct 2010 09:28:36 -0500
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Date: Mon, 18 Oct 2010 09:28:35 -0500
Message-ID: 
In-Reply-To: <4CBBA607.7080404@auckland.ac.nz>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [IPFIX] Two WGLCs starting now
Thread-Index: ActuZcCqGy01X6naQ7mHfgX42wDAMAAauHaQ
References: <4CBBA607.7080404@auckland.ac.nz>
From: "Rahul Patel (rahulp)" 
To: "Nevil Brownlee" , "IPFIX Working Group" 
X-OriginalArrivalTime: 18 Oct 2010 14:28:36.0404 (UTC) FILETIME=[C005A740:01CB6ED0]
Subject: Re: [IPFIX] Two WGLCs starting now
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, 18 Oct 2010 14:27:24 -0000

I approve the new version (draft-ietf-ipfix-structured-data-03.txt).

-Rahul


> -----Original Message-----
> From: ipfix-bounces@ietf.org [mailto:ipfix-bounces@ietf.org] On Behalf
Of
> Nevil Brownlee
> Sent: Sunday, October 17, 2010 9:43 PM
> To: IPFIX Working Group
> Subject: [IPFIX] Two WGLCs starting now
> Importance: Low
>=20
>=20
> Hi all:
>=20
> We have two drafts waiting for Working Group Last Call.
> Their WGLCs start now, and will finish on 3 November (the
> Wednesday before the Beijing IETF).
>=20
> The drafts are:
>   1. draft-ietf-ipfix-structured-data-03.txt
>         Second WGLC for this draft, the first was back in July
>         for the -01 version.  There's been a *lot* of discussion
>         on the mailing list since!)
>   2. draft-ietf-ipfix-configuration-model-07.txt
>         We were waiting for the YANG RFCs to be published for this
one.
>=20
> Cheers, Nevil  (IPFIX co-chair)
>=20
> --
> ---------------------------------------------------------------------
>   Nevil Brownlee                    Computer Science Department | ITS
>   Phone: +64 9 373 7599 x88941             The University of Auckland
>   FAX: +64 9 373 7453   Private Bag 92019, Auckland 1142, New Zealand
> _______________________________________________
> IPFIX mailing list
> IPFIX@ietf.org
> https://www.ietf.org/mailman/listinfo/ipfix

From acmorton@att.com  Mon Oct 18 07:31:07 2010
Return-Path: 
X-Original-To: ipfix@core3.amsl.com
Delivered-To: ipfix@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C072E3A6814 for ; Mon, 18 Oct 2010 07:31:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -105.514
X-Spam-Level: 
X-Spam-Status: No, score=-105.514 tagged_above=-999 required=5 tests=[AWL=0.282, BAYES_00=-2.599, MSGID_FROM_MTA_HEADER=0.803, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aLU11DBUzPYg for ; Mon, 18 Oct 2010 07:31:03 -0700 (PDT)
Received: from mail146.messagelabs.com (mail146.messagelabs.com [216.82.241.147]) by core3.amsl.com (Postfix) with ESMTP id 112F63A6C43 for ; Mon, 18 Oct 2010 07:30:58 -0700 (PDT)
X-VirusChecked: Checked
X-Env-Sender: acmorton@att.com
X-Msg-Ref: server-12.tower-146.messagelabs.com!1287412344!9471797!1
X-StarScan-Version: 6.2.4; banners=-,-,-
X-Originating-IP: [144.160.20.145]
Received: (qmail 28885 invoked from network); 18 Oct 2010 14:32:25 -0000
Received: from sbcsmtp6.sbc.com (HELO mlpd192.enaf.sfdc.sbc.com) (144.160.20.145) by server-12.tower-146.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 18 Oct 2010 14:32:25 -0000
Received: from enaf.sfdc.sbc.com (localhost.localdomain [127.0.0.1]) by mlpd192.enaf.sfdc.sbc.com (8.14.4/8.14.4) with ESMTP id o9IEWfhX005273 for ; Mon, 18 Oct 2010 10:32:42 -0400
Received: from alpd052.aldc.att.com (alpd052.aldc.att.com [130.8.42.31]) by mlpd192.enaf.sfdc.sbc.com (8.14.4/8.14.4) with ESMTP id o9IEWZIg005129 for ; Mon, 18 Oct 2010 10:32:36 -0400
Received: from aldc.att.com (localhost.localdomain [127.0.0.1]) by alpd052.aldc.att.com (8.14.4/8.14.4) with ESMTP id o9IEWIZ4007316 for ; Mon, 18 Oct 2010 10:32:18 -0400
Received: from dns.maillennium.att.com (dns.maillennium.att.com [135.25.114.99]) by alpd052.aldc.att.com (8.14.4/8.14.4) with ESMTP id o9IEWDv2007072 for ; Mon, 18 Oct 2010 10:32:13 -0400
Message-Id: <201010181432.o9IEWDv2007072@alpd052.aldc.att.com>
Received: from acmt.att.com (ds135-16-251-236.dhcps.ugn.att.com[135.16.251.236](misconfigured sender)) by maillennium.att.com (mailgw1) with SMTP id <20101018143213gw100ei1gge>; Mon, 18 Oct 2010 14:32:13 +0000
X-Originating-IP: [135.16.251.236]
X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9
Date: Mon, 18 Oct 2010 10:32:37 -0400
To: ipfix@ietf.org, "Aamer Akhter (aakhter)" 
From: Al Morton 
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
X-Mailman-Approved-At: Mon, 18 Oct 2010 09:02:14 -0700
Subject: [IPFIX] Fwd: I-D Action:draft-akhter-ipfix-perfmon-00.txt
X-BeenThere: ipfix@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: IPFIX WG discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 18 Oct 2010 14:31:07 -0000

>A URL for this Internet-Draft is:
>http://www.ietf.org/internet-drafts/draft-akhter-ipfix-perfmon-00.txt

Hi Aamer,

I gave this a look-over, and have the following comments:

- I think you've done a good job describing the sequence number
roll-over problem, I was checking to be sure this was covered.

- I think a slightly different loss triad is what you want here.
   Instead of:
>        4.1.1.  perfPacketLoss . . . . . . . . . . . . . . . . . . . .  6
>        4.1.2.  perfPacketExpected . . . . . . . . . . . . . . . . . .  8
>        4.1.3.  perfPacketLossRate . . . . . . . . . . . . . . . . . .  9

I think 4.1.1 should be the observed packet count.
When you combine this in a ratio with the number of expected packets,
you get the packet loss ratio.

So, I suggest:
OLD
4.1.  Transport Layer

4.1.1.  perfPacketLoss

    Name:  perfPacketLoss

    Description:  The packet loss metric reports the number of individual
       packets that were lost in the reporting interval.

NEW
4.1.  Transport Layer

4.1.1.  perfPacketCount

    Name:  perfPacketCount

    Description:  The packet count metric reports the number of individual
       packets that arrived at the observation point during the reporting
       interval.    ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

other edits are needed in 4.1.1, but let's see if we're
on the same page. :-)

Also, I suggest
OLD
4.1.3.  perfPacketLossRate
NEW
4.1.3.  perfPacketLossRatio
as we've done elsewhere, including IPPM and PMOL.

interesting draft,
Al


From bclaise@cisco.com  Tue Oct 19 02:44:22 2010
Return-Path: 
X-Original-To: ipfix@core3.amsl.com
Delivered-To: ipfix@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 85CB93A6452; Tue, 19 Oct 2010 02:44:21 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.483
X-Spam-Level: 
X-Spam-Status: No, score=-2.483 tagged_above=-999 required=5 tests=[AWL=0.115,  BAYES_00=-2.599, HTML_MESSAGE=0.001]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jGgDMhKjT0JX; Tue, 19 Oct 2010 02:44:19 -0700 (PDT)
Received: from av-tac-bru.cisco.com (weird-brew.cisco.com [144.254.15.118]) by core3.amsl.com (Postfix) with ESMTP id 742103A672E; Tue, 19 Oct 2010 02:44:18 -0700 (PDT)
X-TACSUNS: Virus Scanned
Received: from strange-brew.cisco.com (localhost.cisco.com [127.0.0.1]) by av-tac-bru.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id o9J9BNG6018922; Tue, 19 Oct 2010 11:11:23 +0200 (CEST)
Received: from [10.55.43.53] (ams-bclaise-8714.cisco.com [10.55.43.53]) by strange-brew.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id o9J9BMXA028608; Tue, 19 Oct 2010 11:11:22 +0200 (CEST)
Message-ID: <4CBD60BA.6030009@cisco.com>
Date: Tue, 19 Oct 2010 11:11:22 +0200
From: Benoit Claise 
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-GB; rv:1.9.2.9) Gecko/20100915 Thunderbird/3.1.4
MIME-Version: 1.0
To: "ipfix@ietf.org" 
Content-Type: multipart/alternative; boundary="------------090108080206020309070902"
Cc: "pmol@ietf.org" 
Subject: [IPFIX] draft-claise-export-application-info-in-ipfix-00
X-BeenThere: ipfix@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: IPFIX WG discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 19 Oct 2010 09:44:22 -0000

This is a multi-part message in MIME format.
--------------090108080206020309070902
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

  Dear all,

Here is a new draft: 
http://tools.ietf.org/html/draft-claise-export-application-info-in-ipfix-00

      Abstract

         This document specifies an extension to the IP Flow Information
         eXport (IPFIX) protocol specification in [RFC5101  ] and the IPFIX
         information model specified in [RFC5102  ] to export application
         information.

I would to request a slot to present this at the next IPFIX meeting.
Please read it and provide feedback.

Regards, Benoit.

--------------090108080206020309070902
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit



  

    
  
  
    Dear all,

    

    Here is a new draft:
http://tools.ietf.org/html/draft-claise-export-application-info-in-ipfix-00

    
     Abstract
     
        This document specifies an extension to the IP Flow Information
        eXport (IPFIX) protocol specification in [RFC5101] and the IPFIX
        information model specified in [RFC5102] to export application
        information.


    I would to request a slot to present this at the next IPFIX meeting.

    Please read it and provide feedback.

    

    Regards, Benoit.

  


--------------090108080206020309070902--

From HKaplan@acmepacket.com  Tue Oct 19 07:04:13 2010
Return-Path: 
X-Original-To: ipfix@core3.amsl.com
Delivered-To: ipfix@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3B0483A681E for ; Tue, 19 Oct 2010 07:04:13 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.024
X-Spam-Level: 
X-Spam-Status: No, score=-1.024 tagged_above=-999 required=5 tests=[AWL=-1.325, BAYES_00=-2.599, J_CHICKENPOX_52=0.6, MANGLED_PENIS=2.3]
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 HULlLAiubox4 for ; Tue, 19 Oct 2010 07:04:12 -0700 (PDT)
Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6]) by core3.amsl.com (Postfix) with ESMTP id C27BC3A680A for ; Tue, 19 Oct 2010 07:04:11 -0700 (PDT)
Received: from mail.acmepacket.com (216.41.24.7) by etmail.acmepacket.com (216.41.24.6) with Microsoft SMTP Server (TLS) id 8.2.254.0; Tue, 19 Oct 2010 10:05:39 -0400
Received: from mail.acmepacket.com ([127.0.0.1]) by mail ([127.0.0.1]) with mapi; Tue, 19 Oct 2010 10:05:39 -0400
From: Hadriel Kaplan 
To: Brian Trammell 
Date: Tue, 19 Oct 2010 10:05:37 -0400
Thread-Topic: [IPFIX] Fwd: New Version Notification for draft-trammell-ipfix-ie-doctors-00
Thread-Index: ActvlrT0hqNoSKbiQoOyhrmVZ5mbeQ==
Message-ID: 
References: <20101001120148.9042B3A74D4@core3.amsl.com> <6A7213D7-64ED-4D3B-AD8D-CBAD105F21B5@tik.ee.ethz.ch> <8FC4E1A0-0FCF-46A7-BDF2-AA3E2D21227D@acmepacket.com>  <7A6C26A5-FC0E-466F-A1FE-D7E63271FE61@acmepacket.com> 
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: "ipfix@ietf.org Group" 
Subject: Re: [IPFIX] Fwd: New Version Notification for draft-trammell-ipfix-ie-doctors-00
X-BeenThere: ipfix@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: IPFIX WG discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 19 Oct 2010 14:04:13 -0000

Hi Brian,
I agree with your comments.  I find the IESpec short-hand especially useful=
 for emails more than anything else, so even for just that I'm fine with 'e=
m. :)
I do worry about having two forms of dictionaries for IPFIX readers, but I =
suppose the market will sort it out. (or not)

-hadriel

On Oct 18, 2010, at 3:21 AM, Brian Trammell wrote:

> Hi, Hadriel,
>=20
> Comments per tradition inline...
>=20
> On Oct 8, 2010, at 9:27 PM, Hadriel Kaplan wrote:
>=20
>>=20
>> Hi Brian,
>> comments inline...
>>=20
>> On Oct 8, 2010, at 2:39 AM, Brian Trammell wrote:
>>=20
>>> Hi, Hadriel,
>>>=20
>>> Thanks for the feedback.
>>>=20
>>> The primary design goal of the IESpec format is human readability in th=
e expression of information model extensions and templates, while maintaini=
ng simple machine readability. The idea is implementors can read an Interne=
t Draft about an IPFIX application with example templates in IESpec form, c=
opy and paste the example templates out of it into an implementation suppor=
ting IEspec, fill in the fields and go.
>>=20
>> At the end of the day what we're talking about is a form of a "dictionar=
y" file, similar to those used for other protocols, like for SNMP, DIAMETER=
, RADIUS, etc.  Right?  Like not just for putting into a RFC, but more impo=
rtantly for importing into a reader so it can decode and understand the IEs=
, right?
>=20
> There are two orthogonal dimensions here, on both of which we're getting =
confused... First there's the human-readable versus machine-readable issue,=
 then the dictionary (Information Model) version template issue. On reflect=
ion, the primary application for iespec (and therefore the reason to includ=
e it in iedoctors) is human-readable templates with easy machine readabilit=
y.
>=20
> As a dictionary file, it's basically a human-editable subset of 5610, and=
 as such only useful for the  and name information. But as a dictiona=
ry, the IANA registry is of course far preferable. So if the collector devi=
ce is capable of doing so, I'd recommend downloading the IANA registry and =
parsing it at boot or pre-parsing it (maybe into 5610)  once per fortnight =
or so. As long as I don't have to _hand edit_ the IANA XML, I'm happy.
>=20
>> Again, I'm not a big fan of XML, but there are a ton of XML parser libra=
ries available, and the importing of that into a reader so it can understan=
d the new IEs is done rarely, and with a CPU (not an FPGA or network proces=
sor).  Libraries exist to not only read them, but verify their correctness =
using a schema.  Further, they support comments and text descriptions, whic=
h are useful for an IPFIX reader importing them.  An IPFIX reader can use t=
hose to display in a GUI as additional help, and a human can use them to un=
derstand stuff when he/she reads the XML. =20
>>=20
>> For example, suppose vendor BigCorp wants to give out such a "dictionary=
" file for some PEN IEs its BigBox generates, so that IPFIX Readers can dec=
ode them.  One of those PEN IEs is for a "camFlowId".  In IESpec, it might =
be:
>> camFlowId(35566/123)[4]
>>=20
>> That doesn't tell the human nor the IPFIX collector/reader much info.  I=
n XML it's a lot longer text, but it can include some more info like this:
>>      
>>        
>>          An identifier of a single Content Addressable Memory index allo=
cated for the flow.  Two CAM entries are allocated, for each direction, unl=
ess the system is provisioned otherwise.
>>        
>>      
>>      
>>        
>>        See BigCorp User Manual chapter titled "Hardware Resources" for m=
ore information.
>>        
>>      
>>=20
>> And the file can even have a "<-- BigCorp dictionary file for BigCorp Bi=
gBox 10000 System, version 1.2.3. Created 2-10-2010 -->" comment at the top=
.
>>=20
>>=20
>>=20
>>> For readability and compactness, it's intended to address shortcomings =
both in the XML format(s) already defined for IPFIX IEs
>>=20
>> What shortcomings?  There're some fields I think it should have that it =
doesn't, and the structure of it is weird, but  I'm a nitpicker.  Is there =
something fatally wrong with it?
>=20
> Eyeball-parsing the XML formats for dictionary purposes is daunting, and =
they're not at all adaptable to easily readable templates. Fortunately, IAN=
A has the eyeball parsing problem fixed,=20
>=20
>>> and in the traditional 32-bit-wide box-and-line diagrams, which make it=
 difficult to fit a nontrivial template onto a single page, and require som=
e manual work to turn into an implementation.
>>=20
>> This is one of the things I was worried about - that we would be saying =
this would avoid showing things in 32-bit-wide box-and-line diagrams.  I fi=
nd those drawings are really, really useful.  For example, I couldn't make =
heads or tails of the structured-data draft until I saw those examples. =20
>=20
> The thing is, they're useful primarily when describing the _framing_ of t=
he protocol. Here's what a template looks like. Here's what a message looks=
 like. Given a template, here's a record. Structured data is defining new _=
types_, with internal structure, and displaying that structure. Of course w=
e need 32-bit box and line diagrams in that case. With respect to simple ap=
plications of IPFIX, just defining a new template doesn't change the framin=
g. But I hadn't considered the possibility that I'm old and jaded, and that=
 everyone else enjoys seeing the same boxes I'm getting bored with. :) So t=
hat's a valid argument against more compact templates in drafts...
>=20
> The structured-data heirarchy extensions for IEspecs are meant to illustr=
ate applications of structured-data, not the framing thereof. But there's a=
 very valid point here -- structured-data is new enough that we really prob=
ably _do_ want to draw things out explicitly the first few times we use it.
>=20
>> Fitting them on a page is not a serious issue really, is it?  I mean if =
it crosses pages, people can deal. =20
>=20
> A thirty-element template (not unthinkable) crosses two pages. At some po=
int there's a tradeoff between verbosity for clarity and so much verbosity =
that you need to tape things to the wall to have any hope of seeing what's =
going on.=20
>=20
>> I know it takes more work to draw them, but you're writing an RFC for ot=
hers to be able to interop with you, so that's life.  If a nontrivial templ=
ate is difficult to draw, maybe that will encourage people to not make comp=
licated templates. :)  I'm half joking, but my point is the work to write t=
he RFC is really moot compared to helping people reading the RFC implementi=
ng it right. =20
>=20
> I chose the word "non-trivial" poorly -- there's not really a complexity =
continuum in templates, it's either "long" or "short". It's hard to draw _l=
ong_ templates, and it's a bad idea to encourage people to use short templa=
tes when what they need is a long one. :)
>=20
> The reason to reduce the amount of work to write an RFC, though, is not t=
o make _my_ life easier. It's to make it easier for IPFIX _non_-experts to =
write RFCs describing new applications. Less work, and less chance of makin=
g a mistake leading to ambiguity, means better, more readable, more quickly=
 and easily edited and published RFCs.
>=20
> Regards,
>=20
> Brian


From bclaise@cisco.com  Tue Oct 19 07:51:12 2010
Return-Path: 
X-Original-To: ipfix@core3.amsl.com
Delivered-To: ipfix@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1B2A63A6823 for ; Tue, 19 Oct 2010 07:51:12 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.485
X-Spam-Level: 
X-Spam-Status: No, score=-2.485 tagged_above=-999 required=5 tests=[AWL=0.114,  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 3y3W1r-CqcEO for ; Tue, 19 Oct 2010 07:51:10 -0700 (PDT)
Received: from av-tac-bru.cisco.com (weird-brew.cisco.com [144.254.15.118]) by core3.amsl.com (Postfix) with ESMTP id 210F33A683A for ; Tue, 19 Oct 2010 07:51:09 -0700 (PDT)
X-TACSUNS: Virus Scanned
Received: from strange-brew.cisco.com (localhost.cisco.com [127.0.0.1]) by av-tac-bru.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id o9JEqeK1011709 for ; Tue, 19 Oct 2010 16:52:40 +0200 (CEST)
Received: from [10.55.43.53] (ams-bclaise-8714.cisco.com [10.55.43.53]) by strange-brew.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id o9JEqemm022300 for ; Tue, 19 Oct 2010 16:52:40 +0200 (CEST)
Message-ID: <4CBDB0B8.1050906@cisco.com>
Date: Tue, 19 Oct 2010 16:52:40 +0200
From: Benoit Claise 
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-GB; rv:1.9.2.9) Gecko/20100915 Thunderbird/3.1.4
MIME-Version: 1.0
To: "ipfix@ietf.org" 
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Subject: [IPFIX] Export of MIB variable in IPFIX: new IETF draft
X-BeenThere: ipfix@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: IPFIX WG discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 19 Oct 2010 14:51:12 -0000

  Dear all,

Andrew, Paul, and I posted this new draft, "Exporting MIB variables 
using the IPFIX Protocol".
http://www.ietf.org/staging/draft-johnson-ipfix-mib-variable-export-00.txt

        Abstract

           This document specifies a way to export Management
           Information Base (MIB) objects within the IPFIX protocol,
           avoiding the need to define new IPFIX Information Elements
           for existing Management Information Base objects that are
           already fully specified.

           This method requires an extension to the current IPFIX
           protocol.  New Template Set and Options Template Sets are
           specified to allow the export of Simple Network Management
           Protocol (SNMP) MIB Objects.


The problem we want to solve is that we keep development two data models 
for a unique information model (*) , i.e. MIB and IPFIX information 
elements, which are overlapping. For example: there is an IPFIX 
information element representing the ifName MIB Object. Note that some 
more advantages are specified in the draft.
(*) RFC 3444, "On the Difference between Information Models and Data Models"

Please read it and send your feedback.

I would like to have a slot at the next meeting to present this work.

Regards, Benoit.

From j.schoenwaelder@jacobs-university.de  Tue Oct 19 08:23:02 2010
Return-Path: 
X-Original-To: ipfix@core3.amsl.com
Delivered-To: ipfix@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 62C353A6879 for ; Tue, 19 Oct 2010 08:23:02 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -101.988
X-Spam-Level: 
X-Spam-Status: No, score=-101.988 tagged_above=-999 required=5 tests=[AWL=0.261, BAYES_00=-2.599, HELO_EQ_DE=0.35, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4nrZghy2Pzmg for ; Tue, 19 Oct 2010 08:23:00 -0700 (PDT)
Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id 172593A683C for ; Tue, 19 Oct 2010 08:23:00 -0700 (PDT)
Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id ABC23C0002; Tue, 19 Oct 2010 17:24:30 +0200 (CEST)
X-Virus-Scanned: amavisd-new at jacobs-university.de
Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius4.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id wdbg2UoNGOY4; Tue, 19 Oct 2010 17:24:30 +0200 (CEST)
Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id B590FC000E; Tue, 19 Oct 2010 17:24:26 +0200 (CEST)
Received: by elstar.local (Postfix, from userid 501) id DE1B41566E8F; Tue, 19 Oct 2010 17:23:46 +0200 (CEST)
Date: Tue, 19 Oct 2010 17:23:46 +0200
From: Juergen Schoenwaelder 
To: Benoit Claise 
Message-ID: <20101019152346.GA21718@elstar.local>
Mail-Followup-To: Benoit Claise , "ipfix@ietf.org" 
References: <4CBDB0B8.1050906@cisco.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <4CBDB0B8.1050906@cisco.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
Cc: "ipfix@ietf.org" 
Subject: Re: [IPFIX] Export of MIB variable in IPFIX: new IETF draft
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: Tue, 19 Oct 2010 15:23:02 -0000

On Tue, Oct 19, 2010 at 04:52:40PM +0200, Benoit Claise wrote:
>  Dear all,
> 
> Andrew, Paul, and I posted this new draft, "Exporting MIB variables
> using the IPFIX Protocol".
> http://www.ietf.org/staging/draft-johnson-ipfix-mib-variable-export-00.txt
> 
>        Abstract
> 
>           This document specifies a way to export Management
>           Information Base (MIB) objects within the IPFIX protocol,
>           avoiding the need to define new IPFIX Information Elements
>           for existing Management Information Base objects that are
>           already fully specified.
> 
>           This method requires an extension to the current IPFIX
>           protocol.  New Template Set and Options Template Sets are
>           specified to allow the export of Simple Network Management
>           Protocol (SNMP) MIB Objects.
> 
> 
> The problem we want to solve is that we keep development two data
> models for a unique information model (*) , i.e. MIB and IPFIX
> information elements, which are overlapping. For example: there is
> an IPFIX information element representing the ifName MIB Object.
> Note that some more advantages are specified in the draft.
> (*) RFC 3444, "On the Difference between Information Models and Data Models"
> 
> Please read it and send your feedback.

I do not have time for a detailed review, but some things already
come to mind:

a) I find text like this in several places:

            An alphanumeric-format variable name which denotes a 
            variable name expressed as a sequence of decimal numbers or 
            names separated by periods, as specified by the OBJECT 
            IDENTIFIER in [RFC2578]. 

   As far as I can tell, RFC 2578 does not specify a format with names
   separated by periods (and terminology wise 2578 call these "names"
   descriptors).

b) It is good to see that you require authorization via VACM. However,
   this requires that in addition to the variableName the following
   is known (see RFC 3415):

              securityModel        -- Security Model in use
              securityName         -- principal who wants access
              securityLevel        -- Level of Security
              viewType             -- read, write, or notify view
              contextName          -- context containing variableName

c) In the SNMP world, a variable exists in a context. A context is
   identified by a contextEngineID and a contextName (see RFC 3411).
   I think you need to make sure this is captured somewhere.

>From a quick read, I have not yet understood how the index handling
works. But I might see if I take more time to read in detail.

/js

-- 
Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: +49 421 200 3587         Campus Ring 1, 28759 Bremen, Germany
Fax:   +49 421 200 3103         

From trammell@tik.ee.ethz.ch  Wed Oct 20 00:13:15 2010
Return-Path: 
X-Original-To: ipfix@core3.amsl.com
Delivered-To: ipfix@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5B5693A69B9 for ; Wed, 20 Oct 2010 00:13:15 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.123
X-Spam-Level: 
X-Spam-Status: No, score=-6.123 tagged_above=-999 required=5 tests=[AWL=0.476,  BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id toE0sWJEGxZQ for ; Wed, 20 Oct 2010 00:13:13 -0700 (PDT)
Received: from smtp.ee.ethz.ch (smtp.ee.ethz.ch [129.132.2.219]) by core3.amsl.com (Postfix) with ESMTP id D290A3A6857 for ; Wed, 20 Oct 2010 00:13:12 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by smtp.ee.ethz.ch (Postfix) with ESMTP id DA16BD938C; Wed, 20 Oct 2010 09:14:44 +0200 (MEST)
X-Virus-Scanned: by amavisd-new on smtp.ee.ethz.ch
Received: from smtp.ee.ethz.ch ([127.0.0.1]) by localhost (.ee.ethz.ch [127.0.0.1]) (amavisd-new, port 10024) with LMTP id i4wQe7IQIGRP; Wed, 20 Oct 2010 09:14:44 +0200 (MEST)
Received: from [192.168.0.188] (77-57-164-35.dclient.hispeed.ch [77.57.164.35]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: briant) by smtp.ee.ethz.ch (Postfix) with ESMTPSA id 5B5ECD9385; Wed, 20 Oct 2010 09:14:44 +0200 (MEST)
Mime-Version: 1.0 (Apple Message framework v1081)
Content-Type: text/plain; charset=us-ascii
From: Brian Trammell 
In-Reply-To: 
Date: Wed, 20 Oct 2010 09:14:43 +0200
Content-Transfer-Encoding: 7bit
Message-Id: <3EB56584-6313-4484-9EAC-EC7742944526@tik.ee.ethz.ch>
References:  <3F070565-6355-499B-B768-A76212988E0F@tik.ee.ethz.ch> 
To: "Romascanu, Dan (Dan)" 
X-Mailer: Apple Mail (2.1081)
Cc: IPFIX Working Group 
Subject: Re: [IPFIX] AD review on draft-ietf-ipfix-anon-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 Oct 2010 07:13:15 -0000

Hi, Dan,

Done; draft-ietf-ipfix-anon-05 is now available.

Best regards,

Brian

On Oct 18, 2010, at 11:08 AM, Romascanu, Dan (Dan) wrote:

> Thanks, Brian. Please submit. 
> 
> Regards,
> 
> Dan
> 
> 
>> -----Original Message-----
>> From: Brian Trammell [mailto:trammell@tik.ee.ethz.ch] 
>> Sent: Monday, October 18, 2010 8:40 AM
>> To: Romascanu, Dan (Dan)
>> Cc: IPFIX Working Group
>> Subject: Re: [IPFIX] AD review on draft-ietf-ipfix-anon-04.txt
>> 
>> Hi, Dan,
>> 
>> Thanks for your review. We've prepared a -05, ready for 
>> submission after a final editorial pass. Comments on comments inline.
>> 
>> On Oct 14, 2010, at 8:45 PM, Romascanu, Dan (Dan) wrote:
>> 
>>> Please find below the AD review of 
>> draft-ietf-ipfix-anon-04.txt. The 
>>> document is in quite good shape, however, there are a 
>> number of issued 
>>> that I suggest should be resolved by a revised ID before 
>> proceeding to 
>>> IETF Last Call.
>>> 
>>> Comments are marked T for Technical and E for Editorial. 
>>> 
>>> T1. Section 4.2 - MAC Address Anonymisation
>>> 
>>>  Beyond
>>>  this, the address is unstructured, and there is no particular
>>>  relationship among the OUIs assigned to a given vendor.
>>> 
>>> This is not completely true. Actually some vendors keep a 
>> structure of 
>>> the OUIs (per family of products for example) or the 
>> relative values 
>>> of the OUIs may indicate a time relation. I suggest 
>>> s/particular/standard/
>> 
>> Good point, thanks.
>> 
>>> T2. Same section.
>>> 
>>> It is not clear for me why the Truncation was not included 
>> as a scheme 
>>> for Anonymisation of MAC addresses. I actually believe that 
>> it can be 
>>> quite significant as the first 24 bits of an EUI-48 address 
>> provides 
>>> vendor information.
>> 
>> Removing vendor information would be served by reverse 
>> truncation. Normal truncation would remove information about 
>> the individual nodes (which may be preserved through IP 
>> addresses, for example) while preserving vendor information 
>> (which may have specific utility when researching 
>> vendor-specific phenomena). More discussion of these issues 
>> in the document wouldn't hurt in any event. Done.
>> 
>>> T3. Section 4.2.1
>>> 
>>>  Also note that the utility or removing
>>>  manufacturer information is dubious, and not particularly well-
>>>  covered by the literature.
>>> 
>>> I would argue against the 'dubious' characterization. Actually the 
>>> information may be important and need to be anonymized.
>> 
>> Point taken. I would actually (on review) argue against 
>> calling it dubious in an RFC, even if it were. But it's 
>> certainly not well-covered by the literature. :) Fixed.
>> 
>>> T4. In sections 5.3, 5.4, 5.5 the last phrase in each 
>> paragraph  that 
>>> makes recommendations about limiting exported information 
>> of various 
>>> sorts should be rephrased using 2119 capitalized SHOULD or 
>> SHOULD NOT
>>> 
>>> T5. Section 7.2.3 -
>>> 
>>>  Anonymisation of timestamps and the Export Time header 
>> field should
>>>  take care to avoid times too far in the past or future
>>> 
>>> Please rephrase - header fields do not 'take care' of anything :-). 
>>> Also usage of 2119 capitalized keywords seems in place here.
>>> 
>>> T6. Section 7.2.4
>>> 
>>>  care should be taken while using
>>>  them with anonymised data export and storage.
>>> 
>>> What does this exactly mean? Please rephrase, possibly using 2119 
>>> capitalized keywords.
>>> 
>>> T7. Same section
>>> 
>>>  care
>>>  must be taken to ensure that Options described by this 
>> template are
>>>  written using the anonymised timestamps instead of the 
>> original ones.
>>> 
>>> Please rephrase, possibly using 2119 capitalized keywords. 
>>> 
>>> T8. Section 7.2.5
>>> 
>>>  When anonymising data for transport or storage using 
>> IPFIX containing
>>>  anonymised IP addresses, and the analysis purpose permits 
>> doing so,
>>>  it is recommended to filter out or leave unanonymised data 
>>> containing
>>> 
>>> Using 2119 RECOMMENDED seems appropriate. 
>>> 
>>> 
>>> T9. Section 7.2.6
>>> 
>>>  The general ground rule is that information of similar type
>>>  to that anonymised should not be made available to the receiver by
>>>  any means, whether in the Data Records, in IPFIX protocol 
>> structures
>>>  such as Message Headers, or out-of-band.
>>> 
>>> Using 2119 RECOMMENDED seems appropriate. 
>> 
>> Points on rephrasing and 2119 lanugage are taken; edited.
>> 
>>> E1. Section 4.3.2 - please expand QoS and SLA at first occurrence
>>> 
>>> E2. Section 5.2.1 - in the first phrase that defines stability s/a 
>>> single given/the same given/
>> 
>> The suggested correction reads to me as if there's no 
>> anonymisation at all. However, the present phrasing is also a 
>> little confusing. How about s/a single given/a given/ here?
>> 
>>> E3. Figure 3 - please expand FR, FW, EP, etc. 
>> 
>> Done, in the introductory text.
>> 
>> Thanks again, best regards,
>> 
>> Brian
>> 


From root@core3.amsl.com  Wed Oct 20 00:15:03 2010
Return-Path: 
X-Original-To: ipfix@ietf.org
Delivered-To: ipfix@core3.amsl.com
Received: by core3.amsl.com (Postfix, from userid 0) id EAEBE3A69D5; Wed, 20 Oct 2010 00:15:02 -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: <20101020071502.EAEBE3A69D5@core3.amsl.com>
Date: Wed, 20 Oct 2010 00:15:02 -0700 (PDT)
Cc: ipfix@ietf.org
Subject: [IPFIX] I-D Action:draft-ietf-ipfix-anon-05.txt
X-BeenThere: ipfix@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: IPFIX WG discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 20 Oct 2010 07:15:03 -0000

--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the IP Flow Information Export Working Group of the IETF.


	Title           : IP Flow Anonymisation Support
	Author(s)       : E. Boschi, B. Trammell
	Filename        : draft-ietf-ipfix-anon-05.txt
	Pages           : 41
	Date            : 2010-10-20

This document describes anonymisation techniques for IP flow data and
the export of anonymised data using the IPFIX protocol.  It
categorizes common anonymisation schemes and defines the parameters
needed to describe them.  It provides guidelines for the
implementation of anonymised data export and storage over IPFIX, and
describes an information model and Options-based method for
anonymisation metadata export within the IPFIX protocol or storage in
IPFIX Files.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-ipfix-anon-05.txt

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

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

--NextPart
Content-Type: Message/External-body;
	name="draft-ietf-ipfix-anon-05.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID: <2010-10-20001149.I-D@ietf.org>


--NextPart--

From paitken@cisco.com  Wed Oct 20 04:23:17 2010
Return-Path: 
X-Original-To: ipfix@core3.amsl.com
Delivered-To: ipfix@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EBBDA3A679F for ; Wed, 20 Oct 2010 04:23:17 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.599
X-Spam-Level: 
X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[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 bSW62uyrr9Ac for ; Wed, 20 Oct 2010 04:23:17 -0700 (PDT)
Received: from sj-iport-4.cisco.com (sj-iport-4.cisco.com [171.68.10.86]) by core3.amsl.com (Postfix) with ESMTP id 0652C3A6768 for ; Wed, 20 Oct 2010 04:23:17 -0700 (PDT)
Authentication-Results: sj-iport-4.cisco.com; dkim=neutral (message not signed) header.i=none
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AvsEAGtuvkyrR7H+/2dsb2JhbAChWHGhLpxIhUoEikuDBA
X-IronPort-AV: E=Sophos;i="4.57,355,1283731200"; d="scan'208";a="203703904"
Received: from sj-core-2.cisco.com ([171.71.177.254]) by sj-iport-4.cisco.com with ESMTP; 20 Oct 2010 11:24:50 +0000
Received: from cisco.com (mrwint.cisco.com [64.103.71.48]) by sj-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id o9KBOmI6013936; Wed, 20 Oct 2010 11:24:49 GMT
Received: from [144.254.153.46] (dhcp-144-254-153-46.cisco.com [144.254.153.46]) by cisco.com (8.11.7p3+Sun/8.8.8) with ESMTP id o9KBOl829225; Wed, 20 Oct 2010 12:24:48 +0100 (BST)
Message-ID: <4CBED17E.5080402@cisco.com>
Date: Wed, 20 Oct 2010 12:24:46 +0100
From: Paul Aitken 
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-GB; rv:1.9.2.11) Gecko/20101013 Lightning/1.0b2 Thunderbird/3.1.5
MIME-Version: 1.0
To: IETF IPFIX Working Group 
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 7bit
Cc: ipfix-chairs@tools.ietf.org
Subject: [IPFIX] exporting decimal places in IPFIX
X-BeenThere: ipfix@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: IPFIX WG discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 20 Oct 2010 11:23:18 -0000

Dear IPFIX experts,

We would like to export a field which is measured to two decimal places.
Internally we store this as an integer of (value x 100).

So eg, if the value is 35.01% then we store 3501. Similarly, if it is
-10.90 then we store -1090. So floating point isn't used or required.

How should we export that in IPFIX?

* Create a new type of "percentage" which is expressed as "integer x100"?

* Or more generically, type = integer, units = 1/100'ths ?

* Should we define "deci", "centi", "micro" and "milli" types as 
integers with 1, 2, 3 and 6 decimal places respectively?

* Converted to floating point? Though clearly arbitrary floating point 
precision isn't needed in this case.

Feedback appreciated...

Thanks,
P.

From trammell@tik.ee.ethz.ch  Wed Oct 20 05:58:03 2010
Return-Path: 
X-Original-To: ipfix@core3.amsl.com
Delivered-To: ipfix@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E9D8E3A67B7 for ; Wed, 20 Oct 2010 05:58:03 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.522
X-Spam-Level: 
X-Spam-Status: No, score=-6.522 tagged_above=-999 required=5 tests=[AWL=0.077,  BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id O7fJjt3Z99gp for ; Wed, 20 Oct 2010 05:58:03 -0700 (PDT)
Received: from smtp.ee.ethz.ch (smtp.ee.ethz.ch [129.132.2.219]) by core3.amsl.com (Postfix) with ESMTP id EDF093A677D for ; Wed, 20 Oct 2010 05:58:02 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by smtp.ee.ethz.ch (Postfix) with ESMTP id BC7FDD93AB; Wed, 20 Oct 2010 14:59:35 +0200 (MEST)
X-Virus-Scanned: by amavisd-new on smtp.ee.ethz.ch
Received: from smtp.ee.ethz.ch ([127.0.0.1]) by localhost (.ee.ethz.ch [127.0.0.1]) (amavisd-new, port 10024) with LMTP id j6Rh2fdDzxIl; Wed, 20 Oct 2010 14:59:35 +0200 (MEST)
Received: from mac-10243.ethz.ch (mac-10243.ethz.ch [82.130.102.152]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: briant) by smtp.ee.ethz.ch (Postfix) with ESMTPSA id 83718D93AA; Wed, 20 Oct 2010 14:59:35 +0200 (MEST)
Mime-Version: 1.0 (Apple Message framework v1081)
Content-Type: text/plain; charset=us-ascii
From: Brian Trammell 
In-Reply-To: <4CBED17E.5080402@cisco.com>
Date: Wed, 20 Oct 2010 14:59:35 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: 
References: <4CBED17E.5080402@cisco.com>
To: Paul Aitken 
X-Mailer: Apple Mail (2.1081)
Cc: IETF IPFIX Working Group , ipfix-chairs@tools.ietf.org
Subject: Re: [IPFIX] exporting decimal places in IPFIX
X-BeenThere: ipfix@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: IPFIX WG discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 20 Oct 2010 12:58:04 -0000

Hi, Paul,

I'd go with the SI prefix solution (type integer, units 1/100 pct), and =
add something to the IE name to point out the scale: it's what we =
already do in cases of fixed-point export in IPFIX (e.g. =
flowDurationMilliseconds/flowDurationMicroseconds)

Cheers,

Brian


On Oct 20, 2010, at 1:24 PM, Paul Aitken wrote:

> Dear IPFIX experts,
>=20
> We would like to export a field which is measured to two decimal =
places.
> Internally we store this as an integer of (value x 100).
>=20
> So eg, if the value is 35.01% then we store 3501. Similarly, if it is
> -10.90 then we store -1090. So floating point isn't used or required.
>=20
> How should we export that in IPFIX?
>=20
> * Create a new type of "percentage" which is expressed as "integer =
x100"?
>=20
> * Or more generically, type =3D integer, units =3D 1/100'ths ?
>=20
> * Should we define "deci", "centi", "micro" and "milli" types as =
integers with 1, 2, 3 and 6 decimal places respectively?
>=20
> * Converted to floating point? Though clearly arbitrary floating point =
precision isn't needed in this case.
>=20
> Feedback appreciated...
>=20
> Thanks,
> P.
> _______________________________________________
> IPFIX mailing list
> IPFIX@ietf.org
> https://www.ietf.org/mailman/listinfo/ipfix


From iesg-secretary@ietf.org  Wed Oct 20 13:21:23 2010
Return-Path: 
X-Original-To: ipfix@core3.amsl.com
Delivered-To: ipfix@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6BCE13A692B; Wed, 20 Oct 2010 13:21:23 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.599
X-Spam-Level: 
X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TTa6TaT1Pe4R; Wed, 20 Oct 2010 13:21:22 -0700 (PDT)
Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8E26C3A6927; Wed, 20 Oct 2010 13:21:22 -0700 (PDT)
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
From: The IESG 
To: IETF-Announce 
X-Test-IDTracker: no
Message-ID: <20101020202122.24802.13275.idtracker@localhost>
Date: Wed, 20 Oct 2010 13:21:22 -0700
Cc: ipfix@ietf.org
Subject: [IPFIX] Last Call:  (IP Flow Anonymisation	Support) to Experimental RFC
X-BeenThere: ipfix@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: IPFIX WG discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 20 Oct 2010 20:21:23 -0000

The IESG has received a request from the IP Flow Information Export WG
(ipfix) to consider the following document:
- 'IP Flow Anonymisation Support'
   as an Experimental RFC

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action. Please send substantive comments to the
ietf@ietf.org mailing lists by 2010-11-03. Exceptionally, comments may be
sent to iesg@ietf.org instead. In either case, please retain the
beginning of the Subject line to allow automated sorting.

The file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-ipfix-anon/

IESG discussion can be tracked via
https://datatracker.ietf.org/doc/draft-ietf-ipfix-anon/


The following IPR Declarations may be related to this I-D:

/ipr/308/
/ipr/419/
/ipr/418/
/ipr/432/
/ipr/431/
/ipr/599/
/ipr/782/
/ipr/783/
/ipr/784/
/ipr/785/
/ipr/1112/

From akoba@nttv6.net  Sat Oct 23 21:37:06 2010
Return-Path: 
X-Original-To: ipfix@core3.amsl.com
Delivered-To: ipfix@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 844BE3A67D0 for ; Sat, 23 Oct 2010 21:37:02 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.885
X-Spam-Level: 
X-Spam-Status: No, score=-2.885 tagged_above=-999 required=5 tests=[AWL=1.715,  BAYES_00=-2.599, GB_I_LETTER=-2, NO_RELAYS=-0.001]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GHkzBq+jDX+Z for ; Sat, 23 Oct 2010 21:36:53 -0700 (PDT)
Received: from mail.nttv6.net (mail.nttv6.net [IPv6:2001:fa8::25]) by core3.amsl.com (Postfix) with ESMTP id 420E03A67D1 for ; Sat, 23 Oct 2010 21:35:17 -0700 (PDT)
Received: from [192.168.1.5] (mail.nttv6.net [IPv6:2001:fa8::25]) by mail.nttv6.net (8.14.4/8.14.3) with ESMTP id o9O4YvCP094287; Sun, 24 Oct 2010 13:34:58 +0900 (JST) (envelope-from akoba@nttv6.net)
Date: Sun, 24 Oct 2010 13:35:07 +0900
From: Kobayashi Atsushi 
To: "Romascanu, Dan (Dan)" 
In-Reply-To: 
References: 
Message-Id: <20101024133503.65B9.17391CF2@nttv6.net>
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: 7bit
X-Mailer: Becky! ver. 2.53 [ja] (Unregistered)
X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.6 (mail.nttv6.net [IPv6:2001:fa8::25]); Sun, 24 Oct 2010 13:35:00 +0900 (JST)
Cc: IPFIX Working Group 
Subject: Re: [IPFIX] AD Review of draft-ipfix-mediators-framework-08
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, 24 Oct 2010 04:37:07 -0000

Dear Dan and all,

Thank you for your review.
Sorry for late reply. Please see inline.

I will prepare next version until Nov.25.

On Tue, 12 Oct 2010 14:17:12 +0200
"Romascanu, Dan (Dan)"  wrote:

> Please find below the AD review of 
> 
> This document is in quite good shape. I would however suggest to deal
> with the issues in this review before sending the document to the IETF
> Last Call. 
> 
> The technical comments are marked Tx and the editorial comments are
> marked Ex.
> 
> T1. Sections 5.2, 5.3: It is not clear what you mean when you say 'This
> function must be configurable' - does this mean that some parameters
> related to this function are configurable (which ones?), or that
> 'Activation of this function must be configurable'? 
> 

In section 5.2, some parameters must be configurable. That implies there
is no parameter to be transmitted just like the case of IPFIX proxy for
original Exporter.
 
5.2.  Exporting Process

snip

   o  Transmitting the origin (e.g., Observation Point, Observation
      Domain ID, Original Exporter IP address, etc.) of the data in
      additional Data Record fields or additional Data Records.  These
      parameters related to this function must be configurable.

In section 5.3, Activation of this function must be configurable.

5.3.  Intermediate Process

snip

   o  Reporting statistics and interpretations for IPFIX Metering
      Processes, PSAMP Metering Processes, and Exporting Processes from
      an Original Exporter.  See section 4 of [RFC5101] and section 6 of
      [RFC5476] for relevant statistics data structures and
      interpretations, respectively.  Activation of this function must
      be configurable.

> T2. Same sections and phrase. This seems to me a very clear
> architectural requirement where RFC 2119 capitalized MUST would fit.
> Please consider this as a non-blocking comment. 
> 

In RFC5470(IPFIX Architecture),  this does not use capitalized "MUST"
as an informational document, although it uses a lot of "must" or "may".

The purpose of the document  expands the functionality of IPFIX
Architecture, therefore the document follows the rule of RFC5470.
Capitalized letter will be used in later document like Mediator protocol.

Is it OK?

> T3. In 5.3 'This relation can be configurable' - same question as at T1.
> 
> 

I would like to remove the sentence "This relation can be configurable".
The phrase already said that  it maintains configurable relation.

5.3.  Intermediate Process

snip

   o  Maintaining the configurable relation between Collecting
      Process(es)/Metering Process(es) and Exporting Process(es)/other
      Intermediate Process(es).

> T4. Section 5.3.2.1: 
> 
>       Maintaining the mapping information about Transport Sessions,
>       Observation Domain IDs, and Template IDs on the incoming and
>       outgoing sides to ensure the appropriateness of the scope field
>       values in Data Records defined by Options Templates and of IPFIX
>       Template Withdrawal Messages.
> 
> I could not figure out what 'the appropriateness of the scope field
> values' means. 

I would like to improve the following.

Maintaining the mapping information about Transport Sessions, Observation
Domain IDs, and Template IDs on the incoming and outgoing sides 
in order to ensure the consistency of scope field values of incoming and outgoing
Data Records defined by Options Templates.


> 
> T5. The 'must', 'should', 'may' in the Security Considerations section
> seem appropriate for RFC 2119 keywords capitalization. Please consider
> this as a non-blocking comment. 
> 

I would like to follow the rule of IPFIX architecture, not use
capitalized keywords.

> 
> E1. idnits complains about 
> 
> ** The document seems to lack a both a reference to RFC 2119 and the
>      recommended RFC 2119 boilerplate, even if it appears to use RFC
> 2119
>      keywords. 
> 
>      RFC 2119, paragraph 2:
>      "The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL
> NOT",
>       "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in
>       this document are to be interpreted as described in RFC 2119."
> 
> This is probably because of a SHOULD left capitalized in the Security
> Considerations section. Change it into a 'should' unless you decide to
> follow the recommendations in T2 and T5. 

Ok, I will change them into "should".
> 
> E2. idnits points to potential problems in references. Please confirm if
> this is what you intended, or updates are needed. 
> 
>   Checking references for intended status: Informational
>  
> ------------------------------------------------------------------------
> ----
> 
>   == Outdated reference: draft-ietf-ipfix-mediators-problem-statement
> has
>      been published as RFC 5982
> 
Ok.

>   == Outdated reference: A later version (-01) exists of
>      draft-ietf-ipfix-psamp-mib-00
> 
Ok.

>   -- Obsolete informational reference (is this intentional?): RFC 3280
>      (Obsoleted by RFC 5280)
> 
Ok.

>   -- Obsolete informational reference (is this intentional?): RFC 4346
>      (Obsoleted by RFC 5246)
> 
Ok.

> E3. Section 1: 
> 
> s/To fulfill application requirements with limited system resources,
> IPFIX architecture needs to introduce/To fulfill application
> requirements with limited system resources, the IPFIX architecture needs
> to introduce/ 

Ok.

> 
> E4. Section 2: 
> 
> s/The use of the terms "must", "should", and "may" in this document are
> informational only/The use of the terms "must", "should", and "may" in
> this document is informational only/

Ok.
> 
> E5. what does 'binning' mean in the context of this document? 
> 

It means data binning.

   Intermediate Aggregation Process

      An Intermediate Aggregation Process is an Intermediate Process
      that aggregates records based upon a set of Flow Keys or functions
      applied to fields from the record (e.g., data binning and subnet
      aggregation).


> E6. Figure F: IPFIX Mediation Functional Block - should be either
> 'Blocks' or 'Block Diagram'
> 
Ok.

> E7. in 5.3.2.3 s/describied/described/
> 

Ok.

Thanks,
Atsushi Kobayashi


From dromasca@avaya.com  Sun Oct 24 03:43:14 2010
Return-Path: 
X-Original-To: ipfix@core3.amsl.com
Delivered-To: ipfix@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 880D23A6832 for ; Sun, 24 Oct 2010 03:43:14 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -103.532
X-Spam-Level: 
X-Spam-Status: No, score=-103.532 tagged_above=-999 required=5 tests=[AWL=1.067, BAYES_00=-2.599, GB_I_LETTER=-2, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ULPMCWyRUJJb for ; Sun, 24 Oct 2010 03:43:13 -0700 (PDT)
Received: from de307622-de-outbound.net.avaya.com (de307622-de-outbound.net.avaya.com [198.152.71.100]) by core3.amsl.com (Postfix) with ESMTP id A967F3A682C for ; Sun, 24 Oct 2010 03:43:12 -0700 (PDT)
X-IronPort-AV: E=Sophos;i="4.58,231,1286164800"; d="scan'208";a="213772150"
Received: from unknown (HELO p-us1-erheast.us1.avaya.com) ([135.11.50.53]) by de307622-de-outbound.net.avaya.com with ESMTP; 24 Oct 2010 06:44:53 -0400
X-IronPort-AV: E=Sophos;i="4.58,231,1286164800"; d="scan'208";a="527125767"
Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.14]) by p-us1-erheast-out.us1.avaya.com with ESMTP; 24 Oct 2010 06:44:52 -0400
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Date: Sun, 24 Oct 2010 12:44:30 +0200
Message-ID: 
In-Reply-To: <20101024133503.65B9.17391CF2@nttv6.net>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [IPFIX] AD Review of draft-ipfix-mediators-framework-08
Thread-Index: ActzNNSiwPr2hHp2QKSdzAfU4rFxjQAMxsqA
References:  <20101024133503.65B9.17391CF2@nttv6.net>
From: "Romascanu, Dan (Dan)" 
To: "Kobayashi Atsushi" 
Cc: IPFIX Working Group 
Subject: Re: [IPFIX] AD Review of draft-ipfix-mediators-framework-08
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, 24 Oct 2010 10:43:14 -0000

Hi Atsushi,

Please see my comments in-line.=20

Thanks and Regards,

Dan=20

> -----Original Message-----
> From: Kobayashi Atsushi [mailto:akoba@nttv6.net]=20
> Sent: Sunday, October 24, 2010 6:35 AM
> To: Romascanu, Dan (Dan)
> Cc: IPFIX Working Group
> Subject: Re: [IPFIX] AD Review of draft-ipfix-mediators-framework-08
>=20
> Dear Dan and all,
>=20
> Thank you for your review.
> Sorry for late reply. Please see inline.
>=20
> I will prepare next version until Nov.25.

Please do.=20

>=20
> On Tue, 12 Oct 2010 14:17:12 +0200
> "Romascanu, Dan (Dan)"  wrote:
>=20
> > Please find below the AD review of
> >=20
> > This document is in quite good shape. I would however=20
> suggest to deal=20
> > with the issues in this review before sending the document=20
> to the IETF=20
> > Last Call.
> >=20
> > The technical comments are marked Tx and the editorial comments are=20
> > marked Ex.
> >=20
> > T1. Sections 5.2, 5.3: It is not clear what you mean when you say=20
> > 'This function must be configurable' - does this mean that some=20
> > parameters related to this function are configurable (which=20
> ones?), or=20
> > that 'Activation of this function must be configurable'?
> >=20
>=20
> In section 5.2, some parameters must be configurable. That=20
> implies there is no parameter to be transmitted just like the=20
> case of IPFIX proxy for original Exporter.
> =20
> 5.2.  Exporting Process
>=20
> snip
>=20
>    o  Transmitting the origin (e.g., Observation Point, Observation
>       Domain ID, Original Exporter IP address, etc.) of the data in
>       additional Data Record fields or additional Data Records.  These
>       parameters related to this function must be configurable.
>=20

OK - it is probably better  s/These parameters/The parameters/

> In section 5.3, Activation of this function must be configurable.
>=20
> 5.3.  Intermediate Process
>=20
> snip
>=20
>    o  Reporting statistics and interpretations for IPFIX Metering
>       Processes, PSAMP Metering Processes, and Exporting=20
> Processes from
>       an Original Exporter.  See section 4 of [RFC5101] and=20
> section 6 of
>       [RFC5476] for relevant statistics data structures and
>       interpretations, respectively.  Activation of this function must
>       be configurable.

OK.=20

>=20
> > T2. Same sections and phrase. This seems to me a very clear=20
> > architectural requirement where RFC 2119 capitalized MUST would fit.
> > Please consider this as a non-blocking comment.=20
> >=20
>=20
> In RFC5470(IPFIX Architecture),  this does not use capitalized "MUST"
> as an informational document, although it uses a lot of=20
> "must" or "may".
>=20
> The purpose of the document  expands the functionality of=20
> IPFIX Architecture, therefore the document follows the rule=20
> of RFC5470.
> Capitalized letter will be used in later document like=20
> Mediator protocol.
>=20
> Is it OK?
>=20

OK.=20

> > T3. In 5.3 'This relation can be configurable' - same=20
> question as at T1.
> >=20
> >=20
>=20
> I would like to remove the sentence "This relation can be=20
> configurable".
> The phrase already said that  it maintains configurable relation.
>=20
> 5.3.  Intermediate Process
>=20
> snip
>=20
>    o  Maintaining the configurable relation between Collecting
>       Process(es)/Metering Process(es) and Exporting Process(es)/other
>       Intermediate Process(es).
>=20

OK.=20

> > T4. Section 5.3.2.1:=20
> >=20
> >       Maintaining the mapping information about Transport Sessions,
> >       Observation Domain IDs, and Template IDs on the incoming and
> >       outgoing sides to ensure the appropriateness of the=20
> scope field
> >       values in Data Records defined by Options Templates=20
> and of IPFIX
> >       Template Withdrawal Messages.
> >=20
> > I could not figure out what 'the appropriateness of the scope field=20
> > values' means.
>=20
> I would like to improve the following.
>=20
> Maintaining the mapping information about Transport Sessions,=20
> Observation Domain IDs, and Template IDs on the incoming and=20
> outgoing sides in order to ensure the consistency of scope=20
> field values of incoming and outgoing Data Records defined by=20
> Options Templates.
>=20
>=20

OK.=20

> >=20
> > T5. The 'must', 'should', 'may' in the Security=20
> Considerations section
> > seem appropriate for RFC 2119 keywords capitalization.=20
> Please consider
> > this as a non-blocking comment.=20
> >=20
>=20
> I would like to follow the rule of IPFIX architecture, not use
> capitalized keywords.
>=20

OK

> >=20
> > E1. idnits complains about=20
> >=20
> > ** The document seems to lack a both a reference to RFC 2119 and the
> >      recommended RFC 2119 boilerplate, even if it appears to use RFC
> > 2119
> >      keywords.=20
> >=20
> >      RFC 2119, paragraph 2:
> >      "The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL
> > NOT",
> >       "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and=20
> "OPTIONAL" in
> >       this document are to be interpreted as described in RFC 2119."
> >=20
> > This is probably because of a SHOULD left capitalized in=20
> the Security
> > Considerations section. Change it into a 'should' unless=20
> you decide to
> > follow the recommendations in T2 and T5.=20
>=20
> Ok, I will change them into "should".
> >=20
> > E2. idnits points to potential problems in references.=20
> Please confirm if
> > this is what you intended, or updates are needed.=20
> >=20
> >   Checking references for intended status: Informational
> > =20
> >=20
> --------------------------------------------------------------
> ----------
> > ----
> >=20
> >   =3D=3D Outdated reference:=20
> draft-ietf-ipfix-mediators-problem-statement
> > has
> >      been published as RFC 5982
> >=20
> Ok.
>=20
> >   =3D=3D Outdated reference: A later version (-01) exists of
> >      draft-ietf-ipfix-psamp-mib-00
> >=20
> Ok.
>=20
> >   -- Obsolete informational reference (is this=20
> intentional?): RFC 3280
> >      (Obsoleted by RFC 5280)
> >=20
> Ok.
>=20
> >   -- Obsolete informational reference (is this=20
> intentional?): RFC 4346
> >      (Obsoleted by RFC 5246)
> >=20
> Ok.
>=20
> > E3. Section 1:=20
> >=20
> > s/To fulfill application requirements with limited system resources,
> > IPFIX architecture needs to introduce/To fulfill application
> > requirements with limited system resources, the IPFIX=20
> architecture needs
> > to introduce/=20
>=20
> Ok.
>=20
> >=20
> > E4. Section 2:=20
> >=20
> > s/The use of the terms "must", "should", and "may" in this=20
> document are
> > informational only/The use of the terms "must", "should",=20
> and "may" in
> > this document is informational only/
>=20
> Ok.
> >=20
> > E5. what does 'binning' mean in the context of this document?=20
> >=20
>=20
> It means data binning.
>=20
>    Intermediate Aggregation Process
>=20
>       An Intermediate Aggregation Process is an Intermediate Process
>       that aggregates records based upon a set of Flow Keys=20
> or functions
>       applied to fields from the record (e.g., data binning and subnet
>       aggregation).
>=20
>=20
> > E6. Figure F: IPFIX Mediation Functional Block - should be either
> > 'Blocks' or 'Block Diagram'
> >=20
> Ok.
>=20
> > E7. in 5.3.2.3 s/describied/described/
> >=20
>=20
> Ok.
>=20
> Thanks,
> Atsushi Kobayashi
>=20
>=20

From akoba@nttv6.net  Mon Oct 25 01:54:11 2010
Return-Path: 
X-Original-To: ipfix@core3.amsl.com
Delivered-To: ipfix@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C01E63A67FD for ; Mon, 25 Oct 2010 01:54:11 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.914
X-Spam-Level: 
X-Spam-Status: No, score=-1.914 tagged_above=-999 required=5 tests=[AWL=-0.114, BAYES_00=-2.599, GB_I_LETTER=-2, 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 2-e2tRhNUXqc for ; Mon, 25 Oct 2010 01:54:10 -0700 (PDT)
Received: from mail.nttv6.net (mail.nttv6.net [IPv6:2001:fa8::25]) by core3.amsl.com (Postfix) with ESMTP id 6A4DA3A67CF for ; Mon, 25 Oct 2010 01:54:09 -0700 (PDT)
Received: from [192.168.1.4] (mail.nttv6.net [IPv6:2001:fa8::25]) by mail.nttv6.net (8.14.4/8.14.3) with ESMTP id o9P8tjXU002006; Mon, 25 Oct 2010 17:55:46 +0900 (JST) (envelope-from akoba@nttv6.net)
Date: Mon, 25 Oct 2010 17:55:46 +0900
From: Kobayashi Atsushi 
To: "Romascanu, Dan (Dan)" 
In-Reply-To: 
References: <20101024133503.65B9.17391CF2@nttv6.net> 
Message-Id: <20101025175545.A384.17391CF2@nttv6.net>
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: 7bit
X-Mailer: Becky! ver. 2.53 [ja] (Unregistered)
X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.6 (mail.nttv6.net [IPv6:2001:fa8::25]); Mon, 25 Oct 2010 17:55:46 +0900 (JST)
Cc: IPFIX Working Group 
Subject: Re: [IPFIX] AD Review of draft-ipfix-mediators-framework-08
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, 25 Oct 2010 08:54:11 -0000

Hi Dan,

Thank you for your reply.
During discussing with co-authors, my answer was a little bit changed.
Please see in-line.

On Sun, 24 Oct 2010 12:44:30 +0200
"Romascanu, Dan (Dan)"  wrote:

> Hi Atsushi,
> 
> Please see my comments in-line. 
> 
> Thanks and Regards,
> 
> Dan 
> 
> > -----Original Message-----
> > From: Kobayashi Atsushi [mailto:akoba@nttv6.net] 
> > Sent: Sunday, October 24, 2010 6:35 AM
> > To: Romascanu, Dan (Dan)
> > Cc: IPFIX Working Group
> > Subject: Re: [IPFIX] AD Review of draft-ipfix-mediators-framework-08
> > 
> > Dear Dan and all,
> > 
> > Thank you for your review.
> > Sorry for late reply. Please see inline.
> > 
> > I will prepare next version until Nov.25.
> 
> Please do. 
> 
> > 
> > On Tue, 12 Oct 2010 14:17:12 +0200
> > "Romascanu, Dan (Dan)"  wrote:
> > 
> > > Please find below the AD review of
> > > 
> > > This document is in quite good shape. I would however 
> > suggest to deal 
> > > with the issues in this review before sending the document 
> > to the IETF 
> > > Last Call.
> > > 
> > > The technical comments are marked Tx and the editorial comments are 
> > > marked Ex.
> > > 
> > > T1. Sections 5.2, 5.3: It is not clear what you mean when you say 
> > > 'This function must be configurable' - does this mean that some 
> > > parameters related to this function are configurable (which 
> > ones?), or 
> > > that 'Activation of this function must be configurable'?
> > > 
> > 
> > In section 5.2, some parameters must be configurable. That 
> > implies there is no parameter to be transmitted just like the 
> > case of IPFIX proxy for original Exporter.
> >  
> > 5.2.  Exporting Process
> > 
> > snip
> > 
> >    o  Transmitting the origin (e.g., Observation Point, Observation
> >       Domain ID, Original Exporter IP address, etc.) of the data in
> >       additional Data Record fields or additional Data Records.  These
> >       parameters related to this function must be configurable.
> > 


According to IPFIX architecture document(rfc5470), it said that some
paramaters should be configurable. This framework follows it.
 
   o  Transmitting the origin (e.g., Observation Point, Observation
      Domain ID, Original Exporter IP address, etc.) of the data in
      additional Data Record fields or additional Data Records.  The
      parameters that represent the origin should be configurable.

> 
> OK - it is probably better  s/These parameters/The parameters/
> 
> > In section 5.3, Activation of this function must be configurable.
> > 
> > 5.3.  Intermediate Process
> > 
> > snip
> > 
> >    o  Reporting statistics and interpretations for IPFIX Metering
> >       Processes, PSAMP Metering Processes, and Exporting 
> > Processes from
> >       an Original Exporter.  See section 4 of [RFC5101] and 
> > section 6 of
> >       [RFC5476] for relevant statistics data structures and
> >       interpretations, respectively.  Activation of this function must
> >       be configurable.
> 
   o  Reporting statistics and interpretations for IPFIX Metering
      Processes, PSAMP Metering Processes, and Exporting Processes from
      an Original Exporter.  See section 4 of [RFC5101] and section 6 of
      [RFC5476] for relevant statistics data structures and
      interpretations, respectively.  Activation of this function should
      be configurable.

> OK. 
> 
> > 
> > > T2. Same sections and phrase. This seems to me a very clear 
> > > architectural requirement where RFC 2119 capitalized MUST would fit.
> > > Please consider this as a non-blocking comment. 
> > > 
> > 
> > In RFC5470(IPFIX Architecture),  this does not use capitalized "MUST"
> > as an informational document, although it uses a lot of 
> > "must" or "may".
> > 
> > The purpose of the document  expands the functionality of 
> > IPFIX Architecture, therefore the document follows the rule 
> > of RFC5470.
> > Capitalized letter will be used in later document like 
> > Mediator protocol.
> > 
> > Is it OK?
> > 
> 
> OK. 
> 
> > > T3. In 5.3 'This relation can be configurable' - same 
> > question as at T1.
> > > 
> > > 
> > 
> > I would like to remove the sentence "This relation can be 
> > configurable".
> > The phrase already said that  it maintains configurable relation.
> > 
> > 5.3.  Intermediate Process
> > 
> > snip
> > 
> >    o  Maintaining the configurable relation between Collecting
> >       Process(es)/Metering Process(es) and Exporting Process(es)/other
> >       Intermediate Process(es).
> > 
> 
> OK. 
> 
> > > T4. Section 5.3.2.1: 
> > > 
> > >       Maintaining the mapping information about Transport Sessions,
> > >       Observation Domain IDs, and Template IDs on the incoming and
> > >       outgoing sides to ensure the appropriateness of the 
> > scope field
> > >       values in Data Records defined by Options Templates 
> > and of IPFIX
> > >       Template Withdrawal Messages.
> > > 
> > > I could not figure out what 'the appropriateness of the scope field 
> > > values' means.
> > 
> > I would like to improve the following.
> > 
> > Maintaining the mapping information about Transport Sessions, 
> > Observation Domain IDs, and Template IDs on the incoming and 
> > outgoing sides in order to ensure the consistency of scope 
> > field values of incoming and outgoing Data Records defined by 
> > Options Templates.
> > 
> > 
> 
> OK. 

I would like to add about the consistency of Template IDs of
Template Withdrawal Messages.

   o  Maintaining the mapping information about Transport Sessions,
      Observation Domain IDs, and Template IDs on the incoming and
      outgoing sides in order to ensure the consistency of scope field
      values of incoming and outgoing Data Records defined by Options
      Templates, and of Template IDs of incoming and outgoing IPFIX
      Template Withdrawal Messages.

Regards,
Atsushi
--- 
Atsushi KOBAYASHI  


From root@core3.amsl.com  Mon Oct 25 04:00:02 2010
Return-Path: 
X-Original-To: ipfix@ietf.org
Delivered-To: ipfix@core3.amsl.com
Received: by core3.amsl.com (Postfix, from userid 0) id 232503A6990; Mon, 25 Oct 2010 04:00:01 -0700 (PDT)
From: Internet-Drafts@ietf.org
To: i-d-announce@ietf.org
Content-Type: Multipart/Mixed; Boundary="NextPart"
Mime-Version: 1.0
Message-Id: <20101025110002.232503A6990@core3.amsl.com>
Date: Mon, 25 Oct 2010 04:00:02 -0700 (PDT)
Cc: ipfix@ietf.org
Subject: [IPFIX] I-D Action:draft-ietf-ipfix-configuration-model-08.txt
X-BeenThere: ipfix@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: IPFIX WG discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 25 Oct 2010 11:00:02 -0000

--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the IP Flow Information Export Working Group of the IETF.


	Title           : Configuration Data Model for IPFIX and PSAMP
	Author(s)       : G. Muenz, et al.
	Filename        : draft-ietf-ipfix-configuration-model-08.txt
	Pages           : 125
	Date            : 2010-10-25

This document specifies a data model for configuring and monitoring
Selection Processes, Caches, Exporting Processes, and Collecting
Processes of IPFIX and PSAMP compliant Monitoring Devices using the
NETCONF protocol [RFC4741].  The data model is defined using UML
(Unified Modeling Language) class diagrams and formally specified
using YANG [RFC6020].  The configuration data is encoded in
Extensible Markup Language (XML).

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-ipfix-configuration-model-08.txt

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

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

--NextPart
Content-Type: Message/External-body;
	name="draft-ietf-ipfix-configuration-model-08.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID: <2010-10-25035125.I-D@ietf.org>


--NextPart--

From root@core3.amsl.com  Mon Oct 25 04:45:02 2010
Return-Path: 
X-Original-To: ipfix@ietf.org
Delivered-To: ipfix@core3.amsl.com
Received: by core3.amsl.com (Postfix, from userid 0) id 273703A69B1; Mon, 25 Oct 2010 04:45:02 -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: <20101025114502.273703A69B1@core3.amsl.com>
Date: Mon, 25 Oct 2010 04:45:02 -0700 (PDT)
Cc: ipfix@ietf.org
Subject: [IPFIX] I-D Action:draft-ietf-ipfix-mediators-framework-09.txt
X-BeenThere: ipfix@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: IPFIX WG discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 25 Oct 2010 11:45:02 -0000

--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the IP Flow Information Export Working Group of the IETF.


	Title           : IPFIX Mediation: Framework
	Author(s)       : A. Kobayashi, et al.
	Filename        : draft-ietf-ipfix-mediators-framework-09.txt
	Pages           : 34
	Date            : 2010-10-25

This document describes a framework for IPFIX Mediation.  This
framework extends the IPFIX reference model by defining the IPFIX
Mediator components.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-ipfix-mediators-framework-09.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-mediators-framework-09.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID: <2010-10-25043548.I-D@ietf.org>


--NextPart--

From dromasca@avaya.com  Mon Oct 25 07:13:18 2010
Return-Path: 
X-Original-To: ipfix@core3.amsl.com
Delivered-To: ipfix@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 42B873A6A3A for ; Mon, 25 Oct 2010 07:13:18 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -103.527
X-Spam-Level: 
X-Spam-Status: No, score=-103.527 tagged_above=-999 required=5 tests=[AWL=1.072, BAYES_00=-2.599, GB_I_LETTER=-2, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Z1koyekidEnw for ; Mon, 25 Oct 2010 07:12:59 -0700 (PDT)
Received: from co300216-co-outbound.net.avaya.com (co300216-co-outbound.net.avaya.com [198.152.13.100]) by core3.amsl.com (Postfix) with ESMTP id EE4A73A6A08 for ; Mon, 25 Oct 2010 07:12:33 -0700 (PDT)
X-IronPort-AV: E=Sophos;i="4.58,236,1286164800"; d="scan'208";a="245329063"
Received: from unknown (HELO co300216-co-erhwest.avaya.com) ([198.152.7.5]) by co300216-co-outbound.net.avaya.com with ESMTP; 25 Oct 2010 10:14:19 -0400
X-IronPort-AV: E=Sophos;i="4.58,236,1286164800"; d="scan'208";a="531186313"
Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.14]) by co300216-co-erhwest-out.avaya.com with ESMTP; 25 Oct 2010 10:14:18 -0400
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Date: Mon, 25 Oct 2010 16:14:00 +0200
Message-ID: 
In-Reply-To: <20101025175545.A384.17391CF2@nttv6.net>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: Re[2]: [IPFIX] AD Review of draft-ipfix-mediators-framework-08
Thread-Index: Act0Ix34xXt1E3NjSbmn2bzdxJOBaQAK6sFw
References: <20101024133503.65B9.17391CF2@nttv6.net>  <20101025175545.A384.17391CF2@nttv6.net>
From: "Romascanu, Dan (Dan)" 
To: "Kobayashi Atsushi" 
Cc: IPFIX Working Group 
Subject: Re: [IPFIX] AD Review of draft-ipfix-mediators-framework-08
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, 25 Oct 2010 14:13:18 -0000

Hi Atsushi,

The suggested changes and clarifications are OK with me.=20

Thanks and Regards,

Dan


> -----Original Message-----
> From: Kobayashi Atsushi [mailto:akoba@nttv6.net]=20
> Sent: Monday, October 25, 2010 10:56 AM
> To: Romascanu, Dan (Dan)
> Cc: IPFIX Working Group
> Subject: Re[2]: [IPFIX] AD Review of=20
> draft-ipfix-mediators-framework-08
>=20
> Hi Dan,
>=20
> Thank you for your reply.
> During discussing with co-authors, my answer was a little bit changed.
> Please see in-line.
>=20
> On Sun, 24 Oct 2010 12:44:30 +0200
> "Romascanu, Dan (Dan)"  wrote:
>=20
> > Hi Atsushi,
> >=20
> > Please see my comments in-line.=20
> >=20
> > Thanks and Regards,
> >=20
> > Dan
> >=20
> > > -----Original Message-----
> > > From: Kobayashi Atsushi [mailto:akoba@nttv6.net]
> > > Sent: Sunday, October 24, 2010 6:35 AM
> > > To: Romascanu, Dan (Dan)
> > > Cc: IPFIX Working Group
> > > Subject: Re: [IPFIX] AD Review of=20
> draft-ipfix-mediators-framework-08
> > >=20
> > > Dear Dan and all,
> > >=20
> > > Thank you for your review.
> > > Sorry for late reply. Please see inline.
> > >=20
> > > I will prepare next version until Nov.25.
> >=20
> > Please do.=20
> >=20
> > >=20
> > > On Tue, 12 Oct 2010 14:17:12 +0200
> > > "Romascanu, Dan (Dan)"  wrote:
> > >=20
> > > > Please find below the AD review of
> > > >=20
> > > > This document is in quite good shape. I would however
> > > suggest to deal
> > > > with the issues in this review before sending the document
> > > to the IETF
> > > > Last Call.
> > > >=20
> > > > The technical comments are marked Tx and the editorial comments=20
> > > > are marked Ex.
> > > >=20
> > > > T1. Sections 5.2, 5.3: It is not clear what you mean=20
> when you say=20
> > > > 'This function must be configurable' - does this mean that some=20
> > > > parameters related to this function are configurable (which
> > > ones?), or
> > > > that 'Activation of this function must be configurable'?
> > > >=20
> > >=20
> > > In section 5.2, some parameters must be configurable.=20
> That implies=20
> > > there is no parameter to be transmitted just like the=20
> case of IPFIX=20
> > > proxy for original Exporter.
> > > =20
> > > 5.2.  Exporting Process
> > >=20
> > > snip
> > >=20
> > >    o  Transmitting the origin (e.g., Observation Point,=20
> Observation
> > >       Domain ID, Original Exporter IP address, etc.) of=20
> the data in
> > >       additional Data Record fields or additional Data=20
> Records.  These
> > >       parameters related to this function must be configurable.
> > >=20
>=20
>=20
> According to IPFIX architecture document(rfc5470), it said=20
> that some paramaters should be configurable. This framework=20
> follows it.
> =20
>    o  Transmitting the origin (e.g., Observation Point, Observation
>       Domain ID, Original Exporter IP address, etc.) of the data in
>       additional Data Record fields or additional Data Records.  The
>       parameters that represent the origin should be configurable.
>=20
> >=20
> > OK - it is probably better  s/These parameters/The parameters/
> >=20
> > > In section 5.3, Activation of this function must be configurable.
> > >=20
> > > 5.3.  Intermediate Process
> > >=20
> > > snip
> > >=20
> > >    o  Reporting statistics and interpretations for IPFIX Metering
> > >       Processes, PSAMP Metering Processes, and Exporting=20
> Processes=20
> > > from
> > >       an Original Exporter.  See section 4 of [RFC5101]=20
> and section=20
> > > 6 of
> > >       [RFC5476] for relevant statistics data structures and
> > >       interpretations, respectively.  Activation of this=20
> function must
> > >       be configurable.
> >=20
>    o  Reporting statistics and interpretations for IPFIX Metering
>       Processes, PSAMP Metering Processes, and Exporting=20
> Processes from
>       an Original Exporter.  See section 4 of [RFC5101] and=20
> section 6 of
>       [RFC5476] for relevant statistics data structures and
>       interpretations, respectively.  Activation of this=20
> function should
>       be configurable.
>=20
> > OK.=20
> >=20
> > >=20
> > > > T2. Same sections and phrase. This seems to me a very clear=20
> > > > architectural requirement where RFC 2119 capitalized=20
> MUST would fit.
> > > > Please consider this as a non-blocking comment.=20
> > > >=20
> > >=20
> > > In RFC5470(IPFIX Architecture),  this does not use=20
> capitalized "MUST"
> > > as an informational document, although it uses a lot of "must" or=20
> > > "may".
> > >=20
> > > The purpose of the document  expands the functionality of IPFIX=20
> > > Architecture, therefore the document follows the rule of RFC5470.
> > > Capitalized letter will be used in later document like Mediator=20
> > > protocol.
> > >=20
> > > Is it OK?
> > >=20
> >=20
> > OK.=20
> >=20
> > > > T3. In 5.3 'This relation can be configurable' - same
> > > question as at T1.
> > > >=20
> > > >=20
> > >=20
> > > I would like to remove the sentence "This relation can be=20
> > > configurable".
> > > The phrase already said that  it maintains configurable relation.
> > >=20
> > > 5.3.  Intermediate Process
> > >=20
> > > snip
> > >=20
> > >    o  Maintaining the configurable relation between Collecting
> > >       Process(es)/Metering Process(es) and Exporting=20
> Process(es)/other
> > >       Intermediate Process(es).
> > >=20
> >=20
> > OK.=20
> >=20
> > > > T4. Section 5.3.2.1:=20
> > > >=20
> > > >       Maintaining the mapping information about=20
> Transport Sessions,
> > > >       Observation Domain IDs, and Template IDs on the=20
> incoming and
> > > >       outgoing sides to ensure the appropriateness of the
> > > scope field
> > > >       values in Data Records defined by Options Templates
> > > and of IPFIX
> > > >       Template Withdrawal Messages.
> > > >=20
> > > > I could not figure out what 'the appropriateness of the scope=20
> > > > field values' means.
> > >=20
> > > I would like to improve the following.
> > >=20
> > > Maintaining the mapping information about Transport Sessions,=20
> > > Observation Domain IDs, and Template IDs on the incoming and=20
> > > outgoing sides in order to ensure the consistency of scope field=20
> > > values of incoming and outgoing Data Records defined by Options=20
> > > Templates.
> > >=20
> > >=20
> >=20
> > OK.=20
>=20
> I would like to add about the consistency of Template IDs of=20
> Template Withdrawal Messages.
>=20
>    o  Maintaining the mapping information about Transport Sessions,
>       Observation Domain IDs, and Template IDs on the incoming and
>       outgoing sides in order to ensure the consistency of scope field
>       values of incoming and outgoing Data Records defined by Options
>       Templates, and of Template IDs of incoming and outgoing IPFIX
>       Template Withdrawal Messages.
>=20
> Regards,
> Atsushi
> ---
> Atsushi KOBAYASHI  
>=20
>=20

From bclaise@cisco.com  Mon Oct 25 07:14:40 2010
Return-Path: 
X-Original-To: ipfix@core3.amsl.com
Delivered-To: ipfix@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6627B3A681B for ; Mon, 25 Oct 2010 07:14:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.492
X-Spam-Level: 
X-Spam-Status: No, score=-2.492 tagged_above=-999 required=5 tests=[AWL=0.106,  BAYES_00=-2.599, HTML_MESSAGE=0.001]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id on36sFpk0GBT for ; Mon, 25 Oct 2010 07:14:34 -0700 (PDT)
Received: from av-tac-bru.cisco.com (weird-brew.cisco.com [144.254.15.118]) by core3.amsl.com (Postfix) with ESMTP id 278403A685B for ; Mon, 25 Oct 2010 07:14:31 -0700 (PDT)
X-TACSUNS: Virus Scanned
Received: from strange-brew.cisco.com (localhost.cisco.com [127.0.0.1]) by av-tac-bru.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id o9PEGEP1000370 for ; Mon, 25 Oct 2010 16:16:14 +0200 (CEST)
Received: from [10.55.43.53] (ams-bclaise-8714.cisco.com [10.55.43.53]) by strange-brew.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id o9PEG5VX011667 for ; Mon, 25 Oct 2010 16:16:09 +0200 (CEST)
Message-ID: <4CC59125.60909@cisco.com>
Date: Mon, 25 Oct 2010 16:16:05 +0200
From: Benoit Claise 
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-GB; rv:1.9.2.11) Gecko/20101013 Thunderbird/3.1.5
MIME-Version: 1.0
To: "ipfix@ietf.org" 
Content-Type: multipart/alternative; boundary="------------030205080908030305080805"
Subject: [IPFIX] New Version Notification for draft-claise-ipfix-mediation-protocol-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, 25 Oct 2010 14:14:40 -0000

This is a multi-part message in MIME format.
--------------030205080908030305080805
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit

Dear all,

A new draft version has been posted.
This draft is now in line with:

[IPFIX-MED-FLOWSEL] Peluso, L., Zseby, T., D'antonio, S., and M. Molina, 
"Flow Selection Techniques", 
draft-ietf-ipfix-flow-selection-tech-02.txt, Internet-Draft work in 
progress, June 2010.

[IPFIX-MED-AGGR] Trammell, B., Boschi, E., and A. Wagner, "Exporting 
Aggregated Flow Data using the IP Flow Information Export (IPFIX) 
Protocol", draft-trammell-ipfix-a9n-01.txt, Internet-Draft work in 
progress, October 2010.

[IPFIX-MED-FMWK] Kobayashi, A., Claise, B., and K. Ishibashi, "IPFIX 
Mediation: Framework", draft-ietf-ipfix-mediators-framework-09, 
Internet-Draft work in progress, October 2010.

[IPFIX-MED-ANON] Boschi, E., Trammell, B. "IP Flow Anonymisation 
Support", draft-ietf-ipfix-anon-05.txt, Internet-Draft work in progress, 
October 2010.

Regards, Benoit.

-------- Original Message --------
Subject: 	New Version Notification for 
draft-claise-ipfix-mediation-protocol-02
Date: 	Mon, 25 Oct 2010 07:08:59 -0700 (PDT)
From: 	IETF I-D Submission Tool 
To: 	bclaise@cisco.com



A new version of I-D, draft-claise-ipfix-mediation-protocol-02.txt has been successfully submitted by Benoit Claise and posted to the IETF repository.

Filename:	 draft-claise-ipfix-mediation-protocol
Revision:	 02
Title:		 Specification of the Protocol for IPFIX Mediations
Creation_date:	 2010-10-25
WG ID:		 Independent Submission
Number_of_pages: 25

Abstract:
This document specifies the IP Flow Information Export

   (IPFIX) protocol specific to the Mediation.



The IETF Secretariat.



--------------030205080908030305080805
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: 7bit



  

    
  
  
    Dear all,

    

    A new draft version has been posted.

    This draft is now in line with:

    
    

    

    
[IPFIX-MED-FLOWSEL]
        Peluso, L., Zseby, T., D'antonio, S., and M. Molina, "Flow
        Selection
        Techniques", draft-ietf-ipfix-flow-selection-tech-02.txt,
Internet-Draft
      work in progress, June 2010.

    
[IPFIX-MED-AGGR] Trammell, B., Boschi, E.,
      and A. Wagner,
      "Exporting Aggregated Flow Data using the IP Flow Information
      Export
      (IPFIX) Protocol", draft-trammell-ipfix-a9n-01.txt, Internet-Draft
      work in
      progress, October 2010.

    
[IPFIX-MED-FMWK] Kobayashi, A., Claise, B.,
      and K. Ishibashi,
      "IPFIX Mediation: Framework",
      draft-ietf-ipfix-mediators-framework-09,
      Internet-Draft work in progress, October 2010.

    
[IPFIX-MED-ANON] Boschi, E., Trammell, B.
      "IP Flow
      Anonymisation Support", draft-ietf-ipfix-anon-05.txt,
      Internet-Draft work
      in progress, October 2010.

    Regards, Benoit.

    

    -------- Original Message --------
    

      
        

          Subject: 
          New Version Notification for
            draft-claise-ipfix-mediation-protocol-02
        

        

          Date: 
          Mon, 25 Oct 2010 07:08:59 -0700 (PDT)
        

        

          From: 
          IETF I-D Submission Tool <idsubmission@ietf.org>
        

        

          To: 
          bclaise@cisco.com
        

      
    

    

    

    
A new version of I-D, draft-claise-ipfix-mediation-protocol-02.txt has been successfully submitted by Benoit Claise and posted to the IETF repository.

Filename:	 draft-claise-ipfix-mediation-protocol
Revision:	 02
Title:		 Specification of the Protocol for IPFIX Mediations
Creation_date:	 2010-10-25
WG ID:		 Independent Submission
Number_of_pages: 25

Abstract:
This document specifies the IP Flow Information Export 

  (IPFIX) protocol specific to the Mediation.
                                                                                  


The IETF Secretariat.



  


--------------030205080908030305080805--

From andrjohn@cisco.com  Mon Oct 25 08:34:31 2010
Return-Path: 
X-Original-To: ipfix@core3.amsl.com
Delivered-To: ipfix@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F18963A6A06 for ; Mon, 25 Oct 2010 08:34:30 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.599
X-Spam-Level: 
X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[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 RgycS7PkM0S0 for ; Mon, 25 Oct 2010 08:34:30 -0700 (PDT)
Received: from rtp-iport-1.cisco.com (rtp-iport-1.cisco.com [64.102.122.148]) by core3.amsl.com (Postfix) with ESMTP id DA0343A689B for ; Mon, 25 Oct 2010 08:34:29 -0700 (PDT)
Authentication-Results: rtp-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AvsEAAVBxUxAZnwN/2dsb2JhbAChXnGgTZwlhUgEik2LLQ
X-IronPort-AV: E=Sophos;i="4.58,236,1286150400"; d="scan'208";a="174740774"
Received: from rtp-core-2.cisco.com ([64.102.124.13]) by rtp-iport-1.cisco.com with ESMTP; 25 Oct 2010 15:36:14 +0000
Received: from cisco.com (mrwint.cisco.com [64.103.71.48]) by rtp-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id o9PFaERN011981; Mon, 25 Oct 2010 15:36:14 GMT
Received: from dhcp-144-254-153-227.cisco.com (dhcp-144-254-153-227.cisco.com [144.254.153.227]) by cisco.com (8.11.7p3+Sun/8.8.8) with ESMTP id o9PFaC816508; Mon, 25 Oct 2010 16:36:13 +0100 (BST)
Mime-Version: 1.0 (Apple Message framework v1078)
Content-Type: text/plain; charset=us-ascii
From: Andrew Johnson 
In-Reply-To: <4CC5641C.8050005@cisco.com>
Date: Mon, 25 Oct 2010 16:41:02 +0100
Content-Transfer-Encoding: quoted-printable
Message-Id: <7F4FC363-0F1A-49A3-9522-B70E8A972C0A@cisco.com>
References: <4CC5641C.8050005@cisco.com>
To: Nevil Brownlee 
X-Mailer: Apple Mail (2.1078)
Cc: IPFIX Working Group 
Subject: Re: [IPFIX] Two WGLCs starting now
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, 25 Oct 2010 15:34:31 -0000

On 18th Oct 2010, Nevil Brownlee wrote:
> Hi all:
>=20
> We have two drafts waiting for Working Group Last Call.
> Their WGLCs start now, and will finish on 3 November (the
> Wednesday before the Beijing IETF).
>=20
> The drafts are:
>  1. draft-ietf-ipfix-structured-data-03.txt
>        Second WGLC for this draft, the first was back in July
>        for the -01 version.  There's been a *lot* of discussion
>        on the mailing list since!)
>  2. draft-ietf-ipfix-configuration-model-07.txt
>        We were waiting for the YANG RFCs to be published for this one.

I see that a little more that the RFC references have changed with =
version 8, but I'm happy with this draft.


Andrew


From muenz@net.in.tum.de  Tue Oct 26 02:50:09 2010
Return-Path: 
X-Original-To: ipfix@core3.amsl.com
Delivered-To: ipfix@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C97F13A68FC for ; Tue, 26 Oct 2010 02:50:09 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.249
X-Spam-Level: 
X-Spam-Status: No, score=-2.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vTAJrtlwv+el for ; Tue, 26 Oct 2010 02:50:09 -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 9D6FB3A67A1 for ; Tue, 26 Oct 2010 02:50:08 -0700 (PDT)
Received: from [46.5.34.49] (HSI-KBW-046-005-034-049.hsi8.kabel-badenwuerttemberg.de [46.5.34.49]) by mail.net.in.tum.de (Postfix) with ESMTPSA id E243E2069BFB for ; Tue, 26 Oct 2010 11:52:09 +0200 (CEST)
Message-ID: <4CC6A4EA.4090307@net.in.tum.de>
Date: Tue, 26 Oct 2010 11:52:42 +0200
From: Gerhard Muenz 
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-GB; rv:1.9.2.11) Gecko/20101013 Thunderbird/3.1.5
MIME-Version: 1.0
To: "ipfix@ietf.org" 
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms030500070604000205030609"
X-Virus-Scanned: ClamAV using ClamSMTP
Subject: [IPFIX] Fwd: I-D Action:draft-ietf-ipfix-configuration-model-08.txt
X-BeenThere: ipfix@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: IPFIX WG discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 26 Oct 2010 09:50:09 -0000

This is a cryptographically signed message in MIME format.

--------------ms030500070604000205030609
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable


Dear all,

Changes in this new version of the draft are made based on the feedback
I got from Martin Bjorklund, Andy Bierman, J=FCrgen Sch=F6nw=E4lder and
Ladislav Lhotka in August.

Regards,
Gerhard


-------- Original Message --------
Subject: [IPFIX] I-D Action:draft-ietf-ipfix-configuration-model-08.txt
Date: Mon, 25 Oct 2010 04:00:02 -0700 (PDT)
From: Internet-Drafts@ietf.org
To: i-d-announce@ietf.org
CC: ipfix@ietf.org

A New Internet-Draft is available from the on-line Internet-Drafts
directories.
This draft is a work item of the IP Flow Information Export Working
Group of the IETF.


	Title           : Configuration Data Model for IPFIX and PSAMP
	Author(s)       : G. Muenz, et al.
	Filename        : draft-ietf-ipfix-configuration-model-08.txt
	Pages           : 125
	Date            : 2010-10-25

This document specifies a data model for configuring and monitoring
Selection Processes, Caches, Exporting Processes, and Collecting
Processes of IPFIX and PSAMP compliant Monitoring Devices using the
NETCONF protocol [RFC4741].  The data model is defined using UML
(Unified Modeling Language) class diagrams and formally specified
using YANG [RFC6020].  The configuration data is encoded in
Extensible Markup Language (XML).

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-ipfix-configuration-model-=
08.txt

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

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.



--------------ms030500070604000205030609
Content-Type: application/pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIO5jCC
BEYwggOvoAMCAQICEGb9R+PCGeToms2Z3fU6yyQwDQYJKoZIhvcNAQEFBQAwXzELMAkGA1UE
BhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMTcwNQYDVQQLEy5DbGFzcyAxIFB1Ymxp
YyBQcmltYXJ5IENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA1MTAyODAwMDAwMFoXDTE1
MTAyNzIzNTk1OVowgd0xCzAJBgNVBAYTAlVTMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEf
MB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazE7MDkGA1UECxMyVGVybXMgb2YgdXNl
IGF0IGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9ycGEgKGMpMDUxHjAcBgNVBAsTFVBlcnNv
bmEgTm90IFZhbGlkYXRlZDE3MDUGA1UEAxMuVmVyaVNpZ24gQ2xhc3MgMSBJbmRpdmlkdWFs
IFN1YnNjcmliZXIgQ0EgLSBHMjCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMnf
rOfq+PgDFMQAktXBfjbCPO98chXLwKuMPRyVzm8eECw/AO2XJua2x+atQx0/pIdHR0w+VPhs
+Mf8sZ69MHC8l7EDBeqV8a1AxUR6SwWi8mD81zplYu//EHuiVrvFTnAt1qIfPO2wQuhejVch
rKaZ2RHp0hoHwHRHQgv8xTTq/ea6JNEdCBU3otdzzwFBL2OyOj++pRpu9MlKWz2VphW7NQIZ
+dTvvI8OcXZZu0u2Ptb8Whb01g6J8kn+bAztFenZiHWcec5gJ925rXXOL3OVekA6hXVJsLjf
aLyrzROChRFQo+A8C67AClPN1zBvhTJGG+RJEMJs4q8fef/btLUCAwEAAaOB/zCB/DASBgNV
HRMBAf8ECDAGAQH/AgEAMEQGA1UdIAQ9MDswOQYLYIZIAYb4RQEHFwEwKjAoBggrBgEFBQcC
ARYcaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYTALBgNVHQ8EBAMCAQYwEQYJYIZIAYb4
QgEBBAQDAgEGMC4GA1UdEQQnMCWkIzAhMR8wHQYDVQQDExZQcml2YXRlTGFiZWwzLTIwNDgt
MTU1MB0GA1UdDgQWBBQRfV4ZfTwE32ps1qKKGj8x2DuUUjAxBgNVHR8EKjAoMCagJKAihiBo
dHRwOi8vY3JsLnZlcmlzaWduLmNvbS9wY2ExLmNybDANBgkqhkiG9w0BAQUFAAOBgQA8o9oC
YzrEk6qrctPcrVA4HgyeFkqIt+7r2f8PjZWg1rv6aguuYYTYaEeJ70+ssh9JQZtJM3aTi55u
uUMcYL3C3Ioth8FFwBFyBBprJCpsb+f8BxMp0Hc6I+f1wYVoGb/GAVQgGa41gsxiPGEJxvTV
67APpp8zhZrTcY5Qj5ndYjCCBUowggQyoAMCAQICEF0kYdlVNx5E1qcmxun5IrswDQYJKoZI
hvcNAQEFBQAwgd0xCzAJBgNVBAYTAlVTMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0G
A1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazE7MDkGA1UECxMyVGVybXMgb2YgdXNlIGF0
IGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9ycGEgKGMpMDUxHjAcBgNVBAsTFVBlcnNvbmEg
Tm90IFZhbGlkYXRlZDE3MDUGA1UEAxMuVmVyaVNpZ24gQ2xhc3MgMSBJbmRpdmlkdWFsIFN1
YnNjcmliZXIgQ0EgLSBHMjAeFw0xMDAxMDIwMDAwMDBaFw0xMTAxMDIyMzU5NTlaMIIBEzEX
MBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0IE5ldHdv
cmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEgSW5jb3JwLiBi
eSBSZWYuLExJQUIuTFREKGMpOTgxHjAcBgNVBAsTFVBlcnNvbmEgTm90IFZhbGlkYXRlZDEz
MDEGA1UECxMqRGlnaXRhbCBJRCBDbGFzcyAxIC0gTmV0c2NhcGUgRnVsbCBTZXJ2aWNlMRYw
FAYDVQQDFA1HZXJoYXJkIE11ZW56MSIwIAYJKoZIhvcNAQkBFhNtdWVuekBuZXQuaW4udHVt
LmRlMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAl/YDW9cnAXJjesGhwtGwj9JN
IHWXQ7QA18s+wGZNsQY0k4eKBeLTk/RAiC1hP+uQAXLoGQHQF/ljjQCQeRmnsN6w04iAzKVo
Ru+NP7Y6ipn8uztx+z0Y3w43CO+LWUudp3PIF3+Fm2zwsAFXj/IYy/8Kq6m9+nQgYO/D4HoN
DDR3//GepXghK0x93gR0GCkm8pgKINHNBD47/IZbDe/cIpAC9HaoxCeLiB1QaCDIYPIrJ0Vx
kk0crAA0tPaMDjdSQTmNRAn2P+7Wg7K+DLvauBHfxLs8PrsolI+XdwiBu6henK9nPxvtoHmm
mfxcdslKLbS9Xz2rHxi6PVVgv1ubWwIDAQABo4HMMIHJMAkGA1UdEwQCMAAwRAYDVR0gBD0w
OzA5BgtghkgBhvhFAQcXATAqMCgGCCsGAQUFBwIBFhxodHRwczovL3d3dy52ZXJpc2lnbi5j
b20vcnBhMAsGA1UdDwQEAwIFoDAdBgNVHSUEFjAUBggrBgEFBQcDBAYIKwYBBQUHAwIwSgYD
VR0fBEMwQTA/oD2gO4Y5aHR0cDovL0luZEMxRGlnaXRhbElELWNybC52ZXJpc2lnbi5jb20v
SW5kQzFEaWdpdGFsSUQuY3JsMA0GCSqGSIb3DQEBBQUAA4IBAQBPU7OeWNo2LRzsdu/RuuAk
L5cj/RzeZ0xv9q4K/eosy9dRu45XACpPvb0fjc3u/dsY4m3jDqzUsB02IrrnF9jpEo10BJPw
b/RZ7NaU7jC/gEknL3bSXiD2PVwL4ZI5ChH5+TJUboWhVh+FpOwOfP/yKk7wQM/46iXXzRIz
enk0rcJp71k4aQgQTML3/8MDeD6TUipuQwQMY9n6T6DsNd/6JpGa+x9ZX4HIEG6+EWwQ85G5
vGfDBaq3dFrksHE75u7b7pf75wm9HIFU2SDHP2tymTHJt/XM9sqP1URIC57s+uZV0/d5KRc1
uPcJ0FAnAiC9o7ybPIh27shiq0FvOEwfMIIFSjCCBDKgAwIBAgIQXSRh2VU3HkTWpybG6fki
uzANBgkqhkiG9w0BAQUFADCB3TELMAkGA1UEBhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJ
bmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTswOQYDVQQLEzJUZXJtcyBv
ZiB1c2UgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYSAoYykwNTEeMBwGA1UECxMV
UGVyc29uYSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5WZXJpU2lnbiBDbGFzcyAxIEluZGl2
aWR1YWwgU3Vic2NyaWJlciBDQSAtIEcyMB4XDTEwMDEwMjAwMDAwMFoXDTExMDEwMjIzNTk1
OVowggETMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1
c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJ
bmNvcnAuIGJ5IFJlZi4sTElBQi5MVEQoYyk5ODEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFs
aWRhdGVkMTMwMQYDVQQLEypEaWdpdGFsIElEIENsYXNzIDEgLSBOZXRzY2FwZSBGdWxsIFNl
cnZpY2UxFjAUBgNVBAMUDUdlcmhhcmQgTXVlbnoxIjAgBgkqhkiG9w0BCQEWE211ZW56QG5l
dC5pbi50dW0uZGUwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCX9gNb1ycBcmN6
waHC0bCP0k0gdZdDtADXyz7AZk2xBjSTh4oF4tOT9ECILWE/65ABcugZAdAX+WONAJB5Gaew
3rDTiIDMpWhG740/tjqKmfy7O3H7PRjfDjcI74tZS52nc8gXf4WbbPCwAVeP8hjL/wqrqb36
dCBg78Pgeg0MNHf/8Z6leCErTH3eBHQYKSbymAog0c0EPjv8hlsN79wikAL0dqjEJ4uIHVBo
IMhg8isnRXGSTRysADS09owON1JBOY1ECfY/7taDsr4Mu9q4Ed/Euzw+uyiUj5d3CIG7qF6c
r2c/G+2geaaZ/Fx2yUottL1fPasfGLo9VWC/W5tbAgMBAAGjgcwwgckwCQYDVR0TBAIwADBE
BgNVHSAEPTA7MDkGC2CGSAGG+EUBBxcBMCowKAYIKwYBBQUHAgEWHGh0dHBzOi8vd3d3LnZl
cmlzaWduLmNvbS9ycGEwCwYDVR0PBAQDAgWgMB0GA1UdJQQWMBQGCCsGAQUFBwMEBggrBgEF
BQcDAjBKBgNVHR8EQzBBMD+gPaA7hjlodHRwOi8vSW5kQzFEaWdpdGFsSUQtY3JsLnZlcmlz
aWduLmNvbS9JbmRDMURpZ2l0YWxJRC5jcmwwDQYJKoZIhvcNAQEFBQADggEBAE9Ts55Y2jYt
HOx279G64CQvlyP9HN5nTG/2rgr96izL11G7jlcAKk+9vR+Nze792xjibeMOrNSwHTYiuucX
2OkSjXQEk/Bv9Fns1pTuML+ASScvdtJeIPY9XAvhkjkKEfn5MlRuhaFWH4Wk7A58//IqTvBA
z/jqJdfNEjN6eTStwmnvWThpCBBMwvf/wwN4PpNSKm5DBAxj2fpPoOw13/omkZr7H1lfgcgQ
br4RbBDzkbm8Z8MFqrd0WuSwcTvm7tvul/vnCb0cgVTZIMc/a3KZMcm39cz2yo/VREgLnuz6
5lXT93kpFzW49wnQUCcCIL2jvJs8iHbuyGKrQW84TB8xggTsMIIE6AIBATCB8jCB3TELMAkG
A1UEBhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBU
cnVzdCBOZXR3b3JrMTswOQYDVQQLEzJUZXJtcyBvZiB1c2UgYXQgaHR0cHM6Ly93d3cudmVy
aXNpZ24uY29tL3JwYSAoYykwNTEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTcw
NQYDVQQDEy5WZXJpU2lnbiBDbGFzcyAxIEluZGl2aWR1YWwgU3Vic2NyaWJlciBDQSAtIEcy
AhBdJGHZVTceRNanJsbp+SK7MAkGBSsOAwIaBQCgggLOMBgGCSqGSIb3DQEJAzELBgkqhkiG
9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTEwMTAyNjA5NTI0MlowIwYJKoZIhvcNAQkEMRYEFOyW
37nRMs5DtPkd0TGVxeTw95XcMF8GCSqGSIb3DQEJDzFSMFAwCwYJYIZIAWUDBAECMAoGCCqG
SIb3DQMHMA4GCCqGSIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG
9w0DAgIBKDCCAQMGCSsGAQQBgjcQBDGB9TCB8jCB3TELMAkGA1UEBhMCVVMxFzAVBgNVBAoT
DlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTswOQYD
VQQLEzJUZXJtcyBvZiB1c2UgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYSAoYykw
NTEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5WZXJpU2lnbiBD
bGFzcyAxIEluZGl2aWR1YWwgU3Vic2NyaWJlciBDQSAtIEcyAhBdJGHZVTceRNanJsbp+SK7
MIIBBQYLKoZIhvcNAQkQAgsxgfWggfIwgd0xCzAJBgNVBAYTAlVTMRcwFQYDVQQKEw5WZXJp
U2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazE7MDkGA1UECxMy
VGVybXMgb2YgdXNlIGF0IGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9ycGEgKGMpMDUxHjAc
BgNVBAsTFVBlcnNvbmEgTm90IFZhbGlkYXRlZDE3MDUGA1UEAxMuVmVyaVNpZ24gQ2xhc3Mg
MSBJbmRpdmlkdWFsIFN1YnNjcmliZXIgQ0EgLSBHMgIQXSRh2VU3HkTWpybG6fkiuzANBgkq
hkiG9w0BAQEFAASCAQBdEFiX9m8DPscet1leeMcx5JGXamz7W1DXp8EIicpBrxaQgpORevvu
5r3KoOosGh66FpitGjzew6B8ofzO2YttmluOL8NHPMk0qRvzfO8IwjmAtjxpkum5VsM2UCWm
BdUvGY608p+CnKiZh8x3mNwW/Jzc2+jXVqQtWwVYXfc4J4V+S5Dzcd9m7Zu1TC7l6hrrMIzv
Whjt+YjlQnEywUaenTvnbXPcUhZq6731yy/y2jw8KCfIcivt+PlE/uptgUpgQbZ2iokOZ5oB
Kl4MEehQWGRLuztdnkkrGgESNJnbqJuumoW9ySUe7+D9k4z87IVPTds6Qbb42VdDHE7ZiRQA
AAAAAAAA
--------------ms030500070604000205030609--

From bclaise@cisco.com  Tue Oct 26 05:10:38 2010
Return-Path: 
X-Original-To: ipfix@core3.amsl.com
Delivered-To: ipfix@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8FB063A67D7 for ; Tue, 26 Oct 2010 05:10:38 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.997
X-Spam-Level: 
X-Spam-Status: No, score=-1.997 tagged_above=-999 required=5 tests=[AWL=-0.398, BAYES_00=-2.599, J_BACKHAIR_36=1]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bFKXumpdlobY for ; Tue, 26 Oct 2010 05:10:36 -0700 (PDT)
Received: from av-tac-bru.cisco.com (weird-brew.cisco.com [144.254.15.118]) by core3.amsl.com (Postfix) with ESMTP id 993FF3A67B2 for ; Tue, 26 Oct 2010 05:10:33 -0700 (PDT)
X-TACSUNS: Virus Scanned
Received: from strange-brew.cisco.com (localhost.cisco.com [127.0.0.1]) by av-tac-bru.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id o9QC8XOv027652; Tue, 26 Oct 2010 14:08:33 +0200 (CEST)
Received: from [10.55.43.53] (ams-bclaise-8714.cisco.com [10.55.43.53]) by strange-brew.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id o9QC8V97004568; Tue, 26 Oct 2010 14:08:32 +0200 (CEST)
Message-ID: <4CC6C4BF.8060505@cisco.com>
Date: Tue, 26 Oct 2010 14:08:31 +0200
From: Benoit Claise 
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-GB; rv:1.9.2.11) Gecko/20101013 Thunderbird/3.1.5
MIME-Version: 1.0
To: Hadriel Kaplan 
References: <646D5D04-3C32-4576-8925-550F3014B59E@acmepacket.com> <4CB0E3FC.7000700@cisco.com> <15772757-4B36-42E0-ACA6-F092B251E865@acmepacket.com> <4CB338A0.40205@cisco.com> <0F683FA7-D364-4BAD-AB08-8D0212353E5D@acmepacket.com>
In-Reply-To: <0F683FA7-D364-4BAD-AB08-8D0212353E5D@acmepacket.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: quoted-printable
Cc: IETF IPFIX Working Group 
Subject: Re: [IPFIX] questions about structured-data draft
X-BeenThere: ipfix@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: IPFIX WG discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 26 Oct 2010 12:10:38 -0000

Hadriel,

Let me come back to this one, now that the IETF deadlines are over.
> On Oct 11, 2010, at 12:17 PM, Benoit Claise wrote:
>
>> We have to pay attention to one thing. Your basicList examples (such a=
s
>> bgpPathList) make perfect sense and could be easily specified in IPFIX=
 IANA.
>> However, we will have to decide how far we want to go in defining new
>> IEs based on subTemplateList and subTemplateMultiList...
> Yeah I can't grok how that would work.
>
> So maybe I should describe the problem I'm trying to solve and see if s=
tructured-data is the solution or not.  (sorry about the email length)
>
> We have this SIP-CLF proposal, where we export/record info about the SI=
P Message. (as you well know :)
> All the current mandatory fields we wish to export are either already e=
xisting IEs, such as sourceIPv4Address, or proposed new ones specific to =
SIP like sipToURI.  None of them can appear more than once in a SIP Messa=
ge, so we don't have to deal with lists.
>
> We want to make it extensible, by letting vendors export additional inf=
o in the record.  We could do that with vendor-specific PENs (and undoubt=
edly people will), but I was going to submit a draft for registering IEs =
for things we expect to be somewhat popular to add, or at least that some=
one might want to add and having a defined IE for already would be useful=
=2E  For example, stuff from a SIP Contact, P-Asserted-Identity, or P-Pre=
ferred-Identity headers.
make sense.
> Some SIP header types can appear multiple times, some cannot.  So havin=
g a basicList for the ones that can solves that.
make sense.
>
>
> The tricky thing about SIP headers, though, is that their contents are =
not just a single "value".  They are really composed of distinct fields. =
 There's a list of zero or more header parameters, a header value, and wi=
thin that header value there could be a URI, display-name, or some other =
combination of discrete fields.  For reporting purposes, one generally wa=
nts to segregate out such fields if possible, so that the collector/reade=
r does not need to understand SIP ABNF rules and do that work itself.  Bu=
t for some headers recording the whole field makes sense.
>
> So as I was writing up the stuff people may want to record, it became o=
bvious that creating a unique IE for each and every field, of each and ev=
ery SIP header, is untenable.  It would mean, for example, that you'd hav=
e a sipContactURI, sipContactDisplayName, sipContactParamName, sipContact=
ParamValue, as well as a sipPAssertedIdURI, sipPAssertedIdDisplayName, si=
pPAssertedIdParamName, sipPAssertedIdParamValue, as well as sipPPreferred=
IdURI, sipPPreferredIdDisplayName, sipPPreferredIdParamName, and sipPPref=
erredIdParamValue.  And that's only the tip of iceberg.  There are curren=
tly *106* SIP headers registered in IANA, and a half-dozen more in drafts=
 at various stages.  Not all of them follow the pattern of having a URI a=
nd optional display name (most don't, but many do); but even if you creat=
ed a "HeaderValue" and "ParamName" and "ParamValue" IE type for each, that's a lot. (and you'd exhaust your IE=
 number space if you did this for other protocols like H.323 and HTTP and=
 RTSP)
>
> What you'd really want is to create a few new abstract data types of "s=
ipGenericHeader", "sipUriHeader" and "sipParam" in IANA, which would be a=
 composite of the pieces, and then define a sipHeader IE for each o=
f the 106 header types, based on their specific abstract data type.  For =
example a sipPAssertedIdHeader IE, which is of abstract type sipUriHeader=
, with a URI, display-name, and a basicList of sipParam (and sipParam wou=
ld be a name/value pair).
>
> Essentially, what this calls for is the ability to take *generic* data =
types, such as URI or paramValue (both of which are based on string), and=
 build upon them to form more complex (and unique) data types to eventual=
ly yield a sipContactHeader IE.  It's not clear to me if the structured-d=
ata draft is actually meant to accomplish that, or if it's just meant to =
take *specific* data type IEs and let them appear multiple times in a str=
ucture, but without changing their meaning.
Initially, the structured data was not meant to accomplish this: it was=20
simply to give some semantic about the existing IEs
However, there is nothing that prevents us to do for the coming for new, =

more complex IE definitions.
Even with a few new abstract complex data types such "sipGenericHeader", =

we would still need the definition of the 106 header fields, as we don't =

want to export a opaque field.
>
>
> In other words, you can't record an ACL list as just a basicList of sou=
rceIPv4Address, because "sourceIPv4Address" has the meaning of being the =
source IPv4 address of the flow's actual *packet*, not an access control =
it may or may not match to.  You'd have to create an IE for aclSourceIPv4=
Address and put it in a basicList.
Yes.

Regards, Benoit.
> -hadriel
>
>



From bclaise@cisco.com  Tue Oct 26 05:21:36 2010
Return-Path: 
X-Original-To: ipfix@core3.amsl.com
Delivered-To: ipfix@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 57E023A694C for ; Tue, 26 Oct 2010 05:21:36 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.494
X-Spam-Level: 
X-Spam-Status: No, score=-2.494 tagged_above=-999 required=5 tests=[AWL=0.105,  BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id G1yQR1+OWoeC for ; Tue, 26 Oct 2010 05:21:35 -0700 (PDT)
Received: from av-tac-bru.cisco.com (weird-brew.cisco.com [144.254.15.118]) by core3.amsl.com (Postfix) with ESMTP id A66713A682E for ; Tue, 26 Oct 2010 05:21:34 -0700 (PDT)
X-TACSUNS: Virus Scanned
Received: from strange-brew.cisco.com (localhost.cisco.com [127.0.0.1]) by av-tac-bru.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id o9QCFp4Z028992; Tue, 26 Oct 2010 14:15:51 +0200 (CEST)
Received: from [10.55.43.53] (ams-bclaise-8714.cisco.com [10.55.43.53]) by strange-brew.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id o9QCFmUL016355; Tue, 26 Oct 2010 14:15:48 +0200 (CEST)
Message-ID: <4CC6C674.1060309@cisco.com>
Date: Tue, 26 Oct 2010 14:15:48 +0200
From: Benoit Claise 
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-GB; rv:1.9.2.11) Gecko/20101013 Thunderbird/3.1.5
MIME-Version: 1.0
To: sujay gupta 
References: <4C80CBE8.2080708@cisco.com>	 
In-Reply-To: 
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Cc: "ipfix@ietf.org" 
Subject: Re: [IPFIX] Flow in IPFIX -> not only IP Flows
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 Oct 2010 12:21:36 -0000

Hi Sujay,
> Hi Benoit,
>
> I believe it is a stance which should be accepted by all, as the name
> (IPFIX) and most usage
> IMO is layer 3.
>
> Could someone point out as to why the protocol was called as 'IP'  FIX??
Historical reasons ;-)
> sFlow&  other groups clearly focus on L2+L3.
So does IPFIX now.

Regards, Benoit.
> BR,
> -Sujay
>
>
> On Fri, Sep 3, 2010 at 5:46 PM, Haruhiko Nishida  wrote:
>> Benoit,
>> I support your point. IPFIX should be a next generation of both
>> netflow and sflow.
>> -- Haru Nishida, NTT
>> On 2010/09/03, at 19:20, Benoit Claise wrote:
>>
>> Dear all,
>>
>> Here is one problem that was anticipated...
>>
>> For whatever reasons at that point in time, RFC 5101 limits the Flow
>> definition to IP packets
>>
>>     IP Traffic Flow or Flow
>>
>>        There are several definitions of the term 'flow' being used by the
>>        Internet community.  Within the context of IPFIX we use the
>>        following definition:
>>
>>        A Flow is defined as a set of IP packets passing an Observation
>>        Point in the network during a certain time interval.  All packets
>>        belonging to a particular Flow have a set of common properties.
>>        Each property is defined as the result of applying a function to
>>        the values of:
>>
>>           1. one or more packet header fields (e.g., destination IP
>>              address), transport header fields (e.g., destination port
>>              number), or application header fields (e.g., RTP header
>>              fields [RFC3550]).
>>
>>           2. one or more characteristics of the packet itself (e.g.,
>>              number of MPLS labels, etc...).
>>
>>           3. one or more of fields derived from packet treatment (e.g.,
>>              next hop IP address, the output interface, etc...).
>>
>>        A packet is defined as belonging to a Flow if it completely
>>        satisfies all the defined properties of the Flow.
>>
>>        This definition covers the range from a Flow containing all
>>        packets observed at a network interface to a Flow consisting of
>>        just a single packet between two applications.  It includes
>>        packets selected by a sampling mechanism.
>>
>> However, we know that IPFIX cover more than IP.
>> http://www.iana.org/assignments/ipfix/ipfix.xhtml mentions sourceMacAddress,
>> ethernetPayloadLength, etc...
>> And we know that IPFIX became a kind of generic streaming protocol.
>>
>> Talking in the context of the NGN networks at the ITU, there are some
>> reluctance to adopt this Flow definition limited to IP packets.
>> Isn't it time to do something about this definition?
>>
>> Regards, Benoit.
>>
>>
>>
>>
>>
>> _______________________________________________
>> IPFIX mailing list
>> IPFIX@ietf.org
>> https://www.ietf.org/mailman/listinfo/ipfix
>>
>>
>> _______________________________________________
>> IPFIX mailing list
>> IPFIX@ietf.org
>> https://www.ietf.org/mailman/listinfo/ipfix
>>
>>


From bclaise@cisco.com  Tue Oct 26 05:33:11 2010
Return-Path: 
X-Original-To: ipfix@core3.amsl.com
Delivered-To: ipfix@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 60DD13A6962 for ; Tue, 26 Oct 2010 05:33:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.495
X-Spam-Level: 
X-Spam-Status: No, score=-2.495 tagged_above=-999 required=5 tests=[AWL=0.104,  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 9XN7qAn+dvmQ for ; Tue, 26 Oct 2010 05:32:59 -0700 (PDT)
Received: from av-tac-bru.cisco.com (weird-brew.cisco.com [144.254.15.118]) by core3.amsl.com (Postfix) with ESMTP id A83D33A6952 for ; Tue, 26 Oct 2010 05:32:58 -0700 (PDT)
X-TACSUNS: Virus Scanned
Received: from strange-brew.cisco.com (localhost.cisco.com [127.0.0.1]) by av-tac-bru.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id o9QCYjLt002275; Tue, 26 Oct 2010 14:34:45 +0200 (CEST)
Received: from [10.55.43.53] (ams-bclaise-8714.cisco.com [10.55.43.53]) by strange-brew.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id o9QCYiLs010551; Tue, 26 Oct 2010 14:34:44 +0200 (CEST)
Message-ID: <4CC6CAE4.8090605@cisco.com>
Date: Tue, 26 Oct 2010 14:34:44 +0200
From: Benoit Claise 
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-GB; rv:1.9.2.11) Gecko/20101013 Thunderbird/3.1.5
MIME-Version: 1.0
To: Brian Trammell 
References: <4C80CBE8.2080708@cisco.com> <4C83F0E6.8050106@net.in.tum.de>	<88A72F0E-DCD8-44B9-A7C2-FE29BF684B93@tik.ee.ethz.ch> <4C86AAFF.9050008@cisco.com>
In-Reply-To: <4C86AAFF.9050008@cisco.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Cc: "ipfix@ietf.org" 
Subject: Re: [IPFIX] Flow in IPFIX -> not only IP Flows
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 Oct 2010 12:33:11 -0000

Dear all,

Thinking some more about this one.
It seems that there is an agreement for changing "IP packets" to 
"packets" in the definition

Let me summarize the options. The first three come from Brian's proposal 
below
1. Do nothing
     -> not ideal
2. Define a new category of data records which IPFIX can be used to export
     -> Brian: not a big fan of this.
     -> Same for me
3. Drastically expand the definition of Flow so that it covers 
everything you might want to represent with IPFIX
4. Errata on RFC5101: "IP Traffic Flow or Flow" to "Traffic Flow or 
Flow", and from "IP packets" to "packets
     -> this is not really an errata
     -> could be done, but we have to check all the implications
5. Change the definition from "IP Traffic Flow or Flow" to "Traffic Flow 
or Flow", and from "IP packets" to "packets" when RFC5101 will go from 
Proposed Standard to Draft Standard.
6. Have an applicability version 2, next to 
http://tools.ietf.org/html/rfc5472
     -> expressing that it's used also for non IP packets, among other 
things.
     -> it's good, but I don't think this solution is complete. For 
example, the ITU-T would still see the definition as being IP...


I'm in favor of 5. and 6., even though 4 would solve the problem now.

Feedback?
Do we want to discuss this in Beijing?

Regards, Benoit.

>  Brian,
>> Benoit, Gerhard, all,
>>
>> I agree with Gerhard here; call it a packet, leave the definition of 
>> packet ambiguous, so that it applies to any commonly accepted 
>> definition thereof.
>>
>> However, we have two separate problems here. The _other_ problem is 
>> how to handle the expansion of IPFIX as a generic flexible data 
>> representation into areas which are not directly related to flow 
>> measurement as originally envisioned. The prototype here is SIPCLF.
>>
>> As I see it, this problem should be solved separately from the 
>> problem of redefining flows for non-IP monitoring, and there are 
>> three separate general solution areas:
>>
>> 1. Do nothing, keep the (slightly expanded) definition of Flow. Here, 
>> we limit the applicibility of IPFIX to network management area, and 
>> exploit the fact that basically everything in the network management 
>> area is at the base of it going to involve packets going from 
>> somewhere to somewhere. In this case, every record represented using 
>> IPFIX is going to _somehow_ have a relationship back to _some_ set of 
>> packets which can be wedged into the present definition (the "packet 
>> treatment" clause in the 5101 definition affords us significant 
>> flexibility here). This works for SIPCLF as presently defined. 
>> Non-flow information can still be exported using Options, so it works 
>> for expanding IPFIX to decidedly non-flow things (e.g., physical 
>> monitoring scenarios, think periodic temperature reporting) as well, 
>> as long as all of these records can be represented as scoped to 
>> something (which I believe they can). In this case, we would probably 
>> want to mention this in the soon-forthcoming I
> E-Doctors draft.
>>
>> 2. Define a new category of data records which IPFIX can be used to 
>> export. These non-flow records would be represented as flow records 
>> (i.e., not Options), and would be equivalent to Flow records, except 
>> that the flow-specific provisions (uniqueness of flow keys, 
>> reversibility of non-key fields, etc., etc.) would not apply. The way 
>> to do this would be, I think, with another RFC which would present 
>> the expanded definition, and devices exporting/handling this non-flow 
>> data would therefore state compliance with this _new_ RFC. I'm not a 
>> big fan of this, personally, because it seems a little complicated, 
>> but it does allow us to segregate IPFIX-for-flow and 
>> IPFIX-for-not-really-flow better than (1) above.
>>
>> 3. Drastically expand the definition of Flow so that it covers 
>> everything you might want to represent with IPFIX. This strikes me as 
>> though it would take a great deal of effort, and break a lot of 
>> assumptions, basically as noted by Gerhard below. I mention it here 
>> only for completeness.
>>
>> My preference would be (1) (do nothing, note applicability). Thoughts?
> Right, as briefly discussed in the past, we would need an 
> applicability  version 2
>
> Regards, Benoit.
>> Best regards,
>>
>> Brian
>>
>> On Sep 5, 2010, at 9:35 PM, Gerhard Muenz wrote:
>>
>>> Benoit,
>>>
>>> I agree: "IP packet" can be replace by "packet".
>>>
>>> However, replacing "packet" by something like "packet, frame, or 
>>> cell" would probably cause inconsistencies in this and other 
>>> IPFIX/PSAMP documents. So, I would not go that far.
>>>
>>> Regards,
>>> Gerhard
>>>
>>>
>>> On 03.09.2010 12:20, Benoit Claise wrote:
>>>>   Dear all,
>>>>
>>>> Here is one problem that was anticipated...
>>>>
>>>> For whatever reasons at that point in time, RFC 5101 limits the Flow
>>>> definition to IP packets
>>>>
>>>>     IP Traffic Flow or Flow
>>>>
>>>>        There are several definitions of the term 'flow' being used 
>>>> by the
>>>>        Internet community.  Within the context of IPFIX we use the
>>>>        following definition:
>>>>
>>>>        A Flow is defined as a set of IP packets passing an Observation
>>>>        Point in the network during a certain time interval.  All 
>>>> packets
>>>>        belonging to a particular Flow have a set of common properties.
>>>>        Each property is defined as the result of applying a 
>>>> function to
>>>>        the values of:
>>>>
>>>>           1. one or more packet header fields (e.g., destination IP
>>>>              address), transport header fields (e.g., destination port
>>>>              number), or application header fields (e.g., RTP header
>>>>              fields [RFC3550]).
>>>>
>>>>           2. one or more characteristics of the packet itself (e.g.,
>>>>              number of MPLS labels, etc...).
>>>>
>>>>           3. one or more of fields derived from packet treatment 
>>>> (e.g.,
>>>>              next hop IP address, the output interface, etc...).
>>>>
>>>>        A packet is defined as belonging to a Flow if it completely
>>>>        satisfies all the defined properties of the Flow.
>>>>
>>>>        This definition covers the range from a Flow containing all
>>>>        packets observed at a network interface to a Flow consisting of
>>>>        just a single packet between two applications.  It includes
>>>>        packets selected by a sampling mechanism.
>>>>
>>>> However, we know that IPFIX cover more than IP.
>>>> http://www.iana.org/assignments/ipfix/ipfix.xhtml mentions
>>>> sourceMacAddress, ethernetPayloadLength, etc...
>>>> And we know that IPFIX became a kind of generic streaming protocol.
>>>>
>>>> Talking in the context of the NGN networks at the ITU, there are some
>>>> reluctance to adopt this Flow definition limited to IP packets.
>>>> Isn't it time to do something about this definition?
>>>>
>>>> Regards, Benoit.
>>> _______________________________________________
>>> IPFIX mailing list
>>> IPFIX@ietf.org
>>> https://www.ietf.org/mailman/listinfo/ipfix
>
>
> _______________________________________________
> IPFIX mailing list
> IPFIX@ietf.org
> https://www.ietf.org/mailman/listinfo/ipfix


From descombes@lpsc.in2p3.fr  Wed Oct 27 00:08:49 2010
Return-Path: 
X-Original-To: ipfix@core3.amsl.com
Delivered-To: ipfix@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DE0343A68CE for ; Wed, 27 Oct 2010 00:08:49 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.248
X-Spam-Level: 
X-Spam-Status: No, score=-2.248 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35, HTML_MESSAGE=0.001]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZAvq1j89ghfK for ; Wed, 27 Oct 2010 00:08:47 -0700 (PDT)
Received: from lpsc-mail.in2p3.fr (lpsc-mail.in2p3.fr [134.158.40.8]) by core3.amsl.com (Postfix) with ESMTP id 4EF313A6997 for ; Wed, 27 Oct 2010 00:08:46 -0700 (PDT)
Received: from [134.158.40.158] (IDENT:U2FsdGVkX1+QnAmhDY4FLOfvuD9NE/sYMhLxmszLvOE@localhost.localdomain [127.0.0.1]) by lpsc-mail.in2p3.fr (8.13.1/8.13.1/In2p3) with ESMTP id o9R7AY80010333 for ; Wed, 27 Oct 2010 09:10:34 +0200
Message-ID: <4CC7DE4E.6090009@lpsc.in2p3.fr>
Date: Wed, 27 Oct 2010 10:09:50 +0200
From: DESCOMBES Thierry 
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.8) Gecko/20100808 Mandriva/3.1.2-0.2mdv2010.1 (2010.1) Thunderbird/3.1.2
MIME-Version: 1.0
To: ipfix@ietf.org
Content-Type: multipart/alternative; boundary="------------000805010808070701070409"
X-Mailman-Approved-At: Wed, 27 Oct 2010 00:19:50 -0700
Subject: [IPFIX] IPFIX flows timestamps
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, 27 Oct 2010 07:08:50 -0000

This is a multi-part message in MIME format.
--------------000805010808070701070409
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit


Hello,

I am currently developing a collector NetFlow / IPFIX. I am trying to 
decode the "first switched" and "last switched" timestamps of flows with 
an accuracy of one second. It was simple so far with Netflows. With 
IPFIX, is there a simple and standard way to do that ? (Or should I deal 
with all possible combinations of time fields (flowStartSysUpTime, 
flowEndSysUpTime, systemInitTimeMilliseconds, flowStartMicroseconds, 
flowEndMicroseconds, flowStartDeltaMicroseconds, 
flowEndDeltaMicroseconds...) ?

What are the manufacturers and models of router implementing IPFIX? What 
type of timestamp do they implement?

Thanks a lot in advance.
Regards

Thierry Descombes
LPSC - CNRS

--------------000805010808070701070409
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit



  

    
  
  
    

      Hello,

          

        I am currently
          developing a collector NetFlow / IPFIX. I am trying to
          decode
          the "first switched" and "last switched" timestamps of flows
          with an accuracy of one second. It was simple
          so far with Netflows. With IPFIX,  is there a
          simple and
          standard way to do that ? (Or should I
          deal with all possible combinations of time fields (flowStartSysUpTime,
          flowEndSysUpTime,
          systemInitTimeMilliseconds, flowStartMicroseconds,
          flowEndMicroseconds,
          flowStartDeltaMicroseconds, flowEndDeltaMicroseconds...)
        ?

          

        What are the manufacturers and models of router
          implementing IPFIX? What type
          of timestamp do they implement?

        
          

        Thanks a lot in
          advance.
          

        Regards
          

        

        Thierry
          Descombes
          

        LPSC - CNRS
        
    

  


--------------000805010808070701070409--

From muenz@net.in.tum.de  Wed Oct 27 04:23:01 2010
Return-Path: 
X-Original-To: ipfix@core3.amsl.com
Delivered-To: ipfix@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BEFFD3A68A0 for ; Wed, 27 Oct 2010 04:23:01 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.598
X-Spam-Level: 
X-Spam-Status: No, score=0.598 tagged_above=-999 required=5 tests=[AWL=1.358,  BAYES_05=-1.11, HELO_EQ_DE=0.35]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id g2N1wqvCkeKb for ; Wed, 27 Oct 2010 04:23:01 -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 A82DB3A6820 for ; Wed, 27 Oct 2010 04:23:00 -0700 (PDT)
Received: from [78.43.105.44] (HSI-KBW-078-043-105-044.hsi4.kabel-badenwuerttemberg.de [78.43.105.44]) by mail.net.in.tum.de (Postfix) with ESMTPSA id BB682202FD7E; Wed, 27 Oct 2010 13:25:10 +0200 (CEST)
Message-ID: <4CC80C2E.1080105@net.in.tum.de>
Date: Wed, 27 Oct 2010 13:25:34 +0200
From: Gerhard Muenz 
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-GB; rv:1.9.2.11) Gecko/20101013 Thunderbird/3.1.5
MIME-Version: 1.0
To: Benoit Claise 
References: <4C4E996E.2000300@net.in.tum.de> <4CA2F41E.7020900@cisco.com>
In-Reply-To: <4CA2F41E.7020900@cisco.com>
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms000402000006040001070101"
X-Virus-Scanned: ClamAV using ClamSMTP
Cc: "ipfix@ietf.org" 
Subject: Re: [IPFIX] Review: draft-ietf-ipfix-structured-data-02.txt
X-BeenThere: ipfix@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: IPFIX WG discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 27 Oct 2010 11:23:01 -0000

This is a cryptographically signed message in MIME format.

--------------ms000402000006040001070101
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

Benoit,

On 29.09.2010 10:09, Benoit Claise wrote:
>>>      The Exporter SHOULD NOT check all semantically meaningless=20
>>>      combinations before exporting the Data Record.=20
>> I do not understand.
>> SHOULD NOT =3D> SHOULD
>> or
>> SHOULD NOT =3D> "does not have to"
> does not have to.
> In IPFIX structured data, we can express some complex (or stupid)
> semantic. It's not the responsibility of the  exporter to check if what=

> is encoded makes sense from a semantic point of view.

I do not see this comment addressed because "SHOULD NOT" still appears
in -03.
Are you actually talking about the Exporting Process and not the
Exporter? Then, you might want to replace "Exporter" as well.

Regards,
Gerhard



--------------ms000402000006040001070101
Content-Type: application/pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIO5jCC
BEYwggOvoAMCAQICEGb9R+PCGeToms2Z3fU6yyQwDQYJKoZIhvcNAQEFBQAwXzELMAkGA1UE
BhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMTcwNQYDVQQLEy5DbGFzcyAxIFB1Ymxp
YyBQcmltYXJ5IENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA1MTAyODAwMDAwMFoXDTE1
MTAyNzIzNTk1OVowgd0xCzAJBgNVBAYTAlVTMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEf
MB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazE7MDkGA1UECxMyVGVybXMgb2YgdXNl
IGF0IGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9ycGEgKGMpMDUxHjAcBgNVBAsTFVBlcnNv
bmEgTm90IFZhbGlkYXRlZDE3MDUGA1UEAxMuVmVyaVNpZ24gQ2xhc3MgMSBJbmRpdmlkdWFs
IFN1YnNjcmliZXIgQ0EgLSBHMjCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMnf
rOfq+PgDFMQAktXBfjbCPO98chXLwKuMPRyVzm8eECw/AO2XJua2x+atQx0/pIdHR0w+VPhs
+Mf8sZ69MHC8l7EDBeqV8a1AxUR6SwWi8mD81zplYu//EHuiVrvFTnAt1qIfPO2wQuhejVch
rKaZ2RHp0hoHwHRHQgv8xTTq/ea6JNEdCBU3otdzzwFBL2OyOj++pRpu9MlKWz2VphW7NQIZ
+dTvvI8OcXZZu0u2Ptb8Whb01g6J8kn+bAztFenZiHWcec5gJ925rXXOL3OVekA6hXVJsLjf
aLyrzROChRFQo+A8C67AClPN1zBvhTJGG+RJEMJs4q8fef/btLUCAwEAAaOB/zCB/DASBgNV
HRMBAf8ECDAGAQH/AgEAMEQGA1UdIAQ9MDswOQYLYIZIAYb4RQEHFwEwKjAoBggrBgEFBQcC
ARYcaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYTALBgNVHQ8EBAMCAQYwEQYJYIZIAYb4
QgEBBAQDAgEGMC4GA1UdEQQnMCWkIzAhMR8wHQYDVQQDExZQcml2YXRlTGFiZWwzLTIwNDgt
MTU1MB0GA1UdDgQWBBQRfV4ZfTwE32ps1qKKGj8x2DuUUjAxBgNVHR8EKjAoMCagJKAihiBo
dHRwOi8vY3JsLnZlcmlzaWduLmNvbS9wY2ExLmNybDANBgkqhkiG9w0BAQUFAAOBgQA8o9oC
YzrEk6qrctPcrVA4HgyeFkqIt+7r2f8PjZWg1rv6aguuYYTYaEeJ70+ssh9JQZtJM3aTi55u
uUMcYL3C3Ioth8FFwBFyBBprJCpsb+f8BxMp0Hc6I+f1wYVoGb/GAVQgGa41gsxiPGEJxvTV
67APpp8zhZrTcY5Qj5ndYjCCBUowggQyoAMCAQICEF0kYdlVNx5E1qcmxun5IrswDQYJKoZI
hvcNAQEFBQAwgd0xCzAJBgNVBAYTAlVTMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0G
A1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazE7MDkGA1UECxMyVGVybXMgb2YgdXNlIGF0
IGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9ycGEgKGMpMDUxHjAcBgNVBAsTFVBlcnNvbmEg
Tm90IFZhbGlkYXRlZDE3MDUGA1UEAxMuVmVyaVNpZ24gQ2xhc3MgMSBJbmRpdmlkdWFsIFN1
YnNjcmliZXIgQ0EgLSBHMjAeFw0xMDAxMDIwMDAwMDBaFw0xMTAxMDIyMzU5NTlaMIIBEzEX
MBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0IE5ldHdv
cmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEgSW5jb3JwLiBi
eSBSZWYuLExJQUIuTFREKGMpOTgxHjAcBgNVBAsTFVBlcnNvbmEgTm90IFZhbGlkYXRlZDEz
MDEGA1UECxMqRGlnaXRhbCBJRCBDbGFzcyAxIC0gTmV0c2NhcGUgRnVsbCBTZXJ2aWNlMRYw
FAYDVQQDFA1HZXJoYXJkIE11ZW56MSIwIAYJKoZIhvcNAQkBFhNtdWVuekBuZXQuaW4udHVt
LmRlMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAl/YDW9cnAXJjesGhwtGwj9JN
IHWXQ7QA18s+wGZNsQY0k4eKBeLTk/RAiC1hP+uQAXLoGQHQF/ljjQCQeRmnsN6w04iAzKVo
Ru+NP7Y6ipn8uztx+z0Y3w43CO+LWUudp3PIF3+Fm2zwsAFXj/IYy/8Kq6m9+nQgYO/D4HoN
DDR3//GepXghK0x93gR0GCkm8pgKINHNBD47/IZbDe/cIpAC9HaoxCeLiB1QaCDIYPIrJ0Vx
kk0crAA0tPaMDjdSQTmNRAn2P+7Wg7K+DLvauBHfxLs8PrsolI+XdwiBu6henK9nPxvtoHmm
mfxcdslKLbS9Xz2rHxi6PVVgv1ubWwIDAQABo4HMMIHJMAkGA1UdEwQCMAAwRAYDVR0gBD0w
OzA5BgtghkgBhvhFAQcXATAqMCgGCCsGAQUFBwIBFhxodHRwczovL3d3dy52ZXJpc2lnbi5j
b20vcnBhMAsGA1UdDwQEAwIFoDAdBgNVHSUEFjAUBggrBgEFBQcDBAYIKwYBBQUHAwIwSgYD
VR0fBEMwQTA/oD2gO4Y5aHR0cDovL0luZEMxRGlnaXRhbElELWNybC52ZXJpc2lnbi5jb20v
SW5kQzFEaWdpdGFsSUQuY3JsMA0GCSqGSIb3DQEBBQUAA4IBAQBPU7OeWNo2LRzsdu/RuuAk
L5cj/RzeZ0xv9q4K/eosy9dRu45XACpPvb0fjc3u/dsY4m3jDqzUsB02IrrnF9jpEo10BJPw
b/RZ7NaU7jC/gEknL3bSXiD2PVwL4ZI5ChH5+TJUboWhVh+FpOwOfP/yKk7wQM/46iXXzRIz
enk0rcJp71k4aQgQTML3/8MDeD6TUipuQwQMY9n6T6DsNd/6JpGa+x9ZX4HIEG6+EWwQ85G5
vGfDBaq3dFrksHE75u7b7pf75wm9HIFU2SDHP2tymTHJt/XM9sqP1URIC57s+uZV0/d5KRc1
uPcJ0FAnAiC9o7ybPIh27shiq0FvOEwfMIIFSjCCBDKgAwIBAgIQXSRh2VU3HkTWpybG6fki
uzANBgkqhkiG9w0BAQUFADCB3TELMAkGA1UEBhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJ
bmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTswOQYDVQQLEzJUZXJtcyBv
ZiB1c2UgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYSAoYykwNTEeMBwGA1UECxMV
UGVyc29uYSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5WZXJpU2lnbiBDbGFzcyAxIEluZGl2
aWR1YWwgU3Vic2NyaWJlciBDQSAtIEcyMB4XDTEwMDEwMjAwMDAwMFoXDTExMDEwMjIzNTk1
OVowggETMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1
c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJ
bmNvcnAuIGJ5IFJlZi4sTElBQi5MVEQoYyk5ODEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFs
aWRhdGVkMTMwMQYDVQQLEypEaWdpdGFsIElEIENsYXNzIDEgLSBOZXRzY2FwZSBGdWxsIFNl
cnZpY2UxFjAUBgNVBAMUDUdlcmhhcmQgTXVlbnoxIjAgBgkqhkiG9w0BCQEWE211ZW56QG5l
dC5pbi50dW0uZGUwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCX9gNb1ycBcmN6
waHC0bCP0k0gdZdDtADXyz7AZk2xBjSTh4oF4tOT9ECILWE/65ABcugZAdAX+WONAJB5Gaew
3rDTiIDMpWhG740/tjqKmfy7O3H7PRjfDjcI74tZS52nc8gXf4WbbPCwAVeP8hjL/wqrqb36
dCBg78Pgeg0MNHf/8Z6leCErTH3eBHQYKSbymAog0c0EPjv8hlsN79wikAL0dqjEJ4uIHVBo
IMhg8isnRXGSTRysADS09owON1JBOY1ECfY/7taDsr4Mu9q4Ed/Euzw+uyiUj5d3CIG7qF6c
r2c/G+2geaaZ/Fx2yUottL1fPasfGLo9VWC/W5tbAgMBAAGjgcwwgckwCQYDVR0TBAIwADBE
BgNVHSAEPTA7MDkGC2CGSAGG+EUBBxcBMCowKAYIKwYBBQUHAgEWHGh0dHBzOi8vd3d3LnZl
cmlzaWduLmNvbS9ycGEwCwYDVR0PBAQDAgWgMB0GA1UdJQQWMBQGCCsGAQUFBwMEBggrBgEF
BQcDAjBKBgNVHR8EQzBBMD+gPaA7hjlodHRwOi8vSW5kQzFEaWdpdGFsSUQtY3JsLnZlcmlz
aWduLmNvbS9JbmRDMURpZ2l0YWxJRC5jcmwwDQYJKoZIhvcNAQEFBQADggEBAE9Ts55Y2jYt
HOx279G64CQvlyP9HN5nTG/2rgr96izL11G7jlcAKk+9vR+Nze792xjibeMOrNSwHTYiuucX
2OkSjXQEk/Bv9Fns1pTuML+ASScvdtJeIPY9XAvhkjkKEfn5MlRuhaFWH4Wk7A58//IqTvBA
z/jqJdfNEjN6eTStwmnvWThpCBBMwvf/wwN4PpNSKm5DBAxj2fpPoOw13/omkZr7H1lfgcgQ
br4RbBDzkbm8Z8MFqrd0WuSwcTvm7tvul/vnCb0cgVTZIMc/a3KZMcm39cz2yo/VREgLnuz6
5lXT93kpFzW49wnQUCcCIL2jvJs8iHbuyGKrQW84TB8xggTsMIIE6AIBATCB8jCB3TELMAkG
A1UEBhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBU
cnVzdCBOZXR3b3JrMTswOQYDVQQLEzJUZXJtcyBvZiB1c2UgYXQgaHR0cHM6Ly93d3cudmVy
aXNpZ24uY29tL3JwYSAoYykwNTEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTcw
NQYDVQQDEy5WZXJpU2lnbiBDbGFzcyAxIEluZGl2aWR1YWwgU3Vic2NyaWJlciBDQSAtIEcy
AhBdJGHZVTceRNanJsbp+SK7MAkGBSsOAwIaBQCgggLOMBgGCSqGSIb3DQEJAzELBgkqhkiG
9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTEwMTAyNzExMjUzNFowIwYJKoZIhvcNAQkEMRYEFGA8
3Aq2v5/foU5rN1XSusJxgMVvMF8GCSqGSIb3DQEJDzFSMFAwCwYJYIZIAWUDBAECMAoGCCqG
SIb3DQMHMA4GCCqGSIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG
9w0DAgIBKDCCAQMGCSsGAQQBgjcQBDGB9TCB8jCB3TELMAkGA1UEBhMCVVMxFzAVBgNVBAoT
DlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTswOQYD
VQQLEzJUZXJtcyBvZiB1c2UgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYSAoYykw
NTEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5WZXJpU2lnbiBD
bGFzcyAxIEluZGl2aWR1YWwgU3Vic2NyaWJlciBDQSAtIEcyAhBdJGHZVTceRNanJsbp+SK7
MIIBBQYLKoZIhvcNAQkQAgsxgfWggfIwgd0xCzAJBgNVBAYTAlVTMRcwFQYDVQQKEw5WZXJp
U2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazE7MDkGA1UECxMy
VGVybXMgb2YgdXNlIGF0IGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9ycGEgKGMpMDUxHjAc
BgNVBAsTFVBlcnNvbmEgTm90IFZhbGlkYXRlZDE3MDUGA1UEAxMuVmVyaVNpZ24gQ2xhc3Mg
MSBJbmRpdmlkdWFsIFN1YnNjcmliZXIgQ0EgLSBHMgIQXSRh2VU3HkTWpybG6fkiuzANBgkq
hkiG9w0BAQEFAASCAQB5s1jN2+scWVzsxpherN6V+TXtCoR5OHiftOuUJDIAcdRNyB31ufWR
PHQG/75ff994KePTVxbndDIhHON1+lmuuJGvrGy6EgGQB74CYBxJOZ7wDEbuNcFBoE6M/wyS
25e7itPyheysNPpqA9yEdjVH+tWIk5TKN96Md2AlCA78cb/MYWOxTjldVS1vJg+KU6Y+d/r0
VzWH3crm/B5tAOq70XJv99mKGM4CE50OmcPhPg4Vzat26rdEB0wGXpDLLOlSZ9rJtkTgEAQ1
XGnHBFSRr9LABbTR+3z1joYECXMM6KTpDo3EpM47MhpD/ajFYPXAvJjAMkAiE92qDqRegTqw
AAAAAAAA
--------------ms000402000006040001070101--

From bclaise@cisco.com  Wed Oct 27 05:26:32 2010
Return-Path: 
X-Original-To: ipfix@core3.amsl.com
Delivered-To: ipfix@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 21DD53A6908 for ; Wed, 27 Oct 2010 05:26:32 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.495
X-Spam-Level: 
X-Spam-Status: No, score=-2.495 tagged_above=-999 required=5 tests=[AWL=0.103,  BAYES_00=-2.599, HTML_MESSAGE=0.001]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qrFI5-8kqbna for ; Wed, 27 Oct 2010 05:26:27 -0700 (PDT)
Received: from av-tac-bru.cisco.com (weird-brew.cisco.com [144.254.15.118]) by core3.amsl.com (Postfix) with ESMTP id A1ABF3A67CF for ; Wed, 27 Oct 2010 05:26:27 -0700 (PDT)
X-TACSUNS: Virus Scanned
Received: from strange-brew.cisco.com (localhost.cisco.com [127.0.0.1]) by av-tac-bru.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id o9RCSGTK015960; Wed, 27 Oct 2010 14:28:16 +0200 (CEST)
Received: from [10.55.43.53] (ams-bclaise-8714.cisco.com [10.55.43.53]) by strange-brew.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id o9RCSEMC008561; Wed, 27 Oct 2010 14:28:16 +0200 (CEST)
Message-ID: <4CC81ADD.5010802@cisco.com>
Date: Wed, 27 Oct 2010 14:28:13 +0200
From: Benoit Claise 
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-GB; rv:1.9.2.11) Gecko/20101013 Thunderbird/3.1.5
MIME-Version: 1.0
To: Gerhard Muenz 
References: <4C4E996E.2000300@net.in.tum.de> <4CA2F41E.7020900@cisco.com> <4CC80C2E.1080105@net.in.tum.de>
In-Reply-To: <4CC80C2E.1080105@net.in.tum.de>
Content-Type: multipart/alternative; boundary="------------080307010605040601070708"
Cc: "ipfix@ietf.org" 
Subject: Re: [IPFIX] Review: draft-ietf-ipfix-structured-data-02.txt
X-BeenThere: ipfix@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: IPFIX WG discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 27 Oct 2010 12:26:32 -0000

This is a multi-part message in MIME format.
--------------080307010605040601070708
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

Hi Gerhard,

Thanks for the follow up.
Changed in my temp version from:

    The Exporter SHOULD NOT check all semantically meaningless
    combinations before exporting the Data Record.


To

    The Exporting Process doesn't have to check all semantically
    meaningless combinations before exporting the Data Record.


Regards, Benoit.
> Benoit,
>
> On 29.09.2010 10:09, Benoit Claise wrote:
>>>>       The Exporter SHOULD NOT check all semantically meaningless
>>>>       combinations before exporting the Data Record.
>>> I do not understand.
>>> SHOULD NOT =>  SHOULD
>>> or
>>> SHOULD NOT =>  "does not have to"
>> does not have to.
>> In IPFIX structured data, we can express some complex (or stupid)
>> semantic. It's not the responsibility of the  exporter to check if what
>> is encoded makes sense from a semantic point of view.
> I do not see this comment addressed because "SHOULD NOT" still appears
> in -03.
> Are you actually talking about the Exporting Process and not the
> Exporter? Then, you might want to replace "Exporter" as well.
>
> Regards,
> Gerhard
>
>


--------------080307010605040601070708
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit



  
    
    
  
  
    Hi Gerhard,

    

    Thanks for the follow up.

    Changed in my temp version from:

    
The Exporter SHOULD NOT check all semantically
      meaningless combinations before exporting the Data Record. 

    

    

    To

    
The Exporting Process doesn't have to check all
      semantically meaningless combinations before exporting the Data
      Record. 

    

    

    Regards, Benoit.

    

      
Benoit,

On 29.09.2010 10:09, Benoit Claise wrote:


      

        

          

            
     The Exporter SHOULD NOT check all semantically meaningless 
     combinations before exporting the Data Record. 


          

          
I do not understand.
SHOULD NOT => SHOULD
or
SHOULD NOT => "does not have to"


        

        
does not have to.
In IPFIX structured data, we can express some complex (or stupid)
semantic. It's not the responsibility of the  exporter to check if what
is encoded makes sense from a semantic point of view.


      

      
I do not see this comment addressed because "SHOULD NOT" still appears
in -03.
Are you actually talking about the Exporting Process and not the
Exporter? Then, you might want to replace "Exporter" as well.

Regards,
Gerhard




    

    

  


--------------080307010605040601070708--

From n.brownlee@auckland.ac.nz  Wed Oct 27 17:45:01 2010
Return-Path: 
X-Original-To: ipfix@core3.amsl.com
Delivered-To: ipfix@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5D9243A67EC for ; Wed, 27 Oct 2010 17:45:01 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -103.08
X-Spam-Level: 
X-Spam-Status: No, score=-103.08 tagged_above=-999 required=5 tests=[AWL=0.519, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id A8IBXTR3YLlh for ; Wed, 27 Oct 2010 17:45:00 -0700 (PDT)
Received: from mx2-int.auckland.ac.nz (mx2-int.auckland.ac.nz [130.216.12.41]) by core3.amsl.com (Postfix) with ESMTP id 4D4883A67E6 for ; Wed, 27 Oct 2010 17:44:59 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=auckland.ac.nz; i=n.brownlee@auckland.ac.nz; q=dns/txt; s=uoa; t=1288226812; x=1319762812; h=message-id:date:from:mime-version:to:subject: content-transfer-encoding; z=Message-ID:=20<4CC8C7F9.8000903@auckland.ac.nz>|Date:=20 Thu,=2028=20Oct=202010=2013:46:49=20+1300|From:=20Nevil =20Brownlee=20|MIME-Version: =201.0|To:=20IPFIX=20Working=20Group=20 |Subject:=20Agenda=20for=20IPFIX=20meeting=20at=20IETF=20 70=20in=20Beijing|Content-Transfer-Encoding:=207bit; bh=XFfhnYvEJn5mCdVC7zjxxr1dAwp3a/f5Iqu5+cJyqfQ=; b=T5W+O10Jb8b8FTNx2oJ070ifo/tUSi0tAXYT1IW1QHczK7WL5cAzndSy uclY+HMdRVDbsYnDA3zb5Z08AvtDbHnMbOF6KEXxBGABJlJ7QUlAzFLq+ FfYFSwN6zr7BJjRGBONER63yeL15LgrPLcmONWlv/SDHs9swSNsh0hSt7 4=;
X-IronPort-AV: E=Sophos;i="4.58,248,1286103600"; d="scan'208";a="33132046"
X-Ironport-HAT: UNIVERSITY - $RELAY-THROTTLE
X-Ironport-Source: 130.216.38.131 - Outgoing - Outgoing-SSL
Received: from nevil-laptop1.sfac.auckland.ac.nz (HELO [130.216.38.131]) ([130.216.38.131]) by mx2-int.auckland.ac.nz with ESMTP; 28 Oct 2010 13:46:49 +1300
Message-ID: <4CC8C7F9.8000903@auckland.ac.nz>
Date: Thu, 28 Oct 2010 13:46:49 +1300
From: Nevil Brownlee 
User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.11) Gecko/20101013 Lightning/1.0b2 Thunderbird/3.1.5
MIME-Version: 1.0
To: IPFIX Working Group 
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Subject: [IPFIX] Agenda for IPFIX meeting at IETF 70 in Beijing
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 Oct 2010 00:45:01 -0000

Hi all:

The first (-00.txt) draft of our agenda is now at
   http://www.ietf.org/proceedings/79/agenda/ipfix.txt

Comments/changes/suggestions to me please.

Also, would authors who want to present drafts - especially 'possible
new work' drafts - please let me know who will be presenting.

Cheers, Nevil

-- 
---------------------------------------------------------------------
  Nevil Brownlee                    Computer Science Department | ITS
  Phone: +64 9 373 7599 x88941             The University of Auckland
  FAX: +64 9 373 7453   Private Bag 92019, Auckland 1142, New Zealand

From muenz@net.in.tum.de  Thu Oct 28 00:11:20 2010
Return-Path: 
X-Original-To: ipfix@core3.amsl.com
Delivered-To: ipfix@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F21133A6845 for ; Thu, 28 Oct 2010 00:11:19 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.174
X-Spam-Level: 
X-Spam-Status: No, score=-2.174 tagged_above=-999 required=5 tests=[AWL=0.075,  BAYES_00=-2.599, HELO_EQ_DE=0.35]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id V8gR6UCBd+Uo for ; Thu, 28 Oct 2010 00:11:18 -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 A800C3A6822 for ; Thu, 28 Oct 2010 00:11:18 -0700 (PDT)
Received: from [192.168.1.151] (ppp-93-104-69-78.dynamic.mnet-online.de [93.104.69.78]) by mail.net.in.tum.de (Postfix) with ESMTPSA id 7A845208423D; Thu, 28 Oct 2010 09:13:10 +0200 (CEST)
Message-ID: <4CC9227E.3080408@net.in.tum.de>
Date: Thu, 28 Oct 2010 09:13:02 +0200
From: Gerhard Muenz 
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.11) Gecko/20101013 Thunderbird/3.1.5
MIME-Version: 1.0
To: Benoit Claise 
References: <4C4E996E.2000300@net.in.tum.de> <4CA2F41E.7020900@cisco.com> <4CC80C2E.1080105@net.in.tum.de> <4CC81ADD.5010802@cisco.com>
In-Reply-To: <4CC81ADD.5010802@cisco.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 8bit
X-Virus-Scanned: ClamAV using ClamSMTP
Cc: "ipfix@ietf.org" 
Subject: Re: [IPFIX] Review: draft-ietf-ipfix-structured-data-02.txt
X-BeenThere: ipfix@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: IPFIX WG discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 28 Oct 2010 07:11:20 -0000

Hi Benoit,

Fine. With this, all my comments have been addressed.

Unfortunately, I do not have the time to proofread the entire document 
again.

Regards,
Gerhard


On 27.10.2010 14:28, Benoit Claise wrote:
> Hi Gerhard,
>
> Thanks for the follow up.
> Changed in my temp version from:
>
>     The Exporter SHOULD NOT check all semantically meaningless
>     combinations before exporting the Data Record.
>
>
> To
>
>     The Exporting Process doesn't have to check all semantically
>     meaningless combinations before exporting the Data Record.
>
>
> Regards, Benoit.
>> Benoit,
>>
>> On 29.09.2010 10:09, Benoit Claise wrote:
>>>>>       The Exporter SHOULD NOT check all semantically meaningless
>>>>>       combinations before exporting the Data Record.
>>>> I do not understand.
>>>> SHOULD NOT =>  SHOULD
>>>> or
>>>> SHOULD NOT =>  "does not have to"
>>> does not have to.
>>> In IPFIX structured data, we can express some complex (or stupid)
>>> semantic. It's not the responsibility of the  exporter to check if what
>>> is encoded makes sense from a semantic point of view.
>> I do not see this comment addressed because "SHOULD NOT" still appears
>> in -03.
>> Are you actually talking about the Exporting Process and not the
>> Exporter? Then, you might want to replace "Exporter" as well.
>>
>> Regards,
>> Gerhard
>>
>>
>

-- 
Dr.-Ing. Gerhard Münz
Chair for Network Architectures and Services (I8)
Technische Universität München - Department of Computer Science
Boltzmannstr. 3, 85748 Garching bei München, Germany
Phone:  +49 89 289-18008       Fax: +49 89 289-18033
E-mail: muenz@net.in.tum.de    WWW: http://www.net.in.tum.de/~muenz

From bclaise@cisco.com  Thu Oct 28 00:24:12 2010
Return-Path: 
X-Original-To: ipfix@core3.amsl.com
Delivered-To: ipfix@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D9F5D3A681F for ; Thu, 28 Oct 2010 00:24:11 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.497
X-Spam-Level: 
X-Spam-Status: No, score=-2.497 tagged_above=-999 required=5 tests=[AWL=0.102,  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 a7Be6hA9KWNe for ; Thu, 28 Oct 2010 00:24:08 -0700 (PDT)
Received: from av-tac-bru.cisco.com (weird-brew.cisco.com [144.254.15.118]) by core3.amsl.com (Postfix) with ESMTP id 8328B3A6867 for ; Thu, 28 Oct 2010 00:24:07 -0700 (PDT)
X-TACSUNS: Virus Scanned
Received: from strange-brew.cisco.com (localhost.cisco.com [127.0.0.1]) by av-tac-bru.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id o9S7LpOJ008222; Thu, 28 Oct 2010 09:21:51 +0200 (CEST)
Received: from [10.55.43.53] (ams-bclaise-8714.cisco.com [10.55.43.53]) by strange-brew.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id o9S7Lmde019340; Thu, 28 Oct 2010 09:21:48 +0200 (CEST)
Message-ID: <4CC9248C.9040405@cisco.com>
Date: Thu, 28 Oct 2010 09:21:48 +0200
From: Benoit Claise 
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-GB; rv:1.9.2.11) Gecko/20101013 Thunderbird/3.1.5
MIME-Version: 1.0
To: Gerhard Muenz 
References: <4C4E996E.2000300@net.in.tum.de> <4CA2F41E.7020900@cisco.com>	<4CC80C2E.1080105@net.in.tum.de> <4CC81ADD.5010802@cisco.com> <4CC9227E.3080408@net.in.tum.de>
In-Reply-To: <4CC9227E.3080408@net.in.tum.de>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Cc: "ipfix@ietf.org" 
Subject: Re: [IPFIX] Review: draft-ietf-ipfix-structured-data-02.txt
X-BeenThere: ipfix@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: IPFIX WG discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 28 Oct 2010 07:24:12 -0000

Thanks for your update Gerhard.

Regards, Benoit.
>
> Hi Benoit,
>
> Fine. With this, all my comments have been addressed.
>
> Unfortunately, I do not have the time to proofread the entire document 
> again.
>
> Regards,
> Gerhard
>
>
> On 27.10.2010 14:28, Benoit Claise wrote:
>> Hi Gerhard,
>>
>> Thanks for the follow up.
>> Changed in my temp version from:
>>
>>     The Exporter SHOULD NOT check all semantically meaningless
>>     combinations before exporting the Data Record.
>>
>>
>> To
>>
>>     The Exporting Process doesn't have to check all semantically
>>     meaningless combinations before exporting the Data Record.
>>
>>
>> Regards, Benoit.
>>> Benoit,
>>>
>>> On 29.09.2010 10:09, Benoit Claise wrote:
>>>>>>       The Exporter SHOULD NOT check all semantically meaningless
>>>>>>       combinations before exporting the Data Record.
>>>>> I do not understand.
>>>>> SHOULD NOT =>  SHOULD
>>>>> or
>>>>> SHOULD NOT =>  "does not have to"
>>>> does not have to.
>>>> In IPFIX structured data, we can express some complex (or stupid)
>>>> semantic. It's not the responsibility of the  exporter to check if 
>>>> what
>>>> is encoded makes sense from a semantic point of view.
>>> I do not see this comment addressed because "SHOULD NOT" still appears
>>> in -03.
>>> Are you actually talking about the Exporting Process and not the
>>> Exporter? Then, you might want to replace "Exporter" as well.
>>>
>>> Regards,
>>> Gerhard
>>>
>>>
>>
>


From kashima@nttv6.net  Thu Oct 28 09:58:04 2010
Return-Path: 
X-Original-To: ipfix@core3.amsl.com
Delivered-To: ipfix@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9912A3A685B for ; Thu, 28 Oct 2010 09:58:04 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.167
X-Spam-Level: 
X-Spam-Status: No, score=-2.167 tagged_above=-999 required=5 tests=[AWL=0.433,  BAYES_00=-2.599, NO_RELAYS=-0.001]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8mGtieTB77Rh for ; Thu, 28 Oct 2010 09:58:03 -0700 (PDT)
Received: from mail.nttv6.net (mail.nttv6.net [IPv6:2001:fa8::25]) by core3.amsl.com (Postfix) with ESMTP id 227CF3A694F for ; Thu, 28 Oct 2010 09:58:02 -0700 (PDT)
Received: from [127.0.0.1] (localhost [IPv6:::1]) by mail.nttv6.net (8.14.4/8.14.3) with ESMTP id o9SGxgYS029070; Fri, 29 Oct 2010 01:59:45 +0900 (JST) (envelope-from kashima@nttv6.net)
Date: Fri, 29 Oct 2010 01:59:35 +0900
From: Shingo KASHIMA 
To: Nevil Brownlee 
In-Reply-To: <4CC8C7F9.8000903@auckland.ac.nz>
References: <4CC8C7F9.8000903@auckland.ac.nz>
Message-Id: <20101029014253.9EDB.1AB7FA03@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]
X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.6 (mail.nttv6.net [IPv6:::1]); Fri, 29 Oct 2010 01:59:45 +0900 (JST)
Cc: IPFIX Working Group 
Subject: Re: [IPFIX] Agenda for IPFIX meeting at IETF 70 in Beijing
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 Oct 2010 16:58:04 -0000

Hi Nevil,

Thank you for adding my draft.

   c) Other new drafts (that export new kinds of information)   = 45 min
      - draft-kashima-ipfix-data-link-layer-monitoring-04
         26 Oct 10  Exporting link-layer information


I have submitted another draft.
http://tools.ietf.org/html/draft-kashima-ipfix-short-timer-00
This draft is about timer of the millisecond time scale.
Would you please adding this draft to our agenda ?

      - draft-kashima-ipfix-short-timer-00
         11 Oct 10  Information Elements for Short Timer

Best Regards,
Shingo

On Thu, 28 Oct 2010 13:46:49 +1300
Nevil Brownlee  wrote:

> 
> Hi all:
> 
> The first (-00.txt) draft of our agenda is now at
>    http://www.ietf.org/proceedings/79/agenda/ipfix.txt
> 
> Comments/changes/suggestions to me please.
> 
> Also, would authors who want to present drafts - especially 'possible
> new work' drafts - please let me know who will be presenting.
> 
> Cheers, Nevil
> 
> -- 
> ---------------------------------------------------------------------
>   Nevil Brownlee                    Computer Science Department | ITS
>   Phone: +64 9 373 7599 x88941             The University of Auckland
>   FAX: +64 9 373 7453   Private Bag 92019, Auckland 1142, New Zealand
> _______________________________________________
> IPFIX mailing list
> IPFIX@ietf.org
> https://www.ietf.org/mailman/listinfo/ipfix
> 

-- 
Shingo KASHIMA 
NTT Information Sharing Platform Lab.



From ralbrigh@cisco.com  Thu Oct 28 17:53:53 2010
Return-Path: 
X-Original-To: ipfix@core3.amsl.com
Delivered-To: ipfix@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B7A593A69B6 for ; Thu, 28 Oct 2010 17:53:53 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -9.917
X-Spam-Level: 
X-Spam-Status: No, score=-9.917 tagged_above=-999 required=5 tests=[AWL=0.682,  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 wX3YuYgsLmZV for ; Thu, 28 Oct 2010 17:53:52 -0700 (PDT)
Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by core3.amsl.com (Postfix) with ESMTP id CBABF3A6778 for ; Thu, 28 Oct 2010 17:53:52 -0700 (PDT)
Authentication-Results: sj-iport-6.cisco.com; dkim=neutral (message not signed) header.i=none
X-IronPort-AV: E=Sophos;i="4.58,255,1286150400"; d="scan'208";a="611269760"
Received: from sj-core-2.cisco.com ([171.71.177.254]) by sj-iport-6.cisco.com with ESMTP; 29 Oct 2010 00:55:46 +0000
Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id o9T0tkJk008857; Fri, 29 Oct 2010 00:55:46 GMT
Received: from xmb-sjc-229.amer.cisco.com ([128.107.191.122]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675);  Thu, 28 Oct 2010 17:55:46 -0700
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Date: Thu, 28 Oct 2010 17:55:45 -0700
Message-ID: <3E461BB921259141B8D244D10C1D331D0A5CD18A@xmb-sjc-229.amer.cisco.com>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: IPR Statement RE: draft-johnson-ipfix-mib-variable-export-00
Thread-Index: Act2C4oXPYD32ZL1TIG+WVTHd8M84QA+ChTQ
From: "Rachel Albright -X (ralbrigh - Unknown at Cisco)" 
To: 
X-OriginalArrivalTime: 29 Oct 2010 00:55:46.0126 (UTC) FILETIME=[05370EE0:01CB7704]
X-Mailman-Approved-At: Thu, 28 Oct 2010 17:56:52 -0700
Subject: [IPFIX] FW: IPR Statement RE: draft-johnson-ipfix-mib-variable-export-00
X-BeenThere: ipfix@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: IPFIX WG discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 29 Oct 2010 00:53:53 -0000

Below is a copy of Cisco's IPR statement regarding
draft-johnson-ipfix-mib-variable-export-00.


-----Original Message-----
From: Rachel Albright -X (ralbrigh - Unknown at Cisco)=20
Sent: Wednesday, October 27, 2010 12:17 PM
To: ietf-ipr@ietf.org
Cc: Andrew Johnson (andrjohn); Benoit Claise (bclaise); Paul Aitken
(paitken)
Subject: IPR Statement RE: draft-johnson-ipfix-mib-variable-export-00

Cisco is the owner of US Patent No. 7,788,371 relating to the subject
matter of "Exporting MIB variables using the IPFIX Protocol"
.=20
=20
If technology in this document is included in a standard adopted by IETF
and any claims of any Cisco patents are necessary for practicing the
standard, any party will have the right to use any such patent claims
under reasonable, non-discriminatory terms, with reciprocity, to
implement and fully comply with the standard.
=20
The reasonable non-discriminatory terms are:
=20
If this standard is adopted, Cisco will not assert any patents owned or
controlled by Cisco against any party for making, using, selling,
importing or offering for sale a product that implements the standard,
provided, however that Cisco retains the right to assert its patents
(including the right to claim past royalties) against any party that
asserts a patent it owns or controls (either directly or indirectly)
against Cisco or any of Cisco's affiliates or successors in title or
against any products of Cisco or any products of any of Cisco's
affiliates either alone or in combination with other products; and Cisco
retains the right to assert its patents against any product or portion
thereof that is not necessary for compliance with the standard.
=20
Royalty-bearing licenses will be available to anyone who prefers that
option.

For information contact:
=20
Dan Lang
Director, Intellectual Property
Cisco Systems
+1 408-526-6672
standards-ipr@cisco.com


From kashima@nttv6.net  Fri Oct 29 02:06:33 2010
Return-Path: 
X-Original-To: ipfix@core3.amsl.com
Delivered-To: ipfix@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 406EF3A6A1C for ; Fri, 29 Oct 2010 02:06:33 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.275
X-Spam-Level: 
X-Spam-Status: No, score=-2.275 tagged_above=-999 required=5 tests=[AWL=0.325,  BAYES_00=-2.599, NO_RELAYS=-0.001]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Mb3-7yIpHv96 for ; Fri, 29 Oct 2010 02:06:32 -0700 (PDT)
Received: from mail.nttv6.net (mail.nttv6.net [IPv6:2001:fa8::25]) by core3.amsl.com (Postfix) with ESMTP id 8E47E3A67C3 for ; Fri, 29 Oct 2010 02:06:31 -0700 (PDT)
Received: from [127.0.0.1] (localhost [IPv6:::1]) by mail.nttv6.net (8.14.4/8.14.3) with ESMTP id o9T98H9V034379; Fri, 29 Oct 2010 18:08:20 +0900 (JST) (envelope-from kashima@nttv6.net)
Date: Fri, 29 Oct 2010 18:08:00 +0900
From: Shingo KASHIMA 
To: Al Morton 
In-Reply-To: <201010181432.o9IEWDv2007072@alpd052.aldc.att.com>
References: <201010181432.o9IEWDv2007072@alpd052.aldc.att.com>
Message-Id: <20101029171716.F0E0.1AB7FA03@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]
X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.6 (mail.nttv6.net [IPv6:::1]); Fri, 29 Oct 2010 18:08:20 +0900 (JST)
Cc: ipfix@ietf.org
Subject: Re: [IPFIX] Fwd: I-D Action:draft-akhter-ipfix-perfmon-00.txt
X-BeenThere: ipfix@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: IPFIX WG discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 29 Oct 2010 09:06:33 -0000

Hi Aamer and all,

Your draft is fine for me.

At last NMRG Netflow/IPFIX workshop in Maastricht,
I have presented Qcast system for IPTV/RTP quality
monitoring with IPFIX/PSAMP.
http://www.ietf.org/proceedings/78/slides/NMRG-4.pdf
This system uses Enterprise-specific Information Elements 
as mentioned in page12.

Regards,
Shingo

On Mon, 18 Oct 2010 10:32:37 -0400
Al Morton  wrote:

> 
> >A URL for this Internet-Draft is:
> >http://www.ietf.org/internet-drafts/draft-akhter-ipfix-perfmon-00.txt
> 
> Hi Aamer,
> 
> I gave this a look-over, and have the following comments:
> 
> - I think you've done a good job describing the sequence number
> roll-over problem, I was checking to be sure this was covered.
> 
> - I think a slightly different loss triad is what you want here.
>    Instead of:
> >        4.1.1.  perfPacketLoss . . . . . . . . . . . . . . . . . . . .  6
> >        4.1.2.  perfPacketExpected . . . . . . . . . . . . . . . . . .  8
> >        4.1.3.  perfPacketLossRate . . . . . . . . . . . . . . . . . .  9
> 
> I think 4.1.1 should be the observed packet count.
> When you combine this in a ratio with the number of expected packets,
> you get the packet loss ratio.
> 
> So, I suggest:
> OLD
> 4.1.  Transport Layer
> 
> 4.1.1.  perfPacketLoss
> 
>     Name:  perfPacketLoss
> 
>     Description:  The packet loss metric reports the number of individual
>        packets that were lost in the reporting interval.
> 
> NEW
> 4.1.  Transport Layer
> 
> 4.1.1.  perfPacketCount
> 
>     Name:  perfPacketCount
> 
>     Description:  The packet count metric reports the number of individual
>        packets that arrived at the observation point during the reporting
>        interval.    ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> 
> other edits are needed in 4.1.1, but let's see if we're
> on the same page. :-)
> 
> Also, I suggest
> OLD
> 4.1.3.  perfPacketLossRate
> NEW
> 4.1.3.  perfPacketLossRatio
> as we've done elsewhere, including IPPM and PMOL.
> 
> interesting draft,
> Al
> 
> _______________________________________________
> IPFIX mailing list
> IPFIX@ietf.org
> https://www.ietf.org/mailman/listinfo/ipfix
> 

-- 
Shingo KASHIMA 
NTT Information Sharing Platform Lab.



From descombes@lpsc.in2p3.fr  Sun Oct 31 07:18:05 2010
Return-Path: 
X-Original-To: ipfix@core3.amsl.com
Delivered-To: ipfix@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AB5203A6988 for ; Sun, 31 Oct 2010 07:18:05 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.948
X-Spam-Level: 
X-Spam-Status: No, score=-0.948 tagged_above=-999 required=5 tests=[AWL=-1.300, BAYES_50=0.001, HELO_EQ_FR=0.35, HTML_MESSAGE=0.001]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9GaJnnDNt0la for ; Sun, 31 Oct 2010 07:18:04 -0700 (PDT)
Received: from lpsc-mail.in2p3.fr (lpsc-mail.in2p3.fr [134.158.40.8]) by core3.amsl.com (Postfix) with ESMTP id 7C0B43A6975 for ; Sun, 31 Oct 2010 07:18:04 -0700 (PDT)
Received: from lpsc.in2p3.fr (lpsc.in2p3.fr [134.158.40.162]) by lpsc-mail.in2p3.fr (8.13.1/8.13.1/In2p3) with ESMTP id o9VEK2N5032607 for ; Sun, 31 Oct 2010 15:20:02 +0100
MIME-Version: 1.0
Date: Sun, 31 Oct 2010 15:20:01 +0100
From: descombes 
To: 
Message-ID: 
X-Sender: descombes@lpsc-mail
User-Agent: RoundCube Webmail/0.3.1
Content-Type: multipart/mixed; boundary="=_210752fea7969552d75c725f661b1120"
Subject: [IPFIX] IPFIX flow's timestamps
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, 31 Oct 2010 14:18:05 -0000

--=_210752fea7969552d75c725f661b1120
Content-Transfer-Encoding: 8bit
Content-Type: text/plain; charset=UTF-8


Hello,

I am currently developing a collector NetFlow / IPFIX. I am trying to 
decode the "first switched" and "last switched" timestamps of flows with 
an accuracy of one second. It was simple so far with Netflows. With 
IPFIX, is there a simple and standard way to do that ? (Or should I deal 
with all possible combinations of time fields (flowStartSysUpTime, 
flowEndSysUpTime, systemInitTimeMilliseconds, flowStartMicroseconds, 
flowEndMicroseconds, flowStartDeltaMicroseconds, 
flowEndDeltaMicroseconds...) ?

What are the manufacturers and models of router implementing IPFIX? What 
type of timestamp do they implement by default?

Thanks a lot in advance.
Regards

Thierry Descombes
LPSC - CNRS
--=_210752fea7969552d75c725f661b1120
Content-Transfer-Encoding: base64
Content-Type: text/html; charset=UTF-8;
 name="Message en HTML";
Content-Disposition: attachment;
 filename="Message en HTML";

PCFET0NUWVBFIEhUTUwgUFVCTElDICItLy9XM0MvL0RURCBIVE1MIDQuMDEgVHJhbnNpdGlvbmFs
Ly9FTiI+CjxodG1sPgogIDxoZWFkPgoKICAgIDxtZXRhIGh0dHAtZXF1aXY9ImNvbnRlbnQtdHlw
ZSIgY29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PUlTTy04ODU5LTEiPgogIDwvaGVhZD4KICA8
Ym9keSB0ZXh0PSIjMDAwMDAwIiBiZ2NvbG9yPSIjZmZmZmZmIj4KICAgIDxkaXYgY2xhc3M9Im1v
ei10ZXh0LWh0bWwiIGxhbmc9Ingtd2VzdGVybiI+CiAgICAgIDxzcGFuIGlkPSJyZXN1bHRfYm94
IiBjbGFzcz0ibG9uZ190ZXh0Ij48c3BhbgogICAgICAgICAgc3R5bGU9ImJhY2tncm91bmQtY29s
b3I6IHJnYigyNTUsIDI1NSwgMjU1KTsiIHRpdGxlPSJqZSBuZQogICAgICAgICAgc2FpcyBwYXMg
dnJhaW1lbnQgJmFncmF2ZTsgcXVpIGplIGRvaXMgbSdhZHJlc3Nlci4iCiAgICAgICAgICBvbm1v
dXNlb3Zlcj0idGhpcy5zdHlsZS5iYWNrZ3JvdW5kQ29sb3I9JyNlYmVmZjknIgogICAgICAgICAg
b25tb3VzZW91dD0idGhpcy5zdHlsZS5iYWNrZ3JvdW5kQ29sb3I9JyNmZmYnIj5IZWxsbyw8YnI+
CiAgICAgICAgICA8YnI+CiAgICAgICAgPC9zcGFuPjxzcGFuIHN0eWxlPSJiYWNrZ3JvdW5kLWNv
bG9yOiByZ2IoMjU1LCAyNTUsIDI1NSk7IgogICAgICAgICAgdGl0bGU9IiZndDsgSmUgZCZlYWN1
dGU7dmVsb3BwZSBhY3R1ZWxsZW1lbnQgdW4gY29sbGVjdGV1cgogICAgICAgICAgTmV0Rmxvdy9J
UEZJWCBldCBqJ2FpIHVuIHBldGl0IHByb2JsJmVncmF2ZTttZTogaidhaSBsdSAoZXQgaW1wcmlt
JmVhY3V0ZTsKICAgICAgICAgIGxlcyBSRkMgNTY1NSwgNTEwMSwgNTEwMiwgLi4uKSBldCBqZSBu
J2FpIHBhcyBjb21wcmlzIG8mdWdyYXZlOyBldAogICAgICAgICAgY29tbWVudCAmZWFjdXRlO3Rh
aWVudCBkJmVhY3V0ZTtmaW5pZXMgbGVzICZxdW90OyIKICAgICAgICAgIG9ubW91c2VvdmVyPSJ0
aGlzLnN0eWxlLmJhY2tncm91bmRDb2xvcj0nI2ViZWZmOSciCiAgICAgICAgICBvbm1vdXNlb3V0
PSJ0aGlzLnN0eWxlLmJhY2tncm91bmRDb2xvcj0nI2ZmZiciPkkgYW0gY3VycmVudGx5CiAgICAg
ICAgICBkZXZlbG9waW5nIGEgY29sbGVjdG9yIE5ldEZsb3cgLyBJUEZJWC48L3NwYW4+PC9zcGFu
PjxzcGFuCiAgICAgICAgaWQ9InJlc3VsdF9ib3giIGNsYXNzPSJsb25nX3RleHQiPjxzcGFuIHRp
dGxlPSImZ3Q7IgogICAgICAgICAgb25tb3VzZW92ZXI9InRoaXMuc3R5bGUuYmFja2dyb3VuZENv
bG9yPScjZWJlZmY5JyIKICAgICAgICAgIG9ubW91c2VvdXQ9InRoaXMuc3R5bGUuYmFja2dyb3Vu
ZENvbG9yPScjZmZmJyI+PC9zcGFuPjxzcGFuCiAgICAgICAgICBzdHlsZT0iYmFja2dyb3VuZC1j
b2xvcjogcmdiKDI1NSwgMjU1LCAyNTUpOyIgdGl0bGU9IiZndDsgSmUKICAgICAgICAgIGNoZXJj
aGUgJmFncmF2ZTsgZCZlYWN1dGU7Y29kZXIgbGVzIGZsb3dzIGF2ZWMgdW5lIHByJmVhY3V0ZTtj
aXNpb24gZGUgbCdvcmRyZSBkZQogICAgICAgICAgbGEgbWlsbGlzZWNvbmRlICh2b2lyIG0mZWNp
cmM7bWUgJmVhY3V0ZTt2ZW50dWVsbGVtZW50IGRlIGxhIHNlY29uZGUpLiIKICAgICAgICAgIG9u
bW91c2VvdmVyPSJ0aGlzLnN0eWxlLmJhY2tncm91bmRDb2xvcj0nI2ViZWZmOSciCiAgICAgICAg
ICBvbm1vdXNlb3V0PSJ0aGlzLnN0eWxlLmJhY2tncm91bmRDb2xvcj0nI2ZmZiciPiBJIGFtIHRy
eWluZyB0bwogICAgICAgICAgZGVjb2RlCiAgICAgICAgICB0aGUgImZpcnN0IHN3aXRjaGVkIiBh
bmQgImxhc3Qgc3dpdGNoZWQiIHRpbWVzdGFtcHMgb2YgZmxvd3MKICAgICAgICAgIHdpdGggYTwv
c3Bhbj48L3NwYW4+PHNwYW4gaWQ9InJlc3VsdF9ib3giIGNsYXNzPSJzaG9ydF90ZXh0Ij48c3Bh
bgogICAgICAgICAgc3R5bGU9IiIgdGl0bGU9IiI+biBhY2N1cmFjeSBvZiBvbmUgc2Vjb25kPC9z
cGFuPjwvc3Bhbj48c3BhbgogICAgICAgIGlkPSJyZXN1bHRfYm94IiBjbGFzcz0ibG9uZ190ZXh0
Ij48c3BhbiBzdHlsZT0iYmFja2dyb3VuZC1jb2xvcjoKICAgICAgICAgIHJnYigyNTUsIDI1NSwg
MjU1KTsiIHRpdGxlPSImZ3Q7IEplIGNoZXJjaGUgJmFncmF2ZTsgZCZlYWN1dGU7Y29kZXIgbGVz
CiAgICAgICAgICBmbG93cyBhdmVjIHVuZSBwciZlYWN1dGU7Y2lzaW9uIGRlIGwnb3JkcmUgZGUg
bGEgbWlsbGlzZWNvbmRlICh2b2lyCiAgICAgICAgICBtJmVjaXJjO21lICZlYWN1dGU7dmVudHVl
bGxlbWVudCBkZSBsYSBzZWNvbmRlKS4iCiAgICAgICAgICBvbm1vdXNlb3Zlcj0idGhpcy5zdHls
ZS5iYWNrZ3JvdW5kQ29sb3I9JyNlYmVmZjknIgogICAgICAgICAgb25tb3VzZW91dD0idGhpcy5z
dHlsZS5iYWNrZ3JvdW5kQ29sb3I9JyNmZmYnIj4uIEl0IHdhcyBzaW1wbGUKICAgICAgICAgIHNv
IGZhciB3aXRoIE5ldGZsb3dzLiBXaXRoIElQRklYLCZuYnNwOyZuYnNwOzwvc3Bhbj48c3BhbiB0
aXRsZT0iRXN0LWNlCiAgICAgICAgICBxdSdpbCB5YSB1bmUgZmEmY2NlZGlsO29uIHNpbXBsZSBl
dCBzdGFuZGFydCBkZSBmYWlyZSA/IgogICAgICAgICAgb25tb3VzZW92ZXI9InRoaXMuc3R5bGUu
YmFja2dyb3VuZENvbG9yPScjZWJlZmY5JyIKICAgICAgICAgIG9ubW91c2VvdXQ9InRoaXMuc3R5
bGUuYmFja2dyb3VuZENvbG9yPScjZmZmJyI+aXMgdGhlcmUgYQogICAgICAgICAgc2ltcGxlIGFu
ZAogICAgICAgICAgc3RhbmRhcmQgd2F5IHRvIGRvIHRoYXQgPyA8L3NwYW4+PHNwYW4KICAgICAg
ICAgIHN0eWxlPSJiYWNrZ3JvdW5kLWNvbG9yOiByZ2IoMjU1LCAyNTUsIDI1NSk7IiB0aXRsZT0i
KG91CiAgICAgICAgICBlc3QtY2UgcXUnaWwgZmF1dCBzYXZvaXIgZyZlYWN1dGU7cmVyIHRvdXRl
cyBsZXMgY29tYmluYWlzb25zCiAgICAgICAgICBwb3NzaWJsZXMgYXZlYyBjZXMgdHlwZXMgPyki
CiAgICAgICAgICBvbm1vdXNlb3Zlcj0idGhpcy5zdHlsZS5iYWNrZ3JvdW5kQ29sb3I9JyNlYmVm
ZjknIgogICAgICAgICAgb25tb3VzZW91dD0idGhpcy5zdHlsZS5iYWNrZ3JvdW5kQ29sb3I9JyNm
ZmYnIj4oT3Igc2hvdWxkIEkKICAgICAgICAgIGRlYWwgd2l0aCBhbGwgcG9zc2libGUgY29tYmlu
YXRpb25zIG9mIHRpbWUgZmllbGRzICg8L3NwYW4+PC9zcGFuPjxzcGFuCiAgICAgICAgaWQ9InJl
c3VsdF9ib3giIGNsYXNzPSJsb25nX3RleHQiPjxzcGFuIHN0eWxlPSJiYWNrZ3JvdW5kLWNvbG9y
OgogICAgICAgICAgcmdiKDI1NSwgMjU1LCAyNTUpOyIgdGl0bGU9IiZndDsgSmUgZCZlYWN1dGU7
dmVsb3BwZSBhY3R1ZWxsZW1lbnQgdW4KICAgICAgICAgIGNvbGxlY3RldXIgTmV0Rmxvdy9JUEZJ
WCBldCBqJ2FpIHVuIHBldGl0IHByb2JsJmVncmF2ZTttZTogaidhaSBsdQogICAgICAgICAgKGV0
IGltcHJpbSZlYWN1dGU7IGxlcyBSRkMgNTY1NSwgNTEwMSwgNTEwMiwgLi4uKSBldCBqZSBuJ2Fp
IHBhcwogICAgICAgICAgY29tcHJpcyBvJnVncmF2ZTsgZXQgY29tbWVudCAmZWFjdXRlO3RhaWVu
dCBkJmVhY3V0ZTtmaW5pZXMgbGVzICZxdW90OyIKICAgICAgICAgIG9ubW91c2VvdmVyPSJ0aGlz
LnN0eWxlLmJhY2tncm91bmRDb2xvcj0nI2ViZWZmOSciCiAgICAgICAgICBvbm1vdXNlb3V0PSJ0
aGlzLnN0eWxlLmJhY2tncm91bmRDb2xvcj0nI2ZmZiciPjwvc3Bhbj48c3BhbgogICAgICAgICAg
c3R5bGU9ImJhY2tncm91bmQtY29sb3I6IHJnYigyNTUsIDI1NSwgMjU1KTsiCiAgICAgICAgICB0
aXRsZT0iY29ycmVzcG9uZGluZyBlbmNvZGluZyBzcGVjaWZpY2F0aW9ucyZxdW90OyBkZXMgdHlw
ZXMKICAgICAgICAgIGRhdGVUaW1lU2Vjb25kcy9kYXRlVGltZU1pbGxpc2Vjb25kcyAodXRpbGlz
JmVhY3V0ZTtzIGF2ZWMgbGVzIHR5cGVzCiAgICAgICAgICBmbG93U3RhcnRTeXNVcFRpbWUsIGZs
b3dFbmRTeXNVcFRpbWUsCiAgICAgICAgICBzeXN0ZW1Jbml0VGltZU1pbGxpc2Vjb25kcywgZmxv
d1N0YXJ0TWljcm9zZWNvbmRzLAogICAgICAgICAgZmxvd0VuZE1pY3Jvc2Vjb25kcywgZmxvd1N0
YXJ0RGVsdGFNaWNyb3NlY29uZHMsCiAgICAgICAgICBmbG93RW5kRGVsdGFNaWNyb3NlY29uZHMp
LiIKICAgICAgICAgIG9ubW91c2VvdmVyPSJ0aGlzLnN0eWxlLmJhY2tncm91bmRDb2xvcj0nI2Vi
ZWZmOSciCiAgICAgICAgICBvbm1vdXNlb3V0PSJ0aGlzLnN0eWxlLmJhY2tncm91bmRDb2xvcj0n
I2ZmZiciPmZsb3dTdGFydFN5c1VwVGltZSwKICAgICAgICAgIGZsb3dFbmRTeXNVcFRpbWUsCiAg
ICAgICAgICBzeXN0ZW1Jbml0VGltZU1pbGxpc2Vjb25kcywgZmxvd1N0YXJ0TWljcm9zZWNvbmRz
LAogICAgICAgICAgZmxvd0VuZE1pY3Jvc2Vjb25kcywKICAgICAgICAgIGZsb3dTdGFydERlbHRh
TWljcm9zZWNvbmRzLCBmbG93RW5kRGVsdGFNaWNyb3NlY29uZHMuLi4pCiAgICAgICAgPC9zcGFu
Pjwvc3Bhbj48c3BhbiBpZD0icmVzdWx0X2JveCIgY2xhc3M9ImxvbmdfdGV4dCI+PHNwYW4KICAg
ICAgICAgIHN0eWxlPSJiYWNrZ3JvdW5kLWNvbG9yOiByZ2IoMjU1LCAyNTUsIDI1NSk7IiB0aXRs
ZT0iKG91CiAgICAgICAgICBlc3QtY2UgcXUnaWwgZmF1dCBzYXZvaXIgZyZlYWN1dGU7cmVyIHRv
dXRlcyBsZXMgY29tYmluYWlzb25zCiAgICAgICAgICBwb3NzaWJsZXMgYXZlYyBjZXMgdHlwZXMg
PykiCiAgICAgICAgICBvbm1vdXNlb3Zlcj0idGhpcy5zdHlsZS5iYWNrZ3JvdW5kQ29sb3I9JyNl
YmVmZjknIgogICAgICAgICAgb25tb3VzZW91dD0idGhpcy5zdHlsZS5iYWNrZ3JvdW5kQ29sb3I9
JyNmZmYnIj4/PGJyPgogICAgICAgICAgPGJyPgogICAgICAgIDwvc3Bhbj48L3NwYW4+PHNwYW4g
aWQ9InJlc3VsdF9ib3giIGNsYXNzPSIiIGxhbmc9ImVuIj48c3BhbgogICAgICAgICAgdGl0bGU9
IiI+V2hhdCBhcmUgdGhlIG1hbnVmYWN0dXJlcnMgYW5kIG1vZGVscyBvZiByb3V0ZXIKICAgICAg
ICAgIGltcGxlbWVudGluZyBJUEZJWD8gPC9zcGFuPjxzcGFuIHN0eWxlPSIiIHRpdGxlPSIiPldo
YXQgdHlwZQogICAgICAgICAgb2YgdGltZXN0YW1wIGRvIHRoZXkgaW1wbGVtZW50Pzxicj4KICAg
ICAgICA8L3NwYW4+PC9zcGFuPjxzcGFuIGlkPSJyZXN1bHRfYm94IiBjbGFzcz0ibG9uZ190ZXh0
Ij48c3BhbgogICAgICAgICAgc3R5bGU9ImJhY2tncm91bmQtY29sb3I6IHJnYigyNTUsIDI1NSwg
MjU1KTsiIHRpdGxlPSIob3UKICAgICAgICAgIGVzdC1jZSBxdSdpbCBmYXV0IHNhdm9pciBnJmVh
Y3V0ZTtyZXIgdG91dGVzIGxlcyBjb21iaW5haXNvbnMKICAgICAgICAgIHBvc3NpYmxlcyBhdmVj
IGNlcyB0eXBlcyA/KSIKICAgICAgICAgIG9ubW91c2VvdmVyPSJ0aGlzLnN0eWxlLmJhY2tncm91
bmRDb2xvcj0nI2ViZWZmOSciCiAgICAgICAgICBvbm1vdXNlb3V0PSJ0aGlzLnN0eWxlLmJhY2tn
cm91bmRDb2xvcj0nI2ZmZiciPgogICAgICAgICAgPGJyPgogICAgICAgIDwvc3Bhbj48c3BhbiB0
aXRsZT0iJmd0OyBNZXJjaSBiZWF1Y291cCBkJ2F2YW5jZS4iCiAgICAgICAgICBvbm1vdXNlb3Zl
cj0idGhpcy5zdHlsZS5iYWNrZ3JvdW5kQ29sb3I9JyNlYmVmZjknIgogICAgICAgICAgb25tb3Vz
ZW91dD0idGhpcy5zdHlsZS5iYWNrZ3JvdW5kQ29sb3I9JyNmZmYnIj5UaGFua3MgYSBsb3QgaW4K
ICAgICAgICAgIGFkdmFuY2UuCiAgICAgICAgICA8YnI+CiAgICAgICAgPC9zcGFuPjxzcGFuIHRp
dGxlPSImZ3Q7IENvcmRpYWxlbWVudCIKICAgICAgICAgIG9ubW91c2VvdmVyPSJ0aGlzLnN0eWxl
LmJhY2tncm91bmRDb2xvcj0nI2ViZWZmOSciCiAgICAgICAgICBvbm1vdXNlb3V0PSJ0aGlzLnN0
eWxlLmJhY2tncm91bmRDb2xvcj0nI2ZmZiciPlJlZ2FyZHMKICAgICAgICAgIDxicj4KICAgICAg
ICA8L3NwYW4+PHNwYW4gdGl0bGU9IiZndDsiCiAgICAgICAgICBvbm1vdXNlb3Zlcj0idGhpcy5z
dHlsZS5iYWNrZ3JvdW5kQ29sb3I9JyNlYmVmZjknIgogICAgICAgICAgb25tb3VzZW91dD0idGhp
cy5zdHlsZS5iYWNrZ3JvdW5kQ29sb3I9JyNmZmYnIj48YnI+CiAgICAgICAgPC9zcGFuPjxzcGFu
IHRpdGxlPSImZ3Q7IERFU0NPTUJFUyBUaGllcnJ5IgogICAgICAgICAgb25tb3VzZW92ZXI9InRo
aXMuc3R5bGUuYmFja2dyb3VuZENvbG9yPScjZWJlZmY5JyIKICAgICAgICAgIG9ubW91c2VvdXQ9
InRoaXMuc3R5bGUuYmFja2dyb3VuZENvbG9yPScjZmZmJyI+VGhpZXJyeQogICAgICAgICAgRGVz
Y29tYmVzCiAgICAgICAgICA8YnI+CiAgICAgICAgPC9zcGFuPjxzcGFuIHRpdGxlPSImZ3Q7IExQ
U0MgLSBDTlJTIgogICAgICAgICAgb25tb3VzZW92ZXI9InRoaXMuc3R5bGUuYmFja2dyb3VuZENv
bG9yPScjZWJlZmY5JyIKICAgICAgICAgIG9ubW91c2VvdXQ9InRoaXMuc3R5bGUuYmFja2dyb3Vu
ZENvbG9yPScjZmZmJyI+TFBTQyAtIENOUlMKICAgICAgICA8L3NwYW4+PC9zcGFuPgogICAgPC9k
aXY+CiAgPC9ib2R5Pgo8L2h0bWw+Cg==
--=_210752fea7969552d75c725f661b1120--