Transports for WebRTC
draft-ietf-rtcweb-transports-17

Thanks for writing this. It's a well written document that really helps bring together the rather fragmented specifications that an implementor needs to understand. I have one minor and a few editorial comments:

Minor Comments:

- 4.2, 2nd to last paragraph:"Sending data over multiple 5-tuples is not supported."
I am confused by this, since the last few paragraphs required support for a separate 5-tuple per media stream. That seems to be a form of sending data over multiple 5-tuples.  Does this mean to distinguish "data" from "media", maybe in the in the sense of "data-channels"?

- Informative References: 
Please consider whether the references to rtcweb-overview, RFC 4595, and RFC 7656 should be normative references. They are cited for definition of terms used in this document; if those definitions are needed to fully understand this document, they should be normative. (IMHO, these are borderline).

Editorial Comments:

- Please expand TURN, SSL, and ICE on first mention.

- 3.4, 5th paragraph from end: "using TCP only between the endpoint and its relay"
I _think_ this means the use of TCP on the hop between the endpoint and the relay and not on other hops, but some may read it as the use of TCP but not other protocols on that hop.

- 4.2: There are a few instances of text of the form of "... packets...use a single DSCP code point", which I think would be more clear with s/a single/the same.

I noted that some comments that I agreed with have appeared during Last Call, and hope they'll be reflected in a -15. Beyond that, I had a few comments of my own, but wanted to thank the working group for producing very clear and helpful transport guidance.

In this text

   If some of the temporary IPv6 addresses, but not all, are marked
   deprecated, the client SHOULD discard the deprecated addresses.
   
I would find some explanation of why this is a SHOULD to be helpful ("if some of the addresses are deprecated, and you could discard them because you still have addresses that are not marked deprecated, why would you not discard the deprecated addresses?").

In this text

   In order to deal with firewalls that block all UDP traffic, the mode
   of TURN that uses TCP between the client and the server MUST be
   supported, and the mode of TURN that uses TLS over TCP between the
   client and the server MUST be supported.  See [RFC5766] section 2.1
   for details.
   
I think MUST for both TCP and TLS over TCP is still a good requirement, but I note that RFC 5766 significantly predates RFC 7258, and wonder if it's worth mentioning the tradeoffs in selecting which to use in a pervasively monitored Internet, with RFC 7258 as a reference (RFC 5766 couldn't do that, of course).

In this text

   For data transport over the WebRTC data channel
   [I-D.ietf-rtcweb-data-channel], WebRTC implementations MUST support
   SCTP over DTLS over ICE.  This encapsulation is specified in
   [I-D.ietf-tsvwg-sctp-dtls-encaps]. 
   
I-D.ietf-tsvwg-sctp-dtls-encaps seems to call this "SCTP over DTLS over ICE/UDP". That would be clearer to me.

I agree with

   There exist a number of schemes for achieving quality of service that
   do not depend solely on DSCP code points.  Some of these schemes
   depend on classifying the traffic into flows based on 5-tuple (source
   address, source port, protocol, destination address, destination
   port) or 6-tuple (5-tuple + DSCP code point).  Under differing
   conditions, it may therefore make sense for a sending application to
   choose any of the configurations:
   
and the text that follows it, but I'm not understanding how a sending application would know which configuration to choose, if we're still talking about downloaded Javascript on an arbitrary browser instance (is that still accurate? If not, my apologies). 

Is the sending application just guessing/applying heuristics, or is there any guidance (or a reference to guidance) you can provide?

Thanks for addressing the issues from my DISCUSS in version 15. I am clearing.