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 protected]>
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.
_______________________________________________
Gen-art mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/gen-art
