Summary: Has enough positions to pass.
- general: As I mentioned in my review of the general transport-usage draft, I think the two drafts should be combined. -2: "It uses common terminology defined in that document and also refers to the terminology of RFC 2119 [RFC2119], but does not itself define new terms." Why does this draft need to refer to 2119? It should not be using 2119 keywords outside of direct quotes. (If it does need to use 2119 keywords, please use the boilerplate from 2119 or 8174 .) -3.1, 2nd paragraph: "should be able to create receive, source, and destination ports and addresses (setting the source and destination ports and addresses)," Is there a missing word after "create"? - 3.1, last paragraph: "[RFC6935] and [RFC6936] defines an update..." s/defines/define
* Section 1 "The UDP and UDP-Lite sockets API differs from that for TCP in several key ways." I was expecting the document to at least briefly describe the differences following this. The socket option text that follows does not really fit the bill. e.g. SO_REUSEADDR applies to TCP as well as UDP.
Nits: 1: Section Introduction "o SO_REUSEADDR specifies the rules for validating addresses supplied to bind() should allow reuse of local addresses." This doesn't really parse -- perhaps "specifies that the rules" ? 2: Section 3.1. Primitives Provided by UDP "A bind operation sets the local port, either implicitly, triggered by a "sendto" operation on an unbound unconnected socket using an ephemeral port. Or by an explicit "bind" to use a configured or well-known port." The "Or by an explicit..." feels like a fragment.
Question: Given this is pass 1 (describing the (abstract) API as defined in the spec), why is there a LISTEN for UDP?