Re: [IPFIX] WG last call on draft-ietf-ipfix-file-02

[Brian Trammell <trammell at tik.ee.ethz.ch>]

On Aug 29, 2008, at 4:07 PM, Gerhard Muenz wrote:

>
> Brian,
>
> Brian Trammell wrote:
>> Thanks for your detailed review and comments. I'll address these by  
>> type.
>>
>> I. Comments related to the length and level of detail of the  
>> document:
>>
>> The IPFIX File draft differs from other IPFIX drafts in that it 1.
>> contains its own requirements (analogous to 3917 and 5101 being the  
>> same
>> document) and 2. contains more motivating text than other drafts,  
>> due to
>> its somewhat unusual nature within the IETF (standardizing a file  
>> format
>> without binding it to some specific transport). The authors believe  
>> that
>> the inclusion and length of the requirements and motivation sections
>> (sections 4 and 5) is warranted by these considerations.
>
> I partially agree: motivation and requirements should be included. The
> question is if we need that many pages.
>
> The general concept of the file format is straight forward and easy to
> understand. The important aspects can be explained on a couple of  
> pages.
> So, an implementer who is already familiar with IPFIX should not be
> urged to read through 50 pages. What he needs to read are sections  
> 3, 7,
> 8. Sections 4 to 6 provide background information which are not
> necessary to implement the standard (but rather useful to sell the
> standard to customers). Sections 9 and 10 cover special cases. Apart
> from reducing verbosity, you could mention in the introduction which
> sections contain the important information.

This is an excellent point; I agree completely. I'll modify the  
introduction to add exactly this sort of implementor-friendly overview.

>> III. Terminology confusion:
>>
>> There are a couple of terms invented here in order to describe  
>> concepts
>> 1. for which there is no accepted terminology but 2. which appear  
>> only
>> for purposes of background. One of these is "IPFIX Message format",
>> which is intended to mean "the encoding and framing of IPFIX Messages
>> defined by RFC 5101 as used with the information model defined by RFC
>> 5102", or less formally, "IPFIX off the wire", _not_ the format of an
>> individual message. Your comments indicate some confusion here, and I
>> would appeal to the working group to suggest an alternative if this  
>> is a
>> problem.
>
> RFC 5101 section 3 defines the IPFIX Message format, which is the  
> format
> of a single IPFIX Message.

Indeed, as a section header, but not as a point of terminology.

> Do you propose to use "IPFIX Message format" in a different way?

No. But we need a way, in the flow of this document, to describe  
"IPFIX without transport". "IPFIX Message format" appears to have  
caused some confusion. Does anyone have a clearer suggestion?

>> The issues regarding the interchangeability of "IPFIX File" and  
>> "IPFIX
>> Transport Session" given the fact that Sessions may span Files have  
>> been
>> fixed; many thanks for pointing this one out. V9-related  
>> terminology has
>> been fixed, too; I got a bit confused in a couple of places switching
>> between V9 and IPFIX.
>>
>> IV.  Technical issues:
>>
>> Time window resolution finer than seconds: Perhaps. We were trying to
>> avoid the explosion of timestamp IEs we have elsewhere in the
>> information model. Keep in mind that the Time Window is meant, in
>> multi-file environments, to determine whether a file must be  
>> scanned to
>> find information about a specific moment in time. Going below the
>> second-level resolution, at least in my experience, is not necessary
>> _for this use case_.
>>
>> Applicability of opaqueOctets: Indeed, one could create an
>> enterprise-specific IE and not export ET info about it, then it's
>> opaque. But 1. we still need to address the how to encap non-IPFIX  
>> info
>> in an IPFIX stream and 2. don't necessarily want to tell people go  
>> get a
>> PEN to do it. I'm inclined to keep opaqueOctets.
>
> I still do not see the need nor the utility of opaqueOctets.

Think of it as an IPFIX-friendly way to say "skip this embedded data".  
It has clear semantics (i.e. "Do Not Do Anything With This"), unlike  
undefined esIEs.

Regards,

Brian
_______________________________________________
IPFIX mailing list
IPFIX at ietf.org
https://www.ietf.org/mailman/listinfo/ipfix