WebRTC IP Address Handling Requirements
draft-ietf-rtcweb-ip-handling-12
Note: This ballot was opened for revision 11 and is now closed.
(Ben Campbell) Yes
Comment (2019-03-04 for -11)
I agree with Mirja that this reads more like a BCP. Was BCP status considered by the WG? (nit) §3: Please expand "RTMFP" on first mention. (nit) §5.2: "Mode 1 MUST only be used when user consent has been provided" Please consider "... MUST NOT be used unless user consent has been provided." §11.2: It seems like the references for STUN and TURN should be normative.
(Spencer Dawkins) Yes
Comment (2019-03-06 for -11)
I agree with Benjamin's question about Section 5.1 (but I'll watch the discussion on his ballot thread, so no follow-up needed here).
(Terry Manderson) Yes
Comment (2019-03-07 for -11)
Thank you for a clear, well written, document.
Alexey Melnikov Yes
Adam Roach Yes
Ignas Bagdonas No Objection
Deborah Brungard No Objection
Alissa Cooper No Objection
Comment (2019-03-06 for -11)
Please respond to the Gen-ART review.
Benjamin Kaduk No Objection
Comment (2019-03-06 for -11)
I agree with Ben about the STUN/TURN normativity.
Section 5.1
2. By default, WebRTC should be able to negotiate direct peer-to-
peer connections between endpoints (i.e., without traversing a
NAT or relay server). [...]
I'm not sure how to interpret "be able to", here, with respect to
"without traversing a NAT", since if one endpoint is behind a NAT w.r.t.
the public Internet, that's not possible.
Section 5.2
Mode 1 MUST only be used when user consent has been provided. The
details of this consent are left to the implementation; one potential
mechanism is to tie this consent to getUserMedia consent.
nit: we may not have left a big enough breadcrumb trail for the reader
to find "getUserMedia consent".Suresh Krishnan No Objection
Comment (2019-03-06 for -11)
* Section 3 Not sure how the use of temporary addresses in IPv6 [RFC4941] is relevant at all to a discussion of NAT usage (#2). Can you please clarify? "#2 is a less significant but valid concern. While the [RFC4941] IPv6 addresses recommended by [I-D.ietf-rtcweb-transports] are fairly benign due to their intentionally short lifetimes"
Warren Kumari No Objection
Comment (2019-03-05 for -11)
I especially enjoyed the Security Consideration section :-)
Mirja Kühlewind No Objection
Comment (2019-02-28 for -11)
To me this doc reads more like a BCP. Thanks for replying to the TSV-ART review (and thanks, Joe, for the review)! Please edit the doc accordingly.
(Eric Rescorla) No Objection
Comment (2019-03-06 for -11)
Rich version of this review at: https://mozphab-ietf.devsvcdev.mozaws.net/D3744 COMMENTS S 3. > > 1. If the client is multihomed, additional public IP addresses for > the client can be learned. In particular, if the client tries to > hide its physical location through a Virtual Private Network > (VPN), and the VPN and local OS support routing over multiple > interfaces (a "split-tunnel" VPN), WebRTC will discover not only This might be simpler if you said "route traffic over" rather than "support routing" Also, do you want to say "may discover" because the guidelines below would potentially stop that. S 6.2. > addresses (0.0.0.0 for IPv4, :: for IPv6), which allows the OS to > route WebRTC traffic the same way as it would HTTP traffic. STUN and > TURN will work as usual, and host candidates can still be determined > as mentioned below. > > 6.2. Determining Host Candidates This is framed a little confusingly, because all host candidates are suitable in mode 1. Perhaps add "In modes XXX..."