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. > II. Typographical, editorial and stylistic comments: > > Thanks for these, there were quite a few typos/capitalization issues > we'd not caught yet. Stylistic suggestions have been incorporated where > they improve the clarity of the document. > > 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. Do you propose to use "IPFIX Message format" in a different way? > Similarly, an "IPFIX Message stream" is a collection of IPFIX Messages > in some loose order. This is applying the word "stream" as it is used > when talking about storage, where there is no connotation in English of > an unbounded sequence. I'm going to suggest we leave this term, as the > suggested alternatives have their own problems: "Sequence" connotes > strict ordering (not the case; IPFIX Messages can be reordered within a > File containing a Message stream for e.g. template consistency.) > "Series" has a strict and nonapplicable mathematical meaning. Ok. > Alternately, a question to the WG: should we define "IPFIX Message > stream" and "IPFIX Message format" as intermediate terms in the > Terminology section of the document? I do not think that this is necessary. > 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. Who is "people"? Usually vendors, so they do have their PEN. On the other hand, if you read an IPFIX File including opaqueOctets fields, you do not know how to interprete it. In fact, opaqueOctets does not fulfill one of the important requirements of IPFIX File: self description. > Thanks again! Welcome. Gerhard
Attachment:
smime.p7s
Description: S/MIME Cryptographic Signature
_______________________________________________ IPFIX mailing list IPFIX at ietf.org https://www.ietf.org/mailman/listinfo/ipfix