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

[Stefan Håkansson LK <[e-mail]>]

Hi Partha!

On 2014-02-07 17:39, Parthasarathi R wrote:
> 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."

Yes, I did that change (TURN -> ICE). My understanding was that ICE is
what is used/mandated (and it in turn makes use of STUN and TURN).

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

I can update them to what you propose. But I think it is a little bit
silly. If we add that note, then we should probably add to F28 "The
browser must support a baseline audio and video codec" a note saying
"this does not preclude the browser from supporting additional codecs"
and so on. After all, the requirements are meant to be what must be
supported; they do not say that additions are not allowed.

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