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

From: Paul Aitken <[email-masked]>
Date: Mon, 11 Oct 2010 23:23:52 +0100

Christoph,

Thanks for reviewing the structured data draft. Please find responses 
inline.

Thanks,
     Gowri, Benoit and Paul.

-----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf 
> Of Christoph Sommer
> Sent: Friday, July 23, 2010 2:03 AM
> To: [email-masked]
> Subject: Re: [IPFIX] I-D ACTION:draft-ietf-ipfix-structured-data-02.txt
>
> 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...
>

Please see the revised text in section 5.1, "Length Encoding 
Considerations".

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

We clarified the text:

     It is not the Exporter's role to check the validity of the semantic 
representation of Data Records. Therefore, the Exporter SHOULD NOT check 
all semantically meaningless combinations before exporting the Data Record.

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

Note that this is a SHOULD, not a MUST.

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

Yes, so we removed the text "exactly as it would have done before the 
introduction of this specification."

> Section 8.4:
>
> >      As explained in Section 4.4.3., a subTemplateMultiList is used
>
> that's section 4.1.3, no?
>

Thanks for pointing this out. Corrected to "Section 4.5.3".

> 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.
>
The space has been removed.

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

Can you give an example use case?

Thanks.

> 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/ 
> <http://www7.informatik.uni-erlangen.de/%7Esommer/>
>
> _______________________________________________
>
> IPFIX mailing list
>
> [email-masked]
>
> https://www.ietf.org/mailman/listinfo/ipfix
>