Skip to main content

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

Yes

(Magnus Westerlund)

No Objection

Lars Eggert
(Lisa Dusseault)
(Pasi Eronen)
(Ross Callon)
(Russ Housley)

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

Lars Eggert
(was Discuss) No Objection
Magnus Westerlund Former IESG member
Yes
Yes ()

                            
Adrian Farrel Former IESG member
No Objection
No Objection (2009-04-02)
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.)
Alexey Melnikov Former IESG member
No Objection
No Objection (2009-04-09)
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.
Cullen Jennings Former IESG member
(was Discuss) No Objection
No Objection (2009-06-24)
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?
Lisa Dusseault Former IESG member
No Objection
No Objection ()

                            
Pasi Eronen Former IESG member
No Objection
No Objection ()

                            
Robert Sparks Former IESG member
(was Discuss) No Objection
No Objection (2009-04-14)
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.
Ron Bonica Former IESG member
No Objection
No Objection (2009-04-07)
supporting Lars' and Russ's DISCUSSES
Ross Callon Former IESG member
No Objection
No Objection ()

                            
Russ Housley Former IESG member
(was Discuss) No Objection
No Objection ()

                            
Tim Polk Former IESG member
(was No Record, Discuss) No Objection
No Objection (2009-04-07)
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/