[rtcweb] New version of use-case draft uploaded

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

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
>