On Friday, February 24, 2012 12:14:28 PM Andrew Sullivan wrote:
cc:s trimmed. I'm not on the w3c list anyway, and I don't think the
IESG cares about this detail.
On Fri, Feb 24, 2012 at 04:58:36PM +0100, Patrik Fältström wrote:
Because people disagree on whether it is actually hard to get new
RRTYPEs deployed.
I for example do completely disagree on it being hard. Sure, your user
interface in the gui of your favorite $EDITOR might not support the new
RRTYPE, but should that constrain deployment of good standards?
Before those who think DNS weenies never listen to real-world problems
jump in, I want to point out what _I_ understand to be a problem. If
you're a DNS geek, then the natural thing to think is, "This is easy.
You just send a well-crafted UDP packet. How hard could that be?
Once the typecode is assigned, what's the problem with sending an
unknown RR?"
If you're most application programmers, however, the entire conversation
ended at "send a well-crafted UDP packet". Your libraries don't
support injecting well-crafted UDP packets, and you have no idea how
to do that, and it's incredibly stupid, and why would anyone think
that was reasonable anyway?
If you're most sysadmins, the entire conversation ended at "My tools
don't know what TYPE1234 is."
If we seriously think that DNS RRTYPEs ought to be useful extensions
to people, we're going to have to make them _easy_ to deploy, not just
possible. I have no idea how to solve this problem, though.
It's occured to me that it might be useful to pre-allocate some new types
without a current use assigned (e.g. TXT1, TXT2, TXT3) so that there's time
for them to be integrated into tools before they are needed. Of course not
everyone will implement an unused, but allocated type, but it might be enough
to make a worthwhile difference in this problem.
The biggest issue with new type deployment is that for a new protocol to get
deployment it needs the new type assigned. For a new type to get assigned,
there needs to be some indication it will get deployed. So there is often a
work around using existing types, but then once the new protocol is deployed
with the workaround old type there's no incentive to migrate. The only way to
break this cycle is to have something readily available for initial use with
protocol experimentation.
Scott K
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf