Re: Last Call: <draft-yourtchenko-cisco-ies-09.txt> (Cisco Specific Information Elements reused in IPFIX) to Informational RFC
Benoit Claise <bclaise@cisco.com> Fri, 31 January 2014 11:53 UTC
Return-Path: <bclaise@cisco.com>
X-Original-To: ietf@ietfa.amsl.com
Delivered-To: ietf@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 082A51A0589 for <ietf@ietfa.amsl.com>; Fri, 31 Jan 2014 03:53:48 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.035
X-Spam-Level:
X-Spam-Status: No, score=-10.035 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.535, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HM7y0R2DWSjM for <ietf@ietfa.amsl.com>; Fri, 31 Jan 2014 03:53:45 -0800 (PST)
Received: from aer-iport-1.cisco.com (aer-iport-1.cisco.com [173.38.203.51]) by ietfa.amsl.com (Postfix) with ESMTP id 666691A0588 for <ietf@ietf.org>; Fri, 31 Jan 2014 03:53:44 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=15721; q=dns/txt; s=iport; t=1391169221; x=1392378821; h=message-id:date:from:mime-version:to:subject:references: in-reply-to; bh=lzbtIfMSZtjqJ2MjXsIPYze2kKjPXIyo/foSYgck90w=; b=YsSL4v8cJt7ttblHtnjPwL6dC/SgBeZJvlavChZbqjox7jzt7+TS9n4Q VCHiCLqz0NfDJSymHKuuXHb/4iPTsY8ECVzXuFOl498rmOUm7QPcjPBPL CBzUoMASz5U3Qxto+AQYohzRDZX32gXkH04PDGJRhq+9lXplpFlMZlPCw E=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AhYFAGyO61KQ/khR/2dsb2JhbABZgkhEOL4NgQQWdIIlAQEBAwFuCg0ECxEEAQEBCRYEBAcJAwIBAgE0CQgHDAYCAQEXh2IIDcx3F44gCgEGAVcGhDIEmCqBMoUWhBaHQ4FvgT87gSwBCBc
X-IronPort-AV: E=Sophos;i="4.95,757,1384300800"; d="scan'208,217";a="4471395"
Received: from ams-core-1.cisco.com ([144.254.72.81]) by aer-iport-1.cisco.com with ESMTP; 31 Jan 2014 11:53:39 +0000
Received: from [10.60.67.88] (ams-bclaise-8917.cisco.com [10.60.67.88]) by ams-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id s0VBrdAt026829; Fri, 31 Jan 2014 11:53:39 GMT
Message-ID: <52EB8EC3.3050904@cisco.com>
Date: Fri, 31 Jan 2014 12:53:39 +0100
From: Benoit Claise <bclaise@cisco.com>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0
MIME-Version: 1.0
To: adrian@olddog.co.uk, ietf@ietf.org
Subject: Re: Last Call: <draft-yourtchenko-cisco-ies-09.txt> (Cisco Specific Information Elements reused in IPFIX) to Informational RFC
References: <20140121123308.17385.36578.idtracker@ietfa.amsl.com> <029b01cf1a0b$707d5c60$51781520$@olddog.co.uk> <52E6F676.9020104@cisco.com> <033501cf1c1a$80089fd0$8019df70$@olddog.co.uk>
In-Reply-To: <033501cf1c1a$80089fd0$8019df70$@olddog.co.uk>
Content-Type: multipart/alternative; boundary="------------070804050904050204010203"
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: IETF-Discussion <ietf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ietf>, <mailto:ietf-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ietf/>
List-Post: <mailto:ietf@ietf.org>
List-Help: <mailto:ietf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 31 Jan 2014 11:53:48 -0000
On 28/01/2014 12:17, Adrian Farrel wrote: > Thanks Benoit, > > And I am not much concerned with the process here as with the meaning of the > IETF last call. > > Reading the document, I don't understand what would happen if I found something > that I thought should be different. It looks to me that this is a record of what > has been implemented and deployed. That is fine and good, but I don't see what > my review is supposed to give as input. > > It seems to me that either this is an IETF document describing some IPFIX > widgets (drop all the Cisco stuff, get the WG to agree they want the feature, > and let the IETF do a proper review probably as Standards Track) or it is a > record of what Cisco did (continue to publish it, but don't ask for review of > the content). If I would have to chose between, this is closer to the later. I meant closer, because there is an important clarification here: the review of BCP 184 "Guidelines for Authors and Reviewers of IP Flow Information Export (IPFIX) Information Elements" must be done. And the best way to have reviews from more people, not only the IPFIX IE doctors, was to present the work to the IPFIX WG (this was done several times). So you should see this document as a clean up of the range 1-127, which was allocated to NetFlow v9 at the time, while the IPFIX information elements were standardized. That lead to some IPFIX information elements being deprecated in that range, because there were better standardized solutions: - samplingInterval, samplingAlgorithm, classNamestandardized in PSAMP - layer2packetSectionOffset, layer2packetSectionSize, layer2packetSectionData standardized in draft-ietf-ipfix-data-link-layer-monitoring-08 <https://datatracker.ietf.org/doc/draft-ietf-ipfix-data-link-layer-monitoring/> (recently in RFC editor queue) What would have been really wrong is to try to publish the draft years ago, via the ISE, and pushing proprietary information elements. Regarding one of your question in the different email: The question might arise as to whether this document is supposed to update 3954. Not sure that question makes sense. NetFlow is a confusing term as it covers at the same time the Metering Process, the Exporting Process, and Information Elements (In IPFIX, there are clear distinctions between those terms). This draft doesn't update RFC 3954: there is no NetFlow 9.x. This draft updates the information model (read the IPFIX information elements) used by IPFIX and NetFlow v9 export protocol. Regards, Benoit > > Joel points out that it is valuable to check that the publication of this > document doesn't break anything else. I think that is a fine answer to my > question and would ask that, in future, when the scope or intent of a last call > is limited, that limit be explicitly called out in the last call so that no-one > waste review effort. I also think that when the RFC is published it should not > use boilerplate that says the document is a product of the IETF if the IETF did > not have the opportunity to edit the technical content. It would be better to > say that the IETF had consensus to publish the document but that it is not a > product of the IETF. > > Cheers, > Adrian > >> -----Original Message----- >> From: Benoit Claise [mailto:bclaise@cisco.com] >> Sent: 28 January 2014 00:15 >> To: adrian@olddog.co.uk; ietf@ietf.org >> Subject: Re: Last Call: <draft-yourtchenko-cisco-ies-09.txt> (Cisco Specific >> Information Elements reused in IPFIX) to Informational RFC >> >> Adrian, >> >> Not an answer to the process question, but some background information >> on this draft. >> This draft, which is now 3 years old, has been evolving with the IPFIX >> standardization. >> For example, looking at >> http://tools.ietf.org/rfcdiff?url2=draft-yourtchenko-cisco-ies-09.txt, >> you can see the interaction with the IPFIX WG document >> ietf-ipfix-data-link-layer-monitoring: now that >> ietf-ipfix-data-link-layer-monitoring is in the RFC editor queue, the >> draft has been simplified, and some IPFIX Information Elements in the >> range 1-127 became deprecated. >> This explains why the draft has been presented and reviewed multiple >> times in the IPFIX WG, and also why it would benefit from a wider review >> than the independent stream. >> >> Regards, Benoit (as draft author) >> >> >>> Hi, >>> >>> I have a process question on this last call which is not clear from the last >>> call text. >>> >>> Are we being asked to consider whether publication of this document is > useful, >>> or are we being asked for IETF consensus on the *content* of the document? >>> >>> It seems from the document that the content is descriptive of something >>> implemented by a single vendor. I applaud putting that information into the >>> public domain, but I don't understand the meaning of IETF consensus with >> respect >>> to this document. >>> >>> Thanks, >>> Adrian >>> >>>> -----Original Message----- >>>> From: IETF-Announce [mailto:ietf-announce-bounces@ietf.org] On Behalf Of >> The >>>> IESG >>>> Sent: 21 January 2014 12:33 >>>> To: IETF-Announce >>>> Subject: Last Call: <draft-yourtchenko-cisco-ies-09.txt> (Cisco Specific >>>> Information Elements reused in IPFIX) to Informational RFC >>>> >>>> >>>> The IESG has received a request from an individual submitter to consider >>>> the following document: >>>> - 'Cisco Specific Information Elements reused in IPFIX' >>>> <draft-yourtchenko-cisco-ies-09.txt> as Informational RFC >>>> >>>> The IESG plans to make a decision in the next few weeks, and solicits >>>> final comments on this action. Please send substantive comments to the >>>> ietf@ietf.org mailing lists by 2014-02-18. 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. >>>> >>>> Abstract >>>> >>>> >>>> This document describes some additional Information Elements of Cisco >>>> Systems, Inc. that are not listed in RFC3954. >>>> >>>> >>>> >>>> >>>> The file can be obtained via >>>> http://datatracker.ietf.org/doc/draft-yourtchenko-cisco-ies/ >>>> >>>> IESG discussion can be tracked via >>>> http://datatracker.ietf.org/doc/draft-yourtchenko-cisco-ies/ballot/ >>>> >>>> >>>> No IPR declarations have been submitted directly on this I-D. >>> . >>> > . >
- RE: Last Call: <draft-yourtchenko-cisco-ies-09.tx… Adrian Farrel
- Re: Last Call: <draft-yourtchenko-cisco-ies-09.tx… Eggert, Lars
- Re: Last Call: <draft-yourtchenko-cisco-ies-09.tx… Eggert, Lars
- Re: Last Call: <draft-yourtchenko-cisco-ies-09.tx… Thomas Narten
- Re: Last Call: <draft-yourtchenko-cisco-ies-09.tx… Benoit Claise
- Re: Last Call: <draft-yourtchenko-cisco-ies-09.tx… Pete Resnick
- Re: Last Call: <draft-yourtchenko-cisco-ies-09.tx… Stephen Farrell
- Re: Last Call: <draft-yourtchenko-cisco-ies-09.tx… Pete Resnick
- Re: Last Call: <draft-yourtchenko-cisco-ies-09.tx… Stephen Farrell
- Re: Last Call: <draft-yourtchenko-cisco-ies-09.tx… Dave Crocker
- Re: Last Call: <draft-yourtchenko-cisco-ies-09.tx… joel jaeggli
- Re: Last Call: <draft-yourtchenko-cisco-ies-09.tx… John C Klensin
- Re: Last Call: <draft-yourtchenko-cisco-ies-09.tx… Benoit Claise
- RE: Last Call: <draft-yourtchenko-cisco-ies-09.tx… Adrian Farrel
- Re: Last Call: <draft-yourtchenko-cisco-ies-09.tx… Spencer Dawkins at IETF
- Re: Last Call: <draft-yourtchenko-cisco-ies-09.tx… John C Klensin
- Re: Last Call: <draft-yourtchenko-cisco-ies-09.tx… Spencer Dawkins
- RE: Last Call: <draft-yourtchenko-cisco-ies-09.tx… Adrian Farrel
- Re: Last Call: <draft-yourtchenko-cisco-ies-09.tx… Brian Trammell
- Re: Last Call: <draft-yourtchenko-cisco-ies-09.tx… Benoit Claise
- Re: Last Call: <draft-yourtchenko-cisco-ies-09.tx… Andrew Feren
- Re: Last Call: <draft-yourtchenko-cisco-ies-09.tx… joel jaeggli
- RE: Last Call: <draft-yourtchenko-cisco-ies-09.tx… Adrian Farrel
- Re: Last Call: <draft-yourtchenko-cisco-ies-09.tx… Abdussalam Baryun
- RE: Last Call: <draft-yourtchenko-cisco-ies-09.tx… Andrew Yourtchenko
- RE: Last Call: <draft-yourtchenko-cisco-ies-09.tx… Andrew Feren
- RE: Last Call: <draft-yourtchenko-cisco-ies-09.tx… Andrew Feren