Re: [rtcweb] Genart last call review of draft-ietf-rtcweb-ip-handling-11

[Justin Uberti <[e-mail]>]

On Thu, Feb 28, 2019 at 12:13 PM Vijay Gurbani <[e-mail]>
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.