Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B6A06131329 for ; Wed, 6 Mar 2019 18:34:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nrfhpFVaFRXw for ; Wed, 6 Mar 2019 18:34:17 -0800 (PST) Received: from mail-lj1-x232.google.com (mail-lj1-x232.google.com [IPv6:2a00:1450:4864:20::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A5606131321 for ; Wed, 6 Mar 2019 18:34:14 -0800 (PST) Received: by mail-lj1-x232.google.com with SMTP id l5so12808976lje.1 for ; Wed, 06 Mar 2019 18:34:14 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=mH22Rz9Fifbnu1noX9kEUmr8XE3Xw2Lv0k2uiiYUDVs=; b=dVu92ExHQHbb6Zt3OtFpuRBvjdD0wenY60npZ9lKI9nNR+/kfcOP8LwIWxyOV8JqM+ g+wJgfqQT6aNEJ9rB8A/rbArqrDGDXCc0qnca+q2XDdeeSczhvvaGFsGNFDsPw9Cvswm lxisW/hz9uPvTa6wFEk3O8GGP8gm6bzQrpbues1sxxCfDBnfiLQ29HoCTVPCDlF44u1C TSeuQFa+w2l+Tf/ZykswKwqcW1mEvLy/+hZv4g1qdDCluoxQWVIVsV8JK57EZLgQBqLI McARr8axOn6l06md9+Av+sFmfV5/sWWVCEKi6kUP1KnytGUDgR2B6mu3M1EQsKwwwH7T YciQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=mH22Rz9Fifbnu1noX9kEUmr8XE3Xw2Lv0k2uiiYUDVs=; b=B3o6W/HqemBenpZhgRvo/ilCYsEkDAVbhDjh0rPTmp9hG2oQrYNm1TjE+dqzd7YuSQ AnDNSablGV/hR2heoUi6i+A4VNMBfAJs1+C2RmjiX31QfUYSXqGDHeZ7tnr8wMO6al0r +T7aIIxUf4CUV13zFRkLKx2vmczssWwRWN0BybQdylFOfQ2hTmg15cxoineqeFoPohQ5 HcYjttb94LUZjtKaaNpwari/YcST3J6+yiiMsGINpP5JROPCHEEyPtOvEk5HyY3UVD46 szHArAQXt1O2priWEL4RWFc67kzjjczbGsymUszf7aX/ThPhrZJnKgJx/KPpt2HcKvTE jnyQ== X-Gm-Message-State: APjAAAUYSd3kXBa1z7iw7SwtOYxGEsOaIn9JwVaLa2bs55SQ73EXJkDR /TJwtONLKiPEunZK7PtTABVSWhcjLKpk/AOu8ACMsw== X-Google-Smtp-Source: APXvYqygas8cJDqQu/pJ5N0Yd17R5PKDGK7k5S/1MaWRdCcuuK/l+LvJcBMV+kwN0GNalQEA3wsWUs/LnPQYxnYanNs= X-Received: by 2002:a2e:a28f:: with SMTP id k15mr4319370lja.160.1551926052659; Wed, 06 Mar 2019 18:34:12 -0800 (PST) MIME-Version: 1.0 References: <155188458557.5238.17233070387773707583.idtracker@ietfa.amsl.com> In-Reply-To: From: Eric Rescorla Date: Wed, 6 Mar 2019 18:33:35 -0800 Message-ID: To: Justin Uberti Cc: Datatracker on behalf of Eric Rescorla , RTCWeb IETF , draft-ietf-rtcweb-ip-handling@ietf.org, The IESG , rtcweb-chairs@ietf.org Content-Type: multipart/alternative; boundary="000000000000164cc9058377f19a" Archived-At: Subject: Re: [rtcweb] Eric Rescorla's No Objection on draft-ietf-rtcweb-ip-handling-11: (with COMMENT) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Mar 2019 02:34:20 -0000 --000000000000164cc9058377f19a Content-Type: text/plain; charset="UTF-8" On Wed, Mar 6, 2019 at 3:45 PM Justin Uberti wrote: > > > On Wed, Mar 6, 2019 at 7:03 AM Datatracker on behalf of Eric Rescorla < > ietf-secretariat-reply@ietf.org> wrote: > >> Eric Rescorla has entered the following ballot position for >> draft-ietf-rtcweb-ip-handling-11: No Objection >> >> When responding, please keep the subject line intact and reply to all >> email addresses included in the To and CC lines. (Feel free to cut this >> introductory paragraph, however.) >> >> >> Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html >> for more information about IESG DISCUSS and COMMENT positions. >> >> >> The document, along with other ballot positions, can be found here: >> https://datatracker.ietf.org/doc/draft-ietf-rtcweb-ip-handling/ >> >> >> >> ---------------------------------------------------------------------- >> COMMENT: >> ---------------------------------------------------------------------- >> >> Rich version of this review at: >> https://mozphab-ietf.devsvcdev.mozaws.net/D3744 >> >> >> >> COMMENTS >> S 3. >> > >> > 1. If the client is multihomed, additional public IP addresses for >> > the client can be learned. In particular, if the client tries >> to >> > hide its physical location through a Virtual Private Network >> > (VPN), and the VPN and local OS support routing over multiple >> > interfaces (a "split-tunnel" VPN), WebRTC will discover not >> only >> >> This might be simpler if you said "route traffic over" rather than >> "support routing" >> >> Also, do you want to say "may discover" because the guidelines below >> would potentially stop that. >> > > This is the problem statement section; I think it is expected that the > proposed guidelines would invalidate some of the problem definition. > > That said, I could get behind switching 'will' to 'can', as is used in S3, > category #2. > That's fine. >> >> S 6.2. >> > addresses (0.0.0.0 for IPv4, :: for IPv6), which allows the OS to >> > route WebRTC traffic the same way as it would HTTP traffic. STUN >> and >> > TURN will work as usual, and host candidates can still be >> determined >> > as mentioned below. >> > >> > 6.2. Determining Host Candidates >> >> This is framed a little confusingly, because all host candidates are >> suitable in mode 1. Perhaps add "In modes XXX..." >> > > This seems like a good addition. > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > --000000000000164cc9058377f19a Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Wed, Mar 6, 2019 at 3:45 PM Justin= Uberti <juberti=3D40goog= le.com@dmarc.ietf.org> wrote:


On Wed, Mar 6, 2= 019 at 7:03 AM Datatracker on behalf of Eric Rescorla <ietf-secretariat-reply@= ietf.org> wrote:
Eric Rescorla has entered the following ballot position for
draft-ietf-rtcweb-ip-handling-11: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/iesg/s= tatement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draf= t-ietf-rtcweb-ip-handling/



----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

Rich version of this review at:
https://mozphab-ietf.devsvcdev.mozaws.net/D3744


COMMENTS
S 3.
>=C2=A0 =C2=A0
>=C2=A0 =C2=A0 =C2=A0 1.=C2=A0 If the client is multihomed, additional p= ublic IP addresses for
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 the client can be learned.=C2=A0 In = particular, if the client tries to
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 hide its physical location through a= Virtual Private Network
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 (VPN), and the VPN and local OS supp= ort routing over multiple
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 interfaces (a "split-tunnel&quo= t; VPN), WebRTC will discover not only

This might be simpler if you said "route traffic over" rather tha= n
"support routing"

Also, do you want to say "may discover" because the guidelines be= low
would potentially stop that.

This is th= e problem statement section; I think it is expected that the proposed guide= lines would invalidate some of the problem definition.=C2=A0

=
That said, I could get behind switching 'will' to 'c= an', as is used in S3, category #2.=C2=A0

That's fine.


<= blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-l= eft:1px solid rgb(204,204,204);padding-left:1ex">


S 6.2.
>=C2=A0 =C2=A0 =C2=A0 addresses (0.0.0.0 for IPv4, :: for IPv6), which a= llows the OS to
>=C2=A0 =C2=A0 =C2=A0 route WebRTC traffic the same way as it would HTTP= traffic.=C2=A0 STUN and
>=C2=A0 =C2=A0 =C2=A0 TURN will work as usual, and host candidates can s= till be determined
>=C2=A0 =C2=A0 =C2=A0 as mentioned below.
>=C2=A0 =C2=A0
>=C2=A0 =C2=A06.2.=C2=A0 Determining Host Candidates

This is framed a little confusingly, because all host candidates are
suitable in mode 1. Perhaps add "In modes XXX..."

This seems like a good addition.
_______________________________________________
rtcweb mailing list
rtcweb@ietf.org https://www.ietf.org/mailman/listinfo/rtcweb
--000000000000164cc9058377f19a--