Re: [rtcweb] Draft new version: draft-ietf-rtcweb-use-cases-and-requirements-12 - WGLC comments implemented

["Rauschenbach, Uwe (NSN - DE/Munich)" <[e-mail]>]

Hi Christer,

A nit: shouldn't the two requirements below mention "receive" as well?
 
Kind regards,
Uwe

 
> ----------------------------------------------------------------
> 
> 
> > 10. Section 3.2.3.1:
> >
> >
> > 3.2.3.1.  Description
> >
> >   This use-case is almost identical to the Simple Video Communication
> >   Service use-case (Section 3.2.1).  The difference is that one of the
> >   users is behind a FW that only allows http traffic.
> >
> > If a firewall only allows HTTP traffic, then can we really assume that
> the firewall administrator per default will accept WebRTC Media and Data
> traffic?
> >
> > I am far from certain of this, and think on a requirement level needs
> to express a situation where the firewall administrator allows WebRTC
> across its FW, or at least can easily configure a rule to block it. Thus
> resulting in that any solution for this needs to be easily identifiable
> and possible to block.
> >
> > See also [e-mail] mailing list.
> 
> V-12: The sentence starting with "The difference..." is replaced by "The
> difference is that one of the users is behind a FW that only allows
> traffic via a HTTP Proxy.", as suggested by Andrew H.
> 
> Requirement F37 is modified to:
> 
>                        "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."


[skipping ...]

> ----------------------------------------------------------------
> 
> 
> > 22. Section 4.2:
> >   F37     The browser must be able to send streams and
> >          data to a peer in the presence of FWs that only
> >          allows http(s) traffic.
> >
> > I think this requirement should have a caveat along the lines: when FW
> policy allows WebRTC traffic.
> 
> V-12: Caveat added.
> 
>                              "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."
> 
>