agreed. while my buddies and I push rocks around, Ed can make sure the “sleeping[*]” is not wakened. :)
* http://www.stuff.co.nz/world/asia/10099510/Dead-guru-just-sleeping-in-a-freezer manning bmann...@karoshi.com PO Box 12317 Marina del Rey, CA 90295 310.322.8102 On 6July2015Monday, at 7:49, joel jaeggli <joe...@bogus.com> wrote: > 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 >> > > > _______________________________________________ > 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
