On Fri, Oct 21, 2022 at 9:52 AM Paul Vixie <paul= 40redbarn....@dmarc.ietf.org> wrote:
> see inline. > > Wes Hardaker wrote on 2022-10-21 09:09: > > Joe Abley <jab...@hopcount.ca> writes: > > > >>> Normally, a registry is created when it will help the operation of > >>> the protocol. The problem here is that there's an _anti_-protocol, > >>> and therefore it's mystifying to me how a registry helps anything, > >>> since there is no way to know whether a registry will actually help > >>> or in some cases even hurt. > >> > >> Yes. This. > > -1. > > > To put this another way: the proponents of the currently active non-DNS > > naming systems are creating these systems with an active desire to avoid > > a centralized form of control over the name space they're creating. And > > by having a registry, it would re-insert some level of control that > > they're explicitly fighting against. > it's a registry of carve-outs for use inside DNS, which happens to > facilitate client development by giving agents such as browser plugins a > clear activation signal that's unambiguous with respect to the DNS. > > it's not a fight, and the internet standards community should facilitate > such carve-outs whenever possible. > That would be an interesting use case, for a different "thing", IMNSHO. What you describe would be different from the use cases of GNS or other similar systems, which either have no need to directly coexist with the ICANN-root DNS, or enable name conflicts by overloading DNS without enforcing guard rails. I think your suggested carve-out would need a different anchor point in the DNS namespace, might need a registry, and if a registry were created, would need very strict enforcement on the cooperative augmentation to DNS by those things. I don't think the suggested carve-out fit into the current proposed draft (alt-tld), but would probably be a similar document, possibly simple in nature and as long as alt-tld was published first or at the same time, would avoid land-rush issues or abuse. As to what place to put the carve-out, I think its requirements would be quite similar to the homenet thing, which has 'home.arpa'. So, maybe 'alt.arpa' with insecure delegation (which would facilitate both adding trust anchors and/or having local namespaces that are intended to sit underneath the alt.arpa namespace safely)? Brian
_______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
