Skip to main content

Transport Options for UDP
draft-ietf-tsvwg-udp-options-45

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: Gorry Fairhurst <gorry@erg.abdn.ac.uk>, The IESG <iesg@ietf.org>, draft-ietf-tsvwg-udp-options@ietf.org, gorry@erg.abdn.ac.uk, rfc-editor@rfc-editor.org, tsvwg-chairs@ietf.org, tsvwg@ietf.org, zahed.sarker.ietf@gmail.com
Subject: Protocol Action: 'Transport Options for UDP' to Proposed Standard (draft-ietf-tsvwg-udp-options-45.txt)

The IESG has approved the following document:
- 'Transport Options for UDP'
  (draft-ietf-tsvwg-udp-options-45.txt) as Proposed Standard

This document is the product of the Transport and Services Working Group.

The IESG contact persons are Zaheduzzaman Sarker and Francesca Palombini.

A URL of this Internet-Draft is:
https://datatracker.ietf.org/doc/draft-ietf-tsvwg-udp-options/


Ballot Text

Technical Summary

   Transport protocols are extended through the use of transport header
   options. This document updates RFC 768 (UDP) by indicating the
   location, syntax, and semantics for UDP transport layer options
   within the surplus area after the end of the UDP user data but
   before the end of the IP length.

Working Group Summary

   The TSVWG working group has worked on this document since adopting this in
2017. It has been discussed extensively and has been stable in recent
revisions. The document retains the support of the TSVWG working group, and there is
consensus (rough) to publish this version. 

Document Quality

   Results were presented to the WG for tests using the option format across a
range of Internet paths to explore traversal (whether an option is passed or
modified by devices on path); and the method has been updated to reflect this
experience. Significant inputs were provided on approaches to implementation, a
pilot integration into a fork of BSD provided input; as did consideration of
the requirements for offload;  and exploration of the complexity of the various
proposed fragmentation methods. It is therefore expected that the protocol is
implementable. The shepherd is not aware of an implementation or the proposed
transport API that supports the final specification.

Personnel

   The Document Shepherd for this document is Gorry Fairhurst. The
   Responsible Area Director is Zaheduzzaman Sarker.


RFC Editor Note