I still need to catch up on the full weekends activity, but I’d like to suggest that, like the v4/v6 transition, it may be time to consider revisiting the DNS protocols. Not that there would ever be a DNS EMP, wiping our all legacy code, but perhaps a phased migration to DNSv2 and a shim to ensure backwards compatibility. In such a case, it might be reasonable to “fix” ordering (among many other things).
Or we can continue to put bandaids over the DNS festering wounds. manning bmann...@karoshi.com PO Box 12317 Marina del Rey, CA 90295 310.322.8102 On 6July2015Monday, at 6:59, Edward Lewis <edward.le...@icann.org> wrote: > (Having quickly scanned through the thread to catch up.) > > CLASS has been problematic since the start. The first "mistake" made was > encoding the CLASS field after the OWNER NAME field in a resource record. > This meant that all domain names have to be encoded and treated the same > regardless of class, removing an important functionality that would have > encouraged better development of CLASS concepts. > > Had the CLASS field come before OWNER NAME, I believe that its history > would be different. I.e., it would have been used and not ignored. Much > as message compression, there was a time when it was proposed and used, > then it went through an era where it was assumed/forgotten before once > again becoming an issue during the latter phases of DNSSEC development. > The result of that historical path was two sets of intertwined RFC > revisions differing on the topic before finally being discovered, if I > recall correctly, when the unknown types RFC (3597, see section 4) was > developed. What I mean to say here is that over the decades, the > collection of volunteers that made up DNS WG, DNSSEC WG, DNSIND WG, DNSEXT > WG, and this one haven't consistently applied the same frame of reference > to the protocol. > > Unless we wiped all DNS code from existence, I don't see how we could ever > engineer a path to a "Clarifications of the CLASS" in the DNS protocol. > Unlike other loosely defined items in STD 13, CLASS was so poorly formed I > can't see saving it past current use. > > I wasn't aware of the mentioned (in the thread) effort to use a different > CLASS for IDN, but the idea had come to me (as in 'across my desk' from > someone else) a long time ago too. It wasn't apparent that it could even > work given the ordering of the fields in the resource record. > _______________________________________________ > DNSOP mailing list > DNSOP@ietf.org > https://www.ietf.org/mailman/listinfo/dnsop _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
