A somewhat different thought about IETF evolution

[Steve Crocker <[e-mail]>]

I’m glad to see there is discussion about how to improve the IETF.  I note the current emphasis in this discussion is about meetings and collaboration tools.  These are important topics, but I want to focus in this note on technical points.

In my view — and you should take those words as an invitation to critique and disagree — two areas that have not evolved very much over the 47 year history of the RFCs are formal analysis and timing.  Re formal analysis, I mean representing all possible behaviors and tracking down all the corner cases.   The payoff for the community is that implementations that adhere to the protocol specification will have a better chance of interoperating in the field.

A separate but perhaps closely related concern is timing.  So far as I have seen, timing considerations are generally not included in protocol specifications, and they are considered an implementation detail.  However, timing issues bedevil us in an operational environment.  In the DNS environment, we have a myriad of timing parameters — TTLs for each RR, signature validity periods, etc. — and no coherent sense of how to choose these parameters or what the impact of various choices will be.  And I mention DNS only because it’s the particular area I’ve dealt with recently.  For a much more fundamental example, the idea of extending TCP to work throughout the solar system immediately runs afoul of any reasonable arrangements of timeouts and retries, and led to the development of the DTN stack

Improving the formality and analyzability of protocol specifications is not easy, nor is providing more complete information and analysis of timing concerns, but both of these seem to be good and useful goals going forward.

Steve