Traversal Using Relays around NAT (TURN) Resolution Mechanism
draft-ietf-behave-turn-uri-10
Discuss
Yes
(David Harrington)
(Magnus Westerlund)
No Objection
Lars Eggert
(Adrian Farrel)
(Dan Romascanu)
(Gonzalo Camarillo)
(Jari Arkko)
(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.
Lars Eggert
No Objection
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
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