Last Call Review of draft-ietf-rtcweb-ip-handling-11

Request Review of draft-ietf-rtcweb-ip-handling
Requested rev. no specific revision (document currently at 12)
Type Last Call Review
Team General Area Review Team (Gen-ART) (genart)
Deadline 2019-02-15
Requested 2019-02-01
Authors Justin Uberti
Draft last updated 2019-02-28
Completed reviews Tsvart Last Call review of -11 by Joseph Touch (diff)
Genart Last Call review of -11 by Vijay Gurbani (diff)
Assignment Reviewer Vijay Gurbani
State Completed
Review review-ietf-rtcweb-ip-handling-11-genart-lc-gurbani-2019-02-28
Reviewed rev. 11 (document currently at 12)
Review result Ready with Nits
Review completed: 2019-02-28


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


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

    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: upwards to the web application, so that they can be
  communicated to the remote endpoint for its checks.
  ...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/