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

From: Paul Aitken <[email-masked]>
Date: Fri, 10 Jul 2009 15:27:46 +0100

Miguel,

Thanks for reviewing the draft. Please find responses inline.

> 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).

Done, except for the title - because "IP Flow Information Export (IPFIX) 
per Stream Control Transmission Protocol (SCTP) stream" completely 
detracts from the meaning.

> - 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."

Done.

> - 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."

Done.

> - 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."

RFC5101 = Specification of the IP Flow Information Export (IPFIX) Protocol

Wherein,

   "This document specifies an Internet standards track protocol ..."

   "This document specifies the IP Flow Information Export (IPFIX)
    protocol ..."

> - 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.

Done.

> - 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.

Done.

Thanks for the review.

-- 
Paul Aitken
Cisco Systems Ltd, Edinburgh, Scotland.