Transport Features of the User Datagram Protocol (UDP) and Lightweight UDP (UDP-Lite)
draft-ietf-taps-transports-usage-udp-07

- 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

Question: Given this is pass 1 (describing the (abstract) API as defined in the spec), why is there a LISTEN for UDP?

* 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.