My experience has been that implementations help improve the quality of
the specifications, and formal security analyses help fix design
errors. I implemented two recent SEC area protocols, but unfortunately
in both cases, my implementations were partial (due to lack of time,
interest etc.,), and it appears that others' implementations were too
(at least at the time we interoperated). The other thing is that my
counterparts and I were privy to some or all of the behind the scenes
information.
The security analyses I am aware of (thanks to Cathy Meadows :-)) helped
revise what is now RFC 3547 (and Russ H mentioned another example at the
SAAG meeting in Paris).
The conclusion I draw is that a formal security analysis (or even
protocol analysis) is very helpful once the protocol design has been
completed to identify any errors, and implementations (preferably full
implementations) would help improve the readability of specs (and that
would happen if the implementer is basing the implementation only on a
given I-D, and not on the history of it or behind the scenes info).
Perhaps it might be worthwhile to identify "problem areas" in a spec and
try and implement those parts to figure out whether we got them right.
best regards,
Lakshminath
Iljitsch van Beijnum wrote:
On 7-aug-2005, at 1:07, Brian Rosen wrote:
I notice that we have stopped being interested in running code.
I think that is to our community's detriment.
[...]
Probably more importantly, I think we should be VERY suspicious of new,
complex specifications before we have running code.
I've been thinking about this on and off for a day, and I'm not
convinced that having running code at the time a specification is
first fleshed out would be all that helpful.
Can you point to any instance in recent IETF history (after 1995 or
2000 or so) where having having running code early in the process
would have made for a better _designed_ protocol?
Sure, trying to implement something brings out bugs in the
specification, but those are usually relatively minor things that
don't go to the design of the protocol. And wide deployment generally
shows that a protocol could have been better in one regard or
another, and that some parts of it don't turn out to be useful in
practice.
However, waiting for implementations on account of the former only
delays having a fixed spec even longer (we already see protocols
_deployed_ before there is an RFC, which is very harmful IMO) while
waiting for the latter leads to insanity such as RFC 1771 being stuck
at "draft standard" even though it has dozens of interoperable
implementations, a decade of operational experience and there
wouldn't be an internet without it.
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/ietf
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/ietf