Re: BoF session in Prague "Formal State Machines"

Hannes Tschofenig <> Wed, 07 February 2007 20:46 UTC

Received: from [] ( by with esmtp (Exim 4.43) id 1HEtgd-0008Jh-Ro; Wed, 07 Feb 2007 15:46:39 -0500
Received: from [] ( by with esmtp (Exim 4.43) id 1HEtgc-0008Jb-Qy for; Wed, 07 Feb 2007 15:46:38 -0500
Received: from ([]) by with smtp (Exim 4.43) id 1HEtgb-00031E-Bv for; Wed, 07 Feb 2007 15:46:38 -0500
Received: (qmail invoked by alias); 07 Feb 2007 20:46:33 -0000
X-Provags-ID: V01U2FsdGVkX1+YJgBLXL2Ypna1NCBuArAvFvp6OPXXGz4WNuS2XD H8Jw==
Message-ID: <>
Date: Wed, 07 Feb 2007 21:46:32 +0100
From: Hannes Tschofenig <>
User-Agent: Thunderbird 2.0b2 (Windows/20070116)
MIME-Version: 1.0
To: Stephane Bortzmeyer <>
References: <> <> <>
In-Reply-To: <>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Y-GMX-Trusted: 0
X-Spam-Score: 0.0 (/)
X-Scan-Signature: f60d0f7806b0c40781eee6b9cd0b2135
Subject: Re: BoF session in Prague "Formal State Machines"
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: DIscussion on state machine specification in IETF protocols <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>

Hi Stephane,

I used formal languages for the verification of security protocols. I 
gave a presentation about the AVISPA project at IETF#59  (see

I also applied them to some more recent protocols as well, including HIP and
(see Appendix E).

There are many nice things out there. The question is only: For whom is 
it helpful and how does it help them?

The above-mentioned formal method tool for verifying security protocols 
might help the protocol designers and people from a formal method 
community when reading IETF documents. The latter group is pretty small 
in size and regarding the former one I noticed that it only helps to the 
extend that they represent the protocol in a different way and could 
therefore discover some inconsistency in their document. The formal 
verification part is for most protocols useless since real problems are 
not discovered.

Here is my conclusion: it looks nice on paper but the tradeoff (effort 
to write compared to the value one gets) lead people to not use it.

So, coming back to the formal state machine language.

Have tried to apply your favorite language to a more complex, real-world 
Have you been noticing real problems in the way how existing protocol 
specifications are written?
Why do you expect people to use it?
Have you spoken with implementers/protocol designers to determine 
whether you solve one of their problems?
Why do you think that the benefit is bigger than the effort?

In any case, I think that it is a useful thing to talk about this stuff 
and to give some guidance. It depends on how far you would like to go. 
If the idea is to give some guidance on how state machines could be 
described in IETF documents then that would be fine. If every working 
group suddenly has to write state machine documents using the developed 
language then some folks could get a bit nervous.


PS: My students have used  the following tools in past projects: the 
state machine compiler, available at, and for 
graphical representation they used

Stephane Bortzmeyer wrote:
 > On Tue, Feb 06, 2007 at 10:09:09AM +0100,
 >  Hannes Tschofenig <> wrote
 >  a message of 53 lines which said:
 >> Why should I re-write my documents to comply to a more formal state
 >> machine description?
 > Figures (wether in ASCII-art, in Unicode-art, in SVG, in GIF or
 > whatever) and informal tables are impossible to analyze automatically
 > (for instance to check if they are deterministic, or to translate them
 > automatically to software like Ragel). That's the main problem I have
 > with informal descriptions: you cannot process them by software and
 > you have to check them manually.
 > Being parsable by a program is the main aim of the future language.

Cosmogol mailing list