Re: [Wpack] wpack@ietf110: minutes posted

Phillip Hallam-Baker <phill@hallambaker.com> Tue, 22 June 2021 13:55 UTC

Return-Path: <hallam@gmail.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 2EF573A260D for <wpack@ietfa.amsl.com>; Tue, 22 Jun 2021 06:55:59 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.402
X-Spam-Level:
X-Spam-Status: No, score=-1.402 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FORGED_FROMDOMAIN=0.248, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.248, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
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 wMyrizJ31hjA for <wpack@ietfa.amsl.com>; Tue, 22 Jun 2021 06:55:55 -0700 (PDT)
Received: from mail-qk1-f170.google.com (mail-qk1-f170.google.com [209.85.222.170]) (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 F08FD3A260B for <wpack@ietf.org>; Tue, 22 Jun 2021 06:55:54 -0700 (PDT)
Received: by mail-qk1-f170.google.com with SMTP id j184so39686457qkd.6 for <wpack@ietf.org>; Tue, 22 Jun 2021 06:55:54 -0700 (PDT)
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=OIWpBf8gzEN3kOSErOxOz/ymEAztoPBeIsKQYSsVowI=; b=PpK+mQvanTUX/v4ixBgxRRJBMRNFG+Bk8vhyujNyn2BCS8sPmCNLoDlbj/bLRt0YMh BP8whWkg4T4NI87OJVzQsKrd87Op9pXo6je09Ow6ubybu5kZT/QLSVTW2OfT/PNBoyY7 AE1H47aAXT7dNLPowfzoNnQWSLK1TWY1Ay2ABrKlmMjgqw9QXwiUh3B/EstiVpFFXqz1 SKqKxW3bde4jIOEs/35G4eHj6ta9PS5cnew7W5aYwXUPe0xc5vUAAysJ+AWKdy5/so5H zqUjsNiqPElOlc/fb3kgS1cTCC8e+QaGwLQnXrmIpDzEp4ikO5BccSM6dIFwLDcISi3K 0eVw==
X-Gm-Message-State: AOAM531gv8fNtKdZWUj64msy1vJBNYXE53wF4hKzTDjGVHDF3yTKIxiH kItdR96oTRYCdLFcuDg9CoxjISEM3L+mYBeyz06Hcvx+Vd70Gg==
X-Google-Smtp-Source: ABdhPJwK9clpF3gmdF8wk/SkwTT/2RKxhS7K0h7VzKQ9AJVHY/keL38XPwaA8LaGWGZU4J6A4ReiZOa7yoNsEy3oAL4=
X-Received: by 2002:a25:688c:: with SMTP id d134mr5406894ybc.523.1624370153762; Tue, 22 Jun 2021 06:55:53 -0700 (PDT)
MIME-Version: 1.0
References: <F99B81CD-37E0-4AF2-90E5-F56C57717E85@sn3rd.com>
In-Reply-To: <F99B81CD-37E0-4AF2-90E5-F56C57717E85@sn3rd.com>
From: Phillip Hallam-Baker <phill@hallambaker.com>
Date: Tue, 22 Jun 2021 09:55:42 -0400
Message-ID: <CAMm+LwhJ2RQ6jC7Du1YpotUvZmLZhy8a7qCLLGGeR4-DXWEK9Q@mail.gmail.com>
To: Sean Turner <sean@sn3rd.com>
Cc: WPACK List <wpack@ietf.org>
Content-Type: multipart/alternative; boundary="000000000000ffb2c405c55b25bf"
Archived-At: <https://mailarchive.ietf.org/arch/msg/wpack/5kLae2ZcjcVuw37sY4faR-7PIKs>
Subject: Re: [Wpack] wpack@ietf110: minutes posted
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: Tue, 22 Jun 2021 13:55:59 -0000

>From the minutes

Daniel Ehrenberg: The motivation for removing some of these features
is to reduce the scope to increase the adoption. There is particular
concern around how content-blockers will work in this context.

Martin Thomson: I think this is the right sort of thing to be thinking
about right now. But a narrowly targeted thing is more likely to be
successful here. If we cut a little too deep, we always have the
opportunity to define something more specific later, possibly with a
different MIME type.


People keep saying this in IETF and I have yet to see evidence for the
claim. Deployment depends on two things, first cost of implementation,
second the utility of the product. Fewer features means lower cost but it
also means lower incentive to deploy.

There are good reasons to keep a tight hand on features, but deployment
isn't one of them. Forcing people to think at a higher level and produce a
more flexible product is the reason I object to niche features that fail to
extend to wider use.

I designed, implemented and specified DARE by myself in under three months.
It does everything WPACK does and more. Besides being a ZIP file format, it
supports incremental authentication via a Merkle Tree, it also supports
incremental encryption and threshold cryptography. Now if I can design and
implement in three months, I really don't think it's the implementation
cost that is stopping adoption.

None of my features are optional because I am going after a different use
case - securing data at rest. WPACK is not a format that could be used to
encrypt and authenticate the transaction log of a database or a social
media forum because those applications simply haven't been considered. But
it could be if that was considered from the start. Instead what will happen
is that a set of choices is made in the first version that foreclose later
choices.

https://www.ietf.org/archive/id/draft-hallambaker-mesh-dare-11.html



On Sat, Mar 20, 2021 at 9:35 PM Sean Turner <sean@sn3rd.com> wrote:

> Hi! I have posted the minutes from WPACK’s session at IETF110:
> https://datatracker.ietf.org/meeting/110/materials/minutes-110-wpack-00
>
> Thanks to Chris Lemmons for taking notes. Please send any comments to
> wpack-chairs@ietf.org.
>
> spt
> _______________________________________________
> Wpack mailing list
> Wpack@ietf.org
> https://www.ietf.org/mailman/listinfo/wpack
>