Re: [Wpack] Problem statement and scope for BoF

Benjamin Kaduk <bkaduk@akamai.com> Wed, 07 August 2019 17:12 UTC

Return-Path: <bkaduk@akamai.com>
X-Original-To: wpack@ietfa.amsl.com
Delivered-To: wpack@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5A586120192 for <wpack@ietfa.amsl.com>; Wed, 7 Aug 2019 10:12:30 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.7
X-Spam-Level:
X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=akamai.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 MAEGpxjDjS3n for <wpack@ietfa.amsl.com>; Wed, 7 Aug 2019 10:12:28 -0700 (PDT)
Received: from mx0b-00190b01.pphosted.com (mx0b-00190b01.pphosted.com [IPv6:2620:100:9005:57f::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5ECAC120232 for <wpack@ietf.org>; Wed, 7 Aug 2019 10:12:28 -0700 (PDT)
Received: from pps.filterd (m0122330.ppops.net [127.0.0.1]) by mx0b-00190b01.pphosted.com (8.16.0.42/8.16.0.42) with SMTP id x77Gw2aF015786; Wed, 7 Aug 2019 18:12:26 +0100
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; h=date : from : to : cc : subject : message-id : references : mime-version : content-type : in-reply-to; s=jan2016.eng; bh=2IOwspE/zQAzHgblP3SuIKKZsFlSfgTnOJqNNh2abKA=; b=J8PXxP9miL+w763ibIGN4KuH739FQFiixpbhYOszSeZVnxmjNmcM8NCqYNa/8Cb9vYeD naRyf/3KlMGqYkXJN5kRNvx/SkQdHivRRVO4wpCdjPR2/iKfkhIWAywVIEUWsccTaPK5 JxfDe3Y/euALYbeVgQGGJJ+dKd7m+QgTBTT048rPymRye9+TvFidJ0J8jR4Ukf3had8w XT5NWtVqM14yt5fxVv+JAwsGHIspxL/X/f7r+Mt9AXkK6NZASvnwecpNFhS4jlDoXY1t IqVaLjkTVE8QlPLlu9T9GoGrHkRpZY+u86eZ9BzHC+c7Lx9KmOKLip6ClQsECBZBdoSv fQ==
Received: from prod-mail-ppoint4 (prod-mail-ppoint4.akamai.com [96.6.114.87] (may be forged)) by mx0b-00190b01.pphosted.com with ESMTP id 2u51wv1tqe-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 07 Aug 2019 18:12:25 +0100
Received: from pps.filterd (prod-mail-ppoint4.akamai.com [127.0.0.1]) by prod-mail-ppoint4.akamai.com (8.16.0.27/8.16.0.27) with SMTP id x77H2Yn4019430; Wed, 7 Aug 2019 13:12:25 -0400
Received: from prod-mail-relay14.akamai.com ([172.27.17.39]) by prod-mail-ppoint4.akamai.com with ESMTP id 2u55m19w7p-1; Wed, 07 Aug 2019 13:12:24 -0400
Received: from bos-lpczi.kendall.corp.akamai.com (bos-lpczi.kendall.corp.akamai.com [172.19.17.86]) by prod-mail-relay14.akamai.com (Postfix) with ESMTP id 5541B815F8; Wed, 7 Aug 2019 17:12:21 +0000 (GMT)
Received: from bkaduk by bos-lpczi.kendall.corp.akamai.com with local (Exim 4.86_2) (envelope-from <bkaduk@akamai.com>) id 1hvPU3-0005lK-R8; Wed, 07 Aug 2019 12:12:19 -0500
Date: Wed, 07 Aug 2019 12:12:19 -0500
From: Benjamin Kaduk <bkaduk@akamai.com>
To: Jeffrey Yasskin <jyasskin=40google.com@dmarc.ietf.org>
Cc: "Salz, Rich" <rsalz@akamai.com>, "wpack@ietf.org" <wpack@ietf.org>
Message-ID: <20190807171218.GB19909@akamai.com>
References: <CANh-dXkRGGVAzRPC5k8p0u6b7NuidkOt81in70eF3Nwe_BAZQw@mail.gmail.com> <C1E62FBD-28A5-4B1B-8C99-06397919E68C@akamai.com> <CANh-dX=Q6G0ArLhHA6K-DsW87QkgJPNmP25vj05LNcLmZEysJA@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <CANh-dX=Q6G0ArLhHA6K-DsW87QkgJPNmP25vj05LNcLmZEysJA@mail.gmail.com>
User-Agent: Mutt/1.5.24 (2015-08-30)
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2019-08-07_04:, , signatures=0
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=0 malwarescore=0 phishscore=0 bulkscore=0 spamscore=0 mlxscore=0 mlxlogscore=614 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1906280000 definitions=main-1908070166
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:5.22.84,1.0.8 definitions=2019-08-07_04:2019-08-07,2019-08-07 signatures=0
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 impostorscore=0 bulkscore=0 mlxlogscore=600 priorityscore=1501 adultscore=0 lowpriorityscore=0 mlxscore=0 spamscore=0 phishscore=0 clxscore=1011 suspectscore=0 malwarescore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-1906280000 definitions=main-1908070166
Archived-At: <https://mailarchive.ietf.org/arch/msg/wpack/LiNISQoxukOWRCLbKlK6qhWyam0>
Subject: Re: [Wpack] Problem statement and scope for BoF
X-BeenThere: wpack@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Web Packaging <wpack.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/wpack>, <mailto:wpack-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/wpack/>
List-Post: <mailto:wpack@ietf.org>
List-Help: <mailto:wpack-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/wpack>, <mailto:wpack-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 07 Aug 2019 17:12:30 -0000

On Wed, Aug 07, 2019 at 10:04:16AM -0700, Jeffrey Yasskin wrote:
> On Mon, Aug 5, 2019 at 4:28 PM Salz, Rich <rsalz@akamai.com> wrote:
> 
> > Commenting only on the "problem" part of your post; I reserve the right to
> > comment on other parts later :)
> >
> > I am surprised that search carousel and AMP isn't mentioned, as frankly it
> > is the use-case with the most economic incentive/impact. Honesty compels us
> > to explicitly mention it, plainly, and first.
> >
> 
> The AMP and Search Carousel use case is mentioned as "Even users with
> highly-available internet connections want to be able to read and interact
> with web pages as quickly as possible after clicking a link." The use case
> is broader than just one framework or piece of search result UI, so it
> seemed wrong to call out particular brands.
> 
> Further, my impression of IETF charters is that they discuss and prioritize
> the goals of the IETF working group, not just the goals of the company
> employing the individuals who are proposing the WG. My impression is that
> the IETF sets a lower priority on fixing the AMP URL problem than improving
> access to the global internet, so I wrote the higher priority use case
> first.
> 
> It's true that a lot of Google's investment in the problem is driven by
> trying to fix things around AMP, but I think it's fair to solve a problem
> for less-wealthy users by using funding from a wealthier client who can
> also benefit from the same solution.
> 
> I'm happy to take changes here, but I need those changes to be designed to
> maximize the chance of chartering a working group. The ideal change comes
> with a statement along the lines of "I don't support chartering a WG with
> the current problem/scope/charter, but I would support it after this
> change." Rich, judging from your ESCAPE submission, you don't want the IETF
> to do this work at all, so I worry that if I take your suggestions, it'll
> make the IETF less likely to create the WG. If I've misread your post, and
> you actually think the IETF is enthusiastic to prioritize AMP first, let me
> know.

Well, given the recent breadth of discussion around expanding the
Internet threat model, there's also been a bit of introspection about
the way we think about the work we do in general.  So that we are not
just going to consider what the stated goals are (and whether they can
be achieved), but what the side effects of doing that work would be, and
whether there are other (potentially harmful) consequences of building a
given technology.  The IAB has explicitly indicated that the risk of
consolidation into a small number of service providers is something they
are concerned about, and so if one should expect them (and, presumably,
the IESG as well) to take that risk into account when considering
chartering new work.  Having an honest discussion of what the possible
and likely side effects of a given technology could be seems to be a
generally helpful thing for the IAB and IESG in their consideration of
proposed ne work, and I for one would welcome such a discussion here.

-Ben