[rtcweb] Eric Rescorla's No Objection on draft-ietf-rtcweb-ip-handling-11: (with COMMENT)

[Datatracker on behalf of Eric Rescorla <[e-mail]>]

Eric Rescorla has entered the following ballot position for
draft-ietf-rtcweb-ip-handling-11: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-rtcweb-ip-handling/



----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

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