Reviewer: Brian Haberman Review result: Ready with Issues 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. -- last-call mailing list -- last-call@xxxxxxxx To unsubscribe send an email to last-call-leave@xxxxxxxx
