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

[Marc Petit-Huguenin <petithug at acm.org>]

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

Margaret Wasserman wrote:
> 
> Hi Marc,
> 
> I have some further questions about your last e-mail.  Sorry for not
> including them in the previous message...
> 
> On Oct 25, 2009, at 3:03 PM, Marc Petit-Huguenin wrote:
>>
>> 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.
> 
> 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...

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

-- 
Marc Petit-Huguenin
Personal email: marc at petit-huguenin.org
Professional email: petithug at acm.org
Blog: http://blog.marc.petit-huguenin.org