Re: [IPFIX] proposal for IPFIX charter update

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