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

Eric Rescorla <ekr@rtfm.com> Mon, 09 October 2023 12:35 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 58ECDC14CE47 for <dispatch@ietfa.amsl.com>; Mon, 9 Oct 2023 05:35:19 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.906
X-Spam-Level:
X-Spam-Status: No, score=-6.906 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, T_SCC_BODY_TEXT_LINE=-0.01] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.20230601.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 HvOKp_grqS7y for <dispatch@ietfa.amsl.com>; Mon, 9 Oct 2023 05:35:17 -0700 (PDT)
Received: from mail-yb1-xb2e.google.com (mail-yb1-xb2e.google.com [IPv6:2607:f8b0:4864:20::b2e]) (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 24CF4C14CE42 for <dispatch@ietf.org>; Mon, 9 Oct 2023 05:35:17 -0700 (PDT)
Received: by mail-yb1-xb2e.google.com with SMTP id 3f1490d57ef6-d9a398f411fso205080276.3 for <dispatch@ietf.org>; Mon, 09 Oct 2023 05:35:17 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20230601.gappssmtp.com; s=20230601; t=1696854916; x=1697459716; darn=ietf.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=WS2sMToqBb0ao3DapAfhXOA3pEoTXtfGkWjXRwyIp5M=; b=e8C53lrQ+x7g5sNlTUvpefSF7sbUS71BI1GQTzrRTQzShV3Dc9p6llkfXjIIyqQF6H J1y2I9Lowh6k1YFCN2PiwMFd94bY5+XEiNsObD1Azgn+/vJJilV/yD3xQuYRPtvaMssg Z1FCpAeRUf8OZDOggfoIwf1vp9K/Rr5XfOCxycPqcthuysbXMvyGlTFAB7YboQSZ5nLw /SLpCpECkSTzpvE+/WpviwRQvTyWkFiWAUecyeMXCIlmCBMWBSoKZVfk/U3T0Rg1HlRx 6bydZVlVP9YQqBuvjYL+wkj1lZVLgtfFV4Gri6uGImcljnfmqOu0jPd1ntPEnL9Br53G X55w==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1696854916; x=1697459716; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=WS2sMToqBb0ao3DapAfhXOA3pEoTXtfGkWjXRwyIp5M=; b=SWNoWoivJshQyKO6IBtTthaK1UoB8n9GFmOVzXQ6LP/TN2qiZqMx+MRx7qC4iZv+HC 6URyBkjNamkg9Qw3M/jhRd/7HL05n0VbaJSDcn4PPWvg6gcRTJ6Jnln0Pp+D8THtqIK1 Ra2ltfHDYEMSMmMRDhwEHAY/AoXZkEn81z1W1N/06EThD2UW5xrggK6Lnr1RUy+Hw+TS seHCcT3Je8zVbutENjzTuNCRuddkCL+nrwrAoJRX8lbIziQIbwPksHiD2ULwLjmIGFpk +aFiVEGZEuPUu6QzzPasGIrYG6Cz+RvBvUTzkAdKbK9R63B0Zg/WExFM1IH7d2iE+Hnn OPIQ==
X-Gm-Message-State: AOJu0YwYB9Zz3gxqh/1aZoGRAOPwGpeBfX6Ags4dPSCIMLGx5ZqNpSYz lqEP/vZfg62NI+YzF79q7h3nOSHYdrh4MFgzd3BwhA==
X-Google-Smtp-Source: AGHT+IGBJQ2gXKSx/wDtSJOA/IkAYBuKhFw40moDyc7HPaaaiKiXsy26raOWOQzLBEGwqB2UsyuLZJZIAis8H+CAjCQ=
X-Received: by 2002:a25:d152:0:b0:d81:a0c5:f274 with SMTP id i79-20020a25d152000000b00d81a0c5f274mr14938545ybg.48.1696854916186; Mon, 09 Oct 2023 05:35:16 -0700 (PDT)
MIME-Version: 1.0
References: <CABcZeBPerX6iObHKExL3VuHCCkT_FrV3nbmOu8WUQT23-Psxdg@mail.gmail.com> <87bkdmuo0m.fsf@hobgoblin.ariadne.com> <CAPUJBFKz98Byrhnr2Gec-FCyTszz5T6jD5n9LZgsK90KmmqFPg@mail.gmail.com>
In-Reply-To: <CAPUJBFKz98Byrhnr2Gec-FCyTszz5T6jD5n9LZgsK90KmmqFPg@mail.gmail.com>
From: Eric Rescorla <ekr@rtfm.com>
Date: Mon, 09 Oct 2023 05:34:39 -0700
Message-ID: <CABcZeBNe4RJ=LexD7U0vqCC31M3qTJ79tqYYbqLPVJukr-c7kg@mail.gmail.com>
To: Jiri Vlasak <jiri.hubacek@gmail.com>
Cc: "Dale R. Worley" <worley@ariadne.com>, victorien.elvinger@inria.fr, dispatch@ietf.org, sir@cmpwn.com
Content-Type: multipart/alternative; boundary="00000000000083da40060747d28a"
Archived-At: <https://mailarchive.ietf.org/arch/msg/dispatch/0KwElh3rzFHwgR1zUk9fTAymQ88>
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, 09 Oct 2023 12:35:19 -0000

On Mon, Oct 9, 2023 at 5:24 AM Jiri Vlasak <jiri.hubacek@gmail.com> wrote:

> On Thu, Sep 28, 2023 at 02:54:33PM -0400, Dale R. Worley wrote:
> > I'm late to this party, but two things strike me immediately:
> >
> > Eric Rescorla <ekr@rtfm.com> writes:
> > > 1. The convention in IETF is to have things in "network" (big-endian)
> order.
> >
> > Yes; we've settled on consistently using big-endian order.  Is there a
> > reason for the IETF to bless an encoding scheme that is little-endian?
>
> BARE use-cases section includes "A structured data format for storing
> data in persistent storage" [1] (along more examples that invove network
> communication). The little endian is chosen because it is widely used in
> processor architectures.
>
> Is that a sufficient reason? If there is no chance that a protocol based
> on the little endian would be published in Standards Track, please, let
> me know.
>

I think you would need a very compelling reason, and "widely used in
processor architecture" isn't likely to do it. Note that gQUIC was
little-endian
and had significant existing deployment, but when the IETF standardized
QUIC, it made it big-endian.


> > Section 1 starts, "The purpose of the BARE message encoding, like
> > hundreds of others, is to encode application messages."  This is very
> > true.  But the I-D doesn't address why this encoding is decidedly better
> > than existing alternatives.  Presumably there's a case to be made for
> > it, but the case isn't made in the I-D.
>
> In general, it is better because of the BARE's goals:
>
> - Concise messages
> - A well-defined message schema
> - Broad compatibility with programming environments
> - Simplicity of implementation
>
> and how these goals are met.
>

To be honest, these all seem fairly subjective.

>From my perspective, the main question here is industry interest. There
are already a multiplicity of serialization formats, some of them with
very wide use. The IETF should not standardize yet another one
without strong evidence of interest. So far, I haven't heard any IETF
WG say they want to use BARE, nor have I heard any meaningful
demand from outside IETF. Absent that, I don't think we should
standardize it.

-Ekr