Please respond to the Gen-ART review.

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

* 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"

I especially enjoyed the Security Consideration section :-)

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.

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