Re: [BEHAVE] Opsdir Review of draft-ietf-behave-turn-uri-03.txt

[Marc Petit-Huguenin <[e-mail]>]

Hi Margaret,

Thanks for your review.  Please see my comments inline.

Margaret Wasserman wrote:
> 
> 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.

Correct.

> 
> 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.

Correct.

> 
>     - 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.]

No, the SRV algorithm says to try the SRV RR, then the A RR if everything fails.
The text in the I-D modifies the SRV algorithm by specifying what to do if
everything fails: Use the default port and also do an AAAA RR query (OT: RFC
2782 could probably benefit from an update at some point in the future).  I
reorganized the paragraph as follow.  Let me know if this made the intent easier
to understand:

"3.  If <host> is a domain name and <port> is not defined but
     <transport> is defined, then <host> is converted to a list of IP
     address and port tuples via a DNS SRV query as defined in
     [I-D.ietf-behave-turn] section 6.1. <scheme> is used for the
     service name and <transport> is used for the protocol name in the
     SRV algorithm [RFC2782].  The SRV algorithm recommends doing an A
     query if the SRV query returns an error or no SRV RR; in this
     case the default port declared in [I-D.ietf-behave-turn] for the
     SRV service name defined in <scheme> MUST be used for contacting
     the TURN server.  Also in this case, this specification modifies
     the SRV algorithm by recommending an A and AAAA query.  If the
     TURN client cannot contact a TURN server at any of the IP
     address, port and transport tuples returned by the SRV algorithm
     then the resolution MUST stop with 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.]

Here's a reorganized version of the text. Let me know if this made the intent
easier to understand:

"4.  If <host> is a domain name and <port> and <transport> are not
     defined, then <host> is converted to an ordered list of IP
     address, port and transport tuples via the S-NAPTR algorithm
     defined in [RFC3958] with a "RELAY" Application Service Tag. The
     TURN transports supported by the application are converted in
     Application Protocol Tags by using "turn.udp" if the TURN
     transport is UDP, "turn.tcp" if the TURN transport is TCP and
     "turn.tls" if the TURN transport is TLS.  The order to try the
     Application Protocol Tags is provided by the ranking of the first
     set of NAPTR records.  If multiple Application Protocol Tags have
     the same ranking, the preferred order set by the application is
     used.  If the first NAPTR SRV query does not return any result
     then <host> is converted to a list of IP address and port tuples
     by using the algorithm specified in step 3 for each of the TURN
     transports supported by the application in order of preference.
     If the TURN client cannot contact a TURN server with any of the
     IP address, port and transport tuples returned by the S-NAPTR
     algorithm, then the resolution MUST stop with an error."

> 
> 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?  

Yes, S-NAPTR and SRV resolution can only be done on domain names.

> 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.

RFC 3958 section 3.2 lists some guidelines that apply also to this I-D.

> 
> 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?

This is inspired by the SIP/SIPS URI schemes and as TURN is mostly used in a
VoIP context, the confusion seems less likely.  I considered referencing the
uri-transports[1] I-D but abandoned this idea as it is targeted for Experimental.

> 
> (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.

What format would you suggest to use?  I tried to write the most concise and
formal description that I could (as a developer, I have very little patience
with verbose and/or imprecise RFC), but I am open to any way to improve the text.

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

I have a full set of examples (which are in fact my unit tests) that I can add
to the I-D, but as a developer I am a bit reluctant to do this as I consider
examples in RFCs as been harmful (thanks to so called developers who think that
they can implement an RFC just by looking at the examples).  This said, as the
editor of this I-D, I will add more examples if requested.



[1] http://tools.ietf.org/html/draft-wood-tae-specifying-uri-transports

-- 
Marc Petit-Huguenin
Personal email: [e-mail]
Professional email: [e-mail]
Blog: http://blog.marc.petit-huguenin.org