Re: [DNSOP] [EXT] Re: draft-schanzen-gns and draft-ietf-dns-alt-tld

[Christian Huitema <[e-mail]>]

On 8/4/2022 1:52 PM, Independent Submissions Editor (Eliot Lear) wrote:
> Dave,
>
> To answer the question, “What is the ISE process?”:
>
> On 04.08.22 21:28, David Conrad wrote:
>> Martin,
>> [...]
>
>> I see 4 options:
>>
>> 1) Wait for ICANN to fix their processes
>> 2) Wait for the IETF to figure out whether/how to reopen the “Special 
>> Use Domains” registry
>> 3) Try to bypass (1) and/or (2) by publishing through the ISE (I 
>> don’t know enough about the ISE process to guess whether this is 
>> appropriate or feasible)
>
> For information about independent submissions, please see 
> https://rfc-editor.org/about/independent and RFC 4846 (among others).

As Eliot gently hints at, the purpose of the ISE is not to bypass 
established processes, or indeed force a code point allocation against 
established processes.

I think that experimenting with "pet names", as proposed in 
draft-schanzen-gns, is a perfectly fine idea. The concept of per names 
has been proposed for a long time, see discussions about Zooko's 
triangle, etc. It is a tradeoff: doing away with registration implies 
either ugly names (hashes of keys) or names that resolve differently in 
different contexts (pet names). Many here posit that the tradeoff is too 
ugly to be useful, but that should not preclude Martin & al from trying 
that experiment.

(I also think that we should avoid comments like "you should be damned" 
in a technical debate.)

Of course, anyone who does an experiment like that will want to somehow 
reuse existing software and existing clients. They will want to open 
something like "http://<my-fancy-new-name>/index.html". They will want 
to stick their fancy new names at places where existing API or 
interfaces expect a fully qualified domain name. Which means they will 
need a simple way to differentiate the new names from actual domain 
names. And for that, the simplest way is to pick a final name part that 
is reserved for the project. That was indeed what RFC 6761 was allowing.

But we have an issue, because for all practical matters the IETF wants 
to obsolete RFC 6761. The IETF wants that for good reasons, based on 
past experience with allocating TLD outside of ICANN. Indeed, part of 
that experience is surfacing in the the use of "example.pet" in 
draft-schanzen-gns. It turns out that ICANN has already allocated the 
TLD ".PET" (see https://data.iana.org/TLD/tlds-alpha-by-domain.txt), so 
using that outside of the DNS would not be good.

Arm-twisting the IETF to revive RFC 6761 is probably not going to work, 
so I could think of only three alternatives:

1) Have the GNS project directly ask ICANN to register their preferred 
name string. That would get the desired UI, but probably require money 
and time, for a somewhat uncertain result.
2) Register something like "gnu.arpa" or "pet.arpa". RFC 3172 requires 
that the IETF endorses new registrations in some kind of standard, which 
is a higher bar than an ISE registration. But it probably could be arranged.
3) Squat under ".test". This breaks a couple of "should not" in RFC 
6761, but is in line with the general philosophy that "Users are free to 
use these test names as they would any other domain names" and "there is 
no central authority responsible for use of test names".

-- Christian Huitema