Hi Thomas, all,
Thanks for preparing the writeup. Looks good to me. I hope to receive more feedback on whether we mark these two IEs as deprecated. For forwardingStatus, I reiterate that the type should be unsigned32 as per the RFC. Cheers, Med De : thomas.g...@swisscom.com <thomas.g...@swisscom.com> Envoyé : samedi 3 février 2024 12:09 À : draft-ietf-opsawg-ipfix-fixes.auth...@ietf.org Cc : draft-ietf-opsawg-ipfix-fixes.cha...@ietf.org; opsawg@ietf.org Objet : draft-ietf-opsawg-ipfix-fixes-05 shepherd review Dear Med and Benoit, Thanks a lot. The document is straight forward and is a very valuable contribution to the Internet community since it updates existing IPFIX entities to make them consistent, which is for IPFIX data collections which obtain the information from the IPFIX IANA registry especially relevant, have references to other registries instead of re-defining them eases the update procedures in the future and last but not least updating some of the descriptions due to shortcomings for more clarity. I have reviewed the document and wrote the initial shepherd review. https://datatracker.ietf.org/doc/draft-ietf-opsawg-ipfix-fixes/shepher dwriteup/ I am looking forward for the feedback from the OPSAWG mailing list wherever ipv6ExtensionHeaders and tcpOptions in favor of ipv6ExtensionHeadersFull and tcpOptionsFull defined in draft-ietf-opsawg-ipfix-tcpo-v6eh. Depending on feedback on the mailing list, a poll at the IETF 119 maybe could be useful as well. ipv6ExtensionHeaders has been adopted by network vendors widely. Where tcpOptions appears to be, https://mailarchive.ietf.org/arch/msg/opsawg/gaJ9-A6i3Z4grgHT86OUym_DA qA/, merely used to its ambiguity. I therefore suggest to deprecate tcpOptions. I suggest also ipv6ExtensionHeaders to deprecate because not all observed extension headers in a Flow maybe export because of a hardware or software limit as described in Section 4.1.1 of this document and addressed with ipv6ExtensionHeadersLimit. As a contributor, I like also to confirm the authors opinions that forwardingStatus should be unsigned32 instead of unsigned8 not only because RFC 7270 specifies forwardingStatus as unsigned32, but it reserves 3 bytes. We have with draft-opsawg-evans-discardmodel and draft-mvmd-opsawg-ipfix-fwd-exceptions two documents showing interest to describe the forwarding behavior in IPFIX. We have on OPSAWG mailing list https://mailarchive.ietf.org/arch/browse/opsawg/?q=draft-mvmd-opsawg-i pfix-fwd-exceptions various feedback that an update, extension of forwardingStatus would be preferred instead of introducing a new IPFIX entity. Best wishes Thomas Orange Restricted
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ OPSAWG mailing list OPSAWG@ietf.org https://www.ietf.org/mailman/listinfo/opsawg
