> From: Robert Elz [mailto:kre@xxxxxxxxxxxxx] > 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. _______________________________________________ Ietf@xxxxxxxx https://www1.ietf.org/mailman/listinfo/ietf