Telechat Review of draft-ietf-tsvwg-udp-options-dplpmtud-13
review-ietf-tsvwg-udp-options-dplpmtud-13-intdir-telechat-haberman-2025-02-11-00

I am an assigned INT directorate reviewer for
draft-ietf-tsvwg-udp-options-dplpmtud. These comments were written primarily
for the benefit of the Internet Area Directors. Document editors and
shepherd(s) should treat these comments just like they would treat comments
from any other IETF contributors and resolve them along with any other Last
Call comments that have been received. For more details on the INT Directorate,
see https://datatracker.ietf.org/group/intdir/about/

For the most part, this is a reasonably easy to read document. However, the
formulation of the prose that makes it easy to read also creates some
ambiguities that appear to make the protocol somewhat difficult to implement
correctly. The following are areas where I think the document could be
clarified.

1. The document states that DPLPMTUD is disabled by default. However, section 3
says receiver SHOULD NOT respond to a UDP REQ Option until enabled. If the
function is disabled, why isn't this guidance MUST NOT? Is the guidance even
needed if functionality is controlled via a configuration/API option?

2. In several places, "ought" is used rather than a BCP 14 keyword. Is "ought"
equivalent to a SHOULD or MUST? Regardless, I recommend avoiding colloquial
terms and using the appropriate keyword. There are also instances of "can" and
"always" that also need to be assessed for replacement with BCP 14 keywords

3. It would be useful to add a label to the figure and use the figure number as
reference in the surrounding text.

4. Typo - change "less than of equal to" to "less than or equal to".

5. Section 3 talks briefly about multiple instances of DPLPMTUD running
concurrently. Given the "disabled by default" guidance for DPLPMTUD at the UDP
transport layer, I would think the text can be tightened up by saying
applications should not enable the transport layer DPLPMTUD if it is running
DPLPMTUD at the application layer.

6. Section 3.1 has an inappropriate use of a BCP 14 keyword. "Each probe packet
MUST be uniquely identifiable..." I recommend rewording that guidance so that
the MUST describes how each probe packet is made uniquely identifiable.

7. The discussion in section 3.2 about avoiding fragmentation would be stronger
by referencing the explicit guidance in section 4.5 of RFC 8899.

8. The text in section 4.4 is a good example of wording that needs more
rigorous structure. It is unclear to me why that section is not worded
something like:

A simple implementation of the method only uses probe packets in a UDP datagram
that includes no application data. The size of each probe packet MUST be padded
to the required probe size including the REQ Option. This implements "Probing
using padding data" (Section 4.1 of [RFC8899]) and avoids having to retransmit
application data when a probe fails. This is achieved by setting a minimum
datagram length, such that the options list ends in EOL (Section 11.1 of
[I-D.ietf-tsvwg-udp-options]) and any additional space MUST be zero-filled (see
Section 15 of [I-D.ietf-tsvwg-udp-options]). These probe packets do not form a
part of the end-to-end application data and a receiver MUST NOT deliver them to
the Upper Layer protocol.