Subject: [fdt] Proposed charter text & meeting

From: Stephen McQuistin <[email-masked]>
Date: Mon, 17 Aug 2020 09:00:25 +0100

Hi all,

One of the main outcomes of the Formal Languages side meeting that we held in
May was that we would proceed to consider what an FDT research group might look
like. Having solicited ideas on this, I've produced draft charter text:

    https://hackmd.io/@fdt/S1wTyI-fv <https://hackmd.io/@fdt/S1wTyI-fv>

I'd encourage everyone to have a look, and to comment/edit as they see fit.

So that we can discuss this text, and the next steps, we also plan to hold a
further meeting in mid-September. I've created a Doodle poll to arrange a
meeting in the week beginning 7th September:

    https://doodle.com/poll/82cdci26x5gktd3u <https://doodle.com/poll/82cdci26x5gktd3u>

The meeting will be held via Webex. I'll confirm the selected date by the end of
next week.

Thanks,

Stephen

---

From: Stephen McQuistin <[email-masked]>
Date: Mon, 24 Aug 2020 08:43:25 +0100

Hi all,

A reminder about this Doodle poll, to schedule a meeting to discuss the next steps for proposing an FDT research group:
	https://doodle.com/poll/82cdci26x5gktd3u <https://doodle.com/poll/82cdci26x5gktd3u>

I'll close the poll towards the end of the week, and confirm the selected date then.

Thanks,

Stephen

> On 17 Aug 2020, at 09:00, Stephen McQuistin <[email-masked]> wrote:
> 
> Hi all,
> 
> -- 
> FDT mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/fdt

---

From: Stephen McQuistin <[email-masked]>
Date: Fri, 28 Aug 2020 14:37:28 +0100

This formal languages meeting has now been scheduled for Thursday 10th September at 17:00 (UK time: UTC+1). I’ll send a Webex link nearer the time.

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 <https://hackmd.io/@fdt/S1wTyI-fv>

If there are any other items for discussion, please let me know.

Thanks,

Stephen

> On 24 Aug 2020, at 08:43, Stephen McQuistin <[email-masked]> wrote:
> 
> Hi all,
> 
>> On 17 Aug 2020, at 09:00, Stephen McQuistin <[email-masked] <mailto:[email-masked]>> wrote:
>> 
>> Hi all,
>> 
>> [email-masked] <mailto:[email-masked]>

---

From: Carsten Bormann <[email-masked]>
Date: Fri, 28 Aug 2020 16:19:05 +0200

On 2020-08-28, at 15:37, Stephen McQuistin <[email-masked]> wrote:
> 	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

---

From: Marc Petit-Huguenin <[email-masked]>
Date: Fri, 28 Aug 2020 08:08:27 -0700

On 8/28/20 7:19 AM, Carsten Bormann wrote:
> (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 :-)  

Technically I-Ds are already literate but codeless, so that's why I call the result of adding code to a specification computerate specification.

I am planning a major release of my draft (the number of pages doubled) and the matching tooling on that subject around September 7.

> 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
> 

-- 
Marc Petit-Huguenin
Email: [email-masked]
Blog: https://marc.petit-huguenin.org
Profile: https://www.linkedin.com/in/petithug

---

From: Stephen McQuistin <[email-masked]>
Date: Fri, 28 Aug 2020 16:46:22 +0100

Hi,

> On 28 Aug 2020, at 15:19, Carsten Bormann <[email-masked]> wrote:
> 

Yes — I think that’s a good plan.

> If you like that change, maybe you can “accept” it.

Done.

> (Properly integrating codimd with git or github is still an unsolved problem AFAIK.)

I wasn’t aware of codimd.ietf.org <http://codimd.ietf.org/>, but I’ll take a look, and perhaps migrate before the meeting.

> 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 an…

This makes sense: if we can agree the broad objectives/goals and organisation in this meeting, it would be easier to then schedule a meeting that fits around that.

> 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…

Also a good idea: not sure where this could be hosted, but grouping this together would be good.

> (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 specificati…

Perhaps an xml2rfc element for processable specifications, that would be processed by the tooling to produce the text? Many problems follow from that of course..

Stephen