Re: [rtcweb] Eric Rescorla's No Objection on draft-ietf-rtcweb-ip-handling-11: (with COMMENT)

Justin Uberti <juberti@google.com> Wed, 06 March 2019 23:45 UTC

Return-Path: <juberti@google.com>
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 02E8312008A for <rtcweb@ietfa.amsl.com>; Wed, 6 Mar 2019 15:45:19 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -17.5
X-Spam-Level:
X-Spam-Status: No, score=-17.5 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, ENV_AND_HDR_SPF_MATCH=-0.5, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_DEF_SPF_WL=-7.5] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.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 CRJRRiJE7Frh for <rtcweb@ietfa.amsl.com>; Wed, 6 Mar 2019 15:45:15 -0800 (PST)
Received: from mail-io1-xd36.google.com (mail-io1-xd36.google.com [IPv6:2607:f8b0:4864:20::d36]) (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 DA8F213110D for <rtcweb@ietf.org>; Wed, 6 Mar 2019 15:45:14 -0800 (PST)
Received: by mail-io1-xd36.google.com with SMTP id p196so11816965iod.9 for <rtcweb@ietf.org>; Wed, 06 Mar 2019 15:45:14 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=EYf7a1tkguXfM3/avo7+qBjJij/MvhwxajDnaVPByCM=; b=AxosyoT8VgkWkmbLL+HPw84tzWFXKZfvQD0BTg9Y1DsItI0VGIbvGUZEr4l6ZNg1zm Ip1/YhJvhbGKDbMdP76LDWW+JLjcZDlkgYFBDBXG18iu2TrtmceGNh6UTsD4PWMahKQF tpe/y3UgnkJsOwWpzCbuD59+QOGhaaI9xveiF6pZGLSQpXhZVrn/ezbhMBZ5/1oEwY0h QMFBhb+Pj4/vvu4He6JNOXB6vUhsakH4yXe/ADruCiGzBkEaKNwolLQHoJw4TeihShUs qeaQp+/h6TfciKzhGfb5xVXrUGV7mExUd/A6yYSV8AU78U9ZfQuKcj237CIRqxfNf5/9 x2iA==
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=EYf7a1tkguXfM3/avo7+qBjJij/MvhwxajDnaVPByCM=; b=nbR4F2w2fMWN3kieNbJ4uBFGe9Lkw8FNG3v686zabyQnKRROjODQq+4No2GlE9UQj8 cFIYocc426OJTH611AtkvFDcSiFk2hnV7VC+Lu9/hS9cMnxYEqUt6oUa3+pzqjXzmXdT ozwSsmlsn0QCK96b46Exz2QKtoCSvEN4MPLSSu6rCp+k/vKccisoGFxyKivQZTjBAdtz GJTnGrvs6oWVT5NfvNXnUaoNJtKR4C845bCDWLkeBUmZ6HIc695rFl3k7djmOkcWdITZ L8bgIGGZuZHqpZ0ES1barWdFZ7Q0zfZYMEM1rUvMjmE3q6m5G48E1dNwr9EpGlYRiNnR nE8A==
X-Gm-Message-State: APjAAAUV2TFAcitdMMn+tGdcEzEN9q01cC2Vcp4/X4V0UFCIgihdy4lF gXJakRGxFk8V8BJPYmpD600FgYCQvZ9Za6R6xPdlig==
X-Google-Smtp-Source: APXvYqzan18HaV/yO7WTu9HBebM5ijR4/jHCPulTWyG8ewDrK+F7FEIvXFtkLlgI5/YHcgJAmrtsUpi0xhKtsCjYSFY=
X-Received: by 2002:a5e:df01:: with SMTP id f1mr4707262ioq.101.1551915913899; Wed, 06 Mar 2019 15:45:13 -0800 (PST)
MIME-Version: 1.0
References: <155188458557.5238.17233070387773707583.idtracker@ietfa.amsl.com>
In-Reply-To: <155188458557.5238.17233070387773707583.idtracker@ietfa.amsl.com>
From: Justin Uberti <juberti@google.com>
Date: Wed, 6 Mar 2019 15:45:02 -0800
Message-ID: <CAOJ7v-0FSHf0y3q14yRE_YiaOafB40s1DgPJhmFe4O42kb-Ykg@mail.gmail.com>
To: Datatracker on behalf of Eric Rescorla <ietf-secretariat-reply@ietf.org>
Cc: The IESG <iesg@ietf.org>, draft-ietf-rtcweb-ip-handling@ietf.org, RTCWeb IETF <rtcweb@ietf.org>, rtcweb-chairs@ietf.org
Content-Type: multipart/alternative; boundary="000000000000c54729058375945c"
Archived-At: <https://mailarchive.ietf.org/arch/msg/rtcweb/mbj_387hRPqjes7FOSk54gbrMcg>
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 <rtcweb.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/rtcweb>, <mailto:rtcweb-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/rtcweb/>
List-Post: <mailto:rtcweb@ietf.org>
List-Help: <mailto:rtcweb-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/rtcweb>, <mailto:rtcweb-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 06 Mar 2019 23:45:19 -0000

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.

>
>
> 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.