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

From: Elwyn Davies <[email-masked]>
Date: Tue, 14 Aug 2007 17:11:21 +0100

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-implementation-guidelines-06
Reviewer: Elwyn Davies
Review Date: 20 July 2007
IETF LC End Date: 18 July 2007
IESG Telechat date: (if known)-

Summary:
Generally in good shape except that the use of RFC 2119 language is generally
inappropriate.  In many cases the uses of MUST represent reflectionsof
requirements in the actual protocol specification, but they are in many cases
paraphrases of the normative statements and thus could potentially be confusing
or result in conflicts.  Given that this is a guidelines document, I believe it
would be better to use statements along the lines of
'the protocol (document) requires' to avoid any potential problems.  There are a
few other minor issues noted below and some editorial matters although the RFC
editor will doubtless find some more.

Comments:
s1.4 suggests that RFC2119 normative language will be used:  in an informational
document billed as guidelines? In practice it looks as if many  of the MUSTs are
actually reflections or paraphrases of normative statements in the protocol
document, rather than the statements in this document being normative.  I think
it would avoid the appearance of being normative statements in their own right
and/or saying something marginally different from the real normative statement
if the wording was altered from 'MUST' to (say) 'the protocol (document)
requires'. Others are reflections of necessary facts of life. Instances of MUST:
- s3.1, para 3: reflection of IPFIX proto
- s3.1, para 4: not a requirement but a fact of life - Exporter has to dothis
because it just won't be able to continue if it doesn't.
- s3.3, para 1: reflection of statements in s3.4.2 of protocol spec.
- s3.4, para 1- first MUST: reflection of statements in s8 of protocol spec.
- s3.4, para 1 - second and third MUSTs: I am not clear that these musts are
backed up by the protocol spec.  The exporting order (s8 of proto spec) appears
to be a SHOULD;  I guess the collection reception order is implicit but isn't
set out explictly in the protocol.
- s3.5, para 1: supposed to be a reflection of s10.3.3 of protocol spec BUT
protocol spec says max 512 octets as compared with 576 in this doc.  Which is right?
- s3.5, para 2: relection of s10 of protocol spec.
- s4.1, para 3: I guess this is implicit in the statement about
malformedmessages in s9 of the protocol spec, but it could be argused that the
message is not malformed if it is just using a reserved Set ID. (the associated
SHOULD has the same caveat).
- s4.2, para 2: fact of life implied by other statements.
- s4.2, para 3: see s3.4, para 1, second and third MUSTs.
- s4.5.4: reflection of s3.3.1 of protocol spec.
- s5.1: Direct quote from protocol spec.
- s6.1, para 3: reflection of protocol spec s10.2.4.3 (as is the SHOULD).
- s6.1, para 4: Tautology?  Certainly a statement of the obvious.
- s6.1, para 10: (MUST NOT) reflection of protocol spec.
- s6.1, paras 2/3 from end: reflection/direct quote of protocol spec.
- s6.2, para 3 and 4 from end: reflection of protocol spec
- s6.3, para 3: direct quote
- s7.3, para 3: this instance appears to be requiring something that is outside
the scope of the protocol to determine.  draft-ipfix-info providesseparate
information elements to allow reporting of post-modification information but
there is nothing (or at least nothing that is guranateed tobe right in all
circumstances) that can be done to verify that the data collected is pre- or
post-modification.  This is intimately tied to difficulty/impossibility of
making a truly transparent middlebox.  I could noteven see an element that
needed to be included to separately specify thenature of the observation point
as regards whether it is pre- or post-modification or in the public/private
addressing realm of a NAT.  Using the'wrong' IEs will not break the protocol or
affect interoperability. All that can be done is remind implementers that the
appropriate kind of IEs ought to be used to reflect the location of the
observation point.
- s7.3, para 4: the same considerations as for the previous 'MUST' apply here as
well.
- s8.1, para 1 (REQUIRED rather than MUST): reflection of protocol spec s11.1
- s8.2, para 3: reflection of protocol spec s11.3
- s9.1, para 3, two places: reflection of s2.1 of ipfix-info draft
- s9.2, para 1: reflection of protocol spec s3.2
- s10.2, para 1: reflection of protocol spec s3.3.1

There are several instances of SHOULD and MAY also that need to be assessed in
the same way as the MUST instances.  In particular the MAY and SHOULD in the
last para of s7.3 can only be recommendations.

s6.1, para 3: The last sentence appears gratuitous and maybe wrong (I don't know
SCTP sufficiently well to know if stream numbers have to be allocated
sequentially, but I suspect that the data stream number can be any valid value.

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

s7, last para: I don't believe this documents should be specifying but
recommending which IEs to send in each case.

s7.3, para 3, last sentence: I do not believe that draft-ipfix-info 'requires'
use of the 'post-*' IEs but merely provides them for use in appropriate
circumstances.  If the implementer does the wrong thing nothing will break and
the situation will be undetectable to the collector.  The guidelines should just
be advising the implementer to use the right sort of IE.

s9.1:  The information about the ipfix wg maintaining the registry until the
RFCs are published ought to be flagged for removal by the RFC editor as it will
be irrelevant once publication is complete.

Editorial:
s1.3: Need to use non-breaking spaces to improve layout of text relating to
protocol structures to keep the braces on the same line as element contents.

ss4.2/4.3:  IE needs to be expanded on first occurrence (even if there isa defn
elsewhere).

s4.8 (and elsewhere): Check capitalization in section headings.

s4.8: Expand IPC

s6 (semi-editorial):  'In the IPFIX documents the terms SCTP and SCTP-PR are
often used interchangeably..'  Actually in almost all the documents  (and
RFC3758) PR-SCTP is the preferred abbreviation.  SCTP-PR is used only in the
applicability document.

s7.1, para 3: s/a more than/more than/

s7.4, para 1: s/few/a few/

s7.4, para 5: The enumeration is in s7 now.

_______________________________________________
Ietf mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ietf