[Top] [All Lists]

Gen-ART LC/Telechat review of draft-ietf-ipfix-export-per-sctp-stream-06

2010-03-01 17:50:16
I have been selected as the General Area Review Team (Gen-ART)
reviewer for this draft (for background on Gen-ART, please see

Please wait for direction from your document shepherd
or AD before posting a new version of the draft.

Document: draft-ietf-ipfix-export-per-sctp-stream-06
Reviewer: Ben Campbell
Review Date: 1 March 2010
IESG Telechat date: 4 March 2010

Summary: This document is almost ready for publication as a proposed standard, 
but there is an open issue that should be considered first.

Major issues:

-- section 4.5, general:

I am confused as to  how the collector determines the exporter supports this 
extension. If I understand correctly (and it's probable that I do not, since 
this is my first real exposure to IPFix), the collector basically has to infer 
exporter support from the behavior of the exporter. But then the second 
paragraph after the numbered list (i.e. 2 paragraphs after item 4) says:

 "In the case where the Exporting Process does not support the 
        per-SCTP-stream extension, then the first Data Record received 
        by the Collecting Process will disable the extension for the 
        specific Exporter on the Collecting side."

This seems to conflict. Why would the collector need to worry about items 1-4 
if it can categorically determine exporter support from the first data record?

In general, though, I think that having the collector infer support is not the 
right way to do this. It would be far better to explicitly signal support, if 
that is at all possible in IPFix. Otherwise, it seems like the collector has to 
watch every record for violations of 1-4, and make fairly complex decisions on 
a per-record basis.

Minor issues:

-- section 4.2, 3rd paragraph from end, starting with "When an Options 

I'm confused by this paragraph. Would exporters using this extension ever send 
the options template and associated data records in different streams?

Nits/editorial comments:

-- section 4.1, description of dataRecordsReliability:

I find the first sentence hard to parse.

-- section 4.2, first paragraph" "...exporting processes should follow..."

(Note that an identical comment applies to the first paragraph of several of 
the specification sections.)

It would be best to avoid the word "should" in this context. Even though we all 
know a lower case should is not normative, it's still enough to confuse a 
reader into interpreting as a normative SHOULD, which is actually weaker than 
the real requirement. That is, I don't think you mean to say that, in order to 
take advantage of this extension and implementation SHOULD follow this 

-- section 4.3, paragraph 3:

pedantic nit - I think you mean all IPFIX messages in a single stream MUST be 
sent in order--not that all messages have to be in a single stream, right? The 
current wording is (slightly) ambiguous on that point.

-- section 4.3, last paragraph:

Why mention the alternative if it is not feasible in production?

--Examples, figure 3:

Is Data 257 a typo?

-- idnits has some warnings. Please check before publication.
Ietf mailing list