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

["Hutton, Andrew" <[e-mail]>]

Some comments in the text below.

As a general comment I suggest changing all the "FW" abbreviations to "Firewall" are have at least a first use definition.

Andy


> -----Original Message-----
> From: Magnus Westerlund [mailto:[e-mail]]
> Sent: 15 January 2014 10:20
> To: Chenxin (Xin); Hutton, Andrew; Christer Holmberg; Parthasarathi R;
> [e-mail]
> Subject: Re: [rtcweb] Query/Comment on draft-ietf-rtcweb-use-cases-and-
> requirements-12
> 
> 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.
> >
> > .

[AndyH] - I support this change.

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

[AndyH] - I support this change.

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

[AndyH] Yes the heading of 3.3.3 should have been changed during the last edit to "Simple Video Communication Service, FW that only allows traffic via a HTTP Proxy". I support this change.


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

[AndyH] I don't believe the intention here was to state a requirement that WebRTC media should be able to flow through a FW only allowing HTTP.  Therefore I think the original description is ok it is just the heading that needs to change. 


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

[AndyH] The existing text is in the 012 draft is ok and I don't think this change is needed as again I don't believe the intention here was to state a requirement that WebRTC media should be able to flow through a FW only allowing HTTP.


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

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