> On 4. Aug 2022, at 21:28, David Conrad <[email protected]> wrote: > > Martin, >
Hi David, > On Aug 4, 2022, at 12:01 PM, Schanzenbach, Martin <[email protected]> > wrote: >> But the resolution protocol is technology-neutral. I invite you to re-read >> the draft. We are not proposing a namespace. > > Right. If I understand correctly, you are proposing to use the existing > domain name namespace, and that’s where the problem lies. Not quite. We are proposing a protocol that can resolve any domain name. Of any name space. Regardless of its governance. > > Because of the way applications have been written and users have been > trained, there is precisely one global "domain name” namespace. It is a > series of labels separated by ‘.’s” at the presentation layer. As > applications and end users cannot distinguish the underlying protocol by > which names are resolved simply from the name, the fact that the protocol is > “technology-neutral” (whatever that means) is irrelevant. Since the domain > name namespace is hierarchical, there can be only one designated > administrator for each branch of the global name space. Note that that > administration can be centralized or decentralized, but if it is > decentralized, it must be coordinated, i.e., the multiple authorities can’t > just go off and partition the namespace by themselves and expect those > partitions to have global uniqueness. > >> The possibility for the user to modify local configurations is as benign as >> a modification of /etc/hosts or Nsswitch. > > Sure. And to what will those users/applications that do not modify /etc/hosts > or use nsswitch, which will undoubtedly be the vast majority, send their > queries? And what happens when someone who “plays by the rules” and goes > through the ICANN “global multi-stakeholder defined" process (e.g., the folks > who obtained .pet) obtains the same portion of the domain name namespace you > have chosen for GNS? > Also not quite. "We" do not choose anything regarding names or TLDs in GNS. Think of the draft as the equivalent of the specification of iterative resolution in DNS. That is what is specified for GNS. Not who controls the root zone. And not what is in it. So, for example, GNS implementations/deployments could ship with a root zone defined by ICANN. Of course, ICANN would have to decide to publish such a configuration. The configuration could be simple mapping from TLDs to zone keys. The delegations would point to the TLD owners (which in turn also publish their zones) that ICANN considers the owners. Of course this is at this point a ridiculous proposition as it would mean that all stakeholders would have to publish their DNS zones in their equivalent GNS zones. But if that would happen tomorrow, you would have the same namespace, governed by the same processes, with a different technical underpinning. Yes, users could modify the ICANN-default root zone in this world. It would effectively be similar (albeit a bit more powerful) to adding a hostname to /etc/hosts. It may destroy a lot of things that would work otherwise (e.g. TLS), it may not (if it is the same IP, for example). But at that point the user is in dragon country anyway. Ok, back to the real world: Of course, the above could not happen overnight. So the idea is that we *MAY* need a place (a sub-namespace) where this protocol can be tested, now. A special-use TLD may make sense for this. I hope this makes it clear what we mean by "this is only a protocol and does not address governance". > I believe (and I’m sure I’ll be corrected if I’m wrong) a major reason there > is a moratorium on the process defined in RFC 6761 is because of a lack of > clarity about who has authority over the administration of the single, global > domain name namespace that you want to insert a name into. Some believe that > authority is ICANN and others believe your usage would fall under “technical > use” (whatever that means) and thus, be in the realm of the IETF. > Complicating matters, the existing processes for TLD allocation at ICANN > simply did not envision this particular usage and even if it did, the "new > round”, known in ICANNland as “Subsequent Procedures”, is still (probably) > years off. > > The implication of all of this is the quagmire you find yourself in. In my > view, you should be commended for trying to do “the right thing” but that > doesn’t solve your problem. Pragmatically speaking, and to perhaps state the > obvious, 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) > 4) Squat on a name like various other folks (Unstoppable Domains, Handshake, > Butterfly, Namecoin, etc.) have done and hope (1) or (2) will happen and > recognize the name you squatted on. > > Did I miss anything? As elaborated above I would like to add the current state of the draft: 5) Only publish a technical protocol as we do now and leave the governance question out of the draft. BR Martin > > Thanks, > -drc >
signature.asc
Description: Message signed with OpenPGP
_______________________________________________ DNSOP mailing list [email protected] https://www.ietf.org/mailman/listinfo/dnsop
