Re: [Ufmrg] [EXT] Re: A few questions about UFMRG goals

Muhammad Usama Sardar <muhammad_usama.sardar@tu-dresden.de> Fri, 08 September 2023 07:46 UTC

Return-Path: <muhammad_usama.sardar@tu-dresden.de>
X-Original-To: ufmrg@ietfa.amsl.com
Delivered-To: ufmrg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B71B3C15198B for <ufmrg@ietfa.amsl.com>; Fri, 8 Sep 2023 00:46:15 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.106
X-Spam-Level:
X-Spam-Status: No, score=-7.106 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, 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=tu-dresden.de
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 ynL2XD0pGmAZ for <ufmrg@ietfa.amsl.com>; Fri, 8 Sep 2023 00:46:11 -0700 (PDT)
Received: from mailout4.zih.tu-dresden.de (mailout4.zih.tu-dresden.de [141.30.67.75]) (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 2D45CC151985 for <ufmrg@ietfa.amsl.com>; Fri, 8 Sep 2023 00:46:08 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=tu-dresden.de; s=dkim2022; h=MIME-Version:Content-Type:In-Reply-To: References:Message-ID:Date:Subject:CC:To:From:Sender:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=j+gWtJC11TwcnaT0vwdSPo2ofbnvCZJqyzY6C7reM6o=; b=kXp+cTnNtpso8Vn9sIA9MHCefh nCV6Nk8NsqeIxXrQHJeU/cRAhTRniVIN5giDusOP0B5w15OKMH9VrxfFTs1TF7lMdLqjkLbFYl1BJ ylmGSwumbdnEGmhfHgK0Y1xdFjQ/yCBdb9lcRIgIqcK5xXePp47IVWKYxxfhB2+lgTB+FLQoqu49y uQGnqIAhldJb4zal589ntT64JCbkrTyRtzfy8B+GWhP28uhVXjYTp2VGuTjUcHc3HnKgsQiVit60F UvYvTPXWAboLKwojdaM0wMd5yRoDY3gWbExGV0Zp76j6Mk1M38P7ViX0wAiOEdxfh5ovKPFt7zHAr 8EFA9Oig==;
Received: from [172.26.35.115] (helo=msx.tu-dresden.de) by mailout4.zih.tu-dresden.de with esmtps (TLS1.2) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from <muhammad_usama.sardar@tu-dresden.de>) id 1qeWBo-009ZSh-8R; Fri, 08 Sep 2023 09:46:04 +0200
Received: from MSX-T314.msx.ad.zih.tu-dresden.de (172.26.35.114) by MSX-T315.msx.ad.zih.tu-dresden.de (172.26.35.115) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.1.2507.31; Fri, 8 Sep 2023 09:45:48 +0200
Received: from MSX-T314.msx.ad.zih.tu-dresden.de ([172.26.35.114]) by MSX-T314.msx.ad.zih.tu-dresden.de ([172.26.35.114]) with mapi id 15.01.2507.031; Fri, 8 Sep 2023 09:45:48 +0200
From: Muhammad Usama Sardar <muhammad_usama.sardar@tu-dresden.de>
To: Jonathan Hoyland <jonathan.hoyland@gmail.com>, Joshua D Guttman <guttman@mitre.org>
CC: Stephen Farrell <stephen.farrell@cs.tcd.ie>, "ufmrg@ietfa.amsl.com" <ufmrg@ietfa.amsl.com>
Thread-Topic: [Ufmrg] [EXT] Re: A few questions about UFMRG goals
Thread-Index: AQHZ4dqhEFW0Z4Qq1UyRisBKY36NYbAQgYlY
Date: Fri, 08 Sep 2023 07:45:48 +0000
Message-ID: <0c6cc15b2a32476dacf13bb0b2083320@tu-dresden.de>
References: <PH0PR09MB76899049A294230B248B1428B9E4A@PH0PR09MB7689.namprd09.prod.outlook.com> <9b35faa9-923a-4258-28a4-7577635101df@cs.tcd.ie> <PH0PR09MB7689628541D0ABDCF1FFD05BB9EEA@PH0PR09MB7689.namprd09.prod.outlook.com>, <CACykbs1AUJ2LmDtFxkLkrrZfMnU89AxMXyd4gt5EVneEyPsSRA@mail.gmail.com>
In-Reply-To: <CACykbs1AUJ2LmDtFxkLkrrZfMnU89AxMXyd4gt5EVneEyPsSRA@mail.gmail.com>
Accept-Language: de-DE, en-US
Content-Language: de-DE
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-pmwin-version: 4.0.4, Antivirus-Engine: 3.87.0, Antivirus-Data: 6.03
Content-Type: multipart/alternative; boundary="_000_0c6cc15b2a32476dacf13bb0b2083320tudresdende_"
MIME-Version: 1.0
X-TUD-Virus-Scanned: mailout4.zih.tu-dresden.de
Archived-At: <https://mailarchive.ietf.org/arch/msg/ufmrg/__eU2W_3YGKuZW_iATRB_NCP0BA>
Subject: Re: [Ufmrg] [EXT] Re: A few questions about UFMRG goals
X-BeenThere: ufmrg@irtf.org
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: Usable Formal Methods Research Group <ufmrg.irtf.org>
List-Unsubscribe: <https://www.irtf.org/mailman/options/ufmrg>, <mailto:ufmrg-request@irtf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ufmrg/>
List-Post: <mailto:ufmrg@irtf.org>
List-Help: <mailto:ufmrg-request@irtf.org?subject=help>
List-Subscribe: <https://www.irtf.org/mailman/listinfo/ufmrg>, <mailto:ufmrg-request@irtf.org?subject=subscribe>
X-List-Received-Date: Fri, 08 Sep 2023 07:46:15 -0000

Hi Joshua,

Thanks for your questions. I think they are very good points. Until this thread, I was under the impression of 1(b) as well.


If the main goal is 1(c), then improving the manuals of tools should be an equally (if not more) important activity. Let's face it: we all know how poorly most (if not all) of these manuals are documented.


> One piece of feedback I get when I ask people why they don't use formal methods is that there is no intermediate level training available.

I don't think this was explicitly clarified before to the volunteers. Some questions in my mind are:

  *   Are the trainers now aware that they are supposed to give intermediate level training and not repeat what they have already presented elsewhere?
  *   Is it still feasible for them to create this intermediate level training within the next 2 months?
  *   Are you certain that you will get enough people in the audience interested in intermediate level training (i.e., well-aware of the basics of the tools)?


Thanks,

Usama


------------------------------------------------------------------------------------------------------------------------------------------
Best Regards,

Muhammad Usama Sardar (M.Sc.)

Research Associate

Technische Universität Dresden


Faculty of Computer Science

Institute of Systems Architecture

Chair of Systems Engineering


Office: APB 3073

Phone: +49 351 463-42048

Email: muhammad_usama.sardar@tu-dresden.de

Website: https://tu-dresden.de/ing/informatik/sya/se/die-professur/beschaeftigte/muhammad-usama-sardar

------------------------------------------------------------------------------------------------------------------------------------------


________________________________
Von: Ufmrg <ufmrg-bounces@irtf.org> im Auftrag von Jonathan Hoyland <jonathan.hoyland@gmail.com>
Gesendet: Freitag, 8. September 2023 00:27
An: Joshua D Guttman
Cc: Stephen Farrell; ufmrg@ietfa.amsl.com
Betreff: Re: [Ufmrg] [EXT] Re: A few questions about UFMRG goals

Hi Joshua,

One piece of feedback I get when I ask people why they don't use formal methods is that there is no intermediate level training available.

There is documentation for some tools, and sometimes YouTube tutorials for the basics, but unless you work with the tool authors, or people experienced in modelling, there isn't somewhere to learn all the tips and tricks necessary to prove complex things. So people get through a very basic tutorial, and then go look at papers that include huge, complex models, and have no idea how to get between those two places.

The goal of the training is to hopefully build up a set of recorded pieces of training that help people use the tools as they are. By running multiple trainings the hope is to provide a pathway, along with a place you can go and ask questions of experts.

Certainly one of my hopes for this group is that we can provide actionable feedback to tool authors so that they can improve their tools, but starting with the things we can achieve without going outside the group seems like the best way to get started.

Another thing I think we can do fairly immediately is provide guidance on which tools might be most appropriate for which tasks, and thus help work out what work needs to be done to prove the properties we want.

So overall I agree with Stephen's 1c, and mostly 2c. I think the training (along with making the materials available) does make the tool more useable, even though I agree a proper usability study would be even better. I do think there are a number of easy usability improvements to be had in many tools before we need to go for a usability study, so I don't think we're completely unable to proceed on that front.

We are definitely looking for people who have a background in things like user studies to help us make both the training and the group overall a success, so if you have suggestions (or even suggestions of people we can ask) they would be very gratefully received.

Regards,

Jonathan

On Thu, 7 Sept 2023, 23:04 Joshua D Guttman, <guttman@mitre.org<mailto:guttman@mitre.org>> wrote:
I was really impressed by the fast three minute
response, just before the interim mtg a week ago.

But I'm not sure that the reply really gets to the
heart of the matter.

You write:

>    1(c) is fine

in response to:

>>    1.  I'm a little unsure whether the primary
>>    goal is:
>>
>>          (a) To determine whether formal
>>          methods are effectively usable for
>>          IETF-type purposes;
>>
>>          (b) To persuade people that formal
>>          methods are effectively usable for
>>          IETF-type purposes; or
>>
>>          (c) To cause formal methods to become
>>          more effectively usable for IETF-type
>>          purposes.
>>
>>          Of course, a possible response is to
>>          give a blend of more or less of these
>>          three components.  And maybe
>>          additional components?  But what would
>>          be the right characterization?

What makes this a bit askew is the fact that the
most visible activities -- such as the planned
tutorials at the Nov 4 Prague meeting -- really
seem to me closer to 1(b).

I guess the tutorial goal is primarily education.
Since formal methods are in fact very useful, one
expects education to be key to "persuading people
that formal methods are effectively usable for
IETF-type purposes."  ( :- )

And I suspect that persuading and educating may be
a more achievable goal for the UFMRG than actually
causing formal methods to become more effectively
usable.

That requires instead a lot of research, both with
a high level of insight into formal modeling and
proving, and with a bunch of user studies and
appraising the kinds of people who could benefit
from specific kinds of FM.

Would the 4 Nov tutorials even give us any insight
into the latter?

It's conceivable but might require some
coordination and restructuring.

More on question (2) in a separate msg.  I'd be
eager to know what people think about these
aspects of question (1).

        Joshua

On 9/1/23, 12:01, "Stephen Farrell" <stephen.farrell@cs.tcd.ie<mailto:stephen.farrell@cs.tcd.ie>> wrote:

1(c) is fine, 2(c) is closest but not quite right

On 01/09/2023 16:58, Joshua D Guttman wrote:
> May I ask a few questions about the UFMRG goals?
>
> 1.  I'm a little unsure whether the primary goal
>      is:
>
>      (a) To determine whether formal methods are
>          effectively usable for IETF-type purposes;
>
>      (b) To persuade people that formal methods are
>          effectively usable for IETF-type purposes;
>          or
>
>      (c) To cause formal methods to become more
>          effectively usable for IETF-type purposes.
>
>      Of course, a possible response is to give a
>      blend of more or less of these three
>      components.  And maybe additional components?
>      But what would be the right characterization?
>
> 2.  Along another axis, we sometimes have
>      different formal methods that may be useful
>      for different sets of goals (eg establishing
>      that a program respects an inductive invariant
>      vs establishing that a protocol achieves an
>      authentication goal), and maybe also competing
>      formal methods that approach the same goals in
>      different (or similar :- ) ways.
>
>      Do we aim to:
>
>      (a) Identify some methods as suitable for some
>          kinds of goals?
>
>      (b) Grade the usability of some "competing"
>          methods for overlapping goals?
>
>      (c) Identify combinations of methods for
>          purposes that require several kinds of
>          results?
>
>      Again, blends may make sense together.
>
> Thanks!
>
>    Joshua
>
>

--
Ufmrg mailing list
Ufmrg@irtf.org<mailto:Ufmrg@irtf.org>
https://www.irtf.org/mailman/listinfo/ufmrg