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

# 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"

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 ;-)