From: DNSOP <dnsop-boun...@ietf.org> on behalf of Ted Lemon <mel...@fugue.com> Date: Wednesday, April 6, 2016 at 2:53 PM To: Paul Hoffman <paul.hoff...@vpnc.org> Cc: "dnsop@ietf.org" <dnsop@ietf.org>, Ted Lemon <ted.le...@nominum.com> Subject: Re: [DNSOP] Alternative Special-Use TLD problem statement draft
So to answer a slightly different question than the one you asked, what I am proposing is that the working group adopt the tldr document, likely with changes, rather than adopting the adpkja document, which I think would take much more work to get into shape. The entire reason that I started the tldr document is that I felt that the adpkja document not only didn't accurately describe the problem, but contained much more text describing some authors' beliefs about what the solutions should be than text describing what the problem is. I also felt that the scope of the adpkja document was too narrow--it mostly talks about problems with 6761, without really talking about the greater context of those problems. > Ted, The recent discussions on the wg mailing list have articulated the tussle between, on one side the desire for the IETF to foster innovation in the naming area, and, on the other side, the ability (or not) of the IETF, as an organization, to deal with the socio-economic aspect such as IPR, etc tied to those ³special names². The argument being that there is nothing fundamental that differentiate the strings associated with "special names" from those associated with regular DNS TLDs, and, as such both are potentially subject to those pressures. Reading section 4.2 and 4.3 of draft-tldr-sutld-ps-00, it would appear you are in the camp that does believe those ³special names² are immune those socio-economic pressures and/or the IETF can deal with this. Do I get this right? If that is the case, then, it is not that one document is better than the other, there is a fundamental difference between the perspectives of the authors. It should follow that this is a non technical issue that is much larger than DNSop wg. As such, the DNSop wg might want to refrain from adopting one or the other document until the IETF, as a community, under the leadership of the IAB, comes to an agreement on that fundamental question. After all, the interpretation of RFC2860 (ICANN/IETF MoU) is the prerogative of the IAB. Alain, long time IETF participant, speaking solely as myself.
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
