Subject: [IPFIX] *Proposed* new work items for IPFIX

From: Nevil Brownlee <[email-masked]>
Date: Thu, 26 Jul 2007 02:48:00 +1200

Hi all:

As promised yesterday, here'e the proposed list ..

Cheers, Nevil

-----------------------------------------------------------------------
  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: Proposal for new work
       Based on discussion at IETF 69, Chicago

For IPFIX mailing list, we suggest that items 1-6
(above the --- line) be adopted as new WG work items.
Please comment by 6 Aug 07 - we'd like to know who's prepared
to work on each item, and who will review its drafts.

0. Remove SCTP stream restrictions in Protocol Document.
   Agreed: WG needs to do this, as soon as possible.
   Procedure: Call protocol document back from RFC EDitor Queue.
      make changes (only those needed for SCTP Stream use),
      and consequent changes to Implementation Guidelines and
      Testing drafts.
      re-run WG Last Call and IETF Last Call, resubmit to IESG.

1. Configuration Data Model (Gerhard Muenz)
   Agreed: Important to WG, not clear what protocol would be needed.
   Proposal: (a) Develop Configuration Info Model as a WG item,
       in English (and also an XML version) - Standards Track RFC.
       (b) Consider what protocol would be best for IPFIX Configuration.
           Requirements RFC?      Milestones: WG LC before IETF 71

2. SCTP Per-Stream Draft (Benoit Claise)
   Agreed: Needs to be explored, as a possible protocol option.
   Procedure: Make this a WG item, as Experimental RFC.
   Milestones:  WG LC after IETF 70, to IESG before IETF  71.

3. File Format (Brian Trammel)
   Agreed: WG item, as soon as possible.
   Procedure: Make this a WG item, as an Informational RFC.
   Milestones:  WG LC after IETF 70, to IESG before IETF  71.

4. Extended Types (Elisa Boschi)
   Needed for IPFIX files, most useful for Enterprise IEs; need to
   specify what operations make sense for an IE.
   Support shown for this as a WG item, as for File Format.
   Milestones:  WG LC after IETF 70, to IESG before IETF  71.

-----------------------------------------------------------------------

5. IPFIX Mediation (Atayushi Kobayashi)
   Needed by (at least) two large operators.
   Could be integrated with Falko Dressler's draft on IPFIX Aggregation.
   Possible future WG item, continue discussion on mailing list.

6. Order of Information Elements (Irino)
   Interesting, need more people to measure possible efficiency gain.
   Would this be better as an individual draft?

7. Flow Sampling (Tanja Zseby)
   Early stage so far, comments/participation encouraged.

=======================================================================

-----------------------------------------------------------------------
This mail sent through University of Auckland http://www.auckland.ac.nz

_______________________________________________
IPFIX mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ipfix

---

From: Stewart Bryant <[email-masked]>
Date: Wed, 25 Jul 2007 19:31:33 +0100

>      re-run WG Last Call and IETF Last Call, resubmit to IESG.
That's a big deal that may result in all kinds of changes - new
LC comments, new discusses etc.  When you start this process
you cannot be sure what you will get out.

Why not continue with draft as it is and produce a second
draft that explains how to run the ipfix protocol in this new
transport mode.

Stewart

---

From: Stewart Bryant <[email-masked]>
Date: Wed, 25 Jul 2007 19:31:33 +0100

Stewart

---

From: Nevil Brownlee <[email-masked]>
Date: Thu, 26 Jul 2007 09:46:28 +1200

> draft that explains how to run the ipfix protocol in this new

We considered doing that, it's certainly not an approach to be taken lightly.
Consensus at the meeting was that we're blocked waiting
for the PSAMP Info draft, which will probably take a fair while yet.

The plan is to limit changes to *only* those addressed in Brian Trammell's
"SCTP change" draft, which we expect to minimise the chance of new
blocks appearing.  And last, since the Protocol documents is sitting
in the RFC Editor queue - i.e. it hasn't been published yet - we have
that (rare) chance to fix it in the original RFC, rather than forcing
everyone to refer to a 'changes' RFC as well as a Protocol RFC.

Cheers, Nevil

---

From: Nevil Brownlee <[email-masked]>
Date: Thu, 26 Jul 2007 09:46:28 +1200

Cheers, Nevil

---

From: "STEPHAN Emile RD-CORE-LAN" <[email-masked]>
Date: Wed, 25 Jul 2007 23:53:49 +0200

Hi Bryan,

As discussed after the meeting yesterday, I consider that the need of tagging the datatypes (tables of sections '3.2.  informationElementSemanticType' and  '3.3 informationElementStorageType') must be addressed through the adding of new information elements in the IPFIX Info model IANA registry.

Regards
Emile

> -----Message d'origine-----
> De : Stewart Bryant [mailto:[email-masked]]
> Envoyé : mercredi 25 juillet 2007 20:32
> À : Nevil Brownlee
> Cc : [email-masked]
> Objet : Re: [IPFIX] *Proposed* new work items for IPFIX
> 
> Nevil Brownlee wrote:
> >
> > Hi all:
> >
> >
> >

---

From: "STEPHAN Emile RD-CORE-LAN" <[email-masked]>
Date: Wed, 25 Jul 2007 23:53:49 +0200

Hi Bryan,

Regards
Emile

---

From: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Thu, 26 Jul 2007 02:03:55 +0200

To add to what Nevil said. Stewart's concern is certainly justified and
probably based on some experience :-) In full truth there is no
guarantee that the risks that he is mentioning could be 100% avoided.
However, it would help to include in the revised I-D a short log changes
section that makes clear that removing SCTP stream restrictions in
Protocol Document is the sole goal of this version. Also, the Last Call
texts should mention that it I sonly this specific set of changes that
is being last called. I will personally take care that this is included
in the IETF LC. 

Dan

> -----Original Message-----
> From: Nevil Brownlee [mailto:[email-masked]] 
> Sent: Thursday, July 26, 2007 12:46 AM
> To: [email-masked]
> Cc: [email-masked]
> Subject: Re: [IPFIX] *Proposed* new work items
> 
> 
> Hi Stewart:
> 
> > That's a big deal that may result in all kinds of changes - new LC 
> > comments, new discusses etc.  When you start this process 
> you cannot 
> draft that 
> > explains how to run the ipfix protocol in this new transport mode.
> 
> Consensus at the meeting was that we're blocked waiting for 
> the PSAMP Info draft, which will probably take a fair while yet.
> 
> The plan is to limit changes to *only* those addressed in 
> Brian Trammell's "SCTP change" draft, which we expect to 
> minimise the chance of new blocks appearing.  And last, since 
> the Protocol documents is sitting in the RFC Editor queue - 
> i.e. it hasn't been published yet - we have that (rare) 
> chance to fix it in the original RFC, rather than forcing

---

From: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Thu, 26 Jul 2007 02:03:55 +0200

Dan

---

From: Juergen Quittek <[email-masked]>
Date: Thu, 26 Jul 2007 08:09:17 +0200

Dear all,

Just for clarification: this issue is not concerning the discussion
of re-chartering IPFIX. It is the action of calling the current draft
of the IPFIX protocol back from the RFC editor queue before it gets
published and modifying it as described in draft-trammell-ipfix-sctp-change.
This implies also changes required in the implementation guidelines.
For both documents it will be required to run WGLC and IETF LC again.

If you see any problem with this (as Stewart did), please send us
your concerns until the end of next week.

Thanks,

    Juergen

---

From: Juergen Quittek <[email-masked]>
Date: Thu, 26 Jul 2007 08:09:17 +0200

Dear all,

Thanks,

    Juergen