Skip to main content

WebRTC IP Address Handling Requirements
draft-ietf-rtcweb-ip-handling-12

Yes

(Adam Roach)
(Alexey Melnikov)

No Objection

(Alvaro Retana)
(Deborah Brungard)
(Ignas Bagdonas)
(Martin Vigoureux)

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

Warren Kumari
No Objection
Comment (2019-03-05 for -11) Not sent
I especially enjoyed the Security Consideration section :-)
Adam Roach Former IESG member
Yes
Yes (for -11) Unknown

                            
Alexey Melnikov Former IESG member
Yes
Yes (for -11) Not sent

                            
Ben Campbell Former IESG member
Yes
Yes (2019-03-04 for -11) Sent
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 IESG member
Yes
Yes (2019-03-06 for -11) Sent
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 IESG member
Yes
Yes (2019-03-07 for -11) Not sent
Thank you for a clear, well written, document.
Alissa Cooper Former IESG member
No Objection
No Objection (2019-03-06 for -11) Sent
Please respond to the Gen-ART review.
Alvaro Retana Former IESG member
No Objection
No Objection (for -11) Not sent

                            
Benjamin Kaduk Former IESG member
No Objection
No Objection (2019-03-06 for -11) Sent
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 IESG member
No Objection
No Objection (for -11) Not sent

                            
Eric Rescorla Former IESG member
No Objection
No Objection (2019-03-06 for -11) Sent
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 IESG member
No Objection
No Objection (for -11) Not sent

                            
Martin Vigoureux Former IESG member
No Objection
No Objection (for -11) Not sent

                            
Mirja Kühlewind Former IESG member
No Objection
No Objection (2019-02-28 for -11) Sent
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 IESG member
No Objection
No Objection (2019-03-06 for -11) Sent
* 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"