Re: [irtf-discuss] Usable formal methods side meeting at IETF 115

Sampo Syreeni <decoy@iki.fi> Mon, 07 November 2022 21:06 UTC

Return-Path: <decoy@iki.fi>
X-Original-To: irtf-discuss@ietfa.amsl.com
Delivered-To: irtf-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8481FC15256C; Mon, 7 Nov 2022 13:06:57 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.129
X-Spam-Level:
X-Spam-Status: No, score=-6.129 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_NEUTRAL=0.779, T_SCC_BODY_TEXT_LINE=-0.01] autolearn=ham autolearn_force=no
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 uGqEFoEnkSUB; Mon, 7 Nov 2022 13:06:53 -0800 (PST)
Received: from mail.kapsi.fi (mail.kapsi.fi [IPv6:2001:67c:1be8::25]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange ECDHE (P-256) server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CC54CC1524C1; Mon, 7 Nov 2022 13:06:49 -0800 (PST)
Received: from kapsi.fi ([2001:67c:1be8::11] helo=lakka.kapsi.fi) by mail.kapsi.fi with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from <decoy@iki.fi>) id 1os9KO-00CqHB-BW; Mon, 07 Nov 2022 23:06:44 +0200
Received: from decoy (helo=localhost) by lakka.kapsi.fi with local-esmtp (Exim 4.94.2) (envelope-from <decoy@iki.fi>) id 1os9KO-006PDj-0t; Mon, 07 Nov 2022 23:06:44 +0200
Date: Mon, 07 Nov 2022 23:06:44 +0200
From: Sampo Syreeni <decoy@iki.fi>
To: Buday Gergely <buday.gergely.istvan=40uni-mate.hu@dmarc.ietf.org>
cc: Colin Perkins <csp@csperkins.org>, irtf-discuss@irtf.org, 115attendees@ietf.org
In-Reply-To: <281e560d-0b89-53a5-de75-bfe68004917c@uni-mate.hu>
Message-ID: <f03ea379-b15f-81b-76fa-f893a57f527@lakka.kapsi.fi>
References: <C91D3863-37D3-4E09-B1F9-588C316240CD@csperkins.org> <281e560d-0b89-53a5-de75-bfe68004917c@uni-mate.hu>
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"; format="flowed"
X-Rspam-Score: -3.1 (---)
X-Rspam-Report: Action: no action Symbol: ARC_NA(0.00) Symbol: R_SPF_NEUTRAL(0.00) Symbol: FROM_HAS_DN(0.00) Symbol: TO_DN_SOME(0.00) Symbol: RCPT_COUNT_THREE(0.00) Symbol: MIME_GOOD(-0.10) Symbol: TO_MATCH_ENVRCPT_ALL(0.00) Symbol: DMARC_NA(0.00) Symbol: RCVD_TLS_LAST(0.00) Symbol: NEURAL_HAM(-0.00) Symbol: FROM_EQ_ENVFROM(0.00) Symbol: R_DKIM_NA(0.00) Symbol: MIME_TRACE(0.00) Symbol: ASN(0.00) Symbol: RCVD_COUNT_TWO(0.00) Symbol: BAYES_HAM(-3.00) Message-ID: f03ea379-b15f-81b-76fa-f893a57f527@lakka.kapsi.fi
X-SA-Exim-Connect-IP: 2001:67c:1be8::11
X-SA-Exim-Mail-From: decoy@iki.fi
X-SA-Exim-Scanned: No (on mail.kapsi.fi); SAEximRunCond expanded to false
Archived-At: <https://mailarchive.ietf.org/arch/msg/irtf-discuss/RBAp7YV3CK96iZJJfRYhM98Yn2k>
Subject: Re: [irtf-discuss] Usable formal methods side meeting at IETF 115
X-BeenThere: irtf-discuss@irtf.org
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: IRTF general and new-work discussion list <irtf-discuss.irtf.org>
List-Unsubscribe: <https://www.irtf.org/mailman/options/irtf-discuss>, <mailto:irtf-discuss-request@irtf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/irtf-discuss/>
List-Post: <mailto:irtf-discuss@irtf.org>
List-Help: <mailto:irtf-discuss-request@irtf.org?subject=help>
List-Subscribe: <https://www.irtf.org/mailman/listinfo/irtf-discuss>, <mailto:irtf-discuss-request@irtf.org?subject=subscribe>
X-List-Received-Date: Mon, 07 Nov 2022 21:06:57 -0000

On 2022-11-06, Buday Gergely wrote:

> Formal methods is a broad term, what did people actually suggest?

I'd argue the first thing to do would be to find out which form of 
temporal logic covers every extant IETF protocol. How to marry that then 
with a formal language able to carry all of the data formats used. Once 
you have those, you have a framework at least capable of describing what 
we already have.

What you have might not be ideal for formal methods use. It might 
surface reasoning with all of that would not be efficient. Or your 
framework might not align with any current reasoning software. But 
still, it would constitute a formal defition, at least amenable to 
*some* formal work. Which is more than what we have now.

> Model checking has a long track record of verifying protocols, 
> especially the Spin model checker by Gerald Holzmann.

So, maybe its input language/formalism? [...]

> I think English should augment formal specifications as it could 
> ignite debate whether the formalisation is correct and unambigous.

Here I'd go more with the literal programming idea, and coloring your 
statements with comments. Because if you really formalized your protocol 
fully, so that the formal description really is whole and binding, there 
is no need for debate. It just is or isn't valid.

As such English (why not other languages) simply serve to explain to a 
human, what the intended semantics of the protocol and its data formats 
are meant to be.
-- 
Sampo Syreeni, aka decoy - decoy@iki.fi, http://decoy.iki.fi/front
+358-40-3751464, 025E D175 ABE5 027C 9494 EEB0 E090 8BA9 0509 85C2