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@xxxxxxxx https://www.ietf.org/mailman/listinfo/ietf