[OPSAWG]Re: AD review of draft-ietf-opsawg-ipfix-on-path-telemetry-17

[[e-mail]]

Dear Mahesh,



Thanks a lot for the review. Much appreciated. We addressed the editorial comments together with the comments from Mahesh and Paul as following:



https://author-tools.ietf.org/diff?doc_1=draft-ietf-opsawg-ipfix-on-path-telemetry-17&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-18.txt



There are some remaining items from Paul which we are currently reviewing.



Best wishes

Thomas

From: Mahesh Jethanandani <[e-mail]>
Sent: Tuesday, April 29, 2025 12:02 AM
To: [e-mail]
Cc: opsawg-chairs <[e-mail]>; opsawg <[e-mail]>; [e-mail]; Aitken, Paul <[e-mail]>
Subject: AD review of draft-ietf-opsawg-ipfix-on-path-telemetry-17

Be aware: This is an external email.

Hi Authors,

Thanks for putting this document together. The document has already been reviewed by several folks, so most of these comments should be easy to address.

Normally, IANA would review this document later in the process, but I would like them to review this document early, as most of the document relates to IANA. I have a separate note for Paul Aitken in the document.

Cheers.

-------------------------------------------------------------------------------
COMMENT
-------------------------------------------------------------------------------

Section 1, paragraph 0
>    Network operators usually gather and maintain some forms of
>    statistical delay view of their networks (or segments of their
>    networks).  That view is meant to help with understanding where in
>    the network, for which customer traffic or services, how much, and
>    why abnormal delay is being accumulated.  To that aim, delay-related
>    data needs to be reported from devices covering both data and control
>    planes.  In order to understand which customer traffic is affected,
>    delay-related data needs to be reported in the context of the
>    customer data-plane.  That enables network operators to quickly
>    identify when the control-plane updates the current path with a
>    different set of intermediate hops (that is, a change of the
>    forwarding path) and interfaces, how the path delay changes for which
>    customer traffic.

First of all, thanks to Martin Duke for his TSVDIR and Menachem Dodge for the OPSDIR review. I tend to agree with Martin that the document could do with an editorial review for clarity. I am therefore going to request a GENART review for the document.

I am glad that Paul Aitken took an early look (version -08) at the document, but the document now is at version -17 and I would not mind him taking one more look at it before we send it to the IESG. Thanks Paul!

Section 3.1.1.1, paragraph 1
>    IANA has allocated the numeric Identifiers TBD1, TBD2, TBD3, and TBD4
>    for the four Named Metric Entries in the following section.
>
>    RFC EDITOR NOTE: please replace TBD1, TBD2, TBD3, and TBD4.

Replace with what? Can we be more specific so there is no confusion here? If the idea is to replace TBD1 ... TBD4, with the four numeric Identifiers that IANA will allocate, can we say that explicitly?

Section 3.1.1.2, paragraph 5
>    RFC EDITOR NOTE: please replace [RFC-to-be].

Similarly, can we let the RFC Editor to know that [RFC-to-be] needs to be replaced with the RFC number that will be assigned to this document? This comment applies to every such note.

Found terminology that should be reviewed for inclusivity; see
https://www.rfc-editor.org/part2/#inclusive_language for background and more
guidance:

 * Term "his"; alternatives might be "they", "them", "their"

-------------------------------------------------------------------------------
NIT
-------------------------------------------------------------------------------

All comments below are about very minor potential issues that you may choose to
address in some way - or ignore - as you see fit. Some were flagged by
automated tools (via https://github.com/larseggert/ietf-reviewtool) so there
will likely be some false positives. There is no need to let me know what you
did with these suggestions.


"Abstract", paragraph 0
>    This document specifies new IP Flow Information Export (IPFIX)
>    Information Elements to export the On-Path Telemetry measured delay
>    on the OAM transit and decapsulating nodes.

s/delay on/delay in/

Document references draft-fz-spring-srv6-alt-mark-10, but -11 is the latest
available revision.

Section 3.4.2.2, paragraph 4
> ls on calculating this statistic. However in this case FiniteDelay or MaxDel
>                                   ^^^^^^^
A comma may be missing after the conjunctive/linking adverb "However".

Section 7.3, paragraph 1
>  packet was transmitted by the node, etc). Based on this information, differ
>                                      ^^^
A period is needed after the abbreviation "etc.".

Mahesh Jethanandani
[e-mail]<mailto:[e-mail]>