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: "Boschi, Elisa" <[email-masked]>
Date: Thu, 6 Sep 2007 15:35:56 +0100

Nevil, all,

> That prompted lots more activity, and a host of people offering to review
> the proposed new drafts.
> 

I believe it should be standards track. It is true that the File Format doesn't describe bits on the wire, but it can be used as input for analysis tools or for testing. It should be standards track to guarantee interoperability.

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

yes it does. Exporting Types was initially part of the File specification, and it is needed to address the self-description requirement for the file format.

> 1 and 2 are well advanced, i.e. items which seem achievable in six months
> to 12 months to complete, but I propse that we adopt them as WG work items.
> 

I think that the File Format is almost complete. It is definitely achievable in six months. Exporting type _might_ take a bit longer but not much...

> support for it.  I suggest that those interested in it work on a 'problem

Cheers,
Elisa

>     IPFIX MIB.  What's the current status of that, please?

************************************************************************************************** 
E-mail Confidentiality Notice and Disclaimer. 

This e-mail and any files transmitted with it are confidential and are intended solely for the use 
of the individual or entity to which they are addressed. Access to this e-mail by anyone else is 
unauthorised. If you are not the intended recipient, any disclosure, copying, distribution or any
action taken or omitted to be taken in reliance on it, is prohibited. E-mail messages are not 
necessarily secure. Hitachi does not accept responsibility for any changes made to this message 
after it was sent. 
Hitachi checks outgoing e-mail messages for the presence of computer viruses. 
**************************************************************************************************
_______________________________________________
IPFIX mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ipfix