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

Justin Uberti <> Thu, 07 March 2019 23:37 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 2D1AA1277D2 for <>; Thu, 7 Mar 2019 15:37:33 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -16.479
X-Spam-Status: No, score=-16.479 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, MISSING_HEADERS=1.021, 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=no autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 43pgP2mux8tO for <>; Thu, 7 Mar 2019 15:37:31 -0800 (PST)
Received: from ( [IPv6:2607:f8b0:4864:20::143]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id E9793130F07 for <>; Thu, 7 Mar 2019 15:37:29 -0800 (PST)
Received: by with SMTP id z124so18739476itc.2 for <>; Thu, 07 Mar 2019 15:37:29 -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:cc; bh=Q0W3EMvkuvltvV126sXap/YINPw9LqyK9msB8t+Elt0=; b=NHAMtALakRge8erG0dvdAAdERAgaer5SlW56SPMdxWDK6tIVXHHl9F3x0/Bfa4AUAq ouieTJouSokvOo+b/iwVdhzRTsN6Wh7xzXyT2/alzXwmFap2jDq/jp4lI0BsTppOVsR5 ug77MXCf3SbzQ/qBix8cYFXbOtnvsVMuCRL7gNRZc2hJKnDGRO/pDVwodUuc5K26UCoU wt9NAWmfpofEnhYGNoile9cyS1XLx+PIPKY0pp4g3b0GBHfRuvKqNxbXq+KkJPZrKlPH hl8H6Ca30Xz0plgQrdvQd6bRghi/HTU2rRZaWyseFRg8G5RMEEkpsN7PKdv8BYOa2418 aVLQ==
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:cc; bh=Q0W3EMvkuvltvV126sXap/YINPw9LqyK9msB8t+Elt0=; b=QreU8oz6RX4jsSx+LrW3cB0s4t43yF8RWT0JmXbIQUYZFBvYOFMdA0AG3yesdPt/G3 qoLgZYof70DEasNRXt22+3b9NkBesAdJQPMEDQEWiuDSu73srv3K77LMvxvWdntA+ylC e/PT6Yf+Of8y03IMjo4JVWwHxFrG6Q+AthPfuD2/uLIoJlzMqBHUxoPQjouisHC1kmUJ bakAEqNlytYwQh11w00jN2vQeUUWCWMhW18Kdw2P1wnH4h7VoTDFj1yVi+/WFGo2U6FX jTRMq6m3/xxn+fsrv3IiebblqObcDt3LVTncIm1w/Fe4NWFWCa7PV261okk8WgQzTh5y Nl6Q==
X-Gm-Message-State: APjAAAVf/9lwStFkgAOHaQJXoUpEBMCH/iOnhnZptmfvbgC6rXrBz3cA X5lptr4Ei+j7nWuPAjM/Pja49+10El3B8jdlAwSttg==
X-Received: by 2002:a02:a482:: with SMTP id d2mt1538719jam.88.1552001848866; Thu, 07 Mar 2019 15:37:28 -0800 (PST)
MIME-Version: 1.0
References: <>
In-Reply-To: <>
From: Justin Uberti <>
Date: Thu, 07 Mar 2019 15:37:17 -0800
Message-ID: <>
Cc: The IESG <>, RTCWeb IETF <>,,
Content-Type: multipart/alternative; boundary="000000000000e615750583899633"
Archived-At: <>
Subject: Re: [rtcweb] Benjamin Kaduk's No Objection on draft-ietf-rtcweb-ip-handling-11: (with COMMENT)
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 23:37:33 -0000

On Thu, Mar 7, 2019 at 1:49 AM Datatracker on behalf of Benjamin Kaduk <> wrote:

> Benjamin Kaduk 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
> for more information about IESG DISCUSS and COMMENT positions.
> The document, along with other ballot positions, can be found here:
> ----------------------------------------------------------------------
> ----------------------------------------------------------------------
> I agree with Ben about the STUN/TURN normativity.
> Section 5.1
>    2.  By default, WebRTC should be able to negotiate direct peer-to-
>        peer connections between endpoints (i.e., without traversing a
>        NAT or relay server).  [...]
> I'm not sure how to interpret "be able to", here, with respect to
> "without traversing a NAT", since if one endpoint is behind a NAT w.r.t.
> the public Internet, that's not possible.

There is an implicit "where possible" here. The specific scenario is for
two devices behind the same NAT who could communicate directly if only they
knew each others' addresses; in this case, a direct connection should be
possible, which implies that there needs to be some way for the two sides
to share their machine addresses. Naturally, devices behind different NATs
will not be able to do this.

> Section 5.2
>    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.
> nit: we may not have left a big enough breadcrumb trail for the reader
> to find "getUserMedia consent".