Last Call Review of draft-ietf-rtcweb-ip-handling-11
review-ietf-rtcweb-ip-handling-11-genart-lc-gurbani-2019-02-28-00

I am the assigned Gen-ART reviewer for this draft. The General Area
Review Team (Gen-ART) reviews all IETF documents being processed
by the IESG for the IETF Chair.  Please treat these comments just
like any other last call comments.

For more information, please see the FAQ at

<https://trac.ietf.org/trac/gen/wiki/GenArtfaq>.

Document: draft-ietf-rtcweb-ip-handling-??
Reviewer: Vijay K. Gurbani
Review Date: 2019-02-28
IETF LC End Date: 2019-02-15
IESG Telechat date: 2019-03-07

Summary: Ready as a proposed standard with 1 minor comment and some nits.  
In the enumeration below, "Sn" stands for "Section n".

Major issues:

Minor issues:
- S8: Perhaps a short sentence like the following one is a bit more
  descriptive than the current text in the section.  (Please feel free to
  use your editorial discretion to disregard this comment, just that it
  does not hurt to be explicit in standard documents.  At least that is my
  opinion.)

    This document has described leak of IP address privacy when WebRTC
    engages in peer-to-peer connections.  This document suggests
    mitigations against the leak of this privacy in the form of
    four different modes of WebRTC communications that explicitly guide
    the WebRTC developer in making an informed choice on how private the
    peer-to-peer communication should be.

Nits/editorial comments: 
- S3: s/private physical\/virtual/private physical or virtual/
- S3:
  OLD:
  ...exposed upwards to the web application, so that they can be
  communicated to the remote endpoint for its checks.
  NEW:
  ...provided to the web application so they can be communicated to
  the remote endpoint for connectivity checks.
- S3: s/concerns, #1/concerns, the first/
   (Similarly for other places where you have #2, etc.  Better to be
   pedantic and minimize colloquialism when writing RFCs.)
- S4: s/As a result, we want to avoid blunt solutions/As a result, the
   preference is to avoid blunt solutions/
   (Reason: Pronouns like "We" are fine for academic paper, but perhaps
   avoided in RFCs.)
- S6.2:
   - s/sent to the web application host/sent to the remote web application host/
   - s/and TCP get the same routing/and TCP get the same routing treatment/

Thanks!