Dear Len, Ruediger, and *Med (AD), Thank you for your replies. We have updated our files accordingly. Ruediger, we have noted your approval on the AUTH48 status page (https://www.rfc-editor.org/auth48/rfc9946). Len, please review the updates and let us know if any further changes are needed or if you approve the document in its current form.
*Med, as AD, please review the beyond editorial changes made to Figure 11 (Section 7.2) and let us know if you approve (https://www.rfc-editor.org/authors/rfc9946-auth48diff.html). —Files (please refresh)— We will await approvals from Med and Len prior to moving forward in the publication process. Updated XML file: https://www.rfc-editor.org/authors/rfc9946.xml Updated output files: https://www.rfc-editor.org/authors/rfc9946.txt https://www.rfc-editor.org/authors/rfc9946.pdf https://www.rfc-editor.org/authors/rfc9946.html Diff files showing all changes made during AUTH48: https://www.rfc-editor.org/authors/rfc9946-auth48diff.html https://www.rfc-editor.org/authors/rfc9946-auth48rfcdiff.html (side by side) Diff files showing only the changes made during the last edit round: https://www.rfc-editor.org/authors/rfc9946-lastdiff.html https://www.rfc-editor.org/authors/rfc9946-lastrfcdiff.html (side by side) Diff files showing all changes: https://www.rfc-editor.org/authors/rfc9946-diff.html https://www.rfc-editor.org/authors/rfc9946-rfcdiff.html (side by side) Best regards, Karen Moore RFC Production Center > On Mar 18, 2026, at 8:34 AM, Len Ciavattone <[email protected]> wrote: > > Karen, > Here are a few things I found doing a full review... > > Section 3.2 > Change "the tool" to "UDPSTP" (given that the RFC describes a protocol and > not a tool) > "Unrestricted use of the tool could lead to traffic starvation..." should be > changed to "Unrestricted use of UDPSTP could lead to traffic starvation..." > > Section 4.6 > “used in the IPv4 packet Header Chesksum specification (see Section 3.1 of > [RFC0791]).” > Misspelled “Checksum” > > Section 5.1 > “maxBandwith: A two-octet field. ..." > Misspelled "maxBandwidth" > > Section 7.1 > Change "discreet" (cautious) to "discrete" (separate) > "it SHALL use the discreet transmission" should be "it SHALL use the discrete > transmission" > > Section 7.2 > The indentation after "sisSav: Sub-Interval statistics...", which should only > include fields "rxDatagrams:" through "accumTime:", should revert back to no > indentation starting at "clockDeltaMin:". This is where the parent structure > fields start again. > > Section 7.2, Figure 11 (two issues with "struct subIntStats {...}") > 1) Fields "rttMinimum" and "rttMaximum" should be "rttVarMinimum" and > "rttVarMaximum" to match what is shown in figure 10 and described in the text > as "rttVarMinimum/rttVarMaximum (in sisSav): Two four-octet fields...". Also, > the comments for these fields should be updated to reflect this (see below). > 2) The structure should be enclosed within "#pragma pack(push, 1)" and > "#pragma pack(pop)" statements for proper C memory alignment. > Here is the updated structure (also, please keep the comments aligned > appropriately): > #pragma pack(push, 1) > struct subIntStats { > uint32_t rxDatagrams; // Received datagrams > uint64_t rxBytes; // Received bytes (64 bits) > uint32_t deltaTime; // Time delta (us) > uint32_t seqErrLoss; // Loss sum > uint32_t seqErrOoo; // Out-of-order sum > uint32_t seqErrDup; // Duplicate sum > uint32_t delayVarMin; // Delay variation minimum (ms) > uint32_t delayVarMax; // Delay variation maximum (ms) > uint32_t delayVarSum; // Delay variation sum (ms) > uint32_t delayVarCnt; // Delay variation count > uint32_t rttVarMinimum; // Minimum RTT variation (ms) > uint32_t rttVarMaximum; // Maximum RTT variation (ms) > uint32_t accumTime; // Accumulated time (ms) > }; > #pragma pack(pop) > > > Thank you, > Len > > > > On Tue, Mar 17, 2026 at 3:34 PM Karen Moore <[email protected]> > wrote: > Dear Len, Ruediger, and Med, > > Thank you for the clarifications. We made 1 instance of “Loss” lowercase and > removed the reference to this document in Table 1. The updated files are > below. Please review and let us know if any further changes are needed or if > you approve the document in its current form. > > Med, please provide approval of the document on behalf of Al Morton. As AD, > please note the addition of “SHOULD” in Section 4.3.1 and the updated > language in Section 4.6 when performing your review (see > <https://www.rfc-editor.org/authors/rfc9946-auth48diff.html>). > > —Files (please refresh)— > > We will await approvals from each author prior to moving forward in the > publication process. > > Updated XML file: > https://www.rfc-editor.org/authors/rfc9946.xml > > Updated output files: > https://www.rfc-editor.org/authors/rfc9946.txt > https://www.rfc-editor.org/authors/rfc9946.pdf > https://www.rfc-editor.org/authors/rfc9946.html > > Diff files showing all changes made during AUTH48: > https://www.rfc-editor.org/authors/rfc9946-auth48diff.html > https://www.rfc-editor.org/authors/rfc9946-auth48rfcdiff.html (side by side) > > Diff files showing only the changes made during the last edit round: > https://www.rfc-editor.org/authors/rfc9946-lastdiff.html > https://www.rfc-editor.org/authors/rfc9946-lastrfcdiff.html (side by side) > > Diff files showing all changes: > https://www.rfc-editor.org/authors/rfc9946-diff.html > https://www.rfc-editor.org/authors/rfc9946-rfcdiff.html (side by side) > > For the AUTH48 status of this document, please see: > https://www.rfc-editor.org/auth48/rfc9946 > > Best regards, > > Karen Moore > RFC Production Center > > > > On Mar 17, 2026, at 7:56 AM, Len Ciavattone <[email protected]> wrote: > > > > Karen, > > I've included responses below marked as [Authors]. Please let me know if > > any further info is needed. > > > > Thank you, > > Len > > > > On Tue, Mar 17, 2026 at 8:20 AM <[email protected]> wrote: > > Hi Karen, hi Len, hi Med > > > > Karen, thanks for your response and further questions. Med, regarding the > > registry issue, KDF HMAC-SHA-256 , I'd prefer you to comment and help. > > Neither Len nor I are IETF registry experts. > > > > Len, I'd suggest that you reply to Karen directly regarding the open points > > apart from the above registry ref one. > > > > I've marked my comments [RG]. > > > > Regards, > > > > Ruediger > > > > -----Ursprüngliche Nachricht----- > > Von: Karen Moore <[email protected]> > > Gesendet: Dienstag, 17. März 2026 03:34 > > An: [email protected]; Geib, Rüdiger <[email protected]>; > > [email protected] > > Cc: [email protected]; [email protected]; [email protected]; > > [email protected]; [email protected] > > Betreff: Re: AUTH48: RFC-to-be 9946 <draft-ietf-ippm-capacity-protocol-25> > > for your review > > > > Dear Med, Ruediger, and Len, > > > > Thank you for your replies. We have updated our files accordingly (see > > below), and we have noted, per Med’s response, that “traditional” is okay > > to use in this RFC. We have some additional questions for the authors. > > > > 1) We added this document as a reference for the KDF entry. If this is not > > correct, please let us know. > > > > Original: > > KDF Description > > Reference > > - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - > > - - - - - - - - - - > > HMAC-SHA-256 HMAC using the SHA-256 hash [RFC6234] > > > > Current: > > KDF Description > > Reference > > - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - > > - - - - - - - - - - - - - - - - - - - - > > HMAC-SHA-256 HMAC using the SHA-256 hash [RFC6234] and RFC 9946 > > > > > [Authors] Please add the suitable xref statement, the RFC is part of the > > > normative ref's (putting it to nonmative has been requested during the > > > process). > > > > [RG] Karen, Med, I need help. I'm not a registry expert (this is my first > > one): entry "HMAC-SHA-256 HMAC using the SHA-256 hash" => this KDF > > is specified by RFC6234. If the table only is to state, that the registry > > key "KDF" "HMAC-SHA-256" is specified by RFC9946, then only referring to > > the latter may be appropriate. > > [Authors] Med can have the final word here. However, I think that since we > > only refer to "HMAC-SHA-256" as the PRF with our specific KDF (Counter > > Mode)...RFC 9946 should NOT be listed. > > > > ... > > 2) Should “Loss” be updated as “seqErrLoss”? Is the second lowercase > > “loss” correct as is? > > > > Current: > > A one-octet field. Ignore out-of-order duplicates, Boolean. When True, only > > Loss counts toward received packet sequence number errors. When False, > > loss, out-of-order, and duplicate totals are all counted as sequence number > > errors. Default is True (see also Table 3 of [TR-471]). > > > > > Loss vs. loss > > > [Authors]: s Loss / seqErrLoss > > > > [RG] My proposals worried....Len, please determine the preferred > > upper/lowercase. My understanding is, packet-loss causes a sequence error > > (seqErrLoss). Packet-loss may be meant in both instances above. > > [Authors] Please simply change "Loss" to lowercase in that sentence ("When > > True, only loss counts toward..."). > > > > … > > 3) On the first mention of “ms” and “us”, we included “milliseconds” and > > “microseconds”, respectively, in parentheses for clarity. If that is not > > desired, please let us know (see Sections 4.1 and 6.1). > > > > > [Len] Replace the terms in square brackets with just the terms...bytes > > > instead of [byte], seconds instead of s, ms for millisecond, and us for > > > microsecond > > [RG] Ooops, didn't replace [Len] by [Authors]...ok with me too! > > [Authors] Yes, it is good to be specific on the first usage of each. > > > > … > > 4) We altered the line lengths in Appendix A to fit the length limit. > > Please review to ensure everything is correct (best viewed in the output > > files). > > [RG] ok, looks good to me. > > [Authors] Yes, that is good. > > > > … > > 5) We updated the Acknowledgments section as follows. If you prefer > > different wording, please let us know. > > > > Original: > > Mohamed Boucadair's AD review improved comprehensibility of the document, > > and he further navigated the document well through the final review stages. > > > > Current: > > Mohamed Boucadair's AD review improved comprehensibility of the document, > > and he provided helpful guidance well through the final review stages. > > > > > [Authors] "Comments" are just one part, Med offered helpful guidance for > > > the process too (in more than one instance). Could you suggest some > > > suitable wording? > > [RG] Thanks, Karen, sounds good to me. > > [Authors] That looks good. > > > > > > > > --Files-- > > Note that it may be necessary for you to refresh your browser to view the > > most recent version. Please review the document carefully to ensure > > satisfaction as we do not make changes once it has been published as an RFC. > > > > Please contact us with any further updates or with your approval of the > > document in its current form. We will await approvals from each author > > prior to moving forward in the publication process. > > > > Updated XML file: > > https://www.rfc-editor.org/authors/rfc9946.xml > > > > Updated output files: > > https://www.rfc-editor.org/authors/rfc9946.txt > > https://www.rfc-editor.org/authors/rfc9946.pdf > > https://www.rfc-editor.org/authors/rfc9946.html > > > > Diff files showing all changes made during AUTH48: > > https://www.rfc-editor.org/authors/rfc9946-auth48diff.html > > https://www.rfc-editor.org/authors/rfc9946-auth48rfcdiff.html (side by > > side) > > > > Diff files showing all changes: > > https://www.rfc-editor.org/authors/rfc9946-diff.html > > https://www.rfc-editor.org/authors/rfc9946-rfcdiff.html (side by side) > > > > For the AUTH48 status of this document, please see: > > https://www.rfc-editor.org/auth48/rfc9946 > > > > Best regards, > > > > Karen Moore > > RFC Production Center > > > > > On Mar 13, 2026, at 1:23 AM, [email protected] > > > wrote: > > > > > > Hi Karen, > > > > > > thanks for your careful review and comments. We / [Authors] mostly > > > "acked" but in some cases you asked for us to change text or explain and > > > so we did. Please see in line [Authors] below... > > > > > > Regards, > > > > > > Len and Ruediger > > > > > > > > > -----Ursprüngliche Nachricht----- > > > Von: mailto:[email protected] <mailto:[email protected]> > > > Gesendet: Donnerstag, 12. März 2026 02:52 > > > An: mailto:[email protected]; Geib, Rüdiger > > > <mailto:[email protected]> > > > Cc: mailto:[email protected]; mailto:[email protected]; > > > mailto:[email protected]; mailto:[email protected]; > > > mailto:[email protected]; mailto:[email protected] > > > Betreff: [AD] Re: AUTH48: RFC-to-be 9946 > > > <draft-ietf-ippm-capacity-protocol-25> for your review > > > > > > Authors and *AD, > > > > > > While reviewing this document during AUTH48, please resolve (as > > > necessary) the following questions, which are also in the source file. > > > > > > *AD, please review question #1. > > > > > > 1) <!--[rfced] *AD, per your request and the request of the WG, we have > > > added Al Morton as an author of this document. We have also added the > > > role of "editor" for Geib Ruediger. Please let us know if Al should have > > > an affiliation listed. > > > > > > Note that when this document has completed AUTH48, we will ask you to > > > approve it on behalf of Al. > > > > > > Current Authors (header): > > > A. Morton > > > > > > L. Ciavattone > > > AT&T Labs > > > > > > R. Geib, Ed. > > > Deutsche Telekom > > > --> > > > > > > [Authors]: Thanks! > > > > > > > > > 2) <!-- [rfced] Please insert any keywords (beyond those that appear in > > > the title) for use on https://www.rfc-editor.org/search. > > > --> > > > > > > [Authors] "load rate adjustment algorithm", BUT NOT "congestion control > > > algorithm" > > > > > > > > > 3) <!--[rfced] Does "conducting RFC 9097 and other related measurements" > > > mean "conducting measurements as described in RFC 9097 and other related > > > measurements"? Please let us know how we may update for clarity. > > > > > > Original: > > > This document defines the UDP Speed Test Protocol (UDPSTP) for > > > conducting RFC 9097 and other related measurements. > > > > > > Perhaps: > > > This document defines the UDP Speed Test Protocol (UDPSTP) for > > > conducting measurements as described in RFC 9097 and other > > > related measurements. > > > --> > > > > > > [Authors] ok. > > > > > > > > > 4) <!-- [rfced] We are unsure if the quoted text was intended to be the > > > titles of or concepts in the RFCs listed. Since quote marks were present, > > > we updated the text to reflect the exact titles of the RFCs. Please let > > > us know if this is agreeable or if you prefer otherwise. > > > > > > Original: > > > The performance community has seen development of Informative Bulk > > > Transport Capacity definitions in the "Framework for Bulk Transport > > > Capacity" (BTC, see [RFC3148]) and for "Network Capacity and Maximum > > > IP-layer Capacity" [RFC5136]. "Model-Based Metrics for BTC" add > > > experimental metric definitions and methods in [RFC8337]. > > > > > > Current: > > > The performance community has seen the development of Informative > > > Bulk Transport Capacity (BTC) definitions in "A Framework for > > > Defining Empirical Bulk Transfer Capacity Metrics" [RFC3148] and > > > "Defining Network Capacity" [RFC5136] as well as experimental > > > metric definitions and methods in "Model-Based Metrics for Bulk > > > Transport Capacity" [RFC8337]. > > > --> > > > > > > [Authors] ok. > > > > > > > > > 5) <!--[rfced] FYI - We made "LMAP environments" singular to agree with > > > "another independent third-party domain measurement server deployment" as > > > shown below. Please let us know of any objections. > > > > > > Original: > > > UDPSTP may be deployed in Large-Scale Measurement of Broadband > > > Performance environments (LMAP, see [RFC7497]), another independent > > > 3rd party domain measurement server deployment. > > > > > > Current: > > > UDPSTP may be deployed in a Large-scale Measurement of Broadband > > > Performance (LMAP) environment (see [RFC7497]), another independent > > > third-party domain measurement server deployment. > > > --> > > > > > > [Authors] NEW > > > UDPSTP may be deployed in Large-Scale Measurement of Broadband > > > Performance environments (LMAP, see [RFC7497]), >>and other<< > > > independent > > > 3rd party domain measurement server >>deployments<<. > > > > > > > > > 6) <!--[rfced] Please clarify "benefit from trust into the results". Is > > > the intended meaning perhaps "benefit from trusting the results"? > > > > > > Original: > > > All these deployments require or benefit from trust into the > > > results, which are ensured by authenticated communication. > > > > > > Perhaps: > > > All these deployments require or benefit from trusting the > > > results, which are ensured by authenticated communication. > > > --> > > > > > > [Authors] ok. > > > > > > > > > 7) <!--[rfced] We don't see the terms "mcIndex", "mcCount", and "mcIdent" > > > in Section 6.1. Was Section 5.1 perhaps intended? > > > > > > Original: > > > Fields in the Setup Request (mcIndex, mcCount, and mcIdent, see > > > Section 6.1) are used to both differentiate and associate the > > > multiple connections that comprise a single test. > > > > > > Perhaps: > > > Fields in the Setup Request (i.e., mcIndex, mcCount, and mcIdent; > > > see Section 5.1) are used to both differentiate and associate the > > > multiple connections that comprise a single test. > > > --> > > > > > > [Authors] Thanks, correct assessment. That would require adapting the > > > above xref in xml to: xref="Setup-Fields" > > > > > > > > > > > > 8) <!--[rfced] Is there only one optional checksum or would it be correct > > > to make checksum plural in the title of Section 4 (for consistency with > > > "Requirements" and "Security Operations") as well as in one sentence in > > > Section 4? > > > > > > Original: > > > Section 4. Requirements, Security Operations, and Optional Checksum > > > > > > This section adds the operational specification related to security > > > and optional checksum. > > > > > > Perhaps: > > > Section 4. Requirements, Security Operations, and Optional Checksums > > > > > > This section adds the operational specification related to security > > > and optional checksums. > > > --> > > > > > > [Authors] This should remain singular as it refers to an individual PDU. > > > The plural version makes it sound like a PDU will have more than one > > > checksum. > > > > > > > > > 9) <!--[rfced] In order to avoid hyphenating "Layer-3-to-Layer-4 > > > mapping", may we rephrase this sentence as shown below? > > > > > > Original: > > > Due to the additional complexities, and loss of the direct > > > Layer 3 to Layer 4 mapping of packets to datagrams, it is > > > recommended that Layer 3 fragmentation be avoided. > > > > > > Perhaps: > > > Due to the additional complexities, and loss of the direct > > > mapping of packets to datagrams between Layer 3 and Layer 4, > > > it is recommended that Layer 3 fragmentation be avoided. > > > --> > > > > > > [Authors] ok. > > > > > > > > > 10) <!--[rfced] We are having trouble parsing this sentence. Please > > > clarify where the feedback received by the experts and the changes > > > resulting from standardization were included - was it in the measurement > > > method or testing? > > > > > > Original: > > > Feedback received by performance measurement experts was included, > > > as well as changes resulting from the standardisation of [RFC9097] > > > (reflected also in algorithm B [Y.1540Amd2], which updates a prior > > > version of this algorithm). > > > --> > > > > > > [Authors] NEW > > > Further, the load rate adjustment algorithm requirements listed below > > > reflect feedback from performance measurement experts, as well as changes > > > .... > > > > > > > > > 11) <!--[rfced] For clarity, may we update this sentence to contain a > > > serial list of the threshold values as shown below? > > > > > > Original: > > > The RECOMMENDED threshold values are 10 for sequence number gaps > > > and 30 ms for lower and 90 ms for upper delay variation thresholds, > > > respectively. > > > > > > Perhaps: > > > The RECOMMENDED threshold values are 10 for sequence number gaps, > > > 30 ms for lower delay variation thresholds, and 90 ms for upper > > > delay variation thresholds. > > > --> > > > > > > [Authors] ok. > > > > > > > > > 12) <!--[rfced] Should this sentence be updated to more closely match > > > similar wording in Section 3.1? This would also help with how "avoid > > > activating the measurement" relates to the sentence. > > > > > > Current: > > > If a network operator is certain of the IP-Layer Capacity to be > > > validated, then testing MAY start with a fixed-rate test at the > > > IP-Layer Capacity and avoid activating the measurement load rate > > > adjustment algorithm (see Section 8.1 of [RFC9097]) > > > > > > Perhaps: > > > A network operator who is certain of the IP-Layer Capacity to be > > > validated MAY start with a fixed-rate test at the IP-Layer Capacity > > > and avoid activating the measurement load rate adjustment algorithm > > > (see Section 8.1 of [RFC9097]) > > > --> > > > > > > [Authors] ok. > > > > > > 13) <!--[rfced] Should "SHOULD" be added to the latter part of this > > > sentence for clarity (i.e., "SHOULD NOT continue with the Control phase > > > and SHOULD implement silent rejection")? > > > > > > Original: > > > If the validation fails, the receiver SHOULD NOT continue with the > > > Control phase and implement silent rejection (no further packets > > > sent on the address/port pairs). > > > > > > Perhaps: > > > If the validation fails, the receiver SHOULD NOT continue with the > > > Control phase and SHOULD implement silent rejection (no further > > > packets sent on the address/port pairs). > > > --> > > > > > > [Authors] ok. > > > > > > 14) <!--[rfced] We note a variance with the terms listed in Section 4.4 > > > versus the terms listed in RFC 7210. In RFC 7210, "Time" is uppercase > > > (except in "SendLifetimeStart", which contains a lowercase "t" > > > both in this document and RFC 7210). Should this document be updated as > > > follows for consistency with RFC 7210? > > > > > > Original: > > > * SendLifetimeEnd > > > > > > * AcceptLifetimeStart > > > > > > * AcceptLifetimeEnd > > > > > > Perhaps: > > > * SendLifeTimeEnd > > > > > > * AcceptLifeTimeStart > > > > > > * AcceptLifeTimeEnd > > > --> > > > > > > [Authors] Thanks, yes, please update for consistency with RFC 7210. > > > > > > > > > 15) <!--[rfced] Does "that 4-tuple" refer to the source and destination > > > addresses and port numbers? If so, may we update the text as shown below > > > for clarity? > > > > > > Original: > > > Successful interaction with a local firewall assumes the firewall is > > > configured to allow a host to open a bidirectional connection using > > > unique source and destination addresses as well as port numbers by > > > sending a packet using that 4-tuple for a given transport protocol. > > > > > > Perhaps: > > > Successful interaction with a local firewall assumes the firewall > > > is configured to allow a host to open a bidirectional connection > > > using unique source and destination addresses as well as port > > > numbers (i.e., a 4-tuple) by sending a packet using that 4-tuple > > > for a given transport protocol. > > > --> > > > > > > [Authors] ok. > > > > > > > > > 16) <!--[rfced] Please clarify what "one" refers to in "16-bit one's > > > complement Internet checksum". Is the checksum 16 bits? > > > > > > Original: > > > The calculation is the same as the 16-bit one's complement Internet > > > checksum used in the IPv4 packet header (see section 3.1 of > > > [RFC0791]). > > > --> > > > > > > [Authors] NEW > > > The calculation is the same as the 16-bit one's complement Internet > > > checksum used in the IPv4 packet >>Header Checksum specification<< > > > (see section 3.1 of [RFC0791]). > > > > > > > > > 17) <!--[rfced] May we rephrase the text in the parentheses for clarity > > > as follows? > > > > > > Original: > > > The client SHALL simultaneously start a test initiation timer so that > > > if the Control phase fails to complete Test Setup and Test Activation > > > exchanges in the allocated time, the client software SHALL exit > > > (close the UDP socket and indicate an error message to the user). > > > > > > Perhaps: > > > The client SHALL simultaneously start a test initiation timer so that > > > if the Control phase fails to complete Test Setup and Test Activation > > > exchanges in the allocated time, the client software SHALL exit > > > (i.e., the UDP socket will close and an error message will be displayed > > > to the user). > > > --> > > > > > > [Authors] Please change the text in parentheses to (i.e., the UDP socket > > > will >>be closed<< and an error message will be displayed to the user) > > > > > > > > > 18) <!--[rfced] Is "by most significant byte" correct, or should it be > > > "with the most significant byte" as shown below? > > > > > > Original: > > > The UDP PDU format layout SHALL be as follows (big-endian AB, > > > starting by most significant byte ending by least > > > significant byte): > > > > > > Perhaps: > > > The UDP PDU format layout SHALL be as follows (big-endian AB, > > > starting with the most significant byte and ending with > > > the least significant byte): > > > --> > > > > > > [Authors] ok. > > > > > > > > > 19) <!--[rfced] FYI: For Figures 2, 4, 6, 8, and 10, we moved the bit > > > ruler over one space to the right so that the numbers are positioned over > > > the dashes rather than the plus signs to match use in the RFC Series. > > > --> > > > > > > [Authors] Thanks. > > > > > > > > > 20) <!--[rfced] Section 6.1. We are having trouble parsing these > > > sentences. May we update as shown below for clarity? > > > > > > Original: > > > lowThresh: Two two-octet field, low threshold Low on the Range of > > > Round Trip Time variation, RTT (Range is values above minimum RTT, see > > > also Table 3 [TR-471]. > > > > > > upperThresh: Two two-octet field, upper threshold Low on the Range > > > of Round Trip Time variation, RTT (Range is values above minimum > > > RTT, see also Table 3 of [TR-471]. > > > > > > Perhaps: > > > lowThresh: Two two-octet fields, with a low threshold Low on the > > > Range of Round-Trip Time (RTT) variation (the range is composed > > > of values above the minimum RTT); see also Table 3 [TR-471]. > > > > > > upperThresh: Two two-octet fields, with an upper threshold Low on > > > the Range of RTT variation (the range is composed of values above > > > the minimum RTT); see also Table 3 of [TR-471]. > > > --> > > > > > > [Authors] Thanks, a copy-and-paste error. NEW: > > > lowThresh: A two-octet field. The lower threshold on the range of > > > Round-Trip Time (RTT) variation (the range is composed of values above > > > the minimum RTT); see also Table 3 [TR-471]. > > > > > > upperThresh: A two-octet field. The upper threshold on the range of RTT > > > variation (the range is composed of values above the minimum RTT); see > > > also Table 3 of [TR-471]. > > > > > > > > > 21) <!--[rfced] We note that the following sentences refer to "Loss, > > > Reordering, and Duplication" differently. Please let us know if/how they > > > can be updated for consistency (perhaps "loss, out-of-order, and > > > duplicate totals"). > > > > > > In addition, under Section 6.1, we updated "default true" to "default is > > > True". Please let us know if this changes the intended meaning. > > > > > > Original: > > > (Section 6.1) > > > ignoreOooDup: ... When False, Loss, Reordering and > > > Duplication are all counted as sequence number errors, default > > > True (see also Table 3 of [TR-471]). > > > > > > (Section 7.1) > > > lpduSeqNo: A four-octet field indicating the Load PDU sequence > > > number (starting at 1). Used to determine loss, out-of-order, > > > and duplicates. > > > > > > (Section 7.2) > > > seqErrLoss/seqErrOoo/seqErrDup: Three four-octet fields, > > > populated by the Loss, out-of-order, and duplicate totals. > > > > > > Perhaps: > > > (Section 6.1) > > > ignoreOooDup: ... When False, loss, out-of-order, and > > > duplicate totals are all counted as sequence number errors; > > > default is True (see also Table 3 of [TR-471]). > > > > > > (Section 7.1) > > > lpduSeqNo: A four-octet field indicating the Load PDU sequence > > > number (starting at 1). Used to determine loss, out-of-order, > > > and duplicate totals. > > > > > > (Section 7.2) > > > seqErrLoss/seqErrOoo/seqErrDup: Three four-octet fields > > > populated by the loss, out-of-order, and duplicate totals. > > > --> > > > > > > [Authors]: ok. > > > > > > > > > 22) <!--[rfced] May we clarify the text in parentheses as shown below > > > (i.e., update "having been set to CHTA_SRIDX_DEF" to "and if the > > > parameters were set to CHTA_SRIDX_DEF")? Note that there are two > > > instances in the text. > > > > > > Original: > > > * include the transmission parameters from the first row of the > > > Sending Rate Table in the Sending Rate structure (if requested by > > > srIndexConf having been set to CHTA_SRIDX_DEF), or > > > > > > Perhaps: > > > * include the transmission parameters from the first row of the > > > Sending Rate Table in the Sending Rate structure (if requested by > > > srIndexConf and if the parameters were set to CHTA_SRIDX_DEF), or > > > --> > > > > > > [Authors] NEW > > > (if requested by >>setting srIndexConf to a value of<< CHTA_SRIDX_DEF), > > > or". > > > > > > > > > 23) <!--[rfced] We are having trouble parsing "SHALL display/report a > > > relevant message to the ... management process". Is "process" > > > essential to the sentence? Please let us know how we may update the text > > > for clarity. > > > > > > Original: > > > If the client receives a Test Activation cmdResponse field value that > > > indicates an error, the client SHALL display/report a relevant > > > message to the user or management process and exit. > > > > > > Perhaps: > > > If the client receives a Test Activation cmdResponse field value that > > > indicates an error, the client SHALL display/report a relevant > > > message to the user or management and exit. > > > --> > > > > > > [Authors] NEW > > > user or >>measurement system<< and exit > > > > > > > > > 24) <!--[rfced] May we rephrase "adds the possibility to" to "provides > > > the option to" for clarity? > > > > > > Original: > > > Algorithm C operation and modes are similar to B, but C uses > > > multiplicative increases in the fast mode to reach the Gigabit > > > range quickly and adds the possibility to re-try the fast mode > > > during a test (which improves the measurement accuracy in dynamic > > > or error-prone access, such as radio access). > > > > > > Perhaps: > > > Algorithm C operation and modes are similar to B, but C uses > > > multiplicative increases in the fast mode to reach the gigabit > > > range quickly and provides the option to retry the fast mode > > > during a test (which improves the measurement accuracy in > > > dynamic or error-prone access, such as radio access). > > > --> > > > > > > [Authors] ok. > > > > > > > > > 25) <!--[rfced] Please review the formatting of the list in Section 7.2, > > > in particular the indentation of terms following "SisSav". Please let us > > > know if this is correct (sisSav consists of all the fields that follow) > > > or if it needs an update. > > > --> > > > > > > [Authors] Thanks, indentation of the SisSav fields "rxDatagrams" down to > > > "accumTime" makes sense. > > > It then follows that the same should be done in section 6.1 by indenting > > > the srStruct fields that are listed. This includes "txInterval1 and > > > txInterval2" to "udpAddon2". > > > > > > > > > > > > 26) <!--[rfced] Please clarify what 2 instances of "those" refer to in > > > this sentence. > > > > > > Original: > > > When considering privacy of those involved in measurement or those > > > whose traffic is measured, the sensitive information available to > > > potential observers is greatly reduced when using active techniques > > > which are within this scope of work. > > > --> > > > > > > [Authors] NEW > > > When considering privacy of users activating measurements as a service or > > > users, whose traffic is measured,... > > > > > > > > > 27) <!-- [rfced] We have included some specific questions about the IANA > > > text below. In addition to responding to those questions, please review > > > all of the IANA-related updates carefully and let us know if any further > > > changes are needed. > > > > > > a) Section 11.1. In the "Service Name and Transport Protocol Port Number > > > Registry" <https://www.iana.org/assignments/> , the Transport Protocol is > > > listed as "udp", but in this document, it is listed as "UDP". For > > > consistency, should this term be lowercase or uppercase? Note that we > > > will communicate any changes to the registry to IANA. > > > > > > In this document: > > > Transport Protocol: UDP > > > > > > In the registry: > > > Transport Protocol: upd [Authors] [sic!] udp > > > > > > [Authors] > > > https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml > > > lists transport protocols by lowercase, hence "udp" seems better. > > > > > > > > > - Also in Section 11.1, should "performance measurement protocol" or > > > "performance measurement" perhaps be capitalized? (We note that it > > > appears as "Performance Measurement protocol" in RFC 6812.) > > > > > > Current: > > > Description: UDP-based IP-Layer Capacity and performance > > > measurement protocol > > > > > > Perhaps: > > > Description: UDP-based IP-Layer Capacity and Performance > > > Measurement protocol > > > > > > [Authors]: ok. > > > > > > > > > b) IANA has added the following entry to the "KeyTable KDFs" registry. > > > Is "[RFC6234]" the correct reference? Should this document also be added > > > as a reference? > > > > > > Current: > > > KDF Description Reference > > > - - - - - - - - - - - - - - - - - - - - - - - - - - - - > > > HMAC-SHA-256 HMAC using the SHA-256 hash [RFC6234] > > > > > > [Authors] Please add the suitable xref statement, the RFC is part of the > > > normative ref's (putting it to nonmative has been requested during the > > > process). > > > > > > > > > c) May we update the note in the "UDP Speed Test Protocol (UDPSTP)" > > > registry group for clarity as shown below (i.e., uppercase "experimental > > > use" and add "are expected")? If so, we will ask IANA to update > > > accordingly. > > > > > > Original: > > > Note: Values reserved for experimental use are not expected to be > > > used on the Internet, but for experiments that are confined to closed > > > environments. > > > > > > Perhaps: > > > Note: Values reserved for Experimental Use are not > > > expected to be used on the Internet but are expected to be used for > > > experiments that are confined to closed environments. > > > > > > [Authors] ok. > > > > > > > > > d) We note that the "Range" and "Value" column headers in the tables > > > listed below are different than what is listed in the corresponding IANA > > > registries. Should the IANA registries (which only list "Range" > > > and "Value") be updated to match this document, or should "(Hex)", > > > "(Decimal)", "(Bitmap)", "(Capital alphabet / UTF-8)", and "(Numeric)" be > > > removed from this document to match the IANA registries? > > > > > > Current in this document (first header columns of the tables): > > > Table 2: Range(Hex) > > > Tables 4, 8, 10, 12, and 18: Range(Decimal) > > > Tables 6 and 14: Range(Bitmap) > > > Table 16: Range(Capital alphabet / UTF-8) > > > Table 17: Value(Numeric) > > > > > > [Authors] We aren't Registry experts. "Hex" etc. indicate the encoding of > > > registry entries and the information has been added to improve > > > comprehensibility. We'd prefer them to be kept or, if applicable, be > > > replaced by other indicators fulfilling the same purpose (like prefixes > > > bx, 0x...) > > > > > > > > > e) In the "PDU Identifier" registry, we note that IANA has listed > > > "0x0001-0x7F00 / Specification Required" twice. We will ask IANA to > > > remove the duplicate entry. We also note that "0x8000-0xFFFE / IETF > > > Review" is missing. We will ask IANA to add it. > > > > > > [Authors]: Thanks, ok. > > > > > > > > > May we update the order of Table 2 in this document and in the IANA > > > registry as shown under the "Suggested" text below so that there is > > > consistency with the order of the number ranges? > > > > > > Current in the "PDU Identifier" registry: > > > > > > Range Registration Procedures > > > - - - - - - - - - - - - - - - - - - - - > > > 0x0000 Reserved > > > 0x0001-0x7F00 Specification Required > > > 0x7F01-0x7FE0 Reserved for Experimental Use > > > 0x7FE1-0x7FFF Reserved for Private Use > > > 0x0001-0x7F00 Specification Required > > > 0xFFFF Reserved > > > > > > Suggested (for the registry and this document): > > > > > > Range Registration Procedures > > > - - - - - - - - - - - - - - - - - - - - > > > 0x0000 Reserved > > > 0x0001-0x7F00 Specification Required > > > 0x7F01-0x7FE0 Experimental Use > > > 0x7FE1-0x7FFF Private Use > > > 0x8000-0xFFFE IETF Review > > > 0xFFFF Reserved > > > > > > [Authors]: If that's acceptable to IANA, please go ahead. We've taken > > > "Registration Procedures" as the ordering constraint, but "Range" is > > > allright too to the authors. > > > > > > > > > f) In Table 7 [Karen, something has changed between your version and the > > > published one: 6 there] under the description for value 0x02, is the > > > hyphen > > > necessary in "IP-header" or may we remove it per use in most RFCs? > > > Also, may we add "an" before "IP header"? > > > > > > Original: > > > 0x02 Use Traditional MTU (1500 bytes with IP-header) > > > > > > Perhaps: > > > 0x02 Use Traditional MTU (1500 bytes with an IP header) > > > > > > [Authors]: ok. > > > > > > > > > g) In the "Test Activation PDU Rate Adjustment Algo." registry name, > > > is the period after "Algo." necessary? We ask as there is no period > > > after the "rateAdjAlgo" field, for example. > > > > > > Original: > > > "Test Activation PDU Rate Adjustment Algo." registry > > > > > > Perhaps: > > > "Test Activation PDU Rate Adjustment Algo" registry > > > > > > [Authors]: Thanks, ok. > > > > > > > > > h) In Tables 11 and 19 [Karen, something has changed between your version > > > and the published one: 10 and 18 there], how may we clarify the > > > description for value 0. > > > Is "Request" referring to the "Setup Request" or other? > > > > > > Original: > > > 0 None (used by client in Request) > > > > > > Perhaps: > > > 0 None (used by client in the Setup Request) > > > --> > > > > > > [Authors] Actually, the use of only "Request" was intended to be generic > > > for both the Setup and Test Activation. So either leave it as-is, or if > > > desired, table 10/11 could say "Setup Request" and table 18/19 could say > > > "Test Activation Request". > > > > > > > > > 28) <!-- [rfced] This reference points to the C99 version of the C > > > Standard, > > > which has been withdrawn (see > > > <https://www.open-std.org/jtc1/sc22/wg14/www/projects#9899>). Should > > > this reference point specifically to the C99 version or should it > > > point to the most up-to-date version (ISO/IEC 9899:2024) as shown > > > below? > > > > > > Current: > > > [C-Prog] ISO/IEC, "Programming languages - C", ISO/IEC 9899:1999, > > > 1999, <https://www.iso.org/standard/29237.html>. > > > > > > Perhaps: > > > [C-Prog] > > > ISO/IEC, "Information technology - Programming languages > > > - C", ISO/IEC 9899:2024, 2024, > > > <https://www.iso.org/standard/82075.html>. > > > --> > > > > > > [Authors] please leave the :1999 reference, it has been picked > > > intentionally. > > > > > > > > > 29) <!--[rfced] The KDF Example in Appendix A has 7 lines over the > > > character > > > limit. Please let us know how you would like to break/wrap the > > > following lines. > > > > > > Original: > > > *p++ = OSSL_PARAM_construct_utf8_string(OSSL_KDF_PARAM_MODE, "COUNTER", > > > 0); - 8 characters over > > > *p++ = OSSL_PARAM_construct_utf8_string(OSSL_KDF_PARAM_MAC, "HMAC", 0); - > > > 4 over > > > *p++ = OSSL_PARAM_construct_utf8_string(OSSL_KDF_PARAM_DIGEST, "SHA256", > > > 0); - 9 over > > > *p++ = OSSL_PARAM_construct_octet_string(OSSL_KDF_PARAM_KEY, Kin, > > > strlen(Kin)); - 12 over > > > *p++ = OSSL_PARAM_construct_octet_string(OSSL_KDF_PARAM_SALT, "UDPSTP", > > > 6); - 8 over > > > *p++ = OSSL_PARAM_construct_octet_string(OSSL_KDF_PARAM_INFO, context, > > > var); - 9 over > > > *p++ = OSSL_PARAM_construct_int(OSSL_KDF_PARAM_KBKDF_USE_SEPARATOR, > > > &var); - 7 over > > > --> > > > > > > [Authors] The preferred way would be to break inside the parentheses and > > > indent the continuation lines for readability... > > > *p++ = OSSL_PARAM_construct_utf8_string( > > > OSSL_KDF_PARAM_MODE, "COUNTER", 0); > > > *p++ = OSSL_PARAM_construct_utf8_string( > > > OSSL_KDF_PARAM_MAC, "HMAC", 0); > > > *p++ = OSSL_PARAM_construct_utf8_string( > > > OSSL_KDF_PARAM_DIGEST, "SHA256", 0); > > > *p++ = OSSL_PARAM_construct_octet_string( > > > OSSL_KDF_PARAM_KEY, Kin, strlen(Kin)); > > > *p++ = OSSL_PARAM_construct_octet_string( > > > OSSL_KDF_PARAM_SALT, "UDPSTP", 6); > > > *p++ = OSSL_PARAM_construct_octet_string( > > > OSSL_KDF_PARAM_INFO, context, var); > > > > > > > > > 30) <!--[rfced] How may we clarify "further navigated the document". Would > > > "provided further comments" be clearer as shown below? > > > > > > Original: > > > Mohamed Boucadair's AD review improved comprehensibility of the > > > document, and he further navigated the document well through the > > > final review stages. > > > > > > Perhaps: > > > Mohamed Boucadair's AD review improved comprehensibility of the > > > document, and he provided further comments through the final > > > review stages. > > > --> > > > > > > [Authors] "Comments" are just one part, Med offered helpful guidance for > > > the process too (in more than one instance). Could you suggest some > > > suitable wording? > > > > > > > > > > > > 31) <!-- [rfced] Please review whether any of the notes in this document > > > should be in the <aside> element. It is defined as "a container for > > > content that is semantically less important or tangential to the > > > content that surrounds it" > > > (https://authors.ietf.org/en/rfcxml-vocabulary#aside). > > > > > > Example: > > > Note: When this specification is used for network debugging, it may > > > be useful for fragmentation to be under the control of the test > > > administrator. > > > --> > > > > > > [Authors] That wouldn't hold for technical notes - these often address > > > corner cases requiring special attention for the mentioned aspect. > > > > > > > > > 32) <!-- [rfced] Terminology > > > > > > a) Throughout the text, the following terminology appears to be used > > > inconsistently. Please review these occurrences and let us know if/how > > > they > > > may be made consistent. > > > > > > [byte] vs. byte > > > [ms] vs. ms vs. millisecond > > > [s] vs. second > > > [us] vs. us vs. microsecond > > > [Len] Replace the terms in square brackets with just the terms...bytes > > > instead of [byte], seconds instead of s, ms for millisecond, and us for > > > microsecond > > > > > > Loss vs. loss > > > [Authors]: s Loss / seqErrLoss > > > > > > Parameter vs. parameter > > > > > > Range vs. range > > > [Authors] Parameter (within text sections 4.2 and 9.) and Range should be > > > lowercase (regarding Range, text upper/lowThresh in the doc is copied > > > literally from TR-471). > > > > > > Sending Rate Table vs. sending rate table > > > [Note: RFC 9097 uses the lowercase form. Also consider > > > whether the following terms need an update: > > > - Sending Rate structure > > > - Configured Sending Rate Table index] > > > > > > [Authors]: These should remain capitalized as-is: Sending Rate Table, > > > Sending Rate structure, and Configured Sending Rate Table index > > > > > > > > > b) FYI - We updated the following terms to reflect the forms on the > > > right for consistency within this document and/or with other > > > RFCs. Please let us know if any further updates are needed. > > > > > > Bit rate -> bit rate > > > data phase -> Data phase > > > command response -> Command Response > > > Firewall -> firewall (per RFC 9097) > > > IP-layer Capacity metric -> IP-layer Capacity Metric (per RFC 9097) > > > Load Rate Adjustment Algorithm -> load rate adjustment algorithm > > > Maximum IP-Layer Capacity metric -> Maximum IP-Layer Capacity Metric > > > (per RFC 9097) > > > message verification procedure -> Message Verification Procedure > > > method of measurement -> Method of Measurement (Per 9097) > > > Payload Content -> payload content (per 9097) > > > Security mode of operation -> security mode of operation > > > Setup request -> Setup Request > > > test activation request -> Test Activation Request > > > Test traffic -> test traffic (per RFC 9097) > > > Traditional size -> traditional size > > > > > > [Authors] That's fine. > > > > > > > > > c) We note the following variances in the text - are these terms the > > > same or different? Please let us know if any updates are needed for > > > consistency. > > > > > > Bulk Transport Capacity vs. Bulk Capacity > > > [Authors]: the same, then Bulk Transport Capacity > > > > > > Command Server Response code vs. Command Response code > > > [Authors]: Should be "Command Response code". > > > > > > Maximum IP-Layer Capacity Metric vs. Maximum IP Capacity > > > [Authors]: re-reading the text, the single instance of Maximum IP > > > Capacity in " ...ability to search for the Maximum IP Capacity and.. " > > > should be lowercase. > > > > > > Setup Request PDU (4 instances) vs. Request PDU (4 instances) > > > [Note: Is "Request PDU" correct or should it be updated to > > > "Setup Request PDU" or "Test Activation Request PDU"?] > > > > > > [Authors]: > > > Ok: cmdResponse: A one-octet field. All Request PDUs always have a > > > Command Response of XXXX_CRSP_NONE. > > > > > > Please change: When the server replies to a Test Setup Request message, > > > the Test Setup Response PDU is structured identically to the >>Test > > > Setup<< Request PDU (2 instances) > > > > > > Please change: ...the Test Activation Response PDU is structured > > > identically to the >>Test Activation<< Request PDU > > > > > > > > > d) "Sub-Interval" and "sisSav" > > > [Authors] Please leave as-is. > > > > > > > > > i) We note the following variances related to "sisSav" (placement and > > > inclusion of "saved"). Should these be made consistent? > > > > > > Original: > > > sisSav: Sub-interval statistics saved (completed) > > > > > > struct subIntStats sisSav; // Sub-interval saved stats > > > > > > Sub-Interval Statistics structure (sisSav) > > > > > > Perhaps: > > > sisSav: Sub-interval statistics saved (completed) > > > > > > struct subIntStats sisSav; // Sub-interval stats saved > > > > > > Sub-interval statistics saved (sisSav) structure > > > > > > [Authors]: ok > > > > > > > > > ii) We also note the following variances; please let us know > > > how we may make these consistent. > > > > > > Sub-Interval vs. Sub-interval vs. sub-interval > > > > > > Some examples: > > > Sub-interval sequence > > > Sub-interval period > > > Sub-Interval byte count > > > during the Sub-Interval > > > each sub-interval is > > > the last saved (completed) sub-interval > > > > > > Sub-Interval Statistics vs. Sub-interval statistics > > > > > > [Authors]: please capitalize "Sub-Interval" in all instances. > > > > > > > > > e) We note the use of "Null Request". Should this perhaps be > > > "NULL Request", "NULL request", or other? We ask as we only > > > see "NULL request" used in other RFCs. > > > > > > [Authors] It should remain "Null Request" as that is the proper name. The > > > use of NULL would imply a non or undefined value (like in a database > > > table). > > > > > > > > > f) We note that the following terms appear as uppercase in the running > > > text but as lowercase in the descriptions in Figures 3, 5, 7, 9, and/or > > > 11. Should we update the figures to reflect the uppercase forms for > > > consistency or is the case okay as is? > > > > > > Current: > > > Null request > > > Command request > > > command response > > > load PDU > > > Out-of-Order > > > Sending rate structure > > > Setup request > > > Setup response > > > Status feedback header > > > status PDU > > > > > > Perhaps: > > > Null Request (or other per author response to the question above) > > > Command Request > > > Command Response > > > Load PDU > > > Out-of-order > > > Sending Rate structure > > > Setup Request > > > Setup Response > > > Status Feedback header > > > Status PDU > > > --> > > > > > > [Authors] ok, but please update ONLY the line comments (text after the > > > '//') > > > > > > > > > 33) <!-- [rfced] Abbreviations > > > > > > a) FYI - We have added expansions for the following abbreviations per > > > Section 3.6 of RFC 7322 ("RFC Style Guide"). Please review these as > > > well as each expansion in the document carefully to ensure > > > correctness. > > > > > > Don't Fragment (DF) > > > Hashed Message Authentication Code (HMAC) > > > > > > [Authos] Thanks, ok. > > > > > > > > > b) FYI - We updated the following expansion to the form on the right for > > > correctness. Please let us know of any concerns. > > > > > > Packetization Layer Path MTU Discovery for Datagram Transports (DPLPMTUD) > > > -> > > > Datagram Packetization Layer PMTU Discovery (DPLPMTUD) > > > > > > [Authos] Thanks, ok. > > > > > > > > > c) FYI - We updated "UDPST" to "UDPSTP" (one instance) as follows. Please > > > let us know if that is not correct. > > > > > > Original: > > > The number n may depend on the implementation and on typical > > > characteristics of environments, where UDPST is deployed (like > > > mobile networks or Wi-Fi). > > > > > > Current: > > > The number n may depend on the implementation and on typical > > > characteristics of environments, where UDPSTP is deployed (like > > > mobile networks or Wi-Fi). > > > --> > > > > > > [Authos] Thanks, ok. > > > > > > > > > 34) <!-- [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. > > > > > > [Ruediger] drew Error 403 > > > > > > Please consider whether "traditional" should be updated for clarity. > > > While the NIST website > > > <https://web.archive.org/web/20250214092458/https://www.nist.gov/nist-research-library/nist-technical-series-publications-author-instructions#table1> > > > indicates that this term is potentially biased, it is also ambiguous. > > > "Tradition" is a subjective term, as it is not the same for everyone. > > > --> > > > [Authos] Please leave "traditional" in this instance. > > > > > > #### End of Comments ##### > > > > > > > > > Thank you. > > > > > > Karen Moore > > > RFC Production Center > > > > > > > > > On Mar 11, 2026, at 6:48 PM, RFC Editor via auth48archive > > > <mailto:[email protected]> wrote: > > > > > > *****IMPORTANT***** > > > > > > Updated 2026/03/11 > > > > > > 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 > > > > > > * mailto:[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). > > > > > > * mailto:[email protected], which is a new archival mailing > > > list > > > to preserve AUTH48 conversations; it is not an active discussion > > > list: > > > > > > * More info: > > > > > > https://mailarchive.ietf.org/arch/msg/ietf-announce/yb6lpIGh-4Q9l2USxIAe6P8O4Zc > > > > > > * The archive itself: > > > https://mailarchive.ietf.org/arch/browse/auth48archive/ > > > > > > * 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, > > > mailto:[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/rfc9946.xml > > > https://www.rfc-editor.org/authors/rfc9946.html > > > https://www.rfc-editor.org/authors/rfc9946.pdf > > > https://www.rfc-editor.org/authors/rfc9946.txt > > > > > > Diff file of the text: > > > https://www.rfc-editor.org/authors/rfc9946-diff.html > > > https://www.rfc-editor.org/authors/rfc9946-rfcdiff.html (side by side) > > > > > > Diff of the XML: > > > https://www.rfc-editor.org/authors/rfc9946-xmldiff1.html > > > > > > > > > Tracking progress > > > ----------------- > > > > > > The details of the AUTH48 status of your document are here: > > > https://www.rfc-editor.org/auth48/rfc9946 > > > > > > Please let us know if you have any questions. > > > > > > Thank you for your cooperation, > > > > > > RFC Editor > > > > > > -------------------------------------- > > > RFC9946 (draft-ietf-ippm-capacity-protocol-25) > > > > > > Title : UDP Speed Test Protocol for One-way IP Capacity Metric > > > Measurement > > > Author(s) : A. Morton, L. Ciavattone, R. Geib, Ed. > > > WG Chair(s) : Marcus Ihlar, Thomas Graf > > > > > > Area Director(s) : Mohamed Boucadair, Mahesh Jethanandani > > > > > > > > > -- > > > auth48archive mailing list -- mailto:[email protected] > > > To unsubscribe send an email to mailto:[email protected] > > > > > -- auth48archive mailing list -- [email protected] To unsubscribe send an email to [email protected]
