Christer, Thanks for the response. In the cases where you note that something is outside the intended scope, that's fine, but I suggest making this clear to the reader. I have also responded to one point under F3 below.
On 07/05/2014 20:00, Christer Holmberg wrote: > 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. Of course that's a matter of opinion, but this whole point is about implementation in the host, not about a wire protocol. So the fact that there needs to be an API to tell the browser about congestion seems quite distinct from the fact that the browser needs to react to it. (How the host *knows* that there's congestion is another point that I am sure DART will have to discuss.) Brian > > 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
