Traversal Using Relays around NAT (TURN): Relay Extensions to Session Traversal Utilities for NAT (STUN)
draft-ietf-behave-turn-16

I understand that other-then-UDP mechanisms for server-peer communications will follow, but I find it confusing that the Introduction discusses client-server TCP and TLS services since the client is presumably actually interested in client-peer delivery. Also that Figure 1 shows a peer behind a NAT and the text comments that some firewalls block UDP entirely.

Would it be helpful to draw out more clearly what deployments and service functions are not possible with the UDP-only variety of TURN? (There is some discussion in section 2.4 of the security of the server-peer data being the protected through encryption or similar.)

In Section 6.2:

   5.  The server checks if the request contains an EVEN-PORT attribute.
       If yes, then the server checks that it satisfy the request.

Missing word: ... that it *can* satisfy ...

I am also agreeing with Russ' DISCUSS.

Seems weird that we can negotiate lifetimes of allocations but not permissions or channels bindings. Why?

Padding up the Channel Data messages over TCP is a waste of bandwidth - why is it needed?

There are several invariant times called out in this document without motivation (default lifetimes MUST be 300 seconds, clients SHOULD wait at least one minute before doing some things and MUST wait 5 minutes before doing others). It would be nice to let the implementors know, if possible, why these values were chosen.

The text in the NOTE on page 25 will not age well after this is published as an RFC

(Comment to version -14): I think it's likely that a client implementer will miss noticing that the client needs to set a separate timer for refreshing the permission and the channelbind when a channelbind request succeeds. You could help avoid some interop problems by explicitly calling this out in the "processing channelbind responses" section.

supporting Lars' and Russ's DISCUSSES

section 2, next-to-last paragraph
s/to application data/to send application data/

section 2.4, para 3:
s/an XOR-PEER-ADDRESS attribute specify/an XOR-PEER-ADDRESS attribute specifying/