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

[Sabrina Tanamal via RT <[e-mail]>]

Hi Mahesh, all, 

Version -17 looks good. We'll provide our official review once the document gets to IETF Last Call. 

Thank you!

Sabrina

On Mon Apr 28 22:08:26 2025, [e-mail] wrote:
> Resending with the correct address for IANA.
> 
> > On Apr 28, 2025, at 3:02 PM, Mahesh Jethanandani
> > <[e-mail]> wrote:
> >
> > 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
> > <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
> > <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]>
> >
> >
> >
> >
> >
> >
> 
> 
> Mahesh Jethanandani
> [e-mail]