Subject: [IPFIX] WG next steps, take two

From: Nevil Brownlee <[email-masked]>
Date: Thu, 6 Sep 2007 12:52:33 +1200

Hi all:

On 8 August I posted a summary of the list activity on "new work items."
That prompted lots more activity, and a host of people offering to  
review
the proposed new drafts.

Here's my summary of what IPFIX should do next:

0: SCTP changes to proto
    This is now in process, with protocol-26 about to start its IETF LC.

1: Config data model
    This has five reviewers,
    its clearly a WG work item, for an Informational RFC.

2: SCTP per-stream
    This has three reviewers,
    I believe it should be a WG work item, for an Informational RFC.

3: File Format
    Again, three reviewers, should be a WG work item.
    Points to discuss:
    a) Since it doesn't describe 'bits on the wire,' it ought to be
       Informational.  But does the WG think it should really be
       Standards Track, so as to guarantee interopability?
    b) Does it need to have the 'exporting-types' draft as a normative
       reference?

4: Exporting Types (was Extended Types)
    Three reviewers, lots of discussion, overall consensus that it
    should be a WG work item.

5: Mediators
    Three reviewers, continuing discussion, consensus that it needs
    to be split into smaller parts.

Recommendation:

1 and 2 are well advanced, i.e. items which seem achievable in six  
months
or so.  I'd like to adopt them as new WG work items.

3 is also well advanced, and 4 is tending that way, but there are open
issues as I mentioned for (3) above.  I guess that these could take six
to 12 months to complete, but I propse that we adopt them as WG work  
items.

5 is clearly going to need lots more work, but there is considerable
support for it.  I suggest that those interested in it work on a  
'problem
statement' document which would provide a framework for specific drafts
on some of the component parts, starting with Aggregation and (maybe)
Anonymisation.

Does anyone have any further feedback at this stage, please?

Cheers, Nevil

PS: Looking at our Milestones, the only one we're behind on if the
     IPFIX MIB.  What's the current status of that, please?

---------------------------------------------------------------------
  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-masked]
https://www1.ietf.org/mailman/listinfo/ipfix

---

From: Paul Aitken <[email-masked]>
Date: Thu, 06 Sep 2007 19:08:54 +0100

Nevil,

>       Standards Track, so as to guarantee interopability?

As long as your file comes with an interface that converts the data to 
and from the IPFIX wire format then you can write the file in whatever 
format you like and it'll be interoperable.

eg, given the right software, mydata.zip is "iteroperable" across all 
platforms.

That said, I can see a standard file format - or perhaps more 
importantly, the rules for creating files conforming to that format - as 
being a useful thing.

So I'm leaning towards Informational.

>    b) Does it need to have the 'exporting-types' draft as a normative

While it's useful to record information about the IEs in the file right 
there with the data, it's not absolutely essential. The type information 
could be archived elsewhere - eg, even written down - and the data 
successfully recovered. This is essentially what happens with the 
IPFIX-INFO IEs: they're written down in the IPFIX-INFO draft.

The main advantages I see are:

1. When using Enterprise Specific IEs, a file can be completely 
self-contained.

2. Even if the definition of the Enterprise Specific IEs changed over 
time, the correct definition can be archived with the data.

3. Potentially, new standard IEs which aren't known to the Collecting 
Process can be used without necessitating a Collector upgrade (eg, if 
the CP manufacturer is out of business or charging an extortionate fee 
for the upgrade).

So, it seems quite useful to me. I'd say it's something the file writer 
MAY do. Even recommend it as a SHOULD.

But it's definitely not essential; the file format is useful in its own 
right without this.

Cheers.
-- 
Paul Aitken
Cisco Systems Ltd, Edinburgh, Scotland.

---

From: Paul Aitken <[email-masked]>
Date: Thu, 06 Sep 2007 19:08:54 +0100

Nevil,

Cheers.