Skip to main content

Last Call Review of draft-ietf-rtcweb-use-cases-and-requirements-14
review-ietf-rtcweb-use-cases-and-requirements-14-opsdir-lc-tsou-2014-05-03-00

Request Review of draft-ietf-rtcweb-use-cases-and-requirements
Requested revision No specific revision (document currently at 16)
Type Last Call Review
Team Ops Directorate (opsdir)
Deadline 2014-05-13
Requested 2014-04-14
Authors Christer Holmberg , Stefan Hakansson , Goran Eriksson
I-D last updated 2014-05-03
Completed reviews Genart Last Call review of -14 by Brian E. Carpenter (diff)
Genart Telechat review of -14 by Brian E. Carpenter (diff)
Secdir Last Call review of -14 by Ben Laurie (diff)
Opsdir Last Call review of -14 by Tina Tsou (Ting ZOU) (diff)
Assignment Reviewer Tina Tsou (Ting ZOU)
State Completed
Request Last Call review on draft-ietf-rtcweb-use-cases-and-requirements by Ops Directorate Assigned
Reviewed revision 14 (document currently at 16)
Result Ready
Completed 2014-05-03
review-ietf-rtcweb-use-cases-and-requirements-14-opsdir-lc-tsou-2014-05-03-00
Dear all,

I have reviewed this document as part of the Operational directorate's
ongoing effort to review all IETF documents being processed by the IESG.
These comments were written primarily for the benefit of the operational
area directors. Document editors and WG chairs should treat these
comments just like any other last call comments.

Summary: Ready with issues and nits

This document presents a few use-cases of web applications that are executed in
a browser and use real-time communication capabilities.

* Section 3.3.1.1:

You should add that a user should be able to block any further communication
attempts from a remote user.

* Section 3.3.1.2:
>       F10     The browser must support a baseline audio and video codec

Should we put this req to this document when the WG could not make consensus on
the MTI video codec?

* Section 3.3.1.2:

>    F13     The browser must encrypt, authenticate and
>            integrity protect media and data on a
>            per-packet basis, and must drop incoming media
>            and data packets that fail the per-packet
>            integrity check.

What does "per packet" mean? IP packet? TCP packet? Application PDU?

* Section 3.3.1.2:

>    F14     The browser must make it possible to set up a
>            call between two parties without one party
>            learning the other party's host IP address.

How can you enforce this on a *browser*?

* Section 3.3.4

This use case needs F20 too, the browser should support STUN and TURN server
Auto Discovery.

* Section 3.3.5.1
...
>       "This should be possible to achieve by auto-configuration methods."
Should be
"This should be possible to achieved by auto-configuration methods."

* Section 3.3.5.1

The user should have the ability to tell whether his/her communications can be
audited.

* Section 3.3.7.2.

F22 is wrong,  which should be replaced by the one in section 4.2.

* Section 3.3.10.2

>    F25     The browser must be able to render several
>            concurrent video streams

Maybe you should add "audio", too? Or isn't that expected?

* Section 3.3.12.2

F22 - F29 is not additional.

**** Nits:****

* Section 1:
"   clients is of another type (e.g. a mobile phone or a SIP UA)"

Expand "SIP UA".

* Section 1
...
A full stop is missed in the end.

Section 3.3.1.1:

>    displays during the session.  Each user can also pause sending of
>    media (audio, video, or both) and mute incoming media

The final dot is missing.

* Section 3.3.1.2:
F6, F9 and F10
Full stops are missing.

Thank you,
Tina