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

[Magnus Westerlund <[e-mail]>]

Hi,

I have reviewed the Use Case and Requirements draft (v11) in the WG last
call. I have the following comments on this document. I have found a
number of issues that I definitely needs to be fixed prior to any
publication request.


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. Something like this:

3.2.2.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 NAT that blocks UDP traffic.

3.2.2.2.  Derived Requirements

   F1, F2, F3, F4, F5, F8, F9, F10, F20, F25, F28

   A1, A2, A3, A4, A5, A6, A7, A8, A9, A10, A11, A12

   New Requirement:

   F29     The browser must be able to send streams and
           data to a peer in the presence of NATs that
           block UDP traffic.


This makes the incremental use cases much more understandable in how
they add requirements.

This I think will also affect Section 3.1 which will need to include the
requirement definitions created by these general considerations.

However, I do suggest that you leave the collection of all requirements
in place for easy reference.

2. Section 1:

   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.

3. Section 2:

If you have no definitions, do remove the section, rather then leaving
it TBD.

4. Section 3.1

   o  Clients can be on wideband (10s of Mbits/sec)

   o  Clients can be on narrowband (10s to 100s of Kbits/sec)

Due to the usage of the terms wideband and narrowband I think you need
to be more explicit about what is actually referred to here. My
assumption is network throughput capability. And in these cases maybe
expressing this explicitly is a better choice.

5. Section 3.1:

   o  Clients can be on networks with any type (as described in RFC4787)
      of NAT.

I think "any type" is unclear here, as there are no types defined in
that RFC unless you are trying to express the difference between basic
NAT and NAPT, which I don't believe you are. I think you should use
something like this:

   o  Clients can be on networks with a NAT using any type of Mapping
      and Filtering behaviors (as described in RFC4787).

6. Section 3.2.1.1:

   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.

7. Section 3.2.1.1:

   In addition, it is required that browsers enable the media and data
   security keys to be cryptographically bound to the user identity.

I think this sentence is actually subtly wrong in a couple of ways.
First of all it talks about "the identity", where I think it should be
talking about "a identity". This can both the human users identity, but
also a role identity, like Police Officer.

Secondly, binding it to  the security keys without putting requirements
on the keying and key-exchange mechanism to prevent man in the middles
empties this requirement. I would recommend that you reformulate this to
a high level requirement without going into mechanism. For example:

In addition, it is required that browsers enables binding an identity of
the user's choice to his end of the secured communication and that such
mechanism prevent man in the middle attacks.

8. Section 3.2.1.1

   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.

9. Section 3.2.1.1:

   One user is located behind a Network Address Translator (NAT).

What is the point being stressed here that isn't covered by the general
consideration in 3.1 that says:

   o  Clients can be on networks with any type (as described in RFC4787)
      of NAT.

Section 3.2.2.2:

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:

3.2.1.2.  Derived Requirements

   F1, F2, F3, F4, F5, F8, F9, F10, F20, F25, F28, F35, F36, F38, F39

   A1, A2, A3, A4, A5, A6, A7, A8, A9, A10, A11, A12, A25, A26


If each use case is listing all the requirement then it needs to be
consistently done and actually list all that applies. If there are
requirements from the parent that doesn't apply that may even be worth
explicitly mentioning.

This comments applies to all use cases as there appears to be general
inconsistencies.

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.

11. Section 3.2.8.1:

   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?

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?

13. Section 3.2.10.1:

   The same issues with connectivity apply.

I don't understand this comment. What is it intended to refer to?

14. Section 3.2.11.1:

   Before the game starts, and during game breaks, the talent scout and
   the manager have a 1-1 audiovisual communication session.  Only the
   rear facing camera of the mobile phone is used.  On the display of
   the mobile phone, the video of the club manager is shown with a
   picture-in-picture thumbnail of the rear facing camera (self-view).
   On the display of the desktop, the video of the talent scout is shown
   with a picture-in-picture thumbnail of the desktop camera (self-
   view).

I get a bit confused with what is the front and rear of my smart phone.
I would consider the display side the front side, and the rear the other
big side of my block shaped mobile phone. I suggest using other terms.

15. Section 3.2.14.1:

   Discussion: This use-case was briefly discussed at the Quebec webrtc
   meeting and it got support.  So far the only concrete requirement
   (A17) derived is that the application must be able to ask the browser
   to treat the audio signal as audio (in contrast to speech).  However,
   the use case should be further analysed to determine other
   requirements (could be e.g. on delay mic->speaker, level control of
   audio signals, etc.).

I think this Discussion points needs to be dealt with before we can
publish this document. I would consider the question if this needs more
analysis a open issue.

16. Section 3.3.2.1:

   Alice uses her web browser with a service that allows her to call
   PSTN numbers.  Alice calls 1-800-gofedex.  Alice should be able to
   hear the initial prompts from the fedex IVR and when the IVR says
   press 1, there should be a way for Alice to navigate the IVR.

Can you please expand IVR.

17. Section 3.3.3.1:

   The organization has an internal network set up with an aggressive
   firewall handling access to the Internet.  If users cannot physically
   access the internal network, they can establish a Virtual Private
   Network (VPN).

I think the requirements or limitations the above paragraph try to
express is not clear. There is some missing assumptions of location of
server related to clients that is not covered. Thus it is not clear what
requirements this results in.

Can you please expand this to something that is understandable.

18. Section 3.3.3.1:

   This use-case adds requirements on support for fast stream
   switches F7, on encryption of media and on ability to traverse very
   restrictive FWs.

Regarding the restricted FWs, my comment 10) applies to also this comment.

19. Section 4.2:

   F14     The browser must be able to measure the level

   F15     The browser must be able to change the level
           in audio streams.


Can you please make explicit what type level you think should be
measured or changed, energy, "voice activity"?

20. Section 4.2

  F19     Streams and data must be able to pass through
           limited middleboxes.

What type of limitations are you considering in this requirement?

21. Section 4.2

I note that F30, and F36 may be affected by earlier comments on the
underlying reason for these requirements and need additional text or
clarifications.

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 allos WebRTC traffic.

23. Section 5:

Change the TBD to a statement that there are no IANA actions in this
document.

24. Section 6.2:

These security considerations are really security requirements on the
browser or the API. I don't know if would be better to move them to
relevant use case sections, or leave them in place.

25. Section 7:

   13.  Enable company coop without being able to decipher http://
        www.ietf.org/mail-archive/web/rtcweb/current/msg04461.html

What is "coop" in the above?


26. Please run a spell checker on the document prior to submitting the
update.


27. Ensure that the ID nits issues are not real issues:

  == Line 667 has weird spacing: '...resence  of NA...'

  == Line 785 has weird spacing: '...of that  strea...'


Cheers

Magnus Westerlund

----------------------------------------------------------------------
Multimedia Technologies, Ericsson Research EAB/TVM
----------------------------------------------------------------------
Ericsson AB                | Phone  [phone]
Färögatan 6                | Mobile [phone]
SE-164 80 Stockholm, Sweden| mailto: [e-mail]
----------------------------------------------------------------------