On 10/20/22 15:05, Brian Dickson wrote:
I fear those challenges mean that GNS simply won't be possible to properly have
registry entries, and without GNS, or possibly using GNS as an alternative
namespace example, the registry makes no sense.
Here's the problem that the GNS draft includes (and maybe doesn't highlight well enough): GNS is
not a namespace. There is no central administration of namespace(s) under GNS, or even a central
anything. GNS has no global "anything", and no concept of global per se. At best,
entities can publish their own equivalent of "root zone"s that assert to a population of
consumers as to what namespace entities exist, without any authority over any aspect of namespaces.
It is anarchy embodied.
[...]
There is also no ability to enforce any rules on using any parent label, or to prevent
conflicting intra-GNS "petnames",
[...]
GNS allows anyone (with local context) to instantiate any namespace (tree
anchored anywhere), including instantiating new TLDs (contrary to ICANN's
current role as exclusive entity responsible for administering the DNS
namespace at the TLD level) and instantiating conflicting TLDs, SLDs, 3LDs, or
anything beneath those.
DNS allows all the same things, you can just set up a local root or local co.uk
or whatever split-horizon scenario you want.
The conventional root zone is the authority because it has been accepted as
such, not because the DNS contains a mechanism for it that GNS lacks.
The question that hasn't been addressed is, who SHOULD actually do
registrations in this proposed registry?
I don't believe the authors of the GNS draft have the actual authority to do
so, as they do not administer any name space per se.
If someone did want to instantiate a local namespace, or a kind-of, sort-of
bigger-than-local namespace (with delegations) as the GNS draft generally
describes, would they be the entities registering their namespace?
[...]
There could easily be 1000 different instances of "lotr.gns.alt" within GNS, each with its own zone(s) with
names like "frodo", "bilbo", "gandalf" etc.
Of course (and again, same with DNS). But having a carve-out suffix would open
up the possibility of telling people who are creating namespaces to do so in a
way that doesn't collide with the DNS namespace as it is used so far. (It's a
possibility; it may get ignored, but there's no harm to it either.)
That carve-out is entirely independent of any mechanisms that record
potentially conflicting names under it. To agree on what the carve-out is, we
don't need to decide whether such record keeping could be done via a IANA
registry, or an ICANN GNS department, or something entirely different, or not
at all.
I thus reiterate [0] that there are two separate things at hand, namely (1) the
carve-out, (2) conflict mitigation below the carve-out.
The second problem can be solved *after* the first, and also doesn't really
concern the DNSOP WG, as long as the solution to the first provides a means to
point non-DNS implementors to some recipe that helps avoid collisions with DNS.
That's the .alt TLD (or _* wildcard TLDs or whatever).
I think we should focus on the first problem exclusively.
In terms of specification, I think that would be pretty straightforward: To get
started, we could basically pass a document that says
If you're going to use names that look like domains names for a
non-DNS purpose, please append the "alt" label to whatever
you're using. DNS stub and recursive resolvers, stop
resolution when you see this.
... and add whatever extra text that is necessary for RFC-ization reasons.
(When settling on some other carve-out, the approach would be similar. For
example, for _* underscore TLDs:
If you're going to use a top-level name for a non-DNS purpose,
please prepend an underscore to whatever you're using. DNS
stub and recursive resolvers, stop resolution when you see this.)
Right now, we need consensus on the carve-out (if any). After that, let's
decide if DNSOP cares about the registry, and settle that.
Best,
Peter
--
https://desec.io/
_______________________________________________
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
