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