On Thu, Feb 28, 2019 at 12:13 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.
Sure - happy to add text of this sort if we think it would be valuable.
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.)
OK.
- 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/
OK.
