Unicast UDP Usage Guidelines for Application Designers
draft-ietf-tsvwg-udp-guidelines-11

Approval announcement
Draft of message to be sent after approval:

Announcement

From: The IESG <iesg-secretary@ietf.org>
To: IETF-Announce <ietf-announce@ietf.org>
Cc: Internet Architecture Board <iab@iab.org>,
    RFC Editor <rfc-editor@rfc-editor.org>
Subject: Protocol Action: 'Unicast UDP Usage Guidelines for 
         Application Designers' to BCP 

The IESG has approved the following document:

- 'Unicast UDP Usage Guidelines for Application Designers '
   <draft-ietf-tsvwg-udp-guidelines-12.txt> as a BCP

This document is the product of the Transport Area Working Group. 

The IESG contact persons are Magnus Westerlund and Lars Eggert.

A URL of this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-tsvwg-udp-guidelines-12.txt

Ballot Text

Technical Summary
         
  The User Datagram Protocol (UDP) provides a minimal, message-passing
  transport that has no inherent congestion control mechanisms.
  Because congestion control is critical to the stable operation of the
  Internet, applications and upper-layer protocols that choose to use
  UDP as an Internet transport must employ mechanisms to prevent
  congestion collapse and establish some degree of fairness with
  concurrent traffic.  This document provides guidelines on the use of
  UDP for the designers of unicast applications and upper-layer
  protocols.  Congestion control guidelines are a primary focus, but
  the document also provides guidance on other topics, including
  message sizes, reliability, checksums and middlebox traversal.

Working Group Summary
  There is strong consensus in publishing this document.

Document Quality
  This document has been well reviewed both within the TSVWG and by
  people from other areas due to an extensive announcement and review
  requests at important points in the documents life time.
           
Personnel
  WG Shepherd and responsible AD is Magnus Westerlund.


RFC Editor Note

  Please update the reference to RFC 3682 with RFC 5082.

RFC Editor Note