From nobody Mon Mar 16 16:48:08 2015 Return-Path: X-Original-To: ipfix@ietfa.amsl.com Delivered-To: ipfix@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2A3E91ACD43; Mon, 16 Mar 2015 16:48:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.9 X-Spam-Level: X-Spam-Status: No, score=-101.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id noZ7P0LQ4duh; Mon, 16 Mar 2015 16:48:04 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id D51911ACD54; Mon, 16 Mar 2015 16:47:58 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: IESG Secretary To: "IETF Announcement List" X-Test-IDTracker: no X-IETF-IDTracker: 5.12.2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150316234758.8282.1029.idtracker@ietfa.amsl.com> Date: Mon, 16 Mar 2015 16:47:58 -0700 Archived-At: Cc: n.brownlee@auckland.ac.nz, ipfix@ietf.org Subject: [IPFIX] WG Action: Conclusion of IP Flow Information Export (ipfix) X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.15 Reply-To: ietf@ietf.org List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Mar 2015 23:48:05 -0000 The IP Flow Information Export (ipfix) working group in the Operations and Management Area has concluded. The IESG contact persons are Benoit Claise and Joel Jaeggli. The mailing list will remain open. From nobody Mon Mar 16 18:34:53 2015 Return-Path: X-Original-To: ipfix@ietfa.amsl.com Delivered-To: ipfix@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BCCD81ACDCD for ; Mon, 16 Mar 2015 18:34:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.889 X-Spam-Level: X-Spam-Status: No, score=-0.889 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MISSING_HEADERS=1.021, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id j1jE06v4RWqb for ; Mon, 16 Mar 2015 18:34:50 -0700 (PDT) Received: from nagasaki.bogus.com (nagasaki.bogus.com [IPv6:2001:418:1::81]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D0BA61ACDCC for ; Mon, 16 Mar 2015 18:34:50 -0700 (PDT) Received: from mb-aye.local (c-98-248-47-249.hsd1.ca.comcast.net [98.248.47.249]) (authenticated bits=0) by nagasaki.bogus.com (8.14.9/8.14.9) with ESMTP id t2H1YfGm012234 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Tue, 17 Mar 2015 01:34:41 GMT (envelope-from joelja@bogus.com) Message-ID: <550784AA.3090307@bogus.com> Date: Mon, 16 Mar 2015 18:34:34 -0700 From: joel jaeggli User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:36.0) Gecko/20100101 Thunderbird/36.0 MIME-Version: 1.0 References: <20150316234758.8282.1029.idtracker@ietfa.amsl.com> In-Reply-To: <20150316234758.8282.1029.idtracker@ietfa.amsl.com> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="P5SHo57mXk31tFo4FpmghAl4at03Bmd1t" Archived-At: Cc: n.brownlee@auckland.ac.nz, ipfix@ietf.org Subject: Re: [IPFIX] WG Action: Conclusion of IP Flow Information Export (ipfix) X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Mar 2015 01:34:51 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --P5SHo57mXk31tFo4FpmghAl4at03Bmd1t Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Thank you to everyone, for a job well done. we have one remaining document which I am happy to AD sponsor when the authors are ready. joel On 3/16/15 4:47 PM, IESG Secretary wrote: > The IP Flow Information Export (ipfix) working group in the Operations = > and Management Area has concluded. The IESG contact persons are Benoit = > Claise and Joel Jaeggli. >=20 > The mailing list will remain open. >=20 --P5SHo57mXk31tFo4FpmghAl4at03Bmd1t Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.22 (Darwin) Comment: GPGTools - http://gpgtools.org iEYEARECAAYFAlUHhKoACgkQ8AA1q7Z/VrLWagCfc/5MRBcBO4U8nkqYK/dzAAGy U5YAn2TvGxmjO9m0NQgLE4Z9qyin3uqO =5MO6 -----END PGP SIGNATURE----- --P5SHo57mXk31tFo4FpmghAl4at03Bmd1t-- From nobody Thu Mar 19 11:10:24 2015 Return-Path: X-Original-To: ipfix@ietfa.amsl.com Delivered-To: ipfix@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 700891A8A8D for ; Thu, 19 Mar 2015 11:10:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.013 X-Spam-Level: X-Spam-Status: No, score=-100.013 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id y-bK5DVY4PEk for ; Thu, 19 Mar 2015 11:10:21 -0700 (PDT) Received: from rfc-editor.org (rfc-editor.org [IPv6:2001:1900:3001:11::31]) by ietfa.amsl.com (Postfix) with ESMTP id 34A2E1A8AAA for ; Thu, 19 Mar 2015 11:10:09 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id 28BEC180205; Thu, 19 Mar 2015 11:08:56 -0700 (PDT) To: brian.trammell@hitachi-eu.com, elisa.boschi@hitachi-eu.com, lutz.mark@ifam.fraunhofer.de, tanja.zseby@fokus.fraunhofer.de, arno@wagner.name, bclaise@cisco.com, joelja@bogus.com, n.brownlee@auckland.ac.nz, quittek@neclab.eu X-PHP-Originating-Script: 6000:errata_mail_lib.php From: RFC Errata System Message-Id: <20150319180856.28BEC180205@rfc-editor.org> Date: Thu, 19 Mar 2015 11:08:56 -0700 (PDT) Archived-At: Cc: ipfix@ietf.org, rfc-editor@rfc-editor.org Subject: [IPFIX] [Technical Errata Reported] RFC5655 (4306) X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Mar 2015 18:10:22 -0000 The following errata report has been submitted for RFC5655, "Specification of the IP Flow Information Export (IPFIX) File Format". -------------------------------------- You may review the report below and at: http://www.rfc-editor.org/errata_search.php?rfc=5655&eid=4306 -------------------------------------- Type: Technical Reported by: Wayne Tackabury Section: A.5 Original Text ------------- 224: 0A 47 0A B6 E5 47 0C 07 48 00|01 03 00 18 00 3E [ message checksum record ^ --> 240: 2B 37 08 CE B2 0E 30 11 32 12 4A 5F E3 AD DB 00 256:|00 0A 05 10 47 0A B6 E5 00 00 00 06 00 00 00 01 Corrected Text -------------- 224: 0A 47 0A B6 E5 47 0C 07 48 00|01 03 00 16 00 3E [ message checksum record ^ --> 240: 2B 37 08 CE B2 0E 30 11 32 12 4A 5F E3 AD DB 00 256:|00 0A 05 10 47 0A B6 E5 00 00 00 06 00 00 00 01 Notes ----- First of all, note that per erratum #2030, the offsets in this whole section are wrong, it should begin (I think) at 192. I shall use the published (incorrect) offset for illuminating this point: I believe the byte at #237 should be 0x16 and not 0x18. I suspect this checksum was copy-pasted from a prior instance in the example, where there were three pad bytes added to the data record for #259 (0x103). In this instance, there is only one pad byte at #255, hence the offset here should be two less (22 or 0x16 and not 24 or 0x18): 2 bytes set ID 2 bytes length 1 byte option data 16 bytes checksum data 1 byte pad (at #255) ...totalling 22. Thanks! Instructions: ------------- This erratum is currently posted as "Reported". If necessary, please use "Reply All" to discuss whether it should be verified or rejected. When a decision is reached, the verifying party (IESG) can log in to change the status and edit the report, if necessary. -------------------------------------- RFC5655 (draft-ietf-ipfix-file-05) -------------------------------------- Title : Specification of the IP Flow Information Export (IPFIX) File Format Publication Date : October 2009 Author(s) : B. Trammell, E. Boschi, L. Mark, T. Zseby, A. Wagner Category : PROPOSED STANDARD Source : IP Flow Information Export Area : Operations and Management Stream : IETF Verifying Party : IESG From nobody Thu Mar 19 14:01:19 2015 Return-Path: X-Original-To: ipfix@ietfa.amsl.com Delivered-To: ipfix@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D712C1ACEC0 for ; Thu, 19 Mar 2015 14:01:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.267 X-Spam-Level: X-Spam-Status: No, score=-2.267 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id K8777brHZ5yZ for ; Thu, 19 Mar 2015 14:01:16 -0700 (PDT) Received: from mx0b-000f0801.pphosted.com (mx0b-000f0801.pphosted.com [67.231.152.113]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 32FD11ACEBF for ; Thu, 19 Mar 2015 14:01:16 -0700 (PDT) Received: from pps.filterd (m0048192.ppops.net [127.0.0.1]) by mx0b-000f0801.pphosted.com (8.14.7/8.14.7) with SMTP id t2JKp4c4021805; Thu, 19 Mar 2015 14:01:05 -0700 Received: from hq1wp-exchub01.corp.brocade.com ([144.49.131.13]) by mx0b-000f0801.pphosted.com with ESMTP id 1t7ks1je9q-1 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Thu, 19 Mar 2015 14:01:05 -0700 Received: from BRMWP-EXCHUB02.corp.brocade.com (172.16.187.99) by HQ1WP-EXCHUB01.corp.brocade.com (10.70.36.101) with Microsoft SMTP Server (TLS) id 14.3.123.3; Thu, 19 Mar 2015 14:01:04 -0700 Received: from brm-excashub-2.corp.brocade.com (172.16.187.74) by BRMWP-EXCHUB02.corp.brocade.com (172.16.187.99) with Microsoft SMTP Server (TLS) id 14.3.123.3; Thu, 19 Mar 2015 15:01:03 -0600 Received: from EMEAWP-CASH01.corp.brocade.com (172.29.18.10) by brm-excashub-2.corp.brocade.com (172.16.187.74) with Microsoft SMTP Server (TLS) id 8.3.298.1; Thu, 19 Mar 2015 15:01:03 -0600 Received: from [172.29.20.130] (172.29.20.130) by imapeu.brocade.com (172.29.18.15) with Microsoft SMTP Server (TLS) id 8.3.298.1; Thu, 19 Mar 2015 22:01:02 +0100 Message-ID: <550B390C.8080809@brocade.com> Date: Thu, 19 Mar 2015 21:01:00 +0000 From: Paul Aitken User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Icedove/31.5.0 MIME-Version: 1.0 To: "brian.trammell@hitachi-eu.com" , "elisa.boschi@hitachi-eu.com" , "lutz.mark@ifam.fraunhofer.de" , "tanja.zseby@fokus.fraunhofer.de" , "arno@wagner.name" , "bclaise@cisco.com" , "joelja@bogus.com" , "n.brownlee@auckland.ac.nz" , "quittek@neclab.eu" References: <20150319180856.28BEC180205@rfc-editor.org> In-Reply-To: <20150319180856.28BEC180205@rfc-editor.org> Content-Type: text/plain; charset="windows-1252"; format=flowed Content-Transfer-Encoding: 7bit X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.13.68, 1.0.33, 0.0.0000 definitions=2015-03-19_06:2015-03-19,2015-03-19,1970-01-01 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 suspectscore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=7.0.1-1402240000 definitions=main-1503190192 Archived-At: Cc: "ipfix@ietf.org" Subject: Re: [IPFIX] [Technical Errata Reported] RFC5655 (4306) X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Mar 2015 21:01:18 -0000 [-RFC Editor] I checked the figure and agree with Wayne: the byte should be 0x16 because there's only one padding octet, not three. P. On 19/03/15 18:08, RFC Errata System wrote: > The following errata report has been submitted for RFC5655, > "Specification of the IP Flow Information Export (IPFIX) File Format". > > -------------------------------------- > You may review the report below and at: > http://www.rfc-editor.org/errata_search.php?rfc=5655&eid=4306 > > -------------------------------------- > Type: Technical > Reported by: Wayne Tackabury > > Section: A.5 > > Original Text > ------------- > 224: 0A 47 0A B6 E5 47 0C 07 48 00|01 03 00 18 00 3E > [ message checksum record ^ --> > 240: 2B 37 08 CE B2 0E 30 11 32 12 4A 5F E3 AD DB 00 > > 256:|00 0A 05 10 47 0A B6 E5 00 00 00 06 00 00 00 01 > > > > Corrected Text > -------------- > 224: 0A 47 0A B6 E5 47 0C 07 48 00|01 03 00 16 00 3E > [ message checksum record ^ --> > 240: 2B 37 08 CE B2 0E 30 11 32 12 4A 5F E3 AD DB 00 > > 256:|00 0A 05 10 47 0A B6 E5 00 00 00 06 00 00 00 01 > > > > Notes > ----- > First of all, note that per erratum #2030, the offsets in this whole section are wrong, it should begin (I think) at 192. I shall use the published (incorrect) offset for illuminating this point: > > I believe the byte at #237 should be 0x16 and not 0x18. I suspect this checksum was copy-pasted from a prior instance in the example, where there were three pad bytes added to the data record for #259 (0x103). In this instance, there is only one pad byte at #255, hence the offset here should be two less (22 or 0x16 and not 24 or 0x18): > > 2 bytes set ID > 2 bytes length > 1 byte option data > 16 bytes checksum data > 1 byte pad (at #255) > > ...totalling 22. Thanks! > > Instructions: > ------------- > This erratum is currently posted as "Reported". If necessary, please > use "Reply All" to discuss whether it should be verified or > rejected. When a decision is reached, the verifying party (IESG) > can log in to change the status and edit the report, if necessary. > > -------------------------------------- > RFC5655 (draft-ietf-ipfix-file-05) > -------------------------------------- > Title : Specification of the IP Flow Information Export (IPFIX) File Format > Publication Date : October 2009 > Author(s) : B. Trammell, E. Boschi, L. Mark, T. Zseby, A. Wagner > Category : PROPOSED STANDARD > Source : IP Flow Information Export > Area : Operations and Management > Stream : IETF > Verifying Party : IESG > > _______________________________________________ > IPFIX mailing list > IPFIX@ietf.org > https://www.ietf.org/mailman/listinfo/ipfix From nobody Thu Mar 19 14:23:40 2015 Return-Path: X-Original-To: ipfix@ietfa.amsl.com Delivered-To: ipfix@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 32DE41ACF59 for ; Thu, 19 Mar 2015 14:23:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.511 X-Spam-Level: X-Spam-Status: No, score=-14.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7W2juizH8mZv for ; Thu, 19 Mar 2015 14:23:37 -0700 (PDT) Received: from aer-iport-3.cisco.com (aer-iport-3.cisco.com [173.38.203.53]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2A2481ACF56 for ; Thu, 19 Mar 2015 14:23:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3080; q=dns/txt; s=iport; t=1426800217; x=1428009817; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=C99vDpFw+s9XCeamPR9OJeW/rF81bT5I/r3zZOeMruw=; b=IxwsRYLiTeDqAQMO4GxDmJK3D9RzKOT2keCa6AvMG9i+sgMSKk/J7Y9P 2uDVxtYRuLFbc3zYhxNB1n7XN4ZqdM1/jrFrd9PafnL2JpFGCPuecEJ/6 IyO94dJGiX923dPph77+XkL7fAZNs4SK49E3rbbLfXTQARUDqGUc+B0Ll E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0BQBABOPQtV/xbLJq1CGg6DSlrEYYFFCoV1AoIBFAEBAQEBAQF8hBABAQQBAQEkETYKARALDgoJFg8JAwIBAgEVMAYBDAEFAgEBiCsNN81tAQEBAQEBAQEBAQEBAQEBAQEBAQEBF4sXgT2DNAeELQEEhhaUI4EbgzCCOI0lIoF/Aw0PgRM+PTEBEYIxAQEB X-IronPort-AV: E=Sophos;i="5.11,432,1422921600"; d="scan'208";a="388706097" Received: from aer-iport-nat.cisco.com (HELO aer-core-4.cisco.com) ([173.38.203.22]) by aer-iport-3.cisco.com with ESMTP; 19 Mar 2015 21:23:35 +0000 Received: from [10.60.67.85] (ams-bclaise-8914.cisco.com [10.60.67.85]) by aer-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id t2JLNYtK012980; Thu, 19 Mar 2015 21:23:35 GMT Message-ID: <550B3E56.4040303@cisco.com> Date: Thu, 19 Mar 2015 22:23:34 +0100 From: Benoit Claise User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: Paul Aitken , "brian.trammell@hitachi-eu.com" , "elisa.boschi@hitachi-eu.com" , "lutz.mark@ifam.fraunhofer.de" , "tanja.zseby@fokus.fraunhofer.de" , "arno@wagner.name" , "joelja@bogus.com" , "n.brownlee@auckland.ac.nz" , "quittek@neclab.eu" References: <20150319180856.28BEC180205@rfc-editor.org> <550B390C.8080809@brocade.com> In-Reply-To: <550B390C.8080809@brocade.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Cc: "ipfix@ietf.org" Subject: Re: [IPFIX] [Technical Errata Reported] RFC5655 (4306) X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Mar 2015 21:23:39 -0000 Thanks Paul, I'll accept it. Regards, Benoit > [-RFC Editor] > > I checked the figure and agree with Wayne: the byte should be 0x16 > because there's only one padding octet, not three. > > P. > > > On 19/03/15 18:08, RFC Errata System wrote: >> The following errata report has been submitted for RFC5655, >> "Specification of the IP Flow Information Export (IPFIX) File Format". >> >> -------------------------------------- >> You may review the report below and at: >> http://www.rfc-editor.org/errata_search.php?rfc=5655&eid=4306 >> >> -------------------------------------- >> Type: Technical >> Reported by: Wayne Tackabury >> >> Section: A.5 >> >> Original Text >> ------------- >> 224: 0A 47 0A B6 E5 47 0C 07 48 00|01 03 00 18 00 3E >> [ message checksum record ^ --> >> 240: 2B 37 08 CE B2 0E 30 11 32 12 4A 5F E3 AD DB 00 >> >> 256:|00 0A 05 10 47 0A B6 E5 00 00 00 06 00 00 00 01 >> >> >> >> Corrected Text >> -------------- >> 224: 0A 47 0A B6 E5 47 0C 07 48 00|01 03 00 16 00 3E >> [ message checksum record ^ --> >> 240: 2B 37 08 CE B2 0E 30 11 32 12 4A 5F E3 AD DB 00 >> >> 256:|00 0A 05 10 47 0A B6 E5 00 00 00 06 00 00 00 01 >> >> >> >> Notes >> ----- >> First of all, note that per erratum #2030, the offsets in this whole >> section are wrong, it should begin (I think) at 192. I shall use the >> published (incorrect) offset for illuminating this point: >> >> I believe the byte at #237 should be 0x16 and not 0x18. I suspect >> this checksum was copy-pasted from a prior instance in the example, >> where there were three pad bytes added to the data record for #259 >> (0x103). In this instance, there is only one pad byte at #255, >> hence the offset here should be two less (22 or 0x16 and not 24 or >> 0x18): >> >> 2 bytes set ID >> 2 bytes length >> 1 byte option data >> 16 bytes checksum data >> 1 byte pad (at #255) >> >> ...totalling 22. Thanks! >> >> Instructions: >> ------------- >> This erratum is currently posted as "Reported". If necessary, please >> use "Reply All" to discuss whether it should be verified or >> rejected. When a decision is reached, the verifying party (IESG) >> can log in to change the status and edit the report, if necessary. >> >> -------------------------------------- >> RFC5655 (draft-ietf-ipfix-file-05) >> -------------------------------------- >> Title : Specification of the IP Flow Information Export >> (IPFIX) File Format >> Publication Date : October 2009 >> Author(s) : B. Trammell, E. Boschi, L. Mark, T. Zseby, A. >> Wagner >> Category : PROPOSED STANDARD >> Source : IP Flow Information Export >> Area : Operations and Management >> Stream : IETF >> Verifying Party : IESG >> >> _______________________________________________ >> IPFIX mailing list >> IPFIX@ietf.org >> https://www.ietf.org/mailman/listinfo/ipfix > > . > From nobody Thu Mar 19 14:25:21 2015 Return-Path: X-Original-To: ipfix@ietfa.amsl.com Delivered-To: ipfix@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7E1501AD05F; Thu, 19 Mar 2015 14:25:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.912 X-Spam-Level: X-Spam-Status: No, score=-101.912 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oqrgJlI4ZU-W; Thu, 19 Mar 2015 14:25:16 -0700 (PDT) Received: from rfc-editor.org (rfc-editor.org [IPv6:2001:1900:3001:11::31]) by ietfa.amsl.com (Postfix) with ESMTP id 013F01AD05C; Thu, 19 Mar 2015 14:25:16 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id 836F4180205; Thu, 19 Mar 2015 14:24:02 -0700 (PDT) To: wtackabury@us.ibm.com, brian.trammell@hitachi-eu.com, elisa.boschi@hitachi-eu.com, lutz.mark@ifam.fraunhofer.de, tanja.zseby@fokus.fraunhofer.de, arno@wagner.name X-PHP-Originating-Script: 1005:errata_mail_lib.php From: RFC Errata System Message-Id: <20150319212402.836F4180205@rfc-editor.org> Date: Thu, 19 Mar 2015 14:24:02 -0700 (PDT) Archived-At: Cc: iesg@ietf.org, ipfix@ietf.org, rfc-editor@rfc-editor.org Subject: [IPFIX] [Errata Verified] RFC5655 (4306) X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Mar 2015 21:25:17 -0000 The following errata report has been verified for RFC5655, "Specification of the IP Flow Information Export (IPFIX) File Format". -------------------------------------- You may review the report below and at: http://www.rfc-editor.org/errata_search.php?rfc=5655&eid=4306 -------------------------------------- Status: Verified Type: Technical Reported by: Wayne Tackabury Date Reported: 2015-03-19 Verified by: Benoit Claise (IESG) Section: A.5 Original Text ------------- 224: 0A 47 0A B6 E5 47 0C 07 48 00|01 03 00 18 00 3E [ message checksum record ^ --> 240: 2B 37 08 CE B2 0E 30 11 32 12 4A 5F E3 AD DB 00 256:|00 0A 05 10 47 0A B6 E5 00 00 00 06 00 00 00 01 Corrected Text -------------- 224: 0A 47 0A B6 E5 47 0C 07 48 00|01 03 00 16 00 3E [ message checksum record ^ --> 240: 2B 37 08 CE B2 0E 30 11 32 12 4A 5F E3 AD DB 00 256:|00 0A 05 10 47 0A B6 E5 00 00 00 06 00 00 00 01 Notes ----- First of all, note that per erratum #2030, the offsets in this whole section are wrong, it should begin (I think) at 192. I shall use the published (incorrect) offset for illuminating this point: I believe the byte at #237 should be 0x16 and not 0x18. I suspect this checksum was copy-pasted from a prior instance in the example, where there were three pad bytes added to the data record for #259 (0x103). In this instance, there is only one pad byte at #255, hence the offset here should be two less (22 or 0x16 and not 24 or 0x18): 2 bytes set ID 2 bytes length 1 byte option data 16 bytes checksum data 1 byte pad (at #255) ...totalling 22. Thanks! -------------------------------------- RFC5655 (draft-ietf-ipfix-file-05) -------------------------------------- Title : Specification of the IP Flow Information Export (IPFIX) File Format Publication Date : October 2009 Author(s) : B. Trammell, E. Boschi, L. Mark, T. Zseby, A. Wagner Category : PROPOSED STANDARD Source : IP Flow Information Export Area : Operations and Management Stream : IETF Verifying Party : IESG From nobody Thu Mar 19 14:37:58 2015 Return-Path: X-Original-To: ipfix@ietfa.amsl.com Delivered-To: ipfix@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 51C821A910E for ; Thu, 19 Mar 2015 14:37:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.912 X-Spam-Level: X-Spam-Status: No, score=-106.912 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cPwdJ_WbCLnQ for ; Thu, 19 Mar 2015 14:37:55 -0700 (PDT) Received: from rfc-editor.org (rfc-editor.org [4.31.198.49]) by ietfa.amsl.com (Postfix) with ESMTP id F23821A90F4 for ; Thu, 19 Mar 2015 14:37:54 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id 71FEA180205; Thu, 19 Mar 2015 14:36:41 -0700 (PDT) To: brian.trammell@hitachi-eu.com, elisa.boschi@hitachi-eu.com, lutz.mark@ifam.fraunhofer.de, tanja.zseby@fokus.fraunhofer.de, arno@wagner.name, bclaise@cisco.com, joelja@bogus.com, n.brownlee@auckland.ac.nz, quittek@neclab.eu X-PHP-Originating-Script: 6000:errata_mail_lib.php From: RFC Errata System Message-Id: <20150319213641.71FEA180205@rfc-editor.org> Date: Thu, 19 Mar 2015 14:36:41 -0700 (PDT) Archived-At: Cc: ipfix@ietf.org, rfc-editor@rfc-editor.org Subject: [IPFIX] [Editorial Errata Reported] RFC5655 (4308) X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Mar 2015 21:37:56 -0000 The following errata report has been submitted for RFC5655, "Specification of the IP Flow Information Export (IPFIX) File Format". -------------------------------------- You may review the report below and at: http://www.rfc-editor.org/errata_search.php?rfc=5655&eid=4308 -------------------------------------- Type: Editorial Reported by: Paul Aitken Section: A.5 Original Text ------------- A.5. Complete File Example Bringing together the examples above and adding message headers as appropriate, a hex dump of the first 317 bytes of the example File constructed above would appear as in the annotated Figure 10 below. Corrected Text -------------- A.5. Complete File Example Bringing together the examples above and adding message headers as appropriate, a hex dump of the first 285 bytes of the example File constructed above would appear as in the annotated Figure 10 below. Notes ----- s/317/285/ Figure 10 shows 18 lines of 16 octets each, less three octets in the final row. (18 x 16 - 3) = 285 octets. This can also be confirmed by the revised numbering in errata 2030 - though note that the dump is numbered from octet zero: 272: 80 02 00 50 06 00 00 46 50 00 00 00 41 Since the offset of the final octet ("41") is 284, the overall length must be 285. Instructions: ------------- This erratum is currently posted as "Reported". If necessary, please use "Reply All" to discuss whether it should be verified or rejected. When a decision is reached, the verifying party (IESG) can log in to change the status and edit the report, if necessary. -------------------------------------- RFC5655 (draft-ietf-ipfix-file-05) -------------------------------------- Title : Specification of the IP Flow Information Export (IPFIX) File Format Publication Date : October 2009 Author(s) : B. Trammell, E. Boschi, L. Mark, T. Zseby, A. Wagner Category : PROPOSED STANDARD Source : IP Flow Information Export Area : Operations and Management Stream : IETF Verifying Party : IESG From nobody Fri Mar 20 01:47:11 2015 Return-Path: X-Original-To: ipfix@ietfa.amsl.com Delivered-To: ipfix@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 057CB1B2C87 for ; Fri, 20 Mar 2015 01:47:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.51 X-Spam-Level: X-Spam-Status: No, score=-14.51 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RCxPLh4DPdZS for ; Fri, 20 Mar 2015 01:47:08 -0700 (PDT) Received: from aer-iport-1.cisco.com (aer-iport-1.cisco.com [173.38.203.51]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F2C111B2C7F for ; Fri, 20 Mar 2015 01:47:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3905; q=dns/txt; s=iport; t=1426841228; x=1428050828; h=message-id:date:from:mime-version:to:subject:references: in-reply-to; bh=pmtH2KwpOl9zyHSScifkO2LYp8GTb6CBUF28jw33MRc=; b=Di7mAK2P8dIyk5niHNIA5GuxJyMcgvzEJU0K5Y0ZRIIOUzXUprHIFcnw HDruPWbKCp2oUucUPGp9BD/8eWTziSPnlEMofLlMCdKME0IjkxVmD37bb mzG0zz+pTIPIAaPY+J/jgkZqURz3PcioWvjPv8y5WLEkQnvqew699dFAl U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0CqBADm3QtV/xbLJq1cg1hagw7DO4V1AoIAAQEBAQEBfYQUAQEBBCNLGw8NAwECCiECAg8CNQcCCAYNBgIBAYgrDbE7mksBAQEBAQEBAQEBAQEBAQEBAQEBFQSLF4RgGAaCYoFFBZQ6hX+HA40lIoNvPTGCQwEBAQ X-IronPort-AV: E=Sophos;i="5.11,435,1422921600"; d="scan'208,217";a="411815113" Received: from aer-iport-nat.cisco.com (HELO aer-core-4.cisco.com) ([173.38.203.22]) by aer-iport-1.cisco.com with ESMTP; 20 Mar 2015 08:47:06 +0000 Received: from [10.61.93.26] (ams3-vpn-dhcp7451.cisco.com [10.61.93.26]) by aer-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id t2K8l5VZ018781 for ; Fri, 20 Mar 2015 08:47:06 GMT Message-ID: <550BDE89.40800@cisco.com> Date: Fri, 20 Mar 2015 09:47:05 +0100 From: Benoit Claise User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: "ipfix@ietf.org" References: <20150316234758.8282.1029.idtracker@ietfa.amsl.com> In-Reply-To: <20150316234758.8282.1029.idtracker@ietfa.amsl.com> X-Forwarded-Message-Id: <20150316234758.8282.1029.idtracker@ietfa.amsl.com> Content-Type: multipart/alternative; boundary="------------040405090005040401090804" Archived-At: Subject: [IPFIX] Fwd: WG Action: Conclusion of IP Flow Information Export (ipfix) X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Mar 2015 08:47:10 -0000 This is a multi-part message in MIME format. --------------040405090005040401090804 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Dear all, Thanks to all of you who have been participating to the existing IPFIX journey, and thanks to Jürgen and Nevil for driving this. Look at the produced set of specifications at https://datatracker.ietf.org/wg/ipfix/documents/. Great achievement. Regards, Benoit -------- Forwarded Message -------- Subject: WG Action: Conclusion of IP Flow Information Export (ipfix) Date: Mon, 16 Mar 2015 16:47:58 -0700 From: IESG Secretary Reply-To: ietf@ietf.org To: IETF Announcement List CC: n.brownlee@auckland.ac.nz, ipfix@ietf.org, quittek@neclab.eu The IP Flow Information Export (ipfix) working group in the Operations and Management Area has concluded. The IESG contact persons are Benoit Claise and Joel Jaeggli. The mailing list will remain open. --------------040405090005040401090804 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit Dear all,

Thanks to all of you who have been participating to the existing IPFIX journey, and thanks to Jürgen and Nevil for driving this.
Look at the produced set of specifications at https://datatracker.ietf.org/wg/ipfix/documents/. Great achievement.

Regards, Benoit

-------- Forwarded Message --------
Subject: WG Action: Conclusion of IP Flow Information Export (ipfix)
Date: Mon, 16 Mar 2015 16:47:58 -0700
From: IESG Secretary <iesg-secretary@ietf.org>
Reply-To: ietf@ietf.org
To: IETF Announcement List <ietf-announce@ietf.org>
CC: n.brownlee@auckland.ac.nz, ipfix@ietf.org, quittek@neclab.eu 


The IP Flow Information Export (ipfix) working group in the Operations 
and Management Area has concluded. The IESG contact persons are Benoit 
Claise and Joel Jaeggli.

The mailing list will remain open.


--------------040405090005040401090804-- From nobody Thu Mar 26 00:14:10 2015 Return-Path: X-Original-To: ipfix@ietfa.amsl.com Delivered-To: ipfix@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 121CA1ACDD1 for ; Thu, 26 Mar 2015 00:14:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.277 X-Spam-Level: X-Spam-Status: No, score=-1.277 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 14cDG215Rnen for ; Thu, 26 Mar 2015 00:14:06 -0700 (PDT) Received: from mail-la0-x22f.google.com (mail-la0-x22f.google.com [IPv6:2a00:1450:4010:c03::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9951A1A7002 for ; Thu, 26 Mar 2015 00:14:05 -0700 (PDT) Received: by lagg8 with SMTP id g8so38325656lag.1 for ; Thu, 26 Mar 2015 00:14:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=4wK+oL8IV0xGy78RcT0+guKshmPGCTTtgCP6kKOnpgw=; b=GO+1xmEJEJrIu9eVZVQ+wfAcfNZ5XY28uYR4fspm4hC0SRJ7wdMbp2TEzTXUpQjq1o Wkc6i6Tl3oCZDgvTCFT8Xbg+vyWT7td1OwrBIFDmiW+A89KbVbgP3GHyX9EZkOjdxJsP lykfA62iDQCYj4twf0XoF+qr/6k7M2TAh+2iLMijAg2M+7791YKs8/HL/BXi+bVYgHID yvJnJxnY+hlfbqJ3xXEiXodYJqghNFnzq21ICkbCjL4zHG60OoxAayf4P1+/tgRj+sQM AGHvbC886NqPGvCXHT40hKtVPwa3OhMbm0hLI14RqDH4PBdJz7++07gQWI302gqOaLR8 LjrA== MIME-Version: 1.0 X-Received: by 10.112.134.167 with SMTP id pl7mr11718315lbb.63.1427354043893; Thu, 26 Mar 2015 00:14:03 -0700 (PDT) Sender: thorgrin@gmail.com Received: by 10.25.16.17 with HTTP; Thu, 26 Mar 2015 00:14:03 -0700 (PDT) In-Reply-To: <54AC4097.1050602@plixer.com> References: <54AC4097.1050602@plixer.com> Date: Thu, 26 Mar 2015 08:14:03 +0100 X-Google-Sender-Auth: tCC7zqus4vpEKFgWsvxiVe_Cncs Message-ID: From: Petr Velan To: Andrew Feren Content-Type: multipart/alternative; boundary=089e011767f9c14c5405122bc233 Archived-At: Cc: ipfix@ietf.org Subject: Re: [IPFIX] NetFlow v9 to IPFIX conversion X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Mar 2015 07:14:08 -0000 --089e011767f9c14c5405122bc233 Content-Type: text/plain; charset=UTF-8 Hi Andrew, all, thank you for your explanation regarding nprobe. However, we also need a fallback for unknown exporters with IEs > 2^15. The generic requests for PENs need organization name, contact name and email address. I can try to request the PEN for NetFlow v9 compatibility myself, but I'd like it to be more public. Therefore, I suggest to complete the request with something like: *Organization Name*: NetFlow v9 to IPFIX *Contact Name*: IPFIX WG *Contact E-Mail: *ipfix@ietf.org This is just a first proposal to get things moving, please add your thoughts. Once the PEN is granted, we can move forward and explain its purpose in a short RFC. Petr On Tue, Jan 6, 2015 at 9:07 PM, Andrew Feren wrote: > Hi Petr, > > On 01/06/2015 07:03 AM, Petr Velan wrote: > > Hello all, > > I'm not sure whether this is the right place to ask, but we encountered > following problem when converting NetFlow v9 messages to IPFIX. > > Some vendors (I've heard of ntop) are using elements IDs large than 32767 > in NetFlow v9. When converting messages with these elements to IPFIX, they > are considered to be Enterprise Numbers. To generate proper IPFIX message, > we need to do one of the following: > a) Generate a list of the elements and map them to PEN of the correct > vendor. However, this would result in an attempt to cover all possible > elements that anybody used in NetFlow v9. Moreover, we would still have to > somehow handle the cases where the element is unknown > > This should help with ntop/nprobe > > Recent versions of nprobe (since version 5.5.5 I think) all use the > following mapping. > > PEN = 35632 and IPFIXID = (v9ID - 57472) > > For example, one v9 IE that nprobe exports is MYSQL_SERVER_VERSION 57667. > The IPFIX equivalent would be > MYSQL_SERVER_VERSION(35632/195). > > The nprobe docs have a complete list. > > Older versions of nprobe (pre ~2010) use IEs not in RFC 3954, but later > allocated in IANA. There is no good way to convert those v9 exports to > IPFIX. > > -Andrew > > > b) Request a PEN for NetFlow compatibility and just add this PEN for > every element that has ID larger than 32767. > > Personally, I believe that the b) is more general and error-prone. Do you > think, that it would be possible to dedicate whole PEN to this cause? > > Thank you for any opinions, > > Petr Velan > > > > _______________________________________________ > IPFIX mailing listIPFIX@ietf.orghttps://www.ietf.org/mailman/listinfo/ipfix > > > --089e011767f9c14c5405122bc233 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi Andrew, all,

thank you for your = explanation regarding nprobe.

However, we also need a fallback for = unknown exporters with IEs > 2^15. The generic requests for PENs need or= ganization name, contact name and email address. I can try to request the P= EN for NetFlow v9 compatibility myself, but I'd like it to be more publ= ic. Therefore, I suggest to complete the request with something like:
Organization Name: NetFlow v9 to IPFIX
Contact Na= me: IPFIX WG
Contact E-Mail: ipfix@ietf.org

This is just a first = proposal to get things moving, please add your thoughts. Once the PEN is gr= anted, we can move forward and explain its purpose in a short RFC.

=
Petr

On Tue, Jan 6, 2015 at 9:07 PM, Andrew Feren <andrewf@plixe= r.com> wrote:
=20 =20 =20
Hi Petr,

On 01/06/2015 07:03 AM, Petr Velan wrote:
=20
Hello all,

I'm not sure whether this is the right place to ask= , but we encountered following problem when converting NetFlow v9 messages to IPFIX.

Some vendors (I've heard of ntop) are using elements IDs large than 32767 in NetFlow v9. When converting messages with these elements to IPFIX, they are considered to be Enterprise Numbers. To generate proper IPFIX message, we need to do one of the following:
a) Generate a list of the elements and map them to PEN of the correct vendor. However, this would result in an attempt to cover all possible elements that anybody used in NetFlow v9. Moreover, we would still have to somehow handle the cases where the element is unknown
 This should help with ntop/nprobe

Recent versions of nprobe (since version 5.5.5 I think) all use the following mapping.

PEN =3D 35632 and IPFIXID =3D (v9ID - 57472)

For example, one v9 IE that nprobe exports is MYSQL_SERVER_VERSION 57667.=C2=A0 The IPFIX equivalent would be
MYSQL_SERVER_VERSION(35632/195).

The nprobe docs have a complete list.

Older versions of nprobe (pre ~2010) use IEs not in RFC 3954, but later allocated in IANA.=C2=A0 There is no good way to convert those v9 exports to IPFIX.

-Andrew


b) Request a PEN for NetFlow compatibility and just add this PEN for every element that has ID larger than 32767.

Personally, I believe that the b) is more general and error-prone. Do you think, that it would be possible to dedicate whole PEN to this cause?

Thank you for any opinions,

Petr Velan



________________________________________=
_______
IPFIX mailing list
IPFIX@ietf.org
h=
ttps://www.ietf.org/mailman/listinfo/ipfix


--089e011767f9c14c5405122bc233-- From nobody Thu Mar 26 01:44:10 2015 Return-Path: X-Original-To: ipfix@ietfa.amsl.com Delivered-To: ipfix@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4AC021AC413 for ; Thu, 26 Mar 2015 01:44:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.266 X-Spam-Level: X-Spam-Status: No, score=-2.266 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hzdMNYAE133l for ; Thu, 26 Mar 2015 01:44:07 -0700 (PDT) Received: from mx0b-000f0801.pphosted.com (mx0b-000f0801.pphosted.com [67.231.152.113]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5AD531A912A for ; Thu, 26 Mar 2015 01:44:07 -0700 (PDT) Received: from pps.filterd (m0000700.ppops.net [127.0.0.1]) by mx0b-000f0801.pphosted.com (8.14.7/8.14.7) with SMTP id t2Q8VjrM019304; Thu, 26 Mar 2015 01:43:59 -0700 Received: from brmwp-exchub01.corp.brocade.com ([208.47.132.227]) by mx0b-000f0801.pphosted.com with ESMTP id 1tc3ev17w2-1 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Thu, 26 Mar 2015 01:43:59 -0700 Received: from BRMWP-EXMB11.corp.brocade.com (172.16.59.77) by BRMWP-EXCHUB01.corp.brocade.com (172.16.186.99) with Microsoft SMTP Server (TLS) id 14.3.123.3; Thu, 26 Mar 2015 02:43:58 -0600 Received: from EMEAWP-CASH01.corp.brocade.com (172.29.18.10) by BRMWP-EXMB11.corp.brocade.com (172.16.59.77) with Microsoft SMTP Server (TLS) id 15.0.1044.25; Thu, 26 Mar 2015 02:43:57 -0600 Received: from [172.29.21.131] (172.29.21.131) by imapeu.brocade.com (172.29.18.15) with Microsoft SMTP Server (TLS) id 8.3.298.1; Thu, 26 Mar 2015 09:43:56 +0100 Message-ID: <5513C6CB.1040001@brocade.com> Date: Thu, 26 Mar 2015 08:43:55 +0000 From: Paul Aitken User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Icedove/31.5.0 MIME-Version: 1.0 To: Petr Velan , Andrew Feren References: <54AC4097.1050602@plixer.com> In-Reply-To: Content-Type: multipart/alternative; boundary="------------090609010209050008010700" X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.13.68, 1.0.33, 0.0.0000 definitions=2015-03-26_02:2015-03-25,2015-03-26,1970-01-01 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 suspectscore=1 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=7.0.1-1402240000 definitions=main-1503260089 Archived-At: Cc: joelja@bogus.com, "ipfix@ietf.org" Subject: Re: [IPFIX] NetFlow v9 to IPFIX conversion X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Mar 2015 08:44:09 -0000 --------------090609010209050008010700 Content-Type: text/plain; charset="utf-8"; format=flowed Content-Transfer-Encoding: 7bit Petr, You should write an RFC (well, start with a draft) which explains the proposal and requests the PEN from IANA. Since the IPFIX WG is now closed, such a draft must be AD sponsored by Joel. P. On 26/03/15 07:14, Petr Velan wrote: > Hi Andrew, all, > > thank you for your explanation regarding nprobe. > > However, we also need a fallback for unknown exporters with IEs > > 2^15. The generic requests for PENs need organization name, contact > name and email address. I can try to request the PEN for NetFlow v9 > compatibility myself, but I'd like it to be more public. Therefore, I > suggest to complete the request with something like: > *Organization Name*: NetFlow v9 to IPFIX > *Contact Name*: IPFIX WG > *Contact E-Mail: *ipfix@ietf.org > > This is just a first proposal to get things moving, please add your > thoughts. Once the PEN is granted, we can move forward and explain its > purpose in a short RFC. > > Petr > > On Tue, Jan 6, 2015 at 9:07 PM, Andrew Feren > wrote: > > Hi Petr, > > On 01/06/2015 07:03 AM, Petr Velan wrote: >> Hello all, >> >> I'm not sure whether this is the right place to ask, but we >> encountered following problem when converting NetFlow v9 messages >> to IPFIX. >> >> Some vendors (I've heard of ntop) are using elements IDs large >> than 32767 in NetFlow v9. When converting messages with these >> elements to IPFIX, they are considered to be Enterprise Numbers. >> To generate proper IPFIX message, we need to do one of the following: >> a) Generate a list of the elements and map them to PEN of the >> correct vendor. However, this would result in an attempt to cover >> all possible elements that anybody used in NetFlow v9. Moreover, >> we would still have to somehow handle the cases where the element >> is unknown > This should help with ntop/nprobe > > Recent versions of nprobe (since version 5.5.5 I think) all use > the following mapping. > > PEN = 35632 and IPFIXID = (v9ID - 57472) > > For example, one v9 IE that nprobe exports is MYSQL_SERVER_VERSION > 57667. The IPFIX equivalent would be > MYSQL_SERVER_VERSION(35632/195). > > The nprobe docs have a complete list. > > Older versions of nprobe (pre ~2010) use IEs not in RFC 3954, but > later allocated in IANA. There is no good way to convert those v9 > exports to IPFIX. > > -Andrew > > >> b) Request a PEN for NetFlow compatibility and just add this PEN >> for every element that has ID larger than 32767. >> >> Personally, I believe that the b) is more general and >> error-prone. Do you think, that it would be possible to dedicate >> whole PEN to this cause? >> >> Thank you for any opinions, >> >> Petr Velan >> >> >> >> _______________________________________________ >> IPFIX mailing list >> IPFIX@ietf.org >> https://www.ietf.org/mailman/listinfo/ipfix > > --------------090609010209050008010700 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: 8bit Petr,

You should write an RFC (well, start with a draft) which explains the proposal and requests the PEN from IANA.

Since the IPFIX WG is now closed, such a draft must be AD sponsored by Joel.

P.


On 26/03/15 07:14, Petr Velan wrote:
Hi Andrew, all,

thank you for your explanation regarding nprobe.

However, we also need a fallback for unknown exporters with IEs > 2^15. The generic requests for PENs need organization name, contact name and email address. I can try to request the PEN for NetFlow v9 compatibility myself, but I'd like it to be more public. Therefore, I suggest to complete the request with something like:
Organization Name: NetFlow v9 to IPFIX
Contact Name: IPFIX WG
Contact E-Mail: ipfix@ietf.org

This is just a first proposal to get things moving, please add your thoughts. Once the PEN is granted, we can move forward and explain its purpose in a short RFC.

Petr

On Tue, Jan 6, 2015 at 9:07 PM, Andrew Feren <andrewf@plixer.com> wrote:
Hi Petr,

On 01/06/2015 07:03 AM, Petr Velan wrote:
Hello all,

I'm not sure whether this is the right place to ask, but we encountered following problem when converting NetFlow v9 messages to IPFIX.

Some vendors (I've heard of ntop) are using elements IDs large than 32767 in NetFlow v9. When converting messages with these elements to IPFIX, they are considered to be Enterprise Numbers. To generate proper IPFIX message, we need to do one of the following:
a) Generate a list of the elements and map them to PEN of the correct vendor. However, this would result in an attempt to cover all possible elements that anybody used in NetFlow v9. Moreover, we would still have to somehow handle the cases where the element is unknown
 This should help with ntop/nprobe

Recent versions of nprobe (since version 5.5.5 I think) all use the following mapping.

PEN = 35632 and IPFIXID = (v9ID - 57472)

For example, one v9 IE that nprobe exports is MYSQL_SERVER_VERSION 57667.  The IPFIX equivalent would be
MYSQL_SERVER_VERSION(35632/195).

The nprobe docs have a complete list.

Older versions of nprobe (pre ~2010) use IEs not in RFC 3954, but later allocated in IANA.  There is no good way to convert those v9 exports to IPFIX.

-Andrew
b) Request a PEN for NetFlow compatibility and just add this PEN for every element that has ID larger than 32767.

Personally, I believe that the b) is more general and error-prone. Do you think, that it would be possible to dedicate whole PEN to this cause?

Thank you for any opinions,

Petr Velan



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



--------------090609010209050008010700--