Dear Med and Benoit, Thanks a lot. The document is very well written and straight forward. As shared previously during the working group, I believe this document is very valuable to network operators since it addresses current issues in the observation of IPv6 headers and TCP options.
I have reviewed the document and wrote the initial shepherd review https://datatracker.ietf.org/doc/draft-ietf-opsawg-ipfix-tcpo-v6eh/shepherdwriteup/. I agree with the points from the IPFIX doctor and the Transport area in regards to the comments made to the data type choice for tcpOptionsFull, tcpSharedOptionExID16 and tcpSharedOptionExID32. Mirroring my concerns previously shared in the review of draft-ietf-opsawg-tsvwg-udp-ipfix with udpExpOptionExID and udpUnsafeExpOptionExID. I suggest to change the sentence from "Because some of these limitations cannot be addressed" to "Because some of these issues cannot be addressed" which is used in several occasions in the document. I suggest in section 3.1, to extend the paragraph Regarding "exported in separate ipv6ExtensionHeadersFull IEs" described in Section 3.1, I assume this refers to Section 8 of RFC 7011 (https://datatracker.ietf.org/doc/html/rfc7011#section-8) where If an Information Element is required more than once in a Template, the different occurrences of this Information Element SHOULD follow the logical order of their treatments by the Metering Process. Is described. If yes, I suggest to reference. If not, to clarify the meaning within the document. Here are some nits I found. replace headerss with headers replace octers with octets Otherwise all perfect. Best wishes Thomas
smime.p7s
Description: S/MIME Cryptographic Signature
_______________________________________________ OPSAWG mailing list OPSAWG@ietf.org https://www.ietf.org/mailman/listinfo/opsawg
