WebRTC IP Address Handling Requirements
RFC 8828
Yes
No Objection
Note: This ballot was opened for revision 11 and is now closed.
Alvaro Retana No Objection
Warren Kumari No Objection
I especially enjoyed the Security Consideration section :-)
(Adam Roach; former steering group member) Yes
(Alexey Melnikov; former steering group member) Yes
(Ben Campbell; former steering group member) Yes
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; former steering group member) Yes
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; former steering group member) Yes
Thank you for a clear, well written, document.
(Alissa Cooper; former steering group member) No Objection
Please respond to the Gen-ART review.
(Benjamin Kaduk; former steering group member) No Objection
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".
(Deborah Brungard; former steering group member) No Objection
(Eric Rescorla; former steering group member) No Objection
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..."
(Ignas Bagdonas; former steering group member) No Objection
(Martin Vigoureux; former steering group member) No Objection
(Mirja Kühlewind; former steering group member) No Objection
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.
(Suresh Krishnan; former steering group member) No Objection
* 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"