Hi,

I have reviewed this document as part of the Operational directorate's ongoing effort to review all IETF documents being processed by the IESG.  These comments were written with the intent of improving the operational aspects of the IETF drafts. Comments that are not addressed in last call may be included in AD reviews during the IESG review.  Document editors and WG chairs should treat these comments just like any other last call comments. 

The document offers guidance to protocol designers considering using UDP.  It updates RFC 5405, which was published in 2008, covering many of the same topics, e.g. congestion control, while adding new material, including coverage of topics such as multicast, PLPMTUD, and the IPv6 Flow Label. 

The document is long, at around 40 pages, plus references, but is well-written, easy to read and contains a wealth of good information and advice. Overall, I believe the document is Ready for publication, with nits.

General comments:

It might be nice to include some level of discussion of new examples of UDP-based protocols devised since RFC 5405 (i.e. since 2008), such as QUIC, or applications such as mosh that enable ssh over UDP rather than the traditional TCP.  Do these follow the guidance here, for example?  

CGNs have appeared since RFC 5405; are there specific issues they pose for UDP-based applications which require state to remain?

Comments:

p.15 first para 3.1.11, maybe add an example, like Teredo.

p.16 final para of point 1 - is most UDP-based communication congestion controlled?

p.18 maybe add a reference to RFC 4890 in para 3 of 3.2 as an example

p.21 in 3.4, para 4 maybe state explicitly the reason here, that IPv6 has no checksum

p.28 para 3, perhaps say “Senders to any cast destinations” rather than “Anycast senders”

p.28 before 4.1, perhaps add a reference to AMT here as an example (RFC 7450)

p.30 when you say “competes fairly within an order of magnitude” do you mean on a 10G link that UDP can take over 9G?  

p.30 in the next paragraph, this suggestion would seem non-trivial to implement well/accurately, and then the “order of magnitude” is thrown in too…

p.30 section 4.2 - perhaps reword as it implies explicit PMTUD to each known destination (receiver)?

p.32 worth adding an example of why this is so valuable, e.g. DNS cache poisoning?

p.34 perhaps note that the IPv6 Flow Label is mutable on path (section 6 of RFC 6437)

p.36 in security section, perhaps add when discussing potential amplification attacks that the application should when appropriate provide a way to limit queries in a sensible way, and the example of open recursive DNS resolvers might be a good one to use

p.36 para 4, some ISPs are deploying IPv6 CPEs as per RFC 6092, so support IKE and IPSec

Nits:

p.3 in the first para of the Introduction should that be “operate over IP” rather than UDP?

p.14 “that chose” -> “that choose” (this sentence is also something of a repeat of the paragraph after next)

p.26 “tends to” -> “tend to”

p.26 add a . after Controlled Environment

p.27 move . after ) in second para

p.29 “were all” -> “where all”

p.32 in 5.1, “rules and procedures” - add the and.

p.34 (perhaps) flow label should be written Flow Label


Best wishes,
Tim