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

["Tirumaleswar Reddy (tireddy)" <[e-mail]>]

> -----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.

-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