Re: [IPFIX] proposal for IPFIX charter update -> Internet Standard

Hi Dan,

Good suggestion.

Regards, Benoit.
> Hi,
>
> I suggest to say 'advance RFC 5101 and RFC 5102 to the next stage of
> standardization on the standards track'.
>
> The question that will be asked at some point is whether IPFIX reached
> the 'wide deployment' required by a Full Standard, but this is something
> we need to care about when and if we reach that phase and the process
> was already transitioned to two levels.
>
> Regards,
>
> Dan
>
>
>
>> -----Original Message-----
>> From: Benoit Claise [mailto:[email protected]]
>> Sent: Tuesday, September 13, 2011 3:10 PM
>> To: Juergen Quittek; Nevil Brownlee; Romascanu, Dan (Dan)
>> Cc: IETF IPFIX Working Group
>> Subject: Re: [IPFIX] proposal for IPFIX charter update ->  Internet
>> Standard
>>
>> Juergen, Nevil, Dan,
>>
>> In light of
>> http://tools.ietf.org/html/draft-housley-two-maturity-levels-08, which
>> is in the RFC-editor queue, should we shoot for RFC5101bis and
>> RFC5102bis as Internet Standard.
>> Maybe a sentence in the charter such as. If
>> draft-housley-two-maturity-levels-08 is published in time for the WG
>> milestones, the revised RFC5101 and RFC5102 should target Internet
>> Standard status"
>>
>> Regards, Benoit.
>>> 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]
>>> https://www.ietf.org/mailman/listinfo/ipfix

_______________________________________________
IPFIX mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/ipfix