On Thu, Oct 20, 2022 at 1:16 AM Eliot Lear <l...@lear.ch> wrote:
> Hi,
>
> First, I would like us to continue to consult on the registry matter at
> least through the London IETF, and would ask the chairs for some time in
> London for this purpose. I would also be available for side meetings
> with any interested party, before or during the IETF. If people would
> like, we can grab a room for this purpose, if we can do so in the
> morning so that Martin can participate remotely (he is far to the east
> of London).
>
> As a matter of practicality, a registry surely will be form. It is
> simply a matter of whether the IANA will host it. If the IANA does not
> host it, then by shifting it elsewhere this group is actually weakening
> the IANA function, and that would be sad.
>
I spent quite a bit of time in the last couple of days reading all the
threaded posts, as well as the two relevant drafts: the alt-tld one, and
the gns one.
The latter (quite a large document, with lots of important nuances
including additions related to dotALT conceptually) has some major
challenges for whether/how it would even fit in such a registry.
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.
Everything in GNS relies on mappings, and "petnames". While those can
potentially be placed under some parent label, the existence of such a
parent label (either ".alt" or ".gns.alt") is neither necessary nor
sufficient to achieve any kind of global consistency.
There is also no ability to enforce any rules on using any parent label, or
to prevent conflicting intra-GNS "petnames", or to prevent conflicts
between GNS "petnames" and any other TLD namespaces (including DNS). 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.
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?
Those namespaces are not required to be unique within GNS, as well, so even
having an FCFS registry would not mirror the reality of GNS. 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.
And if the GNS draft isn't included in the registry (because it does not
administer ANY namespace), I don't see how the registry can function as
envisioned.
It may possibly be reduced to definitions: what is a namespace? If it is
not something that is global and consistent, I don't think it could
accurately be called a namespace.
It basically suffers from the "Woody Allen" problem ("I wouldn't want to be
a member of any club that would accept me as a member.")
Creating a registry as a place to put GNS would be self-contradicting if
GNS cannot be added to the registry.
Brian
>
> Two more points below.
>
> Paul wrote:
> >
> >> This proposes two significant changes to the draft: make the registry
> FCFS and make entrance to it be by RFC. Those are both pretty heavy-weight
> for things *that are not part of our naming system*.
>
> Heavy for who? Those wanting to create an entire naming systems for the
> Internet? Look, from my perspective I am comfortable with ANY registry
> policy. I've already provided a number of options to put the brakes on,
> if people are worried about a sudden rash of people building entire new
> name systems for the Internet. So let's discuss.
>
> Martin followed up to Paul:
>
> >> I strongly prefer "drop the registry" and let the non-DNS folks
> figure out how to deal with their own issues. After you see the next draft,
> if you think the registry with your two changes is needed, you can propose
> to add it back in.
> >>
> > The consequence of this (and I am looking at ISE here) will be that our
> > document will not be able to clearly define how to "use" alt as we are
> > not an authority on how to do things in the "non-DNS folks" community and
> > there is not way how to do that to date obviously.
>
> There exist a number of possibilities to establish an external
> registry. What is important is that one of them be mentioned in the ALT
> draft, so that others know where to look. But let's get through London.
>
> Eliot
>
>
> _______________________________________________
> DNSOP mailing list
> DNSOP@ietf.org
> https://www.ietf.org/mailman/listinfo/dnsop
>
_______________________________________________
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
