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

[Magnus Westerlund <[e-mail]>]

WG,

It has been quite some time since the WG last call ended and a new
revision was submitted. As Document Shepherd I want to push this
document to publication request.

Chenxin proposed below three different sets of changes to the document.
Does the WG support making these changes? Please indicate within the
next week if you support or want to reject these changes.

Thanks

Magnus


On 2013-10-17 12:23, Chenxin (Xin) wrote:
> 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
> 
>  
> 


-- 

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