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