Traversal Using Relays around NAT (TURN) Resolution Mechanism
Note: This ballot was opened for revision 10 and is now closed.
(Cullen Jennings) Discuss
Discuss (2010-02-25 for -** No value found for 'p.get_dochistory.rev' **)
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) Yes
Magnus Westerlund Yes
(Jari Arkko) No Objection
(Ron Bonica) No Objection
(Ross Callon) No Objection
(Gonzalo Camarillo) (was Discuss) No Objection
(Ralph Droms) No Objection
(Lisa Dusseault) No Objection
(Lars Eggert) No Objection
(Pasi Eronen) (was Discuss) No Objection
(Adrian Farrel) No Objection
(Russ Housley) No Objection
Alexey Melnikov No Objection
Comment (2010-01-16 for -** No value found for 'p.get_dochistory.rev' **)
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.