Éric Vyncke has entered the following ballot position for draft-ietf-opsawg-ipfix-on-path-telemetry-20: No Objection
When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/ for more information about how to handle DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-opsawg-ipfix-on-path-telemetry/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- # Éric Vyncke, INT AD, comments for draft-ietf-opsawg-ipfix-on-path-telemetry-20 CC @evyncke Thank you for the work put into this document. Please find below some non-blocking COMMENT points/nits (replies would be appreciated even if only for my own education). I also second many Gunter's points (about "mean" and IANA). Special thanks to Giuseppe Fioccola for the shepherd's detailed write-up including the WG consensus and the justification of the intended status. Other thanks to Tim Wicinski, the Internet directorate reviewer (at my request), please consider this int-dir review: https://datatracker.ietf.org/doc/review-ietf-opsawg-ipfix-on-path-telemetry-20-intdir-telechat-wicinski-2025-08-02/ I hope that this review helps to improve the document, Regards, -éric ## COMMENTS (non-blocking) ### Abstract Abstract should be short of course but this one is too succinct IMHO: be specific about encapsulating/decapsulating node (i.e., OAM header encaps and not VPN encaps) + a reference to RFC 9232 would be useful. ### Section 1 The term 'delay' is ambiguous in the IETF context... is it end to end ? serialisation ? propagation ? Only the 2nd paragraph explains it. s/postcard mode, where the metrics are also exposed in transit nodes/postcard mode, where the metrics are also exposed *by* transit nodes/ ? Again `decapsulating nodes` suggest using "OAM header decapsulating nodes". Unsure whether the next text is useful in an introduction and is not also easy to parse `Following the guidelines for Registered ... even if they are performed using different implementations and in different networks.` To make a much nicer HTML rendering, suggest using the aasvg too to generate SVG graphics. It is worth a try especially if the I-D uses the Kramdown file format ;-) `and/or the sum of measured path delay` it is unclear why there is a "and/or" and what is the "sum" here ? The accumulated delay by all segments or the sum of all delays locally computed ? If the latter, does it have any statistical value in the absence of sample count ? ### Section 3.3.2 [I-D.zhou-ippm-enhanced-alternate-marking] and [I-D.fz-spring-srv6-alt-mark] are clearly *normative* references. ### Section 3.3.5 Is the `host A Role` defined somewhere ? Add a forward reference ? or why not using "initiator" ? It seems to overly add some complexity. ### Section 3.3.6 The terms should rather be defined in the terminology section. ### Section 6.2 In 2025, does a division have a significant CPU impact when compared to other factors ? ### Section 6.4 Who is the "we" in `we might miss the temporal distribution` ? The authors ? The WG ? The IETF ? Please avoid using "we" in an I-D. ### Section 6.5 s/IPv6 options header/IPv6 *extensions* header/ ### Appendix A THANKS for the IPv6 examples ;-) s/us/µs/ as UTF-8 encoding is supported in I-D. _______________________________________________ OPSAWG mailing list -- [email protected] To unsubscribe send an email to [email protected]
