Hi Med, We have noted your approval of Sections 4.3.1 and 4.6. on the AUTH48 status page (https://www.rfc-editor.org/auth48/rfc9946). FYI: In Section 4.6, we wanted to make sure the update from "IPv4 packet header” to "IPv4 packet Header Checksum specification" was okay.
Best regards, Karen Moore RFC Production Center > On Mar 17, 2026, at 5:04 PM, Mohamed Boucadair via auth48archive > <[email protected]> wrote: > > Re-, > > I approve the language change in Section 4.3.1. The changes in 4.6 are OK > (although I don't see there any language change). > > I will review the full text once Len and Ruediger provide their approval. > > Cheers, > Med > >> -----Message d'origine----- >> De : Karen Moore <[email protected]> >> Envoyé : mercredi 18 mars 2026 03:34 >> À : [email protected]; BOUCADAIR Mohamed INNOV/NET >> <[email protected]>; Len Ciavattone >> <[email protected]> >> Cc : [email protected]; [email protected]; ippm- >> [email protected]; [email protected]; [email protected] >> Objet : Re: AUTH48: RFC-to-be 9946 <draft-ietf-ippm-capacity- >> protocol-25> for your review >> >> Dear Len, Ruediger, and Med, >> >> Thank you for the clarifications. We made 1 instance of “Loss” >> lowercase and removed the reference to this document in Table 1. >> The updated files are below. Please review and let us know if any >> further changes are needed or if you approve the document in its >> current form. >> >> Med, please provide approval of the document on behalf of Al >> Morton. As AD, please note the addition of “SHOULD” in Section >> 4.3.1 and the updated language in Section 4.6 when performing your >> review (see >> <https://fra01.safelinks.protection.outlook.com/?url=https%3A%2F%2 >> Fwww.rfc-editor.org%2Fauthors%2Frfc9946- >> auth48diff.html&data=05%7C02%7Cmohamed.boucadair%40orange.com%7Cde >> fe74979b754bd6dd1308de845c3edf%7C90c7a20af34b40bfbc48b9253b6f5d20% >> 7C0%7C0%7C639093728906161660%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hc >> GkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIld >> UIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=w6JHQ6egYeREvfN6kwl77F38TPYRUFjp2 >> pbQwJ8XUA0%3D&reserved=0>). >> >> —Files (please refresh)— >> >> We will await approvals from each author prior to moving forward >> in the publication process. >> >> Updated XML file: >> >> 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%7Cdefe74979b754bd6dd1308de845c3edf%7C90c7a20af34b40 >> bfbc48b9253b6f5d20%7C0%7C0%7C639093728906187140%7CUnknown%7CTWFpbG >> Zsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIs >> IkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=NRaqR6ldfO8bXs >> %2BjVnyFUOuof%2BTfS%2BWJgiF0Y72KHUs%3D&reserved=0 >> >> Updated output files: >> >> 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%7Cdefe74979b754bd6dd1308de845c3edf%7C90c7a20af34b40 >> bfbc48b9253b6f5d20%7C0%7C0%7C639093728906204966%7CUnknown%7CTWFpbG >> Zsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIs >> IkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=mqWf2Qmr2RnE0l >> gsWBBBenTRY4GkH86kUmptkCIUIyA%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%7Cdefe74979b754bd6dd1308de845c3edf%7C90c7a20af34b40 >> bfbc48b9253b6f5d20%7C0%7C0%7C639093728906220962%7CUnknown%7CTWFpbG >> Zsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIs >> IkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=w3HNrOUfQtJDXW >> XTRccre5uEtIeRgIhENkOdZy1iKEo%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%7Cdefe74979b754bd6dd1308de845c3edf%7C90c7a20af34b4 >> 0bfbc48b9253b6f5d20%7C0%7C0%7C639093728906242057%7CUnknown%7CTWFpb >> GZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiI >> sIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=cwnWL0uBfIQx3 >> bQLl0R6EqOwetcbS0xkyz%2FFvn1WoBM%3D&reserved=0 >> >> Diff files showing all changes made during AUTH48: >> >> https://fra01.safelinks.protection.outlook.com/?url=https%3A%2F%2F >> www.rfc-editor.org%2Fauthors%2Frfc9946- >> auth48diff.html&data=05%7C02%7Cmohamed.boucadair%40orange.com%7Cde >> fe74979b754bd6dd1308de845c3edf%7C90c7a20af34b40bfbc48b9253b6f5d20% >> 7C0%7C0%7C639093728906258489%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hc >> GkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIld >> UIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=wELFyRHx4SJX%2BgJOEqJXyKk3UkYoXq4 >> aNwNZUUiE2qw%3D&reserved=0 >> >> https://fra01.safelinks.protection.outlook.com/?url=https%3A%2F%2F >> www.rfc-editor.org%2Fauthors%2Frfc9946- >> auth48rfcdiff.html&data=05%7C02%7Cmohamed.boucadair%40orange.com%7 >> Cdefe74979b754bd6dd1308de845c3edf%7C90c7a20af34b40bfbc48b9253b6f5d >> 20%7C0%7C0%7C639093728906270654%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU >> 1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIs >> IldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=unh%2BIyu5PqorhIsCZIbYnLcJ02Bn >> ueQBTXnm%2B324I%2Fs%3D&reserved=0 (side by side) >> >> Diff files showing only the changes made during the last edit >> round: >> https://fra01.safelinks.protection.outlook.com/?url=https%3A%2F%2F >> www.rfc-editor.org%2Fauthors%2Frfc9946- >> lastdiff.html&data=05%7C02%7Cmohamed.boucadair%40orange.com%7Cdefe >> 74979b754bd6dd1308de845c3edf%7C90c7a20af34b40bfbc48b9253b6f5d20%7C >> 0%7C0%7C639093728906282151%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGk >> iOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUI >> joyfQ%3D%3D%7C0%7C%7C%7C&sdata=tp8LCNvnw56%2BdHObRikvgRgQUT6arznoV >> ic76qGDrGg%3D&reserved=0 >> https://fra01.safelinks.protection.outlook.com/?url=https%3A%2F%2F >> www.rfc-editor.org%2Fauthors%2Frfc9946- >> lastrfcdiff.html&data=05%7C02%7Cmohamed.boucadair%40orange.com%7Cd >> efe74979b754bd6dd1308de845c3edf%7C90c7a20af34b40bfbc48b9253b6f5d20 >> %7C0%7C0%7C639093728906293244%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1h >> cGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIl >> dUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=%2FMBhtqAUpTYSHJU7WPHT2aUQqZXvt9 >> XycmLtYsfc9ic%3D&reserved=0 (side by side) >> >> Diff files showing all changes: >> >> 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%7Cdefe7497 >> 9b754bd6dd1308de845c3edf%7C90c7a20af34b40bfbc48b9253b6f5d20%7C0%7C >> 0%7C639093728906304604%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnR >> ydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyf >> Q%3D%3D%7C0%7C%7C%7C&sdata=dOks%2BDE2Vi8ahzxMGnuNb7NmG2WY91bImDLOl >> fuqbBc%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%7Cdefe7 >> 4979b754bd6dd1308de845c3edf%7C90c7a20af34b40bfbc48b9253b6f5d20%7C0 >> %7C0%7C639093728906316140%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGki >> OnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIj >> oyfQ%3D%3D%7C0%7C%7C%7C&sdata=tVYcc3e2E%2BC%2FGph%2BzdIHLKNbp4F6NT >> ROd6QbwsO5vqs%3D&reserved=0 (side by side) >> >> For the AUTH48 status of this document, please see: >> >> 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%7Cdefe74979b754bd6dd1308de845c3edf%7C90c7a20af34b40bfbc4 >> 8b9253b6f5d20%7C0%7C0%7C639093728906328235%7CUnknown%7CTWFpbGZsb3d >> 8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOI >> joiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=2l9%2FyPUtxb10lPVGL >> cgWNFHJayXSHNOdOttFCg4l26w%3D&reserved=0 >> >> Best regards, >> >> Karen Moore >> RFC Production Center >> >> >>> On Mar 17, 2026, at 7:56 AM, Len Ciavattone >> <[email protected]> wrote: >>> >>> Karen, >>> I've included responses below marked as [Authors]. Please let me >> know if any further info is needed. >>> >>> Thank you, >>> Len >>> >>> On Tue, Mar 17, 2026 at 8:20 AM <[email protected]> wrote: >>> Hi Karen, hi Len, hi Med >>> >>> Karen, thanks for your response and further questions. Med, >> regarding the registry issue, KDF HMAC-SHA-256 , I'd prefer you to >> comment and help. Neither Len nor I are IETF registry experts. >>> >>> Len, I'd suggest that you reply to Karen directly regarding the >> open points apart from the above registry ref one. >>> >>> I've marked my comments [RG]. >>> >>> Regards, >>> >>> Ruediger >>> >>> -----Ursprüngliche Nachricht----- >>> Von: Karen Moore <[email protected]> >>> Gesendet: Dienstag, 17. März 2026 03:34 >>> An: [email protected]; Geib, Rüdiger >> <[email protected]>; [email protected] >>> Cc: [email protected]; [email protected]; ippm- >> [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://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%7Cdefe74979b754bd6dd1308de845c3edf%7C90c7a20af34b40 >> bfbc48b9253b6f5d20%7C0%7C0%7C639093728906339173%7CUnknown%7CTWFpbG >> Zsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIs >> IkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=1T7JeXHCNHEZJH >> LjE5aupN%2FnWJDwZROwyZayfc5QJAc%3D&reserved=0 >>> >>> Updated output files: >>> >> 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%7Cdefe74979b754bd6dd1308de845c3edf%7C90c7a20af34b40 >> bfbc48b9253b6f5d20%7C0%7C0%7C639093728906350034%7CUnknown%7CTWFpbG >> Zsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIs >> IkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=Gslsk6RqfOru2a >> sPdGerMWZuQzol4loeeT0rLWgKdl4%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%7Cdefe74979b754bd6dd1308de845c3edf%7C90c7a20af34b40 >> bfbc48b9253b6f5d20%7C0%7C0%7C639093728906360236%7CUnknown%7CTWFpbG >> Zsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIs >> IkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=i8dv0aesR1LCY6 >> NLHOFRBtaHbuC5weaytoBlcxP%2F5%2B8%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%7Cdefe74979b754bd6dd1308de845c3edf%7C90c7a20af34b4 >> 0bfbc48b9253b6f5d20%7C0%7C0%7C639093728906370657%7CUnknown%7CTWFpb >> GZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiI >> sIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=hnvJfIwLlnNwm >> ShPkiFbG8nu%2BVw6TwNG%2Fbc9cFiXnp4%3D&reserved=0 >>> >>> Diff files showing all changes made during AUTH48: >>> >> https://fra01.safelinks.protection.outlook.com/?url=https%3A%2F%2F >> www.rfc-editor.org%2Fauthors%2Frfc9946- >> auth48diff.html&data=05%7C02%7Cmohamed.boucadair%40orange.com%7Cde >> fe74979b754bd6dd1308de845c3edf%7C90c7a20af34b40bfbc48b9253b6f5d20% >> 7C0%7C0%7C639093728906383613%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hc >> GkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIld >> UIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=JZ%2FMZs445rte5EMZzyhxlWQDY07gvOs >> ahQIgd6nmu6c%3D&reserved=0 >>> >> https://fra01.safelinks.protection.outlook.com/?url=https%3A%2F%2F >> www.rfc-editor.org%2Fauthors%2Frfc9946- >> auth48rfcdiff.html&data=05%7C02%7Cmohamed.boucadair%40orange.com%7 >> Cdefe74979b754bd6dd1308de845c3edf%7C90c7a20af34b40bfbc48b9253b6f5d >> 20%7C0%7C0%7C639093728906397670%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU >> 1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIs >> IldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=NOyty8QCsXxVLG6pQ%2FTnBw9PHz%2 >> BdnjH%2B4THCwZNpKmw%3D&reserved=0 (side by side) >>> >>> Diff files showing all changes: >>> >> 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%7Cdefe7497 >> 9b754bd6dd1308de845c3edf%7C90c7a20af34b40bfbc48b9253b6f5d20%7C0%7C >> 0%7C639093728906411073%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnR >> ydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyf >> Q%3D%3D%7C0%7C%7C%7C&sdata=e9yCdr0lk7Nlk0rmZm%2FY2CWwcpqXi51AAPf2f >> 6Mv9qU%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%7Cdefe7 >> 4979b754bd6dd1308de845c3edf%7C90c7a20af34b40bfbc48b9253b6f5d20%7C0 >> %7C0%7C639093728906425530%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGki >> OnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIj >> oyfQ%3D%3D%7C0%7C%7C%7C&sdata=wdhy4vPETjwBiu%2BacZYP10%2FS9NsvjP3R >> QreitEI7Mps%3D&reserved=0 (side by side) >>> >>> For the AUTH48 status of this document, please see: >>> >> 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%7Cdefe74979b754bd6dd1308de845c3edf%7C90c7a20af34b40bfbc4 >> 8b9253b6f5d20%7C0%7C0%7C639093728906441005%7CUnknown%7CTWFpbGZsb3d >> 8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOI >> joiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=gKA8FzOldImR2NLqG13 >> n8NTfqYEm3cU1KSHOQ1Bk8BI%3D&reserved=0 >>> >>> 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:rfc-editor@rfc- >> editor.org> >>>> Gesendet: Donnerstag, 12. März 2026 02:52 >>>> An: mailto:[email protected]; Geib, Rüdiger >> <mailto:[email protected]> >>>> Cc: mailto:[email protected]; mailto:ippm- >> [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://fra01.safelinks.protection.outlook.com/?url=https%3A%2F%2F >> www.rfc- >> editor.org%2Fsearch&data=05%7C02%7Cmohamed.boucadair%40orange.com% >> 7Cdefe74979b754bd6dd1308de845c3edf%7C90c7a20af34b40bfbc48b9253b6f5 >> d20%7C0%7C0%7C639093728906467704%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0e >> U1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCI >> sIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=%2BHO93joZjDtWHSqkwvZ4HCjbvl1 >> UVug4YBTljkHPMVw%3D&reserved=0. >>>> --> >>>> >>>> [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://fra01.safelinks.protection.outlook.com/?url=https%3A%2F%2 >> Fwww.iana.org%2Fassignments%2F&data=05%7C02%7Cmohamed.boucadair%40 >> orange.com%7Cdefe74979b754bd6dd1308de845c3edf%7C90c7a20af34b40bfbc >> 48b9253b6f5d20%7C0%7C0%7C639093728906480640%7CUnknown%7CTWFpbGZsb3 >> d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFO >> IjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=%2B9DKcQaG0BeaLvKR >> wQtO0zQvv046sHbB2oeWQXhV6GU%3D&reserved=0> , 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://fra01.safelinks.protection.outlook.com/?url=https%3A%2F%2F >> www.iana.org%2Fassignments%2Fservice-names-port-numbers%2Fservice- >> names-port- >> numbers.xhtml&data=05%7C02%7Cmohamed.boucadair%40orange.com%7Cdefe >> 74979b754bd6dd1308de845c3edf%7C90c7a20af34b40bfbc48b9253b6f5d20%7C >> 0%7C0%7C639093728906494153%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGk >> iOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUI >> joyfQ%3D%3D%7C0%7C%7C%7C&sdata=kV%2BL%2FqO2CI17505Enty2o51w%2BanGR >> 70H3NhgLCuHZ5g%3D&reserved=0 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://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%7Cdefe74979b754bd6dd1308de845c3ed >> f%7C90c7a20af34b40bfbc48b9253b6f5d20%7C0%7C0%7C639093728906505298% >> 7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMC >> IsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sd >> ata=yti44CzSeGi5unLJO30Q70pdtfQ71f8kRiBXLUbINVE%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%7Cdefe74979b754bd6dd1308de845c3edf%7C90c7a20af34b >> 40bfbc48b9253b6f5d20%7C0%7C0%7C639093728906515817%7CUnknown%7CTWFp >> bGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMi >> IsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=w2y1j8tpFsuc >> U2wEDnhZKhh%2B3XtvZXSUkoQBnEfmsns%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%7Cdefe74979b754bd6dd1308de845c3edf%7C90c7a20af34b >> 40bfbc48b9253b6f5d20%7C0%7C0%7C639093728906526803%7CUnknown%7CTWFp >> bGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMi >> IsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=V437IJ2e1ykN >> KXsjZgk%2BQUvAFmAKTAEUjW7i97CyR1E%3D&reserved=0>. >>>> --> >>>> >>>> [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://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 >> Cdefe74979b754bd6dd1308de845c3edf%7C90c7a20af34b40bfbc48b9253b6f5d >> 20%7C0%7C0%7C639093728906544464%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU >> 1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIs >> IldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=i42hLwrbz1DZJMMPI6AzclYND8FLqe >> JtNnDEZjPT0VE%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. >>>> --> >>>> >>>> [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://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%7Cdefe74979b754bd6dd1308de845c >> 3edf%7C90c7a20af34b40bfbc48b9253b6f5d20%7C0%7C0%7C6390937289065684 >> 90%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDA >> wMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C >> &sdata=lQygPGqzTdg2QCd%2BaBUsXZ6jWq9rgamlKRCWaoLK92o%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. >>>> >>>> [Ruediger] drew Error 403 >>>> >>>> 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%2Fnist-research-library%2Fnist-technical-series-publications- >> author- >> instructions%23table1&data=05%7C02%7Cmohamed.boucadair%40orange.co >> m%7Cdefe74979b754bd6dd1308de845c3edf%7C90c7a20af34b40bfbc48b9253b6 >> f5d20%7C0%7C0%7C639093728906584131%7CUnknown%7CTWFpbGZsb3d8eyJFbXB >> 0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpb >> CIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=2GSXLapNaTefhX%2BukLz7TsE9m >> Y9Snkz9OLMDUTVPlSM%3D&reserved=0> >>>> 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://fra01.safelinks.protection.outlook.com/?url=https%3A%2F%2 >> Fwww.rfc- >> editor.org%2Ffaq%2F&data=05%7C02%7Cmohamed.boucadair%40orange.com% >> 7Cdefe74979b754bd6dd1308de845c3edf%7C90c7a20af34b40bfbc48b9253b6f5 >> d20%7C0%7C0%7C639093728906596404%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0e >> U1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCI >> sIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=17lPHNYhALXeglOuNNek9APJBiXLQ >> pbcPjYuVLAsnBM%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%7Cdefe74979b754 >> bd6dd1308de845c3edf%7C90c7a20af34b40bfbc48b9253b6f5d20%7C0%7C0%7C6 >> 39093728906607298%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUs >> IlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D% >> 3D%7C0%7C%7C%7C&sdata=CCvFBL53EggTa4aG0QKyJdP8XMi6ogduXWoShTFJpzU% >> 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%7Cdefe749 >> 79b754bd6dd1308de845c3edf%7C90c7a20af34b40bfbc48b9253b6f5d20%7C0%7 >> C0%7C639093728906618815%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOn >> RydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoy >> fQ%3D%3D%7C0%7C%7C%7C&sdata=LZWA7WOvjvxnyCwpdWLhEl3BOy1I6H%2BlZh0e >> sBcgnZg%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 >>>> >>>> * 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://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 >> Cdefe74979b754bd6dd1308de845c3edf%7C90c7a20af34b40bfbc48b9253b6f5d >> 20%7C0%7C0%7C639093728906630819%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU >> 1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIs >> IldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=eUrc2ZQpinKtpG%2B4qCL96Ipxr%2F >> dJpUwaIuGHdgcGo%2Fw%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%7Cdefe74979b754bd6dd1308de845c >> 3edf%7C90c7a20af34b40bfbc48b9253b6f5d20%7C0%7C0%7C6390937289066411 >> 44%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDA >> wMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C >> &sdata=Tl04wyCnYXKF0Z5SHWN507rv5nhSxFyfrF9W76dnDUo%3D&reserved=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, >>>> 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://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%7Cdefe74979b754bd6dd1308de845c3edf%7C90c7a20af34b40 >> bfbc48b9253b6f5d20%7C0%7C0%7C639093728906652023%7CUnknown%7CTWFpbG >> Zsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIs >> IkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=lX1pXsvoNo6qpt >> 2qxLCOYTAjgNE8dO02XaX9F9DB0B0%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%7Cdefe74979b754bd6dd1308de845c3edf%7C90c7a20af34b4 >> 0bfbc48b9253b6f5d20%7C0%7C0%7C639093728906662326%7CUnknown%7CTWFpb >> GZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiI >> sIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=7zePaJ%2Fl1Zd >> %2Ffcqcn6oGw8T0yy2BeP%2Bp1Gc%2FDhLpoYw%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%7Cdefe74979b754bd6dd1308de845c3edf%7C90c7a20af34b40 >> bfbc48b9253b6f5d20%7C0%7C0%7C639093728906672903%7CUnknown%7CTWFpbG >> Zsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIs >> IkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=BxT2yKbjCyj%2B >> heocG6KVkIZP%2FGjERyH9I%2FsvrONHlUo%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%7Cdefe74979b754bd6dd1308de845c3edf%7C90c7a20af34b40 >> bfbc48b9253b6f5d20%7C0%7C0%7C639093728906682887%7CUnknown%7CTWFpbG >> Zsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIs >> IkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=n0uX36VTU986%2 >> Bn5uSiBuT91HU%2Fle0L6PBQ7xX9QoTlE%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%7Cdefe7497 >> 9b754bd6dd1308de845c3edf%7C90c7a20af34b40bfbc48b9253b6f5d20%7C0%7C >> 0%7C639093728906693011%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnR >> ydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyf >> Q%3D%3D%7C0%7C%7C%7C&sdata=yHMpZH1Hr2MnK4xBjR7IDv%2FFxh0gSaH7ISPKq >> EVsY5w%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%7Cdefe7 >> 4979b754bd6dd1308de845c3edf%7C90c7a20af34b40bfbc48b9253b6f5d20%7C0 >> %7C0%7C639093728906707387%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGki >> OnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIj >> oyfQ%3D%3D%7C0%7C%7C%7C&sdata=GpLL2Jj6iTwcgEWni%2F7YvLyfOspflxuv9L >> j8RnkSmdI%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%7Cdefe >> 74979b754bd6dd1308de845c3edf%7C90c7a20af34b40bfbc48b9253b6f5d20%7C >> 0%7C0%7C639093728906718271%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGk >> iOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUI >> joyfQ%3D%3D%7C0%7C%7C%7C&sdata=WrOsIzftFufeEj1Rrp5btptf3HRFWR4GWRe >> AB%2BYUH0c%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%7Cdefe74979b754bd6dd1308de845c3edf%7C90c7a20af34b40bfbc4 >> 8b9253b6f5d20%7C0%7C0%7C639093728906729843%7CUnknown%7CTWFpbGZsb3d >> 8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOI >> joiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=3Es%2BmYmvZIPyBm%2F >> 0Cp7H%2BBqG57Mb6fVmh%2FZsvZoBTy4%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 -- mailto:auth48archive@rfc- >> editor.org >>>> To unsubscribe send an email to mailto:auth48archive- >> [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] -- auth48archive mailing list -- [email protected] To unsubscribe send an email to [email protected]
