[DNSOP] on engineering cost/benefits

[Paul Vixie <[e-mail]>]

I realize that for the Perl language, "there is always more than one way 
to do it". That was a design choice, and the results are now part of 
Perl's reputation as a "swiss-army chainsaw" perfectly suitable for the 
creation of unmaintainable programs.

Generally, we do not provide more than one way to accomplish something, 
because it imposes costs on operators and implementers and especially on 
QA/test teams, who must support all such methods, for competitive or 
coverage reasons. Distributed system complexity is a function of message 
types and their options and permutations and combinations, and state 
variables and their options and permutations and combinations. More 
complexity is almost always going to add more cost than benefit, and 
every argument about adding new states, variables, or messages has to 
begin with the engineering economics: what are the costs & benefits?

For example if it's possible to express the nonexistence of a wildcard 
in two ways, each publisher of DNS information will have to decide 
whether to support only one and if so which one, or both ways. Every 
implementer of a DNS client library or a DNS-aware application will also 
have to choose. If some choose method A and others choose method B than 
the functionality will not be effectively present. If everyone chooses 
to support both then there was no advantage to the second way.

In terms of cost/benefit, someone who wanted to provide a new way to 
support signalling of non-wildcard should be comparing the effort of 
standardizing, implementing and deploying a second way, vs. pushing for 
broader deployment of the existing way. One could either come to the 
IETF, and to the authors of PowerDNS, BIND, NSD, Unbound, and companies 
like Nominum, Microsoft, and so on, asking "could you please support 
this second way to do something your systems already know how to do?", 
or one could approach one's own I.T. department and the I.T. departments 
of our customers, suppliers, and partners, and say, "could you please 
support this existing standard by changing your operational practice to 
include DNSSEC signing and validation?"

In the first case, it's all new work, which adds complexity for all 
operators and all implementers, and may have the effect of reducing 
DNSSEC deployment if some number of operators cared only about this 
feature (which we'll call SWILD) and have no other reason to deploy 
DNSSEC. This concern is heightened because the DNSSEC specification is 
crap, and there's been unending concern as to whether its costs are 
greater than its benefits. DNSSEC rests on knife-edge, ready to fall.

In the second case, it's mostly just turning stuff on that's already 
defined, already implemented, and is an option in virtually all current 
generation DNS software. We would not be adding new test cases for 
QA/test teams. And importantly, we would be adding new effort to the 
task of causing DNSSEC to be more ubiquitous.

This kind of engineering economics tradeoff should be obvious. I 
apologize to anyone who is about to ask me why I appear to be trying to 
teach my grandmother how to chew cheese. Consider this a PSA for 
newcomers for whom shiny objects are an unalloyed good, and aren't seen 
in the context of costs and benefits and effects and side effects.

-- 
P Vixie