Dear Alice, Similar to Benoit, in case you need an explicit approval, I approve. We already discussed the changes among the co-authors.
Regards, Alex > On 6 Apr 2026, at 19:57, Alice Russo <[email protected]> wrote: > > Thomas, > > Thank you for your reply. The revised files are here (please refresh): > https://www.rfc-editor.org/authors/rfc9951.html > https://www.rfc-editor.org/authors/rfc9951.txt > https://www.rfc-editor.org/authors/rfc9951.pdf > https://www.rfc-editor.org/authors/rfc9951.xml > > This diff file shows all changes from the approved I-D: > https://www.rfc-editor.org/authors/rfc9951-diff.html > https://www.rfc-editor.org/authors/rfc9951-rfcdiff.html (side by side) > > This diff file shows the changes made during AUTH48 thus far: > https://www.rfc-editor.org/authors/rfc9951-auth48diff.html > https://www.rfc-editor.org/authors/rfc9951-auth48rfcdiff.html (side by side) > > We will wait to hear from you again regarding the remaining quetsions and > from your coauthors before continuing the publication process. This page > shows the AUTH48 status of your document: > https://www.rfc-editor.org/auth48/rfc9951 > > Thank you. > > Alice Russo > RFC Production Center > >> On Apr 2, 2026, at 12:08 AM, <[email protected]> >> <[email protected]> wrote: >> >> Dear Alice, >> >> Many thanks! Well done! >> >> I reviewed the changes with my co-authors and they all look well. I only >> have some minor input below. Everything else if perfectly fine as you >> proposed. >> >> Best wishes >> Thomas >> >> 1 >> --- >> Keywords: Flow Record, Performance Metric, On-Path, Hybrid Type I, OAM >> >> >> 2 >> --- >> OLD: >> This correlation enables the detection of changes in >> forwarding paths, such as updated intermediate hops or interfaces, >> and the resulting impact on delay experienced by customer traffic. >> >> NEW: >> This correlation enables the detection of changes in >> forwarding paths, such as updated intermediate hops or interfaces, >> and of the resulting impact on delay experienced by customer traffic. >> >> >> 3 >> --- >> OLD: >> This category includes multiple indexes of the registered performance >> metrics: the element Identifier and Metric Name. >> >> NEW: >> This category includes multiple indexes of the registered performance >> metrics: the Identifier and Metric Name. >> >> RFC editor remark: Identifier refers to >> https://datatracker.ietf.org/doc/html/rfc8911#section-11.1.1 and Metric Name >> to https://datatracker.ietf.org/doc/html/rfc8911#section-11.1.2 >> >> >> 11 >> --- >> OLD: >> The mean (average) path delay can be calculated by dividing the >> pathDelaySumDeltaMicroseconds(533) by the packetDeltaCount(2) at the >> IPFIX data collection in order to offload the IPFIX Exporter from >> calculating the mean for every Flow at export time. >> >> NEW: >> The mean (average) path delay can be calculated by dividing the >> pathDelaySumDeltaMicroseconds(533) by the packetDeltaCount(2) at the >> IPFIX data collection at the collection time instead of the IPFIX Exporter >> at >> the export time. >> >> RFC editor remark: The sentence can optionally be further simplified by >> removing "at the collection" and "at the export time". >> >> >> 18 >> --- >> OLD: flow record >> NEW: Flow Record >> >> OLD: Singleton >> NEW: singleton >> >> >> -----Original Message----- >> From: [email protected] <[email protected]> >> Sent: Tuesday, March 31, 2026 7:49 AM >> To: Graf Thomas, SCS-INI-NET-VNC-E2E <[email protected]>; >> [email protected]; [email protected] >> Cc: [email protected]; [email protected]; [email protected]; >> [email protected]; [email protected]; >> [email protected] >> Subject: Re: AUTH48: RFC-to-be 9951 >> <draft-ietf-opsawg-ipfix-on-path-telemetry-23> for your review >> >> >> Be aware: This is an external email. >> >> >> >> Authors, >> >> While reviewing this document during AUTH48, please resolve (as necessary) >> the following questions, which are also in the source file. >> >> 1) <!-- [rfced] Please insert any keywords (beyond those that appear in the >> title) for use on https://www.rfc-editor.org/search. --> >> >> >> 2) <!--[rfced] Please clarify this sentence. Is the intended meaning >> (i) "This correlation enables the detection of changes and of the impact." >> or >> (ii) "This correlation enables the detection and the impact."? >> >> Original: >> This correlation enables the detection of changes in >> forwarding paths, such as updated intermediate hops or interfaces, >> and the resulting impact on delay experienced by customer traffic. >> >> Perhaps (assuming (i), adding a second "of"): >> This correlation enables the detection of changes in >> forwarding paths, such as updated intermediate hops or interfaces, >> and of the resulting impact on delay experienced by customer traffic. >> >> Or (assuming (i), for more precision): >> This correlation enables the detection of (a) changes in >> forwarding paths, such as updated intermediate hops or interfaces, >> and (b) the resulting impact on delay experienced by customer traffic. >> --> >> >> >> 3) <!--[rfced] Should "element Identifier" be "Information Element >> identifier"? >> The latter term is used in RFC 7011 (which you had mentioned in the intake >> form). >> >> Original: >> This category includes multiple indexes of the registered performance >> metrics: the element Identifier and Metric Name. >> --> >> >> >> 4) <!--[rfced] FYI, we added "is" to make the 2nd sentence complete in each >> definition below. Please let us know if a different meaning was intended. >> For example: >> >> Original: >> The measurement of one-way delay based on a single Observation Point >> [RFC7011] somewhere in the network. >> >> Current: >> The measurement of one-way delay is based on a single Observation Point >> [RFC7011] somewhere in the network. >> --> >> >> >> 5) <!-- [rfced] FYI, we corrected this section number as follows; please >> review. >> Section 2 of [RFC2330] is the copyright statement; the terms mentioned are >> defined in Section 11 of [RFC2330]. >> >> Original: >> Note that terms such as "singleton" and "sample" are defined in >> Section 2 of [RFC2330]. >> >> Perhaps: >> Note that terms such as "singleton" and "sample" are defined in >> Section 11 of [RFC2330]. >> --> >> >> >> 6) <!-- [rfced] RFC 6991 has been obsoleted by RFC 9911. We have replaced >> each citation of RFC 6991 with RFC 9911, as the section numbers seem to >> contain the data types being mentioned. Please review and let us know any >> further updates. For example: >> >> Original: or ipv6-address-no-zone value for IPv6; see Section 4 of >> [RFC6991]). >> Current: or ipv6-address-no-zone value for IPv6; see Section 4 of >> [RFC9911]). >> --> >> >> >> 7) <!--[rfced] We suggest changing "analysis choice" (4 instances) to >> "analytic choice" or "analytical choice", because "analysis" is a noun. >> We note the term "analysis choice" is only used RFC 8912. For example: >> >> Original: >> see Section 5 of [RFC6703] for background on this analysis choice. >> >> Suggested: >> see Section 5 of [RFC6703] for background on this analytic choice. >> --> >> >> >> 8) <!--[rfced] FYI, Revision Date will be updated before publication.--> >> >> >> 9) <!--[rfced] Please clarify "as defined to the following [...] >> dimensions"; should it be "as defined across the following [...] dimensions"? >> >> Original: >> The measured On-Path delay can be aggregated with Flow Aggregation as >> defined in [RFC7015] to the following device and control-plane >> dimensions [IANA-IPFIX] to determine: >> >> Perhaps: >> The measured On-Path delay can be aggregated with Flow Aggregation as >> defined in [RFC7015] across the following device and control-plane >> dimensions [IANA-IPFIX] to determine: >> --> >> >> >> 10) <!-- [rfced] FYI, we simplified this sentence as follows; please review. >> >> Original: >> Let us consider the example depicted in Figure 1 from Section 1 as >> topology example. >> >> Current: >> Let us consider Figure 1 as a topology example. >> --> >> >> >> 11) <!--[rfced] How may this be rephrased to avoid the odd phrase "offload >> the IPFIX Exporter from calculating the mean"? >> Specifically, rather than "offload X from doing a task", we can offload the >> task - or we can offload X by doing the task elsewhere. >> >> Original: >> The mean (average) path delay can be calculated by dividing the >> pathDelaySumDeltaMicroseconds(533) by the packetDeltaCount(2) at the >> IPFIX data collection in order to offload the IPFIX Exporter from >> calculating the mean for every Flow at export time. >> >> Perhaps ("offload" changed to "prevent"): >> The mean (average) path delay can be calculated by dividing the >> pathDelaySumDeltaMicroseconds(533) by the packetDeltaCount(2) at the >> IPFIX data collection in order to prevent the IPFIX Exporter from >> calculating the mean for every Flow at export time. >> --> >> >> >> 12) <!--[rfced] We suggest changing "being accounted" to "being counted" >> here. >> Please review the intended meaning. >> >> Original: >> Unsigned64 has been chosen as type for pathDelaySumDeltaMicroseconds >> to support cases with large delay numbers and where many packets are >> being accounted. >> >> Perhaps: >> Unsigned64 has been chosen as type for pathDelaySumDeltaMicroseconds >> to support cases with large delay numbers and where many packets are >> being counted. >> --> >> >> >> 13) <!--[rfced] Should "node" be plural "nodes"? In other words, is this >> about both an intermediate node and decapsulating node? >> Also, is it accurate that "on-path delay" should be "On-Path delay" as it is >> elsewhere in this document? >> >> Original: >> [...] and be read at the OAM header intermediate and decapsulating >> node to calculate the on-path delay. >> >> Perhaps: >> [...] and be read at the OAM header intermediate and decapsulating >> nodes to calculate the On-Path delay. >> --> >> >> >> 14) <!--[rfced] Is the intended meaning that attacks by the receiver may be >> possible? If so, we suggest changing "for" to "by" or rephrasing otherwise. >> >> Original: >> For example, exporting delay metrics may make attacks possible for >> the receiver of this information; ... >> >> Perhaps: >> For example, exporting delay metrics may make attacks possible by >> the receiver of this information; ... >> --> >> >> >> 15) <!-- [rfced] [RFC7012] is not cited in the text. Please let us know >> where it should be cited; otherwise it will be deleted from the references >> section. >> >> [RFC7012] Claise, B., Ed. and B. Trammell, Ed., "Information Model for >> IP Flow Information Export (IPFIX)", RFC 7012, DOI 10.17487/RFC7012, >> September 2013, <https://www.rfc-editor.org/info/rfc7012>. >> --> >> >> >> 16) <!-- [rfced] FYI, this sentence has been updated to remove the pointer >> to Section 1. Rationale: Figure 1 is specific enough for the reader to find >> the information. And it's in Section 3, not Section 1. >> >> Original: >> Taking Figure 1 from Section 1 as topology example. >> >> Current: >> Let's take Figure 1 as a topology example. >> --> >> >> >> 17) <!--[rfced] For Table 4, is it correct that the column headers are >> intended as the names of the IEs? If so, we recommend rotating the table (so >> the column headers become the first column) as shown in the edited document. >> Please review and let us know any updates, or if you want to revert to the >> previous format. (We note that Table 2 also adds spaces into IE names, >> perhaps in order get line breaks within the cell; please let us know if >> you'd like to make any updates to Table 2.) >> >> Original (column headers): >> path Delay Mean Delta Micro.. >> path Delay Min Delta Micro.. >> path Delay Max Delta Micro.. >> >> Perhaps intended as the IE names: >> pathDelayMeanDeltaMicroseconds >> pathDelayMinDeltaMicroseconds >> pathDelayMaxDeltaMicroseconds >> --> >> >> >> 18) <!--[rfced] Terminology: Please review usage of these terms and let us >> know if any updates should be made for consistency. >> >> Flow Record (8 instances) vs. flow record (1 instance) >> >> Singleton (2 instances) vs. singleton (5 instances) >> --> >> >> >> 19) <!-- [rfced] Please review the "Inclusive Language" portion of the >> online Style Guide >> <https://www.rfc-editor.org/styleguide/part2/#inclusive_language> >> and let us know if any changes are needed. Updates of this nature typically >> result in more precise language, which is helpful for readers. >> >> Note that our script did not flag any words in particular, but this should >> still be reviewed as a best practice. >> --> >> >> >> Thank you. >> >> Alice Russo >> RFC Production Center >> >> On Mar 30, 2026, [email protected] wrote: >> >>> *****IMPORTANT***** >>> >>> Updated 2026/03/30 >>> >>> RFC Author(s): >>> -------------- >>> >>> Instructions for Completing AUTH48 >>> >>> Your document has now entered AUTH48. Once it has been reviewed and >>> approved by you and all coauthors, it will be published as an RFC. >>> If an author is no longer available, there are several remedies >>> available as listed in the FAQ (https://www.rfc-editor.org/faq/). >>> >>> You and you coauthors are responsible for engaging other parties >>> (e.g., Contributors or Working Group) as necessary before providing >>> your approval. >>> >>> Planning your review >>> --------------------- >>> >>> Please review the following aspects of your document: >>> >>> * RFC Editor questions >>> >>> Please review and resolve any questions raised by the RFC Editor >>> that have been included in the XML file as comments marked as >>> follows: >>> >>> <!-- [rfced] ... --> >>> >>> These questions will also be sent in a subsequent email. >>> >>> * Changes submitted by coauthors >>> >>> Please ensure that you review any changes submitted by your >>> coauthors. We assume that if you do not speak up that you >>> agree to changes submitted by your coauthors. >>> >>> * Content >>> >>> Please review the full content of the document, as this cannot >>> change once the RFC is published. Please pay particular attention to: >>> - IANA considerations updates (if applicable) >>> - contact information >>> - references >>> >>> * Copyright notices and legends >>> >>> Please review the copyright notice and legends as defined in >>> RFC 5378 and the Trust Legal Provisions >>> (TLP - https://trustee.ietf.org/license-info). >>> >>> * Semantic markup >>> >>> Please review the markup in the XML file to ensure that elements of >>> content are correctly tagged. For example, ensure that <sourcecode> >>> and <artwork> are set correctly. See details at >>> <https://authors.ietf.org/rfcxml-vocabulary>. >>> >>> * Formatted output >>> >>> Please review the PDF, HTML, and TXT files to ensure that the >>> formatted output, as generated from the markup in the XML file, is >>> reasonable. Please note that the TXT will have formatting >>> limitations compared to the PDF and HTML. >>> >>> >>> Submitting changes >>> ------------------ >>> >>> To submit changes, please reply to this email using 'REPLY ALL' as all >>> the parties CCed on this message need to see your changes. The parties >>> include: >>> >>> * your coauthors >>> >>> * [email protected] (the RPC team) >>> >>> * other document participants, depending on the stream (e.g., >>> IETF Stream participants are your working group chairs, the >>> responsible ADs, and the document shepherd). >>> >>> * [email protected], which is a new archival mailing list >>> to preserve AUTH48 conversations; it is not an active discussion >>> list: >>> >>> * More info: >>> >>> https://mail/ >>> archive.ietf.org%2Farch%2Fmsg%2Fietf-announce%2Fyb6lpIGh-4Q9l2USxIAe6P >>> 8O4Zc&data=05%7C02%7CThomas.Graf%40swisscom.com%7Cb222fdce8ad44e6613f0 >>> 08de8ee952ea%7C364e5b87c1c7420d9beec35d19b557a1%7C0%7C0%7C639105330081 >>> 672710%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDA >>> wMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sda >>> ta=ljqVoPzwL3ziA7XwO6JmZfIFRB%2Br3aDNSEfBRTVxoWo%3D&reserved=0 >>> >>> * The archive itself: >>> >>> https://mail/ >>> archive.ietf.org%2Farch%2Fbrowse%2Fauth48archive%2F&data=05%7C02%7CTho >>> mas.Graf%40swisscom.com%7Cb222fdce8ad44e6613f008de8ee952ea%7C364e5b87c >>> 1c7420d9beec35d19b557a1%7C0%7C0%7C639105330081686639%7CUnknown%7CTWFpb >>> GZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkF >>> OIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=9eaz%2FeoKT0R2e442ve6 >>> i2zzLpYwL%2B1lUzp1wgatt6B4%3D&reserved=0 >>> >>> * Note: If only absolutely necessary, you may temporarily opt out >>> of the archiving of messages (e.g., to discuss a sensitive matter). >>> If needed, please add a note at the top of the message that you >>> have dropped the address. When the discussion is concluded, >>> [email protected] will be re-added to the CC list and >>> its addition will be noted at the top of the message. >>> >>> You may submit your changes in one of two ways: >>> >>> An update to the provided XML file >>> - OR - >>> An explicit list of changes in this format >>> >>> Section # (or indicate Global) >>> >>> OLD: >>> old text >>> >>> NEW: >>> new text >>> >>> You do not need to reply with both an updated XML file and an explicit >>> list of changes, as either form is sufficient. >>> >>> We will ask a stream manager to review and approve any changes that >>> seem beyond editorial in nature, e.g., addition of new text, deletion >>> of text, and technical changes. Information about stream managers can >>> be found in the FAQ. Editorial changes do not require approval from a >>> stream manager. >>> >>> >>> Approving for publication >>> -------------------------- >>> >>> To approve your RFC for publication, please reply to this email >>> stating that you approve this RFC for publication. Please use 'REPLY >>> ALL', as all the parties CCed on this message need to see your approval. >>> >>> >>> Files >>> ----- >>> >>> The files are available here: >>> https://www.rfc-editor.org/authors/rfc9951.xml >>> https://www.rfc-editor.org/authors/rfc9951.html >>> https://www.rfc-editor.org/authors/rfc9951.pdf >>> >>> https://www/. >>> rfc-editor.org%2Fauthors%2Frfc9951.txt&data=05%7C02%7CThomas.Graf%40sw >>> isscom.com%7Cb222fdce8ad44e6613f008de8ee952ea%7C364e5b87c1c7420d9beec3 >>> 5d19b557a1%7C0%7C0%7C639105330081735016%7CUnknown%7CTWFpbGZsb3d8eyJFbX >>> B0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIs >>> IldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=wp%2BcMbAPrxTvFN4AGRcIf%2FpKR578oF >>> bwAg%2BQZsqW62Y%3D&reserved=0 >>> >>> Diff file of the text: >>> https://www.rfc-editor.org/authors/rfc9951-diff.html >>> >>> https://www/. >>> rfc-editor.org%2Fauthors%2Frfc9951-rfcdiff.html&data=05%7C02%7CThomas. >>> Graf%40swisscom.com%7Cb222fdce8ad44e6613f008de8ee952ea%7C364e5b87c1c74 >>> 20d9beec35d19b557a1%7C0%7C0%7C639105330081758944%7CUnknown%7CTWFpbGZsb >>> 3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjo >>> iTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=0XtOV9y%2BvNXnvH2tSqqsltt >>> s%2BOlybWTDw1sz6DNWn4U%3D&reserved=0 (side by side) >>> >>> Diff of the XML: >>> >>> https://www/. >>> rfc-editor.org%2Fauthors%2Frfc9951-xmldiff1.html&data=05%7C02%7CThomas >>> .Graf%40swisscom.com%7Cb222fdce8ad44e6613f008de8ee952ea%7C364e5b87c1c7 >>> 420d9beec35d19b557a1%7C0%7C0%7C639105330081770784%7CUnknown%7CTWFpbGZs >>> b3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIj >>> oiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=hRqXcqPXYic2UAiuuBuIcf%2 >>> BGMGlXd%2Fbs1ZgpD1bHMVg%3D&reserved=0 >>> >>> >>> Tracking progress >>> ----------------- >>> >>> The details of the AUTH48 status of your document are here: >>> >>> https://www/. >>> rfc-editor.org%2Fauth48%2Frfc9951&data=05%7C02%7CThomas.Graf%40swissco >>> m.com%7Cb222fdce8ad44e6613f008de8ee952ea%7C364e5b87c1c7420d9beec35d19b >>> 557a1%7C0%7C0%7C639105330081782563%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1 >>> hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUI >>> joyfQ%3D%3D%7C0%7C%7C%7C&sdata=mMyly9toR8OIcqcOji605EBvRgYMy1pcTFZ3nWJ >>> %2F1xM%3D&reserved=0 >>> >>> Please let us know if you have any questions. >>> >>> Thank you for your cooperation, >>> >>> RFC Editor >>> >>> -------------------------------------- >>> RFC9951 (draft-ietf-opsawg-ipfix-on-path-telemetry-23) >>> >>> Title : Export of Delay Performance Metrics in IP Flow >>> Information Export (IPFIX) >>> Author(s) : T. Graf, B. Claise, A. Huang-Feng >>> WG Chair(s) : Joe Clarke, Benoît Claise >>> Area Director(s) : Mohamed Boucadair, Mahesh Jethanandani > > > > > > -- auth48archive mailing list -- [email protected] To unsubscribe send an email to [email protected]
