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]
