Hello Behave Folks,

As a member of the Operations Directorate, I was asked to review
draft-ietf-behave-turn-uri-03.txt.

I have some operational concerns with this document that should probably
be resolved before the document is published.  I apologize in advance
if my comments reflect a lack of knowledge of this subject.

In section 4, there is a numbered list of ways in which the TURN
resolution may be processed, and this appears to be the core of the
document.  I have spent a considerable amount of time trying to figure
out what this list says, and I have not been completely successful.
My current understanding is as follows:

(1.) If the <host> is an IP address, the other fields are filled in as
     follows:

    - <port> is set to the value in the URI if present, or to the
      default in draft-ietf-behave-turn.
    - If <transport> is defined:
          > <scheme> and <transport> are converted to a TURN transport.
    - If <transport> is not defined:
          > The supported transports are tried in order of
            preference.

If <host> is a Domain Name, the fields are filled in as follows:

(2.)- If <port> is defined:
          > <host> is resolved to a list of IP addresses via DNS.
          > If <transport> is defined:
	      >> <scheme> and <transport> are converted to a TURN
                 transport
	  > If <transport> is not defined:
	      >> The supported transports are tried in order of
	      	 preference.

     - If <port> is not defined:
(3.)      > If <transport> is defined:
	       >> <host> is converted to list of IP address
                  and port tuples via a DNS SRV query, with
		  <scheme> as the service name and <transport>
		  as the protocol name.

           [There is some wording here about the fact that the
           SRV algorith recommends doing an A query, but it
           doesn't actually say to do one, and the text above
           this already indicates that you would have reached
           the TURN server or returned an error.]

(4.)       > If <transport> is not defined:
	       >> <host> is convered to an ordered list of
                  IP Address, port and and transport tuples
                  via the S-NAPTR algorithm.
               >> The TURN transports supported by the
                  application are then converted into
                  Application Protocol Tags, and the protocol
                  tags are "tried" in some order.

                  [It is not clear, to me, what it means to
                  "try" a protocol tag.  Also, we seem to
                  using all of the tags supported by the
                  application, not anything returned from
                  the S-NAPTR algorithm?]

                  [Again, we have the problem that there is
                  text after the previous text has either
                  succeeded or returned an error.  In this
                  case, it says that the <host> is converted
                  to a list of IP Address and Port tuples
                  using the algorithm in section 3 "for each
                  of the TURN transports supported by the
                  application".  It is not clear to me what
                  this means, exactly.]

In addition to not being able to decipher exactly what steps
should be performed, I am somewhat concerned about what I
consider to be an artificial distinction between domain names
and IP addresses.  Is it actually the case that you cannot
use the S-NAPTR algorithm and/or look up SRV records using an
IP address instead of a Domain Name?  I am somewhat concerned
about the impacts of this choice on management and debugging,
although I am not sure if the problem lies in this document
or in the S-NAPTR and SRV documents.

I also have a couple of suggestions that might make the URI scheme
more straightforward for operators and users:

(1) Why is it desirable to overload the transport name "tcp" in the
    URI scheme to mean TCP for TURN and TLS for TURNS, when similar
    overloading is not present in the NAPTR definition?  Is there some
    advantage to doing so that offsets the potential for confusion?

(2) At various places in this document, decision trees are represented
    as numbered or bulleted lists, instead of laying out the choices
    at each layer.  While I think that the lists are logically
    consistent and represent all of the choices, this format does not
    make it easy to tell.

(3) It would be better to include a more complete range of examples
    showing all of the different permutations.

Margaret