Traversal Using Relays around NAT (TURN): Relay Extensions to Session Traversal Utilities for NAT (STUN)
RFC 5766

Note: This ballot was opened for revision 16 and is now closed.

Magnus Westerlund Yes

(Ron Bonica) No Objection

Comment (2009-04-07 for -)
No email
send info
supporting Lars' and Russ's DISCUSSES

(Ross Callon) No Objection

(Lisa Dusseault) No Objection

(Lars Eggert) (was Discuss) No Objection

(Pasi Eronen) No Objection

(Adrian Farrel) No Objection

Comment (2009-04-02 for -)
No email
send info
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.)

(Russ Housley) (was Discuss) No Objection

(Cullen Jennings) (was Discuss) No Objection

Comment (2009-06-24)
No email
send info
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?

(Alexey Melnikov) No Objection

Comment (2009-04-09 for -)
No email
send info
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.

(Tim Polk) (was No Record, Discuss) No Objection

Comment (2009-04-07)
No email
send info
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/

(Robert Sparks) (was Discuss) No Objection

Comment (2009-04-14)
No email
send info
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.