Transports for WebRTC
RFC 8835

Note: This ballot was opened for revision 14 and is now closed.

(Ben Campbell) Yes

Comment (2016-08-01 for -14)
No email
send info
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.

(Alissa Cooper) Yes

(Spencer Dawkins) Yes

Comment (2016-08-02 for -14)
No email
send info
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 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?

(Suresh Krishnan) (was Discuss) Yes

Comment (2016-08-04 for -15)
No email
send info
Thanks for addressing the issues from my DISCUSS in version 15. I am clearing.

(Alia Atlas) No Objection

(Deborah Brungard) No Objection

(Stephen Farrell) (was Discuss) No Objection

(Joel Jaeggli) No Objection

(Mirja K├╝hlewind) (was Discuss, No Record, No Objection) No Objection

Comment (2016-08-04 for -15)
No email
send info
Thanks for updating!

Leaving it to this comment:
Based on the TSV review I agree that this document (named "Transports for WebRTC") should say more about congestion control. The TSV reviewer (Thanks Allison!) proposes to refer draft-ietf-avtcore-rtp-circuit-breakers-17 and draft-ietf-rmcat-cc-requirements-09. I would even appreciate to have a  sentence that says that congestion control and a circuit breaker is mandated in draft-ietf-rtcweb-rtp-usage-26.

(Terry Manderson) No Objection

(Alexey Melnikov) No Objection

Comment (2016-08-03 for -14)
No email
send info
I am glad this work is being completed.

(Kathleen Moriarty) No Objection

Comment (2016-08-03 for -14)
No email
send info
I had the dame question as Stephen on why SSL instead of TLS, so thanks for clearing that up in the next revision.

Alvaro Retana No Objection