On 3/16/15, 11:05, "bert hubert" <bert.hub...@netherlabs.nl> wrote:
>Sorry? We solve implementation hardship by standards action now? My thoughts in this thread (and I'm choosing to keep this in dns-operations) keep circling because I've spent time at different perspectives. On one hand we like to say that the Internet has valued innovation at the edges. Innovation is generally doing something unconventional, or "against the standard." (Yes, it can also mean exploring the unexplored.) When doing something "against the standard" one of the results is shifting more cost on to your neighbors. If one values adherence to standards, innovation is shackled to some extent. I once made this comment inside a company where there had been intense cost reducing efforts. When asked "how should we innovate" my answer was to fatten the budget and then illustrated that if you have a well-tuned machine, any change is going to be burden somewhere else. Sometimes, as you shift the burden around you can raise revenue to offset it and sometimes you can shift the burden to where it "disappears." But during the shifts, innovation and standards often work against each other. When writing the AXFR update/clarification RFC, one of the motivations was to isolate AXFR from being an essential element of a DNS server. There are zones for which generating a roster is not practical, so it's not good, if you will, to expect an AXFR to come form it. Such zones may be those with telephone numbers (ENUM) or even IPv6 reverse mappings. Usually "practical" refers to the speed of updates as opposed to shear size. I can imagine an environment in which constructing a DNSSEC-signed authoritative answer to an ANY query could be a real pain. In environments that tailor responses by query source, you'll find that A and AAAA records are generally from a recipe while the others types are static, in some cases the A and AAAA, or one or the other, don't exist. Sometimes, if the A and AAAA records are null, you want the entire node to own no records, whether or not ir exists for the NSEC/NSEC3 chain. Think this is "stupid DNS tricks?" One might, but, this is something that gets people to buy DNS hosting services. When I studied wildcards for that update/clarifications RFC, it was correctly pointed out to me (by DJB) that standard ways of doing something need not be the only ways to accomplish something. For wildcards, the standards-defined method is compatible with AXFR. Other means of synthesizing an answer just wouldn't be - but if one could extend AXFR, you could expand answer synthesis. Or maybe this is all just stupid DNS tricks and we shouldn't bother. But, I do agree with the handwaving argument to date is insufficient and a bit weak. It is right to challenge the proposal as it stands (as I have done too). While I an inclined to agree to deprecate qtype=ANY as well as other elements of the protocol I am also inclined to demand a better rationale before accepting a document's proposal. But yes, I do think standards actions in response to local problems can at times be the right thing to do, if we value innovation. I'll note that Paul Vixie has talked about cost shifting in the past. Saying one is "innovating" isn't license to shift costs without good reason or warning or acceptance or ... innovation doesn't remove the need to say "I'm sorry." ;)
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations dns-jobs mailing list https://lists.dns-oarc.net/mailman/listinfo/dns-jobs
