I am the assigned Gen-ART reviewer for this draft. For background on
Gen-ART, please see the FAQ at
<http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>.

Please resolve these comments along with any other Last Call comments
you may receive.

Document: draft-ietf-rtcweb-use-cases-and-requirements-14.txt
Reviewer: Brian Carpenter
Review Date: 2014-04-21
IETF LC End Date: 2014-04-25
IESG Telechat date:

Summary:  In good shape but still needs work.
--------

Comment:
--------

In case there are W3C people reading this review, let me clarify that Gen-ART reviews
are by generalists who are often encountering a topic for the first time. I haven't
classified the issues into "major" and "minor" but some of them really do need
attention before the document advances. There are also some nits noted at the end.

Issues:
-------

>   The following considerations are applicable to all use cases:
>
>   o  Clients can be on IPv4-only
>
>   o  Clients can be on IPv6-only
>
>   o  Clients can be on dual-stack

It isn't clear whether this is intended to include the case where an
IPv4-only client communicates with an IPv6-only node (or vice versa).

It also isn't clear about cases in which a mobile client's connectivity
changes dynamically during a session (e.g. from IPv4 to IPv6). This is
partly clarified later by F17, but only partly.

>   o  Clients can be on networks with a NAT using any type of Mapping
>      and Filtering behaviors (as described in RFC4787).

That document is scoped for UDP only. Is that sufficient? As I understand the
RTCWEB transport drafts, it is aiming at connection-oriented transport.
(How many NATs support SCTP, for example?)

> 3.2.  Common requirements
>
>   The requirements retrived from the Simple Video Communication Service
>   use-case (Section 3.3.1) by default apply to all other use-cases, and
>   are considred common.  For each individual use-case, only the
>   additional requirements are listed.

In fact you duplicate the additional requirements in each use case where they
occur. That seems like overkill. Also there's at least one mix-up as a result,
noted below.

> 3.3.1.2.  Common Requirements
...
>  F3      Transmitted streams and data must be rate
>          controlled (meaning that the browser must, regardless
>          of application behavior, reduce send rate when
>          there is congestion).

I think that needs to be broken into two more atomic requirements.
Something like

   F3.1    There must be a mechanism by which the transport layer
           can signal the occurrence of congestion to the browser.

   F3.2    Transmitted streams and data must be rate
           controlled (meaning that the browser must, regardless
           of application behavior, reduce send rate while
           there is congestion).

The change from "when" to "while" is intentional, since the browser
should allow the rate to increase when there is no congestion.

>   F11     It must be possible to protect streams and data
>           from wiretapping [RFC2804].

I don't see the relevance of the reference (of which I am a co-author),
which mainly states that the IETF won't consider requirements *for* wiretapping.
I'm sure you can find a reference that says encryption is a Good Thing.

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

It is not clear how to interpret that. I assume it's supposed to be a
restatement of the earlier comment:

>   The application gives the users the opportunity to stop it from
>   exposing the host IP address to the application of the other user.

But -- assuming the implementation model is peer-to-peer communication
between the two hosts, rather than client1-server-client2 communication --
I'm afraid I don't see how F14 can be guaranteed, since the peers must be
aware of each others' IP address. Even if the browser and app hide the
remote address, a little Wiresharking will reveal it immediately.
There's not much point stating a requirement that cannot be met.

I realised at this point in the document that you need to be very
explicit about whether communication is indeed intended to be peer-to-peer
or via the server. And assuming it is meant to be peer-to-peer, what
is the model for the rendez-vous between the peers? What requirements do
you need to solve the resulting referral problem?
(http://tools.ietf.org/html/draft-carpenter-referral-ps-02)

This topic belongs in the Common Requirements.

> 3.3.7.1.  Description
...
>   The user in the previous use case that starts a trip is behind a
>   common residential router that supports prioritization of traffic.

Please talk about differentiated services (RFC 2474 etc.). IP doesn't
have simple priority. That's exactly why the DART WG was just formed.

> 3.3.7.2.  Additional Requirements
>
>   ----------------------------------------------------------------
>   REQ-ID      DESCRIPTION
>   ----------------------------------------------------------------
>   F17     The communication session must survive across a
>           change of the network interface used by the
>           session
>   ----------------------------------------------------------------
>   F22     The browser must be able to receive streams and
>           data from multiple peers concurrently.
>   ----------------------------------------------------------------

This seems completely messed up. The reader expects requirements for
QoS at this point. Isn't this "F22" really F24?

> 3.3.10.2.  Additional Requirements
>
>   ----------------------------------------------------------------
>   REQ-ID      DESCRIPTION
>   ----------------------------------------------------------------
>   F22     The browser should be able to take advantage
>           of available capabilities (supplied by network
>           nodes) to prioritize voice, video and data
>           appropriately.

Again, please cite differentiated services rather than prioritization.
Also, you now have two different F22s. This one seems to fit 3.3.7.2 better.

Below, you also have two F25s. And other duplicates. Wasn't the idea
just to add *new* requirements when they arose? As F22 shows, the
duplication is error-prone.

> 6.  Security Considerations

I am really surprised that there isn't a sub-section on Privacy
Considerations. RFC 6973 describes the various types of threat and they
seem specially relevant here.

Nits:
-----

> 2.  Conventions
>
>   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
>   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
>   document are to be interpreted as described in BCP 14, RFC 2119
>   [RFC2119].

The change log says you removed this. Also there is no change log
since version 10.

RFC 4787 is mentioned but not listed as an Informative Reference.

>    A17, A23
>    A13, A14, A15, A16

What are these lines that occur in a few places?

RFC 2804 and RFC 5479 are Informational documents so cannot reasonably be
Normative References.