Ballot for draft-ietf-opsawg-ipfix-tcpo-v6eh
Discuss
Yes
No Objection
No Record
Summary: Has 2 DISCUSSes. Has enough positions to pass once DISCUSS positions are resolved.
This specification deprecates the ipv6ExtensionHeaders IPFIX IE in favor of the new IEs defined in this document. I don't see which RFC those were in, because this document does not Update: or Obsolete: the RFC that defined the ipv6ExtensionHeaders IPFIX IE This specification deprecates the tcpOptions IE Same here.
** Section 8.2. This section is under-specified and contains typos relevant to registration. -- The "IPFIX Information Elements" registry doesn’t have a “Value” field. It is “ElementID” -- The mandatory elements of the "IPFIX Information Elements" registry defined in the registration template of Section 2.1 of RFC7012 are missing – description, datatype, and status. I appreciate that the first two in this list are found in their respective sections. However, there is no guidance to IANA to extract those values as such. -- Per the Reference field value, is a section number permitted? No other current entry in this registry includes a section number. The definition of references from RFC7012 doesn’t seem to account for it either -- “reference - Identifies additional specifications that more precisely define this item or provide additional context for its use.”
Thank you to Joel M. Halpern for the GENART review.
# Éric Vyncke, INT AD, comments for draft-ietf-opsawg-ipfix-tcpo-v6eh-16 Thank you for the work put into this document. Please find below one blocking some non-blocking COMMENT points (but replies would be appreciated even if only for my own education), and one nit. Special thanks to Thomas Graf for the shepherd's detailed write-up including the WG consensus and the justification of the intended status. I hope that this review helps to improve the document, Regards, -éric # COMMENTS (non-blocking) ## Section 3 Suggest using the IE acronym rather than "Information Element" in the subsections of this section. ## Section 3.1 s/Type of an IPv6 extension header observed *in packets* of this Flow./Type of an IPv6 extension header observed *in at least one packet* of this Flow./ ? (or "in some packets") ## Section 3.2 I was wondering about this IE and the previous one as they looked quite atomic (plus the use of "consecutive") until I read the specification of ipv6ExtensionHeaderTypeCountList. Suggest adding a forward reference to section 3.4 and add some text that those 2 IEs can only occur in ipv6ExtensionHeaderTypeCountList. E.g., "This atomic IE MAY only occur in ipv6ExtensionHeaderTypeCountList as specified in section 3.4". ## Section 3.3 It took me to read until section 8.4.1 to understand the the bit number is *NOT* the extension header type per RFC 8200. It is really confusing with `The "No Next Header" (59) value` text, which I also read as bit 59. Strongly suggest adding a note on the value referring to NEW_IPFIX_IPv6EH_SUBREGISTRY not only in "Additional Information" but in "Description" (as it is really normative). ## Section 3.4 `How an implementation disambiguates between unknown upper-layer protocols vs. extension headers is not IPFIX-specific` is true but why not specifying the expected behavior of the collector at least? Citing RFC 8883 as an example, does not really help in a PS. Alternatively, the IANA NEW_IPFIX_IPv6EH_SUBREGISTRY could redefine UNK as "unknown extension or transport header". ## Sections 3.5 & 3.6 Excellent idea :-) Thanks ## Missing RH Type ? It would be really to be able to also export the Routing Header type, perhaps in an optional new IE following ipv6ExtensionHeaderType in the list or by adding more values in NEW_IPFIX_IPv6EH_SUBREGISTRY (cfr also section 8.4.2 `For example, a registration may request two bits for a new EH to cover specific behaviors or uses of that EH.`)? ## Section 4.1 `The value of tcpOptionsFull IE may be encoded in fewer octets` should it rather be a "SHOULD" (with explanations about the consequences of bypassing the SHOULD) ? s/The presence of tcpSharedOptionExID16List or tcpSharedOptionExID32List IEs is an indication that a shared TCP option (Kind=253 or 254) is observed in a Flow./The presence of tcpSharedOptionExID16List (Kind=253) or tcpSharedOptionExID32List (Kind=254) IEs is an indication that a shared TCP option is observed in a Flow./ ? ## Sections 4.2 and 4.3 Same comment as in sections 3.2 and 3.3. ## Section 5 Should it be an "Implementation Consideration" ? # NITS (non-blocking / cosmetic) ## Section 3.4 Should plural form be used for "header" in the example ?
Thanks to Tero Kivinen for multiple secdir reviews.
# Internet AD comments for draft-ietf-opsawg-ipfix-tcpo-v6eh-17 CC @ekline * comment syntax: - https://github.com/mnot/ietf-comments/blob/main/format.md * "Handling Ballot Positions": - https://ietf.org/about/groups/iesg/statements/handling-ballot-positions/ ## Comments ### S3.6 * "reported that IPv6 packets with extension headers are often dropped" A useful citation here might be RFC 7872, "Observations on the Dropping of Packets with IPv6 Extension Headers in the Real World". ## Nits ### S3.4 * "the occurrences of the Fragment headers" -> "the occurrence of the Fragment header" to match the example scenario's description.
Thanks for this document. I have one suggestion -- even though the update to the IANA registry is sufficient to deprecate ipv6ExtensionHeaders and tcpOptions, it seems to me it would be a courtesy to future users of RFC 5102 if you also used the Updates: header to indicate that 5102 is updated to deprecate these elements, instead of requiring them to discover this (perhaps late in their journey) by examining the registry. (Now that I look at this a little harder, I see that although the registry points to 5102, that RFC is obsoleted by 7012, so the chain of pointers is already messy. It would still be nice to use Updates: but presumably pointing to 7012... and I wonder if the registry should be updated to reference 5102 throughout, the note at the top of it notwithstanding. But that is a problem for another day.)
Thanks for working on this specification. Thanks to Wesley Eddy for his TSVART review. I think this specification is OK to publish from tranpsport protocol perspective. However, this specification deprecates tcpOptions IE without updating (or obsolating) RFC 5102, so I am unsure about the operational issues and usage of the new IEs when we have tcpOption IE. Hence supporting Paul's discuss. One question - - Section 4.1: it says "This approach allows an observer to export any observed TCP option even if it does support that option and without requiring updating a mapping table" Do you mean "even if it does *not* support that option"?