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

From: "Tirumaleswar Reddy (tireddy)" <[email-masked]>
Date: Mon, 3 Feb 2014 15:41:28 +0000

> -----Original Message-----
> From: rtcweb [mailto:[email-masked]] On Behalf Of Magnus
> Westerlund
> Sent: Friday, January 31, 2014 2:32 PM
> To: Parthasarathi R; 'Cb B'; 'Simon Perreault'
> Cc: [email-masked]
> 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.

-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:[email-masked]]
> >> Sent: Wednesday, January 29, 2014 2:59 PM
> >> To: Parthasarathi R; 'Cb B'; 'Simon Perreault'
> >> Cc: [email-masked]
> >> 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:[email-masked]]
> >>> *Sent:* Saturday, January 25, 2014 6:22 AM
> >>> *To:* Simon Perreault
> >>> *Cc:* [email-masked]; 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"
> >> <[email-masked]
> >>> <mailto:[email-masked]>> 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
> >>>> [email-masked] <mailto:[email-masked]>
> >>>> https://www.ietf.org/mailman/listinfo/rtcweb
> >>>
> >>>
> >>>
> >>> _______________________________________________
> >>> rtcweb mailing list
> >>> [email-masked]
> >>> https://www.ietf.org/mailman/listinfo/rtcweb
> >>>
> >>
> >>
> >> --
> >>
> >> Magnus Westerlund
> >>
> >> ---------------------------------------------------------------------
> >> - Services, Media and Network features, Ericsson Research EAB/TXM
> >> ----------------------------------------------------------------------
> >> Ericsson AB                 | Phone  +46 10 7148287
> >> Färögatan 6                 | Mobile +46 73 0949079
> >> SE-164 80 Stockholm, Sweden | mailto:
> [email-masked]
> >> ---------------------------------------------------------------------
> >> -
> >
> >
> >
> 
> 
> --
> 
> Magnus Westerlund
> 
> ----------------------------------------------------------------------
> Services, Media and Network features, Ericsson Research EAB/TXM
> ----------------------------------------------------------------------
> Ericsson AB                 | Phone  +46 10 7148287
> Färögatan 6                 | Mobile +46 73 0949079
> SE-164 80 Stockholm, Sweden | mailto: [email-masked]
> ----------------------------------------------------------------------
> 
> _______________________________________________
> rtcweb mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/rtcweb

---

From: Stefan Håkansson LK <[email-masked]>
Date: Mon, 10 Feb 2014 10:56:37 +0000

On 2014-02-03 16:41, Tirumaleswar Reddy (tireddy) wrote:
>> -----Original Message----- From: rtcweb
>> [mailto:[email-masked]] On Behalf Of Magnus Westerlund
>> Sent: Friday, January 31, 2014 2:32 PM To: Parthasarathi R; 'Cb B';
>> 'Simon Perreault' Cc: [email-masked] 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

>>> 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
>>> 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.
>>>
>>> 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:[email-masked]] Sent: Wednesday,
>>>> January 29, 2014 2:59 PM To: Parthasarathi R; 'Cb B'; 'Simon
>>>> Perreault' Cc: [email-masked] Subject: Re: [rtcweb]
>>>> Query/Comment on draft-ietf-rtcweb-use-cases-and-
>>>> requirements-12
>>>>
>>>> Hi Partha and WG,
>>>>
>>>> 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:
>>>>
>>>> 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
>>>>
>>>>
>>>>> 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
>>>>> 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
>>>>> *From:*Cb B [mailto:[email-masked]] *Sent:* Saturday,
>>>>> January 25, 2014 6:22 AM *To:* Simon Perreault *Cc:*
>>>>> [email-masked]; Parthasarathi R *Subject:* Re: [rtcweb]
>>>>> Query/Comment on
>>>>>>> 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
>>>>>> I would totally agree with that sentiment, although I don't
>>>>>> see your
>>>>>> 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 [email-masked] <mailto:[email-masked]>
>>>>> _______________________________________________ rtcweb
>>>>> mailing list [email-masked]
>>>> Färögatan 6                 | Mobile +46 73 0949079 SE-164 80
>>>> Stockholm, Sweden | mailto:
-
>> Färögatan 6                 | Mobile +46 73 0949079 SE-164 80
>> Stockholm, Sweden | mailto: [email-masked]
>> rtcweb mailing list [email-masked]
> _______________________________________________ rtcweb mailing list
> [email-masked] https://www.ietf.org/mailman/listinfo/rtcweb
>

---

From: Magnus Westerlund <[email-masked]>
Date: Mon, 10 Feb 2014 13:34:36 +0100

> configured to block UDP traffic. F19 Requirement seems to be missing

Regarding F29 and F2, that is the benefit of having solution neutral
requirements. Thus, these requirements are not blocking or hindering you
from proposing additional solutions or implementation requirements when
it comes to NAT/FW traversal. Thus, these requirements applies to UDP
blocking IPv6 firewalls as well as other types.

cheers

Magnus Westerlund