Below is a work in progress for the TLDA's Operational Standards and Procedures Manual  (OSP) - the recommended guidelines for maintaining a stable, permanent, and non-colliding Inclusive Name Space.

The sole document at this time we have published is a draft of the LCC-Draft-002. It is nearing the stage of adoption review by the TLDA's Compliance Committee and is posted for public and membership review.

If you have constructive observations or suggestions, please let us know either by posting to the TLDA's Public Discussion Mailing List if you are not a TLDA Member, and if you are a member, the discussion of the draft is taking place on the TLD-WG (TLD Working Group) and the WGCA (Working Group - Constructive Abandonment) Lists.

To Join any list, merely visit the link HERE, and navigate to the list you want to join. You will receive a confirmation of approval from a list moderator or administrator as soon as your request has been approved.

Below is Draft-002 of the OSP's LCC...

Top Level Domain Association

Compliance Committee

Criteria for Determining Legitimate Claims to Top Level Domains

Author: John Palmer
Draft 2009-31-MAY-002

© Copyright 2009 – Top Level Domain Association
All Rights Reserved

1.0 Introduction

The Top Level Domain Association (TLDA) publishes a list of all know TLDs, including colliding versions of those TLDs, when present. The TLDA’s Compliance Committee is charged with determining which instances of any claims to Top-level Domains in the Inclusive Name Space should be marked or otherwise designated as the recommended version of a colliding duplicate TLD string for the purposes of being carried by all of the various and publicly available DNS service providers.

This document contains the criteria used by the Compliance Committee to determine which version of a TLD is to be considered the version recommended by the TLDA as the version that, in the opinion of the TLDA, is the currently legitimate version of a TLD, if any. The criteria are both operational and based on First-Come, first-serve (FCFS), as is the case with registration of Second Level Domains (SLDs) and also incorporates tests for inappropriate behavior on the part of TLD claimants.

2.0 Definition of Terms

The following terms are used throughout this document. These definitions are the operable definitions for the purpose of this document and for the purpose of the work of the Compliance Committee.

Top Level Domain Association (TLDA): The Top Level Domain Association Inc. is a trade association of Internet Top Level Domain (TLD) holders. This organization represents the interests of TLD Holders and fosters cooperation among them to insure a stable, inclusive namespace.

Compliance Committee (TLDACC): The TLDA’s Compliance Committee is charged with determining which instances of any claims to Top-level Domains in the Inclusive Name Space should be marked or otherwise designated as the recommended version of a colliding duplicate TLD string for the purposes of being carried by all of the various and publicly available DNS service providers.

Top Level Domain (TLD): A top-level domain or domain name (TLD), is the last part of an Internet domain name, that is, the group of letters that follow the final dot of a fully qualified domain name. For example, in the domain name www.example.com, the top-level domain is com (or COM , as domain names are not case-sensitive).

TLD Holder/Owner: A TLD holder/owner is the entity (person or organization) that claims a TLD and is responsible for its operation. The reason that we call this entity a “holder/owner” is because there is some question in legal circles as to whether a TLD is property that can be owned, and the TLDA is making no judgment on this question but will leave it up to the lawyers and courts.

TLD Instance: A TLD instance is a version of a TLD, along with information on its owner/holder and operational information, such as a list of authoritative name servers for the TLD instance. The difference between a TLD and TLD instance is the recognition that there could be more than one version of a TLD (in the Taproot – see below). Each version of a TLD is known as a TLD instance.

Collision: A TLD is said to be in a state of collision when more than one instance of a TLD exists. This is unacceptable from the perspective of the DNS as only one instance of a TLD can exist in the name space. One of the jobs of the Compliance Committee is to determine which, if any, of colliding TLD instances is the legitimate claimant, that is, which one the TLD recommends that root server operators use.

Taproot: The Taproot is a list of all known TLD instances. The TLDA collects information about all known TLD instances, colliding TLDs included, and produces the Taproot. The Taproot is NOT an operational root zone, even though it may contain the necessary information to become one because all known versions of all known TLDs will be in the Taproot, including colliding TLDs. As only one version of a TLD can be contained in a root zone file, the Taproot cannot be used as a root zone, by itself

Annotated Taproot (ATAP): The Annotated Taproot is the work product of the TLDACC and consist of a list of all of the recommended TLD instances. The ATAP will have all of the same information about a TLD instance (contact information, name servers, holder/owner information) as is present in the Taproot. The ATAP, however, can be used as the basis for a live root zone file as there are no collisions. The ATAP will be updated on a periodic basis as the TLDACC evaluates new and existing TLD instances and updates its recommendations.

Create on Demand Scheme (COD scheme): A COD scheme is a domain registration method where domain registrants can register a domain in a TLD, even if that TLD does not yet exist. If a registrant registers a domain with a COD registrar and the TLD does not yet exist, the registrar creates the TLD in its name servers “on-the-fly”. This process is not considered legitimate by the TLDA as 1) No one can see the registrants domains as no root server network has the TLD listed (other than perhaps the local servers used by the registrar in questions), 2) Most COD registrars do not check to see if they are creating colliding TLDs and thus infringing on other holder/owner’s existing TLD claims and 3) This process leads to TLD hoarding, which is also not considered legitimate by the TLDA.

TLD Hoarding: Hoarding means any action by a TLD holder/owner to claim more than a reasonable number of TLDs. In the past, several TLD holder/owners made claims on every generic and potentially profitable word in the dictionary for their TLDs, without any infrastructure behind them. The TLDA does not consider TLD hoarding to be acceptable. The TLDA considers any entity that holds/owns more than 24 TLDs to be hoarding. The TLDACC will not recommend any TLD instances held/owned by one entity beyond this number.

The TLDACC may make exceptions to this rule if a holder/owner holds more than this number of TLD instances and if they are all related to some specific theme, for instance, if a holder/owner has TLDs that correspond to all of the birds in North America, or the names of all of the star ships mentioned in the Star Trek movies. The TLDACC can still limit the number of TLD instances it recommends for any one holder/owner, even if they all match a specific theme, if in the TLDACC’s opinion, the number is unreasonable. The TLDACC will set its own criteria for determining what constitutes a “theme” for the purposes of this hoarding definition.

Private TLD Registrations: Private TLD registrations are TLD instances whose owner/holder hides its identity behind a third party, making it impossible for anyone in the public to know who is responsible for the TLD instance. Private TLD registrations are not considered legitimate by the TLDA. TLDs are at a high level in the internet DNS and there are many security concerns that may make it essential to contact the real holder of a TLD without having to go through an intermediate party. Unlike SLDs, TLDs are internet infrastructure components and their holders and operators must be easily contacted.

3.0 Overall Philosophy

The criteria in this document were developed based on several core values that the TLDA considers essential for fair, open and reliable operation of the internet name space. These core principals are as follows:

1. There is ONE Name Space – Collisions are Unacceptable: The TLDA recognizes that there can only be one internet domain name space, regardless of how many roots exist. This means that collisions are absolutely unacceptable. Internet users must be assured that each time they visit a web site or send an e-mail, that the content behind that domain is the same each time. There cannot be two versions of “ABC.COM” or else some users would get one result while others would end up at an entirely different site, depending on their DNS provider. This cannot be allowed. The TLDA offers its assistance to holders of colliding TLD instances in resolving collisions and produces a recommended list of TLD instances from the Taproot (the ATAP) precisely to maintain this consistency in the name space.
   

2. Respect for First-Come, First-Serve (FCFS) Claims: The TLDA believes that an organization that makes the first claim on a TLD, and then backs it up by making a TLD operational in a technically sound and stable manner should be recognized as the organization that has the sole legitimate claim to the TLD in question. This is the classic First-Come, First-Serve (FCFS) scheme that has been the cornerstone of claims in regular domain name registrations since the inception of the DNS. FCFS is NOT to be respected, however, if a claimant is engaging in any unacceptable behavior, such as TLD hoarding, hiding its identity or running a create-on-demand scheme, or any other behaviors that this document prohibits.
   
   This philosophy mimics the venerable practice of the U.S. Government in the early history of the U.S. when it would give homestead grants to people who promised to improve the land. They staked a claim and worked the land, and if they succeeded in improving the land, the government would reward them with ownership rights.
   
   The TLDA believes that entrepreneurs should be rewarded for investing time and money in developing the internet equivalent of a homestead and that the entrepreneur should not have his or her business product stolen by a capricious and arbitrary force that re-assigns it to someone else.
   

3. Stability of Internet Infrastructure MUST be maintained: TLD and Root Server operators are responsible for a big piece of the internet’s infrastructure and must take this duty seriously. Outages of TLD servers, registration systems and root servers cause a great interruption in the operation of the internet. As more and more businesses and public services rely on the internet for their communications, outages will take an increasingly large toll, harming businesses, interrupting public services and slowing down responses in emergencies. All TLD and Root operators must maintain best practices in the operation of their technology infrastructure to maximize availability of these critical resources. It is for this reason that the TLDA requires that TLD operators engage in the current best practices when running their TLD infrastructure, such as following the RFC’s related to DNS operations.
   

These core values inform the Compliance Committee as it determines which version of a TLD from the Taproot (if any) will receive the TLDA’s recommendation.

3.5 General Rules and Principals

This section contains some miscellaneous rules and principals that apply to the TLD evaluation process in general.

It is important to note the level of scrutiny given to data about recommended TLD instances, not only during a determination of what version to recommend, but also after a recommendation is given. Once a TLD instance is recommended, it becomes operational data and changes must be verified as coming from the authority for that TLD instance.

The TLDACC will implement a method of secure and verified communications with the holder/owners of recommended TLD instances, such as the use of signed messages, using registered certificates and other methods. More details about these procedures are in Section 5 of this document.

Operational data, even when verified, must be checked to make sure it is valid. Name server changes must be checked and double-checked before the ATAP is updated.

The most destabilizing changes to the name space is the removal of a TLD instance and replacement with an entirely different version. This is even more destabilizing than a TLD suddenly going dark, because in that case, at least you know it’s not working and get nothing. In the case where one instance of a TLD is replaced with another existing instance of that same TLD, it is possible that the an SLD in the old version also exists in the new version and internet users will still expect the old content to be there, but it won't be. This is especially problematic when the website or resource behind that SLD was sensitive in nature, such as a bank website. The user may, for instance, trust that website to be reputable, but now it is an entirely different website that may or may not be trustworthy and is certainly not the same content as before.

This is the reason that the rules for swaps (i.e. recommending a new version of a TLD or sale/transfer of TLD to a new holder/owner when the new holder/owner will be replacing the content of the TLD instance with a new set of SLDs) are so strict. This is the reason for the 30 day waiting periods and notices given – to make sure people don’t wake up to a surprise. This is also the reason that the re-evaluation process for a dead (or non-compliant) TLD that has been “de-recommended” does not take place for 1 whole year. If the TLDACC allowed a new TLD to slip into place in a month or so after a non-compliant TLD instance was de-recommended, it would provide for too much confusion. Allowing it to lie dormant for a year (after de-recommending it and having no recommended version that will be in root server networks) allows time for 1) the current TLD instance holder/owner to become compliant, but more importantly, so that there is not a sudden change in TLD content as visible from the internet public.

Taproot data itself (other than the recommended instances) does not have to be as highly scrutinized since the Taproot is meant to be a “vacuum cleaner” that sucks up all available data on TLD instances. It is bound to be inaccurate and is designed as a collection of data points only, not necessarily verified. The ATAP, on the other hand is operational data and invalid or erroneous data can cause serious problems with the operation of the internet.

This policy is designed to give all parties involved in the TLDA recommendation process the ability to provide data and to provide proof of the accuracy of that data. We hope that this policy will convince the internet community that the Annotated Taproot is worthy to be used as an operational root zone and that the internet community can finally enjoy all of the TLDs that have been out there for over a decade.

4.0 The Criteria for Assigning Recommended Status for a TLD

The TLDACC is charged with determining which TLD instances receive the TLDA’s recommendation as the legitimate version of a TLD. It is possible that NO version of a particular TLD will be recommended, if none of the versions pass the tests outlined in this document.

There are two different operational eras of the TLDACC: Initial Evaluation and Ongoing Evaluation.

The first era is called Initial Evaluation (IE) This occurs at the beginning of the operation of the TLDACC, before it has made its first recommendation list of all of the TLDs in the Taproot. TLDA members will endeavor to produce as complete a list of all known TLDs as possible and will hand this off to the TLDACC which will make its initial evaluation and recommendation list.

Once this first copy of the recommended list (the Annotated Taproot or ATAP) is produced and published, the TLDACC enters the Ongoing Evaluation era (OE) and is in that era from that point forward.

The reason for this distinction is that some rules apply during IE that do not apply during OE, mainly having to do with re-evaluation of TLDs that have been recommended. During the IE, the TLDACC will publish its initial findings and ask for any objections or comments from the public and more importantly, TLD holders/owners. If objections are heard, the TLDACC may re-evaluate its findings if new information comes to light.

Once, however, the first cut of the ATAP is published, TLD holders, root operators and internet users will start relying on the ATAP for an operational map of the name space. Any changes that remove a recommended TLD instance, or that replaces one version of a TLD with another one from the Taproot will cause consistency problems and can only be made with extreme caution and only for a real good reason. For this reason, rules on removal or replacement of TLD instances during the OE are very strict and greatly limit the instances of this kind of event occurring.

4.1 Rules for Evaluating TLD Instances during the Initial Evaluation

4.1.1 The TLDACC will publish this document for the public and will attempt to deliver a copy to each and every TLD holder/owner mentioned in the Taproot along with a message that the TLDACC will be entering its Initial Evaluation phase. This communication will stress the importance that each TLD instance be compliant with all of the policies in this document, especially the operational ones (i.e. name servers RFC compliant, etc) by the time that the TLDACC begins its Initial Evaluation. Of particular importance is the need to stress how difficult it will be after the Initial Evaluation to reverse a decision on which TLD instances are recommended.

4.1.2 Not less than 30 calendar days after the communication mentioned in 4.1.1 is sent to each and every TLD holder/owner mentioned in the Taproot, the TLDACC will begin its evaluation of the TLDs in the Taproot as follows:

4.1.2.1 An alphabetical list of each and every TLD listed in the Taproot will be made. For each TLD represented in this list, a list of each instance of said TLD will be made, in order of claim, from oldest to newest claim. Each TLD instance will undergo the following tests in sections 4.1.2.2 through 4.1.2.5

4.1.2.2 The TLD holder/owner contact information will be checked and verified. TLDACC staff will contact the TLD holder/owner at each of the listed phone number(s), postal addresses and e-mail addresses. If any of this contact information turns out to be inaccurate, Staff will attempt to contact the TLD holder/owner via other methods and to obtain up-to-date contact information, making any changes to the Taproot, once the new information is verified. If the ANY piece of contact information cannot be verified, the TLD instance is removed from consideration as a recommended TLD instance. Any TLD instance that is hidden behind a “private registration” will also be removed from consideration as a recommended TLD instance. The minimum contact information that must be maintained in an accurate form is:

1. Name of Holding/Owning Entity

2. Type of Entity (corporation, individual)

3. Full Name of contact person (First and Last)

4. Full Postal address

5. Working E-Mail address of contact person

6. Working URL of the TLD’s information page

4.1.2.3 Each TLD instance must have at least 2 separate name servers running that answer authoritatively for the TLD instance in question. These name servers must be on separate IP subnets and in at least two different geographical locations (i.e. not in the same facility). TLDACC technical staff will perform the necessary tests and analysis to determine compliance with this section and will report back to the TLDACC. Holder/owners of TLD instances that are not in compliance with the name server requirements in this section will be contacted and informed that they are not compliant and will be sent a list of deficiencies. Any TLD instances remaining non-compliant will be removed from consideration as a recommended TLD.

4.1.2.4 A determination will be made to determine if the TLD holder/owner operates a “Create-On-Demand” scheme. If it is determined that this is the case, ALL of this TLD holder/owner’s TLDs are excluded from consideration as recommended TLD instances.

4.1.2.5 Each and every TLD instance must have a web page available to the public that identifies the TLD holder/owner, provides contact information and provides some description as to the purpose of the TLD. If the TLD is open to paid public registration, the registration page MUST provide a proper disclaimer to potential registrants regarding the limited visibility of Inclusive Namespace domains and that NOT ALL INTERNET USERS will be able to access these domains by default. TLDACC staff will perform an analysis of the public web page for the TLD and will report back to the TLDACC. The holder/owner of any TLD instance that is not compliant with this section will be notified of the deficiencies and will be sent a list of deficiencies. Any TLD instance remaining in non-compliance with this section will be removed from consideration as a recommended TLD.

4.1.2.6 Once the analysis of each TLD instance is completed as outlined above, the TLDACC will publish its preliminary findings and will list any outstanding requests for information from TLD holder/owners as specified in sections 4.1.2.2 – 4.1.2.5.

Any holder/owner that has more than the maximum number of TLD instances allowed on the recommended list, as defined in the definition of “TLD Hoarding” and that, in the opinion of the TLDACC does not fit the “theme exception” (as defined in the definition of “TLD Hoarding”) will be notified of this fact and will be asked to choose which TLDs that the holder/owner wishes to remove from consideration, so as to be in compliance with the Hoarding prohibition.

A 30 day waiting period will begin which will allow any TLD holder/owners to respond to requests for information and non-compliance notices sent by the TLDACC. If any information comes in during this 30 day period, or if a TLD instances have its deficiencies cured, the TLDACC will update its findings and publish the new findings.

4.1.3 Once the 30 day waiting period passes, the TLD instances that pass all of the requirements are added to the recommended list. If there is more than one version of a colliding TLD that passes all of the tests, the one with the OLDEST CLAIM is selected as the recommended version. If a holder/owner would have too many TLD instances on the recommended list, and did not respond to the request made by the TLDACC to choose which TLD instances to remove (as outlined in section 4.1.2.6, paragraph 2), the TLDACC will remove from consideration the number of TLD instances held by this holder/owner in excess of the allowed number by ordering all of the holder/owner’s recommended TLD instances by order of date of claim and then by alphabetical order and will exclude the TLD instances at the end of the list in order to bring the holder/owner in compliance with the limit outlined in the definition of “TLD Hoarding”.

4.1.4 The TLDACC will publish a Draft Initial Annotated Taproot (ATAP) as well as an updated Taproot version with the proposed recommendations applied. A 30 day comment and appeal period will commence during which any interested party can provide information to the TLDACC regarding the findings. TLD holder/owners may file appeals of decisions with the TLDACC . Appeals must address only issues listed in these rules and may provide information as to why the decision of the TLDACC did not follow these rules. There are no grounds for appeal for reasons beyond the rules outlined in this document. Note that any TLD instance that was not compliant with the provisions 4.1.2.2 – 4.1.2.5 may no longer qualify by becoming compliant at this point. That opportunity ended when the 30 day waiting period described in 4.1.3 ended. Appeals may only address that facts as they existed prior to the end of the 4.1.3 waiting period.

4.1.5 The TLDACC will dispose of any appeals as soon as possible . TLD holders/owners may appeal the decision of the TLDACC made during the appeals process to the TLDA Board within 10 days of the TLDACC rendering its appeal decision and the TLDA Board will decide the matter. The TLDA Board’s decision is final.

4.1.6 Once all appeals have been decided, both by the TLDACC and any Board Appeals, the TLDACC will publish the final version of the Initial Annotated Taproot (ATAP) with all of its recommended TLD instances and will make a new version of the Taproot with the final recommendations included. After this publication, the TLDACC will enter the Ongoing Evaluation (OE) era of operation.

4.2 Rules for Evaluating TLD Instances during the Ongoing Evaluation

Once the initial ATAP is published, the TLDACC enters the Ongoing Evaluation (OE) era. Some of the evaluation criteria are different, specifically for cases when a recommended version of a TLD becomes non-compliant.

After publication of the initial ATAP, internet users and root operators will start using the ATAP as an operational root. They will come to rely on it as a stable map of the internet name space. Making changes to this map cannot be done lightly, especially when removing a TLD instance or, even worse, when swapping one version of a TLD for another one. Because of this, the following rules apply to maintaining the ATAP during the OE era of operation:

4.2.1.1 Once the initial ATAP is published and the TLDACC is in the OE era of operation, NO changes can be made to the recommended list based on any information that was not provided or known to the TLDACC during the IE era regarding date of original claim. This means that if someone did not make a claim on a TLD during the IE era and they now attempt to make a claim, even if the date of their original claim turns out to be older than the recommended version, the claim will be denied. Note that new information about a new claim can and must be entered in the Taproot, but will not affect the current recommendations.

4.2.1.2 If a new TLD instance is created and claimed and no version of that TLD is in the current ATAP, then the new TLD instance will be added to the recommended list PROVIDED complies with the criteria of sections 4.1.2.2 – 4.1.2.5 of this document and the holder/owner does not already have the maximum number of TLDs allowed on the recommended list per the Hoarding definition.

4.2.1.3 If ALL of the authoritative name servers for a recommended TLD instance become unreachable from the public internet, the TLDACC will attempt to contact the TLD holder/owner to demand a remedy to the situation. If no name servers come back online within 24 hours of said notice being delivered or if the TLD holder/owner cannot be contacted, the TLDACC will immediately remove the recommendation of the TLDA instance from the ATAP and the Taproot and will publish a new versions of these documents with a URGENT notice to all interested parties, identifying the problem. If the TLD holder/owner later remedies the situation, the TLDACC will restore the recommended status and republish the ATAP and Taproot.

4.2.1.4 If the TLD instance becomes non-compliant with sections 4.1.2.2 (Contact information component no longer valid), section 4.1.2.3 (Name servers not on at least two separate subnets, geographically separated, at least two name servers running – excluding “all name servers down” as described in 4.1.2.3), section 4.2.1.4 (TLD instance now held/owned by the operator of a “create-on-demand” scheme), section 4.2.1.5 (Info web page must be publically accessible, proper disclosures), the TLD holder/owner will be notified of the deficiency and will be given 24 hours to remedy the situation. If the deficiency is not cured, the TLDACC will publish a new version of the ATAP and Taproot with a WARNING next to the TLD instance in question notifying the internet community that the TLD instance is no longer in compliance with the rules.

4.2.1.5 If the TLD instance still remains non-compliant as described in section 4.2.1.4 for 30 calendar days from the date of the notice, the TLDACC will publish an URGENT notice to the public that the TLD instance in question will lose its recommended status in 10 calendar days. After 10 calendar days, if the deficiency is still not cured, the TLDACC will remove the recommended status for the TLD instance from both the Taproot and ATAP and will enter a notation in both to the effect “Was a recommended version – became non-compliant on <DATE> for reason <REASON>”.

4.2.1.6 If the TLD instance becomes compliant again at some point, and if a different version has not yet been recommended (see below), the TLDACC will restore its recommendation and will publish new versions of the ATAP and Taproot with the recommendation restored.

4.2.1.7 Any TLD instance that becomes non-compliant (as outlined in sections 4.2.1.3 through 4.2.16) and gets its recommendation revoked 5 times will not have its recommendation restored.

4.2.1.8 If a TLD instance becomes non-compliant and has its recommended status revoked as outlined in sections 4.2.1.3 through 4.2.1.6 and does not cure its deficiencies within 1 YEAR of having its recommended status revoked, or has had its right to re-claim recommended status revoked as outlined in section 4.2.1.7, loses its right to reclaim that status. At that point, the TLD is available for claim by some other entity. The procedures of 4.1.2.2 through 4.1.2.5 will apply with all other versions of the TLD in question eligible for claim under the rules of section 4.1.2.2 – 4.1.2.5. The procedure for this re-assignment of claim will proceed as outlined below.

4.2.1.9 Once a TLD instance has lost its right to reclaim recommended status as described in section 4.2.1.8, the TLDACC will publish a notice stating this fact and will notify any and all holders/owners of any other instance of the TLD in question as listed in the Taproot and will notify them of this fact.

4.2.1.10 A 30 day waiting period will commence, during which any new claims for the TLD in question will be accepted and entered in the Taproot. During this time, potential claimants must make their TLD instances compliant with all applicable rules in this document.

4.2.1.11 Once the 30 day waiting period has passed, the TLDACC and staff will list all of the claims for the TLD in question in order of date of claim and will carry out the process outlined in 4.2.1.2 – 4.2.1.5 and will determine the new recommended version, if any. The TLDACC will update the ATAP and the Taproot and will publish a new version with the updated recommendation.

4.2.1.12 If a TLD holder/owner of a recommended TLD instance sells or otherwise transfers rights to a TLD instance to another holder/owner, the TLDACC and staff will verify the transfer by requiring appropriate and verified (notarized, etc) documents. Once verified, the transfer will take place in the records of the ATAP and Taproot in a manner which depends on whether or not the new owner is taking over the TLD instance and will retain the current base of domains within it or if the new holder/owner is wiping out the old list of domains and replacing it or starting clean.

4.2.1.13 If the new holder/owner of a recommended version of a TLD instance as outlined in section 4.2.1.12 is keeping the current TLD instance intact, with all of the current domains (SLDs), then upon verification of the ownership/holder transfer, the TLDACC will update the ATAP and Taproot with the new owner information and operational data (name servers) and will publish new versions of the ATAP and Taproot.

4.2.1.14 If the new owner of a recommended version of a TLD instance as outlined in section 4.2.1.12 is NOT keeping the current base of domains and is starting clean or replacing it with a different set of SLDs, then upon verification of the ownership/holder transfer, the TLDACC will publish a notice to the internet community that this change will be taking place. A 30 day waiting period will commence in order to give ample opportunity for all interested parties to be notified. After the 30 day waiting period is completed, the TLDACC will update the ATAP and Taproot with the appropriate changes to the contact and operation information for the TLD instance in question and will publish a new version of the ATAP and Taproot.

4.2.1.15 Upon notification by the holder/owner of a recommended TLD instance that there are any changes to the authoritative name servers for a TLD instance, the TLDACC technical staff verify that the new name servers are properly configured and answering authoritatively for the TLD in question and that the new name server configuration is such that at there are at least two name servers on at least 2 IP subnets and in at least two different geographical locations. Upon being notified of the compliance of the new name servers for the recommended TLD instance, the TLDACC will update the ATAP and Taproot with this information and will publish new versions of both documents. Any other changes to contact information and such by the holder/owner of a recommended TLD instance will be similarly scrutinized any updated in both the ATAP and Taproot.

4.2.1.16 There are no appeals of the TLDACC decisions in the Ongoing Evaluation era unless the appeal request gets the backing of at least one member of the TLDA Board of Directors.

5.0 Case Management and Historical Record-Keeping

It is essential for the TLDACC to keep accurate records of not only on-going deliberations, but also an historical record of past decisions.

It is for this reason that the TLDACC will develop a publically available database that will track all decisions regarding the process of deciding which TLD instances to recommend.

In this database, each TLD instance will be assigned a unique identifier which will consist of the TLD string and an integer which represents the order in which it was claimed. For instance, if there are three instances of TLD “ABC”, then they would be identified as “ABC-1”, “ABC-2” and “ABC-3” with instance ABC-1 having the earliest claim date, ABC-2 having the next claim date and finally ABC-3 having the newest claim date.

During the OE era, each TLD instance discovered in the initial Taproot will be assigned a TLD instance number.

Each time a request is made to the TLDACC for some sort of ruling (new TLD created, TLD instance sold, etc), a unique case is created with a case number. This case number is linked to the TLD instance in question via the TLD instance ID. The case data includes, in time order, all correspondence from related parties regarding the case, all responses by the TLDACC and staff, and all decisions made by the TLDACC. Case numbers are of the form YYYY-XXXXXXX where YYYY is the year in which the claim is made and XXXXXX is a sequence number, with “1” being the first claim of year YYYY.

A case is opened and a case number assigned when someone files a request with the TLDACC for some sort of action (TLD instance sale, new TLD created, etc) and a case is considered closed when the final decision on all open questions raised by the case are handed down.

During the OE era, a case will be opened for each and every TLD instance in the Taproot and all decisions about that TLD instance will be recorded in the records for that case. These OE era cases will all be closed en-masse when the OE era is concluded, as defined in section 4.1.16.

The online database will contain all cases handled by the TLDACC. It will also contain a list of all TLD instances along with all decisions and cases related to that TLD instance, in time order.

Finally, both the Taproot and ATAP must be versioned. This means that each version must have a unique serial number, namely the date and a sequence number assigned to them. Each version of each of these documents must also have text indicating what has changed since the last version. This should include the Case numbers of any related cases, whose resolution changed data in the document as well as what specific changes were made.

Sufficient search capabilities will be made available via the public interface to this database to allow the public to easily find any information about the TLD instances and cases.

As mentioned in Section 3.5, a secure and verifiable means of identifying TLD instance holder/owners must be created. Once a TLD holder/owner is identified, the TLDACC must have means of secure communications with that entity. This means that there must be means to allow the TLDACC and staff to verify that it is talking to the legitimate holder/owner and not an imposter and the holder/owner must also be assured that communications purporting to be from the TLDACC are indeed from the TLDACC.

The TLDACC will implement all means to effect this secure, verified communications channel, including the use of certificates and any other acceptable means. 

---

Add this page to your favorite Social Bookmarking websites