#645+ Handling ICANN Strings in Hard Fork #649
Comments
This is what I care about the most. However, how do we incentivize holders of Handshake names to give up what they invested in? Give them a refund totaling the winning (or second highest) bid? That seems the fairest but would they all do it? (Also, does someone have a list of existing collisions?) A rude alternative would be to go ahead with the fork and declare names like |
The whole point is that you don't have to trust. You can verify. My company owns the Handshake name It doesn't really matter how things are seen. And by whom? The code is open source, anyone can check it out and come to their own conclusions as to whether it is mature and trustworthy.
I am not sure this is true. For example it didn't stop Namecheap (the 2nd largest and fastest growing registrar in the world) to adopt Handshake. |
|
Using a hard fork to reallocate assets will necessarily be controversial, meaning any such attempt to do so will result in a second blockchain. We've seen this exact story play out with Ethereum / Ethereum Classic. If anyone is concerned about name collisions, a controversial hard fork of Handshake will literally double those concerns. Cryptocurrencies are designed to protect and empower individual users, not large institutions. |
|
Namecheap is big, no argument, but they are a sales channel, not a national DNS resolver. This project is about more than fomo sales and profits, it is about use and adoption too. Conflating registration and resolution is cognitive distortion. Analog is (registration) Apple sells iPhones, but if only small carrier networks but no national/international carriers support them (resolution) then they are mighty tech but isolated from mass adoption. In fact, it is a perfect example, to walk it out further... Say Apple developed and sold a few million new iPhone models that they allowed custom area codes on as major features but these were not activatable or carried by the big networks because they re-routed a few actual area codes incorrectly in its firmware because Apple engineers failed to look at the announced area code routing tables, instead opting for what was in the phone book at the time. Despite the excitement over the technical capability of these special phones wifi or other features, the carriers won't add these phones while they reroute a few of the conflicting area codes, and a handful of folks entrench on their custom area codes that conflict at the end result of 2 million bricked iPhone devices that can only work to make calls on wifi or spotty isolated regions. Folks want them to work all over the place, naturally, universally. Move the barrier. We just need to put a link to this issue and #649 in the pinned message on telegram in response to "wen cloudflare" |
|
Regarding a hard fork for Handshake to address reserved strings, here are my thoughts: It would be useful to develop some principles and policies to be governed by. Here are a few:
The original intent of Handshake was to be backwards-compatible with ICANN But it missed a few TLDs that were still in the ICANN pipeline. These should be clawed back and placed on the reserved list. This isolates the namespace collision issue to one where ICANN is initiating namespace collisions rather than Handshake. In terms of collisions with other alternative DNS (UD, Butterfly, etc.) , I propose that these can be ignored.
Otherwise, if these reserved ICANN TLDs are released, then Handshake becomes the initiator of namespace collisions, which violates the first principle above.
5 Maintain a plan for the expiration of reserved website domains The reservation of these should expire, since there are also legitimate non-infringing uses for trademarked strings, especially if they are dictionary words. To discourage cybersquatting, see the next policy. I suspect there is a significant overlap between the reserved Alexa list and the strings that will be applied for in the next ICANN TLD round. So, perhaps the timing of unreserving Alexa names could be event-driven: i.e it occurs only after ICANN publishes its list of submitted TLD applications, so that the overlap can be moved to the reserved ICANN TLD list before the Alexa names expire.
There are likely many famous trademarks that do not operate stand-alone high traffic websites and thus were not included on the Alexa list. And new global famous trademarks have emerged since Handshake has launched and continue to emerge. How will Handshake discourage cybersquatting of these trademarks? Beyond trademarks, there are also TLD uses that should be discouraged, since as Child Trafficking. How will the Handshake community police unacceptable uses of Handshake? |
I somewhat agree with this but this statement brought a question to mind...what if ICANN sees a Handshake name doing well and wants to create it on their side? There's a lot of talk about users of Handshake respecting ICANN. Is this respect reciprocal?
Johnny Wu of Namebase has a burner wallet that people have sent names to. |
|
Forget about reciprocal respect. ICANN isn't on the other side. Instead, it is some corporation or entrepreneur or speculator (hoping to be bought out). Voluntary submission to a burner wallet isn't going to cut it. The issue-du-jour is "DNS Abuse". The heavyweights are gearing up...https://www.fastcompany.com/90686579/blockchain-domains-bit-microsoft |
|
@NetOperatorWibby
This doesn't make sense. The names will just expire and back to auction. If we really wanted to burn a name it should be sent to an anyonecanrenew address and the community will have to keep the name alive, with no dns data, and keep it off the auction block. Even this strategy won't be bulletproof as fees rise on chain and renewal fees aren't fun anymore. |
I agree with Encircas post with a few comments:
ICANN TLDs which were not reserved by mistake in the beginning should become reserved via hard fork (of course just if community voted for). The current owner (who was probably aware of the mistake) should get (double?) the amount of HNS of the highest bid.
I disagree to reserve any ICANN TLDs in the future. Neither is it possible to quickly reserve a name (which takes a hard fork) nor do I think that such a name would still be available on Handshake.
Law enforcement has ways to seize Bitcoin so are ways to seize Handshake TLDs. I guess it's even easier to get the owner of a name since for a working domain you need also nameserver and host, so a lot of traces... |
Namebase owns
A blockchain project that claws back user's assets is a dead project in my opinion. We can argue over the founders' "intents" with the reserved list but I guarantee you they did NOT intend for an authoritarian organization of people especially a for-profit corporation like MMX co-founded by Jothan Frakes aka @dnsguru to HIJACK the protocol. Users in support of this corporate take-over should learn about the Ethereum Classic hard fork, and the SegWit2x (failed) hard fork. The community can decide to do whatever it wants but I promise I will personally not merge code to handshake-org/hsd that claws back user's assets. |
|
I have to correct myself. There are currently 3 name conflicts between Handshake and IANA TLD list which I guess occurred after Handshake Mainnet start. |
@pinheadmz this appears to be a bit of a personal reputational attack. You're better than that. The problem with it besides it being offensive and frustrating because of all the effort I put in to evolving this project, is that factually it is as ham-fisted as the founders' understanding of ICANN that led to the mistakes in the bootstrap. Yes, I helped co-found MMX and worked there in 2009-2010, which is two years before MMX applied for any TLDs in 2012, and although they were one of the ten applicants for .music in the 2012 round, they did not end up prevailing as the party who ultimately secured the TLD through the ICANN application process. I get frustrated too, but don't make it personal. |
...is what led to the invention of Handshake. |
Apologies. 🙏 |
You guys do have so much more background in this space, can you explain why the names you mentioned are not in the current IANA TLD list? Wouldn't it be better to clean up the disprepances between ICANN and IANA or at least mark names with a status to understand the difference? And even on IANA site there's a second list which is different again. And last question, how do you recommend to solve conflicts between Handshake and 'constantly updated' list by ICANN? Edit: Just checked .active, .blanco and .boots in ICANN gTLDs JSON Report they have a removalDate 2018/2019!! And here's |
Israel launched a Hebrew language version of its ccTLD (.il), and the two Amazon IDN were caught in the conflict queue along with .amazon (but this was caught by the alexa list) as the TLD for the brand worked out their matter where there were objections from the South American countries that regionally held some rights to dispute it.
Yup
Because it got unconflicted, then contracted, and then gets added to the root zone. Doesn't mean it doesn't exist any more than a name that is sitting in reveal on handshake isn't real
Thats a tad entrenched, but I get that argument. This is the perspective that the founders just took a snapshot of whatever was in the root zone at the time and it had some stuff and missed some stuff. This is a perfectly valid point of view, and from the perspective of anyone who picked up one of the conflicting strings, it makes sense to frame things this way. So let's say there are about a dozen (maybe TLDs) that had been created in the 2012 round but were not in the root due to de-conflicting delays and other guard rails against name collisions. The conflicts were thornier and those took longer, but didn't appear in a cornfield suddenly, unless one choses to look at the IANA list or root zone in isolation. The challenge with this perspective on handling the matter of the collisions with exsting domains, perhaps even more hard-edged than using the ICANN Json resource, is that it carries a message to large institutional carriers, DNS Infrastructure, browsers etc that the founders of handshake completely missed some really obvious stuff like this, which begs the question, what else did they miss. It erodes confidence in the project as viable or safe to embrace. While taking the 'it wasn't in the root' preserves the dozen or so TLDs that slipped through in conflict with the published json list and the ngtld portal that listed all the 2012 round applications, it does so at the cost of diminishing overall handshake adoption in the wild. Parties that could have quite a transformative impact on the project like cloudflare or major browsers watch these threads for how these matters are addressed or not have done the "alt-root" dance a few times already, and are already in 'no thank you' mode. If we leave this as-is, those dozen or so TLDs that really should not have been allowed into auction are absoluately in the way of a good answer to
The gTLD conflicts don't just pop up magically in a corn field. There was a 2012 round - period. The results are in the queue. That queue was either unknown or ignored. To say that list is "constantly updated" is less unpredictable if one uses the ICANN json and not the root zone or IANA list. There is a process under way within ICANN called 'subpro' or 'subsequent procedures' that is likely 18-36 months from delivering a new TLD round, and that is a W.A.G. estimate that seems to constantly slip. By addressing the gaps to those known in a manner that Tom Barrett and I are identifying, it makes the issue of name collission less a thing until such time as that round opens, and by then this community will have all kinds of remedy or answers to questions about this that are not present today.
I enumerated a few examples but the principle there was to not only have names get taken from auctionees (if the community opts that) or switch lists, but also to make available some TLDs that the ICANN side of things dropped so those are available to people in the handshake.org namespace.
Good star wars reference - nerd respect active. Anyways... Correct on that date. Pretty similar topic on most all of the conflict domains, but .music seems to be the focus of your comments. Although all 10 of the applications for .music were applied to ICANN in 2012, the conflict resolution process to narrow down to the (there can only be one) "Highlander" situation down to the sole party that ultimately was delegated the ICANN TLD. There are a number of other stories of conflicts that had to get untangled, but all stem from a predictable, publicly available list of strings that were applied for in 2012. The objective here is to get handshake better answers to the conflict and name collission stuff as it is big obstacle for how usable the rest of the names can be. Path A: Clutch tightly to 12ish names but hobble confidence from vendor/service for 2M others |
It was a 'forced alumnist' situation so I have no level of butthurtedness over them not prevailing. I moved on to other things. It was just a wierd thing to have a job from 12 years ago thrown up as some reason I am motivated here (or?) The timing, while I am in the middle of being asked by other community members to coach others in the handshake community on how to speak and engage during the ICANN 72 meeting (on right now https://72.schedule.icann.org) about the handshake project and engage in a productive manner with that community... ain't nobody got time for that kind of demotivational stuff. |
|
First of all, I want to express my sincerely respect for all of you and your opinions. I will be direct and short in my opinion. |
|
So right now it appears that the consensus is that there is no consensus. Industry (or corporate/incumbent) adoption seems to be the goal. However, many users of Handshake are quite tired of how things have been. Deference to corporations is decidedly anti-cypherpunk, even with the best intentions...which, the original authors of Handshake built the blockchain with. What I see happening is this: we'll agree to disagree and user adoption will drive industry adoption — not the other way around. ICANN's continued planned round slippage keeps moving back in our (Handshake's) favor. While there is power in being the default and included in every shipping operating system, crypto-native folks are no strangers to augmenting their devices with additional software to achieve what they want. My mom knows what a smart contract is and I gave her her Handshake name. Public awareness is only a matter of time and ICANN is all too keen to (unintentionally) provide us this gift. What everything will boil down to is a browser/extension setting asking users which namespace they want to access. 🤷🏾♂️ |
|
@faltrum That's actually pretty genius. It's not like ICANN would be losing money. |
I think could be a great solution, everybody win. |
I don't understand how you come to this conclusion. A line had to be drawn, and it was drawn. .music wasn't in it and so it didn't make the cut. Do you propose that ICANN be the root of trust for Handshake? That is to say, should we claw back any new ICANN TLD? Or do you want to draw a line in the sand, but you want it to be at some later point (presumably after .music is clawed back)? I don't see it as the founders missed anything, I see it simply that a line had to be drawn and it was drawn with the root zone at the time it was drawn. You can't keep moving it / changing it. The line was drawn and now it is Handshake's turn to control the root zone. |
I admire the creativity of this community in finding alternative paths forward. Utopian idea, but this has low odds, unfortunately. On a good day I would give this a 2-3% chance, knowing how risk-averse and careful review would be at ICANN, they would probably spend whatever it's equivalent fiat on legal / financial / security reviews. Most folks familiar with ICANN understand that this suggestion needs to be presented in a nuanced way to have a chance. The leadership and community at ICANN may be entirely unaware of the claim being available. Would be worth someone stepping up at the public forum during the current ICANN 72 meeting to mention the handshake project claim, the claim and its equivalent usd value, and do so without much other said. There are a set of people from within the ICANN community who are watching the discussion, and it is good, where we can, to convince them there is a community that respects what it is building upon the shoulders of, that it understands how to expand the namespace responsibly and there is appetite for more than just mercenary commercial interests going on. |
Seems like the ball is in y'all court. |
|
Mobile client ; bumped wrong button |
No, I am saying that the runner sharted at the firing gun and needs new underwear. That line is brown and needs a bleaching to clean up some "farticles"
Just those which existed from various stages of application in 2012. I keep saying this, it is not a new or growing list.
I want this project to get wider adoption before facing collision issues
I think this is a split of perspective based upon what one wants to select as the approach that supports one outcome or another. But they totally missed the existing TLD list for all practical intents and purpose, otherwise there would not be collisions
Nothing moved. The wrong line was chosen
This would imply it has been demonstrated handshake could be trusted to do that in a way that could be possible, with things like rectifying the shart |
Just for the sake of clarity, can you name it? |
Sure, Here is the link to the In the brief window that was open in 2012 to do so, there were 1933 applications filed, many of which were multiple parties interested in the same TLD. No new rounds or application opportunities have occurred since 2012, but the evaluation and contracting for these took time so TLDs started to hit the root around late 2013 for them, and some have taken longer t han others. Click on Contention Sets link from the page link above - those would have to get sorted out before going to contract and then into the root. This data has all been there - the list of TLDs was static at the point they closed the round in 2012. |
|
It's funny to tell me to sort things out myself to get the names. Thanks, I'm out. |
|
must have been a language misunderstanding of "can you name it" maybe you were asking for a list of conflicted domans and not a link to the resource that had been there since 2012 ? |
|
Ok, obviously a misunderstanding. I wanted to ask you if you can name the names/domains - explicitely - which create conflicts and you want to get solved. |
|
Just some meta-commentary on the thread so far
Ok now on to lengthy argument as i am so want to do :) I empathize with the argument to not clawback assets but this is an incredibly small scope with clearly defined criteria and precedence. This is not an undefined, arbitrary change that violates first principles of Handshake. It is an unfortunate situation that we are in but one do to a bug in the implementation of Handshake itself and now we have the opportunity to fix it. For perspective there are over 2.6 million TLDs registered on Handshake so far meaning this change would affect only 0.0002% of all Handshake domains. (can update stat if conflicted TLD number changes) I do believe that HNS would still be useful and valuable even if it doesn't become the global root zone. But it would only ever be useful to us. It would be hard to give the freedom and security that we strive for ourselves to others without it being THE root zone. Advocating for a shortlist of investors (see below why only this stakeholder matters in this proposal) jeopardizes the success of the project and introduces security risks for nontechnical users that might not even know that Handshake vs ICANN differences exist or which conflicting TLD they are or should be accessing. At the end of the day it is our job to maintain the global common namespace for ALL users of the internet. For such an outsized impact for the greater good, I find it hard to believe that an owner of a conflicted Handshake domain wouldn't advocate for this change and if they dont advocate it I would question our responsibility to them as a community. I think there are 3 main stakeholders at play here - DNS infrastructure providers, self-sovereign domain users, and TLD investors. DNS Infrastructure - Pretty obvious standpoint. They will not support Handshake if it conflicts with ICANN. Handshake can try to rebuild the global internet infrastructure on its own but considering the difficulty in funding basic protocol development already, it is safe to say we are dependent on these service providers for any large scale adoption. Self-sovereign domain users - These are just your average TLD owners. They like owning their name and knowing that it is verifiably theirs. They think it's pretty cool that all these weird domain names actually work, partially because they don't even know how its possible. They may or may not believe in all the values of crypto and Handshake. This policy will affect 0% of these users! Even if we mirrored ICANN forever and revoked any TLD they create this policy wouldn't affect 99.99~% of these personal/niche/shitpost domains because only mainstream domains would be tolerable and profitable for large scale companies to go through the capital intensive ICANN process. TLD investors - Speculators and scalpers that only want to monetize TLDs through resales or SLD sales. Realistically these are the only stakeholders at risk in this proposal because they are the only domains worth going through the ICANN process. Obviously not ideal to "lose" "your" domain investment but as speculators they are aware of the risks and a full loss should be calculated and accounted beforehand. This proposal states that these names should have been reserved since genesis block and should never have been available for auction. But lets say there wasnt a bug and you do rightfully own it, lets keep in mind that this proposal doesn't constantly revoke TLDs in the future putting all of your assets at risk. These investors likely own a diverse portfolio of TLDs. It is better to get full refund on your purchase and lose upside in one asset in order to derisk and increase potential value for the rest of you portfolio. Sure one of the domains you used to own might have been worth millions, but overall your portfolio is much bigger in absolute terms than it would be if you don't get a refund for your domain. So effectively this proposal affects almost no one and even for those that it does affect negatively in the short term, in the long term the change will have a much larger positive impact on them. Most importantly there's nothing to prevent anyone from forking Handshake into a new chain and implementing these changes themselves, improving their chances of adoption. You should hope that it is a hardfork and you retain your existing assets on Handshake onto this new chain but realistically (or at least what I would do if I had no allegiance to Handshake) it would be an entirely new chain and you will have to buy your TLDs and coins all over again. Investing in a new chain reduces your profitability as well and delegitimizes Handshake more than clawingback assets that theoretically shouldn't have been available on Handshake in the first place. In order to be THE root zone Handshake MUST be compatible with the original root zone. Otherwise we are a just another alternative namespace and have failed at our mission. With foreign governments building independent infrastructure to replace systems that have historically been controlled U.S interests, such as the European Union's Galileo program to replace GPS, it is possible that we could see nation state adoption of Handshake as credibly neutral infrastructure.
ICANN policies like mandatory data collection for WHOIS in conflict with GDPR regulation creating friction, that could tip the balance in our favor. However, a government would never adopt Handshake if we aren't in synch with ICANN, putting citizens at risk for phishing cyberattacks, fraudulent domain sales, etc. As a cryptoanarchist I really do wish that this situation could be avoided its short sighted and zero-sum to say that this proposal only has negative affects and could potentially kill handshake. If anything i think the opposite is true, there is almost no downside and massive upside to the potential. I recognize this challenges the sovereignty of Handshake and its users but I would like to think of us as a community and that the affected community members see this is a good decision for all of us and support it. |
|
I don't disagree...I'd like confirmation from the ICANN guys about other conflicts, if we missed any. Also, what about future ICANN gTLD rounds? They're gonna happen...eventually. Will the conversation of forking come up again? Whatever happens right now should be done so with the clear expectation that future conflicts won't be accommodated. This proposed hard fork is fixing an oopsie that shouldn't have happened in the first place (and maybe adjusting other things people smarter than I see as slight annoyances within Handshake). |
Just for reference, recorded on 28 Oct 2021 |
|
I think this discussion should include a more near-term threat facing Handshake. The main threat to Handshake right now is that blockchain domains are being perceived as a haven for cyber-criminals. The “minor” distinctions between Handshake, Unstoppable Domains, Butterfly and ENS do not matter. I am new to Handshake but fully embrace its potential. I do not see it replacing ICANN. Instead, it will enable the long tail of TLDs for individuals and businesses who are unable or unwilling to go through the ICANN application process. As someone who has been involved in the domain name space since before the formation of ICANN, I have this observation to make: The ICANN community that has spent 20+ years building the DNS regulatory framework is increasingly viewing the blockchain as an existential threat to their DNS governance role. And as Chair of the Blockchain Committee for the International Trademark Association, interest in the threats and opportunities from blockchain domains is intensifying. Right now, the threats are over-whelming the opportunities. Microsoft ALREADY flagged blockchain domains for potential DNS abuse. In their October, 2021 report, Microsoft Digital Defense Report OCTOBER 2021, they say “blockchain domains have become a preferred choice for cybercrime infrastructure” and “The next big threat: “Forever” (blockchain) domains” (just do a search for “blockchain” in the report) (https://query.prod.cms.rt.microsoft.com/cms/api/am/binary/RWMFIi) ICANN is also raising the alarm here (January 5, 2022): Relying on ICANN Community-Developed Processes for a Safe, Secure Internet (https://www.icann.org/en/blogs/details/relying-on-icann-community-developed-processes-for-a-safe-secure-internet-5-1-2022-en) and here (November 24, 2021): Buyer Beware: Not All Names Are Created Equal (icann.org) (https://www.icann.org/en/blogs/details/buyer-beware-not-all-names-are-created-equal-24-11-2021-en) One recently staked Handshake TLD is “.c0m” that substitutes the letter o with a zero. Do not be surprised to see this TLD making headlines in 2022 as another shining example of how blockchain domains can be exploited by cyber-criminals to defraud consumers. And finally, the 5-10 missed ICANN TLDs will also be publicized in the near-term as an example of blockchain’s abuse of the DNS. Defending against all this will be a HUGE distraction and hinder the adoption and success of Handshake. In this context, here are some general principles for your consideration:
The next round of ICANN TLDs will be in 4-5 years’ time. I predict MOST of these applications will overlap with the Alexa100K list and will be claimed before the reserved status expires. So, I do not see a lot of Handshake collisions happening in the next ICANN round. I participate in ICANN’s Names Collision Advisory Process (NCAP). NCAP is focused primarily on root server error traffic. In 2012, 95% of applied-for strings had such error traffic. All new TLDs were required to undergo a controlled interruption process to alert users generating this error traffic. The DNS has evolved in 10 years. NCAP will be releasing a draft report this month that reveals that root server traffic in 2022 do not have visibility to 30% of all potential TLD collisions—instead, these non-root TLD “collisions” are seen only by public dns resolvers. Thus, in 2022, the controlled interruption method would not mitigate 30% of potential TLD collisions. ICANN will be forced to address these non-root TLD collisions before delegating more TLDs.
If not addressed somehow, these 5-10 Handshake TLDs will be shining examples of why blockchain TLDs are a huge risk of potential harm to consumers. Allowing these small number of Handshake TLDs to collide with ICANN TLDs in 2022 will put Handshake supporters on the defensive and risk being labelled as “bad actors”. In other words, this will be a distraction and inhibitor to gaining further adoption of Handshake. I do not think there should be a hard or soft fork just to claw these back. But I do think the owners of these TLDs should voluntarily return them for the good of Handshake. Otherwise, they WILL continually be publicized as examples of DNS Abuse by Blockchain domains by the ICANN, Microsoft, Brand protection providers, etc.
The initial reservation of the top 100,000 Alexa-ranked websites was a crude anti-cybersquatting policy that merely used the Alexa list as a proxy for the top trademarks. Many of these strings have legitimate non-infringing uses. If not claimed, they should be released for general registration per the current schedule. I predict most of these will be claimed by the trademark owners anyway before the Handshake expiration date: aided and abetted by brand protection providers and new TLD consultants.
Unacceptable Content: How will the Handshake community assess and police unacceptable uses for Handshake? (i.e., child sex trafficking). What is the mechanism to blacklist TLDs deemed not acceptable to the community? Homographs: There are TLD strings that should be discouraged, such as TLD Homographs that could be used to confuse, mislead, and defraud consumers. See What is an IDN Homograph Attack and How Do You Protect Yourself? (zvelo.com). (https://zvelo.com/what-is-idn-homograph-attack-protect-yourself/#:~:text=An%20internationalized%20domain%20name%20%28IDN%29%20homograph%20attack%20is,used%20to%20lure%20users%20to%20the%20new%20website.) ICANN already requires ICANN TLDs to police this. See ICANN Statement on IDN Homograph Attacks and Request for Public Comment. (https://www.icann.org/en/announcements/details/icann-statement-on-idn-homograph-attacks-and-request-for-public-comment-23-2-2005-en) Donuts, the registry with the largest portfolio of names has made this their predominant market positioning: TrueName Home - TrueName by Donuts saying “Our advanced anti-phishing technology blocks imposters by preventing registrations that spoof your domain name.” (https://truename.domains/) Handshake should have a policy to prevent IDN Homographs – which is prohibiting the use of more than one IDN script in characters comprising a given TLD label. I do not know if Handshake homograph TLDs have already been registered and would be impacted by such a policy. If we become aware of them, we would blacklist them. And I would discourage Namebase and others from not staking them. Regarding the Handshake “.c0m” TLD that substitutes a zero for the letter o. I see no redeeming value to a TLD that appears designed to confuse consumers. Although EnCirca supports every Namebase-staked TLD, EnCirca has flagged the “.c0m” TLD and a few other obvious trademark infringements for special processing where we will process the SLD order only if the registrant can demonstrate rights in the corresponding .com domain or trademark. We will lobby other registrars to do the same. FORK OR NOT?
I do not see many ICANN TLD claims happening in the current climate. There are two major reasons why: Here is ICANN’s January 5 response: Relying on ICANN Community-Developed Processes for a Safe, Secure Internet. (https://www.icann.org/en/blogs/details/relying-on-icann-community-developed-processes-for-a-safe-secure-internet-5-1-2022-en) One of my clients cancelled claiming their reserved Handshake TLD last week due to concerns over this. B. TLD registries need cooperation from the Back-end registry providers providing the TLD’s HSM. Do not under-estimate the potential competitive threat they perceive from Handshake to their business model.
I look forward to continuing this discussion! |
and others
(This carries over from and splits off #645)
Extending the claim period is a good and responsibile idea to put in place, +4 years, +10 years, +25 years, whatever the term is. The downside is that it might diminish the urgency to act which may have had some claim sooner vs defer, but the upside is that Handshake can be seen as a mature and trustable platform.
There are TLDs that should have been set aside as ICANN TLDs that either:
There are also some TLDs (mostly .brand that opted to later not launch) which were in the ICANN root which have been released and could be available in Handshake (ex: .active, .blanco, .boots etc) (see: ICANN gTLDs JSON Report, constantly updated)
It would be good to use this hard fork to address where some TLDs were missed and went to auction - we've discussed this and it seems a bit controversial but the mistakes that let some errors slip through should be fixed. It is problematic and it creates more difficulty in having conversations with large providers to describe that there is name collision now as opposed to it being something to address later for names that have auctioned (.music, .spa, hotels etc).
Originally posted by @dnsguru in #645 (comment)
The conversation splits down the line of what to do about a few of the 2012 round ICANN strings that were not included in the bootstrap in Feb 2020 and later auctioned. This includes some Amazon TLDs, .music, .kids, .spa, .hotels and some others.
These force collision between the "ICANN root" versions and the handshake versions of the TLDs that were missed in the bootstrap and got auctioned on handshake and remain unclaimable by the TLD administrators on the ICANN side.
The collision stuff is fueling disinterest in adoption and inclusion by larger institutional / incumbent DNS / Service Providers / Browsers that might otherwise be accellerating adoption of handshake.
The folks who won the auctions on the slipped names understandibly want to keep them.
The adoption challenge will remain thick and sticky until this gets sorted out, so the community needs to decide if the hobbled adoption is more important than the certainty of TLD ownership on this one.
There was a plugin solution for resolvers that was developed as a potential band-aid with the ambition of addressing this at the per-resolver preference level, but institutional large-scale providers seem disinterested in that solution as a bridge to the collisions issue.
It is a bit of a polarized issue. Move large adoption obstacles out of the path on the handful of names that probably should not have been allowed, or leave them in place?
The text was updated successfully, but these errors were encountered: