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.
Apologies for the late review. Got tangled up with IETF and holidays.
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 reflections of 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 do this
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 malformed
messages 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 provides separate
information elements to allow reporting of post-modification information but
there is nothing (or at least nothing that is guranateed to be 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 not even see an element that
needed to be included to separately specify the nature 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 is a
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.
_______________________________________________
Gen-art mailing list
[email protected]
https://www1.ietf.org/mailman/listinfo/gen-art
