Hi Benoit, Re: > I am not too just what you expect from us here? > If it's just the approval, I approved.
Today's mail was the first mail that we received from you regarding 9951. We've recorded your approval on this page: http://www.rfc-editor.org/auth48/rfc9951 The following questions remain open: - Amanda's questions re: IANA actions in this mail [1] - questions 7, 9, 11-15, and 17 from the RPC [2] [1] https://mailarchive.ietf.org/arch/msg/auth48archive/IH7s1qYUQYs1M0ymV3KA3flNJYg/ [2] https://mailarchive.ietf.org/arch/msg/auth48archive/i1orRmYbLR68oanbXxBHMkXNgzY/ Thank you. Alice Russo RFC Production Center > On Apr 8, 2026, at 3:18 AM, [email protected] > <[email protected]> wrote: > > Hi Alice, > > "We will wait to hear from you again regarding the remaining quetsions and > from your coauthors before continuing the publication process." I am not too > just what you expect from us here? > If it's just the approval, I approved. > > Regards, Benoit > > > On 06/04/2026 19:57, Alice Russo 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]
