Re: [rtcweb] Query/Comment on draft-ietf-rtcweb-use-cases-and-requirements-12

[Magnus Westerlund <[e-mail]>]

Hi Partha and WG,

I don't see any support for the changes you proposes in this discussion.
What I see some support for is to add a statement making clear that
there might be additional NAT/Firewall traversal mechanisms than
STUN/TURN. Simon proposed:

"Note that TURN support being mandatory does not preclude a WebRTC
 endpoint from supporting additional traversal mechanisms."

However, looking at the document as it is currently written, I am
uncertain where this would be added. The first mention of TURN is in
Section 3.3.4.1, and that section is focused on the global service
provider perspective and the need for location based provisioning of
NAT/Firewall traversal server resources.

I think it can be added to Section 3.3.5.1 without being misplaced, but
it would be given a slightly narrower scope.

I any of you want to be more explicit where this should be included,
please be. If you are not forthcoming I will request the authors to add
this in what they consider sensible position.

Cheers

Magnus


On 2014-01-25 17:46, Parthasarathi R wrote:
> Hi Simon,
> 
>  
> 
> Thanks for your understanding about my firewall/NAT related problem
> statement in this draft.
> 
>  
> 
> I have proposed the firewall/NAT related text by which the specific
> mechanism is not highlighted in the requirement document as there is no
> WG consensus for any of the mechanism including TURN. It is possible to
> argue hypothetically in PNTAW alias that PCP is the only mechanism
> required in WebRTC endpoint.   Also, I’m more interested in WebRTC
> gateway/server (Sec 4.3. of
> draft-ietf-rtcweb-use-cases-and-requirements-12) requirements wherein it
> is not required to support TURN and the related mail thread is
> http://www.ietf.org/mail-archive/web/pntaw/current/msg00181.html.
> 
>  
> 
> IMO, my proposed text without mentioning any firewall/NAT mechanism in
> the requirement document helps to move forward without depend on the
> solution discussion in PNTAW alias.
> 
>  
> 
> Thanks
> 
> Partha
> 
>  
> 
> *From:*Cb B [mailto:[e-mail]]
> *Sent:* Saturday, January 25, 2014 6:22 AM
> *To:* Simon Perreault
> *Cc:* [e-mail]; Parthasarathi R
> *Subject:* Re: [rtcweb] Query/Comment on
> draft-ietf-rtcweb-use-cases-and-requirements-12
> 
>  
> 
> 
> On Jan 24, 2014 10:17 AM, "Simon Perreault" <[e-mail]
> <mailto:[e-mail]>> wrote:
>>
>> Le 2014-01-24 12:14, Parthasarathi R a écrit :
>>
>>> Please note that when non-IETFers read this requirement document,
> they come
>>> to the conclusion that IETF RTCWeb WG recommends TURN and not other
>>> mechanisms. I'm saying that requirement document should not be used
> as the
>>> mechanism to eliminate the other alternatives when there is a discussion
>>> going-on in PNTAW alias. So, I'm asking for the change.
>>
>>
>> I would totally agree with that sentiment, although I don't see your
> proposed text change reflecting it accurately. How about simply:
>>
>> "Note that TURN support being mandatory does not preclude a WebRTC
> endpoint from supporting additional traversal mechanisms."
>>
>>
> 
> +1 for the above text.
> 
> CB
> 
>> Simon
>> --
>> DTN made easy, lean, and smart --> http://postellation.viagenie.ca
>> NAT64/DNS64 open-source        --> http://ecdysis.viagenie.ca
>> STUN/TURN server               --> http://numb.viagenie.ca
>> _______________________________________________
>> rtcweb mailing list
>> [e-mail] <mailto:[e-mail]>
>> https://www.ietf.org/mailman/listinfo/rtcweb
> 
> 
> 
> _______________________________________________
> rtcweb mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/rtcweb
> 


-- 

Magnus Westerlund

----------------------------------------------------------------------
Services, Media and Network features, Ericsson Research EAB/TXM
----------------------------------------------------------------------
Ericsson AB                 | Phone  [phone]
Färögatan 6                 | Mobile [phone]
SE-164 80 Stockholm, Sweden | mailto: [e-mail]
----------------------------------------------------------------------