Re: [IPFIX] proposal for IPFIX charter update

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