ietf
[Top] [All Lists]

More haste, less speed.

2017-03-06 10:27:41
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.
<Prev in Thread] Current Thread [Next in Thread>