Mike-Heard
commented
7 months ago I think that the idea of a framework, not a protocol, actually works well for the options that are fully defined in the proposed base specification. See https://datatracker.ietf.org/doc/html/draft-heard-dnsop-udp-opt-large-dns-responses for how FRAG and MRDS would be employed as building blocks to support large DNS messages, without precluding other use patterns. And of course https://datatracker.ietf.org/doc/html/draft-ietf-tsvwg-udp-options-dplpmtud defines how to use REQ/RES and padding to achieve its ends, without necessarily precluding other uses of these capabilities. It is true that future options, not defined in the base specification, may need to have the option format and usage defined in the same extension specification.
gorryfair
jtouch
"UDP options provide a soft control plane to UDP."
I'm not sure what this means. Isn't UDP Options a data plane protocol?
"Past experience confirms that static length limits will always need to be exceeded. Each implementation can limit how long/many options there are, but the specification should not introduce such a limit."
If each implementation can set arbitrary limits that makes interoperability really difficult. One application might accept 100 options, another might only accept one and the sender doesn't know. This is a common problem with stateless options. I suggest to at least referencing draft-ietf-6man-eh-limits as an example for providing useful guidance to limit stateless options (but not mandating static limits)
"UDP options are a framework, not a protocol."
I don't think this is true. The draft describes packet formats, sender and receiver normative requirements for handling UDP options. Pretty much by any definition, UDP options is a protocol. I think the point of this principle is that UDP options are an extensible protocol where we don't define all possible extensions up front.
"Examples herein include REQ/RES and TIME; in both cases, the option format is defined, but the protocol that uses these is specified elsewhere (REQ/RES for DPLPMTUD [Fa24]) or left undefined (TIME)."
Why not just define the option format with the specification of the option? The potential problem I see is that the format specified here might not be the final format when someone looks deep into all the requirements. I would recommend removing any option formats and type assignments that aren't fully specified in this draft-- they can be specified in other docs.
"Options that do not modify user data should (by default) result in the user data also being passed, even if, e.g., option checksums or authentication fails."
As mentioned above, I disagree with this as a default behavior. If networking stacks knows that a packet is corrupted (CRC failed) or authentication failed (Auth failed) the behavior should be to drop the packet-- that is how nearly all other protocols behave.
(Added by GF during WGLC)