> One large problem with publishing a protocol as "experimental" is > there is not objective way to exit that status. There are no criteria > that say "this experiment succeeded" or "this experiment failed". > > It will take much less IETF effort to fix the charter now than it > will to move the already-deployed protocol to standards track. We > might as well bit the bureaucratic bullet now and just fix the > charter. If most folks agree, I can do that work.
This draft seems fine as an experiment, but as standard, maybe there are some operational considerations that need to be addressed. The first is that at the moment some people are serving different content on port 853, from what they are serving on port 53. I can't quickly find anything in this draft on how to reach those people or how to deal with that. Current users of port 853 are not implementing this draft. So it may take then considerable time to sort out this issue. If this draft becomes a standard, 'almost overnight' traffic seen by authoritative servers may switch from almost exclusively UDP to port 53, to TLS or QUIC to port 853. It seems that the draft is rather weak in looking at the operational impact that could have. We also don't know much on how this affects recursive resolvers. The draft says in Section 4.6.10: "a recursive resolver following this guidance may also choose not to initiate new connections for encrypted transport". It is not great to have security related standards where the implementor may or may not implement the feature that is discussed. Maybe we should first experiment, and then create an updated document that becomes a standard. _______________________________________________ dns-privacy mailing list dns-privacy@ietf.org https://www.ietf.org/mailman/listinfo/dns-privacy
