Datagram PLPMTUD for UDP Options
draft-ietf-tsvwg-udp-options-dplpmtud-15

Thank you to Robert Starks for his secdir review of this draft (and the udp-options draft).

First of all thanks to Brian Haberman for his INTDIR and to Robert Sparks for his SECDIR review. Both the reviews have provided comments that I think will help improve the draft. I look forward to the resolution of those comments and what needs to be incorported into the document.

The document is otherwise well-written and easy to understand. I have only these minor nits on the draft.

-------------------------------------------------------------------------------
NIT
-------------------------------------------------------------------------------

All comments below are about very minor potential issues that you may choose to
address in some way - or ignore - as you see fit. Some were flagged by
automated tools (via https://github.com/larseggert/ietf-reviewtool), so there
will likely be some false positives. There is no need to let me know what you
did with these suggestions.

Section 3, paragraph 11
> ,Min_PMTU | | Token Values & Probes, etc | +---------------------------+----+
>                                      ^^^
In American English, abbreviations like "etc." require a period.

Section 3, paragraph 12
> end | Events: ICMP, Interface MTU, etc +--------------------------------+ | 
>                                    ^^^
In American English, abbreviations like "etc." require a period.

Section 4.1, paragraph 2
> be packet to elicit a positive acknowledgment that the path has delivered a 
>                                ^^^^^^^^^^^^^^
Do not mix variants of the same word ("acknowledgment" and "acknowledgement")
within a single text.

Section 5.2, paragraph 1
> de the option, filtering on the path, etc). * (DPLPMTUD receiver uses applica
>                                       ^^^
In American English, abbreviations like "etc." require a period.

Section 5.2, paragraph 2
> is periodic feedback (e.g., one acknowledgment packet per RTT). It requires t
>                                 ^^^^^^^^^^^^^^
Do not mix variants of the same word ("acknowledgment" and "acknowledgement")
within a single text.

Thanks for the document. To the universal deployment of properly sized packets!

Thank you to Meral Shirazipour for the GENART review.

# Éric Vyncke, INT AD, comments for draft-ietf-tsvwg-udp-options-dplpmtud-14
CC @evyncke

Thank you for the work put into this document.

Please find below some non-blocking COMMENT points (but replies would be appreciated even if only for my own education), and some nits.

Special thanks to Marten Seemann for the shepherd's write-up including the WG consensus *and* the justification of the intended status.

Other thanks to Brian Haberman, the Internet directorate reviewer (at my request), please consider this detailed int-dir review:
https://datatracker.ietf.org/doc/review-ietf-tsvwg-udp-options-dplpmtud-13-intdir-telechat-haberman-2025-02-11/ (and I have read Gorry's replies)

Please note that Henk Birkholz is the DNS directorate reviewer and you may want to consider this dns-dir review as well when it will be available (no need to wait for it though):
https://datatracker.ietf.org/doc/draft-ietf-tsvwg-udp-options-dplpmtud/reviewrequest/21462/

I hope that this review helps to improve the document,

Regards,

-éric

## COMMENTS (non-blocking)

### Sequencing of UDP options drafts

It would have been nicer for the IESG evaluation to have draft-ietf-tsvwg-udp-options-39 in the same telechat as for this document ;-)

### Missing topics ?

This is perhaps mentioned in RFC 8899, but is this specification applicable to multicast traffic ?

Some words may be written about ECMP as this method works fine with ECMP.

### Section 3

```
Use of DPLPMTUD MUST be explicitly enabled by the application, for instance once an application has established connectivity and is ready to exchange data with the remote Upper Layer protocol.
```

Seems to indicate that this mechanism works *only* for bidirectional flows, i.e., not for a sender-only role (e.g., Syslog). Should this document be clear about this restriction (in the abstract and in the introduction)?

### Section 3.1

How can UDP talkers discover the RTT in `to send 1 per RTT` ?

### Section 3.3

I find weird the use of 'normally' in a specification `DPLPMTUD does not normally send more than one probe packet per timeout interval`. Should it rather be "per specification" ?

### Section 4.5

Probably due to my lack of knowledge in UDP, but I find probing with application data problematic, see below.

`include the corresponding RES Option in an Upper Layer protocol message that it returns to the requester` the "an ULP message" is rather vague... what if the reply comes minutes after the request ? What is dozens of replies are generated (should the RES be sent in the first, the last packets)

How can a receiver distinguish between:
- a sender not sending probes with application data (i.e., having no payload in the probe)
- a sender sending probes with application data but for once sending a UDP w/o application data (e.g., keeping a NAT happy)

### Section 5.2

The Packet-too-big section of RFC 8899 only checks for ports but in this case, should it also validate that the 4-octet token is present ? The text says that the token MUST be present but is rather light that in absence of the token in the PTB, the PTB is to be ignored. (I understand that I am splitting hair here).

## NITS (non-blocking / cosmetic)

### Byte vs. octet

I usually prefer the use of "octet" vs. "byte", but this is a matter of taste.

### 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 ;-)

(correcting ballot from "no record" to "no objection", sorry for the noise)

Thanks for this document. Among other things, I appreciated the care you took to make it clear when you were quoting pre-existing normative requirements rather than imposing new ones.

I have one trivial and superficial gripe: I was bugged by the fact that in your diagram, the arcs on the left/Rx side are arrows pointing up:

^
|
+

But the ones on the right/Tx side are nondirected dangling lines:

+
|
|

Instead of arrows pointing down, which would be:

+
|
v

¯\_(ツ)_/¯