3,197
edits
Changes
→Issues
...And in fact, with the advent of DNSSEC, this is what we found. For several years, security and stability bugs in popular nameserver implementations were absolutely dominated by DNSSEC and cryptography-related issues.<ref name="hubert" /></blockquote>
...And in fact, with the advent of DNSSEC, this is what we found. For several years, security and stability bugs in popular nameserver implementations were absolutely dominated by DNSSEC and cryptography-related issues.<ref name="hubert" /></blockquote>
Bush and Hubert both identify one of the key issues as an unwillingness to say "no" to feature requests.<ref name="bush" /><ref name="hubert" />
Bush and Hubert both identify one of the key issues as an unwillingness to say "no" to feature requests.<ref name="bush" /><ref name="hubert" /> Hubert also sees the "resume boosting" aspect of RFC authorship to be a problem:
<blockquote>Authoring an Internet-Draft and getting it published as an RFC is an achievement, a CV-worthy accomplishment. People work hard on it. In fact, within many employers, getting such documents issued is actually an agreed performance target. “Well done”.
So the growth in DNS standards text is far from an accident – it is baked into our constellation of active standardizers, willing implementors, and lack of operational guidance to hold us back.<ref name="hubert2">[https://www.ietf.org/blog/herding-dns-camel/ IETF Blog - Herding the DNS Camel], November 21, 2018</ref></blockquote>
In a subsequent blog post for IETF, Hubert provided an updated list of proposed next steps to help unburden the camel:
*Stop writing new RFCs
*Modernize or rewrite existing RFCs
*Obsolete old protocols or standards
*Make DNS operation more accessible<ref name="hubert2" />
==References==
==References==
{{reflist}}
{{reflist}}
__NOTOC__
__NOTOC__