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

From: Margaret Wasserman <[email-masked]>
Date: Tue, 20 Oct 2009 11:08:47 -0400

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

---

From: Marc Petit-Huguenin <[email-masked]>
Date: Tue, 20 Oct 2009 12:12:43 -0700

Hi Margaret,

Thanks for your review.  Please see my comments inline.

>          > The supported transports are tried in order of

Correct.

>           >> The supported transports are tried in order of

Correct.

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

>                  application".  It is not clear to me what

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

> IP address instead of a Domain Name?  

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

> I am somewhat concerned

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

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

>    consistent and represent all of the choices, this format does not

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.

>    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: [email-masked]
Professional email: [email-masked]
Blog: http://blog.marc.petit-huguenin.org

---

From: Marc Petit-Huguenin <[email-masked]>
Date: Sun, 25 Oct 2009 12:03:53 -0700

Hi Margaret,

see inline.

Margaret Wasserman wrote:
> Hi Marc,
> 
> I've added the WG back to this message, because I think that some of
> my questions/comments in this message should be considered by the
> group.
> 
> I think that I understand this specification now.  I do have a few
> more comments on your proposed text (in-line below), but I also have a
> few more fundamental concerns about this specification.
> 
> It is possible that the WG has already discussed these issues and
> agreed to the approach in your document.  If so, I apologize for
> wasting time.  If not, though, I think it is important that we all
> understand these issues and agree on the right approach.
> 
> (1) Implicit vs. Explicit Processing:
> 
> The URIs in the specification are defined so that the processing
> performed to resolve them is implied by the contents and/or presence
> of various fields in the URI.
> 
> - If the <host> is an IP address, no DNS lookup is performed.
> 
> - If the <host> is a domain name (or any string that could be a domain
> name), processing depends on the existence of the <transport> and
> <port> fields.
> 
> -- If <port> is defined, then a DNS A/AAAA lookup is defined, and
> services are contacted at the defined port.
> 
> -- If <port> is not defined, and <transport> is defined a DNS SRV
> lookup is performed, with fallback to an A/AAAA lookup.
> 
> -- If neither <port> nor <transport> is defined, then an S-NAPTR
> lookup is performed, with fallback to DNS SRV, and subsequent fallback
> to A/AAAA.
> 
> Having the type(s) of resolution performed be dependent on the
> inclusion/exclusion of fields in the URI has some advantages.  One is
> that you are never asked to perform a type of resolution for which you
> do not have the appropriate information.
> 
> However, there are some downsides to this approach, because it limits
> the flexibility of the application.
> 
> It is not possible, for example, to request an S-NAPTR lookup without
> fallback to DNS SRV.  If there should be an S-NAPTR record or a DNS
> SRV record, and that lookup fails, fallback to trying all supported
> transports based on an A/AAAA lookup may result in connecting to a
> different TURN/TURNS service than desired, or to a different server
> than has been contacted in the past.  All of this would, presumably,
> be invisible to the user and perhaps to the application, so debugging
> the problem might be difficult.
> 
> Were these tradeoffs discussed in the WG?

No.

>  What were the reasons for
> choosing the current implicit processing approach?

This design is inspired by RFC 3263.  The idea is that domain administrators can
choose to implement either A/AAAA or SRV+A/AAAA or NAPTR+SRV+A/AAAA as they see
fit for their environment, but still use the same TURN URI.

Let's use as example the growth of a VoIP provider.  The TURN URI provisioned in
the VoIP end-user devices is "turn:example.com", and cannot be easily changed.
The provider starts with few identical TURN boxes and use an A RR for each box.
 Each endpoint queries for NAPTR, which fails; then for SRV, which fails; then
for A, which succeeds.

After some time, more TURN servers are added, but they are not identical, so
load balancing is needed, so the provider adds some SRV RR.  Now each endpoint
queries for NAPTR, which fails; then for SRV, which succeeds; then the final A.
 Without modifications on the endpoint, the administrators were successful in
upgrading their infrastructure.

After even more time, the provider decides to delegate the management of the
TURN servers to an external company, so they add a NAPTR RR.  Now each endpoint
queries for the NAPTR which succeed to delegate to the NAPTR of the domain of
the company managing the TURN servers, and the SRV succeeds, and then the A.
Here again, the provider succeeded in changing their infrastructure without
having to reconfigure the endpoints.

> 
> (2) TURNS vs. TURN URIs:
> 
> The document specifies two different URI schemes, TURN and TURNS.
> 
> However, the processing steps defined imply that a TURNS URL might
> end-up reaching a TURN server, and vice versa.  I am particularly
> concerned about the case where a request for an authenticated,
> encrypted session (TURNS) may result in connection to an insecure
> service (TURN).
> 
> This could happen (I believe) in at least two cases:
> 
> - If an IP address is provided for the <host> and no <transport> is
>   provided, "the TURN transports supported by the application are
>   tried by preference order."
> 
> - If a domain name is provided for <host>, <port> is defined and
>   <transport> is not defined, "the TURN transports supported by the
>   application are tried by preference order."
> 
> Is it intentional that these choices will try all of the "TURN
> transports" supported by the application, not just those that match
> the <scheme> in the URI?  If so, why?
> 
> If this is not intentional, then further wording changes are needed.
> 
> If this is intentional, the implications should be discussed in the
> Security Considerations section.

You are absolutely right, this is a bug in the spec, the ordered list of TURN
transports should have been filtered by the <scheme> used.

I propose to replace "...the TURN transports supported by the application..." by
"...the filtered TURN transports supported by the application..." in step #1 and
#2 and to add the following paragraph before paragraph 6:

"After verifying the validity of the URI elements, the algorithm
 filters the list of TURN transports supported by the application by
 keeping only the UDP and TCP TURN transports if the <scheme> is
 defined as "turn" and by keeping only the TLS TURN transport if the
 <scheme> is defined as "turns".  If the list of TURN transports is
 empty after this filtering, the resolution MUST stop with an error."

and to modify paragraph 6 (now 7) like this:

"After filtering the list of TURN transports supported by the
 application, the algorithm applies the steps described below.  Note
 that in some steps, <scheme> and <transport> have to be converted to
 [...]"

> 
> (2) There seem to be some ambiguity in case 2 about whether the
> service will always be contacted using the <transport> defined in the
> URI, if any.  The text indicates that a <transport> may be defined and
> would be used to construct a TURN transport, but then the text says:
> 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.
> 
> So, it appears that the resolution process will try all of the
> transports supported by the application, even if a <transport> is
> specified in the URI.  There are similar ambiguities elsewhere.
> 
> Is this intentional?  If so, why?  If not, then further wording
> changes are required to make this clearer.

New proposed text:

"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 filtered TURN transports
     supported by the application are tried in preference order.  The
     TURN client can choose the order to contact the resolved IP
     addresses in any implementation-specific way.  If the TURN client
     cannot contact a TURN server with this port, the transport or
     list of transports, and the resolved IP addresses, then the
     resolution MUST stop with an error."

> 
> (4) I also continue to be concerned about the amount of information in
> the 4 numbered paragraphs in section 4, and their relative lack of
> structure, as well as the lack of examples.  I am concerned that this
> specification may not be clear enough to promote consistent
> implementation.
> 
> I think that it would be much better if you added a section explaining
> how each type of lookup (A/AAAA, SRV, S-NAPTR) is constructed from the
> fields of the URI and performed, with examples.  Then you could
> include a trimmed down version of your current section that explains
> how to determine which lookups to perform based on the contents of the
> URI.  I think that would be clearer than trying to do it all in the
> same paragraphs.  You might also consider writing the procedures more
> in the order they would be performed if they were written in a
> program, perhaps handling the IP address case first (as you have done),
> but then reversing the order of the other cases and describing how
> you would fall through from one type of lookup to another.

I still think that examples must not be added until the text is so clear that
the examples are useless.

> 
> On Oct 22, 2009, at 2:52 PM, Marc Petit-Huguenin wrote:
> 
>> Here's the new proposed text:
>> "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. <host> is
>> used for the Name, <scheme> is used for the Service and <transport>
>> is used for the Protocol 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,
> 
> Will these connection attempts also use the <transport> defined
> above?  Or will they use all of the transports supported by the
> application?

This is specified by RFC 2782 section "Usage Rules":

"else
    Do a lookup for QNAME=target, QCLASS=IN, QTYPE=A

    for each address record found, try to connect to the (protocol, address,
service)"

protocol been already defined as <transport>.

> 
>> 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."
> 
> This has the same problem as the one you fixed in section 4.  We
> don't return an error if the SRV fails, only if both the SRV lookup
> and the subsequent A/AAAA lookup fail, right?

I disagree here.  The text says "SRV algorithm" not "SRV query".  The fallback
to A is part of the SRV algorithm, not something added by this text, so the
tuples returned by the SRV algorithm eventually contains the result of the A
query (and AAAA as modified by the text).

And thinking of it, I am not sure I should have modified step 4, but see below.

> 
>> > When you say "using the algorithm specified in step 3" do you
>> > really mean that if S-NAPTR fails, the client should try multiple
>> > DNS SRV queries using the supported TURN transports to construct
>> > DNS SRV lookup targets? Or are you talking about the second half
>> > of step 3?  Or both?
>>
>> Both, so if NAPTR fails, then SRV is tried.  If SRV fails then
>> A/AAAA is tried.
> 
>> Here's the new proposed text:
>> "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] by using <host> as the
>> initial target domain name and "RELAY" as the Application Service
>> Tag. The TURN transports supported by the application are converted
>> in Application Protocol Tags by using "turn.udp" if the TURN
>> used.  If the first NAPTR query does not return any result then
>> <host> is converted to a list of IP address and port tuples by using
>> the algorithms specified in step 3, including the fallback to the
>> A/AAAA query, for each of the TURN transports supported by the
>> application in order of preference.
> 
> This makes it clear that the A/AAAA lookup is included, but does not
> make it clear that the DNS SRV lookup is included.

I think that the main problem here is that I tried to reuse step 3 as a
procedure call, and that parameter passing does not work very well in a human
language.  So instead of fixing this, I added a step 5 that copies step 3, so
the new text becomes this:

"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] by using <host> as the initial target domain
     name and "RELAY" as the 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 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.

 5.  If the first NAPTR query in the previous step does not return any
     result 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.  The filtered TURN transports supported by the
     application are tried in preference order for the Protocol,
     <host> is used for the Name and <scheme> is used for the Service
     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."

> 
>> 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 or by eventually applying
>> the algorithms specified in step 3, then the resolution MUST stop
>> with an error."
> 
>> > My concern is that there are some subtleties omitted from your
>> > text, such as exactly how an SRV lookup target, an S-NAPTR lookup
>> > target and/or an A/AAAA lookup target are constructed from the
>> > contents of the URI, and I think further examples might make this
>> > clearer.  You make it clearer in the text, instead, if you think
>> > that would be preferable.
> 
>> I hope that we can settle on a normative text that would not require
>> developers to look at the examples.
> 
> It is still not clear to me, from your text, how the S-NAPTR lookup
> would be constructed, but that may reflect my limited understanding
> of S-NAPTR.

---

From: Margaret Wasserman <[email-masked]>
Date: Fri, 30 Oct 2009 14:32:03 -0400

Hi Marc,

>> Were these tradeoffs discussed in the WG?

Do you think they should be?
> fit for their environment, but still use the same TURN URI.

I understand that the current mechanism supports this type of  
fallback, but you
could allow this type of fallback without deciding whether or not to  
try the
S-NAPTR or DNS SRV lookups based on the presence (or lack) of the <port>
and <transport> fields in the URI.

For example, you could ignore the <port> and <transport> fields for  
the S-NAPTR
lookup, and ignore the <transport> field for the DNS SRV lookup, and  
still fall back
to using both them the (if present) when you do an A/AAAA lookup.  In  
that case, the
administrator would have even more flexibility, because he could run  
his servers on
a non-default port and/or specify a specific transport, without  
needing to change the
configuration of the end-user devices to allow them to step up to DNS  
SRV and/or
S-NAPTR.  At this point, the upgrade path you have described only  
works if the
site is running TURN or TURNS on the default port.

There are a number of alternatives here, and it seems to me that the  
one chosen
in the draft is the least flexible.  I am not saying that the choice  
in the draft is the
wrong choice, because I don't know all of the tradeoffs that were  
considered, but
this is something I definitely think would warrant some discussion in  
the WG, so
that folks could reach informed consent on the right approach to use.

> empty after this filtering, the resolution MUST stop with an error."

Looks good.
> that in some steps, <scheme> and <transport> have to be converted to

Looks good.
>     resolution MUST stop with an error."

Looks good.

> the examples are useless.

If no one else supports my position that example would be valuable, I  
will
yield to your opinion on this point, as document editor.
> protocol been already defined as <transport>.

Okay.  That makes sense.  Thanks.
> And thinking of it, I am not sure I should have modified step 4, but  

I understand what you are trying to say, but you haven't defined the  
term "SRV
algorithm" (to include the A/AAAA lookup) anywhere, so it is my  
opinion that
the meaning of this paragraph is still ambiguous.  This is the type of  
thing
that I think could be made very clear by an example, but if you don't  
want
to include examples, you need to be very clear about the step by step
process in each of these paragraphs.

>     SRV algorithm then the resolution MUST stop with an error."

I am not sure that it is valid to indicate that section 4 stops with  
an error,
and then indicate that there are some cases where you would
continue (presumably) without an error...

Maybe you should add a line to section 4, in the middle, indicating that
if the NAPTR query returns an error, you should proceed to step 5?

Also, you mention "the first NAPTR query".  Will there be more than one?
If so, why and what will the subsequent queries contain?
>> would be constructed, but that may reflect my limited understanding

Could you give me an example of how the NAPTR query would be
constructed from the URI?

Margaret

---

From: Margaret Wasserman <[email-masked]>
Date: Fri, 30 Oct 2009 14:54:23 -0400

Hi Marc,

I have some further questions about your last e-mail.  Sorry for not  
including them in the previous message...

> Each endpoint queries for NAPTR, which fails; then for SRV, which  

I think there is a  problem with this example....

(1) While I don't fully understand how "turn:example.com" would be  
transformed into an S-NAPTR query, that is more likely a weakness in  
my understanding than a problem in your draft.

(2) I understand how "example.com" could be turned into a (set of) DNS  
SRV queries for the TURN transports supported by the application.

(3) But, how could you transform "turn:example.com" into an A/AAAA  
record query? Where do you get the host name?  It doesn't make sense  
to just do an A/AAAA query on "example.com" when you are trying to  
find a specific server...

This was what I was dancing around in an earlier post, when I  
indicated some confusion about whether the <name> portion of the URI  
was intended to be a FQDN or just a domain...  The specification seems  
to have some ambiguity in this area.

Margaret

---

From: Marc Petit-Huguenin <[email-masked]>
Date: Fri, 30 Oct 2009 12:36:52 -0700

I'll respond later to your previous email.  See inline for my response to this
email.

Margaret Wasserman wrote:
> transformed into an S-NAPTR query, that is more likely a weakness in my
> understanding than a problem in your draft.
> 
> record query? Where do you get the host name?  It doesn't make sense to
> just do an A/AAAA query on "example.com" when you are trying to find a
> specific server...

$host example.com
example.com has address 192.0.32.10

> 
> This was what I was dancing around in an earlier post, when I indicated
> some confusion about whether the <name> portion of the URI was intended
> to be a FQDN or just a domain...  The specification seems to have some
> ambiguity in this area.

"FQDN" is never used in the draft, so I do not understand why you are referring
to this.  A <host> can be a FQDN and a domain name at the same time. Even "com"
could be a FQDN if someone adds a A record for it, why not?  As there is
absolutely no way to distinguish between a FQDN and a domain name, I do not see
the point of using this terminology.  If you really want to think in term of
FQDN and domain name, then the algorithm is to take whatever is in the <host> if
it is not an IP address, use it first as a domain name and if the NAPTR/SRV
query fails, use it as a FQDN.

---

From: Margaret Wasserman <[email-masked]>
Date: Fri, 30 Oct 2009 15:59:44 -0400

Hi Marc,

> example.com has address 192.0.32.10

I didn't say that you _couldn't_ send a query for example.com, just  
that it wouldn't
make sense to do so...

Are you expecting that administrators will accept a requirement to run  
their TURN
servers at an IP address returned for their domain, in order to  
maintain their ability to
move to DNS SRV records or S-NAPTR later without changing the URIs on  
their
end-user devices?

Isn't it more likely that they will want to name their TURN servers  
something like
turn1.example.com, or something like that?

>> indicated

I am not attempting to argue about the term FQDN vs. the term domain  
name...  I
am arguing that if you won't want to use the same <name> value for the  
DNS
SRV lookup as the A/AAAA in most cases.  So, I am not sure how well  
the fallback
you have described will work in practice.

Are there cases where people do something like this today and it works?

Margaret

---

From: Marc Petit-Huguenin <[email-masked]>
Date: Fri, 30 Oct 2009 13:14:21 -0700

Margaret Wasserman wrote:
> I didn't say that you _couldn't_ send a query for example.com, just that
> it wouldn't
> make sense to do so...
> 
> servers at an IP address returned for their domain, in order to maintain
> their ability to
> move to DNS SRV records or S-NAPTR later without changing the URIs on their
> end-user devices?
> 

Or better turn.example.com.

A provider starts with A/AAAA RR, so turn.example.com is an FQDN, then later
they can convert it into a domain name by adding NAPTR/SRV.

> am arguing that if you won't want to use the same <name> value for the DNS
> SRV lookup as the A/AAAA in most cases.  So, I am not sure how well the
> fallback

SIP (RFC 3263).  Yes it works, I used it for the VoIP service I developed for my
former employer.

---

From: WashamFan <[email-masked]>
Date: Sat, 31 Oct 2009 16:29:42 +0800

Hi,

>  > empty after this filtering, the resolution MUST stop with an error."

Please look at the example illustrated in section 5,  "turn:example.com"
URI turns out to be keeping UDP, TCP, and TLS.

washam

---

From: Marc Petit-Huguenin <[email-masked]>
Date: Sat, 31 Oct 2009 07:45:53 -0700

Hi Washam,

> URI turns out to be keeping UDP, TCP, and TLS.

The example is generated by my reference implementation.  After implementing the
new filtering rule, the I-D will automatically contain the correct text.  A new
I-D will be released as soon the blackout period is over (should be Monday 9th).

Thanks.