On 29.3.2018 22:59, Phillip Hallam-Baker wrote: > On Thu, Mar 29, 2018 at 3:18 PM, Suzanne Woolf <suzworldw...@gmail.com > <mailto: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.
I do not see a problem. First there needs to be running code and RFC will follow. It IMHO does not make much sense the other way around, and we will suffer for next decade because we did not follow this rule in the past. -- Petr Špaček @ CZ.NIC _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
