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. 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). -- last-call mailing list -- last-call@xxxxxxxx To unsubscribe send an email to last-call-leave@xxxxxxxx
