Re: [rfc-i] [Rswg] draft-mcquistin-augmented-ascii-diagrams

Carsten Bormann <cabo@tzi.org> Fri, 27 October 2023 16:42 UTC

Return-Path: <cabo@tzi.org>
X-Original-To: rfc-interest@ietfa.amsl.com
Delivered-To: rfc-interest@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4A709C15108C; Fri, 27 Oct 2023 09:42:57 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.206
X-Spam-Level:
X-Spam-Status: No, score=-4.206 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-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
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 IiwJ0y225wHh; Fri, 27 Oct 2023 09:42:52 -0700 (PDT)
Received: from smtp.zfn.uni-bremen.de (smtp.zfn.uni-bremen.de [134.102.50.21]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 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 B09AFC15108B; Fri, 27 Oct 2023 09:42:49 -0700 (PDT)
Received: from eduroam-pool10-182.wlan.uni-bremen.de (eduroam-pool10-182.wlan.uni-bremen.de [134.102.90.181]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.zfn.uni-bremen.de (Postfix) with ESMTPSA id 4SH7kb442szDCcl; Fri, 27 Oct 2023 18:42:47 +0200 (CEST)
Content-Type: text/plain; charset="utf-8"
Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.7\))
From: Carsten Bormann <cabo@tzi.org>
In-Reply-To: <d8576d5a-04a9-4d96-bdb8-7608e81746a5@petit-huguenin.org>
Date: Fri, 27 Oct 2023 18:42:47 +0200
Cc: Kyle Rose <krose@krose.org>, RFC Interest <rfc-interest@rfc-editor.org>, RSWG <rswg@rfc-editor.org>, "Independent Submissions Editor (Eliot Lear)" <rfc-ise@rfc-editor.org>
X-Mao-Original-Outgoing-Id: 720117767.1080019-db06da6b613732ed2d2d3633059d91b4
Content-Transfer-Encoding: quoted-printable
Message-Id: <6A8121B3-8457-4621-8B6B-B9D5BD5F7CA1@tzi.org>
References: <05dff7e7-9744-4ce8-9cc2-98699f7a0c7b@rfc-editor.org> <14700.1698412872@localhost> <CAJU8_nVJvAzjxtPNQpBSdGgDdEsEk_8DjABnGUff+fdL8Crs_A@mail.gmail.com> <23B3F709-8EEE-405C-9101-0228DBB4A969@tzi.org> <d52d730c-664d-420c-804e-ea344ac1c89d@petit-huguenin.org> <49DEB942-283B-4ECA-8CE2-ABE1929F9B3D@tzi.org> <d8576d5a-04a9-4d96-bdb8-7608e81746a5@petit-huguenin.org>
To: Marc Petit-Huguenin <marc@petit-huguenin.org>
X-Mailer: Apple Mail (2.3608.120.23.2.7)
Archived-At: <https://mailarchive.ietf.org/arch/msg/rfc-interest/pEHF5SM6WzPVzPQ30TGKlsn3rak>
Subject: Re: [rfc-i] [Rswg] draft-mcquistin-augmented-ascii-diagrams
X-BeenThere: rfc-interest@rfc-editor.org
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: "A list for discussion of the RFC series and RFC Editor functions." <rfc-interest.rfc-editor.org>
List-Unsubscribe: <https://mailman.rfc-editor.org/mailman/options/rfc-interest>, <mailto:rfc-interest-request@rfc-editor.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/rfc-interest/>
List-Post: <mailto:rfc-interest@rfc-editor.org>
List-Help: <mailto:rfc-interest-request@rfc-editor.org?subject=help>
List-Subscribe: <https://mailman.rfc-editor.org/mailman/listinfo/rfc-interest>, <mailto:rfc-interest-request@rfc-editor.org?subject=subscribe>
X-List-Received-Date: Fri, 27 Oct 2023 16:42:57 -0000


> On 2023-10-27, at 18:32, Marc Petit-Huguenin <marc@petit-huguenin.org> wrote:
> 
> On 10/27/23 09:09, Carsten Bormann wrote:
>> 
>> 
>>> On 2023-10-27, at 17:19, Marc Petit-Huguenin <marc@petit-huguenin.org> wrote:
>>> 
>>> Signed PGP part
>>> On 10/27/23 07:52, Carsten Bormann wrote:
>>>> On 2023-10-27, at 16:35, Kyle Rose <krose@krose.org> wrote:
>>>>> 
>>>>> Agree with Michael that this should be in the IETF stream if possible. Seems very cool.
>>>> 
>>>> It actually should be in the IRTF stream, under UFMRG.
>>>> 
>>> 
>>> I was preparing an email in support for draft-mcquistin-augmented-ascii-diagrams when I saw that comment.  What I was going to say in that email was that we do not have an RG or WG to work on formal languages, although we do have an RG for formal methods.  
>> 
>> A formal description technique (“formal language”) *is* a formal method.
>> At least https://www.irtf.org/ufmrg.html uses “formal method” in this way.
> 
> No, and the charter even says that "...the use of formal methods may require the use of unfamiliar protocol description languages...", clearly separating the two concepts.

It is not separating the concepts, but the people being impacted.
For the verification people to do their work, they have to extract a formal description from the specification.  One way to do this is to have the people making the specification use formal description techniques, which may be unfamiliar to them, and cause pushback.  That is all this sentence is about.

> Let's go back to definitions.  [1] says that a formal language is "[a] language with explicit and precise rules for its syntax and semantics."  

(Your term.
I’m more interested in the narrower concept of formal description techniques, which might indeed employ formal languages.)

> On the other hand [2] says that '"Formal Methods" refers to mathematically rigorous techniques and tools for the specification, design and verification of software and hardware systems.' 

… "for the specification, design"…  exactly, that is what a formal description technique is about.

> Formal languages are not formal methods.  

Your term.

> It's like saying that XML is a programming language.  

Non sequitur.

I’m not sure that the rswg is interested in these finer points about formal specification of protocols.

Grüße, Carsten