Last Call Review of draft-ietf-tsvwg-udp-options-dplpmtud-13
review-ietf-tsvwg-udp-options-dplpmtud-13-secdir-lc-sparks-2025-02-09-00

I have reviewed this document as part of the security directorate's ongoing
effort to review all IETF documents being processed by the IESG. These comments
were written primarily for the benefit of the security area directors. Document
editors and WG chairs should treat these comments just like any other review
comments.

This document is ready (but with nits bordering on issues) for publication as a
Proposed Standard RFC.

This document was not as clear as the -options document. Please see my review
of that document for a question about whether these two documents are
consistent.

The Security Considerations of this and the -options document are clear, and I
believe sufficient.

I chose the "with nits" response rather than the "with issues" response, but
with some discomfort as I found pulling the actual protocol out of this text
harder than I think it should be. I worry that this document is only accessible
to an inside-crowd - that only people who have already implemented (not just
read) RFC8899 in other contexts would do the right thing, leaving things that
would be "obvious" to them unstated even though they are important in this new
context.

In the -options document, phrases like "need to" were clearly followed with
2119 interpretations of meeting that need. It's not as clear here if normative
requirements have not been explicitly stated when this (and "ought to") have
been used.

The prose in this document places agency in designs which is really unclear. A
design doesn't _do_ things. Please look at places where you say things like "a
design ought to to avoid performing such discovery" and "This design is also
permitted to use" and try to replace them with text that constrains protocol
actors instead.

The use of an (almost) 2119 keyword at "This design REQUIRES an API primitive"
is not a proper use of 2119.

This sentence is written as a requirement on the UDP and IP layers: "UDP
datagrams used as DPLPMTUD probe packets, as described in this document, MUST
NOT be fragmented at the UDP or IP layer."  As written the code _in those
layers_ would need to change. Is that the intent? If not, can the sentence be
rewritten along the lines of "the following things must be done to ensure that
DPLPMTUD probe packets are not fragmented at the UDP or IP layer"?

There are normative requirements in a section that is ostensibly supposed to be
Examples (Section 6).

Finally, please skim this extraction of the 2119 usage from the document (see
https://gist.githubusercontent.com/rjsparks/5e8557c83e70013f51bbb3b74ab4dc09/raw/391f1f295a63ae686bf51f37fadcb9f9843a5120/gistfile1.txt)
to see if the entire protocol is apparent from them. It's not a _requirement_
to fully represent the protocol with 2119 requirements, but if you're using
them only for part of the specification, misinterpretation and arguments over
future implementation are more likely).