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

Received changes through RFC Editor sync (changed state to RFC, created became rfc relationship between draft-ietf-tsvwg-udp-options and RFC 9868, changed IESG state to RFC Published)

[Ballot comment]
Thanks for quickly addressing my previous DISCUSS. I have kept my previous comments below for archiving purpose only.
See also: https://mailarchive.ietf.org/arch/msg/tsvwg/-VPfuPWFvj5HHtZF67eq9OLzG2w/

This is a simple and brilliant technique

-éric

## Previous DISCUSS (for archiving)

As noted in https://www.ietf.org/blog/handling-iesg-ballot-positions/, a DISCUSS ballot is just a request to have a discussion on the following topics:

### Section 7

`UDP_Length = IPv4_Total_Length - IPv4_IHL * 4` this formula is incorrect in the presence of IPsec (ESH/AH) in transport mode or IPcomp.

### Section 8

`Option area bytes used for alignment before the OCS MUST be zero` What is the expected receiver behaviour when these octets are not zero ?

### Interaction with RFC 9298

I was expected some text about RFC 9298 "Proxying UDP in HTTP" as it may affect UDP options; i.e., at least some words about this RFC should appear in this document.

## Previous COMMENTS (for archiving only)

### Abstract

s/end of the IP length/end of the IP datagram length/ ?

### Section 3

s/IP header and an IP payload area/IP header, IP extension headers (if any), and an IP payload area/ ?

s/that all implementations are required to support/that all implementations MUS to support/ ?

About the SAFE options, should there already be some words about the middleboxes ?

### Section 4

To my non-English reader's eyes "Internet historians suggest a number of reasons why UDP includes this field" would read easier than `There are a number of reasons why Internet historians suggest that UDP includes this field`

Wow Teredo is still worth referring to... (ignore this comment of course)

### Section 5

I was about to ballot a DISCUSS on this text
```
  They
  enable capabilities available in other transport protocols, such as
  fragmentation and reassembly, that enable UDP frames larger than the
  IP MTU to traverse devices that rely on transport ports, e.g., NATs.
```

As both TCP & UDP messages can be fragmented by IPv6/IPv4 layer in several IPv6/IPv4 fragments without the need of anything at layer-4. Of course, this requires stateful NAT/NAT64 devices to handle this correctly.

So, either the text is unclear (i.e., I misread it) or is plain wrong. This sentence *SHOULD* really be rewritten, e.g., by including "stateless middleboxes".

Should there be a reference for `UDP was originally intended to assume such capabilities` ?

### Section 9

What are `errant middleboxes` ?

### Section 10

Is there any reason why the field is "Kind" rather than the usual "Type" as in TLV?

Even if obvious, please state the unit of the Length field.

Suggest adding some leading text between figure 6 and the indented specification paragraphs.

s/Option lengths MUST NOT exceed the IP length /The sum of all option lengths MUST NOT exceed the IP length / ?

### Section 11.1

`Bytes after EOL in the surplus area or the options area of a UDP fragment MAY be checked as being zero on receipt, ` should this rather be a MUST to avoid the side channel? I.e., the receiver will be made aware of something wrong happening.

### Section 11.3

Should there be informal reference to `including iSCSI` ?

`UDP packets with incorrect APC checksums SHOULD be passed to the application, e.g., with a flag indicating APC failure` unsure whether 'e.g.,' is safe here, mandating an CRC violation signal to the application seems mandatory to me.

### Section 11.4

This is probably the section that is the most contentious from my view... Fragmentation is done in layer-3 usually (for the better or the worse) so having *TWO* fragmentation layers seems useless (beside stateless NAT), redundant, and possibly having side effects related to path MTU discovery.


Notably, because TCP and its options do not have a similar mechanism and nobody has every complained (I can be wrong though).
At the bare minimum, add "stateless NAT" in
```
  FRAG includes
  a copy of the same UDP transport ports in each fragment, enabling
  them to traverse Network Address (and port) Translation (NAT)
  devices, in contrast to the behavior of IP fragments [RFC4787].
```

Is there any implementation of HW acceleration as in
```
  When present, placing FRAG first can simplify some implementations,
  notably those using hardware acceleration that assume a fixed
  location for the FRAG option.
```
?

### Sections 11.5 and 11.6

Should there be some text about the usefulness of these options in the case of a unidirectional UDP flow ?

### Section 11.8

No need to reply, but this section seems to be an attempt to have a TCP-like transport above UDP. Anyway, it does not hurt...


### Section 18

A blast from the past `Windows Cygwin` ;-) (no need to reply)


## NITS (non-blocking / cosmetic)

### Use of SVG graphics

To make a much nicer HTML rendering, suggest using the aasvg too to generate SVG graphics. It is worth a try especially when using Markdown format ;-)

[Ballot discuss]

# Éric Vyncke, INT AD, comments for draft-ietf-tsvwg-udp-options-42
CC @evyncke

Thank you for the work put into this document. I do not often review a -42 revision of a document started in 2015 ;-) it is also the first RFC to update RFC 768 :-O

Even if I am balloting a DISCUSS, this idea behind this I-D is simple and brilliant.

Please find below some blocking DISCUSS points (easy to address), some non-blocking COMMENT points (but replies would be appreciated even if only for my own education), and one nit.

Special thanks to Gorry Fairhurst for the shepherd's detailed write-up including the WG consensus and the justification of the intended status.

Other thanks to Antoine Fressancourt, the Internet directorate reviewer (at my request), please consider this int-dir review:
https://datatracker.ietf.org/doc/review-ietf-tsvwg-udp-options-38-intdir-telechat-fressancourt-2025-02-27/ (and I have read Mike's reply)

Other thanks to David Blacka, the DNS directorate reviewer, please consider this dns-dir review:
https://datatracker.ietf.org/doc/review-ietf-tsvwg-udp-options-40-dnsdir-telechat-blacka-2025-02-27/ (and I have read Joe's reply)

I hope that this review helps to improve the document,

Regards,

-éric


## DISCUSS (blocking)

As noted in https://www.ietf.org/blog/handling-iesg-ballot-positions/, a DISCUSS ballot is just a request to have a discussion on the following topics:

### Section 7

`UDP_Length = IPv4_Total_Length - IPv4_IHL * 4` this formula is incorrect in the presence of IPsec (ESH/AH) in transport mode or IPcomp.

### Section 8

`Option area bytes used for alignment before the OCS MUST be zero` What is the expected receiver behaviour when these octets are not zero ?

### Interaction with RFC 9298

I was expected some text about RFC 9298 "Proxying UDP in HTTP" as it may affect UDP options; i.e., at least some words about this RFC should appear in this document.

[Ballot comment]

## COMMENTS (non-blocking)

### Abstract

s/end of the IP length/end of the IP datagram length/ ?

### Section 3

s/IP header and an IP payload area/IP header, IP extension headers (if any), and an IP payload area/ ?

s/that all implementations are required to support/that all implementations MUS to support/ ?

About the SAFE options, should there already be some words about the middleboxes ?

### Section 4

To my non-English reader's eyes "Internet historians suggest a number of reasons why UDP includes this field" would read easier than `There are a number of reasons why Internet historians suggest that UDP includes this field`

Wow Teredo is still worth referring to... (ignore this comment of course)

### Section 5

I was about to ballot a DISCUSS on this text
```
  They
  enable capabilities available in other transport protocols, such as
  fragmentation and reassembly, that enable UDP frames larger than the
  IP MTU to traverse devices that rely on transport ports, e.g., NATs.
```

As both TCP & UDP messages can be fragmented by IPv6/IPv4 layer in several IPv6/IPv4 fragments without the need of anything at layer-4. Of course, this requires stateful NAT/NAT64 devices to handle this correctly.

So, either the text is unclear (i.e., I misread it) or is plain wrong. This sentence *SHOULD* really be rewritten, e.g., by including "stateless middleboxes".

Should there be a reference for `UDP was originally intended to assume such capabilities` ?

### Section 9

What are `errant middleboxes` ?

### Section 10

Is there any reason why the field is "Kind" rather than the usual "Type" as in TLV?

Even if obvious, please state the unit of the Length field.

Suggest adding some leading text between figure 6 and the indented specification paragraphs.

s/Option lengths MUST NOT exceed the IP length /The sum of all option lengths MUST NOT exceed the IP length / ?

### Section 11.1

`Bytes after EOL in the surplus area or the options area of a UDP fragment MAY be checked as being zero on receipt, ` should this rather be a MUST to avoid the side channel? I.e., the receiver will be made aware of something wrong happening.

### Section 11.3

Should there be informal reference to `including iSCSI` ?

`UDP packets with incorrect APC checksums SHOULD be passed to the application, e.g., with a flag indicating APC failure` unsure whether 'e.g.,' is safe here, mandating an CRC violation signal to the application seems mandatory to me.

### Section 11.4

This is probably the section that is the most contentious from my view... Fragmentation is done in layer-3 usually (for the better or the worse) so having *TWO* fragmentation layers seems useless (beside stateless NAT), redundant, and possibly having side effects related to path MTU discovery.


Notably, because TCP and its options do not have a similar mechanism and nobody has every complained (I can be wrong though).
At the bare minimum, add "stateless NAT" in
```
  FRAG includes
  a copy of the same UDP transport ports in each fragment, enabling
  them to traverse Network Address (and port) Translation (NAT)
  devices, in contrast to the behavior of IP fragments [RFC4787].
```

Is there any implementation of HW acceleration as in
```
  When present, placing FRAG first can simplify some implementations,
  notably those using hardware acceleration that assume a fixed
  location for the FRAG option.
```
?

### Sections 11.5 and 11.6

Should there be some text about the usefulness of these options in the case of a unidirectional UDP flow ?

### Section 11.8

No need to reply, but this section seems to be an attempt to have a TCP-like transport above UDP. Anyway, it does not hurt...


### Section 18

A blast from the past `Windows Cygwin` ;-) (no need to reply)


## NITS (non-blocking / cosmetic)

### Use of SVG graphics

To make a much nicer HTML rendering, suggest using the aasvg too to generate SVG graphics. It is worth a try especially when using Markdown format ;-)

Closed request for Telechat review by DNSDIR with state 'Team Will not Review Version': giving the review team just 2 days to review a 50 page document is insane - the answer is NO!

[Ballot discuss]
Thanks for this document. I found it interesting and for the most part, solidly written. I have a few comments about spots I found rough, and one discuss point.

## DISCUSS

### Section 11.8, TIME isn't time

I was bamboozled by this section until I followed the breadcrumb you kindly left pointing to RFC 7323, and learned that 7323 defines the clock "without any connection to time" (I am not making this up, it's RFC 7323 Section 5.4). Ergo, TIME has no connection to time. What a world.

I assume you are inheriting this definition; with that assumption, this section makes sense, without it, it doesn't. If that's what you are doing, I think you have to either provide the necessary definitions here, or (probably better) reference RFC 7232 normatively and state what definition(s) you're inheriting, instead of casually saying "serves a similar purpose".

(I appreciate that to people who live in this world, this was probably too obvious to bother writing down. I'm here to remind you that to the casual punter, it's not obvious.)

[Ballot comment]
## COMMENT

### Section 10, isn't this part of the base spec?

This section is about UDP Options, but includes the paragraph,

  >> The UDP length MUST be at least as large as the UDP header (8)
  and no larger than the IP transport payload. Datagrams with length
  values outside this range MUST be silently dropped as invalid and
  logged.

Isn't that a requirement of the base UDP transport and independent of options? Why is it specified here?

### Section 10, language about lengths is muddled

I have a few problems understanding this paragraph:

  >> Receivers supporting UDP options MUST silently ignore unknown
  SAFE options (i.e., in the same way a legacy receiver would ignore
  all UDP options). That includes options whose length does not
  indicate the specified value(s), as long as the length is not
  inherently invalid (i.e., smaller than 2 for the default and 4 for
  the extended formats). Note: a FRAG option with an unknown length
  field SHALL be treated as an unsupported UNSAFE option.

First, what does "whose length does not indicate the specified value(s)" mean? Specifically, what do you mean by "indicate", how does a length "indicate" a value? My best guess is that you mean for a given type code (oh sorry, "kind"), there will be some specified structure, for which only certain lengths might apply, e.g. 10 and 12 for FRAG. Do you mean that, again using FRAG as our example, a length of 11 wouldn't "indicate" something-or-other? (I devolve to "something-or-other" because I realized I also don't know what you mean by "the specified values" -- I guess maybe "the specified values" would be 10 and 12.)

If that's what you mean, I think a less opaque way to say it would be something like, "... options whose length is inconsistent with the values permitted by the specification of that option".

Later, we have "a FRAG option with an unknown length field". What does it even *mean* for the length *field* to be "unknown"? My best guess is you mean something like "a FRAG option whose length is inconsistent with the values permitted by this specification, see Section 11.4".

### Section 10, is this just a roundabout way of saying "drop it"?

  >> Receivers supporting UDP options that receive unsupported options
  in the UNSAFE range MUST terminate all option processing and MUST
  silently drop all UDP options in that datagram. See Section 12 for
  further discussion of UNSAFE options.

OK, we are just dropping the options. But in the previous paragraph, you told me that any UNSAFE option implies there is no user data in the normal place:

  >> When UNSAFE options are present, the UDP user data MUST be empty,
  and any transport payload MUST be contained in a FRAG option (see

When I put these two things together, what I come away with is that if I get an UNSAFE option I will deliver no data to the user. This seems like a bit of a roundabout way to tell me that. Maybe it's important to use these phrasings, but even if so, it would be nice to mention to the casual reader what the implication is.

### Section 10, wut

This made my brain hurt:

                                                This does not prohibit
  future uses of the entire surplus area; space that would have
  occurred after the EOL can be used as a UDP option instead, i.e.,
  rather than using the EOL option and trying to define meaning beyond
  it, define a new option that uses the remaining surplus area as an
  option itself, in conjunction with an assigned UDP option codepoint
  and length to unambiguously indicate the meaning of that area. This
  also does not prohibit options that modify later options (in order
  of appearance within a packet), such as would typically be the case
  for compression (UCMP).

After I read it a few times, I decided (a) I kind of halfway get what you're saying, but only halfway, (b) it's non-normative anyway, just some notes toward possible extensions so it's not worth giving myself a migraine over.

Anyway, be aware that to at least this reader, the quoted text doesn't do an effective job of communicating. I'm sorry I can't suggest a rewrite.

### Section 10, "impossible"

  >> Impossible lengths SHOULD be treated as an indication of a
  malformed surplus area and all options SHOULD silently be discarded.
  This includes lengths that imply a physical impossibility, e.g.,
  smaller than two for conventional options and four for extended
  length options. Lengths other than those expected result in safe
  options being ignored and skipped over, as with any other unknown
  safe option.

First you mention "impossible lengths", which is interestingly vague.

Then you say these impossible lengths include (which implies "but not limited to") underruns. I guess the other impossible length would be an overrun (but then you specify that as a separate case, see later comment). Are there any other categories you'd lump under "impossible"? Is it... possible... to use more precise language than "impossible" here?

I guess the final sentence excludes lengths that are inconsistent with the type code^H^H^H^H kind's specification as being "impossible", these are treated by ignoring them, not giving up completely. Isn't this sentence redundant with (though clearer than!) the paragraph I complained about above? ("language about lengths is muddled")

### Section 10, is this also "impossible"?

  >> Option lengths MUST NOT exceed the IP length of the overall IP
  datagram. A receiver MUST drop all options in such a malformed
  packet and the event MAY be logged for diagnostics.

Either this falls under the "impossible" umbrella I just complained about and is redundant, or I misunderstand "impossible" even worse than I feared.

### Section 11.4, partially reassembled

                                                              UDP
  options that apply to the reassembled datagram are contained in the
  partially reassembled surplus area, as indicated by RDOS.
 
What's "partially reassembled" mean? I would have thought this should say something like,

  UDP options that apply to the reassembled datagram are contained in
  the surplus area of the reassembled datagram, as indicated by RDOS.
 
which is a bit of an unlovely sentence (too much "reassembled datagram") but anyway, I can make sense of it and I think it says what I understand you to mean.

### Section 11.4, I don't get it

I don't understand this:

  >> Users MAY also select the FRAG option to provide limited support
  for UDP options in systems that have access to only the initial
  portion of the data in incoming or outgoing packets
 
Can't make head or tail of it. Sorry. :-(

### Section 11.5, known path MTU

  >> MDS does not indicate a known path MTU and thus MUST NOT be used
  to limit transmissions.

That sounds wrong to me. Surely it represents an upper bound on the PMTU and thus is of some use in limiting transmissions?

## NITS

### Section 25.1

I suggest,

OLD
  Note that any user application that considers UDP options to affect

NEW
  Note that any user application that considers UDP options to adversely
  affect

[Ballot comment]
Thanks to Paul Wouters for their secdir review (circa 2023)!!!

I found this draft to be easy to read.  Thanks to the authors and working group for that effort.

[Ballot comment]
I too enjoyed reading the document and the design to address any issues the addition of the header may cause in existing deployment.

Section 24, paragraph 0
> 24. Network Management Considerations
>    IP Flow Information Export Information Elements for UDP options have
>    been defined in [Bo24].

Thank you for adding a section on management considerations. From a monitoring perspective, I can imagine that if someone wanted to write a YANG model, they could look at what is being exported via IPFIX.

Does it mean there is no configuration required to enable/disable this feature? If so, a statement to that effect would provide clarity.

-------------------------------------------------------------------------------
NIT
-------------------------------------------------------------------------------

All comments below are about very minor potential issues that you may choose to
address in some way - or ignore - as you see fit. Some were flagged by
automated tools (via https://github.com/larseggert/ietf-reviewtool), so there
will likely be some false positives. There is no need to let me know what you
did with these suggestions.

Section 6, paragraph 1
> hat of the UDP packet itself. Past experience confirms that static length li
>                              ^^^^^^^^^^^^^^^
Consider using "experience".

Section 8, paragraph 4
>  the surplus area from errors in a similar way that the UDP checksum protect
>                              ^^^^^^^^^^^^^^^^
Consider replacing this phrase with the adverb "similarly" to avoid wordiness.

Section 10, paragraph 18
> gram. If an option other than these four occurs more than once, a receiver MU
>                              ^^^^^^^^^^^^^^^^^
The verb "occurs" is singular. Did you mean: "these four occur"?

Section 10, paragraph 33
>  used as padding, e.g., to align multi-byte options along 16-bit, 32-bit, or
>                                  ^^^^^^^^^^
This word is normally spelled as one.

Section 11.4, paragraph 51
> ed per-fragment, the reported value is be the minimum of the MRDS values rece
>                                    ^^^^^
Consider using either the present participle "is being" here.

Section 11.4, paragraph 52
> ons provides UDP packet-level acknowledgements as a capability for use by up
>                              ^^^^^^^^^^^^^^^^
Do not mix variants of the same word ("acknowledgement" and "acknowledgment")
within a single text.

Section 11.6, paragraph 1
>  Echo Reply (TSecr) are used in a similar manner to the TCP TS option [RFC732
>                              ^^^^^^^^^^^^^^^^^^^
Consider replacing this phrase with the adverb

Section 11.7, paragraph 2
> uting the check), the latter in a similar manner as per TCP-AO NAT traversal
>                              ^^^^^^^^^^^^^^^^^^^
Consider replacing this phrase with the adverb "similarly" to avoid wordiness.

Section 11.8, paragraph 14
> r, in sequence) UDP options, in a similar manner as TCP-AO-ENC [To18]. 12.3.
>                              ^^^^^^^^^^^^^^^^^^^
Consider replacing this phrase with the adverb "similarly" to avoid wordiness.

Section 25.2, paragraph 2
>  ExIDs) are intended for use in a similar manner as TCP ExIDs [RFC6994]. Both
>                              ^^^^^^^^^^^^^^^^^^^
Consider replacing this phrase with the adverb "similarly" to avoid wordiness.

Section 27.1, paragraph 6
> bugging purposes, and is not intended be enabled otherwise. System variables
>                                      ^^
It seems that "to" is missing before the verb.

[Ballot comment]
# Internet AD comments for draft-ietf-tsvwg-udp-options-39
CC @ekline

* comment syntax:
  - https://github.com/mnot/ietf-comments/blob/main/format.md

* "Handling Ballot Positions":
  - https://ietf.org/about/groups/iesg/statements/handling-ballot-positions/

## Comments

### Appendix A

* Out of curiosity, what happens (or is supposed to happen) if UDP_JUNK is
  enabled?

## Nits

### S6

* "A mechanism that requires bidirectionally" ->
  "A mechanism that requires bidirectionality"?

### S10

* "trying to defining meaning" ->
  "trying to define meaning"

### S11.3

* "embedded ports numbers" ->
  "embedded port numbers"

### S11.4

* "no larger no larger" ->
  "no larger"

### S11.7

* "in which case and REQ/RES" ->
  "in which case REQ/RES"

[Ballot discuss]
Question from IANA -->

==[ snip ]==
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.

Is this registry to remain in place, or is the registry to be moved to the new registry group created by the first action?
==[ snip ]==

[Ballot comment]
Thank you to Robert Sparks for the GENART review.

** Section 26.
  Initial values of the UDP Option Kind registry are as listed in
  Section 10, including those both assigned and reserved.

-- Should the table in Section 10 being converted into this new “UDP Option Kind” registry also have a reference column?  Otherwise, how would one know where to look for newly registered options?

** Section 26.
  >> Although option nicknames are not used in-band, new UNSAFE option
  names SHOULD commence with the capital letter "U" and avoid either
  uppercase or lowercase "U" as commencing safe options.

When is it ok to violate this naming convention as it isn’t mandatory.

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

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/

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.

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/

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/

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/

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.

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.

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.