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

Hi Andy,

  I think you means F29 not F27:). When I read it , I realize that there is cross and ambiguous between 3.3.2 and 3.3.3

  More details:

  The topic of 3.3.2 is "Simple Video Communication Service, *NAT/FW* that blocks UDP". But in the description and requirement, only *NAT* is considered.

  The topic of 3.3.3 is "Simple Video Communication Service, FW that only allows http", But only *http proxy* deployed scenarios is considered.

  There are other usecases " FW block UDP, incoming TCP, Http allowing FW without http proxy deplolyed under the permission of FW policy" , which is lost in the description. If we need consider these usecases , I suggest to make some change to the description.

  Proposal 1 :

  add FW related words to section 3.3.2

-------------------------------------------------

3.3.2.  Simple Video Communication Service, NAT/FW that blocks UDP

3.3.2.1.  Description

   This use-case is almost identical to the Simple Video Communication

   Service use-case (Section 3.3.1).  The difference is that one of the

   users is behind a NAT*/FW* that blocks UDP traffic.

.

3.3.2.2.  Additional Requirements

   F29     The browser must be able to send streams and

           data to a peer in the presence of NATs *and FWs* that

           block UDP traffic ,* when FW policy allows WebRTC traffic*.

-------------------------------------------------------

   Proposal 2: If the" Http allowing FW without http proxy deployed" case is impliedly included in F29. I suggest to change the topics of 3.3.3 to "Simple Video Communication Service, FW that only allows traffic via a http proxy". So the 3.3.3 is a specific case.

    Proposal 3: If " Http allowing FW without http proxy deployed" case need to be explicitly mentioned. I suggest to add some descriptions to 3.3.3

-----------------------------------------------------------------

3.3.3.  Simple Video Communication Service, FW that only allows http

3.3.3.1.  Description

   This use-case is almost identical to the Simple Video Communication

   Service use-case (Section 3.3.1).  The difference is that one of the

   users is behind a http allowing FW or a FW that only allows traffic via a HTTP Proxy.

3.3.3.2.  Additional Requirements

   F37     The browser must be able to send streams and

           data to a peer in the presence of http allowing FWs or FWs that only

           allows traffic via a HTTP Proxy, when FW policy

           allows WebRTC traffic.

-------------------------------------------------------------------

Best Regards,

     Xin

>-----Original Message-----

>From: Hutton, Andrew [mailto:andrew.hutton@unify.com]

>Sent: Thursday, October 17, 2013 2:08 AM

>To: Christer Holmberg; Chenxin (Xin); Parthasarathi R; rtcweb@ietf.org

>Subject: RE: [rtcweb] Query/Comment on

>draft-ietf-rtcweb-use-cases-and-requirements-12

>

>Hi Xin,

>

>I see the PNTAW mailing list as being there to discuss potential solutions to

>these requirements which are documented in the use case draft.

>

>The requirement F37 is specific to the case when there is a HTTP Proxy and F27

>would include the case when there is no proxy.

>

>Do you see other use cases and requirements that need to be explicitly brought

>out in draft-ietf-rtcweb-use-cases-and-requirements?

>

>Regards

>Andy

>

>

>> -----Original Message-----

>> From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On

>> Behalf Of Christer Holmberg

>> Sent: 16 October 2013 10:32

>> To: Chenxin (Xin); Parthasarathi R; rtcweb@ietf.org

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

>> requirements-12

>>

>> Hi Xin,

>>

>> So, you are saying we shouldn't finalize the use-case-requirements

>> document yet?

>>

>> Regards,

>>

>> Christer

>>

>> -----Original Message-----

>> From: Chenxin (Xin) [mailto:hangzhou.chenxin@huawei.com]

>> Sent: 16. lokakuuta 2013 12:28

>> To: Christer Holmberg; Parthasarathi R; rtcweb@ietf.org

>> Subject: RE: [rtcweb] Query/Comment on draft-ietf-rtcweb-use-cases-and-

>> requirements-12

>>

>> Hi Christer,

>>

>> >Hi,

>> >

>> >>  +1. I think we should wait for the result of PNTAW@ietf.org

>> >> discussion

>> >before modifying the related use case and requirement. there seems no

>> >clear consensus by now.

>> >>

>> >>  The related use case is 3.3.2 , F29 , 3.3.3 and F37.

>> >

>> >Consensus on what?

>>

>> Should we just consider the case that " one of the users is behind a FW

>> that only allows traffic via a HTTP Proxy "? what will happen if there

>> is no http proxy deployed?

>>

>> There are two options to solve this usecase discussed in PNTAW mailing

>> list. "5)UDP relay candidates via some HTTP/TLS compatible transport

>> (TURN) - MUST/SHOULD (TLS via HTTP CONNET or TURN over WebSockets

>have

>> been proposed."  List in http://www.ietf.org/mail-

>> archive/web/pntaw/current/msg00162.html

>> Also there is other discussions in http://www.ietf.org/mail-

>> archive/web/pntaw/current/msg00166.html.

>>

>> That all mention that we should consider more than the http proxy

>> scenarios.

>>

>> I believe that the PNTAW mailing list is used for discussion of these

>> similar transport problems, including the related use case and

>> requirement. In the end , some consensus should be make to decide what

>> problem we need handle and how to solve it , which will influence the

>> use case and requirement to make it more clear.  Is my thought right?

>> Or miss something...

>>

>> Best Regards,

>>      Xin

>> >

>> >Note that the draft is only talking about requirements.

>> >

>> >Regards,

>> >

>> >Christer

>> >

>> >

>> >>-----Original Message-----

>> >>From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On

>> >>Behalf Of Parthasarathi R

>> >>Sent: Tuesday, October 15, 2013 3:15 AM

>> >>To: 'Christer Holmberg'; rtcweb@ietf.org

>> >>Subject: [rtcweb] Query/Comment on

>> >>draft-ietf-rtcweb-use-cases-and-requirements-12

>> >>

>> >>Hi Christer & all,

>> >>

>> >>In PNTAW mailing list, there is a discussion on firewall blocking

>> >>incoming TCP traffic when the firewall blocks UDP or allows only HTTP

>> >>traffic. The related link is

>> >>http://www.ietf.org/mail-archive/web/pntaw/current/msg00166.html.

>> >>

>> >>Could you please clarify whether F29 & F37 requirement implicitly

>> >>indicates that incoming TCP/HTTP traffic is blocked for browser when

>> >>these requirements are met. If so, Please update the below

>> requirement

>> >>text with those details.

>> >>

>> >>Thanks

>> >>Partha

>> >>

>> >>Note:

>> >>

>> >>----------------------------------------------------------------

>> >>   F29     The browser must be able to send streams and

>> >>           data to a peer in the presence of NATs that

>> >>           block UDP traffic.

>> >>

>> >>----------------------------------------------------------------

>> >>  F37     The browser must be able to send streams and

>> >>           data to a peer in the presence of FWs that only

>> >>           allows traffic via a HTTP Proxy, when FW policy

>> >>           allows WebRTC traffic.

>> >>

>> >>_______________________________________________

>> >>rtcweb mailing list

>> >>rtcweb@ietf.org

>> >>https://www.ietf.org/mailman/listinfo/rtcweb

>> _______________________________________________

>> rtcweb mailing list

>> rtcweb@ietf.org

>> https://www.ietf.org/mailman/listinfo/rtcweb