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

From: Christer Holmberg <[email-masked]>
Date: Mon, 14 Oct 2013 09:35:59 +0000

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 [email-masked] 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

---

From: "Rauschenbach, Uwe (NSN - DE/Munich)" <[email-masked]>
Date: Mon, 14 Oct 2013 12:52:41 +0000

Hi Christer,

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

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

[skipping ...]

---

From: Christer Holmberg <[email-masked]>
Date: Mon, 14 Oct 2013 12:58:41 +0000

Hi Uwe,

I guess you are right. I'll fix that in the next version.

Thanks!

Regards,

Christer

-----Original Message-----
From: Rauschenbach, Uwe (NSN - DE/Munich) [mailto:[email-masked]] 
Sent: 14. lokakuuta 2013 15:53
To: Christer Holmberg; [email-masked]
Subject: RE: [rtcweb] Draft new version: draft-ietf-rtcweb-use-cases-and-requirements-12 - WGLC comments implemented

Hi Christer,

Kind regards,
Uwe

> the firewall administrator per default will accept WebRTC Media and 
> Data traffic?
> >
> 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.
> >
> 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.
> 

[skipping ...]

> > I think this requirement should have a caveat along the lines: when 
> > FW
> policy allows WebRTC traffic.
> 
> V-12: Caveat added.
>

---

From: "Parthasarathi R" <[email-masked]>
Date: Tue, 15 Oct 2013 00:45:01 +0530

Hi Christer & all,

In PNTAW mailing list, there is a discussion on firewall blocking incoming
TCP traffic when the firewall blocks UDP or allows only HTTP traffic. The
related link is
http://www.ietf.org/mail-archive/web/pntaw/current/msg00166.html.

Could you please clarify whether F29 & F37 requirement implicitly indicates
that incoming TCP/HTTP traffic is blocked for browser when these
requirements are met. If so, Please update the below requirement text with
those details.

Thanks
Partha

Note:

           allows WebRTC traffic.

---

From: "Chenxin (Xin)" <[email-masked]>
Date: Wed, 16 Oct 2013 06:04:15 +0000

Hi Christer,

  +1. I think we should wait for the result of [email-masked] discussion before modifying the related use case and requirement. there seems no clear consensus by now. 

  The related use case is 3.3.2 , F29 , 3.3.3 and F37.

Best Regards,
     Xin 

>From: [email-masked] [mailto:[email-masked]] On Behalf Of
>Parthasarathi R
>Sent: Tuesday, October 15, 2013 3:15 AM
>To: 'Christer Holmberg'; [email-masked]
>Subject: [rtcweb] Query/Comment on
>draft-ietf-rtcweb-use-cases-and-requirements-12
>
>Hi Christer & all,
>
>_______________________________________________
>rtcweb mailing list
>[email-masked]
>https://www.ietf.org/mailman/listinfo/rtcweb

---

From: Christer Holmberg <[email-masked]>
Date: Wed, 16 Oct 2013 08:02:20 +0000

Hi,

>  The related use case is 3.3.2 , F29 , 3.3.3 and F37.

Consensus on what?

Note that the draft is only talking about requirements.

Regards,

Christer

>From: [email-masked] [mailto:[email-masked]] On 
>Behalf Of Parthasarathi R
>In PNTAW mailing list, there is a discussion on firewall blocking 
>incoming TCP traffic when the firewall blocks UDP or allows only HTTP 
>traffic. The related link is 
>Could you please clarify whether F29 & F37 requirement implicitly 
>indicates that incoming TCP/HTTP traffic is blocked for browser when 
>these requirements are met. If so, Please update the below requirement 
>text with those details.
>
>Thanks
>Partha
>
>Note:
>

---

From: "Chenxin (Xin)" <[email-masked]>
Date: Wed, 16 Oct 2013 09:28:13 +0000

Hi Christer,

>Hi,
>
>>  +1. I think we should wait for the result of [email-masked] discussion
>before modifying the related use case and requirement. there seems no clear
>consensus by now.
>>

Should we just consider the case that " one of the users is behind a FW that only allows traffic via a HTTP Proxy "? what will happen if there is no http proxy deployed? 

There are two options to solve this usecase discussed in PNTAW mailing list. "5)UDP relay candidates via some HTTP/TLS compatible transport (TURN) - MUST/SHOULD (TLS via HTTP CONNET or TURN over WebSockets have been proposed."  List in http://www.ietf.org/mail-archive/web/pntaw/current/msg00162.html
Also there is other discussions in http://www.ietf.org/mail-archive/web/pntaw/current/msg00166.html. 

That all mention that we should consider more than the http proxy scenarios. 

I believe that the PNTAW mailing list is used for discussion of these similar transport problems, including the related use case and requirement. In the end , some consensus should be make to decide what problem we need handle and how to solve it , which will influence the use case and requirement to make it more clear.  Is my thought right? Or miss something...

Best Regards,
     Xin

---

From: Christer Holmberg <[email-masked]>
Date: Wed, 16 Oct 2013 09:32:16 +0000

Hi Xin,

So, you are saying we shouldn't finalize the use-case-requirements document yet?

Regards,

Christer

-----Original Message-----
From: Chenxin (Xin) [mailto:[email-masked]] 
Sent: 16. lokakuuta 2013 12:28
To: Christer Holmberg; Parthasarathi R; [email-masked]
Subject: RE: [rtcweb] Query/Comment on draft-ietf-rtcweb-use-cases-and-requirements-12

Hi Christer,

>before modifying the related use case and requirement. there seems no 
>clear consensus by now.
>>

Best Regards,
     Xin

---

From: "Hutton, Andrew" <[email-masked]>
Date: Wed, 16 Oct 2013 18:07:36 +0000

Hi Xin,

I see the PNTAW mailing list as being there to discuss potential solutions to these requirements which are documented in the use case draft.

The requirement F37 is specific to the case when there is a HTTP Proxy and F27 would include the case when there is no proxy.

Do you see other use cases and requirements that need to be explicitly brought out in draft-ietf-rtcweb-use-cases-and-requirements?

Regards
Andy

> Behalf Of Christer Holmberg
> Sent: 16 October 2013 10:32
> To: Chenxin (Xin); Parthasarathi R; [email-masked]
> Subject: Re: [rtcweb] Query/Comment on draft-ietf-rtcweb-use-cases-and-
> requirements-12
> 
> Hi Xin,
> 
> Should we just consider the case that " one of the users is behind a FW
> that only allows traffic via a HTTP Proxy "? what will happen if there
> is no http proxy deployed?
> 
> There are two options to solve this usecase discussed in PNTAW mailing
> list. "5)UDP relay candidates via some HTTP/TLS compatible transport
> (TURN) - MUST/SHOULD (TLS via HTTP CONNET or TURN over WebSockets have
> been proposed."  List in http://www.ietf.org/mail-
> archive/web/pntaw/current/msg00162.html
> I believe that the PNTAW mailing list is used for discussion of these
> similar transport problems, including the related use case and
> requirement. In the end , some consensus should be make to decide what
> problem we need handle and how to solve it , which will influence the
> use case and requirement to make it more clear.  Is my thought right?
> Or miss something...
> 
> Best Regards,
>      Xin
> >

---

From: "Chenxin (Xin)" <[email-masked]>
Date: Thu, 17 Oct 2013 01:43:02 +0000

Hi Christer,

   That is not my purpose . I just want this document less ambiguous. I will try to figure out the things that need to consider in the use case and requirement based on the discussion in the pntaw. so we could decide if it is need to add ,modify or just keep .

Best Regards,
     Xin 

>From: Christer Holmberg [mailto:[email-masked]]
>Sent: Wednesday, October 16, 2013 5:32 PM
>Subject: RE: [rtcweb] Query/Comment on
>Subject: RE: [rtcweb] Query/Comment on
>Should we just consider the case that " one of the users is behind a FW that only
>allows traffic via a HTTP Proxy "? what will happen if there is no http proxy
>deployed?
>
>There are two options to solve this usecase discussed in PNTAW mailing list.
>"5)UDP relay candidates via some HTTP/TLS compatible transport (TURN) -
>MUST/SHOULD (TLS via HTTP CONNET or TURN over WebSockets have been
>proposed."  List in
>http://www.ietf.org/mail-archive/web/pntaw/current/msg00162.html
>Also there is other discussions in
>I believe that the PNTAW mailing list is used for discussion of these similar
>transport problems, including the related use case and requirement. In the end ,
>some consensus should be make to decide what problem we need handle and
>how to solve it , which will influence the use case and requirement to make it
>more clear.  Is my thought right? Or miss something...
>
>Best Regards,
>     Xin
>>

---

From: "Chenxin (Xin)" <[email-masked]>
Date: Thu, 17 Oct 2013 10:23:37 +0000

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

   Service use-case (Section 3.3.1).  The difference is that one of the

   users is behind a NAT*/FW* that blocks UDP traffic.

.

3.3.2.2.  Additional Requirements

           data to a peer in the presence of NATs *and FWs* that

           block UDP traffic ,* when FW policy allows WebRTC traffic*.

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

   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.

    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

   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.

3.3.3.2.  Additional Requirements

           data to a peer in the presence of http allowing FWs or FWs that only

           allows WebRTC traffic.

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

Best Regards,

     Xin

>From: Hutton, Andrew [mailto:[email-masked]]

>Sent: Thursday, October 17, 2013 2:08 AM

>To: Christer Holmberg; Chenxin (Xin); Parthasarathi R; [email-masked]

>I see the PNTAW mailing list as being there to discuss potential solutions to

>these requirements which are documented in the use case draft.

>The requirement F37 is specific to the case when there is a HTTP Proxy and F27

>would include the case when there is no proxy.

>Do you see other use cases and requirements that need to be explicitly brought

>out in draft-ietf-rtcweb-use-cases-and-requirements?

>> So, you are saying we shouldn't finalize the use-case-requirements

>> document yet?

>> Subject: RE: [rtcweb] Query/Comment on draft-ietf-rtcweb-use-cases-and-

>> >>  +1. I think we should wait for the result of [email-masked]

>> >> discussion

>> (TURN) - MUST/SHOULD (TLS via HTTP CONNET or TURN over WebSockets

>have

>> Also there is other discussions in http://www.ietf.org/mail-

>> archive/web/pntaw/current/msg00166.html.

>> That all mention that we should consider more than the http proxy

>> scenarios.

>> >>these requirements are met. If so, Please update the below

>> requirement

---

From: "Parthasarathi R" <[email-masked]>
Date: Sun, 20 Oct 2013 22:05:23 +0530

Hi Xin & all,

Apart from modified F29 by Xin, the following requirement has to be
discussed: 

1)      New requirement for blocking incoming TCP connection:

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

2)      New requirement to cover both browsers are behind the firewall

a.         The browser must be able to send streams and data to a peer in
the presence of NATs and FWs that block UDP traffic and incoming TCP
connection  in both browser side as well as in the peer side (TURN only
works) 

Thanks

Partha

From: Chenxin (Xin) [mailto:[email-masked]] 
Sent: Thursday, October 17, 2013 3:54 PM
To: Hutton, Andrew; Christer Holmberg; Parthasarathi R; [email-masked]
Subject: RE: [rtcweb] Query/Comment on
draft-ietf-rtcweb-use-cases-and-requirements-12

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 : 

3.3.2.1.  Description

.

   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.

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

   users is behind a http allowing FW or a FW that only allows traffic via a
HTTP Proxy.

           data to a peer in the presence of http allowing FWs or FWs that
only

           allows WebRTC traffic.

 

Best Regards,

     Xin