On 20.10.22 12:05, Brian Dickson wrote:
> 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.
In GNS, you can expect that there will be default configurations of TLDs
(e.g. example.gns.alt with the alt suffix).
Those defaults (=root) will have to be governed similarly to what ICANN
does. And rules will, of cource, have to be enforced contractually, not
through the protocol. As is the case with DNS.
Yes the user can create local mappings, but you can do the same in DNS
(split horizon, RFC8375 etc etc)
>
> The question that hasn't been addressed is, who SHOULD actually do
> registrations in this proposed registry?
Experts well versed in name system design?
> 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.
Not exclusively, no.
> 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.
>
I do not understand the question. Isn't that exactly how home.arpa
works?
Names in .home.arpa are only locally unique. In practice, GNS will
actually have unique(r) deployments than .home.arpa.
But even if it does not, calling global uniqueness/consistency a
requirement is calling home.arpa not a namespace.
BR
Martin
> 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
_______________________________________________
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
