> On 03/Mar/12 00:13, John R. Levine wrote: > > > >> Until provisoning systems accept UNKNOWN record types they will > >> always be a bottle neck. Without that you will have to wait for > >> the change request to be processed. Given the history just getting > >> AAAA records added to most of these system it will be forever. > > > > AAAA was unusually painful, since it requires adding a parser for IPv6 > > addresses. (Having hacked it into my provisioning system, I speak > > from experience.) Most new RR types are just strings, numbers, names, > > and the occasional bit field. > Yeah, and if ISPs already had troubles with ho-de-ho-de-ho-de-ho, how > will they join in on skee-bop-de-google-eet-skee-bop-de-goat? > Given that, designers of new RR types will want to stick to string > formats just to spare ISPs some parsing, at the cost of losing a half > of the advantages that RFC 5507 talks about, along with syntactic > validations aimed at preventing some permerror/permfail cases. Doubtful. If a record needs to have, say, a priority field, or a port number, given the existence of MX, SRV, and various other RRs it's going to be very difficult for the designers of said field to argue that that should be done as ASCII text that has to be parsed out to use. More generally, this is trying to have things both ways. We can't simultaneously assert that deploying simple new RRs is a breeze, making this unnnecessary, and that it's so difficult that everything should be crammed into TXT Format no matter the actual structure is. NNed _______________________________________________ Ietf mailing list Ietf@xxxxxxxx https://www.ietf.org/mailman/listinfo/ietf