Re: Why have we gotten away from running code?

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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@xxxxxxxx
https://www1.ietf.org/mailman/listinfo/ietf


_______________________________________________

Ietf@xxxxxxxx
https://www1.ietf.org/mailman/listinfo/ietf

[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Fedora Users]