Re: [rtcweb] [OPS-DIR] Opsdir last call review of draft-ietf-rtcweb-ip-handling-11

Justin Uberti <> Sat, 23 February 2019 01:28 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 02413130EB0 for <>; Fri, 22 Feb 2019 17:28:31 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -17.5
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=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id OZQBBmccOJOn for <>; Fri, 22 Feb 2019 17:28:28 -0800 (PST)
Received: from ( [IPv6:2607:f8b0:4864:20::d33]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 2FB10130F29 for <>; Fri, 22 Feb 2019 17:28:28 -0800 (PST)
Received: by with SMTP id y6so3283463ioq.10 for <>; Fri, 22 Feb 2019 17:28:28 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=PcnL2yucadYuTG4YW6p662J+uA6i2sW6uhEg7sImxY0=; b=h6AOQo2T5uA6yHuKvbzkSQu2Uk6Xe6WadGl1TFDZGhTrx4+qEQMLyrR0DOK3ijBCqq c+Rb/0R/dXY3SUd2yX3nF8lIV91ijp9ePvbuwHYdTfXQTuoTYG3EnWxEzUnZSmVcbr/S 63Msbu/9508kPdYtwnQKMHyqqyKFHFhGlQJ2Q4pgBJG77IXJDEe7zrGOg8innMBeWE4B 5Uk883SNkM6ZEVdlwIFBWPGa5HeThh1F1s6miFfNEn1QQZiumexR087SGvWoOprjqHhE +70ECLLvMqOb12EW70IbK55Ux7+xNstchWRBFVKUoxuyhMKAKwXvKY28jFgWZtCkjjRw +9ag==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=PcnL2yucadYuTG4YW6p662J+uA6i2sW6uhEg7sImxY0=; b=GQdfpQke0ugJB+vn1S6L0zUn/yCkzwwb6/51V2Ff1fgYKDn0txtuPWTFnK4JRBgcbO Ge2Sm6ryxy4JWh+X14NZ0xeO3KRm4a9v4W7qtcBzdEiSCynd/U8oxmVrt+5YyaMSsF0i 0/SiaccDbHop8/QKVFwNXhtxxLhn5/UafiSMzRB0DEG99NZ575crfZPCwSmuytt/pGcz wFLdO/JjJ69bj/V19O124gKGpxNG8kUWu49BUCzMRgjKq14Ob8qBhKXnkBBXjFhvmTTF TVP3LJZ18DkRGaAt4hATEiVl5atWwJFMBJ1glYjSCl3NASvK7fLpsTD0QtO2YzfIVxIS R4pQ==
X-Gm-Message-State: AHQUAuZcRlsy2x6q+p7P8WKiW0DiRLOIZwwMf3BG9I0DNs6plJm1icc4 eo9TcUM8D108Zc9HRl2BpTHUKvMzxkDR9VJR5nHg2Q==
X-Google-Smtp-Source: AHgI3IZy7nNJ848QiIc+C1sPDBhgB4P0PvR88abXQPaXA08eQ+Oi97IvEKvE3mvsMrkyhxn8g8iz1WU0NIErzUUx3gM=
X-Received: by 2002:a6b:f01a:: with SMTP id w26mr3861549ioc.101.1550885306668; Fri, 22 Feb 2019 17:28:26 -0800 (PST)
MIME-Version: 1.0
References: <>
In-Reply-To: <>
From: Justin Uberti <>
Date: Fri, 22 Feb 2019 17:28:13 -0800
Message-ID: <>
To: מנחם דודג' <>
Cc:,, RTCWeb IETF <>, IETF discussion list <>, Justin Uberti <>
Content-Type: multipart/alternative; boundary="000000000000cb2ed60582859f37"
Archived-At: <>
Subject: Re: [rtcweb] [OPS-DIR] Opsdir last call review of draft-ietf-rtcweb-ip-handling-11
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: Sat, 23 Feb 2019 01:28:31 -0000

Thanks for your comments. See below.

‪On Sun, Feb 17, 2019 at 1:59 PM ‫מנחם דודג'‬‎ <>

> Reviewer: Menachem Dodge
> Review Result: Has Nits
> This document has "Intended Status" for the Standards Track but the
> document is written as an informational guide. I suggest  that the ADs
> decide whether this is informational or for the Standards Track.

Not sure exactly how this is decided, but this document is trying to set
specific requirements for how browsers should operate. As such, it seems
like Standards Track is probably the better opion.

> On the whole the document is written well and is understandable.
> In Section 5.2 it states that:
>   "Mode 1 MUST only be used when user consent has been provided. The
> details of this consent are left to the implementation; one potential
> mechanism is to tie this consent to *getUserMedia *consent.   "
> I'm not sure what "getUserMedia consent" refers to.

I can add a reference to security-arch, e.g.

> While the document defines that Mode 1 should be used when there is user
> consent and Mode 2 should be used when there is no User consent , however
> when should Mode 3 and Mode 4 be used?

These modes roughly equate to stops on a
maximum-performance<-->minimum-disclosure tradeoff slider. Implementations
that are willing to incur the performance consequences may decide to adopt
stricter default modes (and, we have seen that the Brave browser does
exactly that.) As noted in the document:

   However, implementations MAY
   choose stricter modes if desired, e.g., if a user indicates they want
   all WebRTC traffic to follow the default route.

> The document also states that:
>   "Future documents may define additional modes and/or update the
> recommended default modes. "
> If this is the case should there be a "version" defined so that the webRTC
> client and Server no which implementation has been implemented?

The server doesn't need to know which mode has been selected; the modes are
entirely specific to client behavior.