Dear Éric, On behalf of the authors, thank you very much for your detailed review and comments.
We addressed your feedback together with Tim's, Mike's, Med's, Deb's, Gunter's, Greg's and Gorry's as following https://author-tools.ietf.org/diff?doc_1=draft-ietf-opsawg-ipfix-on-path-telemetry-20&url_2=https://raw.githubusercontent.com/network-analytics/draft-ietf-opsawg-ipfix-on-path-telemetry/refs/heads/main/draft-ietf-opsawg-ipfix-on-path-telemetry-21.txt EV> In 2025, does a division have a significant CPU impact when compared to other factors ? It can depending on implementation. During the specification phase, we interacted with several implementors and received feedback that such limitations can occur depending on software and hardware constraints on the network processor. Therefore the authors concluded to add pathDelaySumDeltaMicroseconds and describe in section 7.2 how this could be offloaded from the network node to the collector. EV> [I-D.zhou-ippm-enhanced-alternate-marking] and [I-D.fz-spring-srv6-alt-mark] are clearly *normative* references. I believe you are refering to the "Packet Stream Generation" section. The "IP One-Way Delay Hybrid Type I Passive Performance Metrics" describes a generic metric definition is defined as per RFC 8911. The "Packet Stream Generation" section contains two normative sentences: The time when the packet is being received at the OAM header encapsulating node. The timestamp format depends on On-Path Telemetry implementation. Which were detailed in the preceding "IP One-Way Delay Hybrid Type I Passive Performance Metrics" section. For IOAM, Section 4.4.1 of [RFC9197] describes the supported timestamps. Sections 4.4.2.3 and 4.4.2.4 describe where the timestamp is being inserted. For the Enhanced Alternate Marking Method, Section 2 of [I-D.zhou-ippm-enhanced-alternate-marking] and Section 3.2 of [I-D.fz-spring-srv6-alt-mark] defines timestamp encoding and granularity. Above paragraph describes possible implementations such as IOAM or Enhanced Alternate Marking and are therefore not normative since in the preceding section, "IP One-Way Delay Hybrid Type I Passive Performance Metrics", a generic metric definition is defined as per RFC 8911. I hope this addresses your comments. Looking forward to your review. Best wishes Thomas -----Original Message----- From: Éric Vyncke via Datatracker <[email protected]> Sent: Tuesday, August 5, 2025 2:24 PM To: The IESG <[email protected]> Cc: [email protected]; [email protected]; [email protected]; [email protected] Subject: [OPSAWG]Éric Vyncke's No Objection on draft-ietf-opsawg-ipfix-on-path-telemetry-20: (with COMMENT) É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.
smime.p7s
Description: S/MIME Cryptographic Signature
_______________________________________________ OPSAWG mailing list -- [email protected] To unsubscribe send an email to [email protected]
