Document: draft-ietf-ipfix-export-per-sctp-stream-02.txt
Reviewer: Miguel Garcia <miguel.a.garcia@ericsson.com> 
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.