From wwwrun@rfc-editor.org Mon Feb 1 07:17:43 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 9BB813A67B0 for ; Mon, 1 Feb 2010 07:17:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.565 X-Spam-Level: X-Spam-Status: No, score=-2.565 tagged_above=-999 required=5 tests=[AWL=0.035, 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 PSORBC4bTkBm for ; Mon, 1 Feb 2010 07:17:42 -0800 (PST) Received: from rfc-editor.org (rfc-editor.org [IPv6:2001:1890:1112:1::2f]) by core3.amsl.com (Postfix) with ESMTP id B502B3A6781 for ; Mon, 1 Feb 2010 07:17:42 -0800 (PST) Received: by rfc-editor.org (Postfix, from userid 30) id 7A787130001; Mon, 1 Feb 2010 07:18:17 -0800 (PST) To: brian.trammell@hitachi-eu.com, elisa.boschi@hitachi-eu.com, lutz.mark@ifam.fraunhofer.de, tanja.zseby@fokus.fraunhofer.de, arno@wagner.name, dromasca@avaya.com, rbonica@juniper.net, n.brownlee@auckland.ac.nz, quittek@netlab.nec.de From: RFC Errata System Message-Id: <20100201151817.7A787130001@rfc-editor.org> Date: Mon, 1 Feb 2010 07:18:17 -0800 (PST) Cc: rfc-editor@rfc-editor.org, ipfix@ietf.org, andrei.rohau@gmail.com Subject: [IPFIX] [Technical Errata Reported] RFC5655 (2030) 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, 01 Feb 2010 15:17:43 -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=2030 -------------------------------------- Type: Technical Reported by: Andrei Rohau Section: A.5, pg.56 Original Text ------------- 144: D6 C7 58 BE 44 E6 60 06 4E 78 74 AE 7D 00 00 00 176:|00 0A 00 50 47 0A B6 E5 00 00 00 01 00 00 00 01 [^ second message header (length 80 bytes) --> 192:|01 01 00 0E 00 47 0A B6 B9 47 0C 07 1B 00|01 02 [^ time window rec -> [ session detail rec ^ --> 208: 00 1C 00 C0 00 02 1E 0C 00 02 1F 80 01 12 83 84 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 [^ third message header (length 1296 bytes) --> 272:|01 00 04 E6|47 0A B6 B9 C0 00 02 02 C0 00 02 03 [^ set hdr ][^ first data rec --> 288: 80 02 00 50 06 00 00 46 50 00 00 00 41 Corrected Text -------------- 144: D6 C7 58 BE 44 E6 60 06 4E 78 74 AE 7D 00 00 00 160:|00 0A 00 50 47 0A B6 E5 00 00 00 01 00 00 00 01 [^ second message header (length 80 bytes) --> 176:|01 01 00 0E 00 47 0A B6 B9 47 0C 07 1B 00|01 02 [^ time window rec -> [ session detail rec ^ --> 192: 00 1C 00 C0 00 02 1E 0C 00 02 1F 80 01 12 83 84 208: 0A 47 0A B6 E5 47 0C 07 48 00|01 03 00 18 00 3E [ message checksum record ^ --> 224: 2B 37 08 CE B2 0E 30 11 32 12 4A 5F E3 AD DB 00 240:|00 0A 05 10 47 0A B6 E5 00 00 00 06 00 00 00 01 [^ third message header (length 1296 bytes) --> 256:|01 00 04 E6|47 0A B6 B9 C0 00 02 02 C0 00 02 03 [^ set hdr ][^ first data rec --> 272: 80 02 00 50 06 00 00 46 50 00 00 00 41 Notes ----- Should be pretty obvious as total size of the hex dump is only 285 bytes. Please note that the whole Figure 10 is supposed to contain 317 bytes! Instructions: ------------- This errata 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 dromasca@avaya.com Mon Feb 1 07: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 23F243A6A2D for ; Mon, 1 Feb 2010 07:22:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.401 X-Spam-Level: X-Spam-Status: No, score=-2.401 tagged_above=-999 required=5 tests=[AWL=0.198, 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 r66oWFYuB03Y for ; Mon, 1 Feb 2010 07:22:51 -0800 (PST) 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 A01D63A6A26 for ; Mon, 1 Feb 2010 07:22:50 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.49,383,1262581200"; d="scan'208";a="174795658" Received: from unknown (HELO co300216-co-erhwest.avaya.com) ([198.152.7.5]) by de307622-de-outbound.net.avaya.com with ESMTP; 01 Feb 2010 10:23:22 -0500 Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.11]) by co300216-co-erhwest-out.avaya.com with ESMTP; 01 Feb 2010 10:23:21 -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, 1 Feb 2010 16:22:43 +0100 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Technical Errata Reported] RFC5655 (2030) Thread-Index: AcqjUdQDgTLk8NYhSce1ck2eC9GGfAAAHtTw From: "Romascanu, Dan (Dan)" To: Subject: [IPFIX] FW: [Technical Errata Reported] RFC5655 (2030) 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, 01 Feb 2010 15:22:52 -0000 IPFIX WG, Please advice on the resolution for this Errata Report.=20 Thanks and Regards, Dan -----Original Message----- From: RFC Errata System [mailto:rfc-editor@rfc-editor.org]=20 Sent: Monday, February 01, 2010 5:18 PM To: brian.trammell@hitachi-eu.com; elisa.boschi@hitachi-eu.com; lutz.mark@ifam.fraunhofer.de; tanja.zseby@fokus.fraunhofer.de; arno@wagner.name; Romascanu, Dan (Dan); rbonica@juniper.net; n.brownlee@auckland.ac.nz; quittek@netlab.nec.de Cc: andrei.rohau@gmail.com; ipfix@ietf.org; rfc-editor@rfc-editor.org Subject: [Technical Errata Reported] RFC5655 (2030) 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=3D5655&eid=3D2030 -------------------------------------- Type: Technical Reported by: Andrei Rohau Section: A.5, pg.56 Original Text ------------- 144: D6 C7 58 BE 44 E6 60 06 4E 78 74 AE 7D 00 00 00 176:|00 0A 00 50 47 0A B6 E5 00 00 00 01 00 00 00 01 [^ second message header (length 80 bytes) --> 192:|01 01 00 0E 00 47 0A B6 B9 47 0C 07 1B 00|01 02 [^ time window rec -> [ session detail rec ^ --> 208: 00 1C 00 C0 00 02 1E 0C 00 02 1F 80 01 12 83 84 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 [^ third message header (length 1296 bytes) --> 272:|01 00 04 E6|47 0A B6 B9 C0 00 02 02 C0 00 02 03 [^ set hdr ][^ first data rec --> 288: 80 02 00 50 06 00 00 46 50 00 00 00 41 Corrected Text -------------- 144: D6 C7 58 BE 44 E6 60 06 4E 78 74 AE 7D 00 00 00 160:|00 0A 00 50 47 0A B6 E5 00 00 00 01 00 00 00 01 [^ second message header (length 80 bytes) --> 176:|01 01 00 0E 00 47 0A B6 B9 47 0C 07 1B 00|01 02 [^ time window rec -> [ session detail rec ^ --> 192: 00 1C 00 C0 00 02 1E 0C 00 02 1F 80 01 12 83 84 208: 0A 47 0A B6 E5 47 0C 07 48 00|01 03 00 18 00 3E [ message checksum record ^ --> 224: 2B 37 08 CE B2 0E 30 11 32 12 4A 5F E3 AD DB 00 240:|00 0A 05 10 47 0A B6 E5 00 00 00 06 00 00 00 01 [^ third message header (length 1296 bytes) --> 256:|01 00 04 E6|47 0A B6 B9 C0 00 02 02 C0 00 02 03 [^ set hdr ][^ first data rec --> 272: 80 02 00 50 06 00 00 46 50 00 00 00 41 Notes ----- Should be pretty obvious as total size of the hex dump is only 285 bytes. Please note that the whole Figure 10 is supposed to contain 317 bytes! Instructions: ------------- This errata 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.=20 -------------------------------------- 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 trammell@tik.ee.ethz.ch Mon Feb 1 07:37: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 95A9A28C0D7 for ; Mon, 1 Feb 2010 07:37:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hKjC+NT5uHiX for ; Mon, 1 Feb 2010 07:37:10 -0800 (PST) Received: from smtp.ee.ethz.ch (smtp.ee.ethz.ch [129.132.2.219]) by core3.amsl.com (Postfix) with ESMTP id 6E4093A6826 for ; Mon, 1 Feb 2010 07:37:10 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by smtp.ee.ethz.ch (Postfix) with ESMTP id EFF08D933D; Mon, 1 Feb 2010 16:37:42 +0100 (MET) X-Virus-Scanned: by amavisd-new on smtp.ee.ethz.ch Received: from smtp.ee.ethz.ch ([127.0.0.1]) by localhost (.ee.ethz.ch [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 2nOK+0uJpMnE; Mon, 1 Feb 2010 16:37:42 +0100 (MET) Received: from pb-10072.ethz.ch (pb-10072.ethz.ch [82.130.103.195]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: briant) by smtp.ee.ethz.ch (Postfix) with ESMTP id 951B5D9302; Mon, 1 Feb 2010 16:37:42 +0100 (MET) Mime-Version: 1.0 (Apple Message framework v1077) Content-Type: text/plain; charset=us-ascii From: Brian Trammell In-Reply-To: <20100201151817.7A787130001@rfc-editor.org> Date: Mon, 1 Feb 2010 16:37:39 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <5C576381-8DA6-4D96-BD02-0D11B158A91B@tik.ee.ethz.ch> References: <20100201151817.7A787130001@rfc-editor.org> To: RFC Errata System X-Mailer: Apple Mail (2.1077) Cc: ipfix@ietf.org, rbonica@juniper.net, andrei.rohau@gmail.com, brian.trammell@hitachi-eu.com, n.brownlee@auckland.ac.nz, tanja.zseby@fokus.fraunhofer.de, quittek@netlab.nec.de, arno@wagner.name Subject: Re: [IPFIX] [Technical Errata Reported] RFC5655 (2030) 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, 01 Feb 2010 15:37:11 -0000 Two points on this erratum: 1. Byte offsets in figure 10 are indeed incorrect (160 is skipped in the = sequence). Offsets from 176 (the 11th line in the dump) should have 16 = subtracted from each offset. The content of the dump is unchanged.=20 2. The introductory text has an incorrect byte count, as well, as it was = calculated from the final offset; the correct value is 301. OLD: 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. NEW: Bringing together the examples above and adding message headers as appropriate, a hex dump of the first 301 bytes of the example File constructed above would appear as in the annotated Figure 10 below. On Feb 1, 2010, at 4:18 PM, RFC Errata System wrote: >=20 > The following errata report has been submitted for RFC5655, > "Specification of the IP Flow Information Export (IPFIX) File Format". >=20 > -------------------------------------- > You may review the report below and at: > http://www.rfc-editor.org/errata_search.php?rfc=3D5655&eid=3D2030 >=20 > -------------------------------------- > Type: Technical > Reported by: Andrei Rohau >=20 > Section: A.5, pg.56 >=20 > Original Text > ------------- > 144: D6 C7 58 BE 44 E6 60 06 4E 78 74 AE 7D 00 00 00 >=20 > 176:|00 0A 00 50 47 0A B6 E5 00 00 00 01 00 00 00 01 > [^ second message header (length 80 bytes) --> > 192:|01 01 00 0E 00 47 0A B6 B9 47 0C 07 1B 00|01 02 > [^ time window rec -> [ session detail rec ^ --> > 208: 00 1C 00 C0 00 02 1E 0C 00 02 1F 80 01 12 83 84 >=20 > 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 >=20 > 256:|00 0A 05 10 47 0A B6 E5 00 00 00 06 00 00 00 01 > [^ third message header (length 1296 bytes) --> > 272:|01 00 04 E6|47 0A B6 B9 C0 00 02 02 C0 00 02 03 > [^ set hdr ][^ first data rec --> > 288: 80 02 00 50 06 00 00 46 50 00 00 00 41 >=20 > Corrected Text > -------------- > 144: D6 C7 58 BE 44 E6 60 06 4E 78 74 AE 7D 00 00 00 >=20 > 160:|00 0A 00 50 47 0A B6 E5 00 00 00 01 00 00 00 01 > [^ second message header (length 80 bytes) --> > 176:|01 01 00 0E 00 47 0A B6 B9 47 0C 07 1B 00|01 02 > [^ time window rec -> [ session detail rec ^ --> > 192: 00 1C 00 C0 00 02 1E 0C 00 02 1F 80 01 12 83 84 >=20 > 208: 0A 47 0A B6 E5 47 0C 07 48 00|01 03 00 18 00 3E > [ message checksum record ^ --> > 224: 2B 37 08 CE B2 0E 30 11 32 12 4A 5F E3 AD DB 00 >=20 > 240:|00 0A 05 10 47 0A B6 E5 00 00 00 06 00 00 00 01 > [^ third message header (length 1296 bytes) --> > 256:|01 00 04 E6|47 0A B6 B9 C0 00 02 02 C0 00 02 03 > [^ set hdr ][^ first data rec --> > 272: 80 02 00 50 06 00 00 46 50 00 00 00 41 >=20 > Notes > ----- > Should be pretty obvious as total size of the hex dump is only 285 = bytes. >=20 > Please note that the whole Figure 10 is supposed to contain 317 bytes! >=20 > Instructions: > ------------- > This errata 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.=20 >=20 > -------------------------------------- > 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 trammell@tik.ee.ethz.ch Mon Feb 1 08:09: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 19BA428C1AF for ; Mon, 1 Feb 2010 08:09:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=-0.001, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PxOXfwUuERoz for ; Mon, 1 Feb 2010 08:09:23 -0800 (PST) Received: from smtp.ee.ethz.ch (smtp.ee.ethz.ch [129.132.2.219]) by core3.amsl.com (Postfix) with ESMTP id 003B828C1A1 for ; Mon, 1 Feb 2010 08:09:22 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by smtp.ee.ethz.ch (Postfix) with ESMTP id 19090D932D; Mon, 1 Feb 2010 17:09:56 +0100 (MET) X-Virus-Scanned: by amavisd-new on smtp.ee.ethz.ch Received: from smtp.ee.ethz.ch ([127.0.0.1]) by localhost (.ee.ethz.ch [127.0.0.1]) (amavisd-new, port 10024) with LMTP id qXS9sWgirEFO; Mon, 1 Feb 2010 17:09:55 +0100 (MET) Received: from pb-10072.ethz.ch (pb-10072.ethz.ch [82.130.103.195]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: briant) by smtp.ee.ethz.ch (Postfix) with ESMTP id A68EBD9329; Mon, 1 Feb 2010 17:09:55 +0100 (MET) From: Brian Trammell Mime-Version: 1.0 (Apple Message framework v1077) Content-Type: multipart/alternative; boundary=Apple-Mail-19--1029414051 Date: Mon, 1 Feb 2010 17:09:54 +0100 In-Reply-To: <271305e11002010805m5cd3dcb7r12812e537fcd26bb@mail.gmail.com> To: RFC Errata System , brian.trammell@hitachi-eu.com, elisa.boschi@hitachi-eu.com, lutz.mark@ifam.fraunhofer.de, Tanja Zseby , Arno Wagner , Dan Romascanu , rbonica@juniper.net, Nevil Brownlee , quittek@netlab.nec.de, IETF IPFIX Working Group References: <20100201151817.7A787130001@rfc-editor.org> <5C576381-8DA6-4D96-BD02-0D11B158A91B@tik.ee.ethz.ch> <271305e11002010805m5cd3dcb7r12812e537fcd26bb@mail.gmail.com> Message-Id: <6ADE5806-CD70-4156-BE73-BEF5750001EF@tik.ee.ethz.ch> X-Mailer: Apple Mail (2.1077) Subject: Re: [IPFIX] [Technical Errata Reported] RFC5655 (2030) 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, 01 Feb 2010 16:09:24 -0000 --Apple-Mail-19--1029414051 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Replace point two as below. 2. The introductory text has an incorrect byte count, as well, as it was = calculated from (an apparently older) final offset; the correct value is = 285. OLD: 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. NEW: 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. On Feb 1, 2010, at 5:05 PM, Andrei Rohau wrote: > Brian, >=20 > Considering the section is supposed to provide a complete file example = with all the headers added, either hex dump should be amended with = missing bytes or the total count further reduced to the 285 bytes = presented. >=20 > Please advise. >=20 > Best Regards, > Andrei >=20 > On Mon, Feb 1, 2010 at 5:37 PM, Brian Trammell = wrote: > Two points on this erratum: >=20 > 1. Byte offsets in figure 10 are indeed incorrect (160 is skipped in = the sequence). Offsets from 176 (the 11th line in the dump) should have = 16 subtracted from each offset. The content of the dump is unchanged. >=20 > 2. The introductory text has an incorrect byte count, as well, as it = was calculated from the final offset; the correct value is 301. >=20 > OLD: >=20 > 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. >=20 > NEW: >=20 > Bringing together the examples above and adding message headers as > appropriate, a hex dump of the first 301 bytes of the example File > constructed above would appear as in the annotated Figure 10 below. >=20 --Apple-Mail-19--1029414051 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii
Replace point = two as below.

2. The introductory text has an incorrect byte = count, as well, as it was calculated from (an apparently older) final = offset; the correct value is 285.

OLD:

  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.

NEW:

  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.

Brian,

Considering the section is = supposed to provide a complete file example with all the headers added, = either hex dump should be amended with missing bytes or the total count = further reduced to the 285 bytes presented.

Please advise.

Best = Regards,
Andrei

On Mon, Feb = 1, 2010 at 5:37 PM, Brian Trammell <trammell@tik.ee.ethz.ch> wrote:
Two points on this erratum:

1. Byte offsets in figure 10 are indeed incorrect (160 is skipped in the = sequence). Offsets from 176 (the 11th line in the dump) should have 16 = subtracted from each offset. The content of the dump is unchanged.

2. The introductory text has an incorrect byte count, as well, as it was = calculated from the final offset; the correct value is 301.

OLD:

  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.

NEW:

  Bringing together the examples above and adding message headers = as
  appropriate, a hex dump of the first 301 bytes of the example = File
  constructed above would appear as in the annotated Figure 10 = below.


= --Apple-Mail-19--1029414051-- From andrei.rohau@gmail.com Mon Feb 1 08:05:00 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 D703A28C133 for ; Mon, 1 Feb 2010 08:05:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aIWA13xAdMuH for ; Mon, 1 Feb 2010 08:05:00 -0800 (PST) Received: from fg-out-1718.google.com (fg-out-1718.google.com [72.14.220.158]) by core3.amsl.com (Postfix) with ESMTP id ADB973A6960 for ; Mon, 1 Feb 2010 08:04:59 -0800 (PST) Received: by fg-out-1718.google.com with SMTP id 16so22900fgg.13 for ; Mon, 01 Feb 2010 08:05:30 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=bD3VskupjlvHayLHVhPeuO2vdGTXP1Doe0apCUB77J0=; b=OO1BFn9KxiArAU6ozaRZzPsayG9hKtFN0C0CGGnpYl1xVmWli8pcKwBoPzPaF24UBH macwWqg/+gmdZ22nWzgfD/dIRGP79AeYP3HBBVOkMi3UiQNOGEvEXo54V4iiFcESMZvi 6UwIpxeV4wdNiWe9ZyCz6wJFM3KtfzqkbPn5E= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=g8gWr8TGmPkv/gU9bIiTI4h1zPozcC3JUJqrrRuxcW/Xb4kDD2eVy9fjzEAdyan/Je S3oKLBPb94DGdxKzs+Oc/i6j2zU6rQlVmXC4265QdSjPWXf1c3r0FR5N2gec/t1MdS7o 3KcLXrprw1KidRLsMEkF6OTbGyTBIczQD90Ek= MIME-Version: 1.0 Received: by 10.87.5.15 with SMTP id h15mr7948849fgi.43.1265040329960; Mon, 01 Feb 2010 08:05:29 -0800 (PST) In-Reply-To: <5C576381-8DA6-4D96-BD02-0D11B158A91B@tik.ee.ethz.ch> References: <20100201151817.7A787130001@rfc-editor.org> <5C576381-8DA6-4D96-BD02-0D11B158A91B@tik.ee.ethz.ch> Date: Mon, 1 Feb 2010 18:05:29 +0200 Message-ID: <271305e11002010805m5cd3dcb7r12812e537fcd26bb@mail.gmail.com> From: Andrei Rohau To: Brian Trammell Content-Type: multipart/alternative; boundary=001485f893d27e6e3b047e8c2727 X-Mailman-Approved-At: Tue, 02 Feb 2010 00:13:58 -0800 Cc: ipfix@ietf.org, rbonica@juniper.net, brian.trammell@hitachi-eu.com, n.brownlee@auckland.ac.nz, tanja.zseby@fokus.fraunhofer.de, quittek@netlab.nec.de, arno@wagner.name, RFC Errata System Subject: Re: [IPFIX] [Technical Errata Reported] RFC5655 (2030) 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, 01 Feb 2010 16:08:52 -0000 --001485f893d27e6e3b047e8c2727 Content-Type: text/plain; charset=UTF-8 Brian, Considering the section is supposed to provide a complete file example with all the headers added, either hex dump should be amended with missing bytes or the total count further reduced to the 285 bytes presented. Please advise. Best Regards, Andrei On Mon, Feb 1, 2010 at 5:37 PM, Brian Trammell wrote: > Two points on this erratum: > > 1. Byte offsets in figure 10 are indeed incorrect (160 is skipped in the > sequence). Offsets from 176 (the 11th line in the dump) should have 16 > subtracted from each offset. The content of the dump is unchanged. > > 2. The introductory text has an incorrect byte count, as well, as it was > calculated from the final offset; the correct value is 301. > > OLD: > > 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. > > NEW: > > Bringing together the examples above and adding message headers as > appropriate, a hex dump of the first 301 bytes of the example File > constructed above would appear as in the annotated Figure 10 below. > > --001485f893d27e6e3b047e8c2727 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Brian,

Considering the section is supposed to provide a = complete file example with all the headers added, either hex dump should be= amended with missing bytes or the total count further reduced to the 285 b= ytes presented.

Please advise.

Best Regards,
Andrei

On Mon, Feb 1, 2010 at 5:= 37 PM, Brian Trammell <trammell@tik.ee.ethz.ch> wrote:
Two points on this erratum:

1. Byte offsets in figure 10 are indeed incorrect (160 is skipped in the se= quence). Offsets from 176 (the 11th line in the dump) should have 16 subtra= cted from each offset. The content of the dump is unchanged.

2. The introductory text has an incorrect byte count, as well, as it was ca= lculated from the final offset; the correct value is 301.

OLD:

=C2=A0 Bringing together the examples above and adding message headers as<= br> =C2=A0 appropriate, a hex dump of the first 317 bytes of the example File<= br> =C2=A0 constructed above would appear as in the annotated Figure 10 below.=

NEW:

=C2=A0 Bringing together the examples above and adding message headers as<= br> =C2=A0 appropriate, a hex dump of the first 301 bytes of the example File<= br> =C2=A0 constructed above would appear as in the annotated Figure 10 below.=

--001485f893d27e6e3b047e8c2727-- From dromasca@avaya.com Tue Feb 2 09:28: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 5047D3A6810 for ; Tue, 2 Feb 2010 09:28:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.44 X-Spam-Level: X-Spam-Status: No, score=-2.44 tagged_above=-999 required=5 tests=[AWL=0.159, 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 N-8eErE+eQLe for ; Tue, 2 Feb 2010 09:28:58 -0800 (PST) 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 8251E3A672E for ; Tue, 2 Feb 2010 09:28:57 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.49,391,1262581200"; d="scan'208";a="174973332" Received: from unknown (HELO co300216-co-erhwest.avaya.com) ([198.152.7.5]) by de307622-de-outbound.net.avaya.com with ESMTP; 02 Feb 2010 12:29:34 -0500 X-IronPort-AV: E=Sophos;i="4.49,391,1262581200"; d="scan'208";a="441806937" Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.11]) by co300216-co-erhwest-out.avaya.com with ESMTP; 02 Feb 2010 12:29:33 -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: Tue, 2 Feb 2010 18:29:06 +0100 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: AD review of draft-ietf-ipfix-mediators-problem-statement Thread-Index: AcqkLTj4vRbVP05SQiu7uLj+5dGbJw== From: "Romascanu, Dan (Dan)" To: Subject: [IPFIX] AD review of draft-ietf-ipfix-mediators-problem-statement 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, 02 Feb 2010 17:28:59 -0000 Please find below the AD review of draft-ietf-ipfix-mediators-problem-statement. The document is in pretty good shape, but I suggest that the editors review my technical and editorial comments and address them before deciding whether to revise the I-D or send the document directly to IETF Last Call.=20 Dan Technical T1. Section 5.3:=20 One way delay from the correlation of PSAMP Packet Reports from different Exporters along a specific path. I have two issues that are not clear to me at this point: - why is only the correlation delay between PSAMP packet reports taken into consideration and not between other type of packets as well?=20 - where does this correlation happen - at the destination point at collectors ingress?=20 T2. Section 5.5 cases 1 - what type of link aggregation are we talking about here? Layer 2 like in IEEE 802.3ad / IEEE 802.1AX? How is an IPFIX collector aware at all about which physical link in the trunk does a data record travel through or why would it matter - this should be completely transparent starting with the second half of layer two actually. Maybe I mis-understand?=20 T3. Section 5.5, Cases 3 and 4 - How are data records originating from different exporters in the same admin domain different areas, or different admin domain synchronized in order to be correlated? Is an unique collector assumed, or some synchronization process between collectors? (if this is just a requirement and the answer is in some other place please point me to it).=20 T4. Section 5.7 - why are (traditional) fixed telephony and mobile telephony mentioned here?=20 T5. I think that the protection of privacy and integrity of data stores should be added to the additional threats and vulnerabilities introduced by mediators taking onto account that Data Retention is listed in 5.7 as one of the applicability examples.=20 Editorial:=20 E1. Running id-nits results in the following warnings:=20 =3D=3D You're using the IETF Trust Provisions' Section 6.b License = Notice from 12 Sep 2009 rather than the newer Notice from 28 Dec 2009. (See http://trustee.ietf.org/license-info/) =3D=3D There are 1 instance of lines with private range IPv4 addresses = in the document. If these are generic example addresses, they should be changed to use any of the ranges defined in RFC3330 (or successor): 192.0.2.x, 198.51.100.x or 203.0.113.x. This refers to section 6.1 E2. Section 4.4 - ' ... made difficult by THE heterogeneous environment ...' E3. Section 5.1 - '... set OF Flow Keys ...' E4. Section 5.7 - '... the collecting infrastructure IS described in section 5.2 ...'=20 E5. Section 5.8 - ' ... the bandwidth for TRANSPORTING IPFIX is ...=20 E6. Should not Section 6.7 be named 'Exporting the Function Item and parameters' E7. Should not Section 7 be named Summary and Conclusions?=20 E8. Also in Section 7: s/the management between/the mapping between/ From dromasca@avaya.com Tue Feb 2 09:55:41 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 1B9763A6803 for ; Tue, 2 Feb 2010 09:55:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.445 X-Spam-Level: X-Spam-Status: No, score=-2.445 tagged_above=-999 required=5 tests=[AWL=0.154, 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 xBzhtyV3iaVY for ; Tue, 2 Feb 2010 09:55:40 -0800 (PST) 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 002E33A67FE for ; Tue, 2 Feb 2010 09:55:39 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.49,392,1262581200"; d="scan'208";a="2133502" 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; 02 Feb 2010 12:56:11 -0500 X-IronPort-AV: E=Sophos;i="4.49,392,1262581200"; d="scan'208";a="427507869" Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.11]) by p-us1-erheast-out.us1.avaya.com with ESMTP; 02 Feb 2010 12:55:35 -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: Tue, 2 Feb 2010 18:55:14 +0100 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: AD review of draft-ietf-ipfix-mediators-framework Thread-Index: AcqkMN9dyhs6UFjsRZOFQuG3gmQwyg== From: "Romascanu, Dan (Dan)" To: Subject: [IPFIX] AD review of draft-ietf-ipfix-mediators-framework 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, 02 Feb 2010 17:55:41 -0000 Please find below the AD review of draft-ietf-ipfix-mediators-framework. The document is in pretty good shape, but I suggest that the editors review my technical and editorial comments and address them before deciding whether to revise the I-D or send the document directly to IETF Last Call. Thanks and Regards, Dan Technical:=20 T1. I do not see the Data Retention use case mentioned in draft-ietf-mediators-problem-statement addressed in any way in this draft. Did I miss anything?=20 T2. In Section 5.3:=20 Maintaining additional information about output record streams, which includes information related to Original Exporter, and some configuration parameters related to each function. I think here we need to add the observation domain and the admin domain to the Original Exporter because of support for multiple exporters and correlation between domains T3. In section 7 - I cannot figure out how the collector knows what to fill in the Observation Domain ID when this is different from the incoming Observation Domain ID? Can you help by explaining how this works?=20 4. Data retention needs to be added to the security considerations - if relevant - related to T1 Editorial:=20 E1. running id-nits results in the following warnings:=20 tmp/draft-ietf-ipfix-mediators-framework-04.txt: tmp/draft-ietf-ipfix-mediators-framework-04.txt(405): Line has weird spacing: '...ributor one ...' tmp/draft-ietf-ipfix-mediators-framework-04.txt(407): Line has weird spacing: '...ntrator one o...' tmp/draft-ietf-ipfix-mediators-framework-04.txt(410): Line has weird spacing: '...erading one o...' tmp/draft-ietf-ipfix-mediators-framework-04.txt(530): Line has weird spacing: '...Reports recor...' tmp/draft-ietf-ipfix-mediators-framework-04.txt(547): Line has weird spacing: '...rvation into ...' Checking boilerplate required by RFC 5378 and the IETF Trust (see http://trustee.ietf.org/license-info): =20 ------------------------------------------------------------------------ ---- ** The document seems to lack a License Notice according IETF Trust Provisions of 28 Dec 2009, Section 6.b.i or Provisions of 12 Sep 2009 Section 6.b -- however, there's a paragraph with a matching beginning. Boilerplate error? IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 3: "This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License." =20 ... text found in draft: "This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents in effect on the date of publication of .................................^ this document (http://trustee.ietf.org/license-info). Please review these documents carefully, as they describe your rights and restrictions with respect to this document." (You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Feb 2009 rather than one of the newer Notices. See http://trustee.ietf.org/license-info/.) E2. Section 1.=20 To acihive application requirements with limited system resources, IPFIX architecture needs to introduce an intermediate device between Exporters and Collectors.=20 s/acihive/achieve/ Also 'device' has too much a hardware connotation, while mediators need not be necessarily hardware 'devices'. Probably 'component' or 'entity' is more appropriate.=20 E3. Part of the definitions in section 2 duplicate definitions in draft-ietf-mediators-problem-statement. Better avoid the duplication and just refer draft-ietf-mediators-problem-statement.=20 E4. Section 7 -=20 The IPFIX Message Header [RFC5101] includes Export Time, Sequence Number, and Observation Domain ID fields. This section describes some consideration points for the IPFIX Message Header encoding. Need to add 'in the context of IPFIX Mediation'. E5. Should not [IPFIX-MD-PS] be a Normative Reference?=20 From akoba@nttv6.net Mon Feb 8 08:09: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 ABF043A7228 for ; Mon, 8 Feb 2010 08:09:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[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 7jQOLQElq0QR for ; Mon, 8 Feb 2010 08:09:02 -0800 (PST) Received: from mail.nttv6.net (mail.nttv6.net [IPv6:2001:fa8::25]) by core3.amsl.com (Postfix) with ESMTP id B3C2E3A6D86 for ; Mon, 8 Feb 2010 08:09:01 -0800 (PST) Received: from [10.10.10.20] ([IPv6:2001:fa8:1000:0:58b4:5f98:900d:16af]) by mail.nttv6.net (8.14.3/8.14.3) with ESMTP id o18G9wCw088138; Tue, 9 Feb 2010 01:09:58 +0900 (JST) (envelope-from akoba@nttv6.net) Date: Tue, 09 Feb 2010 01:06:01 +0900 From: Atsushi Kobayashi To: "Romascanu, Dan (Dan)" In-Reply-To: References: Message-Id: <20100208163453.F021.17391CF2@nttv6.net> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Becky! ver. 2.50.05 [ja] (Unregistered) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.3 (mail.nttv6.net [IPv6:2001:fa8::25]); Tue, 09 Feb 2010 01:09:58 +0900 (JST) Cc: ipfix@ietf.org Subject: Re: [IPFIX] AD review of draft-ietf-ipfix-mediators-problem-statement 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, 08 Feb 2010 16:09:03 -0000 Hi Dan, and all, Thank you for your comments. Sorry for my late reply. Please see in-line. On Tue, 2 Feb 2010 18:29:06 +0100 "Romascanu, Dan (Dan)" wrote: > Please find below the AD review of > draft-ietf-ipfix-mediators-problem-statement. The document is in pretty > good shape, but I suggest that the editors review my technical and > editorial comments and address them before deciding whether to revise > the I-D or send the document directly to IETF Last Call. > > Dan > > > Technical > T1. Section 5.3: > > One way delay from the correlation of PSAMP Packet Reports from > different Exporters along a specific path. > > I have two issues that are not clear to me at this point: > - why is only the correlation delay between PSAMP packet reports taken > into consideration and not between other type of packets as well? For example, it can utilize the PSAMP Hash-Based filtering in section 6.2.1.2 in RFC5475. PSAMP Packet Reports, including the packet digest and the arrival time of the packet at the Observation Point, are reported to IPFIX Mediation, and then it calculates one way delay after identifying same digest from different Exporters. > - where does this correlation happen - at the destination point at > collectors ingress? I means the Observation Point along with Exporter path. I would like to replace it. One way delay from the correlation of PSAMP Packet Reports from different Exporters along a specific path. For example, one way delay is calculated from correlation of two PSAMP Packet Reports including the packet digest and the arrival time at Observation Point. This cases are described in section 6.2.1.2 in RFC5475. > > T2. Section 5.5 cases 1 - what type of link aggregation are we talking > about here? Layer 2 like in IEEE 802.3ad / IEEE 802.1AX? How is an IPFIX > collector aware at all about which physical link in the trunk does a > data record travel through or why would it matter - this should be > completely transparent starting with the second half of layer two > actually. Maybe I mis-understand? > I just mean IEEE 802.3ad. Operators commonly want to measure traffic data for trunk link, whether their observation points are trunk interface or not. In this case, IPFIX Collector needs to measure traffic volume per trunk link by aggregating data records observed at physical interface which is combined in same trunk link. I think that IPFIX mediator can export the traffic data per trunk link after aggregating data record including the traffic data per physical link. Current description seems sketchy explanation. I would like to replace it. o Cases 1: Spatial Composition within one Observation Domain For example, to measure the traffic for a single logical interface in the case where link aggregation exists, Data Records metered at physical interfaces belonging to the same trunk can be merged. > T3. Section 5.5, Cases 3 and 4 - How are data records originating from > different exporters in the same admin domain different areas, or > different admin domain synchronized in order to be correlated? Is an > unique collector assumed, or some synchronization process between > collectors? (if this is just a requirement and the answer is in some > other place please point me to it). > Traffic data per some area within a same admin domain comes from aggregation of data records based on info related to observation points. For example, an unique Collector knows where each Explorter exists, such as west or east, and then it works out traffic data per area based on Exporter IP address. In the same way, Traffic data per customer beyond admin domain comes from aggregation of data records. In this case, an unique Collector knows the customer in which each Explorter exists. I assume IPFIX mediators execute it instead for an unique Collector to reduce the load of Collector. It is just requirement. These aggregation method is described in section 5.3.2.3 in framework draft. > T4. Section 5.7 - why are (traditional) fixed telephony and mobile > telephony mentioned here? > As far as I know, originally data retention comes from requirement of traditional service. I means the starting point for data retension is traditional service to explain it. > T5. I think that the protection of privacy and integrity of data stores > should be added to the additional threats and vulnerabilities introduced > by mediators taking onto account that Data Retention is listed in 5.7 as > one of the applicability examples. > Yes. I would add the following paragraph in Security Consideration section. o Confidentiality protection and data integrity via IPFIX Mediation To ensure integrity and confidentiality of Data Records, its transport for Data Records should use Transport Layer Security (TLS) or Datagram Transport Layer Security (DTLS). However, an IPFIX Collector cannot know whether received Data Records are transported as encrypted data between an Original Exporter and an IPFIX Mediator. And an IPFIX Collector can also not certificate an Original Exporter directly. Some method would be required to make up for this deficiency. > > Editorial: > > E1. Running id-nits results in the following warnings: > > == You're using the IETF Trust Provisions' Section 6.b License Notice > from > 12 Sep 2009 rather than the newer Notice from 28 Dec 2009. (See > http://trustee.ietf.org/license-info/) > Ok. > == There are 1 instance of lines with private range IPv4 addresses in > the > document. If these are generic example addresses, they should be > changed > to use any of the ranges defined in RFC3330 (or successor): > 192.0.2.x, > 198.51.100.x or 203.0.113.x. > > This refers to section 6.1 > Ok. > E2. Section 4.4 - ' ... made difficult by THE heterogeneous environment > ...' > > E3. Section 5.1 - '... set OF Flow Keys ...' > Ok. I will change it as follows. A simplest set OF Flow Keys is a fixed 5-tuple of protocol... > E4. Section 5.7 - '... the collecting infrastructure IS described in > section 5.2 ...' > Ok. > E5. Section 5.8 - ' ... the bandwidth for TRANSPORTING IPFIX is ... > Ok. > E6. Should not Section 6.7 be named 'Exporting the Function Item and > parameters' > Ok. I will rename section 6.7. title. 6.7 IPFIX Mediation Interpretation > E7. Should not Section 7 be named Summary and Conclusions? > Ok. I will name the section 7 "Conclusion". > E8. Also in Section 7: s/the management between/the mapping between/ > Ok. Best Regards, Atsushi > _______________________________________________ > IPFIX mailing list > IPFIX@ietf.org > https://www.ietf.org/mailman/listinfo/ipfix --- Atsushi KOBAYASHI NTT Information Sharing Platform Lab. tel:+81-(0)422-59-3978 fax:+81-(0)422-59-5637 From akoba@nttv6.net Mon Feb 8 08:18: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 43A243A7446 for ; Mon, 8 Feb 2010 08:18:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.901 X-Spam-Level: X-Spam-Status: No, score=-0.901 tagged_above=-999 required=5 tests=[AWL=-1.700, BAYES_00=-2.599, J_CHICKENPOX_63=0.6, 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 a9OSVHJwCW2h for ; Mon, 8 Feb 2010 08:18:00 -0800 (PST) Received: from mail.nttv6.net (mail.nttv6.net [IPv6:2001:fa8::25]) by core3.amsl.com (Postfix) with ESMTP id 399F53A6881 for ; Mon, 8 Feb 2010 08:17:57 -0800 (PST) Received: from [10.10.10.20] ([IPv6:2001:fa8:1000:0:58b4:5f98:900d:16af]) by mail.nttv6.net (8.14.3/8.14.3) with ESMTP id o18GIujQ088175; Tue, 9 Feb 2010 01:18:56 +0900 (JST) (envelope-from akoba@nttv6.net) Date: Tue, 09 Feb 2010 01:15:02 +0900 From: Atsushi Kobayashi To: Atsushi Kobayashi In-Reply-To: <20100126100448.0A02.17391CF2@nttv6.net> References: <4B59DAB8.8040705@net.in.tum.de> <20100126100448.0A02.17391CF2@nttv6.net> Message-Id: <20100209010851.F028.17391CF2@nttv6.net> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Becky! ver. 2.50.05 [ja] (Unregistered) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.3 (mail.nttv6.net [IPv6:2001:fa8::25]); Tue, 09 Feb 2010 01:19:00 +0900 (JST) Cc: ipfix@ietf.org Subject: Re: [IPFIX] WGLC comments on draft-ietf-ipfix-configuration-model-04 X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Feb 2010 16:18:03 -0000 Hi Gerhard, and all, I find my following answer could not have been shared in list due to our network trouble. Regards, atsushi On Tue, 26 Jan 2010 10:37:23 +0900 Atsushi Kobayashi wrote: > > Hi Gerhard, > > Thank you for your reply. Please see in-line. > > On Fri, 22 Jan 2010 18:04:56 +0100 > Gerhard Muenz wrote: > > > > > Hi Atsushi, > > > > Please find answers to your comments inline. > > > > Regards, > > Gerhard > > > > > > > > Atsushi Kobayashi wrote: > > > Hi Gerhard, > > > > > > Sorry for late reply. > > > Please see in-line. > > > > > >>>> 1. Introduction > > >>>> > > >>>> IPFIX and PSAMP compliant Monitoring Devices (routers, switches, > > >>>> monitoring probes, Collectors etc.) offer various configuration > > >>>> possibilities that allow adapting network monitoring to the goals and > > >>>> purposes of the application, such as accounting and charging, traffic > > >>>> analysis, performance monitoring, security monitoring. The use of a > > >>>> common vendor-independent configuration data model for IPFIX and > > >>>> PSAMP compliant Monitoring Devices facilitates network management and > > >>>> configuration, especially if Monitoring Devices of different > > >>>> implementers and/or manufacturers are deployed simultaneously. On > > >>>> the one hand, a vendor-independent configuration data model helps > > >>>> storing and managing the configuration data of Monitoring Devices in > > >>>> a consistent format. On the other hand, it can be used for local and > > >>>> remote configuration of Monitoring Devices. However, this requires > > >>>> that Monitoring Devices natively support the configuration data > > >>>> model, or that a mapping between the configuration data model and the > > >>>> device-specific representation of configuration data is provided. > > >>>> > > >>> I want to confirm the meaning of "mapping" in last sentence. > > >>> If a vender deploy the different configuration model at first, does it > > >>> need to replace them with the common configuration data? > > >> No. > > >> > > >> "Mapping between the configuration data model and device-specific > > >> configuration data" means that CDM parameters must correspond to > > >> device-specific parameters. If this is fulfilled, the CDM can be easily > > >> converted into the device-specific data (CLI, XML, or whatever) and vice > > >> versa. On the other hand, if the device-specific parameters have a very > > >> different meaning, a conversion is not possible (or at least difficult). > > >> > > >> Side note: The conversion can be realized at different places, for example: > > >> - in the management system > > >> - on the device by running an agent > > >> > > >> What shall we do with the last sentence "However,...."? > > >> Remove it? > > >> > > > > > > Is it better to remove the following? > > > > > > "or that a mapping between the configuration data model and the > > > device-specific representation of configuration data is provided." > > > > Ok. > > > > >>>> The purpose of this document is the specification of a vendor- > > >>>> independent configuration data model that covers the commonly > > >>>> available configuration parameters of Selection Processes, Caches, > > >>>> Exporting Processes, and Collecting Processes. The configuration > > >>>> data model is defined using UML (Unified Modeling Language) class > > >>>> diagrams [UML] while the actual configuration data is encoded in > > >>>> Extensible Markup Language (XML) [W3C.REC-xml-20040204]. An XML > > >>>> document conforming to the configuration data model contains the > > >>>> configuration data of one Monitoring Device. In order to ensure > > >>>> compatibility with the NETCONF protocol [RFC4741], YANG > > >>>> [I-D.ietf-netmod-yang] is used as the modeling language. If > > >>>> required, the YANG specification of the configuration data model can > > >>>> be converted into XML Schema language [W3C.REC-xmlschema-0-20041028] > > >>>> using the pyang tool [YANG-WEB]. YANG provides mechanisms to adapt > > >>>> the configuration data model to device-specific constraints and to > > >>>> augment the model with additional device-specific or vendor-specific > > >>>> parameters. > > >>>> > > >>>> For the configuration of remote Monitoring Devices, an appropriate > > >>>> protocol is needed to transfer the XML encoded configuration data. > > >>>> The configuration data model is compatible with the NETCONF protocol > > >>>> [RFC4741]. However, alternative protocols, such as the Simple Object > > >>>> Access Protocol (SOAP) [W3C.REC-soap12-part1-20070427], are also > > >>>> suitable for transferring XML data from a network management system > > >>>> to a Monitoring Device. > > >>>> > > >> [snip] > > >> > > >>>> 2. Terminology > > >> [snip] > > >> > > >>>> In addition to the existing IPFIX and PSAMP terminology, the > > >>>> following terms are defined: > > >>>> > > >>>> Cache: The Cache is a functional block in a Metering Process which > > >>>> maintains IPFIX Flow Records or PSAMP Packet Reports. According > > >>>> to [RFC5101], the maintenance of Flow Records may include creating > > >>>> new records, updating existing ones, computing Flow statistics, > > >>>> deriving further Flow properties, detecting Flow expiration, > > >>>> passing Flow Records to the Exporting Process, and deleting Flow > > >>>> Records. The maintenance of Packet Reports covers the same set of > > >>>> functions. > > >>> In the case of PSAMP Packet Reports, how is the Cache used in Metering > > >>> Process? Is a PSAMP Packet Report maintained in Cache until deriving > > >>> further properties? It seems an implementation matter. > > >> The only difference between a PSAMP Packet Report and an IPFIX Flow > > >> Record is that the Packet Report always carries information about a > > >> single packet while the Flow Record may contain information about > > >> multiple packets. > > >> > > >> The CDM always includes a Cache as part of the Metering Process, even if > > >> Packet Reports are generated, because this is the place where the fields > > >> contained in the record are defined. The Cache Mode specifies the > > >> expiration policy and thus whether one or multiple packets are included > > >> in a record. > > >> > > >> Is there a need to clarify the definition of Cache? > > >> > > > Yes. > > > > > > In the case of Packet Reports, the current Cache definition does not > > > clarify what functions Cache has. > > > > NEW: > > > > Cache: The Cache is a functional block in a Metering Process which > > generates IPFIX Flow Records or PSAMP Packet Reports from a > > Selected Packet Stream, in accordance with its configuration. If > > Flow Records are generated, the Cache performs tasks like creating > > new records, updating existing ones, computing Flow statistics, > > deriving further Flow properties, detecting Flow expiration, > > passing Flow Records to the Exporting Process, and deleting Flow > > Records. If Packet Reports are generated, the Cache performs > > tasks like extracting packet contents and derived packet > > properties from the Selected Packet Stream, creating new records, > > and passing them as Packet Reports to the Exporting Process. > > > > > > Is this ok? > > > Fine. > > > > > >>>> Cache Layout: The Cache Layout defines the superset of fields that > > >>>> are included in the Packet Reports or Flow Records maintained by > > >>>> the Cache. The fields are specified by the corresponding > > >>>> Information Elements. In general, the largest possible subset of > > >>>> the specified fields is derived for every Packet Report or Flow > > >>>> Record. More specific rules about which fields must be included > > >>>> are given in Section 4.3.1. > > >>>> > > >>>> Cache Mode: The Cache Mode specifies whether Packet Reports or Flow > > >>>> Records are generated by the Cache. In the case of Flow Records, > > >>>> it also specifies the Flow expiration policy. > > >>>> > > >>>> Monitoring Device: A Monitoring Device implements at least one of > > >>>> the functional blocks specified in the context of IPFIX or PSAMP. > > >>>> In particular, the term Monitoring Device encompasses Exporters, > > >>>> Collectors, IPFIX Devices, and PSAMP Devices. > > >>>> > > >>>> Selected Packet Stream: The Selected Packet Stream is the set of all > > >>>> packets selected by a Selection Process. > > > > > > >>>> Beyond the basic Metering Process shown in Figure 1, the > > >>>> configuration data model enables the specification of more complex > > >>>> configurations. A single Cache may process the output of multiple > > >>>> Selection Processes. The Selected Packet Stream may be copied to > > >>> I cannot image that a single cache process the output from multiple Selection > > >>> Process. This sentence seems cause the inconsistency to the > > >>> definition of Observation Domain, when a Metering Process consisting of > > >>> a sequence of Selection Processes and Cahce. > > >> I do not understand your point. If there is any inconsistency, please > > >> explain it to me. > > >> > > > > > > When a single cache processes the input from multiple Selection Processes, > > > it is not clear what components compose a single Metering Process. > > > > > > Observed > > > Packet ----> Selection Process#1 -+ > > > Stream | > > > +----> Cache#1 ---> > > > Observed | > > > Packet ----> Selection Process#2 -+ > > > Stream > > > > > > If you mean SP#1, SP#2, and Cahce#1 compose Metering Process#1, Observed > > > packets at different Observation Domains can enter the same Metering > > > Process. > > > > > > Or you mean SP#1 and Cahce#1 compose Metering Process#1, and SP#2 and > > > Cache#1 compose Metering Process#2? > > > > Your example is a single Metering Process. > > > > > On the other hand, in the following case, SP#1, Cache#1 and Cache#2 > > > compose MP#1, or SP#1 and Cache#1 compose MP#1 and SP#1 and Cache#2 > > > compose MP#2? > > > > > > > > > Observed > > > Packet ----> Selection Process#1 -+----> Cache#1 ---> Flow > > > Stream | > > > +----> Cache#2 ---> Packet > > > > > > Could you clarify which components compose a single MP in complicated > > > cases? > > > > Again, a single Metering Process. > > > > The text says: > > > > In a Monitoring Device implementation, the functionality of the > > Metering Process is commonly split into packet Sampling and Filtering > > functions performed by Selection Processes, and the maintenance of > > Flow Records and Packet Reports performed by Caches. > > > > > > It talks about Caches (plural), so there is no limitation. > > > > What do you think about adding this sentence: > > > > A Metering Process may be composed of multiple Selection Processes > > and multiple Caches. > > Ok. > > > > > > > >>> And I have another question. Are Selection Processes after Cahce > > >>> available as an IPFIX Mediation? > > >> No. This RFC will not cover IPFPIX Mediation. > > >> > > > Ok. > > > > > > Have you already mentioned somewhere that the output of a Cache can not > > > be input of another Selection Process and Cache? > > > > The text says: > > > > As defined in [RFC5476], > > the Selection Process takes the Observed Packet Stream as its input > > and selects a subset of that stream as its output (Selected Packet > > Stream). > > > > So, it should be clear that a Selection Process cannot process Flow > > Records nor Packet Reports. > > > > > > Regarding the Cache, see the new definition proposed above: > > > > Cache: The Cache is a functional block in a Metering Process which > > generates IPFIX Flow Records or PSAMP Packet Reports from a > > Selected Packet Stream, in accordance with its configuration. > > > > > > So, it should be clear that a Cache takes a Selected Packet Stream as > > its input, not Flow Records or Packet Reports. > > > > This is also shown in Figur 1. > > > Ok. > > > > > >>>> enter several Caches, for example one Cache that generates Flow > > >>>> Records and another Cache that generates Packet Reports. Selection > > >>>> Processes can also be cascaded, such that the Selected Packet Stream > > >>>> at the output of one Selection Process is passed to another Selection > > >>>> Process. Cascading Selection Processes can be useful in specific > > >>>> contexts such as the example in Section 7.3. > > >>>> > > >>>> The selection of parameters in the configuration data model is based > > >>>> on configuration issues discussed in the IPFIX and PSAMP documents > > >>>> [RFC3917], [RFC5101], [RFC5470], [RFC5476], [RFC5474], and [RFC5475]. > > >>>> Furthermore, the structure and content of the IPFIX MIB module > > >>>> [I-D.ietf-ipfix-mib] and the PSAMP MIB module [I-D.ietf-psamp-mib] > > >>>> have been taken into consideration. Consistency between the > > >>>> configuration data model and the IPFIX and PSAMP MIB modules is an > > >>>> intended goal. Therefore, parameters in the configuration data model > > >>>> are named according to corresponding managed objects. Certain IPFIX > > >>>> MIB objects containing state data have been adopted as state > > >>>> parameters in the configuration data model. State parameters cannot > > >>>> be configured, yet their values can be queried from the Monitoring > > >>>> Device. > > >>> They can be queried from other devices as well as Monitoring Device. > > >> I do not understand. Why shall a Monitoring Device query state > > >> information from another Monitoring Device? > > > > > > I would like to say that generally other device(NMS or etc) as well as > > > Monitoring Device can query state parameters. > > > > Yes, NMS may query state parameters. Shall put this as an example? > > > > State parameters cannot > > be configured, yet their values can be queried from the Monitoring > > Device, for example by a network management station (NMS). > > > > > I am not sure why you limits only Monitoring Device on this. > > > But, it is minor question. > > > > I think that you misunderstand the phrase. It does NOT say: > > "their values can be queried BY the Monitoring Device" > > > > > Ok. > > > >>>> The next section explains how UML class diagrams are deployed to > > >>>> illustrate the structure of the configuration data model. > > >>>> Thereafter, Section 3.2 and Section 3.3 explain the class diagrams > > >>>> for the configuration of Exporters and Collectors, respectively. > > >>>> Each of the presented classes contains specific configuration > > >>>> parameters which are specified in Section 4. The formal definition > > >>>> of the configuration data model in YANG is given in Section 6. > > >>>> Section 7 illustrates the usage of the model with example > > >>>> configurations in XML. Section 5 gives a short introduction to YANG > > >>>> concepts that allow adapting the configuration data model to the > > >>>> capabilities of a device. > > >>>> > > > > > > [snip] > > > > > >>>> 3.2. Exporter Configuration > > >>>> > > >>>> Figure 4 below shows the main classes of the configuration data model > > >>>> which are involved in the configuration of an IPFIX or PSAMP > > >>>> Exporter. The role of the classes can be briefly summarized as > > >>>> follows: > > >>>> > > >>>> o The ObservationPoint class specifies an Observation Point (i.e., > > >>>> an interface or linecard) of the Monitoring Device at which > > >>>> packets are captured for traffic measurements. An object of the > > >>>> ObservationPoint class may be associated with one or more objects > > >>>> of the SelectionProcess class configuring Selection Processes that > > >>>> process the observed packets in parallel. As long as an > > >>>> ObservationPoint object is specified without any references to > > >>>> SelectionProcess objects, the Observation Point is not deployed > > >>>> for traffic measurements. > > >>>> > > >>>> o The SelectionProcess class contains the configuration parameters > > >>>> of a Selection Process. The Selection Process may be composed of > > >>>> a single Selector or a sequence of Selectors, defining a Primitive > > >>>> or Composite Selector, respectively. > > >>>> > > >>>> The Selection Process selects packets from an Observed Packet > > >>>> Stream originating from one or multiple Observation Points. > > >>>> Therefore, a SelectionProcess object MAY be referred to from > > >>>> multiple ObservationPoint objects. The corresponding Observation > > >>>> Points must belong to the same Observation Domain. > > >>> The Selection Process after Cache handles the Flow Records or Packet > > >>> Reports, not packets. > > >> All Selection Process are located in front of a Cache, not behind. > > >> > > > > > > Ok, please put above sentense in this document somewhere. > > > > See comment above. > > > > With the new term definition of Cache (which mentions Selected Packet > > Stream), I hope that this is clear now. > > > > Ok. > > > > > > >>>> 4.2. SelectionProcess Class > > >>>> > > >>>> +--------------------------------+ > > >>>> | SelectionProcess | > > >>>> +--------------------------------+ 1..* +----------+ > > >>>> | name |<>----------| Selector | > > >>>> | selectionSequenceId {readOnly} | +----------+ > > >>>> | | 0..* > > >>>> | |<---+ > > >>>> | | | > > >>>> | |----+ > > >>>> | | 0..* > > >>>> | | > > >>>> | | 0..* 0..* +----------+ > > >>>> | |----------->| Cache | > > >>>> +--------------------------------+ +----------+ > > >>>> > > >>>> Figure 7: SelectionProcess class > > >>>> > > >>>> Figure 7 shows the SelectionProcess class. The SelectionProcess > > >>>> class contains the configuration parameters of a Selection Process > > >>>> which selects packets from the Observed Packet Stream at its input > > >>>> and outputs the Selected Packet Stream to one or multiple other > > >>>> Selection Processes or Caches. A non-empty ordered list defines a > > >>>> sequence of Selectors. The actions defined by the Selectors are > > >>>> applied to the stream of incoming packet in the specified order. > > >>>> > > >>>> The state parameter selectionSequenceId contains the Selection > > >>>> Sequence ID (i.e., the value of the Information Element > > >>>> selectionSequenceId [RFC5477]) which is assigned by the Monitoring > > >>>> Device. The Selection Sequence ID MUST be unique within the > > >>>> Observation Domain as required by [RFC5477]. > > >>>> > > >>>> The output of one Selection Process MAY be processed by other > > >>>> Selection Processes. Therefore, the SelectionProcess class allows > > >>>> references to itself, meaning that one SelectionProcess object MAY > > >>>> refer to other SelectionProcess objects. > > >>>> > > >>>> A SelectionProcess object MAY include references to one or more > > >>>> objects of the Cache class configuring Caches that receive the > > >>>> Selected Packet Stream and generate corresponding Packet Reports or > > >>>> Flow Records. > > >>> If SelectionProcess class embodies the function of Metering Process, I > > >>> prefer the name of MeteringProcess class instead of SelectionProcess > > >>> from the consistency with IPFIX-MIB. > > >> I do not understand. SelectonProcess class corresponds to > > >> ipfixSelectionProcessTable in the IPFIX-MIB. > > >> > > > > > > In IPFIX-MIB, there is ipfixMeteringProcessTable related to Metering > > > Process. On the other hand, IPFIX-CONFIG does not have some object whose > > > name comes from Metering Process. Reader might look for it. > > > > > > And also, as I previously mentioned, it is not clear about the relation > > > among MP, SP, and Cache in complicated cases. > > > > See my proposed changes above. > > > > Ok. > > > > Could you add some Metering Process object, or describe clearly the > > > relation? > > > > We decided not to add any Metering Process class to the model because > > there are no parameters to configure. > > > > Another problem is that no other object would refer to a MeteringProcess > > object. ObservationPoint objects refer to explicit SelectionProcess > > objects. That cannot be changed. > > > > > > >>>> 4.2.1. Selector Class > > >>>> > > >>>> +--------------------------------------+ > > >>>> | Selector | > > >>>> +--------------------------------------+ 1 +-----------------+ > > >>>> | name |<>------+ SelectAll/ | > > >>>> | selectorId {readOnly} | | SampCountBased/ | > > >>>> | packetsObserved {readOnly} | | SampTimeBased/ | > > >>>> | packetsDropped {readOnly} | | SampRandOutOfN/ | > > >>>> | selectorDiscontinuityTime {readOnly} | | SampUniProb/ | > > >>>> | | | FilterMatch/ | > > >>>> | | | FilterHash/ | > > >>>> +--------------------------------------+ +-----------------+ > > >>>> > > >>>> Figure 8: Selector class > > >>>> > > >>>> The Selector class in Figure 8 contains the configuration and state > > >>>> parameters of a Selector. Standardized PSAMP Sampling and Filtering > > >>>> methods are described in [RFC5475]; their configuration parameters > > >>>> are specified in corresponding sampler (SampCountBased, > > >>>> SampTimeBased, SampRandOutOfN, SampUniProb) or filter (FilterMatch, > > >>>> FilterHash) classes. In addition, the SelectAll class, which has no > > >>>> parameters, is used for a Selector that selects all packets. The > > >>>> Selector class includes exactly one of these sampler and filter > > >>>> classes, depending on the applied method. > > >>>> > > >>>> The state parameter selectorId contains the Selector ID (i.e., the > > >>>> value of the Information Element selectorId [RFC5477]) assigned by > > >>>> the Monitoring Device. The Selector ID MUST be unique within the > > >>>> Observation Domain as required by [RFC5477]. > > >>>> > > >>>> As state parameters, the Selector class contains the Selector > > >>>> statistics packetsObserved and packetsDropped that correspond to the > > >>>> objects of the ipfixSelectorStatsTable in the IPFIX MIB module > > >>>> [I-D.ietf-ipfix-mib]. > > >>>> > > >> [snip] > > >> > > >>>> 4.2.3. Filter Classes > > >>>> > > >>>> +--------------------------+ > > >>>> | FilterMatch | > > >>>> +--------------------------+ > > >>>> | ieId/ieName | > > >>>> | ieEnterpriseNumber[0..1] | > > >>>> | value | > > >>>> +--------------------------+ > > >>>> > > >>>> +--------------------------+ > > >>>> | FilterHash | > > >>>> +--------------------------+ 1..* +---------------+ > > >>>> | hashFunction = BOB |<>-------| SelectedRange | > > >>>> | ipPayloadOffset = 0 | +---------------+ > > >>>> | ipPayloadSize = 8 | | name | > > >>>> | digestOutput = false | | min | > > >>>> | initialiserValue[0..1] | | max | > > >>>> +--------------------------+ +---------------+ > > >>>> > > >>>> Figure 10: Filter classes > > >>>> > > >>>> The Filter classes in Figure 10 contain the configuration parameters > > >>>> of specific Filtering methods. For property match filtering, the > > >>>> configuration parameters are: > > >>>> > > >>>> ieId, ieName, ieEnterpriseNumber: The property to be matched is > > >>>> specified by either ieId or ieName, specifying the ID or name of > > >>>> the Information Element, respectively. ieEnterpriseNumber MUST be > > >>>> used for enterprise-specific Information Elements. If > > >>>> ieEnterpriseNumber is omitted or zero, this is Information Element > > >>>> is not enterprise-specific but registered at IANA. > > >>>> > > >>>> value: Matching value. > > >>>> > > >>> Can the ranges of value be defined like hash value? > > >> No. The reason is that min/max fields are not specified in the Selector > > >> Report Interpretation: > > >> http://tools.ietf.org/html/rfc5476#section-6.5.2.5 > > >> > > >> In the case of FilterHash, we do min/max fields in the Selector Report > > >> Interpretation: > > >> http://tools.ietf.org/html/rfc5476#section-6.5.2.6 > > >> > > >>> And, I would like to specify its instruction, "match" or "unmatch". > > >> This is not specified in the Selector Report Interpretation. Therefore, > > >> we cannot allow configuring this. > > >> > > > > > > Above all, they apparently would be required from viewpoint of usability. > > > > I agree. But this is not the document to solve this problem. > > > > > Please see http://tools.ietf.org/html/rfc5475#section-6.1 that described > > > it as an extension of the basic model. > > > > > > Implementor will add above functions because only exact match is too > > > poor. In that case, can IPFIX-CONFIG expand to add these functions? > > > How does it expand? > > > > The model can be extensible by vendors or in later revisions of the model. > > > Ok, I understood what you would like to say. I am concerned that the > extensions are built indiscriminately. > > > > >>>> For hash-based filtering, the configuration parameters are: > > >>>> > > >>>> hashFunction: Hash function to be used. The following parameter > > >>>> values are defined by the configuration data model: > > >>>> * BOB: BOB Hash Function as specified in [RFC5475], Appendix A.2 > > >>>> * IPSX: IP Shift-XOR (IPSX) Hash Function as specified in > > >>>> [RFC5475], Appendix A.1 > > >>>> * CRC: CRC-32 function as specified in [RFC1141] > > >>>> Default value is "BOB". > > >>>> > > >>>> ipPayloadOffset, ipPayloadSize: ipPayloadOffset and ipPayloadSize > > >>>> configure the offset and the size of the payload section used as > > >>>> input to the hash function. Default values are 0 and 8, > > >>>> respectively, corresponding to the minimum configurable values > > >>>> according to [RFC5476], Section 6.2.5.6. These parameters > > >>>> correspond to the Information Elements hashIPPayloadOffset and > > >>>> hashIPPayloadSize [RFC5477]. > > >>>> > > >>>> digestOutput: digestOutput enables or disables the inclusion of the > > >>>> packet digest in the resulting PSAMP Packet Report. This requires > > >>>> that the Cache Layout of the Cache generating the Packet Reports > > >>>> includes a digestHashValue field. This parameter corresponds to > > >>>> the Information Element hashDigestOutput [RFC5477]. > > >>>> > > >>>> initialiserValue: Initializer value to the hash function. This > > >>>> parameter corresponds to the Information Element > > >>>> hashInitialiserValue [RFC5477]. If not configured by the user, > > >>>> the monitoring device arbitrarily chooses an initializer value. > > >>>> > > >>>> One or more ranges of matching hash values are defined by the min and > > >>>> max parameters of the SelectedRange subclass. These parameters > > >>>> correspond to the Information Elements hashSelectedRangeMin and > > >>>> hashSelectedRangeMax [RFC5477]. > > >>>> > > >>>> 4.3. Cache Class > > >>>> > > >>>> +-----------------------------------+ > > >>>> | Cache | > > >>>> +-----------------------------------+ 1 +-------------+ > > >>>> | name |<>----------| CacheLayout | > > >>>> | cacheMode | +-------------+ > > >>>> | maxRecords {opt.} | > > >>>> | activeTimeout {opt.} | 0..* 0..* +------------------+ > > >>>> | {except Cache Mode "immediate"} |----------->| ExportingProcess | > > >>>> | inactiveTimeout {opt.} | +------------------+ > > >>>> | {Cache Mode "timeout" only} | > > >>>> | activeFlows {readOnly} | > > >>>> | inactiveFlows {readOnly} | > > >>>> | cacheDataRecords {readOnly} | > > >>>> | cacheDiscontinuityTime {readOnly} | > > >>>> +-----------------------------------+ > > >>>> > > >>>> Figure 11: Cache class > > >>>> > > >>>> Figure 11 shows the Cache class that contains the configuration and > > >>>> state parameters of a Cache. The configuration parameters of the > > >>>> Cache class are as follows: > > >>>> > > >>>> cacheMode: Configures the Cache Mode. The following parameter > > >>>> values are specified by the configuration data model: > > >>>> * immediate: Data Records expire after the first packet > > >>>> * timeout: Data Records expire after active or inactive timeout > > >>>> * permanent: Data Records never expire, but are periodically > > >>>> exported with interval set by the active timeout > > >>>> In the case of "immediate", PSAMP Packet Reports are generated. > > >>>> Otherwise, IPFIX Flow Records are generated. > > >>>> > > >>>> maxRecords: Maximum number of Data Records in the Cache. If not > > >>>> configured by the user, the Monitoring Device sets this parameter. > > >>>> > > >>> When a cache becomes max Records, new Flow Records can be dropped or > > >>> push the old one? Does it depend on the implementation matter? > > >> There are various possibilities, such as dropping or early expiration of > > >> Flows. I do not think that we need to specify the behavior. > > >> > > > Ok. It is out of scope for the document. Could you please put above sentence. > > > > NEW: > > > > maxRecords: Maximum number of Data Records in the Cache. If the > > Cache stores this number of Data Records, no additional record can > > be created before any of the existing records is removed. If > > not configured by the user, the Monitoring Device sets this > > parameter. > > > > > > Is this ok? > > > Ok. > > > > > >>>> An object of the Cache class includes an object of the CacheLayout > > >>>> class that defines which fields are included in the Packet Reports or > > >>>> Flow Records. A Cache object MAY refer to one or multiple > > >>>> ExportingProcess objects configuring different Exporting Processes. > > >>>> > > >>>> As state parameters, the Cache class contains the Metering Process > > >>>> statistics activeFlows, inactiveFlows, and cacheDataRecords that > > >>>> correspond to the objects of the ipfixMeteringProcessStatsTable of > > >>>> the IPFIX MIB module [I-D.ietf-ipfix-mib]. > > >>>> > > >> [snip] > > >> > > >>>> 4.4.1. Destination Class > > >>>> > > >>>> +------------------------------------------------+ > > >>>> | Destination | > > >>>> +------------------------------------------------+ > > >>>> | name |<>-----+ > > >>>> | exportMemberType = parallel | | 0..1 > > >>>> | ipfixVersion = 10 | | > > >>>> | transportProtocol | +------------+ > > >>>> | destinationIpAddress | | Transport- | > > >>>> | destinationPort = 4739|4740 | | Layer- | > > >>>> | sendBufferSize {opt.} | | Security | > > >>>> | rateLimit[0..1] | +------------+ > > >>>> | localIpAddress[0..*] {SCTP only} | > > >>>> | timedReliability = 0 {SCTP only} | > > >>>> | numberOfStreams {opt.} {SCTP only} | > > >>>> | sourceIpAddress[0..1] {UDP only} | > > >>>> | templateRefreshTimeout = 600 {UDP only} | > > >>>> | optionsTemplateRefreshTimeout = 600 {UDP only} | > > >>>> | templateRefreshPacket[0..1] {UDP only} | > > >>>> | optionsTemplateRefreshPacket[0..1] {UDP only} | > > >>>> +------------------------------------------------+ > > >>>> > > >>>> Figure 14: Destination class > > >>>> > > >>>> The Destination class shown in Figure 14 contains the configuration > > >>>> parameters of one export destination (i.e., Collector) the Exporting > > >>>> Process sends IPFIX Messages to. Some of the parameters are only > > >>>> applicable if a specific transport protocol (SCTP, UDP, or TCP) is > > >>>> used. The following parameters apply to all transport protocols: > > >>>> > > >>>> exportMemberType: Configures the export member type that corresponds > > >>>> to the ipfixTransportSessionGroupMemberType object in > > >>>> [I-D.ietf-ipfix-mib]. The following parameter values are > > >>>> specified by the configuration data model: > > >>>> * primary: primary target of the Exporting Process > > >>>> * secondary: secondary target of the Exporting Process used when > > >>>> the primary target is not reachable > > >>>> * parallel: parallel exporting to all destinations and files of > > >>>> the Exporting Process > > >>>> * loadBalancing: load-balancing between different destinations > > >>>> and files of the Exporting Process > > >>>> "parallel" is the default value if this parameter is not > > >>>> configured. If one destination or file is configured as "primary" > > >>>> target, all other destinations and files must be configured as > > >>>> "secondary" targets. If "parallel" or "loadBalancing" is used, > > >>>> the same type must be configured for all destinations and File > > >>>> Writers of the Exporting Process. > > >>>> > > >>>> ipfixVersion: Version number of the IPFIX protocol used. If > > >>>> omitted, the default value is 10 (=0x000a) as specified in > > >>>> [RFC5101]. > > >>>> > > >>>> transportProtocol: One of "sctp", "udp", and "tcp". > > >>>> > > >>>> destinationIpAddress, destinationPort: Destination IP address and > > >>>> destination port number to be used. destinationIpAddress is a > > >>>> mandatory parameter. If destinationPort is omitted, standard port > > >>>> 4739 (IPFIX without TLS and DTLS) or 4740 (IPFIX over TLS or DTLS) > > >>>> is used. > > >>>> > > >>>> sendBufferSize: Size of the socket send buffer in bytes. > > >>>> > > >>>> rateLimit: Maximum number of bytes per second the Exporting Process > > >>>> may export to the given destination as required by [RFC5476]. The > > >>>> number of bytes is calculated from the lengths of the IPFIX > > >>>> Messages exported. If this parameter is not configured, no rate > > >>>> limiting is performed for this destination. > > >>>> > > >>>> The following parameters are applicable if SCTP is transport > > >>>> protocol: > > >>>> > > >>>> localIpAddress: This optional parameter MAY appear multiple times to > > >>>> specify the list of eligible local IP addresses of the SCTP > > >>>> association [RFC4960]. If omitted, all locally assigned IP > > >>>> addresses are used by the SCTP endpoint. > > >>>> > > >>>> timedReliability: Lifetime in milliseconds until an IPFIX Message > > >>>> containing Data Sets only is "abandoned" due to the timed > > >>>> reliability mechanism of PR-SCTP [RFC3758]. If this parameter is > > >>>> set to zero, reliable SCTP transport is used. > > >>>> > > >>>> numberOfStreams: Number of outbound streams requested for SCTP > > >>>> associations [RFC4960]. If not configured by the user, this > > >>>> parameter is set by the Monitoring Device. > > >>>> > > >>>> The following parameters are applicable if UDP is transport protocol: > > >>>> > > >>>> sourceIpAddress: This parameter sets the source IP address. If this > > >>>> parameter is omitted, the address assigned to the outgoing > > >>>> interface is used. > > >>>> > > >>> I would like to make available in the case of TCP. > > >> We adopted this parameter because the Cisco CLI has it for UDP. As far > > >> as I understand, it is not used to specify the outgoing interface but > > >> the (forged) source address in the IP header only. > > >> > > > No. In current network operation, source IP address is important > > > parameter as a indicator of exporting device(router). Operators are > > > often confused that a source IP address is changed when route changes > > > happen. Exporting device may select source address as a optimal exit points, or > > > arbitrarily. Then, some collectors may fail to recognize identical > > > exporting device before and after route changes. > > > > > > This function is necessary to avoid the confusion. > > > > I will ask Benoit how this parameter is used. > > > > >> How do you want to forge the IP address of a TCP endpoint? It must > > >> belong to the interface. > > >> > > >> The parameter description remains unclear in the case of multiple > > >> addresses assigned to a single interface. > > >> > > >> I'm not sure what to do. > > >> We can remove the parameter. > > >> We can change to "...one of the addresses assigned to the outgoing > > >> interface is used." > > >> We can try to find a generic solution that defines the outgoing interface. > > > > > > I propose the following. > > > > > > The following parameters are applicable if TCP or UDP is transport > > > protocol: > > > > > > sourceIpAddress: This parameter sets the source IP address. > > > If this parameter is omitted, Exporter selects outgoing interface > > > according to routing policy, and then arbitrarily assigns the address. > > > > You cannot use an arbitrary source IP address with TCP. > > > > I mean exporting device may select appropriate source ip > address as TCP client along with routing policy if the parameter is > omitted. The routing policy may change between before and after its > shutdown or link-failure, etc. This may cause in the case of TCP. > > In simple example, if you can use source IP address on loopback, it > avoid this problem. > > > >>>> templateRefreshTimeout, optionsTemplateRefreshTimeout, > > >>>> templateRefreshPacket, optionsTemplateRefreshPacket: Template > > >>>> refresh parameters when using UDP as transport protocol. > > >>>> templateRefreshTimeout and optionsTemplateRefreshTimeout are > > >>>> specified in seconds between resendings of (Options) Templates. > > >>>> If omitted, the default value of 600 seconds (10 minutes) is used > > >>>> [RFC5101]. templateRefreshPacket and optionsTemplateRefreshPacket > > >>>> are specified in number of IPFIX Messages. If omitted, the > > >>>> (Options) Templates are only resent after timeout. > > >>>> > > >>>> Using the TransportLayerSecurity class, transport layer security is > > >>>> enabled and configured for this export destination. If the transport > > >>>> protocol is SCTP or UDP, transport layer security is realized using > > >>>> DTLS. In the case of TCP, TLS is used instead. > > >>>> > > >> [snip] > > Regards, > Atsushi > > --- > Atsushi KOBAYASHI > NTT Information Sharing Platform Lab. > tel:+81-(0)422-59-3978 fax:+81-(0)422-59-5637 --- Atsushi KOBAYASHI NTT Information Sharing Platform Lab. tel:+81-(0)422-59-3978 fax:+81-(0)422-59-5637 From akoba@nttv6.net Tue Feb 9 07:27: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 AB4553A73C6 for ; Tue, 9 Feb 2010 07:27:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.75 X-Spam-Level: X-Spam-Status: No, score=-1.75 tagged_above=-999 required=5 tests=[AWL=0.850, 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 EptOA6w2o02q for ; Tue, 9 Feb 2010 07:27:37 -0800 (PST) Received: from mail.nttv6.net (mail.nttv6.net [IPv6:2001:fa8::25]) by core3.amsl.com (Postfix) with ESMTP id B78E13A73C5 for ; Tue, 9 Feb 2010 07:27:36 -0800 (PST) Received: from [10.10.10.20] ([IPv6:2001:fa8:1000:0:5454:6383:4753:9b58]) by mail.nttv6.net (8.14.3/8.14.3) with ESMTP id o19FSboS096932; Wed, 10 Feb 2010 00:28:37 +0900 (JST) (envelope-from akoba@nttv6.net) Date: Wed, 10 Feb 2010 00:24:37 +0900 From: Atsushi Kobayashi To: "Romascanu, Dan (Dan)" In-Reply-To: References: Message-Id: <20100209175816.09FB.17391CF2@nttv6.net> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Becky! ver. 2.50.05 [ja] (Unregistered) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.3 (mail.nttv6.net [IPv6:2001:fa8::25]); Wed, 10 Feb 2010 00:28:37 +0900 (JST) Cc: ipfix@ietf.org Subject: Re: [IPFIX] AD review of draft-ietf-ipfix-mediators-framework 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, 09 Feb 2010 15:27:38 -0000 Hi Dan, and all, Thank you for your comments. Sorry for my late reply. Please see in-line. On Tue, 2 Feb 2010 18:55:14 +0100 "Romascanu, Dan (Dan)" wrote: > Please find below the AD review of draft-ietf-ipfix-mediators-framework. > The document is in pretty good shape, but I suggest that the editors > review my technical and editorial comments and address them before > deciding whether to revise the I-D or send the document directly to IETF > Last Call. > > Thanks and Regards, > > Dan > > > Technical: > > T1. I do not see the Data Retention use case mentioned in > draft-ietf-mediators-problem-statement addressed in any way in this > draft. Did I miss anything? > Problem statement draft raised the following requirements about data retentions. - Reliable exporting In this case, an IPFIX Mediator beside an Original Exporter can enhance the export reliability by converting from UDP to SCP. This has relevance to section 5.3.2.1. "Intermediate Conversion Process". - Huge storage for data records In this case, an IPFIX Mediator re-exports data records stored to a Collector on demand. This has relevance to section 6.3. "IPFIX File Writer/Reader". I will improve the section 5.3.2.1. and section 6.3 as follows. 5.3.2.1. Intermediate Conversion Process [snip] [Old] In the case of IPFIX transport protocol conversion, the Intermediate Conversion Process covers the following functions. [New] In the case of IPFIX transport protocol conversion to enhance the export reliability, commonly used in data retention and accounting, the Intermediate Conversion Process covers the following functions. 6.3. IPFIX File Writer/Reader [snip] .-------------. .---------------. .---------------. .-----------. | IPFIX | | Intermediate | | Intermediate | | Exporting | | File | | Anonymization | | Correlation | | Process | | Reader +->| Process +->| Process +->| | '-------------' '---------------' '---------------' '-----------' Figure J: IPFIX Mediation Example with IPFIX File Reader. [New] When distributed IPFIX Mediators export Data Records stored on demand as like figure, it allows us to build the collecting infrastructure with huge storage for data retention. > T2. In Section 5.3: > > Maintaining additional information about output record streams, > which includes information related to Original Exporter, and some > configuration parameters related to each function. > > I think here we need to add the observation domain and the admin domain > to the Original Exporter because of support for multiple exporters and > correlation between domains I will replace it as follows. [New] Maintaining additional information about output record streams, which includes information related to Original Exporter, Observation Domain, and administrative domain and some configuration parameters related to each function. > > T3. In section 7 - I cannot figure out how the collector knows what to > fill in the Observation Domain ID when this is different from the > incoming Observation Domain ID? Can you help by explaining how this > works? Could you please see last sentense in section 7. But, it seems sketchy. I will replace it as follows. [Old] In that case, the IPFIX Concentrator can add a new field to the Flow Record instead of the Observation Domain ID. The field indicates the largest set of Observation Points for an aggregated Flow Record. [New] When an IPFIX Mediator needs to give the Observation Domain ID value exported from an Original Exporter to Collector, an IPFIX Mediator can insert this value as new fields into Flow Record, or Data Records defined by Options Templates. In the case of Flow Records aggregation in an IPFIX Mediator, this new field indicates the largest set of Observation Points for an aggregated Flow Record. I think this method will be described in detail in standard mediation protocol document at next stage. > > 4. Data retention needs to be added to the security considerations - if > relevant - related to T1 I put the feedback from problem statement draft, and will enhance them. > > > Editorial: > > E1. running id-nits results in the following warnings: > > > tmp/draft-ietf-ipfix-mediators-framework-04.txt: > tmp/draft-ietf-ipfix-mediators-framework-04.txt(405): Line has weird > spacing: '...ributor one ...' > tmp/draft-ietf-ipfix-mediators-framework-04.txt(407): Line has weird > spacing: '...ntrator one o...' > tmp/draft-ietf-ipfix-mediators-framework-04.txt(410): Line has weird > spacing: '...erading one o...' > tmp/draft-ietf-ipfix-mediators-framework-04.txt(530): Line has weird > spacing: '...Reports recor...' > tmp/draft-ietf-ipfix-mediators-framework-04.txt(547): Line has weird > spacing: '...rvation into ...' > > > Checking boilerplate required by RFC 5378 and the IETF Trust (see > http://trustee.ietf.org/license-info): > > ------------------------------------------------------------------------ > ---- > > ** The document seems to lack a License Notice according IETF Trust > Provisions of 28 Dec 2009, Section 6.b.i or Provisions of 12 Sep > 2009 > Section 6.b -- however, there's a paragraph with a matching > beginning. > Boilerplate error? > This document was submitted in October, 2009. Thus, it could not catch up with latest License Notice. I will take care in next version. > IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), > paragraph 3: > "This document is subject to BCP 78 and the IETF Trust's Legal > Provisions > Relating to IETF Documents (http://trustee.ietf.org/license-info) > in effect on the date of publication of this document. Please > review these documents carefully, as they describe your rights and > restrictions with respect to this document. Code Components > extracted from this document must include Simplified BSD License > text as described in Section 4.e of the Trust Legal Provisions and > are provided without warranty as described in the Simplified BSD > License." > > ... text found in draft: > "This document is subject to BCP 78 and the IETF Trust's Legal > Provisions > Relating to IETF Documents in effect on the date of publication of > .................................^ > this document (http://trustee.ietf.org/license-info). Please > review > these documents carefully, as they describe your rights and > restrictions with respect to this document." > > > (You're using the IETF Trust Provisions' Section 6.b License Notice > from > 12 Feb 2009 rather than one of the newer Notices. See > http://trustee.ietf.org/license-info/.) > > E2. Section 1. > > To acihive application requirements with limited system resources, > IPFIX architecture needs to introduce an intermediate device between > Exporters and Collectors. > > s/acihive/achieve/ > > Also 'device' has too much a hardware connotation, while mediators need > not be necessarily hardware 'devices'. Probably 'component' or 'entity' > is more appropriate. Thank you. > > E3. Part of the definitions in section 2 duplicate definitions in > draft-ietf-mediators-problem-statement. Better avoid the duplication and > just refer draft-ietf-mediators-problem-statement. > > E4. Section 7 - > > The IPFIX Message Header [RFC5101] includes Export Time, Sequence > Number, and Observation Domain ID fields. This section describes > some consideration points for the IPFIX Message Header encoding. > > Need to add 'in the context of IPFIX Mediation'. > Ok. > E5. Should not [IPFIX-MD-PS] be a Normative Reference? > [IPFIX-MD-PS] describes the concept of mediation as informative reference, does not describe the normative standard. Thus, I think it is a informative reference. Regards, Atsushi > > _______________________________________________ > IPFIX mailing list > IPFIX@ietf.org > https://www.ietf.org/mailman/listinfo/ipfix --- Atsushi KOBAYASHI NTT Information Sharing Platform Lab. tel:+81-(0)422-59-3978 fax:+81-(0)422-59-5637 From wwwrun@core3.amsl.com Thu Feb 11 09:27:02 2010 Return-Path: X-Original-To: ipfix@ietf.org Delivered-To: ipfix@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 30) id 2836628C117; Thu, 11 Feb 2010 09:27:01 -0800 (PST) X-idtracker: yes From: The IESG To: IETF-Announce Message-Id: <20100211172702.2836628C117@core3.amsl.com> Date: Thu, 11 Feb 2010 09:27:02 -0800 (PST) Cc: Internet Architecture Board , ipfix chair , ipfix mailing list , RFC Editor Subject: [IPFIX] Document Action: 'IPFIX Export per SCTP Stream' to Informational 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: Thu, 11 Feb 2010 17:27:02 -0000 The IESG has approved the following document: - 'IPFIX Export per SCTP Stream ' as an Informational RFC This document is the product of the IP Flow Information Export Working Group. The IESG contact persons are Dan Romascanu and Ron Bonica. A URL of this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ipfix-export-per-sctp-stream-06.txt Technical Summary This document specifies an improvement to the PR-SCTP export specified in the IPFIX specifications in RFC5101. This method offers several advantages such as the ability to calculate Data Record losses for PR-SCTP, immediate export of Template Withdrawal Messages, immediate reuse of Template IDs within an SCTP stream, and reduced demands on the Collecting Process. Working Group Summary This work was motivated by experiences made with early IPFIX implementations. It was accepted with consensus as WG work item and progressed within the WG. WG last call was conducted in August 2008. Modifications based on received comments were applied until November 2008. No more issues were brought up since then and at the IETF meeting in March 2009 the WG confirmed at the session that the document is ready for requesting publication. Document Quality IPFIX is implemented and deployed and this work is based on deployment experience. The document underwent several reviews and a WG last call in the IPFIX WG. This way, a high document quality has been achieved already. Personnel Juergen Quittek is shepherding this document. Dan Romascanu is the responsible Area Director. From root@core3.amsl.com Mon Feb 15 04:00: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 7AD5828C0E3; Mon, 15 Feb 2010 04:00:01 -0800 (PST) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20100215120001.7AD5828C0E3@core3.amsl.com> Date: Mon, 15 Feb 2010 04:00:01 -0800 (PST) Cc: ipfix@ietf.org Subject: [IPFIX] I-D Action:draft-ietf-ipfix-anon-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, 15 Feb 2010 12:00:01 -0000 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IP Flow Information Export Working Group of the IETF. Title : IP Flow Anonymisation Support Author(s) : E. Boschi, B. Trammell Filename : draft-ietf-ipfix-anon-02.txt Pages : 37 Date : 2010-02-15 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 technique 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-02.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-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2010-02-15034627.I-D@ietf.org> --NextPart-- From dromasca@avaya.com Mon Feb 15 04:06: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 EC22028C1A7 for ; Mon, 15 Feb 2010 04:06:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.52 X-Spam-Level: X-Spam-Status: No, score=-2.52 tagged_above=-999 required=5 tests=[AWL=0.079, 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 DaKAyFXHU4Gw for ; Mon, 15 Feb 2010 04:06:27 -0800 (PST) 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 64AF328C199 for ; Mon, 15 Feb 2010 04:06:27 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.49,476,1262581200"; d="scan'208";a="3630229" 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; 15 Feb 2010 07:07:57 -0500 X-IronPort-AV: E=Sophos;i="4.49,476,1262581200"; d="scan'208";a="431673630" Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.11]) by p-us1-erheast-out.us1.avaya.com with ESMTP; 15 Feb 2010 07:07:16 -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, 15 Feb 2010 13:07:13 +0100 Message-ID: In-Reply-To: <20100208163453.F021.17391CF2@nttv6.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [IPFIX] AD review of draft-ietf-ipfix-mediators-problem-statement Thread-Index: Acqo2S1z1x21o1phSteX9URfhlX2egFXMplQ References: <20100208163453.F021.17391CF2@nttv6.net> From: "Romascanu, Dan (Dan)" To: "Atsushi Kobayashi" Cc: ipfix@ietf.org Subject: Re: [IPFIX] AD review of draft-ietf-ipfix-mediators-problem-statement 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, 15 Feb 2010 12:06:29 -0000 Hi Atsushi, Please see in-line.=20 I am expecting for a revised version to be published before sending the document to IETF Last Call.=20 Thanks and Regards, Dan =20 > -----Original Message----- > From: Atsushi Kobayashi [mailto:akoba@nttv6.net]=20 > Sent: Monday, February 08, 2010 6:06 PM > To: Romascanu, Dan (Dan) > Cc: ipfix@ietf.org > Subject: Re: [IPFIX] AD review of=20 > draft-ietf-ipfix-mediators-problem-statement >=20 >=20 > Hi Dan, and all, >=20 > Thank you for your comments. Sorry for my late reply. > Please see in-line. >=20 > On Tue, 2 Feb 2010 18:29:06 +0100 > "Romascanu, Dan (Dan)" wrote: >=20 > > Please find below the AD review of > > draft-ietf-ipfix-mediators-problem-statement. The document is in=20 > > pretty good shape, but I suggest that the editors review my=20 > technical=20 > > and editorial comments and address them before deciding whether to=20 > > revise the I-D or send the document directly to IETF Last Call. > >=20 > > Dan > >=20 > >=20 > > Technical > > T1. Section 5.3:=20 > >=20 > > One way delay from the correlation of PSAMP Packet=20 > Reports from > > different Exporters along a specific path. > >=20 > > I have two issues that are not clear to me at this point: > > - why is only the correlation delay between PSAMP packet=20 > reports taken=20 > > into consideration and not between other type of packets as well? >=20 > For example, it can utilize the PSAMP Hash-Based filtering in section > 6.2.1.2 in RFC5475. PSAMP Packet Reports, including the=20 > packet digest and the arrival time of the packet at the=20 > Observation Point, are reported to IPFIX Mediation, and then=20 > it calculates one way delay after identifying same digest=20 > from different Exporters. Yes, but you did not answer my question. Why only this type of packets (PSAMP packet reports) and not other type of IPFIX packets can be used to measure one way delay correlation?=20 >=20 > > - where does this correlation happen - at the destination point at=20 > > collectors ingress? >=20 > I means the Observation Point along with Exporter path. >=20 > I would like to replace it. >=20 > One way delay from the correlation of PSAMP Packet Reports=20 > from different Exporters along a specific path. For example,=20 > one way delay is calculated from correlation of two PSAMP=20 > Packet Reports including the packet digest and the arrival=20 > time at Observation Point. This cases are described in=20 > section 6.2.1.2 in RFC5475. >=20 OK, but please address the question above.=20 > >=20 > > T2. Section 5.5 cases 1 - what type of link aggregation are=20 > we talking=20 > > about here? Layer 2 like in IEEE 802.3ad / IEEE 802.1AX? How is an=20 > > IPFIX collector aware at all about which physical link in the trunk=20 > > does a data record travel through or why would it matter -=20 > this should=20 > > be completely transparent starting with the second half of=20 > layer two=20 > > actually. Maybe I mis-understand? > >=20 >=20 > I just mean IEEE 802.3ad. >=20 Please clarify this and add IEEE 802.3ad as Informative Reference.=20 > Operators commonly want to measure traffic data for trunk=20 > link, whether their observation points are trunk interface or=20 > not. In this case, IPFIX Collector needs to measure traffic=20 > volume per trunk link by aggregating data records observed at=20 > physical interface which is combined in same trunk link. >=20 > I think that IPFIX mediator can export the traffic data per=20 > trunk link after aggregating data record including the=20 > traffic data per physical link. >=20 > Current description seems sketchy explanation. I would like=20 > to replace it. >=20 > o Cases 1: Spatial Composition within one Observation Domain >=20 > For example, to measure the traffic for a single logical=20 > interface in the case where link aggregation exists, Data=20 > Records metered at physical interfaces belonging to the same=20 > trunk can be merged. >=20 OK >=20 > > T3. Section 5.5, Cases 3 and 4 - How are data records=20 > originating from=20 > > different exporters in the same admin domain different areas, or=20 > > different admin domain synchronized in order to be=20 > correlated? Is an=20 > > unique collector assumed, or some synchronization process between=20 > > collectors? (if this is just a requirement and the answer=20 > is in some=20 > > other place please point me to it). > >=20 >=20 > Traffic data per some area within a same admin domain comes=20 > from aggregation of data records based on info related to=20 > observation points. For example, an unique Collector knows=20 > where each Explorter exists, such as west or east, and then=20 > it works out traffic data per area based on Exporter IP address. >=20 > In the same way, Traffic data per customer beyond admin=20 > domain comes from aggregation of data records. In this case,=20 > an unique Collector knows the customer in which each Explorter exists. >=20 > I assume IPFIX mediators execute it instead for an unique=20 > Collector to reduce the load of Collector. It is just requirement. >=20 > These aggregation method is described in section 5.3.2.3 in=20 > framework draft. It would be good to mention that unique collectors are assumed. Otherwise people may try to implement the functions on multiple collector which would imply usage of expensive time synchronization processes.=20 >=20 > > T4. Section 5.7 - why are (traditional) fixed telephony and mobile=20 > > telephony mentioned here? > >=20 >=20 > As far as I know, originally data retention comes from=20 > requirement of traditional service. I means the starting=20 > point for data retension is traditional service to explain it. >=20 This explanation is not clear to me. In order for IPFIX to carry traditional telephony traffic information this information needs to be translated into IP traffic using some kind of gateway. After that it does not differ to regular VoIP traffic originated by the gateway. So how are these cases different from VoIP?=20 > > T5. I think that the protection of privacy and integrity of data=20 > > stores should be added to the additional threats and=20 > vulnerabilities=20 > > introduced by mediators taking onto account that Data Retention is=20 > > listed in 5.7 as one of the applicability examples. > >=20 >=20 > Yes. I would add the following paragraph in Security=20 > Consideration section. >=20 > o Confidentiality protection and data integrity via IPFIX Mediation >=20 > To ensure integrity and confidentiality of Data Records, its=20 > transport for Data Records should use Transport Layer=20 > Security (TLS) or Datagram Transport Layer Security (DTLS).=20 > However, an IPFIX Collector cannot know whether received Data=20 > Records are transported as encrypted data between an Original=20 > Exporter and an IPFIX Mediator. And an IPFIX Collector can=20 > also not certificate an Original Exporter directly. Some=20 > method would be required to make up for this deficiency. >=20 OK. > >=20 > > Editorial:=20 > >=20 > > E1. Running id-nits results in the following warnings:=20 > >=20 > > =3D=3D You're using the IETF Trust Provisions' Section 6.b=20 > License Notice=20 > > from > > 12 Sep 2009 rather than the newer Notice from 28 Dec=20 > 2009. (See > > http://trustee.ietf.org/license-info/) > >=20 >=20 > Ok. >=20 > > =3D=3D There are 1 instance of lines with private range IPv4=20 > addresses in=20 > > the > > document. If these are generic example addresses,=20 > they should be=20 > > changed > > to use any of the ranges defined in RFC3330 (or successor): > > 192.0.2.x, > > 198.51.100.x or 203.0.113.x. > >=20 > > This refers to section 6.1 > >=20 >=20 > Ok. >=20 > > E2. Section 4.4 - ' ... made difficult by THE heterogeneous=20 > > environment ...' > >=20 > > E3. Section 5.1 - '... set OF Flow Keys ...' > >=20 >=20 > Ok. I will change it as follows. >=20 > A simplest set OF Flow Keys is a fixed 5-tuple of protocol... >=20 > > E4. Section 5.7 - '... the collecting infrastructure IS=20 > described in=20 > > section 5.2 ...' > >=20 > Ok. >=20 > > E5. Section 5.8 - ' ... the bandwidth for TRANSPORTING IPFIX is ...=20 > >=20 > Ok. >=20 > > E6. Should not Section 6.7 be named 'Exporting the Function=20 > Item and=20 > > parameters' > >=20 > Ok. I will rename section 6.7. title. >=20 > 6.7 IPFIX Mediation Interpretation >=20 > > E7. Should not Section 7 be named Summary and Conclusions?=20 > >=20 > Ok. I will name the section 7 "Conclusion". >=20 >=20 > > E8. Also in Section 7: s/the management between/the mapping between/ > >=20 > Ok. >=20 > Best Regards, > Atsushi >=20 > > _______________________________________________ > > IPFIX mailing list > > IPFIX@ietf.org > > https://www.ietf.org/mailman/listinfo/ipfix >=20 > --- > Atsushi KOBAYASHI > NTT Information Sharing Platform Lab. > tel:+81-(0)422-59-3978 fax:+81-(0)422-59-5637 >=20 >=20 From dromasca@avaya.com Mon Feb 15 04:09: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 830853A77E7 for ; Mon, 15 Feb 2010 04:09:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.521 X-Spam-Level: X-Spam-Status: No, score=-2.521 tagged_above=-999 required=5 tests=[AWL=0.078, 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 0Loccxh1BqMV for ; Mon, 15 Feb 2010 04:09:38 -0800 (PST) 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 225423A711D for ; Mon, 15 Feb 2010 04:09:38 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.49,476,1262581200"; d="scan'208";a="205080581" Received: from unknown (HELO p-us1-erheast.us1.avaya.com) ([135.11.50.53]) by co300216-co-outbound.net.avaya.com with ESMTP; 15 Feb 2010 07:11:07 -0500 X-IronPort-AV: E=Sophos;i="4.49,476,1262581200"; d="scan'208";a="431674508" Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.11]) by p-us1-erheast-out.us1.avaya.com with ESMTP; 15 Feb 2010 07:10: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, 15 Feb 2010 13:10:21 +0100 Message-ID: In-Reply-To: <20100209175816.09FB.17391CF2@nttv6.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [IPFIX] AD review of draft-ietf-ipfix-mediators-framework Thread-Index: AcqpnJTkyu2s3Z6CR/iDT6CQPrzOqgEmubGw References: <20100209175816.09FB.17391CF2@nttv6.net> From: "Romascanu, Dan (Dan)" To: "Atsushi Kobayashi" Cc: ipfix@ietf.org Subject: Re: [IPFIX] AD review of draft-ietf-ipfix-mediators-framework 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, 15 Feb 2010 12:09:39 -0000 Hi Atsushi, Your proposed edits are fine. I am expecting for a revised version to be published before sending the document to IETF Last Call.=20 Thanks and Regards, Dan=20 > -----Original Message----- > From: Atsushi Kobayashi [mailto:akoba@nttv6.net]=20 > Sent: Tuesday, February 09, 2010 5:25 PM > To: Romascanu, Dan (Dan) > Cc: ipfix@ietf.org > Subject: Re: [IPFIX] AD review of draft-ietf-ipfix-mediators-framework >=20 >=20 > Hi Dan, and all, >=20 > Thank you for your comments. Sorry for my late reply. > Please see in-line. >=20 > On Tue, 2 Feb 2010 18:55:14 +0100 > "Romascanu, Dan (Dan)" wrote: >=20 > > Please find below the AD review of=20 > draft-ietf-ipfix-mediators-framework. > > The document is in pretty good shape, but I suggest that=20 > the editors=20 > > review my technical and editorial comments and address them before=20 > > deciding whether to revise the I-D or send the document directly to=20 > > IETF Last Call. > >=20 > > Thanks and Regards, > >=20 > > Dan > >=20 > >=20 > > Technical:=20 > >=20 > > T1. I do not see the Data Retention use case mentioned in=20 > > draft-ietf-mediators-problem-statement addressed in any way in this=20 > > draft. Did I miss anything? > >=20 >=20 > Problem statement draft raised the following requirements=20 > about data retentions. >=20 > - Reliable exporting > In this case, an IPFIX Mediator beside an Original Exporter=20 > can enhance the export reliability by converting from UDP to=20 > SCP. This has relevance to section 5.3.2.1. "Intermediate=20 > Conversion Process". >=20 > - Huge storage for data records > In this case, an IPFIX Mediator re-exports data records=20 > stored to a Collector on demand. This has relevance to=20 > section 6.3. "IPFIX File Writer/Reader". >=20 > I will improve the section 5.3.2.1. and section 6.3 as follows. >=20 > 5.3.2.1. Intermediate Conversion Process >=20 > [snip] >=20 > [Old] > In the case of IPFIX transport protocol conversion, the=20 > Intermediate Conversion Process covers the following functions. >=20 > [New] > In the case of IPFIX transport protocol conversion to enhance=20 > the export reliability, commonly used in data retention and=20 > accounting, the Intermediate Conversion Process covers the=20 > following functions. >=20 > 6.3. IPFIX File Writer/Reader >=20 > [snip] >=20 > .-------------. .---------------. .---------------. =20 > .-----------. > | IPFIX | | Intermediate | | Intermediate | |=20 > Exporting | > | File | | Anonymization | | Correlation | | =20 > Process | > | Reader +->| Process +->| Process +->| =20 > | > '-------------' '---------------' '---------------' =20 > '-----------' >=20 > Figure J: IPFIX Mediation Example with IPFIX File Reader. >=20 > [New] > When distributed IPFIX Mediators export Data Records stored=20 > on demand as like figure, it allows us to build the=20 > collecting infrastructure with huge storage for data retention. >=20 >=20 > > T2. In Section 5.3:=20 > >=20 > > Maintaining additional information about output record streams, > > which includes information related to Original=20 > Exporter, and some > > configuration parameters related to each function. > >=20 > > I think here we need to add the observation domain and the admin=20 > > domain to the Original Exporter because of support for multiple=20 > > exporters and correlation between domains >=20 > I will replace it as follows. >=20 > [New] > Maintaining additional information about output record=20 > streams, which includes information related to Original=20 > Exporter, Observation Domain, and administrative domain and=20 > some configuration parameters related to each function. >=20 > >=20 > > T3. In section 7 - I cannot figure out how the collector=20 > knows what to=20 > > fill in the Observation Domain ID when this is different from the=20 > > incoming Observation Domain ID? Can you help by explaining how this=20 > > works? >=20 > Could you please see last sentense in section 7. But, it=20 > seems sketchy. > I will replace it as follows. >=20 >=20 > [Old] > In that case, the IPFIX Concentrator can add a new field to=20 > the Flow Record instead of the Observation Domain ID. The=20 > field indicates the largest set of Observation Points for an=20 > aggregated Flow Record. >=20 > [New] > When an IPFIX Mediator needs to give the Observation Domain=20 > ID value exported from an Original Exporter to Collector, an=20 > IPFIX Mediator can insert this value as new fields into Flow=20 > Record, or Data Records defined by Options Templates. In the=20 > case of Flow Records aggregation in an IPFIX Mediator, this=20 > new field indicates the largest set of Observation Points for=20 > an aggregated Flow Record. >=20 > I think this method will be described in detail in standard=20 > mediation protocol document at next stage. >=20 > >=20 > > 4. Data retention needs to be added to the security=20 > considerations -=20 > > if relevant - related to T1 >=20 > I put the feedback from problem statement draft, and will=20 > enhance them. >=20 > >=20 > >=20 > > Editorial:=20 > >=20 > > E1. running id-nits results in the following warnings:=20 > >=20 > >=20 > > tmp/draft-ietf-ipfix-mediators-framework-04.txt: > > tmp/draft-ietf-ipfix-mediators-framework-04.txt(405): Line has weird > > spacing: '...ributor one ...' > > tmp/draft-ietf-ipfix-mediators-framework-04.txt(407): Line has weird > > spacing: '...ntrator one o...' > > tmp/draft-ietf-ipfix-mediators-framework-04.txt(410): Line has weird > > spacing: '...erading one o...' > > tmp/draft-ietf-ipfix-mediators-framework-04.txt(530): Line has weird > > spacing: '...Reports recor...' > > tmp/draft-ietf-ipfix-mediators-framework-04.txt(547): Line has weird > > spacing: '...rvation into ...' > >=20 > >=20 > > Checking boilerplate required by RFC 5378 and the IETF Trust (see > > http://trustee.ietf.org/license-info): > > =20 > >=20 > ---------------------------------------------------------------------- > > -- > > ---- > >=20 > > ** The document seems to lack a License Notice according=20 > IETF Trust > > Provisions of 28 Dec 2009, Section 6.b.i or Provisions=20 > of 12 Sep > > 2009 > > Section 6.b -- however, there's a paragraph with a matching=20 > > beginning. > > Boilerplate error? > >=20 >=20 > This document was submitted in October, 2009. Thus, it could=20 > not catch up with latest License Notice. I will take care in=20 > next version. >=20 >=20 > > IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i),=20 > > paragraph 3: > > "This document is subject to BCP 78 and the IETF Trust's Legal=20 > > Provisions > > Relating to IETF Documents=20 > (http://trustee.ietf.org/license-info) > > in effect on the date of publication of this document. Please > > review these documents carefully, as they describe=20 > your rights and > > restrictions with respect to this document. Code Components > > extracted from this document must include Simplified=20 > BSD License > > text as described in Section 4.e of the Trust Legal=20 > Provisions and > > are provided without warranty as described in the=20 > Simplified BSD > > License." =20 > >=20 > > ... text found in draft: > > "This document is subject to BCP 78 and the IETF Trust's Legal=20 > > Provisions > > Relating to IETF Documents in effect on the date of=20 > publication=20 > > of .................................^ > > this document (http://trustee.ietf.org/license-info). Please=20 > > review > > these documents carefully, as they describe your rights and > > restrictions with respect to this document." > >=20 > >=20 > > (You're using the IETF Trust Provisions' Section 6.b License=20 > > Notice from > > 12 Feb 2009 rather than one of the newer Notices. See > > http://trustee.ietf.org/license-info/.) > >=20 > > E2. Section 1.=20 > >=20 > > To acihive application requirements with limited system resources, > > IPFIX architecture needs to introduce an intermediate=20 > device between > > Exporters and Collectors.=20 > >=20 > > s/acihive/achieve/ > >=20 > > Also 'device' has too much a hardware connotation, while mediators=20 > > need not be necessarily hardware 'devices'. Probably=20 > 'component' or 'entity' > > is more appropriate.=20 >=20 > Thank you.=20 >=20 > >=20 > > E3. Part of the definitions in section 2 duplicate definitions in=20 > > draft-ietf-mediators-problem-statement. Better avoid the=20 > duplication=20 > > and just refer draft-ietf-mediators-problem-statement. > >=20 > > E4. Section 7 - > >=20 > > The IPFIX Message Header [RFC5101] includes Export Time, Sequence > > Number, and Observation Domain ID fields. This section describes > > some consideration points for the IPFIX Message Header encoding. > >=20 > > Need to add 'in the context of IPFIX Mediation'. > >=20 > Ok. >=20 > > E5. Should not [IPFIX-MD-PS] be a Normative Reference?=20 > >=20 >=20 > [IPFIX-MD-PS] describes the concept of mediation as=20 > informative reference, does not describe the normative standard. > Thus, I think it is a informative reference. >=20 > Regards, > Atsushi >=20 > >=20 > > _______________________________________________ > > IPFIX mailing list > > IPFIX@ietf.org > > https://www.ietf.org/mailman/listinfo/ipfix >=20 > --- > Atsushi KOBAYASHI > NTT Information Sharing Platform Lab. > tel:+81-(0)422-59-3978 fax:+81-(0)422-59-5637 >=20 >=20 From muenz@net.in.tum.de Mon Feb 15 04:14: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 F17E128C0FF for ; Mon, 15 Feb 2010 04:14:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.249 X-Spam-Level: X-Spam-Status: No, score=-2.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1w9d2GyvacrA for ; Mon, 15 Feb 2010 04:14:29 -0800 (PST) Received: from mail-out1.informatik.tu-muenchen.de (mail-out1.informatik.tu-muenchen.de [131.159.0.8]) by core3.amsl.com (Postfix) with ESMTP id 50D8A3A7228 for ; Mon, 15 Feb 2010 04:14:28 -0800 (PST) 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 4418A200C265; Mon, 15 Feb 2010 13:15:40 +0100 (CET) Message-ID: <4B793B9D.4000604@net.in.tum.de> Date: Mon, 15 Feb 2010 13:18:37 +0100 From: Gerhard Muenz User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: "Romascanu, Dan (Dan)" References: <20100209175816.09FB.17391CF2@nttv6.net> In-Reply-To: Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms070403060509020703000107" X-Virus-Scanned: ClamAV using ClamSMTP Cc: ipfix@ietf.org Subject: Re: [IPFIX] AD review of draft-ietf-ipfix-mediators-framework 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, 15 Feb 2010 12:14:36 -0000 This is a cryptographically signed message in MIME format. --------------ms070403060509020703000107 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable Hi Dan, Atsushi, I'm confused. Has there already been a WG LC for this document? Regards, Gerhard Romascanu, Dan (Dan) wrote: > Hi Atsushi, >=20 > Your proposed edits are fine. I am expecting for a revised version to b= e > published before sending the document to IETF Last Call.=20 >=20 > Thanks and Regards, >=20 > Dan=20 >=20 >> -----Original Message----- >> From: Atsushi Kobayashi [mailto:akoba@nttv6.net]=20 >> Sent: Tuesday, February 09, 2010 5:25 PM >> To: Romascanu, Dan (Dan) >> Cc: ipfix@ietf.org >> Subject: Re: [IPFIX] AD review of draft-ietf-ipfix-mediators-framework= >> >> >> Hi Dan, and all, >> >> Thank you for your comments. Sorry for my late reply. >> Please see in-line. >> >> On Tue, 2 Feb 2010 18:55:14 +0100 >> "Romascanu, Dan (Dan)" wrote: >> >>> Please find below the AD review of=20 >> draft-ietf-ipfix-mediators-framework. >>> The document is in pretty good shape, but I suggest that=20 >> the editors=20 >>> review my technical and editorial comments and address them before=20 >>> deciding whether to revise the I-D or send the document directly to=20 >>> IETF Last Call. >>> >>> Thanks and Regards, >>> >>> Dan >>> >>> >>> Technical:=20 >>> >>> T1. I do not see the Data Retention use case mentioned in=20 >>> draft-ietf-mediators-problem-statement addressed in any way in this=20 >>> draft. Did I miss anything? >>> >> Problem statement draft raised the following requirements=20 >> about data retentions. >> >> - Reliable exporting >> In this case, an IPFIX Mediator beside an Original Exporter=20 >> can enhance the export reliability by converting from UDP to=20 >> SCP. This has relevance to section 5.3.2.1. "Intermediate=20 >> Conversion Process". >> >> - Huge storage for data records >> In this case, an IPFIX Mediator re-exports data records=20 >> stored to a Collector on demand. This has relevance to=20 >> section 6.3. "IPFIX File Writer/Reader". >> >> I will improve the section 5.3.2.1. and section 6.3 as follows. >> >> 5.3.2.1. Intermediate Conversion Process >> >> [snip] >> >> [Old] >> In the case of IPFIX transport protocol conversion, the=20 >> Intermediate Conversion Process covers the following functions. >> >> [New] >> In the case of IPFIX transport protocol conversion to enhance=20 >> the export reliability, commonly used in data retention and=20 >> accounting, the Intermediate Conversion Process covers the=20 >> following functions. >> >> 6.3. IPFIX File Writer/Reader >> >> [snip] >> >> .-------------. .---------------. .---------------. =20 >> .-----------. >> | IPFIX | | Intermediate | | Intermediate | |=20 >> Exporting | >> | File | | Anonymization | | Correlation | | =20 >> Process | >> | Reader +->| Process +->| Process +->| =20 >> | >> '-------------' '---------------' '---------------' =20 >> '-----------' >> >> Figure J: IPFIX Mediation Example with IPFIX File Reader. >> >> [New] >> When distributed IPFIX Mediators export Data Records stored=20 >> on demand as like figure, it allows us to build the=20 >> collecting infrastructure with huge storage for data retention. >> >> >>> T2. In Section 5.3:=20 >>> >>> Maintaining additional information about output record streams, >>> which includes information related to Original=20 >> Exporter, and some >>> configuration parameters related to each function. >>> >>> I think here we need to add the observation domain and the admin=20 >>> domain to the Original Exporter because of support for multiple=20 >>> exporters and correlation between domains >> I will replace it as follows. >> >> [New] >> Maintaining additional information about output record=20 >> streams, which includes information related to Original=20 >> Exporter, Observation Domain, and administrative domain and=20 >> some configuration parameters related to each function. >> >>> T3. In section 7 - I cannot figure out how the collector=20 >> knows what to=20 >>> fill in the Observation Domain ID when this is different from the=20 >>> incoming Observation Domain ID? Can you help by explaining how this=20 >>> works? >> Could you please see last sentense in section 7. But, it=20 >> seems sketchy. >> I will replace it as follows. >> >> >> [Old] >> In that case, the IPFIX Concentrator can add a new field to=20 >> the Flow Record instead of the Observation Domain ID. The=20 >> field indicates the largest set of Observation Points for an=20 >> aggregated Flow Record. >> >> [New] >> When an IPFIX Mediator needs to give the Observation Domain=20 >> ID value exported from an Original Exporter to Collector, an=20 >> IPFIX Mediator can insert this value as new fields into Flow=20 >> Record, or Data Records defined by Options Templates. In the=20 >> case of Flow Records aggregation in an IPFIX Mediator, this=20 >> new field indicates the largest set of Observation Points for=20 >> an aggregated Flow Record. >> >> I think this method will be described in detail in standard=20 >> mediation protocol document at next stage. >> >>> 4. Data retention needs to be added to the security=20 >> considerations -=20 >>> if relevant - related to T1 >> I put the feedback from problem statement draft, and will=20 >> enhance them. >> >>> >>> Editorial:=20 >>> >>> E1. running id-nits results in the following warnings:=20 >>> >>> >>> tmp/draft-ietf-ipfix-mediators-framework-04.txt: >>> tmp/draft-ietf-ipfix-mediators-framework-04.txt(405): Line has weird >>> spacing: '...ributor one ...' >>> tmp/draft-ietf-ipfix-mediators-framework-04.txt(407): Line has weird >>> spacing: '...ntrator one o...' >>> tmp/draft-ietf-ipfix-mediators-framework-04.txt(410): Line has weird >>> spacing: '...erading one o...' >>> tmp/draft-ietf-ipfix-mediators-framework-04.txt(530): Line has weird >>> spacing: '...Reports recor...' >>> tmp/draft-ietf-ipfix-mediators-framework-04.txt(547): Line has weird >>> spacing: '...rvation into ...' >>> >>> >>> Checking boilerplate required by RFC 5378 and the IETF Trust (see >>> http://trustee.ietf.org/license-info): >>> =20 >>> >> ----------------------------------------------------------------------= >>> -- >>> ---- >>> >>> ** The document seems to lack a License Notice according=20 >> IETF Trust >>> Provisions of 28 Dec 2009, Section 6.b.i or Provisions=20 >> of 12 Sep >>> 2009 >>> Section 6.b -- however, there's a paragraph with a matching=20 >>> beginning. >>> Boilerplate error? >>> >> This document was submitted in October, 2009. Thus, it could=20 >> not catch up with latest License Notice. I will take care in=20 >> next version. >> >> >>> IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i),=20 >>> paragraph 3: >>> "This document is subject to BCP 78 and the IETF Trust's Legal=20 >>> Provisions >>> Relating to IETF Documents=20 >> (http://trustee.ietf.org/license-info) >>> in effect on the date of publication of this document. Please >>> review these documents carefully, as they describe=20 >> your rights and >>> restrictions with respect to this document. Code Components >>> extracted from this document must include Simplified=20 >> BSD License >>> text as described in Section 4.e of the Trust Legal=20 >> Provisions and >>> are provided without warranty as described in the=20 >> Simplified BSD >>> License." =20 >>> >>> ... text found in draft: >>> "This document is subject to BCP 78 and the IETF Trust's Legal=20 >>> Provisions >>> Relating to IETF Documents in effect on the date of=20 >> publication=20 >>> of .................................^ >>> this document (http://trustee.ietf.org/license-info). Please=20 >>> review >>> these documents carefully, as they describe your rights and >>> restrictions with respect to this document." >>> >>> >>> (You're using the IETF Trust Provisions' Section 6.b License=20 >>> Notice from >>> 12 Feb 2009 rather than one of the newer Notices. See >>> http://trustee.ietf.org/license-info/.) >>> >>> E2. Section 1.=20 >>> >>> To acihive application requirements with limited system resources, >>> IPFIX architecture needs to introduce an intermediate=20 >> device between >>> Exporters and Collectors.=20 >>> >>> s/acihive/achieve/ >>> >>> Also 'device' has too much a hardware connotation, while mediators=20 >>> need not be necessarily hardware 'devices'. Probably=20 >> 'component' or 'entity' >>> is more appropriate.=20 >> Thank you.=20 >> >>> E3. Part of the definitions in section 2 duplicate definitions in=20 >>> draft-ietf-mediators-problem-statement. Better avoid the=20 >> duplication=20 >>> and just refer draft-ietf-mediators-problem-statement. >>> >>> E4. Section 7 - >>> >>> The IPFIX Message Header [RFC5101] includes Export Time, Sequence >>> Number, and Observation Domain ID fields. This section describes >>> some consideration points for the IPFIX Message Header encoding. >>> >>> Need to add 'in the context of IPFIX Mediation'. >>> >> Ok. >> >>> E5. Should not [IPFIX-MD-PS] be a Normative Reference?=20 >>> >> [IPFIX-MD-PS] describes the concept of mediation as=20 >> informative reference, does not describe the normative standard. >> Thus, I think it is a informative reference. >> >> Regards, >> Atsushi >> >>> _______________________________________________ >>> IPFIX mailing list >>> IPFIX@ietf.org >>> https://www.ietf.org/mailman/listinfo/ipfix >> --- >> Atsushi KOBAYASHI >> NTT Information Sharing Platform Lab. >> tel:+81-(0)422-59-3978 fax:+81-(0)422-59-5637 >> >> > _______________________________________________ > IPFIX mailing list > IPFIX@ietf.org > https://www.ietf.org/mailman/listinfo/ipfix --=20 Dipl.-Ing. Gerhard M=FCnz Chair for Network Architectures and Services (I8) Technische Universit=E4t M=FCnchen - Department of Informatics Boltzmannstr. 3, 85748 Garching bei M=FCnchen, Germany Phone: +49 89 289-18008 Fax: +49 89 289-18033 E-mail: muenz@net.in.tum.de WWW: http://www.net.in.tum.de/~muenz --------------ms070403060509020703000107 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 9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTEwMDIxNTEyMTgzN1owIwYJKoZIhvcNAQkEMRYEFCMH cGT6UWluLhmJWAljAlVN9iTPMF8GCSqGSIb3DQEJDzFSMFAwCwYJYIZIAWUDBAECMAoGCCqG SIb3DQMHMA4GCCqGSIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG 9w0DAgIBKDCCAQMGCSsGAQQBgjcQBDGB9TCB8jCB3TELMAkGA1UEBhMCVVMxFzAVBgNVBAoT DlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTswOQYD VQQLEzJUZXJtcyBvZiB1c2UgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYSAoYykw NTEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5WZXJpU2lnbiBD bGFzcyAxIEluZGl2aWR1YWwgU3Vic2NyaWJlciBDQSAtIEcyAhBdJGHZVTceRNanJsbp+SK7 MIIBBQYLKoZIhvcNAQkQAgsxgfWggfIwgd0xCzAJBgNVBAYTAlVTMRcwFQYDVQQKEw5WZXJp U2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazE7MDkGA1UECxMy VGVybXMgb2YgdXNlIGF0IGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9ycGEgKGMpMDUxHjAc BgNVBAsTFVBlcnNvbmEgTm90IFZhbGlkYXRlZDE3MDUGA1UEAxMuVmVyaVNpZ24gQ2xhc3Mg MSBJbmRpdmlkdWFsIFN1YnNjcmliZXIgQ0EgLSBHMgIQXSRh2VU3HkTWpybG6fkiuzANBgkq hkiG9w0BAQEFAASCAQBxV+j530c0BWW3hAzgzw/hbVsjWw8u74sDbIGB8F97QMdb7XJHL2Ts Tdu6OvBiR7qOp/2/EpWc2AAIG9p9j7a7NEBz7bvtsUwbYZv16F1/bVG4oEjpg2ePyBQAba7W 4iyn/PaEkkkY9ZFOa5qje8/fcKBASM+fFuv5vi/IoZy4dS30jLTGDzbuaxkMVV0IvkDrb3dt 4EYDnr4zufaSdAt62U8lrbnHpnICL/eYQgaM1KRPj6xdhdBw0dcxT99Z0z71fW/9STWMeDi3 i/F/bw5++TchGaUbvXb+CjDf/lFWnNi+hrmbip5ok47IPBl9wdxX/4p7OpNRRakWAhtpQ3kH AAAAAAAA --------------ms070403060509020703000107-- From dromasca@avaya.com Mon Feb 15 06:05: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 DD7ED28C133 for ; Mon, 15 Feb 2010 06:05:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.522 X-Spam-Level: X-Spam-Status: No, score=-2.522 tagged_above=-999 required=5 tests=[AWL=0.077, 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 OJ3TVq8NNUac for ; Mon, 15 Feb 2010 06:05:01 -0800 (PST) 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 0540428C177 for ; Mon, 15 Feb 2010 06:05:00 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.49,476,1262581200"; d="scan'208";a="176471019" Received: from unknown (HELO p-us1-erheast.us1.avaya.com) ([135.11.50.53]) by de307622-de-outbound.net.avaya.com with ESMTP; 15 Feb 2010 09:06:29 -0500 X-IronPort-AV: E=Sophos;i="4.49,476,1262581200"; d="scan'208";a="431712637" Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.11]) by p-us1-erheast-out.us1.avaya.com with ESMTP; 15 Feb 2010 09:05:48 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Mon, 15 Feb 2010 15:05:43 +0100 Message-ID: In-Reply-To: <4B793B9D.4000604@net.in.tum.de> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [IPFIX] AD review of draft-ietf-ipfix-mediators-framework Thread-Index: AcquOKMsWkt5tI0NSWS0N/xfyd/SpAADi6HA References: <20100209175816.09FB.17391CF2@nttv6.net> <4B793B9D.4000604@net.in.tum.de> From: "Romascanu, Dan (Dan)" To: "Gerhard Muenz" Cc: ipfix@ietf.org Subject: Re: [IPFIX] AD review of draft-ietf-ipfix-mediators-framework 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, 15 Feb 2010 14:05:04 -0000 Hmmmm ... This is a question for the chairs actually. The tracker says = it was submitted to the IESG on 1/19 together with = draft-ipfix-mediators-problem-statement, but maybe the track is wrong as = I cannot find a PROTO write-up for it - the one in the tracker is for = problem-statement. I am freezing this one until I get a clarification = from Juergen and Nevil. If you are correct I will wait for the WG to = complete the consensus process. No bad things happened, anyway - you = just got an early AD review :-)=20 Dan > -----Original Message----- > From: Gerhard Muenz [mailto:muenz@net.in.tum.de]=20 > Sent: Monday, February 15, 2010 2:19 PM > To: Romascanu, Dan (Dan) > Cc: Atsushi Kobayashi; ipfix@ietf.org > Subject: Re: [IPFIX] AD review of draft-ietf-ipfix-mediators-framework >=20 >=20 > Hi Dan, Atsushi, >=20 > I'm confused. Has there already been a WG LC for this document? >=20 > Regards, > Gerhard >=20 >=20 > Romascanu, Dan (Dan) wrote: > > Hi Atsushi, > >=20 > > Your proposed edits are fine. I am expecting for a revised=20 > version to=20 > > be published before sending the document to IETF Last Call. > >=20 > > Thanks and Regards, > >=20 > > Dan > >=20 > >> -----Original Message----- > >> From: Atsushi Kobayashi [mailto:akoba@nttv6.net] > >> Sent: Tuesday, February 09, 2010 5:25 PM > >> To: Romascanu, Dan (Dan) > >> Cc: ipfix@ietf.org > >> Subject: Re: [IPFIX] AD review of=20 > >> draft-ietf-ipfix-mediators-framework > >> > >> > >> Hi Dan, and all, > >> > >> Thank you for your comments. Sorry for my late reply. > >> Please see in-line. > >> > >> On Tue, 2 Feb 2010 18:55:14 +0100 > >> "Romascanu, Dan (Dan)" wrote: > >> > >>> Please find below the AD review of > >> draft-ietf-ipfix-mediators-framework. > >>> The document is in pretty good shape, but I suggest that > >> the editors > >>> review my technical and editorial comments and address=20 > them before=20 > >>> deciding whether to revise the I-D or send the document=20 > directly to=20 > >>> IETF Last Call. > >>> > >>> Thanks and Regards, > >>> > >>> Dan > >>> > >>> > >>> Technical:=20 > >>> > >>> T1. I do not see the Data Retention use case mentioned in=20 > >>> draft-ietf-mediators-problem-statement addressed in any=20 > way in this=20 > >>> draft. Did I miss anything? > >>> > >> Problem statement draft raised the following requirements=20 > about data=20 > >> retentions. > >> > >> - Reliable exporting > >> In this case, an IPFIX Mediator beside an Original Exporter can=20 > >> enhance the export reliability by converting from UDP to SCP. This=20 > >> has relevance to section 5.3.2.1. "Intermediate Conversion=20 > Process". > >> > >> - Huge storage for data records > >> In this case, an IPFIX Mediator re-exports data records=20 > stored to a=20 > >> Collector on demand. This has relevance to section 6.3.=20 > "IPFIX File=20 > >> Writer/Reader". > >> > >> I will improve the section 5.3.2.1. and section 6.3 as follows. > >> > >> 5.3.2.1. Intermediate Conversion Process > >> > >> [snip] > >> > >> [Old] > >> In the case of IPFIX transport protocol conversion, the=20 > Intermediate=20 > >> Conversion Process covers the following functions. > >> > >> [New] > >> In the case of IPFIX transport protocol conversion to enhance the=20 > >> export reliability, commonly used in data retention and=20 > accounting,=20 > >> the Intermediate Conversion Process covers the following functions. > >> > >> 6.3. IPFIX File Writer/Reader > >> > >> [snip] > >> > >> .-------------. .---------------. .---------------. =20 > >> .-----------. > >> | IPFIX | | Intermediate | | Intermediate | |=20 > >> Exporting | > >> | File | | Anonymization | | Correlation | | =20 > >> Process | > >> | Reader +->| Process +->| Process +->| =20 > >> | > >> '-------------' '---------------' '---------------' =20 > >> '-----------' > >> > >> Figure J: IPFIX Mediation Example with IPFIX File Reader. > >> > >> [New] > >> When distributed IPFIX Mediators export Data Records=20 > stored on demand=20 > >> as like figure, it allows us to build the collecting=20 > infrastructure=20 > >> with huge storage for data retention. > >> > >> > >>> T2. In Section 5.3:=20 > >>> > >>> Maintaining additional information about output record streams, > >>> which includes information related to Original > >> Exporter, and some > >>> configuration parameters related to each function. > >>> > >>> I think here we need to add the observation domain and the admin=20 > >>> domain to the Original Exporter because of support for multiple=20 > >>> exporters and correlation between domains > >> I will replace it as follows. > >> > >> [New] > >> Maintaining additional information about output record=20 > streams, which=20 > >> includes information related to Original Exporter, Observation=20 > >> Domain, and administrative domain and some configuration=20 > parameters=20 > >> related to each function. > >> > >>> T3. In section 7 - I cannot figure out how the collector > >> knows what to > >>> fill in the Observation Domain ID when this is different from the=20 > >>> incoming Observation Domain ID? Can you help by=20 > explaining how this=20 > >>> works? > >> Could you please see last sentense in section 7. But, it seems=20 > >> sketchy. > >> I will replace it as follows. > >> > >> > >> [Old] > >> In that case, the IPFIX Concentrator can add a new field=20 > to the Flow=20 > >> Record instead of the Observation Domain ID. The field=20 > indicates the=20 > >> largest set of Observation Points for an aggregated Flow Record. > >> > >> [New] > >> When an IPFIX Mediator needs to give the Observation=20 > Domain ID value=20 > >> exported from an Original Exporter to Collector, an IPFIX Mediator=20 > >> can insert this value as new fields into Flow Record, or=20 > Data Records=20 > >> defined by Options Templates. In the case of Flow Records=20 > >> aggregation in an IPFIX Mediator, this new field indicates the=20 > >> largest set of Observation Points for an aggregated Flow Record. > >> > >> I think this method will be described in detail in=20 > standard mediation=20 > >> protocol document at next stage. > >> > >>> 4. Data retention needs to be added to the security > >> considerations - > >>> if relevant - related to T1 > >> I put the feedback from problem statement draft, and will enhance=20 > >> them. > >> > >>> > >>> Editorial:=20 > >>> > >>> E1. running id-nits results in the following warnings:=20 > >>> > >>> > >>> tmp/draft-ietf-ipfix-mediators-framework-04.txt: > >>> tmp/draft-ietf-ipfix-mediators-framework-04.txt(405):=20 > Line has weird > >>> spacing: '...ributor one ...' > >>> tmp/draft-ietf-ipfix-mediators-framework-04.txt(407):=20 > Line has weird > >>> spacing: '...ntrator one o...' > >>> tmp/draft-ietf-ipfix-mediators-framework-04.txt(410):=20 > Line has weird > >>> spacing: '...erading one o...' > >>> tmp/draft-ietf-ipfix-mediators-framework-04.txt(530):=20 > Line has weird > >>> spacing: '...Reports recor...' > >>> tmp/draft-ietf-ipfix-mediators-framework-04.txt(547):=20 > Line has weird > >>> spacing: '...rvation into ...' > >>> > >>> > >>> Checking boilerplate required by RFC 5378 and the IETF=20 > Trust (see > >>> http://trustee.ietf.org/license-info): > >>> =20 > >>> > >>=20 > --------------------------------------------------------------------- > >> - > >>> -- > >>> ---- > >>> > >>> ** The document seems to lack a License Notice according > >> IETF Trust > >>> Provisions of 28 Dec 2009, Section 6.b.i or Provisions > >> of 12 Sep > >>> 2009 > >>> Section 6.b -- however, there's a paragraph with a matching=20 > >>> beginning. > >>> Boilerplate error? > >>> > >> This document was submitted in October, 2009. Thus, it could not=20 > >> catch up with latest License Notice. I will take care in next=20 > >> version. > >> > >> > >>> IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i),=20 > >>> paragraph 3: > >>> "This document is subject to BCP 78 and the IETF=20 > Trust's Legal=20 > >>> Provisions > >>> Relating to IETF Documents > >> (http://trustee.ietf.org/license-info) > >>> in effect on the date of publication of this=20 > document. Please > >>> review these documents carefully, as they describe > >> your rights and > >>> restrictions with respect to this document. Code Components > >>> extracted from this document must include Simplified > >> BSD License > >>> text as described in Section 4.e of the Trust Legal > >> Provisions and > >>> are provided without warranty as described in the > >> Simplified BSD > >>> License." =20 > >>> > >>> ... text found in draft: > >>> "This document is subject to BCP 78 and the IETF=20 > Trust's Legal=20 > >>> Provisions > >>> Relating to IETF Documents in effect on the date of > >> publication > >>> of .................................^ > >>> this document=20 > (http://trustee.ietf.org/license-info). Please=20 > >>> review > >>> these documents carefully, as they describe your rights and > >>> restrictions with respect to this document." > >>> > >>> > >>> (You're using the IETF Trust Provisions' Section 6.b License=20 > >>> Notice from > >>> 12 Feb 2009 rather than one of the newer Notices. See > >>> http://trustee.ietf.org/license-info/.) > >>> > >>> E2. Section 1.=20 > >>> > >>> To acihive application requirements with limited system resources, > >>> IPFIX architecture needs to introduce an intermediate > >> device between > >>> Exporters and Collectors.=20 > >>> > >>> s/acihive/achieve/ > >>> > >>> Also 'device' has too much a hardware connotation, while=20 > mediators=20 > >>> need not be necessarily hardware 'devices'. Probably > >> 'component' or 'entity' > >>> is more appropriate.=20 > >> Thank you.=20 > >> > >>> E3. Part of the definitions in section 2 duplicate definitions in=20 > >>> draft-ietf-mediators-problem-statement. Better avoid the > >> duplication > >>> and just refer draft-ietf-mediators-problem-statement. > >>> > >>> E4. Section 7 - > >>> > >>> The IPFIX Message Header [RFC5101] includes Export Time, Sequence > >>> Number, and Observation Domain ID fields. This=20 > section describes > >>> some consideration points for the IPFIX Message Header=20 > encoding. > >>> > >>> Need to add 'in the context of IPFIX Mediation'. > >>> > >> Ok. > >> > >>> E5. Should not [IPFIX-MD-PS] be a Normative Reference?=20 > >>> > >> [IPFIX-MD-PS] describes the concept of mediation as informative=20 > >> reference, does not describe the normative standard. > >> Thus, I think it is a informative reference. > >> > >> Regards, > >> Atsushi > >> > >>> _______________________________________________ > >>> IPFIX mailing list > >>> IPFIX@ietf.org > >>> https://www.ietf.org/mailman/listinfo/ipfix > >> --- > >> Atsushi KOBAYASHI > >> NTT Information Sharing Platform Lab. > >> tel:+81-(0)422-59-3978 fax:+81-(0)422-59-5637 > >> > >> > > _______________________________________________ > > IPFIX mailing list > > IPFIX@ietf.org > > https://www.ietf.org/mailman/listinfo/ipfix >=20 > -- > Dipl.-Ing. Gerhard M=FCnz > Chair for Network Architectures and Services (I8) Technische=20 > Universit=E4t M=FCnchen - Department of Informatics Boltzmannstr.=20 > 3, 85748 Garching bei M=FCnchen, Germany > Phone: +49 89 289-18008 Fax: +49 89 289-18033 > E-mail: muenz@net.in.tum.de WWW: http://www.net.in.tum.de/~muenz >=20 >=20 >=20 From akoba@nttv6.net Mon Feb 15 08:16: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 CC05828C0F6 for ; Mon, 15 Feb 2010 08:16:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.428 X-Spam-Level: X-Spam-Status: No, score=-0.428 tagged_above=-999 required=5 tests=[AWL=-1.039, BAYES_00=-2.599, HOST_MISMATCH_COM=0.311, RDNS_DYNAMIC=0.1, 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 UVPPa8+xxEgw for ; Mon, 15 Feb 2010 08:15:47 -0800 (PST) Received: from mail.nttv6.net (mail.nttv6.net [IPv6:2001:fa8::25]) by core3.amsl.com (Postfix) with ESMTP id C3EFB3A7B69 for ; Mon, 15 Feb 2010 08:15:45 -0800 (PST) Received: from [127.0.0.1] (dhcp-3-152.nttv6.com [192.47.163.152]) by mail.nttv6.net (8.14.3/8.14.3) with ESMTP id o1FGHBCm040292; Tue, 16 Feb 2010 01:17:12 +0900 (JST) (envelope-from akoba@nttv6.net) Date: Tue, 16 Feb 2010 01:13:01 +0900 From: Atsushi Kobayashi To: "Romascanu, Dan (Dan)" In-Reply-To: References: <4B793B9D.4000604@net.in.tum.de> Message-Id: <20100216010914.3F33.17391CF2@nttv6.net> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Becky! ver. 2.50.05 [ja] (Unregistered) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.3 (mail.nttv6.net [192.16.178.5]); Tue, 16 Feb 2010 01:17:12 +0900 (JST) Cc: ipfix@ietf.org Subject: Re: [IPFIX] AD review of draft-ietf-ipfix-mediators-framework 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, 15 Feb 2010 16:16:04 -0000 Hi Dan, Gerhard, I am also asking chairs what happened to this document. It seems mistake. All I can say is that Dan review is worthwhile at even this phase. Thank you. Regards, Atsushi On Mon, 15 Feb 2010 15:05:43 +0100 "Romascanu, Dan (Dan)" wrote: > Hmmmm ... This is a question for the chairs actually. The tracker says it was submitted to the IESG on 1/19 together with draft-ipfix-mediators-problem-statement, but maybe the track is wrong as I cannot find a PROTO write-up for it - the one in the tracker is for problem-statement. I am freezing this one until I get a clarification from Juergen and Nevil. If you are correct I will wait for the WG to complete the consensus process. No bad things happened, anyway - you just got an early AD review :-) > > Dan > > > > -----Original Message----- > > From: Gerhard Muenz [mailto:muenz@net.in.tum.de] > > Sent: Monday, February 15, 2010 2:19 PM > > To: Romascanu, Dan (Dan) > > Cc: Atsushi Kobayashi; ipfix@ietf.org > > Subject: Re: [IPFIX] AD review of draft-ietf-ipfix-mediators-framework > > > > > > Hi Dan, Atsushi, > > > > I'm confused. Has there already been a WG LC for this document? > > > > Regards, > > Gerhard > > > > > > Romascanu, Dan (Dan) wrote: > > > Hi Atsushi, > > > > > > Your proposed edits are fine. I am expecting for a revised > > version to > > > be published before sending the document to IETF Last Call. > > > > > > Thanks and Regards, > > > > > > Dan > > > > > >> -----Original Message----- > > >> From: Atsushi Kobayashi [mailto:akoba@nttv6.net] > > >> Sent: Tuesday, February 09, 2010 5:25 PM > > >> To: Romascanu, Dan (Dan) > > >> Cc: ipfix@ietf.org > > >> Subject: Re: [IPFIX] AD review of > > >> draft-ietf-ipfix-mediators-framework > > >> > > >> > > >> Hi Dan, and all, > > >> > > >> Thank you for your comments. Sorry for my late reply. > > >> Please see in-line. > > >> > > >> On Tue, 2 Feb 2010 18:55:14 +0100 > > >> "Romascanu, Dan (Dan)" wrote: > > >> > > >>> Please find below the AD review of > > >> draft-ietf-ipfix-mediators-framework. > > >>> The document is in pretty good shape, but I suggest that > > >> the editors > > >>> review my technical and editorial comments and address > > them before > > >>> deciding whether to revise the I-D or send the document > > directly to > > >>> IETF Last Call. > > >>> > > >>> Thanks and Regards, > > >>> > > >>> Dan > > >>> > > >>> > > >>> Technical: > > >>> > > >>> T1. I do not see the Data Retention use case mentioned in > > >>> draft-ietf-mediators-problem-statement addressed in any > > way in this > > >>> draft. Did I miss anything? > > >>> > > >> Problem statement draft raised the following requirements > > about data > > >> retentions. > > >> > > >> - Reliable exporting > > >> In this case, an IPFIX Mediator beside an Original Exporter can > > >> enhance the export reliability by converting from UDP to SCP. This > > >> has relevance to section 5.3.2.1. "Intermediate Conversion > > Process". > > >> > > >> - Huge storage for data records > > >> In this case, an IPFIX Mediator re-exports data records > > stored to a > > >> Collector on demand. This has relevance to section 6.3. > > "IPFIX File > > >> Writer/Reader". > > >> > > >> I will improve the section 5.3.2.1. and section 6.3 as follows. > > >> > > >> 5.3.2.1. Intermediate Conversion Process > > >> > > >> [snip] > > >> > > >> [Old] > > >> In the case of IPFIX transport protocol conversion, the > > Intermediate > > >> Conversion Process covers the following functions. > > >> > > >> [New] > > >> In the case of IPFIX transport protocol conversion to enhance the > > >> export reliability, commonly used in data retention and > > accounting, > > >> the Intermediate Conversion Process covers the following functions. > > >> > > >> 6.3. IPFIX File Writer/Reader > > >> > > >> [snip] > > >> > > >> .-------------. .---------------. .---------------. > > >> .-----------. > > >> | IPFIX | | Intermediate | | Intermediate | | > > >> Exporting | > > >> | File | | Anonymization | | Correlation | | > > >> Process | > > >> | Reader +->| Process +->| Process +->| > > >> | > > >> '-------------' '---------------' '---------------' > > >> '-----------' > > >> > > >> Figure J: IPFIX Mediation Example with IPFIX File Reader. > > >> > > >> [New] > > >> When distributed IPFIX Mediators export Data Records > > stored on demand > > >> as like figure, it allows us to build the collecting > > infrastructure > > >> with huge storage for data retention. > > >> > > >> > > >>> T2. In Section 5.3: > > >>> > > >>> Maintaining additional information about output record streams, > > >>> which includes information related to Original > > >> Exporter, and some > > >>> configuration parameters related to each function. > > >>> > > >>> I think here we need to add the observation domain and the admin > > >>> domain to the Original Exporter because of support for multiple > > >>> exporters and correlation between domains > > >> I will replace it as follows. > > >> > > >> [New] > > >> Maintaining additional information about output record > > streams, which > > >> includes information related to Original Exporter, Observation > > >> Domain, and administrative domain and some configuration > > parameters > > >> related to each function. > > >> > > >>> T3. In section 7 - I cannot figure out how the collector > > >> knows what to > > >>> fill in the Observation Domain ID when this is different from the > > >>> incoming Observation Domain ID? Can you help by > > explaining how this > > >>> works? > > >> Could you please see last sentense in section 7. But, it seems > > >> sketchy. > > >> I will replace it as follows. > > >> > > >> > > >> [Old] > > >> In that case, the IPFIX Concentrator can add a new field > > to the Flow > > >> Record instead of the Observation Domain ID. The field > > indicates the > > >> largest set of Observation Points for an aggregated Flow Record. > > >> > > >> [New] > > >> When an IPFIX Mediator needs to give the Observation > > Domain ID value > > >> exported from an Original Exporter to Collector, an IPFIX Mediator > > >> can insert this value as new fields into Flow Record, or > > Data Records > > >> defined by Options Templates. In the case of Flow Records > > >> aggregation in an IPFIX Mediator, this new field indicates the > > >> largest set of Observation Points for an aggregated Flow Record. > > >> > > >> I think this method will be described in detail in > > standard mediation > > >> protocol document at next stage. > > >> > > >>> 4. Data retention needs to be added to the security > > >> considerations - > > >>> if relevant - related to T1 > > >> I put the feedback from problem statement draft, and will enhance > > >> them. > > >> > > >>> > > >>> Editorial: > > >>> > > >>> E1. running id-nits results in the following warnings: > > >>> > > >>> > > >>> tmp/draft-ietf-ipfix-mediators-framework-04.txt: > > >>> tmp/draft-ietf-ipfix-mediators-framework-04.txt(405): > > Line has weird > > >>> spacing: '...ributor one ...' > > >>> tmp/draft-ietf-ipfix-mediators-framework-04.txt(407): > > Line has weird > > >>> spacing: '...ntrator one o...' > > >>> tmp/draft-ietf-ipfix-mediators-framework-04.txt(410): > > Line has weird > > >>> spacing: '...erading one o...' > > >>> tmp/draft-ietf-ipfix-mediators-framework-04.txt(530): > > Line has weird > > >>> spacing: '...Reports recor...' > > >>> tmp/draft-ietf-ipfix-mediators-framework-04.txt(547): > > Line has weird > > >>> spacing: '...rvation into ...' > > >>> > > >>> > > >>> Checking boilerplate required by RFC 5378 and the IETF > > Trust (see > > >>> http://trustee.ietf.org/license-info): > > >>> > > >>> > > >> > > --------------------------------------------------------------------- > > >> - > > >>> -- > > >>> ---- > > >>> > > >>> ** The document seems to lack a License Notice according > > >> IETF Trust > > >>> Provisions of 28 Dec 2009, Section 6.b.i or Provisions > > >> of 12 Sep > > >>> 2009 > > >>> Section 6.b -- however, there's a paragraph with a matching > > >>> beginning. > > >>> Boilerplate error? > > >>> > > >> This document was submitted in October, 2009. Thus, it could not > > >> catch up with latest License Notice. I will take care in next > > >> version. > > >> > > >> > > >>> IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), > > >>> paragraph 3: > > >>> "This document is subject to BCP 78 and the IETF > > Trust's Legal > > >>> Provisions > > >>> Relating to IETF Documents > > >> (http://trustee.ietf.org/license-info) > > >>> in effect on the date of publication of this > > document. Please > > >>> review these documents carefully, as they describe > > >> your rights and > > >>> restrictions with respect to this document. Code Components > > >>> extracted from this document must include Simplified > > >> BSD License > > >>> text as described in Section 4.e of the Trust Legal > > >> Provisions and > > >>> are provided without warranty as described in the > > >> Simplified BSD > > >>> License." > > >>> > > >>> ... text found in draft: > > >>> "This document is subject to BCP 78 and the IETF > > Trust's Legal > > >>> Provisions > > >>> Relating to IETF Documents in effect on the date of > > >> publication > > >>> of .................................^ > > >>> this document > > (http://trustee.ietf.org/license-info). Please > > >>> review > > >>> these documents carefully, as they describe your rights and > > >>> restrictions with respect to this document." > > >>> > > >>> > > >>> (You're using the IETF Trust Provisions' Section 6.b License > > >>> Notice from > > >>> 12 Feb 2009 rather than one of the newer Notices. See > > >>> http://trustee.ietf.org/license-info/.) > > >>> > > >>> E2. Section 1. > > >>> > > >>> To acihive application requirements with limited system resources, > > >>> IPFIX architecture needs to introduce an intermediate > > >> device between > > >>> Exporters and Collectors. > > >>> > > >>> s/acihive/achieve/ > > >>> > > >>> Also 'device' has too much a hardware connotation, while > > mediators > > >>> need not be necessarily hardware 'devices'. Probably > > >> 'component' or 'entity' > > >>> is more appropriate. > > >> Thank you. > > >> > > >>> E3. Part of the definitions in section 2 duplicate definitions in > > >>> draft-ietf-mediators-problem-statement. Better avoid the > > >> duplication > > >>> and just refer draft-ietf-mediators-problem-statement. > > >>> > > >>> E4. Section 7 - > > >>> > > >>> The IPFIX Message Header [RFC5101] includes Export Time, Sequence > > >>> Number, and Observation Domain ID fields. This > > section describes > > >>> some consideration points for the IPFIX Message Header > > encoding. > > >>> > > >>> Need to add 'in the context of IPFIX Mediation'. > > >>> > > >> Ok. > > >> > > >>> E5. Should not [IPFIX-MD-PS] be a Normative Reference? > > >>> > > >> [IPFIX-MD-PS] describes the concept of mediation as informative > > >> reference, does not describe the normative standard. > > >> Thus, I think it is a informative reference. > > >> > > >> Regards, > > >> Atsushi > > >> > > >>> _______________________________________________ > > >>> IPFIX mailing list > > >>> IPFIX@ietf.org > > >>> https://www.ietf.org/mailman/listinfo/ipfix > > >> --- > > >> Atsushi KOBAYASHI > > >> NTT Information Sharing Platform Lab. > > >> tel:+81-(0)422-59-3978 fax:+81-(0)422-59-5637 > > >> > > >> > > > _______________________________________________ > > > IPFIX mailing list > > > IPFIX@ietf.org > > > https://www.ietf.org/mailman/listinfo/ipfix > > From akoba@nttv6.net Mon Feb 15 09:46:26 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 4633A3A7BB3 for ; Mon, 15 Feb 2010 09:46:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.168 X-Spam-Level: X-Spam-Status: No, score=-0.168 tagged_above=-999 required=5 tests=[AWL=-0.779, BAYES_00=-2.599, HOST_MISMATCH_COM=0.311, RDNS_DYNAMIC=0.1, 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 nXUbim+XDUdS for ; Mon, 15 Feb 2010 09:46:24 -0800 (PST) Received: from mail.nttv6.net (mail.nttv6.net [IPv6:2001:fa8::25]) by core3.amsl.com (Postfix) with ESMTP id AFD783A7BB2 for ; Mon, 15 Feb 2010 09:46:23 -0800 (PST) Received: from [127.0.0.1] (dhcp-3-152.nttv6.com [192.47.163.152]) by mail.nttv6.net (8.14.3/8.14.3) with ESMTP id o1FHloPs040737; Tue, 16 Feb 2010 02:47:50 +0900 (JST) (envelope-from akoba@nttv6.net) Date: Tue, 16 Feb 2010 02:43:39 +0900 From: Atsushi Kobayashi To: "Romascanu, Dan (Dan)" In-Reply-To: References: <20100208163453.F021.17391CF2@nttv6.net> Message-Id: <20100216012754.3F36.17391CF2@nttv6.net> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Becky! ver. 2.50.05 [ja] (Unregistered) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.3 (mail.nttv6.net [192.16.178.5]); Tue, 16 Feb 2010 02:47:50 +0900 (JST) Cc: ipfix@ietf.org Subject: Re: [IPFIX] AD review of draft-ietf-ipfix-mediators-problem-statement 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, 15 Feb 2010 17:46:26 -0000 Hi Dan, and all, Thank you for your replay. Please see in-line. On Mon, 15 Feb 2010 13:07:13 +0100 "Romascanu, Dan (Dan)" wrote: > Hi Atsushi, > > Please see in-line. > > I am expecting for a revised version to be published before sending the > document to IETF Last Call. > I will prepare next version. > Thanks and Regards, > > Dan > > > > -----Original Message----- > > From: Atsushi Kobayashi [mailto:akoba@nttv6.net] > > Sent: Monday, February 08, 2010 6:06 PM > > To: Romascanu, Dan (Dan) > > Cc: ipfix@ietf.org > > Subject: Re: [IPFIX] AD review of > > draft-ietf-ipfix-mediators-problem-statement > > > > > > Hi Dan, and all, > > > > Thank you for your comments. Sorry for my late reply. > > Please see in-line. > > > > On Tue, 2 Feb 2010 18:29:06 +0100 > > "Romascanu, Dan (Dan)" wrote: > > > > > Please find below the AD review of > > > draft-ietf-ipfix-mediators-problem-statement. The document is in > > > pretty good shape, but I suggest that the editors review my > > technical > > > and editorial comments and address them before deciding whether to > > > revise the I-D or send the document directly to IETF Last Call. > > > > > > Dan > > > > > > > > > Technical > > > T1. Section 5.3: > > > > > > One way delay from the correlation of PSAMP Packet > > Reports from > > > different Exporters along a specific path. > > > > > > I have two issues that are not clear to me at this point: > > > - why is only the correlation delay between PSAMP packet > > reports taken > > > into consideration and not between other type of packets as well? > > > > For example, it can utilize the PSAMP Hash-Based filtering in section > > 6.2.1.2 in RFC5475. PSAMP Packet Reports, including the > > packet digest and the arrival time of the packet at the > > Observation Point, are reported to IPFIX Mediation, and then > > it calculates one way delay after identifying same digest > > from different Exporters. > > Yes, but you did not answer my question. Why only this type of packets > (PSAMP packet reports) and not other type of IPFIX packets can be used > to measure one way delay correlation? > Sorry, I would like to clarify your question. This section covers the one way delay associated with observed packets in PSAMP Exporter. I do not mean one way delay for IPFIX packets, PSAMP packets. Or do you mean all of relevant functions should be put in? For example, one way delay for IPTV stream, an IPFIX Exporter filters specified IPTV session by using property match filtering, and then a Collector calculates one way delay without hash digest. But, this example uses PSAMP packet reports as well. Besides it, it is apparently difficult to get one way delay from general Flow Record. At this stage, I can not come up with another idea. > > > > > - where does this correlation happen - at the destination point at > > > collectors ingress? > > > > I means the Observation Point along with Exporter path. > > > > I would like to replace it. > > > > One way delay from the correlation of PSAMP Packet Reports > > from different Exporters along a specific path. For example, > > one way delay is calculated from correlation of two PSAMP > > Packet Reports including the packet digest and the arrival > > time at Observation Point. This cases are described in > > section 6.2.1.2 in RFC5475. > > > > OK, but please address the question above. > > > > > > > T2. Section 5.5 cases 1 - what type of link aggregation are > > we talking > > > about here? Layer 2 like in IEEE 802.3ad / IEEE 802.1AX? How is an > > > IPFIX collector aware at all about which physical link in the trunk > > > does a data record travel through or why would it matter - > > this should > > > be completely transparent starting with the second half of > > layer two > > > actually. Maybe I mis-understand? > > > > > > > I just mean IEEE 802.3ad. > > > > Please clarify this and add IEEE 802.3ad as Informative Reference. > > > Operators commonly want to measure traffic data for trunk > > link, whether their observation points are trunk interface or > > not. In this case, IPFIX Collector needs to measure traffic > > volume per trunk link by aggregating data records observed at > > physical interface which is combined in same trunk link. > > > > I think that IPFIX mediator can export the traffic data per > > trunk link after aggregating data record including the > > traffic data per physical link. > > > > Current description seems sketchy explanation. I would like > > to replace it. > > > > o Cases 1: Spatial Composition within one Observation Domain > > > > For example, to measure the traffic for a single logical > > interface in the case where link aggregation exists, Data > > Records metered at physical interfaces belonging to the same > > trunk can be merged. > > > OK > I will add it as Informative Reference. o Cases 1: Spatial Composition within one Observation Domain For example, to measure the traffic for a single logical interface in the case where link aggregation [IEEE802.3ad] exists, Data Records metered at physical interfaces belonging to the same trunk can be merged. > > > > > T3. Section 5.5, Cases 3 and 4 - How are data records > > originating from > > > different exporters in the same admin domain different areas, or > > > different admin domain synchronized in order to be > > correlated? Is an > > > unique collector assumed, or some synchronization process between > > > collectors? (if this is just a requirement and the answer > > is in some > > > other place please point me to it). > > > > > > > Traffic data per some area within a same admin domain comes > > from aggregation of data records based on info related to > > observation points. For example, an unique Collector knows > > where each Explorter exists, such as west or east, and then > > it works out traffic data per area based on Exporter IP address. > > > > In the same way, Traffic data per customer beyond admin > > domain comes from aggregation of data records. In this case, > > an unique Collector knows the customer in which each Explorter exists. > > > > I assume IPFIX mediators execute it instead for an unique > > Collector to reduce the load of Collector. It is just requirement. > > > > These aggregation method is described in section 5.3.2.3 in > > framework draft. > > It would be good to mention that unique collectors are assumed. > Otherwise people may try to implement the functions on multiple > collector which would imply usage of expensive time synchronization > processes. > I will replace it as follows. o Cases 4: Spatial Composition across administrative domains Data Records metered across administrative domains, such as across different customer networks or different ISP networks, can be merged. For example, an unique Collector knows in which customer network an Explorter exists, and then works out the traffic data per customer based on the Explorter IP address. > > > > > T4. Section 5.7 - why are (traditional) fixed telephony and mobile > > > telephony mentioned here? > > > > > > > As far as I know, originally data retention comes from > > requirement of traditional service. I means the starting > > point for data retension is traditional service to explain it. > > > > This explanation is not clear to me. In order for IPFIX to carry > traditional telephony traffic information this information needs to be > translated into IP traffic using some kind of gateway. After that it > does not differ to regular VoIP traffic originated by the gateway. So > how are these cases different from VoIP? > Hmm, they are not much different than traditional. So, I will improve it more concisely. [Old] Data retention services examples are the following: o Fixed telephony (includes fixed voice calls, voicemail, and conference and data calls) o Mobile telephony (includes mobile voice calls, voicemail, conference and data calls, SMS, and MMS) o Internet telephony (includes every multimedia session associated with IP multimedia services) o Internet e-mail o Internet access Data retention for Internet access services in particular requires a measurement system with reliable export and huge storage as the data must be available for a long period of time, typically at least six months. [New] Data retention examples relevant to IP networks are the following: o Internet telephony (includes every multimedia session associated with IP multimedia services, such as VoIP, IPTV) o Internet e-mail o Internet access Data retention for these services in particular has been required a measurement system with reliable export and huge storage as the data must be available for a long period of time, typically at least six months. > > > T5. I think that the protection of privacy and integrity of data > > > stores should be added to the additional threats and > > vulnerabilities > > > introduced by mediators taking onto account that Data Retention is > > > listed in 5.7 as one of the applicability examples. > > > > > > > Yes. I would add the following paragraph in Security > > Consideration section. > > > > o Confidentiality protection and data integrity via IPFIX Mediation > > > > To ensure integrity and confidentiality of Data Records, its > > transport for Data Records should use Transport Layer > > Security (TLS) or Datagram Transport Layer Security (DTLS). > > However, an IPFIX Collector cannot know whether received Data > > Records are transported as encrypted data between an Original > > Exporter and an IPFIX Mediator. And an IPFIX Collector can > > also not certificate an Original Exporter directly. Some > > method would be required to make up for this deficiency. > > > > OK. > Regards, Atsushi --- Atsushi KOBAYASHI NTT Information Sharing Platform Lab. tel:+81-(0)422-59-3978 fax:+81-(0)422-59-5637 From dromasca@avaya.com Mon Feb 15 09:56: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 E2E3628C1F0 for ; Mon, 15 Feb 2010 09:56:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.523 X-Spam-Level: X-Spam-Status: No, score=-2.523 tagged_above=-999 required=5 tests=[AWL=0.076, 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 mRLa87lIAOpU for ; Mon, 15 Feb 2010 09:56:46 -0800 (PST) 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 ACE6428C200 for ; Mon, 15 Feb 2010 09:56:46 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.49,478,1262581200"; d="scan'208";a="205133320" Received: from unknown (HELO co300216-co-erhwest.avaya.com) ([198.152.7.5]) by co300216-co-outbound.net.avaya.com with ESMTP; 15 Feb 2010 12:58:17 -0500 X-IronPort-AV: E=Sophos;i="4.49,478,1262581200"; d="scan'208";a="445969742" Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.11]) by co300216-co-erhwest-out.avaya.com with ESMTP; 15 Feb 2010 12:58:16 -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, 15 Feb 2010 18:57:59 +0100 Message-ID: In-Reply-To: <20100216012754.3F36.17391CF2@nttv6.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Re[2]: [IPFIX] AD review of draft-ietf-ipfix-mediators-problem-statement Thread-Index: AcquZwDWI4m1+jk5TGKrmlJmm8t+SAAAJjKA References: <20100208163453.F021.17391CF2@nttv6.net> <20100216012754.3F36.17391CF2@nttv6.net> From: "Romascanu, Dan (Dan)" To: "Atsushi Kobayashi" Cc: ipfix@ietf.org Subject: Re: [IPFIX] AD review of draft-ietf-ipfix-mediators-problem-statement 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, 15 Feb 2010 17:56:48 -0000 I deleted much of the stuff we agreed about.=20 Thanks and Regards, Dan =20 > -----Original Message----- > From: Atsushi Kobayashi [mailto:akoba@nttv6.net]=20 > Sent: Monday, February 15, 2010 7:44 PM > To: Romascanu, Dan (Dan) > Cc: ipfix@ietf.org > Subject: Re[2]: [IPFIX] AD review of=20 > draft-ietf-ipfix-mediators-problem-statement >=20 >=20 ... > > > > T1. Section 5.3:=20 > > > >=20 > > > > One way delay from the correlation of PSAMP Packet > > > Reports from > > > > different Exporters along a specific path. > > > >=20 > > > > I have two issues that are not clear to me at this point: > > > > - why is only the correlation delay between PSAMP packet > > > reports taken > > > > into consideration and not between other type of=20 > packets as well? > > >=20 > > > For example, it can utilize the PSAMP Hash-Based filtering in=20 > > > section > > > 6.2.1.2 in RFC5475. PSAMP Packet Reports, including the packet=20 > > > digest and the arrival time of the packet at the=20 > Observation Point,=20 > > > are reported to IPFIX Mediation, and then it calculates one way=20 > > > delay after identifying same digest from different Exporters. > >=20 > > Yes, but you did not answer my question. Why only this type=20 > of packets=20 > > (PSAMP packet reports) and not other type of IPFIX packets=20 > can be used=20 > > to measure one way delay correlation? > >=20 >=20 > Sorry, I would like to clarify your question.=20 > This section covers the one way delay associated with=20 > observed packets in PSAMP Exporter. I do not mean one way=20 > delay for IPFIX packets, PSAMP packets. Why only PSAMP? This is my question. Section 5.3 is titled 'Correlation for Data Records' so in a IPFIX document I would expect it to be about any IPFIX data records, not only PSAMP. If you limit the scope to PSAMP you should title it 'Correlation of PSAMP Data Records'.=20 >=20 > Or do you mean all of relevant functions should be put in?=20 > For example, one way delay for IPTV stream, an IPFIX Exporter=20 > filters specified IPTV session by using property match=20 > filtering, and then a Collector calculates one way delay=20 > without hash digest. But, this example uses PSAMP packet=20 > reports as well. Besides it, it is apparently difficult to=20 > get one way delay from general Flow Record. At this stage, I=20 > can not come up with another idea. >=20 .... > >=20 >=20 > I will add it as Informative Reference. >=20 > o Cases 1: Spatial Composition within one Observation Domain > =20 > For example, to measure the traffic for a single logical=20 > interface in the case where link aggregation [IEEE802.3ad] exists, > Data Records metered at physical interfaces belonging to the same=20 > trunk can be merged. OK. >=20 >=20 > > >=20 > > > > T3. Section 5.5, Cases 3 and 4 - How are data records=20 > > > originating from=20 > > > > different exporters in the same admin domain different=20 > areas, or=20 > > > > different admin domain synchronized in order to be=20 > > > correlated? Is an=20 > > > > unique collector assumed, or some synchronization=20 > process between=20 > > > > collectors? (if this is just a requirement and the answer=20 > > > is in some=20 > > > > other place please point me to it). > > > >=20 > > >=20 > > > Traffic data per some area within a same admin domain comes=20 > > > from aggregation of data records based on info related to=20 > > > observation points. For example, an unique Collector knows=20 > > > where each Explorter exists, such as west or east, and then=20 > > > it works out traffic data per area based on Exporter IP address. > > >=20 > > > In the same way, Traffic data per customer beyond admin=20 > > > domain comes from aggregation of data records. In this case,=20 > > > an unique Collector knows the customer in which each=20 > Explorter exists. > > >=20 > > > I assume IPFIX mediators execute it instead for an unique=20 > > > Collector to reduce the load of Collector. It is just requirement. > > >=20 > > > These aggregation method is described in section 5.3.2.3 in=20 > > > framework draft. > >=20 > > It would be good to mention that unique collectors are assumed. > > Otherwise people may try to implement the functions on multiple > > collector which would imply usage of expensive time synchronization > > processes.=20 > >=20 >=20 > I will replace it as follows. >=20 > o Cases 4: Spatial Composition across administrative domains >=20 > Data Records metered across administrative domains, such as across > different customer networks or different ISP networks, can be merged. > For example, an unique Collector knows in which customer network an > Explorter exists, and then works out the traffic data per=20 > customer based > on the Explorter IP address. OK.=20 >=20 >=20 > > >=20 > > > > T4. Section 5.7 - why are (traditional) fixed telephony=20 > and mobile=20 > > > > telephony mentioned here? > > > >=20 > > >=20 > > > As far as I know, originally data retention comes from=20 > > > requirement of traditional service. I means the starting=20 > > > point for data retension is traditional service to explain it. > > >=20 > >=20 > > This explanation is not clear to me. In order for IPFIX to carry > > traditional telephony traffic information this information=20 > needs to be > > translated into IP traffic using some kind of gateway. After that it > > does not differ to regular VoIP traffic originated by the=20 > gateway. So > > how are these cases different from VoIP?=20 > >=20 >=20 > Hmm, they are not much different than traditional. So, I will=20 > improve it > more concisely. >=20 > [Old] > Data retention services examples are the following: >=20 > o Fixed telephony (includes fixed voice calls, voicemail, and > conference and data calls) >=20 > o Mobile telephony (includes mobile voice calls, voicemail, > conference and data calls, SMS, and MMS) >=20 > o Internet telephony (includes every multimedia session associated > with IP multimedia services) >=20 > o Internet e-mail >=20 > o Internet access >=20 > Data retention for Internet access services in particular requires a > measurement system with reliable export and huge storage as the data=20 > must be available for a long period of time, typically at least six=20 > months. >=20 >=20 > [New] > Data retention examples relevant to IP networks are the following: >=20 > o Internet telephony (includes every multimedia session associated > with IP multimedia services, such as VoIP, IPTV) >=20 > o Internet e-mail >=20 > o Internet access >=20 > Data retention for these services in particular has been required a > measurement system with reliable export and huge storage as the data > must be available for a long period of time, typically at least six > months.=20 OK.=20 From akoba@nttv6.net Tue Feb 16 02:11: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 563683A7CA9 for ; Tue, 16 Feb 2010 02:11:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.012 X-Spam-Level: X-Spam-Status: No, score=-0.012 tagged_above=-999 required=5 tests=[AWL=-0.623, BAYES_00=-2.599, HOST_MISMATCH_COM=0.311, RDNS_DYNAMIC=0.1, 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 8-FJoeveFFx0 for ; Tue, 16 Feb 2010 02:11:00 -0800 (PST) Received: from mail.nttv6.net (mail.nttv6.net [IPv6:2001:fa8::25]) by core3.amsl.com (Postfix) with ESMTP id 2748B3A7CA8 for ; Tue, 16 Feb 2010 02:10:59 -0800 (PST) Received: from [127.0.0.1] (dhcp-3-152.nttv6.com [192.47.163.152]) by mail.nttv6.net (8.14.3/8.14.3) with ESMTP id o1GACTr7046186; Tue, 16 Feb 2010 19:12:30 +0900 (JST) (envelope-from akoba@nttv6.net) Date: Tue, 16 Feb 2010 19:08:16 +0900 From: Atsushi Kobayashi To: "Romascanu, Dan (Dan)" In-Reply-To: References: <20100216012754.3F36.17391CF2@nttv6.net> Message-Id: <20100216184050.3F62.17391CF2@nttv6.net> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Becky! ver. 2.50.05 [ja] (Unregistered) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.3 (mail.nttv6.net [192.16.178.5]); Tue, 16 Feb 2010 19:12:30 +0900 (JST) Cc: ipfix@ietf.org Subject: Re: [IPFIX] AD review of draft-ietf-ipfix-mediators-problem-statement 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, 16 Feb 2010 10:11:01 -0000 Hi Dan, > > > Yes, but you did not answer my question. Why only this type > > of packets > > > (PSAMP packet reports) and not other type of IPFIX packets > > can be used > > > to measure one way delay correlation? > > > > > > > Sorry, I would like to clarify your question. > > This section covers the one way delay associated with > > observed packets in PSAMP Exporter. I do not mean one way > > delay for IPFIX packets, PSAMP packets. > > Why only PSAMP? This is my question. Section 5.3 is titled 'Correlation > for Data Records' so in a IPFIX document I would expect it to be about > any IPFIX data records, not only PSAMP. If you limit the scope to PSAMP > you should title it 'Correlation of PSAMP Data Records'. > Section 5.3 is not limited to just one-way delay, it enumerates some examples, such as average/maximum/minimum values, rate-limiting ratio, and BGP attributes. Even though one-way delay or packet inter-arrival time comes from only PSAMP packet report, the rest are applied to both. Thus, I named it "Correlation for Data Records". Is it OK? Regards, Atsushi --- Atsushi KOBAYASHI NTT Information Sharing Platform Lab. tel:+81-(0)422-59-3978 fax:+81-(0)422-59-5637 From dromasca@avaya.com Tue Feb 16 02:16:26 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 580AB3A7CAE for ; Tue, 16 Feb 2010 02:16:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.525 X-Spam-Level: X-Spam-Status: No, score=-2.525 tagged_above=-999 required=5 tests=[AWL=0.074, 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 2wj48Rr+upck for ; Tue, 16 Feb 2010 02:16:25 -0800 (PST) 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 D3BCA3A7CAD for ; Tue, 16 Feb 2010 02:16:24 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.49,483,1262581200"; d="scan'208";a="176586676" Received: from unknown (HELO p-us1-erheast.us1.avaya.com) ([135.11.50.53]) by de307622-de-outbound.net.avaya.com with ESMTP; 16 Feb 2010 05:17:56 -0500 X-IronPort-AV: E=Sophos;i="4.49,483,1262581200"; d="scan'208";a="431995473" Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.11]) by p-us1-erheast-out.us1.avaya.com with ESMTP; 16 Feb 2010 05:17:20 -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: Tue, 16 Feb 2010 11:16:55 +0100 Message-ID: In-Reply-To: <20100216184050.3F62.17391CF2@nttv6.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Re[4]: [IPFIX] AD review of draft-ietf-ipfix-mediators-problem-statement Thread-Index: Acqu8I5b4V+8hNWSRceADQ5rWqIvnQAAH/xw References: <20100216012754.3F36.17391CF2@nttv6.net> <20100216184050.3F62.17391CF2@nttv6.net> From: "Romascanu, Dan (Dan)" To: "Atsushi Kobayashi" Cc: ipfix@ietf.org Subject: Re: [IPFIX] AD review of draft-ietf-ipfix-mediators-problem-statement 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, 16 Feb 2010 10:16:26 -0000 =20 > -----Original Message----- > From: Atsushi Kobayashi [mailto:akoba@nttv6.net]=20 > Sent: Tuesday, February 16, 2010 12:08 PM > To: Romascanu, Dan (Dan) > Cc: ipfix@ietf.org > Subject: Re[4]: [IPFIX] AD review of=20 > draft-ietf-ipfix-mediators-problem-statement >=20 >=20 > Hi Dan, >=20 > > > > Yes, but you did not answer my question. Why only this type > > > of packets > > > > (PSAMP packet reports) and not other type of IPFIX packets > > > can be used > > > > to measure one way delay correlation? > > > >=20 > > >=20 > > > Sorry, I would like to clarify your question.=20 > > > This section covers the one way delay associated with observed=20 > > > packets in PSAMP Exporter. I do not mean one way delay for IPFIX=20 > > > packets, PSAMP packets. > >=20 > > Why only PSAMP? This is my question. Section 5.3 is titled=20 > > 'Correlation for Data Records' so in a IPFIX document I=20 > would expect=20 > > it to be about any IPFIX data records, not only PSAMP. If you limit=20 > > the scope to PSAMP you should title it 'Correlation of=20 > PSAMP Data Records'. > >=20 >=20 > Section 5.3 is not limited to just one-way delay, it=20 > enumerates some examples, such as average/maximum/minimum=20 > values, rate-limiting ratio, and BGP attributes. Even though=20 > one-way delay or packet inter-arrival time comes from only=20 > PSAMP packet report, the rest are applied to both. > Thus, I named it "Correlation for Data Records". Is it OK? >=20 > Regards, > Atsushi >=20 OK, I got it. Thanks for your patience in explaining the details.=20 Dan From Quittek@nw.neclab.eu Tue Feb 16 09:08: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 D424E3A7D53 for ; Tue, 16 Feb 2010 09:08:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5rBTy9ruja5o for ; Tue, 16 Feb 2010 09:08:09 -0800 (PST) Received: from smtp0.neclab.eu (smtp0.neclab.eu [195.37.70.41]) by core3.amsl.com (Postfix) with ESMTP id 8108D3A75C6 for ; Tue, 16 Feb 2010 09:08:08 -0800 (PST) Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp0.neclab.eu (Postfix) with ESMTP id 5C2A32C0203E2; Tue, 16 Feb 2010 18:09:43 +0100 (CET) X-Virus-Scanned: Amavisd on Debian GNU/Linux (atlas2.office) Received: from smtp0.neclab.eu ([127.0.0.1]) by localhost (atlas2.office [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Q5zsHpNqwvKd; Tue, 16 Feb 2010 18:09:43 +0100 (CET) Received: from VENUS.office (mx1.office [192.168.24.3]) by smtp0.neclab.eu (Postfix) with ESMTP id 375952C01CA08; Tue, 16 Feb 2010 18:09:28 +0100 (CET) X-MimeOLE: Produced By Microsoft Exchange V6.5 Received: from 10.1.2.39 ([10.1.2.39]) by VENUS.office ([192.168.24.102]) with Microsoft Exchange Server HTTP-DAV ; Tue, 16 Feb 2010 17:09:28 +0000 MIME-Version: 1.0 Content-class: urn:content-classes:message Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="B_3349188828_7735978" Date: Tue, 16 Feb 2010 18:13:47 +0100 Message-ID: In-Reply-To: X-MS-Has-Attach: yes X-MS-TNEF-Correlator: Thread-Topic: [IPFIX] AD review of draft-ipfix-mediators-problem-statement Thread-Index: AcquOKMsWkt5tI0NSWS0N/xfyd/SpAADi6HAADklLRQ= From: "Juergen Quittek" To: "Dan Romascanu" , "Gerhard Muenz" Cc: IETF IPFIX Working Group Subject: Re: [IPFIX] AD review of draft-ipfix-mediators-problem-statement 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, 16 Feb 2010 17:08:10 -0000 > This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --B_3349188828_7735978 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable Dear Dan and all, This is a mistake in the tracker. On Jan 19 I submitted the write-up for draft-ipfix-mediators-problem-statement, but not for draft-ietf-ipfix-mediators-framework. The framework still needs to undergo a WG last call Which will probably happen soon. Juergen On 15.02.10 15:05 "Dan Romascanu" wrote: > Hmmmm ... This is a question for the chairs actually. The tracker says it= was > submitted to the IESG on 1/19 together with > draft-ipfix-mediators-problem-statement, but maybe the track is wrong as = I > cannot find a PROTO write-up for it - the one in the tracker is for > problem-statement. I am freezing this one until I get a clarification fro= m > Juergen and Nevil. If you are correct I will wait for the WG to complete = the > consensus process. No bad things happened, anyway - you just got an early= AD > review :-)=20 >=20 > Dan >=20 >=20 >> -----Original Message----- >> From: Gerhard Muenz [mailto:muenz@net.in.tum.de] >> Sent: Monday, February 15, 2010 2:19 PM >> To: Romascanu, Dan (Dan) >> Cc: Atsushi Kobayashi; ipfix@ietf.org >> Subject: Re: [IPFIX] AD review of draft-ietf-ipfix-mediators-framework >>=20 >>=20 >> Hi Dan, Atsushi, >>=20 >> I'm confused. Has there already been a WG LC for this document? >>=20 >> Regards, >> Gerhard >>=20 >>=20 >> Romascanu, Dan (Dan) wrote: >>> Hi Atsushi, >>>=20 >>> Your proposed edits are fine. I am expecting for a revised >> version to=20 >>> be published before sending the document to IETF Last Call. >>>=20 >>> Thanks and Regards, >>>=20 >>> Dan >>>=20 >>>> -----Original Message----- >>>> From: Atsushi Kobayashi [mailto:akoba@nttv6.net] >>>> Sent: Tuesday, February 09, 2010 5:25 PM >>>> To: Romascanu, Dan (Dan) >>>> Cc: ipfix@ietf.org >>>> Subject: Re: [IPFIX] AD review of >>>> draft-ietf-ipfix-mediators-framework >>>>=20 >>>>=20 >>>> Hi Dan, and all, >>>>=20 >>>> Thank you for your comments. Sorry for my late reply. >>>> Please see in-line. >>>>=20 >>>> On Tue, 2 Feb 2010 18:55:14 +0100 >>>> "Romascanu, Dan (Dan)" wrote: >>>>=20 >>>>> Please find below the AD review of >>>> draft-ietf-ipfix-mediators-framework. >>>>> The document is in pretty good shape, but I suggest that >>>> the editors >>>>> review my technical and editorial comments and address >> them before=20 >>>>> deciding whether to revise the I-D or send the document >> directly to=20 >>>>> IETF Last Call. >>>>>=20 >>>>> Thanks and Regards, >>>>>=20 >>>>> Dan >>>>>=20 >>>>>=20 >>>>> Technical:=20 >>>>>=20 >>>>> T1. I do not see the Data Retention use case mentioned in >>>>> draft-ietf-mediators-problem-statement addressed in any >> way in this=20 >>>>> draft. Did I miss anything? >>>>>=20 >>>> Problem statement draft raised the following requirements >> about data=20 >>>> retentions. >>>>=20 >>>> - Reliable exporting >>>> In this case, an IPFIX Mediator beside an Original Exporter can >>>> enhance the export reliability by converting from UDP to SCP. This >>>> has relevance to section 5.3.2.1. "Intermediate Conversion >> Process". >>>>=20 >>>> - Huge storage for data records >>>> In this case, an IPFIX Mediator re-exports data records >> stored to a=20 >>>> Collector on demand. This has relevance to section 6.3. >> "IPFIX File=20 >>>> Writer/Reader". >>>>=20 >>>> I will improve the section 5.3.2.1. and section 6.3 as follows. >>>>=20 >>>> 5.3.2.1. Intermediate Conversion Process >>>>=20 >>>> [snip] >>>>=20 >>>> [Old] >>>> In the case of IPFIX transport protocol conversion, the >> Intermediate=20 >>>> Conversion Process covers the following functions. >>>>=20 >>>> [New] >>>> In the case of IPFIX transport protocol conversion to enhance the >>>> export reliability, commonly used in data retention and >> accounting,=20 >>>> the Intermediate Conversion Process covers the following functions. >>>>=20 >>>> 6.3. IPFIX File Writer/Reader >>>>=20 >>>> [snip] >>>>=20 >>>> .-------------. .---------------. .---------------. >>>> .-----------. >>>> | IPFIX | | Intermediate | | Intermediate | | >>>> Exporting | >>>> | File | | Anonymization | | Correlation | | >>>> Process | >>>> | Reader +->| Process +->| Process +->| >>>> | >>>> '-------------' '---------------' '---------------' >>>> '-----------' >>>>=20 >>>> Figure J: IPFIX Mediation Example with IPFIX File Reader. >>>>=20 >>>> [New] >>>> When distributed IPFIX Mediators export Data Records >> stored on demand >>>> as like figure, it allows us to build the collecting >> infrastructure=20 >>>> with huge storage for data retention. >>>>=20 >>>>=20 >>>>> T2. In Section 5.3: >>>>>=20 >>>>> Maintaining additional information about output record streams, >>>>> which includes information related to Original >>>> Exporter, and some >>>>> configuration parameters related to each function. >>>>>=20 >>>>> I think here we need to add the observation domain and the admin >>>>> domain to the Original Exporter because of support for multiple >>>>> exporters and correlation between domains >>>> I will replace it as follows. >>>>=20 >>>> [New] >>>> Maintaining additional information about output record >> streams, which=20 >>>> includes information related to Original Exporter, Observation >>>> Domain, and administrative domain and some configuration >> parameters=20 >>>> related to each function. >>>>=20 >>>>> T3. In section 7 - I cannot figure out how the collector >>>> knows what to >>>>> fill in the Observation Domain ID when this is different from the >>>>> incoming Observation Domain ID? Can you help by >> explaining how this >>>>> works? >>>> Could you please see last sentense in section 7. But, it seems >>>> sketchy. >>>> I will replace it as follows. >>>>=20 >>>>=20 >>>> [Old] >>>> In that case, the IPFIX Concentrator can add a new field >> to the Flow=20 >>>> Record instead of the Observation Domain ID. The field >> indicates the=20 >>>> largest set of Observation Points for an aggregated Flow Record. >>>>=20 >>>> [New] >>>> When an IPFIX Mediator needs to give the Observation >> Domain ID value=20 >>>> exported from an Original Exporter to Collector, an IPFIX Mediator >>>> can insert this value as new fields into Flow Record, or >> Data Records=20 >>>> defined by Options Templates. In the case of Flow Records >>>> aggregation in an IPFIX Mediator, this new field indicates the >>>> largest set of Observation Points for an aggregated Flow Record. >>>>=20 >>>> I think this method will be described in detail in >> standard mediation >>>> protocol document at next stage. >>>>=20 >>>>> 4. Data retention needs to be added to the security >>>> considerations - >>>>> if relevant - related to T1 >>>> I put the feedback from problem statement draft, and will enhance >>>> them. >>>>=20 >>>>>=20 >>>>> Editorial:=20 >>>>>=20 >>>>> E1. running id-nits results in the following warnings: >>>>>=20 >>>>>=20 >>>>> tmp/draft-ietf-ipfix-mediators-framework-04.txt: >>>>> tmp/draft-ietf-ipfix-mediators-framework-04.txt(405): >> Line has weird >>>>> spacing: '...ributor one ...' >>>>> tmp/draft-ietf-ipfix-mediators-framework-04.txt(407): >> Line has weird >>>>> spacing: '...ntrator one o...' >>>>> tmp/draft-ietf-ipfix-mediators-framework-04.txt(410): >> Line has weird >>>>> spacing: '...erading one o...' >>>>> tmp/draft-ietf-ipfix-mediators-framework-04.txt(530): >> Line has weird >>>>> spacing: '...Reports recor...' >>>>> tmp/draft-ietf-ipfix-mediators-framework-04.txt(547): >> Line has weird >>>>> spacing: '...rvation into ...' >>>>>=20 >>>>>=20 >>>>> Checking boilerplate required by RFC 5378 and the IETF >> Trust (see >>>>> http://trustee.ietf.org/license-info): >>>>> =20 >>>>>=20 >>>>=20 >> --------------------------------------------------------------------- >>>> - >>>>> -- >>>>> ---- >>>>>=20 >>>>> ** The document seems to lack a License Notice according >>>> IETF Trust >>>>> Provisions of 28 Dec 2009, Section 6.b.i or Provisions >>>> of 12 Sep >>>>> 2009 >>>>> Section 6.b -- however, there's a paragraph with a matching >>>>> beginning. >>>>> Boilerplate error? >>>>>=20 >>>> This document was submitted in October, 2009. Thus, it could not >>>> catch up with latest License Notice. I will take care in next >>>> version. >>>>=20 >>>>=20 >>>>> IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), >>>>> paragraph 3: >>>>> "This document is subject to BCP 78 and the IETF >> Trust's Legal=20 >>>>> Provisions >>>>> Relating to IETF Documents >>>> (http://trustee.ietf.org/license-info) >>>>> in effect on the date of publication of this >> document. Please >>>>> review these documents carefully, as they describe >>>> your rights and >>>>> restrictions with respect to this document. Code Components >>>>> extracted from this document must include Simplified >>>> BSD License >>>>> text as described in Section 4.e of the Trust Legal >>>> Provisions and >>>>> are provided without warranty as described in the >>>> Simplified BSD >>>>> License." >>>>>=20 >>>>> ... text found in draft: >>>>> "This document is subject to BCP 78 and the IETF >> Trust's Legal=20 >>>>> Provisions >>>>> Relating to IETF Documents in effect on the date of >>>> publication >>>>> of .................................^ >>>>> this document >> (http://trustee.ietf.org/license-info). Please >>>>> review >>>>> these documents carefully, as they describe your rights and >>>>> restrictions with respect to this document." >>>>>=20 >>>>>=20 >>>>> (You're using the IETF Trust Provisions' Section 6.b License >>>>> Notice from >>>>> 12 Feb 2009 rather than one of the newer Notices. See >>>>> http://trustee.ietf.org/license-info/.) >>>>>=20 >>>>> E2. Section 1. >>>>>=20 >>>>> To acihive application requirements with limited system resources, >>>>> IPFIX architecture needs to introduce an intermediate >>>> device between >>>>> Exporters and Collectors. >>>>>=20 >>>>> s/acihive/achieve/ >>>>>=20 >>>>> Also 'device' has too much a hardware connotation, while >> mediators=20 >>>>> need not be necessarily hardware 'devices'. Probably >>>> 'component' or 'entity' >>>>> is more appropriate. >>>> Thank you.=20 >>>>=20 >>>>> E3. Part of the definitions in section 2 duplicate definitions in >>>>> draft-ietf-mediators-problem-statement. Better avoid the >>>> duplication >>>>> and just refer draft-ietf-mediators-problem-statement. >>>>>=20 >>>>> E4. Section 7 - >>>>>=20 >>>>> The IPFIX Message Header [RFC5101] includes Export Time, Sequence >>>>> Number, and Observation Domain ID fields. This >> section describes >>>>> some consideration points for the IPFIX Message Header >> encoding. >>>>>=20 >>>>> Need to add 'in the context of IPFIX Mediation'. >>>>>=20 >>>> Ok. >>>>=20 >>>>> E5. Should not [IPFIX-MD-PS] be a Normative Reference? >>>>>=20 >>>> [IPFIX-MD-PS] describes the concept of mediation as informative >>>> reference, does not describe the normative standard. >>>> Thus, I think it is a informative reference. >>>>=20 >>>> Regards, >>>> Atsushi >>>>=20 >>>>> _______________________________________________ >>>>> IPFIX mailing list >>>>> IPFIX@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/ipfix >>>> --- >>>> Atsushi KOBAYASHI >>>> NTT Information Sharing Platform Lab. >>>> tel:+81-(0)422-59-3978 fax:+81-(0)422-59-5637 >>>>=20 >>>>=20 >>> _______________________________________________ >>> IPFIX mailing list >>> IPFIX@ietf.org >>> https://www.ietf.org/mailman/listinfo/ipfix >>=20 >> -- >> Dipl.-Ing. Gerhard M=FCnz >> Chair for Network Architectures and Services (I8) Technische >> Universit=E4t M=FCnchen - Department of Informatics Boltzmannstr. >> 3, 85748 Garching bei M=FCnchen, Germany >> Phone: +49 89 289-18008 Fax: +49 89 289-18033 >> E-mail: muenz@net.in.tum.de WWW: http://www.net.in.tum.de/~muenz >>=20 >>=20 >>=20 > _______________________________________________ > IPFIX mailing list > IPFIX@ietf.org > https://www.ietf.org/mailman/listinfo/ipfix --B_3349188828_7735978 Content-type: application/pkcs7-signature; name="smime.p7s" Content-transfer-encoding: base64 Content-disposition: attachment; filename="smime.p7s" MIIQ6gYJKoZIhvcNAQcCoIIQ2zCCENcCAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3DQEHAaCC DpIwggU2MIIEHqADAgECAgQNLisHMA0GCSqGSIb3DQEBBQUAMIGQMQswCQYDVQQGEwJERTEY MBYGA1UEChMPTkVDIEV1cm9wZSBMdGQuMSAwHgYDVQQLExdORUMgTGFib3JhdG9yaWVzIEV1 cm9wZTESMBAGA1UEAxMJTkVDTEFCLUNBMTEwLwYJKoZIhvcNAQkBFiJ6ZXJ0aWZpemllcnVu Z3NzdGVsbGVAbncubmVjbGFiLmV1MB4XDTA4MTEwMzA3NTEyMFoXDTExMTEwMzA3NTEyMFow YzELMAkGA1UEBhMCREUxGDAWBgNVBAoTD05FQyBFdXJvcGUgTHRkLjEgMB4GA1UECxMXTkVD IExhYm9yYXRvcmllcyBFdXJvcGUxGDAWBgNVBAMTD0p1ZXJnZW4gUXVpdHRlazCCASIwDQYJ KoZIhvcNAQEBBQADggEPADCCAQoCggEBALYRfFB9x4h1YO6Mva6A5GCwKjwpgvzjiayFSmdD HwV8u5gHp3sHIhyVtxgMSifEp9AV+ChxWHS3KQwuQ3XhDAP/xDN6QSk4Bmqa6rCZuTJygxYh K39rNKd47ZfpuRC7j/Mbzwe9DTsbbBtpBgl5UKFc9c+zMbPlSwwlVbshWaUEoM6HoVFaDJdh tJBIpsblz1oQVKXDjxjGkUNh9Ds3m7BGXkr5yaGsEuEa0J/QAFdO+auvBJlAzIM0UwBAmlcT UHanS6Sdw5MkeutQqnmsUBtoenydq2Tmd9hfSfuTfiFuLmsvL3udH/jDAgQZ+PH6Mprqpyd3 wSycF/xZF5zz8X0CAwEAAaOCAcIwggG+MAkGA1UdEwQCMAAwCwYDVR0PBAQDAgXgMCkGA1Ud JQQiMCAGCCsGAQUFBwMCBggrBgEFBQcDBAYKKwYBBAGCNxQCAjAdBgNVHQ4EFgQUWQo3BPrO OLA4qljzDL1H8/6hIWEwHwYDVR0jBBgwFoAUTxyHeh3gL5n2vhWq0TWdDkrmujYwHwYDVR0R BBgwFoEUUXVpdHRla0Budy5uZWNsYWIuZXUwfQYDVR0fBHYwdDA4oDagNIYyaHR0cDovL2Nk cDEucGNhLmRmbi5kZS9uZWNsYWItY2EvcHViL2NybC9jYWNybC5jcmwwOKA2oDSGMmh0dHA6 Ly9jZHAyLnBjYS5kZm4uZGUvbmVjbGFiLWNhL3B1Yi9jcmwvY2FjcmwuY3JsMIGYBggrBgEF BQcBAQSBizCBiDBCBggrBgEFBQcwAoY2aHR0cDovL2NkcDEucGNhLmRmbi5kZS9uZWNsYWIt Y2EvcHViL2NhY2VydC9jYWNlcnQuY3J0MEIGCCsGAQUFBzAChjZodHRwOi8vY2RwMi5wY2Eu ZGZuLmRlL25lY2xhYi1jYS9wdWIvY2FjZXJ0L2NhY2VydC5jcnQwDQYJKoZIhvcNAQEFBQAD ggEBAB37+54yupDBTDpEMuyf+ouCRrOE3fPAD2SEGBXCpKTYteFkFSWvHlgN8ecRSma0Dz/5 QShzacGMeJ8o+XzVXHe2gtZbjzSVvJn+/nAKtKgDCzw0ltt3xkdMMv2ax6IKGR7BcccsXx7B R2PMaxdmHfCJseXiMzZO9QlWN2NZq2SSo3eGX/YDhHCWXDsoSu+uaKU/aRL2uZa92ptak2MA uKI5tylKLFZ3FHf08F8J+5tTaMGem6DfaMZR/9GZ8aRFJrdA7tzUAGKpl+CzRxsJVHbAAU5L hm5oTt6XYbh2G/cgdpeucsHJWBz9NQJrSrfWZYSwrv6AekMcvMi9X/CVZxEwggUvMIIEF6AD AgECAgQNIQpHMA0GCSqGSIb3DQEBBQUAMFoxCzAJBgNVBAYTAkRFMRMwEQYDVQQKEwpERk4t VmVyZWluMRAwDgYDVQQLEwdERk4tUEtJMSQwIgYDVQQDExtERk4tVmVyZWluIFBDQSBHbG9i YWwgLSBHMDEwHhcNMDgxMDI0MDg1MjA4WhcNMTkwNjMwMDAwMDAwWjCBkDELMAkGA1UEBhMC REUxGDAWBgNVBAoTD05FQyBFdXJvcGUgTHRkLjEgMB4GA1UECxMXTkVDIExhYm9yYXRvcmll cyBFdXJvcGUxEjAQBgNVBAMTCU5FQ0xBQi1DQTExMC8GCSqGSIb3DQEJARYiemVydGlmaXpp ZXJ1bmdzc3RlbGxlQG53Lm5lY2xhYi5ldTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoC ggEBAJ7yFbG1EaoyDnG5367mJEXHljmacrzNnm52KW3dXD/s3Vpuskex0jvaaTntWWRSGrAK 6kKXnTxBb3J3EhveBUbltzQ+K0XKtPJm6VE5qVpl33WJSaUHs27Dhwlke+DV6BBGyukz2SDB aSa+nc0AwMZ0XO1DoDuiUNVeNmd/QT4SGzyFs+uLfLL2n8WzkZsbpSZ+xecwyw3EdQBBsp/i /W+uOQBsGqaCjYe3EkBU6nW+pBsj0Iy1n7b9PXb5gQynrK3Mi2V7g1idSzHos0o1BMoHUrMz Vw94Hj4CWlWmQ0t6Pdt1uYAMjwk0saQBY/Fyfv+wKeYycGIYyYCfJIRUeyUCAwEAAaOCAcQw ggHAMBIGA1UdEwEB/wQIMAYBAf8CAQEwCwYDVR0PBAQDAgEGMB0GA1UdDgQWBBRPHId6HeAv mfa+FarRNZ0OSua6NjAfBgNVHSMEGDAWgBRJt8bP6D0ff+pEexMp9/EKcD7eZDAtBgNVHREE JjAkgSJ6ZXJ0aWZpemllcnVuZ3NzdGVsbGVAbncubmVjbGFiLmV1MIGIBgNVHR8EgYAwfjA9 oDugOYY3aHR0cDovL2NkcDEucGNhLmRmbi5kZS9nbG9iYWwtcm9vdC1jYS9wdWIvY3JsL2Nh Y3JsLmNybDA9oDugOYY3aHR0cDovL2NkcDIucGNhLmRmbi5kZS9nbG9iYWwtcm9vdC1jYS9w dWIvY3JsL2NhY3JsLmNybDCBogYIKwYBBQUHAQEEgZUwgZIwRwYIKwYBBQUHMAKGO2h0dHA6 Ly9jZHAxLnBjYS5kZm4uZGUvZ2xvYmFsLXJvb3QtY2EvcHViL2NhY2VydC9jYWNlcnQuY3J0 MEcGCCsGAQUFBzAChjtodHRwOi8vY2RwMi5wY2EuZGZuLmRlL2dsb2JhbC1yb290LWNhL3B1 Yi9jYWNlcnQvY2FjZXJ0LmNydDANBgkqhkiG9w0BAQUFAAOCAQEAbDEPnQ9JpouPHYA1OEek P3l3GNM0HBzadVbtbN5MDtFmoVgdLYqlQaHb30wFhuOMbsNCOzV0k8EOvBVOT9BiEJ70RWcl SZQ460jZS2MY6n5oG/ilZuu6N/N3GSLg2pBBNH9vZFCyBJ9n4Px7A4gQF07G+CNfV2jdE1yy PjzIVPhg6bBgia8nXroBFe6oteavMspo0gLGIJ63NsCbl6ckPa96grT+mnnQD0h6jk/IGtXS 09mEWRbN7zZu0x0q+SScpljG36Q+jnG0U5zQI0jAx8CcYEQQH5QOlsw1Zu35OI4lsi7ycFkz JNfbfEC4ihuw9J2L43BFGMojkhPkhVExHTCCBCEwggMJoAMCAQICAgDHMA0GCSqGSIb3DQEB BQUAMHExCzAJBgNVBAYTAkRFMRwwGgYDVQQKExNEZXV0c2NoZSBUZWxla29tIEFHMR8wHQYD VQQLExZULVRlbGVTZWMgVHJ1c3QgQ2VudGVyMSMwIQYDVQQDExpEZXV0c2NoZSBUZWxla29t IFJvb3QgQ0EgMjAeFw0wNjEyMTkxMDI5MDBaFw0xOTA2MzAyMzU5MDBaMFoxCzAJBgNVBAYT AkRFMRMwEQYDVQQKEwpERk4tVmVyZWluMRAwDgYDVQQLEwdERk4tUEtJMSQwIgYDVQQDExtE Rk4tVmVyZWluIFBDQSBHbG9iYWwgLSBHMDEwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEK AoIBAQDpm8NnhfkNrvWNVMOWUDU9YuluTO2U1wBblSJ01CDrNI/W7MAxBAuZgeKmFNJSoCgj hIt0iQReW+DieMF4yxbLKDU5ey2QRdDtoAB6fL9KDhsAw4bpXCsxEXsM84IkQ4wcOItqaACa 7txPeKvSxhObdq3u3ibo7wGvdA/BCaL2a869080UME/15eOkyGKbghoDJzANAmVgTe3RCSMq ljVYJ9N2xnG2kB3E7f81hn1vM7PbD8URwoqDoZRdQWvY0hD1TP3KUazZve+Sg7va64sWVlZD z+HVEz2mHycwzUlU28kTNJpxdcVs6qcLmPkhnSevPqM5OUhqjK3JmfvDEvK9AgMBAAGjgdkw gdYwcAYDVR0fBGkwZzBloGOgYYZfaHR0cDovL3BraS50ZWxlc2VjLmRlL2NnaS1iaW4vc2Vy dmljZS9hZl9Eb3dubG9hZEFSTC5jcmw/LWNybF9mb3JtYXQ9WF81MDkmLWlzc3Vlcj1EVF9S T09UX0NBXzIwHQYDVR0OBBYEFEm3xs/oPR9/6kR7Eyn38QpwPt5kMB8GA1UdIwQYMBaAFDHD eRu69VPXF+CJei0XbAqzK50zMA4GA1UdDwEB/wQEAwIBBjASBgNVHRMBAf8ECDAGAQH/AgEC MA0GCSqGSIb3DQEBBQUAA4IBAQA74Vp3wEgX3KkY7IGvWonwvSiSpspZGBJw7Cjy565/lizn 8l0ZMfYTK3S9vYCyufdnyTmieTvhERHua3iRM347XyYndVNljjNj7s9zw7CSI0khUHUjoR8Y 4pSFPT8z6XcgjaK95qGFKUD2P3MyWA0Ja6bahWzAP7uNZmRWJE6uDT8yNQFb6YyC2XJZT7GG hfF0hVblw/hc843uR7NTBXDn5U2KaYMo4RMJhp5eyOpYHgwf+aTUWgRo/Sg+iwK2WLX2oSw3 VwBnqyNojWOl75lrXP1LVvarQIc01BGSbOyHxQoLBzNytG8MHVQs2FHHzL8w00Ny8TK/jM5J Y6gA9/IcMYICIDCCAhwCAQEwgZkwgZAxCzAJBgNVBAYTAkRFMRgwFgYDVQQKEw9ORUMgRXVy b3BlIEx0ZC4xIDAeBgNVBAsTF05FQyBMYWJvcmF0b3JpZXMgRXVyb3BlMRIwEAYDVQQDEwlO RUNMQUItQ0ExMTAvBgkqhkiG9w0BCQEWInplcnRpZml6aWVydW5nc3N0ZWxsZUBudy5uZWNs YWIuZXUCBA0uKwcwCQYFKw4DAhoFAKBdMCMGCSqGSIb3DQEJBDEWBBSAVwXVsXxT+Uh1yCkY MIx1OSYXfDAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xMDAy MTYxNzEzNDhaMA0GCSqGSIb3DQEBAQUABIIBAA20Uysd30ySen9oHWFUAi14yRYacxqRR7PL 1VhvdJw3xBGzjjGiSlk/gGuZ67cPquduShLQ2f/957DAbKpfP/wI5+DPhzzDCQJN7S01wLAo DnbDuVJJXN2V8seJGAbtbTeXXJ2woALAlAsKvRMlRfcFTVsHlgF53Nb0okI8HYqtLoYp0/Ik 6eTStm414TQgq7gl0YbOsjAUOEePuJmcVa4hR640EnT24jjl5hWeOMpMPBWWNhn+QhU9kzKM FlhXtPjqtY93SAUPXsK9Zu+DGInuiziSDvK+sWD/ZwbtKPFQKp5Dtqvx99x7+3Zfg2NAwIbO qjs4hSx7QUCbU1XYr6c= --B_3349188828_7735978-- From dharani@cisco.com Tue Feb 16 10:51: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 ADA8F3A6ED9 for ; Tue, 16 Feb 2010 10:51:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.382 X-Spam-Level: X-Spam-Status: No, score=-9.382 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_53=0.6, RCVD_IN_DNSWL_HI=-8, SARE_UNSUB21=0.616] 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 huFSn+Qd+Rtm for ; Tue, 16 Feb 2010 10:51:30 -0800 (PST) Received: from rtp-iport-2.cisco.com (rtp-iport-2.cisco.com [64.102.122.149]) by core3.amsl.com (Postfix) with ESMTP id E4B453A6A8A for ; Tue, 16 Feb 2010 10:51:29 -0800 (PST) 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: AvsEACB4ekurR7H+/2dsb2JhbACbGXSmB5dmhFsEgxQ X-IronPort-AV: E=Sophos;i="4.49,485,1262563200"; d="scan'208,217";a="86608540" Received: from sj-core-2.cisco.com ([171.71.177.254]) by rtp-iport-2.cisco.com with ESMTP; 16 Feb 2010 18:53:04 +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 o1GIr26S002546 for ; Tue, 16 Feb 2010 18:53:04 GMT Received: from xmb-sjc-222.amer.cisco.com ([128.107.191.106]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 16 Feb 2010 10:52:45 -0800 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_01CAAF39.39C8F7C5" Date: Tue, 16 Feb 2010 10:52:45 -0800 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Regarding draft-kashima-ipfix-data-link-layer-monitoring-01.txt Thread-Index: AcqvOToCwpG/Opb6QGOoCdsfsYQBVg== From: "Dharani Vilwanathan (dharani)" To: X-OriginalArrivalTime: 16 Feb 2010 18:52:45.0315 (UTC) FILETIME=[39EA8D30:01CAAF39] Subject: [IPFIX] Regarding draft-kashima-ipfix-data-link-layer-monitoring-01.txt X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Feb 2010 18:53:29 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CAAF39.39C8F7C5 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Kashima, =20 This is regarding the document: Data Link Layer Monitoring with IPFIX/PSAMP http://tools.ietf.org/id/draft-kashima-ipfix-data-link-layer-monitoring- 01.txt =20 After some email exchanges with Ganesh Murthy and Paul Aitken, we (Yaonan Liang, Laxmi Mukund and self) had a discussion on this document. We would like to understand the document better and so we would like to present our comments to you here: =20 - There are many ethernet types mentioned in the document. But they don't seem to be exhaustive. Some key things like 802.3, WiMax,etc seem to be missing. Probably we can attempt to cover everything or just provide a summary of various types with an explicit note. =20 - The document seems to start straight with a couple of ethernet types. It would be nice if we can start the document more smoothly from an overall perspective. =20 - In section 2, we have: =20 "This was because, at that time, the PSAMP Working Group selected not standardization based on vague requirements but standardization that was quickly completed." =20 The sentence can probably be rephrased. =20 - We can probably add "as well" to the end of next paragraph so that it reads like this: =20 The following Information Elements are necessary for enabling the above-mentioned method, which is not limited to Ethernet because the method can be applied to other data link protocols as well. <<<<----------=20 =20 - It looks like there might be some refinements needed to make the document more precise. =20 - Is this document an extension of RFC5477 (Info model for Packet Sampling Exports) and should it actually be under PSAMP? And because PSAMP working group seems to be no longer active, we are trying to fit in this document in IPFIX? Because, if this document is really intended for IPFIX, we should see how it co-exists with several fields defined by Paul Aitken, Ganesh Murthy and Marco (please see http://tools.ietf.org/id/draft-aitken-ipfix-new-infos-03.txt content of which got added to IANA database). But if the document is intended for PSAMP, then we need to make sure it fits properly in IPFIX. =20 - Section 5.1: Only 3 types are defined. We may have to define rest of the types. =20 - Section 5.1: Any reason why the type is unsigned32? Why can't it be just unsigned8?=20 Also, is it correct to say that dataLinkFrameSize is really the datalink header length?=20 =20 - Section 5.2: Can the type be as low as needed? Like unsigned8 or unsigned16? =20 - Section 5.3: The following paragraph is not clear. It may need rephrasing: =20 "The data for this field MUST NOT be padded. If insufficient octets are available for the length specified in the Template, then a new Template MUST be used." =20 Please pass your comments. =20 Thanks dharani =20 ------_=_NextPart_001_01CAAF39.39C8F7C5 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Hi Kashima,
 
This is regarding the document:
Data = Link Layer=20 Monitoring with IPFIX/PSAMP
http://tools.ietf.org/id/draft-kashima-ipfix-data-link-lay= er-monitoring-01.txt
 
After some email exchanges with Ganesh = Murthy and=20 Paul Aitken, we (Yaonan Liang, Laxmi Mukund and self) had a discussion = on this=20 document. We would like to understand the document better and so we = would like=20 to present our comments to you here:
 
- There are many ethernet types = mentioned in the=20 document. But they don't seem to be exhaustive. Some key things like = 802.3,=20 WiMax,etc seem to be missing. Probably we can attempt to cover = everything or=20 just provide a summary of various types with an explicit = note.
 
- The document seems to start straight = with a=20 couple of ethernet types. It would be nice if we can start the document = more=20 smoothly from an overall perspective.
 
- In section 2, we have:
 
"This was because, at that time,=20 the
   PSAMP Working Group selected not standardization = based on=20 vague
   requirements but standardization that was quickly=20 completed."
 
The sentence can probably be=20 rephrased.
 
- We can probably add "as well" to the = end of next=20 paragraph so that it reads like this:
 
The following Information Elements are = necessary=20 for enabling the
   above-mentioned method, which is not = limited to=20 Ethernet because the
   method can be applied to other data = link=20 protocols as well.    <<<<----------=20
 
-  It looks like there might be some refinements = needed to=20 make the document more precise.
 
-  Is this document an extension = of RFC5477=20 (Info model for Packet Sampling Exports) and should  it actually be = under=20 PSAMP? And because PSAMP working group seems to be no longer active, we = are=20 trying to fit in this document in IPFIX? Because, if this document is = really=20 intended for IPFIX, we should see how it co-exists with several fields = defined=20 by Paul Aitken, Ganesh Murthy and Marco (please see htt= p://tools.ietf.org/id/draft-aitken-ipfix-new-infos-03.txt=20 <htt= p://tools.ietf.org/id/draft-aitken-ipfix-new-infos-03.txt> =20 content of which got added to IANA database). But if the document is = intended=20 for PSAMP, then we need to make sure it fits properly in = IPFIX.
 
- Section 5.1: Only 3 types are = defined. We may=20 have to define rest of the types.
 
- Section 5.1: Any reason why the type = is=20 unsigned32? Why can't it be just unsigned8?=20
        Also, is it correct to = say that=20 dataLinkFrameSize is really the datalink header length?
 
- Section 5.2: Can the type be as low = as needed?=20 Like unsigned8 or unsigned16?
 
- Section 5.3: The following paragraph = is not=20 clear. It may need rephrasing:
 
"The data for this field MUST NOT be = padded. =20 If insufficient
      octets are available = for the=20 length specified in the Template,
      then = a new=20 Template MUST be used."
 
Please pass your comments.
 
Thanks
dharani
 
------_=_NextPart_001_01CAAF39.39C8F7C5-- From Quittek@nw.neclab.eu Wed Feb 17 17:48: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 41DF628C117 for ; Wed, 17 Feb 2010 17:48:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aVTCmxCCNgfW for ; Wed, 17 Feb 2010 17:48:48 -0800 (PST) Received: from smtp0.neclab.eu (smtp0.neclab.eu [195.37.70.41]) by core3.amsl.com (Postfix) with ESMTP id 0848628C0FD for ; Wed, 17 Feb 2010 17:48:48 -0800 (PST) Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp0.neclab.eu (Postfix) with ESMTP id 5D65A2C000352 for ; Thu, 18 Feb 2010 02:50:28 +0100 (CET) X-Virus-Scanned: Amavisd on Debian GNU/Linux (atlas2.office) Received: from smtp0.neclab.eu ([127.0.0.1]) by localhost (atlas2.office [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lqOZvyYwxt0P for ; Thu, 18 Feb 2010 02:50:28 +0100 (CET) Received: from VENUS.office (mx2.office [192.168.24.15]) by smtp0.neclab.eu (Postfix) with ESMTP id 41D332C000350 for ; Thu, 18 Feb 2010 02:50:23 +0100 (CET) Received: from 10.7.0.54 ([10.7.0.54]) by VENUS.office ([192.168.24.102]) with Microsoft Exchange Server HTTP-DAV ; Thu, 18 Feb 2010 01:50:22 +0000 MIME-Version: 1.0 Content-class: urn:content-classes:message Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="B_3349306483_8266410" X-MimeOLE: Produced By Microsoft Exchange V6.5 Date: Thu, 18 Feb 2010 02:54:43 +0100 Message-ID: In-Reply-To: X-MS-Has-Attach: yes X-MS-TNEF-Correlator: Thread-Topic: [IPFIX] WG last call on draft-ietf-ipfix-configuration-model-04 Thread-Index: AcpvYRgUQbW+SV772Um/x/s4lgl5tQpSXJ5SBeSzE6s= From: "Juergen Quittek" To: "IETF IPFIX Working Group" Subject: Re: [IPFIX] WG last call on draft-ietf-ipfix-configuration-model-04 X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Feb 2010 01:48:49 -0000 > This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --B_3349306483_8266410 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Dear all, There is still just one review for this draft. Brian is working on a second review, but I want to see at least a third one before closing the WGLC. Would anyone be willing to add another review for this document? Thanks, Juergen On 19.01.10 02:55 "Juergen Quittek" wrote: > Dear all, > > I received only one review of this document during WGLC. > Did I miss any review? > > I don't think a single review is enough to pass a WGLC > successfully. > > Are there any volunteers for reviewing the draft? > > Thanks, > > Juergen > > > On 27.11.09 13:56 "Juergen Quittek" wrote: > >> Dear all, >> >> At our session at Hiroshima we agreed to have working group last call >> on draft-ietf-ipfix-configuration-model-04. >> >> The call starts today and will last until Friday December 11. >> >> A URL for this Internet-Draft is: >> http://www.ietf.org/id/draft-ietf-ipfix-configuration-model-04.txt >> >> I will ask the NETMOD WG to also review the draft as soon as the >> YANG specification is final. >> >> Please read the draft! >> Please send your comments to this mailing list! >> Please also send a message if you are fine with the draft as it is! >> >> Thank you, >> >> Juergen >> _______________________________________________ >> IPFIX mailing list >> IPFIX@ietf.org >> https://www.ietf.org/mailman/listinfo/ipfix --B_3349306483_8266410 Content-type: application/pkcs7-signature; name="smime.p7s" Content-transfer-encoding: base64 Content-disposition: attachment; filename="smime.p7s" MIIQ6gYJKoZIhvcNAQcCoIIQ2zCCENcCAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3DQEHAaCC DpIwggU2MIIEHqADAgECAgQNLisHMA0GCSqGSIb3DQEBBQUAMIGQMQswCQYDVQQGEwJERTEY MBYGA1UEChMPTkVDIEV1cm9wZSBMdGQuMSAwHgYDVQQLExdORUMgTGFib3JhdG9yaWVzIEV1 cm9wZTESMBAGA1UEAxMJTkVDTEFCLUNBMTEwLwYJKoZIhvcNAQkBFiJ6ZXJ0aWZpemllcnVu Z3NzdGVsbGVAbncubmVjbGFiLmV1MB4XDTA4MTEwMzA3NTEyMFoXDTExMTEwMzA3NTEyMFow YzELMAkGA1UEBhMCREUxGDAWBgNVBAoTD05FQyBFdXJvcGUgTHRkLjEgMB4GA1UECxMXTkVD IExhYm9yYXRvcmllcyBFdXJvcGUxGDAWBgNVBAMTD0p1ZXJnZW4gUXVpdHRlazCCASIwDQYJ KoZIhvcNAQEBBQADggEPADCCAQoCggEBALYRfFB9x4h1YO6Mva6A5GCwKjwpgvzjiayFSmdD HwV8u5gHp3sHIhyVtxgMSifEp9AV+ChxWHS3KQwuQ3XhDAP/xDN6QSk4Bmqa6rCZuTJygxYh K39rNKd47ZfpuRC7j/Mbzwe9DTsbbBtpBgl5UKFc9c+zMbPlSwwlVbshWaUEoM6HoVFaDJdh tJBIpsblz1oQVKXDjxjGkUNh9Ds3m7BGXkr5yaGsEuEa0J/QAFdO+auvBJlAzIM0UwBAmlcT UHanS6Sdw5MkeutQqnmsUBtoenydq2Tmd9hfSfuTfiFuLmsvL3udH/jDAgQZ+PH6Mprqpyd3 wSycF/xZF5zz8X0CAwEAAaOCAcIwggG+MAkGA1UdEwQCMAAwCwYDVR0PBAQDAgXgMCkGA1Ud JQQiMCAGCCsGAQUFBwMCBggrBgEFBQcDBAYKKwYBBAGCNxQCAjAdBgNVHQ4EFgQUWQo3BPrO OLA4qljzDL1H8/6hIWEwHwYDVR0jBBgwFoAUTxyHeh3gL5n2vhWq0TWdDkrmujYwHwYDVR0R BBgwFoEUUXVpdHRla0Budy5uZWNsYWIuZXUwfQYDVR0fBHYwdDA4oDagNIYyaHR0cDovL2Nk cDEucGNhLmRmbi5kZS9uZWNsYWItY2EvcHViL2NybC9jYWNybC5jcmwwOKA2oDSGMmh0dHA6 Ly9jZHAyLnBjYS5kZm4uZGUvbmVjbGFiLWNhL3B1Yi9jcmwvY2FjcmwuY3JsMIGYBggrBgEF BQcBAQSBizCBiDBCBggrBgEFBQcwAoY2aHR0cDovL2NkcDEucGNhLmRmbi5kZS9uZWNsYWIt Y2EvcHViL2NhY2VydC9jYWNlcnQuY3J0MEIGCCsGAQUFBzAChjZodHRwOi8vY2RwMi5wY2Eu ZGZuLmRlL25lY2xhYi1jYS9wdWIvY2FjZXJ0L2NhY2VydC5jcnQwDQYJKoZIhvcNAQEFBQAD ggEBAB37+54yupDBTDpEMuyf+ouCRrOE3fPAD2SEGBXCpKTYteFkFSWvHlgN8ecRSma0Dz/5 QShzacGMeJ8o+XzVXHe2gtZbjzSVvJn+/nAKtKgDCzw0ltt3xkdMMv2ax6IKGR7BcccsXx7B R2PMaxdmHfCJseXiMzZO9QlWN2NZq2SSo3eGX/YDhHCWXDsoSu+uaKU/aRL2uZa92ptak2MA uKI5tylKLFZ3FHf08F8J+5tTaMGem6DfaMZR/9GZ8aRFJrdA7tzUAGKpl+CzRxsJVHbAAU5L hm5oTt6XYbh2G/cgdpeucsHJWBz9NQJrSrfWZYSwrv6AekMcvMi9X/CVZxEwggUvMIIEF6AD AgECAgQNIQpHMA0GCSqGSIb3DQEBBQUAMFoxCzAJBgNVBAYTAkRFMRMwEQYDVQQKEwpERk4t VmVyZWluMRAwDgYDVQQLEwdERk4tUEtJMSQwIgYDVQQDExtERk4tVmVyZWluIFBDQSBHbG9i YWwgLSBHMDEwHhcNMDgxMDI0MDg1MjA4WhcNMTkwNjMwMDAwMDAwWjCBkDELMAkGA1UEBhMC REUxGDAWBgNVBAoTD05FQyBFdXJvcGUgTHRkLjEgMB4GA1UECxMXTkVDIExhYm9yYXRvcmll cyBFdXJvcGUxEjAQBgNVBAMTCU5FQ0xBQi1DQTExMC8GCSqGSIb3DQEJARYiemVydGlmaXpp ZXJ1bmdzc3RlbGxlQG53Lm5lY2xhYi5ldTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoC ggEBAJ7yFbG1EaoyDnG5367mJEXHljmacrzNnm52KW3dXD/s3Vpuskex0jvaaTntWWRSGrAK 6kKXnTxBb3J3EhveBUbltzQ+K0XKtPJm6VE5qVpl33WJSaUHs27Dhwlke+DV6BBGyukz2SDB aSa+nc0AwMZ0XO1DoDuiUNVeNmd/QT4SGzyFs+uLfLL2n8WzkZsbpSZ+xecwyw3EdQBBsp/i /W+uOQBsGqaCjYe3EkBU6nW+pBsj0Iy1n7b9PXb5gQynrK3Mi2V7g1idSzHos0o1BMoHUrMz Vw94Hj4CWlWmQ0t6Pdt1uYAMjwk0saQBY/Fyfv+wKeYycGIYyYCfJIRUeyUCAwEAAaOCAcQw ggHAMBIGA1UdEwEB/wQIMAYBAf8CAQEwCwYDVR0PBAQDAgEGMB0GA1UdDgQWBBRPHId6HeAv mfa+FarRNZ0OSua6NjAfBgNVHSMEGDAWgBRJt8bP6D0ff+pEexMp9/EKcD7eZDAtBgNVHREE JjAkgSJ6ZXJ0aWZpemllcnVuZ3NzdGVsbGVAbncubmVjbGFiLmV1MIGIBgNVHR8EgYAwfjA9 oDugOYY3aHR0cDovL2NkcDEucGNhLmRmbi5kZS9nbG9iYWwtcm9vdC1jYS9wdWIvY3JsL2Nh Y3JsLmNybDA9oDugOYY3aHR0cDovL2NkcDIucGNhLmRmbi5kZS9nbG9iYWwtcm9vdC1jYS9w dWIvY3JsL2NhY3JsLmNybDCBogYIKwYBBQUHAQEEgZUwgZIwRwYIKwYBBQUHMAKGO2h0dHA6 Ly9jZHAxLnBjYS5kZm4uZGUvZ2xvYmFsLXJvb3QtY2EvcHViL2NhY2VydC9jYWNlcnQuY3J0 MEcGCCsGAQUFBzAChjtodHRwOi8vY2RwMi5wY2EuZGZuLmRlL2dsb2JhbC1yb290LWNhL3B1 Yi9jYWNlcnQvY2FjZXJ0LmNydDANBgkqhkiG9w0BAQUFAAOCAQEAbDEPnQ9JpouPHYA1OEek P3l3GNM0HBzadVbtbN5MDtFmoVgdLYqlQaHb30wFhuOMbsNCOzV0k8EOvBVOT9BiEJ70RWcl SZQ460jZS2MY6n5oG/ilZuu6N/N3GSLg2pBBNH9vZFCyBJ9n4Px7A4gQF07G+CNfV2jdE1yy PjzIVPhg6bBgia8nXroBFe6oteavMspo0gLGIJ63NsCbl6ckPa96grT+mnnQD0h6jk/IGtXS 09mEWRbN7zZu0x0q+SScpljG36Q+jnG0U5zQI0jAx8CcYEQQH5QOlsw1Zu35OI4lsi7ycFkz JNfbfEC4ihuw9J2L43BFGMojkhPkhVExHTCCBCEwggMJoAMCAQICAgDHMA0GCSqGSIb3DQEB BQUAMHExCzAJBgNVBAYTAkRFMRwwGgYDVQQKExNEZXV0c2NoZSBUZWxla29tIEFHMR8wHQYD VQQLExZULVRlbGVTZWMgVHJ1c3QgQ2VudGVyMSMwIQYDVQQDExpEZXV0c2NoZSBUZWxla29t IFJvb3QgQ0EgMjAeFw0wNjEyMTkxMDI5MDBaFw0xOTA2MzAyMzU5MDBaMFoxCzAJBgNVBAYT AkRFMRMwEQYDVQQKEwpERk4tVmVyZWluMRAwDgYDVQQLEwdERk4tUEtJMSQwIgYDVQQDExtE Rk4tVmVyZWluIFBDQSBHbG9iYWwgLSBHMDEwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEK AoIBAQDpm8NnhfkNrvWNVMOWUDU9YuluTO2U1wBblSJ01CDrNI/W7MAxBAuZgeKmFNJSoCgj hIt0iQReW+DieMF4yxbLKDU5ey2QRdDtoAB6fL9KDhsAw4bpXCsxEXsM84IkQ4wcOItqaACa 7txPeKvSxhObdq3u3ibo7wGvdA/BCaL2a869080UME/15eOkyGKbghoDJzANAmVgTe3RCSMq ljVYJ9N2xnG2kB3E7f81hn1vM7PbD8URwoqDoZRdQWvY0hD1TP3KUazZve+Sg7va64sWVlZD z+HVEz2mHycwzUlU28kTNJpxdcVs6qcLmPkhnSevPqM5OUhqjK3JmfvDEvK9AgMBAAGjgdkw gdYwcAYDVR0fBGkwZzBloGOgYYZfaHR0cDovL3BraS50ZWxlc2VjLmRlL2NnaS1iaW4vc2Vy dmljZS9hZl9Eb3dubG9hZEFSTC5jcmw/LWNybF9mb3JtYXQ9WF81MDkmLWlzc3Vlcj1EVF9S T09UX0NBXzIwHQYDVR0OBBYEFEm3xs/oPR9/6kR7Eyn38QpwPt5kMB8GA1UdIwQYMBaAFDHD eRu69VPXF+CJei0XbAqzK50zMA4GA1UdDwEB/wQEAwIBBjASBgNVHRMBAf8ECDAGAQH/AgEC MA0GCSqGSIb3DQEBBQUAA4IBAQA74Vp3wEgX3KkY7IGvWonwvSiSpspZGBJw7Cjy565/lizn 8l0ZMfYTK3S9vYCyufdnyTmieTvhERHua3iRM347XyYndVNljjNj7s9zw7CSI0khUHUjoR8Y 4pSFPT8z6XcgjaK95qGFKUD2P3MyWA0Ja6bahWzAP7uNZmRWJE6uDT8yNQFb6YyC2XJZT7GG hfF0hVblw/hc843uR7NTBXDn5U2KaYMo4RMJhp5eyOpYHgwf+aTUWgRo/Sg+iwK2WLX2oSw3 VwBnqyNojWOl75lrXP1LVvarQIc01BGSbOyHxQoLBzNytG8MHVQs2FHHzL8w00Ny8TK/jM5J Y6gA9/IcMYICIDCCAhwCAQEwgZkwgZAxCzAJBgNVBAYTAkRFMRgwFgYDVQQKEw9ORUMgRXVy b3BlIEx0ZC4xIDAeBgNVBAsTF05FQyBMYWJvcmF0b3JpZXMgRXVyb3BlMRIwEAYDVQQDEwlO RUNMQUItQ0ExMTAvBgkqhkiG9w0BCQEWInplcnRpZml6aWVydW5nc3N0ZWxsZUBudy5uZWNs YWIuZXUCBA0uKwcwCQYFKw4DAhoFAKBdMCMGCSqGSIb3DQEJBDEWBBQNp4Spl1SIUiZ6rRn5 63vpScpT1DAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xMDAy MTgwMTU0NDNaMA0GCSqGSIb3DQEBAQUABIIBAKwfM8nKkA6+4HdbYsyLKk7x5Nrv6B6w7FHw 28koQAOReowkL+e2uRosY7hKSkyWGDb6eI6ecqL/oxdgx6p65ebNkDnJHod4dpuTkocm4OmK RsHNaQh41fXrPYQ1LQT/i7K81QArVmbD5bOhLh/UsajQu+skSEBQ9c/r0R5kAuHLiFXpk8Nz sut6LyWBPiPwaLV09QAACbhBY8EsHbsJto5ZJjqvEuRxJnOKd8V3Ey4GdVbxwElPQcxTGPUZ O8Wiehi92HSEOC+lD2UxyX21IaS4p7euxCNRRCk/8ktWjvqvf723Ot/7Z0LAi4ghgqyn5E/G PdrCVa7MLKTHWJ+49Ss= --B_3349306483_8266410-- From kashima@nttv6.net Wed Feb 17 21:07:57 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 00ED63A75C8 for ; Wed, 17 Feb 2010 21:07:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_53=0.6, 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 tgYgVPNsH3GD for ; Wed, 17 Feb 2010 21:07:55 -0800 (PST) Received: from mail.nttv6.net (mail.nttv6.net [IPv6:2001:fa8::25]) by core3.amsl.com (Postfix) with ESMTP id 845193A6842 for ; Wed, 17 Feb 2010 21:07:54 -0800 (PST) Received: from [127.0.0.1] (localhost [IPv6:::1]) by mail.nttv6.net (8.14.3/8.14.3) with ESMTP id o1I595T4060467; Thu, 18 Feb 2010 14:09:07 +0900 (JST) (envelope-from kashima@nttv6.net) Date: Thu, 18 Feb 2010 14:07:00 +0900 From: Shingo KASHIMA To: "Dharani Vilwanathan (dharani)" In-Reply-To: References: Message-Id: <20100218135814.C821.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.3 (mail.nttv6.net [IPv6:::1]); Thu, 18 Feb 2010 14:09:07 +0900 (JST) Cc: ipfix@ietf.org Subject: Re: [IPFIX] Regarding draft-kashima-ipfix-data-link-layer-monitoring-01.txt X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Feb 2010 05:07:57 -0000 Hi Dharani, Thank you for your comments. Please see in-line. On Tue, 16 Feb 2010 10:52:45 -0800 "Dharani Vilwanathan (dharani)" san wrote: > Hi Kashima, > > This is regarding the document: > Data Link Layer Monitoring with IPFIX/PSAMP > http://tools.ietf.org/id/draft-kashima-ipfix-data-link-layer-monitoring- > 01.txt > > After some email exchanges with Ganesh Murthy and Paul Aitken, we > (Yaonan Liang, Laxmi Mukund and self) had a discussion on this document. > We would like to understand the document better and so we would like to > present our comments to you here: > > - There are many ethernet types mentioned in the document. But they > don't seem to be exhaustive. Some key things like 802.3, WiMax,etc seem > to be missing. Probably we can attempt to cover everything or just > provide a summary of various types with an explicit note. > > - The document seems to start straight with a couple of ethernet types. > It would be nice if we can start the document more smoothly from an > overall perspective. I would like to clarify this document goal. This document tries to propose simple information elements independent from ethernet type, also data link layer type. Section data including ethernet header (or other link layer header) and upper layer headers can be applied to all of ethernet type (or link layer protocol) We pick up examples, such as Q-in-Q and MAC-in-MAC, to have readers understand the issues we would face in near future when monitoring backbone bridge networks. We might come up with other examples. But, it does not mean to enumerate the list of ethernet type to be exhaustive. Even so, should we complete the list for ethernet types? > > - In section 2, we have: > > "This was because, at that time, the > PSAMP Working Group selected not standardization based on vague > requirements but standardization that was quickly completed." > > The sentence can probably be rephrased. In this sentence we just explain why the information elements ("dataLinkFrameSection" and "dataLinkFrameSize") have been deleted from , but this sentence might be removed in our final document. > > - We can probably add "as well" to the end of next paragraph so that it > reads like this: > > The following Information Elements are necessary for enabling the > above-mentioned method, which is not limited to Ethernet because the > method can be applied to other data link protocols as well. > <<<<---------- Thank you. In next draft, we would like to revise as your comment. > - It looks like there might be some refinements needed to make the > document more precise. Thank you. > > - Is this document an extension of RFC5477 (Info model for Packet > Sampling Exports) and should it actually be under PSAMP? And because > PSAMP working group seems to be no longer active, we are trying to fit > in this document in IPFIX? Because, if this document is really intended > for IPFIX, we should see how it co-exists with several fields defined by > Paul Aitken, Ganesh Murthy and Marco (please see > http://tools.ietf.org/id/draft-aitken-ipfix-new-infos-03.txt > content > of which got added to IANA database). But if the document is intended > for PSAMP, then we need to make sure it fits properly in IPFIX. Section data information element related to link layer had already been discussed in PSAMP WG, thus we put in PSAMP. But, I do not adhere the extension of PSAMP info. > > - Section 5.1: Only 3 types are defined. We may have to define rest of > the types. Sorry for the confusion, this is just example. In next draft, we would like to use IANAifType (http://www.iana.org/assignments/ianaiftype-mib). > > - Section 5.1: Any reason why the type is unsigned32? Why can't it be > just unsigned8? In next draft, we would like to use signed32. because MIB SYNTAX of IANAifType is "INTEGER". > Also, is it correct to say that dataLinkFrameSize is really the > datalink header length? No, dataLinkFrameSize is not heder length but frame length. In case of ethernet, dataLinkFrameSize means a length of from destination MAC address to FCS (end of a frame). > > - Section 5.2: Can the type be as low as needed? Like unsigned8 or > unsigned16? In next draft, we would like to revise to unsigned16. > > - Section 5.3: The following paragraph is not clear. It may need > rephrasing: > > "The data for this field MUST NOT be padded. If insufficient > octets are available for the length specified in the Template, > then a new Template MUST be used." It's my mistake. In next draft, we would like to revise as follows. "The data for this field MUST NOT be padded." > > Please pass your comments. > > Thanks > dharani > Regards, Shingo --- Shingo KASHIMA NTT Information Sharing Platform Lab. From wwwrun@core3.amsl.com Thu Feb 18 08:19:13 2010 Return-Path: X-Original-To: ipfix@ietf.org Delivered-To: ipfix@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 30) id 8DEFC3A7CEE; Thu, 18 Feb 2010 08:19:13 -0800 (PST) X-idtracker: yes To: IETF-Announce From: The IESG Message-Id: <20100218161913.8DEFC3A7CEE@core3.amsl.com> Date: Thu, 18 Feb 2010 08:19:13 -0800 (PST) Cc: ipfix@ietf.org Subject: [IPFIX] Last Call: draft-ietf-ipfix-export-per-sctp-stream (IPFIX Export per SCTP Stream) to Proposed Standard X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.9 Precedence: list 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: Thu, 18 Feb 2010 16:19:13 -0000 The IESG has received a request from the IP Flow Information Export WG (ipfix) to consider the following document: - 'IPFIX Export per SCTP Stream ' as a Proposed Standard 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-03-04. 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 http://www.ietf.org/internet-drafts/draft-ietf-ipfix-export-per-sctp-stream-06.txt IESG discussion can be tracked via https://datatracker.ietf.org/public/pidtracker.cgi?command=view_id&dTag=17394&rfc_flag=0 From braun@net.in.tum.de Fri Feb 19 04:11: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 21BBC28C1E9 for ; Fri, 19 Feb 2010 04:11:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.249 X-Spam-Level: X-Spam-Status: No, score=-2.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IPp7fuV8x-b4 for ; Fri, 19 Feb 2010 04:11:09 -0800 (PST) Received: from mail-out1.informatik.tu-muenchen.de (mail-out1.informatik.tu-muenchen.de [131.159.0.8]) by core3.amsl.com (Postfix) with ESMTP id 19C2528C1DB for ; Fri, 19 Feb 2010 04:11:08 -0800 (PST) Received: from honshu.net.in.tum.de (honshu.net.in.tum.de [131.159.20.100]) by mail.net.in.tum.de (Postfix) with ESMTPSA id 3604B200D3B1; Fri, 19 Feb 2010 13:12:53 +0100 (CET) Mime-Version: 1.0 (Apple Message framework v1077) Content-Type: text/plain; charset=iso-8859-1 From: Lothar Braun In-Reply-To: Date: Fri, 19 Feb 2010 13:12:52 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <4AD793E9-3463-43F1-8840-13BB6FF0B1E6@net.in.tum.de> References: To: Juergen Quittek X-Mailer: Apple Mail (2.1077) X-Virus-Scanned: ClamAV using ClamSMTP Cc: IETF IPFIX Working Group Subject: Re: [IPFIX] WG last call on draft-ietf-ipfix-configuration-model-04 X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Feb 2010 12:11:10 -0000 Dear Juergen, all, On Feb 18, 2010, at 2:54 AM, Juergen Quittek wrote: > There is still just one review for this draft. Brian is working > on a second review, but I want to see at least a third one before > closing the WGLC. >=20 > Would anyone be willing to add another review for this document? I will find some time to review the draft in the next days and should be able to send my review to the list within the next week. Best regards, Lothar -- Lothar Braun Chair for Network Architectures and Services (I8) Department of Informatics Technische Universit=E4t M=FCnchen Boltzmannstr. 3, 85748 Garching bei M=FCnchen, Germany Phone: +49 89 289-18010 Fax: +49 89 289-18033 E-mail: braun@net.in.tum.de=20 From andrjohn@cisco.com Fri Feb 19 07:49:16 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 3E25C3A7B6A for ; Fri, 19 Feb 2010 07:49:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.734 X-Spam-Level: X-Spam-Status: No, score=-0.734 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FRT_LOLITA1=1.865] 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 j2kHuZBAJY3k for ; Fri, 19 Feb 2010 07:49:13 -0800 (PST) Received: from ams-iport-2.cisco.com (ams-iport-2.cisco.com [144.254.224.141]) by core3.amsl.com (Postfix) with ESMTP id 3AD753A6BF8 for ; Fri, 19 Feb 2010 07:49:12 -0800 (PST) Authentication-Results: ams-iport-2.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AqQAADNCfkuQ/uCWe2dsb2JhbACbBxUBARYkBh2mLpd5hGcE X-IronPort-AV: E=Sophos;i="4.49,504,1262563200"; d="scan'208";a="3607225" Received: from ams-core-1.cisco.com ([144.254.224.150]) by ams-iport-2.cisco.com with ESMTP; 19 Feb 2010 15:19:12 +0000 Received: from cisco.com (mrwint.cisco.com [64.103.71.48]) by ams-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id o1JFovek008702; Fri, 19 Feb 2010 15:50:57 GMT Received: from [10.55.163.35] (ams-andrjohn-8712.cisco.com [10.55.163.35]) by cisco.com (8.11.7p3+Sun/8.8.8) with ESMTP id o1JFouX10777; Fri, 19 Feb 2010 15:50:56 GMT Message-ID: <4B7EB360.8060902@cisco.com> Date: Fri, 19 Feb 2010 15:50:56 +0000 From: Andrew Johnson User-Agent: Thunderbird 2.0.0.23 (X11/20090817) MIME-Version: 1.0 To: Juergen Quittek References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: IETF IPFIX Working Group Subject: [IPFIX] Review (was Re: WG last call on draft-ietf-ipfix-configuration-model-04) X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Feb 2010 15:49:16 -0000 One general comment: Why do only some of the UML fields have settings given> e.g. "direction = both" ======================================================================== Section 3: ======================================================================== If a Selection Process is part of a Metering Process and a single Selection Process can feed into more than one Cache, then it is implied that a single Metering Process can have more than once cache. I can see why it would be convenient to configure multiple caches to be populated from a single Selection Process, and it could even be implemented that way (to some extent), but that is not the PSAMP model. The configuration model doesn't have to exactly match this model, but you should ensure that the differences are made clear. ======================================================================== >From section 3.1: ======================================================================== Why have so many SCTP or UDP only options? Can't you use UML inheritance to do something like: +------------------------------------------------+ | Destination | +------------------------------------------------+ | name | | exportMemberType = parallel | | ipfixVersion = 10 | | transportProtocol | | destinationIpAddress | | destinationPort = 4739|4740 | | sendBufferSize {opt.} | | rateLimit[0..1] | +------------------------------------------------+ ^ | 1 +----+-------------------+ | | | +------------------------------------------------+ | | SCTP Destination | | +------------------------------------------------+ | | localIpAddress[0..*] {SCTP only} |<>-----+ | | timedReliability = 0 {SCTP only} | | 0..1 | | numberOfStreams {opt.} {SCTP only} | | | | sourceIpAddress[0..1] {UDP only} | +------------+ | | templateRefreshTimeout = 600 {UDP only} | | Transport- | | | optionsTemplateRefreshTimeout = 600 {UDP only} | | Layer- | | | templateRefreshPacket[0..1] {UDP only} | | Security | | | optionsTemplateRefreshPacket[0..1] {UDP only} | +------------+ | +------------------------------------------------+ | +---------------------+ | +------------------------------------------------+ | UDP Destination | +------------------------------------------------+ | sourceIpAddress[0..1] {UDP only} |<>-----+ | templateRefreshTimeout = 600 {UDP only} | | 0..1 | optionsTemplateRefreshTimeout = 600 {UDP only} | | | templateRefreshPacket[0..1] {UDP only} | +------------+ | optionsTemplateRefreshPacket[0..1] {UDP only} | | Transport- | +------------------------------------------------+ | Layer- | | Security | +------------+ Are there no options that are used with TCP? Are the security parameters the same across DTLS and TLS? ======================================================================== >From section 4.1: ======================================================================== Doesn't the direction belong in the Observation Point class, not the Interface or LC class. ======================================================================== >From Section 4.2.1 ======================================================================== Why packetsDropped and not packetsSelected, when PSAMP talks about packetsSelected in the stats it needs to export? ======================================================================== >From Section 4.3.1 ======================================================================== Isn't is possible to generate a cache without any keys? This would generate a cache with a single flow? Do we allow this? Would it be useful to have two lists, one for keys and one for non-keys? For a permanent cache, update counters should be used and for a timeout cache the delta counters should be used. Where is this sort of thing enforced? ======================================================================== >From Section 4.4.1 ======================================================================== exportMemberType: Configures the export member type that corresponds to the ipfixTransportSessionGroupMemberType object in [I-D.ietf-ipfix-mib]. The following parameter values are specified by the configuration data model: * primary: primary target of the Exporting Process * secondary: secondary target of the Exporting Process used when the primary target is not reachable * parallel: parallel exporting to all destinations and files of the Exporting Process * loadBalancing: load-balancing between different destinations and files of the Exporting Process "parallel" is the default value if this parameter is not configured. If one destination or file is configured as "primary" ------------------------------------------------------------------------ Comments ------------------------------------------------------------------------ It's not clear to me that this parameter belongs to the Destination class. The number of restrictions on when you can use the various types suggests that we could simplify things. A Cache can pass flow records to multiple Exporting Processes, so we don't really need a parallel option. This would mean that each Exporting Process is responsible for sending one complete set of records. i.e. one record in, one record out. It could do that, either using a redundancy model or with a load-balancing one. In other words, the exportType would be an Exporting Process attribute which would indicate whether the list of Destinations should be load- balanced across or treated as Primary, Seondary, Tertiary, etc. ======================================================================== >From Section 4.7: TransportSession class ======================================================================== I think you want to add a timestamp for when the session came up and when it went down (unless it's still active). There's no association with the relevant destination. It seems to me that your really want this as part of each Destination or FileReader. Specifically, I think you want to separate the Transport Session from the File Reader stats. Potentially there could be a one to many relationship of Destination and Transport Sessions, each with their own timestamp for coming up and going down. From root@core3.amsl.com Tue Feb 23 03: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 D40FD28C124; Tue, 23 Feb 2010 03:45:02 -0800 (PST) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20100223114502.D40FD28C124@core3.amsl.com> Date: Tue, 23 Feb 2010 03:45:02 -0800 (PST) Cc: ipfix@ietf.org Subject: [IPFIX] I-D Action:draft-ietf-ipfix-mediators-problem-statement-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, 23 Feb 2010 11:45: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 : IPFIX Mediation: Problem Statement Author(s) : A. Kobayashi, et al. Filename : draft-ietf-ipfix-mediators-problem-statement-08.txt Pages : 29 Date : 2010-02-23 Flow-based measurement is a popular method for various network monitoring usages. The sharing of flow-based information for monitoring applications having different requirements raises some open issues in terms of measurement system scalability, flow-based measurement flexibility, and export reliability that IPFIX Mediation may help resolve. This document describes some problems related to flow-based measurement that network administrators have been facing, and then describes IPFIX Mediation applicability examples along with the problems. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ipfix-mediators-problem-statement-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-mediators-problem-statement-08.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2010-02-23034335.I-D@ietf.org> --NextPart-- From paitken@cisco.com Thu Feb 25 15:37: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 4825B3A8731 for ; Thu, 25 Feb 2010 15:37:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uhzO5S0Fnkug for ; Thu, 25 Feb 2010 15:37:43 -0800 (PST) Received: from ams-iport-2.cisco.com (ams-iport-2.cisco.com [144.254.224.141]) by core3.amsl.com (Postfix) with ESMTP id 98E443A8407 for ; Thu, 25 Feb 2010 15:37:42 -0800 (PST) Authentication-Results: ams-iport-2.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: At0AAKeYhkuQ/uCWe2dsb2JhbACbFxUBARYkBhykQ5hlAoJSgiEE X-IronPort-AV: E=Sophos;i="4.49,542,1262563200"; d="scan'208";a="3794529" Received: from ams-core-1.cisco.com ([144.254.224.150]) by ams-iport-2.cisco.com with ESMTP; 25 Feb 2010 23:07:39 +0000 Received: from [10.55.84.40] (dhcp-10-55-84-40.cisco.com [10.55.84.40]) by ams-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id o1PNdrja016312; Thu, 25 Feb 2010 23:39:53 GMT Message-ID: <4B870A49.6000608@cisco.com> Date: Thu, 25 Feb 2010 23:39:53 +0000 From: Paul Aitken User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-GB; rv:1.8.1.22) Gecko/20090605 SeaMonkey/1.1.17 (Ubuntu-1.1.17+nobinonly-0ubuntu0.9.04.1) MIME-Version: 1.0 To: "Romascanu, Dan (Dan)" References: <4AD6E120.50002@cisco.com> <4AD6EAF4.9040303@net.in.tum.de> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: ipfix@ietf.org Subject: Re: [IPFIX] Mistake in PSAMP RFCs: Selector ID length 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, 25 Feb 2010 23:37:44 -0000 Dan, As you will have seen, I just opened errata 2052 - 2059 for this. Thanks, P. > It looks like two errata on RFC 5478 and 5477 should be issues. > I suggest that one of you takes the pen to enter the errata texts, > and when they are ready and have reached consensus I can approve them. > > Dan > > >> -----Original Message----- >> From: ipfix-bounces@ietf.org [mailto:ipfix-bounces@ietf.org] >> On Behalf Of Brian Trammell >> Sent: Thursday, October 15, 2009 11:41 AM >> To: Gerhard Muenz >> Cc: psamp; ipfix@ietf.org >> Subject: Re: [IPFIX] Mistake in PSAMP RFCs: Selector ID length >> >> hi Benoit, Gerhard, >> >> I agree with the change to 64 bit, to keep it in line with >> every other protocol-level identifier (save odID, bound by >> the header format to 32 bits), with the understanding that >> RLE will often be used to use it as >> 32 bit. >> >> However, in this case we might want as well to update 5476 >> with a line noting that all the examples use RLE. >> >> Best regards, >> >> Brian >> >> On Oct 15, 2009, at 11:27 AM, Gerhard Muenz wrote: >> >>> Benoit, >>> >>> Benoit Claise wrote: >>>> Dear all, >>>> We found a mistake in the PSAMP RFCs. >>>> RFC5477 >>>> 8.1.2. selectorId >>>> Description: >>>> The Selector ID is the unique ID identifying a Primitive Selector. >>>> Each Primitive Selector must have a unique ID in the Observation >>>> Domain. >>>> Abstract Data Type: unsigned16 <------------------ >>>> Data Type Semantics: identifier >>>> ElementId: 302 >>>> Status: current >>>> RFC5476, the selectorID length is 4 bytes in ALL examples (and there are many). >>>> >>>> IPFIX Options Template Record: >>>> 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 >>>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >>>> | Set ID = 3 | Length = 26 | >>>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >>>> | Template ID = 262 | Field Count = 4 | >>>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >>>> | Scope Field Count = 1 |0| selectionSequenceId = 301 | >>>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >>>> | Scope 1 Length = 4 |0| ingressInterface = 10 | >>>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >>>> | Field Length = 4 |0| selectorId = 302 | >>>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >>>> | Field Length = 4 |0| selectorId = 302 | >>>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >>>> | Field Length = 4 | >>>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >>>> >>>> The proposed solution is to >>>> increase the Selector ID length and put an ERRATA on RFC5477. >>>> 16 bits is definitely not enough and clearly not was intended. >>>> Since we can do reduced length encoding with larger identifiers, we >>>> don't see any harm in making all identifiers 64 bit Feedback? >>> 4 Bytes = 32 Bit >>> >>> You propose to increase it to 64 (=8 Byte), which means that both RFCs >>> need to be corrected. Or is 64 a mistake? >>> >>> Regards, >>> Gerhard >>> >>>> Regards, Benoit. >>>> ------------------------------------------------------------------------ >>>> _______________________________________________ >>>> IPFIX mailing list >>>> IPFIX@ietf.org >>>> https://www.ietf.org/mailman/listinfo/ipfix >>> -- >>> Dipl.-Ing. Gerhard Münz >>> Chair for Network Architectures and Services (I8) Technische >>> Universität München - Department of Informatics Boltzmannstr. 3, 85748 >>> Garching bei München, Germany >>> Phone: +49 89 289-18008 Fax: +49 89 289-18033 >>> E-mail: muenz@net.in.tum.de WWW: http://www.net.in.tum.de/~muenz >>> >>> _______________________________________________ >>> 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 >> > _______________________________________________ > IPFIX mailing list > IPFIX@ietf.org > https://www.ietf.org/mailman/listinfo/ipfix -- Paul Aitken Cisco Systems Ltd, Edinburgh, Scotland. From n.brownlee@auckland.ac.nz Thu Feb 25 20:11: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 6EEBF28C2C7 for ; Thu, 25 Feb 2010 20:11:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4CDbLOI5Qq3D for ; Thu, 25 Feb 2010 20:11:18 -0800 (PST) Received: from mailhost.auckland.ac.nz (larry.its.auckland.ac.nz [130.216.12.34]) by core3.amsl.com (Postfix) with ESMTP id 0B9F128C210 for ; Thu, 25 Feb 2010 20:11:16 -0800 (PST) Received: from localhost (localhost.localdomain [127.0.0.1]) by mailhost.auckland.ac.nz (Postfix) with ESMTP id 7AC331A1F7 for ; Fri, 26 Feb 2010 17:13:28 +1300 (NZDT) X-Virus-Scanned: by amavisd-new at mailhost.auckland.ac.nz Received: from mailhost.auckland.ac.nz ([127.0.0.1]) by localhost (larry.its.auckland.ac.nz [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id R-PmRBF8Xz-t for ; Fri, 26 Feb 2010 17:13:28 +1300 (NZDT) Received: from nevil-laptop.sfac.auckland.ac.nz (nevil-laptop.sfac.auckland.ac.nz [130.216.38.130]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailhost.auckland.ac.nz (Postfix) with ESMTP id 5C30F1A1E3 for ; Fri, 26 Feb 2010 17:13:28 +1300 (NZDT) Message-ID: <4B874A68.2040606@auckland.ac.nz> Date: Fri, 26 Feb 2010 17:13:28 +1300 From: Nevil Brownlee User-Agent: Thunderbird 2.0.0.12 (Macintosh/20080213) MIME-Version: 1.0 To: IPFIX Working Group Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [IPFIX] DRAFT agenda for IETF in Anaheim 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, 26 Feb 2010 04:11:19 -0000 Hi all: My first attempt at an agenda for our IPFIX session at IETF 77 in Anaheim is available at http://www.ietf.org/proceedings/10mar/agenda/ipfix.txt Please send me any comments/suggestions/requests for time slots. 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 akoba@nttv6.net Thu Feb 25 20:45: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 5078428C4E4 for ; Thu, 25 Feb 2010 20:45:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.308 X-Spam-Level: X-Spam-Status: No, score=-1.308 tagged_above=-999 required=5 tests=[AWL=0.880, BAYES_00=-2.599, HOST_MISMATCH_COM=0.311, RDNS_DYNAMIC=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XV4JOkOv1Q6Y for ; Thu, 25 Feb 2010 20:45:46 -0800 (PST) Received: from mail.nttv6.net (mail.nttv6.net [IPv6:2001:fa8::25]) by core3.amsl.com (Postfix) with ESMTP id 0445828C4DD for ; Thu, 25 Feb 2010 20:45:45 -0800 (PST) Received: from [127.0.0.1] (dhcp-3-152.nttv6.com [192.47.163.152]) by mail.nttv6.net (8.14.3/8.14.3) with ESMTP id o1Q4lqcQ023342; Fri, 26 Feb 2010 13:47:53 +0900 (JST) (envelope-from akoba@nttv6.net) Date: Fri, 26 Feb 2010 13:43:18 +0900 From: Atsushi Kobayashi To: Nevil Brownlee In-Reply-To: <4B874A68.2040606@auckland.ac.nz> References: <4B874A68.2040606@auckland.ac.nz> Message-Id: <20100226132551.405B.17391CF2@nttv6.net> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Becky! ver. 2.50.05 [ja] (Unregistered) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.3 (mail.nttv6.net [192.16.178.5]); Fri, 26 Feb 2010 13:47:53 +0900 (JST) Cc: IPFIX Working Group Subject: Re: [IPFIX] DRAFT agenda for IETF in Anaheim 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, 26 Feb 2010 04:45:47 -0000 Hi Nevil, and all, We are preparing the next version draft of new information element for link layer monitoring. http://tools.ietf.org/id/draft-kashima-ipfix-data-link-layer-monitoring-01.txt In last meeting, we discussed how to progress it furthermore. Please see minute of last meeting. New Drafts Data-link Layer Monitoring, Shingo Kashima. Proposes to make 3 new IEs? dataLinkFrameType - why not use ifType (from RMON) for values. Juergen says "since Ethernet is so common, this should be documented in an RFC." Could be an Independent Submission. Dan agrees we need a more detailed draft, discussed on WG. Nevil will send some comments to the authors. I and Kashima-san would like to have 5 or 10 minutes to present the update in IPFIX WG. But, I am not sure how to progress it. Should it be presented at another working group, or independent submission? Will you give me any suggestion about it? Regards, Atsushi On Fri, 26 Feb 2010 17:13:28 +1300 Nevil Brownlee wrote: > > Hi all: > > My first attempt at an agenda for our IPFIX session at IETF 77 > in Anaheim is available at > > http://www.ietf.org/proceedings/10mar/agenda/ipfix.txt > > Please send me any comments/suggestions/requests for time slots. > > 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 > --- Atsushi KOBAYASHI NTT Information Sharing Platform Lab. tel:+81-(0)422-59-3978 fax:+81-(0)422-59-5637 From muenz@net.in.tum.de Fri Feb 26 02:00: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 3A74528C10C for ; Fri, 26 Feb 2010 02:00:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.249 X-Spam-Level: X-Spam-Status: No, score=-2.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3Ek8EXxKwW+5 for ; Fri, 26 Feb 2010 02:00:22 -0800 (PST) Received: from mail-out1.informatik.tu-muenchen.de (mail-out1.informatik.tu-muenchen.de [131.159.0.8]) by core3.amsl.com (Postfix) with ESMTP id B498028C132 for ; Fri, 26 Feb 2010 02:00:21 -0800 (PST) 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 25F2F20C4214; Fri, 26 Feb 2010 11:02:27 +0100 (CET) Message-ID: <4B879C38.4080100@net.in.tum.de> Date: Fri, 26 Feb 2010 11:02:32 +0100 From: Gerhard Muenz User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Paul Aitken References: <4AD6E120.50002@cisco.com> <4AD6EAF4.9040303@net.in.tum.de> <4B870A49.6000608@cisco.com> In-Reply-To: <4B870A49.6000608@cisco.com> Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms080801050507080309010904" X-Virus-Scanned: ClamAV using ClamSMTP Cc: ipfix@ietf.org Subject: Re: [IPFIX] Mistake in PSAMP RFCs: Selector ID length 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, 26 Feb 2010 10:00:23 -0000 This is a cryptographically signed message in MIME format. --------------ms080801050507080309010904 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable Dear all, IMO, the distinction between "protocol-level" and other identifiers is=20 quite arbitrary. Most identifiers are currently unsigned32: http://www.iana.org/assignments/ipfix/ipfix.xhtml If we change selectorId to unsigned32, it would be consistent other=20 identifiers and with IPFIX-MIB, where we have: ipfixSelectionProcessSelectorIndex Unsigned32 However, if you want to change it to unsigned64, why shouldn't we change = observationPointId etc. as well? And what about ipfixSelectionProcessSelectorIndex? The IPFIX-MIB does not say that ipfixSelectionProcessSelectorIndex =3D=3D selectorId, yet this would be an obvious implementation. These are just some thoughts about possible consequences, which does not = mean that I do not like unsigned64 in general. Regards, Gerhard Paul Aitken wrote: > Dan, >=20 > As you will have seen, I just opened errata 2052 - 2059 for this. >=20 > Thanks, > P. >=20 >=20 >> It looks like two errata on RFC 5478 and 5477 should be issues. >> I suggest that one of you takes the pen to enter the errata texts, >> and when they are ready and have reached consensus I can approve them.= =20 >> >> Dan >> =20 >> >>> -----Original Message----- >>> From: ipfix-bounces@ietf.org [mailto:ipfix-bounces@ietf.org]=20 >>> On Behalf Of Brian Trammell >>> Sent: Thursday, October 15, 2009 11:41 AM >>> To: Gerhard Muenz >>> Cc: psamp; ipfix@ietf.org >>> Subject: Re: [IPFIX] Mistake in PSAMP RFCs: Selector ID length >>> >>> hi Benoit, Gerhard, >>> >>> I agree with the change to 64 bit, to keep it in line with=20 >>> every other protocol-level identifier (save odID, bound by=20 >>> the header format to 32 bits), with the understanding that=20 >>> RLE will often be used to use it as >>> 32 bit. >>> >>> However, in this case we might want as well to update 5476=20 >>> with a line noting that all the examples use RLE. >>> >>> Best regards, >>> >>> Brian >>> >>> On Oct 15, 2009, at 11:27 AM, Gerhard Muenz wrote: >>> >>>> Benoit, >>>> >>>> Benoit Claise wrote: >>>>> Dear all, >>>>> We found a mistake in the PSAMP RFCs. >>>>> RFC5477 >>>>> 8.1.2. selectorId >>>>> Description: >>>>> The Selector ID is the unique ID identifying a Primitive S= elector. >>>>> Each Primitive Selector must have a unique ID in the Obser= vation >>>>> Domain. >>>>> Abstract Data Type: unsigned16 <----------= -------- >>>>> Data Type Semantics: identifier >>>>> ElementId: 302 >>>>> Status: current >>>>> RFC5476, the selectorID length is 4 bytes in ALL examples (and= there are many). >>>>> >>>>> IPFIX Options Template Record: >>>>> 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 >>>>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-= +-+ >>>>> | Set ID =3D 3 | Length =3D 26 = | >>>>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-= +-+ >>>>> | Template ID =3D 262 | Field Count =3D 4 = | >>>>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-= +-+ >>>>> | Scope Field Count =3D 1 |0| selectionSequenceId =3D= 301 | >>>>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-= +-+ >>>>> | Scope 1 Length =3D 4 |0| ingressInterface =3D= 10 | >>>>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-= +-+ >>>>> | Field Length =3D 4 |0| selectorId =3D 302 = | >>>>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-= +-+ >>>>> | Field Length =3D 4 |0| selectorId =3D 302 = | >>>>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-= +-+ >>>>> | Field Length =3D 4 | >>>>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >>>>> >>>>> The proposed solution is to=20 >>>>> increase the Selector ID length and put an ERRATA on RFC5477. >>>>> 16 bits is definitely not enough and clearly not was intended. =20 >>>>> Since we can do reduced length encoding with larger identifiers, we= =20 >>>>> don't see any harm in making all identifiers 64 bit Feedback? >>>> 4 Bytes =3D 32 Bit >>>> >>>> You propose to increase it to 64 (=3D8 Byte), which means that both = RFCs=20 >>>> need to be corrected. Or is 64 a mistake? >>>> >>>> Regards, >>>> Gerhard >>>> >>>>> Regards, Benoit. >>>>> -------------------------------------------------------------------= ----- >>>>> _______________________________________________ >>>>> IPFIX mailing list >>>>> IPFIX@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/ipfix >>>> -- >>>> Dipl.-Ing. Gerhard M=FCnz >>>> Chair for Network Architectures and Services (I8) Technische=20 >>>> Universit=E4t M=FCnchen - Department of Informatics Boltzmannstr. 3,= 85748=20 >>>> Garching bei M=FCnchen, Germany >>>> Phone: +49 89 289-18008 Fax: +49 89 289-18033 >>>> E-mail: muenz@net.in.tum.de WWW: http://www.net.in.tum.de/~muenz >>>> >>>> _______________________________________________ >>>> IPFIX mailing list >>>> IPFIX@ietf.org >>>> https://www.ietf.org/mailman/listinfo/ipfix >>> _______________________________________________ >>> 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 >=20 >=20 --=20 Dipl.-Ing. Gerhard M=FCnz Chair for Network Architectures and Services (I8) Technische Universit=E4t M=FCnchen - Department of Informatics Boltzmannstr. 3, 85748 Garching bei M=FCnchen, Germany Phone: +49 89 289-18008 Fax: +49 89 289-18033 E-mail: muenz@net.in.tum.de WWW: http://www.net.in.tum.de/~muenz --------------ms080801050507080309010904 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 9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTEwMDIyNjEwMDIzMlowIwYJKoZIhvcNAQkEMRYEFANO eHnhLEgnKAwYh7fY9qKzeWSdMF8GCSqGSIb3DQEJDzFSMFAwCwYJYIZIAWUDBAECMAoGCCqG SIb3DQMHMA4GCCqGSIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG 9w0DAgIBKDCCAQMGCSsGAQQBgjcQBDGB9TCB8jCB3TELMAkGA1UEBhMCVVMxFzAVBgNVBAoT DlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTswOQYD VQQLEzJUZXJtcyBvZiB1c2UgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYSAoYykw NTEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5WZXJpU2lnbiBD bGFzcyAxIEluZGl2aWR1YWwgU3Vic2NyaWJlciBDQSAtIEcyAhBdJGHZVTceRNanJsbp+SK7 MIIBBQYLKoZIhvcNAQkQAgsxgfWggfIwgd0xCzAJBgNVBAYTAlVTMRcwFQYDVQQKEw5WZXJp U2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazE7MDkGA1UECxMy VGVybXMgb2YgdXNlIGF0IGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9ycGEgKGMpMDUxHjAc BgNVBAsTFVBlcnNvbmEgTm90IFZhbGlkYXRlZDE3MDUGA1UEAxMuVmVyaVNpZ24gQ2xhc3Mg MSBJbmRpdmlkdWFsIFN1YnNjcmliZXIgQ0EgLSBHMgIQXSRh2VU3HkTWpybG6fkiuzANBgkq hkiG9w0BAQEFAASCAQBuA1VAdk7JdrvyFPu8Y1w/nXUguzvTzuSRFFRIH9ITBlktMzX+HbF+ sDYs5uSFulOTucAgLkDOXfpEp8fLtI+dSC2GfUGQ/YWUjD0i38Ss8ug3AC5TtydzsJqpUTek XwDUiBJVaoL85il8DwkfWvct9QdKjvZpgRUyyD7XJtHYFNcaBcKpTfEMQm8xmA/9Ki8smvZA lg4Ng+q7jvTvbcsCiFAep3LFhOunx+ka+XSq9krVtPtdpUjxHq9LYoN4x9o8ftlNDApAXHzz +ghpCH2KoMORrTYNBVfTDG+vzcb32k5WFnZkwyuZQDSR/Pnuix8VEZsek/6s7Q9hpwUYlAiY AAAAAAAA --------------ms080801050507080309010904-- From boschie@tik.ee.ethz.ch Fri Feb 26 02:58: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 E6C5D3A832E for ; Fri, 26 Feb 2010 02:58:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.597 X-Spam-Level: X-Spam-Status: No, score=-6.597 tagged_above=-999 required=5 tests=[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 wJUhsnIfIcty for ; Fri, 26 Feb 2010 02:58:35 -0800 (PST) Received: from smtp.ee.ethz.ch (smtp.ee.ethz.ch [129.132.2.219]) by core3.amsl.com (Postfix) with ESMTP id BF40F3A86DD for ; Fri, 26 Feb 2010 02:58:35 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by smtp.ee.ethz.ch (Postfix) with ESMTP id 51595D938F; Fri, 26 Feb 2010 12:00:48 +0100 (MET) X-Virus-Scanned: by amavisd-new on smtp.ee.ethz.ch Received: from smtp.ee.ethz.ch ([127.0.0.1]) by localhost (.ee.ethz.ch [127.0.0.1]) (amavisd-new, port 10024) with LMTP id HeKquUL-t5V2; Fri, 26 Feb 2010 12:00:48 +0100 (MET) Received: from Ely.local (unknown [213.188.207.187]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: boschie) by smtp.ee.ethz.ch (Postfix) with ESMTPSA id A88E9D930B; Fri, 26 Feb 2010 12:00:47 +0100 (MET) Message-ID: <4B87A9DE.1030902@tik.ee.ethz.ch> Date: Fri, 26 Feb 2010 12:00:46 +0100 From: Elisa Boschi User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-GB; rv:1.9.1.7) Gecko/20100111 Thunderbird/3.0.1 MIME-Version: 1.0 To: ipfix-chairs@tools.ietf.org Content-Type: multipart/mixed; boundary="------------060603030402070203010202" Cc: ipfix@ietf.org Subject: [IPFIX] Fwd: I-D Action:draft-ietf-ipfix-anon-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, 26 Feb 2010 10:58:37 -0000 This is a multi-part message in MIME format. --------------060603030402070203010202 Content-Type: multipart/alternative; boundary="------------040601020609040308070405" --------------040601020609040308070405 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Nevil, Jürgen, as you've seen we've submitted a new revision of the anonymisation draft. The changes are relatively minor and address all remaining open issues and comments received so far. At this point we think we're ready for Working Group Last Call. In order to take advantage of the upcoming meeting we suggest starting WG last call soon so that we can discuss last call comments during the anon draft agenda slot. thanks, Elisa & Brian -------- Original Message -------- Subject: [IPFIX] I-D Action:draft-ietf-ipfix-anon-02.txt Date: Mon, 15 Feb 2010 04:00:01 -0800 (PST) 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 : IP Flow Anonymisation Support Author(s) : E. Boschi, B. Trammell Filename : draft-ietf-ipfix-anon-02.txt Pages : 37 Date : 2010-02-15 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 technique 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-02.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. --------------040601020609040308070405 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Nevil, Jürgen,

as you've seen we've submitted a new revision of the anonymisation draft. The changes are relatively minor and address all remaining open issues and comments received so far. At this point we think we're ready for Working Group Last Call. In order to take advantage of the upcoming meeting we suggest starting WG last call soon so that we can discuss last call comments during the anon draft agenda slot.

thanks,
Elisa & Brian

-------- Original Message --------
Subject: [IPFIX] I-D Action:draft-ietf-ipfix-anon-02.txt
Date: Mon, 15 Feb 2010 04:00:01 -0800 (PST)
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           : IP Flow Anonymisation Support
	Author(s)       : E. Boschi, B. Trammell
	Filename        : draft-ietf-ipfix-anon-02.txt
	Pages           : 37
	Date            : 2010-02-15

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 technique 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-02.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.
--------------040601020609040308070405-- --------------060603030402070203010202 Content-Type: Message/External-body; name="draft-ietf-ipfix-anon-02.txt" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="draft-ietf-ipfix-anon-02.txt" Content-Type: text/plain Content-ID: <2010-02-15034627.I-D@ietf.org> --------------060603030402070203010202 Content-Type: text/plain; name="Attached Message Part" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="Attached Message Part" _______________________________________________ IPFIX mailing list IPFIX@ietf.org https://www.ietf.org/mailman/listinfo/ipfix --------------060603030402070203010202-- From braun@net.in.tum.de Fri Feb 26 05:37: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 069CF28C0FC for ; Fri, 26 Feb 2010 05:37:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.249 X-Spam-Level: X-Spam-Status: No, score=-3.249 tagged_above=-999 required=5 tests=[AWL=1.000, BAYES_00=-2.599, GB_I_LETTER=-2, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2GQkgF7Fyxqq for ; Fri, 26 Feb 2010 05:37:44 -0800 (PST) Received: from mail-out1.informatik.tu-muenchen.de (mail-out1.informatik.tu-muenchen.de [131.159.0.8]) by core3.amsl.com (Postfix) with ESMTP id 9F7C93A84BA for ; Fri, 26 Feb 2010 05:37:43 -0800 (PST) Received: from honshu.net.in.tum.de (honshu.net.in.tum.de [131.159.20.100]) by mail.net.in.tum.de (Postfix) with ESMTPSA id 97A172110231 for ; Fri, 26 Feb 2010 14:39:40 +0100 (CET) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Apple Message framework v1077) From: Lothar Braun In-Reply-To: <4AD793E9-3463-43F1-8840-13BB6FF0B1E6@net.in.tum.de> Date: Fri, 26 Feb 2010 14:39:40 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <33C32EC7-A6D6-4238-B376-3F91FA3B74D4@net.in.tum.de> References: <4AD793E9-3463-43F1-8840-13BB6FF0B1E6@net.in.tum.de> To: IETF IPFIX Working Group X-Mailer: Apple Mail (2.1077) X-Virus-Scanned: ClamAV using ClamSMTP Subject: Re: [IPFIX] WG last call on draft-ietf-ipfix-configuration-model-04 X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Feb 2010 13:37:46 -0000 Hi all, please find my comments inline. Best regards, Lothar > IP Flow Information Export WG G. = Muenz > Internet-Draft TU = Muenchen > Intended status: Standards Track B. = Claise > Expires: April 26, 2010 P. = Aitken > Cisco Systems, = Inc. > October 23, = 2009 >=20 >=20 > Configuration Data Model for IPFIX and PSAMP > >=20 > 2. Terminology >=20 > This document adopts the terminologies used in [RFC5101], > [I-D.ietf-ipfix-file], and [RFC5476]. As in these documents, all > specific terms have the first letter of a word capitalized when = used > in this document. The following listing indicates in which > references the definitions of those terms that are commonly used > throughout this document can be found: >=20 >=20 >=20 >=20 >=20 >=20 > Muenz, et al. draft-ietf-ipfix-configuration-model-04.txt [Page = 6] > Internet-Draft IPFIX/PSAMP Configuration Data Model October = 2009 >=20 >=20 > o Definitions adopted from [RFC5101]: > * Collection Process > * Collector > * Data Record > * Exporter > * Flow Record > * Information Element > * IPFIX Device > * IPFIX Message > * Observation Domain > * Observation Point > * (Options) Template >=20 > o Definitions adopted from [I-D.ietf-ipfix-file]: > * File Reader > * File Writer >=20 > o Definitions adopted from [RFC5476]: > * Filtering > * Observed Packet Stream > * Packet Report > * PSAMP Device > * Sampling > * Selection Process > * Selection Sequence > * Selection Sequence Report Interpretation > * Selector, Primitive Selector, Composite Selector You might want to add the term "Flow Keys" somewhere to this lists. > The terms Metering Process and Exporting Process have different > definitions in [RFC5101] and [RFC5476]. In the scope of this > document, these terms are used according to the following = definitions > which cover the deployment in both PSAMP Devices and IPFIX Devices: > Cache: The Cache is a functional block in a Metering Process which > maintains IPFIX Flow Records or PSAMP Packet Reports. According > to [RFC5101], the maintenance of Flow Records may include = creating > new records, updating existing ones, computing Flow statistics, > deriving further Flow properties, detecting Flow expiration, > passing Flow Records to the Exporting Process, and deleting Flow > Records. The maintenance of Packet Reports covers the same set = of > functions. > =20 > Cache Layout: The Cache Layout defines the superset of fields that > are included in the Packet Reports or Flow Records maintained by > the Cache. The fields are specified by the corresponding > Information Elements. In general, the largest possible subset = of > the specified fields is derived for every Packet Report or Flow > Record. More specific rules about which fields must be included > are given in Section 4.3.1. >=20 > Cache Mode: The Cache Mode specifies whether Packet Reports or = Flow > Records are generated by the Cache. In the case of Flow = Records, > it also specifies the Flow expiration policy. >=20 I had some difficulties to understand the definition of the Cache. I = could not understand what the packet cache does when generating PSAMP = Packet Reports. It was clear after reading Section 4.3 when the Cache = Modes are explained. Maybe there could be some text that explains that = maintaining Packet Reports and Flow Records is the same task except that = Packet Records expire after the first packet.=20 Could there be an example for a Cache? >=20 > +-----------------------------------+ > | Metering Process | > | +-----------+ Selected | > Observed | | Selection | Packet +-------+ | Stream of > Packet -->| Process |---------->| Cache |--> Flow Records or > Stream | +-----------+ Stream +-------+ | Packet Reports > +-----------------------------------+ >=20 > Figure 1: Selection Process and Cache forming a Metering Process >=20 > The configuration data model adopts the separation of Selection > Processes and Caches in order to support the flexible configuration > and combination of these functional blocks. As defined in = [RFC5476], > the Selection Process takes the Observed Packet Stream as its input > and selects a subset of that stream as its output (Selected Packet > Stream). The action of the Selection Process on a single packet of > its input is defined by a Primitive Selector or a Composite = Selector. > The Cache generates Flow Records or Packet Reports from the = Selected > Packet Stream, depending on the configured Cache Mode. >=20 > The Observed Packet Stream at the input of a Selection Process MUST > only contain packets originating from a single Observation Domain. > Similarly, the Selected Packet Stream at the input of a Cache MUST > only contain packets originating from a single Observation Domain. > Packets from Observation Points belonging to different Observation > Domains MUST NOT enter the same Selection Process or the same = Cache. When I read this, I had the feeling that this text does poses some = restriction on how I am able to configure my monitor. But it seems like = this corresponds to the definition of an Observation Domain: Observation Domain An Observation Domain is the largest set of Observation Points for which Flow information can be aggregated by a Metering Process. ...=20 Is there some further restriction that I miss? > 3.2. Exporter Configuration >=20 > Figure 4 below shows the main classes of the configuration data = model > which are involved in the configuration of an IPFIX or PSAMP > Exporter. The role of the classes can be briefly summarized as > follows: >=20 > o The ObservationPoint class specifies an Observation Point (i.e., > an interface or linecard) of the Monitoring Device at which > packets are captured for traffic measurements. An object of the > ObservationPoint class may be associated with one or more = objects > of the SelectionProcess class configuring Selection Processes = that > process the observed packets in parallel. As long as an > ObservationPoint object is specified without any references to > SelectionProcess objects, the Observation Point is not deployed > for traffic measurements. >=20 > o The SelectionProcess class contains the configuration parameters > of a Selection Process. The Selection Process may be composed = of > a single Selector or a sequence of Selectors, defining a = Primitive > or Composite Selector, respectively. >=20 > The Selection Process selects packets from an Observed Packet > Stream originating from one or multiple Observation Points. Could you please introduce the selectAll policy of the SelectionProcess = at this point? When I read this, I was wondering why I cannot connect an Observation = Point directly to a Cache, if I do not want to sample or filter packets. >=20 > 4.1. ObservationPoint Class >=20 > +-------------------------------+ > | ObservationPoint | > +-------------------------------+ 1 = +--------------------+ > | name |<>----------| Interface/Linecard = | > | observationPointId {readOnly} | = +--------------------+ > | observationDomainId | > | | 0..* 0..* = +--------------------+ > | |----------->| SelectionProcess = | > +-------------------------------+ = +--------------------+ >=20 > +------------------+ +----------------------------------+ > | Interface | | Linecard | > +------------------+ +----------------------------------+ > | ifIndex/ifName | | entPhysicalIndex/entPhysicalName | > | direction =3D both | | direction =3D both | > +------------------+ +----------------------------------+ >=20 > Figure 6: ObservationPoint class >=20 Both, the Interface and the Linecard, contain the "direction". Is there = a reason why it is not a part of the Observation Point if it has to be = specified in both cases? >=20 >=20 > 4.3.1. CacheLayout Class >=20 > +--------------+ > | CacheLayout | > +--------------+ 1..* +--------------------------+ > | |<>------| CacheField | > | | +--------------------------+ > | | | name | > | | | ieId/ieName | > | | | ieLength {opt.} | > | | | ieEnterpriseNumber[0..1] | > | | | isFlowKey[0..1] | > +--------------+ +--------------------------+ >=20 > Figure 12: CacheLayout class >=20 > A Cache generates and maintains Packet Reports or Flow Records > containing information that has been extracted from the incoming > stream of packets. Using the CacheField class, the CacheLayout = class > specifies the superset of fields that are included in the Packet > Reports or Flow Records (see Figure 12). >=20 > If Packet Reports are generated (i.e., if Cache Mode is = "immediate"), > every field specified by the Cache Layout MUST be included in the > resulting Packet Report unless the corresponding Information = Element > is not applicable or cannot be derived from the content or = treatment > of the incoming packet. Could you give an example for "not applicable or cannot be derived = from"? Maybe something like when a source port needs to be extracted = from an ICMP packet. > If Flow Records are generated (i.e., if Cache Mode is "timeout" or > "permanent"), every Flow Key field specified by the Cache Layout = MUST > be included as Flow Key in the resulting Flow Record unless the > corresponding Information Element is not applicable or cannot be > derived from the content or treatment of the incoming packet. Two > packets MUST be accounted by different Flow Records if different > subsets of the Flow Key fields are applicable or derivable. I do not understand this. What do you mean with "different subsets of = the Flow Key fields". Is it maybe: "Two packets MUST be accounted by different Flow Records if = they differ in at least one Flow Key field." > ieId, ieName, ieEnterpriseNumber: These parameters specify a field > by the combination of the Information Element identifier or = name, > and the Information Element enterprise number. Either ieId or > ieName MUST be specified. ieEnterpriseNumber MUST be used for > enterprise-specific Information Elements. If ieEnterpriseNumber > is omitted or zero, this is Information Element is not = enterprise- > specific but registered at IANA. If I want to configure a custom non-IANA field using the Enterprise ID = 1. The field should have the ieID 1. What do I have to configure. Do I = need to configure ieID 1, ieEnterpriseNumber 1 or do I need to give ieID = 32768 (the first bit if the id field) and ieEnterpriseNumber 1? So my question is: Is the enterprise Bit set by the user or is it done = by the monitor if he sees the ieEnterpriseNumber field? > ieLength: This parameter specifies the length of the field in > octets. A value of 65535 means that the field is encoded as > variable-length Information Element. For Information Elements = of > integer and float type, the field length MAY be set to a smaller > value than the standard length of the abstract data type if the > rules of reduced size encoding are fulfilled (see [RFC5101], > Section 6.2). If not configured by the user, the field length = is > set by the Monitoring Device. The monitoring device can set the length field if it nows the ID (either = IANA or known custom ID). But what if the monitor does not know a = specific ID? Should there be a default value (which one?) for unknown = IDs or should the device reject such a configuration? I think the device should reject the configuration. > 4.4.3. Options Class >=20 > +-----------------------+ > | Options | > +-----------------------+ > | name | > | optionsType | > | optionsTimeout {opt.} | > +-----------------------+ >=20 > Figure 16: Options class >=20 > The Options class in Figure 16 defines the type of specific > information to be reported, such as statistics, flow keys, Sampling > and Filtering parameters etc. [RFC5101] and [RFC5476] specify > several types of reporting information which may be exported. The > following parameter values are specified by the configuration data > model: >=20 > meteringStatistics: Export of Metering Process statistics using = the > Metering Process Statistics Options Template [RFC5101]. >=20 > meteringReliability: Export of Metering Process reliability > statistics using the Metering Process Reliability Statistics > Options Template [RFC5101]. >=20 > exportingReliability: Export of Exporting Process reliability > statistics using the Exporting Process Reliability Statistics > Options Template [RFC5101]. >=20 > flowKeys: Export of the Flow Key specification using the Flow Keys > Options Template [RFC5101]. >=20 > selectionSequence: Export of Selection Sequence Report > Interpretation and Selector Report Interpretation [RFC5476]. >=20 > selectionStatistics: Export of Selection Sequence Statistics = Report > Interpretation [RFC5476]. >=20 > accuracy: Export of Accuracy Report Interpretation [RFC5476]. >=20 > reducingRedundancy: Export of common properties according to > [RFC5473]. >=20 > The Exporting Process MUST choose a template definition according = to > the options type and available options data. > 7.3. Export of Flow Records and Packet Reports >=20 > This configuration example demonstrates the combined export of Flow > Records and Packet Reports for a single Observation Point. A > Selection Process (Selection Sequence ID =3D 1) applies random = Sampling > to the stream of observed packets. The output is passed to a Cache > generating Flow Records. In parallel, the output is passed to a > second Selection Process (Selection Sequence ID =3D 2) which = discards > all non-ICMP packets. A second Cache generates Packet Reports of = the > retained ICMP packets. The output of both caches is exported to a > single Collector using SCTP. >=20 > >=20 > > OP at linecard 3 > 9876 > > 4 > ingress > > Sampling > >=20 > > Sampling > 1 > > Random sampler > 1 > > 0.01 > > > ICMP > Flow cache > >=20 > > ICMP > 2 > > ICMP filter >=20 >=20 >=20 > Muenz, et al. draft-ietf-ipfix-configuration-model-04.txt [Page = 84] > Internet-Draft IPFIX/PSAMP Configuration Data Model October = 2009 >=20 >=20 > 2 > > 4 > 1 > > > Packet cache > >=20 > > Flow cache > timeout > 4096 > 5 > 10 > > > Field 1 > sourceIPv4Address > > > > Field 2 > destinationIPv4Address > > > > Field 6 > flowStartMilliSeconds > > > Field 7 > flowEndSeconds > > > Field 8 > octetDeltaCount > > > Field 9 > packetDeltaCount > > > Export > >=20 > > Packet cache >=20 >=20 >=20 > Muenz, et al. draft-ietf-ipfix-configuration-model-04.txt [Page = 85] > Internet-Draft IPFIX/PSAMP Configuration Data Model October = 2009 >=20 >=20 > immediate > 512 > > > Field 1 > 313 > 64 > > > Field 2 > 154 > > > Export > >=20 > > Export > > SCTP collector > sctp > 192.0.2.1 > 0 > 2 > > >=20 > >=20 > The Observed Packet Stream at the input of the Selection Process > "ICMP" originates from the Selection Process "Sampling", which thus > constitutes a pseudo Observation Point. In order to inform the > Collector about the cascaded Selection Processes, the Exporting > Process exports two Selection Sequence Report Interpretations as > defined in [RFC5476], section 6.5.1, including the following = fields: Shouldn't there be something like in the exportingProcess configuration? > Selection Process "Sampling": >=20 > Scope: selectionSequenceId =3D 1 > Non-scope: ingressInterface =3D 4 > selectorId =3D 1 >=20 >=20 > Selection Process "ICMP": >=20 > Scope: selectionSequenceId =3D 2 > Non-scope: selectionSequenceId =3D 1 > selectorId =3D 2 >=20 >=20 >=20 > Muenz, et al. draft-ietf-ipfix-configuration-model-04.txt [Page = 86] > Internet-Draft IPFIX/PSAMP Configuration Data Model October = 2009 >=20 >=20 > One possibility to link the Selection Sequence Report = Interpretation > of Selection Process "Sampling" to the Flow Record generated by the > Cache named "Flow cache" is to include a field selectionSequenceId = =3D > 1 to each Data Record. Similarly, the Selection Sequence Report > Interpretation of Selection Process "ICMP" can be linked to the > Packet Reports generated by the Cache named "Packet cache" by > including a field selectionSequenceId =3D 2 to each Data Record. >=20 > The following modifications lead to a similar but not identical > configuration of the Monitoring Device: >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 > Muenz, et al. draft-ietf-ipfix-configuration-model-04.txt [Page = 87] > Internet-Draft IPFIX/PSAMP Configuration Data Model October = 2009 >=20 >=20 > ... > > OP at linecard 3 > > 3 > > Sampling > Sampled ICMP packets > > ... > > Sampling > > Random sampler > > 0.01 > > > Flow cache > >=20 > > Sampled ICMP packets > > Random sampler > > 0.01 > > > > ICMP filter > > 4 > 1 > > > Packet cache > > ... >=20 > In this case, the random sampler is implemented in two different > Selection Processes, leading to different sets of selected packets. > As a consequence, the set of packets accounted in the Flow Cache is > not identical to the set of packets from which the ICMP Packet > Reports are generated. >=20 >=20 >=20 >=20 >=20 >=20 > Muenz, et al. draft-ietf-ipfix-configuration-model-04.txt [Page = 88] > Internet-Draft IPFIX/PSAMP Configuration Data Model October = 2009 >=20 >=20 > 7.4. Collector and File Writer >=20 > This configuration example configures a Collector which writes the > received data to a file. >=20 > >=20 > > SCTP collector > > Listening port 4739 > sctp > 192.0.2.1 > 4739 > 64 > > File writer > >=20 > > File writer > > Write to /tmp folder > primary > file://tmp/collected-records.ipfix > > >=20 > >=20 -- Lothar Braun Chair for Network Architectures and Services (I8) Department of Informatics Technische Universit=E4t M=FCnchen Boltzmannstr. 3, 85748 Garching bei M=FCnchen, Germany Phone: +49 89 289-18010 Fax: +49 89 289-18033 E-mail: braun@net.in.tum.de=20 From dromasca@avaya.com Sun Feb 28 06: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 4EEAB3A832E for ; Sun, 28 Feb 2010 06:22:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.001 X-Spam-Level: X-Spam-Status: No, score=0.001 tagged_above=-999 required=5 tests=[BAYES_50=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 eJlcdxyghf+M for ; Sun, 28 Feb 2010 06:22:51 -0800 (PST) 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 D62A33A84BA for ; Sun, 28 Feb 2010 06:22:50 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.49,555,1262581200"; d="scan'208";a="178320327" Received: from unknown (HELO co300216-co-erhwest.avaya.com) ([198.152.7.5]) by de307622-de-outbound.net.avaya.com with ESMTP; 28 Feb 2010 09:22:48 -0500 X-IronPort-AV: E=Sophos;i="4.49,555,1262581200"; d="scan'208";a="450513709" Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.15]) by co300216-co-erhwest-out.avaya.com with ESMTP; 28 Feb 2010 09:22:47 -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: Sun, 28 Feb 2010 15:22:25 +0100 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Editorial Errata Reported] RFC5476 (2053) Thread-Index: Acq2ciGIdojgiFkDRiCxVbb1sILQWgCDqUVA From: "Romascanu, Dan (Dan)" To: Subject: [IPFIX] FW: [Editorial Errata Reported] RFC5476 (2053) 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, 28 Feb 2010 14:22:52 -0000 =20 IPFIX WG, Please provide your advice on the resolution of this Errata and the following six errata (in total seven numbered 2053 to 2059, all Editorial) submitted for RFC 5476.=20 Regards, Dan -----Original Message----- From: RFC Errata System [mailto:rfc-editor@rfc-editor.org]=20 Sent: Friday, February 26, 2010 1:28 AM To: bclaise@cisco.com; andrjohn@cisco.com; quittek@nw.neclab.eu; Romascanu, Dan (Dan); rbonica@juniper.net; quittek@netlab.nec.de Cc: paitken@cisco.com; psamp@ietf.org; rfc-editor@rfc-editor.org Subject: [Editorial Errata Reported] RFC5476 (2053) The following errata report has been submitted for RFC5476, "Packet Sampling (PSAMP) Protocol Specifications". -------------------------------------- You may review the report below and at: http://www.rfc-editor.org/errata_search.php?rfc=3D5476&eid=3D2053 -------------------------------------- Type: Editorial Reported by: Paul Aitken Section: 6.5.1. Original Text ------------- Notes: * There are two Records here in the same Data Set. Each record defines a different Selection Sequence. * If, for example, a different Selection Sequence is composed of three Selectors, then a different Options Template with three selectorId Information Elements (instead of two) must be used. Corrected Text -------------- Notes: * There are two Records here in the same Data Set. Each record defines a different Selection Sequence. * If, for example, a different Selection Sequence is composed of three Selectors, then a different Options Template with three selectorId Information Elements (instead of two) must be used. * IPFIX Reduced Size Encoding [RFC5101] has been used for the selectorId fields. Notes ----- Addition of "Reduced Size Encoding" note per Errata ID 2052. NB "fields" is plural in this example only. Instructions: ------------- This errata 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.=20 -------------------------------------- RFC5476 (draft-ietf-psamp-protocol-09) -------------------------------------- Title : Packet Sampling (PSAMP) Protocol Specifications Publication Date : March 2009 Author(s) : B. Claise, Ed., A. Johnson, J. Quittek Category : PROPOSED STANDARD Source : Packet Sampling Area : Operations and Management Stream : IETF Verifying Party : IESG From dromasca@avaya.com Sun Feb 28 06:48: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 9018628C146 for ; Sun, 28 Feb 2010 06:48:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.949 X-Spam-Level: X-Spam-Status: No, score=-1.949 tagged_above=-999 required=5 tests=[AWL=0.650, 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 TPJuF6dXgnGs for ; Sun, 28 Feb 2010 06:48:09 -0800 (PST) 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 9897E3A897E for ; Sun, 28 Feb 2010 06:48:09 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.49,555,1262581200"; d="scan'208";a="5556847" 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; 28 Feb 2010 09:48:09 -0500 X-IronPort-AV: E=Sophos;i="4.49,555,1262581200"; d="scan'208";a="436619058" Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.15]) by p-us1-erheast-out.us1.avaya.com with ESMTP; 28 Feb 2010 09:47:33 -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: Sun, 28 Feb 2010 15:47:12 +0100 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Technical Errata Reported] RFC5477 (2052) Thread-Index: Acq2cpsdd4PygArmRdK3fzy2fnaRLQCEjNFQ From: "Romascanu, Dan (Dan)" To: Subject: [IPFIX] FW: [Technical Errata Reported] RFC5477 (2052) 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, 28 Feb 2010 14:48:10 -0000 =20 This one is Technical!=20 WG members, please suggest a resolution. Thanks and Regards, Dan -----Original Message----- From: Paul Aitken [mailto:paitken@cisco.com]=20 Sent: Friday, February 26, 2010 1:31 AM To: RFC Errata System Cc: Thomas.Dietz@nw.neclab.eu; bclaise@cisco.com; dressler@informatik.uni-erlangen.de; carle@informatik.uni-tuebingen.de; Romascanu, Dan (Dan); rbonica@juniper.net; quittek@netlab.nec.de; psamp@ietf.org Subject: Re: [Technical Errata Reported] RFC5477 (2052) Errata errata, sigh. See inline... RFC Errata System wrote: > The following errata report has been submitted for RFC5477,=20 > "Information Model for Packet Sampling Exports". >=20 > -------------------------------------- > You may review the report below and at: > http://www.rfc-editor.org/errata_search.php?rfc=3D5477&eid=3D2052 >=20 > -------------------------------------- > Type: Technical > Reported by: Paul Aitken >=20 > Section: 8.1.2 >=20 > Original Text > ------------- > Abstract Data Type: unsigned16 >=20 > Corrected Text > -------------- > Abstract Data Type: unsigned32 "unsigned64". P. >=20 > Notes > ----- > Change selectorID from 16 bits to 64 bits per discussion on the IPFIX mailing list: >=20 >=20 >=20 > http://www.ietf.org/mail-archive/web/ipfix/current/msg05133.html >=20 > Instructions: > ------------- > This errata is currently posted as "Reported". If necessary, please=20 > use "Reply All" to discuss whether it should be verified or rejected.=20 > When a decision is reached, the verifying party (IESG) can log in to=20 > change the status and edit the report, if necessary. >=20 > -------------------------------------- > RFC5477 (draft-ietf-psamp-info-11) > -------------------------------------- > Title : Information Model for Packet Sampling Exports > Publication Date : March 2009 > Author(s) : T. Dietz, B. Claise, P. Aitken, F. Dressler, G. Carle > Category : PROPOSED STANDARD > Source : Packet Sampling > Area : Operations and Management > Stream : IETF > Verifying Party : IESG -- Paul Aitken Cisco Systems Ltd, Edinburgh, Scotland.