Re: [fdt] Proposed charter text & meeting

Carsten Bormann <cabo@tzi.org> Fri, 28 August 2020 14:19 UTC

Return-Path: <cabo@tzi.org>
X-Original-To: fdt@ietfa.amsl.com
Delivered-To: fdt@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 635903A0C0D for <fdt@ietfa.amsl.com>; Fri, 28 Aug 2020 07:19:11 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.897
X-Spam-Level:
X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2x45LF6s59UP for <fdt@ietfa.amsl.com>; Fri, 28 Aug 2020 07:19:07 -0700 (PDT)
Received: from gabriel-vm-2.zfn.uni-bremen.de (gabriel-vm-2.zfn.uni-bremen.de [134.102.50.17]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A7E693A0C06 for <fdt@ietf.org>; Fri, 28 Aug 2020 07:19:07 -0700 (PDT)
Received: from client-0102.vpn.uni-bremen.de (client-0102.vpn.uni-bremen.de [134.102.107.102]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by gabriel-vm-2.zfn.uni-bremen.de (Postfix) with ESMTPSA id 4BdMCt01rVzyVx; Fri, 28 Aug 2020 16:19:05 +0200 (CEST)
Content-Type: text/plain; charset="utf-8"
Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.1\))
From: Carsten Bormann <cabo@tzi.org>
In-Reply-To: <B8882E15-4E47-4921-AED5-F2A1F4B36C11@smcquistin.uk>
Date: Fri, 28 Aug 2020 16:19:05 +0200
Cc: fdt@ietf.org
X-Mao-Original-Outgoing-Id: 620317145.482936-073b2c8f127d9f75764e5b2b6bb0cdc0
Content-Transfer-Encoding: quoted-printable
Message-Id: <BD60952D-51BB-4D45-898E-A8D58B83F71C@tzi.org>
References: <16D9B498-78F0-41AB-BAFC-77250C084A33@smcquistin.uk> <EA48528D-F798-4ED1-9BA1-39603E3C804E@smcquistin.uk> <B8882E15-4E47-4921-AED5-F2A1F4B36C11@smcquistin.uk>
To: Stephen McQuistin <sm@smcquistin.uk>
X-Mailer: Apple Mail (2.3608.120.23.2.1)
Archived-At: <https://mailarchive.ietf.org/arch/msg/fdt/XEwAxUi_HP2WRKNBBZiCXxCY5nA>
Subject: Re: [fdt] Proposed charter text & meeting
X-BeenThere: fdt@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Mailing list for the discussion of the use of formal description techniques in IETF documents <fdt.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/fdt>, <mailto:fdt-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/fdt/>
List-Post: <mailto:fdt@ietf.org>
List-Help: <mailto:fdt-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/fdt>, <mailto:fdt-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 28 Aug 2020 14:19:12 -0000

On 2020-08-28, at 15:37, Stephen McQuistin <sm@smcquistin.uk> wrote:
> 
> The meeting is to discuss the next steps for proposing an FDT group, and specifically, this draft charter text:
> 	https://hackmd.io/@fdt/S1wTyI-fv

I expect we will be live-editing that at the meeting?
I made one minor change, but I wasn’t sure how to mark this as my proposed change (I used italics and a [cabo] mark).
If you like that change, maybe you can “accept” it.

Not that it is necessary to do that now, but moving to codimd.ietf.org would have the advantage that you can see who added some text.
(Properly integrating codimd with git or github is still an unsolved problem AFAIK.)

Re agenda: I think we could keep the side meeting focused on the administrative part, and (assuming we can pull it off) schedule an actual PRG meeting soon for the actual technical presentations and discussions.

We could also discuss setting up a (possibly wiki-like) structure where we could collect pointers to relevant work and maybe get some taxonomy work started so we have a way to group those pointers into meaningful clusters.

(One think I’d like to understand in the long run is how we will build entire specifications that make use of one or more FDT techniques, in the sense of literate programming — literate specification :-)  Making the specification techniques directly applicable to this like Augmented Packet Header Diagrams is certainly one way, but it also would be good to have a standard way to author specs with in-line ABNF or CDDL and have both readable text and processable specification at the end.  Add references between specifications in various stages of evolution to this if you think that alone is too easy.)

Grüße, Carsten