Original text:
6.2. <del> For most of the history of the Internet, we have trusted UDP-based applications to limit their impact on other users.  One of the strategies used was to use UDP for simple query-response application protocols, such as DNS, which is often used to send a single-packet request to look up the IP address for a domain name, and return a single-packet response containing the IP address.  Although it is possible to saturate a path between a DNS client and DNS server with DNS requests, in practice, that was rare enough that DNS included few mechanisms to resolve contention between DNS users and other users (whether they are also using DNS, or using other application protocols that share the same pathways). In recent times, the usage of UDP-based applications that were not simple query-response protocols has grown substantially, and since UDP does not provide any feedback mechanism to senders to help limit impacts on other users, application-level protocols such as RTP RFC3550 have been responsible for the decisions that TCP-based </del>  applications have delegated to TCP - what to send, how much to send, and when to send it.  Because UDP itself has no transport-layer feedback mechanisms, UDP-based applications that send and receive substantial amounts of information are expected to provide their own <del> feedback mechanisms and respond to the feedback the application </del>  receives.  This expectation is most recently codified in Best Current Practice RFC8085. Thanks to Alexandre Gouaillard, Aaron Falk, Chris Lemmons, Dave Oran, Eric Vyncke, Glenn Deen, Kyle Rose, Leslie Daigle, Linda Dunbar, <del> Lucas Pardue, Mark Nottingham, Matt Stock, Michael Scharf, Mike English, Renan Krishna, Roni Even, Sanjay Mishra, and Will Law for very helpful suggestions, reviews and comments. </del>  12.  References

Reviewer comments:
Also adding Tommy's name in Acks section.
LGTM, too and ready to merge.
From NAME In Section 6.1 (on UDP), DNS queries are described as follows: "DNS, which is often used to send a single-packet request to look up the IP address for a DNS name, and return a single-packet response containing the IP address." I'm not sure how valuable this example is for explaining UDP, but if it is kept, please say that multiple packets are sent to get multiple addresses. With IPv6 and IPv4, clients query for both A and AAAA records, and handle multiple addresses, especially for IPv6.
FWIW, I understand why you're saying this. My point (and I wrote this) was to explain why it we've used DNS over UDP for decades without worrying about congestive collapse, but we've used other protocols over TCP because we were worried. I can certainly explain that more correctly, as you propose. And thanks for pushing back.
Hi, NAME especially after NAME suggesting in his TSVART review that I don't need to talk about history, removing this text completely was a perfectly reasonable resolution for your issue!
Sounds good
LGTM

Revised text:
6.2.  <ins> Because UDP does not provide any feedback mechanism to senders to help limit impacts on other users, UDP-based application-level protocols have been responsible for the decisions that TCP-based </ins> applications have delegated to TCP - what to send, how much to send, and when to send it.  Because UDP itself has no transport-layer feedback mechanisms, UDP-based applications that send and receive substantial amounts of information are expected to provide their own  <ins> feedback mechanisms, and to respond to the feedback the application </ins> receives.  This expectation is most recently codified in Best Current Practice RFC8085. Thanks to Alexandre Gouaillard, Aaron Falk, Chris Lemmons, Dave Oran, Eric Vyncke, Glenn Deen, Kyle Rose, Leslie Daigle, Linda Dunbar,  <ins> Lucas Pardue, Mark Nottingham, Matt Stock, Mike English, Renan Krishna, Roni Even, Sanjay Mishra, Tommy Pauly, and Will Law for very helpful suggestions, reviews and comments. </ins> 12.  References