Hi. Aside from the more substantive content of the suggestion, including whether this could actually be done and all costs covered for one time charges of USD 0.10, I see three major concerns / questions that you should probably address: (1) Why .ARPA? In addition to the concern Nick raised, my recollection of the agreement between IETF and ICANN is that the TLD is supposed to be used for _network_ infrastructure, not as a cheap substitute for a gTLD. Granted that boundary has been pushed a bit in the past, but what you are talking about sounds like personal identifiers and definitely not network infrastructure. (2) Assuming the IETF went along with this (and ICANN did not have a fit about their perception of the agreement), what would be the acceptance or rejection criterion for whenever the next such request came along? In other words, when someone proposed a different scheme for, say, "hsem.arpa." or "tangle.arpa." rather than "mesh.arpa.", what criteria would the IETF use to accept or reject it? Equally important, when a fight breaks out as to who is the real Alice, or, as in the mistakes that were made in the delegation of the NAME TLD illustrate, who gets to administer the *.alice.mesh.arpa" subtree? Given that, at least in the absence of some complex administrative adjudication procedure (like ICANN's UDRP), debates about "who is the real Alice" tend to attract lawyers, some of whom find our theories about DNS delegations and delegated authority inconvenient, how would you propose to protect the IETF (or the IETF LLC) from becoming enmeshed in such disputes? If nothing else, that set of issues might be a strong argument for "mesh" second level domains underneath ccTLDs: countries are, if they choose to get involved, good at determining the legitimate owners of a name and associated attributes and can immunize themselves from disputes about those questions in ways in which the IETF or your hypothetical non-profit probably cannot. (3) The DNS was not designed for, and has never been good at, handling very large zones (independent of the level of the tree at which they occur). In the last couple of decades, throwing some database technology and a great deal of computer horsepower at the DNS has increased the plausible maximum zone size by several orders of magnitude over what I believe were the expectations in 1987 or even 1994, but the fundamental problem remains. Perhaps I don't understand your explanation and example, but if the subnodes of mesh.arpa are going to be callsigns bound to people and this model is successful, then you are talking about a zone with four or five billion nodes in it today (and growing). I can think of some plausible ways around that, perhaps including your idea about separating the resolver function from that of a registry, but they fall well short of "respects the DNS data model" and the computationally intensive versions would, at scale, causes Alice's coffee to get rather cold before she could drink it. best, john --On Monday, December 20, 2021 13:28 -0500 Phillip Hallam-Baker <phill@xxxxxxxxxxxxxxx> wrote: > TL;DR; I have two ways of achieving my desired end. One of > which people are not going to like, the other of which they > are totally going to hate. I do not actually require IETF > permission for either, nor am I the only person thinking along > these lines, I am merely the person whose approach is least > likely to result in collateral damage, consider responses in > those terms. > > I have been following various naming proposals in the > PonziCoin world for some time. There are many companies who > for a mere $10-200/year will register a shortname for your > ethereum wallet so people can give you money. And of course, > the cost of ethereum gas for making the payments only makes > the cost even stupider. But don't worry, there will be a > technical fix for that the minute they find themselves a > virgin and a unicorn. > > OK, so those proposals are obvious nonsense but the notion of > using a Certificate Transparency type log to issue names for > life on a first come first served basis is not. Hence my > callsign proposal: > > https://www.ietf.org/archive/id/draft-hallambaker-mesh-callsig > n-01.html > > [A very similar proposal has been made to ITU by the Chinese > delegation under their 'New Internet' scheme though I only > became aware of the details of that after I wrote my own. It > is my belief that the primary motivation behind the ITU > proposal is to prevent the abuse of DNS as a control point in > the Internet infrastructure.] > > Running infrastructure costs real money but I see no reason > for the cost of running the infrastructure proposed to be more > than a one-time $0.10 per name. No renewal fees. Names are > sold freehold, not rented. > > The objective here is to give Internet users a name they can > use for life. And yes, I realize that it is impossible to > collect $0.10 fees so I plan to sell names in packs of 50 or > so. So for the price of a pint of beer you can buy a permanent > callsign for yourself and pass out the means to grab one to > your friends. > > There are of course many social issues to be considered, not > least of which where does the surplus go. My proposal being > that the whole show to be run by a not-for-profit and the > surplus go to fund open source development of secure Internet > software, specifications and standards. > > > But that is not the part I want to talk about right now. What > I do want to talk about is how a new naming scheme interfaces > to the DNS so that it can be used to connect to legacy > applications. Legacy in this context meaning 'the stuff that > is working'. > > So Alice registers the callsign @alice and can use that in > messaging applications that understand the callsign scheme. > Which is not hard, just hook up to a callsign resolver and > send over a query. As with blockchain, the resolver maintains > a complete copy of the log. Queries go to a resolver, not the > registry. This means far greater robustness than DNS and > offloads almost all the cost from the registry. > > > But what about that doorbell, that WiFi camera, etc. that > Alice has? To talk to them she needs to use her browser and > that runs HTTP. > > The obvious solution for this is to put a statement in the > delegation assertion for @alice to specify an authoritative > DNS resolver for the DNS addresses *.alice.mesh. The callsign > resolver then delegates to the authoritatives. The net result > is that all Alice needs to do to resolve these names is to use > a DNS resolver that redirects requests in .mesh to one of the > callsign resolvers. > > The net result is a protocol that respects the DNS data model > at the lower levels while modernizing the root level. > > > OK so nobody expects me to pay to register .mesh. I am not > even going to lift a finger to make a proposal to ICANN. > > But I am not the only person making a proposal in this area > and while a single pirate TLD designed by someone who knows > something of what they are doing is likely to be amusing, a > hundred or more is likely to be less so. > > Which has me looking at .ARPA instead. > > Having Alice type http://coffee.alice.mesh.arpa/ instead of > https://coffee.alice.mesh/ is not as nice but she will live > with it. or if open callsigns win the naming game, the anybox > in her browser will probably let her type coffee@alice and > route to the place she expects to go. > > > Problem here is that RFC 3172 was written in a different era > when people were still frightened about the loss of control. > The notion that registries are not control points had not yet > been understood. > > So which would people prefer for the pseudo-delegation? > > alice.mesh or alice.mesh.arpa? > > This would be a reservation in .arpa, not a delegation. > > > PHB > > > (Oh and yes, I do have a browser implementation thanks to the > heroes who developed WebView2 at Microsoft. It's Windows only > at the moment but should be fixed with MAUI.) > > (Oh and yes, I do understand how complex naming gets, I > watched it all happening in real time.)
