Dear Karen, dear Med, thanks for helping us to complete this work. To me, the document can be published with the changes agreed between us.
Regards, Ruediger -----Ursprüngliche Nachricht----- Von: Karen Moore <[email protected]> Gesendet: Dienstag, 17. März 2026 20:34 An: Geib, Rüdiger <[email protected]>; [email protected]; Len Ciavattone <[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 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]
