Hi all, Please see inline.
Cheers, Med > -----Message d'origine----- > De : Len Ciavattone <[email protected]> > Envoyé : mardi 17 mars 2026 22:56 > À : [email protected] > Cc : [email protected]; BOUCADAIR Mohamed INNOV/NET > <[email protected]>; [email protected]; ippm- > [email protected]; [email protected]; [email protected]; > [email protected] > Objet : Re: AUTH48: RFC-to-be 9946 <draft-ietf-ippm-capacity- > protocol-25> for your review > > > Karen, > I've included responses below marked as [Authors]. Please let me > know if any further info is needed. > > Thank you, > Len > > On Tue, Mar 17, 2026 at 8:20 AM <[email protected]> wrote: > > > Hi Karen, hi Len, hi Med > > > > Karen, thanks for your response and further questions. Med, > regarding > > the registry issue, KDF HMAC-SHA-256 , I'd prefer you to comment > and help. > > Neither Len nor I are IETF registry experts. > > > > Len, I'd suggest that you reply to Karen directly regarding the > open > > points apart from the above registry ref one. > > > > I've marked my comments [RG]. > > > > Regards, > > > > Ruediger > > > > -----Ursprüngliche Nachricht----- > > Von: Karen Moore <[email protected]> > > Gesendet: Dienstag, 17. März 2026 03:34 > > An: [email protected]; Geib, Rüdiger > > <[email protected]>; [email protected] > > Cc: [email protected]; [email protected]; > > [email protected]; [email protected]; auth48archive@rfc- > editor.org > > 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. > [Med] Agree, per RFC 7210: The registry has three columns. The first column is a string of Unicode characters encoded in UTF-8 representing the name of a KDF. The second column is a string of Unicode characters encoded in UTF-8 providing a brief description of the KDF. The third column is a reference to a specification defining the KDF, if available. The reference is not about the doc that registered the entry but the one that specifies the KDF. > > > > ... > > 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%7Cbeea15fd8832495e393a08de84356288%7C90c7a20af34b40 > bfbc > > > 48b9253b6f5d20%7C0%7C0%7C639093562274072778%7CUnknown%7CTWFpbGZsb3 > d8ey > > > JFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoi > TWFp > > > bCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=aSQzTz89Mc9QTgai4rm6F8aQgi > XOgH > > vTxQll5asnYvE%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%7Cbeea15fd8832495e393a08de84356288%7C90c7a20af34b40 > bfbc > > > 48b9253b6f5d20%7C0%7C0%7C639093562274118496%7CUnknown%7CTWFpbGZsb3 > d8ey > > > JFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoi > TWFp > > > bCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=FkVy5y4PqTJdCUfeOYTXLpNlFX > Kh%2 > > BrXoTmFMWgMjsfw%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%7Cbeea15fd8832495e393a08de84356288%7C90c7a20af34b40 > bfbc > > > 48b9253b6f5d20%7C0%7C0%7C639093562274149704%7CUnknown%7CTWFpbGZsb3 > d8ey > > > JFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoi > TWFp > > > bCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=GON4aODEEs24aF9zcNV6N0kXNT > 5fsB > > wijGA6E5zZPyI%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%7Cbeea15fd8832495e393a08de84356288%7C90c7a20af34b4 > 0bfb > > > c48b9253b6f5d20%7C0%7C0%7C639093562274169811%7CUnknown%7CTWFpbGZsb > 3d8e > > > yJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjo > iTWF > > > pbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=JRwpG%2BDTnfuAAPPJAvexu5s > x5Jh > > VFP80QN5nYNN7xM8%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%7Cmoha > > > med.boucadair%40orange.com%7Cbeea15fd8832495e393a08de84356288%7C90 > c7a2 > > > 0af34b40bfbc48b9253b6f5d20%7C0%7C0%7C639093562274188949%7CUnknown% > 7CTW > > > FpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4z > MiIs > > > IkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=eULFG2g3AvYn4R > EJ4M > > smLUJrdVY4bxgXBZbx3juL1ok%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%7Cm > > > ohamed.boucadair%40orange.com%7Cbeea15fd8832495e393a08de84356288%7 > C90c > > > 7a20af34b40bfbc48b9253b6f5d20%7C0%7C0%7C639093562274208585%7CUnkno > wn%7 > > > CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXa > W4zM > > > iIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=Hwn%2F1BNOL > m%2F > > 7xFCizHTfTEsMnWLg8E3qGDLnL5ES7AE%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.bo > > > ucadair%40orange.com%7Cbeea15fd8832495e393a08de84356288%7C90c7a20a > f34b > > > 40bfbc48b9253b6f5d20%7C0%7C0%7C639093562274227575%7CUnknown%7CTWFp > bGZs > > > b3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIk > FOIj > > > oiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=EOgpkefPSZl%2BbmEKma > c2k1 > > %2B%2BffJbAEiw4QmWj0oBT1g%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%7Cbeea15fd8832495e393a08de84356288%7C90c7a > 20af > > > 34b40bfbc48b9253b6f5d20%7C0%7C0%7C639093562274244642%7CUnknown%7CT > WFpb > > > GZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiI > sIkF > > > OIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=Z0woFlAF%2FNBR05d > QPnr > > UyLSTM3wb5Wyq6gdm3gzPYwk%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%7Cbeea15fd8832495e393a08de84356288%7C90c7a20af34b40bfbc4 > 8b92 > > > 53b6f5d20%7C0%7C0%7C639093562274261820%7CUnknown%7CTWFpbGZsb3d8eyJ > FbXB > > > 0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpb > CIsI > > > ldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=IkgkSG8FKe5LDE2JEX2yqV2ctStyFlb > 8%2F > > vAFOiJ1SeY%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:[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:ippm- > [email protected]; mailto: > > [email protected]; mailto:[email protected]; mailto: > > [email protected]; mailto:auth48archive@rfc- > editor.org > > > 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% > 7Cbeea15fd8832495e393a08de84356288%7C90c7a20af34b40bfbc48b9253b6f5 > d20%7C0%7C0%7C639093562274278658%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0e > U1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCI > sIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=f2Yx5PyloYrOg7FeWevKU%2Fb3zMY > E5BT5f6%2B0QRVcjb4%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 ____________________________________________________________________________________________________________ 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]
