Hi Karen, all, Thank you for preparing this version.
For point#1, thank you for taking care of that. I suggest to add the affiliation as well to acknowledge sponsorship of Al work when he contributed to this spec. Cheers, Med > -----Message d'origine----- > De : [email protected] <[email protected]> > Envoyé : jeudi 12 mars 2026 02:52 > À : [email protected]; [email protected] > Cc : [email protected]; [email protected]; ippm- > [email protected]; [email protected]; BOUCADAIR Mohamed INNOV/NET > <[email protected]>; [email protected] > Objet : [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 > --> > > > 2) <!-- [rfced] Please insert any keywords (beyond those that > appear in the title) for use on > https://fra01.safelinks.protection.outlook.com/?url=https%3A%2F%2F > www.rfc- > editor.org%2Fsearch&data=05%7C02%7Cmohamed.boucadair%40orange.com% > 7C3219bd76814342cbafc308de7fd9e821%7C90c7a20af34b40bfbc48b9253b6f5 > d20%7C0%7C0%7C639088771335247078%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0e > U1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCI > sIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=9OKGtZNvIxrQgvbFPRQ8yEqMQkuy4 > eikC4IdJUtedyk%3D&reserved=0. > --> > > > 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. > --> > > > 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]. > --> > > > 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. > --> > > > 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. > --> > > > 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. > --> > > > 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. > --> > > > 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. > --> > > > 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). > --> > > > 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. > --> > > > 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]) > --> > > > 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). > --> > > > 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 > --> > > > 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. > --> > > > 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]). > --> > > > 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). > --> > > > 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): > --> > > > 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. > --> > > > 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]. > --> > > > 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. > --> > > > 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 > --> > > > 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. > --> > > > 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). > --> > > > 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. > --> > > > 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. > --> > > > 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://fra01.safelinks.protection.outlook.com/?url=https%3A%2F%2 > Fwww.iana.org%2Fassignments%2F&data=05%7C02%7Cmohamed.boucadair%40 > orange.com%7C3219bd76814342cbafc308de7fd9e821%7C90c7a20af34b40bfbc > 48b9253b6f5d20%7C0%7C0%7C639088771335271381%7CUnknown%7CTWFpbGZsb3 > d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFO > IjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=2ymjzmEEA5%2FL3FvJ > JMutK1cbFbfbxeIpeaTX4lb4toM%3D&reserved=0 > service-names-port-numbers/>, 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 > > - 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 > > 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] > > 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. > > > 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) > > > 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. > > 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 > > > f) In Table 7 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) > > > 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 > > > h) In Tables 11 and 19, 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) > --> > > > 28) <!-- [rfced] This reference points to the C99 version of the C > Standard, > which has been withdrawn (see > <https://fra01.safelinks.protection.outlook.com/?url=https%3A%2F%2 > Fwww.open- > std.org%2Fjtc1%2Fsc22%2Fwg14%2Fwww%2Fprojects%239899&data=05%7C02% > 7Cmohamed.boucadair%40orange.com%7C3219bd76814342cbafc308de7fd9e82 > 1%7C90c7a20af34b40bfbc48b9253b6f5d20%7C0%7C0%7C639088771335282154% > 7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMC > IsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sd > ata=teJDOm95ArscK8sfh18dmIitTpOwp3YOWSjonUEgH8E%3D&reserved=0>). > 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://fra01.safelinks.protection.outlook.com/?url=https%3A%2F%2 > Fwww.iso.org%2Fstandard%2F29237.html&data=05%7C02%7Cmohamed.boucad > air%40orange.com%7C3219bd76814342cbafc308de7fd9e821%7C90c7a20af34b > 40bfbc48b9253b6f5d20%7C0%7C0%7C639088771335292181%7CUnknown%7CTWFp > bGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMi > IsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=5NSVkYCbARLW > Yj6i0XwF5ZEaoszKZuti%2FUSVI2axCkA%3D&reserved=0>. > > Perhaps: > [C-Prog] > ISO/IEC, "Information technology - Programming > languages > - C", ISO/IEC 9899:2024, 2024, > > <https://fra01.safelinks.protection.outlook.com/?url=https%3A%2F%2 > Fwww.iso.org%2Fstandard%2F82075.html&data=05%7C02%7Cmohamed.boucad > air%40orange.com%7C3219bd76814342cbafc308de7fd9e821%7C90c7a20af34b > 40bfbc48b9253b6f5d20%7C0%7C0%7C639088771335301978%7CUnknown%7CTWFp > bGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMi > IsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=EZjhtY9ZX4Lr > cHh%2FygRNa07pPxB6CYutlL%2FZtBfNS%2BM%3D&reserved=0>. > --> > > > 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 > --> > > > 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. > --> > > > 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://fra01.safelinks.protection.outlook.com/?url=https%3A%2F%2 > Fauthors.ietf.org%2Fen%2Frfcxml- > vocabulary%23aside&data=05%7C02%7Cmohamed.boucadair%40orange.com%7 > C3219bd76814342cbafc308de7fd9e821%7C90c7a20af34b40bfbc48b9253b6f5d > 20%7C0%7C0%7C639088771335314815%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU > 1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIs > IldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=AoZu3ch%2FtAk1WK%2FfBS1HqifRjl > D%2FHU%2FgNA0KlhQA6Lo%3D&reserved=0). > > 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. > --> > > > 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 > > Loss vs. loss > > Parameter vs. parameter > > Range vs. range > > 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] > > > 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 > > > 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 > > Command Server Response code vs. Command Response code > > Maximum IP-Layer Capacity Metric vs. Maximum IP Capacity > > 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"?] > > > d) "Sub-Interval" and "sisSav" > > 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 > > 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 > > > 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. > > > 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 > --> > > > 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) > > 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) > > 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). > --> > > > 34) <!-- [rfced] Please review the "Inclusive Language" portion of > the online > Style Guide > <https://fra01.safelinks.protection.outlook.com/?url=https%3A%2F%2 > Fwww.rfc- > editor.org%2Fstyleguide%2Fpart2%2F%23inclusive_language&data=05%7C > 02%7Cmohamed.boucadair%40orange.com%7C3219bd76814342cbafc308de7fd9 > e821%7C90c7a20af34b40bfbc48b9253b6f5d20%7C0%7C0%7C6390887713353268 > 95%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDA > wMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C > &sdata=a1qMTekjtzqhlTVrsQh2JBQuttMPA6TlJjSeyZQ3yRk%3D&reserved=0> > and let us know if any changes are needed. Updates of this nature > typically > result in more precise language, which is helpful for readers. > > Please consider whether "traditional" should be updated for > clarity. > While the NIST website > <https://fra01.safelinks.protection.outlook.com/?url=https%3A%2F%2 > Fweb.archive.org%2Fweb%2F20250214092458%2Fhttps%3A%2F%2Fwww.nist.g > ov%2F&data=05%7C02%7Cmohamed.boucadair%40orange.com%7C3219bd768143 > 42cbafc308de7fd9e821%7C90c7a20af34b40bfbc48b9253b6f5d20%7C0%7C0%7C > 639088771335337713%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWU > sIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D > %3D%7C0%7C%7C%7C&sdata=z%2BjFG6HE7OhGBzonn%2B7SwwiNhdXwDUuuaBtSlP0 > qJko%3D&reserved=0 > 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. > --> > > > Thank you. > > Karen Moore > RFC Production Center > > > On Mar 11, 2026, at 6:48 PM, RFC Editor via auth48archive > <[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://fra01.safelinks.protection.outlook.com/?url=https%3A%2F%2 > Fwww.rfc- > editor.org%2Ffaq%2F&data=05%7C02%7Cmohamed.boucadair%40orange.com% > 7C3219bd76814342cbafc308de7fd9e821%7C90c7a20af34b40bfbc48b9253b6f5 > d20%7C0%7C0%7C639088771335347618%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0e > U1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCI > sIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=OTlTlAhwjYt%2BjBMipKq5VC1Zlfc > jyKHkOW7jRM%2B7ZYY%3D&reserved=0). > > 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://fra01.safelinks.protection.outlook.com/?url=https%3A%2F%2F > trustee.ietf.org%2Flicense- > info&data=05%7C02%7Cmohamed.boucadair%40orange.com%7C3219bd7681434 > 2cbafc308de7fd9e821%7C90c7a20af34b40bfbc48b9253b6f5d20%7C0%7C0%7C6 > 39088771335357500%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUs > IlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D% > 3D%7C0%7C%7C%7C&sdata=EHnt%2B0gRP6hlDR8BzJep8dfizrwvLHRbL%2B7Eh0cj > Tqc%3D&reserved=0). > > * 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://fra01.safelinks.protection.outlook.com/?url=https%3A%2F%2 > Fauthors.ietf.org%2Frfcxml- > vocabulary&data=05%7C02%7Cmohamed.boucadair%40orange.com%7C3219bd7 > 6814342cbafc308de7fd9e821%7C90c7a20af34b40bfbc48b9253b6f5d20%7C0%7 > C0%7C639088771335367206%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOn > RydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoy > fQ%3D%3D%7C0%7C%7C%7C&sdata=8IT%2FN1GOzyFNgRPGQ%2BSWkd4hNQeJcsRhXq > UQzF8QbhU%3D&reserved=0>. > > * Formatted output > > Please review the PDF, HTML, and TXT files to ensure that the > formatted output, as generated from the markup in the XML file, > is > reasonable. Please note that the TXT will have formatting > limitations compared to the PDF and HTML. > > > Submitting changes > ------------------ > > To submit changes, please reply to this email using ‘REPLY ALL’ as > all > the parties CCed on this message need to see your changes. The > parties > include: > > * your coauthors > > * [email protected] (the RPC team) > > * other document participants, depending on the stream (e.g., > IETF Stream participants are your working group chairs, the > responsible ADs, and the document shepherd). > > * [email protected], which is a new archival mailing > list > to preserve AUTH48 conversations; it is not an active > discussion > list: > > * More info: > > https://fra01.safelinks.protection.outlook.com/?url=https%3A%2F%2F > mailarchive.ietf.org%2Farch%2Fmsg%2Fietf-announce%2Fyb6lpIGh- > 4Q9l2USxIAe6P8O4Zc&data=05%7C02%7Cmohamed.boucadair%40orange.com%7 > C3219bd76814342cbafc308de7fd9e821%7C90c7a20af34b40bfbc48b9253b6f5d > 20%7C0%7C0%7C639088771335377249%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU > 1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIs > IldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=%2FRx%2BVHyqPtVA%2BLGLmY8Ul%2F > I11tepVxuUAc9rSqf3BFs%3D&reserved=0 > > * The archive itself: > > https://fra01.safelinks.protection.outlook.com/?url=https%3A%2F%2F > mailarchive.ietf.org%2Farch%2Fbrowse%2Fauth48archive%2F&data=05%7C > 02%7Cmohamed.boucadair%40orange.com%7C3219bd76814342cbafc308de7fd9 > e821%7C90c7a20af34b40bfbc48b9253b6f5d20%7C0%7C0%7C6390887713353875 > 62%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDA > wMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C > &sdata=VnmQFiIr%2BDGBU%2BOjSi1Cca%2Fxw80FytIvG3qNClRFfvk%3D&reserv > ed=0 > > * Note: If only absolutely necessary, you may temporarily opt > out > of the archiving of messages (e.g., to discuss a sensitive > matter). > If needed, please add a note at the top of the message that > you > have dropped the address. When the discussion is concluded, > [email protected] will be re-added to the CC > list and > its addition will be noted at the top of the message. > > You may submit your changes in one of two ways: > > An update to the provided XML file > — OR — > An explicit list of changes in this format > > Section # (or indicate Global) > > OLD: > old text > > NEW: > new text > > You do not need to reply with both an updated XML file and an > explicit > list of changes, as either form is sufficient. > > We will ask a stream manager to review and approve any changes > that seem > beyond editorial in nature, e.g., addition of new text, deletion > of text, > and technical changes. Information about stream managers can be > found in > the FAQ. Editorial changes do not require approval from a stream > manager. > > > Approving for publication > -------------------------- > > To approve your RFC for publication, please reply to this email > stating > that you approve this RFC for publication. Please use ‘REPLY > ALL’, > as all the parties CCed on this message need to see your approval. > > > Files > ----- > > The files are available here: > > https://fra01.safelinks.protection.outlook.com/?url=https%3A%2F%2F > www.rfc- > editor.org%2Fauthors%2Frfc9946.xml&data=05%7C02%7Cmohamed.boucadai > r%40orange.com%7C3219bd76814342cbafc308de7fd9e821%7C90c7a20af34b40 > bfbc48b9253b6f5d20%7C0%7C0%7C639088771335398262%7CUnknown%7CTWFpbG > Zsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIs > IkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=5WkrZceM5Fomc6 > Hrm%2FlwMf%2FaVXaU%2Brz8Mo05EnKZhK4%3D&reserved=0 > > https://fra01.safelinks.protection.outlook.com/?url=https%3A%2F%2F > www.rfc- > editor.org%2Fauthors%2Frfc9946.html&data=05%7C02%7Cmohamed.boucada > ir%40orange.com%7C3219bd76814342cbafc308de7fd9e821%7C90c7a20af34b4 > 0bfbc48b9253b6f5d20%7C0%7C0%7C639088771335408190%7CUnknown%7CTWFpb > GZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiI > sIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=xfqekdrC9co9z > 4vlYXLe%2FD0E7ujMaCY8rTxrVkkw3WA%3D&reserved=0 > > https://fra01.safelinks.protection.outlook.com/?url=https%3A%2F%2F > www.rfc- > editor.org%2Fauthors%2Frfc9946.pdf&data=05%7C02%7Cmohamed.boucadai > r%40orange.com%7C3219bd76814342cbafc308de7fd9e821%7C90c7a20af34b40 > bfbc48b9253b6f5d20%7C0%7C0%7C639088771335418052%7CUnknown%7CTWFpbG > Zsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIs > IkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=QEqNOYMPYrs6ag > UyIpXyivCF1TW8TT6%2B%2BR%2BklRqEZQo%3D&reserved=0 > > https://fra01.safelinks.protection.outlook.com/?url=https%3A%2F%2F > www.rfc- > editor.org%2Fauthors%2Frfc9946.txt&data=05%7C02%7Cmohamed.boucadai > r%40orange.com%7C3219bd76814342cbafc308de7fd9e821%7C90c7a20af34b40 > bfbc48b9253b6f5d20%7C0%7C0%7C639088771335427971%7CUnknown%7CTWFpbG > Zsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIs > IkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=bWENpL9RBLpuS6 > xLCBixe5PxC9Y7mISKRM2lQgNsS%2Bw%3D&reserved=0 > > Diff file of the text: > > https://fra01.safelinks.protection.outlook.com/?url=https%3A%2F%2F > www.rfc-editor.org%2Fauthors%2Frfc9946- > diff.html&data=05%7C02%7Cmohamed.boucadair%40orange.com%7C3219bd76 > 814342cbafc308de7fd9e821%7C90c7a20af34b40bfbc48b9253b6f5d20%7C0%7C > 0%7C639088771335438143%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnR > ydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyf > Q%3D%3D%7C0%7C%7C%7C&sdata=8rVqyFR%2FPUYHQfQGtvmKHXc9szVfKaXcGS8gH > DyOsrA%3D&reserved=0 > > https://fra01.safelinks.protection.outlook.com/?url=https%3A%2F%2F > www.rfc-editor.org%2Fauthors%2Frfc9946- > rfcdiff.html&data=05%7C02%7Cmohamed.boucadair%40orange.com%7C3219b > d76814342cbafc308de7fd9e821%7C90c7a20af34b40bfbc48b9253b6f5d20%7C0 > %7C0%7C639088771335447683%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGki > OnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIj > oyfQ%3D%3D%7C0%7C%7C%7C&sdata=p9QHgeAQxw3FwBYsNw7I0ovuBm2hWCQXFBg8 > yDxDbrI%3D&reserved=0 (side by side) > > Diff of the XML: > > https://fra01.safelinks.protection.outlook.com/?url=https%3A%2F%2F > www.rfc-editor.org%2Fauthors%2Frfc9946- > xmldiff1.html&data=05%7C02%7Cmohamed.boucadair%40orange.com%7C3219 > bd76814342cbafc308de7fd9e821%7C90c7a20af34b40bfbc48b9253b6f5d20%7C > 0%7C0%7C639088771335458190%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGk > iOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUI > joyfQ%3D%3D%7C0%7C%7C%7C&sdata=3oBPAW9d5jfEwO0ni7WmyoZ3q6CUbflr4dT > MKx5R5II%3D&reserved=0 > > > Tracking progress > ----------------- > > The details of the AUTH48 status of your document are here: > > https://fra01.safelinks.protection.outlook.com/?url=https%3A%2F%2F > www.rfc- > editor.org%2Fauth48%2Frfc9946&data=05%7C02%7Cmohamed.boucadair%40o > range.com%7C3219bd76814342cbafc308de7fd9e821%7C90c7a20af34b40bfbc4 > 8b9253b6f5d20%7C0%7C0%7C639088771335469521%7CUnknown%7CTWFpbGZsb3d > 8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOI > joiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=p1tUraoO9gdpM%2FIWr > f%2BZKkBaGxzvbXaB6%2BQ4rni2BJA%3D&reserved=0 > > 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 -- [email protected] > To unsubscribe send an email to [email protected] ____________________________________________________________________________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci. This message and its attachments may contain confidential or privileged information that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and delete this message and its attachments. As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified. Thank you. -- auth48archive mailing list -- [email protected] To unsubscribe send an email to [email protected]
