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]
