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, [email protected] wrote: > Resending with the correct address for IANA. > > > On Apr 28, 2025, at 3:02 PM, Mahesh Jethanandani > > <[email protected]> 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 > > [email protected] <mailto:[email protected]> > > > > > > > > > > > > > > > Mahesh Jethanandani > [email protected] _______________________________________________ OPSAWG mailing list -- [email protected] To unsubscribe send an email to [email protected]
