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

[Colin Perkins <[e-mail]>]

The same rules apply for this as for any other side meeting at IETF: https://wiki.ietf.org/meeting/115/sidemeetings

Assuming the room has the right equipment, I’m hoping to set things up to allow remote participation, most likely via Zoom.

Colin



On 5 Nov 2022, at 7:57, Toerless Eckert wrote:

> Given how this is a side meeting, i don't think that formal
> IETF meeting attendance requirements apply. But maybe they do,
> by virtue of an IETF official (Colin) calling for the meeting.
>
> Rooms at least are set up to enable remote participation in side
> meetings (video camera et. al.). Just "Bring Your Own Webex/Zoom" for
> the organizer. Not sure if Colin was planning to allow remote
> participation.
>
> Then again: are you sleepless at 3 AM in the morning ? ;-))
>
> Cheers
>     Toerless
>
> On Sat, Nov 05, 2022 at 05:18:49PM +1000, Ross Finlayson wrote:
>> I won’t be in London for IETF 115, and so won’t be able to attend the side meeting.  But I got to see the interesting presentations at the Applied Networking Research Workshop at IETF 114.
>>
>> A couple of the talks there took the approach of using natural language processing to try to generate a formal protocol description from the text of an (English-language) RFC.  While this is a noble goal, it seems to be hindered by both the inherent ambiguities in English, and the imperfections in natural language processing.
>>
>> Instead, it seems clear that, ideally, an RFC that describes a protocol should contain a protocol description, written in a formal language.  The problem with this, though, is that a formal language description, by itself, is not sufficiently understandable by humans.  Some sort of English-language ‘documentation’ should also be present.
>>
>> One of the workshop speakers suggested automatically generating documentation from a formal protocol specification.  At this point, I was reminded of an idea that Don Knuth came up with in the 1980s: “Literate Programming”:
>> 	https://en.wikipedia.org/wiki/Literate_programming
>>
>> The idea behind Literate Programming is that the primary document that the (human) programmer writes is not a program (source code), but instead *structured documentation* that describes the program.  This document contains both English prose, and code snippets (or macros).  From this document, you can automatically generate both the program’s source code, and documentation for the program.
>>
>> So perhaps the ideas behind Literate Programming could be applied to protocol specification - i.e., “Literate Protocol Specifications”?  (Of course, this is just a germ of an idea - which would need a lot more fleshing out (by others :-)
>>
>>
>> Ross Finlayson
>> Live Networks, Inc.
>> http://www.live555.com/
>
> -- 
> ---
> [e-mail]