Specifications are moving through IETF faster than ever. Rarely is the question asked, is this actually a good thing.
The specific reason for raising this topic is a complaint on the DNSops list about large public resolvers failing to support DPRIV. But that is not the only example of what I see as an anti-pattern for standards development.
1) A group identifies a security need
2) Asserting that the need is urgent and the very most important thing is speed, a draft is cobbled together that meets the functional requirements the group has identified.
3) Deployment stakeholders point out the practical problems they would face implementing the draft in the current form.
4) The objections are brushed aside because of the urgent need for speed.
5) A couple of years later the draft is published as an RFC
6) A couple of years later, it is noticed than none of the essential stakeholders have deployed.
7) Attacks on the stakeholders' lack of interest in security, gaslighting of the individuals who raised the blocking deployment issues.
8) Further attempts to address the issue are blocked because 'what needs to happen' is deployment of 'the standard'
9) Those people who point out that this behavior is problematic are cast out from the tribe.
This isn't just one isolated incident. It is now a firmly established pattern. I have seen it happen on three separate projects in the DNS area alone. First with DNSSEC, then with DANE and now with DPRIV. And there are real costs.
DNSSEC was deployed in .com for almost a decade late because of the refusal to fix the NXT record issue. As a result, we lost a critical window where deployment would have been a lot easier than it became.
DANE conflates publication of security policy with public key validation and distribution.
And now we have DPRIV which is built with no regard for the architectural constraints of running the large public DNS resolvers whose adoption is essential for success.
Every time I point out that the same group of individuals are engaging in the same behavior that caused their last proposal to fail, I am accused of trying to re-fight old battles and what we all need to do is to ram this next RFC through the process as fast as we possibly can because this time we really need to do it fast.
What concerns me here is not so much the waste of time but the fact that as long as there is a purported standard meeting some need, its existence and failure to achieve adopted blocks attempts to solve the problem in ways that could be acceptable to the deployment stakeholders.
So what I propose is a mechanism to formalize the raising of deployment objections. The basic idea being that is a group decides to behave this way and the IESG decides to let them, the fact that their proposed solution fails to meet what key stakeholders assert are show stopper deployment issues is noted. If the WG then produces a specification that fails to achieve deployment, the existence of the objections can then be taken into account when considering chartering a new group.