Re: [rtcweb] Preparing for publication request of draft-ietf-rtcweb-use-cases-and-requirements

[Mary Barnes <[e-mail]>]

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".
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.
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.
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?
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. ]
6) Section 3.4. I would expect F27 to  be referenced by at least one of
these use cases.
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).
- What's the difference between F24 and 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.

             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?


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


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.




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"



On Wed, Jan 15, 2014 at 4:44 AM, Magnus Westerlund <
[e-mail]> wrote:

> WG,
>
> This is related to:
>
> https://datatracker.ietf.org/doc/draft-ietf-rtcweb-use-cases-and-requirements/
>
> We have held WG last call and there has been updates to the document to
> resolve the WG last call comments. It is now time to finish up this
> document and request publication of it. I am the document shepherd for
> this document and will prepare my write-up of the document and in that
> process do the necessary reviews.
>
> I also asked the WG for input on two open issues that needs to be closed
> prior to publication request. So please review these and provide your
> input on them.
>
> This is your chance to verify that your comments has been addressed in
> the revision. Please provide any feedback on the document within the
> next week, i.e. no later than the 22 Feb.
>
> Note, that I will require that the WG approves of any changes in this
> state, rather than any silence is approval model. So if you want some
> change to go into the document at this stage there need to (rough)
> consensus to introduce it and clearly shown support.
>
>
> Cheers
>
> 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
>