Re: [IPFIX] proposal for IPFIX charter update
Brian Trammell <[email protected]>
| Newsgroups | gmane.ietf.ipfix |
|---|---|
| Message-ID | <[email protected]> |
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" <[email protected]> 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"<[email protected]> 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"
>>>>>> <[email protected]>
>>>>>> 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"
>>>>>>> <[email protected]>
>>>>>>> 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
>>>>>>>>>>>
>>>>>>>>>>> [email protected]://www.ietf.org/mailman/listinfo/ipfix
>>>>>>>>>> _______________________________________________
>>>>>>>>>> IPFIX mailing list
>>>>>>>>>>
>>>>>>>>>> [email protected]://www.ietf.org/mailman/listinfo/ipfix
>>>>>>>>> _______________________________________________
>>>>>>>>> IPFIX mailing list
>>>>>>>>>
>>>>>>>>> [email protected]://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
>>>>>>>>
>>>>>>>> [email protected]://www.ietf.org/mailman/listinfo/ipfix
>>>>>>> _______________________________________________
>>>>>>> IPFIX mailing list
>>>>>>>
>>>>>>> [email protected]://www.ietf.org/mailman/listinfo/ipfix
>>>> _______________________________________________
>>>> IPFIX mailing list
>>>> [email protected]
>>>> https://www.ietf.org/mailman/listinfo/ipfix
>>>
>>>
>>
_______________________________________________
IPFIX mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/ipfix