Skip to main content

Traversal Using Relays around NAT (TURN) Resolution Mechanism
draft-ietf-behave-turn-uri-10

Discuss


Yes

(David Harrington)
(Magnus Westerlund)

No Objection

(Adrian Farrel)
(Dan Romascanu)
(Gonzalo Camarillo)
(Jari Arkko)
(Lars Eggert)
(Lisa Dusseault)
(Pasi Eronen)
(Ralph Droms)
(Robert Sparks)
(Ron Bonica)
(Ross Callon)
(Russ Housley)
(Tim Polk)

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

Cullen Jennings Former IESG member
Discuss
Discuss [Treat as non-blocking comment] (2010-02-25) Unknown
I discussed this with Magnus today and I think we both came to about the same conclusion. 

In the say way that _turn._udp needs a normative ref to TURN, the _turn._tcp needs a normative ref to TURN-TCP as that defines the protocol that this service will provide. 

On the topic of DNS resolution, TURN defines one way, this draft defines a different way. Having two ways is not a good thing and will lead to interoperability problems. The WG has consensus to do it one way or the other not both. If we want to do it this way, TURN should be yanked out of RFC Ed Q and changed. If not, this doc should do it the way TURN does. I do not understand any significant advantages of using the way over the way in TURN.
David Harrington Former IESG member
Yes
Yes () Unknown

                            
Magnus Westerlund Former IESG member
Yes
Yes () Unknown

                            
Adrian Farrel Former IESG member
No Objection
No Objection () Unknown

                            
Alexey Melnikov Former IESG member
No Objection
No Objection (2010-01-16) Unknown
The first mentioning of TLS probably needs an Informative reference to TLS 1.2. Its use in Section 5 probably means that the reference is Normative.

In Section 3:
   After verifying the validity of the URI elements, the algorithm
   filters the list of TURN transports supported by the application by
   removing the UDP and TCP TURN transport if <secure> is true.

Firstly, URI needs an Informative reference. Secondly, this is the first time that the term URI is mentioned, so it is not entirely clear what you mean here (Ok, I can guess, but the point still stands.)

The following Normative reference is no longer used:

   [RFC5234]  Crocker, D. and P. Overell, "Augmented BNF for Syntax
              Specifications: ABNF", STD 68, RFC 5234, January 2008.

The following Informative reference is not used as well:

   [RFC4395]  Hansen, T., Hardie, T., and L. Masinter, "Guidelines and
              Registration Procedures for New URI Schemes", BCP 35,
              RFC 4395, February 2006.
Dan Romascanu Former IESG member
No Objection
No Objection () Unknown

                            
Gonzalo Camarillo Former IESG member
(was Discuss) No Objection
No Objection () Unknown

                            
Jari Arkko Former IESG member
No Objection
No Objection () Unknown

                            
Lars Eggert Former IESG member
No Objection
No Objection () Unknown

                            
Lisa Dusseault Former IESG member
No Objection
No Objection () Unknown

                            
Pasi Eronen Former IESG member
(was Discuss) No Objection
No Objection () Unknown

                            
Ralph Droms Former IESG member
No Objection
No Objection () Unknown

                            
Robert Sparks Former IESG member
No Objection
No Objection () Unknown

                            
Ron Bonica Former IESG member
No Objection
No Objection () Unknown

                            
Ross Callon Former IESG member
No Objection
No Objection () Unknown

                            
Russ Housley Former IESG member
No Objection
No Objection () Unknown

                            
Tim Polk Former IESG member
(was No Record, Discuss) No Objection
No Objection () Unknown