Re: [rtcweb] WGLC of draft-ietf-rtcweb-use-cases-and-requirements-11

[Bernard Aboba <[e-mail]>]

I agree with Magnus's comments in large part.  A few notes: 

> 1. First of all I like to bring up a document structure problem. When
> reviewing this it is difficult to follow what requirements that are
> added for the different use cases. I would propose that each Use Case or
> general section that describe something that causes new requirements
> that hasn't been listed yet in the document to define the Requirement
> there....>> This makes the incremental use cases much more understandable in how> they add requirements.

[BA] +1 on this.  I found myself flipping back and forth between the requirements definition and the use cases to try to understand what the incremental functionality was and sometimes it was less than obvious why a requirement (such as "no wiretapping") was dropped from the basic use case.  To me, it makes more sense to lay out basic use cases, and then to focus on incremental requirement additions based on that.  
>    The document focuses on requirements related to real-time media
>    streams and data exchange.  Requirements related to privacy,
>    signalling between the browser and web server etc. are currently not
>    considered.
> 
> I think this needs to be rewritten. The draft actually do consider a
> number of high level security and privacy concerns.
[BA] I do think the document covers the security and privacy concerns (modulo some issues I had with the "wiretapping" definition).  So I think we can eliminate that last sentence entirely. 
>    It is essential that the communication cannot be wiretapped
>    [RFC2804].
> 
> This sentence returns a number of times in this document. I think it is
> a general security requirement that applies to probably all of the use
> cases. If there is one use case that don't need to enable protection
> against this, then please be explicit about that.>> My Suggestion is to move this into the general considerations section.

[BA] There is a use case ("distributed music band") that omits the requirement, but that omission didn't make sense to me.  Personally, I would elevate this to a universal requirement in the base use case, and all other cases. 
>    One user has an unreliable Internet connection.  It sometimes loses
>    packets, and sometimes goes down completely.
> 
> I guess the requirement here is to handle this in a graceful way from
> media transport and rendering perspective. The packet loss is also
> unclear as I don't know if the intention is to capture spurious packet
> losses due to the link media, or congestion losses. I think some
> expansion of this is needed.

[BA] To me, connectivity loss and packet loss are somewhat different issues.  Connectivity loss leads to addition of requirements relating to keep-alives and/or consent (e.g. if the peer drops off the Internet, the consent mechanism will detect it eventually and stop sending).   Packet loss leads to requirements relating to concealment, FEC and/or RTX.  So lumping them together doesn't make sense to me.  > 3.2.2.2.  Derived Requirements
> 
>    F1, F2, F3, F4, F5, F8, F9, F10, F20, F25, F28, F29
> 
>    A1, A2, A3, A4, A5, A6, A7, A8, A9, A10, A11, A12
> 
> How come this list of Derived Requirements are shorter than for the
> parent use case which has the following list:

[BA] Yes, that didn't make sense to me either.  Better to stick with the requirements of the base case and add to them as necessary for more advanced cases.  If something is deleted, I think the document needs to explain why, but in this case the deletions didn't make sense to me. 
> 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?

[BA]  Data traffic sent as SCTP/DTLS/UDP will *not* work in this case.  Websockets might, but then I think you need to clarify whether "HTTP only" includes websockets (in my experience, in most cases it won't). 
>    But in addition to this, one of the users can share what is being
>    displayed on her/his screen with a peer.  The user can choose to
>    share the entire screen, part of the screen (part selected by the
>    user) or what a selected applicaton displays with the peer.
> 
> Does this needs mentioning of additional high level security requirements?

[BA]  The requirements may need to be *very* high level (e.g. "without introducing other vulnerabilities"), because this is a tricky area that may end up requiring significant work. 
> 12. Section 3.2.10.1:
> 
>   The service providers are interconnected by some means, but exchange
>    no more information about the users than what can be carried using
>    SIP.
> 
>    NOTE: More profiling of what this means may be needed.
> 
> The Note, can it be removed, or do we need additional text in this document?
[BA] The NOTE tells me that we're not even really sure why this section is there.  So perhaps we should figure out what it adds above and beyond the gateway use case.