On Thu, Mar 29, 2018 at 3:18 PM, Suzanne Woolf <suzworldw...@gmail.com> wrote:
> > Should we refuse to document such things because they’re not in well-known > open source codebases, or have otherwise not passed tests of goodness? > > It’s not a rhetorical question. Given that people are extending the > protocol outside of the IETF or any other formal process, in order to solve > their own technical and business problems, it makes sense to ask ourselves > periodically whether we should be encouraging them, trying to stop them, or > something in between. > There are in fact precedents for doing something of the sort. But not ones that I think we should follow. DNSSEC would have been implemented as part of the VeriSign ATLAS roll out. The reason it was not was it simply could not be deployed using the tech available with the spec as it was at the time without a major increase in cost and complexity. A blanket requirement for open source implementations may well have the same effect. Operating systems at Internet scale is vastly more complex than running systems at network scale. It is not just the genius of the original Internet designers that has allowed the Internet to scale from 100 nodes to 10 billion. There is a vast amount of unseen engineering work that is equally heroic and some of that infrastructure comes with some very specific constraints. Some of the most useful work in IETF is making closed systems more open. Often those projects require some extra slots to carry information that is needed for some legacy system. I see no value to saying folk can't have a smooth transition path from proprietary to open.
_______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
