Re: [tsvwg] UDP Options API document

["C. M. Heard" <[e-mail]>]

On Fri, Sep 3, 2021 at 10:35 AM Tom Jones wrote:

> It was raised today during the interim (I think by Carsten) that a clear
> API description is very important for real world adoption of a protocol.
> Michael Tuexen added that during the original SCTP standardisation a
> separate API draft made writing portable applications much easier.
>
> Let me start the discussion, should we provide a separate draft for UDP
> Options API or should this work happen inside the UDP Options draft?
>

I would like to see thorough and clear documentation in the base
specification of the ***services*** that are provided by UDP options.to the
application layer (or the higher layer protocol running on top of UDP).


On Sat, Sep 4, 2021 at 9:35 AM Joe Touch replied:

> As I mentioned during the meeting, there’s already an abstract API in the
> spirit of TCP's in section 8 of the draft, with a real-world example in
> Appendix A based on a preliminary implementation.
>
> It’s been there since draft-touch-tsvwg-udp-options-06, dated March 27,
> 2017.
>
> I don’t recall anyone commenting on that yet, though.
>

I took Tom's advice and read both RFC 8303 ("On the Usage of Transport
Features Provided by IETF Transport Protocols") and RFC 8304 ("Transport
Features of the User Datagram Protocol (UDP) and Lightweight UDP
(UDP-Lite)"). RFC 8303 (and RFC 8304) relied on existing, documented
application interface requirements and abstract APIs, and that Tom is
proposing to do something similar for UDP options, and asks whether we
should do that in the base spec or as a separate document. Note that RFC
8303, despite its title, deals substantively only with connection-oriented
transport protocols, and simply references RFC 8304 in its sections on
connectionless transport protocols.

I also heeded Joe's admonition to read the abstract API in the current
draft (I indeed have not paid attention to it or commented on it up to now).

My sense is that the existing abstract API is insufficient to serve as a
basis for something like an extended version of RFC 8304. But I also feel
that RFC 8304 somewhat misses the mark, since it does not adequately
distinguish what primitives should actually be per-datagram (i.e., figuring
as input parameters to send(), sendto(), or sendmsg() and output parameters
from recv(), recvfrom(), and recvmsg() or the like) versus what things
should be per-socket (and controlled by setsockopt() or the like).  I would
really like to see a complete laundry list written down, and I will take a
stab at it if I am asked.

Thanks,

Mike Heard