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 wait for direction from your document shepherd
or AD before posting a new version of the draft.
Document: draft-ietf-ipfix-implementation-guidelines-07
Reviewer: Elwyn Davies
Review Date: 26 October 2007
IESG Telechat date: 1 November 2007
Summary:
Many of the items noted in my last call review have been fixed. However, and I
am sorry to harp on about this, I believe that many of the instances of the use
of RFC 2119 language are inappropriate. It is now asserted (new in this
version)in Section 2(my emphasis):
This document is Informational. It does not specify a protocol and
does not use RFC 2119 keywords [RFC2119] such as "MUST" and "SHOULD",
except in quotations *and restatements* from the IPFIX standards dcouments.
The examples cited below show that this is not always true. To be blunt, I
think that paraphrases using RFC 2119 language are dangerous, and too easily
lead to the sort of cases shown below where it would appear that additional
requirements are being pushed onto the protocol or the language is open to
alternative interpretations. I think that it would be better to explicitly cite
the language in the standard or give a section reference, but avoid any sort of
alleged paraphrase that uses RFC 2119 language.
Accordingly I believe that every instance of RFC 2119 language including the
SHOULDs and MAYs needs to checked against the protocol once again. Where they
actually do reflect the protocol spec, replace them with actual quotes; if it
turns out they are not backed up by the protocol but are useful implementation
guidelines (and I am happy that this is the case with all the items suggested)
use lower case 'shoulds' etc. This would match with the recent example of IKE
implementation guidelines (RFC 4718).
There are a few other nits that didn't get fixed or have been introduced in the
last edit.
Comments:
Use of RFC 2119 terminology that are not (apparently) restatements of the
protocol documents:
For example in Section 3.1 'If no Template becomes available, the event SHOULD
be logged...'. I cannot trace the origin oif this (re-)statemment in Section 9
or 10 of the IPFIX protocol document.
And immediately after the previous example: 'and the Transport Session reset
(unless UDP is used), which will cause the Templates to be resent. The amount
of time the Collecting Process waits for a Template before resetting SHOULD be
configurable.' Again I cannot find requirements to this effect in sections 8-10
of the protocol.
In section 4.5: 'To ensure accuracy the clocks SHOULD be synchronised to a UTC
time source.' This is clearly a good idea but the protocol and info documents
are silent on this matter.
s6.2, first bullet at top of p18: s/topographically/topologically/ (I assume
this is not about how high up the hill the Collector should be!)
Editorial:
s4.4.3, para 1: 'However, for these records the need for
alignment is limited the 32-bits alignement that always occur is
sufficient.' This needs some punctuation and the spelling corrected, maybe
s/is limited the 32-bits alignement/is limited; the 32-bits alignment/
s4.7: Expand IPC
s7.3, para 5: s/section Section 7/Section 7/
_______________________________________________
Gen-art mailing list
[email protected]
https://www1.ietf.org/mailman/listinfo/gen-art
