Re: [Uri-review] [Fwd: [BEHAVE] Last Call: draft-ietf-behave-turn-uri (Traversal Using Relays around NAT (TURN) Uniform Resource Identifiers) to Proposed Standard]

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

Hi Ted,

More comments below.

Ted Hardie wrote:
> Hi Marc,
> 
> Thanks for your reply.  Some further comments below.
> 
> On Thu, Oct 15, 2009 at 4:20 PM, Marc Petit-Huguenin
> <[e-mail]> wrote:
> Hi Ted,
> 
> Thanks for reviewing this I-D.  See my comments below.
> 
> Ted Hardie wrote:
>>>> Howdy,
>>>>
>>>> I do not believe this document is ready for publication, as I believe
>>>> the URI scheme documentation needs work.  As it stands now, the
>>>> scheme-specific processing required for this scheme is so great that I
>>>> believe a standard URI parser will not work with the scheme as it is
>>>> intended.  Looking, for example, at the CPAN module PERL::URI, the
>>>> operation of the standard behavior for path and port seem likely to
>>>> work contrary to this scheme's intention.
> The standard behavior for path does not apply in this case, because a TURN URI
> is an opaque URI, not a hierarchical URI, as advised by RFC 4395[1].  As far as
> I understand PERL::URI, this should fall in the scheme specific support of
> PERL::URI[2], like for SIP and MAILTO URIs.
> 
> 
>> RFC 3986 has the following text:
> 
>>    A parser of the generic URI syntax can parse any URI reference into
>>    its major components.  Once the scheme is determined, further
>>    scheme-specific parsing can be performed on the components.  In other
>>    words, the URI generic syntax is a superset of the syntax of all URI
>>    schemes.
> 
>> When you re-use elements from RFC 3986 (as you do with port, to
>> take on example), I believe the general expectation will be that you
>> are using them in ways that would allow general parsing to occur
>> first, as per the text in RFC 3986.  If you do not wish to have this
>> general parsing occur before scheme-specific behavior, I believe
>> that you would be better off not re-using the elements as you have done
>> here.  Some further discussion on the URI list on exactly how to achieve
>> what you want might turn out to be appropriate.

Hmm, I see your point.  Because I reuse definitions from RFC 3986, you think
that these definitions should be used in the same exact way that they are used
in RFC 3986, where in fact I merely use them as a short cut to not have to copy
them (especially for <host>).

There was not many opaque URI defined in standard track since RFC 3986, but the
IRIS URI (RFC 3981 section 7.1) looks like an opaque URI that reuse components
from RFC 2396 and RFC 2732.

Anyway, I can copy and rename the definitions that I need from RFC 3986 if it is
what is needed.


>>>> I also could not follow the
>>>> details of how this would work in relation to a DDDS remote hosting
>>>> option, as mentioned in section 1, and I believe that more descriptive
>>>> text may be required.
> The best would be to add another example for this usage:
> 
> <begin-text>
> 5.  Examples
> 
> 5.1.  Multiple Protocols
> 
>   With the DNS RRs in Figure 1 and an ordered TURN transport list of
>   {TLS, TCP, UDP}, the resolution algorithm will convert the "turn:
>   example.net" URI to the list of IP addresses, port and protocol
>   tuples in Table 2.
> 
> 
>   example.net.
>   IN NAPTR 100 10 "" "RELAY:turn.udp" "" datagram.example.net.
>   IN NAPTR 200 10 "" "RELAY:turn.tcp:turn.tls" "" stream.example.net.
> 
>   datagram.example.net.
>   IN NAPTR 100 10 "S" "RELAY:turn.udp" "" _udp._turn.example.net.
> 
>   stream.example.net.
>   IN NAPTR 100 10 "S" "RELAY:turn.tcp" "" _turn._tcp.example.net.
>   IN NAPTR 200 10 "A" "RELAY:turn.tls" "" a.example.net.
> 
>   _turn._udp.example.net.
>   IN SRV   0   0  3478 a.example.net.
> 
>   _turn._tcp.example.net.
>   IN SRV   0   0  5000 a.example.net.
> 
>   a.example.net.
>   IN A     192.0.2.1
> 
> 
>                                 Figure 1
> 
>                 +-------+----------+------------+------+
>                 | Order | Protocol | IP address | Port |
>                 +-------+----------+------------+------+
>                 | 1     | UDP      | 192.0.2.1  | 3478 |
>                 | 2     | TLS      | 192.0.2.1  | 5349 |
>                 | 3     | TCP      | 192.0.2.1  | 5000 |
>                 +-------+----------+------------+------+
> 
>                                  Table 2
> 
> 5.2.  Remote Hosting
> 
>   In the example in Figure 2, a VoIP provider (example.com) is using
>   the TURN servers managed by the administrators of the example.net
>   domain (defined in Figure 1).  The resolution algorithm using the
>   ordered TURN transport list of {TLS, TCP, UDP} would convert the
>   "turn:example.com" URI to the list of IP addresses, port and protocol
>   tuples in Table 2.
> 
> 
>   example.com.
>   IN NAPTR 100 10 "" "RELAY:turn.udp:turn.tcp:turn.tls" "" example.net.
> 
> 
>                                 Figure 2
> </end-text>
> 
> 
>> This is somewhat clearer, but the transport list ordering is still confusing
>> to me (for more, see below).
> 
>>>> One area of particular concern is this:
>>>>
>>>> "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."
>>>>
>>>> Having a URI resolution method rely on a preference order associated
>>>> with a calling application seems very fragile.  There seems to be no way
>>>> to guarantee that the information on calling application would be preserved in
>>>> passing the URI to a parser.  If this input list is required, I suspect that
>>>> that it must be noted within a URI parameter to avoid unexpected or incorrect
>>>> results.
> I am not sure to fully understand the concern here.  The preference order is
> used so the resolver can choose in case of a tie.  There is 3 different sources
> of data that are processed by the resolution algorithm to generate the list of
> {IP address, port, protocol} tuples to try:
> 
> 
>> Where does it get the preference order?  The document seems to imply that
>> the preference order is associated with an application using the URI, which
>> you have restated in 2. below.  As stated above, this implies knowledge
>> of that preference order in the URI parser, without explicitly passing that
>> knowledge.  If that is not correct, sorry, but that is how the document reads
>> to me at the moment.  If that is correct, it seems fragile.

The I-D talks about two separate things:

First a resolution mechanism, or algorithm, that take in input this 4 elements:

- A list of ordered TURN transport
- A domain or an IP address
- A port that can be empty
- A transport that can be empty

With this information and the RR retrieved from the network, it builds a list of
{IP, port, transport} tuples.

The second thing described in the I-D is an URI that permit to conveniently
provide the 3 last elements in a unique character string.  The URI parser (at
the difference of the resolution algorithm) does not care about which TURN
protocols are implemented or not, or which one is more efficient or more secure
than the other (according to the implementer).

            +------+                 +----------+
TURN URI -->|Parser+--> domain/IP -->|Resolution+--> {IP, port, transport} list
            |      +--> port ------->|mechanism |
            |      +--> transport--->|          |
            +------+                 |          |
TURN transport list----------------->|          |
RRs--------------------------------->|          |
                                     +----------+

> 
> 
> 
> 1. The NAPR/SRV/A/AAA RRs that express the preferences of the domain(s)
> administrators.
> 
> 2. The ordered list of TURN transports that express the preferences of the
> application developers (i.e. the capabilities of the application - what
> protocols are implemented - and in case the algorithm cannot decide, the
> preferred protocol - the fastest implementation, or more secure, etc...).
> 
> 3. The URI itself that express the preferences of the user of the application
> (i.e. specific IP, specific port, specific transport or just the domain if the
> user does not care).
> 
> Moving the ordered list of TURN transports to the URI would prevent the
> application to provide to the resolution algorithm its own capabilities and
> preferences.
> 
> Let me know if you think that the current text does not reflect this
> explanation, in which case I will try to add some text.
> 
> 
>> Honestly, I am increasingly confused about why it would not be
>> better to simply use the existing DNS URI scheme to point to
>> the NAPTR RRs, then apply all the post processing to what
>> is returned, without trying to do a portion of this within this scheme
>> structure.  That's obviously a different set of trade-offs, but given
>> the extensive set of scheme-specific behavior this requires, I'm
>> not sure I understand the engineering choice here.

Let met know if after reading my explanation above you still think that the DNS
URI is a solution to explore, and I will then answer that.

Thanks.

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