Re: [dispatch] draft-devault-bare-07 to be discussed during IETF 114

Eric Rescorla <ekr@rtfm.com> Mon, 25 July 2022 13:15 UTC

Return-Path: <ekr@rtfm.com>
X-Original-To: dispatch@ietfa.amsl.com
Delivered-To: dispatch@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 83F33C159529 for <dispatch@ietfa.amsl.com>; Mon, 25 Jul 2022 06:15:30 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.903
X-Spam-Level:
X-Spam-Status: No, score=-1.903 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.20210112.gappssmtp.com
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wtIjSKZx2K_J for <dispatch@ietfa.amsl.com>; Mon, 25 Jul 2022 06:15:29 -0700 (PDT)
Received: from mail-il1-x12c.google.com (mail-il1-x12c.google.com [IPv6:2607:f8b0:4864:20::12c]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 582D9C14F74A for <dispatch@ietf.org>; Mon, 25 Jul 2022 06:15:20 -0700 (PDT)
Received: by mail-il1-x12c.google.com with SMTP id y13so5558941ilv.5 for <dispatch@ietf.org>; Mon, 25 Jul 2022 06:15:20 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20210112.gappssmtp.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=CuiYKaWjtOnAbzaE6wxpQXTdbLLgCo9ub74xYfw0Gps=; b=6nsx35Y1v0uemYlqCdtdy4JdPpwbTSoIgNs+g0XQ9papcVJR0Ts52qQ3P/RaX0z19U F/DWKgR5ImNvdmO69sqz13emAQdhsmjB+37e2kU23293OHlO1Sa5hWJL297D4DnvTo4n pR4z7xfBT4tCkmyVLZ2IaachnMMmM3FMYXXbnzDchDC2tHki8nOX1xJ0Lam0Onx0yZaL UxCnCBCetAEhI+DU4wwMiIIDgyb/WO0Z2DUExObNGObHhWJhbsfDkU2ncLGBMWN4S809 AA8nPdA6XL7y+jL4KCTO2jfMDIRJ1yhL1grJi7oNBXeRTgQJ3exqAa4nign7kggnYFyx DQbQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=CuiYKaWjtOnAbzaE6wxpQXTdbLLgCo9ub74xYfw0Gps=; b=ue3oFhLSKGC126l22cKRb/q26pSn65Sdb4m3g1RbwVlxWNmtiYZ9AFRuXlHEmPCik8 uB1Php+4XZIX35Hov2iBiAjdqHQqriZ+ZQB63nRxiguLvSJ7X+4+NyvbBfEhKtpPhxX7 5Ni4fVBDjwGw+FvNlZETZt9ipZWiiwGVXwcDuWQcB/NGzHjavDssifC1se+DoifSGJo4 wtNagU+qgznQKR1K4ML5tqK3Dyb0nO6Z2wySH2AkLi+pu6MmRLXZNi6sG89jP9tIv1U7 KL9G+ZL1E6xGs6Xy4B7klO5mJGef2Wr8lYCuYEnXmeFbPYVsPwux1/eeUoR1y1XOMVwH M1SQ==
X-Gm-Message-State: AJIora9LiK4GPRfz4/+ZuSNqthH6JU5cjnp13a8PzEyQoLKXcBSZmGHV XQN5/C8jW2IMWgm/e/AVeG4gUdXe0i6zN54O2XWbEd6zjTU=
X-Google-Smtp-Source: AGRyM1sQ+0L/ULrH4Cp/+sEAcUlwW5F7Ap0ABfym9/3KfknO6b++/U6J/7g1M9Wyr5PMvnTeaTTed6iJllPOAv+o1NY=
X-Received: by 2002:a92:d606:0:b0:2dc:e2d1:b75b with SMTP id w6-20020a92d606000000b002dce2d1b75bmr4748934ilm.91.1658754919248; Mon, 25 Jul 2022 06:15:19 -0700 (PDT)
MIME-Version: 1.0
References: <YqC0MHD7MPpcFEuc@cvut.cz> <20220608210551.72EB94341C93@ary.qy> <CAL02cgTqv5_18w_sNZHuk5uStRL3UGH5JzxHPxkyG1MEBXZLYQ@mail.gmail.com> <CAL02cgTcoN5suDOMAs5L8kM9MU-4Kyyt5pjNCiTZX=50fMbErQ@mail.gmail.com>
In-Reply-To: <CAL02cgTcoN5suDOMAs5L8kM9MU-4Kyyt5pjNCiTZX=50fMbErQ@mail.gmail.com>
From: Eric Rescorla <ekr@rtfm.com>
Date: Mon, 25 Jul 2022 06:14:43 -0700
Message-ID: <CABcZeBMoVKxbjBT3r_zs7okTsM77Qy97FXVcpUAntVSqwUHSkQ@mail.gmail.com>
To: Richard Barnes <rlb@ipv.sx>
Cc: John Levine <johnl@taugh.com>, DISPATCH <dispatch@ietf.org>
Content-Type: multipart/alternative; boundary="000000000000bb4ea105e4a0f979"
Archived-At: <https://mailarchive.ietf.org/arch/msg/dispatch/Zs84OpU6efDKxIw6LYpruJxfP1A>
Subject: Re: [dispatch] draft-devault-bare-07 to be discussed during IETF 114
X-BeenThere: dispatch@ietf.org
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: DISPATCH Working Group Mail List <dispatch.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dispatch>, <mailto:dispatch-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/dispatch/>
List-Post: <mailto:dispatch@ietf.org>
List-Help: <mailto:dispatch-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dispatch>, <mailto:dispatch-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 25 Jul 2022 13:15:30 -0000

My sense is that the competitors for this work are, e.g., protocol buffers,
thrift etc.

With that said, I don't think the most important question is technical
details but rather customer demand, What I mean by this is that there are
quite a few pieces of technology in this space, and so we should only take
this on if there is real evidence of some constituency which will adopt the
output of this work (if it happens). Presumably, we can make whatever
technical design choices will result in a good system, but there's no point
in doing that if people don't want to use it.

-Ekr


On Mon, Jul 25, 2022 at 6:09 AM Richard Barnes <rlb@ipv.sx> wrote:

>
>
> On Mon, Jul 25, 2022 at 9:00 AM Richard Barnes <rlb@ipv.sx> wrote:
>
>> On Wed, Jun 8, 2022 at 5:06 PM John Levine <johnl@taugh.com> wrote:
>>
>>> It appears that Jiri Vlasak  <jiri.hubacek@gmail.com> said:
>>> >Dear members of DISPATCH WG,
>>> >
>>> >I would like to ask you to consider discussing Binary Application Record
>>> >Encoding (BARE) I-D [1] during the upcoming DISPATCH meeting at IETF
>>> >114.
>>>
>>> An obvious question is why one would use BARE rather than CBOR which
>>> appears at first glance to do the largely the same thing. See RFCs
>>> 8949, 8152, 8392, 8610, 8742, 8746, and 8812.  If you can join the
>>> session remotely, I expect we can have a useful discussion about this
>>> and related topics.
>>>
>>
>> Probably for similar reasons that TLS and MLS do not use CBOR.  CBOR is
>> much more complex than is called for in a lot of use cases (arguments about
>> spec size aside), in particular because it enables decodability without a
>> schema.
>>
>> I do not view CBOR as a plausible competitor for this work.
>>
>> --Richard
>>
>>
>>
>>>
>>> R's,
>>> John
>>>
>>> _______________________________________________
>>> dispatch mailing list
>>> dispatch@ietf.org
>>> https://www.ietf.org/mailman/listinfo/dispatch
>>>
>> _______________________________________________
> dispatch mailing list
> dispatch@ietf.org
> https://www.ietf.org/mailman/listinfo/dispatch
>