Subject: Re: [BEHAVE] WGLC: draft-ietf-behave-turn-uri-02

From: Dave Thaler <[email-masked]>
Date: Fri, 7 Aug 2009 20:35:00 +0000

Attached is a copy with my comments.

Summary of comments that aren't purely editorial:

1) Why does this diverge from the generic URI syntax in
   RFC 3986 by omitting // before the host part?

2) The algorithm keep saying convert to "a" TURN transport
   "as specified above".  However, there's nowhere in the doc
   that actually does so.  Page 4 _filters_ the list, but
   you can end up with multiple (turn/tcp -> TCP and TLS).

3) Is there any ordering constraint on the order in which
   IP addresses are tried or is RFC 3484 sufficient?

4) Algorithm step 3 is underspecified.  It says it recommends
   "A or AAAA query".  In constrast step 2 says "A and AAAA
   query".  Why is step 3 an "or"?  I think it should be
   "and".

-Dave

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On
> Behalf Of Dan Wing
> Sent: Thursday, July 30, 2009 1:49 AM
> To: [email-masked]
> Cc: [email-masked]; 'Behave Chairs'; apps-
> [email-masked]
> Subject: [BEHAVE] WGLC: draft-ietf-behave-turn-uri-02
>
> BEHAVE is starting a 3 week working group last call (WGLC), ending
> August 19,
> for
>
>   draft-ietf-behave-turn-uri-02
>   "Traversal Using Relays around NAT (TURN) Uniform Resource
> Identifiers"
>
>
> *** Review by folks familiar with URIs are encouraged.  ***
>
>
> Please send technical comments to the BEHAVE list, and editorial
> comments to
> the authors.
>
> Thanks,
> -d
>
> _______________________________________________
> Behave mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/behave

---

From: Marc Petit-Huguenin <[email-masked]>
Date: Mon, 10 Aug 2009 09:52:25 -0700

Thanks for your review.  Please see my answers below.

>    RFC 3986 by omitting // before the host part?

I went back and forth between a hierarchical URI (i.e. with the //)
and and opaque URI (without the //), but the changelog[1] that
explain this disappeared between the draft-petithuguenin and the
draft-ietf versions (I put back the complete changelog in my local
copy of the draft, to be publish at the end of the WGLC).

The reason I went back to an opaque URI is because of RFC 4395
Section 2.2.  The TURN URI does not describe a hierarchical
structure and RFC 4395 advises to use opaque URI in this case.

>    that actually does so.  

The "as specified above" refers to the fourth paragraph of section 4
("In some steps...").  I inverted "<transport>" and "<scheme>" in
the fourth paragraph so it matches the order used in the steps.  I
did not find a better way to do not have to repeat the text multiple
times.  Any advice?

> Page 4 _filters_ the list, but

I am not sure to understand this.  The conversion described is for
the URI elements i.e.:

turn:example.com?transport=udp --> UDP
turn:example.com?transport=tcp --> TCP
turns:example.com?transport=tcp --> TLS

There cannot be multiple conversions at this step.  Do you have any
suggestion to improve the text?

>    IP addresses are tried or is RFC 3484 sufficient?

I think that RFC 3484 is sufficient.  Should I add a reference?

>    query".  Why is step 3 an "or"?  I think it should be

Yes, modified on my local copy.

I also applied all your editorial modifications.  I moved the
"Running Code Considerations" section in the "Release Notes"
appendix so it will be removed (with the URIs section) before
publication (see draft-petithuguenin-running-code-considerations for
the motivations and the subsequent discussion on the IETF mailing
list on how much people disliked it :-( )

[1]
http://tools.ietf.org/rfcdiff?url2=draft-petithuguenin-behave-turn-uri-03.txt

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

---

From: "Alfred E. Heggestad" <[email-masked]>
Date: Mon, 10 Aug 2009 21:40:46 +0200

Dan Wing wrote:
> BEHAVE is starting a 3 week working group last call (WGLC), ending August 19,
> for 
> 
>   "Traversal Using Relays around NAT (TURN) Uniform Resource Identifiers"
> 
> 
> Please send technical comments to the BEHAVE list, and editorial comments to
> the authors.
> 

I have done a WGLC review of the document draft-ietf-behave-turn-uri-02.

The document looks good, it is quite easy to read, and it should be
quite easy to implement from reading the text.
I do not have any major comments.

/alfred

---

From: Dave Thaler <[email-masked]>
Date: Mon, 10 Aug 2009 23:43:46 +0000

> structure and RFC 4395 advises to use opaque URI in this case.

Ok.  No change needed.

> did not find a better way to do not have to repeat the text multiple

I'd suggest:
1) Right before the paragraph starting
  "First the resolution algorithm checks that the URI can be resolved"
   Add a table:

   <scheme> <transport>    TURN Transport
   -------- -----------    --------------
   "turn"   "udp"          UDP
   "turn"   "tcp"          TCP
   "turns"  "tcp"          TLS
   "turns"  not defined    TLS

2) Change the bullets to say basically: if the scheme and transport
   match an entry in table 1, but the list of TURN transports
   supported by the application does not include the corresponding
   TURN transport, stop with an error.  And if there is no matching
   row, stop with an error.

3) Then when you talk about converting "as specified above", say
   "as specified in Table 1".

> suggestion to improve the text?

Yes, since your answer above does not match what's in the draft.
Specifically, section 4 second bullet states:

>   o  If <scheme> is defined as "turn" and <transport> is defined as
>      "tcp" but the list of TURN transports does not contain TCP or TLS
>      then the resolution MUST stop with an error.

Hence both of these are legal:
turn:example.com?transport=tcp --> TCP
turn:example.com?transport=tcp --> TLS

If you want to guarantee there's a single possibility only, then
delete "or TLS".  (The table I suggested above already omits this.)

> I think that RFC 3484 is sufficient.  Should I add a reference?

I'd just say the client can choose an order in any implementation-specific
way.  (Then no need to reference 3484 and any other alternative is okay
too.)

-Dave

---

From: Marc Petit-Huguenin <[email-masked]>
Date: Tue, 11 Aug 2009 08:26:20 -0700

> Marc Petit-Huguenin wrote:
[...]
>    <scheme> <transport>    TURN Transport

The table is a good idea, thanks.

> delete "or TLS".  (The table I suggested above already omits this.)

OK, I see what the misunderstanding is.  I pasted the revised
Section 4 at the end of this email.  Can you please read it again, trying
to forget the previous version, and let me know if it makes sense now?

There is an additional issue in the "...does not contain TCP or TLS" sentence.
The motivation for this sentence was to permit to use TLS if TLS was the only
protocol available, even if the TURN URI requested TCP (the opposite will fail,
see bullet 4). The issue is that there is no text in the resolution steps that
explain how to do this.  But perhaps doing this kind of "upgrade" from TCP to
TLS is a mistake.  So before adding the missing text in the resolution steps, I
would like to know what people think of this.

> way.  (Then no need to reference 3484 and any other alternative is okay

Done.

-------------------------------------------------------------------------------

   The URI resolution mechanism is used only to create an allocation.
   All other transactions use the IP address, transport and port used
   for a successful allocation creation.

   The URI resolution algorithm uses <scheme>, <host>, <port> and
   <transport> as input.  It also uses as input a list ordered by
   preference of TURN transports (UDP, TCP, TLS) supported by the
   application using the TURN client.  The output of the algorithm is a
   list of {IP address, transport, port} tuples that a TURN client can
   try in order to create an allocation on a TURN server.

   An Allocate error response as specified in section 6.4 of
   [I-D.ietf-behave-turn] is processed as a failure as specified by
   [RFC3958] section 2.2.4.  The resolution stops when a TURN client
   gets a successful Allocate response from a TURN server.  After an
   allocation succeeds or all the allocations fail, the resolution
   context MUST be discarded and the URI resolution algorithm MUST be
   restarted from the beginning for any subsequent allocation.  Servers
   blacklisted as described in section 6.4 of [I-D.ietf-behave-turn]
   should not be used for the specified duration even if returned by a
   subsequent resolution.

   First the resolution algorithm checks that the URI can be resolved
   with the list of TURN transports supported by the application:

   o  If <scheme> is defined as "turn" and <transport> is defined as
      "udp" but the list of TURN transports supported by the application
      does not contain UDP then the resolution MUST stop with an error.
   o  If <scheme> is defined as "turn" and <transport> is defined as
      "tcp" but the list of TURN transports supported by the application
      does not contain TCP or TLS then the resolution MUST stop with an
      error.
   o  If <scheme> is defined as "turns" and <transport> is defined as
      "udp" then the algorithm MUST stop with an error.
   o  If <scheme> is defined as "turns" and <transport> is defined as
      "tcp" but the list of TURN transports supported by the application
      does not contain TLS then the resolution MUST stop with an error.
   o  If <scheme> is defined as "turns" and <transport> is not defined
      but the list of TURN transports supported by the application does
      not contain TLS then the resolution MUST stop with an error.
   o  If <transport> is defined but unknown then the resolution MUST
      stop with an error.

   After verifying the validity of the URI elements, the algorithm
   applies the steps described below.  Note that in some steps, <scheme>
   and <transport> have to be converted to a TURN transport.  If
   <scheme> is defined as "turn" and <transport> is defined as "udp"
   then the TURN UDP transport is used.  If <scheme> is defined as
   "turn" and <transport> is defined as "tcp" then the TURN TCP
   transport is used.  If <scheme> is defined as "turns" and <transport>
   is defined as "tcp" then the TURN TLS transport is used.  This is
   summarized in Table 1.

                +----------+-------------+----------------+
                | <scheme> | <transport> | TURN Transport |
                +----------+-------------+----------------+
                | "turn"   | "udp"       | UDP            |
                | "turn"   | "tcp"       | TCP            |
                | "turns"  | "tcp"       | TLS            |
                +----------+-------------+----------------+

                                  Table 1

   1.  If <host> is an IP address then it indicates the specific IP
       address to be used.  If <port> is not defined, the default port
       declared in [I-D.ietf-behave-turn] for the SRV service name
       defined in <scheme> is used.  If <transport> is defined then
       <scheme> and <transport> are converted to a TURN transport as
       specified in Table 1.  If <transport> is not defined, the TURN
       transports supported by the application are tried by preference
       order.  If the TURN client cannot contact a TURN server with this
       IP address and port on any of the transports supported by the
       application then the resolution MUST stop with an error.

   2.  If <host> is a domain name and <port> is defined, then <host> is
       resolved to a list of IP addresses via DNS A and AAAA queries.
       If <transport> is defined, then <scheme> and <transport> are
       converted to a TURN transport as specified in Table 1.  If
       <transport> is not defined, the TURN transports supported by the
       application are tried in preference order.  If the TURN client
       cannot contact a TURN server with this port and any combination
       of transports supported by the application and resolved IP
       addresses then the resolution MUST stop with an error.  The TURN
       client can choose the order to contact the resolved IP addresses
       in any implementation-specific way.

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

   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
       protocol tags is provided by the ranking of the first set of
       NAPTR records.  If multiple protocol tags have the same ranking,
       the preferred order set by the application is used.  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.  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.