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

[Christer Holmberg <[e-mail]>]

Hi,

I have submitted a new version (-12) of the use-case-requirements draft. The draft implements the changes due to the WGLC comments.

Below is an e-mail which describes the changes (indicated by the "V-12" prefix), based on the comments that Magnus gave (also taking into consideration the comments given by Bernard A and Andrew H).

NOTE: Based on the comments, some text has been removed (as indicated below), so I ask people to take a look at the draft.

Regards,

Christer


-----------------------------------------


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

V-12: I now define the requirements retrieved from the "Simple Video Communication Service" use-case as common. Then, for each additional use-case, I only list the additional requirement(s) retrieved from that use-case.


----------------------------------------------------------------


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

V-12: Paragraph removed, as suggested by Bernard A.


----------------------------------------------------------------


> 3. Section 2:
>
> If you have no definitions, do remove the section, rather then leaving it TBD.

V-12: Section removed.


----------------------------------------------------------------


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

V-12: The bullets above are removed, and replaced with a bullet saying: "Clients can be connected to networks with different throughput capabilities".


----------------------------------------------------------------


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

V-12: The bullet above is modified as suggested.


----------------------------------------------------------------


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

V-12: The sentence is removed from sections 3.2.11, 3.2.11.1, 3.2.12.1, 3.2.13.1, 3.3.1.1 and 3.3.3.1. No new requirement is needed, as it is already covered by requirement F20.


----------------------------------------------------------------


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

V-12: The sentence is removed, as it is covered by requirement F36.


----------------------------------------------------------------


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

V-12: Sentence removed. Covered by requirement F5.


----------------------------------------------------------------


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

V-12: The sentence is removed.


----------------------------------------------------------------


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

V-12: As indicated earlier, I now define the requirements retrieved from the "Simple Video Communication Service" use-case as common. Then, for each additional use-case, I only list the additional requirement(s) retrieved from that use-case.


----------------------------------------------------------------


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


----------------------------------------------------------------


>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?
                                                                                                                                          
V-12: No change was done based on this comment.


----------------------------------------------------------------


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

V-12: Note removed.


----------------------------------------------------------------


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

V-12: Section removed. As indicated by Bernard A, the note indicates that the purpose of the section is unclear. Requirements not affected.


----------------------------------------------------------------


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

V-12: Text is modified to:

		"Before the game starts, and during game breaks, the talent scout and
		the manager have a 1-1 audiovisual communication session. On the mobile phone,
		only the camera facing the talent scout is used. On the user 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)."


----------------------------------------------------------------


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

V-12: Section removed. Requirements not affected.


----------------------------------------------------------------


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

V-12: Added "Interactive Voice Responder (IVR)" on first occurrence.


----------------------------------------------------------------


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

V-12: Paragraph removed.


----------------------------------------------------------------


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

V-12: No change done in section 3.3.3.1. Covered by the change done based on comment 10).


----------------------------------------------------------------


> 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"?

V-12: "level" replaced with "voice activity level".


----------------------------------------------------------------


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

V-12: Requirement removed. Can only think of firewall traversal, which are covered by requirement F37.

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


----------------------------------------------------------------


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

V-12: No need for changes were identified.


----------------------------------------------------------------


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


----------------------------------------------------------------


> 23. Section 5:
>
> Change the TBD to a statement that there are no IANA actions in this document.

V-12: Done.


----------------------------------------------------------------


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

V-12: No changes based on this comment.


----------------------------------------------------------------


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

V-12: I have no idea. Use-case removed.

http://www.ietf.org/mail-archive/web/rtcweb/current/msg04461.html


----------------------------------------------------------------


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

V-12: Done.


----------------------------------------------------------------


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

V-12: Done.


----------------------------------------------------------------

Regards,

Christer