Last Call Review of draft-ietf-tsvwg-rfc5405bis-11
review-ietf-tsvwg-rfc5405bis-11-opsdir-lc-chown-2016-06-13-00

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