On Mar 28, 2018, at 11:19 AM, Mukund Sivaraman <m...@isc.org> wrote:
> On Wed, Mar 28, 2018 at 10:55:13AM -0400, tjw ietf wrote: >> I would say that most things we have adopted in the past few years do have >> some implementations to reference. >> Not when drafts are adopted, but generally before we head to WGLC I've >> always wanted to see someone >> who implemented the option in some manner. >> >> But yes, agree. > > I'd raise the bar even higher, to see complete implementation in a major > open source DNS implementation when it applies. Sometimes implementation > problems are very revealing (client-subnet should have gone through > this). This is actually quite a good example of another problem: Client-subnet was documented for Informational purposes; it was already in wide use in the public internet and had an EDNS opt code codepoint allocated from the IANA registry. Nothing that happened in DNSOP or the IETF changed that, and I strongly suspect nothing that happened in DNSOP or the IETF could have changed it. Other documents we’ve considered on features or modifications to the protocol include refuse-any and, I believe, serve-stale, and the stated purpose of the localhost draft is to clarify the existing documentation on the reserved name “localhost”. 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. Suzanne _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
