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 alignment/is limited; the 32-bits alignment/

s4.7: Expand IPC

s7.3, para 5: s/section Section 7/Section 7/