Thomas, Benoît, and Alex,

Thanks for your patience and your last week reply. The -21 and your reply are 
addressing my non-blocking comments.

About my comments about section 3.3.2, the normative vs. informative choice is 
indeed not clear cut, so let it be.
Regards

-éric


From: thomas.g...@swisscom.com <thomas.g...@swisscom.com>
Date: Thursday, 11 September 2025 at 08:57
To: Eric Vyncke (evyncke) <evyn...@cisco.com>, i...@ietf.org <i...@ietf.org>
Cc: draft-ietf-opsawg-ipfix-on-path-teleme...@ietf.org 
<draft-ietf-opsawg-ipfix-on-path-teleme...@ietf.org>, opsawg-cha...@ietf.org 
<opsawg-cha...@ietf.org>, opsawg@ietf.org <opsawg@ietf.org>, tjw.i...@gmail.com 
<tjw.i...@gmail.com>
Subject: RE: [OPSAWG]Éric Vyncke's No Objection on 
draft-ietf-opsawg-ipfix-on-path-telemetry-20: (with COMMENT)
Dear Èric,

On behalf of the authors. We received feedback from Deb, Gunter, Med and Greg 
and decided to publish revision -21.

https://author-tools.ietf.org/diff?doc_1=draft-ietf-opsawg-ipfix-on-path-telemetry-21

We are looking forward to your feedback wherever the changes addressing your 
concerns.

Best wishes
Thomas

-----Original Message-----
From: Graf Thomas, SCS-INI-NET-VNC-E2E
Sent: Friday, September 5, 2025 7:17 AM
To: 'Éric Vyncke' <evyn...@cisco.com>; 'The IESG' <i...@ietf.org>
Cc: 'draft-ietf-opsawg-ipfix-on-path-teleme...@ietf.org' 
<draft-ietf-opsawg-ipfix-on-path-teleme...@ietf.org>; 'opsawg-cha...@ietf.org' 
<opsawg-cha...@ietf.org>; 'opsawg@ietf.org' <opsawg@ietf.org>; 
'tjw.i...@gmail.com' <tjw.i...@gmail.com>
Subject: RE: [OPSAWG]Éric Vyncke's No Objection on 
draft-ietf-opsawg-ipfix-on-path-telemetry-20: (with COMMENT)

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 <nore...@ietf.org>
Sent: Tuesday, August 5, 2025 2:24 PM
To: The IESG <i...@ietf.org>
Cc: draft-ietf-opsawg-ipfix-on-path-teleme...@ietf.org; opsawg-cha...@ietf.org; 
opsawg@ietf.org; tjw.i...@gmail.com
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.


_______________________________________________
OPSAWG mailing list -- opsawg@ietf.org
To unsubscribe send an email to opsawg-le...@ietf.org

Reply via email to