Thank you for this review - such
reviews are really appreciated, please see the proposed responses
below.
Best wishes,
Gorry
On 09/02/2025 21:37, Robert Sparks via
Datatracker wrote:
GF: I am unsure what to change here, this is a specification for how to implement DPLPMTUD, the reader has to understand that, but that said, this reading is now hopefully eased by the updates proposed below.Reviewer: Robert Sparks Review result: Has Nits 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.
GF: They were requirements carried through by the way DPLPMTUD was defined. We propose these are rewritten to quote exactly what was required by DPLPMTUD.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.
GF: Understood - the examples were contributed by others, and I think were useful additions. Sorry for any confusion. In the PR being prepared we have removed the word design, and tied to clarify the intent. One use was changed to MAY.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.
GF: Indeed, Changed to “requires”, (lower case) - since this is a statement of fact not a protocol requirement, thanks.The use of an (almost) 2119 keyword at "This design REQUIRES an API primitive" is not a proper use of 2119.
We changed this to explicitly refer to the text in RFC8899 (where more is said):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"?
UDP datagrams used as DPLPMTUD probe packets, as described in this
document, MUST not be fragmented at the UDP or IP layer.
Section 3 of <xref target="RFC8899"></xref>
therefore requires: "In IPv4, a probe packet MUST be sent with the
Don't Fragment (DF) bit set in the IP header and without network layer
endpoint fragmentation."</t>
GF: Sorry, this should not be. This sentence isn’t indeed appropriate in an example: “If a UDP Options endpoint creates and sends a datagram with a RES option solely as response to a received REQ Option, the responder MUST limit the rate of these responses (e.g., limiting each pair of ports to send 1 per RTT or 1 per second)”. We will resolve this by moving this sentence to a normative section.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).
GF: The new PR also proposes to change one SHOULD NOT to MUST NOT, because in another place it was stated as a requirement for a erceiver to not respond until configured to do so. This has been explained why this to protect from other forms of probing attempts.
Thanks again for the review.
-- last-call mailing list -- last-call@xxxxxxxx To unsubscribe send an email to last-call-leave@xxxxxxxx
