Subject: Re: [IPFIX] proposal for IPFIX charter update

From: Benoit Claise <[email-masked]>
Date: Fri, 02 Sep 2011 15:40:34 +0200

Hi Juergen,

Double-checking with my meeting minutes, I found some more issues.
See below.
> 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.
Even if obvious, I believe that a sentence explaining that all new 
deliverables should be based on RFC5102bis and RFC5101bis
>
> 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
I guess you want to mention the IPFIX MIB module
> 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
I guess you want to mention the IPFIX MIB module

Regards, Benoit.
> 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-masked]
> https://www.ietf.org/mailman/listinfo/ipfix

---

From: Benoit Claise <[email-masked]>
Date: Fri, 02 Sep 2011 15:24:12 +0200

Hi Juergen,

Next to Dan's editorial comments, I have some more.
See in line.
> element developers guideline document.
There are actually two different audiences. See section 1.1 
http://tools.ietf.org/html/draft-trammell-ipfix-ie-doctors-02
NEW:

For giving guidelines to developers of new IPFIX information
elements, for helping the IPFIX experts appointed as IE-Doctors, and for better defining the process of registering new
information elements at IANA, the IPFIX WG will create an information
element developers guideline document.

> for the use of the IPFIX protocol on IPFIX mediators.
"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:

produce the protocol specifications in order to solve these IPFIX mediation
specific problems.

> the IPFIX WG will define how to export aggregated flow information using
s/define/specify
> packets from multiple original Flows sharing some set of common properties.
s/Flow/flow

Regards, Benoit.

---

From: Gerhard Muenz <[email-masked]>
Date: Sun, 11 Sep 2011 22:47:47 +0200

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 already see IPFIX config being outdated by RFC5101/5102bis before it 
ever becomes RFC...)

Regards,
Gerhard

---

From: Shingo KASHIMA <[email-masked]>
Date: Tue, 13 Sep 2011 01:25:40 +0900

Hi Juergen,

> Apr 2012    Submit draft on data link IEs for publication as Standards

Has "Link Layer IEs" accepted as WG item ?

IETF81's minutes is as follows:
>  We have one other draft that was presented in earlier meetings - "Link
>  Layer IEs."  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.

Best regards,
Shingo

---

From: Benoit Claise <[email-masked]>
Date: Tue, 13 Sep 2011 14:10:00 +0200

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.

---

From: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Tue, 13 Sep 2011 16:56:30 +0200

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-masked]]
> 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

---

From: Benoit Claise <[email-masked]>
Date: Tue, 13 Sep 2011 17:35:21 +0200

Hi Dan,

Good suggestion.

Regards, Benoit.

---

From: Benoit Claise <[email-masked]>
Date: Wed, 28 Sep 2011 15:40:54 +0200

IPFIX chairs,
> 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
>
>

---

From: Nevil Brownlee <[email-masked]>
Date: Fri, 30 Sep 2011 11:10:55 +1300

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 :-)

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

---

From: Juergen Quittek <[email-masked]>
Date: Fri, 30 Sep 2011 07:18:13 +0000

Nevil,

Thanks for the summary.
I will post a new version of the charter at the weekend.

    Juergen