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

[Jari Arkko <[e-mail]>]

Brian:

Thank your for your detailed review. 

Authors:

Any responses? (I personally think at least the first comment deserves a change in the document.)

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

I'd suggest expanding the last bullet of Section 3.1 to include various translation designs that might be involved in Ipv4-IPv6 connectivity. Eg., 

OLD:
   o  Clients can be on networks with a NAT using any type of Mapping
      and Filtering behaviors (as described in RFC4787).
NEW:
   o  Clients can be on networks with a NAT or IPv4-IPv6 translation devices using any type of Mapping
      and Filtering behaviors (as described in RFC4787).


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

I thought that any SCTP would be encapsulated within UDP fro that reason.

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

I agree with the when=>while change, good catch. Not sure personally if the breakdown to smaller requirements is necessary.

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

Agreed. I do not think this is a blocking comment, but I too would like to see a difference reference.

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

I agree that DS would be a more appropriate term, but I don't think the document should otherwise expand too much on that space, IMO.

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

Jari