Re: [IPFIX] proposal for IPFIX charter update

"Romascanu, Dan (Dan)" <dromasca@avaya.com> Mon, 29 August 2011 08:19 UTC

Return-Path: <dromasca@avaya.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 F03D021F85B9 for <ipfix@ietfa.amsl.com>; Mon, 29 Aug 2011 01:19:04 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.904
X-Spam-Level:
X-Spam-Status: No, score=-102.904 tagged_above=-999 required=5 tests=[AWL=-0.305, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
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 IXWQ2TDvb3bc for <ipfix@ietfa.amsl.com>; Mon, 29 Aug 2011 01:19:04 -0700 (PDT)
Received: from p-us1-iereast-outbound.us1.avaya.com (p-us1-iereast-outbound.us1.avaya.com [135.11.29.13]) by ietfa.amsl.com (Postfix) with ESMTP id 1905F21F856A for <ipfix@ietf.org>; Mon, 29 Aug 2011 01:19:03 -0700 (PDT)
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: ArAAAA9LW07GmAcF/2dsb2JhbABCmBqPXneBQAEBAQEDAQEBDx4KNBcEAgEIDQQEAQELBgwLAQYBJh8JCAIEAQkJCBqHVJpFApsuhWxgBJhLi1o
X-IronPort-AV: E=Sophos;i="4.68,296,1312171200"; d="scan'208";a="204497011"
Received: from unknown (HELO co300216-co-erhwest.avaya.com) ([198.152.7.5]) by p-us1-iereast-outbound.us1.avaya.com with ESMTP; 29 Aug 2011 04:20:26 -0400
Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.14]) by co300216-co-erhwest-out.avaya.com with ESMTP; 29 Aug 2011 04:16:11 -0400
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, 29 Aug 2011 10:20:23 +0200
Message-ID: <EDC652A26FB23C4EB6384A4584434A04038D6612@307622ANEX5.global.avaya.com>
In-Reply-To: <CA8092FA.172F7%quittek@neclab.eu>
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: [IPFIX] proposal for IPFIX charter update
Thread-Index: AQHMZggzIq+uoU73cUmzabOsxYu6T5Uze7rA
References: <CA8092FA.172F7%quittek@neclab.eu>
From: "Romascanu, Dan (Dan)" <dromasca@avaya.com>
To: Juergen Quittek <Quittek@neclab.eu>, IETF IPFIX Working Group <ipfix@ietf.org>
Subject: Re: [IPFIX] proposal for IPFIX charter update
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: Mon, 29 Aug 2011 08:19:05 -0000

Editorial comments: 

s/exiting implementations/existing implementations/
s/For giving guidelines/In order to provide guidelines/
s/For supporting the aggregation/In order to support the aggregation/
s/ the the MIB modules/the MIB modules/
s/draft/Internet-Draft/ (several times in the milestones)

Regards,

Dan

> -----Original Message-----
> From: ipfix-bounces@ietf.org [mailto:ipfix-bounces@ietf.org] On Behalf
> Of Juergen Quittek
> Sent: Monday, August 29, 2011 7:58 AM
> To: IETF IPFIX Working Group
> Subject: [IPFIX] proposal for IPFIX charter update
> 
> 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