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
_______________________________________________
Gen-art mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/gen-art
