Re: [IPFIX] proposal for IPFIX charter update

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] 
> <mailto:[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