From n.brownlee@auckland.ac.nz Sun Feb 6 14:28:57 2011 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 AD86F3A6B0A for ; Sun, 6 Feb 2011 14:28:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.999 X-Spam-Level: X-Spam-Status: No, score=-100.999 tagged_above=-999 required=5 tests=[BAYES_50=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EDsWsOed120y for ; Sun, 6 Feb 2011 14:28:56 -0800 (PST) Received: from mx2-int.auckland.ac.nz (mx2-int.auckland.ac.nz [130.216.12.41]) by core3.amsl.com (Postfix) with ESMTP id 2A4003A6A3C for ; Sun, 6 Feb 2011 14:28:55 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=auckland.ac.nz; i=n.brownlee@auckland.ac.nz; q=dns/txt; s=uoa; t=1297031339; x=1328567339; h=message-id:date:from:mime-version:to:subject: content-transfer-encoding; z=Message-ID:=20<4D4F20A2.2050102@auckland.ac.nz>|Date:=20 Mon,=2007=20Feb=202011=2011:28:50=20+1300|From:=20Nevil =20Brownlee=20|MIME-Version: =201.0|To:=20IPFIX=20Working=20Group=20 |Subject:=20I=20need=20some=20reviews/comments=20on=20=20 draft-ietf-ipfix-structured-data-04.txt |Content-Transfer-Encoding:=207bit; bh=UG4weIPdQ7pRfftppyMgyUWuqFUl5qykdKdmzCUYnbo=; b=OaF+SBtRZP/iwoSMjAFIeKMnGim0eTbSgZpdYAASGA5wkjkNiNd/AHV2 paAaMG+xIYkxYYewKMpq6oGj3KoTLObeB6VBwfaMJZyQhdnmQdAlqPDrO wbCtEj5N2vOjRsy9FhDtoT+kZHLs+K/fIzLIhKdBy3D6FJ2TWs9bsUQ/m E=; X-IronPort-AV: E=Sophos;i="4.60,434,1291546800"; d="scan'208";a="45074601" X-Ironport-HAT: UNIVERSITY - $RELAY-THROTTLE X-Ironport-Source: 130.216.38.131 - Outgoing - Outgoing-SSL Received: from nevil-laptop1.sfac.auckland.ac.nz (HELO [130.216.38.131]) ([130.216.38.131]) by mx2-int.auckland.ac.nz with ESMTP; 07 Feb 2011 11:28:50 +1300 Message-ID: <4D4F20A2.2050102@auckland.ac.nz> Date: Mon, 07 Feb 2011 11:28:50 +1300 From: Nevil Brownlee User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.13) Gecko/20101207 Lightning/1.0b2 Thunderbird/3.1.7 MIME-Version: 1.0 To: IPFIX Working Group Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [IPFIX] I need some reviews/comments on draft-ietf-ipfix-structured-data-04.txt X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 06 Feb 2011 22:28:57 -0000 Hi all: I'm writing the shepherd document for draft-ietf-ipfix-structured-data-04.txt However, I'm surprised to find that as far as I can see, no-one has posted a review of it to the IPFIX list. Please can I have a few (brief) reviews to the list now! 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 n.brownlee@auckland.ac.nz Sun Feb 6 15:17:35 2011 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 C3C983A6B12 for ; Sun, 6 Feb 2011 15:17:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.092 X-Spam-Level: X-Spam-Status: No, score=-101.092 tagged_above=-999 required=5 tests=[AWL=0.093, BAYES_40=-0.185, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RaDq+Q62uXDZ for ; Sun, 6 Feb 2011 15:17:34 -0800 (PST) Received: from mx2-int.auckland.ac.nz (mx2-int.auckland.ac.nz [130.216.12.41]) by core3.amsl.com (Postfix) with ESMTP id B0BBA3A6A3C for ; Sun, 6 Feb 2011 15:17:33 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=auckland.ac.nz; i=n.brownlee@auckland.ac.nz; q=dns/txt; s=uoa; t=1297034257; x=1328570257; h=message-id:date:from:mime-version:to:cc:subject; z=Message-ID:=20<4D4F2C06.9070606@auckland.ac.nz>|Date:=20 Mon,=2007=20Feb=202011=2012:17:26=20+1300|From:=20Nevil =20Brownlee=20|MIME-Version: =201.0|To:=20"Romascanu,=20Dan=20(Dan)"=20|CC:=20draft-ietf-ipfix-structured-data@tools.ietf.o rg,=20=0D=0A=20IPFIX=20Working=20Group=20 |Subject:=20Shepherd=20doc=20for:=20=20draft-ietf-ipfix-s tructured-data; bh=Yc5aBZ3qpkxTiKySE5uxs1YHIHAcqwPzvaf1F5emjuo=; b=euVQj+IsyLTObOYZ7qaLOqsUyeFuw2zDmvdj8Fc/C8m2z5Wq/GlpB2P/ 7uJpMhji51vbzkTZ46eEVTglozziCSUteuqynbG7giwHZUUoXpPPvZdk1 Oj5f8MjpWkmg5lnIsb12pcEoOBrYeYINVesIHEWD6LP8Krb/+qQQKTXor s=; X-IronPort-AV: E=Sophos;i="4.60,435,1291546800"; d="scan'208";a="45085689" X-Ironport-HAT: UNIVERSITY - $RELAY-THROTTLE X-Ironport-Source: 130.216.38.131 - Outgoing - Outgoing-SSL Received: from nevil-laptop1.sfac.auckland.ac.nz (HELO [130.216.38.131]) ([130.216.38.131]) by mx2-int.auckland.ac.nz with ESMTP; 07 Feb 2011 12:17:27 +1300 Message-ID: <4D4F2C06.9070606@auckland.ac.nz> Date: Mon, 07 Feb 2011 12:17:26 +1300 From: Nevil Brownlee User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.13) Gecko/20101207 Lightning/1.0b2 Thunderbird/3.1.7 MIME-Version: 1.0 To: "Romascanu, Dan (Dan)" Content-Type: multipart/mixed; boundary="------------080706000005080909020203" Cc: IPFIX Working Group , draft-ietf-ipfix-structured-data@tools.ietf.org Subject: [IPFIX] Shepherd doc for: draft-ietf-ipfix-structured-data X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 06 Feb 2011 23:17:35 -0000 This is a multi-part message in MIME format. --------------080706000005080909020203 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Hi Dan: Here is the shepherd document for draft-ietf-ipfix-structured-data-04.txt Would you please submit it to IESG for approval and publication as a Standards Track RFC. Cheers, Nevil (IPFIX Co-chair) -- --------------------------------------------------------------------- Nevil Brownlee Computer Science Department | ITS Phone: +64 9 373 7599 x88941 The University of Auckland FAX: +64 9 373 7453 Private Bag 92019, Auckland 1142, New Zealand --------------080706000005080909020203 Content-Type: text/plain; x-mac-type="0"; x-mac-creator="0"; name="ipfix-structured-data.shepherd" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="ipfix-structured-data.shepherd" Shepherd Document for draft-ietf-ipfix-structured-data-04.txt (1.a) Who is the Document Shepherd for this document? Has the Document Shepherd personally reviewed this version of the document and, in particular, does he or she believe this version is ready for forwarding to the IESG for publication? Nevil Brownlee. I have reviewed this draft, I believe it's ready for publication. (1.b) Has the document had adequate review both from key WG members and from key non-WG members? Does the Document Shepherd have any concerns about the depth or breadth of the reviews that have been performed? Yes. It was developed over the last two years, and has had extensive discussion on the IPFIX list. I have no concerns about its reviews. (1.c) Does the Document Shepherd have concerns that the document needs more review from a particular or broader perspective, e.g., security, operational complexity, someone familiar with AAA, internationalization or XML? No. This is a Standards Track document describing extensions to the IPFIX Information Model (RFC 5102), and the implications of these extensions for the IPFIX Protocol (RFC 5101). It should not impact any other areas. (1.d) Does the Document Shepherd have any specific concerns or issues with this document that the Responsible Area Director and/or the IESG should be aware of? For example, perhaps he or she is uncomfortable with certain parts of the document, or has concerns whether there really is a need for it. In any event, if the WG has discussed those issues and has indicated that it still wishes to advance the document, detail those concerns here. Has an IPR disclosure related to this document been filed? If so, please include a reference to the disclosure and summarize the WG discussion and conclusion on this issue. I regard this draft as a necessary and important step forward for IPFIX. No IPR disclosure has been made for this draft. (1.e) How solid is the WG consensus behind this document? Does it represent the strong concurrence of a few individuals, with others being silent, or does the WG as a whole understand and agree with it? The WG has reached full consensus on this draft. (1.f) Has anyone threatened an appeal or otherwise indicated extreme discontent? If so, please summarise the areas of conflict in separate email messages to the Responsible Area Director. (It should be in a separate email because this questionnaire is entered into the ID Tracker.) No. (1.g) Has the Document Shepherd personally verified that the document satisfies all ID nits? (See the Internet-Drafts Checklist and http://tools.ietf.org/tools/idnits/). Boilerplate checks are not enough; this check needs to be thorough. Has the document met all formal review criteria it needs to, such as the MIB Doctor, media type and URI type reviews? Yes. The checker finds no issues with this draft. (1.h) Has the document split its references into normative and informative? Are there normative references to documents that are not ready for advancement or are otherwise in an unclear state? If such normative references exist, what is the strategy for their completion? Are there normative references that are downward references, as described in [RFC3967]? If so, list these downward references to support the Area Director in the Last Call procedure for them [RFC3967]. Yes. All the normative references are to RFCs, there are no downward references. (1.i) Has the Document Shepherd verified that the document IANA consideration section exists and is consistent with the body of the document? If the document specifies protocol extensions, are reservations requested in appropriate IANA registries? Are the IANA registries clearly identified? If the document creates a new registry, does it define the proposed initial contents of the registry and an allocation procedure for future registrations? Does it suggest a reasonable name for the new registry? See [RFC5226]. If the document describes an Expert Review process has Shepherd conferred with the Responsible Area Director so that the IESG can appoint the needed Expert during the IESG Evaluation? Yes. The draft "specifies several new IPFIX abstract data types, a new IPFIX Data Type Semantic, and several new Information Elements. These require the creation of two new IPFIX registries and updating the existing IPFIX Information Element registry." These requirements are clearly explained. (1.j) Has the Document Shepherd verified that sections of the document that are written in a formal language, such as XML code, BNF rules, MIB definitions, etc., validate correctly in an automated checker? There are no sections written in a formal language. (1.k) The IESG approval announcement includes a Document Announcement Write-Up. Please provide such a Document Announcement Write-Up? Recent examples can be found in the "Action" announcements for approved documents. The approval announcement contains the following sections: Technical Summary This document specifies an extension to the IP Flow Information eXport (IPFIX) protocol specification in [RFC5101] and the IPFIX information model specified in [RFC5102] to support hierarchical structured data and lists (sequences) of Information Elements in data records. This extension allows definition of complex data structures such as variable-length lists and specification of hierarchical containment relationships between Templates. Finally, the semantics are provided in order to express the relationship among multiple list elements in a structured data record. Working Group Summary Work on this draft began in March 2009. Its development has had strong co-operative work from WG members in Europe, Japan and elsewhere. Its WG Last Call generated enough comments that we ran a second WGLC, this version represents the WG consensus. Document Quality Are there existing implementations of the protocol? Have a significant number of vendors indicated their plan to implement the specification? Are there any reviewers that merit special mention as having done a thorough review, e.g., one that resulted in important changes or a conclusion that the document had no substantive issues? If there was a MIB Doctor, Media Type or other expert review, what was its course (briefly)? In the case of a Media Type review, on what date was the request posted? I'm not aware of any current implementations, but the list discussion makes me think that they do exist. There has been so much list discussion of this draft that I can't really single out any particular reviewer. Nevil Brownlee 8 Feb 11 --------------080706000005080909020203-- From acmorton@att.com Sun Feb 13 07:06:13 2011 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 23C183A6C05; Sun, 13 Feb 2011 07:06:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.796 X-Spam-Level: X-Spam-Status: No, score=-105.796 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MSGID_FROM_MTA_HEADER=0.803, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5zJCT-PPiVOl; Sun, 13 Feb 2011 07:06:12 -0800 (PST) Received: from mail129.messagelabs.com (mail129.messagelabs.com [216.82.250.147]) by core3.amsl.com (Postfix) with ESMTP id 3DD0C3A6BFF; Sun, 13 Feb 2011 07:06:11 -0800 (PST) X-VirusChecked: Checked X-Env-Sender: acmorton@att.com X-Msg-Ref: server-7.tower-129.messagelabs.com!1297609591!38658868!1 X-StarScan-Version: 6.2.9; banners=-,-,- X-Originating-IP: [144.160.20.145] Received: (qmail 14394 invoked from network); 13 Feb 2011 15:06:32 -0000 Received: from sbcsmtp6.sbc.com (HELO mlpd192.enaf.sfdc.sbc.com) (144.160.20.145) by server-7.tower-129.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 13 Feb 2011 15:06:32 -0000 Received: from enaf.sfdc.sbc.com (localhost.localdomain [127.0.0.1]) by mlpd192.enaf.sfdc.sbc.com (8.14.4/8.14.4) with ESMTP id p1DF6saf009213; Sun, 13 Feb 2011 10:06:54 -0500 Received: from alpd052.aldc.att.com (alpd052.aldc.att.com [130.8.42.31]) by mlpd192.enaf.sfdc.sbc.com (8.14.4/8.14.4) with ESMTP id p1DF6m6n009181; Sun, 13 Feb 2011 10:06:48 -0500 Received: from aldc.att.com (localhost.localdomain [127.0.0.1]) by alpd052.aldc.att.com (8.14.4/8.14.4) with ESMTP id p1DF6OrU024633; Sun, 13 Feb 2011 10:06:24 -0500 Received: from dns.maillennium.att.com (dns.maillennium.att.com [135.25.114.99]) by alpd052.aldc.att.com (8.14.4/8.14.4) with ESMTP id p1DF6Kgc024578; Sun, 13 Feb 2011 10:06:20 -0500 Message-Id: <201102131506.p1DF6Kgc024578@alpd052.aldc.att.com> Received: from acmt.att.com (vpn-135-70-193-246.vpn.east.att.com[135.70.193.246](misconfigured sender)) by maillennium.att.com (mailgw1) with SMTP id <20110213150619gw100e4lvqe>; Sun, 13 Feb 2011 15:06:20 +0000 X-Originating-IP: [135.70.193.246] X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Sun, 13 Feb 2011 10:06:54 -0500 To: bmwg@ietf.org From: Al Morton Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Mailman-Approved-At: Sun, 13 Feb 2011 09:44:20 -0800 Cc: ipfix@ietf.org Subject: [IPFIX] WGLC: draft-ietf-bmwg-ipflow-meth-00 X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 13 Feb 2011 15:06:13 -0000 BMWG, CC: IPFIX WG, This message begins the first WG Last call on the draft: IP Flow Information Accounting and Export Benchmarking Methodology draft-ietf-bmwg-ipflow-meth-00.txt A URL for this draft is: http://tools.ietf.org/html/draft-ietf-bmwg-ipflow-meth-00 The Last Call will end on March 14, 2011. Although this is the first WGLC, we have discussed this draft in the working group for over two years, and made many suggestions. We have also benefited from review by folks from IPFIX WG. I now ask folks to consider items where they commented earlier, and make sure that the resolutions are satisfactory. And it's not too late to read the draft for the first time, and provide comments based on your review. Please weigh-in on whether or not this Internet-Draft should be given to the Area Directors and IESG for consideration and publication as an Informational RFC. Send your comments to this list and/or acmorton@att.com. Al bmwg chair From muenz@net.in.tum.de Sun Feb 13 13:04:34 2011 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 2670F3A6AFD for ; Sun, 13 Feb 2011 13:04:34 -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 OabFL0iCbm1K for ; Sun, 13 Feb 2011 13:04:33 -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 47A753A6AEC for ; Sun, 13 Feb 2011 13:04:32 -0800 (PST) Received: from [192.168.1.151] (ppp-93-104-92-142.dynamic.mnet-online.de [93.104.92.142]) by mail.net.in.tum.de (Postfix) with ESMTPSA id A99D1200AAC9; Sun, 13 Feb 2011 22:04:49 +0100 (CET) Message-ID: <4D58472E.6050804@net.in.tum.de> Date: Sun, 13 Feb 2011 22:03:42 +0100 From: Gerhard Muenz User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: IETF IPFIX Working Group References: <4D5570B1.2070901@cisco.com> In-Reply-To: <4D5570B1.2070901@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [IPFIX] I need some reviews/comments on draft-ietf-ipfix-structured-data-04.txt X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 13 Feb 2011 21:04:34 -0000 Hi all, I briefly scanned the changes in -04. As far as I can see, all comments of my -02 review have been addressed. So, I'm fine with the document. Cheers, Gerhard > > Hi all: > > I'm writing the shepherd document for > draft-ietf-ipfix-structured-data-04.txt > However, I'm surprised to find that as far as I can see, no-one has > posted a review of it to the IPFIX list. > Please can I have a few (brief) reviews to the list now! > > Cheers, Nevil > From peter.phaal@inmon.com Sun Feb 13 14:04:05 2011 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 DAEF43A6C32; Sun, 13 Feb 2011 14:04:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-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 T+7zg4y-zs9q; Sun, 13 Feb 2011 14:04:04 -0800 (PST) Received: from mail-pw0-f44.google.com (mail-pw0-f44.google.com [209.85.160.44]) by core3.amsl.com (Postfix) with ESMTP id 9782B3A6A31; Sun, 13 Feb 2011 14:04:04 -0800 (PST) Received: by pwi7 with SMTP id 7so1047960pwi.31 for ; Sun, 13 Feb 2011 14:04:25 -0800 (PST) Received: by 10.143.17.13 with SMTP id u13mr2522788wfi.269.1297634665620; Sun, 13 Feb 2011 14:04:25 -0800 (PST) Received: from [10.1.1.60] (adsl-75-37-23-164.dsl.pltn13.sbcglobal.net [75.37.23.164]) by mx.google.com with ESMTPS id v19sm3175231wfh.0.2011.02.13.14.04.24 (version=TLSv1/SSLv3 cipher=OTHER); Sun, 13 Feb 2011 14:04:24 -0800 (PST) Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii From: Peter Phaal In-Reply-To: <201102131506.p1DF6Kgc024578@alpd052.aldc.att.com> Date: Sun, 13 Feb 2011 14:04:22 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <0486FD12-14F9-4223-8C23-BE5AE0ED3892@inmon.com> References: <201102131506.p1DF6Kgc024578@alpd052.aldc.att.com> To: Al Morton X-Mailer: Apple Mail (2.1082) X-Mailman-Approved-At: Sun, 13 Feb 2011 14:07:19 -0800 Cc: ipfix@ietf.org, bmwg@ietf.org Subject: Re: [IPFIX] WGLC: draft-ietf-bmwg-ipflow-meth-00 X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 13 Feb 2011 22:05:40 -0000 Hi all, I would like to comment on the references to sFlow in the IP Flow = Information Accounting and Export Benchmarking Methodology document. The Abstract states, "The metric is only applicable to the devices = compliant with the Architecture for IP Flow Information Export = [RFC5470]." The sFlow architecture differs significantly from RFC5470 = and the benchmarking methodology described in the document is not = applicable sFlow. Confusion can arise because the sFlow specification = (http://www.sflow.org/sflow_version_5.txt) does use the term Packet = Flow. However, sFlow's definition of a packet flow is: o Packet Flow: A Packet Flow is defined as the path or trajectory that a packet takes through a Network Device (i.e. the path that a packet takes as it is received on one interface, is subject to a switching/routing decision and is then sent on another interface. Note that the definition refers to a single packet. The sFlow = architecture is stateless, an sFlow agent does not examine packet = attributes or aggregate data in a flow cache. Sampled packet headers are = immediately exported to a central sFlow collector which decodes, = classifies, scales and aggregates the data. o Packet Flow Record: A Packet Flow Record describes the attributes of a Packet Flow. There are two types of information in a flow record: 1 Information on the packet itself, typically a packet header, packet length and packet encapsulation. 2 Information about the path the packet took through the device, including information relating to the selection of the forwarding path. The second measurement technique used by sFlow, Counter Sampling, also = differs significantly from RFC5470: o Counter Sampling: Periodic sampling or polling of counters associated with a Data Source. =20 The following example demonstrates the general lack of applicability of = this document to sFlow benchmarking. Paragraph 5, in the Introduction = states: The most significant parameter in terms of performance, is the rate at which IP flows are created and expired in the network devices memory and exported to a collector.=20 Since sFlow agents are stateless, the rate of IP flows is not a factor = that influences performance. To avoid confusion, the following references to sFlow should be removed = from the benchmark document: 1. Figure 1, page 7. sFlow does not export flows and is not part of the = flow monitoring plane. 2. Page 30, sFlow should be removed from the Flow Export Protocol list = since it does not export flow records. Cheers, Peter =20 On Feb 13, 2011, at 7:06 AM, Al Morton wrote: > BMWG, > CC: IPFIX WG, >=20 > This message begins the first WG Last call on the draft: >=20 > IP Flow Information Accounting and Export Benchmarking Methodology > draft-ietf-bmwg-ipflow-meth-00.txt >=20 > A URL for this draft is: > http://tools.ietf.org/html/draft-ietf-bmwg-ipflow-meth-00 >=20 > The Last Call will end on March 14, 2011. >=20 > Although this is the first WGLC, we have discussed this draft > in the working group for over two years, and made many suggestions. > We have also benefited from review by folks from IPFIX WG. > I now ask folks to consider items where they commented earlier, > and make sure that the resolutions are satisfactory. >=20 > And it's not too late to read the draft for the first time, > and provide comments based on your review. >=20 > Please weigh-in on whether or not this Internet-Draft > should be given to the Area Directors and IESG for consideration and > publication as an Informational RFC. Send your comments > to this list and/or acmorton@att.com. >=20 > Al > bmwg chair >=20 >=20 > _______________________________________________ > IPFIX mailing list > IPFIX@ietf.org > https://www.ietf.org/mailman/listinfo/ipfix From n.brownlee@auckland.ac.nz Sun Feb 13 18:17:30 2011 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 3A3D23A6AEF for ; Sun, 13 Feb 2011 18:17:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.346 X-Spam-Level: X-Spam-Status: No, score=-102.346 tagged_above=-999 required=5 tests=[AWL=1.254, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mlx15Szn4dlw for ; Sun, 13 Feb 2011 18:17:29 -0800 (PST) Received: from mx2-int.auckland.ac.nz (mx2-int.auckland.ac.nz [130.216.12.41]) by core3.amsl.com (Postfix) with ESMTP id 41B083A6A62 for ; Sun, 13 Feb 2011 18:17:28 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=auckland.ac.nz; i=n.brownlee@auckland.ac.nz; q=dns/txt; s=uoa; t=1297649872; x=1329185872; h=message-id:date:from:mime-version:to:subject: content-transfer-encoding; z=Message-ID:=20<4D5890C5.9060903@auckland.ac.nz>|Date:=20 Mon,=2014=20Feb=202011=2015:17:41=20+1300|From:=20Nevil =20Brownlee=20|MIME-Version: =201.0|To:=20IPFIX=20Working=20Group=20 |Subject:=20flow-selection-tech:=20reviews=20needed |Content-Transfer-Encoding:=207bit; bh=mK+81MhbZBfKUqE6aKS7NK6rmgRF8SqGE3Pj2kkNyd8=; b=fKRUhysKeK1dNW6BfeKl2wYyYGhSK8AJyzE25ozgH09URDtuX4l0X99o e8SEQVskXSLU5lUxNoxgk3KosOuojGCnM/RzM/lYQi9ikfwomSzj3KHiu KokI/ltxmGz6QX0ljuFbE6IeLznNfYrDQ95ZCZ7TLbAN6FeC2qFShbXyx o=; X-IronPort-AV: E=Sophos;i="4.60,466,1291546800"; d="scan'208";a="46061403" X-Ironport-HAT: UNIVERSITY - $RELAY-THROTTLE X-Ironport-Source: 130.216.38.131 - Outgoing - Outgoing-SSL Received: from nevil-laptop1.sfac.auckland.ac.nz (HELO [130.216.38.131]) ([130.216.38.131]) by mx2-int.auckland.ac.nz with ESMTP; 14 Feb 2011 15:17:41 +1300 Message-ID: <4D5890C5.9060903@auckland.ac.nz> Date: Mon, 14 Feb 2011 15:17:41 +1300 From: Nevil Brownlee User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.13) Gecko/20101207 Lightning/1.0b2 Thunderbird/3.1.7 MIME-Version: 1.0 To: IPFIX Working Group Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [IPFIX] flow-selection-tech: reviews needed 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, 14 Feb 2011 02:17:30 -0000 Hi all: Now I'm working on the Shepherd document for the 'Flow Selection' draft. Alas, I don't see any reviews for it - please can you have a look at it and email some brief comments to the IPFIX list. 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 trammell@tik.ee.ethz.ch Mon Feb 14 07:00:52 2011 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 921273A6D78 for ; Mon, 14 Feb 2011 07:00:52 -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 knOsUKBTuCzm for ; Mon, 14 Feb 2011 07:00:51 -0800 (PST) Received: from smtp.ee.ethz.ch (smtp.ee.ethz.ch [129.132.2.219]) by core3.amsl.com (Postfix) with ESMTP id 899893A6D73 for ; Mon, 14 Feb 2011 07:00:51 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by smtp.ee.ethz.ch (Postfix) with ESMTP id 53961D932D; Mon, 14 Feb 2011 16:01:13 +0100 (MET) X-Virus-Scanned: by amavisd-new on smtp.ee.ethz.ch Received: from smtp.ee.ethz.ch ([127.0.0.1]) by localhost (.ee.ethz.ch [127.0.0.1]) (amavisd-new, port 10024) with LMTP id SZXARPjO6O+f; Mon, 14 Feb 2011 16:01:13 +0100 (MET) Received: from pb-10243.ethz.ch (pb-10243.ethz.ch [82.130.102.152]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: briant) by smtp.ee.ethz.ch (Postfix) with ESMTPSA id 24605D9327; Mon, 14 Feb 2011 16:01:13 +0100 (MET) Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii From: Brian Trammell In-Reply-To: <4D4F20A2.2050102@auckland.ac.nz> Date: Mon, 14 Feb 2011 16:01:12 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <789A7CC7-AAD5-480D-82FF-4EABB46CC997@tik.ee.ethz.ch> References: <4D4F20A2.2050102@auckland.ac.nz> To: Nevil Brownlee X-Mailer: Apple Mail (2.1082) Cc: IPFIX Working Group Subject: Re: [IPFIX] I need some reviews/comments on draft-ietf-ipfix-structured-data-04.txt X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Feb 2011 15:00:52 -0000 Hi. Nevil, all, FYI, have reviewed -04 of this document, and it's good as far as I'm = concerned. Best regards, Brian On Feb 6, 2011, at 11:28 PM, Nevil Brownlee wrote: >=20 > Hi all: >=20 > I'm writing the shepherd document for > draft-ietf-ipfix-structured-data-04.txt > However, I'm surprised to find that as far as I can see, no-one has > posted a review of it to the IPFIX list. > Please can I have a few (brief) reviews to the list now! >=20 > Cheers, Nevil >=20 > --=20 > --------------------------------------------------------------------- > Nevil Brownlee Computer Science Department | ITS > Phone: +64 9 373 7599 x88941 The University of Auckland > FAX: +64 9 373 7453 Private Bag 92019, Auckland 1142, New Zealand > _______________________________________________ > IPFIX mailing list > IPFIX@ietf.org > https://www.ietf.org/mailman/listinfo/ipfix From janovak@cisco.com Mon Feb 14 07:50:06 2011 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 AC9793A6D63; Mon, 14 Feb 2011 07:50:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EnukmZsJ6VeB; Mon, 14 Feb 2011 07:50:05 -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 C9BDC3A6D20; Mon, 14 Feb 2011 07:50:03 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=janovak@cisco.com; l=4516; q=dns/txt; s=amsiport02001; t=1297698627; x=1298908227; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to:cc; bh=Bfhbto0yxH+5JLucljDgZ7gSNbizUHB5CrpmtpDZ4s0=; b=beAryv9bsHjcxCBxP4SFF9e+kX3q4xtftFc0Ft1UdmxFfPS9pPEimQBA i7PFiY+bIYqEjpeXO3i+NfxpMkwbD8/2YnpdYb6DXmE0ktLyGe/vZhG/u l9aFhLvzezCz5JBSGgMCm7ewP5xPzR3mcY60UlDIITFrMO7YNaaIKHfIz s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AuAEAG7eWE2Q/khNgWdsb2JhbACmBxUBARYiJJ9AmwuFXgSPNw X-IronPort-AV: E=Sophos;i="4.60,469,1291593600"; d="scan'208";a="19148329" Received: from ams-core-4.cisco.com ([144.254.72.77]) by ams-iport-2.cisco.com with ESMTP; 14 Feb 2011 15:50:20 +0000 Received: from xbh-ams-101.cisco.com (xbh-ams-101.cisco.com [144.254.74.71]) by ams-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id p1EFoKiG001390; Mon, 14 Feb 2011 15:50:20 GMT Received: from xmb-ams-107.cisco.com ([144.254.74.82]) by xbh-ams-101.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 14 Feb 2011 16:50:20 +0100 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, 14 Feb 2011 16:50:18 +0100 Message-ID: <6674CF9A9F682245A590204F819F78AD03D0BC8D@XMB-AMS-107.cisco.com> In-Reply-To: <0486FD12-14F9-4223-8C23-BE5AE0ED3892@inmon.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [bmwg] [IPFIX] WGLC: draft-ietf-bmwg-ipflow-meth-00 Thread-Index: AcvMWZsJ+Wvzj2AbQXugKgVh/8QUXAABTjhA References: <201102131506.p1DF6Kgc024578@alpd052.aldc.att.com> <0486FD12-14F9-4223-8C23-BE5AE0ED3892@inmon.com> From: "Jan Novak (janovak)" To: "Peter Phaal" , "Al Morton" X-OriginalArrivalTime: 14 Feb 2011 15:50:20.0801 (UTC) FILETIME=[E26D7F10:01CBCC5E] Cc: bmwg@ietf.org, ipfix@ietf.org Subject: Re: [IPFIX] [bmwg] WGLC: draft-ietf-bmwg-ipflow-meth-00 X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Feb 2011 15:50:06 -0000 Hi, Thank you - quite valuable point. Jan The climate of Edinburgh is such that the weak succumb young ....=20 and the strong envy them. Dr. Johnson -----Original Message----- From: bmwg-bounces@ietf.org [mailto:bmwg-bounces@ietf.org] On Behalf Of Peter Phaal Sent: 13 February 2011 22:04 To: Al Morton Cc: ipfix@ietf.org; bmwg@ietf.org Subject: Re: [bmwg] [IPFIX] WGLC: draft-ietf-bmwg-ipflow-meth-00 Hi all, I would like to comment on the references to sFlow in the IP Flow Information Accounting and Export Benchmarking Methodology document. The Abstract states, "The metric is only applicable to the devices compliant with the Architecture for IP Flow Information Export [RFC5470]." The sFlow architecture differs significantly from RFC5470 and the benchmarking methodology described in the document is not applicable sFlow. Confusion can arise because the sFlow specification (http://www.sflow.org/sflow_version_5.txt) does use the term Packet Flow. However, sFlow's definition of a packet flow is: o Packet Flow: A Packet Flow is defined as the path or trajectory that a packet takes through a Network Device (i.e. the path that a packet takes as it is received on one interface, is subject to a switching/routing decision and is then sent on another interface. Note that the definition refers to a single packet. The sFlow architecture is stateless, an sFlow agent does not examine packet attributes or aggregate data in a flow cache. Sampled packet headers are immediately exported to a central sFlow collector which decodes, classifies, scales and aggregates the data. o Packet Flow Record: A Packet Flow Record describes the attributes of a Packet Flow. There are two types of information in a flow record: 1 Information on the packet itself, typically a packet header, packet length and packet encapsulation. 2 Information about the path the packet took through the device, including information relating to the selection of the forwarding path. The second measurement technique used by sFlow, Counter Sampling, also differs significantly from RFC5470: o Counter Sampling: Periodic sampling or polling of counters associated with a Data Source. =20 The following example demonstrates the general lack of applicability of this document to sFlow benchmarking. Paragraph 5, in the Introduction states: The most significant parameter in terms of performance, is the rate at which IP flows are created and expired in the network devices memory and exported to a collector.=20 Since sFlow agents are stateless, the rate of IP flows is not a factor that influences performance. To avoid confusion, the following references to sFlow should be removed from the benchmark document: 1. Figure 1, page 7. sFlow does not export flows and is not part of the flow monitoring plane. 2. Page 30, sFlow should be removed from the Flow Export Protocol list since it does not export flow records. Cheers, Peter =20 On Feb 13, 2011, at 7:06 AM, Al Morton wrote: > BMWG, > CC: IPFIX WG, >=20 > This message begins the first WG Last call on the draft: >=20 > IP Flow Information Accounting and Export Benchmarking Methodology > draft-ietf-bmwg-ipflow-meth-00.txt >=20 > A URL for this draft is: > http://tools.ietf.org/html/draft-ietf-bmwg-ipflow-meth-00 >=20 > The Last Call will end on March 14, 2011. >=20 > Although this is the first WGLC, we have discussed this draft > in the working group for over two years, and made many suggestions. > We have also benefited from review by folks from IPFIX WG. > I now ask folks to consider items where they commented earlier, > and make sure that the resolutions are satisfactory. >=20 > And it's not too late to read the draft for the first time, > and provide comments based on your review. >=20 > Please weigh-in on whether or not this Internet-Draft > should be given to the Area Directors and IESG for consideration and > publication as an Informational RFC. Send your comments > to this list and/or acmorton@att.com. >=20 > Al > bmwg chair >=20 >=20 > _______________________________________________ > IPFIX mailing list > IPFIX@ietf.org > https://www.ietf.org/mailman/listinfo/ipfix _______________________________________________ bmwg mailing list bmwg@ietf.org https://www.ietf.org/mailman/listinfo/bmwg From bclaise@cisco.com Mon Feb 14 08:56:08 2011 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 BA23E3A6D4C for ; Mon, 14 Feb 2011 08:56:08 -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.001, 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 Gv6XIFUbHEAL for ; Mon, 14 Feb 2011 08:56:08 -0800 (PST) Received: from av-tac-bru.cisco.com (weird-brew.cisco.com [144.254.15.118]) by core3.amsl.com (Postfix) with ESMTP id B479C3A6A57 for ; Mon, 14 Feb 2011 08:56:07 -0800 (PST) X-TACSUNS: Virus Scanned Received: from strange-brew.cisco.com (localhost.cisco.com [127.0.0.1]) by av-tac-bru.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id p1EGqaI6028796; Mon, 14 Feb 2011 17:52:36 +0100 (CET) Received: from [10.55.43.51] (ams-bclaise-8712.cisco.com [10.55.43.51]) by strange-brew.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id p1EGqZft009009; Mon, 14 Feb 2011 17:52:36 +0100 (CET) Message-ID: <4D595DD2.1040309@cisco.com> Date: Mon, 14 Feb 2011 17:52:34 +0100 From: Benoit Claise User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-GB; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: Nevil Brownlee References: <4D5890C5.9060903@auckland.ac.nz> In-Reply-To: <4D5890C5.9060903@auckland.ac.nz> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: IPFIX Working Group Subject: Re: [IPFIX] flow-selection-tech: reviews needed 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, 14 Feb 2011 16:56:08 -0000 Hi Nevil, I will review the draft now, mainly in the context of the IPFIX Mediation Protocol draft. I'm not sure anymore in which state we are wrt this draft. WGLC is finished? Regards, Benoit. > > Hi all: > > Now I'm working on the Shepherd document for the 'Flow Selection' > draft. Alas, I don't see any reviews for it - please can you > have a look at it and email some brief comments to the IPFIX list. > > Cheers, Nevil > From rahulp@cisco.com Mon Feb 14 09:28:27 2011 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 9BB663A6A6D for ; Mon, 14 Feb 2011 09:28:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9VwsB6jif-xB for ; Mon, 14 Feb 2011 09:28:26 -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 C79EE3A69EB for ; Mon, 14 Feb 2011 09:28:26 -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: Ag4BADT1WE2tJXG+/2dsb2JhbACXLo5dc6AWmySFXgSFBIoz X-IronPort-AV: E=Sophos;i="4.60,469,1291593600"; d="scan'208";a="215448155" Received: from rcdn-core2-3.cisco.com ([173.37.113.190]) by rtp-iport-2.cisco.com with ESMTP; 14 Feb 2011 17:28:49 +0000 Received: from xbh-rcd-202.cisco.com (xbh-rcd-202.cisco.com [72.163.62.201]) by rcdn-core2-3.cisco.com (8.14.3/8.14.3) with ESMTP id p1EHSnqE003543 for ; Mon, 14 Feb 2011 17:28:49 GMT Received: from xmb-rcd-213.cisco.com ([72.163.62.220]) by xbh-rcd-202.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 14 Feb 2011 11:28:49 -0600 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, 14 Feb 2011 11:28:48 -0600 Message-ID: In-Reply-To: <4D58472E.6050804@net.in.tum.de> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [IPFIX] I need some reviews/commentson draft-ietf-ipfix-structured-data-04.txt Thread-Index: AcvLwa0UxGxhbAdoTCqItWYz+YLGTAAqtqpw References: <4D5570B1.2070901@cisco.com> <4D58472E.6050804@net.in.tum.de> From: "Rahul Patel (rahulp)" To: "IETF IPFIX Working Group" X-OriginalArrivalTime: 14 Feb 2011 17:28:49.0730 (UTC) FILETIME=[A46C8220:01CBCC6C] Subject: Re: [IPFIX] I need some reviews/commentson draft-ietf-ipfix-structured-data-04.txt X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Feb 2011 17:28:27 -0000 I am fine with this version. My comments are addressed. Thanks, -Rahul -----Original Message----- From: ipfix-bounces@ietf.org [mailto:ipfix-bounces@ietf.org] On Behalf Of Gerhard Muenz Sent: Sunday, February 13, 2011 4:04 PM To: IETF IPFIX Working Group Subject: Re: [IPFIX] I need some reviews/commentson draft-ietf-ipfix-structured-data-04.txt Importance: Low Hi all, I briefly scanned the changes in -04. As far as I can see, all comments of my -02 review have been addressed. So, I'm fine with the document. Cheers, Gerhard > > Hi all: > > I'm writing the shepherd document for > draft-ietf-ipfix-structured-data-04.txt > However, I'm surprised to find that as far as I can see, no-one has=20 > posted a review of it to the IPFIX list. > Please can I have a few (brief) reviews to the list now! > > Cheers, Nevil > _______________________________________________ IPFIX mailing list IPFIX@ietf.org https://www.ietf.org/mailman/listinfo/ipfix From bclaise@cisco.com Tue Feb 15 00:24:10 2011 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 A7B7C3A6A5A for ; Tue, 15 Feb 2011 00:24: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 RV-4MuE6JUva for ; Tue, 15 Feb 2011 00:24:09 -0800 (PST) Received: from av-tac-bru.cisco.com (weird-brew.cisco.com [144.254.15.118]) by core3.amsl.com (Postfix) with ESMTP id 636173A6E61 for ; Tue, 15 Feb 2011 00:24:09 -0800 (PST) X-TACSUNS: Virus Scanned Received: from strange-brew.cisco.com (localhost.cisco.com [127.0.0.1]) by av-tac-bru.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id p1F8KmAd021153 for ; Tue, 15 Feb 2011 09:20:49 +0100 (CET) Received: from [10.55.43.51] (ams-bclaise-8712.cisco.com [10.55.43.51]) by strange-brew.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id p1F8KmBR012802 for ; Tue, 15 Feb 2011 09:20:48 +0100 (CET) Message-ID: <4D5A3760.8010701@cisco.com> Date: Tue, 15 Feb 2011 09:20:48 +0100 From: Benoit Claise User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-GB; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: "ipfix@ietf.org" Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [IPFIX] draft-claise-ipfix-mediation-protocol-03.txt has been successfully submitted 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, 15 Feb 2011 08:24:10 -0000 Dear all, A new version of the IPFIX Mediation has been posted. You can find the diff at http://tools.ietf.org/rfcdiff?url2=draft-claise-ipfix-mediation-protocol-03.txt - Definitions are in line between the framework, the aggregation draft, and this draft. - We introduced the notion of Template Mapping Template Mapping A mapping from Template Records and/or Options Template Records received by a Mediator to Template Records and/or Options Template Records sent by that IPFIX Mediator. Each entry in a Template Mapping is scoped by incoming or outgoing Transport Session and Observation Domain, as with Templates and Options Templates in the IPFIX Protocol. - In terms of Template Management, we were able to classify all Intermediate Process into 2 categories: 3.2.1. Template Management Without Template Record Change 3.2.2. Template Management With Template Record Change We gave some examples, also including the Template Mapping. - In terms of Observation Domain Management, we have a completed section, which also includes the notion of Template Mapping. - New section on configuration management. - 3 new Informations Elements: originalExporterIPv4Address, originalExporterIPv6Address, and originalObservationDomainId We have resolved all the open issues. This draft fits the mediation requirements, the framework, the anonymization, and the aggregation drafts. Regards, Brian, Kobayshi-san, and Benoit. From bclaise@cisco.com Tue Feb 15 23:12:30 2011 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 9B28F3A6D63 for ; Tue, 15 Feb 2011 23:12:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[AWL=1.000, BAYES_00=-2.599, GB_I_LETTER=-2, 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 Gpbo0Bu+Ihin for ; Tue, 15 Feb 2011 23:12:26 -0800 (PST) Received: from av-tac-bru.cisco.com (weird-brew.cisco.com [144.254.15.118]) by core3.amsl.com (Postfix) with ESMTP id CFCC53A6DB1 for ; Tue, 15 Feb 2011 23:12:25 -0800 (PST) X-TACSUNS: Virus Scanned Received: from strange-brew.cisco.com (localhost.cisco.com [127.0.0.1]) by av-tac-bru.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id p1G71R9Y026500 for ; Wed, 16 Feb 2011 08:01:27 +0100 (CET) Received: from [10.55.43.50] (ams-bclaise-8711.cisco.com [10.55.43.50]) by strange-brew.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id p1G71NQv004620 for ; Wed, 16 Feb 2011 08:01:24 +0100 (CET) Message-ID: <4D5B7643.2010701@cisco.com> Date: Wed, 16 Feb 2011 08:01:23 +0100 From: Benoit Claise User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-GB; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: "ipfix@ietf.org" Content-Type: multipart/alternative; boundary="------------080905060202040805060900" Subject: [IPFIX] Flow-selection-tech: review X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Feb 2011 07:12:31 -0000 This is a multi-part message in MIME format. --------------080905060202040805060900 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Dear all, I've been reviewing the draft, mainly in the context of the IPFIX Mediation Protocol draft, to make that all the mediation related drafts are in line: requirements (RFC 5982), framework (RFC-editor), anonymization, flow selection techniques, aggregation, and finally the protocol. Sorry if I'm late, this flow selection technique is the last one I reviewed. The important issues start with "important" - Reference. Sometimes referred as the RFC number [RFC5475 ], and sometimes as [IPFIX-REQ ] - "Flow selection reduces the resource demands for capturing, storing, exporting and post-processing flow-based measurement results." Actually, reduces the resource demands for post-processing flow-based measurement results, that's for sure. While, reduces the resource demands for capturing, storing -> it depends: if you have to look at the all packets, hence all flows, in order to do the flow selection (like the elephant), you don't gain much. You might want to clarify. Somehow, you have to go in the conclusions of [EsVa01] to discover this. - Terminology This document is consistent with the terminology introduced in [RFC5470 ], [RFC5475 ] and [IPFIX-REQ ]. Further some additional terms are presented which extend the terminology. * Flow A Flow is defined as a set of packets with common properties passing an Observation Point in the network during a certain time interval. Actually "Flow" is not an additional term, as it's defined already in RFC5101. However, the definitions are not quite the same. Isn't it confusing? The "Flow record" definition is exactly the same as RFC5101. Why redefined? Important point: this is the first draft in the IPFIX series that doesn't use capitalized definitions. All IPFIX draft uses a sentence such as: At the beginning of the terminology section, you might add a sentence such as: In this document, as in [RFC5101 ] and [RFC5476 ], the first letter of each IPFIX-specific and PSAMP-specific term is capitalized along with the IPFIX Mediation-specific terms defined here. However, some sentences use the capitalization. "As an example, if an IPFIX Mediator interacts with a set of IPFIX Collectors, flow records arriving at ..." the "Intermediate Process" and "IPFIX Mediator" definitions should be referred fromhttp://tools.ietf.org/html/draft-ietf-ipfix-mediators-framework-09 Important point: I believe that your definition of "Flow Selection Process" should be a special case of the Intermediate Selection Process, which is defined as, in bothhttp://tools.ietf.org/html/draft-ietf-ipfix-mediators-framework-09 andhttp://tools.ietf.org/html/draft-claise-ipfix-mediation-protocol-02: Intermediate Selection Process An Intermediate Selection Process is an Intermediate Process that selects records from a sequence based upon criteria-evaluated record values and passes only those records that match the criteria (e.g., Filtering only records from a given network to a given Collector). How is the IPFIX Exporter different from the Exporter specified in RFC5101? RFC5101: Exporter A device that hosts one or more Exporting Processes is termed an Exporter. Your draft: * IPFIX Exporter The IPFIX exporter is a software that receives measurement data from e.g. the Metering Process and exports this data to a collector. Somehow, based on the terminology section, I'm missing the link with the other drafts, such as the mediation framework. - Important: RFC 2119 language "Ideally, we would like to keep also a timestamp for the first (T_fd) and last (T_ld) not yet exported packets belonging to every discarded flow record. " use MAY? "Another information that can be easily maintained is the number of discarding actions, along with the timestamps of the first and last action. This information SHOULD not be used by applications to re- normalize the received per flow statistics (because a flow may be discarded and created multiple times), but rather to monitor and control the performance of the implemented policy." Second sentence use SHOULD (-> btw, SHOULD NOT) So the first sentence should use MAY? "For this reason, flow exporting protocol specification does not include flow selection during the recording process as a mandatory function even if the information model has been designed to enable such function." I could give other examples, but my point is that I don't know how to be compliant to this standard track future RFC, from an implementation point of view. Along the same lines, which flow selection techniques in section 6 must a compliant implementation support? - Important: IPR Along the same line as the previous point, you refer tohttp://conferences.sigcomm.org/imc/2001/imw2001-papers/03.pdf in section 4.3. Flow selection during the exporting process " An example of such a policy could be to export only the flow records associated to flows whose accounted traffic is below a certain threshold, or to implement a more complex mechanism such as the one described in [DuLT01a ] or [DuLT01b ]." Should it be implemented or not to be compliant with that future RFC? When I spoke with Nick Duffield some years ago, there was a patent on this. And I don't see any IPR on this draft. - Important: Section 5 doesn't refer at all to the Intermediate Process specifies in the mediation framework - Important: I have now finished the section 5, and still not sure how the flow recording process is different from the metering process. I can't find this term in the IPFIX architecture. However, we have some IEs that are defined specifically for the Flow Recording... - Important: why do we have "Flow recording and selection" on the Original Exporter while we only have "Flow Selection" on the Mediator? If I look at with IE I should implement, I see: If there 7 . Information model for flow selection information exporting . .14 7.1 . Meter process related (TBD1-TBD3) . . . . . . . . . . . .16 7.2 . Flow recording process related (TBD4-TBD11) . . . . . . .18 7.3 . Flow exporting process related (TBD12-TBD19) . . . . . . .21 How does it translate for Mediator, which only contains "Flow Selection" according to this figure? - IE naming convention. In the description, can you please have the meaning. For example: fsMeterUnmeasPacketCountTsFirst is the concatenation of FlowSelectionMeasuredUnmeteredPacketCounterTimeStampFirst. Even after the reading, I'm not 100%. So if someone only looks at the IANA registry... For example, what is fsFrecPacketInDroppedRecsCountTsFirst, FlowSelectionFrec... unless it's FlowSelectionFlowRec... with a capitalized R fsFrecFrecDroppedCountTsFirst, fsFrecFrecDroppedCountTsLast: why twice Frec in the names Btw, what's the size limit for a IE name? - fsMeterUnmeasPacketCountTsFirst Description: Specifies the timestamp of the first packet not measured because of the use of the flow state dependent sampling. Together with the IE fsMeterUnmeasPacketCountTsLast it allows to evaluate the count of packets that were not measured because of the use of the flow sampling. "measured" by who? by the Metering Process, so it should be "metered", right? Also, "by the Metering Process" should be added in the description, right? Same remark for 7.1.* - Important 7.2.6. fsFrecUnexportedFrecCount Description: This Information Element specifies the count of the flow records currently existing in the flow recording process containing at least one non-exported packet. 7.2.7. fsFrecUnexportedPacketInFrecCount Description: This Information Element specifies the count of non-exported packets contained in flow records of the flow recording process. 7.2.8. fsFrecUnexportedBytesInFrecCount Description: This Information Element specifies the count of non-exported bytes contained in flow records of the flow recording process. Looking at figure 1, the Flow Recording is before the Exporting Process. So all flow records in the Flow Recording are not exported, right? What do I miss? - fsExpUnexportedCount should at least contain FlowRecord (or FRec or whatever) in the name - Important: you have defined a new IE selectorMethod Why not reuse selectorAlgorithm from RFC 5476? - Important: IPFIX IANA specifies the IE 60, ipVersion You redefined this. 9.6. flowIPAddressVersion Description: This Information Element specifies the IP version field of the packets belonging to flow records which SHOULD be considered as not eligible for removal. Abstract Data Type: unsigned8 Data Type Semantics: identifier ElementId: 60 Status: current Reference: see [RFC5102 ] for the definition of the ipVersion information element and its Id. You can not do this. Same remark for flowIPv4SourceAddress, flowIPv6SourceAddress, flowIPv6DestinationAddress Regards, Benoit. --------------080905060202040805060900 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Dear all,

I've been reviewing the draft, mainly in the context of the IPFIX Mediation Protocol draft, to make that all the mediation related drafts are in line:
requirements (RFC 5982), framework (RFC-editor), anonymization, flow selection techniques, aggregation, and finally the protocol.
Sorry if I'm late, this flow selection technique is the last one I reviewed.

The important issues start with "important"

- Reference. Sometimes referred as the RFC number [RFC5475], and sometimes as [IPFIX-REQ]

- "Flow selection reduces the resource demands for capturing, storing, exporting and post-processing flow-based measurement results."
Actually, reduces the resource demands for post-processing flow-based measurement results, that's for sure.
While, reduces  the resource demands for capturing, storing -> it depends: if you have to look at the all packets, hence all flows, in order to do the flow selection (like the elephant), you don't gain much.
You might want to clarify. Somehow, you have to go in the conclusions of [EsVa01] to discover this.

- Terminology
  This document is consistent with the terminology introduced in
   [RFC5470], [RFC5475] and [IPFIX-REQ].  Further some additional terms
   are presented which extend the terminology.

   * Flow

      A Flow is defined as a set of packets with common properties
      passing an Observation Point in the network during a certain time
      interval.

Actually "Flow" is not an additional term, as it's defined already in RFC5101.
However, the definitions are not quite the same. Isn't it confusing?

The "Flow record" definition is exactly the same as RFC5101. Why redefined?

Important point: this is the first draft in the IPFIX series that doesn't use capitalized definitions.
All IPFIX draft uses a sentence such as: 
   At the beginning of the terminology section, you might add a sentence such as:
   In this document, as in [RFC5101] and [RFC5476], the first letter of
   each IPFIX-specific and PSAMP-specific term is capitalized along with
   the IPFIX Mediation-specific terms defined here.
However, some sentences use the capitalization.
   "As an example, if an IPFIX Mediator interacts with a set of IPFIX
   Collectors, flow records arriving at ..."

the "Intermediate Process" and "IPFIX Mediator" definitions should be referred from http://tools.ietf.org/html/draft-ietf-ipfix-mediators-framework-09

Important point: I believe that your definition of "Flow Selection Process" should be a special case of the Intermediate Selection Process, which is defined as, in both http://tools.ietf.org/html/draft-ietf-ipfix-mediators-framework-09 and http://tools.ietf.org/html/draft-claise-ipfix-mediation-protocol-02:

Intermediate Selection Process

An Intermediate Selection Process is an Intermediate Process that selects records from a sequence based upon criteria-evaluated record values and passes only those records that match the criteria (e.g., Filtering only records from a given network to a given Collector).

How is the IPFIX Exporter different from the Exporter specified in RFC5101?
RFC5101:
   Exporter

      A device that hosts one or more Exporting Processes is termed an
      Exporter.
Your draft:
   * IPFIX Exporter

      The IPFIX exporter is a software that receives measurement data
      from e.g. the Metering Process and exports this data to a
      collector.

Somehow, based on the terminology section, I'm missing the link with the other drafts, such as the mediation framework.

- Important: RFC 2119 language
   "Ideally, we would like to keep also a timestamp for the first (T_fd)
   and last (T_ld) not yet exported packets belonging to every discarded
   flow record. " 
   use MAY?

   "Another information that can be easily maintained is the number of
   discarding actions, along with the timestamps of the first and last
   action.  This information SHOULD not be used by applications to re-
   normalize the received per flow statistics (because a flow may be
   discarded and created multiple times), but rather to monitor and
   control the performance of the implemented policy."
   Second sentence use SHOULD (-> btw, SHOULD NOT)
   So the first sentence should use MAY?   

   "For this reason, flow exporting protocol specification does
   not include flow selection during the recording process as a
   mandatory function even if the information model has been designed to
   enable such function."

   I could give other examples, but my point is that I don't know how to be compliant to this standard track future RFC, from an implementation point of view.

Along the same lines, which flow selection techniques in section 6 must a compliant implementation support?

- Important: IPR
Along the same line as the previous point, you refer to http://conferences.sigcomm.org/imc/2001/imw2001-papers/03.pdf in section 4.3.  Flow selection during the exporting process

"  An example of such a policy could
   be to export only the flow records associated to flows whose
   accounted traffic is below a certain threshold, or to implement a
   more complex mechanism such as the one described in [DuLT01a] or
   [DuLT01b]."

Should it be implemented or not to be compliant with that future RFC?
When I spoke with Nick Duffield some years ago, there was a patent on this.
And I don't see any IPR on this draft.

- Important: Section 5 doesn't refer at all to the Intermediate Process specifies in the mediation framework

- Important: I have now finished the section 5, and still not sure how the flow recording process is different from the metering process.
I can't find this term in the IPFIX architecture.
However, we have some IEs that are defined specifically for the Flow Recording...

- Important: why do we have "Flow recording and selection" on the Original Exporter while we only have "Flow Selection" on the Mediator?
If I look at with IE I should implement, I see:
If there 
   7.  Information model for flow selection information exporting . . 14
     7.1.  Meter process related (TBD1-TBD3)  . . . . . . . . . . . . 16
     7.2.  Flow recording process related (TBD4-TBD11)  . . . . . . . 18
     7.3.  Flow exporting process related (TBD12-TBD19) . . . . . . . 21
How does it translate for Mediator, which only contains "Flow Selection" according to this figure?

- IE naming convention. In the description, can you please have the meaning.
For example: fsMeterUnmeasPacketCountTsFirst is the concatenation of FlowSelectionMeasuredUnmeteredPacketCounterTimeStampFirst.
Even after the reading, I'm not 100%.
So if someone only looks at the IANA registry...
For example, what is fsFrecPacketInDroppedRecsCountTsFirst, FlowSelectionFrec... unless it's FlowSelectionFlowRec... with a capitalized R
fsFrecFrecDroppedCountTsFirst, fsFrecFrecDroppedCountTsLast: why twice Frec in the names
Btw, what's the size limit for a IE name?

- fsMeterUnmeasPacketCountTsFirst

   Description:

      Specifies the timestamp of the first packet not measured because
      of the use of the flow state dependent sampling.  Together with
      the IE fsMeterUnmeasPacketCountTsLast it allows to evaluate the
      count of packets that were not measured because of the use of the
      flow sampling.

"measured" by who? by the Metering Process, so it should be "metered", right?
Also, "by the Metering Process" should be added in the description, right?
Same remark for 7.1.*

- Important

7.2.6.  fsFrecUnexportedFrecCount

   Description:

      This Information Element specifies the count of the flow records
      currently existing in the flow recording process containing at
      least one non-exported packet.


7.2.7.  fsFrecUnexportedPacketInFrecCount


   Description:

      This Information Element specifies the count of non-exported
      packets contained in flow records of the flow recording process.


7.2.8.  fsFrecUnexportedBytesInFrecCount


   Description:

      This Information Element specifies the count of non-exported bytes
      contained in flow records of the flow recording process.

Looking at figure 1, the Flow Recording is before the Exporting Process.
So all flow records in the Flow Recording are not exported, right? What do I miss?


- fsExpUnexportedCount should at least contain FlowRecord (or FRec or whatever) in the name

- Important: you have defined a new IE selectorMethod          
Why not reuse selectorAlgorithm from RFC 5476?

- Important: IPFIX IANA specifies the IE 60, ipVersion
You redefined this.


9.6.  flowIPAddressVersion

   Description:

      This Information Element specifies the IP version field of the
      packets belonging to flow records which SHOULD be considered as
      not eligible for removal.

   Abstract Data Type: unsigned8

   Data Type Semantics: identifier

   ElementId: 60

   Status: current

   Reference: see [RFC5102] for the definition of the ipVersion
   information element and its Id.

You can not do this.
Same remark for flowIPv4SourceAddress, flowIPv6SourceAddress, flowIPv6DestinationAddress
Regards, Benoit.
--------------080905060202040805060900-- From trammell@tik.ee.ethz.ch Wed Feb 16 07:59:36 2011 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 9A7C93A6D9D for ; Wed, 16 Feb 2011 07:59:36 -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 RhH3hsyj3qOR for ; Wed, 16 Feb 2011 07:59: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 4A4DE3A6D21 for ; Wed, 16 Feb 2011 07:59:35 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by smtp.ee.ethz.ch (Postfix) with ESMTP id D3D00D9340 for ; Wed, 16 Feb 2011 17:00:02 +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 RZ9yvAPyEl9u for ; Wed, 16 Feb 2011 17:00:02 +0100 (MET) Received: from pb-10243.ethz.ch (pb-10243.ethz.ch [82.130.102.152]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: briant) by smtp.ee.ethz.ch (Postfix) with ESMTPSA id 839A9D9339 for ; Wed, 16 Feb 2011 17:00:02 +0100 (MET) From: Brian Trammell Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Wed, 16 Feb 2011 17:00:02 +0100 Message-Id: <8E7BE015-EEFB-48B4-B85D-6AE5BA5D3B34@tik.ee.ethz.ch> To: IPFIX Working Group Mime-Version: 1.0 (Apple Message framework v1082) X-Mailer: Apple Mail (2.1082) Subject: [IPFIX] Interop in Prague, March 24-25, 2011 X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Feb 2011 15:59:36 -0000 Greetings, all, Updated information is available for the IPFIX Interop event in Prague = at http://fp7-demons.eu/?p=3D164, including changes to the nondisclosure = agreement and initial information on the testing protocol. To help us organize this event, those planning on attending should send = a registration email to me, trammell@tik.ee.ethz.ch, with the following = information, by Friday 25 February 2011 if possible: - whether you'll bring an exporter, collector, or both - the transport protocols supported by your implementation = (SCTP, TCP, UDP) - link(s) to any public documentation available detailing the = template(s) natively supported by the implementation - the name(s) of the people attending Please do this even if we've already been in contact. Also, please = indicate whether your organization's participation in the event may be = shared with other prospective participants, and/or made public. Many thanks, and best regards, Brian= From trammell@tik.ee.ethz.ch Tue Feb 22 03:09:47 2011 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 EAF323A687E for ; Tue, 22 Feb 2011 03:09:47 -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 VUJXYQ0-pmWt for ; Tue, 22 Feb 2011 03:09:47 -0800 (PST) Received: from smtp.ee.ethz.ch (smtp.ee.ethz.ch [129.132.2.219]) by core3.amsl.com (Postfix) with ESMTP id 09B373A6879 for ; Tue, 22 Feb 2011 03:09:46 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by smtp.ee.ethz.ch (Postfix) with ESMTP id B453DD9349 for ; Tue, 22 Feb 2011 12:10:29 +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 1DSfSU5K4na7 for ; Tue, 22 Feb 2011 12:10:29 +0100 (MET) Received: from [10.0.1.2] (cust-integra-121-161.antanet.ch [80.75.121.161]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: briant) by smtp.ee.ethz.ch (Postfix) with ESMTPSA id 66849D9339 for ; Tue, 22 Feb 2011 12:10:29 +0100 (MET) From: Brian Trammell Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Tue, 22 Feb 2011 12:10:28 +0100 References: <20110222104605.20B303A6872@core3.amsl.com> To: ipfix@ietf.org Message-Id: Mime-Version: 1.0 (Apple Message framework v1082) X-Mailer: Apple Mail (2.1082) Subject: [IPFIX] Fwd: New Version Notification for draft-trammell-ipfix-a9n-02 X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Feb 2011 11:09:48 -0000 Greetings, all, We have posted a new version of -a9n, the IPFIX Aggregation draft. This = revision of the draft is essentially complete except for detailed = examples and an security considerations section, and we believe is ready = for consideration to be adopted as a WG item on the next charter. Best regards, Brian Begin forwarded message: > From: IETF I-D Submission Tool > Date: February 22, 2011 11:46:05 AM GMT+01:00 > To: trammell@tik.ee.ethz.ch > Cc: arno@wagner.name, boschie@tik.ee.ethz.ch, bclaise@cisco.com > Subject: New Version Notification for draft-trammell-ipfix-a9n-02=20 >=20 >=20 > A new version of I-D, draft-trammell-ipfix-a9n-02.txt has been = successfully submitted by Brian Trammell and posted to the IETF = repository. >=20 > Filename: draft-trammell-ipfix-a9n > Revision: 02 > Title: Exporting Aggregated Flow Data using the IP = Flow Information Export (IPFIX) Protocol > Creation_date: 2011-02-22 > WG ID: Independent Submission > Number_of_pages: 27 >=20 > Abstract: > This document describes the export of aggregated Flow information > using IPFIX. An Aggregated Flow is essentially an IPFIX Flow > representing packets from multiple original Flows sharing some set of > common properties. The document describes Aggregated Flow export > within the framework of IPFIX Mediators and defines an interoperable, > implementation-independent method for Aggregated Flow export. >=20 >=20 >=20 > The IETF Secretariat. >=20 From n.brownlee@auckland.ac.nz Sun Feb 27 14:57:58 2011 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 50DEB3A6836 for ; Sun, 27 Feb 2011 14:57:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.972 X-Spam-Level: X-Spam-Status: No, score=-102.972 tagged_above=-999 required=5 tests=[AWL=0.627, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mfPSVMf6ytfn for ; Sun, 27 Feb 2011 14:57:56 -0800 (PST) Received: from mx2-int.auckland.ac.nz (mx2-int.auckland.ac.nz [130.216.12.41]) by core3.amsl.com (Postfix) with ESMTP id 2FA943A6835 for ; Sun, 27 Feb 2011 14:57:54 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=auckland.ac.nz; i=n.brownlee@auckland.ac.nz; q=dns/txt; s=uoa; t=1298847535; x=1330383535; h=message-id:date:from:mime-version:to:subject: content-transfer-encoding; z=Message-ID:=20<4D6AD72C.1040701@auckland.ac.nz>|Date:=20 Mon,=2028=20Feb=202011=2011:58:52=20+1300|From:=20Nevil =20Brownlee=20|MIME-Version: =201.0|To:=20IPFIX=20Working=20Group=20 |Subject:=20WGLC=20for=20'flow=20selection'=20draft |Content-Transfer-Encoding:=207bit; bh=GcwUfjoDAbRo5V4NlCbK2Tbe1b4lXi60LYZq7+BVmM0=; b=bKi/BjaSsLJO/iNL4WABdkJ0uiCIrVki3eU6mlMdsCXPcMZ05ZRC0Lfs hoMoDLrW4fUXA7sczz9zSY7r8o7oVHdBLfeAbV+a6IufPzn0dKWR6AJbV 9b9qWIknHtlt2VRo+yIqiITAVzFaArJjyyWsJOpQkdKhZlrIUS/1/zlCw k=; X-IronPort-AV: E=Sophos;i="4.62,235,1296990000"; d="scan'208";a="48086883" X-Ironport-HAT: UNIVERSITY - $RELAY-THROTTLE X-Ironport-Source: 130.216.38.131 - Outgoing - Outgoing-SSL Received: from nevil-laptop1.sfac.auckland.ac.nz (HELO [130.216.38.131]) ([130.216.38.131]) by mx2-int.auckland.ac.nz with ESMTP; 28 Feb 2011 11:58:52 +1300 Message-ID: <4D6AD72C.1040701@auckland.ac.nz> Date: Mon, 28 Feb 2011 11:58:52 +1300 From: Nevil Brownlee User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.13) Gecko/20101207 Lightning/1.0b2 Thunderbird/3.1.7 MIME-Version: 1.0 To: IPFIX Working Group Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [IPFIX] WGLC for 'flow selection' draft X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 27 Feb 2011 22:57:58 -0000 Hi all: A little while ago, Benoit commented "I didn't see the WGLC notice for this draft." Looking back through my notes, I see that at IETF 79 in Maastricht we agreed that "it would be ready for WGLC after its Editors had published a new draft." Its -03 draft was published on 7 December 2010, so I started on its writeup, but failed to send out its WGLC note. Ditto for its -04 draft. I apologise for that. On 14 Feb I called for reviews of it; Benoit has posted a review, thanks very much. I still need one or two more reviews, and I'm - at last - starting its WG Last Call now. It will end on 14 March. 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 trammell@tik.ee.ethz.ch Sun Feb 27 22:59:45 2011 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 2C5633A6AB3 for ; Sun, 27 Feb 2011 22:59:45 -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 ONIbL2lD3THJ for ; Sun, 27 Feb 2011 22:59:44 -0800 (PST) Received: from smtp.ee.ethz.ch (smtp.ee.ethz.ch [129.132.2.219]) by core3.amsl.com (Postfix) with ESMTP id DDCAC3A68F2 for ; Sun, 27 Feb 2011 22:59:43 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by smtp.ee.ethz.ch (Postfix) with ESMTP id BE3D0D9353; Mon, 28 Feb 2011 08:00: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 iDfN8PEfv0pB; Mon, 28 Feb 2011 08:00:42 +0100 (MET) Received: from [10.0.1.2] (cust-integra-121-161.antanet.ch [80.75.121.161]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: briant) by smtp.ee.ethz.ch (Postfix) with ESMTPSA id 79D62D934D; Mon, 28 Feb 2011 08:00:42 +0100 (MET) Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii From: Brian Trammell In-Reply-To: <4D6AD72C.1040701@auckland.ac.nz> Date: Mon, 28 Feb 2011 08:00:42 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <461A60AE-5DC6-4EC2-8538-03502D0F5A0F@tik.ee.ethz.ch> References: <4D6AD72C.1040701@auckland.ac.nz> To: Nevil Brownlee X-Mailer: Apple Mail (2.1082) Cc: IPFIX Working Group Subject: Re: [IPFIX] WGLC for 'flow selection' draft X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Feb 2011 06:59:45 -0000 Hi, Nevil, I've done a single pass of the draft, and in its current state it does = require, I think, a more thorough review. I'll do this by the 14th. Cheers, Brian =20 On Feb 27, 2011, at 11:58 PM, Nevil Brownlee wrote: >=20 > Hi all: >=20 > A little while ago, Benoit commented "I didn't see the WGLC notice for > this draft." Looking back through my notes, I see that at IETF 79 in > Maastricht we agreed that "it would be ready for WGLC after its = Editors > had published a new draft." Its -03 draft was published on 7 December > 2010, so I started on its writeup, but failed to send out its WGLC > note. Ditto for its -04 draft. I apologise for that. >=20 > On 14 Feb I called for reviews of it; Benoit has posted a review, > thanks very much. I still need one or two more reviews, and I'm - > at last - starting its WG Last Call now. It will end on 14 March. >=20 > Cheers, Nevil >=20 > --=20 > --------------------------------------------------------------------- > Nevil Brownlee Computer Science Department | ITS > Phone: +64 9 373 7599 x88941 The University of Auckland > FAX: +64 9 373 7453 Private Bag 92019, Auckland 1142, New Zealand > _______________________________________________ > IPFIX mailing list > IPFIX@ietf.org > https://www.ietf.org/mailman/listinfo/ipfix