Ballot for draft-ietf-opsawg-ipfix-tcpo-v6eh
Yes
No Objection
No Record
Summary: Needs 5 more YES or NO OBJECTION positions to pass.
# É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 ?
# 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.