Re: adapting IETF in light of github and similar tools

Phillip Hallam-Baker <> Tue, 20 April 2021 05:26 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 920FB3A0DD5 for <>; Mon, 19 Apr 2021 22:26:00 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.4
X-Spam-Status: No, score=-1.4 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FORGED_FROMDOMAIN=0.249, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.249, HTML_MESSAGE=0.001, 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 ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id uBcWBPGkXIzN for <>; Mon, 19 Apr 2021 22:25:56 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 17B963A0DD2 for <>; Mon, 19 Apr 2021 22:25:55 -0700 (PDT)
Received: by with SMTP id g38so41554476ybi.12 for <>; Mon, 19 Apr 2021 22:25:55 -0700 (PDT)
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:to:cc; bh=472GI1BlcaWftmO6fjaA8KrVv1A+nCMbIru7+1uQVcU=; b=dNH5gkz21VsgVtqBDFk+ryIf1r1NUXWWtBmnDQpxYfRJWHnmOqJEA3RxYC0hO4lHvp GoS0kHxB1PJ4R/d/rL2oE105DX8ShY2EV8I5/fgowHTBEJQl17o+E0pt+6FUjCVXWxGU Roh8D45hfJ0rgm4aGRyBKDp6PpgTSH3QDXcx+G3Hvd7zKrfUDl47OuBhmQ4z1HPCD038 AwfHe1AcclHwmgasah1qky2VXMlRcWlXI3ym3nUx734FBvJQJM/tlvfjoKO5G0Y8YGzv IKFH+xNhyFtVA8dKK+mVRW7vA7nNMVxqya3GWeiAqLRaM2iRGMdXaG4U0YmEVhGSI9vr Dbow==
X-Gm-Message-State: AOAM533smkQCwhlFIEPCQQVFyJQZqi39xd3MB3W7uE8W53FMGGFTzWNL kUx0PIm9rhAL2GAa89z/VSpbsb3StKh1YTtBrf4=
X-Google-Smtp-Source: ABdhPJyBFdhGa01hfEary1QS0xsMIWnf1IcKNbJBGgnT2vIoaDm2E3e2Dylo9OfB09iE1QmsBietOrqlhWgBiDnz2FM=
X-Received: by 2002:a5b:585:: with SMTP id l5mr20959524ybp.213.1618896354462; Mon, 19 Apr 2021 22:25:54 -0700 (PDT)
MIME-Version: 1.0
References: <> <> <> <> <>
In-Reply-To: <>
From: Phillip Hallam-Baker <>
Date: Tue, 20 Apr 2021 01:25:42 -0400
Message-ID: <>
Subject: Re: adapting IETF in light of github and similar tools
To: Brian E Carpenter <>
Cc: Keith Moore <>, Richard Shockey <>, Leif Johansson <>, IETF Discussion Mailing List <>
Content-Type: multipart/alternative; boundary="00000000000022cdbb05c060aef9"
Archived-At: <>
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: IETF-Discussion <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 20 Apr 2021 05:26:01 -0000

On Mon, Apr 19, 2021 at 10:59 PM Brian E Carpenter <> wrote:

> On 20-Apr-21 10:22, Keith Moore wrote:
> > Could we make greater use of protocol specification
> > languages to reduce the difference between specification and running
> code?
> In theory we could, but it's far from easy. Take CBOR-based protocols for
> a start. Yes, you can use CDDL for a formal specification of the message
> formats, and you can in theory verify that the messages conform; you could
> presumably write a CDDL-driven message parser. But none of that models
> the protocol's state machine. That would be a whole new level of formalism.
> People are trying, however:

I use formal-ized tools for much of my work. But I haven't written a proof
since I finished my doctorate. The problem I found is the aspects of the
system that can be reasoned about tend to not be the parts that are
important for reliability of the system. I prefer to spend the time
simplifying the system and removing what is unnecessary than limiting
myself to what can be proved.

There turns out to be a particular hazard with proofs of crypto protocols
as protocols with a proof of correctness tend to be brittle as the
constraints of proof hacking prevent the defense in depth type approaches
needed today.

I almost always write a tool to parse and serialize even apparently simple
messages because experience tells me that is necessary. I don't find the
same is true for protocol state machines even though I have dozens of
domain specific languages for state machines as well.

This morning, I modelled the state machine of RUD using CSP. But it doesn't
really help very much because the important issues are packets being lost,
packets arriving out of order and timing. Sure, there are timed versions of
CSP but how do I get from CSP to the Tasks model of C# or anything in