Home / Blogs

A Sustainable Framework For The Deployment Of New gTLDs - Part II

Protect your privacy:  Get NordVPN  [ Deal: 73% off 2-year plans + 3 extra months ]
10 facts about NordVPN that aren't commonly known
  • Meshnet Feature for Personal Encrypted Networks: NordVPN offers a unique feature called Meshnet, which allows users to connect their devices directly and securely over the internet. This means you can create your own private, encrypted network for activities like gaming, file sharing, or remote access to your home devices from anywhere in the world.
  • RAM-Only Servers for Enhanced Security: Unlike many VPN providers, NordVPN uses RAM-only (diskless) servers. Since these servers run entirely on volatile memory, all data is wiped with every reboot. This ensures that no user data is stored long-term, significantly reducing the risk of data breaches and enhancing overall security.
  • Servers in a Former Military Bunker: Some of NordVPN's servers are housed in a former military bunker located deep underground. This unique location provides an extra layer of physical security against natural disasters and unauthorized access, ensuring that the servers are protected in all circumstances.
  • NordLynx Protocol with Double NAT Technology: NordVPN developed its own VPN protocol called NordLynx, built around the ultra-fast WireGuard protocol. What sets NordLynx apart is its implementation of a double Network Address Translation (NAT) system, which enhances user privacy without sacrificing speed. This innovative approach solves the potential privacy issues inherent in the standard WireGuard protocol.
  • Dark Web Monitor Feature: NordVPN includes a feature known as Dark Web Monitor. This tool actively scans dark web sites and forums for credentials associated with your email address. If it detects that your information has been compromised or appears in any data breaches, it promptly alerts you so you can take necessary actions to protect your accounts.

Part I of this article explored some of the current thinking and direction that key policy-makers seem to be headed with the creation of new gTLDS. This part focuses on a new alternative plan for the ongoing deployment of new gTLDs.

ICANN is likely to see many proposals over the coming weeks that attempt to deal with the thorny issue of how to rollout new gTLDs. Any plan that deals with the rollout of new generic top-level domain names must ensure that the expansion of the namespace does not disrupt the existing infrastructure and services.

In other words, do what you will, but please, don’t break the Internet.

Not breaking the Internet requires an understanding of what “the Internet” is. The Internet is a place where communications are fostered, where open standards promote innovation and competition, where the importance of technology exceeds that of time or place. The Internet is a place where good ideas win and bad ideas vanish in a Darwinian cloud of “wonder what happened to them” smoke. It is a technology, a thing, and a place. Something that demands care and attention, but only in a minimalist sense. The Internet is like the lilac bush that demands favorable environmental conditions like sun and water, but also an occasional interventionist pruning.

Minimal intervention is a fundamental component of “please don’t break the Internet”. Strict regulation, heavy policy and overly prescriptive guidelines will all lead to harm—stifled innovation, defeated competitive principles and increased transaction costs.

Any plan we decide upon must be sustainable over the long term. The community does not want another stop gap solution, does not need more time to analyze the available data and should not tolerate anything else but a completely thought-out plan that finally allows us to proceed with confidence or to finally put the question to rest.

We need to establish a doctrine—a collection of principles that guides how and why we make decisions about the ongoing introduction of new gTLDs.

The Doctrine:

  • Do No Harm.
  • Intervene only when necessary.
  • Think long term.

We need to agree on a final plan of action that addresses the concerns of all involved. The following proposal is not intended to be the final word. It is a starting point that attempts to move the discussion forward.

The ICANN Accredited Registry and TLD Sponsorship Program

The current gTLD roll-out program is defined by three operational models; i) Sponsored/Chartered, ii) Unsponsored/Chartered and iii) Unsponsored/Unchartered. (Theoretically, there is also a Sponsored/Unchartered category as well, but no one has come up with a compelling plan for an operation that fits into that category). As discussed in the previous installment of this article, there are many problems with the selection process that leads to these types of determinations. Principally, the effort that it takes to put bids into these different categories is entirely too subjective.

We need a different way to look at this problem.

There are two parties that are critical to the successful launch and operation of any gTLD—the party that receives the delegation and the party that operates the delegation. Sometimes these are the same entity (as with .COM) and sometimes they are not (as with .ORG). These two parties need a more visible role in the process. Their function needs to be evolved so that it is more meaningful and more sustainable.

For the sake of simplicity, let’s call these two roles “the Delegant” and “the Operator”—and try to avoid confusing them with the existing terms, “TLD Sponsor” and “Registry Operator”. Remember, our goal is to evolve these rudimentary roles, not preserve them.

Each of these roles has a central function in the process—prospective delegants need to apply to ICANN to receive a delegation for a gTLD string that has not been previously delegated by ICANN. Applications by prospective delegants will be dealt with by ICANN on a first-come, first-served basis. Existing applicants should receive similar first-come, first-served priority. Operators are accredited by ICANN. Successful Delegants will contract with, or become, Operators. This pairing forms the basis for the ongoing management of new gTLDs.

The Operator is a technical coordinator that ensures that the gTLD works from day to day. The Operator develops and implements new standards, manages the registration and publication function of the registry and upholds a minimum standard of transactional and technical integrity. Operators must be accredited by ICANN in much the same fashion as registrars are. They must receive their accreditation before they will be allowed to technically manage a gTLD under contract with a Delegant. The criteria for accreditation is simple—it is the sum of minimum standards that it takes to technically operate a registry—database capability, protocol interoperability, zone file publication, capability to escrow and so on. There should be no policy limitations to the number of gTLDs that an Operator can contract with a Delegant to manage.

The Delegant is the policy coordinator for the gTLD that ensures that the registry operates in a manner that benefits its target community. A Delegant should be expected to behave as outlined in RFC 1591 if they wish to be approved to receive a delegation. Delegants will be approved based on simple and straightforward criteria.

1. The desired gTLD string must not be confusingly similar to an existing gTLD string. For example, an application for .C0M (c zero m) should not be approved, nor should .NETWORK. This does not however imply that a TLD must be uniquely distinct within the namespace. The opportunity to operate .PER in competition with .NAME or .BIZ in competition with .COM must not be precluded by any criteria as it represents one of the more compelling reasons why expansion is desirable in the first place—competition at all levels of the DNS is something that we should strive for. gTLDs are no different.

2. The Sponsor must present a balanced and reasonable plan for the operation of the TLD that includes any significant policies that affect the operation of the gTLD. For instance, any limiting charters must be noted up front. This is desirable because it provides the community with important disclosure and allows for community perceptions to be managed from a very early date.

3. The Sponsor must demonstrate that an accredited Operator is willing to manage the technical function of the TLD for a minimum specified period of time.

4. The Sponsor must indicate their willingness to forgo all rights and interest in the specific string as it relates to the use of the string as a TLD. This is especially important as it relates to ICANN’s capability to transition a string to a new Sponsor.

It is not important that there be an identifiable link between the target community for a particular gTLD and the actual gTLD string (i.e. .NAME is for individuals, but .NET is not for network operators). A Sponsor is not accredited so much as they are approved. A Sponsor can seek approval by filing an application to receive a delegation for a string and paying an application fee. The commercial relationship between a Delegant and an Operator are a private matter but the relationship must at least permit redelegation or technical transition in the case of a business failure.

In order for this proposal to be successful, ICANN needs to be willing to accredit as many Operators as is necessary to manage the operations of the Delegants that they approve. ICANN will also need to ensure that the processes and criteria used to accredit the Operators and approve the Delegants be as standardized as possible. Lastly, some consideration of historical precedent needs to be undertaken to ensure that this proposal remains consistent with the practice and goals of the community.

The next and final piece in this series will focus on the relative merits of this plan in comparison to others that have come forward.

—-
This article is reproduced with special permission from Tucows Inc. Copyright 2003, Tucows Inc. All rights reserved. URL. Author expresses special thanks to Bret Fausett, Joanna Becket and Thomas Roessler for their assistance and input.

Creative Commons License
This work is licensed under a CreativeCommons License.

By Ross Rader, Director of Innovation & Research

Filed Under

Comments

Comment Title:

  Notify me of follow-up comments

We encourage you to post comments and engage in discussions that advance this post through relevant opinion, anecdotes, links and data. If you see a comment that you believe is irrelevant or inappropriate, you can report it using the link at the end of each comment. Views expressed in the comments do not represent those of CircleID. For more information on our comment policy, see Codes of Conduct.

CircleID Newsletter The Weekly Wrap

More and more professionals are choosing to publish critical posts on CircleID from all corners of the Internet industry. If you find it hard to keep up daily, consider subscribing to our weekly digest. We will provide you a convenient summary report once a week sent directly to your inbox. It's a quick and easy read.

Related

Topics

Domain Names

Sponsored byVerisign

Cybersecurity

Sponsored byVerisign

IPv4 Markets

Sponsored byIPv4.Global

New TLDs

Sponsored byRadix

DNS

Sponsored byDNIB.com

Brand Protection

Sponsored byCSC

Threat Intelligence

Sponsored byWhoisXML API