Subject: [Gen-art] Gen-art review of draft-ietf-ipfix-implementation-guidelines-06.txt

From: Elwyn Davies <[email-masked]>
Date: Mon, 29 Oct 2007 15:26:38 +0000

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-masked]
https://www1.ietf.org/mailman/listinfo/gen-art

---

From: Elisa Boschi <[email-masked]>
Date: Wed, 31 Oct 2007 11:54:09 +0100

Elwyn,

find inline answers to your comments

thanks,
Elisa

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

all changed to lowercase

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

yeah, done.
(there were two of those and I just saw - and corrected - one during
last review...)

>    sufficient.'  This needs some punctuation and the spelling corrected, maybe s/is limited the 32-bits alignement/is limited; the 32-bits alignment/

proposed NEW text:

There is no means for aligning Template Records within a Set. However,
there is limited need for such a method, as Information Element
specifiers are always 32-bit aligned, and 32-bit alignment is generally
sufficient.

> s4.7: Expand IPC

done

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

done