From Quittek@neclab.eu Mon Oct 3 12:35:25 2011 Return-Path: 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 8504021F8E09 for ; Mon, 3 Oct 2011 12:35:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.386 X-Spam-Level: X-Spam-Status: No, score=-102.386 tagged_above=-999 required=5 tests=[AWL=0.213, 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 yHStE1WKt2qV for ; Mon, 3 Oct 2011 12:35:24 -0700 (PDT) Received: from mailer1.neclab.eu (mailer1.neclab.eu [195.37.70.40]) by ietfa.amsl.com (Postfix) with ESMTP id 498E821F8E15 for ; Mon, 3 Oct 2011 12:35:23 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by mailer1.neclab.eu (Postfix) with ESMTP id 76CB7280001D6; Mon, 3 Oct 2011 21:38:25 +0200 (CEST) X-Virus-Scanned: Amavisd on Debian GNU/Linux (atlas1.office.hd) Received: from mailer1.neclab.eu ([127.0.0.1]) by localhost (atlas1.office.hd [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gwXuPxGlYKgn; Mon, 3 Oct 2011 21:38:25 +0200 (CEST) Received: from METHONE.office.hd (Methone.office.hd [192.168.24.54]) by mailer1.neclab.eu (Postfix) with ESMTP id 4B2452800018F; Mon, 3 Oct 2011 21:38:10 +0200 (CEST) Received: from DAPHNIS.office.hd ([169.254.2.240]) by METHONE.office.hd ([192.168.24.54]) with mapi id 14.01.0323.003; Mon, 3 Oct 2011 21:37:49 +0200 From: Juergen Quittek To: Nevil Brownlee , Benoit Claise Thread-Topic: [IPFIX] proposal for IPFIX charter update Thread-Index: AQHMggPuMgSqGqa2u0mSLPg+e4yMCA== Date: Mon, 3 Oct 2011 19:37:49 +0000 Message-ID: In-Reply-To: Accept-Language: de-DE, en-US Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.13.0.110805 x-originating-ip: [10.7.0.92] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: IETF IPFIX Working Group 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Oct 2011 19:35:25 -0000 Dear all, Below please find an update of the proposed IPFIX charter update. It addresses all comments posted on the list. The only major change is adding item 7 on link layer IEs. Please send you comments on this version until next Monday, Oct 10. 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 existing 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. All following items 2.-7. will be in line with the revised versions of the IPFIX protocol specifications and the IPFIX information model. 2. In order to provide 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.In order to support 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 MIB modules. 7. Operational experiences showed that it would be useful to define several new information elements for data link monitoring covering frame size, type, sections of frames, and VLAN information. The IPFIX WG will create a document defining these new information elements. Oct 2011 Publish Internet-Draftt on guidelines for IE doctors Oct 2011 Publish Internet-Draft on IPFIX use at mediators Oct 2011 Publish Internet-Draft on intermediate aggregation Oct 2011 Publish Internet-Draft on exporting MIB objects Oct 2011 Publish Internet-Draft on data link IEs Oct 2011 Publish Internet-Draft on revised IPFIX MIB Dec 2011 Publish Internet-Draft revising RFC 5101 Dec 2011 Publish Internet-Draft revising RFC 5102 Apr 2012 Submit guidelines for IE doctors for publication as Informational BCP RFC Apr 2012 Submit IPFIX use at mediators for publication as Standards track RFC Apr 2012 Submit intermediate aggregation for publication as Standards track RFC Apr 2012 Submit data link IEs for publication as Standards track RFC Apr 2012 Submit revised RFC 5101 for publication as Standards track RFC Apr 2012 Submit revised IPFIX MIB for publications as Standards track RFC Apr 2012 Submit revised RFC 5102 for publication as Standards track RFC Sep 2012 Submit export of MIB objects for publication as Standards track RFC On 30.09.11 09:18, "Juergen Quittek" wrote: >Nevil, > >Thanks for the summary. >I will post a new version of the charter at the weekend. > > Juergen > >On 30.09.11 00:10, "Nevil Brownlee" wrote: > >> >>Hi all: >> >>Juergen posted the proposed new IPFIX charter at the end of August. >>I've only seen one comment on it, which was "what happened to the >>Link Layer IEs draft?" >> >>Looking at the minutes from our meeting in Quebec, we said >>"We discussed whether this could be a 'trial run for the >>IE Doctors,' or a WG item. We reached consensus for it as a WG item, >>with the proviso that it will need views from Layer 2 domain experts, >>e.g. IEEE 802.1." >> >>So Juergen, please add this as one more charter item. >> >>With that, I think we're ready to ask Dan to take it to IESG for >>approval. >> >>Cheers, Nevil >> >>PS: it's really good to see lots of discussion on the IPFIX list >> about improvements to 5101 et al :-) >> >> >>On 29/09/11 2:40 AM, Benoit Claise wrote: >>> IPFIX chairs, >>>> >>>> Hi Juergen, >>>> >>>> The IPFIX configuration data model is pending because of the IPFIX and >>>> PSAMP MIBs. IMO, solving the SELECTOR MIB issue should be of highest >>>> priority, and a solution be published before any other new draft. >>> I agree. >>> >>> Btw, where is the new charter? ;-) There is always a tendency to delay >>> work for which there is no deadlines... >>> >>> Regards, Benoit. >>>> (I already see IPFIX config being outdated by RFC5101/5102bis before >>>> it ever becomes RFC...) >>>> >>>> Regards, >>>> Gerhard >>>> >>>> >>>> On 29.08.2011 06:57, Juergen Quittek wrote: >>>>> 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 mailing list >>>> IPFIX@ietf.org >>>> https://www.ietf.org/mailman/listinfo/ipfix >>> >>> _______________________________________________ >>> IPFIX mailing list >>> IPFIX@ietf.org >>> https://www.ietf.org/mailman/listinfo/ipfix >> >> >>--=20 >>--------------------------------------------------------------------- >> 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 > >_______________________________________________ >IPFIX mailing list >IPFIX@ietf.org >https://www.ietf.org/mailman/listinfo/ipfix From paitken@cisco.com Mon Oct 3 14:17:19 2011 Return-Path: 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 7F85921F8BB9 for ; Mon, 3 Oct 2011 14:17:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.546 X-Spam-Level: X-Spam-Status: No, score=-10.546 tagged_above=-999 required=5 tests=[AWL=0.053, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] 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 37Bbr9GlzbVZ for ; Mon, 3 Oct 2011 14:17:18 -0700 (PDT) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by ietfa.amsl.com (Postfix) with ESMTP id A6F9E21F8BB8 for ; Mon, 3 Oct 2011 14:17:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=paitken@cisco.com; l=13101; q=dns/txt; s=iport; t=1317676821; x=1318886421; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=f6oD0SIBphVirg5apAiKeK124zJaurmgJZ1V1aL6kCw=; b=lHoYdGK238UHi9CuLZIVoMO+sNT6AY6TEaLLDq3MQSnLMNL537XXE9ak FqAIBH+0yW4tvM6S5n0pCSSfJzQC6vmUsJL++b7AzwI/rgPReLfbqg+49 jWEKws2h/Jk1+dl2+0fzGUcjbTiirRg2hGWDWoiyUvT9xxBTKaH1YM9sz g=; X-IronPort-AV: E=Sophos;i="4.68,481,1312156800"; d="scan'208";a="118165266" Received: from ams-core-1.cisco.com ([144.254.72.81]) by ams-iport-1.cisco.com with ESMTP; 03 Oct 2011 21:20:20 +0000 Received: from [10.61.85.126] (ams3-vpn-dhcp5503.cisco.com [10.61.85.126]) by ams-core-1.cisco.com (8.14.3/8.14.3) with ESMTP id p93LKJOD013753; Mon, 3 Oct 2011 21:20:19 GMT Message-ID: <4E8A2714.7000104@cisco.com> Date: Mon, 03 Oct 2011 22:20:20 +0100 From: Paul Aitken User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.23) Gecko/20110922 Lightning/1.0b2 Thunderbird/3.1.15 MIME-Version: 1.0 To: Juergen Quittek References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Nevil Brownlee , IETF IPFIX Working Group 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Oct 2011 21:17:19 -0000 Dear All, Regarding item #7: There's no need for the WG to create a document just to define new fields, since this can be done simply by approaching IANA. Rather, the goal of this item should be to define how to monitor and report data link information in IPFIX. Part of the task will be the clear definition of a suitable set of Information Elements. Thanks, P. On 03/10/11 20:37, Juergen Quittek wrote: > Dear all, > > Below please find an update of the proposed IPFIX charter update. > It addresses all comments posted on the list. > The only major change is adding item 7 on link layer IEs. > > Please send you comments on this version until next Monday, Oct 10. > > 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 existing 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. > > All following items 2.-7. will be in line with the revised versions > of the IPFIX protocol specifications and the IPFIX information model. > > 2. In order to provide 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.In order to support 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 MIB modules. > > 7. Operational experiences showed that it would be useful to define > several new information elements for data link monitoring covering > frame size, type, sections of frames, and VLAN information. The IPFIX > WG will create a document defining these new information elements. > > > Oct 2011 Publish Internet-Draftt on guidelines for IE doctors > Oct 2011 Publish Internet-Draft on IPFIX use at mediators > Oct 2011 Publish Internet-Draft on intermediate aggregation > Oct 2011 Publish Internet-Draft on exporting MIB objects > Oct 2011 Publish Internet-Draft on data link IEs > Oct 2011 Publish Internet-Draft on revised IPFIX MIB > Dec 2011 Publish Internet-Draft revising RFC 5101 > Dec 2011 Publish Internet-Draft revising RFC 5102 > > Apr 2012 Submit guidelines for IE doctors for publication as > Informational BCP RFC > Apr 2012 Submit IPFIX use at mediators for publication as > Standards track RFC > Apr 2012 Submit intermediate aggregation for publication as > Standards track RFC > Apr 2012 Submit data link IEs for publication as > Standards track RFC > Apr 2012 Submit revised RFC 5101 for publication as > Standards track RFC > Apr 2012 Submit revised IPFIX MIB for publications as > Standards track RFC > Apr 2012 Submit revised RFC 5102 for publication as > Standards track RFC > Sep 2012 Submit export of MIB objects for publication as > Standards track RFC > > > > > On 30.09.11 09:18, "Juergen Quittek" wrote: > >> Nevil, >> >> Thanks for the summary. >> I will post a new version of the charter at the weekend. >> >> Juergen >> >> On 30.09.11 00:10, "Nevil Brownlee" wrote: >> >>> Hi all: >>> >>> Juergen posted the proposed new IPFIX charter at the end of August. >>> I've only seen one comment on it, which was "what happened to the >>> Link Layer IEs draft?" >>> >>> Looking at the minutes from our meeting in Quebec, we said >>> "We discussed whether this could be a 'trial run for the >>> IE Doctors,' or a WG item. We reached consensus for it as a WG item, >>> with the proviso that it will need views from Layer 2 domain experts, >>> e.g. IEEE 802.1." >>> >>> So Juergen, please add this as one more charter item. >>> >>> With that, I think we're ready to ask Dan to take it to IESG for >>> approval. >>> >>> Cheers, Nevil >>> >>> PS: it's really good to see lots of discussion on the IPFIX list >>> about improvements to 5101 et al :-) >>> >>> >>> On 29/09/11 2:40 AM, Benoit Claise wrote: >>>> IPFIX chairs, >>>>> Hi Juergen, >>>>> >>>>> The IPFIX configuration data model is pending because of the IPFIX and >>>>> PSAMP MIBs. IMO, solving the SELECTOR MIB issue should be of highest >>>>> priority, and a solution be published before any other new draft. >>>> I agree. >>>> >>>> Btw, where is the new charter? ;-) There is always a tendency to delay >>>> work for which there is no deadlines... >>>> >>>> Regards, Benoit. >>>>> (I already see IPFIX config being outdated by RFC5101/5102bis before >>>>> it ever becomes RFC...) >>>>> >>>>> Regards, >>>>> Gerhard >>>>> >>>>> >>>>> On 29.08.2011 06:57, Juergen Quittek wrote: >>>>>> 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 mailing list >>>>> IPFIX@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/ipfix >>>> _______________________________________________ >>>> IPFIX mailing list >>>> IPFIX@ietf.org >>>> https://www.ietf.org/mailman/listinfo/ipfix >>> >>> -- >>> --------------------------------------------------------------------- >>> 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 >> _______________________________________________ >> IPFIX mailing list >> IPFIX@ietf.org >> https://www.ietf.org/mailman/listinfo/ipfix > _______________________________________________ > IPFIX mailing list > IPFIX@ietf.org > https://www.ietf.org/mailman/listinfo/ipfix From bclaise@cisco.com Mon Oct 3 14:35:38 2011 Return-Path: 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 1381D21F8EA5 for ; Mon, 3 Oct 2011 14:35:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.473 X-Spam-Level: X-Spam-Status: No, score=-2.473 tagged_above=-999 required=5 tests=[AWL=0.125, BAYES_00=-2.599, HTML_MESSAGE=0.001] 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 yAMzDpP+K7Yc for ; Mon, 3 Oct 2011 14:35:36 -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 D5F2021F8E68 for ; Mon, 3 Oct 2011 14:35:35 -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 p93LcVZv023698; Mon, 3 Oct 2011 23:38:31 +0200 (CEST) Received: from [10.61.106.83] (dhcp-10-61-106-83.cisco.com [10.61.106.83]) by strange-brew.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id p93LcUU9001953; Mon, 3 Oct 2011 23:38:30 +0200 (CEST) Message-ID: <4E8A2B56.5090804@cisco.com> Date: Mon, 03 Oct 2011 23:38:30 +0200 From: Ben Claise User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1 MIME-Version: 1.0 To: Juergen Quittek References: In-Reply-To: Content-Type: multipart/alternative; boundary="------------010907090002010205050806" Cc: Nevil Brownlee , IETF IPFIX Working Group 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Oct 2011 21:35:38 -0000 This is a multi-part message in MIME format. --------------010907090002010205050806 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Juergen, One comment that was forgotten. See inline. > Dear all, > > Below please find an update of the proposed IPFIX charter update. > It addresses all comments posted on the list. > The only major change is adding item 7 on link layer IEs. > > Please send you comments on this version until next Monday, Oct 10. > > 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 existing 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. > > All following items 2.-7. will be in line with the revised versions > of the IPFIX protocol specifications and the IPFIX information model. > > 2. In order to provide 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. Here is the comment I made earlier in this email thread: "common ways", "specifying guidelines for the use of the IPFIX protocol": actually it's a real protocol specification, which will be standard track. Should we be more specific? Note that http://tools.ietf.org/html/draft-claise-ipfix-mediation-protocol-04 title is: Specification of the Protocol for IPFIX Mediations For example: 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 produce the protocol specifications in order to solve these IPFIX mediation specific problems. Regards, Benoit. > > 4.In order to support 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 MIB modules. > > 7. Operational experiences showed that it would be useful to define > several new information elements for data link monitoring covering > frame size, type, sections of frames, and VLAN information. The IPFIX > WG will create a document defining these new information elements. > > > Oct 2011 Publish Internet-Draftt on guidelines for IE doctors > Oct 2011 Publish Internet-Draft on IPFIX use at mediators > Oct 2011 Publish Internet-Draft on intermediate aggregation > Oct 2011 Publish Internet-Draft on exporting MIB objects > Oct 2011 Publish Internet-Draft on data link IEs > Oct 2011 Publish Internet-Draft on revised IPFIX MIB > Dec 2011 Publish Internet-Draft revising RFC 5101 > Dec 2011 Publish Internet-Draft revising RFC 5102 > > Apr 2012 Submit guidelines for IE doctors for publication as > Informational BCP RFC > Apr 2012 Submit IPFIX use at mediators for publication as > Standards track RFC > Apr 2012 Submit intermediate aggregation for publication as > Standards track RFC > Apr 2012 Submit data link IEs for publication as > Standards track RFC > Apr 2012 Submit revised RFC 5101 for publication as > Standards track RFC > Apr 2012 Submit revised IPFIX MIB for publications as > Standards track RFC > Apr 2012 Submit revised RFC 5102 for publication as > Standards track RFC > Sep 2012 Submit export of MIB objects for publication as > Standards track RFC > > > > > On 30.09.11 09:18, "Juergen Quittek" wrote: > >> Nevil, >> >> Thanks for the summary. >> I will post a new version of the charter at the weekend. >> >> Juergen >> >> On 30.09.11 00:10, "Nevil Brownlee" wrote: >> >>> Hi all: >>> >>> Juergen posted the proposed new IPFIX charter at the end of August. >>> I've only seen one comment on it, which was "what happened to the >>> Link Layer IEs draft?" >>> >>> Looking at the minutes from our meeting in Quebec, we said >>> "We discussed whether this could be a 'trial run for the >>> IE Doctors,' or a WG item. We reached consensus for it as a WG item, >>> with the proviso that it will need views from Layer 2 domain experts, >>> e.g. IEEE 802.1." >>> >>> So Juergen, please add this as one more charter item. >>> >>> With that, I think we're ready to ask Dan to take it to IESG for >>> approval. >>> >>> Cheers, Nevil >>> >>> PS: it's really good to see lots of discussion on the IPFIX list >>> about improvements to 5101 et al :-) >>> >>> >>> On 29/09/11 2:40 AM, Benoit Claise wrote: >>>> IPFIX chairs, >>>>> Hi Juergen, >>>>> >>>>> The IPFIX configuration data model is pending because of the IPFIX and >>>>> PSAMP MIBs. IMO, solving the SELECTOR MIB issue should be of highest >>>>> priority, and a solution be published before any other new draft. >>>> I agree. >>>> >>>> Btw, where is the new charter? ;-) There is always a tendency to delay >>>> work for which there is no deadlines... >>>> >>>> Regards, Benoit. >>>>> (I already see IPFIX config being outdated by RFC5101/5102bis before >>>>> it ever becomes RFC...) >>>>> >>>>> Regards, >>>>> Gerhard >>>>> >>>>> >>>>> On 29.08.2011 06:57, Juergen Quittek wrote: >>>>>> 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 mailing list >>>>> IPFIX@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/ipfix >>>> _______________________________________________ >>>> IPFIX mailing list >>>> IPFIX@ietf.org >>>> https://www.ietf.org/mailman/listinfo/ipfix >>> >>> -- >>> --------------------------------------------------------------------- >>> 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 >> _______________________________________________ >> IPFIX mailing list >> IPFIX@ietf.org >> https://www.ietf.org/mailman/listinfo/ipfix > > --------------010907090002010205050806 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Juergen,

One comment that was forgotten.
See inline.
Dear all,

Below please find an update of the proposed IPFIX charter update.
It addresses all comments posted on the list.
The only major change is adding item 7 on link layer IEs.

Please send you comments on this version until next Monday, Oct 10.

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 existing 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.

All following items 2.-7. will be in line with the revised versions
of the IPFIX protocol specifications and the IPFIX information model.

2. In order to provide 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.
Here is the comment I made earlier in this email thread:
"common ways", "specifying guidelines for the use of the IPFIX protocol": actually it's a real protocol specification, which will be standard track.
Should we be more specific?
Note that http://tools.ietf.org/html/draft-claise-ipfix-mediation-protocol-04 title is: Specification of the Protocol for IPFIX Mediations

For example:

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
produce the protocol specifications in order to solve these IPFIX mediation
specific problems.

Regards, Benoit.

4.In order to support 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 MIB modules.

7. Operational experiences showed that it would be useful to define
several new information elements for data link monitoring covering
frame size, type, sections of frames, and VLAN information. The IPFIX
WG will create a document defining these new information elements.


Oct 2011    Publish Internet-Draftt on guidelines for IE doctors
Oct 2011    Publish Internet-Draft on IPFIX use at mediators
Oct 2011    Publish Internet-Draft on intermediate aggregation
Oct 2011    Publish Internet-Draft on exporting MIB objects
Oct 2011    Publish Internet-Draft on data link IEs
Oct 2011    Publish Internet-Draft on revised IPFIX MIB
Dec 2011    Publish Internet-Draft revising RFC 5101
Dec 2011    Publish Internet-Draft revising RFC 5102

Apr 2012    Submit guidelines for IE doctors for publication as
            Informational BCP RFC
Apr 2012    Submit IPFIX use at mediators for publication as
            Standards track RFC
Apr 2012    Submit intermediate aggregation for publication as
            Standards track RFC
Apr 2012    Submit data link IEs for publication as
            Standards track RFC
Apr 2012    Submit revised RFC 5101 for publication as
            Standards track RFC
Apr 2012    Submit revised IPFIX MIB for publications as
            Standards track RFC
Apr 2012    Submit revised RFC 5102 for publication as
            Standards track RFC
Sep 2012    Submit export of MIB objects for publication as
            Standards track RFC




On 30.09.11 09:18, "Juergen Quittek" <Quittek@neclab.eu> wrote:


Nevil,

Thanks for the summary.
I will post a new version of the charter at the weekend.

   Juergen

On 30.09.11 00:10, "Nevil Brownlee" <n.brownlee@auckland.ac.nz> wrote:


Hi all:

Juergen posted the proposed new IPFIX charter at the end of August.
I've only seen one comment on it, which was "what happened to the
Link Layer IEs draft?"

Looking at the minutes from our meeting in Quebec, we said
"We discussed whether this could be a 'trial run for the
IE Doctors,' or a WG item.  We reached consensus for it as a WG item,
with the proviso that it will need views from Layer 2 domain experts,
e.g. IEEE 802.1."

So Juergen, please add this as one more charter item.

With that, I think we're ready to ask Dan to take it to IESG for
approval.

Cheers, Nevil

PS: it's really good to see lots of discussion on the IPFIX list
    about improvements to 5101 et al :-)


On 29/09/11 2:40 AM, Benoit Claise wrote:

IPFIX chairs,

Hi Juergen,

The IPFIX configuration data model is pending because of the IPFIX and
PSAMP MIBs. IMO, solving the SELECTOR MIB issue should be of highest
priority, and a solution be published before any other new draft.

I agree.

Btw, where is the new charter? ;-) There is always a tendency to delay
work for which there is no deadlines...

Regards, Benoit.

(I already see IPFIX config being outdated by RFC5101/5102bis before
it ever becomes RFC...)

Regards,
Gerhard


On 29.08.2011 06:57, Juergen Quittek wrote:

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 mailing list
IPFIX@ietf.org
https://www.ietf.org/mailman/listinfo/ipfix

_______________________________________________
IPFIX mailing list
IPFIX@ietf.org
https://www.ietf.org/mailman/listinfo/ipfix


-- 
---------------------------------------------------------------------
 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

_______________________________________________
IPFIX mailing list
IPFIX@ietf.org
https://www.ietf.org/mailman/listinfo/ipfix

--------------010907090002010205050806-- From Quittek@neclab.eu Sat Oct 8 10:21:05 2011 Return-Path: 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 D86EF21F8BB9 for ; Sat, 8 Oct 2011 10:21:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.393 X-Spam-Level: X-Spam-Status: No, score=-102.393 tagged_above=-999 required=5 tests=[AWL=0.205, BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 jHPwucOEy-fV for ; Sat, 8 Oct 2011 10:21:03 -0700 (PDT) Received: from mailer1.neclab.eu (mailer1.neclab.eu [195.37.70.40]) by ietfa.amsl.com (Postfix) with ESMTP id 4F5EA21F8B9C for ; Sat, 8 Oct 2011 10:21:03 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by mailer1.neclab.eu (Postfix) with ESMTP id 8387D280001AB; Sat, 8 Oct 2011 19:24:19 +0200 (CEST) X-Virus-Scanned: Amavisd on Debian GNU/Linux (atlas1.office.hd) Received: from mailer1.neclab.eu ([127.0.0.1]) by localhost (atlas1.office.hd [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7vrNjVkhObvn; Sat, 8 Oct 2011 19:24:19 +0200 (CEST) Received: from METHONE.office.hd (Methone.office.hd [192.168.24.54]) by mailer1.neclab.eu (Postfix) with ESMTP id 595BF280001A7; Sat, 8 Oct 2011 19:24:04 +0200 (CEST) Received: from DAPHNIS.office.hd ([169.254.2.240]) by METHONE.office.hd ([192.168.24.54]) with mapi id 14.01.0323.003; Sat, 8 Oct 2011 19:23:43 +0200 From: Juergen Quittek To: Ben Claise , IETF IPFIX Working Group Thread-Topic: [IPFIX] proposal for IPFIX charter update Thread-Index: AQHMhd8GGYH1F1+P9kOtXS8TLd5+ig== Date: Sat, 8 Oct 2011 17:23:42 +0000 Message-ID: In-Reply-To: <4E8A2B56.5090804@cisco.com> Accept-Language: de-DE, en-US Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.13.0.110805 x-originating-ip: [10.7.0.92] Content-Type: multipart/alternative; boundary="_000_CAB6351922E09quittekneclabeu_" MIME-Version: 1.0 Cc: Nevil Brownlee 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 08 Oct 2011 17:21:06 -0000 --_000_CAB6351922E09quittekneclabeu_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Dear Benoit, I am sorry for missing your comment. The point you are raising addresses t= he nature of the mediation protocol draft. Is it - a guideline how to use the IPFIX protocol for use with mediation? - is it an modification of the IPFIX protocol addressing the use with med= iation? - is it an extension of the IPFIX protocol addressing the use with mediat= ion? - is it a new protocol? I think the text that you are proposing comes closer to what the draft does= . However, I would like to have the question above answered clearly before= finalizing the charter update. Thanks, Juergen On 03.10.11 23:38, "Ben Claise" > wrote: Juergen, One comment that was forgotten. See inline. Dear all, Below please find an update of the proposed IPFIX charter update. It addresses all comments posted on the list. The only major change is adding item 7 on link layer IEs. Please send you comments on this version until next Monday, Oct 10. 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 existing 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. All following items 2.-7. will be in line with the revised versions of the IPFIX protocol specifications and the IPFIX information model. 2. In order to provide 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. Here is the comment I made earlier in this email thread: "common ways", "specifying guidelines for the use of the IPFIX protocol": a= ctually it's a real protocol specification, which will be standard track. Should we be more specific? Note that http://tools.ietf.org/html/draft-claise-ipfix-mediation-protocol-= 04 title is: Specification of the Protocol for IPFIX Mediations For example: 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 produce the protocol specifications in order to solve these IPFIX mediation specific problems. Regards, Benoit. 4.In order to support 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 MIB modules. 7. Operational experiences showed that it would be useful to define several new information elements for data link monitoring covering frame size, type, sections of frames, and VLAN information. The IPFIX WG will create a document defining these new information elements. Oct 2011 Publish Internet-Draftt on guidelines for IE doctors Oct 2011 Publish Internet-Draft on IPFIX use at mediators Oct 2011 Publish Internet-Draft on intermediate aggregation Oct 2011 Publish Internet-Draft on exporting MIB objects Oct 2011 Publish Internet-Draft on data link IEs Oct 2011 Publish Internet-Draft on revised IPFIX MIB Dec 2011 Publish Internet-Draft revising RFC 5101 Dec 2011 Publish Internet-Draft revising RFC 5102 Apr 2012 Submit guidelines for IE doctors for publication as Informational BCP RFC Apr 2012 Submit IPFIX use at mediators for publication as Standards track RFC Apr 2012 Submit intermediate aggregation for publication as Standards track RFC Apr 2012 Submit data link IEs for publication as Standards track RFC Apr 2012 Submit revised RFC 5101 for publication as Standards track RFC Apr 2012 Submit revised IPFIX MIB for publications as Standards track RFC Apr 2012 Submit revised RFC 5102 for publication as Standards track RFC Sep 2012 Submit export of MIB objects for publication as Standards track RFC On 30.09.11 09:18, "Juergen Quittek" wrote: Nevil, Thanks for the summary. I will post a new version of the charter at the weekend. Juergen On 30.09.11 00:10, "Nevil Brownlee" wrote: Hi all: Juergen posted the proposed new IPFIX charter at the end of August. I've only seen one comment on it, which was "what happened to the Link Layer IEs draft?" Looking at the minutes from our meeting in Quebec, we said "We discussed whether this could be a 'trial run for the IE Doctors,' or a WG item. We reached consensus for it as a WG item, with the proviso that it will need views from Layer 2 domain experts, e.g. IEEE 802.1." So Juergen, please add this as one more charter item. With that, I think we're ready to ask Dan to take it to IESG for approval. Cheers, Nevil PS: it's really good to see lots of discussion on the IPFIX list about improvements to 5101 et al :-) On 29/09/11 2:40 AM, Benoit Claise wrote: IPFIX chairs, Hi Juergen, The IPFIX configuration data model is pending because of the IPFIX and PSAMP MIBs. IMO, solving the SELECTOR MIB issue should be of highest priority, and a solution be published before any other new draft. I agree. Btw, where is the new charter? ;-) There is always a tendency to delay work for which there is no deadlines... Regards, Benoit. (I already see IPFIX config being outdated by RFC5101/5102bis before it ever becomes RFC...) Regards, Gerhard On 29.08.2011 06:57, Juergen Quittek wrote: 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.orghttps://www.ietf.org/mailman/listinfo/= ipfix _______________________________________________ IPFIX mailing list IPFIX@ietf.orghttps://www.ietf.org/mailman/listinfo/= ipfix _______________________________________________ IPFIX mailing list IPFIX@ietf.orghttps://www.ietf.org/mailman/listinfo/= ipfix -- --------------------------------------------------------------------- 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.orghttps://www.ietf.org/mailman/listinfo/= ipfix _______________________________________________ IPFIX mailing list IPFIX@ietf.orghttps://www.ietf.org/mailman/listinfo/= ipfix --_000_CAB6351922E09quittekneclabeu_ Content-Type: text/html; charset="us-ascii" Content-ID: <9ECAA4938EC88D4596FAC0F970C77D19@office.hd> Content-Transfer-Encoding: quoted-printable
Dear Benoit,

I am sorry for missing your comment.  The point you are raising addres= ses the nature of the mediation protocol draft.  Is it
  - a guideline how to use the IPFIX protocol for use with mediation?<= /div>
  - is it an modification of the IPFIX protocol addressing the use wit= h mediation? 
  - is it an extension of the IPFIX protocol addressing the use with m= ediation? 
  - is it a new protocol?

I think the text that you are proposing comes closer to what the draft does= .  However, I would like to have the question above answered clearly b= efore finalizing the charter update.

Thanks,

    Juergen


On 03.10.11 23:38, "Ben Claise" <bclaise@cisco.com> wrote:

Juergen,

One comment that was forgotten.
See inline.
Dear all,

Below please find an update of the proposed IPFIX charter update.
It addresses all comments posted on the list.
The only major change is adding item 7 on link layer IEs.

Please send you comments on this version until next Monday, Oct 10.

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 existing 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.

All following items 2.-7. will be in line with the revised versions
of the IPFIX protocol specifications and the IPFIX information model.

2. In order to provide 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.
Here is the comment I made earlier in this email thread:
"common ways", "specifying guidelines for the us= e of the IPFIX protocol": actually it's a real protocol specification,= which will be standard track.
Should we be more specific?
Note that http://tools.ietf.org/html/draft-claise-ipfix-mediation-protocol-04 tit= le is: Specification of the Protocol for IPFIX Mediations

For example:

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
produce the protocol specifications in order to solve these IPFIX mediation=
specific problems.

Regards, Benoit.
4.In order to support the aggregation of flow records at IPF=
IX 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 MIB modules.

7. Operational experiences showed that it would be useful to define
several new information elements for data link monitoring covering
frame size, type, sections of frames, and VLAN information. The IPFIX
WG will create a document defining these new information elements.


Oct 2011    Publish Internet-Draftt on guidelines for IE doctors
Oct 2011    Publish Internet-Draft on IPFIX use at mediators
Oct 2011    Publish Internet-Draft on intermediate aggregation
Oct 2011    Publish Internet-Draft on exporting MIB objects
Oct 2011    Publish Internet-Draft on data link IEs
Oct 2011    Publish Internet-Draft on revised IPFIX MIB
Dec 2011    Publish Internet-Draft revising RFC 5101
Dec 2011    Publish Internet-Draft revising RFC 5102

Apr 2012    Submit guidelines for IE doctors for publication as
            Informational BCP RFC
Apr 2012    Submit IPFIX use at mediators for publication as
            Standards track RFC
Apr 2012    Submit intermediate aggregation for publication as
            Standards track RFC
Apr 2012    Submit data link IEs for publication as
            Standards track RFC
Apr 2012    Submit revised RFC 5101 for publication as
            Standards track RFC
Apr 2012    Submit revised IPFIX MIB for publications as
            Standards track RFC
Apr 2012    Submit revised RFC 5102 for publication as
            Standards track RFC
Sep 2012    Submit export of MIB objects for publication as
            Standards track RFC




On 30.09.11 09:18, "Juergen Quittek" <Quittek@neclab.eu> wrot=
e:


Nevil,

Thanks for the summary.
I will post a new version of the charter at the weekend.

   Juergen

On 30.09.11 00:10, "Nevil Brownlee" <n.brownlee@auckland.ac.=
nz> wrote:


Hi all:

Juergen posted the proposed new IPFIX charter at the end of August.
I've only seen one comment on it, which was "what happened to the
Link Layer IEs draft?"

Looking at the minutes from our meeting in Quebec, we said
"We discussed whether this could be a 'trial run for the
IE Doctors,' or a WG item.  We reached consensus for it as a WG item,
with the proviso that it will need views from Layer 2 domain experts,
e.g. IEEE 802.1."

So Juergen, please add this as one more charter item.

With that, I think we're ready to ask Dan to take it to IESG for
approval.

Cheers, Nevil

PS: it's really good to see lots of discussion on the IPFIX list
    about improvements to 5101 et al :-)


On 29/09/11 2:40 AM, Benoit Claise wrote:

IPFIX chairs,

Hi Juergen,

The IPFIX configuration data model is pending because of the IPFIX and
PSAMP MIBs. IMO, solving the SELECTOR MIB issue should be of highest
priority, and a solution be published before any other new draft.

I agree.

Btw, where is the new charter? ;-) There is always a tendency to delay
work for which there is no deadlines...

Regards, Benoit.

(I already see IPFIX config being outdated by RFC5101/5102bi=
s before
it ever becomes RFC...)

Regards,
Gerhard


On 29.08.2011 06:57, Juergen Quittek wrote:

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.orghttps://www.ietf.org/mailman/listinfo/ipfix

_______________________________________________
IPFIX mailing list
IPFIX@=
ietf.orghttps://www.ietf.org/mailman/listinfo/ipfix

_______________________________________________
IPFIX mailing list
IPFIX@=
ietf.orghttps://www.ietf.org/mailman/listinfo/ipfix

--=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.orghttps://www.ietf.org/mailman/listinfo/ipfix

_______________________________________________
IPFIX mailing list
IPFIX@=
ietf.orghttps://www.ietf.org/mailman/listinfo/ipfix














--_000_CAB6351922E09quittekneclabeu_--

From bclaise@cisco.com  Sun Oct  9 00:15:43 2011
Return-Path: 
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 7E4F621F848F for ; Sun,  9 Oct 2011 00:15:42 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.002
X-Spam-Level: 
X-Spam-Status: No, score=0.002 tagged_above=-999 required=5 tests=[BAYES_50=0.001, HTML_MESSAGE=0.001]
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 JuWLnR1s+hrF for ; Sun,  9 Oct 2011 00:15:40 -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 5D28E21F848D for ; Sun,  9 Oct 2011 00:15:39 -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 p997FSKl017554; Sun, 9 Oct 2011 09:15:29 +0200 (CEST)
Received: from [10.60.67.84] (ams-bclaise-8913.cisco.com [10.60.67.84]) by strange-brew.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id p997FNAW003656; Sun, 9 Oct 2011 09:15:23 +0200 (CEST)
Message-ID: <4E914A0B.8090307@cisco.com>
Date: Sun, 09 Oct 2011 09:15:23 +0200
From: Benoit Claise 
User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1
MIME-Version: 1.0
To: Juergen Quittek 
References: 
In-Reply-To: 
Content-Type: multipart/alternative; boundary="------------000107040702080909040806"
Cc: Nevil Brownlee , IETF IPFIX Working Group 
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 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sun, 09 Oct 2011 07:15:44 -0000

This is a multi-part message in MIME format.
--------------000107040702080909040806
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

Hi Juergen,

It's an extension/modification of the IPFIX protocol addressing the use 
with mediation.
I'm not too sure what is the difference between extension and modification.
However, since it's based on RFC5101, I would say an extension.

Regards, Benoit.
> Dear Benoit,
>
> I am sorry for missing your comment.  The point you are raising 
> addresses the nature of the mediation protocol draft.  Is it
>   - a guideline how to use the IPFIX protocol for use with mediation?
>   - is it an modification of the IPFIX protocol addressing the use 
> with mediation?
>   - is it an extension of the IPFIX protocol addressing the use with 
> mediation?
>   - is it a new protocol?
>
> I think the text that you are proposing comes closer to what the draft 
> does.  However, I would like to have the question above answered 
> clearly before finalizing the charter update.
>
> Thanks,
>
>     Juergen
>
>
> On 03.10.11 23:38, "Ben Claise"  > wrote:
>
> Juergen,
>
> One comment that was forgotten.
> See inline.
>> Dear all,
>>
>> Below please find an update of the proposed IPFIX charter update.
>> It addresses all comments posted on the list.
>> The only major change is adding item 7 on link layer IEs.
>>
>> Please send you comments on this version until next Monday, Oct 10.
>>
>> 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 existing 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.
>>
>> All following items 2.-7. will be in line with the revised versions
>> of the IPFIX protocol specifications and the IPFIX information model.
>>
>> 2. In order to provide 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.
> Here is the comment I made earlier in this email thread:
>
>     "common ways", "specifying guidelines for the use of the IPFIX
>     protocol": actually it's a real protocol specification, which will
>     be standard track.
>     Should we be more specific?
>     Note that
>     http://tools.ietf.org/html/draft-claise-ipfix-mediation-protocol-04 title
>     is: Specification of the Protocol for IPFIX Mediations
>
>     For example:
>
>     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
>     produce the protocol specifications in order to solve these IPFIX
>     mediation
>     specific problems.
>
> Regards, Benoit.
>> 4.In order to support 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 MIB modules.
>>
>> 7. Operational experiences showed that it would be useful to define
>> several new information elements for data link monitoring covering
>> frame size, type, sections of frames, and VLAN information. The IPFIX
>> WG will create a document defining these new information elements.
>>
>>
>> Oct 2011    Publish Internet-Draftt on guidelines for IE doctors
>> Oct 2011    Publish Internet-Draft on IPFIX use at mediators
>> Oct 2011    Publish Internet-Draft on intermediate aggregation
>> Oct 2011    Publish Internet-Draft on exporting MIB objects
>> Oct 2011    Publish Internet-Draft on data link IEs
>> Oct 2011    Publish Internet-Draft on revised IPFIX MIB
>> Dec 2011    Publish Internet-Draft revising RFC 5101
>> Dec 2011    Publish Internet-Draft revising RFC 5102
>>
>> Apr 2012    Submit guidelines for IE doctors for publication as
>>              Informational BCP RFC
>> Apr 2012    Submit IPFIX use at mediators for publication as
>>              Standards track RFC
>> Apr 2012    Submit intermediate aggregation for publication as
>>              Standards track RFC
>> Apr 2012    Submit data link IEs for publication as
>>              Standards track RFC
>> Apr 2012    Submit revised RFC 5101 for publication as
>>              Standards track RFC
>> Apr 2012    Submit revised IPFIX MIB for publications as
>>              Standards track RFC
>> Apr 2012    Submit revised RFC 5102 for publication as
>>              Standards track RFC
>> Sep 2012    Submit export of MIB objects for publication as
>>              Standards track RFC
>>
>>
>>
>>
>> On 30.09.11 09:18, "Juergen Quittek"  wrote:
>>
>>> Nevil,
>>>
>>> Thanks for the summary.
>>> I will post a new version of the charter at the weekend.
>>>
>>>     Juergen
>>>
>>> On 30.09.11 00:10, "Nevil Brownlee"  wrote:
>>>
>>>> Hi all:
>>>>
>>>> Juergen posted the proposed new IPFIX charter at the end of August.
>>>> I've only seen one comment on it, which was "what happened to the
>>>> Link Layer IEs draft?"
>>>>
>>>> Looking at the minutes from our meeting in Quebec, we said
>>>> "We discussed whether this could be a 'trial run for the
>>>> IE Doctors,' or a WG item.  We reached consensus for it as a WG item,
>>>> with the proviso that it will need views from Layer 2 domain experts,
>>>> e.g. IEEE 802.1."
>>>>
>>>> So Juergen, please add this as one more charter item.
>>>>
>>>> With that, I think we're ready to ask Dan to take it to IESG for
>>>> approval.
>>>>
>>>> Cheers, Nevil
>>>>
>>>> PS: it's really good to see lots of discussion on the IPFIX list
>>>>      about improvements to 5101 et al :-)
>>>>
>>>>
>>>> On 29/09/11 2:40 AM, Benoit Claise wrote:
>>>>> IPFIX chairs,
>>>>>> Hi Juergen,
>>>>>>
>>>>>> The IPFIX configuration data model is pending because of the IPFIX and
>>>>>> PSAMP MIBs. IMO, solving the SELECTOR MIB issue should be of highest
>>>>>> priority, and a solution be published before any other new draft.
>>>>> I agree.
>>>>>
>>>>> Btw, where is the new charter? ;-) There is always a tendency to delay
>>>>> work for which there is no deadlines...
>>>>>
>>>>> Regards, Benoit.
>>>>>> (I already see IPFIX config being outdated by RFC5101/5102bis before
>>>>>> it ever becomes RFC...)
>>>>>>
>>>>>> Regards,
>>>>>> Gerhard
>>>>>>
>>>>>>
>>>>>> On 29.08.2011 06:57, Juergen Quittek wrote:
>>>>>>> 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.orghttps://www.ietf.org/mailman/listinfo/ipfix
>>>>>> _______________________________________________
>>>>>> IPFIX mailing list
>>>>>> IPFIX@ietf.orghttps://www.ietf.org/mailman/listinfo/ipfix
>>>>> _______________________________________________
>>>>> IPFIX mailing list
>>>>> IPFIX@ietf.orghttps://www.ietf.org/mailman/listinfo/ipfix
>>>> -- 
>>>> ---------------------------------------------------------------------
>>>>   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.orghttps://www.ietf.org/mailman/listinfo/ipfix
>>> _______________________________________________
>>> IPFIX mailing list
>>> IPFIX@ietf.orghttps://www.ietf.org/mailman/listinfo/ipfix
>


--------------000107040702080909040806
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit


  
    
  
  
    Hi Juergen,

    

    It's an extension/modification of the IPFIX protocol addressing the
    use with mediation.

    I'm not too sure what is the difference between extension and
    modification.

    However, since it's based on RFC5101, I would say an extension.

    

    Regards, Benoit.

    

      
      

        Dear Benoit,

      

        

      

      

        I am sorry for missing your comment.  The point you are raising
        addresses the nature of the mediation protocol draft.  Is it

      

          - a guideline how to use the IPFIX protocol for use with
        mediation?

      

          - is it an modification of the IPFIX protocol addressing the
        use with mediation? 

      

          - is it an extension of the IPFIX protocol addressing the use
        with mediation? 

      

          - is it a new protocol?

      

        

      

      

        I think the text that you are proposing comes closer to what the
        draft does.  However, I would like to have the question above
        answered clearly before finalizing the charter update.

      

        

      

      

        Thanks,

      

        

      

      

            Juergen

      

        

      

      

        

      

      
        

          
On 03.10.11 23:38, "Ben Claise" <bclaise@cisco.com>
            wrote:

        

        


        

        

          
Juergen,

            

            One comment that was forgotten.

            See inline.

            

              
Dear all,

Below please find an update of the proposed IPFIX charter update.
It addresses all comments posted on the list.
The only major change is adding item 7 on link layer IEs.

Please send you comments on this version until next Monday, Oct 10.

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 existing 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.

All following items 2.-7. will be in line with the revised versions
of the IPFIX protocol specifications and the IPFIX information model.

2. In order to provide 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.

            

            Here is the comment I made earlier in this email thread:

            
"common ways", "specifying guidelines for the
              use of the IPFIX protocol": actually it's a real protocol
              specification, which will be standard track.
              

              Should we be more specific? 

              Note that http://tools.ietf.org/html/draft-claise-ipfix-mediation-protocol-04
              title is: Specification of the Protocol for IPFIX
              Mediations
              

              

              For example: 

              

              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 

              produce the protocol specifications in order to solve
              these IPFIX mediation 

              specific problems.

              

            

            Regards, Benoit.

            

              
4.In order to support 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 MIB modules.

7. Operational experiences showed that it would be useful to define
several new information elements for data link monitoring covering
frame size, type, sections of frames, and VLAN information. The IPFIX
WG will create a document defining these new information elements.


Oct 2011    Publish Internet-Draftt on guidelines for IE doctors
Oct 2011    Publish Internet-Draft on IPFIX use at mediators
Oct 2011    Publish Internet-Draft on intermediate aggregation
Oct 2011    Publish Internet-Draft on exporting MIB objects
Oct 2011    Publish Internet-Draft on data link IEs
Oct 2011    Publish Internet-Draft on revised IPFIX MIB
Dec 2011    Publish Internet-Draft revising RFC 5101
Dec 2011    Publish Internet-Draft revising RFC 5102

Apr 2012    Submit guidelines for IE doctors for publication as
            Informational BCP RFC
Apr 2012    Submit IPFIX use at mediators for publication as
            Standards track RFC
Apr 2012    Submit intermediate aggregation for publication as
            Standards track RFC
Apr 2012    Submit data link IEs for publication as
            Standards track RFC
Apr 2012    Submit revised RFC 5101 for publication as
            Standards track RFC
Apr 2012    Submit revised IPFIX MIB for publications as
            Standards track RFC
Apr 2012    Submit revised RFC 5102 for publication as
            Standards track RFC
Sep 2012    Submit export of MIB objects for publication as
            Standards track RFC




On 30.09.11 09:18, "Juergen Quittek" <Quittek@neclab.eu> wrote:



              

                
Nevil,

Thanks for the summary.
I will post a new version of the charter at the weekend.

   Juergen

On 30.09.11 00:10, "Nevil Brownlee" <n.brownlee@auckland.ac.nz> wrote:



                

                  
Hi all:

Juergen posted the proposed new IPFIX charter at the end of August.
I've only seen one comment on it, which was "what happened to the
Link Layer IEs draft?"

Looking at the minutes from our meeting in Quebec, we said
"We discussed whether this could be a 'trial run for the
IE Doctors,' or a WG item.  We reached consensus for it as a WG item,
with the proviso that it will need views from Layer 2 domain experts,
e.g. IEEE 802.1."

So Juergen, please add this as one more charter item.

With that, I think we're ready to ask Dan to take it to IESG for
approval.

Cheers, Nevil

PS: it's really good to see lots of discussion on the IPFIX list
    about improvements to 5101 et al :-)


On 29/09/11 2:40 AM, Benoit Claise wrote:


                  

                    
IPFIX chairs,


                    

                      
Hi Juergen,

The IPFIX configuration data model is pending because of the IPFIX and
PSAMP MIBs. IMO, solving the SELECTOR MIB issue should be of highest
priority, and a solution be published before any other new draft.


                    

                    
I agree.

Btw, where is the new charter? ;-) There is always a tendency to delay
work for which there is no deadlines...

Regards, Benoit.


                    

                      
(I already see IPFIX config being outdated by RFC5101/5102bis before
it ever becomes RFC...)

Regards,
Gerhard


On 29.08.2011 06:57, Juergen Quittek wrote:


                      

                        
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.orghttps://www.ietf.org/mailman/listinfo/ipfix

                      

                      
_______________________________________________
IPFIX mailing list
IPFIX@ietf.orghttps://www.ietf.org/mailman/listinfo/ipfix

                    

                    
_______________________________________________
IPFIX mailing list
IPFIX@ietf.orghttps://www.ietf.org/mailman/listinfo/ipfix

                  

                  
-- 
---------------------------------------------------------------------
 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.orghttps://www.ietf.org/mailman/listinfo/ipfix

                

                
_______________________________________________
IPFIX mailing list
IPFIX@ietf.orghttps://www.ietf.org/mailman/listinfo/ipfix

              

            

            

          

        

      
    

    

  


--------------000107040702080909040806--

From bclaise@cisco.com  Mon Oct 10 04:52:06 2011
Return-Path: 
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 892CA21F8B75 for ; Mon, 10 Oct 2011 04:52:06 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.298
X-Spam-Level: 
X-Spam-Status: No, score=-1.298 tagged_above=-999 required=5 tests=[AWL=1.300,  BAYES_00=-2.599, HTML_MESSAGE=0.001]
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 UOYj7JoCP7Pj for ; Mon, 10 Oct 2011 04:52:06 -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 B926721F8B52 for ; Mon, 10 Oct 2011 04:52:05 -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 p9ABq4jp022038; Mon, 10 Oct 2011 13:52:04 +0200 (CEST)
Received: from [10.60.67.84] (ams-bclaise-8913.cisco.com [10.60.67.84]) by strange-brew.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id p9ABq3a1027364; Mon, 10 Oct 2011 13:52:03 +0200 (CEST)
Message-ID: <4E92DC63.60603@cisco.com>
Date: Mon, 10 Oct 2011 13:52:03 +0200
From: Benoit Claise 
User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1
MIME-Version: 1.0
To: "ipfix@ietf.org" 
References: <20111010100052.30656.13342.idtracker@ietfa.amsl.com>
In-Reply-To: <20111010100052.30656.13342.idtracker@ietfa.amsl.com>
X-Forwarded-Message-Id: <20111010100052.30656.13342.idtracker@ietfa.amsl.com>
Content-Type: multipart/alternative; boundary="------------060303030601000500030806"
Subject: [IPFIX] Fwd: New Version Notification for draft-claise-ipfix-information-model-rfc5102bis-00.txt
X-BeenThere: ipfix@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: IPFIX WG discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 10 Oct 2011 11:52:06 -0000

This is a multi-part message in MIME format.
--------------060303030601000500030806
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit

Dear all,

Here is new draft, for our new charter proposal: 
http://tools.ietf.org/html/draft-claise-ipfix-information-model-rfc5102bis-00
The diffs with RFC5102 are at 
http://tools.ietf.org/rfcdiff?url2=draft-claise-ipfix-information-model-rfc5102bis-00.txt

Your feedback is welcome.

Regards, Benoit.
-------- Original Message --------
Subject: 	New Version Notification for 
draft-claise-ipfix-information-model-rfc5102bis-00.txt
Date: 	Mon, 10 Oct 2011 03:00:52 -0700
From: 	internet-drafts@ietf.org
To: 	bclaise@cisco.com
CC: 	bclaise@cisco.com, stbryant@cisco.com, jemeyer@paypal.com, 
paitken@cisco.com, quittek@nw.neclab.eu



A new version of I-D, draft-claise-ipfix-information-model-rfc5102bis-00.txt has been successfully submitted by Benoit Claise and posted to the IETF repository.

Filename:	 draft-claise-ipfix-information-model-rfc5102bis
Revision:	 00
Title:		 Information Model for IP Flow Information eXport (IPFIX)
Creation date:	 2011-10-10
WG ID:		 Individual Submission
Number of pages: 172

Abstract:
This memo defines an information model for the IP Flow Information
eXport (IPFIX) protocol.  It is used by the IPFIX protocol for encoding
measured traffic information and information related to the traffic
Observation Point, the traffic Metering Process, and the Exporting
Process.  Although developed for the IPFIX protocol, the model is
defined in an open way that easily allows using it in other protocols,
interfaces, and applications.  This document obsoletes RFC 5102.




The IETF Secretariat




--------------060303030601000500030806
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: 7bit


  

    
  
  
    Dear all,

    

    Here is new draft, for our new charter proposal:
http://tools.ietf.org/html/draft-claise-ipfix-information-model-rfc5102bis-00

    The diffs with RFC5102 are at
http://tools.ietf.org/rfcdiff?url2=draft-claise-ipfix-information-model-rfc5102bis-00.txt

    

    Your feedback is welcome.

    

    Regards, Benoit.

    -------- Original Message --------
    

      
        

          Subject: 
          New Version Notification for
            draft-claise-ipfix-information-model-rfc5102bis-00.txt
        

        

          Date: 
          Mon, 10 Oct 2011 03:00:52 -0700
        

        

          From: 
          internet-drafts@ietf.org
        

        

          To: 
          bclaise@cisco.com
        

        

          CC: 
          bclaise@cisco.com, stbryant@cisco.com, jemeyer@paypal.com,
            paitken@cisco.com, quittek@nw.neclab.eu
        

      
    

    

    

    
A new version of I-D, draft-claise-ipfix-information-model-rfc5102bis-00.txt has been successfully submitted by Benoit Claise and posted to the IETF repository.

Filename:	 draft-claise-ipfix-information-model-rfc5102bis
Revision:	 00
Title:		 Information Model for IP Flow Information eXport (IPFIX)
Creation date:	 2011-10-10
WG ID:		 Individual Submission
Number of pages: 172

Abstract:
This memo defines an information model for the IP Flow Information
eXport (IPFIX) protocol.  It is used by the IPFIX protocol for encoding
measured traffic information and information related to the traffic
Observation Point, the traffic Metering Process, and the Exporting
Process.  Although developed for the IPFIX protocol, the model is
defined in an open way that easily allows using it in other protocols,
interfaces, and applications.  This document obsoletes RFC 5102.

                                                                                  


The IETF Secretariat




  


--------------060303030601000500030806--

From trammell@tik.ee.ethz.ch  Mon Oct 10 06:15:25 2011
Return-Path: 
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 A46F721F8484 for ; Mon, 10 Oct 2011 06:15:25 -0700 (PDT)
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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id B5J6R1rieWng for ; Mon, 10 Oct 2011 06:15:10 -0700 (PDT)
Received: from smtp.ee.ethz.ch (smtp.ee.ethz.ch [129.132.2.219]) by ietfa.amsl.com (Postfix) with ESMTP id 143EA21F8BBE for ; Mon, 10 Oct 2011 06:15:09 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by smtp.ee.ethz.ch (Postfix) with ESMTP id E0B95D9317; Mon, 10 Oct 2011 15:15:07 +0200 (MEST)
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 5uXSpi8zcWt7; Mon, 10 Oct 2011 15:15:07 +0200 (MEST)
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 E7777D9305; Mon, 10 Oct 2011 15:15:06 +0200 (MEST)
Mime-Version: 1.0 (Apple Message framework v1084)
Content-Type: text/plain; charset=us-ascii
From: Brian Trammell 
In-Reply-To: <4E914A0B.8090307@cisco.com>
Date: Mon, 10 Oct 2011 15:15:06 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: 
References:  <4E914A0B.8090307@cisco.com>
To: Benoit Claise 
X-Mailer: Apple Mail (2.1084)
Cc: Nevil Brownlee , IETF IPFIX Working Group 
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 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 10 Oct 2011 13:15:25 -0000

Hi, Benoit, all,

I'm not quite happy with any of these characterizations... "extension" =
means to me "I have to worry about this, even if I don't care about =
Mediators". Since there is _nothing_ in medproto which would require an =
Original Exporter to do something differently when sending to a =
Mediator, or would require a Collector to do something differently when =
receiving from a Mediator, AFAICT this is not the case (and should not =
be)...

So, how about:


a set of specifications for applying the IPFIX Protocol at Mediators, =
including new specifications for protocol issues not envisioned by the =
IPFIX Protocol itself.

Regards,

Brian

On Oct 9, 2011, at 9:15 AM, Benoit Claise wrote:

> Hi Juergen,
>=20
> It's an extension/modification of the IPFIX protocol addressing the =
use with mediation.
> I'm not too sure what is the difference between extension and =
modification.
> However, since it's based on RFC5101, I would say an extension.
>=20
> Regards, Benoit.
>> Dear Benoit,
>>=20
>> I am sorry for missing your comment.  The point you are raising =
addresses the nature of the mediation protocol draft.  Is it
>>   - a guideline how to use the IPFIX protocol for use with mediation?
>>   - is it an modification of the IPFIX protocol addressing the use =
with mediation?=20
>>   - is it an extension of the IPFIX protocol addressing the use with =
mediation?=20
>>   - is it a new protocol?
>>=20
>> I think the text that you are proposing comes closer to what the =
draft does.  However, I would like to have the question above answered =
clearly before finalizing the charter update.
>>=20
>> Thanks,
>>=20
>>     Juergen
>>=20
>>=20
>> On 03.10.11 23:38, "Ben Claise"  wrote:
>>=20
>> Juergen,
>>=20
>> One comment that was forgotten.
>> See inline.
>>> Dear all,
>>>=20
>>> Below please find an update of the proposed IPFIX charter update.
>>> It addresses all comments posted on the list.
>>> The only major change is adding item 7 on link layer IEs.
>>>=20
>>> Please send you comments on this version until next Monday, Oct 10.
>>>=20
>>> Thanks,
>>>=20
>>>     Juergen
>>>=20
>>>=20
>>> IP Flow Information Export (ipfix)
>>>=20
>>> Description of Working Group
>>>=20
>>> 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.
>>>=20
>>> 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.
>>>=20
>>> 1. Having a solid standardized base for IPFIX deployment and =
operation
>>> and several existing 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.
>>>=20
>>> All following items 2.-7. will be in line with the revised versions
>>> of the IPFIX protocol specifications and the IPFIX information =
model.
>>>=20
>>> 2. In order to provide 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.
>>>=20
>>> 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.
>>>=20
>> Here is the comment I made earlier in this email thread:
>> "common ways", "specifying guidelines for the use of the IPFIX =
protocol": actually it's a real protocol specification, which will be =
standard track.=20
>> Should we be more specific?=20
>> Note that =
http://tools.ietf.org/html/draft-claise-ipfix-mediation-protocol-04 =
title is: Specification of the Protocol for IPFIX Mediations=20
>>=20
>> For example:=20
>>=20
>> 3. The export of IPFIX flow records from IPFIX mediators introduces a=20=

>> set of potential issues at the protocol level, such as the loss of=20
>> information on the original exporter, loss of base time information,=20=

>> loss of original options template information, etc. The IPFIX WG will=20=

>> produce the protocol specifications in order to solve these IPFIX =
mediation=20
>> specific problems.
>>=20
>> Regards, Benoit.
>>> 4.In order to support 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.
>>>=20
>>> 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 MIB modules.
>>>=20
>>> 7. Operational experiences showed that it would be useful to define
>>> several new information elements for data link monitoring covering
>>> frame size, type, sections of frames, and VLAN information. The =
IPFIX
>>> WG will create a document defining these new information elements.
>>>=20
>>>=20
>>> Oct 2011    Publish Internet-Draftt on guidelines for IE doctors
>>> Oct 2011    Publish Internet-Draft on IPFIX use at mediators
>>> Oct 2011    Publish Internet-Draft on intermediate aggregation
>>> Oct 2011    Publish Internet-Draft on exporting MIB objects
>>> Oct 2011    Publish Internet-Draft on data link IEs
>>> Oct 2011    Publish Internet-Draft on revised IPFIX MIB
>>> Dec 2011    Publish Internet-Draft revising RFC 5101
>>> Dec 2011    Publish Internet-Draft revising RFC 5102
>>>=20
>>> Apr 2012    Submit guidelines for IE doctors for publication as
>>>             Informational BCP RFC
>>> Apr 2012    Submit IPFIX use at mediators for publication as
>>>             Standards track RFC
>>> Apr 2012    Submit intermediate aggregation for publication as
>>>             Standards track RFC
>>> Apr 2012    Submit data link IEs for publication as
>>>             Standards track RFC
>>> Apr 2012    Submit revised RFC 5101 for publication as
>>>             Standards track RFC
>>> Apr 2012    Submit revised IPFIX MIB for publications as
>>>             Standards track RFC
>>> Apr 2012    Submit revised RFC 5102 for publication as
>>>             Standards track RFC
>>> Sep 2012    Submit export of MIB objects for publication as
>>>             Standards track RFC
>>>=20
>>>=20
>>>=20
>>>=20
>>> On 30.09.11 09:18, "Juergen Quittek"=20
>>> 
>>>  wrote:
>>>=20
>>>=20
>>>> Nevil,
>>>>=20
>>>> Thanks for the summary.
>>>> I will post a new version of the charter at the weekend.
>>>>=20
>>>>    Juergen
>>>>=20
>>>> On 30.09.11 00:10, "Nevil Brownlee"=20
>>>> 
>>>>  wrote:
>>>>=20
>>>>=20
>>>>> Hi all:
>>>>>=20
>>>>> Juergen posted the proposed new IPFIX charter at the end of =
August.
>>>>> I've only seen one comment on it, which was "what happened to the
>>>>> Link Layer IEs draft?"
>>>>>=20
>>>>> Looking at the minutes from our meeting in Quebec, we said
>>>>> "We discussed whether this could be a 'trial run for the
>>>>> IE Doctors,' or a WG item.  We reached consensus for it as a WG =
item,
>>>>> with the proviso that it will need views from Layer 2 domain =
experts,
>>>>> e.g. IEEE 802.1."
>>>>>=20
>>>>> So Juergen, please add this as one more charter item.
>>>>>=20
>>>>> With that, I think we're ready to ask Dan to take it to IESG for
>>>>> approval.
>>>>>=20
>>>>> Cheers, Nevil
>>>>>=20
>>>>> PS: it's really good to see lots of discussion on the IPFIX list
>>>>>     about improvements to 5101 et al :-)
>>>>>=20
>>>>>=20
>>>>> On 29/09/11 2:40 AM, Benoit Claise wrote:
>>>>>=20
>>>>>> IPFIX chairs,
>>>>>>=20
>>>>>>> Hi Juergen,
>>>>>>>=20
>>>>>>> The IPFIX configuration data model is pending because of the =
IPFIX and
>>>>>>> PSAMP MIBs. IMO, solving the SELECTOR MIB issue should be of =
highest
>>>>>>> priority, and a solution be published before any other new =
draft.
>>>>>>>=20
>>>>>> I agree.
>>>>>>=20
>>>>>> Btw, where is the new charter? ;-) There is always a tendency to =
delay
>>>>>> work for which there is no deadlines...
>>>>>>=20
>>>>>> Regards, Benoit.
>>>>>>=20
>>>>>>> (I already see IPFIX config being outdated by RFC5101/5102bis =
before
>>>>>>> it ever becomes RFC...)
>>>>>>>=20
>>>>>>> Regards,
>>>>>>> Gerhard
>>>>>>>=20
>>>>>>>=20
>>>>>>> On 29.08.2011 06:57, Juergen Quittek wrote:
>>>>>>>=20
>>>>>>>> Dear all,
>>>>>>>>=20
>>>>>>>> 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.
>>>>>>>>=20
>>>>>>>> Please have a look at it and send us your comments.
>>>>>>>>=20
>>>>>>>> Thanks,
>>>>>>>>=20
>>>>>>>> Juergen
>>>>>>>>=20
>>>>>>>>=20
>>>>>>>> IP Flow Information Export (ipfix)
>>>>>>>>=20
>>>>>>>>=20
>>>>>>>> Description of Working Group
>>>>>>>>=20
>>>>>>>>=20
>>>>>>>> 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.
>>>>>>>>=20
>>>>>>>> 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.
>>>>>>>>=20
>>>>>>>> 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.
>>>>>>>>=20
>>>>>>>> 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.
>>>>>>>>=20
>>>>>>>> 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.
>>>>>>>>=20
>>>>>>>> 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.
>>>>>>>>=20
>>>>>>>> 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.
>>>>>>>>=20
>>>>>>>> 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.
>>>>>>>>=20
>>>>>>>> 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
>>>>>>>>=20
>>>>>>>> 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
>>>>>>>>=20
>>>>>>>>=20
>>>>>>>> _______________________________________________
>>>>>>>> IPFIX mailing list
>>>>>>>>=20
>>>>>>>> IPFIX@ietf.orghttps://www.ietf.org/mailman/listinfo/ipfix
>>>>>>> _______________________________________________
>>>>>>> IPFIX mailing list
>>>>>>>=20
>>>>>>> IPFIX@ietf.orghttps://www.ietf.org/mailman/listinfo/ipfix
>>>>>> _______________________________________________
>>>>>> IPFIX mailing list
>>>>>>=20
>>>>>> IPFIX@ietf.orghttps://www.ietf.org/mailman/listinfo/ipfix
>>>>> --=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
>>>>>=20
>>>>> IPFIX@ietf.orghttps://www.ietf.org/mailman/listinfo/ipfix
>>>> _______________________________________________
>>>> IPFIX mailing list
>>>>=20
>>>> IPFIX@ietf.orghttps://www.ietf.org/mailman/listinfo/ipfix
>>=20
>=20
> _______________________________________________
> IPFIX mailing list
> IPFIX@ietf.org
> https://www.ietf.org/mailman/listinfo/ipfix


From bclaise@cisco.com  Mon Oct 10 06:19:47 2011
Return-Path: 
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 186B821F8BCB for ; Mon, 10 Oct 2011 06:19:47 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.949
X-Spam-Level: 
X-Spam-Status: No, score=-1.949 tagged_above=-999 required=5 tests=[AWL=0.651,  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 WgM-pNxEE-Sb for ; Mon, 10 Oct 2011 06:19:45 -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 69CF821F8BB9 for ; Mon, 10 Oct 2011 06:19:45 -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 p9ADJaWb003052; Mon, 10 Oct 2011 15:19:36 +0200 (CEST)
Received: from [10.60.67.84] (ams-bclaise-8913.cisco.com [10.60.67.84]) by strange-brew.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id p9ADJZ83005737; Mon, 10 Oct 2011 15:19:35 +0200 (CEST)
Message-ID: <4E92F0E7.6050501@cisco.com>
Date: Mon, 10 Oct 2011 15:19:35 +0200
From: Benoit Claise 
User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1
MIME-Version: 1.0
To: Brian Trammell 
References:  <4E914A0B.8090307@cisco.com> 
In-Reply-To: 
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Cc: Nevil Brownlee , IETF IPFIX Working Group 
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 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 10 Oct 2011 13:19:47 -0000

Hi Brian,

That works for me. Thanks for the better wording.

Regards, Benoit.
> Hi, Benoit, all,
>
> I'm not quite happy with any of these characterizations... "extension" means to me "I have to worry about this, even if I don't care about Mediators". Since there is _nothing_ in medproto which would require an Original Exporter to do something differently when sending to a Mediator, or would require a Collector to do something differently when receiving from a Mediator, AFAICT this is not the case (and should not be)...
>
> So, how about:
>
>
> a set of specifications for applying the IPFIX Protocol at Mediators, including new specifications for protocol issues not envisioned by the IPFIX Protocol itself.
>
> Regards,
>
> Brian
>
> On Oct 9, 2011, at 9:15 AM, Benoit Claise wrote:
>
>> Hi Juergen,
>>
>> It's an extension/modification of the IPFIX protocol addressing the use with mediation.
>> I'm not too sure what is the difference between extension and modification.
>> However, since it's based on RFC5101, I would say an extension.
>>
>> Regards, Benoit.
>>> Dear Benoit,
>>>
>>> I am sorry for missing your comment.  The point you are raising addresses the nature of the mediation protocol draft.  Is it
>>>    - a guideline how to use the IPFIX protocol for use with mediation?
>>>    - is it an modification of the IPFIX protocol addressing the use with mediation?
>>>    - is it an extension of the IPFIX protocol addressing the use with mediation?
>>>    - is it a new protocol?
>>>
>>> I think the text that you are proposing comes closer to what the draft does.  However, I would like to have the question above answered clearly before finalizing the charter update.
>>>
>>> Thanks,
>>>
>>>      Juergen
>>>
>>>
>>> On 03.10.11 23:38, "Ben Claise"  wrote:
>>>
>>> Juergen,
>>>
>>> One comment that was forgotten.
>>> See inline.
>>>> Dear all,
>>>>
>>>> Below please find an update of the proposed IPFIX charter update.
>>>> It addresses all comments posted on the list.
>>>> The only major change is adding item 7 on link layer IEs.
>>>>
>>>> Please send you comments on this version until next Monday, Oct 10.
>>>>
>>>> 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 existing 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.
>>>>
>>>> All following items 2.-7. will be in line with the revised versions
>>>> of the IPFIX protocol specifications and the IPFIX information model.
>>>>
>>>> 2. In order to provide 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.
>>>>
>>> Here is the comment I made earlier in this email thread:
>>> "common ways", "specifying guidelines for the use of the IPFIX protocol": actually it's a real protocol specification, which will be standard track.
>>> Should we be more specific?
>>> Note that http://tools.ietf.org/html/draft-claise-ipfix-mediation-protocol-04 title is: Specification of the Protocol for IPFIX Mediations
>>>
>>> For example:
>>>
>>> 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
>>> produce the protocol specifications in order to solve these IPFIX mediation
>>> specific problems.
>>>
>>> Regards, Benoit.
>>>> 4.In order to support 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 MIB modules.
>>>>
>>>> 7. Operational experiences showed that it would be useful to define
>>>> several new information elements for data link monitoring covering
>>>> frame size, type, sections of frames, and VLAN information. The IPFIX
>>>> WG will create a document defining these new information elements.
>>>>
>>>>
>>>> Oct 2011    Publish Internet-Draftt on guidelines for IE doctors
>>>> Oct 2011    Publish Internet-Draft on IPFIX use at mediators
>>>> Oct 2011    Publish Internet-Draft on intermediate aggregation
>>>> Oct 2011    Publish Internet-Draft on exporting MIB objects
>>>> Oct 2011    Publish Internet-Draft on data link IEs
>>>> Oct 2011    Publish Internet-Draft on revised IPFIX MIB
>>>> Dec 2011    Publish Internet-Draft revising RFC 5101
>>>> Dec 2011    Publish Internet-Draft revising RFC 5102
>>>>
>>>> Apr 2012    Submit guidelines for IE doctors for publication as
>>>>              Informational BCP RFC
>>>> Apr 2012    Submit IPFIX use at mediators for publication as
>>>>              Standards track RFC
>>>> Apr 2012    Submit intermediate aggregation for publication as
>>>>              Standards track RFC
>>>> Apr 2012    Submit data link IEs for publication as
>>>>              Standards track RFC
>>>> Apr 2012    Submit revised RFC 5101 for publication as
>>>>              Standards track RFC
>>>> Apr 2012    Submit revised IPFIX MIB for publications as
>>>>              Standards track RFC
>>>> Apr 2012    Submit revised RFC 5102 for publication as
>>>>              Standards track RFC
>>>> Sep 2012    Submit export of MIB objects for publication as
>>>>              Standards track RFC
>>>>
>>>>
>>>>
>>>>
>>>> On 30.09.11 09:18, "Juergen Quittek"
>>>> 
>>>>   wrote:
>>>>
>>>>
>>>>> Nevil,
>>>>>
>>>>> Thanks for the summary.
>>>>> I will post a new version of the charter at the weekend.
>>>>>
>>>>>     Juergen
>>>>>
>>>>> On 30.09.11 00:10, "Nevil Brownlee"
>>>>> 
>>>>>   wrote:
>>>>>
>>>>>
>>>>>> Hi all:
>>>>>>
>>>>>> Juergen posted the proposed new IPFIX charter at the end of August.
>>>>>> I've only seen one comment on it, which was "what happened to the
>>>>>> Link Layer IEs draft?"
>>>>>>
>>>>>> Looking at the minutes from our meeting in Quebec, we said
>>>>>> "We discussed whether this could be a 'trial run for the
>>>>>> IE Doctors,' or a WG item.  We reached consensus for it as a WG item,
>>>>>> with the proviso that it will need views from Layer 2 domain experts,
>>>>>> e.g. IEEE 802.1."
>>>>>>
>>>>>> So Juergen, please add this as one more charter item.
>>>>>>
>>>>>> With that, I think we're ready to ask Dan to take it to IESG for
>>>>>> approval.
>>>>>>
>>>>>> Cheers, Nevil
>>>>>>
>>>>>> PS: it's really good to see lots of discussion on the IPFIX list
>>>>>>      about improvements to 5101 et al :-)
>>>>>>
>>>>>>
>>>>>> On 29/09/11 2:40 AM, Benoit Claise wrote:
>>>>>>
>>>>>>> IPFIX chairs,
>>>>>>>
>>>>>>>> Hi Juergen,
>>>>>>>>
>>>>>>>> The IPFIX configuration data model is pending because of the IPFIX and
>>>>>>>> PSAMP MIBs. IMO, solving the SELECTOR MIB issue should be of highest
>>>>>>>> priority, and a solution be published before any other new draft.
>>>>>>>>
>>>>>>> I agree.
>>>>>>>
>>>>>>> Btw, where is the new charter? ;-) There is always a tendency to delay
>>>>>>> work for which there is no deadlines...
>>>>>>>
>>>>>>> Regards, Benoit.
>>>>>>>
>>>>>>>> (I already see IPFIX config being outdated by RFC5101/5102bis before
>>>>>>>> it ever becomes RFC...)
>>>>>>>>
>>>>>>>> Regards,
>>>>>>>> Gerhard
>>>>>>>>
>>>>>>>>
>>>>>>>> On 29.08.2011 06:57, Juergen Quittek wrote:
>>>>>>>>
>>>>>>>>> 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.orghttps://www.ietf.org/mailman/listinfo/ipfix
>>>>>>>> _______________________________________________
>>>>>>>> IPFIX mailing list
>>>>>>>>
>>>>>>>> IPFIX@ietf.orghttps://www.ietf.org/mailman/listinfo/ipfix
>>>>>>> _______________________________________________
>>>>>>> IPFIX mailing list
>>>>>>>
>>>>>>> IPFIX@ietf.orghttps://www.ietf.org/mailman/listinfo/ipfix
>>>>>> -- 
>>>>>> ---------------------------------------------------------------------
>>>>>>   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.orghttps://www.ietf.org/mailman/listinfo/ipfix
>>>>> _______________________________________________
>>>>> IPFIX mailing list
>>>>>
>>>>> IPFIX@ietf.orghttps://www.ietf.org/mailman/listinfo/ipfix
>> _______________________________________________
>> IPFIX mailing list
>> IPFIX@ietf.org
>> https://www.ietf.org/mailman/listinfo/ipfix
>
>


From bclaise@cisco.com  Mon Oct 10 08:15:00 2011
Return-Path: 
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 489BB21F8C49; Mon, 10 Oct 2011 08:15:00 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.273
X-Spam-Level: 
X-Spam-Status: No, score=-2.273 tagged_above=-999 required=5 tests=[AWL=0.325,  BAYES_00=-2.599, HTML_MESSAGE=0.001]
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 12Da20Y48Vht; Mon, 10 Oct 2011 08:14:59 -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 4F47021F8C36; Mon, 10 Oct 2011 08:14:59 -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 p9AFEtkt017146; Mon, 10 Oct 2011 17:14:55 +0200 (CEST)
Received: from [10.60.67.84] (ams-bclaise-8913.cisco.com [10.60.67.84]) by strange-brew.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id p9AFEpII017460; Mon, 10 Oct 2011 17:14:51 +0200 (CEST)
Message-ID: <4E930BEB.3080208@cisco.com>
Date: Mon, 10 Oct 2011 17:14:51 +0200
From: Benoit Claise 
User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1
MIME-Version: 1.0
To: "ipfix@ietf.org" , IETF IPPM WG 
References: <20111006001856.ACD1E98C28D@rfc-editor.org>
In-Reply-To: <20111006001856.ACD1E98C28D@rfc-editor.org>
X-Forwarded-Message-Id: <20111006001856.ACD1E98C28D@rfc-editor.org>
Content-Type: multipart/alternative; boundary="------------030708040603010607060301"
Subject: [IPFIX] Fwd: BCP 170, RFC 6390 on Guidelines for Considering New Performance Metric Development
X-BeenThere: ipfix@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: IPFIX WG discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 10 Oct 2011 15:15:00 -0000

This is a multi-part message in MIME format.
--------------030708040603010607060301
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

Dear all,

This BCP would be of interest to both IPPM and IPFIX WGs

Regards, Benoit.

-------- Original Message --------
Subject: 	BCP 170, RFC 6390 on Guidelines for Considering New 
Performance Metric Development
Date: 	Wed, 5 Oct 2011 17:18:56 -0700 (PDT)
From: 	rfc-editor@rfc-editor.org
To: 	ietf-announce@ietf.org, rfc-dist@rfc-editor.org
CC: 	pmol@ietf.org, rfc-editor@rfc-editor.org



A new Request for Comments is now available in online RFC libraries.

         BCP 170
         RFC 6390

         Title:      Guidelines for Considering New Performance
                     Metric Development
         Author:     A. Clark, B. Claise
         Status:     Best Current Practice
         Stream:     IETF
         Date:       October 2011
         Mailbox:    alan.d.clark@telchemy.com,
                     bclaise@cisco.com
         Pages:      23
         Characters: 49930
         See Also:   BCP0170

         I-D Tag:    draft-ietf-pmol-metrics-framework-12.txt

         URL:        http://www.rfc-editor.org/rfc/rfc6390.txt

This document describes a framework and a process for developing
Performance Metrics of protocols and applications transported over
IETF-specified protocols.  These metrics can be used to characterize
traffic on live networks and services.  This memo documents an
Internet Best Current Practice.

This document is a product of the Performance Metrics for Other Layers Working Group of the IETF.


BCP: This document specifies an Internet Best Current Practices for the
Internet Community, and requests discussion and suggestions for
improvements. Distribution of this memo is unlimited.

This announcement is sent to the IETF-Announce and rfc-dist lists.
To subscribe or unsubscribe, see
   http://www.ietf.org/mailman/listinfo/ietf-announce
   http://mailman.rfc-editor.org/mailman/listinfo/rfc-dist

For searching the RFC series, see http://www.rfc-editor.org/rfcsearch.html.
For downloading RFCs, see http://www.rfc-editor.org/rfc.html.

Requests for special distribution should be addressed to either the
author of the RFC in question, or to rfc-editor@rfc-editor.org.  Unless
specifically noted otherwise on the RFC itself, all RFCs are for
unlimited distribution.


The RFC Editor Team
Association Management Solutions, LLC


_______________________________________________
IETF-Announce mailing list
IETF-Announce@ietf.org
https://www.ietf.org/mailman/listinfo/ietf-announce




--------------030708040603010607060301
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit


  

    
  
  
    Dear all,

    

    This BCP would be of interest to both IPPM and IPFIX WGs

    

    Regards, Benoit.

    

    -------- Original Message --------
    

      
        

          Subject: 
          BCP 170, RFC 6390 on Guidelines for Considering New
            Performance Metric Development
        

        

          Date: 
          Wed, 5 Oct 2011 17:18:56 -0700 (PDT)
        

        

          From: 
          rfc-editor@rfc-editor.org
        

        

          To: 
          ietf-announce@ietf.org, rfc-dist@rfc-editor.org
        

        

          CC: 
          pmol@ietf.org, rfc-editor@rfc-editor.org
        

      
    

    

    

    
A new Request for Comments is now available in online RFC libraries.

        BCP 170        
        RFC 6390

        Title:      Guidelines for Considering New Performance 
                    Metric Development 
        Author:     A. Clark, B. Claise
        Status:     Best Current Practice
        Stream:     IETF
        Date:       October 2011
        Mailbox:    alan.d.clark@telchemy.com, 
                    bclaise@cisco.com
        Pages:      23
        Characters: 49930
        See Also:   BCP0170

        I-D Tag:    draft-ietf-pmol-metrics-framework-12.txt

        URL:        http://www.rfc-editor.org/rfc/rfc6390.txt

This document describes a framework and a process for developing
Performance Metrics of protocols and applications transported over
IETF-specified protocols.  These metrics can be used to characterize
traffic on live networks and services.  This memo documents an 
Internet Best Current Practice.

This document is a product of the Performance Metrics for Other Layers Working Group of the IETF.


BCP: This document specifies an Internet Best Current Practices for the
Internet Community, and requests discussion and suggestions for 
improvements. Distribution of this memo is unlimited.

This announcement is sent to the IETF-Announce and rfc-dist lists.
To subscribe or unsubscribe, see
  http://www.ietf.org/mailman/listinfo/ietf-announce
  http://mailman.rfc-editor.org/mailman/listinfo/rfc-dist

For searching the RFC series, see http://www.rfc-editor.org/rfcsearch.html.
For downloading RFCs, see http://www.rfc-editor.org/rfc.html.

Requests for special distribution should be addressed to either the
author of the RFC in question, or to rfc-editor@rfc-editor.org.  Unless
specifically noted otherwise on the RFC itself, all RFCs are for
unlimited distribution.


The RFC Editor Team
Association Management Solutions, LLC


_______________________________________________
IETF-Announce mailing list
IETF-Announce@ietf.org
https://www.ietf.org/mailman/listinfo/ietf-announce




  


--------------030708040603010607060301--

From Quittek@neclab.eu  Tue Oct 11 01:54:32 2011
Return-Path: 
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 2643821F8D9E for ; Tue, 11 Oct 2011 01:54:32 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.599
X-Spam-Level: 
X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[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 AtHI8aFCNpIr for ; Tue, 11 Oct 2011 01:54:30 -0700 (PDT)
Received: from mailer1.neclab.eu (mailer1.neclab.eu [195.37.70.40]) by ietfa.amsl.com (Postfix) with ESMTP id 1BE7821F8D6F for ; Tue, 11 Oct 2011 01:54:30 -0700 (PDT)
Received: from localhost (localhost.localdomain [127.0.0.1]) by mailer1.neclab.eu (Postfix) with ESMTP id 3A88D280001AA; Tue, 11 Oct 2011 10:54:27 +0200 (CEST)
X-Virus-Scanned: Amavisd on Debian GNU/Linux (atlas1.office.hd)
Received: from mailer1.neclab.eu ([127.0.0.1]) by localhost (atlas1.office.hd [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tAkdiotx85JN; Tue, 11 Oct 2011 10:54:27 +0200 (CEST)
Received: from ENCELADUS.office.hd (ENCELADUS.office.hd [192.168.24.52]) by mailer1.neclab.eu (Postfix) with ESMTP id 032A4280001A7; Tue, 11 Oct 2011 10:54:07 +0200 (CEST)
Received: from DAPHNIS.office.hd ([169.254.2.240]) by ENCELADUS.office.hd ([192.168.24.52]) with mapi id 14.01.0323.003; Tue, 11 Oct 2011 10:53:45 +0200
From: Juergen Quittek 
To: Benoit Claise , Brian Trammell 
Thread-Topic: [IPFIX] proposal for IPFIX charter update
Thread-Index: AQHMh/NIVLS8zVsJ206QoJqoXu0wrg==
Date: Tue, 11 Oct 2011 08:53:46 +0000
Message-ID: 
In-Reply-To: <4E92F0E7.6050501@cisco.com>
Accept-Language: de-DE, en-US
Content-Language: de-DE
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
user-agent: Microsoft-MacOutlook/14.13.0.110805
x-originating-ip: [10.1.2.219]
Content-Type: text/plain; charset="us-ascii"
Content-ID: 
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: Nevil Brownlee , IETF IPFIX Working Group 
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 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 11 Oct 2011 08:54:32 -0000

Hi Benoit and Brian,

Thank you for your comments.
Here comes another update.

    Juergen

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

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 existing 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.

All following items 2.-7. will be in line with the revised versions
of the IPFIX protocol specifications and the IPFIX information model.

2. In order to provide 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 a set of specifications for applying the IPFIX protocol at
mediators, including new specifications for protocol issues not
envisioned by the IPFIX protocol itself.

4.In order to support 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 MIB modules.

7. Operational experiences showed that it would be useful to define
several new information elements for data link monitoring covering
frame size, type, sections of frames, and VLAN information. The IPFIX
WG will create a document defining these new information elements.


Oct 2011   Publish Internet-Draftt on guidelines for IE doctors
Oct 2011   Publish Internet-Draft on IPFIX use at mediators
Oct 2011   Publish Internet-Draft on intermediate aggregation
Oct 2011   Publish Internet-Draft on exporting MIB objects
Oct 2011   Publish Internet-Draft on data link IEs
Oct 2011   Publish Internet-Draft on revised IPFIX MIB
Dec 2011   Publish Internet-Draft revising RFC 5101
Dec 2011   Publish Internet-Draft revising RFC 5102

Apr 2012   Submit guidelines for IE doctors for publication as
           Informational BCP RFC
Apr 2012   Submit IPFIX use at mediators for publication as
           Standards track RFC
Apr 2012   Submit intermediate aggregation for publication as
           Standards track RFC
Apr 2012   Submit data link IEs for publication as
           Standards track RFC
Apr 2012   Submit revised RFC 5101 for publication as
           Standards track RFC
Apr 2012   Submit revised IPFIX MIB for publications as
           Standards track RFC
Apr 2012   Submit revised RFC 5102 for publication as
           Standards track RFC
Sep 2012   Submit export of MIB objects for publication as
           Standards track RFC



On 10.10.11 15:19, "Benoit Claise"  wrote:

>Hi Brian,
>
>That works for me. Thanks for the better wording.
>
>Regards, Benoit.
>> Hi, Benoit, all,
>>
>> I'm not quite happy with any of these characterizations... "extension"
>>means to me "I have to worry about this, even if I don't care about
>>Mediators". Since there is _nothing_ in medproto which would require an
>>Original Exporter to do something differently when sending to a
>>Mediator, or would require a Collector to do something differently when
>>receiving from a Mediator, AFAICT this is not the case (and should not
>>be)...
>>
>> So, how about:
>>
>>
>> a set of specifications for applying the IPFIX Protocol at Mediators,
>>including new specifications for protocol issues not envisioned by the
>>IPFIX Protocol itself.
>>
>> Regards,
>>
>> Brian
>>
>> On Oct 9, 2011, at 9:15 AM, Benoit Claise wrote:
>>
>>> Hi Juergen,
>>>
>>> It's an extension/modification of the IPFIX protocol addressing the
>>>use with mediation.
>>> I'm not too sure what is the difference between extension and
>>>modification.
>>> However, since it's based on RFC5101, I would say an extension.
>>>
>>> Regards, Benoit.
>>>> Dear Benoit,
>>>>
>>>> I am sorry for missing your comment.  The point you are raising
>>>>addresses the nature of the mediation protocol draft.  Is it
>>>>    - a guideline how to use the IPFIX protocol for use with mediation?
>>>>    - is it an modification of the IPFIX protocol addressing the use
>>>>with mediation?
>>>>    - is it an extension of the IPFIX protocol addressing the use with
>>>>mediation?
>>>>    - is it a new protocol?
>>>>
>>>> I think the text that you are proposing comes closer to what the
>>>>draft does.  However, I would like to have the question above answered
>>>>clearly before finalizing the charter update.
>>>>
>>>> Thanks,
>>>>
>>>>      Juergen
>>>>
>>>>
>>>> On 03.10.11 23:38, "Ben Claise"  wrote:
>>>>
>>>> Juergen,
>>>>
>>>> One comment that was forgotten.
>>>> See inline.
>>>>> Dear all,
>>>>>
>>>>> Below please find an update of the proposed IPFIX charter update.
>>>>> It addresses all comments posted on the list.
>>>>> The only major change is adding item 7 on link layer IEs.
>>>>>
>>>>> Please send you comments on this version until next Monday, Oct 10.
>>>>>
>>>>> 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 existing 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.
>>>>>
>>>>> All following items 2.-7. will be in line with the revised versions
>>>>> of the IPFIX protocol specifications and the IPFIX information model.
>>>>>
>>>>> 2. In order to provide 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.
>>>>>
>>>> Here is the comment I made earlier in this email thread:
>>>> "common ways", "specifying guidelines for the use of the IPFIX
>>>>protocol": actually it's a real protocol specification, which will be
>>>>standard track.
>>>> Should we be more specific?
>>>> Note that=20
>>>>http://tools.ietf.org/html/draft-claise-ipfix-mediation-protocol-04
>>>>title is: Specification of the Protocol for IPFIX Mediations
>>>>
>>>> For example:
>>>>
>>>> 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
>>>> produce the protocol specifications in order to solve these IPFIX
>>>>mediation
>>>> specific problems.
>>>>
>>>> Regards, Benoit.
>>>>> 4.In order to support 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 MIB modules.
>>>>>
>>>>> 7. Operational experiences showed that it would be useful to define
>>>>> several new information elements for data link monitoring covering
>>>>> frame size, type, sections of frames, and VLAN information. The IPFIX
>>>>> WG will create a document defining these new information elements.
>>>>>
>>>>>
>>>>> Oct 2011    Publish Internet-Draftt on guidelines for IE doctors
>>>>> Oct 2011    Publish Internet-Draft on IPFIX use at mediators
>>>>> Oct 2011    Publish Internet-Draft on intermediate aggregation
>>>>> Oct 2011    Publish Internet-Draft on exporting MIB objects
>>>>> Oct 2011    Publish Internet-Draft on data link IEs
>>>>> Oct 2011    Publish Internet-Draft on revised IPFIX MIB
>>>>> Dec 2011    Publish Internet-Draft revising RFC 5101
>>>>> Dec 2011    Publish Internet-Draft revising RFC 5102
>>>>>
>>>>> Apr 2012    Submit guidelines for IE doctors for publication as
>>>>>              Informational BCP RFC
>>>>> Apr 2012    Submit IPFIX use at mediators for publication as
>>>>>              Standards track RFC
>>>>> Apr 2012    Submit intermediate aggregation for publication as
>>>>>              Standards track RFC
>>>>> Apr 2012    Submit data link IEs for publication as
>>>>>              Standards track RFC
>>>>> Apr 2012    Submit revised RFC 5101 for publication as
>>>>>              Standards track RFC
>>>>> Apr 2012    Submit revised IPFIX MIB for publications as
>>>>>              Standards track RFC
>>>>> Apr 2012    Submit revised RFC 5102 for publication as
>>>>>              Standards track RFC
>>>>> Sep 2012    Submit export of MIB objects for publication as
>>>>>              Standards track RFC
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> On 30.09.11 09:18, "Juergen Quittek"
>>>>> 
>>>>>   wrote:
>>>>>
>>>>>
>>>>>> Nevil,
>>>>>>
>>>>>> Thanks for the summary.
>>>>>> I will post a new version of the charter at the weekend.
>>>>>>
>>>>>>     Juergen
>>>>>>
>>>>>> On 30.09.11 00:10, "Nevil Brownlee"
>>>>>> 
>>>>>>   wrote:
>>>>>>
>>>>>>
>>>>>>> Hi all:
>>>>>>>
>>>>>>> Juergen posted the proposed new IPFIX charter at the end of August.
>>>>>>> I've only seen one comment on it, which was "what happened to the
>>>>>>> Link Layer IEs draft?"
>>>>>>>
>>>>>>> Looking at the minutes from our meeting in Quebec, we said
>>>>>>> "We discussed whether this could be a 'trial run for the
>>>>>>> IE Doctors,' or a WG item.  We reached consensus for it as a WG
>>>>>>>item,
>>>>>>> with the proviso that it will need views from Layer 2 domain
>>>>>>>experts,
>>>>>>> e.g. IEEE 802.1."
>>>>>>>
>>>>>>> So Juergen, please add this as one more charter item.
>>>>>>>
>>>>>>> With that, I think we're ready to ask Dan to take it to IESG for
>>>>>>> approval.
>>>>>>>
>>>>>>> Cheers, Nevil
>>>>>>>
>>>>>>> PS: it's really good to see lots of discussion on the IPFIX list
>>>>>>>      about improvements to 5101 et al :-)
>>>>>>>
>>>>>>>
>>>>>>> On 29/09/11 2:40 AM, Benoit Claise wrote:
>>>>>>>
>>>>>>>> IPFIX chairs,
>>>>>>>>
>>>>>>>>> Hi Juergen,
>>>>>>>>>
>>>>>>>>> The IPFIX configuration data model is pending because of the
>>>>>>>>>IPFIX and
>>>>>>>>> PSAMP MIBs. IMO, solving the SELECTOR MIB issue should be of
>>>>>>>>>highest
>>>>>>>>> priority, and a solution be published before any other new draft.
>>>>>>>>>
>>>>>>>> I agree.
>>>>>>>>
>>>>>>>> Btw, where is the new charter? ;-) There is always a tendency to
>>>>>>>>delay
>>>>>>>> work for which there is no deadlines...
>>>>>>>>
>>>>>>>> Regards, Benoit.
>>>>>>>>
>>>>>>>>> (I already see IPFIX config being outdated by RFC5101/5102bis
>>>>>>>>>before
>>>>>>>>> it ever becomes RFC...)
>>>>>>>>>
>>>>>>>>> Regards,
>>>>>>>>> Gerhard
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> On 29.08.2011 06:57, Juergen Quittek wrote:
>>>>>>>>>
>>>>>>>>>> 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.orghttps://www.ietf.org/mailman/listinfo/ipfix
>>>>>>>>> _______________________________________________
>>>>>>>>> IPFIX mailing list
>>>>>>>>>
>>>>>>>>> IPFIX@ietf.orghttps://www.ietf.org/mailman/listinfo/ipfix
>>>>>>>> _______________________________________________
>>>>>>>> IPFIX mailing list
>>>>>>>>
>>>>>>>> IPFIX@ietf.orghttps://www.ietf.org/mailman/listinfo/ipfix
>>>>>>> --=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.orghttps://www.ietf.org/mailman/listinfo/ipfix
>>>>>> _______________________________________________
>>>>>> IPFIX mailing list
>>>>>>
>>>>>> IPFIX@ietf.orghttps://www.ietf.org/mailman/listinfo/ipfix
>>> _______________________________________________
>>> IPFIX mailing list
>>> IPFIX@ietf.org
>>> https://www.ietf.org/mailman/listinfo/ipfix
>>
>>
>


From trammell@tik.ee.ethz.ch  Tue Oct 11 02:04:29 2011
Return-Path: 
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 70BA821F8D87 for ; Tue, 11 Oct 2011 02:04:29 -0700 (PDT)
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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id edvSbkockrq1 for ; Tue, 11 Oct 2011 02:04:27 -0700 (PDT)
Received: from smtp.ee.ethz.ch (smtp.ee.ethz.ch [129.132.2.219]) by ietfa.amsl.com (Postfix) with ESMTP id 68A5B21F8D85 for ; Tue, 11 Oct 2011 02:04:27 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by smtp.ee.ethz.ch (Postfix) with ESMTP id 7A13CD9319; Tue, 11 Oct 2011 11:04:26 +0200 (MEST)
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 gXN3LkDSiSV3; Tue, 11 Oct 2011 11:04:26 +0200 (MEST)
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 5B15FD9317; Tue, 11 Oct 2011 11:04:25 +0200 (MEST)
Mime-Version: 1.0 (Apple Message framework v1084)
Content-Type: text/plain; charset=us-ascii
From: Brian Trammell 
In-Reply-To: 
Date: Tue, 11 Oct 2011 11:04:23 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: 
References: 
To: Juergen Quittek 
X-Mailer: Apple Mail (2.1084)
Cc: Nevil Brownlee , IETF IPFIX Working Group 
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 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 11 Oct 2011 09:04:29 -0000

Hi, Juergen,

Two quick comments inline

Cheers, Brian

On Oct 11, 2011, at 10:53 AM, Juergen Quittek wrote:

> Hi Benoit and Brian,
>=20
> Thank you for your comments.
> Here comes another update.
>=20
>    Juergen
>=20
> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
>=20
> IP Flow Information Export (ipfix)
>=20
> Description of Working Group
>=20
> 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.
>=20
> 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.
>=20
> 1. Having a solid standardized base for IPFIX deployment and operation
> and several existing 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.

=46rom a suggestion by Dan 13 Sep, and in view of the fact that =
draft-housley-two-maturity-levels was approved by the IESG on 8 Sep and =
is in the RFC Editor queue, this should read

"in order to advance them to the next stage on the standards track."

> All following items 2.-7. will be in line with the revised versions
> of the IPFIX protocol specifications and the IPFIX information model.
>=20
> 2. In order to provide 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.
>=20
> 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 a set of specifications for applying the IPFIX protocol at
> mediators, including new specifications for protocol issues not
> envisioned by the IPFIX protocol itself.
>=20
> 4.In order to support 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.
>=20
> 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.
>=20
> 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 MIB modules.
>=20
> 7. Operational experiences showed that it would be useful to define
> several new information elements for data link monitoring covering
> frame size, type, sections of frames, and VLAN information. The IPFIX
> WG will create a document defining these new information elements.
>=20
>=20
> Oct 2011   Publish Internet-Draftt on guidelines for IE doctors
                                  ^ typo, extra 't'
> Oct 2011   Publish Internet-Draft on IPFIX use at mediators
> Oct 2011   Publish Internet-Draft on intermediate aggregation
> Oct 2011   Publish Internet-Draft on exporting MIB objects
> Oct 2011   Publish Internet-Draft on data link IEs
> Oct 2011   Publish Internet-Draft on revised IPFIX MIB
> Dec 2011   Publish Internet-Draft revising RFC 5101
> Dec 2011   Publish Internet-Draft revising RFC 5102
>=20
> Apr 2012   Submit guidelines for IE doctors for publication as
>           Informational BCP RFC
> Apr 2012   Submit IPFIX use at mediators for publication as
>           Standards track RFC
> Apr 2012   Submit intermediate aggregation for publication as
>           Standards track RFC
> Apr 2012   Submit data link IEs for publication as
>           Standards track RFC
> Apr 2012   Submit revised RFC 5101 for publication as
>           Standards track RFC
> Apr 2012   Submit revised IPFIX MIB for publications as
>           Standards track RFC
> Apr 2012   Submit revised RFC 5102 for publication as
>           Standards track RFC
> Sep 2012   Submit export of MIB objects for publication as
>           Standards track RFC
>=20
>=20
>=20
> On 10.10.11 15:19, "Benoit Claise"  wrote:
>=20
>> Hi Brian,
>>=20
>> That works for me. Thanks for the better wording.
>>=20
>> Regards, Benoit.
>>> Hi, Benoit, all,
>>>=20
>>> I'm not quite happy with any of these characterizations... =
"extension"
>>> means to me "I have to worry about this, even if I don't care about
>>> Mediators". Since there is _nothing_ in medproto which would require =
an
>>> Original Exporter to do something differently when sending to a
>>> Mediator, or would require a Collector to do something differently =
when
>>> receiving from a Mediator, AFAICT this is not the case (and should =
not
>>> be)...
>>>=20
>>> So, how about:
>>>=20
>>>=20
>>> a set of specifications for applying the IPFIX Protocol at =
Mediators,
>>> including new specifications for protocol issues not envisioned by =
the
>>> IPFIX Protocol itself.
>>>=20
>>> Regards,
>>>=20
>>> Brian
>>>=20
>>> On Oct 9, 2011, at 9:15 AM, Benoit Claise wrote:
>>>=20
>>>> Hi Juergen,
>>>>=20
>>>> It's an extension/modification of the IPFIX protocol addressing the
>>>> use with mediation.
>>>> I'm not too sure what is the difference between extension and
>>>> modification.
>>>> However, since it's based on RFC5101, I would say an extension.
>>>>=20
>>>> Regards, Benoit.
>>>>> Dear Benoit,
>>>>>=20
>>>>> I am sorry for missing your comment.  The point you are raising
>>>>> addresses the nature of the mediation protocol draft.  Is it
>>>>>   - a guideline how to use the IPFIX protocol for use with =
mediation?
>>>>>   - is it an modification of the IPFIX protocol addressing the use
>>>>> with mediation?
>>>>>   - is it an extension of the IPFIX protocol addressing the use =
with
>>>>> mediation?
>>>>>   - is it a new protocol?
>>>>>=20
>>>>> I think the text that you are proposing comes closer to what the
>>>>> draft does.  However, I would like to have the question above =
answered
>>>>> clearly before finalizing the charter update.
>>>>>=20
>>>>> Thanks,
>>>>>=20
>>>>>     Juergen
>>>>>=20
>>>>>=20
>>>>> On 03.10.11 23:38, "Ben Claise"  wrote:
>>>>>=20
>>>>> Juergen,
>>>>>=20
>>>>> One comment that was forgotten.
>>>>> See inline.
>>>>>> Dear all,
>>>>>>=20
>>>>>> Below please find an update of the proposed IPFIX charter update.
>>>>>> It addresses all comments posted on the list.
>>>>>> The only major change is adding item 7 on link layer IEs.
>>>>>>=20
>>>>>> Please send you comments on this version until next Monday, Oct =
10.
>>>>>>=20
>>>>>> Thanks,
>>>>>>=20
>>>>>>     Juergen
>>>>>>=20
>>>>>>=20
>>>>>> IP Flow Information Export (ipfix)
>>>>>>=20
>>>>>> Description of Working Group
>>>>>>=20
>>>>>> 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.
>>>>>>=20
>>>>>> 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.
>>>>>>=20
>>>>>> 1. Having a solid standardized base for IPFIX deployment and
>>>>>> operation
>>>>>> and several existing 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.
>>>>>>=20
>>>>>> All following items 2.-7. will be in line with the revised =
versions
>>>>>> of the IPFIX protocol specifications and the IPFIX information =
model.
>>>>>>=20
>>>>>> 2. In order to provide 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.
>>>>>>=20
>>>>>> 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.
>>>>>>=20
>>>>> Here is the comment I made earlier in this email thread:
>>>>> "common ways", "specifying guidelines for the use of the IPFIX
>>>>> protocol": actually it's a real protocol specification, which will =
be
>>>>> standard track.
>>>>> Should we be more specific?
>>>>> Note that=20
>>>>> =
http://tools.ietf.org/html/draft-claise-ipfix-mediation-protocol-04
>>>>> title is: Specification of the Protocol for IPFIX Mediations
>>>>>=20
>>>>> For example:
>>>>>=20
>>>>> 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
>>>>> produce the protocol specifications in order to solve these IPFIX
>>>>> mediation
>>>>> specific problems.
>>>>>=20
>>>>> Regards, Benoit.
>>>>>> 4.In order to support 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.
>>>>>>=20
>>>>>> 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 MIB modules.
>>>>>>=20
>>>>>> 7. Operational experiences showed that it would be useful to =
define
>>>>>> several new information elements for data link monitoring =
covering
>>>>>> frame size, type, sections of frames, and VLAN information. The =
IPFIX
>>>>>> WG will create a document defining these new information =
elements.
>>>>>>=20
>>>>>>=20
>>>>>> Oct 2011    Publish Internet-Draftt on guidelines for IE doctors
>>>>>> Oct 2011    Publish Internet-Draft on IPFIX use at mediators
>>>>>> Oct 2011    Publish Internet-Draft on intermediate aggregation
>>>>>> Oct 2011    Publish Internet-Draft on exporting MIB objects
>>>>>> Oct 2011    Publish Internet-Draft on data link IEs
>>>>>> Oct 2011    Publish Internet-Draft on revised IPFIX MIB
>>>>>> Dec 2011    Publish Internet-Draft revising RFC 5101
>>>>>> Dec 2011    Publish Internet-Draft revising RFC 5102
>>>>>>=20
>>>>>> Apr 2012    Submit guidelines for IE doctors for publication as
>>>>>>             Informational BCP RFC
>>>>>> Apr 2012    Submit IPFIX use at mediators for publication as
>>>>>>             Standards track RFC
>>>>>> Apr 2012    Submit intermediate aggregation for publication as
>>>>>>             Standards track RFC
>>>>>> Apr 2012    Submit data link IEs for publication as
>>>>>>             Standards track RFC
>>>>>> Apr 2012    Submit revised RFC 5101 for publication as
>>>>>>             Standards track RFC
>>>>>> Apr 2012    Submit revised IPFIX MIB for publications as
>>>>>>             Standards track RFC
>>>>>> Apr 2012    Submit revised RFC 5102 for publication as
>>>>>>             Standards track RFC
>>>>>> Sep 2012    Submit export of MIB objects for publication as
>>>>>>             Standards track RFC
>>>>>>=20
>>>>>>=20
>>>>>>=20
>>>>>>=20
>>>>>> On 30.09.11 09:18, "Juergen Quittek"
>>>>>> 
>>>>>>  wrote:
>>>>>>=20
>>>>>>=20
>>>>>>> Nevil,
>>>>>>>=20
>>>>>>> Thanks for the summary.
>>>>>>> I will post a new version of the charter at the weekend.
>>>>>>>=20
>>>>>>>    Juergen
>>>>>>>=20
>>>>>>> On 30.09.11 00:10, "Nevil Brownlee"
>>>>>>> 
>>>>>>>  wrote:
>>>>>>>=20
>>>>>>>=20
>>>>>>>> Hi all:
>>>>>>>>=20
>>>>>>>> Juergen posted the proposed new IPFIX charter at the end of =
August.
>>>>>>>> I've only seen one comment on it, which was "what happened to =
the
>>>>>>>> Link Layer IEs draft?"
>>>>>>>>=20
>>>>>>>> Looking at the minutes from our meeting in Quebec, we said
>>>>>>>> "We discussed whether this could be a 'trial run for the
>>>>>>>> IE Doctors,' or a WG item.  We reached consensus for it as a WG
>>>>>>>> item,
>>>>>>>> with the proviso that it will need views from Layer 2 domain
>>>>>>>> experts,
>>>>>>>> e.g. IEEE 802.1."
>>>>>>>>=20
>>>>>>>> So Juergen, please add this as one more charter item.
>>>>>>>>=20
>>>>>>>> With that, I think we're ready to ask Dan to take it to IESG =
for
>>>>>>>> approval.
>>>>>>>>=20
>>>>>>>> Cheers, Nevil
>>>>>>>>=20
>>>>>>>> PS: it's really good to see lots of discussion on the IPFIX =
list
>>>>>>>>     about improvements to 5101 et al :-)
>>>>>>>>=20
>>>>>>>>=20
>>>>>>>> On 29/09/11 2:40 AM, Benoit Claise wrote:
>>>>>>>>=20
>>>>>>>>> IPFIX chairs,
>>>>>>>>>=20
>>>>>>>>>> Hi Juergen,
>>>>>>>>>>=20
>>>>>>>>>> The IPFIX configuration data model is pending because of the
>>>>>>>>>> IPFIX and
>>>>>>>>>> PSAMP MIBs. IMO, solving the SELECTOR MIB issue should be of
>>>>>>>>>> highest
>>>>>>>>>> priority, and a solution be published before any other new =
draft.
>>>>>>>>>>=20
>>>>>>>>> I agree.
>>>>>>>>>=20
>>>>>>>>> Btw, where is the new charter? ;-) There is always a tendency =
to
>>>>>>>>> delay
>>>>>>>>> work for which there is no deadlines...
>>>>>>>>>=20
>>>>>>>>> Regards, Benoit.
>>>>>>>>>=20
>>>>>>>>>> (I already see IPFIX config being outdated by RFC5101/5102bis
>>>>>>>>>> before
>>>>>>>>>> it ever becomes RFC...)
>>>>>>>>>>=20
>>>>>>>>>> Regards,
>>>>>>>>>> Gerhard
>>>>>>>>>>=20
>>>>>>>>>>=20
>>>>>>>>>> On 29.08.2011 06:57, Juergen Quittek wrote:
>>>>>>>>>>=20
>>>>>>>>>>> Dear all,
>>>>>>>>>>>=20
>>>>>>>>>>> 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.
>>>>>>>>>>>=20
>>>>>>>>>>> Please have a look at it and send us your comments.
>>>>>>>>>>>=20
>>>>>>>>>>> Thanks,
>>>>>>>>>>>=20
>>>>>>>>>>> Juergen
>>>>>>>>>>>=20
>>>>>>>>>>>=20
>>>>>>>>>>> IP Flow Information Export (ipfix)
>>>>>>>>>>>=20
>>>>>>>>>>>=20
>>>>>>>>>>> Description of Working Group
>>>>>>>>>>>=20
>>>>>>>>>>>=20
>>>>>>>>>>> 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.
>>>>>>>>>>>=20
>>>>>>>>>>> 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.
>>>>>>>>>>>=20
>>>>>>>>>>> 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.
>>>>>>>>>>>=20
>>>>>>>>>>> 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.
>>>>>>>>>>>=20
>>>>>>>>>>> 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.
>>>>>>>>>>>=20
>>>>>>>>>>> 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.
>>>>>>>>>>>=20
>>>>>>>>>>> 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.
>>>>>>>>>>>=20
>>>>>>>>>>> 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.
>>>>>>>>>>>=20
>>>>>>>>>>> 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
>>>>>>>>>>>=20
>>>>>>>>>>> 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
>>>>>>>>>>>=20
>>>>>>>>>>>=20
>>>>>>>>>>> _______________________________________________
>>>>>>>>>>> IPFIX mailing list
>>>>>>>>>>>=20
>>>>>>>>>>> IPFIX@ietf.orghttps://www.ietf.org/mailman/listinfo/ipfix
>>>>>>>>>> _______________________________________________
>>>>>>>>>> IPFIX mailing list
>>>>>>>>>>=20
>>>>>>>>>> IPFIX@ietf.orghttps://www.ietf.org/mailman/listinfo/ipfix
>>>>>>>>> _______________________________________________
>>>>>>>>> IPFIX mailing list
>>>>>>>>>=20
>>>>>>>>> IPFIX@ietf.orghttps://www.ietf.org/mailman/listinfo/ipfix
>>>>>>>> --=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
>>>>>>>>=20
>>>>>>>> IPFIX@ietf.orghttps://www.ietf.org/mailman/listinfo/ipfix
>>>>>>> _______________________________________________
>>>>>>> IPFIX mailing list
>>>>>>>=20
>>>>>>> IPFIX@ietf.orghttps://www.ietf.org/mailman/listinfo/ipfix
>>>> _______________________________________________
>>>> IPFIX mailing list
>>>> IPFIX@ietf.org
>>>> https://www.ietf.org/mailman/listinfo/ipfix
>>>=20
>>>=20
>>=20


From Quittek@neclab.eu  Tue Oct 11 02:26:27 2011
Return-Path: 
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 7A7B121F8C47 for ; Tue, 11 Oct 2011 02:26:27 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.599
X-Spam-Level: 
X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[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 uCmmEgaRRnpj for ; Tue, 11 Oct 2011 02:26:27 -0700 (PDT)
Received: from mailer1.neclab.eu (mailer1.neclab.eu [195.37.70.40]) by ietfa.amsl.com (Postfix) with ESMTP id E512221F8C3C for ; Tue, 11 Oct 2011 02:26:26 -0700 (PDT)
Received: from localhost (localhost.localdomain [127.0.0.1]) by mailer1.neclab.eu (Postfix) with ESMTP id D1A56280001A8; Tue, 11 Oct 2011 11:25:11 +0200 (CEST)
X-Virus-Scanned: Amavisd on Debian GNU/Linux (atlas1.office.hd)
Received: from mailer1.neclab.eu ([127.0.0.1]) by localhost (atlas1.office.hd [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CB4+F+yE6FVL; Tue, 11 Oct 2011 11:25:11 +0200 (CEST)
Received: from ENCELADUS.office.hd (ENCELADUS.office.hd [192.168.24.52]) by mailer1.neclab.eu (Postfix) with ESMTP id B3F4B280001A7; Tue, 11 Oct 2011 11:24:51 +0200 (CEST)
Received: from DAPHNIS.office.hd ([169.254.2.240]) by ENCELADUS.office.hd ([192.168.24.52]) with mapi id 14.01.0323.003; Tue, 11 Oct 2011 11:24:51 +0200
From: Juergen Quittek 
To: Brian Trammell 
Thread-Topic: [IPFIX] proposal for IPFIX charter update
Thread-Index: AQHMh/ehYsYgjdHJ2USrk0i+Avf32Q==
Date: Tue, 11 Oct 2011 09:24:52 +0000
Message-ID: 
In-Reply-To: 
Accept-Language: de-DE, en-US
Content-Language: de-DE
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
user-agent: Microsoft-MacOutlook/14.13.0.110805
x-originating-ip: [10.1.2.219]
Content-Type: text/plain; charset="us-ascii"
Content-ID: <140290281AF46347B3A350280B7FF37C@office.hd>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: Nevil Brownlee , IETF IPFIX Working Group 
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 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 11 Oct 2011 09:26:27 -0000

Hi Brian,

On 11.10.11 11:04, "Brian Trammell"  wrote:

>Hi, Juergen,
>
>Two quick comments inline
>
>Cheers, Brian
>
>On Oct 11, 2011, at 10:53 AM, Juergen Quittek wrote:
>
>> Hi Benoit and Brian,
>>=20
>> Thank you for your comments.
>> Here comes another update.
>>=20
>>    Juergen
>>=20
>> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
>>=20
>> IP Flow Information Export (ipfix)
>>=20
>> Description of Working Group
>>=20
>> 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.
>>=20
>> 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.
>>=20
>> 1. Having a solid standardized base for IPFIX deployment and operation
>> and several existing 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.
>
>From a suggestion by Dan 13 Sep, and in view of the fact that
>draft-housley-two-maturity-levels was approved by the IESG on 8 Sep and
>is in the RFC Editor queue, this should read
>
>"in order to advance them to the next stage on the standards track."

Yes. Thanks.
And I will also fix the typo you found.

    Juergen



From bclaise@cisco.com  Tue Oct 11 02:31:09 2011
Return-Path: 
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 CDEC721F8C42 for ; Tue, 11 Oct 2011 02:31:09 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.413
X-Spam-Level: 
X-Spam-Status: No, score=-2.413 tagged_above=-999 required=5 tests=[AWL=0.186,  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 5xHcEEjqQ6kV for ; Tue, 11 Oct 2011 02:31:08 -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 9745621F8C3E for ; Tue, 11 Oct 2011 02:31:07 -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 p9B9V00e020583; Tue, 11 Oct 2011 11:31:00 +0200 (CEST)
Received: from [10.60.67.84] (ams-bclaise-8913.cisco.com [10.60.67.84]) by strange-brew.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id p9B9UuF2007517; Tue, 11 Oct 2011 11:30:56 +0200 (CEST)
Message-ID: <4E940CD0.8040007@cisco.com>
Date: Tue, 11 Oct 2011 11:30:56 +0200
From: Benoit Claise 
User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1
MIME-Version: 1.0
To: Brian Trammell 
References:  
In-Reply-To: 
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Cc: Nevil Brownlee , IETF IPFIX Working Group 
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 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 11 Oct 2011 09:31:09 -0000

Brian, Juergen,

Actually, the BCP 9, RFC 6410 on Reducing the Standards Track to Two 
Maturity Levels, is out.
Not sure if that changes anything for the charter though.

Regards, Benoit.
> Hi, Juergen,
>
> Two quick comments inline
>
> Cheers, Brian
>
> On Oct 11, 2011, at 10:53 AM, Juergen Quittek wrote:
>
>> Hi Benoit and Brian,
>>
>> Thank you for your comments.
>> Here comes another update.
>>
>>     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 existing 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.
> > From a suggestion by Dan 13 Sep, and in view of the fact that draft-housley-two-maturity-levels was approved by the IESG on 8 Sep and is in the RFC Editor queue, this should read
>
> "in order to advance them to the next stage on the standards track."
>
>> All following items 2.-7. will be in line with the revised versions
>> of the IPFIX protocol specifications and the IPFIX information model.
>>
>> 2. In order to provide 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 a set of specifications for applying the IPFIX protocol at
>> mediators, including new specifications for protocol issues not
>> envisioned by the IPFIX protocol itself.
>>
>> 4.In order to support 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 MIB modules.
>>
>> 7. Operational experiences showed that it would be useful to define
>> several new information elements for data link monitoring covering
>> frame size, type, sections of frames, and VLAN information. The IPFIX
>> WG will create a document defining these new information elements.
>>
>>
>> Oct 2011   Publish Internet-Draftt on guidelines for IE doctors
>                                    ^ typo, extra 't'
>> Oct 2011   Publish Internet-Draft on IPFIX use at mediators
>> Oct 2011   Publish Internet-Draft on intermediate aggregation
>> Oct 2011   Publish Internet-Draft on exporting MIB objects
>> Oct 2011   Publish Internet-Draft on data link IEs
>> Oct 2011   Publish Internet-Draft on revised IPFIX MIB
>> Dec 2011   Publish Internet-Draft revising RFC 5101
>> Dec 2011   Publish Internet-Draft revising RFC 5102
>>
>> Apr 2012   Submit guidelines for IE doctors for publication as
>>            Informational BCP RFC
>> Apr 2012   Submit IPFIX use at mediators for publication as
>>            Standards track RFC
>> Apr 2012   Submit intermediate aggregation for publication as
>>            Standards track RFC
>> Apr 2012   Submit data link IEs for publication as
>>            Standards track RFC
>> Apr 2012   Submit revised RFC 5101 for publication as
>>            Standards track RFC
>> Apr 2012   Submit revised IPFIX MIB for publications as
>>            Standards track RFC
>> Apr 2012   Submit revised RFC 5102 for publication as
>>            Standards track RFC
>> Sep 2012   Submit export of MIB objects for publication as
>>            Standards track RFC
>>
>>
>>
>> On 10.10.11 15:19, "Benoit Claise"  wrote:
>>
>>> Hi Brian,
>>>
>>> That works for me. Thanks for the better wording.
>>>
>>> Regards, Benoit.
>>>> Hi, Benoit, all,
>>>>
>>>> I'm not quite happy with any of these characterizations... "extension"
>>>> means to me "I have to worry about this, even if I don't care about
>>>> Mediators". Since there is _nothing_ in medproto which would require an
>>>> Original Exporter to do something differently when sending to a
>>>> Mediator, or would require a Collector to do something differently when
>>>> receiving from a Mediator, AFAICT this is not the case (and should not
>>>> be)...
>>>>
>>>> So, how about:
>>>>
>>>>
>>>> a set of specifications for applying the IPFIX Protocol at Mediators,
>>>> including new specifications for protocol issues not envisioned by the
>>>> IPFIX Protocol itself.
>>>>
>>>> Regards,
>>>>
>>>> Brian
>>>>
>>>> On Oct 9, 2011, at 9:15 AM, Benoit Claise wrote:
>>>>
>>>>> Hi Juergen,
>>>>>
>>>>> It's an extension/modification of the IPFIX protocol addressing the
>>>>> use with mediation.
>>>>> I'm not too sure what is the difference between extension and
>>>>> modification.
>>>>> However, since it's based on RFC5101, I would say an extension.
>>>>>
>>>>> Regards, Benoit.
>>>>>> Dear Benoit,
>>>>>>
>>>>>> I am sorry for missing your comment.  The point you are raising
>>>>>> addresses the nature of the mediation protocol draft.  Is it
>>>>>>    - a guideline how to use the IPFIX protocol for use with mediation?
>>>>>>    - is it an modification of the IPFIX protocol addressing the use
>>>>>> with mediation?
>>>>>>    - is it an extension of the IPFIX protocol addressing the use with
>>>>>> mediation?
>>>>>>    - is it a new protocol?
>>>>>>
>>>>>> I think the text that you are proposing comes closer to what the
>>>>>> draft does.  However, I would like to have the question above answered
>>>>>> clearly before finalizing the charter update.
>>>>>>
>>>>>> Thanks,
>>>>>>
>>>>>>      Juergen
>>>>>>
>>>>>>
>>>>>> On 03.10.11 23:38, "Ben Claise"   wrote:
>>>>>>
>>>>>> Juergen,
>>>>>>
>>>>>> One comment that was forgotten.
>>>>>> See inline.
>>>>>>> Dear all,
>>>>>>>
>>>>>>> Below please find an update of the proposed IPFIX charter update.
>>>>>>> It addresses all comments posted on the list.
>>>>>>> The only major change is adding item 7 on link layer IEs.
>>>>>>>
>>>>>>> Please send you comments on this version until next Monday, Oct 10.
>>>>>>>
>>>>>>> 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 existing 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.
>>>>>>>
>>>>>>> All following items 2.-7. will be in line with the revised versions
>>>>>>> of the IPFIX protocol specifications and the IPFIX information model.
>>>>>>>
>>>>>>> 2. In order to provide 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.
>>>>>>>
>>>>>> Here is the comment I made earlier in this email thread:
>>>>>> "common ways", "specifying guidelines for the use of the IPFIX
>>>>>> protocol": actually it's a real protocol specification, which will be
>>>>>> standard track.
>>>>>> Should we be more specific?
>>>>>> Note that
>>>>>> http://tools.ietf.org/html/draft-claise-ipfix-mediation-protocol-04
>>>>>> title is: Specification of the Protocol for IPFIX Mediations
>>>>>>
>>>>>> For example:
>>>>>>
>>>>>> 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
>>>>>> produce the protocol specifications in order to solve these IPFIX
>>>>>> mediation
>>>>>> specific problems.
>>>>>>
>>>>>> Regards, Benoit.
>>>>>>> 4.In order to support 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 MIB modules.
>>>>>>>
>>>>>>> 7. Operational experiences showed that it would be useful to define
>>>>>>> several new information elements for data link monitoring covering
>>>>>>> frame size, type, sections of frames, and VLAN information. The IPFIX
>>>>>>> WG will create a document defining these new information elements.
>>>>>>>
>>>>>>>
>>>>>>> Oct 2011    Publish Internet-Draftt on guidelines for IE doctors
>>>>>>> Oct 2011    Publish Internet-Draft on IPFIX use at mediators
>>>>>>> Oct 2011    Publish Internet-Draft on intermediate aggregation
>>>>>>> Oct 2011    Publish Internet-Draft on exporting MIB objects
>>>>>>> Oct 2011    Publish Internet-Draft on data link IEs
>>>>>>> Oct 2011    Publish Internet-Draft on revised IPFIX MIB
>>>>>>> Dec 2011    Publish Internet-Draft revising RFC 5101
>>>>>>> Dec 2011    Publish Internet-Draft revising RFC 5102
>>>>>>>
>>>>>>> Apr 2012    Submit guidelines for IE doctors for publication as
>>>>>>>              Informational BCP RFC
>>>>>>> Apr 2012    Submit IPFIX use at mediators for publication as
>>>>>>>              Standards track RFC
>>>>>>> Apr 2012    Submit intermediate aggregation for publication as
>>>>>>>              Standards track RFC
>>>>>>> Apr 2012    Submit data link IEs for publication as
>>>>>>>              Standards track RFC
>>>>>>> Apr 2012    Submit revised RFC 5101 for publication as
>>>>>>>              Standards track RFC
>>>>>>> Apr 2012    Submit revised IPFIX MIB for publications as
>>>>>>>              Standards track RFC
>>>>>>> Apr 2012    Submit revised RFC 5102 for publication as
>>>>>>>              Standards track RFC
>>>>>>> Sep 2012    Submit export of MIB objects for publication as
>>>>>>>              Standards track RFC
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> On 30.09.11 09:18, "Juergen Quittek"
>>>>>>> 
>>>>>>>   wrote:
>>>>>>>
>>>>>>>
>>>>>>>> Nevil,
>>>>>>>>
>>>>>>>> Thanks for the summary.
>>>>>>>> I will post a new version of the charter at the weekend.
>>>>>>>>
>>>>>>>>     Juergen
>>>>>>>>
>>>>>>>> On 30.09.11 00:10, "Nevil Brownlee"
>>>>>>>> 
>>>>>>>>   wrote:
>>>>>>>>
>>>>>>>>
>>>>>>>>> Hi all:
>>>>>>>>>
>>>>>>>>> Juergen posted the proposed new IPFIX charter at the end of August.
>>>>>>>>> I've only seen one comment on it, which was "what happened to the
>>>>>>>>> Link Layer IEs draft?"
>>>>>>>>>
>>>>>>>>> Looking at the minutes from our meeting in Quebec, we said
>>>>>>>>> "We discussed whether this could be a 'trial run for the
>>>>>>>>> IE Doctors,' or a WG item.  We reached consensus for it as a WG
>>>>>>>>> item,
>>>>>>>>> with the proviso that it will need views from Layer 2 domain
>>>>>>>>> experts,
>>>>>>>>> e.g. IEEE 802.1."
>>>>>>>>>
>>>>>>>>> So Juergen, please add this as one more charter item.
>>>>>>>>>
>>>>>>>>> With that, I think we're ready to ask Dan to take it to IESG for
>>>>>>>>> approval.
>>>>>>>>>
>>>>>>>>> Cheers, Nevil
>>>>>>>>>
>>>>>>>>> PS: it's really good to see lots of discussion on the IPFIX list
>>>>>>>>>      about improvements to 5101 et al :-)
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> On 29/09/11 2:40 AM, Benoit Claise wrote:
>>>>>>>>>
>>>>>>>>>> IPFIX chairs,
>>>>>>>>>>
>>>>>>>>>>> Hi Juergen,
>>>>>>>>>>>
>>>>>>>>>>> The IPFIX configuration data model is pending because of the
>>>>>>>>>>> IPFIX and
>>>>>>>>>>> PSAMP MIBs. IMO, solving the SELECTOR MIB issue should be of
>>>>>>>>>>> highest
>>>>>>>>>>> priority, and a solution be published before any other new draft.
>>>>>>>>>>>
>>>>>>>>>> I agree.
>>>>>>>>>>
>>>>>>>>>> Btw, where is the new charter? ;-) There is always a tendency to
>>>>>>>>>> delay
>>>>>>>>>> work for which there is no deadlines...
>>>>>>>>>>
>>>>>>>>>> Regards, Benoit.
>>>>>>>>>>
>>>>>>>>>>> (I already see IPFIX config being outdated by RFC5101/5102bis
>>>>>>>>>>> before
>>>>>>>>>>> it ever becomes RFC...)
>>>>>>>>>>>
>>>>>>>>>>> Regards,
>>>>>>>>>>> Gerhard
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> On 29.08.2011 06:57, Juergen Quittek wrote:
>>>>>>>>>>>
>>>>>>>>>>>> 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.orghttps://www.ietf.org/mailman/listinfo/ipfix
>>>>>>>>>>> _______________________________________________
>>>>>>>>>>> IPFIX mailing list
>>>>>>>>>>>
>>>>>>>>>>> IPFIX@ietf.orghttps://www.ietf.org/mailman/listinfo/ipfix
>>>>>>>>>> _______________________________________________
>>>>>>>>>> IPFIX mailing list
>>>>>>>>>>
>>>>>>>>>> IPFIX@ietf.orghttps://www.ietf.org/mailman/listinfo/ipfix
>>>>>>>>> -- 
>>>>>>>>>
>>>>>>>>> --------------------------------------------------------------------
>>>>>>>>> -
>>>>>>>>>   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.orghttps://www.ietf.org/mailman/listinfo/ipfix
>>>>>>>> _______________________________________________
>>>>>>>> IPFIX mailing list
>>>>>>>>
>>>>>>>> IPFIX@ietf.orghttps://www.ietf.org/mailman/listinfo/ipfix
>>>>> _______________________________________________
>>>>> IPFIX mailing list
>>>>> IPFIX@ietf.org
>>>>> https://www.ietf.org/mailman/listinfo/ipfix
>>>>
>
>


From bclaise@cisco.com  Tue Oct 11 02:34:05 2011
Return-Path: 
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 1271D21F8CF0 for ; Tue, 11 Oct 2011 02:34:05 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.436
X-Spam-Level: 
X-Spam-Status: No, score=-2.436 tagged_above=-999 required=5 tests=[AWL=0.163,  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 L4ByiotA6hjs for ; Tue, 11 Oct 2011 02:34:03 -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 0D5E721F8CEF for ; Tue, 11 Oct 2011 02:34:02 -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 p9B9XtGI020962; Tue, 11 Oct 2011 11:33:55 +0200 (CEST)
Received: from [10.60.67.84] (ams-bclaise-8913.cisco.com [10.60.67.84]) by strange-brew.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id p9B9XtVa009547; Tue, 11 Oct 2011 11:33:55 +0200 (CEST)
Message-ID: <4E940D83.1080000@cisco.com>
Date: Tue, 11 Oct 2011 11:33:55 +0200
From: Benoit Claise 
User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1
MIME-Version: 1.0
To: Juergen Quittek 
References: 
In-Reply-To: 
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Cc: Nevil Brownlee , IETF IPFIX Working Group 
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 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 11 Oct 2011 09:34:05 -0000

Juergen,

Taking into account Brian's comments, that works for me.

Regards, Benoit.
> Hi Benoit and Brian,
>
> Thank you for your comments.
> Here comes another update.
>
>      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 existing 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.
>
> All following items 2.-7. will be in line with the revised versions
> of the IPFIX protocol specifications and the IPFIX information model.
>
> 2. In order to provide 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 a set of specifications for applying the IPFIX protocol at
> mediators, including new specifications for protocol issues not
> envisioned by the IPFIX protocol itself.
>
> 4.In order to support 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 MIB modules.
>
> 7. Operational experiences showed that it would be useful to define
> several new information elements for data link monitoring covering
> frame size, type, sections of frames, and VLAN information. The IPFIX
> WG will create a document defining these new information elements.
>
>
> Oct 2011   Publish Internet-Draftt on guidelines for IE doctors
> Oct 2011   Publish Internet-Draft on IPFIX use at mediators
> Oct 2011   Publish Internet-Draft on intermediate aggregation
> Oct 2011   Publish Internet-Draft on exporting MIB objects
> Oct 2011   Publish Internet-Draft on data link IEs
> Oct 2011   Publish Internet-Draft on revised IPFIX MIB
> Dec 2011   Publish Internet-Draft revising RFC 5101
> Dec 2011   Publish Internet-Draft revising RFC 5102
>
> Apr 2012   Submit guidelines for IE doctors for publication as
>             Informational BCP RFC
> Apr 2012   Submit IPFIX use at mediators for publication as
>             Standards track RFC
> Apr 2012   Submit intermediate aggregation for publication as
>             Standards track RFC
> Apr 2012   Submit data link IEs for publication as
>             Standards track RFC
> Apr 2012   Submit revised RFC 5101 for publication as
>             Standards track RFC
> Apr 2012   Submit revised IPFIX MIB for publications as
>             Standards track RFC
> Apr 2012   Submit revised RFC 5102 for publication as
>             Standards track RFC
> Sep 2012   Submit export of MIB objects for publication as
>             Standards track RFC
>
>
>
> On 10.10.11 15:19, "Benoit Claise"  wrote:
>
>> Hi Brian,
>>
>> That works for me. Thanks for the better wording.
>>
>> Regards, Benoit.
>>> Hi, Benoit, all,
>>>
>>> I'm not quite happy with any of these characterizations... "extension"
>>> means to me "I have to worry about this, even if I don't care about
>>> Mediators". Since there is _nothing_ in medproto which would require an
>>> Original Exporter to do something differently when sending to a
>>> Mediator, or would require a Collector to do something differently when
>>> receiving from a Mediator, AFAICT this is not the case (and should not
>>> be)...
>>>
>>> So, how about:
>>>
>>>
>>> a set of specifications for applying the IPFIX Protocol at Mediators,
>>> including new specifications for protocol issues not envisioned by the
>>> IPFIX Protocol itself.
>>>
>>> Regards,
>>>
>>> Brian
>>>
>>> On Oct 9, 2011, at 9:15 AM, Benoit Claise wrote:
>>>
>>>> Hi Juergen,
>>>>
>>>> It's an extension/modification of the IPFIX protocol addressing the
>>>> use with mediation.
>>>> I'm not too sure what is the difference between extension and
>>>> modification.
>>>> However, since it's based on RFC5101, I would say an extension.
>>>>
>>>> Regards, Benoit.
>>>>> Dear Benoit,
>>>>>
>>>>> I am sorry for missing your comment.  The point you are raising
>>>>> addresses the nature of the mediation protocol draft.  Is it
>>>>>     - a guideline how to use the IPFIX protocol for use with mediation?
>>>>>     - is it an modification of the IPFIX protocol addressing the use
>>>>> with mediation?
>>>>>     - is it an extension of the IPFIX protocol addressing the use with
>>>>> mediation?
>>>>>     - is it a new protocol?
>>>>>
>>>>> I think the text that you are proposing comes closer to what the
>>>>> draft does.  However, I would like to have the question above answered
>>>>> clearly before finalizing the charter update.
>>>>>
>>>>> Thanks,
>>>>>
>>>>>       Juergen
>>>>>
>>>>>
>>>>> On 03.10.11 23:38, "Ben Claise"   wrote:
>>>>>
>>>>> Juergen,
>>>>>
>>>>> One comment that was forgotten.
>>>>> See inline.
>>>>>> Dear all,
>>>>>>
>>>>>> Below please find an update of the proposed IPFIX charter update.
>>>>>> It addresses all comments posted on the list.
>>>>>> The only major change is adding item 7 on link layer IEs.
>>>>>>
>>>>>> Please send you comments on this version until next Monday, Oct 10.
>>>>>>
>>>>>> 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 existing 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.
>>>>>>
>>>>>> All following items 2.-7. will be in line with the revised versions
>>>>>> of the IPFIX protocol specifications and the IPFIX information model.
>>>>>>
>>>>>> 2. In order to provide 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.
>>>>>>
>>>>> Here is the comment I made earlier in this email thread:
>>>>> "common ways", "specifying guidelines for the use of the IPFIX
>>>>> protocol": actually it's a real protocol specification, which will be
>>>>> standard track.
>>>>> Should we be more specific?
>>>>> Note that
>>>>> http://tools.ietf.org/html/draft-claise-ipfix-mediation-protocol-04
>>>>> title is: Specification of the Protocol for IPFIX Mediations
>>>>>
>>>>> For example:
>>>>>
>>>>> 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
>>>>> produce the protocol specifications in order to solve these IPFIX
>>>>> mediation
>>>>> specific problems.
>>>>>
>>>>> Regards, Benoit.
>>>>>> 4.In order to support 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 MIB modules.
>>>>>>
>>>>>> 7. Operational experiences showed that it would be useful to define
>>>>>> several new information elements for data link monitoring covering
>>>>>> frame size, type, sections of frames, and VLAN information. The IPFIX
>>>>>> WG will create a document defining these new information elements.
>>>>>>
>>>>>>
>>>>>> Oct 2011    Publish Internet-Draftt on guidelines for IE doctors
>>>>>> Oct 2011    Publish Internet-Draft on IPFIX use at mediators
>>>>>> Oct 2011    Publish Internet-Draft on intermediate aggregation
>>>>>> Oct 2011    Publish Internet-Draft on exporting MIB objects
>>>>>> Oct 2011    Publish Internet-Draft on data link IEs
>>>>>> Oct 2011    Publish Internet-Draft on revised IPFIX MIB
>>>>>> Dec 2011    Publish Internet-Draft revising RFC 5101
>>>>>> Dec 2011    Publish Internet-Draft revising RFC 5102
>>>>>>
>>>>>> Apr 2012    Submit guidelines for IE doctors for publication as
>>>>>>               Informational BCP RFC
>>>>>> Apr 2012    Submit IPFIX use at mediators for publication as
>>>>>>               Standards track RFC
>>>>>> Apr 2012    Submit intermediate aggregation for publication as
>>>>>>               Standards track RFC
>>>>>> Apr 2012    Submit data link IEs for publication as
>>>>>>               Standards track RFC
>>>>>> Apr 2012    Submit revised RFC 5101 for publication as
>>>>>>               Standards track RFC
>>>>>> Apr 2012    Submit revised IPFIX MIB for publications as
>>>>>>               Standards track RFC
>>>>>> Apr 2012    Submit revised RFC 5102 for publication as
>>>>>>               Standards track RFC
>>>>>> Sep 2012    Submit export of MIB objects for publication as
>>>>>>               Standards track RFC
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> On 30.09.11 09:18, "Juergen Quittek"
>>>>>> 
>>>>>>    wrote:
>>>>>>
>>>>>>
>>>>>>> Nevil,
>>>>>>>
>>>>>>> Thanks for the summary.
>>>>>>> I will post a new version of the charter at the weekend.
>>>>>>>
>>>>>>>      Juergen
>>>>>>>
>>>>>>> On 30.09.11 00:10, "Nevil Brownlee"
>>>>>>> 
>>>>>>>    wrote:
>>>>>>>
>>>>>>>
>>>>>>>> Hi all:
>>>>>>>>
>>>>>>>> Juergen posted the proposed new IPFIX charter at the end of August.
>>>>>>>> I've only seen one comment on it, which was "what happened to the
>>>>>>>> Link Layer IEs draft?"
>>>>>>>>
>>>>>>>> Looking at the minutes from our meeting in Quebec, we said
>>>>>>>> "We discussed whether this could be a 'trial run for the
>>>>>>>> IE Doctors,' or a WG item.  We reached consensus for it as a WG
>>>>>>>> item,
>>>>>>>> with the proviso that it will need views from Layer 2 domain
>>>>>>>> experts,
>>>>>>>> e.g. IEEE 802.1."
>>>>>>>>
>>>>>>>> So Juergen, please add this as one more charter item.
>>>>>>>>
>>>>>>>> With that, I think we're ready to ask Dan to take it to IESG for
>>>>>>>> approval.
>>>>>>>>
>>>>>>>> Cheers, Nevil
>>>>>>>>
>>>>>>>> PS: it's really good to see lots of discussion on the IPFIX list
>>>>>>>>       about improvements to 5101 et al :-)
>>>>>>>>
>>>>>>>>
>>>>>>>> On 29/09/11 2:40 AM, Benoit Claise wrote:
>>>>>>>>
>>>>>>>>> IPFIX chairs,
>>>>>>>>>
>>>>>>>>>> Hi Juergen,
>>>>>>>>>>
>>>>>>>>>> The IPFIX configuration data model is pending because of the
>>>>>>>>>> IPFIX and
>>>>>>>>>> PSAMP MIBs. IMO, solving the SELECTOR MIB issue should be of
>>>>>>>>>> highest
>>>>>>>>>> priority, and a solution be published before any other new draft.
>>>>>>>>>>
>>>>>>>>> I agree.
>>>>>>>>>
>>>>>>>>> Btw, where is the new charter? ;-) There is always a tendency to
>>>>>>>>> delay
>>>>>>>>> work for which there is no deadlines...
>>>>>>>>>
>>>>>>>>> Regards, Benoit.
>>>>>>>>>
>>>>>>>>>> (I already see IPFIX config being outdated by RFC5101/5102bis
>>>>>>>>>> before
>>>>>>>>>> it ever becomes RFC...)
>>>>>>>>>>
>>>>>>>>>> Regards,
>>>>>>>>>> Gerhard
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> On 29.08.2011 06:57, Juergen Quittek wrote:
>>>>>>>>>>
>>>>>>>>>>> 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.orghttps://www.ietf.org/mailman/listinfo/ipfix
>>>>>>>>>> _______________________________________________
>>>>>>>>>> IPFIX mailing list
>>>>>>>>>>
>>>>>>>>>> IPFIX@ietf.orghttps://www.ietf.org/mailman/listinfo/ipfix
>>>>>>>>> _______________________________________________
>>>>>>>>> IPFIX mailing list
>>>>>>>>>
>>>>>>>>> IPFIX@ietf.orghttps://www.ietf.org/mailman/listinfo/ipfix
>>>>>>>> -- 
>>>>>>>>
>>>>>>>> --------------------------------------------------------------------
>>>>>>>> -
>>>>>>>>    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.orghttps://www.ietf.org/mailman/listinfo/ipfix
>>>>>>> _______________________________________________
>>>>>>> IPFIX mailing list
>>>>>>>
>>>>>>> IPFIX@ietf.orghttps://www.ietf.org/mailman/listinfo/ipfix
>>>> _______________________________________________
>>>> IPFIX mailing list
>>>> IPFIX@ietf.org
>>>> https://www.ietf.org/mailman/listinfo/ipfix
>>>
>
>


From dannyll@mindspring.com  Tue Oct 11 07:54:38 2011
Return-Path: 
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 F166721F8E07 for ; Tue, 11 Oct 2011 07:54:38 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1
X-Spam-Level: 
X-Spam-Status: No, score=-1 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, DATE_IN_PAST_03_06=0.044, HTML_MESSAGE=0.001, HTML_MIME_NO_HTML_TAG=0.097, MIME_HTML_ONLY=1.457]
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 RW50KBvvCjVG for ; Tue, 11 Oct 2011 07:54:38 -0700 (PDT)
Received: from elasmtp-kukur.atl.sa.earthlink.net (elasmtp-kukur.atl.sa.earthlink.net [209.86.89.65]) by ietfa.amsl.com (Postfix) with ESMTP id 5ACB621F8E05 for ; Tue, 11 Oct 2011 07:54:38 -0700 (PDT)
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=mindspring.com; b=dQ7bPNLmCkWT1Vui8MrObwq10yg+rtKiyKJQx3hVsPG0Ujnq9HTULiw+vCqX1hC9; h=Message-ID:Date:From:Reply-To:To:Subject:Mime-Version:Content-Transfer-Encoding:X-Mailer:Content-Type:X-ELNK-Trace:X-Originating-IP;
Received: from [209.86.224.44] (helo=elwamui-ovcar.atl.sa.earthlink.net) by elasmtp-kukur.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1RDdj3-0004a1-In for ipfix@ietf.org; Tue, 11 Oct 2011 10:54:37 -0400
Received: from 209.182.184.2 by webmail.earthlink.net with HTTP; Tue, 11 Oct 2011 07:26:00 -0400
Message-ID: <29997431.1318332361054.JavaMail.root@elwamui-ovcar.atl.sa.earthlink.net>
Date: Tue, 11 Oct 2011 07:26:00 -0400 (GMT-04:00)
From: Danny Llewallyn 
To: "ipfix@ietf.org" 
Mime-Version: 1.0
Content-Transfer-Encoding: 7bit
X-Mailer: EarthLink Zoo Mail 1.0
Content-Type: text/html; charset=UTF-8
X-ELNK-Trace: 2f7f79dc08201ef99649176a89d694c0f43c108795ac450705c8d573a3a4d2c3be25413ece38ee9c350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c
X-Originating-IP: 209.86.224.44
Subject: Re: [IPFIX] Fwd: New Version Notification for	draft-claise-ipfix-information-model-rfc5102bis-00.txt
X-BeenThere: ipfix@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
Reply-To: Danny Llewallyn 
List-Id: IPFIX WG discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 11 Oct 2011 14:54:39 -0000

Concerning these elements:

                    
3.1.17.  dateTimeMicroseconds

   The type "dateTimeMicroseconds" represents a time value in units of
   microseconds based on coordinated universal time (UTC).  The choice
   of an epoch, for example, 00:00 UTC, January 1, 1970, is left to
   corresponding encoding specifications for this type, for example, the
   IPFIX protocol specification.  Leap seconds are excluded.  Note that
   transformation of values might be required between different
   encodings if different epoch values are used.


3.1.18.  dateTimeNanoseconds

   The type "dateTimeNanoseconds" represents a time value in units of
   nanoseconds based on coordinated universal time (UTC).  The choice of
   an epoch, for example, 00:00 UTC, January 1, 1970, is left to
   corresponding encoding specifications for this type, for example, the
   IPFIX protocol specification.  Leap seconds are excluded.  Note that
   transformation of values might be required between different
   encodings if different epoch values are used.
 
I recently added support for these fields in the Lancope
              collector, and the format I assumed was NTP.  Now I read
              here that these can come down in epoch time.  Is there
              anything in the IPFIX protocol that denotes the format
              being used or the epoch time being used in these time
              values?  I see also that the same Note exists at the end of each defined time element.  Perhaps this could be solved with an options template.

              

              Thanks,

              

              Danny Llewallyn

              Lancope Inc.

              


-----Original Message-----

From: Benoit Claise 

Sent: Oct 10, 2011 7:52 AM

To: "ipfix@ietf.org" 

Subject: [IPFIX] Fwd: New Version Notification for	draft-claise-ipfix-information-model-rfc5102bis-00.txt




  

    
  
  
    Dear all,

    

    Here is new draft, for our new charter proposal:
http://tools.ietf.org/html/draft-claise-ipfix-information-model-rfc5102bis-00

    The diffs with RFC5102 are at
http://tools.ietf.org/rfcdiff?url2=draft-claise-ipfix-information-model-rfc5102bis-00.txt

    

    Your feedback is welcome.

    

    Regards, Benoit.

    -------- Original Message --------
    

      
        

          Subject: 
          New Version Notification for
            draft-claise-ipfix-information-model-rfc5102bis-00.txt
        

        

          Date: 
          Mon, 10 Oct 2011 03:00:52 -0700
        

        

          From: 
          internet-drafts@ietf.org
        

        

          To: 
          bclaise@cisco.com
        

        

          CC: 
          bclaise@cisco.com, stbryant@cisco.com, jemeyer@paypal.com,
            paitken@cisco.com, quittek@nw.neclab.eu
        

      
    

    

    

    
A new version of I-D, draft-claise-ipfix-information-model-rfc5102bis-00.txt has been successfully submitted by Benoit Claise and posted to the IETF repository.

Filename:	 draft-claise-ipfix-information-model-rfc5102bis
Revision:	 00
Title:		 Information Model for IP Flow Information eXport (IPFIX)
Creation date:	 2011-10-10
WG ID:		 Individual Submission
Number of pages: 172

Abstract:
This memo defines an information model for the IP Flow Information
eXport (IPFIX) protocol.  It is used by the IPFIX protocol for encoding
measured traffic information and information related to the traffic
Observation Point, the traffic Metering Process, and the Exporting
Process.  Although developed for the IPFIX protocol, the model is
defined in an open way that easily allows using it in other protocols,
interfaces, and applications.  This document obsoletes RFC 5102.

                                                                                  


The IETF Secretariat




  






From andrewf@plixer.com  Tue Oct 11 08:19:06 2011
Return-Path: 
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 8A19821F8DFB for ; Tue, 11 Oct 2011 08:19:06 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.598
X-Spam-Level: 
X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TsgCb+HoN1nH for ; Tue, 11 Oct 2011 08:19:05 -0700 (PDT)
Received: from smtp.plixer.com (smtp.plixer.com [66.186.184.193]) by ietfa.amsl.com (Postfix) with ESMTP id 493D121F8DF5 for ; Tue, 11 Oct 2011 08:19:05 -0700 (PDT)
Received: from [10.1.15.20] ([66.186.184.173]) by smtp.plixer.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675);  Tue, 11 Oct 2011 11:19:03 -0400
Message-ID: <4E945E67.6050108@plixer.com>
Date: Tue, 11 Oct 2011 11:19:03 -0400
From: Andrew Feren 
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:10.0a1) Gecko/20111009 Thunderbird/10.0a1
MIME-Version: 1.0
To: ipfix@ietf.org
References: <29997431.1318332361054.JavaMail.root@elwamui-ovcar.atl.sa.earthlink.net>
In-Reply-To: <29997431.1318332361054.JavaMail.root@elwamui-ovcar.atl.sa.earthlink.net>
Content-Type: multipart/alternative; boundary="------------090704010903020201030003"
X-OriginalArrivalTime: 11 Oct 2011 15:19:03.0757 (UTC) FILETIME=[1C598FD0:01CC8829]
Subject: Re: [IPFIX] Fwd: New Version Notification for	draft-claise-ipfix-information-model-rfc5102bis-00.txt
X-BeenThere: ipfix@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: IPFIX WG discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 11 Oct 2011 15:19:06 -0000

This is a multi-part message in MIME format.
--------------090704010903020201030003
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

Hi Danny,

RFC 5101 is pretty clear both dateTimeMicroseconds and 
dateTimeNanoseconds are encoded in NTP format.

6.1.9.  dateTimeMicroseconds

    The data type dateTimeMicroseconds represents a time value in units
    of microseconds normalized to the GMT timezone.  It MUST be encoded
    in a 64-bit integer, according to the NTP format given in [RFC1305].

6.1.10.  dateTimeNanoseconds

    The data type of dateTimeNanoseconds represents a time value in units
    of nanoseconds normalized to the GMT time zone.  It MUST be encoded
    in a 64-bit integer, according to the NTP format given in [RFC1305].

As I understand it the quotes you cite basically boil down to "it is up 
it to NTP/RFC1305 to define the epoch (start of time)" since that is the 
corresponding encoding specification.

-Andrew


On 10/11/2011 07:26 AM, Danny Llewallyn wrote:
> Concerning these elements:
>
>
>         3.1.17. dateTimeMicroseconds The type "dateTimeMicroseconds"
>         represents a time value in units of microseconds based on
>         coordinated universal time (UTC). The choice of an epoch, for
>         example, 00:00 UTC, January 1, 1970, is left to corresponding
>         encoding specifications for this type, for example, the IPFIX
>         protocol specification. Leap seconds are excluded. Note that
>         transformation of values might be required between different
>         encodings if different epoch values are used.
>
>
>         3.1.18. dateTimeNanoseconds The type "dateTimeNanoseconds"
>         represents a time value in units of nanoseconds based on
>         coordinated universal time (UTC). The choice of an epoch, for
>         example, 00:00 UTC, January 1, 1970, is left to corresponding
>         encoding specifications for this type, for example, the IPFIX
>         protocol specification. Leap seconds are excluded. Note that
>         transformation of values might be required between different
>         encodings if different epoch values are used.
>
>
> I recently added support for these fields in the Lancope collector, 
> and the format I assumed was NTP.  Now I read here that these can come 
> down in epoch time.  Is there anything in the IPFIX protocol that 
> denotes the format being used or the epoch time being used in these 
> time values?  I see also that the same Note exists at the end of each 
> defined time element.  Perhaps this could be solved with an options 
> template.
>
> Thanks,
>
> Danny Llewallyn
> Lancope Inc.
>
>
>
>     -----Original Message-----
>     From: Benoit Claise
>     Sent: Oct 10, 2011 7:52 AM
>     To: "ipfix@ietf.org"
>     Subject: [IPFIX] Fwd: New Version Notification for
>     draft-claise-ipfix-information-model-rfc5102bis-00.txt
>
>     Dear all,
>
>     Here is new draft, for our new charter proposal:
>     http://tools.ietf.org/html/draft-claise-ipfix-information-model-rfc5102bis-00
>     The diffs with RFC5102 are at
>     http://tools.ietf.org/rfcdiff?url2=draft-claise-ipfix-information-model-rfc5102bis-00.txt
>
>     Your feedback is welcome.
>
>     Regards, Benoit.
>     -------- Original Message --------
>     Subject: 	New Version Notification for
>     draft-claise-ipfix-information-model-rfc5102bis-00.txt
>     Date: 	Mon, 10 Oct 2011 03:00:52 -0700
>     From: 	internet-drafts@ietf.org
>     To: 	bclaise@cisco.com
>     CC: 	bclaise@cisco.com, stbryant@cisco.com, jemeyer@paypal.com,
>     paitken@cisco.com, quittek@nw.neclab.eu
>
>
>
>     A new version of I-D, draft-claise-ipfix-information-model-rfc5102bis-00.txt has been successfully submitted by Benoit Claise and posted to the IETF repository.
>
>     Filename:	 draft-claise-ipfix-information-model-rfc5102bis
>     Revision:	 00
>     Title:		 Information Model for IP Flow Information eXport (IPFIX)
>     Creation date:	 2011-10-10
>     WG ID:		 Individual Submission
>     Number of pages: 172
>
>     Abstract:
>     This memo defines an information model for the IP Flow Information
>     eXport (IPFIX) protocol.  It is used by the IPFIX protocol for encoding
>     measured traffic information and information related to the traffic
>     Observation Point, the traffic Metering Process, and the Exporting
>     Process.  Although developed for the IPFIX protocol, the model is
>     defined in an open way that easily allows using it in other protocols,
>     interfaces, and applications.  This document obsoletes RFC 5102.
>
>
>
>
>     The IETF Secretariat
>
>
>
>
>
> _______________________________________________
> IPFIX mailing list
> IPFIX@ietf.org
> https://www.ietf.org/mailman/listinfo/ipfix


--------------090704010903020201030003
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit


  
    
  
  
    Hi Danny,

    

    RFC 5101 is pretty clear both dateTimeMicroseconds and
    dateTimeNanoseconds are encoded in NTP format.

    

    6.1.9.  dateTimeMicroseconds

    

       The data type dateTimeMicroseconds represents a time value in
    units

       of microseconds normalized to the GMT timezone.  It MUST be
    encoded

       in a 64-bit integer, according to the NTP format given in
    [RFC1305].

    

    6.1.10.  dateTimeNanoseconds

    

       The data type of dateTimeNanoseconds represents a time value in
    units

       of nanoseconds normalized to the GMT time zone.  It MUST be
    encoded

       in a 64-bit integer, according to the NTP format given in
    [RFC1305].

    

    As I understand it the quotes you cite basically boil down to "it is
    up it to NTP/RFC1305 to define the epoch (start of time)" since that
    is the corresponding encoding specification.

    

    -Andrew

    

    

    On 10/11/2011 07:26 AM, Danny Llewallyn wrote:
    

      Concerning
            these elements:

            

          
      
3.1.17.  dateTimeMicroseconds

   The type "dateTimeMicroseconds" represents a time value in units of
   microseconds based on coordinated universal time (UTC).  The choice
   of an epoch, for example, 00:00 UTC, January 1, 1970, is left to
   corresponding encoding specifications for this type, for example, the
   IPFIX protocol specification.  Leap seconds are excluded.  Note that
   transformation of values might be required between different
   encodings if different epoch values are used.



      
3.1.18.  dateTimeNanoseconds

   The type "dateTimeNanoseconds" represents a time value in units of
   nanoseconds based on coordinated universal time (UTC).  The choice of
   an epoch, for example, 00:00 UTC, January 1, 1970, is left to
   corresponding encoding specifications for this type, for example, the
   IPFIX protocol specification.  Leap seconds are excluded.  Note that
   transformation of values might be required between different
   encodings if different epoch values are used.
 


      I recently added support for these fields in the Lancope
      collector, and the format I assumed was NTP.  Now I read here that
      these can come down in epoch time.  Is there anything in the IPFIX
      protocol that denotes the format being used or the epoch time
      being used in these time values?  I see also that the same Note
      exists at the end of each defined time element.  Perhaps this
      could be solved with an options template.

      

      Thanks,

      

      Danny Llewallyn

      Lancope Inc.

      

      

            

          
      
-----Original Message-----
        

        From: Benoit Claise 
          

          Sent: Oct 10, 2011 7:52 AM
          

          To: "ipfix@ietf.org" 
            

            Subject: [IPFIX] Fwd: New Version Notification for
            draft-claise-ipfix-information-model-rfc5102bis-00.txt
            

            

                 Dear all,

                

                Here is new draft, for our new charter proposal:
                http://tools.ietf.org/html/draft-claise-ipfix-information-model-rfc5102bis-00

                The diffs with RFC5102 are at
                http://tools.ietf.org/rfcdiff?url2=draft-claise-ipfix-information-model-rfc5102bis-00.txt

                

                Your feedback is welcome.

                

                Regards, Benoit.

                -------- Original Message --------
                

                  
                    

                      Subject: 
                      New Version Notification for
                        draft-claise-ipfix-information-model-rfc5102bis-00.txt
                    

                    

                      Date: 
                      Mon, 10 Oct 2011 03:00:52 -0700
                    

                    

                      From: 
                      internet-drafts@ietf.org
                    

                    

                      To: 
                      bclaise@cisco.com
                    

                    

                      CC: 
                      bclaise@cisco.com,
                        stbryant@cisco.com,
                        jemeyer@paypal.com,
                        paitken@cisco.com,
                        quittek@nw.neclab.eu
                    

                  
                

                

                

                
A new version of I-D, draft-claise-ipfix-information-model-rfc5102bis-00.txt has been successfully submitted by Benoit Claise and posted to the IETF repository.

Filename:	 draft-claise-ipfix-information-model-rfc5102bis
Revision:	 00
Title:		 Information Model for IP Flow Information eXport (IPFIX)
Creation date:	 2011-10-10
WG ID:		 Individual Submission
Number of pages: 172

Abstract:
This memo defines an information model for the IP Flow Information
eXport (IPFIX) protocol.  It is used by the IPFIX protocol for encoding
measured traffic information and information related to the traffic
Observation Point, the traffic Metering Process, and the Exporting
Process.  Although developed for the IPFIX protocol, the model is
defined in an open way that easily allows using it in other protocols,
interfaces, and applications.  This document obsoletes RFC 5102.

                                                                                  


The IETF Secretariat




              
            
          

      

      

      

      

      
_______________________________________________
IPFIX mailing list
IPFIX@ietf.org
https://www.ietf.org/mailman/listinfo/ipfix


    

    

  


--------------090704010903020201030003--

From trammell@tik.ee.ethz.ch  Tue Oct 11 08:48:42 2011
Return-Path: 
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 A6B2A21F8EB2 for ; Tue, 11 Oct 2011 08:48:42 -0700 (PDT)
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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id R37C6t-iSWyo for ; Tue, 11 Oct 2011 08:48:42 -0700 (PDT)
Received: from smtp.ee.ethz.ch (smtp.ee.ethz.ch [129.132.2.219]) by ietfa.amsl.com (Postfix) with ESMTP id 8F1EE21F8EAB for ; Tue, 11 Oct 2011 08:48:41 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by smtp.ee.ethz.ch (Postfix) with ESMTP id BDBA5D931B; Tue, 11 Oct 2011 17:48:40 +0200 (MEST)
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 UrhPPcSJtaPV; Tue, 11 Oct 2011 17:48:40 +0200 (MEST)
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 7F719D9319; Tue, 11 Oct 2011 17:48:40 +0200 (MEST)
Mime-Version: 1.0 (Apple Message framework v1084)
Content-Type: text/plain; charset=iso-8859-1
From: Brian Trammell 
In-Reply-To: <4E945E67.6050108@plixer.com>
Date: Tue, 11 Oct 2011 17:48:40 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: <69301285-A978-4815-9A53-975C1E19F6F1@tik.ee.ethz.ch>
References: <29997431.1318332361054.JavaMail.root@elwamui-ovcar.atl.sa.earthlink.net> <4E945E67.6050108@plixer.com>
To: Andrew Feren 
X-Mailer: Apple Mail (2.1084)
Cc: ipfix@ietf.org
Subject: Re: [IPFIX] Fwd: New Version Notification for	draft-claise-ipfix-information-model-rfc5102bis-00.txt
X-BeenThere: ipfix@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: IPFIX WG discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 11 Oct 2011 15:48:42 -0000

Hi, all,

As I read these, they are internally-self consistent, though they =
certainly don't look that way until you remove the irrelevant verbiage.

5102 leaves the encoding of =B5s and ns up to 5101; everything else in =
5102 on these types is essentially window dressing and should be =
ignored.

5101 chooses RFC 1305 style NTP encoding for _both_ of these. =
Specification of GMT is irrelevant here. The missing epoch is =
misleading. 1305 specifies an epoch of 1 Jan 1900 00:00 UTC, and 2^32 =
seconds in the era that ends in February 2036.

So, why have two data types for identical encodings of timestamps? 1305 =
allows 2^-32 s of precision (~232ps), sufficient for both =B5s and ns. =
The assumption made by the authors of RFC 5153 behind this reasoning was =
that the data type signaled the underlying precision of the measurement; =
i.e., the bottom two bits or so should be ignored for ns, and the bottom =
twelve bits or so should be ignored for ns. This is specified in RFC =
5153 section 4.5 paragraph 3.

5101 is canonical but not particularly forthcoming, while 5102 is =
unclear to the point of being misleading on this point.

I believe the correct action in the -bis documents is to correct these =
errors, preferably by specifying the reference to 1305 and the epoch =
explicitly in both.

Updating to NTPv4 with support for eras will give these timestamps a =
life beyond the next 21 years, but that requires a change to the =
definition of the IEs via the iedoctors process, I think.

Regards,

Brian

On Oct 11, 2011, at 5:19 PM, Andrew Feren wrote:

> Hi Danny,
>=20
> RFC 5101 is pretty clear both dateTimeMicroseconds and =
dateTimeNanoseconds are encoded in NTP format.
>=20
> 6.1.9.  dateTimeMicroseconds
>=20
>    The data type dateTimeMicroseconds represents a time value in units
>    of microseconds normalized to the GMT timezone.  It MUST be encoded
>    in a 64-bit integer, according to the NTP format given in =
[RFC1305].
>=20
> 6.1.10.  dateTimeNanoseconds
>=20
>    The data type of dateTimeNanoseconds represents a time value in =
units
>    of nanoseconds normalized to the GMT time zone.  It MUST be encoded
>    in a 64-bit integer, according to the NTP format given in =
[RFC1305].
>=20
> As I understand it the quotes you cite basically boil down to "it is =
up it to NTP/RFC1305 to define the epoch (start of time)" since that is =
the corresponding encoding specification.
>=20
> -Andrew
>=20
>=20
> On 10/11/2011 07:26 AM, Danny Llewallyn wrote:
>> Concerning these elements:
>>=20
>>  3.1.17
>> .  dateTimeMicroseconds
>>=20
>>    The type "dateTimeMicroseconds" represents a time value in units =
of
>>    microseconds based on coordinated universal time (UTC).  The =
choice
>>    of an epoch, for example, 00:00 UTC, January 1, 1970, is left to
>>    corresponding encoding specifications for this type, for example, =
the
>>    IPFIX protocol specification.  Leap seconds are excluded.  Note =
that
>>    transformation of values might be required between different
>>    encodings if different epoch values are used.
>>=20
>>=20
>>=20
>> 3.1.18
>> .  dateTimeNanoseconds
>>=20
>>    The type "dateTimeNanoseconds" represents a time value in units of
>>    nanoseconds based on coordinated universal time (UTC).  The choice =
of
>>    an epoch, for example, 00:00 UTC, January 1, 1970, is left to
>>    corresponding encoding specifications for this type, for example, =
the
>>    IPFIX protocol specification.  Leap seconds are excluded.  Note =
that
>>    transformation of values might be required between different
>>    encodings if different epoch values are used.
>>=20
>>=20
>> =20
>>=20
>>=20
>> I recently added support for these fields in the Lancope collector, =
and the format I assumed was NTP.  Now I read here that these can come =
down in epoch time.  Is there anything in the IPFIX protocol that =
denotes the format being used or the epoch time being used in these time =
values?  I see also that the same Note exists at the end of each defined =
time element.  Perhaps this could be solved with an options template.
>>=20
>> Thanks,
>>=20
>> Danny Llewallyn
>> Lancope Inc.
>>=20
>>=20
>>=20
>> -----Original Message-----=20
>> From: Benoit Claise=20
>> Sent: Oct 10, 2011 7:52 AM=20
>> To: "ipfix@ietf.org"=20
>> Subject: [IPFIX] Fwd: New Version Notification for =
draft-claise-ipfix-information-model-rfc5102bis-00.txt=20
>>=20
>> Dear all,
>>=20
>> Here is new draft, for our new charter proposal: =
http://tools.ietf.org/html/draft-claise-ipfix-information-model-rfc5102bis=
-00
>> The diffs with RFC5102 are at =
http://tools.ietf.org/rfcdiff?url2=3Ddraft-claise-ipfix-information-model-=
rfc5102bis-00.txt
>>=20
>> Your feedback is welcome.
>>=20
>> Regards, Benoit.
>> -------- Original Message --------
>> Subject:	New Version Notification for =
draft-claise-ipfix-information-model-rfc5102bis-00.txt
>> Date:	Mon, 10 Oct 2011 03:00:52 -0700
>> From:	internet-drafts@ietf.org
>> To:	bclaise@cisco.com
>> CC:	bclaise@cisco.com, stbryant@cisco.com, jemeyer@paypal.com, =
paitken@cisco.com, quittek@nw.neclab.eu
>>=20
>> A new version of I-D, =
draft-claise-ipfix-information-model-rfc5102bis-00.txt has been =
successfully submitted by Benoit Claise and posted to the IETF =
repository.
>>=20
>> Filename:	 draft-claise-ipfix-information-model-rfc5102bis
>> Revision:	 00
>> Title:		 Information Model for IP Flow Information =
eXport (IPFIX)
>> Creation date:	 2011-10-10
>> WG ID:		 Individual Submission
>> Number of pages: 172
>>=20
>> Abstract:
>> This memo defines an information model for the IP Flow Information
>> eXport (IPFIX) protocol.  It is used by the IPFIX protocol for =
encoding
>> measured traffic information and information related to the traffic
>> Observation Point, the traffic Metering Process, and the Exporting
>> Process.  Although developed for the IPFIX protocol, the model is
>> defined in an open way that easily allows using it in other =
protocols,
>> interfaces, and applications.  This document obsoletes RFC 5102.
>>=20
>>                                                                       =
           =20
>>=20
>>=20
>> The IETF Secretariat
>>=20
>>=20
>>=20
>>=20
>>=20
>> _______________________________________________
>> IPFIX mailing list
>>=20
>> IPFIX@ietf.org
>> https://www.ietf.org/mailman/listinfo/ipfix
>=20
> _______________________________________________
> IPFIX mailing list
> IPFIX@ietf.org
> https://www.ietf.org/mailman/listinfo/ipfix


From joshb@google.com  Tue Oct 11 17:49:25 2011
Return-Path: 
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 5F66521F8C80 for ; Tue, 11 Oct 2011 17:49:25 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -106.599
X-Spam-Level: 
X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, 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 X7Mfl91T6IkK for ; Tue, 11 Oct 2011 17:49:25 -0700 (PDT)
Received: from smtp-out.google.com (smtp-out.google.com [216.239.44.51]) by ietfa.amsl.com (Postfix) with ESMTP id D3E2821F8C48 for ; Tue, 11 Oct 2011 17:49:24 -0700 (PDT)
Received: from wpaz33.hot.corp.google.com (wpaz33.hot.corp.google.com [172.24.198.97]) by smtp-out.google.com with ESMTP id p9C0nKU5017497 for ; Tue, 11 Oct 2011 17:49:20 -0700
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1318380560; bh=hxid53IlqggUdtpGeHh894ioUuc=; h=Date:From:To:Subject:Message-ID:MIME-Version:Content-Type; b=B5OrB41xEBuN6x43rVehByaNi9mDbp0d58R+kJlrFR/kjfFwN3cR4JDOqlgQPuMGJ qu1EoZMJPdvXV4reEswVQ==
DomainKey-Signature: a=rsa-sha1; s=beta; d=google.com; c=nofws; q=dns; h=date:from:x-x-sender:to:subject:message-id:user-agent: mime-version:content-type:x-system-of-record; b=O5fED8igVDlY9RzNIqBjzTshEd3n5iYGrni7H0w2+1nfmZ0w0q25wy7D435txfj/6 3tmKjceIg5BFRGTm8T5rQ==
Received: from vandervecken.mtv.corp.google.com (vandervecken.mtv.corp.google.com [172.18.88.211]) by wpaz33.hot.corp.google.com with ESMTP id p9C0nDJV022983 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Tue, 11 Oct 2011 17:49:19 -0700
Date: Tue, 11 Oct 2011 17:49:13 -0700 (PDT)
From: Josh Bailey 
X-X-Sender: joshb@vandervecken.mtv.corp.google.com
To: ipfix@ietf.org
Message-ID: 
User-Agent: Alpine 2.00 (DEB 1167 2008-08-23)
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII
X-System-Of-Record: true
Subject: [IPFIX] timestamps, exporters, and other animals
X-BeenThere: ipfix@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: IPFIX WG discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 12 Oct 2011 01:02:11 -0000

Hi all;

So I wanted to start a discussion around timestamps when exporting flows 
or OID values (qv. http://www.ietf.org/proceedings/81/slides/ipfix-6.pdf).

I think it'd be good thing to specify an association between a timestamp, 
and an exported OID, flow, etc. When exporting an OID, for example, I 
would like a way to know within some limit of certainty when that OID 
value was actually sampled.

A problem I find with SNMP is that the client can only use its own 
timestamp of the server's reply to guess when the requested variable was 
sampled. If there is uncertainty in the server implementation that adds 
some delay between sampling and sending the response (without even 
addressing variable network delay), there's no way to know when the object
was sampled with any certainty.

I have also seen this problem in various sFlow implementations. There, 
often the timestamp is added by the control plane an unknown amount of 
time after the sample was taken.

Has there been any prior work or discussion around this issue? I had a few 
of my own thoughts about how to approach it, but I thought it would be 
useful to start here.

PS. For background - I am looking at NMS/protocol implementation for 
OpenFlow devices, which might have very many distributed individual 
devices with very many ports and variables per port. Therefore I'd very 
much like to implement an efficient NMS "counter" protocol.

Thanks,

--
Josh Bailey

From j.schoenwaelder@jacobs-university.de  Tue Oct 11 22:56:56 2011
Return-Path: 
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 3017621F8B3B for ; Tue, 11 Oct 2011 22:56:56 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -103.03
X-Spam-Level: 
X-Spam-Status: No, score=-103.03 tagged_above=-999 required=5 tests=[AWL=0.219, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-1, 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 bKDyjapIRj0f for ; Tue, 11 Oct 2011 22:56:55 -0700 (PDT)
Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by ietfa.amsl.com (Postfix) with ESMTP id 9108421F8B37 for ; Tue, 11 Oct 2011 22:56:55 -0700 (PDT)
Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id 9FF6420DBB; Wed, 12 Oct 2011 07:56:54 +0200 (CEST)
X-Virus-Scanned: amavisd-new at jacobs-university.de
Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius4.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id U4HPUOqGLiNq; Wed, 12 Oct 2011 07:56:53 +0200 (CEST)
Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 498E820DBA; Wed, 12 Oct 2011 07:56:53 +0200 (CEST)
Received: by elstar.local (Postfix, from userid 501) id 672F41B1D4BE; Wed, 12 Oct 2011 07:56:39 +0200 (CEST)
Date: Wed, 12 Oct 2011 07:56:39 +0200
From: Juergen Schoenwaelder 
To: Josh Bailey 
Message-ID: <20111012055639.GA13515@elstar.local>
Mail-Followup-To: Josh Bailey , ipfix@ietf.org
References: 
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: 
User-Agent: Mutt/1.5.21 (2010-09-15)
Cc: ipfix@ietf.org
Subject: Re: [IPFIX] timestamps, exporters, and other animals
X-BeenThere: ipfix@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
Reply-To: Juergen Schoenwaelder 
List-Id: IPFIX WG discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 12 Oct 2011 05:56:56 -0000

On Tue, Oct 11, 2011 at 05:49:13PM -0700, Josh Bailey wrote:
 
> I think it'd be good thing to specify an association between a
> timestamp, and an exported OID, flow, etc. When exporting an OID,
> for example, I would like a way to know within some limit of
> certainty when that OID value was actually sampled.
> 
> A problem I find with SNMP is that the client can only use its own
> timestamp of the server's reply to guess when the requested variable
> was sampled. If there is uncertainty in the server implementation
> that adds some delay between sampling and sending the response
> (without even addressing variable network delay), there's no way to
> know when the object was sampled with any certainty.

In SNMP land, you typically fetch sysUpTime together with the counters
(also to detect discontinuities). This means you get a timestamp that
is attached to the counter by the 'server' and this timestamp can take
care of the network delay part. That said, implementations sometimes
for efficiency reasons do not read out hardware registers on every
request if you poll very fast - so there might be some notable delay
in how counter changes are reported (but then typical SNMP poll cycles
are counted in minutes).

/js

-- 
Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: +49 421 200 3587         Campus Ring 1, 28759 Bremen, Germany
Fax:   +49 421 200 3103         

From joshb@google.com  Tue Oct 11 23:54:34 2011
Return-Path: 
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 B2EC821F8C61 for ; Tue, 11 Oct 2011 23:54:34 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -106.433
X-Spam-Level: 
X-Spam-Status: No, score=-106.433 tagged_above=-999 required=5 tests=[AWL=0.166, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, 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 KZbLQOejtMVn for ; Tue, 11 Oct 2011 23:54:34 -0700 (PDT)
Received: from smtp-out.google.com (smtp-out.google.com [216.239.44.51]) by ietfa.amsl.com (Postfix) with ESMTP id 2288321F8C48 for ; Tue, 11 Oct 2011 23:54:34 -0700 (PDT)
Received: from hpaq3.eem.corp.google.com (hpaq3.eem.corp.google.com [172.25.149.3]) by smtp-out.google.com with ESMTP id p9C6sR1T023027; Tue, 11 Oct 2011 23:54:28 -0700
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1318402468; bh=hcn7UuagV3WGpktZPxrXe4UXDJo=; h=Date:From:To:cc:Subject:In-Reply-To:Message-ID:References: MIME-Version:Content-Type; b=aG4T4RYYvW79PXm2DUe9FaB9KrwTk9fhUpBcsmTNNxflZORNLpqpJ5zrKvHFp3wlN aIEJztz3y4uueH5zcpu7w==
DomainKey-Signature: a=rsa-sha1; s=beta; d=google.com; c=nofws; q=dns; h=date:from:x-x-sender:to:cc:subject:in-reply-to:message-id: references:user-agent:mime-version:content-type:x-system-of-record; b=mjC7LLlwOTBMHCS504ETfSk6tKKTCMwZHFuo3G9Ua4smQptwBZP1PRZwSxJflpKIv VtEW7nCByVBmY6Aa3G00w==
Received: from vandervecken.mtv.corp.google.com (vandervecken.mtv.corp.google.com [172.18.88.211]) by hpaq3.eem.corp.google.com with ESMTP id p9C6sK5C021464 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 11 Oct 2011 23:54:21 -0700
Date: Tue, 11 Oct 2011 23:54:19 -0700 (PDT)
From: Josh Bailey 
X-X-Sender: joshb@vandervecken.mtv.corp.google.com
To: j.schoenwaelder@jacobs-university.de
In-Reply-To: 
Message-ID: 
References: 
User-Agent: Alpine 2.00 (DEB 1167 2008-08-23)
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII
X-System-Of-Record: true
Cc: ipfix@ietf.org
Subject: Re: [IPFIX] timestamps, exporters, and other animals (fwd)
X-BeenThere: ipfix@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: IPFIX WG discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 12 Oct 2011 06:54:34 -0000

Hi Juergen;

I assert that polling the sysUpTime does not take care of the core 
problem, because you cannot know when sysUpTime itself was sampled (eg. 
you received it after 1.5s because of network delay and because the packet 
was queued in the control plane kernel because the control plane CPU was 
busy).

I don't mind so much that the reply was delayed (though I like fast 
replies!), but I do mind that there can be a very large uncertainty.

There is also the overhead of requesting sysUpTime itself, not to mention 
when walking a table, you may time slew over the course of walking the 
table.

I understand definitely re caching hardware counters, etc, and I think 
that's fine (and necessary in a system with multiple NMSes), and I don't 
mind that the counters are cached, but I do want to know when they were 
cached for me to recover maximum temporal information.

> On Tue, Oct 11, 2011 at 05:49:13PM -0700, Josh Bailey wrote:
>
>> I think it'd be good thing to specify an association between a
>> timestamp, and an exported OID, flow, etc. When exporting an OID,
>> for example, I would like a way to know within some limit of
>> certainty when that OID value was actually sampled.
>>
>> A problem I find with SNMP is that the client can only use its own
>> timestamp of the server's reply to guess when the requested variable
>> was sampled. If there is uncertainty in the server implementation
>> that adds some delay between sampling and sending the response
>> (without even addressing variable network delay), there's no way to
>> know when the object was sampled with any certainty.
>
> In SNMP land, you typically fetch sysUpTime together with the counters
> (also to detect discontinuities). This means you get a timestamp that
> is attached to the counter by the 'server' and this timestamp can take
> care of the network delay part. That said, implementations sometimes
> for efficiency reasons do not read out hardware registers on every
> request if you poll very fast - so there might be some notable delay
> in how counter changes are reported (but then typical SNMP poll cycles
> are counted in minutes).

--
Josh Bailey

From j.schoenwaelder@jacobs-university.de  Wed Oct 12 00:33:55 2011
Return-Path: 
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 74B5821F8C0E for ; Wed, 12 Oct 2011 00:33:55 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -103.047
X-Spam-Level: 
X-Spam-Status: No, score=-103.047 tagged_above=-999 required=5 tests=[AWL=0.202, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-1, 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 cXNYFEUCUyK9 for ; Wed, 12 Oct 2011 00:33:54 -0700 (PDT)
Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by ietfa.amsl.com (Postfix) with ESMTP id 8178021F8B68 for ; Wed, 12 Oct 2011 00:33:54 -0700 (PDT)
Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id E3F2720DA9; Wed, 12 Oct 2011 09:33:53 +0200 (CEST)
X-Virus-Scanned: amavisd-new at jacobs-university.de
Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius3.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id 7joOWTXTOqyv; Wed, 12 Oct 2011 09:33:52 +0200 (CEST)
Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 5F88220DA6; Wed, 12 Oct 2011 09:33:52 +0200 (CEST)
Received: by elstar.local (Postfix, from userid 501) id 9C7941B1D883; Wed, 12 Oct 2011 09:33:38 +0200 (CEST)
Date: Wed, 12 Oct 2011 09:33:38 +0200
From: Juergen Schoenwaelder 
To: Josh Bailey 
Message-ID: <20111012073338.GA13898@elstar.local>
Mail-Followup-To: Josh Bailey , ipfix@ietf.org
References:  
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: 
User-Agent: Mutt/1.5.21 (2010-09-15)
Cc: ipfix@ietf.org
Subject: Re: [IPFIX] timestamps, exporters, and other animals (fwd)
X-BeenThere: ipfix@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
Reply-To: Juergen Schoenwaelder 
List-Id: IPFIX WG discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 12 Oct 2011 07:33:55 -0000

On Tue, Oct 11, 2011 at 11:54:19PM -0700, Josh Bailey wrote:
> 
> Hi Juergen;
> 
> I assert that polling the sysUpTime does not take care of the core
> problem, because you cannot know when sysUpTime itself was sampled
> (eg. you received it after 1.5s because of network delay and because
> the packet was queued in the control plane kernel because the
> control plane CPU was busy).

The SNMP agents controls sysUpTime - so sysUpTime is pretty much the
time the packet left the agent. If you talk about delays in the
instrumentation, that is the delay to read the register, then you are
correct. But once again, SNMP polling cycles are usually counted in
minutes.
 
> I don't mind so much that the reply was delayed (though I like fast
> replies!), but I do mind that there can be a very large uncertainty.

Very large is relative to the precision you want. SNMP was not
designed with subsecond precision in mind.

> There is also the overhead of requesting sysUpTime itself, not to
> mention when walking a table, you may time slew over the course of
> walking the table.

For any counter, you need discontinuity detection. The way you walk a
table has indeed a big impact in terms of data consistency - the
recommendation here is to use getbulk and to walk the columns of
interest concurrently.

> I understand definitely re caching hardware counters, etc, and I
> think that's fine (and necessary in a system with multiple NMSes),
> and I don't mind that the counters are cached, but I do want to know
> when they were cached for me to recover maximum temporal
> information.

SNMP agents typically do not help you with that - caching is rather
something implementation specific. And yes, operators have complained
about SNMP counters on some boxes being less "precise" than what the
CLI shows. I am no way saying SNMP is a model to choose - I just
wanted to help making it clear what SNMP does and what not.

If you want high accuracy, then every counter reading must be
timestamped exactly when the counter is read. This of course has a
price.

/js

-- 
Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: +49 421 200 3587         Campus Ring 1, 28759 Bremen, Germany
Fax:   +49 421 200 3103         

From joshb@google.com  Wed Oct 12 00:47:32 2011
Return-Path: 
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 90E5A21F8C69 for ; Wed, 12 Oct 2011 00:47:32 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -106.599
X-Spam-Level: 
X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, 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 gCV9ftDPxXEa for ; Wed, 12 Oct 2011 00:47:31 -0700 (PDT)
Received: from smtp-out.google.com (smtp-out.google.com [74.125.121.67]) by ietfa.amsl.com (Postfix) with ESMTP id 91A0621F8C65 for ; Wed, 12 Oct 2011 00:47:31 -0700 (PDT)
Received: from hpaq14.eem.corp.google.com (hpaq14.eem.corp.google.com [172.25.149.14]) by smtp-out.google.com with ESMTP id p9C7lUKK026396; Wed, 12 Oct 2011 00:47:30 -0700
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1318405650; bh=eHcDUIcvIdnrnLdXYCReA+KaM7Q=; h=Date:From:To:cc:Subject:In-Reply-To:Message-ID:References: MIME-Version:Content-Type; b=HEuilzCDIOh1s1ouLWtCKvjEuNUWpgPqUR7GvAUsygWUAyx4NwfAFG7qKeKjO8r5/ vZE+deQIo+D5/8tVD67lg==
DomainKey-Signature: a=rsa-sha1; s=beta; d=google.com; c=nofws; q=dns; h=date:from:x-x-sender:to:cc:subject:in-reply-to:message-id: references:user-agent:mime-version:content-type:x-system-of-record; b=m3MX20xrHIUCEwUAFTar+VHZu3qBY+HDRL/SpeNap9gEaO4WxDtcnJ7FNr+huCZcO wsn6B0XfGP6mwt4KOiu9w==
Received: from vandervecken.mtv.corp.google.com (vandervecken.mtv.corp.google.com [172.18.88.211]) by hpaq14.eem.corp.google.com with ESMTP id p9C7lRd6024241 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 12 Oct 2011 00:47:29 -0700
Date: Wed, 12 Oct 2011 00:47:27 -0700 (PDT)
From: Josh Bailey 
X-X-Sender: joshb@vandervecken.mtv.corp.google.com
To: j.schoenwaelder@jacobs-university.de
In-Reply-To: 
Message-ID: 
References: 
User-Agent: Alpine 2.00 (DEB 1167 2008-08-23)
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed
X-System-Of-Record: true
Cc: ipfix@ietf.org
Subject: Re: [IPFIX] timestamps, exporters, and other animals (fwd)
X-BeenThere: ipfix@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: IPFIX WG discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 12 Oct 2011 07:47:32 -0000

Hi Juergen;

I agree with your statement about SNMP not being designed for subsecond 
precision. And I definitely agree that there are things you can do to 
minimise potential delays and that often those delays are implementation 
specific.

I don't agree though that sysUpTime is when the packet left the agent; 
especially if the agent is running slowly for whatever reason, or if the 
sysUpTime reply happens to be part of a packet containing replies for 
other variables (perhaps from different CPUs in a typical distributed CPU 
router).

I also don't agree that cycles are usually measured in minutes. In my 
experience cycles are very much shorter on average.

As you say having a timestamp per counter while costly is ideal in some 
sense. However I am looking to explore different tradeoffs; for example, a 
timestamp followed by a list of OIDs all current at that same timestamp.

I am aware of counter implementations that could do such a "snapshot" 
operation for example.

Thanks,

>>
>> Hi Juergen;
>>
>> I assert that polling the sysUpTime does not take care of the core
>> problem, because you cannot know when sysUpTime itself was sampled
>> (eg. you received it after 1.5s because of network delay and because
>> the packet was queued in the control plane kernel because the
>> control plane CPU was busy).
>
> The SNMP agents controls sysUpTime - so sysUpTime is pretty much the
> time the packet left the agent. If you talk about delays in the
> instrumentation, that is the delay to read the register, then you are
> correct. But once again, SNMP polling cycles are usually counted in
> minutes.
>
>> I don't mind so much that the reply was delayed (though I like fast
>> replies!), but I do mind that there can be a very large uncertainty.
>
> Very large is relative to the precision you want. SNMP was not
> designed with subsecond precision in mind.
>
>> There is also the overhead of requesting sysUpTime itself, not to
>> mention when walking a table, you may time slew over the course of
>> walking the table.
>
> For any counter, you need discontinuity detection. The way you walk a
> table has indeed a big impact in terms of data consistency - the
> recommendation here is to use getbulk and to walk the columns of
> interest concurrently.
>
>> I understand definitely re caching hardware counters, etc, and I
>> think that's fine (and necessary in a system with multiple NMSes),
>> and I don't mind that the counters are cached, but I do want to know
>> when they were cached for me to recover maximum temporal
>> information.
>
> SNMP agents typically do not help you with that - caching is rather
> something implementation specific. And yes, operators have complained
> about SNMP counters on some boxes being less "precise" than what the
> CLI shows. I am no way saying SNMP is a model to choose - I just
> wanted to help making it clear what SNMP does and what not.
>
> If you want high accuracy, then every counter reading must be
> timestamped exactly when the counter is read. This of course has a
> price.
>
> /js
>
> -- 
> Juergen Schoenwaelder           Jacobs University Bremen gGmbH
> Phone: +49 421 200 3587         Campus Ring 1, 28759 Bremen, Germany
> Fax:   +49 421 200 3103         
>
>
>

--
Josh Bailey

From trammell@tik.ee.ethz.ch  Wed Oct 12 01:23:46 2011
Return-Path: 
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 DB21421F8C20 for ; Wed, 12 Oct 2011 01:23:46 -0700 (PDT)
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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6Yui5kouCjDu for ; Wed, 12 Oct 2011 01:23:45 -0700 (PDT)
Received: from smtp.ee.ethz.ch (smtp.ee.ethz.ch [129.132.2.219]) by ietfa.amsl.com (Postfix) with ESMTP id 9491621F8C14 for ; Wed, 12 Oct 2011 01:23:45 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by smtp.ee.ethz.ch (Postfix) with ESMTP id 55480D9319; Wed, 12 Oct 2011 10:13:33 +0200 (MEST)
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 T54Kcx+hWlUO; Wed, 12 Oct 2011 10:13:33 +0200 (MEST)
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 05D30D9317; Wed, 12 Oct 2011 10:13:33 +0200 (MEST)
Mime-Version: 1.0 (Apple Message framework v1084)
Content-Type: text/plain; charset=us-ascii
From: Brian Trammell 
In-Reply-To: 
Date: Wed, 12 Oct 2011 10:13:32 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: 
References:  
To: Josh Bailey 
X-Mailer: Apple Mail (2.1084)
Cc: ipfix@ietf.org
Subject: Re: [IPFIX] timestamps, exporters, and other animals (fwd)
X-BeenThere: ipfix@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: IPFIX WG discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 12 Oct 2011 08:23:47 -0000

Hi, Josh, all,

As I read it, one of the wins of MIB Variable Export is that you get the =
whole timestamp machinery of IPFIX for free, including absolute =
timestamps wherein individual records can have observation timestamps =
down to nanosecond precision completely independent of the export =
timestamps. Relative timestamps can be expressed either as negative =
offsets to the export time (which can be a little tricky to implement, =
mind) or as positive offsets to the system initialization time (itself =
exported via options)

Now, as you'll see elsewhere on the list, the flexible timestamps need a =
little work -- the microsecond and nanosecond types in particular are =
confusingly defined in a way that has led to (not-yet-verified) =
interoperability failures; the discussion about fixing this in =
5101bis/5102bis is elsewhere on the ipfix list.

Simply because an exporter has the _tools_ to export accurate =
timestamps, of course, does not mean that it can (e.g. due to =
implementation constraints) or will (e.g. due to faults or simple =
laziness). And system initialization based relative timestamps can have =
their own subtle pitfalls as in NetFlow V9 (on which see our paper in =
PAM this year, "Peeling Away Timing Error in NetFlow Data", author copy =
at =
ftp://ftp.tik.ee.ethz.ch/pub/people/martibur/Netflow-Timing-PAM2011.pdf =
-- the cyclic error from lost export time precision are V9-specific, but =
particularly the drift and delay components of the error there are =
universally applicable to any such arrangement, I think)

But the protocol here should give you the room to do what you need with =
respect to timing at the implementation level... WRT impacts on =
documents, would it be helpful to have a more thorough handling of IPFIX =
timestamping in the MIB Export draft (i.e., as an introduction for SNMP =
people)?

Cheers,

Brian

On Oct 12, 2011, at 9:47 AM, Josh Bailey wrote:

>=20
> Hi Juergen;
>=20
> I agree with your statement about SNMP not being designed for =
subsecond precision. And I definitely agree that there are things you =
can do to minimise potential delays and that often those delays are =
implementation specific.
>=20
> I don't agree though that sysUpTime is when the packet left the agent; =
especially if the agent is running slowly for whatever reason, or if the =
sysUpTime reply happens to be part of a packet containing replies for =
other variables (perhaps from different CPUs in a typical distributed =
CPU router).
>=20
> I also don't agree that cycles are usually measured in minutes. In my =
experience cycles are very much shorter on average.
>=20
> As you say having a timestamp per counter while costly is ideal in =
some sense. However I am looking to explore different tradeoffs; for =
example, a timestamp followed by a list of OIDs all current at that same =
timestamp.
>=20
> I am aware of counter implementations that could do such a "snapshot" =
operation for example.
>=20
> Thanks,
>=20
>>>=20
>>> Hi Juergen;
>>>=20
>>> I assert that polling the sysUpTime does not take care of the core
>>> problem, because you cannot know when sysUpTime itself was sampled
>>> (eg. you received it after 1.5s because of network delay and because
>>> the packet was queued in the control plane kernel because the
>>> control plane CPU was busy).
>>=20
>> The SNMP agents controls sysUpTime - so sysUpTime is pretty much the
>> time the packet left the agent. If you talk about delays in the
>> instrumentation, that is the delay to read the register, then you are
>> correct. But once again, SNMP polling cycles are usually counted in
>> minutes.
>>=20
>>> I don't mind so much that the reply was delayed (though I like fast
>>> replies!), but I do mind that there can be a very large uncertainty.
>>=20
>> Very large is relative to the precision you want. SNMP was not
>> designed with subsecond precision in mind.
>>=20
>>> There is also the overhead of requesting sysUpTime itself, not to
>>> mention when walking a table, you may time slew over the course of
>>> walking the table.
>>=20
>> For any counter, you need discontinuity detection. The way you walk a
>> table has indeed a big impact in terms of data consistency - the
>> recommendation here is to use getbulk and to walk the columns of
>> interest concurrently.
>>=20
>>> I understand definitely re caching hardware counters, etc, and I
>>> think that's fine (and necessary in a system with multiple NMSes),
>>> and I don't mind that the counters are cached, but I do want to know
>>> when they were cached for me to recover maximum temporal
>>> information.
>>=20
>> SNMP agents typically do not help you with that - caching is rather
>> something implementation specific. And yes, operators have complained
>> about SNMP counters on some boxes being less "precise" than what the
>> CLI shows. I am no way saying SNMP is a model to choose - I just
>> wanted to help making it clear what SNMP does and what not.
>>=20
>> If you want high accuracy, then every counter reading must be
>> timestamped exactly when the counter is read. This of course has a
>> price.
>>=20
>> /js
>>=20
>> --=20
>> Juergen Schoenwaelder           Jacobs University Bremen gGmbH
>> Phone: +49 421 200 3587         Campus Ring 1, 28759 Bremen, Germany
>> Fax:   +49 421 200 3103         
>>=20
>>=20
>>=20
>=20
> --
> Josh Bailey
> _______________________________________________
> IPFIX mailing list
> IPFIX@ietf.org
> https://www.ietf.org/mailman/listinfo/ipfix


From joshb@google.com  Wed Oct 12 01:57:55 2011
Return-Path: 
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 34EC521F8B2B for ; Wed, 12 Oct 2011 01:57:55 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -106.599
X-Spam-Level: 
X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, 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 nKEZ3VBTFZQX for ; Wed, 12 Oct 2011 01:57:54 -0700 (PDT)
Received: from smtp-out.google.com (smtp-out.google.com [74.125.121.67]) by ietfa.amsl.com (Postfix) with ESMTP id C8E7521F8B1E for ; Wed, 12 Oct 2011 01:57:53 -0700 (PDT)
Received: from hpaq12.eem.corp.google.com (hpaq12.eem.corp.google.com [172.25.149.12]) by smtp-out.google.com with ESMTP id p9C8PcmO032030; Wed, 12 Oct 2011 01:25:38 -0700
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1318407938; bh=BKpNpco6Z4un54fdWpuYu07N7C4=; h=Date:From:To:cc:Subject:In-Reply-To:Message-ID:References: MIME-Version:Content-Type; b=QGZAHn890zmb2ug+KMvAm3OojdBvpPVUHXDEnHGxB9XDJCg7bLKJGeuMorwGKqt7Q 9Oh1fOGuxXiN8F19FGZ2Q==
DomainKey-Signature: a=rsa-sha1; s=beta; d=google.com; c=nofws; q=dns; h=date:from:x-x-sender:to:cc:subject:in-reply-to:message-id: references:user-agent:mime-version:content-type:x-system-of-record; b=sEbnuqFKC0JOqx6L+1fIqgQb7/+fUntad0661N2wsZMvJ6eEnoVAFSm2RFl1sWShs vWRlvpbRsnSAPAJOYC6ig==
Received: from vandervecken.mtv.corp.google.com (vandervecken.mtv.corp.google.com [172.18.88.211]) by hpaq12.eem.corp.google.com with ESMTP id p9C8PZpK023422 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 12 Oct 2011 01:25:37 -0700
Date: Wed, 12 Oct 2011 01:25:35 -0700 (PDT)
From: Josh Bailey 
X-X-Sender: joshb@vandervecken.mtv.corp.google.com
To: trammell@tik.ee.ethz.ch
In-Reply-To: 
Message-ID: 
References: 
User-Agent: Alpine 2.00 (DEB 1167 2008-08-23)
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed
X-System-Of-Record: true
Cc: ipfix@ietf.org
Subject: Re: [IPFIX] timestamps, exporters, and other animals (fwd)
X-BeenThere: ipfix@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: IPFIX WG discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 12 Oct 2011 08:57:55 -0000

Hi Brian;

In summary - yes! I believe you perceive where I'm coming from most 
accurately. I would be very interested in specific handling of this issue 
in the next draft.

> Hi, Josh, all,
>
> As I read it, one of the wins of MIB Variable Export is that you get the whole timestamp machinery of IPFIX for free, including absolute timestamps wherein individual records can have observation timestamps down to nanosecond precision completely independent of the export timestamps. Relative timestamps can be expressed either as negative offsets to the export time (which can be a little tricky to implement, mind) or as positive offsets to the system initialization time (itself exported via options)
>
> Now, as you'll see elsewhere on the list, the flexible timestamps need a little work -- the microsecond and nanosecond types in particular are confusingly defined in a way that has led to (not-yet-verified) interoperability failures; the discussion about fixing this in 5101bis/5102bis is elsewhere on the ipfix list.
>
> Simply because an exporter has the _tools_ to export accurate 
> timestamps, of course, does not mean that it can (e.g. due to 
> implementation constraints) or will (e.g. due to faults or simple 
> laziness). And system initialization based relative timestamps can have 
> their own subtle pitfalls as in NetFlow V9 (on which see our paper in 
> PAM this year, "Peeling Away Timing Error in NetFlow Data", author copy 
> at 
> ftp://ftp.tik.ee.ethz.ch/pub/people/martibur/Netflow-Timing-PAM2011.pdf 
> -- the cyclic error from lost export time precision are V9-specific, but 
> particularly the drift and delay components of the error there are 
> universally applicable to any such arrangement, I think)
>
> But the protocol here should give you the room to do what you need with 
> respect to timing at the implementation level... WRT impacts on 
> documents, would it be helpful to have a more thorough handling of IPFIX 
> timestamping in the MIB Export draft (i.e., as an introduction for SNMP 
> people)?
>
> Cheers,
>
> Brian
>
> On Oct 12, 2011, at 9:47 AM, Josh Bailey wrote:
>
>>
>> Hi Juergen;
>>
>> I agree with your statement about SNMP not being designed for subsecond precision. And I definitely agree that there are things you can do to minimise potential delays and that often those delays are implementation specific.
>>
>> I don't agree though that sysUpTime is when the packet left the agent; especially if the agent is running slowly for whatever reason, or if the sysUpTime reply happens to be part of a packet containing replies for other variables (perhaps from different CPUs in a typical distributed CPU router).
>>
>> I also don't agree that cycles are usually measured in minutes. In my experience cycles are very much shorter on average.
>>
>> As you say having a timestamp per counter while costly is ideal in some sense. However I am looking to explore different tradeoffs; for example, a timestamp followed by a list of OIDs all current at that same timestamp.
>>
>> I am aware of counter implementations that could do such a "snapshot" operation for example.
>>
>> Thanks,
>>
>>>>
>>>> Hi Juergen;
>>>>
>>>> I assert that polling the sysUpTime does not take care of the core
>>>> problem, because you cannot know when sysUpTime itself was sampled
>>>> (eg. you received it after 1.5s because of network delay and because
>>>> the packet was queued in the control plane kernel because the
>>>> control plane CPU was busy).
>>>
>>> The SNMP agents controls sysUpTime - so sysUpTime is pretty much the
>>> time the packet left the agent. If you talk about delays in the
>>> instrumentation, that is the delay to read the register, then you are
>>> correct. But once again, SNMP polling cycles are usually counted in
>>> minutes.
>>>
>>>> I don't mind so much that the reply was delayed (though I like fast
>>>> replies!), but I do mind that there can be a very large uncertainty.
>>>
>>> Very large is relative to the precision you want. SNMP was not
>>> designed with subsecond precision in mind.
>>>
>>>> There is also the overhead of requesting sysUpTime itself, not to
>>>> mention when walking a table, you may time slew over the course of
>>>> walking the table.
>>>
>>> For any counter, you need discontinuity detection. The way you walk a
>>> table has indeed a big impact in terms of data consistency - the
>>> recommendation here is to use getbulk and to walk the columns of
>>> interest concurrently.
>>>
>>>> I understand definitely re caching hardware counters, etc, and I
>>>> think that's fine (and necessary in a system with multiple NMSes),
>>>> and I don't mind that the counters are cached, but I do want to know
>>>> when they were cached for me to recover maximum temporal
>>>> information.
>>>
>>> SNMP agents typically do not help you with that - caching is rather
>>> something implementation specific. And yes, operators have complained
>>> about SNMP counters on some boxes being less "precise" than what the
>>> CLI shows. I am no way saying SNMP is a model to choose - I just
>>> wanted to help making it clear what SNMP does and what not.
>>>
>>> If you want high accuracy, then every counter reading must be
>>> timestamped exactly when the counter is read. This of course has a
>>> price.
>>>
>>> /js
>>>
>>> --
>>> Juergen Schoenwaelder           Jacobs University Bremen gGmbH
>>> Phone: +49 421 200 3587         Campus Ring 1, 28759 Bremen, Germany
>>> Fax:   +49 421 200 3103         
>>>
>>>
>>>
>>
>> --
>> Josh Bailey
>> _______________________________________________
>> IPFIX mailing list
>> IPFIX@ietf.org
>> https://www.ietf.org/mailman/listinfo/ipfix
>
>
>

--
Josh Bailey

From bclaise@cisco.com  Thu Oct 13 03:33:54 2011
Return-Path: 
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 D189321F8B8C for ; Thu, 13 Oct 2011 03:33:54 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.469
X-Spam-Level: 
X-Spam-Status: No, score=-2.469 tagged_above=-999 required=5 tests=[AWL=0.130,  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 Rd7IIjYGp0HV for ; Thu, 13 Oct 2011 03:33:54 -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 020AD21F8B86 for ; Thu, 13 Oct 2011 03:33:53 -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 p9DAXpR4014943; Thu, 13 Oct 2011 12:33:51 +0200 (CEST)
Received: from [10.60.67.84] (ams-bclaise-8913.cisco.com [10.60.67.84]) by strange-brew.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id p9DAXpQ3009426; Thu, 13 Oct 2011 12:33:51 +0200 (CEST)
Message-ID: <4E96BE8F.4020706@cisco.com>
Date: Thu, 13 Oct 2011 12:33:51 +0200
From: Benoit Claise 
User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1
MIME-Version: 1.0
To: Josh Bailey 
References: 
In-Reply-To: 
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Cc: ipfix@ietf.org
Subject: Re: [IPFIX] timestamps, exporters, and other animals
X-BeenThere: ipfix@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: IPFIX WG discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 13 Oct 2011 10:33:54 -0000

Hi Josh,

Thanks for bringing up that point.
There are actually multiple cases

1.  Flow Records composed of MIB variables only.
Yes, we would need the time next to each counter, to be precise. At the 
minimum, a single time for all counters, assuming that all counters are 
read at the same time.
In this case, I believe that the Flow Records encoding have an advantage 
compared SNMP: the absolute timestamps.
I mean: when you receive a SNMP notification, you have the sysUpTime. 
Big deal! Hence some NMS just depends on the time the SNMP notifications 
arrives.

2. Flow Records composed of MIB variables completing the Flow IEs. 
Example: I want to poll my QoS class counters at the time of my flow
In this case, we need to pay attention to something else: we have to 
decide when to poll the counters: when the Flow started, when the Flow 
ended, multiple times along the Flow live, or ...?
Anyway, we would to attach the time next to the SNMP counters, exactly 
like in the first case.

Now, we still have the issue that some SNMP interface counters are not 
updated real-time! Obviously, this metering issue will not be solved 
with a new encoding.

Regards, Benoit.
>
> Hi all;
>
> So I wanted to start a discussion around timestamps when exporting 
> flows or OID values (qv. 
> http://www.ietf.org/proceedings/81/slides/ipfix-6.pdf).
>
> I think it'd be good thing to specify an association between a 
> timestamp, and an exported OID, flow, etc. When exporting an OID, for 
> example, I would like a way to know within some limit of certainty 
> when that OID value was actually sampled.
>
> A problem I find with SNMP is that the client can only use its own 
> timestamp of the server's reply to guess when the requested variable 
> was sampled. If there is uncertainty in the server implementation that 
> adds some delay between sampling and sending the response (without 
> even addressing variable network delay), there's no way to know when 
> the object
> was sampled with any certainty.
>
> I have also seen this problem in various sFlow implementations. There, 
> often the timestamp is added by the control plane an unknown amount of 
> time after the sample was taken.
>
> Has there been any prior work or discussion around this issue? I had a 
> few of my own thoughts about how to approach it, but I thought it 
> would be useful to start here.
>
> PS. For background - I am looking at NMS/protocol implementation for 
> OpenFlow devices, which might have very many distributed individual 
> devices with very many ports and variables per port. Therefore I'd 
> very much like to implement an efficient NMS "counter" protocol.
>
> Thanks,
>
> -- 
> Josh Bailey
> _______________________________________________
> IPFIX mailing list
> IPFIX@ietf.org
> https://www.ietf.org/mailman/listinfo/ipfix
>
>


From bclaise@cisco.com  Thu Oct 13 04:21:56 2011
Return-Path: 
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 DA73921F8AC3 for ; Thu, 13 Oct 2011 04:21:56 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.481
X-Spam-Level: 
X-Spam-Status: No, score=-2.481 tagged_above=-999 required=5 tests=[AWL=0.118,  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 qx2kHaIQuh8x for ; Thu, 13 Oct 2011 04:21:55 -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 88E2121F8A70 for ; Thu, 13 Oct 2011 04:21:55 -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 p9DAc2jT015413; Thu, 13 Oct 2011 12:38:02 +0200 (CEST)
Received: from [10.60.67.84] (ams-bclaise-8913.cisco.com [10.60.67.84]) by strange-brew.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id p9DAc2lV012172; Thu, 13 Oct 2011 12:38:02 +0200 (CEST)
Message-ID: <4E96BF8A.5020009@cisco.com>
Date: Thu, 13 Oct 2011 12:38:02 +0200
From: Benoit Claise 
User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1
MIME-Version: 1.0
To: Josh Bailey 
References:  
In-Reply-To: 
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Cc: ipfix@ietf.org
Subject: Re: [IPFIX] timestamps, exporters, and other animals (fwd)
X-BeenThere: ipfix@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: IPFIX WG discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 13 Oct 2011 11:21:57 -0000

Josh, Brian,

Point taken. I created an open issue for the draft.

Regards, Benoit.
>
> Hi Brian;
>
> In summary - yes! I believe you perceive where I'm coming from most 
> accurately. I would be very interested in specific handling of this 
> issue in the next draft.
>
>> Hi, Josh, all,
>>
>> As I read it, one of the wins of MIB Variable Export is that you get 
>> the whole timestamp machinery of IPFIX for free, including absolute 
>> timestamps wherein individual records can have observation timestamps 
>> down to nanosecond precision completely independent of the export 
>> timestamps. Relative timestamps can be expressed either as negative 
>> offsets to the export time (which can be a little tricky to 
>> implement, mind) or as positive offsets to the system initialization 
>> time (itself exported via options)
>>
>> Now, as you'll see elsewhere on the list, the flexible timestamps 
>> need a little work -- the microsecond and nanosecond types in 
>> particular are confusingly defined in a way that has led to 
>> (not-yet-verified) interoperability failures; the discussion about 
>> fixing this in 5101bis/5102bis is elsewhere on the ipfix list.
>>
>> Simply because an exporter has the _tools_ to export accurate 
>> timestamps, of course, does not mean that it can (e.g. due to 
>> implementation constraints) or will (e.g. due to faults or simple 
>> laziness). And system initialization based relative timestamps can 
>> have their own subtle pitfalls as in NetFlow V9 (on which see our 
>> paper in PAM this year, "Peeling Away Timing Error in NetFlow Data", 
>> author copy at 
>> ftp://ftp.tik.ee.ethz.ch/pub/people/martibur/Netflow-Timing-PAM2011.pdf 
>> -- the cyclic error from lost export time precision are V9-specific, 
>> but particularly the drift and delay components of the error there 
>> are universally applicable to any such arrangement, I think)
>>
>> But the protocol here should give you the room to do what you need 
>> with respect to timing at the implementation level... WRT impacts on 
>> documents, would it be helpful to have a more thorough handling of 
>> IPFIX timestamping in the MIB Export draft (i.e., as an introduction 
>> for SNMP people)?
>>
>> Cheers,
>>
>> Brian
>>
>> On Oct 12, 2011, at 9:47 AM, Josh Bailey wrote:
>>
>>>
>>> Hi Juergen;
>>>
>>> I agree with your statement about SNMP not being designed for 
>>> subsecond precision. And I definitely agree that there are things 
>>> you can do to minimise potential delays and that often those delays 
>>> are implementation specific.
>>>
>>> I don't agree though that sysUpTime is when the packet left the 
>>> agent; especially if the agent is running slowly for whatever 
>>> reason, or if the sysUpTime reply happens to be part of a packet 
>>> containing replies for other variables (perhaps from different CPUs 
>>> in a typical distributed CPU router).
>>>
>>> I also don't agree that cycles are usually measured in minutes. In 
>>> my experience cycles are very much shorter on average.
>>>
>>> As you say having a timestamp per counter while costly is ideal in 
>>> some sense. However I am looking to explore different tradeoffs; for 
>>> example, a timestamp followed by a list of OIDs all current at that 
>>> same timestamp.
>>>
>>> I am aware of counter implementations that could do such a 
>>> "snapshot" operation for example.
>>>
>>> Thanks,
>>>
>>>>>
>>>>> Hi Juergen;
>>>>>
>>>>> I assert that polling the sysUpTime does not take care of the core
>>>>> problem, because you cannot know when sysUpTime itself was sampled
>>>>> (eg. you received it after 1.5s because of network delay and because
>>>>> the packet was queued in the control plane kernel because the
>>>>> control plane CPU was busy).
>>>>
>>>> The SNMP agents controls sysUpTime - so sysUpTime is pretty much the
>>>> time the packet left the agent. If you talk about delays in the
>>>> instrumentation, that is the delay to read the register, then you are
>>>> correct. But once again, SNMP polling cycles are usually counted in
>>>> minutes.
>>>>
>>>>> I don't mind so much that the reply was delayed (though I like fast
>>>>> replies!), but I do mind that there can be a very large uncertainty.
>>>>
>>>> Very large is relative to the precision you want. SNMP was not
>>>> designed with subsecond precision in mind.
>>>>
>>>>> There is also the overhead of requesting sysUpTime itself, not to
>>>>> mention when walking a table, you may time slew over the course of
>>>>> walking the table.
>>>>
>>>> For any counter, you need discontinuity detection. The way you walk a
>>>> table has indeed a big impact in terms of data consistency - the
>>>> recommendation here is to use getbulk and to walk the columns of
>>>> interest concurrently.
>>>>
>>>>> I understand definitely re caching hardware counters, etc, and I
>>>>> think that's fine (and necessary in a system with multiple NMSes),
>>>>> and I don't mind that the counters are cached, but I do want to know
>>>>> when they were cached for me to recover maximum temporal
>>>>> information.
>>>>
>>>> SNMP agents typically do not help you with that - caching is rather
>>>> something implementation specific. And yes, operators have complained
>>>> about SNMP counters on some boxes being less "precise" than what the
>>>> CLI shows. I am no way saying SNMP is a model to choose - I just
>>>> wanted to help making it clear what SNMP does and what not.
>>>>
>>>> If you want high accuracy, then every counter reading must be
>>>> timestamped exactly when the counter is read. This of course has a
>>>> price.
>>>>
>>>> /js
>>>>
>>>> -- 
>>>> Juergen Schoenwaelder           Jacobs University Bremen gGmbH
>>>> Phone: +49 421 200 3587         Campus Ring 1, 28759 Bremen, Germany
>>>> Fax:   +49 421 200 3103 
>>>>
>>>>
>>>>
>>>
>>> -- 
>>> Josh Bailey
>>> _______________________________________________
>>> IPFIX mailing list
>>> IPFIX@ietf.org
>>> https://www.ietf.org/mailman/listinfo/ipfix
>>
>>
>>
>
> -- 
> Josh Bailey
> _______________________________________________
> IPFIX mailing list
> IPFIX@ietf.org
> https://www.ietf.org/mailman/listinfo/ipfix
>
>


From n.brownlee@auckland.ac.nz  Thu Oct 13 13:50:09 2011
Return-Path: 
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 AE27F21F8B3A for ; Thu, 13 Oct 2011 13:50:09 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -106.486
X-Spam-Level: 
X-Spam-Status: No, score=-106.486 tagged_above=-999 required=5 tests=[AWL=0.114, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, 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 jL+C6DOetvS8 for ; Thu, 13 Oct 2011 13:50:08 -0700 (PDT)
Received: from mx1.auckland.ac.nz (mx1.auckland.ac.nz [130.216.12.42]) by ietfa.amsl.com (Postfix) with ESMTP id BB49021F8B34 for ; Thu, 13 Oct 2011 13:50:07 -0700 (PDT)
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=1318539008; x=1350075008; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; z=Message-ID:=20<4E974EFD.1010502@auckland.ac.nz>|Date:=20 Fri,=2014=20Oct=202011=2009:50:05=20+1300|From:=20Nevil =20Brownlee=20|MIME-Version: =201.0|To:=20iana-matrix@iana.org|CC:=20Paul=20Aitken=20< paitken@cisco.com>,=20IPFIX=20Working=20Group=20|Subject:=20Re:=20[IANA=20#493526]=20Re:=20=20Gene ral=20Request=20for=20Assignment=20(ipfix)|References:=20 =20=20<201109221140.p8MBeSVg004561@smtp01.icann.org>=20=20<4E 8CE2B4.5050007@cisco.com>=20=20<4E96AE04.5050109@cisco.com> |In-Reply-To:=20<4E96AE04.5050109@cisco.com> |Content-Transfer-Encoding:=207bit; bh=7NkofsYr6bu2dubYwO8uo072jXIVXtz32BbWZ5PByI4=; b=oYvOBkpPpSkn4R2UniBfhdkAMjCahES8MPPVHm6Sz6E/5EWb0PzvWFFW x6/oJiSRje49gwdWdYbtRpJyAu7nzh2JwI96ygj81V525qNHcMXvwjAro dxWhzgXqzRUCVF78G2C7ROWhHObmm42klteuG9wReoqJahCK0IjbewtYW I=;
X-IronPort-AV: E=Sophos;i="4.69,342,1315137600"; d="scan'208";a="106803947"
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 mx1-int.auckland.ac.nz with ESMTP; 14 Oct 2011 09:50:06 +1300
Message-ID: <4E974EFD.1010502@auckland.ac.nz>
Date: Fri, 14 Oct 2011 09:50:05 +1300
From: Nevil Brownlee 
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1
MIME-Version: 1.0
To: iana-matrix@iana.org
References:   <201109221140.p8MBeSVg004561@smtp01.icann.org>  <4E8CE2B4.5050007@cisco.com>  <4E96AE04.5050109@cisco.com>
In-Reply-To: <4E96AE04.5050109@cisco.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Cc: IPFIX Working Group 
Subject: Re: [IPFIX] [IANA #493526] Re: General Request for Assignment (ipfix)
X-BeenThere: ipfix@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: IPFIX WG discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 13 Oct 2011 20:50:09 -0000

Hi Amanda:

I agree with Paul, natType would be a more consistent name for
that Information Element.

Cheers, Nevil


On 13/10/11 10:23 PM, Paul Aitken wrote:
> Amanda,
>
>> Hi Paul,
>>
>> These changes are complete:
>>
>> http://www.iana.org/assignments/ipfix
>
> Thanks for that.
>
> Two points:
>
>
> 1. I suspect that the name should be "natType" rather than "NATtype",
> for consistency with existing fields such as
> "natOriginatingAddressRealm", "natEvent", "natPoolID", and "natPoolName".
>
>
> 2. Unfortunately the description appears flat like so:
>
> The type of NAT treatment: 0 unknown 1 NAT44 translated 2 NAT64
> translated 3 NAT46
> translated 4 IPv4-->IPv4 (no NAT) 5 NAT66 translated 6 IPv6-->IPv6
> (no NAT)
>
> - so the separation of the items is lost, and it's not at all clear that
> this is an enumerated list.
>
> Could you make it appear like so?:
>
> The type of NAT treatment:
> 0 unknown
> 1 NAT44 translated
> 2 NAT64 translated
> 3 NAT46 translated
> 4 IPv4-->IPv4 (no NAT)
> 5 NAT66 translated
> 6 IPv6-->IPv6 (no NAT)
>
>
> Fields 229, 230, 233, and 277 would benefit from a similar improvement.
>
> I envisage each of these as an extensible list, so new values can be
> added in future.
> eg, NAT444 may be appended to the NAT type - see draft-shirasaki-nat444.
>
> Thanks,
> P.
>
>


-- 
---------------------------------------------------------------------
  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 Quittek@neclab.eu  Mon Oct 24 11:06:52 2011
Return-Path: 
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 C2A9A21F8B38 for ; Mon, 24 Oct 2011 11:06:52 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.599
X-Spam-Level: 
X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[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 oJrw9C2-noFS for ; Mon, 24 Oct 2011 11:06:51 -0700 (PDT)
Received: from mailer1.neclab.eu (mailer1.neclab.eu [195.37.70.40]) by ietfa.amsl.com (Postfix) with ESMTP id 13EA421F8B9D for ; Mon, 24 Oct 2011 11:06:51 -0700 (PDT)
Received: from localhost (localhost.localdomain [127.0.0.1]) by mailer1.neclab.eu (Postfix) with ESMTP id C71AC280000F5; Mon, 24 Oct 2011 20:07:10 +0200 (CEST)
X-Virus-Scanned: Amavisd on Debian GNU/Linux (netlab.nec.de)
Received: from mailer1.neclab.eu ([127.0.0.1]) by localhost (atlas1.office.hd [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5JxmXxOearc8; Mon, 24 Oct 2011 20:07:10 +0200 (CEST)
Received: from ENCELADUS.office.hd (ENCELADUS.office.hd [192.168.24.52]) by mailer1.neclab.eu (Postfix) with ESMTP id A9AF128000080; Mon, 24 Oct 2011 20:06:55 +0200 (CEST)
Received: from PALLENE.office.hd ([169.254.1.17]) by ENCELADUS.office.hd ([192.168.24.52]) with mapi id 14.01.0323.003; Mon, 24 Oct 2011 20:06:35 +0200
From: Juergen Quittek 
To: Dan Romascanu 
Thread-Topic: IPFIX re-chartering request
Thread-Index: AQHMkneqQnE4NqwHPUOVKcnRelBBWg==
Date: Mon, 24 Oct 2011 18:06:35 +0000
Message-ID: 
Accept-Language: de-DE, en-US
Content-Language: de-DE
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
user-agent: Microsoft-MacOutlook/14.13.0.110805
x-originating-ip: [10.1.2.219]
Content-Type: text/plain; charset="us-ascii"
Content-ID: <54EF99E3C4FD36438D8A00288390F223@office.hd>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: Ronald Bonica , IETF IPFIX Working Group 
Subject: [IPFIX] IPFIX re-chartering request
X-BeenThere: ipfix@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: IPFIX WG discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 24 Oct 2011 18:06:52 -0000

Dear Dan,

As discussed at the last IPFIX session and on the mailing
list, here is a proposal from the IPFIX WG for an update
of the IPFIX WG charter.

Please find the revised version below. It describes eight
new drafts to produce.  For each of them we have already
a quite mature version that is ready for immediate adoption
as WG draft and that is expected to resolve remaining open
issues soon.

>From our old charter we have only a single milestone left:

Dec 2010   Submit flow selection I-D to IESG for publication as
           Standards Track RFC

This draft still needs a few changes based on comments from
the last WGLC and will then be ready for submission.


Proposal for IPFIX charter update
###########################

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 existing implementations, the IPFIX WG will revisit the
IPFIX protocol specifications (RFC 5101) and the IPFIX information
element specification (RFC 5102) in order to in order to advance them
to the next stage on the standards track.

All following items 2.-7. will be in line with the revised versions
of the IPFIX protocol specifications and the IPFIX information model.

2. In order to provide 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 a set of specifications for applying the IPFIX protocol at
mediators, including new specifications for protocol issues not
envisioned by the IPFIX protocol itself.

4.In order to support 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 MIB modules.

7. Operational experiences showed that it would be useful to define
several new information elements for data link monitoring covering
frame size, type, sections of frames, and VLAN information. The IPFIX
WG will create a document defining these new information elements.


Nov 2011   Publish Internet-Draft on guidelines for IE doctors
Nov 2011   Publish Internet-Draft on IPFIX use at mediators
Nov 2011   Publish Internet-Draft on intermediate aggregation
Nov 2011   Publish Internet-Draft on exporting MIB objects
Nov 2011   Publish Internet-Draft on data link IEs
Nov 2011   Publish Internet-Draft on revised IPFIX MIB
Dec 2011   Publish Internet-Draft revising RFC 5101
Dec 2011   Publish Internet-Draft revising RFC 5102

Dec 2011   Submit flow selection I-D to IESG for publication as
           Standards Track RFC

Apr 2012   Submit guidelines for IE doctors for publication as
           Informational BCP RFC
Apr 2012   Submit IPFIX use at mediators for publication as
           Standards track RFC
Apr 2012   Submit intermediate aggregation for publication as
           Standards track RFC
Apr 2012   Submit data link IEs for publication as
           Standards track RFC
Apr 2012   Submit revised RFC 5101 for publication as
           Standards track RFC
Apr 2012   Submit revised IPFIX MIB for publications as
           Standards track RFC
Apr 2012   Submit revised RFC 5102 for publication as
           Standards track RFC
Sep 2012   Submit export of MIB objects for publication as
           Standards track RFC


From Thomas.Dietz@neclab.eu  Wed Oct 26 01:48:58 2011
Return-Path: 
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 2836E21F8A58 for ; Wed, 26 Oct 2011 01:48:58 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level: 
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jAs6A8jeuHeJ for ; Wed, 26 Oct 2011 01:48:54 -0700 (PDT)
Received: from mailer1.neclab.eu (mailer1.neclab.eu [195.37.70.40]) by ietfa.amsl.com (Postfix) with ESMTP id F0E8821F8AAA for ; Wed, 26 Oct 2011 01:48:51 -0700 (PDT)
Received: from localhost (localhost.localdomain [127.0.0.1]) by mailer1.neclab.eu (Postfix) with ESMTP id 32A7228000082 for ; Wed, 26 Oct 2011 10:49:13 +0200 (CEST)
X-Virus-Scanned: Amavisd on Debian GNU/Linux (netlab.nec.de)
Received: from mailer1.neclab.eu ([127.0.0.1]) by localhost (atlas1.office.hd [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id z2J3wVkGZ1O5 for ; Wed, 26 Oct 2011 10:49:13 +0200 (CEST)
Received: from ENCELADUS.office.hd (ENCELADUS.office.hd [192.168.24.52]) by mailer1.neclab.eu (Postfix) with ESMTP id 12BC428000080 for ; Wed, 26 Oct 2011 10:49:08 +0200 (CEST)
Received: from PALLENE.office.hd ([169.254.1.17]) by ENCELADUS.office.hd ([192.168.24.52]) with mapi id 14.01.0323.003; Wed, 26 Oct 2011 10:48:43 +0200
From: Thomas Dietz 
To: "ipfix@ietf.org" 
Thread-Topic: Updated Version of RFC5815 (IPFIX MIB)
Thread-Index: AcyTvBA1O0f2TdlTQquPt0B8h4n10w==
Date: Wed, 26 Oct 2011 08:48:43 +0000
Message-ID: <75581E268A48F849916117B977D76D3734C0689A@PALLENE.office.hd>
Accept-Language: en-US, de-DE
Content-Language: en-US
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator: 
x-originating-ip: [10.1.1.137]
Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_00B4_01CC93CC.D3D2A2B0"
MIME-Version: 1.0
Subject: [IPFIX] Updated Version of RFC5815 (IPFIX MIB)
X-BeenThere: ipfix@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: IPFIX WG discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 26 Oct 2011 08:48:58 -0000

------=_NextPart_000_00B4_01CC93CC.D3D2A2B0
Content-Type: text/plain;
	charset="iso-2022-jp"
Content-Transfer-Encoding: 7bit

Dear all,

I have posted an updated version of RFC5815. It is already listed at the
datatracker pages for IPFIX as
http://datatracker.ietf.org/doc/draft-dkcm-ipfix-rfc5815bis/ 

This version changes the way how Selector Functions for Sampling and
Filtering are registered with IANA because the method put forward in RFC5815
was not suitable. This was already discussed at the last IETF meeting.

I will update the PSAMP MIB draft this week to reflect the changes in the
new version of RFC5815.

Any comments and improvements are welcome.

Best Regards,

Thomas

-- 
Thomas Dietz                 E-mail: Thomas.Dietz@neclab.eu
$B%H!<%^%9!&%B%#!<%D(B
NEC Europe Ltd.              Phone: +49 6221 4342-128
NEC Laboratories Europe      Fax:   +49 6221 4342-155
Network Research Division
Kurfuersten-Anlage 36
69115 Heidelberg, Germany    http://www.neclab.eu

NEC Europe Limited             Registered in England 2832014
Registered Office: NEC House, 1 Victoria Road, London W3 6BL


------=_NextPart_000_00B4_01CC93CC.D3D2A2B0
Content-Type: application/pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIISNDCCA58w
ggKHoAMCAQICASYwDQYJKoZIhvcNAQEFBQAwcTELMAkGA1UEBhMCREUxHDAaBgNVBAoTE0RldXRz
Y2hlIFRlbGVrb20gQUcxHzAdBgNVBAsTFlQtVGVsZVNlYyBUcnVzdCBDZW50ZXIxIzAhBgNVBAMT
GkRldXRzY2hlIFRlbGVrb20gUm9vdCBDQSAyMB4XDTk5MDcwOTEyMTEwMFoXDTE5MDcwOTIzNTkw
MFowcTELMAkGA1UEBhMCREUxHDAaBgNVBAoTE0RldXRzY2hlIFRlbGVrb20gQUcxHzAdBgNVBAsT
FlQtVGVsZVNlYyBUcnVzdCBDZW50ZXIxIzAhBgNVBAMTGkRldXRzY2hlIFRlbGVrb20gUm9vdCBD
QSAyMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAqwujNeCLKRSxFIWvPBDkOW81XUqu
3ephjZVJ9G9koxpgZqSpQCKE2dSl5XiTDmgBrblNXDrO07ioQkDfz6O6gllqkhusHJraCCslJ/lp
I0fx4Ossepv1EwLQfjR8wp48AFmr9doM9TI8K6xQ2tbD3oOUyqgMmTIOCEhWW2r72uFYWAFJX3JB
PBUGAY5draq4k7TNnuun6GotUjTbOu9cdVHa2/Mx+e5xmDLEVBVEDPmbVe2t3xgIoKOGiknuUwWP
GUzV3lh5m9JqHEKrxdWnz2gPluThYZh2YciRfNY+AOKRUIfhnQrmrZfSHcY6fcu82gM01Y5bAfVq
B7cWtm5KfwIDAQABo0IwQDAdBgNVHQ4EFgQUMcN5G7r1U9cX4Il6LRdsCrMrnTMwDwYDVR0TBAgw
BgEB/wIBBTAOBgNVHQ8BAf8EBAMCAQYwDQYJKoZIhvcNAQEFBQADggEBAJRkWa05ZOcp6xP+WsOL
E1fIBCTwdHfAYONn++mJpoO/loJ8btTDPe+egG67KbSYerE7VOs5F0d+Go4L/B8xWTEEss4X8yzH
YjZV4iLYiVW0mEiqZPrWHDbYRHhaWiM6V5f1ejBPrp9qTEsrjqAD4z7gqdTSe9KzqOJyPK2e/4BZ
5JtFtPY7sM05GZgy5eohYZDkMSGONLH3LzVKhRDa54o3Ib5ZY+DyhYgxU9RUFIVwefQuBncndS8f
uIr5/sW62Dbkg+znZbe/Y1rzRq+BlDfUQYzWI9Yez/VoG0Rjolq6pzVZoeVwBZsOI1eZlAptujlj
KIaS8xiE2PvRzwVWZFcwggQhMIIDCaADAgECAgIAxzANBgkqhkiG9w0BAQUFADBxMQswCQYDVQQG
EwJERTEcMBoGA1UEChMTRGV1dHNjaGUgVGVsZWtvbSBBRzEfMB0GA1UECxMWVC1UZWxlU2VjIFRy
dXN0IENlbnRlcjEjMCEGA1UEAxMaRGV1dHNjaGUgVGVsZWtvbSBSb290IENBIDIwHhcNMDYxMjE5
MTAyOTAwWhcNMTkwNjMwMjM1OTAwWjBaMQswCQYDVQQGEwJERTETMBEGA1UEChMKREZOLVZlcmVp
bjEQMA4GA1UECxMHREZOLVBLSTEkMCIGA1UEAxMbREZOLVZlcmVpbiBQQ0EgR2xvYmFsIC0gRzAx
MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA6ZvDZ4X5Da71jVTDllA1PWLpbkztlNcA
W5UidNQg6zSP1uzAMQQLmYHiphTSUqAoI4SLdIkEXlvg4njBeMsWyyg1OXstkEXQ7aAAeny/Sg4b
AMOG6VwrMRF7DPOCJEOMHDiLamgAmu7cT3ir0sYTm3at7t4m6O8Br3QPwQmi9mvOvdPNFDBP9eXj
pMhim4IaAycwDQJlYE3t0QkjKpY1WCfTdsZxtpAdxO3/NYZ9bzOz2w/FEcKKg6GUXUFr2NIQ9Uz9
ylGs2b3vkoO72uuLFlZWQ8/h1RM9ph8nMM1JVNvJEzSacXXFbOqnC5j5IZ0nrz6jOTlIaoytyZn7
wxLyvQIDAQABo4HZMIHWMHAGA1UdHwRpMGcwZaBjoGGGX2h0dHA6Ly9wa2kudGVsZXNlYy5kZS9j
Z2ktYmluL3NlcnZpY2UvYWZfRG93bmxvYWRBUkwuY3JsPy1jcmxfZm9ybWF0PVhfNTA5Ji1pc3N1
ZXI9RFRfUk9PVF9DQV8yMB0GA1UdDgQWBBRJt8bP6D0ff+pEexMp9/EKcD7eZDAfBgNVHSMEGDAW
gBQxw3kbuvVT1xfgiXotF2wKsyudMzAOBgNVHQ8BAf8EBAMCAQYwEgYDVR0TAQH/BAgwBgEB/wIB
AjANBgkqhkiG9w0BAQUFAAOCAQEAO+Fad8BIF9ypGOyBr1qJ8L0okqbKWRgScOwo8ueuf5Ys5/Jd
GTH2Eyt0vb2Asrn3Z8k5onk74RER7mt4kTN+O18mJ3VTZY4zY+7Pc8OwkiNJIVB1I6EfGOKUhT0/
M+l3II2iveahhSlA9j9zMlgNCWum2oVswD+7jWZkViROrg0/MjUBW+mMgtlyWU+xhoXxdIVW5cP4
XPON7kezUwVw5+VNimmDKOETCYaeXsjqWB4MH/mk1FoEaP0oPosCtli19qEsN1cAZ6sjaI1jpe+Z
a1z9S1b2q0CHNNQRkmzsh8UKCwczcrRvDB1ULNhRx8y/MNNDcvEyv4zOSWOoAPfyHDCCBS8wggQX
oAMCAQICBA0hCkcwDQYJKoZIhvcNAQEFBQAwWjELMAkGA1UEBhMCREUxEzARBgNVBAoTCkRGTi1W
ZXJlaW4xEDAOBgNVBAsTB0RGTi1QS0kxJDAiBgNVBAMTG0RGTi1WZXJlaW4gUENBIEdsb2JhbCAt
IEcwMTAeFw0wODEwMjQwODUyMDhaFw0xOTA2MzAwMDAwMDBaMIGQMQswCQYDVQQGEwJERTEYMBYG
A1UEChMPTkVDIEV1cm9wZSBMdGQuMSAwHgYDVQQLExdORUMgTGFib3JhdG9yaWVzIEV1cm9wZTES
MBAGA1UEAxMJTkVDTEFCLUNBMTEwLwYJKoZIhvcNAQkBFiJ6ZXJ0aWZpemllcnVuZ3NzdGVsbGVA
bncubmVjbGFiLmV1MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAnvIVsbURqjIOcbnf
ruYkRceWOZpyvM2ebnYpbd1cP+zdWm6yR7HSO9ppOe1ZZFIasArqQpedPEFvcncSG94FRuW3ND4r
Rcq08mbpUTmpWmXfdYlJpQezbsOHCWR74NXoEEbK6TPZIMFpJr6dzQDAxnRc7UOgO6JQ1V42Z39B
PhIbPIWz64t8svafxbORmxulJn7F5zDLDcR1AEGyn+L9b645AGwapoKNh7cSQFTqdb6kGyPQjLWf
tv09dvmBDKesrcyLZXuDWJ1LMeizSjUEygdSszNXD3gePgJaVaZDS3o923W5gAyPCTSxpAFj8XJ+
/7Ap5jJwYhjJgJ8khFR7JQIDAQABo4IBxDCCAcAwEgYDVR0TAQH/BAgwBgEB/wIBATALBgNVHQ8E
BAMCAQYwHQYDVR0OBBYEFE8ch3od4C+Z9r4VqtE1nQ5K5ro2MB8GA1UdIwQYMBaAFEm3xs/oPR9/
6kR7Eyn38QpwPt5kMC0GA1UdEQQmMCSBInplcnRpZml6aWVydW5nc3N0ZWxsZUBudy5uZWNsYWIu
ZXUwgYgGA1UdHwSBgDB+MD2gO6A5hjdodHRwOi8vY2RwMS5wY2EuZGZuLmRlL2dsb2JhbC1yb290
LWNhL3B1Yi9jcmwvY2FjcmwuY3JsMD2gO6A5hjdodHRwOi8vY2RwMi5wY2EuZGZuLmRlL2dsb2Jh
bC1yb290LWNhL3B1Yi9jcmwvY2FjcmwuY3JsMIGiBggrBgEFBQcBAQSBlTCBkjBHBggrBgEFBQcw
AoY7aHR0cDovL2NkcDEucGNhLmRmbi5kZS9nbG9iYWwtcm9vdC1jYS9wdWIvY2FjZXJ0L2NhY2Vy
dC5jcnQwRwYIKwYBBQUHMAKGO2h0dHA6Ly9jZHAyLnBjYS5kZm4uZGUvZ2xvYmFsLXJvb3QtY2Ev
cHViL2NhY2VydC9jYWNlcnQuY3J0MA0GCSqGSIb3DQEBBQUAA4IBAQBsMQ+dD0mmi48dgDU4R6Q/
eXcY0zQcHNp1Vu1s3kwO0WahWB0tiqVBodvfTAWG44xuw0I7NXSTwQ68FU5P0GIQnvRFZyVJlDjr
SNlLYxjqfmgb+KVm67o383cZIuDakEE0f29kULIEn2fg/HsDiBAXTsb4I19XaN0TXLI+PMhU+GDp
sGCJrydeugEV7qi15q8yymjSAsYgnrc2wJuXpyQ9r3qCtP6aedAPSHqOT8ga1dLT2YRZFs3vNm7T
HSr5JJymWMbfpD6OcbRTnNAjSMDHwJxgRBAflA6WzDVm7fk4jiWyLvJwWTMk19t8QLiKG7D0nYvj
cEUYyiOSE+SFUTEdMIIFNTCCBB2gAwIBAgIED+0gWzANBgkqhkiG9w0BAQUFADCBkDELMAkGA1UE
BhMCREUxGDAWBgNVBAoTD05FQyBFdXJvcGUgTHRkLjEgMB4GA1UECxMXTkVDIExhYm9yYXRvcmll
cyBFdXJvcGUxEjAQBgNVBAMTCU5FQ0xBQi1DQTExMC8GCSqGSIb3DQEJARYiemVydGlmaXppZXJ1
bmdzc3RlbGxlQG53Lm5lY2xhYi5ldTAeFw0xMDA0MjAxMjQ5MTVaFw0xMzA0MTkxMjQ5MTVaMGAx
CzAJBgNVBAYTAkRFMRgwFgYDVQQKEw9ORUMgRXVyb3BlIEx0ZC4xIDAeBgNVBAsTF05FQyBMYWJv
cmF0b3JpZXMgRXVyb3BlMRUwEwYDVQQDEwxUaG9tYXMgRGlldHowggEiMA0GCSqGSIb3DQEBAQUA
A4IBDwAwggEKAoIBAQD2mMcvPbgraEaWMV6uNCs6t88lhBczgfxybD46mwr8D3VaQLEnqTsBOAf/
Y8ARtq+P6Dkm2MBMXQG+Ebo2qhif6O4dH7whcG9E88F9247R2EJjcXmxMYZWYGQTI2vGw/joerRB
waiwfxCXWBTLutbdWEEKL/DG9A1yQRPGJc+jJYfgm0ekYn+WESOLYaBH7G9aIIZQ7en3afhPpbQA
Ajh92K240TG+VgBpe1vnDdth28Ps5XeN+otookDZHwwGQYwYrPZJtnhGIyjKMm7OkXL62Rf3aSoI
doVUwYYS67RYYNOY0C7qOVyCUF+z4Bkn758sZhZzotiLQVT3AZ625PrvAgMBAAGjggHEMIIBwDAJ
BgNVHRMEAjAAMAsGA1UdDwQEAwIF4DApBgNVHSUEIjAgBggrBgEFBQcDAgYIKwYBBQUHAwQGCisG
AQQBgjcUAgIwHQYDVR0OBBYEFH9fxgi2EshupgLF49SzaAX0QFoMMB8GA1UdIwQYMBaAFE8ch3od
4C+Z9r4VqtE1nQ5K5ro2MCEGA1UdEQQaMBiBFlRob21hcy5EaWV0ekBuZWNsYWIuZXUwfQYDVR0f
BHYwdDA4oDagNIYyaHR0cDovL2NkcDEucGNhLmRmbi5kZS9uZWNsYWItY2EvcHViL2NybC9jYWNy
bC5jcmwwOKA2oDSGMmh0dHA6Ly9jZHAyLnBjYS5kZm4uZGUvbmVjbGFiLWNhL3B1Yi9jcmwvY2Fj
cmwuY3JsMIGYBggrBgEFBQcBAQSBizCBiDBCBggrBgEFBQcwAoY2aHR0cDovL2NkcDEucGNhLmRm
bi5kZS9uZWNsYWItY2EvcHViL2NhY2VydC9jYWNlcnQuY3J0MEIGCCsGAQUFBzAChjZodHRwOi8v
Y2RwMi5wY2EuZGZuLmRlL25lY2xhYi1jYS9wdWIvY2FjZXJ0L2NhY2VydC5jcnQwDQYJKoZIhvcN
AQEFBQADggEBACnPHI1mIY1TVY9Aj8zsHHxiwMRx02Hp6DLZGYXHGG9IkflrRKNiDIV2LbBDpXVH
vojMxTtCt10iwbyVMGaevet/VHYCJSHzrCLkw+GkvuhDU70lNsWw9P+mai7OHa+NQ6im8+4RnY1B
yhqidcCt3hIV9B69ax0/KIhIFpiWz/lKZVIghki07I4m8mf1sbvCORKxudH0TVLlRJlX1r8S+8ea
9e+Q8pgXfrsCeyxBV3KAjszRQkqDZsbD7jQHQWokkMPIjbaTjw6V/5SRzmcAy0XlKNOCbldlzmCB
jDZTQWdSH/AFDy5L2l4j0Ck0vVlQv+r1F4omsb4BelRq+vHd+lExggQsMIIEKAIBATCBmTCBkDEL
MAkGA1UEBhMCREUxGDAWBgNVBAoTD05FQyBFdXJvcGUgTHRkLjEgMB4GA1UECxMXTkVDIExhYm9y
YXRvcmllcyBFdXJvcGUxEjAQBgNVBAMTCU5FQ0xBQi1DQTExMC8GCSqGSIb3DQEJARYiemVydGlm
aXppZXJ1bmdzc3RlbGxlQG53Lm5lY2xhYi5ldQIED+0gWzAJBgUrDgMCGgUAoIICZzAYBgkqhkiG
9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xMTEwMjYwODQ4NDJaMCMGCSqGSIb3
DQEJBDEWBBRrhsWGY9oF82eloP18z2U4wS8MvzCBqgYJKwYBBAGCNxAEMYGcMIGZMIGQMQswCQYD
VQQGEwJERTEYMBYGA1UEChMPTkVDIEV1cm9wZSBMdGQuMSAwHgYDVQQLExdORUMgTGFib3JhdG9y
aWVzIEV1cm9wZTESMBAGA1UEAxMJTkVDTEFCLUNBMTEwLwYJKoZIhvcNAQkBFiJ6ZXJ0aWZpemll
cnVuZ3NzdGVsbGVAbncubmVjbGFiLmV1AgQP7SBbMIGrBgkqhkiG9w0BCQ8xgZ0wgZowCwYJYIZI
AWUDBAEqMAsGCWCGSAFlAwQBFjAKBggqhkiG9w0DBzALBglghkgBZQMEAQIwDgYIKoZIhvcNAwIC
AgCAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgFAMA0GCCqGSIb3DQMCAgEoMAcGBSsOAwIaMAsGCWCG
SAFlAwQCAzALBglghkgBZQMEAgIwCwYJYIZIAWUDBAIBMIGsBgsqhkiG9w0BCRACCzGBnKCBmTCB
kDELMAkGA1UEBhMCREUxGDAWBgNVBAoTD05FQyBFdXJvcGUgTHRkLjEgMB4GA1UECxMXTkVDIExh
Ym9yYXRvcmllcyBFdXJvcGUxEjAQBgNVBAMTCU5FQ0xBQi1DQTExMC8GCSqGSIb3DQEJARYiemVy
dGlmaXppZXJ1bmdzc3RlbGxlQG53Lm5lY2xhYi5ldQIED+0gWzANBgkqhkiG9w0BAQEFAASCAQBy
rrac4p3JX80Z6qPfJ21ay8IvpTKCE5R2tMB66N27WiPOsJrw1KSnMJDOVnCXvXnCfVOU2Atyl95F
DWa0upZPzXI2T8MsZHkQtnQq4fC2BvLvTMn+VBkmKxtrg3/H2IONoGUFM9YeMjVYsPupNEvNIcsi
zcx47LrHws9JC20peMje1LVMN1OV3qGmEIYl3UReT2Sn1s9/bNEhRIzQP8oyfInkupRNlV5yMXkQ
OhZnKzChZ6BaU4zFDplGD+aNju8zG2CXIPtTpX4FABfFnnmwRaVP28qlILcIRXiOrJ5oiYNF28b2
L3QdpfT3s77ZVJoyo86OaWEGTvT1q2bg7Dq1AAAAAAAA

------=_NextPart_000_00B4_01CC93CC.D3D2A2B0--

From bclaise@cisco.com  Wed Oct 26 05:19:30 2011
Return-Path: 
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 2AD8D21F8A35 for ; Wed, 26 Oct 2011 05:19:30 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.457
X-Spam-Level: 
X-Spam-Status: No, score=-2.457 tagged_above=-999 required=5 tests=[AWL=0.141,  BAYES_00=-2.599, HTML_MESSAGE=0.001]
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 G0C8EG8-+jRN for ; Wed, 26 Oct 2011 05:19:29 -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 E257F21F89BA for ; Wed, 26 Oct 2011 05:19:28 -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 p9QCJRn2000035 for ; Wed, 26 Oct 2011 14:19:27 +0200 (CEST)
Received: from [10.60.67.84] (ams-bclaise-8913.cisco.com [10.60.67.84]) by strange-brew.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id p9QCJQQ7029560 for ; Wed, 26 Oct 2011 14:19:26 +0200 (CEST)
Message-ID: <4EA7FACE.2090008@cisco.com>
Date: Wed, 26 Oct 2011 14:19:26 +0200
From: Benoit Claise 
User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1
MIME-Version: 1.0
To: "ipfix >> \"ipfix@ietf.org\"" 
References: <20111026121515.14533.22346.idtracker@ietfa.amsl.com>
In-Reply-To: <20111026121515.14533.22346.idtracker@ietfa.amsl.com>
X-Forwarded-Message-Id: <20111026121515.14533.22346.idtracker@ietfa.amsl.com>
Content-Type: multipart/alternative; boundary="------------070201050504080806050300"
Subject: [IPFIX] Fwd: New Version Notification for draft-claise-ipfix-protocol-rfc5101bis-02.txt
X-BeenThere: ipfix@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: IPFIX WG discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 26 Oct 2011 12:19:30 -0000

This is a multi-part message in MIME format.
--------------070201050504080806050300
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit

Dear all,

A new version of the 
http://tools.ietf.org/html/draft-claise-ipfix-protocol-rfc5101bis-02 has 
been posted.
What has been done is:

       * Observation Domain Id: from "the same Exporting Process" to "the
    same Exporter". See http://www.ietf.org/mail-
    archive/web/ipfix/current/msg06078.html

       * Clarified the timestamps and updated the reference from RFC1305 to
    RFC5905 (thanks to Brian)

The TO-DO list will have to be discussed face to face in Taipei

       * Resolution to the template lifetime mechanism for UDP

       * RFC2026 section 4.1.2: "The requirement for at least two
    independent and interoperable implementations applies to all of the
    options and features of the specification. In cases in which one or
    more options or features have not been demonstrated in at least two
    interoperable implementations, the specification may advance to the
    Draft Standard level only if those options or features are removed."
    The interop report from Prague is at
    http://www.ietf.org/proceedings/80/slides/ipfix-4.pdf Missing from
    this interop (and therefore, every interop):
          1. DTLS over SCTP or UDP (5101 sec. 11.1)
          2. ANY advanced template handling, withdrawal, stream
             separation, or reuse UDP template expiration (5101 sec.
             10.3.6) template withdrawals (5101 sec. 8 para 8 et seq.)
          3. SCTP export on any stream other than 0 (5101 sec 10.2.4.3)


Regards, Benoit.


-------- Original Message --------
Subject: 	New Version Notification for 
draft-claise-ipfix-protocol-rfc5101bis-02.txt
Date: 	Wed, 26 Oct 2011 05:15:15 -0700
From: 	internet-drafts@ietf.org
To: 	bclaise@cisco.com
CC: 	bclaise@cisco.com



A new version of I-D, draft-claise-ipfix-protocol-rfc5101bis-02.txt has been successfully submitted by Benoit Claise and posted to the IETF repository.

Filename:	 draft-claise-ipfix-protocol-rfc5101bis
Revision:	 02
Title:		 Specification of the IP Flow Information eXport (IPFIX) Protocol for the Exchange of IP Traffic Flow Information
Creation date:	 2011-10-26
WG ID:		 Individual Submission
Number of pages: 70

Abstract:
    This document specifies the IP Flow Information Export (IPFIX)
    protocol that serves for transmitting IP Traffic Flow information
    over the network.  In order to transmit IP Traffic Flow information
    from an Exporting Process to an information Collecting Process, a
    common representation of flow data and a standard means of
    communicating them is required.  This document describes how the
    IPFIX Data and Template Records are carried over a number of
    transport protocols from an IPFIX Exporting Process to an IPFIX
    Collecting Process.  This document obsoletes RFC 5101.




The IETF Secretariat




--------------070201050504080806050300
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: 7bit


  

    
  
  
    Dear all,

    

    A new version of the
    http://tools.ietf.org/html/draft-claise-ipfix-protocol-rfc5101bis-02
    has been posted.

    What has been done is:

    
      * Observation Domain Id: from "the same Exporting Process" to "the
   same Exporter". See http://www.ietf.org/mail-
   archive/web/ipfix/current/msg06078.html

      * Clarified the timestamps and updated the reference from RFC1305 to
   RFC5905 (thanks to Brian)

    The TO-DO list will have to be discussed face to face in Taipei

    
      * Resolution to the template lifetime mechanism for UDP

      * RFC2026 section 4.1.2: "The requirement for at least two
   independent and interoperable implementations applies to all of the
   options and features of the specification. In cases in which one or
   more options or features have not been demonstrated in at least two
   interoperable implementations, the specification may advance to the
   Draft Standard level only if those options or features are removed."
   The interop report from Prague is at
   http://www.ietf.org/proceedings/80/slides/ipfix-4.pdf Missing from
   this interop (and therefore, every interop):
         1. DTLS over SCTP or UDP (5101 sec. 11.1)
         2. ANY advanced template handling, withdrawal, stream
            separation, or reuse UDP template expiration (5101 sec.
            10.3.6) template withdrawals (5101 sec. 8 para 8 et seq.) 
         3. SCTP export on any stream other than 0 (5101 sec 10.2.4.3)

    

    Regards, Benoit.

    

    

    -------- Original Message --------
    

      
        

          Subject: 
          New Version Notification for
            draft-claise-ipfix-protocol-rfc5101bis-02.txt
        

        

          Date: 
          Wed, 26 Oct 2011 05:15:15 -0700
        

        

          From: 
          internet-drafts@ietf.org
        

        

          To: 
          bclaise@cisco.com
        

        

          CC: 
          bclaise@cisco.com
        

      
    

    

    

    
A new version of I-D, draft-claise-ipfix-protocol-rfc5101bis-02.txt has been successfully submitted by Benoit Claise and posted to the IETF repository.

Filename:	 draft-claise-ipfix-protocol-rfc5101bis
Revision:	 02
Title:		 Specification of the IP Flow Information eXport (IPFIX) Protocol for the Exchange of IP Traffic Flow Information
Creation date:	 2011-10-26
WG ID:		 Individual Submission
Number of pages: 70

Abstract:
   This document specifies the IP Flow Information Export (IPFIX)
   protocol that serves for transmitting IP Traffic Flow information
   over the network.  In order to transmit IP Traffic Flow information
   from an Exporting Process to an information Collecting Process, a
   common representation of flow data and a standard means of
   communicating them is required.  This document describes how the
   IPFIX Data and Template Records are carried over a number of
   transport protocols from an IPFIX Exporting Process to an IPFIX
   Collecting Process.  This document obsoletes RFC 5101.

                                                                                  


The IETF Secretariat




  


--------------070201050504080806050300--

From bclaise@cisco.com  Wed Oct 26 15:51:20 2011
Return-Path: 
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 048891F0C52 for ; Wed, 26 Oct 2011 15:51:20 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.478
X-Spam-Level: 
X-Spam-Status: No, score=-2.478 tagged_above=-999 required=5 tests=[AWL=0.121,  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 mf7+X1m64QWa for ; Wed, 26 Oct 2011 15:51:19 -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 485B11F0C35 for ; Wed, 26 Oct 2011 15:51:19 -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 p9QMk0pq005400 for ; Thu, 27 Oct 2011 00:46:00 +0200 (CEST)
Received: from [10.60.67.84] (ams-bclaise-8913.cisco.com [10.60.67.84]) by strange-brew.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id p9QMjxMn004189 for ; Thu, 27 Oct 2011 00:46:00 +0200 (CEST)
Message-ID: <4EA88DA7.1060006@cisco.com>
Date: Thu, 27 Oct 2011 00:45:59 +0200
From: Benoit Claise 
User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1
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-04 -> Feedback?
X-BeenThere: ipfix@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: IPFIX WG discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 26 Oct 2011 22:51:20 -0000

Dear all,

As stated during the meeting at IETF81, the authors believe that we have 
solved all the open issues regarding the "Specification of the Protocol 
for IPFIX Mediations" at
http://tools.ietf.org/html/draft-claise-ipfix-mediation-protocol-04

Please let us know if we missed something.
We still have a couple of days before the deadline.

Regards, Benoit.

From n.brownlee@auckland.ac.nz  Thu Oct 27 16:19:25 2011
Return-Path: 
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 57C6321F8564 for ; Thu, 27 Oct 2011 16:19:25 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -104.561
X-Spam-Level: 
X-Spam-Status: No, score=-104.561 tagged_above=-999 required=5 tests=[AWL=-1.962, 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 p6+Jmx3qHBw4 for ; Thu, 27 Oct 2011 16:19:24 -0700 (PDT)
Received: from mx2.auckland.ac.nz (mx2.auckland.ac.nz [130.216.12.44]) by ietfa.amsl.com (Postfix) with ESMTP id 7B62421F84DA for ; Thu, 27 Oct 2011 16:19:22 -0700 (PDT)
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=1319757564; x=1351293564; h=message-id:date:from:mime-version:to:subject: content-transfer-encoding; z=Message-ID:=20<4EA9E6F8.2050708@auckland.ac.nz>|Date:=20 Fri,=2028=20Oct=202011=2012:19:20=20+1300|From:=20Nevil =20Brownlee=20|MIME-Version: =201.0|To:=20IPFIX=20Working=20Group=20 |Subject:=20EARLY=20DRAFT=20agenda=20for=20IPFIX=20at=20T aipei=20IETF|Content-Transfer-Encoding:=207bit; bh=6D8apSipUMEmHpWd9YJVrIJ9mQLeCyzxT4bfpsJP6+k=; b=akusUmMbPwFzjWy/nEClsdV7btho3KVE6qmnJE4MXcjcK8UHOostyBik 8fW2eH9HAra5z6sGMnQXoDSGCPklWym6SMtnzKNRNpvKrqOZ7L1ZTI9lJ IYw35yRedGRQ2P8frP9FvTVUEFu3F8HfCXNv4vBVst17ujUiBD6afZE+6 o=;
X-IronPort-AV: E=Sophos;i="4.69,415,1315137600"; d="scan'208";a="87619606"
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 Oct 2011 12:19:21 +1300
Message-ID: <4EA9E6F8.2050708@auckland.ac.nz>
Date: Fri, 28 Oct 2011 12:19:20 +1300
From: Nevil Brownlee 
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1
MIME-Version: 1.0
To: IPFIX Working Group 
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Subject: [IPFIX] EARLY DRAFT agenda for IPFIX at Taipei IETF
X-BeenThere: ipfix@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: IPFIX WG discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 27 Oct 2011 23:19:25 -0000

Hi all:

A first draft of our agenda for the Taipei meeting is available
from http://www.ietf.org/proceedings/82/agenda/ipfix.txt
and is appended below.

You'll see that we plan to get started on new-charter work items, so:
  - If you'll be presenting anything, email me so  that I can
      update the agenda
  - If you're prepared to work on any of the new work items, please
      say that on the IPFIX list
  - Similarly, please say, on the list, which of the new work items
      you're prepared to review

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  Fri Oct 28 00:15:34 2011
Return-Path: 
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 892A621F8B33 for ; Fri, 28 Oct 2011 00:15:34 -0700 (PDT)
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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PwVG3pXoSeSp for ; Fri, 28 Oct 2011 00:15:33 -0700 (PDT)
Received: from smtp.ee.ethz.ch (smtp.ee.ethz.ch [129.132.2.219]) by ietfa.amsl.com (Postfix) with ESMTP id 882DB21F89BA for ; Fri, 28 Oct 2011 00:15:33 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by smtp.ee.ethz.ch (Postfix) with ESMTP id 3144BD9311; Fri, 28 Oct 2011 09:15:31 +0200 (MEST)
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 ve6CZ1Vg-Q23; Fri, 28 Oct 2011 09:15:31 +0200 (MEST)
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 D9A8FD9310; Fri, 28 Oct 2011 09:15:30 +0200 (MEST)
Mime-Version: 1.0 (Apple Message framework v1084)
Content-Type: text/plain; charset=us-ascii
From: Brian Trammell 
In-Reply-To: <4EA9E6F8.2050708@auckland.ac.nz>
Date: Fri, 28 Oct 2011 09:15:30 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: <9A357FC3-131F-4436-80D0-A4AFE8D059FC@tik.ee.ethz.ch>
References: <4EA9E6F8.2050708@auckland.ac.nz>
To: Nevil Brownlee 
X-Mailer: Apple Mail (2.1084)
Cc: IPFIX Working Group 
Subject: Re: [IPFIX] EARLY DRAFT agenda for IPFIX at Taipei IETF
X-BeenThere: ipfix@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: IPFIX WG discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 28 Oct 2011 07:15:35 -0000

Hi, Nevil, all,

I'd like to ask for 5-10 minutes somewhere to talk about what I see as a =
looming open issue in the application of structured data. Specifically, =
as defined, the generic container IEs carry no semantic information =
about their contents into the template, which breaks the very nice (if =
only implicitly intentional) property of IPFIX that a collector's =
interest in a record can be determined at the time that its template is =
parsed. Using the basicList semantic data type (as opposed to the =
basicList IE) to create new Information Elements which carry that =
information would fix this problem (i.e. creating a new =
mplsLabelStackList basicList IE that would contain mplsLabelStackSection =
IEs), but would require some new mechanism (or merely process) to ensure =
that a container's semantics matched its contents.

We can take some time from the aggregation draft, the changes to which =
are almost completely editorial, and I anticipate needing no more than =
two minutes to mention them.

Thanks,

Brian

On Oct 28, 2011, at 1:19 AM, Nevil Brownlee wrote:

>=20
> Hi all:
>=20
> A first draft of our agenda for the Taipei meeting is available
> from http://www.ietf.org/proceedings/82/agenda/ipfix.txt
> and is appended below.
>=20
> You'll see that we plan to get started on new-charter work items, so:
> - If you'll be presenting anything, email me so  that I can
>     update the agenda
> - If you're prepared to work on any of the new work items, please
>     say that on the IPFIX list
> - Similarly, please say, on the list, which of the new work items
>     you're prepared to review
>=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 bclaise@cisco.com  Fri Oct 28 00:21:31 2011
Return-Path: 
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 89AE121F8B5E for ; Fri, 28 Oct 2011 00:21:31 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.494
X-Spam-Level: 
X-Spam-Status: No, score=-2.494 tagged_above=-999 required=5 tests=[AWL=0.105,  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 66ZvtnZ8ow3u for ; Fri, 28 Oct 2011 00:21: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 8F7A021F8B59 for ; Fri, 28 Oct 2011 00:21: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 p9S7E6fB027326; Fri, 28 Oct 2011 09:14:07 +0200 (CEST)
Received: from [10.60.67.84] (ams-bclaise-8913.cisco.com [10.60.67.84]) by strange-brew.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id p9S7E4L1011804; Fri, 28 Oct 2011 09:14:05 +0200 (CEST)
Message-ID: <4EAA563B.1060205@cisco.com>
Date: Fri, 28 Oct 2011 09:14:03 +0200
From: Benoit Claise 
User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1
MIME-Version: 1.0
To: Nevil Brownlee 
References: <4EA9E6F8.2050708@auckland.ac.nz>
In-Reply-To: <4EA9E6F8.2050708@auckland.ac.nz>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Cc: IPFIX Working Group 
Subject: Re: [IPFIX] EARLY DRAFT agenda for IPFIX at Taipei IETF
X-BeenThere: ipfix@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: IPFIX WG discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 28 Oct 2011 07:21:31 -0000

Hi Nevil,

We would like to present an update of 
http://tools.ietf.org/html/draft-yourtchenko-cisco-ies-01, which will be 
posted before the deadline.

Thank you.

Regards, Benoit.
>
> Hi all:
>
> A first draft of our agenda for the Taipei meeting is available
> from http://www.ietf.org/proceedings/82/agenda/ipfix.txt
> and is appended below.
>
> You'll see that we plan to get started on new-charter work items, so:
>  - If you'll be presenting anything, email me so  that I can
>      update the agenda
>  - If you're prepared to work on any of the new work items, please
>      say that on the IPFIX list
>  - Similarly, please say, on the list, which of the new work items
>      you're prepared to review
>
> Cheers, Nevil
>


From trammell@tik.ee.ethz.ch  Fri Oct 28 01:44:18 2011
Return-Path: 
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 750A321F8A97 for ; Fri, 28 Oct 2011 01:44:18 -0700 (PDT)
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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nTk4AGVsdxs3 for ; Fri, 28 Oct 2011 01:44:18 -0700 (PDT)
Received: from smtp.ee.ethz.ch (smtp.ee.ethz.ch [129.132.2.219]) by ietfa.amsl.com (Postfix) with ESMTP id CD24921F8B02 for ; Fri, 28 Oct 2011 01:44:17 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by smtp.ee.ethz.ch (Postfix) with ESMTP id 0E1C4D9311 for ; Fri, 28 Oct 2011 10:44:17 +0200 (MEST)
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 w3lRQa9RYvpI for ; Fri, 28 Oct 2011 10:44:16 +0200 (MEST)
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 A389DD9310 for ; Fri, 28 Oct 2011 10:44:16 +0200 (MEST)
From: Brian Trammell 
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: quoted-printable
Date: Fri, 28 Oct 2011 10:44:16 +0200
References: <20111028083953.28437.90234.idtracker@ietfa.amsl.com>
To: IPFIX Working Group 
Message-Id: <0F3102E9-838B-4828-86B6-2A1F4834DC2C@tik.ee.ethz.ch>
Mime-Version: 1.0 (Apple Message framework v1084)
X-Mailer: Apple Mail (2.1084)
Subject: [IPFIX] Fwd: New Version Notification for draft-trammell-ipfix-ie-doctors-03.txt
X-BeenThere: ipfix@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: IPFIX WG discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 28 Oct 2011 08:44:18 -0000

Greetings, all,

A new version of the IE-Doctors draft has been posted; this adds a new =
section on avoiding bad precedents in the registry when designing new =
IEs,  and more clearly separates the discussion on internal IE structure =
and IE multiplicity.

Before an ietf-00, we'll want to expand the "bad ideas" section to have =
a specific list of Information Elements which in one way or another =
violate the IE-DOCTORS rules and as such should be ignored when applying =
the general rule "make new IEs that look like old IEs."

Best regards,

Brian

Begin forwarded message:

> From: internet-drafts@ietf.org
> Date: October 28, 2011 10:39:53 AM GMT+02:00
> To: trammell@tik.ee.ethz.ch
> Cc: bclaise@cisco.com, trammell@tik.ee.ethz.ch
> Subject: New Version Notification for =
draft-trammell-ipfix-ie-doctors-03.txt
>=20
> A new version of I-D, draft-trammell-ipfix-ie-doctors-03.txt has been =
successfully submitted by Brian Trammell and posted to the IETF =
repository.
>=20
> Filename:	 draft-trammell-ipfix-ie-doctors
> Revision:	 03
> Title:		 Guidelines for Authors and Reviewers of IPFIX =
Information Elements
> Creation date:	 2011-10-28
> WG ID:		 Individual Submission
> Number of pages: 28
>=20
> Abstract:
>   This document provides guidelines for the definition of IPFIX
>   Information Elements for addition to the IANA IPFIX Information
>   Element registry, in order to extend the applicability of the IPFIX
>   protocol to new operations and management areas.
>=20
>=20
>=20
>=20
> The IETF Secretariat


From bclaise@cisco.com  Sat Oct 29 09:31:00 2011
Return-Path: 
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 686B221F84DC for ; Sat, 29 Oct 2011 09:31:00 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.506
X-Spam-Level: 
X-Spam-Status: No, score=-2.506 tagged_above=-999 required=5 tests=[AWL=0.092,  BAYES_00=-2.599, HTML_MESSAGE=0.001]
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 cRLLJISp5e8K for ; Sat, 29 Oct 2011 09:30:59 -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 D272F21F84FD for ; Sat, 29 Oct 2011 09:30:52 -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 p9TGUote015200; Sat, 29 Oct 2011 18:30:50 +0200 (CEST)
Received: from [10.60.67.84] (ams-bclaise-8913.cisco.com [10.60.67.84]) by strange-brew.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id p9TGUlgJ010227; Sat, 29 Oct 2011 18:30:47 +0200 (CEST)
Message-ID: <4EAC2A36.30803@cisco.com>
Date: Sat, 29 Oct 2011 18:30:46 +0200
From: Benoit Claise 
User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1
MIME-Version: 1.0
To: "ipfix@ietf.org" 
References: <20111029162843.16699.94292.idtracker@ietfa.amsl.com>
In-Reply-To: <20111029162843.16699.94292.idtracker@ietfa.amsl.com>
X-Forwarded-Message-Id: <20111029162843.16699.94292.idtracker@ietfa.amsl.com>
Content-Type: multipart/alternative; boundary="------------060508020401090302050200"
Cc: draft-claise-ipfix-information-model-rfc5102bis@tools.ietf.org
Subject: [IPFIX] Fwd: New Version Notification for draft-claise-ipfix-information-model-rfc5102bis-01.txt
X-BeenThere: ipfix@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: IPFIX WG discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sat, 29 Oct 2011 16:31:00 -0000

This is a multi-part message in MIME format.
--------------060508020401090302050200
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit

Dear all,

Here is an update of draft-claise-ipfix-information-model-rfc5102bis.
The primary update is a resolution for the time-related IEs. Please 
double-check this.
Also the "open issues" list has been updated with some new ones, to be 
discussed in Taipei.

Regards, Benoit.

-------- Original Message --------
Subject: 	New Version Notification for 
draft-claise-ipfix-information-model-rfc5102bis-01.txt
Date: 	Sat, 29 Oct 2011 09:28:43 -0700
From: 	internet-drafts@ietf.org
To: 	bclaise@cisco.com
CC: 	bclaise@cisco.com, stbryant@cisco.com, jemeyer@paypal.com, 
paitken@cisco.com, quittek@nw.neclab.eu



A new version of I-D, draft-claise-ipfix-information-model-rfc5102bis-01.txt has been successfully submitted by Benoit Claise and posted to the IETF repository.

Filename:	 draft-claise-ipfix-information-model-rfc5102bis
Revision:	 01
Title:		 Information Model for IP Flow Information eXport (IPFIX)
Creation date:	 2011-10-28
WG ID:		 Individual Submission
Number of pages: 174

Abstract:
This memo defines an information model for the IP Flow Information
eXport (IPFIX) protocol.  It is used by the IPFIX protocol for encoding
measured traffic information and information related to the traffic
Observation Point, the traffic Metering Process, and the Exporting
Process.  Although developed for the IPFIX protocol, the model is
defined in an open way that easily allows using it in other protocols,
interfaces, and applications.  This document obsoletes RFC 5102.




The IETF Secretariat




--------------060508020401090302050200
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: 7bit


  

    
  
  
    Dear all,

    

    Here is an update of
    draft-claise-ipfix-information-model-rfc5102bis.

    The primary update is a resolution for the time-related IEs. Please
    double-check this.

    Also the "open issues" list has been updated with some new ones, to
    be discussed in Taipei.

    

    Regards, Benoit.

    

    -------- Original Message --------
    

      
        

          Subject: 
          New Version Notification for
            draft-claise-ipfix-information-model-rfc5102bis-01.txt
        

        

          Date: 
          Sat, 29 Oct 2011 09:28:43 -0700
        

        

          From: 
          internet-drafts@ietf.org
        

        

          To: 
          bclaise@cisco.com
        

        

          CC: 
          bclaise@cisco.com, stbryant@cisco.com, jemeyer@paypal.com,
            paitken@cisco.com, quittek@nw.neclab.eu
        

      
    

    

    

    
A new version of I-D, draft-claise-ipfix-information-model-rfc5102bis-01.txt has been successfully submitted by Benoit Claise and posted to the IETF repository.

Filename:	 draft-claise-ipfix-information-model-rfc5102bis
Revision:	 01
Title:		 Information Model for IP Flow Information eXport (IPFIX)
Creation date:	 2011-10-28
WG ID:		 Individual Submission
Number of pages: 174

Abstract:
This memo defines an information model for the IP Flow Information
eXport (IPFIX) protocol.  It is used by the IPFIX protocol for encoding
measured traffic information and information related to the traffic
Observation Point, the traffic Metering Process, and the Exporting
Process.  Although developed for the IPFIX protocol, the model is
defined in an open way that easily allows using it in other protocols,
interfaces, and applications.  This document obsoletes RFC 5102.

                                                                                  


The IETF Secretariat




  


--------------060508020401090302050200--

From bclaise@cisco.com  Sun Oct 30 16:35:31 2011
Return-Path: 
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 67C7C1F0C42 for ; Sun, 30 Oct 2011 16:35:31 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.509
X-Spam-Level: 
X-Spam-Status: No, score=-2.509 tagged_above=-999 required=5 tests=[AWL=0.089,  BAYES_00=-2.599, HTML_MESSAGE=0.001]
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 gwVkPy+9pqMD for ; Sun, 30 Oct 2011 16:35: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 9EBD41F0C3E for ; Sun, 30 Oct 2011 16:35: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 p9UNZQax001529; Mon, 31 Oct 2011 00:35:26 +0100 (CET)
Received: from [10.60.67.88] (ams-bclaise-8917.cisco.com [10.60.67.88]) by strange-brew.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id p9UNZLax029563; Mon, 31 Oct 2011 00:35:21 +0100 (CET)
Message-ID: <4EADDF39.7050008@cisco.com>
Date: Mon, 31 Oct 2011 00:35:21 +0100
From: Benoit Claise 
User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1
MIME-Version: 1.0
To: "ipfix@ietf.org" 
References: <20111030232936.5134.34000.idtracker@ietfa.amsl.com>
In-Reply-To: <20111030232936.5134.34000.idtracker@ietfa.amsl.com>
X-Forwarded-Message-Id: <20111030232936.5134.34000.idtracker@ietfa.amsl.com>
Content-Type: multipart/alternative; boundary="------------010602000808010708070405"
Subject: [IPFIX] Fwd: New Version Notification for draft-claise-export-application-info-in-ipfix-03.txt
X-BeenThere: ipfix@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: IPFIX WG discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sun, 30 Oct 2011 23:35:31 -0000

This is a multi-part message in MIME format.
--------------010602000808010708070405
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit

Dear all, Dan

A new version of this draft has been posted.
See 
http://tools.ietf.org/html/draft-claise-export-application-info-in-ipfix-03
This is basically a clean up of the previous version.

Dan,
We would like to request an AD sponsored individual submission for this 
draft, if possible.

Regards, Paul, Nir, and Benoit.

-------- Original Message --------
Subject: 	New Version Notification for 
draft-claise-export-application-info-in-ipfix-03.txt
Date: 	Sun, 30 Oct 2011 16:29:36 -0700
From: 	internet-drafts@ietf.org
To: 	bclaise@cisco.com
CC: 	bclaise@cisco.com, paitken@cisco.com, nirbd@cisco.com



A new version of I-D, draft-claise-export-application-info-in-ipfix-03.txt has been successfully submitted by Benoit Claise and posted to the IETF repository.

Filename:	 draft-claise-export-application-info-in-ipfix
Revision:	 03
Title:		 Export of Application Information in IPFIX
Creation date:	 2011-10-30
WG ID:		 Individual Submission
Number of pages: 33

Abstract:
         This document specifies an extension to the IPFIX information
         model specified in [RFC5102] to export application information.






The IETF Secretariat




--------------010602000808010708070405
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: 7bit


  

    
  
  
    Dear all, Dan

    

    A new version of this draft has been posted.

    See
http://tools.ietf.org/html/draft-claise-export-application-info-in-ipfix-03

    This is basically a clean up of the previous version.

    

    Dan, 

    We would like to request an AD sponsored individual submission for
    this draft, if possible.

    

    Regards, Paul, Nir, and Benoit.

    

    -------- Original Message --------
    

      
        

          Subject: 
          New Version Notification for
            draft-claise-export-application-info-in-ipfix-03.txt
        

        

          Date: 
          Sun, 30 Oct 2011 16:29:36 -0700
        

        

          From: 
          internet-drafts@ietf.org
        

        

          To: 
          bclaise@cisco.com
        

        

          CC: 
          bclaise@cisco.com, paitken@cisco.com, nirbd@cisco.com
        

      
    

    

    

    
A new version of I-D, draft-claise-export-application-info-in-ipfix-03.txt has been successfully submitted by Benoit Claise and posted to the IETF repository.

Filename:	 draft-claise-export-application-info-in-ipfix
Revision:	 03
Title:		 Export of Application Information in IPFIX
Creation date:	 2011-10-30
WG ID:		 Individual Submission
Number of pages: 33

Abstract:
        This document specifies an extension to the IPFIX information
        model specified in [RFC5102] to export application information.


     
                                                                                  


The IETF Secretariat




  


--------------010602000808010708070405--

From bclaise@cisco.com  Sun Oct 30 16:42:14 2011
Return-Path: 
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 84E3C11E808B for ; Sun, 30 Oct 2011 16:42:14 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.513
X-Spam-Level: 
X-Spam-Status: No, score=-2.513 tagged_above=-999 required=5 tests=[AWL=0.086,  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 T1TOgGmGNwyB for ; Sun, 30 Oct 2011 16:42:14 -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 D193711E808A for ; Sun, 30 Oct 2011 16:42:13 -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 p9UNg3fI002086; Mon, 31 Oct 2011 00:42:03 +0100 (CET)
Received: from [10.60.67.88] (ams-bclaise-8917.cisco.com [10.60.67.88]) by strange-brew.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id p9UNg0m9001743; Mon, 31 Oct 2011 00:42:01 +0100 (CET)
Message-ID: <4EADE0C8.1080602@cisco.com>
Date: Mon, 31 Oct 2011 00:42:00 +0100
From: Benoit Claise 
User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1
MIME-Version: 1.0
To: Nevil Brownlee 
References: <4EA9E6F8.2050708@auckland.ac.nz>
In-Reply-To: <4EA9E6F8.2050708@auckland.ac.nz>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Cc: IPFIX Working Group 
Subject: Re: [IPFIX] EARLY DRAFT agenda for IPFIX at Taipei IETF
X-BeenThere: ipfix@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: IPFIX WG discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sun, 30 Oct 2011 23:42:14 -0000

Hi Nevil,

I would like to present 
http://tools.ietf.org/html/draft-claise-export-application-info-in-ipfix-03

Regards, Benoit.
>
> Hi all:
>
> A first draft of our agenda for the Taipei meeting is available
> from http://www.ietf.org/proceedings/82/agenda/ipfix.txt
> and is appended below.
>
> You'll see that we plan to get started on new-charter work items, so:
>  - If you'll be presenting anything, email me so  that I can
>      update the agenda
>  - If you're prepared to work on any of the new work items, please
>      say that on the IPFIX list
>  - Similarly, please say, on the list, which of the new work items
>      you're prepared to review
>
> Cheers, Nevil
>


From internet-drafts@ietf.org  Mon Oct 31 05:06:32 2011
Return-Path: 
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 8B3BF21F8DEE; Mon, 31 Oct 2011 05:06:32 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.563
X-Spam-Level: 
X-Spam-Status: No, score=-102.563 tagged_above=-999 required=5 tests=[AWL=0.036, 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 6OUhnPElu2X3; Mon, 31 Oct 2011 05:06:32 -0700 (PDT)
Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2098121F8DE8; Mon, 31 Oct 2011 05:06:32 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
From: internet-drafts@ietf.org
To: i-d-announce@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 3.62
Message-ID: <20111031120632.22153.51492.idtracker@ietfa.amsl.com>
Date: Mon, 31 Oct 2011 05:06:32 -0700
Cc: ipfix@ietf.org
Subject: [IPFIX] I-D Action: draft-ietf-ipfix-psamp-mib-04.txt
X-BeenThere: ipfix@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: IPFIX WG discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 31 Oct 2011 12:06:32 -0000

A New Internet-Draft is available from the on-line Internet-Drafts director=
ies. This draft is a work item of the IP Flow Information Export Working Gr=
oup of the IETF.

	Title           : Definitions of Managed Objects for Packet Sampling
	Author(s)       : Thomas Dietz
                          Benoit Claise
                          Juergen Quittek
	Filename        : draft-ietf-ipfix-psamp-mib-04.txt
	Pages           : 28
	Date            : 2011-10-31

   This memo defines a portion of the Management Information Base (MIB)
   for use with network management protocols in the Internet community.
   In particular, it describes extensions to the IPFIX SELECTOR MIB
   module [I-D.dkcm-ipfix-rfc5815bis].  For IPFIX implementations that
   use packet Sampling (PSAMP) techniques as described in [RFC5475],
   this memo defines the PSAMP MIB module containing managed objects for
   providing information on applied packet selection functions and their
   parameters.


A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-ipfix-psamp-mib-04.txt

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

This Internet-Draft can be retrieved at:
ftp://ftp.ietf.org/internet-drafts/draft-ietf-ipfix-psamp-mib-04.txt

From Thomas.Dietz@neclab.eu  Mon Oct 31 05:11:05 2011
Return-Path: 
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 0D5FB21F86A4 for ; Mon, 31 Oct 2011 05:11:05 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level: 
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YYNo3VZ7i6tV for ; Mon, 31 Oct 2011 05:11:04 -0700 (PDT)
Received: from mailer1.neclab.eu (mailer1.neclab.eu [195.37.70.40]) by ietfa.amsl.com (Postfix) with ESMTP id 1207721F8532 for ; Mon, 31 Oct 2011 05:11:04 -0700 (PDT)
Received: from localhost (localhost.localdomain [127.0.0.1]) by mailer1.neclab.eu (Postfix) with ESMTP id DB46128000102 for ; Mon, 31 Oct 2011 13:11:38 +0100 (CET)
X-Virus-Scanned: Amavisd on Debian GNU/Linux (netlab.nec.de)
Received: from mailer1.neclab.eu ([127.0.0.1]) by localhost (atlas1.office.hd [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6oqoThW7s-VA for ; Mon, 31 Oct 2011 13:11:38 +0100 (CET)
Received: from METHONE.office.hd (Methone.office.hd [192.168.24.54]) by mailer1.neclab.eu (Postfix) with ESMTP id AF2AA28000101 for ; Mon, 31 Oct 2011 13:11:33 +0100 (CET)
Received: from PALLENE.office.hd ([169.254.1.17]) by METHONE.office.hd ([192.168.24.54]) with mapi id 14.01.0323.003; Mon, 31 Oct 2011 13:10:58 +0100
From: Thomas Dietz 
To: "ipfix@ietf.org" 
Thread-Topic: [IPFIX] I-D Action: draft-ietf-ipfix-psamp-mib-04.txt
Thread-Index: AQHMl8WpGXtoF23Rck23QiJXKea6k5WWW+zw
Date: Mon, 31 Oct 2011 12:10:57 +0000
Message-ID: <75581E268A48F849916117B977D76D3734C0DFE7@PALLENE.office.hd>
References: <20111031120632.22153.51492.idtracker@ietfa.amsl.com>
In-Reply-To: <20111031120632.22153.51492.idtracker@ietfa.amsl.com>
Accept-Language: en-US, de-DE
Content-Language: en-US
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator: 
x-originating-ip: [10.1.1.137]
Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_0032_01CC97CE.86B640D0"
MIME-Version: 1.0
Subject: Re: [IPFIX] I-D Action: draft-ietf-ipfix-psamp-mib-04.txt
X-BeenThere: ipfix@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: IPFIX WG discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 31 Oct 2011 12:11:05 -0000

------=_NextPart_000_0032_01CC97CE.86B640D0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit

Dear all,

I just submitted a new version of the PSAMP MIB draft. It now refers to the
new rfc5815bis draft I submitted recently for registering new selector
functions. This should be the final change for this draft. Please check
carefully and send your comments.

Best Regards,

Thomas

-- 
Thomas Dietz
NEC Europe Ltd., NEC Laboratories, Network Research Division, 69115
Heidelberg, Germany

NEC Europe Limited, Registered in England 2832014
Registered Office: NEC House, 1 Victoria Road, London W3 6BL


> -----Original Message-----
> From: ipfix-bounces@ietf.org [mailto:ipfix-bounces@ietf.org] On Behalf Of
> internet-drafts@ietf.org
> Sent: Monday, October 31, 2011 1:07 PM
> To: i-d-announce@ietf.org
> Cc: ipfix@ietf.org
> Subject: [IPFIX] I-D Action: draft-ietf-ipfix-psamp-mib-04.txt
> 
> A New Internet-Draft is available from the on-line Internet-Drafts
> directories. This draft is a work item of the IP Flow Information Export
> Working Group of the IETF.
> 
> 	Title           : Definitions of Managed Objects for Packet Sampling
> 	Author(s)       : Thomas Dietz
>                           Benoit Claise
>                           Juergen Quittek
> 	Filename        : draft-ietf-ipfix-psamp-mib-04.txt
> 	Pages           : 28
> 	Date            : 2011-10-31
> 
>    This memo defines a portion of the Management Information Base (MIB)
>    for use with network management protocols in the Internet community.
>    In particular, it describes extensions to the IPFIX SELECTOR MIB
>    module [I-D.dkcm-ipfix-rfc5815bis].  For IPFIX implementations that
>    use packet Sampling (PSAMP) techniques as described in [RFC5475],
>    this memo defines the PSAMP MIB module containing managed objects for
>    providing information on applied packet selection functions and their
>    parameters.
> 
> 
> A URL for this Internet-Draft is:
> http://www.ietf.org/internet-drafts/draft-ietf-ipfix-psamp-mib-04.txt
> 
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/
> 
> This Internet-Draft can be retrieved at:
> ftp://ftp.ietf.org/internet-drafts/draft-ietf-ipfix-psamp-mib-04.txt
> _______________________________________________
> IPFIX mailing list
> IPFIX@ietf.org
> https://www.ietf.org/mailman/listinfo/ipfix

------=_NextPart_000_0032_01CC97CE.86B640D0
Content-Type: application/pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIISNDCCA58w
ggKHoAMCAQICASYwDQYJKoZIhvcNAQEFBQAwcTELMAkGA1UEBhMCREUxHDAaBgNVBAoTE0RldXRz
Y2hlIFRlbGVrb20gQUcxHzAdBgNVBAsTFlQtVGVsZVNlYyBUcnVzdCBDZW50ZXIxIzAhBgNVBAMT
GkRldXRzY2hlIFRlbGVrb20gUm9vdCBDQSAyMB4XDTk5MDcwOTEyMTEwMFoXDTE5MDcwOTIzNTkw
MFowcTELMAkGA1UEBhMCREUxHDAaBgNVBAoTE0RldXRzY2hlIFRlbGVrb20gQUcxHzAdBgNVBAsT
FlQtVGVsZVNlYyBUcnVzdCBDZW50ZXIxIzAhBgNVBAMTGkRldXRzY2hlIFRlbGVrb20gUm9vdCBD
QSAyMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAqwujNeCLKRSxFIWvPBDkOW81XUqu
3ephjZVJ9G9koxpgZqSpQCKE2dSl5XiTDmgBrblNXDrO07ioQkDfz6O6gllqkhusHJraCCslJ/lp
I0fx4Ossepv1EwLQfjR8wp48AFmr9doM9TI8K6xQ2tbD3oOUyqgMmTIOCEhWW2r72uFYWAFJX3JB
PBUGAY5draq4k7TNnuun6GotUjTbOu9cdVHa2/Mx+e5xmDLEVBVEDPmbVe2t3xgIoKOGiknuUwWP
GUzV3lh5m9JqHEKrxdWnz2gPluThYZh2YciRfNY+AOKRUIfhnQrmrZfSHcY6fcu82gM01Y5bAfVq
B7cWtm5KfwIDAQABo0IwQDAdBgNVHQ4EFgQUMcN5G7r1U9cX4Il6LRdsCrMrnTMwDwYDVR0TBAgw
BgEB/wIBBTAOBgNVHQ8BAf8EBAMCAQYwDQYJKoZIhvcNAQEFBQADggEBAJRkWa05ZOcp6xP+WsOL
E1fIBCTwdHfAYONn++mJpoO/loJ8btTDPe+egG67KbSYerE7VOs5F0d+Go4L/B8xWTEEss4X8yzH
YjZV4iLYiVW0mEiqZPrWHDbYRHhaWiM6V5f1ejBPrp9qTEsrjqAD4z7gqdTSe9KzqOJyPK2e/4BZ
5JtFtPY7sM05GZgy5eohYZDkMSGONLH3LzVKhRDa54o3Ib5ZY+DyhYgxU9RUFIVwefQuBncndS8f
uIr5/sW62Dbkg+znZbe/Y1rzRq+BlDfUQYzWI9Yez/VoG0Rjolq6pzVZoeVwBZsOI1eZlAptujlj
KIaS8xiE2PvRzwVWZFcwggQhMIIDCaADAgECAgIAxzANBgkqhkiG9w0BAQUFADBxMQswCQYDVQQG
EwJERTEcMBoGA1UEChMTRGV1dHNjaGUgVGVsZWtvbSBBRzEfMB0GA1UECxMWVC1UZWxlU2VjIFRy
dXN0IENlbnRlcjEjMCEGA1UEAxMaRGV1dHNjaGUgVGVsZWtvbSBSb290IENBIDIwHhcNMDYxMjE5
MTAyOTAwWhcNMTkwNjMwMjM1OTAwWjBaMQswCQYDVQQGEwJERTETMBEGA1UEChMKREZOLVZlcmVp
bjEQMA4GA1UECxMHREZOLVBLSTEkMCIGA1UEAxMbREZOLVZlcmVpbiBQQ0EgR2xvYmFsIC0gRzAx
MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA6ZvDZ4X5Da71jVTDllA1PWLpbkztlNcA
W5UidNQg6zSP1uzAMQQLmYHiphTSUqAoI4SLdIkEXlvg4njBeMsWyyg1OXstkEXQ7aAAeny/Sg4b
AMOG6VwrMRF7DPOCJEOMHDiLamgAmu7cT3ir0sYTm3at7t4m6O8Br3QPwQmi9mvOvdPNFDBP9eXj
pMhim4IaAycwDQJlYE3t0QkjKpY1WCfTdsZxtpAdxO3/NYZ9bzOz2w/FEcKKg6GUXUFr2NIQ9Uz9
ylGs2b3vkoO72uuLFlZWQ8/h1RM9ph8nMM1JVNvJEzSacXXFbOqnC5j5IZ0nrz6jOTlIaoytyZn7
wxLyvQIDAQABo4HZMIHWMHAGA1UdHwRpMGcwZaBjoGGGX2h0dHA6Ly9wa2kudGVsZXNlYy5kZS9j
Z2ktYmluL3NlcnZpY2UvYWZfRG93bmxvYWRBUkwuY3JsPy1jcmxfZm9ybWF0PVhfNTA5Ji1pc3N1
ZXI9RFRfUk9PVF9DQV8yMB0GA1UdDgQWBBRJt8bP6D0ff+pEexMp9/EKcD7eZDAfBgNVHSMEGDAW
gBQxw3kbuvVT1xfgiXotF2wKsyudMzAOBgNVHQ8BAf8EBAMCAQYwEgYDVR0TAQH/BAgwBgEB/wIB
AjANBgkqhkiG9w0BAQUFAAOCAQEAO+Fad8BIF9ypGOyBr1qJ8L0okqbKWRgScOwo8ueuf5Ys5/Jd
GTH2Eyt0vb2Asrn3Z8k5onk74RER7mt4kTN+O18mJ3VTZY4zY+7Pc8OwkiNJIVB1I6EfGOKUhT0/
M+l3II2iveahhSlA9j9zMlgNCWum2oVswD+7jWZkViROrg0/MjUBW+mMgtlyWU+xhoXxdIVW5cP4
XPON7kezUwVw5+VNimmDKOETCYaeXsjqWB4MH/mk1FoEaP0oPosCtli19qEsN1cAZ6sjaI1jpe+Z
a1z9S1b2q0CHNNQRkmzsh8UKCwczcrRvDB1ULNhRx8y/MNNDcvEyv4zOSWOoAPfyHDCCBS8wggQX
oAMCAQICBA0hCkcwDQYJKoZIhvcNAQEFBQAwWjELMAkGA1UEBhMCREUxEzARBgNVBAoTCkRGTi1W
ZXJlaW4xEDAOBgNVBAsTB0RGTi1QS0kxJDAiBgNVBAMTG0RGTi1WZXJlaW4gUENBIEdsb2JhbCAt
IEcwMTAeFw0wODEwMjQwODUyMDhaFw0xOTA2MzAwMDAwMDBaMIGQMQswCQYDVQQGEwJERTEYMBYG
A1UEChMPTkVDIEV1cm9wZSBMdGQuMSAwHgYDVQQLExdORUMgTGFib3JhdG9yaWVzIEV1cm9wZTES
MBAGA1UEAxMJTkVDTEFCLUNBMTEwLwYJKoZIhvcNAQkBFiJ6ZXJ0aWZpemllcnVuZ3NzdGVsbGVA
bncubmVjbGFiLmV1MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAnvIVsbURqjIOcbnf
ruYkRceWOZpyvM2ebnYpbd1cP+zdWm6yR7HSO9ppOe1ZZFIasArqQpedPEFvcncSG94FRuW3ND4r
Rcq08mbpUTmpWmXfdYlJpQezbsOHCWR74NXoEEbK6TPZIMFpJr6dzQDAxnRc7UOgO6JQ1V42Z39B
PhIbPIWz64t8svafxbORmxulJn7F5zDLDcR1AEGyn+L9b645AGwapoKNh7cSQFTqdb6kGyPQjLWf
tv09dvmBDKesrcyLZXuDWJ1LMeizSjUEygdSszNXD3gePgJaVaZDS3o923W5gAyPCTSxpAFj8XJ+
/7Ap5jJwYhjJgJ8khFR7JQIDAQABo4IBxDCCAcAwEgYDVR0TAQH/BAgwBgEB/wIBATALBgNVHQ8E
BAMCAQYwHQYDVR0OBBYEFE8ch3od4C+Z9r4VqtE1nQ5K5ro2MB8GA1UdIwQYMBaAFEm3xs/oPR9/
6kR7Eyn38QpwPt5kMC0GA1UdEQQmMCSBInplcnRpZml6aWVydW5nc3N0ZWxsZUBudy5uZWNsYWIu
ZXUwgYgGA1UdHwSBgDB+MD2gO6A5hjdodHRwOi8vY2RwMS5wY2EuZGZuLmRlL2dsb2JhbC1yb290
LWNhL3B1Yi9jcmwvY2FjcmwuY3JsMD2gO6A5hjdodHRwOi8vY2RwMi5wY2EuZGZuLmRlL2dsb2Jh
bC1yb290LWNhL3B1Yi9jcmwvY2FjcmwuY3JsMIGiBggrBgEFBQcBAQSBlTCBkjBHBggrBgEFBQcw
AoY7aHR0cDovL2NkcDEucGNhLmRmbi5kZS9nbG9iYWwtcm9vdC1jYS9wdWIvY2FjZXJ0L2NhY2Vy
dC5jcnQwRwYIKwYBBQUHMAKGO2h0dHA6Ly9jZHAyLnBjYS5kZm4uZGUvZ2xvYmFsLXJvb3QtY2Ev
cHViL2NhY2VydC9jYWNlcnQuY3J0MA0GCSqGSIb3DQEBBQUAA4IBAQBsMQ+dD0mmi48dgDU4R6Q/
eXcY0zQcHNp1Vu1s3kwO0WahWB0tiqVBodvfTAWG44xuw0I7NXSTwQ68FU5P0GIQnvRFZyVJlDjr
SNlLYxjqfmgb+KVm67o383cZIuDakEE0f29kULIEn2fg/HsDiBAXTsb4I19XaN0TXLI+PMhU+GDp
sGCJrydeugEV7qi15q8yymjSAsYgnrc2wJuXpyQ9r3qCtP6aedAPSHqOT8ga1dLT2YRZFs3vNm7T
HSr5JJymWMbfpD6OcbRTnNAjSMDHwJxgRBAflA6WzDVm7fk4jiWyLvJwWTMk19t8QLiKG7D0nYvj
cEUYyiOSE+SFUTEdMIIFNTCCBB2gAwIBAgIED+0gWzANBgkqhkiG9w0BAQUFADCBkDELMAkGA1UE
BhMCREUxGDAWBgNVBAoTD05FQyBFdXJvcGUgTHRkLjEgMB4GA1UECxMXTkVDIExhYm9yYXRvcmll
cyBFdXJvcGUxEjAQBgNVBAMTCU5FQ0xBQi1DQTExMC8GCSqGSIb3DQEJARYiemVydGlmaXppZXJ1
bmdzc3RlbGxlQG53Lm5lY2xhYi5ldTAeFw0xMDA0MjAxMjQ5MTVaFw0xMzA0MTkxMjQ5MTVaMGAx
CzAJBgNVBAYTAkRFMRgwFgYDVQQKEw9ORUMgRXVyb3BlIEx0ZC4xIDAeBgNVBAsTF05FQyBMYWJv
cmF0b3JpZXMgRXVyb3BlMRUwEwYDVQQDEwxUaG9tYXMgRGlldHowggEiMA0GCSqGSIb3DQEBAQUA
A4IBDwAwggEKAoIBAQD2mMcvPbgraEaWMV6uNCs6t88lhBczgfxybD46mwr8D3VaQLEnqTsBOAf/
Y8ARtq+P6Dkm2MBMXQG+Ebo2qhif6O4dH7whcG9E88F9247R2EJjcXmxMYZWYGQTI2vGw/joerRB
waiwfxCXWBTLutbdWEEKL/DG9A1yQRPGJc+jJYfgm0ekYn+WESOLYaBH7G9aIIZQ7en3afhPpbQA
Ajh92K240TG+VgBpe1vnDdth28Ps5XeN+otookDZHwwGQYwYrPZJtnhGIyjKMm7OkXL62Rf3aSoI
doVUwYYS67RYYNOY0C7qOVyCUF+z4Bkn758sZhZzotiLQVT3AZ625PrvAgMBAAGjggHEMIIBwDAJ
BgNVHRMEAjAAMAsGA1UdDwQEAwIF4DApBgNVHSUEIjAgBggrBgEFBQcDAgYIKwYBBQUHAwQGCisG
AQQBgjcUAgIwHQYDVR0OBBYEFH9fxgi2EshupgLF49SzaAX0QFoMMB8GA1UdIwQYMBaAFE8ch3od
4C+Z9r4VqtE1nQ5K5ro2MCEGA1UdEQQaMBiBFlRob21hcy5EaWV0ekBuZWNsYWIuZXUwfQYDVR0f
BHYwdDA4oDagNIYyaHR0cDovL2NkcDEucGNhLmRmbi5kZS9uZWNsYWItY2EvcHViL2NybC9jYWNy
bC5jcmwwOKA2oDSGMmh0dHA6Ly9jZHAyLnBjYS5kZm4uZGUvbmVjbGFiLWNhL3B1Yi9jcmwvY2Fj
cmwuY3JsMIGYBggrBgEFBQcBAQSBizCBiDBCBggrBgEFBQcwAoY2aHR0cDovL2NkcDEucGNhLmRm
bi5kZS9uZWNsYWItY2EvcHViL2NhY2VydC9jYWNlcnQuY3J0MEIGCCsGAQUFBzAChjZodHRwOi8v
Y2RwMi5wY2EuZGZuLmRlL25lY2xhYi1jYS9wdWIvY2FjZXJ0L2NhY2VydC5jcnQwDQYJKoZIhvcN
AQEFBQADggEBACnPHI1mIY1TVY9Aj8zsHHxiwMRx02Hp6DLZGYXHGG9IkflrRKNiDIV2LbBDpXVH
vojMxTtCt10iwbyVMGaevet/VHYCJSHzrCLkw+GkvuhDU70lNsWw9P+mai7OHa+NQ6im8+4RnY1B
yhqidcCt3hIV9B69ax0/KIhIFpiWz/lKZVIghki07I4m8mf1sbvCORKxudH0TVLlRJlX1r8S+8ea
9e+Q8pgXfrsCeyxBV3KAjszRQkqDZsbD7jQHQWokkMPIjbaTjw6V/5SRzmcAy0XlKNOCbldlzmCB
jDZTQWdSH/AFDy5L2l4j0Ck0vVlQv+r1F4omsb4BelRq+vHd+lExggQsMIIEKAIBATCBmTCBkDEL
MAkGA1UEBhMCREUxGDAWBgNVBAoTD05FQyBFdXJvcGUgTHRkLjEgMB4GA1UECxMXTkVDIExhYm9y
YXRvcmllcyBFdXJvcGUxEjAQBgNVBAMTCU5FQ0xBQi1DQTExMC8GCSqGSIb3DQEJARYiemVydGlm
aXppZXJ1bmdzc3RlbGxlQG53Lm5lY2xhYi5ldQIED+0gWzAJBgUrDgMCGgUAoIICZzAYBgkqhkiG
9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xMTEwMzExMjEwNTZaMCMGCSqGSIb3
DQEJBDEWBBTDiBaN9yOlojtnFa9nx6hsYt51NTCBqgYJKwYBBAGCNxAEMYGcMIGZMIGQMQswCQYD
VQQGEwJERTEYMBYGA1UEChMPTkVDIEV1cm9wZSBMdGQuMSAwHgYDVQQLExdORUMgTGFib3JhdG9y
aWVzIEV1cm9wZTESMBAGA1UEAxMJTkVDTEFCLUNBMTEwLwYJKoZIhvcNAQkBFiJ6ZXJ0aWZpemll
cnVuZ3NzdGVsbGVAbncubmVjbGFiLmV1AgQP7SBbMIGrBgkqhkiG9w0BCQ8xgZ0wgZowCwYJYIZI
AWUDBAEqMAsGCWCGSAFlAwQBFjAKBggqhkiG9w0DBzALBglghkgBZQMEAQIwDgYIKoZIhvcNAwIC
AgCAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgFAMA0GCCqGSIb3DQMCAgEoMAcGBSsOAwIaMAsGCWCG
SAFlAwQCAzALBglghkgBZQMEAgIwCwYJYIZIAWUDBAIBMIGsBgsqhkiG9w0BCRACCzGBnKCBmTCB
kDELMAkGA1UEBhMCREUxGDAWBgNVBAoTD05FQyBFdXJvcGUgTHRkLjEgMB4GA1UECxMXTkVDIExh
Ym9yYXRvcmllcyBFdXJvcGUxEjAQBgNVBAMTCU5FQ0xBQi1DQTExMC8GCSqGSIb3DQEJARYiemVy
dGlmaXppZXJ1bmdzc3RlbGxlQG53Lm5lY2xhYi5ldQIED+0gWzANBgkqhkiG9w0BAQEFAASCAQDl
hQPZs/pJjDOAL8yDVr3LMn7AuQKi/wIhzRmFUzpkOxbiwqpTxPdHxBJthd3tK9zrrIScYC1lpp/H
Lq57BvHZa/2v6n6G7PEuGx3nFx4ANZjAwKDr64MxocAQd9FKP/8Wj9S/Kj9WQ3FVWvqDYS5cIpne
tSLIkPpT8k0szXujVssln0MlC8cmbs1SfhNV6vOOoDqbA6Oikbwlit15G3gM7SsJmbvBK3pPlg7Q
2zaOlYhdkjOxezJD/QTrwNZpxWHatgdkGzXFPAcGIyHdOnhdGMXwOYIwgPVWItzDDP7rXFeoAemc
xik+abIs96RZ9PVN2eQ1EZ6MgnKikfsVRv92AAAAAAAA

------=_NextPart_000_0032_01CC97CE.86B640D0--

From paitken@cisco.com  Mon Oct 31 05:53:30 2011
Return-Path: 
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 3044221F8D5B for ; Mon, 31 Oct 2011 05:53:30 -0700 (PDT)
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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id W-znanPeGVBG for ; Mon, 31 Oct 2011 05:53:29 -0700 (PDT)
Received: from ams-iport-2.cisco.com (ams-iport-2.cisco.com [144.254.224.141]) by ietfa.amsl.com (Postfix) with ESMTP id 6517421F8B25 for ; Mon, 31 Oct 2011 05:53:29 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=paitken@cisco.com; l=1809; q=dns/txt; s=iport; t=1320065609; x=1321275209; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=ATh+Vcm3c93ZKa/Sp4W/bAJTcnvtLiW+AK1NVDOKbeQ=; b=fGh5u7sPXDv3uP96aNTeq75vWR4plwVn8+60fX85gbHPE4gls1s4KT2X mG8pyGxpwTa77OIbYXnhecdnkVonLOMNwDcq1Wqa5XsHY80eVl6FcIrCa XgKlDOOGIli47TDhOB6bxnPK+TSlDpLEaZotHZIrWAod2oLjLsddwvAJd k=;
X-IronPort-AV: E=Sophos;i="4.69,432,1315180800"; d="scan'208";a="58883031"
Received: from ams-core-2.cisco.com ([144.254.72.75]) by ams-iport-2.cisco.com with ESMTP; 31 Oct 2011 12:53:28 +0000
Received: from [10.61.85.30] (ams3-vpn-dhcp5407.cisco.com [10.61.85.30]) by ams-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id p9VCrSYw021955; Mon, 31 Oct 2011 12:53:28 GMT
Message-ID: <4EAE9A49.1070308@cisco.com>
Date: Mon, 31 Oct 2011 12:53:29 +0000
From: Paul Aitken 
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.23) Gecko/20110922 Lightning/1.0b2 Thunderbird/3.1.15
MIME-Version: 1.0
To: IETF IPFIX Working Group 
References: <20111031123010.32234.71195.idtracker@ietfa.amsl.com>
In-Reply-To: <20111031123010.32234.71195.idtracker@ietfa.amsl.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: [IPFIX] New Version Notification for draft-johnson-ipfix-mib-variable-export-03.txt
X-BeenThere: ipfix@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: IPFIX WG discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 31 Oct 2011 12:53:30 -0000

Dear All,

draft-johnson-ipfix-mib-variable-export-03 is now available at
     http://tools.ietf.org/html/draft-johnson-ipfix-mib-variable-export-03


Changes from -02:

* Split "Extended Field Specifier Format for an Indexed MIB Object" into 
two sections:
     "Extended Field Specifier Format for an Indexed MIB Object, With an 
MIB OID as Index"
     "Extended Field Specifier Format for an Indexed MIB Object, With an 
IPFIX IE as Index".

* Added "Indices Considerations".

* Organised and corrected Example Use Cases.

* Added missing "Index Field length" to figure 9.

* Made open issues list visible.

* Minor corrections for consistency and typos.


We believe the draft is ready for adoption by the WG.

Thanks,

     Juergen, Benoit and Paul.


On 31/10/11 12:30, internet-drafts@ietf.org wrote:
> A new version of I-D, draft-johnson-ipfix-mib-variable-export-03.txt has been successfully submitted by Paul Aitken and posted to the IETF repository.
>
> Filename:	 draft-johnson-ipfix-mib-variable-export
> Revision:	 03
> Title:		 Exporting MIB Variables using the IPFIX Protocol
> Creation date:	 2011-10-31
> WG ID:		 Individual Submission
> Number of pages: 44
>
> Abstract:
>     This document specifies a way to complement IPFIX Flow Records with
>     Management Base (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 an extension to the current IPFIX protocol.  New
>     Template Set and Options Template Sets are specified to allow the
>     export of Simple Network Management Protocol (SNMP) MIB Objects along
>     with IPFIX Information Elements.
>
>
>
>
> The IETF Secretariat


From paitken@cisco.com  Mon Oct 31 09:52:34 2011
Return-Path: 
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 6C1DB11E8111 for ; Mon, 31 Oct 2011 09:52:34 -0700 (PDT)
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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vb5VjBNREKKc for ; Mon, 31 Oct 2011 09:52:32 -0700 (PDT)
Received: from ams-iport-2.cisco.com (ams-iport-2.cisco.com [144.254.224.141]) by ietfa.amsl.com (Postfix) with ESMTP id CCA5411E80EA for ; Mon, 31 Oct 2011 09:52:31 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=paitken@cisco.com; l=18815; q=dns/txt; s=iport; t=1320079951; x=1321289551; h=message-id:date:from:mime-version:to:subject; bh=878HQ2xDy7vLeVaE5/E3rukxFEFKP7J+df/HmLR2eMY=; b=aletsGT6QXo1fkVUK7WUKdeiVCQZ/8yCVDCLwL6+0yYQ9NGxc3ORvO0R tyN/Kne4L4D+i1UL67i15xl/VP0I/1ygtcRdJC2w0K1HZ0ULqVZ6gE0uK LBEsp6bH+iOXa0mUO5o6uN+8PThzpYLmnhOHyAsNfSGd+7+1HA4RKnGhV 4=;
X-Files: draft-aitken-ipfix-unobserved-fields-00.txt : 17389
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: Av4EACbSrk6Q/khL/2dsb2JhbAA4BwOpNYEFggsBZQ8uFhgDAgECAQkBQQ0GAgEBBRIHh2iUMYEmAZ4lAoVRGoMVBIZEjUqFLYUKhyg
X-IronPort-AV: E=Sophos;i="4.69,433,1315180800";  d="txt'?scan'208";a="58899458"
Received: from ams-core-2.cisco.com ([144.254.72.75]) by ams-iport-2.cisco.com with ESMTP; 31 Oct 2011 16:52:30 +0000
Received: from [10.61.85.30] (ams3-vpn-dhcp5407.cisco.com [10.61.85.30]) by ams-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id p9VGqUEk007784 for ; Mon, 31 Oct 2011 16:52:30 GMT
Message-ID: <4EAED24F.1030003@cisco.com>
Date: Mon, 31 Oct 2011 16:52:31 +0000
From: Paul Aitken 
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.23) Gecko/20110922 Lightning/1.0b2 Thunderbird/3.1.15
MIME-Version: 1.0
To: IETF IPFIX Working Group 
Content-Type: multipart/mixed; boundary="------------010901020107080208030908"
Subject: [IPFIX] draft-aitken-ipfix-unobserved-fields-00
X-BeenThere: ipfix@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: IPFIX WG discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 31 Oct 2011 16:52:34 -0000

This is a multi-part message in MIME format.
--------------010901020107080208030908
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

Dear all,

Due to vacation last week, I overlooked submitting the attached draft 
prior to the -00 cutoff.

This document discusses several methods to report unobserved fields in 
IPFIX and the advantages and disadvantage of each, with the ultimate 
goal of recommending and specify one method as an extension to the IPFIX 
Protocol [RFC5101].

Your feedback is warmly welcomed.

Thanks,
P.

--------------010901020107080208030908
Content-Type: text/plain;
 name="draft-aitken-ipfix-unobserved-fields-00.txt"
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
 filename="draft-aitken-ipfix-unobserved-fields-00.txt"


                 Reporting Unobserved Fields in IPFIX 

  
  
  
 Internet-Draft                                             P. Aitken
 draft-aitken-ipfix-unobserved-fields-00.txt            Cisco Systems
 Expires: February, 2009 
  
  
                                                         October 2011
  
  
  
                 Reporting Unobserved Fields in IPFIX 
                draft-aitken-ipfix-unobserved-fields-00 
     
  
    Status of this Memo 
     
    By submitting this Internet-Draft, each author represents that 
    any applicable patent or other IPR claims of which he or she is 
    aware have been or will be disclosed, and any of which he or she 
    becomes aware will be disclosed, in accordance with Section 6 of 
    BCP 79. 
     
    Internet-Drafts are working documents of the Internet 
    Engineering Task Force (IETF), its areas, and its working 
    groups.  Note that other groups may also distribute working 
    documents as Internet-Drafts.  
     
    Internet-Drafts are draft documents valid for a maximum of six 
    months and may be updated, replaced, or obsoleted by other 
    documents at any time.  It is inappropriate to use 
    Internet-Drafts as reference material or to cite them other than 
    as "work in progress."  
     
    The list of current Internet-Drafts can be accessed at 
    http://www.ietf.org/1id-abstracts.txt. 
     
    The list of Internet-Draft Shadow Directories can be accessed at  
    http://www.ietf.org/shadow.html. 
     
    This Internet-Draft will expire on May 2007. 
     
  
     
    Copyright Notice  
     
    Copyright (C) The Internet Society (2006). 
  

















                                                        
 Aitken                   Expires Aug 2011                  [Page 1] 

  
 Abstract 
     
    This document discusses several methods to report unobserved 
    fields in IPFIX and the advantages and disadvantage of each. 
     
     
 Conventions used in this document 
  
     The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL 
     NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and 
     "OPTIONAL" in this document are to be interpreted as described 
     in RFC 2119 [RFC2119]. 
      
      
 Table of Contents 
  
    1.   Introduction................................................3
    2.   Terminology.................................................3
    3.   Possibilities...............................................3
    3.1    Multiple templates........................................3
    3.2    CommonProperties..........................................4
    3.3    Default Values............................................4 
    3.3.1    Default of Zero.........................................5 
    3.3.2    Field-specific default values...........................5 
    3.4    "Observed Fields" Bitfield................................5
    3.5    Length of Zero............................................6
    4.   Conclusion..................................................6 
    5.   Security Considerations.....................................6 
    6.   IANA Considerations.........................................6 
    7.   References..................................................6 
    7.1    Normative References......................................6 
    7.2    Informative References....................................6 
    8.   Acknowledgements............................................7
    9.   Author's Addresses..........................................7
    10.  Intellectual Property Statement.............................7
    11.  Copyright Statement.........................................7
    12.  Disclaimer..................................................8
     
     
  

























  

  
 1. Introduction 
     
    The IPFIX information model [RFC5102] contains a wide variety of 
    fields [IANA-IPFIX], which are not always present in all 
    traffic. For example, ICMP type and code. Indeed, some fields 
    are mutually exclusive. For example, IPv4 / IPv6 address fields; 
    UDP / TCP port numbers. 
     
    When an IPFIX Metering Process monitors a single such field, it 
    simply reports whenever appropriate traffic is seen. ie, 
    whenever the Observed Traffic Stream [RFC5476] contains the 
    field to be metered. No output is generated whenever the 
    monitored field is not present. 
     
    The IPFIX protocol lacks a method for the Metering Process to 
    actively express that although fields were being monitored, no 
    relevant observations were made. Therefore the Collecting 
    Process cannot know whether the Metering Process was actively 
    monitoring the field, and can only infer from the lack of export 
    that no relevant observations were made. 
     
    Further, when a Metering Process monitors a combination of 
    fields, some may be present while others are not. Therefore the 
    Metering Process observes values for some fields, though not for 
    others. 
     
    The IPFIX Protocol [RFC5101] requires the Exporting Process to 
    employ a number of templates in order to export these 
    combinations, using one template for each observed combination 
    of fields. Since the number of templates required grows 
    exponentially with the number of mutually-exclusive fields, the 
    templates can quickly become unmanageable. Indeed, just a few 
    sets of mutually exclusive fields is sufficient to exhaust the 
    template number space. 
     
    Clearly the IPFIX protocol [RFC5101] would benefit from a method 
    for the Metering Process to actively express that although 
    fields were being monitored, no relevant observations were made. 
     
    This draft discusses various options for reporting such 
    unobserved fields, and the advantages and disadvantages of each, 
    with the ultimate goal of recommending and specify one method as 
    an extension to the IPFIX Protocol [RFC5101]. 


 2. Terminology 
  
    The terminology in this draft is fully aligned with the IPFIX 
    terminology, per section 2 of [RFC5101]. 
     
    Unobserved Field: a field which a Metering Process is metering, 
    but for which no traffic has been seen or no data is available.


 3. Possibilities 
     
    This section discusses various possibilities for unobserved 
    fields. 

  3.1 Multiple templates 
     
    The NetFlow v9 [RFC3954] and IPFIX protocol [RFC5101] are both 
    template based. Templates express which fields are present in 
    the exported Data Records. 
     
  

  
    When no value has been observed for a particular field, a new 
    template is generated without that field. Thus no value is 
    exported for the unobserved field. 
     
    While this prevents an incorrect or misleading value from being 
    exported for the field, it may require a great many Templates to 
    be created. The number may soon become unmanageable, or may 
    exceed the Template number space. 
     
    TODO: example. 
     
    The main issue with this solution is that no data is exported 
    about unobserved fields - so the Collecting Process cannot tell 
    whether the field was not being observed by the Metering 
    Process, or was being observed but no relevant traffic was seen. 
     
  3.2 CommonProperties 
     
    This solution divides Data Records into a core part in which the 
    fields are always observed, and additional parts according to 
    which other fields are observed. These are exported using the 
    method described in [RFC5473]. 
     
    One template is required to express which fields are present in 
    the core, and one Template is required for each combination of 
    additional fields. Since multiple templates are required, the 
    number of Templates may soon become unmanageable or may exceed 
    the Template number space. 
     
    The main issue with this solution is that again, like the 
    Multiple Template case, no data is exported about unobserved 
    fields - so the Collecting Process cannot tell whether the field 
    was not being observed, or was being observed but no relevant 
    traffic was seen. 
     
    TODO: does CP work for NFv9? 
     
  3.3 Default Values 
     
    With this solution, a single Template specifies all the fields 
    which the Metering Process was asked to observe. Fields for 
    which no value was observed, or for which the value is 
    unavailable, are exported with a default value. 
     
    Note that there are two cases: 
     
       1. Unavailable / Not applicable: 
          
         The monitored field was not present in, or not applicable 
         to, the observed traffic. 
         eg, when RTP SSRC is requested for a TCP flow. 
  
       2. Not Calculated: 
        
         Although the required fields exist, something is preventing 
         the calculation from occurring. For example, not enough 
         data has been collected to calculate a TCP round-trip time.  
     
    Note that multiple default values are required only if it's 
    necessary to differentiate these cases. In general, both cases 
    are represented by a single value. 
     
    Since only one template is used, this scheme is trivial to 
    implement and works for both NFv9 and IPFIX. 
     
  

  
    The default value can be one of two kinds as discussed below. 
     
 3.3.1   Default of Zero 
  
    All unobserved fields are exported with the value zero. Neither 
    the Exporting Process nor the Collecting Process needs any extra 
    knowledge about the field. 
     
    However, if zero is a valid value for the field, it will be 
    impossible to distinguish an unobserved field from a real 
    observation. Eg, when reporting the number of lost packets, 
    packetsLost = 0 seems to indicate that no traffic was lost, when 
    it may be intended to indicate that there is no relevant 
    information to report. 
  
 3.3.2   Field-specific default values 
  
    Each field is provided with a special "unobserved" value, which 
    is outside the normal range of observed values. 
     
    When no value is observed for the field, it's exported with the 
    "unobserved" value. This value varies from field to field. 
     
    Eg, when reporting that traffic lost is not relevant to the 
    current flow, packetsLost may be set to 65535 or -1. 
     
    In this case, both the Exporting Process and the Collecting 
    Process need extra knowledge about each individual field. 
     
    Since the "unobserved" value is outwith the normal range of 
    values for the field, it will be possible to distinguish an 
    unobserved field from a real observation. 
     
    However, not all fields have a suitable value. (TODO: example) 
     
  3.4 "Observed Fields" Bitfield 
     
    With this solution, a single template specifies all the fields 
    which the Metering Process was asked to observe. The template 
    contains an additional bitfield which is exported in the Data 
    Record along with the flow data. This bitfield is similar to the 
    flowKeyIndicator [IANA-IPFIX, #173], in that each bit 
    corresponds to one field in the flow record. Each bit indicates 
    whether or not a value was observed for the corresponding field. 
     
    The Collecting Process examines the bitfield and disregards any 
    unobserved fields. Unobserved fields may therefore be exported 
    with any value, since they will be disregarded. 
     
    Since it uses only one template, this scheme is trivial to 
    implement and works for both NFv9 and IPFIX. 
     
    However, a mediator must understand the bitfield and correctly 
    interpret it. eg, if the mediator is aggregating Data Records, 
    it must pay attention to the bitfield. If fields are added or 
    removed from the Flow Record, bits in the bitfield must be 
    shifted accordingly. Therefore this requires changes to IPFIX 
    record processing. 
     
    Note that if the "Observed Fields" bitfield is sent in an IPFIX 
    Options Record, it expresses which fields are valid in that 
    Options Data Record. It's not possible to use option scoping to 
    report the Observed Fields bitfield for any other Record. 
     

  

  
  3.5 Length of Zero. 
     
    This method exports a single Template which specifies all the 
    fields which the Metering Process was asked to observe. Fields 
    for which no value was observed are exported with a length of 
    zero. Therefore unobserved fields are actively indicated. 
     
    Fields which may be unobserved must be anticipated ahead of time 
    and specified in the Template using IPFIX variable-length 
    encoding. 
     
    While this method only requires a single Template, it doesn't 
    work for NFv9 export since NFv9 doesn't support variable-length 
    encoding. 
     
    It also does not address the not-applicable versus not-
    calculated case discussed in section 3.3, which is needed for 
    some fields. 
     
     
 4. Conclusion. 
     
    Several methods of encoding "unobserved" fields have been 
    presented. Each has pros and cons. 
     
    TODO: weigh up the pros and cons and recommend a solution. 
     
     
 5. Security Considerations 
     
    The same security considerations as for the IPFIX protocol 
    apply. 
     
     
 6. IANA Considerations 
     
    There are no IANA considerations at this time. 
     
    Some of the solutions discussed in section 2 require additional 
    Information Elements to be allocated. 
     
     
 7. References 
                                            
     
  7.1 Normative References 
  
    [RFC5101] Claise, B., Ed., "Specification of the IP Flow 
              Information Export (IPFIX) Protocol for the Exchange 
              of IP Traffic Flow Information", RFC 5101, 
              January 2008. 
     
    [RFC2119] S. Bradner, Key words for use in RFCs to Indicate 
              Requirement Levels, BCP 14, RFC 2119, March 1997 
     
     
  7.2 Informative References 
     
    [RFC5102] Quittek, J., Bryant, S., Claise, B., Aitken, P., 
              and J. Meyer, "Information Model for IP Flow 
              Information Export", RFC 5102, January 2008. 
     



  

  
    [RFC5473] Boschi, E., Mark, L., and B. Claise, "Reducing 
              Redundancy in IP Flow Information Export (IPFIX) and 
              Packet Sampling (PSAMP) Reports", 
              RFC 5473, March 2009. 
     
    [RFC5476] Claise, B., Ed., "Packet Sampling (PSAMP) 
              Protocol Specifications", RFC 5476, March 2009. 
     
    [RFC3954] Claise, B., Ed., "Cisco Systems NetFlow Services 
              Export Version 9", RFC 3954, October 2004. 
     
    [IANA-IPFIX]  http://www.iana.org/assignments/ipfix/ipfix.xml 
     
     
     
 8. Acknowledgements 
     
    Thanks to Aamer Akhter for initial review and feedback. 
     
     
 9. Author's Addresses 
     
        Paul Aitken 
        Cisco Systems (Scotland) Ltd. 
        96 Commercial Quay 
        Commercial Street  
        Edinburgh, EH6 6LX, United Kingdom 
        Phone: +44 131 561 3616 
        Email: paitken@cisco.com 
  
             
 10.   Intellectual Property Statement 
     
    The IETF takes no position regarding the validity or scope of 
    any Intellectual Property Rights or other rights that might be 
    claimed to pertain to the implementation or use of the 
    technology described in this document or the extent to which any 
    license under such rights might or might not be available; nor 
    does it represent that it has made any independent effort to 
    identify any such rights.  Information on the procedures with 
    respect to rights in RFC documents can be found in BCP 78 and 
    BCP 79. 
    Copies of IPR disclosures made to the IETF Secretariat and any 
    assurances of licenses to be made available, or the result of an 
    attempt made to obtain a general license or permission for the 
    use of such proprietary rights by implementers or users of this 
    specification can be obtained from the IETF on-line IPR 
    repository at http://www.ietf.org/ipr. 
     
    The IETF invites any interested party to bring to its attention 
    any copyrights, patents or patent applications, or other 
    proprietary rights that may cover technology that may be 
    required to implement this standard. Please address the 
    information to the IETF at ietf-ipr@ietf.org. 
     
 11.   Copyright Statement 
     
    Copyright (C) The Internet Society (2011). This document is 
    subject to the rights, licenses and restrictions contained in 
    BCP 78, and except as set forth therein, the authors retain all 
    their rights. 
     



  

  
 12.Disclaimer  
     
    This document and the information contained herein are provided 
    on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE 
    REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND 
    THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, 
    EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY 
    THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY 
    RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS 
    FOR A PARTICULAR PURPOSE. 























































  

--------------010901020107080208030908--

From n.brownlee@auckland.ac.nz  Mon Oct 31 21:31:27 2011
Return-Path: 
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 E4BAF1F0C3C for ; Mon, 31 Oct 2011 21:31:26 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -104.071
X-Spam-Level: 
X-Spam-Status: No, score=-104.071 tagged_above=-999 required=5 tests=[AWL=-1.472, 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 5uw7E-+eC8Km for ; Mon, 31 Oct 2011 21:31:25 -0700 (PDT)
Received: from mx2.auckland.ac.nz (mx2.auckland.ac.nz [130.216.12.44]) by ietfa.amsl.com (Postfix) with ESMTP id 51A321F0C42 for ; Mon, 31 Oct 2011 21:31:24 -0700 (PDT)
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=1320121886; x=1351657886; h=message-id:date:from:mime-version:to:subject: content-transfer-encoding; bh=D/4dGP/7GZpGwehxc2Vozk08Mp7yGMXMzp5cOf4cIcM=; b=VD1MZYCgvg98Mysu0TUPw67U2H6RS+FU3B99yQa1nQAsUqmG+/NHyJcM rI/XY4WdcK10SzOIqAlRXEH05eV3DACtrUAd3BwSGJP0RljbgwVUcX/rZ n/Z/JXvxXdjj2kUATxxAFZ8/eRs1YS83fVME5jbdPmqaRqfTZ8PmDg9VD A=;
X-IronPort-AV: E=Sophos;i="4.69,436,1315137600"; d="scan'208";a="88212768"
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; 01 Nov 2011 17:31:07 +1300
Message-ID: <4EAF760A.6020903@auckland.ac.nz>
Date: Tue, 01 Nov 2011 17:31:06 +1300
From: Nevil Brownlee 
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1
MIME-Version: 1.0
To: IPFIX Working Group 
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Subject: [IPFIX] Taipei agenda, DRAFT-01
X-BeenThere: ipfix@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: IPFIX WG discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 01 Nov 2011 04:31:27 -0000

Hi all:

Thanks for your feedback, the next version of the Taipei meeting's
IPFIX agenda is online at
   http://www.ietf.org/proceedings/82/agenda/ipfix.txt

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