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

[Stefan Håkansson LK <[e-mail]>]

On 2014-02-03 16:41, Tirumaleswar Reddy (tireddy) wrote:
>> -----Original Message----- From: rtcweb
>> [mailto:[e-mail]] On Behalf Of Magnus Westerlund
>> Sent: Friday, January 31, 2014 2:32 PM To: Parthasarathi R; 'Cb B';
>> 'Simon Perreault' Cc: [e-mail] Subject: Re: [rtcweb]
>> Query/Comment on draft-ietf-rtcweb-use-cases-and- requirements-12
>>
>> Hi Partha,
>>
>> Personal opinion:
>>
>> I think the below places the text in the wrong context. The note is
>> in my mind relevant in the context of the general NAT/FW traversal
>> requirements, not the one discussing need to support multiple
>> NAT/FW traversal servers. Thus, I think Section 3.3.2 and thus
>> requirement F29. Or potentially regarding Requirement F2. Is more
>> appropriate places to include this.
>
> F29, F2 does not mention any NAT/FW traversal techniques. F29 just
> discusses the problems with NAT but IPv6 Firewalls could also be
> configured to block UDP traffic. F19 Requirement seems to be missing
> in the latest version.

F19 was removed to the -12 version when the following text was removed 
from the use-case "Video conferencing system with central server":


"The organization has an internal network set up with an aggressive 
firewall handling access to the Internet.  If users cannot physically 
access the internal network, they can establish a Virtual Private 
Network (VPN)."

Stefan

>
> -Tiru.
>
>>
>> Cheers
>>
>> Magnus
>>
>> On 2014-01-31 02:26, Parthasarathi R wrote:
>>> Hi Magnus,
>>>
>>> I can live with Simon text in case it is documented in Sec 4.2
>>> as
>>>
>>> F31     The browser must be able to use several STUN and TURN
>>> servers. Note that TURN support being mandatory does not preclude
>>> the browser from supporting additional traversal mechanisms.
>>> ----------------------------------------------------------------
>>> F32     There browser must support that STUN and TURN servers to
>>> use are supplied by other entities than via the web application
>>> (i.e. the network provider). Note that TURN support being
>>> mandatory does not preclude the browser from supporting
>>> additional traversal mechanisms.
>>>
>>> and also Appendix A:
>>>
>>> A22     The Web API must provide means for the application to
>>> specify several STUN and/or TURN servers to use. Note that TURN
>>> support being mandatory does not preclude a Web API from
>>> supporting additional traversal mechanisms.
>>>
>>> Please let me know in case you have any issue in the above text.
>>>
>>> BTW, just for the record,
>>> draft-ietf-rtcweb-use-cases-and-requirements-12 does not specify
>>> the list of traversal mechanism requirements for WebRTC
>>> Gateway/Server.
>>>
>>> Thanks Partha
>>>
>>>> -----Original Message----- From: Magnus Westerlund
>>>> [mailto:[e-mail]] Sent: Wednesday,
>>>> January 29, 2014 2:59 PM To: Parthasarathi R; 'Cb B'; 'Simon
>>>> Perreault' Cc: [e-mail] Subject: Re: [rtcweb]
>>>> Query/Comment on draft-ietf-rtcweb-use-cases-and-
>>>> requirements-12
>>>>
>>>> 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]
>>>> ---------------------------------------------------------------------
>>>>
>>>>
-
>>>
>>>
>>>
>>
>>
>> --
>>
>> 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]
>> ----------------------------------------------------------------------
>>
>>
>>
_______________________________________________
>> rtcweb mailing list [e-mail]
>> https://www.ietf.org/mailman/listinfo/rtcweb
> _______________________________________________ rtcweb mailing list
> [e-mail] https://www.ietf.org/mailman/listinfo/rtcweb
>