> How about stopping for a bit and challenging the IESG (Internet Engineering Steering Group) and IETF(Internet Engineering Task Force) to actually assess the situation at hand, and decide upon actual improvements, creating proper documentation and generally creating a proper professional environment regarding the technology so that you don’t have to open 40 tabs and read documentation that you may or may not need. Making the information more easily accessible and readable means more people will actually go through it and that means more security.<p>I agree with the author, RFCs are awful to work with. For example, DHCP (because I'm familiar with it). So let's look at the RFC [0], which "Obsoletes: 1541" and is "Updated by: 3396, 4361, 5494, 6842". It turns out, there's about 60 (!) RFCs relevant for DHCP [1], and probably more references in those. What the hell.<p>An example of reference overload and horribleness through backwards compatibility is the second field in a DHCP header, `htype` or hardware type requires you to look at RFC 1700. It has 230 pages, and some of the hardware types are: Ethernet, Experimental Ethernet, Amateur Radio AX.25, Proteon ProNET Token Ring, etc. Almost all but Ethernet are completely useless today.<p>Except, oh shit, RFC 1700 is obsoleted by RFC 3232. Which says everything has been moved into a database, but <i>HAS NO LINK</i> to where you might find that database. Now, in this database there are values which require two bytes, but `htype` is only a byte long! Brilliant.<p>One solution would be to mandate passed RFCs have behavioural tests. In effect, you'd be encoding the standards in a way that computers can understand, and not having the potential error of `human -> computer (txt/html) -> human -> computer (programming)` conversion.<p>---<p>[0] <a href="https://tools.ietf.org/html/rfc2131" rel="nofollow">https://tools.ietf.org/html/rfc2131</a>
[1] <a href="http://www.zytrax.com/books/dhcp/apc/" rel="nofollow">http://www.zytrax.com/books/dhcp/apc/</a>