Hi Karen, all,
(1) OK with the change in Figure 11.
(2) Len/Ruediger, I lost the context what is meant by the following
"XXXX_CRSP_NONE":
CURRENT:
cmdResponse: A one-octet field. All Request PDUs always have a
Command Response of XXXX_CRSP_NONE.
(3) Karen, please find below some nits and edits I flagged when reviewing the
full text:
# Title
OLD: The UDP Speed Test Protocol for One-Way IP Capacity Metric Measurement
NEW: The UDP Speed Test Protocol (UDPSTP) for One-Way IP Capacity Metric
Measurement
# Section 1
## Nit
OLD: The performance community has seen the development of Informative
NEW: The performance community has seen the development of informative
## BTC acronym is introduced, but not used in the doc
Maybe delete that it or consider using it in this part
CURRENT:
controlled Bulk Transport Capacity measurement or Speed Test,
respectively, is based on UDP rather than TCP.
## delete "secondarily"
OLD:
Additionally, because the protocol uses synthetic payload
data and contains no direct user information, a decision was made to
forgo encryption support. Secondarily, this is also expected to
increase the number of low-end devices that can support the test
methodology.
NEW:
Additionally, because the protocol uses synthetic payload
data and contains no direct user information, a decision was made to
forgo encryption support. This is also expected to
increase the number of low-end devices that can support the test
methodology.
# Please move Sections 1.1 and 1.2 to be a separate NEW Section "Conventions
and Terminology"
# Section 2
OLD: The primary application of the protocol described here
NEW: The primary application of UDPSTP
# Section 3
## be affirmative
OLD: It shall be the responsibility of the client process
NEW: It is the responsibility of the client process
## Move a reference earlier
OLD:
All messages defined by this document SHALL use UDP transport.
...
The protocol uses UDP transport [RFC0768]
NEW:
All messages defined by this document SHALL use UDP transport [RFC0768].
...
The protocol uses UDP transport
## Please move this text to be under the new terminology section
CURRENT:
In
this document, the term "message" and the term "Protocol Data Unit",
or "PDU" [RFC5044], are used interchangeably.
## nit
OLD: regardless of whether it's IPv4 or
NEW: regardless of whether it is IPv4 or
# Section 4.1
## clarity
OLD: The requirements following below and
NEW: The requirements listed in this section
## This is about requirements
OLD:
The load rate adjustment algorithm for capacity measurement
requirements is as follows:
NEW:
The load rate adjustment algorithm for capacity measurement
requirements are as follows:
# Section 4.4.1
KDF already expanded and used as such prior to this section
OLD: A Key Derivation Function (KDF)
NEW: A KDF
# Section 4.5: port number
OLD:
The firewall at the server MUST be configured with an open pinhole
for the server IP address and standard UDP port of the server. All
messages sent by the client to the server use this standard UDP port.
NEW:
The firewall at the server MUST be configured with an open pinhole
for the server IP address and standard UDP port number of the server. All
messages sent by the client to the server use this standard UDP port number.
Please s/port/port number in other occurrences of the document, except for
"port range"
# Section 6.2.1
OLD
* Load rate adjustment algorithm: lowThresh, upperThresh,
useOwDelayVar, highSpeedDelta, slowAdjThresh, seqErrThresh,
highSpeedDelta, ignoreOooDup, rateAdjAlgo
* Test duration/intervals: trialInt, testIntTime, subIntPeriod
NEW:
* Load rate adjustment algorithm: lowThresh, upperThresh,
useOwDelayVar, highSpeedDelta, slowAdjThresh, seqErrThresh,
highSpeedDelta, ignoreOooDup, and arateAdjAlgo
* Test duration/intervals: trialInt, testIntTime, and subIntPeriod
# Section 5.2/7.1: more than a note
OLD:
Note: If any of the above checks fail, the message SHALL be
considered invalid.
NEW:
If any of the above checks fail, the message SHALL be
considered invalid.
Cheers,
Med
> -----Message d'origine-----
> De : Karen Moore <[email protected]>
> Envoyé : jeudi 19 mars 2026 01:25
> À : Len Ciavattone <[email protected]>; BOUCADAIR Mohamed
> INNOV/NET <[email protected]>; [email protected]
> Cc : [email protected]; [email protected]; ippm-
> [email protected]; [email protected]; [email protected]
> Objet : [AD] Re: AUTH48: RFC-to-be 9946 <draft-ietf-ippm-capacity-
> protocol-25> for your review
>
>
> Dear Len, Ruediger, and *Med (AD),
>
> Thank you for your replies. We have updated our files
> accordingly. Ruediger, we have noted your approval on the AUTH48
> status page
> (https://fra01.safelinks.protection.outlook.com/?url=https%3A%2F%2
> Fwww.rfc-
> editor.org%2Fauth48%2Frfc9946&data=05%7C02%7Cmohamed.boucadair%40o
> range.com%7C7fd48a8a97064b1efa3308de851355f5%7C90c7a20af34b40bfbc4
> 8b9253b6f5d20%7C0%7C0%7C639094515287999814%7CUnknown%7CTWFpbGZsb3d
> 8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOI
> joiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=4IxZeLcPGMWdFmeBSdv
> 3joQfs6DdG9pjRv%2FwKDYa7F0%3D&reserved=0). Len, please review the
> updates and let us know if any further changes are needed or if
> you approve the document in its current form.
>
> *Med, as AD, please review the beyond editorial changes made to
> Figure 11 (Section 7.2) and let us know if you approve
> (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%7C7f
> d48a8a97064b1efa3308de851355f5%7C90c7a20af34b40bfbc48b9253b6f5d20%
> 7C0%7C0%7C639094515288038781%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hc
> GkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIld
> UIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=BvLIRxPiy5DoecfdH8%2FomSDFw2SyeDh
> nuV3JLphG6j0%3D&reserved=0).
>
>
> —Files (please refresh)—
>
> We will await approvals from Med and Len 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%7C7fd48a8a97064b1efa3308de851355f5%7C90c7a20af34b40
> bfbc48b9253b6f5d20%7C0%7C0%7C639094515288071826%7CUnknown%7CTWFpbG
> Zsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIs
> IkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=Ymyq7ipgobWUbP
> asoYzB1ms5maisbt2IDD1vefEsKeM%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%7C7fd48a8a97064b1efa3308de851355f5%7C90c7a20af34b40
> bfbc48b9253b6f5d20%7C0%7C0%7C639094515288108198%7CUnknown%7CTWFpbG
> Zsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIs
> IkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=ji7zOMcifYHhqL
> tFD4DhSzwweLMUcY9ZQddLCtYmljY%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%7C7fd48a8a97064b1efa3308de851355f5%7C90c7a20af34b40
> bfbc48b9253b6f5d20%7C0%7C0%7C639094515288155496%7CUnknown%7CTWFpbG
> Zsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIs
> IkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=4%2FiNSmq8Si0U
> hJp5lFTNdzHE5voUSFeen6YnlmQ5YJA%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%7C7fd48a8a97064b1efa3308de851355f5%7C90c7a20af34b4
> 0bfbc48b9253b6f5d20%7C0%7C0%7C639094515288180586%7CUnknown%7CTWFpb
> GZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiI
> sIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=dxsIV9OEJwFpg
> YG9w9pJ6VyQXNqj5bk1pvyx9YaE1NI%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%7C7f
> d48a8a97064b1efa3308de851355f5%7C90c7a20af34b40bfbc48b9253b6f5d20%
> 7C0%7C0%7C639094515288195868%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hc
> GkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIld
> UIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=5OzUJD0mh2JhBe25sK0ryg%2F7pU%2FAk
> 7QRRzFFj9k72QQ%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
> C7fd48a8a97064b1efa3308de851355f5%7C90c7a20af34b40bfbc48b9253b6f5d
> 20%7C0%7C0%7C639094515288213263%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU
> 1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIs
> IldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=hWluOIBOt%2Bn4TVYAn0e67uuy3Wt3
> IIwIX%2BO%2BR8iiwQg%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%7C7fd4
> 8a8a97064b1efa3308de851355f5%7C90c7a20af34b40bfbc48b9253b6f5d20%7C
> 0%7C0%7C639094515288226024%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGk
> iOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUI
> joyfQ%3D%3D%7C0%7C%7C%7C&sdata=8YWCYBYJsCR0fuSgJ1ycDz4eJMGO88xTDEC
> NCYm1uEA%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%7C7
> fd48a8a97064b1efa3308de851355f5%7C90c7a20af34b40bfbc48b9253b6f5d20
> %7C0%7C0%7C639094515288242317%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1h
> cGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIl
> dUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=jbTK1s1%2FNgus2KU959x%2Bo%2BkCYZ
> CTGO%2BIfZi2%2BGottu4%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%7C7fd48a8a
> 97064b1efa3308de851355f5%7C90c7a20af34b40bfbc48b9253b6f5d20%7C0%7C
> 0%7C639094515288279523%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnR
> ydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyf
> Q%3D%3D%7C0%7C%7C%7C&sdata=XfPqhxLcw0hTC77WghOhMlOBlZz7RRhTnx26jt9
> LZrc%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%7C7fd48
> a8a97064b1efa3308de851355f5%7C90c7a20af34b40bfbc48b9253b6f5d20%7C0
> %7C0%7C639094515288299598%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGki
> OnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIj
> oyfQ%3D%3D%7C0%7C%7C%7C&sdata=2Nc2Rj4jki3vW2aLiTEkGSq4N1BRu64o880A
> FGdid1E%3D&reserved=0 (side by side)
>
> Best regards,
>
> Karen Moore
> RFC Production Center
>
> > On Mar 18, 2026, at 8:34 AM, Len Ciavattone
> <[email protected]> wrote:
> >
> > Karen,
> > Here are a few things I found doing a full review...
> >
> > Section 3.2
> > Change "the tool" to "UDPSTP" (given that the RFC describes a
> protocol and not a tool)
> > "Unrestricted use of the tool could lead to traffic
> starvation..." should be changed to "Unrestricted use of UDPSTP
> could lead to traffic starvation..."
> >
> > Section 4.6
> > “used in the IPv4 packet Header Chesksum specification (see
> Section 3.1 of [RFC0791]).”
> > Misspelled “Checksum”
> >
> > Section 5.1
> > “maxBandwith: A two-octet field. ..."
> > Misspelled "maxBandwidth"
> >
> > Section 7.1
> > Change "discreet" (cautious) to "discrete" (separate)
> > "it SHALL use the discreet transmission" should be "it SHALL use
> the discrete transmission"
> >
> > Section 7.2
> > The indentation after "sisSav: Sub-Interval statistics...",
> which should only include fields "rxDatagrams:" through
> "accumTime:", should revert back to no indentation starting at
> "clockDeltaMin:". This is where the parent structure fields start
> again.
> >
> > Section 7.2, Figure 11 (two issues with "struct subIntStats
> {...}")
> > 1) Fields "rttMinimum" and "rttMaximum" should be
> "rttVarMinimum" and "rttVarMaximum" to match what is shown in
> figure 10 and described in the text as
> "rttVarMinimum/rttVarMaximum (in sisSav): Two four-octet
> fields...". Also, the comments for these fields should be updated
> to reflect this (see below).
> > 2) The structure should be enclosed within "#pragma pack(push,
> 1)" and "#pragma pack(pop)" statements for proper C memory
> alignment.
> > Here is the updated structure (also, please keep the comments
> aligned appropriately):
> > #pragma pack(push, 1)
> > struct subIntStats {
> > uint32_t rxDatagrams; // Received datagrams
> > uint64_t rxBytes; // Received bytes (64 bits)
> > uint32_t deltaTime; // Time delta (us)
> > uint32_t seqErrLoss; // Loss sum
> > uint32_t seqErrOoo; // Out-of-order sum
> > uint32_t seqErrDup; // Duplicate sum
> > uint32_t delayVarMin; // Delay variation minimum (ms)
> > uint32_t delayVarMax; // Delay variation maximum (ms)
> > uint32_t delayVarSum; // Delay variation sum (ms)
> > uint32_t delayVarCnt; // Delay variation count
> > uint32_t rttVarMinimum; // Minimum RTT variation (ms)
> > uint32_t rttVarMaximum; // Maximum RTT variation (ms)
> > uint32_t accumTime; // Accumulated time (ms)
> > };
> > #pragma pack(pop)
> >
> >
> > Thank you,
> > Len
> >
> >
> >
> > On Tue, Mar 17, 2026 at 3:34 PM Karen Moore <[email protected]
> editor.org> wrote:
> > 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%7C7f
> d48a8a97064b1efa3308de851355f5%7C90c7a20af34b40bfbc48b9253b6f5d20%
> 7C0%7C0%7C639094515288320046%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hc
> GkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIld
> UIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=EIInoXMvLKXw2NAXmY0RrzbjWmchkleJt
> c8h%2BqTHUcs%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%7C7fd48a8a97064b1efa3308de851355f5%7C90c7a20af34b40
> bfbc48b9253b6f5d20%7C0%7C0%7C639094515288340236%7CUnknown%7CTWFpbG
> Zsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIs
> IkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=McNnnEGbf1HojA
> SgBbjWfARC5azCgIKMKIA081VxTg0%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%7C7fd48a8a97064b1efa3308de851355f5%7C90c7a20af34b40
> bfbc48b9253b6f5d20%7C0%7C0%7C639094515288357533%7CUnknown%7CTWFpbG
> Zsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIs
> IkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=8uongv%2BJ%2FT
> t%2BnSBxi1E2B2h03mx8jXGAu8EaVQU7EnU%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%7C7fd48a8a97064b1efa3308de851355f5%7C90c7a20af34b40
> bfbc48b9253b6f5d20%7C0%7C0%7C639094515288374449%7CUnknown%7CTWFpbG
> Zsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIs
> IkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=xATj8S8NyevmXK
> hjbjt3%2Bd05oT2I7Dw6Wb4m3%2BIZCHs%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%7C7fd48a8a97064b1efa3308de851355f5%7C90c7a20af34b4
> 0bfbc48b9253b6f5d20%7C0%7C0%7C639094515288388857%7CUnknown%7CTWFpb
> GZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiI
> sIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=hjJitNxJs%2BR
> H2yJIKmBI4XOwVlyXv%2BOStQZAH3Fijxk%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%7C7f
> d48a8a97064b1efa3308de851355f5%7C90c7a20af34b40bfbc48b9253b6f5d20%
> 7C0%7C0%7C639094515288428386%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hc
> GkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIld
> UIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=EOOzTgx8Yi15CRfPyEEmLl304QMUSGTWe
> HEKyKaiSQ4%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
> C7fd48a8a97064b1efa3308de851355f5%7C90c7a20af34b40bfbc48b9253b6f5d
> 20%7C0%7C0%7C639094515288453926%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU
> 1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIs
> IldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=D96nLCrXOsPEA298%2B3pn3xBSX4s0
> C3V%2FrMYokyGgldQ%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%7C7fd4
> 8a8a97064b1efa3308de851355f5%7C90c7a20af34b40bfbc48b9253b6f5d20%7C
> 0%7C0%7C639094515288467198%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGk
> iOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUI
> joyfQ%3D%3D%7C0%7C%7C%7C&sdata=AMPQwF0vK7VgmdPI2XhBfihwmysmeEgYysC
> JqnrqMjc%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%7C7
> fd48a8a97064b1efa3308de851355f5%7C90c7a20af34b40bfbc48b9253b6f5d20
> %7C0%7C0%7C639094515288479043%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1h
> cGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIl
> dUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=jA7WJdf3w7X6aUkFz3NCGP%2Bp2rBpqN
> 0iftc0GQU9uUY%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%7C7fd48a8a
> 97064b1efa3308de851355f5%7C90c7a20af34b40bfbc48b9253b6f5d20%7C0%7C
> 0%7C639094515288491467%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnR
> ydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyf
> Q%3D%3D%7C0%7C%7C%7C&sdata=kjPk050UA7cZQbDGSEOtHxWqXxNsn6wT8UqDJay
> Xo9g%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%7C7fd48
> a8a97064b1efa3308de851355f5%7C90c7a20af34b40bfbc48b9253b6f5d20%7C0
> %7C0%7C639094515288503219%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGki
> OnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIj
> oyfQ%3D%3D%7C0%7C%7C%7C&sdata=vCrZbetqRQQ2RTFELxRt%2FCcPEGpIqbx00%
> 2B%2FOVstGYz8%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%7C7fd48a8a97064b1efa3308de851355f5%7C90c7a20af34b40bfbc4
> 8b9253b6f5d20%7C0%7C0%7C639094515288514593%7CUnknown%7CTWFpbGZsb3d
> 8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOI
> joiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=4MGH980a4CCZ6TfqGpq
> Lf1UXwBRjShUT6%2B1YLoUyxno%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%7C7fd48a8a97064b1efa3308de851355f5%7C90c7a20af34b40
> bfbc48b9253b6f5d20%7C0%7C0%7C639094515288526112%7CUnknown%7CTWFpbG
> Zsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIs
> IkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=AV3os54nakjde8
> Y6BK4VEM%2FPVhS7LjZZQ4RUsFwnFZM%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%7C7fd48a8a97064b1efa3308de851355f5%7C90c7a20af34b40
> bfbc48b9253b6f5d20%7C0%7C0%7C639094515288537992%7CUnknown%7CTWFpbG
> Zsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIs
> IkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=vWurRoyZMbqGGk
> Tc%2FaLD67dkWEPSUMM7%2FAyM3BD9Ito%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%7C7fd48a8a97064b1efa3308de851355f5%7C90c7a20af34b40
> bfbc48b9253b6f5d20%7C0%7C0%7C639094515288550309%7CUnknown%7CTWFpbG
> Zsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIs
> IkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=UF%2B2F7IIg7p6
> 0f58uqEk46yodVPjhHtQmbR3FlrHbVI%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%7C7fd48a8a97064b1efa3308de851355f5%7C90c7a20af34b4
> 0bfbc48b9253b6f5d20%7C0%7C0%7C639094515288574333%7CUnknown%7CTWFpb
> GZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiI
> sIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=3lGsLB%2FDre3
> Pc%2FuhxacD1razhAn14S8FZj%2BZ4cNIn44%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%7C7f
> d48a8a97064b1efa3308de851355f5%7C90c7a20af34b40bfbc48b9253b6f5d20%
> 7C0%7C0%7C639094515288639871%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hc
> GkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIld
> UIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=sAT4SP2bM8bnhd94yI2JEbqJWdJNH3DqU
> 4fTCjunIi4%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
> C7fd48a8a97064b1efa3308de851355f5%7C90c7a20af34b40bfbc48b9253b6f5d
> 20%7C0%7C0%7C639094515288689226%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU
> 1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIs
> IldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=U4tqJOGEkDfxPiizewmX4lRI%2FYqD
> 69BdYsBviXF%2BIvc%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%7C7fd48a8a
> 97064b1efa3308de851355f5%7C90c7a20af34b40bfbc48b9253b6f5d20%7C0%7C
> 0%7C639094515288736899%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnR
> ydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyf
> Q%3D%3D%7C0%7C%7C%7C&sdata=CquUKQbhlEQxoOdE3HjEkCyVZIVLYmk%2B6vTUN
> YuYRxw%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%7C7fd48
> a8a97064b1efa3308de851355f5%7C90c7a20af34b40bfbc48b9253b6f5d20%7C0
> %7C0%7C639094515288770157%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGki
> OnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIj
> oyfQ%3D%3D%7C0%7C%7C%7C&sdata=psLx75h9ERa0IND0lMFXMbpVcac2VdP0aGzB
> uckHiro%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%7C7fd48a8a97064b1efa3308de851355f5%7C90c7a20af34b40bfbc4
> 8b9253b6f5d20%7C0%7C0%7C639094515288794990%7CUnknown%7CTWFpbGZsb3d
> 8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOI
> joiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=Ic1vseZLIseX1zOHp4L
> %2BKcuTa7VKV7L8OHvjbXp7Kuk%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-
> [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:[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%
> 7C7fd48a8a97064b1efa3308de851355f5%7C90c7a20af34b40bfbc48b9253b6f5
> d20%7C0%7C0%7C639094515288824920%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0e
> U1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCI
> sIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=3EVsFWNVX%2FrHJJcd%2FOmFsiwov
> HGI1yk6KyjJcACCCAA%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%7C7fd48a8a97064b1efa3308de851355f5%7C90c7a20af34b40bfbc
> 48b9253b6f5d20%7C0%7C0%7C639094515288881165%7CUnknown%7CTWFpbGZsb3
> d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFO
> IjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=p%2B4%2FIif9oJ8ie%
> 2B3aNO26JxXKlKqeiBXxJHCCWLCEspw%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%7C7fd4
> 8a8a97064b1efa3308de851355f5%7C90c7a20af34b40bfbc48b9253b6f5d20%7C
> 0%7C0%7C639094515288970556%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGk
> iOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUI
> joyfQ%3D%3D%7C0%7C%7C%7C&sdata=4%2FkYeUpmrTpBeTIZkD7ObhNSes6cjv9Bt
> kwzNJaYstE%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%7C7fd48a8a97064b1efa3308de851355f
> 5%7C90c7a20af34b40bfbc48b9253b6f5d20%7C0%7C0%7C639094515289032118%
> 7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMC
> IsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sd
> ata=cx2BbfBw8UzrvLrPI%2FlqHCAUVFKedxRzVNpC1PU%2BNg0%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%7C7fd48a8a97064b1efa3308de851355f5%7C90c7a20af34b
> 40bfbc48b9253b6f5d20%7C0%7C0%7C639094515289092418%7CUnknown%7CTWFp
> bGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMi
> IsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=O9ky1WngP0r9
> UOOg2BIRSDXCSjuU7aVI50yTrX4re1c%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%7C7fd48a8a97064b1efa3308de851355f5%7C90c7a20af34b
> 40bfbc48b9253b6f5d20%7C0%7C0%7C639094515289119243%7CUnknown%7CTWFp
> bGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMi
> IsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=lxTh9ORjNVl5
> 2PgAwM77q8YYpVdm2YeEg6k9knYzL90%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
> C7fd48a8a97064b1efa3308de851355f5%7C90c7a20af34b40bfbc48b9253b6f5d
> 20%7C0%7C0%7C639094515289139744%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU
> 1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIs
> IldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=CJL5Jwl69tZX52%2F1%2FtQC0ghbDT
> s4XLFBmg2UqOs1hxY%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%7C7fd48a8a97064b1efa3308de8513
> 55f5%7C90c7a20af34b40bfbc48b9253b6f5d20%7C0%7C0%7C6390945152891584
> 80%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDA
> wMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C
> &sdata=2f7QvpEyzRo38clfZOhqXqPE1JZcIeHwqQSrkDV%2FwGQ%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%7C7fd48a8a97064b1efa3308de851355f5%7C90c7a20af34b40bfbc48b9253b6
> f5d20%7C0%7C0%7C639094515289178516%7CUnknown%7CTWFpbGZsb3d8eyJFbXB
> 0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpb
> CIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=JtlmDvsEdEuMU4iBerJXNq6XvQO
> %2FNZSjhF%2Bg3VD92S0%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%
> 7C7fd48a8a97064b1efa3308de851355f5%7C90c7a20af34b40bfbc48b9253b6f5
> d20%7C0%7C0%7C639094515289248780%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0e
> U1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCI
> sIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=K62p5OAnBaxWYMbReyW2EiwFpTLqI
> Im0KvWQVACf4ek%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%7C7fd48a8a97064
> b1efa3308de851355f5%7C90c7a20af34b40bfbc48b9253b6f5d20%7C0%7C0%7C6
> 39094515289292291%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUs
> IlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%
> 3D%7C0%7C%7C%7C&sdata=ymLe6Qp1lf1CCrmuowytOi8fOcEA1Vxd8tn1XnYDEAA%
> 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%7C7fd48a8
> a97064b1efa3308de851355f5%7C90c7a20af34b40bfbc48b9253b6f5d20%7C0%7
> C0%7C639094515289323139%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOn
> RydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoy
> fQ%3D%3D%7C0%7C%7C%7C&sdata=s2NsUQo%2BSOkwcN%2FLC%2BUb0vAyFNwv9pmJ
> mfMvY%2FueWLs%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
> C7fd48a8a97064b1efa3308de851355f5%7C90c7a20af34b40bfbc48b9253b6f5d
> 20%7C0%7C0%7C639094515289345160%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU
> 1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIs
> IldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=A4tmBOetT9HSpY7E0zGTY9JOvlUH2M
> W1RQDIvm1G1T0%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%7C7fd48a8a97064b1efa3308de8513
> 55f5%7C90c7a20af34b40bfbc48b9253b6f5d20%7C0%7C0%7C6390945152893697
> 26%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDA
> wMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C
> &sdata=vcnAXhuMj4RkfSzjVbLl2MdSjIKYkh8k8h92d%2FRgsvU%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%7C7fd48a8a97064b1efa3308de851355f5%7C90c7a20af34b40
> bfbc48b9253b6f5d20%7C0%7C0%7C639094515289388158%7CUnknown%7CTWFpbG
> Zsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIs
> IkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=My7gvDXscWNOs3
> w5S6K3%2BSkdjy1MFETVrCOydOz6CnM%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%7C7fd48a8a97064b1efa3308de851355f5%7C90c7a20af34b4
> 0bfbc48b9253b6f5d20%7C0%7C0%7C639094515289403917%7CUnknown%7CTWFpb
> GZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiI
> sIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=dVE6koGzAjWwM
> Tvj4Lifpr9v5Vqlzglh5Q2IyQyWK5s%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%7C7fd48a8a97064b1efa3308de851355f5%7C90c7a20af34b40
> bfbc48b9253b6f5d20%7C0%7C0%7C639094515289416324%7CUnknown%7CTWFpbG
> Zsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIs
> IkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=qdAjP8iTKXaLZW
> Uw7Lu%2Frgx8I9iLwbi9%2F3gClajKcNo%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%7C7fd48a8a97064b1efa3308de851355f5%7C90c7a20af34b40
> bfbc48b9253b6f5d20%7C0%7C0%7C639094515289428490%7CUnknown%7CTWFpbG
> Zsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIs
> IkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=m3dmZhregl%2FC
> GcKqiPrlC99QSg903N3AzYYYb1Dad98%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%7C7fd48a8a
> 97064b1efa3308de851355f5%7C90c7a20af34b40bfbc48b9253b6f5d20%7C0%7C
> 0%7C639094515289440067%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnR
> ydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyf
> Q%3D%3D%7C0%7C%7C%7C&sdata=HDzEGRBu6KX0waGJWWhv8InmTSM1%2Fc7G3A9L3
> rDQy20%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%7C7fd48
> a8a97064b1efa3308de851355f5%7C90c7a20af34b40bfbc48b9253b6f5d20%7C0
> %7C0%7C639094515289451952%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGki
> OnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIj
> oyfQ%3D%3D%7C0%7C%7C%7C&sdata=JSSfJEbxbX3FErC%2FZDQ45f8qBSlFUdTu5f
> prpvaXagM%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%7C7fd4
> 8a8a97064b1efa3308de851355f5%7C90c7a20af34b40bfbc48b9253b6f5d20%7C
> 0%7C0%7C639094515289465995%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGk
> iOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUI
> joyfQ%3D%3D%7C0%7C%7C%7C&sdata=hMERKKY2i1Qtauo3jF%2BIRMjvJ%2FL2huY
> kcxwnFhUK4GI%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%7C7fd48a8a97064b1efa3308de851355f5%7C90c7a20af34b40bfbc4
> 8b9253b6f5d20%7C0%7C0%7C639094515289480252%7CUnknown%7CTWFpbGZsb3d
> 8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOI
> joiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=ZS9DvawTRhm5fCiA751
> m2Fm%2FwtnQbr6tAX9p0tHRqHw%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]
