On 7/6/15 7:25 AM, manning wrote: > 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).
I would hope that offers to tear the temple down would come with a proposal for the erection of a new edifice, albiet maybe not here. > Or we can continue to put bandaids over the DNS festering wounds. This is dnsop, addressing the condition of current patient, rather than euthanizing it, is the remit. We do the later somewhere else. > 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 >
signature.asc
Description: OpenPGP digital signature
_______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
