Draft: draft-ietf-mops-streaming-opcons

Commentary: Also adding  's name in Acks section . 
 LGTM , too and ready to merge . 
 From 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 , especially after suggesting in his TSVART review that I do n't need to talk about history , removing this text completely was a perfectly reasonable resolution for your issue ! 
 Sounds good 
 LGTM
Paragraph (version A):
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).
Paragraph (version A):
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
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
feedback mechanisms and respond to the feedback the application
receives.  This expectation is most recently codified in Best Current
Practice RFC8085.
Paragraph (version B):
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
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
feedback mechanisms, and to respond to the feedback the application
receives.  This expectation is most recently codified in Best Current
Practice RFC8085.
Paragraph (version A):
Thanks to Alexandre Gouaillard, Aaron Falk, Chris Lemmons, Dave Oran,
Eric Vyncke, Glenn Deen, Kyle Rose, Leslie Daigle, Linda Dunbar,
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.
Paragraph (version B):
Thanks to Alexandre Gouaillard, Aaron Falk, Chris Lemmons, Dave Oran,
Eric Vyncke, Glenn Deen, Kyle Rose, Leslie Daigle, Linda Dunbar,
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.