Hi, On Aug 2, 2022, at 8:00 AM, Geoff Huston <g...@apnic.net> wrote: >> I came to this group because of concerns that Warren raised, and because the >> draft sits before me. I have reviewed what discussion I could find in the >> logs relating to Warren's draft, which amounts to either (a) this is ICANN's >> problem or (b) there is nobody willing to make use of the space. Please >> feel free to inform me if I have missed something. >> >> Regarding (a), that is not my interpretation of RFC 6761. RFC 6761 drops >> special use domains firmly in the lap of the IETF, which is presumably why >> Warren brought his draft here and why I came here and didn't go to ICANN. >> Regarding (b), we have someone here willing to at least have the >> conversation. > > ICANN was not created out of thin air. It was created in part as an admission > by the IETF at the time that the dimensions of the discussions relating to > name spaces, alternate roots, name space expansion and such was far broader > than the IETF at the time and the discussions on this topics necessitated a > host and a community that was not isomorphic to the IETF. > > Regarding your interpretation of RFC6761 and your conclusion, as ISE, that > this is not matter for ICANN, I respectfully disagree with the ISE here, and > I believe that such matters are well beyond the more limited scope and remit > of the IETF and the considerations of some 20 years ago in this space remain > relevant today.
I agree with Geoff. I’ll be a bit more blunt: RFC 6761 was a mistake in a number of different ways that I won’t bother going into here. There is a reason its application has been halted. The idea that it “drops special use domains firmly in the lap of the IETF” presupposes a clear definition of “special use domains” that can be distinguished at a namespace as opposed to a protocol level. Unfortunately, distinguishing at the namespace level is unappealing as it would necessarily impact users (e.g, force them to use a “_”). That leaves partitioning the namespace. However, partitioning the singular domain name space involves non-technical policy considerations which is exactly why ICANN was created. There are many reasons why the ICANN gTLD process is so Byzantine and painful. One of those reasons is because trying to distinguish why one group should get a chunk of the namespace and another shouldn’t is a very hard, almost always non-technical problem. The IETF has not shown a whole lot of interest or skill in dealing with those sorts of problems, something I believe RFC 2860 recognized. To me, the right answer here is as obvious as it is painful: requests for namespace partitioning (i.e., creation of top-level domains) should be punted over to ICANN (regardless of the protocol underlying the implementation of that namespace). If a particular usage of the namespace doesn’t fit the model ICANN has come up with, it’s indicative a brokenness/failure within ICANN, not justification for bypassing the clear intent of RFC 2860. There has been a reluctance/inability on the part of both ICANN and the IETF to deal with this for more than 20 years. Given the proliferation of “alternative roots”, I don’t think this is desirable or even tenable. Regards, -drc
signature.asc
Description: Message signed with OpenPGP
_______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
