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

From: Ted Hardie <[email-masked]>
Date: Thu, 15 Oct 2009 14:33:56 -0700

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

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.

Since this mechanism involves a fairly distinctive URI resolution
mechanism, I suggest that this document also be reviewed by the URI
mailing list, in addition to URI-review.  It seems more likely to be
able to discuss how to best meet the requirements expressed within a
URI syntax more likely to be handled correctly by parsers already
deployed.

regards,

Ted Hardie

On Thu, Oct 15, 2009 at 7:58 AM, Magnus Westerlund
<[email-masked]> wrote:
> Hi,
>
> As responsible AD I would really appreciate an URI review of the two
> proposed URI schemes.
>
> Thanks
>
> Magnus Westerlund
>
> IETF Transport Area Director
> ----------------------------------------------------------------------
> Multimedia Technologies, Ericsson Research EAB/TVM
> ----------------------------------------------------------------------
> Ericsson AB                | Phone  +46 10 7148287
> Färögatan 6                | Mobile +46 73 0949079
> SE-164 80 Stockholm, Sweden| mailto: [email-masked]
> ----------------------------------------------------------------------
>
> The IESG has received a request from the Behavior Engineering for
> Hindrance Avoidance WG (behave) to consider the following document:
>
> - 'Traversal Using Relays around NAT (TURN) Uniform Resource Identifiers '
>   <draft-ietf-behave-turn-uri-03.txt> as a Proposed Standard
>
> The IESG plans to make a decision in the next few weeks, and solicits
> final comments on this action.  Please send substantive comments to the
> [email-masked] mailing lists by 2009-10-29. Exceptionally,
> comments may be sent to [email-masked] instead. In either case, please
> retain the beginning of the Subject line to allow automated sorting.
>
> The file can be obtained via
> http://www.ietf.org/internet-drafts/draft-ietf-behave-turn-uri-03.txt
>
>
> IESG discussion can be tracked via
> https://datatracker.ietf.org/public/pidtracker.cgi?command=view_id&dTag=18080&rfc_flag=0
>
> _______________________________________________
> Behave mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/behave
>
>
> _______________________________________________
> Uri-review mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/uri-review
>
>

---

From: "Dan Wing" <[email-masked]>
Date: Thu, 15 Oct 2009 18:03:00 -0700

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On 
> Behalf Of Ted Hardie
> Sent: Thursday, October 15, 2009 2:34 PM
> To: Magnus Westerlund
> Cc: [email-masked]; [email-masked]; [email-masked]
> Subject: Re: [Uri-review] [Fwd: [BEHAVE] Last Call: 
> draft-ietf-behave-turn-uri(Traversal Using Relays around NAT 
> (TURN) Uniform Resource Identifiers)to Proposed Standard]
> 
> Howdy,
> 

Thanks for your review comments.

> URI syntax more likely to be handled correctly by parsers already

I requested review by uri-review on 30-JUL-2009, per your earlier
suggestion.  However, we received no review comments from that 
request, which was mentioned in the PROTO write-up for this
document.  This is my only experience with uri-review; it was
easy and painless, because we received no comments.

Somebody please shake the tree that is uri-review so that we can
progress this document.

-d

> Ietf mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ietf

---

From: Ted Hardie <[email-masked]>
Date: Thu, 15 Oct 2009 18:09:59 -0700

Hi Marc,

Thanks for your reply.  Some further comments below.

On Thu, Oct 15, 2009 at 4:20 PM, Marc Petit-Huguenin
<[email-masked]> wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Hi Ted,
>
> Thanks for reviewing this I-D.  See my comments below.
>
> Ted Hardie wrote:
>> Howdy,
>>
>> 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.

>> I also could not follow the
> 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).

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

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

regards,

Ted Hardie

> [1] http://www.ietf.org/mail-archive/web/behave/current/msg06537.html
> [2] http://search.cpan.org/~gaas/URI-1.40/URI.pm#SCHEME-SPECIFIC_SUPPORT
>
> - --
> Marc Petit-Huguenin
> Personal email: [email-masked]
> Professional email: [email-masked]
> Blog: http://blog.marc.petit-huguenin.org
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.10 (GNU/Linux)
>
> iEYEARECAAYFAkrXrjIACgkQ9RoMZyVa61cM7wCgn+57/Rab0lg1jQCMASabTPx/
> 2lAAoKr/ntOzbchDJj8SHZSOLrl/chgg
> =OIPz
> -----END PGP SIGNATURE-----
>

---

From: Ted Hardie <[email-masked]>
Date: Thu, 15 Oct 2009 18:14:53 -0700

> Somebody please shake the tree that is uri-review so that we can

Howdy.

It is being reviewed by URI-review, as per Magnus's request.  I
personally probably missed the earlier request because I was changing
jobs right after the Stockholm IETF and had queued that kind of review
for after the meeting.  Sorry for my own delay.  What I have
suggested, though, is review by the *uri* mailing list, which is a
larger group at [email-masked].  This is not required, but can be done if
there is reason.

regards,

Ted Hardie

---

From: Marc Petit-Huguenin <[email-masked]>
Date: Thu, 15 Oct 2009 23:56:17 -0700

Hi Ted,

More comments below.

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

>   IN SRV   0   0  5000 a.example.net.

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

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

---

From: Ted Hardie <[email-masked]>
Date: Fri, 16 Oct 2009 10:09:11 -0700

Hi Marc,

Thanks for your quick reply; a few notes in-line below.

> them (especially for <host>).

This is part of the issue, and probably the main part.  As it stands,
reusing those elements appears to put portions of the URI into an
"authority section" model (go here to get the resource specified in
the path, or returned by the query) when they are really closer to a
query portion.

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

IRIS is an interesting model here, as it is one of the few others to
really use S-NAPTR.  I've cc'ed Andy on this message to ping him to
take a look at your draft.  IRIS's complexity is pretty substantial on
a number of fronts, and the URI resolution is certainly
one of the areas where the complexity has daunted some of those
interested in the protocol.  It's also noteworthy that IRIS created a
very rigid URI, with a very flexibile resolution mechanism.  I'm not
sure, honestly, that approach was a success.

> than the other (according to the implementer).

This is clearer; thanks.  My own reading of the current text did not
reflect this understanding.  Reading it, it seemed to me to imply that
the *URI resolution* relied on knowing the TURN preferences of the
calling application (your 2).  Your text above notes that the URI
resolution does not depend on this at all; the URI resolution proceeds
and then the application logic is applied.  Is that correct?

> URI is a solution to explore, and I will then answer that.

As I said before, I think it is a different set of trade-offs, and
last call is not really
a fair time to suggest a completely different road.  What it gets you
is the ability
to separate the "get the RRs" step from all the other steps in the application
logic.  If that would be useful, then by all means do explore it; if the working
group's conclusion is that the right approach is mint a single URI that both
retrieves the relevant NAPTR  RRs and carries the other parameters needed to
identify the TURN server, then continuing to work on this may be the way to go.
What started me down the line of thinking that led to separating them was the
notion that at least some of the parameters (the application's preference order)
were already outside the URI.

regards,

Ted Hardie

---

From: Marc Petit-Huguenin <[email-masked]>
Date: Thu, 15 Oct 2009 16:20:21 -0700

Hi Ted,

<begin-text>
5.  Examples

5.1.  Multiple Protocols

   example.net.

   datagram.example.net.

   stream.example.net.

   _turn._udp.example.net.

   _turn._tcp.example.net.

   a.example.net.
   IN A     192.0.2.1

                                 Figure 1

                                  Table 2

5.2.  Remote Hosting

   example.com.

                                 Figure 2
</end-text>

- --
Marc Petit-Huguenin

---

From: Marc Petit-Huguenin <[email-masked]>
Date: Tue, 20 Oct 2009 09:06:50 -0700

Hi Ted,

I was waiting for some feedback from Andy but let's continue the discussion.

> the path, or returned by the query) when they are really closer to a

So what would be your advice here?

I can 1) add some text to make explicit that I am just referencing the elements
in RFC 3986 and that this is not an <authority> element, 2) copy and past the
elements (i.e. <port> and <host>) from RFC 3986, or something else.

> sure, honestly, that approach was a success.

Yes, I would be interested in this as IRIS was one of the document I use as a
guidance to design the resolution mechanism. (Off-topic:  I see a lot of I-Ds
this days proposing to use SRV for various protocols.  I wonder why people does
not go directly to NAPTR+SRV, as it is far more flexible for the administrators)

> and then the application logic is applied.  Is that correct?

Yes.

I am proposing the following text to replace the beginning of section 4.  Let me
know if this reflects my explanation above:

"4.  Resolution Mechanism

   The 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 resolution algorithm uses <scheme>, <host>, <port> and
   <transport> from the TURN URI as input.  It also uses as input a list
   ordered by preference of TURN transports (UDP, TCP, TLS) supported
   that is provided by the application using the TURN client.  This list
   reflects the capabilities and preferences of the application code as
   opposed to the TURN URI that reflects the preferences of the user of
   the application.  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."

---

From: Andrew Newton <[email-masked]>
Date: Thu, 22 Oct 2009 11:24:49 -0400

> sure, honestly, that approach was a success.

Marc, Ted,

I'm unsure of what insight I can offer here.  The TURN URI scheme does  
seem to mix "layers" of the resolution process, or at least as I've  
thought about it in the past.   But that may just be me and my limited  
understanding of what is trying to be accomplished by the TURN URI.

With regard to complexity, that is most likely in the eye of the  
beholder.  I would think this is more complex than other uses of S- 
NAPTR.  I don't know how one goes about judging these sort of things.   
Perhaps it would be helpful to look at an S-NAPTR implementation.   
VeriSign's SVN repository still hosts pysnaptr, which you can find here:
http://svn.verisignlabs.com/main/snaptr/pysnaptr/tags/RELEASE_0_1/pysnaptr

This discussion would also benefit from anybody with knowledge of or  
implementation experience with generic URI parsers, as that would be a  
point of interoperability.

-andy

---

From: Marc Petit-Huguenin <[email-masked]>
Date: Thu, 22 Oct 2009 12:05:53 -0700

Hi Andrew,

Andrew Newton wrote:
> beholder.  I would think this is more complex than other uses of
> S-NAPTR.  I don't know how one goes about judging these sort of things. 

For comparison my own reference implementation in Java of the TURN URI parser
and resolver is 364 lines long.  This is without the RFC 3958 implementation,
255 lines long, and the RFC 2782 implementation which is 141 lines long. The URL
to this reference implementation is in Annex A.10 in the I-D.

---

From: Andrew Newton <[email-masked]>
Date: Thu, 22 Oct 2009 16:01:20 -0400

On Oct 22, 2009, at 3:05 PM, Marc Petit-Huguenin wrote:

>> ...
> ...

Marc,

I suppose if I had been a little more caffeinated this morning, I  
would have also provided links to VeriSign's Java and Perl  
implementations of 3958:

http://svn.verisignlabs.com/main/snaptr/net_dns_snaptr/trunk/lib/Net/DNS/SNAPTR.pm
http://svn.verisignlabs.com/main/snaptr/jsnaptr/trunk/src/com/verisignlabs/jsnatpr/JSNaptr.java

Lines of code is certainly one measure of complexity, but that can be  
heavily influenced by the programming style and language used.  Again,  
this is all subjective, but in my opinion it is complex.  I think most  
of that is due to the nature of NAPTR and DNS itself and perhaps  
cannot be avoided.  I hope this is helpful.

-andy

---

From: Marc Petit-Huguenin <[email-masked]>
Date: Thu, 22 Oct 2009 14:59:31 -0700

Andrew Newton wrote:
> I suppose if I had been a little more caffeinated this morning, I would
> have also provided links to VeriSign's Java and Perl implementations of
> 3958:
> 
> of that is due to the nature of NAPTR and DNS itself and perhaps cannot
> be avoided.  I hope this is helpful.

Well, I do not think that the full complexity of NAPTR and SRV should be counted
when evaluating the implementation complexity of this I-D.  A TURN URI is used
by a TURN client, which is probably used in an ICE implementation which is
probably used in a SIP UAC.  A SIP UAC is probably implementing RFC 3263, which
means that NAPTR and SRV are already implemented.  So the real complexity is the
complexity of the TURN URI parser and the resolver as defined in the I-D and the
complexity of S-NAPTR (i.e. without NAPTR as defined in RFC 3403).  That's
around 370 lines of code in my reference implementation.