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

From: Alissa Cooper <[email-masked]>
Date: Wed, 6 Mar 2019 14:33:35 -0500

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 <[email-masked]> 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
> [email-masked]
> https://www.ietf.org/mailman/listinfo/gen-art

---

From: Justin Uberti <[email-masked]>
Date: Wed, 6 Mar 2019 15:49:14 -0800

>     peer-to-peer communication should be.

Sure - happy to add text of this sort if we think it would be valuable.

>    pedantic and minimize colloquialism when writing RFCs.)

OK.

>    (Reason: Pronouns like "We" are fine for academic paper, but perhaps

:-)

> OK.