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 Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
