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]
