Vijay, thanks for your review. I entered a No Objection ballot and pointed to your review therein. Alissa > On Feb 28, 2019, at 3:11 PM, Vijay Gurbani <vijay.gurbani@xxxxxxxxx> wrote: > > 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! > > _______________________________________________ > Gen-art mailing list > Gen-art@xxxxxxxx > https://www.ietf.org/mailman/listinfo/gen-art
