Re: [IPFIX] proposal for IPFIX charter update -> Internet Standard
Benoit Claise <bclaise@cisco.com> Tue, 13 September 2011 15:33 UTC
Return-Path: <bclaise@cisco.com>
X-Original-To: ipfix@ietfa.amsl.com
Delivered-To: ipfix@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ADAAF21F8B76 for <ipfix@ietfa.amsl.com>; Tue, 13 Sep 2011 08:33:34 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.476
X-Spam-Level:
X-Spam-Status: No, score=-2.476 tagged_above=-999 required=5 tests=[AWL=0.123, BAYES_00=-2.599]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bF1l+5Y+h7+K for <ipfix@ietfa.amsl.com>; Tue, 13 Sep 2011 08:33:30 -0700 (PDT)
Received: from av-tac-bru.cisco.com (weird-brew.cisco.com [144.254.15.118]) by ietfa.amsl.com (Postfix) with ESMTP id 2D11721F8B9B for <ipfix@ietf.org>; Tue, 13 Sep 2011 08:33:30 -0700 (PDT)
X-TACSUNS: Virus Scanned
Received: from strange-brew.cisco.com (localhost.cisco.com [127.0.0.1]) by av-tac-bru.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id p8DFZOpK027708; Tue, 13 Sep 2011 17:35:24 +0200 (CEST)
Received: from [10.60.67.83] (ams-bclaise-8912.cisco.com [10.60.67.83]) by strange-brew.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id p8DFZLxn009371; Tue, 13 Sep 2011 17:35:22 +0200 (CEST)
Message-ID: <4E6F7839.4080908@cisco.com>
Date: Tue, 13 Sep 2011 17:35:21 +0200
From: Benoit Claise <bclaise@cisco.com>
User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:6.0.2) Gecko/20110902 Thunderbird/6.0.2
MIME-Version: 1.0
To: "Romascanu, Dan (Dan)" <dromasca@avaya.com>
References: <CA8092FA.172F7%quittek@neclab.eu> <4E6F4818.2020501@cisco.com> <EDC652A26FB23C4EB6384A4584434A04039D5321@307622ANEX5.global.avaya.com>
In-Reply-To: <EDC652A26FB23C4EB6384A4584434A04039D5321@307622ANEX5.global.avaya.com>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
Cc: Nevil Brownlee <n.brownlee@auckland.ac.nz>, IETF IPFIX Working Group <ipfix@ietf.org>
Subject: Re: [IPFIX] proposal for IPFIX charter update -> Internet Standard
X-BeenThere: ipfix@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: IPFIX WG discussion list <ipfix.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ipfix>, <mailto:ipfix-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ipfix>
List-Post: <mailto:ipfix@ietf.org>
List-Help: <mailto:ipfix-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ipfix>, <mailto:ipfix-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 13 Sep 2011 15:33:34 -0000
Hi Dan, Good suggestion. Regards, Benoit. > Hi, > > I suggest to say 'advance RFC 5101 and RFC 5102 to the next stage of > standardization on the standards track'. > > The question that will be asked at some point is whether IPFIX reached > the 'wide deployment' required by a Full Standard, but this is something > we need to care about when and if we reach that phase and the process > was already transitioned to two levels. > > Regards, > > Dan > > > >> -----Original Message----- >> From: Benoit Claise [mailto:bclaise@cisco.com] >> Sent: Tuesday, September 13, 2011 3:10 PM >> To: Juergen Quittek; Nevil Brownlee; Romascanu, Dan (Dan) >> Cc: IETF IPFIX Working Group >> Subject: Re: [IPFIX] proposal for IPFIX charter update -> Internet >> Standard >> >> Juergen, Nevil, Dan, >> >> In light of >> http://tools.ietf.org/html/draft-housley-two-maturity-levels-08, which >> is in the RFC-editor queue, should we shoot for RFC5101bis and >> RFC5102bis as Internet Standard. >> Maybe a sentence in the charter such as. If >> draft-housley-two-maturity-levels-08 is published in time for the WG >> milestones, the revised RFC5101 and RFC5102 should target Internet >> Standard status" >> >> Regards, Benoit. >>> Dear all, >>> >>> At our session in Quebec we discussed candidates >>> for new IPFIX work items. Based on this discussion, >>> Nevil and I drafted an update of our charter that >>> you can find below. >>> >>> Please have a look at it and send us your comments. >>> >>> Thanks, >>> >>> Juergen >>> >>> >>> IP Flow Information Export (ipfix) >>> >>> >>> Description of Working Group >>> >>> >>> The IPFIX working group has specified the information model (to >> describe >>> IP flows) and the IPFIX protocol (to transfer IP flow data from > IPFIX >>> exporters to collectors). Several implementers have already built >>> applications using the IPFIX protocol. As a result of a series of >> IPFIX >>> interoperability testing events the WG has produced guidelines for >> IPFIX >>> implementation and testing as well as recommendations for handling >>> special cases such as bidirectional flow reporting and reducing >>> redundancy in flow records. >>> >>> The IPFIX WG has developed a mediation framework, that defines IPFIX >>> mediators for processing flow records for various purposes including >>> aggregation, anonymization, etc. For configuring IPFIX devices, a >> YANG >>> module has been developed. >>> >>> 1. Having a solid standardized base for IPFIX deployment and >> operation >>> and several exiting implementations, the IPFIX WG will revisit the >> IPFIX >>> protocol specifications (RFC 5101) and the IPFIX information element >>> specification (RFC 5102) in order to advance them to draft standard. >>> >>> 2. For giving guidelines to developers of new IPFIX information >>> elements and for better defining the process of registering new >>> information elements at IANA the IPFIX WG will create an information >>> element developers guideline document. >>> >>> 3. The export of IPFIX flow records from IPFIX mediators introduces > a >>> set of potential issues at the protocol level, such as the loss of >>> information on the original exporter, loss of base time information, >>> loss of original options template information, etc. The IPFIX WG > will >>> define common ways to deal with these issues, by specifying >> guidelines >>> for the use of the IPFIX protocol on IPFIX mediators. >>> >>> 4. For supporting the aggregation of flow records at IPFIX mediators >>> the IPFIX WG will define how to export 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. >>> 5. The IPFIX WG will investigate the use of the IPFIX protocol for >>> exporting >>> MIB objects, avoiding the need to define new IPFIX information >> elements >>> for existing management information base objects that are already >> fully >>> specified. This method requires the specification of new template > set >>> and options template sets to allow the export of MIB objects along >>> with IPFIX information elements. >>> >>> 6. The IPFIX MIB module (RFC 5815) defined a way to register packet >>> selector functions at IANA. The WG agreed that another method would >>> be preferable that requires a minor change of RFC 5815. The IPFIX WG >>> will produce a new version of RFC 5815 with small modifications of >>> the IANA actions and DESCRIPTION clauses in the the MIB modules. >>> >>> Oct 2011 Publish draft on guidelines for IE doctors >>> Oct 2011 Publish draft on IPFIX use at mediators >>> Oct 2011 Publish draft on intermediate aggregation >>> Oct 2011 Publish draft on exporting MIB objects >>> Oct 2011 Publish draft on data link IEs >>> Dec 2011 Publish draft revising RFC 5101 >>> Dec 2011 Publish draft revising RFC 5102 >>> >>> Apr 2012 Submit guidelines for IE doctors for publication as >>> Informational BCP RFC >>> Apr 2012 Submit draft on IPFIX use at mediators for publication > as >>> Standards track RFC >>> Apr 2012 Submit draft on intermediate aggregation for publication >> as >>> Standards track RFC >>> Apr 2012 Submit draft on data link IEs for publication as >> Standards >>> track RFC >>> Apr 2012 Submit draft revising RFC 5101 for publication as >> Standards >>> track RFC >>> Apr 2012 Submit draft revising RFC 5102 for publication as >> Standards >>> track RFC >>> Sep 2012 Submit draft on exporting MIB objects for publication as >>> Standards track RFC >>> >>> >>> _______________________________________________ >>> IPFIX mailing list >>> IPFIX@ietf.org >>> https://www.ietf.org/mailman/listinfo/ipfix
- [IPFIX] proposal for IPFIX charter update Juergen Quittek
- Re: [IPFIX] proposal for IPFIX charter update Brian Trammell
- Re: [IPFIX] proposal for IPFIX charter update Romascanu, Dan (Dan)
- Re: [IPFIX] proposal for IPFIX charter update Benoit Claise
- Re: [IPFIX] proposal for IPFIX charter update Benoit Claise
- Re: [IPFIX] proposal for IPFIX charter update Gerhard Muenz
- Re: [IPFIX] proposal for IPFIX charter update Shingo KASHIMA
- Re: [IPFIX] proposal for IPFIX charter update -> … Benoit Claise
- Re: [IPFIX] proposal for IPFIX charter update -> … Romascanu, Dan (Dan)
- Re: [IPFIX] proposal for IPFIX charter update -> … Benoit Claise
- Re: [IPFIX] proposal for IPFIX charter update Benoit Claise
- Re: [IPFIX] proposal for IPFIX charter update Nevil Brownlee
- Re: [IPFIX] proposal for IPFIX charter update Juergen Quittek
- Re: [IPFIX] proposal for IPFIX charter update Juergen Quittek
- Re: [IPFIX] proposal for IPFIX charter update Paul Aitken
- Re: [IPFIX] proposal for IPFIX charter update Ben Claise
- Re: [IPFIX] proposal for IPFIX charter update Juergen Quittek
- Re: [IPFIX] proposal for IPFIX charter update Benoit Claise
- Re: [IPFIX] proposal for IPFIX charter update Brian Trammell
- Re: [IPFIX] proposal for IPFIX charter update Benoit Claise
- Re: [IPFIX] proposal for IPFIX charter update Juergen Quittek
- Re: [IPFIX] proposal for IPFIX charter update Brian Trammell
- Re: [IPFIX] proposal for IPFIX charter update Juergen Quittek
- Re: [IPFIX] proposal for IPFIX charter update Benoit Claise
- Re: [IPFIX] proposal for IPFIX charter update Benoit Claise