Traversal Using Relays around NAT (TURN) Resolution Mechanism
RFC 5928

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

Lars Eggert No Objection

(Cullen Jennings; former steering group member) Discuss

Discuss [Treat as non-blocking comment] (2010-02-25 for -)
No email
send info
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 steering group member) Yes

Yes ()
No email
send info

(Magnus Westerlund; former steering group member) Yes

Yes ( for -)
No email
send info

(Adrian Farrel; former steering group member) No Objection

No Objection ( for -)
No email
send info

(Alexey Melnikov; former steering group member) No Objection

No Objection (2010-01-16 for -)
No email
send info
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 steering group member) No Objection

No Objection ( for -)
No email
send info

(Gonzalo Camarillo; former steering group member) (was Discuss) No Objection

No Objection ()
No email
send info

(Jari Arkko; former steering group member) No Objection

No Objection ( for -)
No email
send info

(Lisa Dusseault; former steering group member) No Objection

No Objection ( for -)
No email
send info

(Pasi Eronen; former steering group member) (was Discuss) No Objection

No Objection ()
No email
send info

(Ralph Droms; former steering group member) No Objection

No Objection ( for -)
No email
send info

(Robert Sparks; former steering group member) No Objection

No Objection ( for -)
No email
send info

(Ron Bonica; former steering group member) No Objection

No Objection ( for -)
No email
send info

(Ross Callon; former steering group member) No Objection

No Objection ( for -)
No email
send info

(Russ Housley; former steering group member) No Objection

No Objection ( for -)
No email
send info

(Tim Polk; former steering group member) (was No Record, Discuss) No Objection

No Objection ( for -)
No email
send info