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 |