Extended TCP Options and IPv6 Extension Headers IPFIX Information Elements
draft-ietf-opsawg-ipfix-tcpo-v6eh-18
Yes
Mahesh Jethanandani
No Objection
Gunter Van de Velde
Jim Guichard
Orie Steele
Warren Kumari
Note: This ballot was opened for revision 16 and is now closed.
Mahesh Jethanandani
Yes
Éric Vyncke
Yes
Comment
(2024-07-02 for -16)
Sent
# É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 ?
Deb Cooley
No Objection
Comment
(2024-07-09 for -17)
Not sent
Thanks to Tero Kivinen for multiple secdir reviews.
Erik Kline
No Objection
Comment
(2024-07-05 for -17)
Sent
# 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.
Gunter Van de Velde
No Objection
Jim Guichard
No Objection
John Scudder
No Objection
Comment
(2024-07-09 for -17)
Sent
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.)
Orie Steele
No Objection
Paul Wouters
(was Discuss)
No Objection
Comment
(2024-08-16)
Sent
Thanks for addressing my concerns. I have updated my ballot to No Objection.
Roman Danyliw
(was Discuss)
No Objection
Comment
(2024-07-09)
Sent for earlier
Thank you to Joel M. Halpern for the GENART review.
Warren Kumari
No Objection
Zaheduzzaman Sarker
No Objection
Comment
(2024-07-11 for -17)
Sent
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"?