From: Robert Elz [mailto:kre(_at_)munnari(_dot_)OZ(_dot_)AU]
However, if this ...
| It is somewhat unfortunate that the choices draft does
not take a more
| realistic approach to deployment constraints. This has
been raised on
| numerous occasions but the fact is that the best
information we have
| available is the information presented during the MARID
working group
| which indicated that at the time only 50% of the deployed DNS
| infrastructure does in fact support new RRs in a production mode
| (i.e. you can add the RR using the standard admin tool and the
| configuration will survive a reboot).
is an example of the quality of argument that is swaying the
consensus of the group, then the IESG (and IETF as a whole)
should be taking a very very close look at what is being
produced, and most probably, simply abandoning the WG in question.
In my book deployability trumps pretty much everything else. Deployability is
what I want from a standards process in the first place.
Deployability is not the only criteria of course. It is also a good idea if the
proposal will fill its intended function and it is certainly a good idea to
avoid deploying something we might regret later.
But I make no appologies for insisting that deployment in the real world is one
of the most important considerations that a Working Group must consider. We
have had enough of projects that remain unused after a decade or more because
insufficient thought was put into deployment.
Deployment is a much harder problem than meeting the technical goals.
In this case we have two approaches that are equally effective in meeting the
functional goals. One has considerably better deployability. Therefore it is an
entirely justifiable engineering decision.
Whether it is possible to add a new RR type to an existing
DNS server (without upgrading it) - whether due to design
limitations, or bugs, is 100% irrelevant to the question of
which is the best way to add data to the DNS.
The limitations in the DNS servers is due to the need for deployment of new RRs
being insufficiently considered in the original DNS design.
Product cycles in our industry are long.
If someone wants to add a new RR type to their DNS server,
and their server cannot handle it, then they can simply
replace/upgrade their server.
You can't do that if it is integrated into your O/S.
It is not the case that the whole world runs on BIND or wants to.
This is no different than anyone else who wants new
functionality in a system that doesn't support the new stuff,
and nothing at all remarkable.
The same is true at the other end - if the system that wants
to perform a lookup of a DNS RR type cannot, because either
its resolver, or local DNS cache (or API, or anything else)
doesn't support the new RR type, then they need to upgrade
whatever is imposing the restriction to something newer, that
can handle the new lookup.
You have just aritrarily locked into a double ended deployment trap. Neither
side can have value until the other completes deployment.
If this were not true, then you may as well abandon DKIM now
- after all, my mailer, and most other site's mailers (I'd
hazard a guess, way more than 50% of the deployed mailers)
don't support DKIM, and, by the argument above, that's enough
to render the technique unrealistic.
We have carefully considered the depolyment issue there. If you don't support
DKIM you get no benefit from it. But equally importantly you do not suffer a
penalty which is unfortunately the case for the MIME based security encodings.
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html