Re: [BEHAVE] DISCUSS: draft-ietf-behave-turn

[Brian E Carpenter <[e-mail]>]

I was the Gen-ART reviewer whoes review led to Russ's comment.
So...

On 2009-04-08 16:01, Philip Matthews wrote:
> 
> On Sat, 4-Apr-09, at 16:09 , Russ Housley wrote:
> 
>> Discuss:
>>
>>  The IAB Considerations in RFC 3424 have not been changed, and it
>>  is clear to me that TURN has an indefinite lifetime.  So, the first
>>  two IAB UNSAF criteria cannot realistically be satisfied.  I do not
>>  want to delay the document, but I do think it should include a
>>  recognition of this conflict.  I'm happy with an IESG note or text
>>  in the body of the document.
>>
> 
> Actually, RFC 3424 only very tangentially applies to TURN, since TURN is
> just a protocol for controlling a relay. RFC 3424  applies to STUN and
> ICE much more directly.
> 
> Consideration 1 simply asks for a precise definition of the problem that
> TURN fixes, so I don't see what else can be said here.

Actually it specifically says "A short term fix should not be generalized
to solve other problems." and the TURN draft says

>    ...However, care has been taken to
>    make sure that TURN is suitable for other types of applications

Reading those two statements gave me a little cognitive dissonance.
Maybe you can add something like

Note that although TURN can be applied beyond the domain of SIP
usage, it can only satisfy these limited purposes.

However, this isn't a big deal IMHO.

> 
> However, Consideration 2 asks for an exit strategy or transition plan.
> Here I have changed the text of the response to Consideration 2 to read:
> 
>     Response: TURN will no longer be needed once there are no longer
>     any NATs.  Unfortunately, as of the date of publication of this
>     document, it no longer seems very likely that NATs will go away
>     any time soon. However, the need for TURN will also decrease as
>     the number of NATs with the mapping property of Endpoint-Independent
>     Mapping [RFC4787] increases.

Works for me.

    Brian