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

[Margaret Wasserman <mrw at lilacglade.org>]

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

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