Skip to main content

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

Revision differences

Document history

Date Rev. By Action
2025-02-07
38 Carlos Pignataro Assignment of request for Telechat review by INTDIR to Carlos Pignataro was rejected
2025-02-07
38 David Dong
IESG/Authors/WG Chairs:

IANA has completed its review of draft-ietf-tsvwg-udp-options-38. If any part of this review is inaccurate, please let us know.

IANA has a question …
IESG/Authors/WG Chairs:

IANA has completed its review of draft-ietf-tsvwg-udp-options-38. If any part of this review is inaccurate, please let us know.

IANA has a question about one of the actions requested in the IANA Considerations section of this document.

IANA understands that, upon approval of this document, there are four actions which we must complete.

First, a new registry group will be created on the IANA Matrix located at:

https://www.iana.org/protocols

The new registry group will be called UDP Options and have a reference of [ RFC-to-be ].

Second, a new registry is to be created called the UDP Option Kind numbers registry. The new registry is to be located on the new registry group created in action one above. The new registry is to be managed via IESG Approval of Standards Action as defined by [RFC8126].

There are initial registrations in the new registry as follows:

Kind Length Meaning
------------------------------------------
0 - End of Options List (EOL)
1 - No operation (NOP)
2 6 Additional payload checksum (APC)
3 10/12 Fragmentation (FRAG)
4 4 Maximum datagram size (MDS)
5 5 Maximum reassembled datagram size (MRDS)
6 6 Request (REQ)
7 6 Response (RES)
8 10 Timestamps (TIME)
9 (varies) RESERVED for Authentication (AUTH)
10-126 (varies) UNASSIGNED
127 (varies) RFC 3692-style experiments (EXP)
128-191 RESERVED
192 (varies) RESERVED for Compression (UCMP)
193 (varies) RESERVED for Encryption (UENC)
194-253 UNASSIGNED-UNSAFE
254 (varies) RFC 3692-style experiments (UEXP)
255 RESERVED-UNSAFE

All of the initial registrations above will have a reference of [ RFC-to-be ].

Third, the existing TCP Experimental Option Experiment Identifiers (TCP ExIDs) in the Transmission Control Protocol (TCP) Parameters registry group located at:

https://www.iana.org/assignments/tcp-parameters/

is to be renamed to Unified TCP/UDP Option Experiment Identifiers and [ RFC-to-be ] will be added to the existing reference.

IANA Question --> Is this registry to remain in place, or is the registry to be moved to the new registry group created by the first action?

A note will be added to this registry as follows:

16-bit ExIDs can be used with either TCP or UDP; 32-bit ExIDs can be used with TCP or their first 16 bits can be used with UDP.

IANA Question --> Section 26 of the current draft requests IANA to establish "a link from the UDP protocol parameters area to this unified TCP/UDP ExID registry." Specifically what UDP protocol parameters area is being referenced here and where should we place this link?

Fourth, in the newly renamed Unified TCP/UDP Option Experiment Identifiers registry, the existing registry will have a field added which indicates whether the identifier is for UDP or TCP. The existing registrations which were for TCP will be marked as TCP in this field and future registrations will be for UDP and/or TCP.

The registration policy for the newly renamed registry will remain First Come, First Served as defined by [ RFC-to-be ].

We understand that these are the only actions required to be completed upon approval of this document.

NOTE: The actions requested in this document will not be completed until the document has been approved for publication as an RFC. This message is meant only to confirm the list of actions that will be performed.

For definitions of IANA review states, please see:

https://datatracker.ietf.org/help/state/draft/iana-review

Thank you,

David Dong
IANA Services Sr. Specialist
2025-02-07
38 (System) IANA Review state changed to IANA - Not OK from IANA - Review Needed
2025-02-07
38 Carlos Pignataro Request for Last Call review by OPSDIR is assigned to Victor Kuarsingh
2025-02-05
38 Carlos Jesús Bernardos Request for Telechat review by INTDIR is assigned to Carlos Pignataro
2025-02-04
38 Éric Vyncke Requested Telechat review by INTDIR
2025-01-30
38 Cindy Morgan Placed on agenda for telechat - 2025-03-06
2025-01-29
38 Jim Reid Request for Last Call review by DNSDIR is assigned to David Blacka
2025-01-28
38 Jean Mahoney Request for Last Call review by GENART is assigned to Robert Sparks
2025-01-28
38 Tero Kivinen Request for Last Call review by SECDIR is assigned to Akira Tsukamoto
2025-01-27
38 Barry Leiba Request for Last Call review by ARTART is assigned to Cullen Jennings
2025-01-27
38 Jenny Bui IANA Review state changed to IANA - Review Needed
2025-01-27
38 Jenny Bui
The following Last Call announcement was sent out (ends 2025-02-10):

From: The IESG
To: IETF-Announce
CC: Gorry Fairhurst , draft-ietf-tsvwg-udp-options@ietf.org, gorry@erg.abdn.ac.uk, tsvwg-chairs@ietf.org, …
The following Last Call announcement was sent out (ends 2025-02-10):

From: The IESG
To: IETF-Announce
CC: Gorry Fairhurst , draft-ietf-tsvwg-udp-options@ietf.org, gorry@erg.abdn.ac.uk, tsvwg-chairs@ietf.org, tsvwg@ietf.org, zahed.sarker.ietf@gmail.com
Reply-To: last-call@ietf.org
Sender:
Subject: Last Call:  (Transport Options for UDP) to Proposed Standard


The IESG has received a request from the Transport and Services Working Group
WG (tsvwg) to consider the following document: - 'Transport Options for UDP'
  as Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits final
comments on this action. Please send substantive comments to the
last-call@ietf.org mailing lists by 2025-02-10. Exceptionally, comments may
be sent to iesg@ietf.org instead. In either case, please retain the beginning
of the Subject line to allow automated sorting.

Abstract


  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.




The file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-tsvwg-udp-options/


The following IPR Declarations may be related to this I-D:

  https://datatracker.ietf.org/ipr/2673/





2025-01-27
38 Jenny Bui IESG state changed to In Last Call from Last Call Requested
2025-01-27
38 Jenny Bui Last call announcement was generated
2025-01-27
38 Zaheduzzaman Sarker Last call was requested
2025-01-27
38 Zaheduzzaman Sarker Ballot approval text was generated
2025-01-27
38 Zaheduzzaman Sarker Ballot writeup was generated
2025-01-27
38 Zaheduzzaman Sarker IESG state changed to Last Call Requested from Publication Requested
2025-01-27
38 Zaheduzzaman Sarker Last call announcement was generated
2024-11-03
38 Joseph Touch New version available: draft-ietf-tsvwg-udp-options-38.txt
2024-11-03
38 (System) New version approved
2024-11-03
38 (System) Request for posting confirmation emailed to previous authors: "C. Heard" , Joseph Touch
2024-11-03
38 Joseph Touch Uploaded new revision
2024-10-29
37 Zaheduzzaman Sarker
There has been request to process udp-options and udp-options-dplpmtud together. Hence I will hold on the AD review till I have received publication request for …
There has been request to process udp-options and udp-options-dplpmtud together. Hence I will hold on the AD review till I have received publication request for udp-options-dplpmtud.
2024-10-16
37 Gorry Fairhurst
UDP Options (draft-ietf-tsvwg-udp-options)

# Document Shepherd Write-Up for Group Documents

*This version is dated 4 July 2022.*

## Document History

1. Does the …
UDP Options (draft-ietf-tsvwg-udp-options)

# Document Shepherd Write-Up for Group Documents

*This version is dated 4 July 2022.*

## Document History

1. Does the working group (WG) consensus represent the strong concurrence of a
  few individuals, with others being silent, or did it reach broad agreement?

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 introduces an options format for UDP, for which ether was support from the WG. From the start it was clear that use of this format is optional, it was understood that many protocols layered over UDP already support options (SCTP, RTP, QUIC, DCCP, etc) and could be more appropriately extended using their own options space. A key addition offered by the set of options is support for methods to offer fragmentation at the UDP layer.

The first complete revision of the specification was reviewed by the WG. There was an invited protocol technical review from Colin Perkins (on draft-ietf-tsvwg-udp-options-19) in 2023 and it was updated. An issue tracker was used and all open issues from invited technical reviews and the WGLCs have been resolved. Each time the document was discussed and reviewed.

The WG decided to separate the procedures for using DPLPMTUD with the RES/REQ option into a separate draft.  The WG also decided the procedures for using the AUTH and Encryption options ought to be in separate I-Ds (currently an individual I-D exist for AUTH). The base document describes a process where receivers are allowed to ignore the AUTH option and accept the packet without verifying the authentication, or when there is no policy to do this.

A registry is described. If needed, the specification can be further extended.  The document retains the support of the TSVWG working group, and there is consensus (rough) to publish this version.

2. Was there controversy about particular points, or were there decisions where
  the consensus was particularly rough?

2.1 Timestamp: There were some additional requests from a small number of people for changes to the timestamp format.  The design was not changed, and this was confirmed on the list.

2.2 Network devices on the network path: UDP options can by default be read by network devices on the network path, in the same way that devices can read IP extensions/options and are often able to read tunnel headers. An explicit consensus call in May 2024, prior to WGLC confirmed that:
1. Routers ought to forward packets with UDP Options without modification, i.e.: "UDP Options MUST NOT be modified in transit".
2. the WG was content that “"UDP options are intended for use only by the transport  endpoints. They are no more (or less) appropriate to be modified  in-transit than any other portion of the transport datagram."
3. UDP Options does not by itself provide any mechanism for a device to authenticate the format or contents of the options data, or to detect if the surplus area has been removed from a packet.

2.3 Authentication and Encryption: UDP options defines the option format and rules for parsing of the UDP headers, but not the procedures for using the option information. The procedures in any additional I-Ds might describe how to establish a security context and procedures for how this is used to validate and forward authenticated data. This design in the latest rev was confirmed on the list (see 3).

3. Has anyone threatened an appeal or otherwise indicated extreme discontent? If
  so, please summarize the areas of conflict in separate email messages to the
  responsible Area Director. (It should be in a separate email because this
  questionnaire is publicly available.)

No, but when this design decision was confirmed on list, two people disagreed with this design. It was asserted that the AUTH option is not sufficiently specified or implemented to make a sufficient evaluation of its security characteristics, and that they think that inability to successfully process an AUTH option within UDP options needs to result in discard of a datagram. The Comments were received that helped to refine the proposed text. The editors proposed to retain the process for parsing the option, because this could then describe how the option related to the processing of other options, e.g. for fragmentation, but the text was amended to identify how the option ought to be configured when used.

4. For protocol documents, are there existing implementations of the contents of
  the document? Have a significant number of potential implementers indicated
  plans to implement? Are any existing implementations reported somewhere,
  either in the document itself (as [RFC 7942][3] recommends) or elsewhere
  (where)?

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. 

## Additional Reviews

5. Do the contents of this document closely interact with technologies in other
  IETF working groups or external organizations, and would it therefore benefit
  from their review? Have those reviews occurred? If yes, describe which
  reviews took place.

No.

6. Describe how the document meets any required formal expert review criteria,
  such as the MIB Doctor, YANG Doctor, media type, and URI type reviews.

No.

7. If the document contains a YANG module, has the final version of the module
  been checked with any of the [recommended validation tools][4] for syntax and
  formatting validation? If there are any resulting errors or warnings, what is
  the justification for not fixing them at this time? Does the YANG module
  comply with the Network Management Datastore Architecture (NMDA) as specified
  in [RFC 8342][5]?

N/A.

8. Describe reviews and automated checks performed to validate sections of the
  final version of the document written in a formal language, such as XML code,
  BNF rules, MIB definitions, CBOR's CDDL, etc.

None.

## Document Shepherd Checks

9. Based on the shepherd's review of the document, is it their opinion that this
  document is needed, clearly written, complete, correctly designed, and ready
  to be handed off to the responsible Area Director?

Yes.

10. Several IETF Areas have assembled [lists of common issues that their
    reviewers encounter][6]. For which areas have such issues been identified
    and addressed? For which does this still need to happen in subsequent
    reviews?

N/A.

11. What type of RFC publication is being requested on the IETF stream ([Best
    Current Practice][12], [Proposed Standard, Internet Standard][13],
    [Informational, Experimental or Historic][14])? Why is this the proper type
    of RFC? Do all Datatracker state attributes correctly reflect this intent?

This is a Standards Track update to an existing Standards Track specification.

12. Have reasonable efforts been made to remind all authors of the intellectual
    property rights (IPR) disclosure obligations described in [BCP 79][7]? To
    the best of your knowledge, have all required disclosures been filed? If
    not, explain why. If yes, summarize any relevant discussion, including links
    to publicly-available messages when applicable.

Yes. There is one related IPR disclosure:  Cisco's Statement about IPR related to draft-touch-tsvwg-udp-options. The WG was aware of this disclosure.

Both Editors have confirmed their obligations described in BCP 79.

13. Has each author, editor, and contributor shown their willingness to be
    listed as such? If the total number of authors and editors on the front page
    is greater than five, please provide a justification.

Yes.

14. Document any remaining I-D nits in this document. Simply running the [idnits
    tool][8] is not enough; please review the ["Content Guidelines" on
    authors.ietf.org][15]. (Also note that the current idnits tool generates
    some incorrect warnings; a rewrite is underway.)

This draft intentionally includes an obsolete informational reference is intentional for: RFC  793 (Obsoleted by RFC 9293).

15. Should any informative references be normative or vice-versa? See the [IESG
    Statement on Normative and Informative References][16].

Checked.

16. List any normative references that are not freely available to anyone. Did
    the community have sufficient access to review any such normative
    references?

None.

17. Are there any normative downward references (see [RFC 3967][9] and [BCP
    97
][10]) that are not already listed in the [DOWNREF registry][17]? If so,
    list them.

No.

18. Are there normative references to documents that are not ready to be
    submitted to the IESG for publication or are otherwise in an unclear state?
    If so, what is the plan for their completion?

The WG decided to separate the procedures for using DPLPMTUD with the RES/REQ option into a separate draft (draft-ietf-tsvwg-udp-options-dplpmtud). This is requested to be co-published with this I-D. A normative reference is included.

19. Will publication of this document change the status of any existing RFCs? If
    so, does the Datatracker metadata correctly reflect this and are those RFCs
    listed on the title page, in the abstract, and discussed in the
    introduction? If not, explain why and point to the part of the document
    where the relationship of this document to these other RFCs is discussed.

This will update a core IETF Spec, RFC 768.

20. Describe the document shepherd's review of the IANA considerations section,
    especially with regard to its consistency with the body of the document.
    Confirm that all aspects of the document requiring IANA assignments are
    associated with the appropriate reservations in IANA registries. Confirm
    that any referenced IANA registries have been clearly identified. Confirm
    that each newly created IANA registry specifies its initial contents,
    allocations procedures, and a reasonable name (see [RFC 8126][11]).

This was revised. A new registry is defined.

21. List any new IANA registries that require Designated Expert Review for
    future allocations. Are the instructions to the Designated Expert clear?
    Please include suggestions of designated experts, if appropriate.

Upon publication, IANA is hereby requested to create a new registry
group for UDP Options. The two suggested experts are:

Joe Touch
Mike Heard.

[1]: https://www.ietf.org/about/groups/iesg/
[2]: https://www.rfc-editor.org/rfc/rfc4858.html
[3]: https://www.rfc-editor.org/rfc/rfc7942.html
[4]: https://wiki.ietf.org/group/ops/yang-review-tools
[5]: https://www.rfc-editor.org/rfc/rfc8342.html
[6]: https://wiki.ietf.org/group/iesg/ExpertTopics
[7]: https://www.rfc-editor.org/info/bcp79
[8]: https://www.ietf.org/tools/idnits/
[9]: https://www.rfc-editor.org/rfc/rfc3967.html
[10]: https://www.rfc-editor.org/info/bcp97
[11]: https://www.rfc-editor.org/rfc/rfc8126.html
[12]: https://www.rfc-editor.org/rfc/rfc2026.html#section-5
[13]: https://www.rfc-editor.org/rfc/rfc2026.html#section-4.1
[14]: https://www.rfc-editor.org/rfc/rfc2026.html#section-4.2
[15]: https://authors.ietf.org/en/content-guidelines-overview
[16]: https://www.ietf.org/about/groups/iesg/statements/normative-informative-references/
[17]: https://datatracker.ietf.org/doc/downref/
2024-10-14
37 Gorry Fairhurst
UDP Options (draft-ietf-tsvwg-udp-options)

# Document Shepherd Write-Up for Group Documents

*This version is dated 4 July 2022.*

## Document History

1. Does the …
UDP Options (draft-ietf-tsvwg-udp-options)

# Document Shepherd Write-Up for Group Documents

*This version is dated 4 July 2022.*

## Document History

1. Does the working group (WG) consensus represent the strong concurrence of a
  few individuals, with others being silent, or did it reach broad agreement?

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 introduces an options format for UDP, for which ether was support from the WG. From the start it was clear that use of this format is optional, it was understood that many protocols layered over UDP already support options (SCTP, RTP, QUIC, DCCP, etc) and could be more appropriately extended using their own options space. A key addition offered by the set of options is support for methods to offer fragmentation at the UDP layer.

The first complete revision of the specification was reviewed by the WG. There was an invited protocol technical review from Colin Perkins (on draft-ietf-tsvwg-udp-options-19) in 2023 and it was updated. An issue tracker was used and all open issues from invited technical reviews and the WGLCs have been resolved. Each time the document was discussed and reviewed.

The WG decided to separate the procedures for using DPLPMTUD with the RES/REQ option into a separate draft.  The WG also decided the procedures for using the AUTH and Encryption options ought to be in separate I-Ds (currently an individual I-D exist for AUTH). The base document describes a process where receivers are allowed to ignore the AUTH option and accept the packet without verifying the authentication, or when there is no policy to do this.

A registry is described. If needed, the specification can be further extended.  The document retains the support of the TSVWG working group, and there is consensus (rough) to publish this version.

2. Was there controversy about particular points, or were there decisions where
  the consensus was particularly rough?

2.1 Timestamp: There were some additional requests from a small number of people for changes to the timestamp format.  The design was not changed, and this was confirmed on the list.

2.2 Network devices on the network path: UDP options can by default be read by network devices on the network path, in the same way that devices can read IP extensions/options and are often able to read tunnel headers. An explicit consensus call in May 2024, prior to WGLC confirmed that:
1. Routers ought to forward packets with UDP Options without modification, i.e.: "UDP Options MUST NOT be modified in transit".
2. the WG was content that “"UDP options are intended for use only by the transport  endpoints. They are no more (or less) appropriate to be modified  in-transit than any other portion of the transport datagram."
3. UDP Options does not by itself provide any mechanism for a device to authenticate the format or contents of the options data, or to detect if the surplus area has been removed from a packet.

2.3 Authentication and Encryption: UDP options defines the option format and rules for parsing of the UDP headers, but not the procedures for using the option information. The procedures in any additional I-Ds might describe how to establish a security context and procedures for how this is used to validate and forward authenticated data. This design in the latest rev was confirmed on the list (see 3).

3. Has anyone threatened an appeal or otherwise indicated extreme discontent? If
  so, please summarize the areas of conflict in separate email messages to the
  responsible Area Director. (It should be in a separate email because this
  questionnaire is publicly available.)

No, but when this design decision was confirmed on list, two people disagreed with this design.  It was asserted that the AUTH option is not sufficiently specified or implemented to make a sufficient evaluation of its security characteristics, comments were received that helped to refine the proposed text. The editors proposed to retain the process for parsing the option, because this could then describe how the option related to the processing of other options, e.g. for fragmentation, but the text was amended to identify how the option ought to be configured when used.

4. For protocol documents, are there existing implementations of the contents of
  the document? Have a significant number of potential implementers indicated
  plans to implement? Are any existing implementations reported somewhere,
  either in the document itself (as [RFC 7942][3] recommends) or elsewhere
  (where)?

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. 

## Additional Reviews

5. Do the contents of this document closely interact with technologies in other
  IETF working groups or external organizations, and would it therefore benefit
  from their review? Have those reviews occurred? If yes, describe which
  reviews took place.

No.

6. Describe how the document meets any required formal expert review criteria,
  such as the MIB Doctor, YANG Doctor, media type, and URI type reviews.

No.

7. If the document contains a YANG module, has the final version of the module
  been checked with any of the [recommended validation tools][4] for syntax and
  formatting validation? If there are any resulting errors or warnings, what is
  the justification for not fixing them at this time? Does the YANG module
  comply with the Network Management Datastore Architecture (NMDA) as specified
  in [RFC 8342][5]?

N/A.

8. Describe reviews and automated checks performed to validate sections of the
  final version of the document written in a formal language, such as XML code,
  BNF rules, MIB definitions, CBOR's CDDL, etc.

None.

## Document Shepherd Checks

9. Based on the shepherd's review of the document, is it their opinion that this
  document is needed, clearly written, complete, correctly designed, and ready
  to be handed off to the responsible Area Director?

Yes.

10. Several IETF Areas have assembled [lists of common issues that their
    reviewers encounter][6]. For which areas have such issues been identified
    and addressed? For which does this still need to happen in subsequent
    reviews?

N/A.

11. What type of RFC publication is being requested on the IETF stream ([Best
    Current Practice][12], [Proposed Standard, Internet Standard][13],
    [Informational, Experimental or Historic][14])? Why is this the proper type
    of RFC? Do all Datatracker state attributes correctly reflect this intent?

This is a Standards Track update to an existing Standards Track specification.

12. Have reasonable efforts been made to remind all authors of the intellectual
    property rights (IPR) disclosure obligations described in [BCP 79][7]? To
    the best of your knowledge, have all required disclosures been filed? If
    not, explain why. If yes, summarize any relevant discussion, including links
    to publicly-available messages when applicable.

Yes. There is one related IPR disclosure:  Cisco's Statement about IPR related to draft-touch-tsvwg-udp-options. The WG was aware of this disclosure.

Both Editors have confirmed their obligations described in BCP 79.

13. Has each author, editor, and contributor shown their willingness to be
    listed as such? If the total number of authors and editors on the front page
    is greater than five, please provide a justification.

Yes.

14. Document any remaining I-D nits in this document. Simply running the [idnits
    tool][8] is not enough; please review the ["Content Guidelines" on
    authors.ietf.org][15]. (Also note that the current idnits tool generates
    some incorrect warnings; a rewrite is underway.)

This draft intentionally includes an obsolete informational reference is intentional for: RFC  793 (Obsoleted by RFC 9293).

15. Should any informative references be normative or vice-versa? See the [IESG
    Statement on Normative and Informative References][16].

Checked.

16. List any normative references that are not freely available to anyone. Did
    the community have sufficient access to review any such normative
    references?

None.

17. Are there any normative downward references (see [RFC 3967][9] and [BCP
    97
][10]) that are not already listed in the [DOWNREF registry][17]? If so,
    list them.

No.

18. Are there normative references to documents that are not ready to be
    submitted to the IESG for publication or are otherwise in an unclear state?
    If so, what is the plan for their completion?

The WG decided to separate the procedures for using DPLPMTUD with the RES/REQ option into a separate draft (draft-ietf-tsvwg-udp-options-dplpmtud). This is requested to be co-published with this I-D. A normative reference is included.

19. Will publication of this document change the status of any existing RFCs? If
    so, does the Datatracker metadata correctly reflect this and are those RFCs
    listed on the title page, in the abstract, and discussed in the
    introduction? If not, explain why and point to the part of the document
    where the relationship of this document to these other RFCs is discussed.

This will update a core IETF Spec, RFC 768.

20. Describe the document shepherd's review of the IANA considerations section,
    especially with regard to its consistency with the body of the document.
    Confirm that all aspects of the document requiring IANA assignments are
    associated with the appropriate reservations in IANA registries. Confirm
    that any referenced IANA registries have been clearly identified. Confirm
    that each newly created IANA registry specifies its initial contents,
    allocations procedures, and a reasonable name (see [RFC 8126][11]).

This was revised. A new registry is defined.

21. List any new IANA registries that require Designated Expert Review for
    future allocations. Are the instructions to the Designated Expert clear?
    Please include suggestions of designated experts, if appropriate.

Upon publication, IANA is hereby requested to create a new registry
group for UDP Options. The two suggested experts are:

Joe Touch
Mike Heard.

[1]: https://www.ietf.org/about/groups/iesg/
[2]: https://www.rfc-editor.org/rfc/rfc4858.html
[3]: https://www.rfc-editor.org/rfc/rfc7942.html
[4]: https://wiki.ietf.org/group/ops/yang-review-tools
[5]: https://www.rfc-editor.org/rfc/rfc8342.html
[6]: https://wiki.ietf.org/group/iesg/ExpertTopics
[7]: https://www.rfc-editor.org/info/bcp79
[8]: https://www.ietf.org/tools/idnits/
[9]: https://www.rfc-editor.org/rfc/rfc3967.html
[10]: https://www.rfc-editor.org/info/bcp97
[11]: https://www.rfc-editor.org/rfc/rfc8126.html
[12]: https://www.rfc-editor.org/rfc/rfc2026.html#section-5
[13]: https://www.rfc-editor.org/rfc/rfc2026.html#section-4.1
[14]: https://www.rfc-editor.org/rfc/rfc2026.html#section-4.2
[15]: https://authors.ietf.org/en/content-guidelines-overview
[16]: https://www.ietf.org/about/groups/iesg/statements/normative-informative-references/
[17]: https://datatracker.ietf.org/doc/downref/
2024-10-14
37 Gorry Fairhurst IETF WG state changed to Submitted to IESG for Publication from WG Consensus: Waiting for Write-Up
2024-10-14
37 Gorry Fairhurst IESG state changed to Publication Requested from I-D Exists
2024-10-14
37 (System) Changed action holders to Zaheduzzaman Sarker (IESG state changed)
2024-10-14
37 Gorry Fairhurst Responsible AD changed to Zaheduzzaman Sarker
2024-10-14
37 Gorry Fairhurst Document is now in IESG state Publication Requested
2024-10-14
37 Gorry Fairhurst Rev draft-ietf-tsvwg-udp-options-37 responded to shepherd feedback, there are no pending issues raised by the document shepherd.
2024-10-14
37 Gorry Fairhurst Tags Revised I-D Needed - Issue raised by WG, Doc Shepherd Follow-up Underway cleared.
2024-10-14
37 Gorry Fairhurst IETF WG state changed to WG Consensus: Waiting for Write-Up from Waiting for WG Chair Go-Ahead
2024-10-14
37 Gorry Fairhurst
UDP Options (draft-ietf-tsvwg-udp-options)

# Document Shepherd Write-Up for Group Documents

*This version is dated 4 July 2022.*

## Document History

1. Does the …
UDP Options (draft-ietf-tsvwg-udp-options)

# Document Shepherd Write-Up for Group Documents

*This version is dated 4 July 2022.*

## Document History

1. Does the working group (WG) consensus represent the strong concurrence of a
  few individuals, with others being silent, or did it reach broad agreement?

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 introduces an options format for UDP, for which ether was support from the WG. From the start it was clear that use of this format is optional, it was understood that many protocols layered over UDP already support options (SCTP, RTP, QUIC, DCCP, etc) and could be more appropriately extended using their own options space. A key addition offered by the set of options is support for methods to offer fragmentation at the UDP layer.

The first complete revision of the specification was reviewed by the WG. There was an invited protocol technical review from Colin Perkins (on draft-ietf-tsvwg-udp-options-19) in 2023 and it was updated. An issue tracker was used and all open issues from invited technical reviews and the WGLCs have been resolved. Each time the document was discussed and reviewed.

The WG decided to separate the procedures for using DPLPMTUD with the RES/REQ option into a separate draft.  The WG also decided the procedures for using the AUTH and Encryption options ought to be in separate I-Ds (currently an individual I-D exist for AUTH). The base document describes a process where receivers are allowed to ignore the AUTH option and accept the packet without verifying the authentication, or when there is no policy to do this.

A registry is described. If needed, the specification can be further extended.  The document retains the support of the TSVWG working group, and there is consensus (rough) to publish this version.

2. Was there controversy about particular points, or were there decisions where
  the consensus was particularly rough?

2.1 Timestamp: There were some additional requests from a small number of people for changes to the timestamp format.  The design was not changed, and this was confirmed on the list.

2.2 Network devices on the network path: UDP options can by default be read by network devices on the network path, in the same way that devices can read IP extensions/options and are often able to read tunnel headers. An explicit consensus call in May 2024, prior to WGLC confirmed that:
1. Routers ought to forward packets with UDP Options without modification, i.e.: "UDP Options MUST NOT be modified in transit".
2. the WG was content that “"UDP options are intended for use only by the transport  endpoints. They are no more (or less) appropriate to be modified  in-transit than any other portion of the transport datagram."
3. UDP Options does not by itself provide any mechanism for a device to authenticate the format or contents of the options data, or to detect if the surplus area has been removed from a packet.

2.3 Authentication and Encryption: UDP options defines the option format and rules for parsing of the UDP headers, but not the procedures for using the option information. The procedures in any additional I-Ds might describe how to establish a security context and procedures for how this is used to validate and forward authenticated data. This design in the latest rev was confirmed on the list (see 3).

3. Has anyone threatened an appeal or otherwise indicated extreme discontent? If
  so, please summarize the areas of conflict in separate email messages to the
  responsible Area Director. (It should be in a separate email because this
  questionnaire is publicly available.)

No, but when this design decision was confirmed on list, two people disagreed with this design.  It was asserted that the AUTH option is not sufficiently specified or implemented to make a sufficient evaluation of its security characteristics, comments were received that helped to refine the proposed text. The editors proposed to retain the process for parsing the option, because this could then describe how the option related to the processing of other options, e.g. for fragmentation, but the text was amended to identify how the option ought to be configured when used.

4. For protocol documents, are there existing implementations of the contents of
  the document? Have a significant number of potential implementers indicated
  plans to implement? Are any existing implementations reported somewhere,
  either in the document itself (as [RFC 7942][3] recommends) or elsewhere
  (where)?

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. 

## Additional Reviews

5. Do the contents of this document closely interact with technologies in other
  IETF working groups or external organizations, and would it therefore benefit
  from their review? Have those reviews occurred? If yes, describe which
  reviews took place.

No.

6. Describe how the document meets any required formal expert review criteria,
  such as the MIB Doctor, YANG Doctor, media type, and URI type reviews.

No.

7. If the document contains a YANG module, has the final version of the module
  been checked with any of the [recommended validation tools][4] for syntax and
  formatting validation? If there are any resulting errors or warnings, what is
  the justification for not fixing them at this time? Does the YANG module
  comply with the Network Management Datastore Architecture (NMDA) as specified
  in [RFC 8342][5]?

N/A.

8. Describe reviews and automated checks performed to validate sections of the
  final version of the document written in a formal language, such as XML code,
  BNF rules, MIB definitions, CBOR's CDDL, etc.

None.

## Document Shepherd Checks

9. Based on the shepherd's review of the document, is it their opinion that this
  document is needed, clearly written, complete, correctly designed, and ready
  to be handed off to the responsible Area Director?

Yes.

10. Several IETF Areas have assembled [lists of common issues that their
    reviewers encounter][6]. For which areas have such issues been identified
    and addressed? For which does this still need to happen in subsequent
    reviews?

N/A.

11. What type of RFC publication is being requested on the IETF stream ([Best
    Current Practice][12], [Proposed Standard, Internet Standard][13],
    [Informational, Experimental or Historic][14])? Why is this the proper type
    of RFC? Do all Datatracker state attributes correctly reflect this intent?

This is a Standards Track update to an existing Standards Track specification.

12. Have reasonable efforts been made to remind all authors of the intellectual
    property rights (IPR) disclosure obligations described in [BCP 79][7]? To
    the best of your knowledge, have all required disclosures been filed? If
    not, explain why. If yes, summarize any relevant discussion, including links
    to publicly-available messages when applicable.

Yes. There is one related IPR disclosure:  Cisco's Statement about IPR related to draft-touch-tsvwg-udp-options. The WG was aware of this disclosure.

Both Editors have confirmed their obligations described in BCP 79.

13. Has each author, editor, and contributor shown their willingness to be
    listed as such? If the total number of authors and editors on the front page
    is greater than five, please provide a justification.

Yes.

14. Document any remaining I-D nits in this document. Simply running the [idnits
    tool][8] is not enough; please review the ["Content Guidelines" on
    authors.ietf.org][15]. (Also note that the current idnits tool generates
    some incorrect warnings; a rewrite is underway.)

This draft intentionally includes an obsolete informational reference is intentional for: RFC  793 (Obsoleted by RFC 9293).

15. Should any informative references be normative or vice-versa? See the [IESG
    Statement on Normative and Informative References][16].

Checked.

16. List any normative references that are not freely available to anyone. Did
    the community have sufficient access to review any such normative
    references?

None.

17. Are there any normative downward references (see [RFC 3967][9] and [BCP
    97
][10]) that are not already listed in the [DOWNREF registry][17]? If so,
    list them.

No.

18. Are there normative references to documents that are not ready to be
    submitted to the IESG for publication or are otherwise in an unclear state?
    If so, what is the plan for their completion?

The WG decided to separate the procedures for using DPLPMTUD with the RES/REQ option into a separate draft (draft-ietf-tsvwg-udp-options-dplpmtud). This is requested to be co-published with this I-D. A normative reference is included.

19. Will publication of this document change the status of any existing RFCs? If
    so, does the Datatracker metadata correctly reflect this and are those RFCs
    listed on the title page, in the abstract, and discussed in the
    introduction? If not, explain why and point to the part of the document
    where the relationship of this document to these other RFCs is discussed.

This will update a core IETF Spec, RFC 768.

20. Describe the document shepherd's review of the IANA considerations section,
    especially with regard to its consistency with the body of the document.
    Confirm that all aspects of the document requiring IANA assignments are
    associated with the appropriate reservations in IANA registries. Confirm
    that any referenced IANA registries have been clearly identified. Confirm
    that each newly created IANA registry specifies its initial contents,
    allocations procedures, and a reasonable name (see [RFC 8126][11]).

This was revised. A new registry is defined.

21. List any new IANA registries that require Designated Expert Review for
    future allocations. Are the instructions to the Designated Expert clear?
    Please include suggestions of designated experts, if appropriate.

Upon publication, IANA is hereby requested to create a new registry
group for UDP Options. The two suggested experts are:

Joe Touch
Mike Heard.

[1]: https://www.ietf.org/about/groups/iesg/
[2]: https://www.rfc-editor.org/rfc/rfc4858.html
[3]: https://www.rfc-editor.org/rfc/rfc7942.html
[4]: https://wiki.ietf.org/group/ops/yang-review-tools
[5]: https://www.rfc-editor.org/rfc/rfc8342.html
[6]: https://wiki.ietf.org/group/iesg/ExpertTopics
[7]: https://www.rfc-editor.org/info/bcp79
[8]: https://www.ietf.org/tools/idnits/
[9]: https://www.rfc-editor.org/rfc/rfc3967.html
[10]: https://www.rfc-editor.org/info/bcp97
[11]: https://www.rfc-editor.org/rfc/rfc8126.html
[12]: https://www.rfc-editor.org/rfc/rfc2026.html#section-5
[13]: https://www.rfc-editor.org/rfc/rfc2026.html#section-4.1
[14]: https://www.rfc-editor.org/rfc/rfc2026.html#section-4.2
[15]: https://authors.ietf.org/en/content-guidelines-overview
[16]: https://www.ietf.org/about/groups/iesg/statements/normative-informative-references/
[17]: https://datatracker.ietf.org/doc/downref/
2024-10-13
37 Joseph Touch New version available: draft-ietf-tsvwg-udp-options-37.txt
2024-10-13
37 (System) New version approved
2024-10-13
37 (System) Request for posting confirmation emailed to previous authors: "C. Heard" , Joseph Touch
2024-10-13
37 Joseph Touch Uploaded new revision
2024-10-01
36 Gorry Fairhurst Shepherd comments sent to list 27th Sept.
Editors to prepare a revised I-D.
2024-10-01
36 Gorry Fairhurst Tags Doc Shepherd Follow-up Underway, Revised I-D Needed - Issue raised by WG set. Tag Other - see Comment Log cleared.
2024-10-01
36 Gorry Fairhurst
One person has disagreed with this design, suggesting that this is a security liability. It  has been noted that this behavior in the draft deviates …
One person has disagreed with this design, suggesting that this is a security liability. It  has been noted that this behavior in the draft deviates from the behavior of other similar IETF authentication protocols including IPv6 AH and TCP-AO.  It has also been stated that the AUTH option is not sufficiently specified or implemented to make a sufficient evaluation of its security characteristics.

We would like to hear of any people who disagree with publishing the current AUTH text. Unless the chairs hear additional reasoned opposition by 4th October 2024, we will declare consensus on the current text and move to request publication for the next revision of the UDP Options I-D. If we do, we plan for the publication request to note this concern as being in the rough.
2024-10-01
36 Gorry Fairhurst Tag Other - see Comment Log set.
2024-09-26
36 Gorry Fairhurst Changed consensus to Yes from Unknown
2024-09-26
36 Gorry Fairhurst Intended Status changed to Proposed Standard from None
2024-09-22
36 Joseph Touch New version available: draft-ietf-tsvwg-udp-options-36.txt
2024-09-22
36 Joseph Touch New version accepted (logged-in submitter: Joseph Touch)
2024-09-22
36 Joseph Touch Uploaded new revision
2024-09-21
35 Gorry Fairhurst Revised I-D was submitted to address WGLC. This document appears to be ready to proceed, and will now be reviewed by the document shepherd.
2024-09-21
35 Gorry Fairhurst Tag Revised I-D Needed - Issue raised by WGLC cleared.
2024-09-20
35 Joseph Touch New version available: draft-ietf-tsvwg-udp-options-35.txt
2024-09-20
35 Joseph Touch New version accepted (logged-in submitter: Joseph Touch)
2024-09-20
35 Joseph Touch Uploaded new revision
2024-09-16
34 Joseph Touch New version available: draft-ietf-tsvwg-udp-options-34.txt
2024-09-16
34 Joseph Touch New version accepted (logged-in submitter: Joseph Touch)
2024-09-16
34 Joseph Touch Uploaded new revision
2024-09-04
33 Joseph Touch New version available: draft-ietf-tsvwg-udp-options-33.txt
2024-09-04
33 Joseph Touch New version accepted (logged-in submitter: Joseph Touch)
2024-09-04
33 Joseph Touch Uploaded new revision
2024-06-11
32 Gorry Fairhurst Tag Revised I-D Needed - Issue raised by WGLC set. Tag Revised I-D Needed - Issue raised by WG cleared.
2024-05-15
32 Gorry Fairhurst
Thanks to all who participated in this WGLC. This document has now successfully concluded the WGLC.

A revised ID is needed to respond to WGLC …
Thanks to all who participated in this WGLC. This document has now successfully concluded the WGLC.

A revised ID is needed to respond to WGLC comments. Editor(s), please revise to address all comments you are able, and propose new text on-list for any issues where there is no obvious way forward. Once all issues have been closed, and a new ID is available, the chairs will prepare a wrietup requesting publication.
2024-05-15
32 Gorry Fairhurst Tag Revised I-D Needed - Issue raised by WG set.
2024-05-15
32 Gorry Fairhurst IETF WG state changed to Waiting for WG Chair Go-Ahead from In WG Last Call
2024-04-10
32 Gorry Fairhurst Start of list WGLC 10th April, to end 1st May 2024.
2024-03-25
32 Gorry Fairhurst
This starts a 3 week WG Last Call call to determine if the following TSVWG IDs are ready to publish:


https://datatracker.ietf.org/doc/draft-ietf-tsvwg-udp-options/

https://datatracker.ietf.org/doc/draft-ietf-tsvwg-udp-options-dplpmtud/

These documents target …
This starts a 3 week WG Last Call call to determine if the following TSVWG IDs are ready to publish:


https://datatracker.ietf.org/doc/draft-ietf-tsvwg-udp-options/

https://datatracker.ietf.org/doc/draft-ietf-tsvwg-udp-options-dplpmtud/

These documents target PROPOSED STANDARD.

The document shepherd  for the UDP Options will be: Gorry Fairhurst.

The document shepherd  for DPLPMTUD with UDP Options will be:  Marten Seemann.

The WGLC will end at midnight UTC on 10th April 2024. 

Please do read the drafts, and send any comments/concerns to the TSVWG mailing list, including notes on whether these are ready to publish (or send an email directly to the chairs ).

Best wishes,

Gorry and Marten

(tsvwg co-chairs)



The IETF WG Last Call process is described in RFC 6174.
2024-03-25
32 Gorry Fairhurst IETF WG state changed to In WG Last Call from WG Document
2024-03-21
32 Joseph Touch New version available: draft-ietf-tsvwg-udp-options-32.txt
2024-03-21
32 Joseph Touch New version accepted (logged-in submitter: Joseph Touch)
2024-03-21
32 Joseph Touch Uploaded new revision
2024-03-09
31 Gorry Fairhurst Added to session: IETF-119: tsvwg  Mon-0730
2024-03-04
31 Joseph Touch New version available: draft-ietf-tsvwg-udp-options-31.txt
2024-03-04
31 (System) New version approved
2024-03-04
31 (System) Request for posting confirmation emailed to previous authors: Joseph Touch
2024-03-04
31 Joseph Touch Uploaded new revision
2024-03-04
30 Joseph Touch New version available: draft-ietf-tsvwg-udp-options-30.txt
2024-03-04
30 (System) New version approved
2024-03-04
30 (System) Request for posting confirmation emailed to previous authors: Joseph Touch
2024-03-04
30 Joseph Touch Uploaded new revision
2024-03-03
29 Joseph Touch New version available: draft-ietf-tsvwg-udp-options-29.txt
2024-03-03
29 (System) New version approved
2024-03-03
29 (System) Request for posting confirmation emailed to previous authors: Joseph Touch
2024-03-03
29 Joseph Touch Uploaded new revision
2023-11-17
28 Joseph Touch New version available: draft-ietf-tsvwg-udp-options-28.txt
2023-11-17
28 Joseph Touch New version accepted (logged-in submitter: Joseph Touch)
2023-11-17
28 Joseph Touch Uploaded new revision
2023-11-14
27 Joseph Touch New version available: draft-ietf-tsvwg-udp-options-27.txt
2023-11-14
27 Joseph Touch New version accepted (logged-in submitter: Joseph Touch)
2023-11-14
27 Joseph Touch Uploaded new revision
2023-11-12
26 Joseph Touch New version available: draft-ietf-tsvwg-udp-options-26.txt
2023-11-12
26 Joseph Touch New version accepted (logged-in submitter: Joseph Touch)
2023-11-12
26 Joseph Touch Uploaded new revision
2023-11-12
25 Joseph Touch New version available: draft-ietf-tsvwg-udp-options-25.txt
2023-11-12
25 Joseph Touch New version accepted (logged-in submitter: Joseph Touch)
2023-11-12
25 Joseph Touch Uploaded new revision
2023-11-06
24 Joseph Touch New version available: draft-ietf-tsvwg-udp-options-24.txt
2023-11-06
24 Joseph Touch New version accepted (logged-in submitter: Joseph Touch)
2023-11-06
24 Joseph Touch Uploaded new revision
2023-09-15
23 Joseph Touch New version available: draft-ietf-tsvwg-udp-options-23.txt
2023-09-15
23 (System) New version approved
2023-09-15
23 (System) Request for posting confirmation emailed to previous authors: Joseph Touch
2023-09-15
23 Joseph Touch Uploaded new revision
2023-09-13
22 Gorry Fairhurst Added to session: interim-2023-tsvwg-01
2023-07-22
22 Paul Wouters Request for Early review by SECDIR Completed: Ready. Reviewer: Paul Wouters. Sent review to list.
2023-07-22
22 Tero Kivinen Request for Early review by SECDIR is assigned to Paul Wouters
2023-07-20
22 Martin Duke Changed document external resources from: None to:

github_repo https://github.com/tsvwg/draft-ietf-tsvwg-udp-options
2023-07-19
22 Paul Wouters Requested Early review by SECDIR
2023-07-14
22 Gorry Fairhurst Added to session: IETF-117: tsvwg  Wed-0000
2023-07-14
22 Gorry Fairhurst Removed from session: IETF-117: tsvwg  Thu-1630
2023-07-14
22 Gorry Fairhurst Added to session: IETF-117: tsvwg  Thu-1630
2023-07-04
22 Gorry Fairhurst This document is being developed at a first WGLC and is expected to require a final WGLC prior to publication.
2023-07-04
22 Gorry Fairhurst Tag Revised I-D Needed - Issue raised by WG cleared.
2023-07-04
22 Gorry Fairhurst IETF WG state changed to WG Document from Waiting for WG Chair Go-Ahead
2023-06-09
22 Joseph Touch New version available: draft-ietf-tsvwg-udp-options-22.txt
2023-06-09
22 (System) New version approved
2023-06-09
22 (System) Request for posting confirmation emailed to previous authors: Joseph Touch
2023-06-09
22 Joseph Touch Uploaded new revision
2023-06-08
21 Joseph Touch New version available: draft-ietf-tsvwg-udp-options-21.txt
2023-06-08
21 (System) New version approved
2023-06-08
21 (System) Request for posting confirmation emailed to previous authors: Joseph Touch
2023-06-08
21 Joseph Touch Uploaded new revision
2023-03-27
20 Joseph Touch New version available: draft-ietf-tsvwg-udp-options-20.txt
2023-03-27
20 Joseph Touch New version accepted (logged-in submitter: Joseph Touch)
2023-03-27
20 Joseph Touch Uploaded new revision
2023-03-14
19 Gorry Fairhurst Added to session: IETF-116: tsvwg  Tue-0030
2023-02-15
19 Gorry Fairhurst IETF WG state changed to Waiting for WG Chair Go-Ahead from In WG Last Call
2023-02-09
19 Carlos Pignataro Request for Early review by INTDIR Completed: Ready with Issues. Reviewer: Carlos Pignataro.
2023-02-09
19 Carlos Pignataro Request for Early review by INTDIR Completed: Ready with Issues. Reviewer: Carlos Pignataro. Sent review to list. Submission of review completed at an earlier date.
2023-02-07
19 Gorry Fairhurst Extended until 10th Feb.
2023-02-07
19 Gorry Fairhurst Tag Revised I-D Needed - Issue raised by WG set.
2023-01-11
19 Carlos Jesús Bernardos Request for Early review by INTDIR is assigned to Carlos Pignataro
2023-01-10
19 Gorry Fairhurst This email starts a 3 week WG Last Call call to determine if the following TSVWG IDs are ready to publish:
   
https://datatracker.ietf.org/doc/draft-ietf-tsvwg-udp-options/
https://datatracker.ietf.org/doc/draft-ietf-tsvwg-udp-options-dplpmtud/
2023-01-10
19 Gorry Fairhurst IETF WG state changed to In WG Last Call from WG Document
2023-01-10
19 Gorry Fairhurst Requested Early review by INTDIR
2022-12-27
19 Joseph Touch New version available: draft-ietf-tsvwg-udp-options-19.txt
2022-12-27
19 (System) New version approved
2022-12-27
19 (System) Request for posting confirmation emailed to previous authors: Joseph Touch
2022-12-27
19 Joseph Touch Uploaded new revision
2022-09-27
18 (System) Document has expired
2022-03-26
18 Joseph Touch New version available: draft-ietf-tsvwg-udp-options-18.txt
2022-03-26
18 (System) New version accepted (logged-in submitter: Joseph Touch)
2022-03-26
18 Joseph Touch Uploaded new revision
2022-03-24
17 Joseph Touch New version available: draft-ietf-tsvwg-udp-options-17.txt
2022-03-24
17 (System) New version accepted (logged-in submitter: Joseph Touch)
2022-03-24
17 Joseph Touch Uploaded new revision
2022-03-22
16 Gorry Fairhurst Added to session: IETF-113: tsvwg  Fri-1000
2022-03-19
16 Joseph Touch New version available: draft-ietf-tsvwg-udp-options-16.txt
2022-03-19
16 (System) New version approved
2022-03-19
16 (System) Request for posting confirmation emailed to previous authors: Joseph Touch
2022-03-19
16 Joseph Touch Uploaded new revision
2022-03-03
15 Joseph Touch New version available: draft-ietf-tsvwg-udp-options-15.txt
2022-03-03
15 (System) New version approved
2022-03-03
15 (System) Request for posting confirmation emailed to previous authors: Joseph Touch
2022-03-03
15 Joseph Touch Uploaded new revision
2022-03-01
14 Joseph Touch New version available: draft-ietf-tsvwg-udp-options-14.txt
2022-03-01
14 (System) New version approved
2022-03-01
14 (System) Request for posting confirmation emailed to previous authors: Joseph Touch
2022-03-01
14 Joseph Touch Uploaded new revision
2021-12-29
13 Bernie Volz Closed request for Early review by INTDIR with state 'Team Will not Review Version'
2021-12-21
13 (System) Document has expired
2021-11-01
13 Gorry Fairhurst Added to session: IETF-112: tsvwg  Fri-1600
2021-10-13
13 Carlos Jesús Bernardos Assignment of request for Early review by INTDIR to Tatuya Jinmei was marked no-response
2021-08-11
13 Gorry Fairhurst Added to session: interim-2021-tsvwg-02
2021-06-19
13 Joseph Touch New version available: draft-ietf-tsvwg-udp-options-13.txt
2021-06-19
13 (System) New version approved
2021-06-19
13 (System) Request for posting confirmation emailed to previous authors: Joseph Touch
2021-06-19
13 Joseph Touch Uploaded new revision
2021-05-18
12 Bernie Volz Request for Early review by INTDIR is assigned to Tatuya Jinmei
2021-05-18
12 Bernie Volz Request for Early review by INTDIR is assigned to Tatuya Jinmei
2021-05-18
12 Martin Duke Closed request for Early review by INTDIR with state 'Withdrawn': Duplicate
2021-05-18
12 Gorry Fairhurst Requested Early review by INTDIR
2021-05-13
12 Gorry Fairhurst Requested Early review by INTDIR
2021-05-02
12 Joseph Touch New version available: draft-ietf-tsvwg-udp-options-12.txt
2021-05-02
12 (System) New version approved
2021-05-02
12 (System) Request for posting confirmation emailed to previous authors: Joseph Touch
2021-05-02
12 Joseph Touch Uploaded new revision
2021-05-02
11 Joseph Touch New version available: draft-ietf-tsvwg-udp-options-11.txt
2021-05-02
11 (System) New version approved
2021-05-02
11 (System) Request for posting confirmation emailed to previous authors: Joseph Touch
2021-05-02
11 Joseph Touch Uploaded new revision
2021-05-01
10 Joseph Touch New version available: draft-ietf-tsvwg-udp-options-10.txt
2021-05-01
10 (System) New version approved
2021-05-01
10 (System) Request for posting confirmation emailed to previous authors: Joseph Touch
2021-05-01
10 Joseph Touch Uploaded new revision
2021-03-07
09 Gorry Fairhurst Added to session: IETF-110: tsvwg  Mon-1700
2020-11-25
09 Joseph Touch New version available: draft-ietf-tsvwg-udp-options-09.txt
2020-11-25
09 (System) New version approved
2020-11-25
09 (System) Request for posting confirmation emailed to previous authors: Joseph Touch
2020-11-25
09 Joseph Touch Uploaded new revision
2020-03-15
08 (System) Document has expired
2019-09-12
08 Joseph Touch New version available: draft-ietf-tsvwg-udp-options-08.txt
2019-09-12
08 (System) New version approved
2019-09-12
08 (System) Request for posting confirmation emailed to previous authors: Joseph Touch
2019-09-12
08 Joseph Touch Uploaded new revision
2019-09-09
07 (System) Document has expired
2019-03-08
07 Joseph Touch New version available: draft-ietf-tsvwg-udp-options-07.txt
2019-03-08
07 (System) New version approved
2019-03-08
07 (System) Request for posting confirmation emailed to previous authors: Joseph Touch
2019-03-08
07 Joseph Touch Uploaded new revision
2019-03-05
06 Joseph Touch New version available: draft-ietf-tsvwg-udp-options-06.txt
2019-03-05
06 (System) New version approved
2019-03-05
06 (System) Request for posting confirmation emailed to previous authors: Joseph Touch
2019-03-05
06 Joseph Touch Uploaded new revision
2019-01-20
05 (System) Document has expired
2018-07-19
05 Joseph Touch New version available: draft-ietf-tsvwg-udp-options-05.txt
2018-07-19
05 (System) New version approved
2018-07-19
05 (System) Request for posting confirmation emailed to previous authors: Joseph Touch
2018-07-19
05 Joseph Touch Uploaded new revision
2018-07-19
04 David Black Added to session: IETF-102: tsvwg  Thu-1810
2018-07-19
04 David Black Removed from session: IETF-102: tsvwg  Thu-1550
2018-07-19
04 David Black Added to session: IETF-102: tsvwg  Thu-1550
2018-07-01
04 Joseph Touch New version available: draft-ietf-tsvwg-udp-options-04.txt
2018-07-01
04 (System) New version approved
2018-07-01
04 (System) Request for posting confirmation emailed to previous authors: Joseph Touch
2018-07-01
04 Joseph Touch Uploaded new revision
2018-07-01
03 Joseph Touch New version available: draft-ietf-tsvwg-udp-options-03.txt
2018-07-01
03 (System) New version approved
2018-07-01
03 (System) Request for posting confirmation emailed to previous authors: Joseph Touch
2018-07-01
03 Joseph Touch Uploaded new revision
2018-03-21
02 Gorry Fairhurst Added to session: IETF-101: tsvwg  Thu-1810
2018-01-19
02 Joseph Touch New version available: draft-ietf-tsvwg-udp-options-02.txt
2018-01-19
02 (System) New version approved
2018-01-19
02 (System) Request for posting confirmation emailed to previous authors: Joseph Touch , tsvwg-chairs@ietf.org
2018-01-19
02 Joseph Touch Uploaded new revision
2017-12-29
01 (System) Document has expired
2017-07-20
01 David Black Notification list changed to Gorry Fairhurst <gorry@erg.abdn.ac.uk>
2017-07-20
01 David Black Document shepherd changed to Gorry Fairhurst
2017-07-18
01 David Black Added to session: IETF-99: tsvwg  Tue-1330
2017-06-27
01 Joseph Touch New version available: draft-ietf-tsvwg-udp-options-01.txt
2017-06-27
01 (System) New version approved
2017-06-27
01 (System) Request for posting confirmation emailed to previous authors: Joseph Touch
2017-06-27
01 Joseph Touch Uploaded new revision
2017-06-09
00 Gorry Fairhurst This document now replaces draft-touch-tsvwg-udp-options instead of draft-touch-tsvwg-udp-options
2017-06-09
00 Joseph Touch New version available: draft-ietf-tsvwg-udp-options-00.txt
2017-06-09
00 (System) WG -00 approved
2017-06-09
00 Gorry Fairhurst This document now replaces draft-touch-tsvwg-udp-options instead of None
2017-06-09
00 Joseph Touch New version available: draft-ietf-tsvwg-udp-options-00.txt
2017-06-09
00 (System) WG -00 approved
2017-06-08
00 Joseph Touch Set submitter to "Joe Touch ", replaces to draft-touch-tsvwg-udp-options and sent approval email to group chairs: tsvwg-chairs@ietf.org
2017-06-08
00 Joseph Touch Set submitter to "Joe Touch ", replaces to draft-touch-tsvwg-udp-options and sent approval email to group chairs: tsvwg-chairs@ietf.org
2017-06-08
00 Joseph Touch Uploaded new revision
2017-06-08
00 Joseph Touch Uploaded new revision