Subject: [tram] TURN server auto-discovery

From: "Olle E. Johansson" <[email-masked]>
Date: Wed, 27 Jul 2016 10:15:46 +0200

Sorry for being late into reviewing this document. If I am too late, my apologies,
but nevertheless here’s a few nits and comments:

https://tools.ietf.org/html/draft-ietf-tram-turn-server-discovery-08

Section 1:
- “Web Real-Time Communication (WebRTC)
   [I-D.ietf-rtcweb-overview] usages and related extensions, which are
   mostly based on web applications, need this immediately.”
When I read this in ten years time, it is no longer immediately. Please rephrase.

- “This document describes three discovery mechanisms, so as to maximize
   opportunity for discovery, based on the network in which the TURN
   client finds itself.  “ 
 A very complicated sentence. Can it be simplified to make reading easier?

- “For example, in case of Web Real-Time Communication
   (WebRTC) [I-D.ietf-rtcweb-overview] usages and related extensions,
   which are based on web applications, a Java Script specified TURN
   server MUST be considered as local configuration. “
I think “local” is a bad choice here - maybe “application-provided configuration”
could be an improvement?

- “A client can choose auto-discovery in the absence of local
configuration, if local configuration doesn't work or on top of local
   configuration. “
I think local security policy may affect choice and maybe also need to override
“local configuration” 

- “An implementation
   MAY give the user an opportunity (e.g., by means of configuration
   file options or menu items) to specify a TURN server for each address
   family.”
How do you define the implementation? The browser, the javascript application
or another TURN user, like a SIP phone? In the case of WebRTC you need
to clarify your terminology - there’s one application running in javascript and
then you have the browser. Also remember that TURN is not only about
browsers :-)

- “A TURN client that implements the auto discovery algorithm, to
   discover TURN servers in the attached network, uses the following
   mechanisms for discovery:”
Change the list that follows to use bullets, as you later write that you do not
prescribe a strict order.

Section 4.1:
This section is a bit open. If I want to write a SIP specific document
specifying a way to use the outbound proxy URI or a service route URI
to use for TURN service discovery - will that be a standalone document
or an update to this document. Maybe some requirements on other
ways to select a domain name would be appropriate.

Section 4.1.2:
- “JID   : [email-masked]’”
You have a SIP URI and a bare JID. Maybe consider making it an XMPP URI 
by prefixing the JID with “XMPP:” for clarity.

Section 5:
- “For example, TURN server advertises the following DNS records :”
s/TURN/a TURN/

Section 9:
- “Use of STUN authentication is OPTIONAL for TURN servers provided by
   the local network or by the access network.  A network provided TURN
   server MAY be configured to accept Allocation requests without STUN
   authentication, and a TURN client MAY be configured to accept
   Allocation success responses without STUN authentication from a
   network provided TURN server.  “
Is this text normative? If so it’s clearly out of scope for a draft on auto-discovery.
You also need to add text on DNSsec here.

A lot of this text is good, but I have issues with it being in this draft. Does
this text normatively update another document? It covers how to set up
connections more than how to discover services. Maybe how to trust
the TURN server should be another draft or, if it needs to be in this draft, 
should be made in a separate section. If that is the case, the abstract
and introduction section  needs to be modified to cover this scope too.

/O