Subject: [IPFIX] I-D ACTION:draft-ietf-ipfix-structured-data-02.txt

From: [email-masked]
Date: Mon, 12 Jul 2010 10:00:01 -0700 (PDT)

A New Internet-Draft is available from the on-line Internet-Drafts 
directories.
This draft is a work item of the IP Flow Information Export Working Group of the IETF.

	Title		: Export of Structured Data in IPFIX
	Author(s)	: B. Claise, G. Dhandapani, S. Yates, P. Aitken
	Filename	: draft-ietf-ipfix-structured-data-02.txt
	Pages		: 72
	Date		: 2010-7-10
	
This document specifies an extension to the IP Flow Information 
        eXport (IPFIX) protocol specification in [RFC5101] and the IPFIX 
        information model specified in [RFC5102] to support hierarchical 
        structured data and lists (sequences) of Information Elements in 
        data records.  This extension allows definition of complex data 
        structures such as variable-length lists and specification of 
        hierarchical containment relationships between Templates.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-ipfix-structured-data-02.txt

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

---

From: Christoph Sommer <[email-masked]>
Date: Fri, 23 Jul 2010 08:03:21 +0200

Benoit, all,

as promised, here are some comments on draft-ietf-ipfix-structured-data-02:

Section 4.5:
> when representing variable-length data, hierarchical data, and
>       repeated data with variable element counts, we RECOMMEND these are
>       encoded as a Variable-Length Information Element

The draft doesn't make very clear why this is recommended. It almost 
feels like the benefits of this are implementation specific...

Section 5.6:
> The Exporter SHOULD NOT check all semantically meaningless
>      combinations before exporting the Data Record.

I didn't understand what is meant by this 'checking of combinations'. Is 
there a way to spell it out more clearly?

Section 5.6:
> in case of a single element in a Structured Data
>      Information Element, the default "undefined" semantic SHOULD be
>      used.

Is this to promote a consistent encoding? I don't see any harm in using 
one of the other semantics - in fact, using the same semantic for the 
same field regardless of the number of encoded values should save both 
the exporter and data visualization tools some time.
Also, there's an off chance that this recommendation might be 
misunderstood to imply that encoding one value with "noneOf" semantic 
should be done using "undefined", too :)

Section 7:
> If the Structured Data contains the "undefined" Structured Data
>      type semantic, the Collecting Process MAY attempt to draw its own
>      conclusion in terms of the semantic contained in the Data Record,
>      exactly as it would have done before the introduction of this
>      specification.

Collectors that are unaware of this specification would never be able to 
make any sense of structured data BLOBs, would they?

Section 8.4:
>      As explained in Section 4.4.3., a subTemplateMultiList is used

that's section 4.1.3, no?

Section 8.4:
>  Template for classification attributes: 259
>   Template for sampling attributes: 260
>   Template for Flow Record: 261

Here, like in other parts of the draft, the indentation is a bit off. It 
might be taken to imply that templates 260 and 261 and dependant on 259. 
In fact, it's 261 that's dependant on 259 and 260.

Section 9.2:
> - this test should be expanded to include Data Records
>    containing variable length basicList,
>    subTemplateList, and subTemplateMultiList Information
>    Elements.

Maybe an explicit recommendation to test not only for variable length 
structured data, but also for fixed length structured data field 
containing variable-length IEs might be warranted.

Cheers,

   Christoph

-- 
Christoph Sommer
Computer Networks and Communication Systems
University of Erlangen-Nuremberg, Germany
Phone: +49 9131 85-27993 / Fax: +49 9131 85-27409
http://www7.informatik.uni-erlangen.de/~sommer/