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
_______________________________________________
DNSOP mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dnsop
