Re: [Gen-art] Gen-ART LC review of draft-ietf-rtcweb-use-cases-and-requirements-14.txt

[Christer Holmberg <[e-mail]>]

Hi Brian,

Thanks for your review! Reply inline.

------------------------------------------

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.

Thanks for the clarification :)

------------------------------------------

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

IP version interworking (in case one client is IPv4-only and the other is IPv6-only) is outside the scope.

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

That is also outside the scope.


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

We are mainly referring to the different NAT behaviors, to the transport protocols.


------------------------------------------


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

I was asked to do it during WG review.

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

I think your suggestion goes too much into implementation details. 

However, I agree to change "when" to "while".


------------------------------------------

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

We reference RFC 2804 only for the wiretapping definition.


------------------------------------------

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

I agree that the text is a little unclear. It is not meant to say that a browser always must be able to hide its IP address, but that it should be possible to set up a call even if the browser does not know the other party's IP address.

I suggest to modify the text to:

	"F14     The browser must make it possible to set up a
           		call between two parties even if one party
           		does not know the other party's host IP address."

------------------------------------------


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

The rendez-vous is outside the scope of the document. RTCWEB will not say anything about the external signaling protocol.

------------------------------------------

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

That's a good point. I suggest:

	"The user in the previous use case that starts a trip is behind a
	common residential router that supports differentiated services."


------------------------------------------

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

It shall be F22, but the requirement text needs to be corrected. The correct F22 text is:

	"F22     The browser should be able to take advantage
           		of available capabilities (supplied by network
           		nodes) to prioritize voice, video and data
           		appropriately."


------------------------------------------


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

Ok.

> Also, you now have two different F22s. This one seems to fit 3.3.7.2 better.

Correct. This is the right F22 requirement.

>Below, you also have two F25s. And other duplicates. Wasn't the idea just to add *new* requirements when they arose?

As indicated earlier, the WG decision was to explicitly add the additional requirements in each use-case where they occur.

>As F22 shows, the duplication is error-prone.

We'll double check.


------------------------------------------


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

The WG decided to cover privacy considerations in a separate draft (rtcweb-security). We could add a reference to that draft in the use-cases draft.


------------------------------------------

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.

We will remove the statement saying that the "Conventions" are removed.


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

We will add 4784 to the Informative References.


>>    A17, A23
>>    A13, A14, A15, A16
>
> What are these lines that occur in a few places?

Those are API requirements (see Annex A) for each use-case.

However, the WG decided not to copy/paste the API requirement descriptions, but simply to list the requirements. I suggest to add "API requirements:" in front of the list associated with each use-case.


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

We will mote those to the Informative Reference section.


Thanks!

Regards,

Christer