Reviewer: Vijay Gurbani Review result: Ready with Nits 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!
