WebRTC IP Address Handling Requirements

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)
No email
send info
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)
No email
send info
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:

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 ( 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..."

Alvaro Retana No Objection

Martin Vigoureux No Objection