Ballot for draft-ietf-ippm-capacity-protocol-23

Discuss (2025-06-26 for -21) Sent

Thank you for this I-D that defines a method for measuring Network Capacity metrics. The measurement flows generate Internet packet flows that are rate-controlled. The primary concerns are about the use of Datagrams (addressing and packet size), the security model, and the congestion control functions. This is therefore a significant piece of transport work and there is a much longer than a normal DISCUSS. I have updated my ballot below, where resolutions have alreday been implemented in rev-21 and expect to clear the remaining, after more discussion.

---
DISCUSS 2.2 At the end of Section 4.2:
To ensure readers are clear about the importance, I'd strongly recommend to add a note stating that the described method is necessary also to avoid potentially inducing congestion after there is a overload/loss on the control path. 

[GF] One concern could be that the algorithm as specified can be used to mount a DoS attack. That might be inevitable if it is not possible to put safeguards to act to prevent this. That needs to be noted. 

---
DISCUSS 2.4 In section 5.1. on the responsiveness (what CC experts often call aggressive behaviour) of a flow:
I note that the LOAD CONTROL as define uses a statically configured watchdog interval -  which I think allows a flow to contribute excess congestions for 3 seconds after this is detected, longer if small levels of loss/congestion is not considered a trigger. For an arbitrary path RTT this could be a large number of RTTs (e.g. 300 for a 10mS path). 
- There are specific recommendations on the use of UDP that describe this case: RFC 8085.

[GF] Please could you  add the following text after:
/The Method of Measurement discussed there deploys a feedback channel from the receiver to control the sender's transmission rate in near-real-time./
NEW:
Section 8.1 of RFC 9097 specifies requirements for this method.

---
DISCUSS Topics 3: How do we know the suitability of the specified rate adaptation mechanisms?

DISCUSS 3.3  There seems little discussion of the risk to the network and other flows when performing a fixed-rate test, or whether this is applicable usage across an Internet path.

[GF] Please consider a separate discussion of this.

---
DISCUSS Topics 4. Concurrent flows.

4.1 In section 9.0:
   /It is obviously counterproductive to run more than one independent
   and concurrent test/
- Is there a congestion control or DoS issue here, I think so, can we discuss why the I-D says this is allowed without a mechanism to defend against this?

[GF] See DISCUSS 3.3.

---
DISCUSS Topics 5. Definition of an IANA Registry for alternative rate control algorithms.

The present I-D says: "Test Activation PDU Rate Adjustment Algo.  Registry" 
Why should the IETF publish a registry for this protocol with a private space and no overarching congestion control framework?

In 11.2.8, the present I-D says:

   Value   Description             Reference
   (Numeric)
   ===================================================
    A(n/a)  Not used                <this RFC>

    B(0)    Rate algorithm Type B   <this RFC>

    C(1)    Rate algorithm Type C   <this RFC>

   Table 16: Initial Test Activation PDU Rate Adjustment Algo. values

---
DISCUSS 5.3 RFC 9473 has provided guidance on the IETF process if this is being considered for use on Internet paths. Why is the IETF standardising use of a rate adjustment algorithm defined elsewhere, without bounding its over-arching congestion control properties? Please explain how these methods were evaluated, and by whom. How in the future will this be tested for congestion control and how this will be maintained. 

---
DISCUSS 5.4  What is the scope of use for a rate adjustment algorithm defined as experimental. RFC 9473 provided guidance on this topic. Why is this not scoped only for use in limited domains?

---
DISCUSS Topics 6. How are new methods evaluated and specified?

I suggest discussion of how to provide IANA guidance for a new code point.

DISCUSS 6.1 Please see this text:
 /On the other hand, the test configuration MAY use a fixed sending
   rate requested by the client, using the field srIndexConf./
- A fixed rate test brings additional concerns, and I didn't find this analysis. Is there a need to scope this as a non-default mode? Should it be restricted to certain domains. 

[GF] See DISCUSS 3.3.

===

Comment (2025-06-26 for -21) Sent

I have a number of non-blocking comments that I expect could be addressed in the next revision of this I-D:

In section 3:
Typos:/resepcitvely/respectively/
/the bottleneck is congested,/if the bottleneck is congested,/
In section 4.2:
- Is /Once the modes requiring or optionally adding
authentication or encryption are implemented and configured locally,
the unauthenticated mode must be disabled./ - Could this be a MUST?
In section 5,1: /A IANA is/IANA is/
In section 5.2.2: I expect the following text helps, but does this ensure or assist in the firewall traversal?
/To ensure that a server's local firewall will successfully allow
packets received for the new ephemeral port, the server SHALL
immediately send a Null Request with the corresponding values
including the source and destination IP addresses and port numbers./
In 6.1, /continuosly/continuously/
In 6.2, Server Processes Test Activation Request and Generates Response:

In this I-D, the following keyword use seems odd to me and could be improved:
/ After the server receives the Test Activation Request on the new
connection, it MUST choose to accept, ignore or modify any of the
test parameters. /
- is this an exclusive list of things that is required or a list of all that are required? I do wonder if this is simply a list of what the protocol does next?

In section 12: /comprehensability/comprehensibility/
Also in section 12: /sheperded/shepherded/
===
There are some additional NiTs that I noted in rev-21:

/erquirements/requirements/
/sectiomn/secyion/
/PDU timeout which both stop/PDU timeout that both stop/

I agree with the requirement, but I see a problem that this directly follows the discussion of the UDP checksum, but the word checksum could be confused between the two. Could we insert a word before checksum here:, perhaps add the word /PDU/ and a cross reference to section 5.2?
/If a PDU sender is populating the checkSum field,/

Similarly the keyword here could be confused, can we insert /PDU/ before checksum here:
/ If checksum validation fails.../

Query: Ought this message to be rate-limited. i.e., “If sent, this message SHOULD be rate limited to avoid exploitation as a DoS mechanism”.
/The exception is for operations support: server administrators are permitted to send a Setup Response to support operations and troubleshooting./

Can this say a tiny bit more than this:
/note that not-ECT MUST be used./
NEW:
Note: This specification does not provide an ECN-capable transport, therefore the sender SHALL set the ECN field to not_ECT./

===
And finally, so we do not forget waht was discuused, here are the currently resolved DISCUSS positions:
---
Topics from the TSV-ART review. (Thought resolved in rev-21)
The I-D needs to therefore consider implications around security. Thanks to the TSVART team for their review. In the security design, I saw many changes and thank the editors et al for these updates in the present revision. Thanks.
This review also noted the way that datagram size was handled - and I note that this is an important part of any service over UDP. In my review, I found the guidance in the following section is inadequate :
/A simplified approach is to choose the
default datagram size small enough to prevent fragmentation. MTU
size detection prior to a test is out of scope of this document. A
method for a path MTU size discovery, as for example proposed by
[RFC8899], is left for future design and implementation./
- RFC8899 could indeed be applicable, but the requires support is not defined in this specification, so this is more than a future implementation issue. This will actually require changes to the protocol, especially if a method is to be interoperable.
---
Topics 1. Normative Dependencies. (Thought resolved in rev-21)
I would like to discuss the normative dependence on two external references for key components of the design.
There are two Normative References to external documents:
[TR-471] Morton, A,, Editor., "Broadband Forum TR-471: IP Layer
Capacity Metrics and Measurement, Issue 4", September
2024, <https://www.broadband-forum.org/technical/download/
TR-471.pdf>.
[Y.1540] ITU-T, "Internet protocol data communication service - IP
packet transfer and availability performance parameters",
ITU-T Recommendation Y.1540, December 2019,
<https://www.itu.int/rec/T-REC-Y.1540-201912-I/en>.
DISCUSS 1.1 What is the process by which these have been revised by the IETF?
(Thought resolved in rev-21, now defined in I-D.)
- I have a concern about the external definitions for terms, metrics and algorithms used in this I-D.
---
DISCUSS 1.2 TR-471 is used to normatively define a set of parameters - this makes the current I-D normatively dependent on changes to another spec. Has the working group fully considered the implications of changes to these specifications, rather than normatively defining the operation to be identical to the current specification of this external reference?
---
DISCUSS Topics 2. (Thought resolved in rev-21, scope identified and required method added in I-D.)
This I-D defines a protocol layered on top of UDP. Therefore, what level of IETF review has been performed to evaluate the way the flow rate controlled? The I-D is subject to the BCP that defines UDP Usage [RFC8085] that sets out expectations for when the protocol is used in the Internet. It is defined for performance testing, and as such it is possible generate considerable Internet load.
---
DISCUSS 2.1 (Thought resolved in rev-21, scope identified in I-D.)
RFC 2914 defines the need for congestion control. Section 3.1.1, 3.1.2 and 3.1.5 of RFC 8085 provides the current BCP guidance on Congestion Control. RFC9743 (BCP 133) provides guidance on how to specify new congestion control methods. RFC 8084 provides an alternative, to define an envelope that controls the overall envelope of a connection. I think these RFCs apply to this I-D to set the envelope.
---
DISCUSS 2.3 (Thought resolved in rev-21, scope identified in I-D.)
In section 7.1: If I understand the sending rate decrease based on feedback intervals - which seems like it is heading in the correct direction. I do not see how these intervals are adjusted to the path RTT, could they be?
---
DISCUSS 3.1 (Thought resolved in rev-21, required method added in I-D.)
In section 7.1 there is a description of another alternative congestion control method.
Algorithm (B, see [Y.1540]) is a CC algorithm defined outside the IETF, please explain how this has been shown to be safe for use as a CC in the Internet?
---
DISCUSS 3.2 (Thought resolved in rev-21, required method added in I-D.)
In section 7.1: The present I-D says:
/Algorithm B also has two modes for increasing/decreasing the sending
rate:/
If I understand the sending rate decrease based on feedback intervals - which seems like it is heading in the correct direction. I did not see how these intervals adjust to the path RTT. I would like to discuss how they adapt or why they do not?
---
DISCUSS 3.4 (Thought resolved in rev-21, required method added in I-D.)
In section 7.2, Status PDU: Please explain (and specify in the text) what happens in the case of the first para of section 7.2 when there is severe congestion on the return path - I assume this could result in significant loss, and no Status PDU is sent?
The watchdog timer at the Load PDU sender SHALL be reset each time a
Status PDU is received. See non-graceful test stop in Section 8 for
handling the watchdog timeout expiration at each endpoint.
---
DISCUSS 3.5 (Thought resolved in rev-21, applicability added in I-D.)
In section 7.2, Status PDU. The present I-D says:
/ The watchdog timer at the Load PDU sender SHALL be reset each time a
Status PDU is received. See non-graceful test stop in Section 8 for
handling the watchdog timeout expiration at each endpoint./
- Please explain (and specify in the text) why is it safe to reset the timer even if the Status PDU does not indicate correct reception?
---
DISCUSS 5.1: (Thought resolved in rev-21, removed.)
What is Value A in Table 16 (PDU Rate Adjustment)?
---
DISCUSS 5.2 : (Thought resolved in rev-21, required method added in I-D.)
There is no specification in this I-D for these algorithms.
---
DISCUSS 6.2 : (resolved in rev-21)
Please add a note to the reaction to lack of feedback in Section 4.2:
I agree that "the test session will prematurely terminate (no further load traffic SHALL be transmitted)"
- To be clear about the importance, I'd recommend to add a note saying this is necessary also
to avoid potentially inducing congestion after there is a overload/loss
on the control path.
---
DISCUSS 7.1 (Resolved in rev-21, aligns with recommended usage.)
In Section 4.5 on Optional Checksum, ought to be required.
---
DISCUSS 7.2 (Resolved in rev-21, aligns with recommended usage.)
IPv6 requires a UDP checksum except for very specific usage, this does not appear to be one of those cases (tell me if I am wrong), and so can this require an IPv6 checksum?
---
DISCUSS Topic 8: (Resolved in rev-21, aligns with recommended usage.)
ECN:RFC 3819 specifies the requirements for new transport methods to utilise an ECT() code point (see also 3.1.7 of RFC 8085). The transfer as defined does not support ECN, i.e. it does not change its rate in response to ECN marks.
---
DISCUSS 9.1 (Resolved in rev-21)
I think this looks like it has no multicast considerations and hence it ought to be scoped to only unicast and not broadcast or multicast addresses. Could this be specified for unicast address only ?
---
DISCUSS 9.2 (Resolved in rev-21)
Could this method be used with an Anycast address?
---
DISCUSS Topic 10: (Resolved in rev-21)
Some parameters appear underspecified in this I-D, please check. e.g.: seqErrLoss/seqErrOoo/seqErrDup

Discuss (2025-06-24 for -20) Sent

The main point of my DISCUSS is around the protocols authentication and encryption.
It is a homegrown protocol, very restricted in cryptographic options, no ephemeral
key exchange and unsafe use of PSK. Why is this protocol not using DTLS for its
security features instead of inventing its own using low level openssl functions
as a security protocol ?

All of the Cryptogrpahic issues would go away, if you just optionally allow to use DTLS 1.2
or later.

1) secure hash algorithm

The document claims a number of times that low power devices are an important use
case. If so, AES-CMAC (RFC4494) would be more appropriate than HMAC-SHA256

2) using the KDF

The KDF SHALL use the following parameters:
[...]

It should more clearly specify thow these parameters are used. One likely method
is concatenation in the order of the listed parameters, but if so, it should
clearly state this, eg KDF(Kin || Label || Context || r) and it should specify
how to deal with input that is larger in size than the input of the KDF.

The authUnixTime field serves as a nonce

This KDF use is not safe against writing a bruce force engine of captured
traffic where the only unknown is the PreSharedKey. I think this could be
cracked in realtime using something like https://hashcat.net/hashcat/ for
every PSK under 16 characters. As PSK is "out of scope", it seriously runs
the risk of going in the clear in email or a phone call with a low entropy
phrase.

3) auth and enc key generation

Why are the authenticaion and encryption keys of a different length/strength ?
This would make the resulting strength the least of the two, eg 128bit.
It only costs 1 HMAC-SHA2 operation more (4 instead of 3) to get 256bit keys
for both. Or, you could use AES-CCM / AES-GCM and use an AEAD when encryption
is needed which requires 256bit (or you can pick/choose 128bit)

Which brings me to another point, at this point CBC should really not be
deployed for new protocols anymore. Please use AES-CCM or AES-GCM. Especially
if low power devices are being targeted, using AES-CBC-SHA256 is far more
expensive (and less secure) compared to AES-CCM/AES-GCM (and SHA256).
Of course, this does require safe handling of the counters.

4) encryption streams

How are different streams using encryption? Same key? How is uniqueness in IV
ensured? Or when switching to CCM/GCM, how are counters not re-used?

5) random

The sender SHALL populate the initVector field with a
cryptographically random 16-octet Initialization Vector (IV),

On low power devices, getting a good random source is not always easy
either. This would be easier if one were to use an AEAD as well, and
use the authUnixTime as a nonce with a proper counter instead of a
random IV. For AES-CBC you would have to use an explicit IV (eg send
it over the wire) to allow decrypting out of order packets (eg see
RFC3602) which means generating randomness per packet. With AEAD
you only need to guarantee uniqueness, not unpredictability (aka random).

I also would think the protocol should not hardcode AES-CBC-SHA256, but
use a registry similar to AlgID.

AUTHMODE_3: Optional Encrypted mode

You want to say: Optional Encrypted plus Authenticated Control and Data phase mode.

Authentication and encryption methods and requirements steadily evolve.
Alternate encryption and/or authentication modes provide for algorithm
agility by defining a new Mode, whose support is indicated by an assigning
a suitable "Test Setup PDU Authentication Mode Registry" value (see Section 11.3.4 ).

But this registry only has different modes of using authentication or encryption. All the
actual values for these (HMAC-SHA256 and AES-CBC) are hardcoded and implicit, so when one
in the future would add something else (eg encryption with AES-CMAC and AES-CTR) the current
naming does not work at all for this registry.

Comment (2025-06-24 for -20) Sent

Titel says:

        Test Protocol for One-way IP Capacity Measurement

Abstract says:

        This document defines the UDP Speed Test Protocol for conducting
        RFC 9097 and other related measurements.

The Introduction says:

        This document specifies the UDP Speed Test Protocol (UDPSTP)

Can these terms be made consistent?


I am skeptical of the value of speed meassurements for anything using specific ports,
as it is allows the network to treat these differently from "regular" traffic. Eg we
commonly see "speedtest.net" outperforming reality. I see it can still be useful in
labs (but then I question the authentication/encryption parts being neccessary at all)


       Test Setup Request and Response: If a server instance is
        identified with a host name that resolves to both IPv4/IPv6
        addresses, it is recommended to use the first address returned
        in the name resolution response - regardless, whether it's IPv4
        or IPv6. Thus, the decision on the preferred IP address family
        is left to the DNS operator.

I don't understand this part. If the application sends out a query for AAAA
before A, or A before AAAA, that will make a difference that is not "left to
the DNS operator" at all. There is currently no way to ask for A + AAAA within
the same DNS packet, but once it does (there are efforts on their way) then
both would arrive at the same time in the same answer.


        The encrypted portion of each PDU SHALL contain the padding required

I believe you mean "the cleartext to be encrypted shall be padded to ...." ?

Comment (2025-06-19 for -20) Sent

Thanks for addressing my questions. As the remainder of my questions are covered by Gory's DISCUSS, I am changing my DISCUSS to No Objections. Thanks for all the work.

Comment (2025-06-24 for -20) Sent

Thanks to Brian Weis for their secdir review.

I support Paul's discuss (this ballot is a no objection only because he has already balloted the discuss).

Section 4.2 and 4.3:  These two sections are very complex from a security point of view.  Shared secrets with no provenance, nonces based on an operator typing in time from the wall-clock, CBC mode (largely deprecated), partial encryption, etc.  It would be much easier, and much more secure to use DTLS (RFC 9147) using the mystery shared secrets for authentication (if keys/certs cannot be obtained).  

The choices of hash, algorithm, mode, random number generation, and KDF don't match with the discussions of constrained devices.

Comment (2025-05-27 for -17) Sent

# Internet AD comments for draft-ietf-ippm-capacity-protocol-17
CC @ekline

* comment syntax:
  - https://github.com/mnot/ietf-comments/blob/main/format.md

* "Handling Ballot Positions":
  - https://ietf.org/about/groups/iesg/statements/handling-ballot-positions/

## Comments

### S4

* I think this document should say something about how the DF bit should be
  set (or unset) when IPv4 is in use.

  At first glance I would recommend saying that the DF bit SHOULD be set,
  but I'll leave that to the working group/community.

### S4.2.2

* The bar for this mode seems low enough that if it's kept in this document
  it ought to be possible to remove Mode 0 (S4.2.1) altogether.  This would
  allow the S4.5 Optional Checksum to be dropped as well, I think.

  I could see that SHA256 calculations at line rate for "low oomph" devices
  means that SHA256 for data mode (S4.2.3) should remain optional, but I
  don't see a reason to keep Mode 0 when every device should be able to do
  Mode 1 for just the control packets.

## Nits

### S3

* "are used exchangeable" ->
  "are used interchangeably" or "are exchangeable"

* "keeps the keep the pinhole (or mapping, resepcitvely)" ->
  "helps to keep the pinhole (or mapping, respectively)"

Comment (2025-06-10 for -18) Sent

# Gunter Van de Velde, RTG AD, comments for draft-ietf-ippm-capacity-protocol-18

# The line numbers used are rendered from IETF idnits tool: https://author-tools.ietf.org/api/idnits?url=https://www.ietf.org/archive/id/draft-ietf-ippm-capacity-protocol-18.txt

# This documented is not an easy read. It assumes very in-depth knowledge of prior performance measurement techniques and procedures. It makes it a complex text to review. Hence, my review has been done from the Routing perspective and i observed only few non-blocking items.

# The document uses UDPST in some parts of the document and the IANA section, but at other parts it talks about UDPSTP. Maybe a single naming could be considered and align descriptions?

# Detailed Review
# ===============

13 The performance community has seen development of Informative Bulk
114 Transport Capacity definitions in [RFC3148] for Framework for Bulk
115 Transport Capacity (BTC) [RFC5136] for Network Capacity and Maximum
116 IP-layer Capacity, and the Experimental metric definitions and
117 methods in [RFC8337], Model-Based Metrics for BTC.

GV> This is a very long complex to read sentence. can this be made easier to digest for a reader?

134 as supported by TWAMP and STAMP, when work on UDPST started.

GV> in other sections UDPSTP is used and not UDPST. Was this intentional?

140 the UDPST Protocol.

GV> maybe use UDPSTP to be consistent within the document

142 Apart from measurement functionality, the UDPSTP security features
143 have been developed following guidance given by the IETF Security
144 Area and the resulting specification is compliant with state of the
145 art security implementations. This is a secondary improvement

GV> Maybe give a one line insight in the implied security functionality embedded into the Protocol?

149 1.1. Terminology

GV> can a server never ever initiate a speediest?

167 2. Scope, Goals, and Applicability
168
169 The scope of this document is to define a protocol to measure the
170 Maximum IP-Layer Capacity metric according to the Method of

GV> What is exactly a 'Capacity' metric? where are the specifics defined

188 UDPSTP is a client based protocol. It may be applied by consumers to

GV> Should this not be a client-server based protocol where the client initiates the measument cycle/procedure?

189 measure their own access bandwidth. Consumers may prefer an cross-
190 domain measurement architecture for this purpose. UDPSTP may be

GV> What is intended by the statement saying "a cross-domain measurement architecture"?
The terminology is used in this paragraph few times and at least to me the text reads unnaturally not making it overly clear to me what was intended.

247 1. Test Setup Request and Response: If a server instance is
248 identified with a host name that resolves to both IPv4/IPv6
249 addresses, it is recommended to use the first address returned in
250 the name resolution response - regardless, whether it's IPv4 or
251 IPv6. Thus the decision on the preferred IP address family is
252 left to the DNS operator. Support for separate IPv4 and IPv6
253 measurements or an IPv4 and IPv6 multi connection setup are left
254 for future improvement. The client then requests to begin a test
255 by communicating its protocol version, intended security mode,
256 and datagram size support. The server either confirms matching a
257 configuration or rejects the connection request. If the request
258 is accepted, the server provides a unique ephemeral port number
259 for each test connection, allowing further communication. In a
260 multi-connection setup, distinct UDP port numbers may be assigned
261 with each Setup Response from a server instance. Distinct UDP
262 port numbers are assigned, if all Setup Response messages
263 originate from the same server in that case.

GV> On line 249 is written that the first address is preferred, but then on line 255 suggest communicating protocol version. That seems to conflict at first glance, not?

749 Additional details regarding the Setup Request and Response fields
750 are as follows:
751
752 pduId: A two-octet field. IANA is asked to assign the value hex
753 0xACE1 (Section 11.2.1).
754
755 protocolVer: A two-octet field, identifying the actual protocol
756 version. IANA is asked to assign only one initial value, 20
757 (Section 11.2.2).
758
759 mcIndex: The index of a connection relative to all connections that
760 make up a single test (starting at 0, incremented by 1 per
761 connection). It is used to differentiate separate connections within
762 a multi-connection test. An implementation may restrict the number
763 of connections supported for a single test to a value smaller or
764 equal to 255.

GV> The table description is inconsistently describing the length of each field. The first few fields have a length (two-octets) while the other fields have no indication of length, making that table diagram normative for the procedure, Can each field have an explicit length description in this table? (similar with the picture, some fields have a length associated, while other fields have not, and similar with the other diagrams and tables later in the document)

766 mcCount: The total count of attempted connections.

GV> can the counter wrap around or overflow?

773 cmdRequest: Is set to CHSR_CREQ_SETUPREQ to indicate a Setup request
774 message. Note that CHSR_CREQ_NONE remains unused.

GV> are the allowed values somewhere specified?

Many thanks for this document,

Gunter Van de Velde,
Routing AD

Comment (2025-06-25 for -21) Not sent

I support Paul Wouter's DISCUSS.

Comment (2025-07-02 for -22) Sent

(revised for -22)
Thank you to Lars Eggert for the GENART review.

Thank you for addressing the first point of my DISCUSS feedback in -21.

Thank you for adding the [C-Prog] normative reference and adding it to Section 5.2.  Please also do the same for <CODE> blocks in Sections 6.1, 7.1, and 7.2, or make a statement the all code blocks in this document are [C-Prog].

** Section 1.  Editorial.
   Apart from measurement functionality, the UDPSTP security features
   have been developed following guidance given by the IETF Security
   Area and the resulting specification is compliant with state-of-the-
   art security implementations.

Consider if this text is needed as it might not age well.

** Section 2.
   The goal is to harmonize the specified IP-Layer Capacity metric and
   method across the industry, and this protocol supports the
   specifications of IETF

What does it mean to “support the specifications of the IETF”?  Is it that it implements the metric of RFC9097 (as already said in Section 1)?

Comment (2025-07-02 for -22) Sent

In short, I have cleared my previous DISCUSS ballot.

# Éric Vyncke, INT AD, comments for draft-ietf-ippm-capacity-protocol-22
CC @evyncke

Thank you for the work put into this document. Notably due to long and complex sentences, I found the document difficult to read.

Please find below my previous DISCUSS/COMMENT points, they are there only for archiving purposes.

Special thanks to Tommy Pauly for the shepherd's detailed write-up including the detailed WG consensus *but* the justification of the intended status is rather light.

I hope that this review helps to improve the document,

Regards,

-éric

## Archived DISCUSS (no more blocking)

As noted in https://www.ietf.org/blog/handling-iesg-ballot-positions/, a DISCUSS ballot is just a request to have a discussion on the following topics:

### Section 3

Querying for AAAA and A ressource records is done in two DNS queries, so it is not up to the DNS operator to decide the order but to the client to request first AAAA then A (or vice-versa). I.e., the following text is not correct `it is recommended to use the first address returned in the name resolution response - regardless, whether it's IPv4 or IPv6. Thus, *the decision on the preferred IP address family is left to the DNS operator*.`

### Section 4.2.1

What is the expected receiver behaviour when some fields are set to 0 and not others ? It is unclear whether the 2nd paragraph applies in this case.

## Archived COMMENTS (non-blocking)

### Title

s/Test Protocol for One-way IP Capacity Measurement/*UDP Speed* Test Protocol for One-way IP Capacity Measurement/ ?

### Abstract

To be honest, the abstract is more about *why* this I-D exists and not what it is about... Consider rewriting it and explaining what it is about.

### Section 1

What is `The performance community` ? Is it within IETF ? within the industry ?

`compliant with *state-of-the-art* security implementations` smells like a marketing statement ;-)

### Section 1.1

Is it required to have twice "measurement" in `a client initiated measurement of Network Capacity measurement` ?

Should there be a mention that client == initiator ?

### Section 2

`SDO` is never used in the text, i.e., no need to define this acronym.

s/protocol described here/protocol *specified* here/

Where is the context for `consumers` defined ?

`Large-Scale Measurement of Broadband Performance environments (LMAP)`, unclear how the LMAP acronym is formed here ? Is it broadband or access ?

### Section 4

s/Layer 3/layer-3/ and other places

Thanks for following Erik Kline's suggestion about the IPv4 DF bit.

### Section 4.2

The same use case `This mode may be preferred to perform infrequent reliable measurements, typically initiated by consumers or for operator OAM purposes (see Section 2).` is stated for options 2 & 3, i.e., it does not really help the user of this protocol when deciding which mode to use.

The LMAP acronym is already defined.

The numbered list starts with 1 while the first mode is actually 0... This is confusing.

### Section 4.2.4

s/Federal Information Processing Standards/US Federal Information Processing Standards/

### Section 5.1

What is "AB" in `big-endian AB` ?

Some header fields have a length defined in the text, but others do not. Please be consistent and provide all field lengths (rather than requesting the implementer to have a look at the figure 2).

Out of curiosity, where does 1250 come from ? IPv6 minimum supported MTU is 1280.

Should the actual value for AUTHMODE_* be present ?

### Section 7.2

I have probably missed something in the protocol, but is the use of RTT (= round-trip time) valid in a unidirectional flow ?

### Section 9

Most of the text uses client/server and this does not match `roles of Src (test packet sender) and Dst (receiver),` where different terms are used. Should this section be consistent ?

### Section 11

The usual wording is "IANA is requested to allocate" rather than `will allocate` but this is a nit and it seems that IANA does not mind.

### Section 11.3.1

`expert review` is required for some values, consider adding a forward reference to 11.4 for the expert guidance.

### Section 11.3.3

Constant names (e.g., CHSR_TRADITIONAL_MTU) were used in the previous text, suggest adding/repeating them in the registry.

### Use of SVG graphics

To make a much nicer HTML rendering, suggest using the aasvg too to generate SVG graphics. It is worth a try especially if the I-D uses the Kramdown file format ;-)

UDP Speed Test Protocol for One-way IP Capacity Measurement draft-ietf-ippm-capacity-protocol-23

UDP Speed Test Protocol for One-way IP Capacity Measurement
draft-ietf-ippm-capacity-protocol-23