Subject: RE: running code vs. formal testing methods

From: "Bob Wise" <[email-masked]>
Date: Tue, 3 Aug 1999 21:30:39 -0600

Was this blanket statement designed to encourage discussion
on this point?  I hope so...

We have certainly used SDL extensively, and found it so worthwhile that
we are engineer all our protocols with SDL - including the ones that
don't have it defined, as can be the case with IETF protocols.

SS7 and H.323 are both defined SDL extensively, and the reduction in
ambiguity
is extremely helpful.  Reduction in ambiguity leads to improvements
in interoperabilty.

Formal methods of all kinds can be extremely useful.  I have heard similar
comments about techniques in software development, from which I will make
my own blanket statements...

Hackers hate formal methods.  They prefer "code and test" development.
They always claim that the effort isn't worthwhile.  This is shockingly
like "hack and interoperate".  Protocol development is essentially software
development, after all. Engineers use formal methods for maximum effect.
Formal methods are a very useful tool, if (like anything) they are not
slavishly
applied.

The examples in the literature showing the productivity, speed, and quality
benefits of formal methods are too numerous to mention.  Not to mention that
I can prove the benefits in my own development organization.

None of this is to say that interoperability testing is any less desirable.
Real testing is critical, in the same way that formal proofs of correctness
are problematic (how do you know the proof is correct?).

For any protocol which will have an extended lifetime, the benfits of
a formal notation (such as SDL) are well worth the effort.  For protocols
which are experimental or transient, the effort may not be worthwhile.

-Bob Wise
Chief Architect
Vsys

> -----Original Message-----
> From: vinton g. cerf [mailto:[email-masked]]
> Sent: Friday, July 30, 1999 11:57 PM
> To: Reinhard Scholl; [email-masked]'
> Subject: Re: running code vs. formal testing methods
>
>
> SDL's and other formal methods have not yielded results
> commensurate with the effort to use them. They are
> overblown, verbose, hard to use, hard to understand.
> What they might gain in precision they lose in
> comprehensibility.
>
> Plain English specs and multiple implementations
> in <your language of choice> followed by interoperability
> bakeoffs continue to be a powerful means of achieving
> interworking implementations and confidence in the
> specifications.
>
> Vint Cerf
>
>
> >
> =================================================================
> "INTERNET IS FOR EVERYONE!"
> Join the Internet Society and help to make it so.
> See you at INET2000, Yokohama, Japan July 18-21, 2000
> http://www.isoc.org/inet2000
>
>
>

---

From: "Bob Wise" <[email-masked]>
Date: Tue, 3 Aug 1999 21:30:39 -0600

-Bob Wise
Chief Architect
Vsys

---

From: Frank Kastenholz <[email-masked]>
Date: Wed, 04 Aug 1999 08:19:52 -0400

formal methods are tools
nothing more
nothing less

like any tool, sometimes they
can be useful. sometimes they
can be useless, or even harmful.

a screwdriver, even the world's
best most swoopiest screwdriver,
is pretty useless if all you 
have is nails.

---

From: Frank Kastenholz <[email-masked]>
Date: Wed, 04 Aug 1999 08:19:52 -0400

formal methods are tools
nothing more
nothing less