Re: [rtcweb] New version of use-case draft uploaded

["Parthasarathi R" <[e-mail]>]

Hi Stefan,

Simon proposed the following text after the lengthy mailing discussion:

> "Note that TURN support being mandatory does not preclude a WebRTC 
> endpoint from supporting additional traversal mechanisms."

Whereas Sec 3.3.4.1 updated as 

"Note that ICE support being mandatory does not preclude a WebRTC
   endpoint from supporting additional traversal mechanisms."

Apart from this, Tiru
(http://www.ietf.org/mail-archive/web/rtcweb/current/msg11246.html) and
myself (http://www.ietf.org/mail-archive/web/rtcweb/current/msg11241.html)
mentioned in the different mail thread that Sec 3.3.4.1 is not only the
right place to put the above text. Could you please correct the F31, F32
requirement text in the next revision of the draft.

Thanks
Partha

> -----Original Message-----
> From: rtcweb [mailto:[e-mail]] On Behalf Of Stefan
> Håkansson LK
> Sent: Thursday, February 06, 2014 4:23 PM
> To: [e-mail]
> Subject: [rtcweb] New version of use-case draft uploaded
> 
> Hi,
> 
> I've uploaded a new version -13 [1]. I have made changes based on input
> from Mary, Magnus and Chenxing+Andy, for details read further down.
> 
> I hope I have caught most things; what remains to my knowledge is:
> * Include the requirement text the first time a requirement is derived
> * Group (and re-number) the claims
> 
> I am hesitating to do the last thing 'cause of the risk of getting all
> internal references into a mess, but one day soon I will feel brave
> enough :-)
> 
> Stefan
> 
> [1]
> http://datatracker.ietf.org/doc/draft-ietf-rtcweb-use-cases-and-
> requirements/
> 
> ======================================
> On 2014-01-15 21:57, Mary Barnes wrote:
> > I had thought I had previously done a detailed review of this doc,
> but
> I can't find it to know whether changes suggested have been
> incorporated. So, I have re-reviewed the document and I think it's
> almost ready to progress. I think it needs some editorial
> clarifications
> and nits to be fixed as summarized below. Note, I did not review the
> appendix.
> > Regards,
> > Mary.
> > In general, I still find the style of this document very difficult to
> grok since the requirements are not grouped in categories and one has
> to
> keep switching back and forth in the document to match requirements to
> use cases.
> > Questions/Comments for clarification:
> > ----------------------------------------------------
> > 1) Section 1, 1st paragraph, last sentence. It's not clear to me that
> "e.g., a telephone" is meaningful. I don't think you're intending to
> interworking with a legacy PSTN connected black phone. So, it might be
> more accurate to say " e.g., a mobile phone or a SIP UA".
> 
> Changed.
> 
> > 2) Section 3.3.1.1. Next to last paragraph. I'm not sure what you
> mean
> by different "makes". I think you mean different types of devices
> (e.g.,
> mobile, SIP UA, etc. ). That all said, I don't think that's not so
> relevant. I think simply stating different OSs and different browsers
> is
> sufficient.
> 
> Changed.
> 
> > 3) Section 3.3.6.1. It's not at all clear to me why this requirement
> is considered specific to WebRTC. I would think the access network
> changes should be transparent to WebRTC. Certainly, the device needs to
> know what's happening, but I think whether this works is entirely based
> on the internals of the device and the specific access network
> technology, and not WebRTC application.
> 
> It is not WebRTC specific per se, but is important for the use-case.
> What parts that solve it is of less importance IMO.
> 
> > 4) Section 3.3.10.1. Why is F24 not considered an additional
> requirement here? Also, do you not need to have a statement as to what
> other use case is the basis for this one such that the core
> requirements
> are reference?
> 
> I added F24 (it belongs here). I don't think we need a statement
> regarding the basis, it is covered in section 3.2
> 
> > 5) Section 3.3.11.1, 2nd paragraph, 1st sentence. I don't understand
> what this is trying to say. What is meant by "enhance intelligibility"?
> And, what is meant by "pans the audio from different participants
> differently when rendering the audio".
> > [As an aside, I will note that some of the CLUE use cases likely
> encompass what you are trying to communicate here in this requirements
> (including subsequent paragraphs and the last "Note:"), so you may want
> to look at those and use similar terminology and concepts, that CLUE
> spent a lot of time developing. ]
> 
> I updated (using similar terminology to Clue).
> 
> > 6) Section 3.4. I would expect F27 to be referenced by at least one
> of
> these use cases.
> 
> I added it to 3.4.1
> 
> > 7) Section 4.2.
> > - General: I am a bit confused as there are requirements in this
> section that aren't referenced in section 3, including F19, F23, and
> F27
> . Perhaps, that's because there are some missing references in section
> 3
> (see item 7)? If not, then why are they there. At a minimum you should
> add a sentence to section 4.1 indicating that not all the requirements
> are derived from the use cases (contrary to what is currently stated).
> 
> F19 has been removed. I added ref to F23 (and F24!) from ues-case
> "multi-party game with voice communication". Ref to F27 added to 3.4.1.
> 
> > - What's the difference between F24 and F34?
> 
> I don't know, and I removed F34
> 
> > - F30. I had to read this several times to understand it due to
> structure. I would suggest changing as follows:
> > OLD:
> > F30 The browser must be able to use the screen (or
> > a specific area of the screen) or what a certain
> > application displays on the screen to generate
> > streams.
> > NEW:
> > F30 The browser must be able to generate streams using the entire
> user
> display, a specific area of the user's display or the information being
> displayed by a specific application.
> 
> Updated.
> 
> > On this one, I also think it would be good to clarify what type of
> stream - are you talking about using protocol to share content or or is
> this just a video stream? Or would you have two separate requirement to
> cover both of these?
> 
> I would like to avoid going into detail; the idea is that it is some
> kind of "stream" that allows sharing what is rendered on your screen,
> the requirement does not need to go into what kind it is.
> 
> > - F32. I can't quite grok this one. Maybe you are trying to say
> something like the following?
> > OLD:
> > F32 There browser must support that STUN and TURN
> > servers to use are supplied by other entities
> > than via the web application (i.e. the network
> > provider).
> > NEW:
> > F32 The browser must support the use of STUN and TURN
> > servers that are supplied by entities
> > other than the web application (i.e. the network
> > provider).
> 
> Updated.
> 
> > 8) Section 7. I have mixed feelings about leaving this list with URLs
> in the document. I think it's good to highlight the use cases that
> weren't incorporated and why they weren't. I think it would add a lot
> more value to provide a concise summary of the reasons they weren't
> added than just including links, in particular, since we usually don't
> like to publish RFCs with links.
> 
> I think the entire list should go before publication. The list has been
> kept there as a reminder of what we included and what we did not
> included. I have removed it in this version.
> 
> > Nits:
> > ------
> > 1) Section 1, 1st paragraph, last sentence, "at least one of the
> end-user client" -> "at least one of the end-user clients"
> > 2) Section 3.2, 1st paragraph, 1st sentence:
> > - "retrives" -> "retrieves"
> > - add a section reference for "Simple Video Communication Service"
> > 3) Section 3.2. , next to last sentence. "retrieved from" -> "derived
> from"
> > 4) Section 3.3.5.1, 3rd paragraph,
> > - 1st sentence. "session" - "session"
> > - 2nd sentence. "straddle the boundary between the internal network
> and external." -> "straddles the boundary between the internal and
> external networks.
> > 5) Section 3.3.5.1, 4th paragraph. "they still want to have the
> traffic to stay" -> "they still want the traffic to say"
> > 6) Section 3.3.61. 1st paragraph. I'm not sure why this ends with ":"
> > 7) Section 3.3.6.1, 2nd paragraph. "device used by one of the users
> have several" -> "device used by one of the users has several"
> > 8) Section 3.3.11.1, 1st para, 1st sentence. "In this use case is the
> Simple..." -> "In this use case, the Simple...."
> > 9) Section 3.3.11.1 3rd from last paragraph. "use experience" ->
> "user
> experience"
> > 10) Section 3.4.3.1, 2nd paragraph. "participant send" ->
> "participant
> sends"
> > 11) Section 4.2:
> > - F35. "of that streams" -> "that streams"
> 
> Most Nit's fixed
> 
> =============================================
> 
> 
> On 2014-01-29 10:29, Magnus Westerlund wrote:
> > Hi Partha and WG,
> >
> > I don't see any support for the changes you proposes in this
> discussion.
> > What I see some support for is to add a statement making clear that
> > there might be additional NAT/Firewall traversal mechanisms than
> > STUN/TURN. Simon proposed:
> >
> > "Note that TURN support being mandatory does not preclude a WebRTC
> > endpoint from supporting additional traversal mechanisms."
> 
> I added this to section 3.3.4.1
> 
> >
> >
> > However, looking at the document as it is currently written, I am
> > uncertain where this would be added. The first mention of TURN is in
> > Section 3.3.4.1, and that section is focused on the global service
> > provider perspective and the need for location based provisioning of
> > NAT/Firewall traversal server resources.
> >
> > I think it can be added to Section 3.3.5.1 without being misplaced,
> but
> > it would be given a slightly narrower scope.
> >
> > I any of you want to be more explicit where this should be included,
> > please be. If you are not forthcoming I will request the authors to
> add
> > this in what they consider sensible position.
> >
> > Cheers
> >
> > Magnus
> >
> >
> > On 2014-01-25 17:46, Parthasarathi R wrote:
> >> Hi Simon,
> >>
> >>
> >>
> >> Thanks for your understanding about my firewall/NAT related problem
> >> statement in this draft.
> >>
> >>
> >>
> >> I have proposed the firewall/NAT related text by which the specific
> >> mechanism is not highlighted in the requirement document as there is
> no
> >> WG consensus for any of the mechanism including TURN. It is possible
> to
> >> argue hypothetically in PNTAW alias that PCP is the only mechanism
> >> required in WebRTC endpoint. Also, I’m more interested in WebRTC
> >> gateway/server (Sec 4.3. of
> >> draft-ietf-rtcweb-use-cases-and-requirements-12) requirements
> wherein it
> >> is not required to support TURN and the related mail thread is
> >> http://www.ietf.org/mail-archive/web/pntaw/current/msg00181.html.
> >>
> >>
> >>
> >> IMO, my proposed text without mentioning any firewall/NAT mechanism
> in
> >> the requirement document helps to move forward without depend on the
> >> solution discussion in PNTAW alias.
> >>
> >>
> >>
> >> Thanks
> >>
> >> Partha
> >>
> >>
> >>
> >> *From:*Cb B [mailto:[e-mail]]
> >> *Sent:* Saturday, January 25, 2014 6:22 AM
> >> *To:* Simon Perreault
> >> *Cc:* [e-mail]; Parthasarathi R
> >> *Subject:* Re: [rtcweb] Query/Comment on
> >> draft-ietf-rtcweb-use-cases-and-requirements-12
> >>
> >>
> >>
> >>
> >> On Jan 24, 2014 10:17 AM, "Simon Perreault"
> <[e-mail]
> >> <mailto:[e-mail]>> wrote:
> >>>
> >>> Le 2014-01-24 12:14, Parthasarathi R a écrit :
> >>>
> >>>> Please note that when non-IETFers read this requirement document,
> >> they come
> >>>> to the conclusion that IETF RTCWeb WG recommends TURN and not
> other
> >>>> mechanisms. I'm saying that requirement document should not be
> used
> >> as the
> >>>> mechanism to eliminate the other alternatives when there is a
> discussion
> >>>> going-on in PNTAW alias. So, I'm asking for the change.
> >>>
> >>>
> >>> I would totally agree with that sentiment, although I don't see
> your
> >> proposed text change reflecting it accurately. How about simply:
> >>>
> >>> "Note that TURN support being mandatory does not preclude a WebRTC
> >> endpoint from supporting additional traversal mechanisms."
> >>>
> >>>
> >>
> >> +1 for the above text.
> >>
> >> CB
> >>
> >>> Simon
> >>> --
> >>> DTN made easy, lean, and smart --> http://postellation.viagenie.ca
> >>> NAT64/DNS64 open-source --> http://ecdysis.viagenie.ca
> >>> STUN/TURN server --> http://numb.viagenie.ca
> >>> _______________________________________________
> >>> rtcweb mailing list
> >>> [e-mail] <mailto:[e-mail]>
> >>> https://www.ietf.org/mailman/listinfo/rtcweb
> >>
> >>
> >>
> >> _______________________________________________
> >> rtcweb mailing list
> >> [e-mail]
> >> https://www.ietf.org/mailman/listinfo/rtcweb
> >>
> >
> >
> 
> 
> ========================================
> 
> On 2014-01-16 15:18, Hutton, Andrew wrote:
> > Some comments in the text below.
> >
> > As a general comment I suggest changing all the "FW" abbreviations to
> "Firewall" are have at least a first use definition.
> 
> Done
> 
> >
> >
> > Andy
> >
> >
> >> -----Original Message-----
> >> From: Magnus Westerlund [mailto:[e-mail]]
> >> Sent: 15 January 2014 10:20
> >> To: Chenxin (Xin); Hutton, Andrew; Christer Holmberg; Parthasarathi
> R;
> >> [e-mail]
> >> Subject: Re: [rtcweb] Query/Comment on draft-ietf-rtcweb-use-cases-
> and-
> >> requirements-12
> >>
> >> WG,
> >>
> >> It has been quite some time since the WG last call ended and a new
> >> revision was submitted. As Document Shepherd I want to push this
> >> document to publication request.
> >>
> >> Chenxin proposed below three different sets of changes to the
> document.
> >> Does the WG support making these changes? Please indicate within the
> >> next week if you support or want to reject these changes.
> >>
> >> Thanks
> >>
> >> Magnus
> >>
> >>
> >> On 2013-10-17 12:23, Chenxin (Xin) wrote:
> >>> 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
> >>>
> >>>
> >>>
> >>> This use-case is almost identical to the Simple Video
> >> Communication
> >>>
> >>> Service use-case (Section 3.3.1). The difference is that one of
> >> the
> >>>
> >>> users is behind a NAT*/FW* that blocks UDP traffic.
> >>>
> >>> .
> >
> > [AndyH] - I support this change.
> 
> Changed
> 
> >
> >
> >>>
> >>>
> >>>
> >>> 3.3.2.2. Additional Requirements
> >>>
> >>>
> >>>
> >>> F29 The browser must be able to send streams and
> >>>
> >>> data to a peer in the presence of NATs *and FWs* that
> >>>
> >>> block UDP traffic ,* when FW policy allows WebRTC
> >> traffic*.
> >
> > [AndyH] - I support this change.
> 
> Changed
> 
> >
> >
> >>>
> >>> -------------------------------------------------------
> >>>
> >>> 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.
> >>>
> >
> > [AndyH] Yes the heading of 3.3.3 should have been changed during the
> last edit to "Simple Video Communication Service, FW that only allows
> traffic via a HTTP Proxy". I support this change.
> 
> Changed.
> 
> >
> >
> >>>
> >>>
> >>> 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
> >>>
> >>>
> >>>
> >>> This use-case is almost identical to the Simple Video
> >> Communication
> >>>
> >>> 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.
> >>>
> >>>
> >
> > [AndyH] I don't believe the intention here was to state a requirement
> that WebRTC media should be able to flow through a FW only allowing
> HTTP. Therefore I think the original description is ok it is just the
> heading that needs to change.
> >
> >
> >>>
> >>> 3.3.3.2. Additional Requirements
> >>>
> >>>
> >>>
> >>> F37 The browser must be able to send streams and
> >>>
> >>> data to a peer in the presence of http allowing FWs or FWs
> >>> that only
> >>>
> >>> allows traffic via a HTTP Proxy, when FW policy
> >>>
> >>> allows WebRTC traffic.
> >>>
> >
> > [AndyH] The existing text is in the 012 draft is ok and I don't think
> this change is needed as again I don't believe the intention here was
> to
> state a requirement that WebRTC media should be able to flow through a
> FW only allowing HTTP.
> >
> >
> >>> -------------------------------------------------------------------
> >>>
> >>>
> >
> >>>
> >>>
> >>>
> >>> Best Regards,
> >>>
> >>> Xin
> >>>
> >>>
> >>>
> >>
> >>
> >> --
> >>
> >> Magnus Westerlund
> >>
> >> --------------------------------------------------------------------
> --
> >> Services, Media and Network features, Ericsson Research EAB/TXM
> >> --------------------------------------------------------------------
> --
> >> Ericsson AB | Phone [phone]
> >> Färögatan 6 | Mobile [phone]
> >> SE-164 80 Stockholm, Sweden | mailto: [e-mail]
> >> --------------------------------------------------------------------
> --
> >
> > _______________________________________________
> > rtcweb mailing list
> > [e-mail]
> > https://www.ietf.org/mailman/listinfo/rtcweb
> >
> 
> _______________________________________________
> rtcweb mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/rtcweb