[BEHAVE] TURN URI implicit processing [was Re: Opsdir Review of draft-ietf-behave-turn-uri-03.txt]

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

Margaret Wasserman wrote:
> 
> Hi Marc,
> 
> On Oct 25, 2009, at 3:03 PM, Marc Petit-Huguenin wrote:
>>>
>>> Were these tradeoffs discussed in the WG?
>>
>> No.
> 
> Do you think they should be?
>>
>>> 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.
> 
> 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.

So let's start the discussion.  What does the WG think of the current implicit
processing, and if it is not correct, what should it be?

If I receive no response asking for a change before November 9th, the next
version will contain the same implicit processing.

Thanks.

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