Subject: [Gen-art] Gen-ART review of draft-ietf-ipfix-export-per-sctp-stream-02.txt

From: "Miguel A. Garcia" <[email-masked]>
Date: Fri, 26 Jun 2009 11:58:53 +0200

I have been selected as the General Area Review Team (Gen-ART)
reviewer for this draft (for background on Gen-ART, please see
http://www.alvestrand.no/ietf/gen/art/gen-art-FAQ.html).

Please resolve these comments along with any other Last Call comments
you may receive.

Document: draft-ietf-ipfix-export-per-sctp-stream-02.txt
Reviewer: Miguel Garcia <[email-masked]>
Review Date: 26-June-2009
IETF LC End Date: 30-June-2009

Summary: The document is ready for publication as an Informational RFC

Major issues:

Minor issues:

Nits/editorial comments:

- Abbreviations should be expanded at first occurrence. This includes 
IPFIX (title), PR-SCTP (Abstract), PSAM (title of Section 1.2).

- Section 1 (Terminology) defines the Template Reuse Delay as follows:

            The time the Exporting Process MUST wait after sending the
            last Data Set described by a given Template before sending a
            Template Withdrawal Message for the Template.

There is a normative "MUST" in that definition. I think it is not 
acceptable to include a normative strength text within a definition. I 
would recommend to replace the existing sentence with:

"The time the Exporting Process needs to wait...";

then, elsewhere in the draft, you can add some text that includes the 
normative text, for example:

"Whatever-entity MUST wait the number of seconds indicated determined by 
the value of the Template Reuse Delay after sending the last Data Set 
described by a given Template before sending a Template Withdrawal 
Message for the Template."

- The first paragraph in Section 2 names the IPFIX working group. Since 
working groups are temporary arrangements (they eventually dismiss), and 
since the name of the WG is irrelevant for the content, I would remove 
it, and just mention that "The IPFIX protocol [RFC5101] has the goal of 
exporting IP Flow information."

- Section 2.1 talks about "IPFIX protocol specifications". Honestly, I am 
not very familiar with IPFIX and what a protocol "specification" is. I 
went to RFC 5101 and it is not obvious what a "specification" is in this 
context. I just hope the concept of a specification is clear for the 
reader of the draft. At least, it is not for me, so I wouldn't know how 
to interpret "All specifications from [RFC5101] apply unless specified 
otherwise in this document."

- Section 6 (IANA considerations). The draft fails to mention the 
registry IANA should act upon. Proposed text:

This document request IANA to allocate a new value to the 
dataRecordREliability Information Element in the IPFIX Information 
Elements registry.

- A number of Internet-Drafts listed int he References section have been 
published as RFC. Bear this in mind if you create a new version.

/Miguel

-- 
Miguel A. Garcia
+34-91-339-3608
Ericsson Spain