[E] Description of TLD Policies

[INSTRUCTION: For sponsored TLDs, this part of the application is to be completed by the sponsoring organization. For unsponsored TLDs, the registry operator should complete this part of the application. Please refer to the Detailed Application Instructions for more information on the requirements for new TLD applications.

The operation of a TLD involves the implementation of policies on a very large number of topics. Applicants are urged to use their response to this part of the application to demonstrate their detailed knowledge of what topics are involved and their careful analysis and clear articulation of the policies they propose on these topics.

Please place the legend "CONFIDENTIAL" on any part of your description that you have listed in item F3.1 of your Statement of Requested Confidential Treatment of Materials Submitted.

Section III of this application applies only to applicants for restricted TLDs. Ordinarily, restricted TLDs should be sponsored.]

[E] I. GENERAL TLD POLICIES

(Required for all TLDs. Note that two special policy areas--policies during the start-up period and restrictions on who may register within the TLD and for what purpose--are covered in sections II and III below.)

E1. In General.

Please provide a full and detailed description of all policies to be followed in the TLD (other than those covered in response to items E11-E21). If the TLD's policy on a particular topic is proposed to be identical to that reflected by a particular version of any of the following documents, it is sufficient for your response to identify the topic, to give a brief summary of the policy, and for the details to reference the document and section:

ICANN Registrar Accreditation Agreement

NSI Registrar License and Agreement

ICANN-NSI Registry Agreement

Uniform Dispute Resolution Policy

Your response should comprehensively describe policies on all topics to be followed in connection with the proposed TLD. The following items (E2-E10) are examples only and should not limit your description.

Context of this proposal

Development of the Restricted TLD Concept of .nom

Originally, .nom was expected to be a generic TLD in that no formal restrictions would apply to it. The redesign of .nom as a restricted personal TLD is based on feedback received over the last three years from a variety of sources and CORE's own experience as a gTLD registrar, and member's experience with other TLDs. Over that period, it became clear that a personal TLD should not be treated like an open and generic TLD and that a set of rules should ensure individual use and at the same time enhance the utility of the domains for individuals.

Policy elements not specific to .nom

Some of the policies and methods described here (such as the management of the initial registrations) can be advantageous for generic top-level domains as well. Whenever possible, this proposal avoids introducing new concepts if the current widely used methods do not cause problems, irrespective of the TLD. Moreover, CORE and its members have worked extensively on new TLD issues. CORE renounces proposing a gTLD in this Application in order to maximize the chances of the joint Application of gTLD registrars (registrar consortium).

Format

For easier analysis we have maintained the format of the ICANN form heading and organized specific items under the General heading. The numbered headings starting with E reflect those of the ICANN form.

Policy objectives

Low-cost, Long-Term Personal Identifier

Restricted for Use as Personal Domain

The .nom TLD is chartered for registrations by individuals only. It is designed to

- facilitate the use of memorable personal Internet addresses to as many people as possible for the lowest possible cost;

- allow registrants as much freedom as possible in selecting the names they wish to use

- give priority as much as possible to a person's rights over her or his own name

- offer ways to avoid or resolve conflicts between individuals and other individuals, or between individuals and organizations, who share a legitimate interest in a given name.

Declaration of nature of name

Registrants will be asked to identify when applying for a domain name the nature of the name and how they intend to register it, such as:

- personal name

- abbreviated personal name

- variation on personal name

- nickname

- fantasy name

- other (please specify) (we allow other as in different cultures different personal "identificators" may be possible including family, clans, etc.)

Even if the normal expectations are one name per user, nothing in the policy excludes multiple registrations for users. The reason is that many people use variations of their names, nicknames, nom de guerre, etc. and there is no legitimate reason to exclude them.

For instance, the same person could have a legitimate interest in having both michael.jordan.nom and air.jordan.nom. (All the examples used in this document are only for the sake of clarity for the reader and do not intend to represent that the results of the examples would be the same in the reality).

Expected non-commercial purpose

Domain holders may not use the domain to sell or advertise products. However, it is acceptable to advertise personal capabilities.

Low-Cost Registration and Enforcement

The chartered objectives of the .nom TLD are reflected in the enforcement mechanisms. In order to satisfy one of the key objectives - namely the low-cost availability of personal names, the registration and enforcement mechanisms are designed to *globally* and *as fairly as possible* minimize cost to the parties involved.

Enforcement mechanisms are therefore partly put in place before registration, and partly after the domain is activated.

Computer-verifiable criteria used for pre-screening

All criteria applied before registration are computer-verifiable. At the time of registering the domain, the user contractually agrees to terms that, in case of infringement can lead to the temporary suspension, deletion or transfer of a domain.

Computer verifiable criteria relates to the format of data provided, i.e. the matching of certain common forms of name, address, etc. For instance, a personal name must be specified based on a series of formats compatible with different cultures.

Post-screening based on computer-readable data

Computerized pre-screening limits accidental violations of the policy, but does not prevent the user from deliberately entering false information. However, thanks to the format-based pre-screening, false information is easier to recognize and possibly detect by plausibility algorithms.

Complaint-based self-policing

The post-registration enforcement is complaint-based.

If the non-compliance with certain clauses of the registration agreement can be easily verified based on electronically recorded or published data, the maintaining registrar must verify the data. Examples of such cases are false registrations evident to a person who understands the respective language or culture.

If a complaint concerns clauses that cannot be verified based on the data stored, the domain holder is contacted through an automated email procedure initiated by the registry. The follow-up on this procedure is the responsibility of the maintaining registrar.

If the complaint cannot be resolved, the complainant can initiate an administrative proceeding based on the model of the UDRP framework currently used for .com, .net and .org.

Long-Term Use

A personal domain should be able to accompany a user over many years, unaffected by a change of employer, a change of service provider or a change of domicile or citizenship.

Unless there are pre-eminent overriding concerns, the domain holder alone should decide if a change of name (e.g. because of a change in marital status, use of an artist's name or use of a nickname) affects her or his continued ability to use the name.

Long-term use also has contractual and economic implications: The contractual framework is designed to ensure that the domain remains with the registered holder irrespective of who made the payment and it must provide methods of verification.

The cost should be low enough to allow any individual to register a domain over many years. Moreover, the cost, the contractual framework and the registration process allow groups of people to make joint individual registrations. An example of joint individual registrations is providing each graduate of a school with a long-term personal address that the alumni will be able to use and remember in the future.

E2. TLD String.

Please identify the TLD string(s) you are proposing. For format requirements for TLD strings, see the answer to FAQ #5.

This policy description applies to the .nom TLD string. It can be extended to other strings and in case there are pre-eminent reasons to change the TLD string that relates to personal use, CORE is ready to modify it.

In particular, if there are widely expressed concerns about the similarity of .nom with .com despite the other substantial differences in appearance mandated through this policy, then CORE would consider changing the string.

Nevertheless CORE has adhered to the policy of using three letters string for gTLD, and therefore has not considered .name or .person. We have neither retained .per as it corresponds to the three letter code for Peru in the ISO lists and should be reserved for possible future use in the ccTLD name space.

E3. Naming conventions.

Describe the naming conventions and structure within the TLD. E.g., will registrants have names registered at the second level (directly under the TLD, as in registered-name.com), or will the TLD be organized with sub-domains so that registered domain names are created at a lower level (as in registered-name.travel.com)?

Two-Dot Policy

The domains are registered on the third level but the second level is created automatically if it does not exist yet. For instance, a user can register John.Smith.nom irrespective of whether the second-level label "smith" is already in the database or not. If both labels are new, then third level label "john" would be created at the same time as the second-level label "smith". If the second-level label existed already, only a record with the third-level label is created.

These examples assume first name.last name.nom structure. Many languages use the reverse one, so for instance, Hungarians could either choose to register, vela.valassa.nom or, more accordingly with their culture, valassa.vela.nom.

What it is important is that in either case, as explained below, the second level is shared among all possible interested users, and third level is exclusively delegated to the individual registrant.

The second level is mandatory shared, and therefore nobody can be only registered at that level. For instance, suharto.nom is not possible, although myself.suharto.nom or doctor.suharto.nom would be.

Not need for two dots. No repetition of identical third-level domain

Once a name is delegated to the third level, no fourth or higher-level name with identical lower levels will be delegated. As additions of sub-domains are generally understood to be made under the responsibility of the domain holder, there could be confusion if two different people had j.smith.nom and f.j.smith.nom.

This is the initial policy. Indeed other alternatives have been considered and could be implemented in the future.

Prohibition of certain potentially confusing third-level labels

To avoid confusion, the use of ubiquitous protocol names such as www, ftp, gopher or ldap is not allowed as a third-level label. For instance, it is possible to register john.www.nom but not www.john.nom.

Minimum length labels policy

The second-level label must be at least two letters long. It is thus possible to register Wong.Li.nom but not Marquise.of.O.nom.

From a personal name perspective this is perfectly arbitrary, but many parties have raised concerns about one letter or two letters registrations at the second level. If the community later agrees that non-exclusive one or two letters registrations at the second level causes no problem whatsoever, the policy will be accordingly relaxed.

International names

Multilingual domains.

CORE is perfectly aware of the wide variety of character sets used around the world. Nevertheless, the ITF has not yet agreed on a multilingual DNS protocol. The different experiments in place, while valuable and even encouraged by CORE all bear at the current stage the risks of partial isolation caused by different parts of the Internet adhering to different multilingual protocols.

Therefore .nom will initially work on the basis of current ITF-US-ASCISS based protocols. We will vigorously work with the ITF relevant working group, the IAB and ICANN staff to make sure that multilingual protocols are a reality as soon as possible.

Discussion of two-dot policy

Common names

This policy is intended to serve as a barrier against speculative registrations of common first and last names. It is not possible to simply register john.nom or smith.nom. At the same time, it enables more people to register their own names than just one lucky person among a very large number of namesakes.

Cybersquatting

The dots policy also radically reduces the Cybersquatting potential. This is particularly important in the case of .nom because it rhymes with .com. It is more difficult to confuse the public with a name like john.macdonald.nom than with macdonald.nom.

Reference value of dotted sub-strings

For computer-based analysis prior to setting a new policy, the sub-strings implicit in labels provide useful information. It is easy to verify if a string is often used or not.

Quantitative exclusion effect of two dots policy

The quantitative effect of the exclusion is limited. Whether or not naming rules are applied, most registrants will have no other choice but to use combined names.

Discussion of commercial use issue

Although .nom is intended for personal use, it does not explicitly forbids commercial use. For one thing, defining commercial in this content could be very difficult. Some perfectly legitimate personal use may have attached some "commercial" implications. For instance, someone puts in its personal page an extensive curriculum vitae listing all her activities and achievements. It may happen that her commercial services are retained because of such information. Moreover, commercial use only is relevant in case of conflict. In this regard, .nom policy objectives are clear. The existence of an identical or confusingly similar trademark does not prevent registration under the combined second and third level, but someone using as a second level a string that is identical or confusingly similar to a trademark should refrain from using the domain in any commercial way that could infringe the legitimate rights of the trademark holder.

For instance, marialuisa.osuna.nom holder could probably have marginal non-central related-commercial use of the domain, except anything related with any real estate activity including the advertisement of the sale of her own flat. This is simply because there is a relative famous real estate company with the same name in the same jurisdiction where she lives.

On the contrary, john.mcdonald.nom should refrain from any commercial use, even marginal or occasional as his name bears clear resemblance with McDonalds, a world wide famous trademark.

Furthermore, commercial use meaning can vary from one jurisdiction to another jurisdiction.

Possible relaxation in medium term

It is important to point out that this policy can be relaxed in the medium term. The relaxation would of course only allow single dot registrations where the second-level label has not being used yet.

Initial non-transfer policy

".Nom" TLD is intended for personal use. It is a TLD where people can register their own names, variations of their names, nicknames, nom de guerre, family names, and so forth. On these premises, it would seem odd to allow unrestricted transfer (i.e. selling) of such domain names: why should Mr. Donald Duck buy mickey.mouse.nom, and why should Mr. Mickey Mouse sell it to Mr. Donald Duck?

This would probably not lead to a real problem in most cases, but it also implies a violation of the charter. Also, taking also into consideration that reselling domains is the primary goal of those performing massive registrations (Cybersquatting or domain warehousing) a policy limiting or preventing transfers would certainly make such behavior marginal. However, there is always a "but". There are many circumstances in which a domain name transfer appears to be perfectly legitimate, which shows that a long term simple "non transfer" policy would be harmful.

There are instances in which people change names for legal or cultural reasons e.g. marriage. There is also the fact that some personal names should be transmittable within the family circle (even as part of heritage) or for other reasons, and many others that have been pointed out.

Despite our consultations with many parties we have not found at this stage a policy that is able to discriminate and regulate the "legitimate" transfers from those that would mean a clear violation of the TLD charter (and that could foster Cybersquatting).

In our modest approach, there is an initial non- transfer policy. In consultations that will start immediately with the proposed Advisory Council (and with the public in general) we will study how to establish the procedures and the limited cases in which transfers could be acceptable. This limited revision in no case will be introduced during the first six months of operation of the TLD.

In the long term, it is possible that the community, the intellectual property interests and the ICANN processes will establish, if they prefer "free" transfer policy. In our approach, this could always be done, but the other way round, that is, moving from an unrestricted transfer policy to a restricted or non-transfer policy would be nearly impossible.

E4. Registrars.

Describe in detail the policies for selection of, and competition among, registrars. Will domain-name holders deal through registrars, directly with the registry operator, or some combination of the two? What are the respective roles, functions, and responsibilities for the registry operator and registrars? If registrars are to be employed, how and by whom will they be selected or accredited? If the number of registrars will be restricted, what number of registrars will be selected? Have the qualifying registrars already been selected? On what basis will selections among those seeking to be registrars be made, and who will make them? If registrars are to be used, what mechanisms will be used to ensure that TLD policies are implemented?

Registry-Registrar Model

The underlying concept of the registry registrar model is also explained in the Registry Operator's Proposal under D13.2 and D15.2.2. For the purposes of the registration policy, the following aspects differentiate the CORE registrar model from the current registrar model used under .com, .net and .org:

-All essential data is managed in the registry by the registrars

-The registry routinely runs the components of verification and enforcement procedures that are best run centrally for reasons of trust, reliability and cost.

Registrar selection criteria

In order to register in .nom, the registrar must be a member in good standing of the CORE-II or its successor organization.

Initial criteria for CORE-II membership are explained in the response to question C3 of the Sponsoring Organization Proposal. There is no numeric limitation to the number of registrars.

Members must sign and accept the obligations derived from the .nom policy. (e.g. sign policy document). Examples of the obligations of the registrar are: required documentation, required computer basis verifications, udrp and future development of the policies. The registry would have the authority to sanction registrars which show a consistent pattern of policy violations.

Roles of registrars

The role of registrars will be to collect the registration data, enter the data into the registry and provide all modification and maintenance services. All of this, is on a competitive basis in which registrars are fully in charge of price and commercial policies, and the registry is limited to the provision of technical, security and escrow services to the system.

E5. Intellectual Property Provisions.

Describe the policies for protection of intellectual property. Your response should address at least the following questions, as appropriate to the TLD:

There are some mechanisms within the policy, already described in E3 above, such as the two-dot policy or the non-transfer policy that substantially decrease the risk of infringement beforehand.

E5.1. Measures against IP infringements

What measures will be taken to discourage registration of domain names that infringe intellectual property rights?

Registration requirements

In order to register a .nom domain name, the following registration requirements should be met:

-Only individuals can register a .nom domain name

-Prepayment of all registration fees (note that fee is interpreted in terms of the registry)

-Provision of accurate contact information.

- Full compliance with required fields and formats of the registration form.

Representations made by registrant in registration agreement

The registrant has to make the following representations in the registration agreement:

The registrant believes that to the best of his/her knowledge

a) registrant has a legitimate interest to register the domain name (does not exclude ipso facto fantasy names).

b) does not infringe on a third party's rights

c) registration and use of domain name does not violate any applicable law or regulation

d) domain name will be used for personal purposes. (The registration agreement will clarify that this does not exclude commercial use but that commercial use will be a key argument in case of conflict with a third party. Moreover it will clarify that if the domain name is identical or confusingly similar to a trademark, commercial use may not be allowed.)

e) registrant accepts dispute resolution policy and jurisdiction of the courts of his/her place of residence as shown in the registration agreement and that of the registrar.

E5.2. Pre-Screening for potential IP infringements

If you are proposing pre-screening for potentially infringing registrations, how will the pre-screening be performed?

It is impossible to pre-screen individual's identities or nick names or the legitimacy of fantasy names at any cost remotely compatible with the purpose of a personal TDL.

Example: It would be difficult and impractical for Norma Jean Baker to prove that she is Marilyn Monroe.

It is therefore not expected that the registrars or the registry will perform pre-screening. This, of course, does not exclude useful advice given by registrars to customer in this matter so as to avoid conflicts.

E5.3. Measures against abusive registrations

What registration practices will be employed to minimize abusive registrations?

Inherent properties of .nom against abusive registration

Cybersquatting.

Two-dots registration and restricted transfer concept means that no .nom large-scale secondary market will emerge.

Piracy

Modified UDRP will be applied as explained in E6.1 below.

See also the explanation of the exclusion mechanism with respect to famous trademarks (E5.5 below).

E5.4. Compliance with existing IP legislation

What measures do you propose to comply with applicable trademark and anti-cybersquatting legislation?

CORE Registry will fully comply, and require its registrars to fully comply, with applicable trademark and anti-cybersquatting legislation.

E5.5. Famous Trademarks Special Protections

Are you proposing any special protections (other than during the start-up period) for famous trademarks?

There are two proposed ways to protect trademarks:

- Ex ante, through an exclusion list that will be working before delegation.

- Ex post, through a .nom adapted UDRP.

Proposed solution

Registration of exclusion requests

An exclusion list will be created through a registration process similar to actual domain registration, performed by registrars of CORE and published through "whois" with a clear legend, and if applicable, pointers to legal information. Registrars' are required to reasonably identify the exclusion string applicant so as to ensure no frivolous requests are presented by third parties.

Famous trademark holders can apply for single-label exclusion or for dual-label exclusion.

Examples of dual-label exclusion requests are mickey.mouse.nom or calvin.klein.nom. They do not exclude, for instance, mickey.johnson.nom or donald.klein.nom or calvin.mouse.nom.

Examples of single-label exclusion requests are ibm.nom and att.nom. They apply to any domain that would use that string as a second level.

As the registrations under .nom are composed of two labels, the combination of the two labels counts as an exclusion on second-level as well.

The request of exclusion string indicates the name of an ICANN-accredited dispute resolution provider entrusted with the handling of potential challenges.

Trademark holders applying for an exclusion string agrees to hold CORE-II and registrar harmless and agrees to pay, in case of challenge, the dispute resolution service provider fee as described under challenges (below). The failure to do so could lead to the deletion of the exclusion request.

Given the cost of services run by the registry for the exclusion request, there is a substantial overhead and the design of special purpose tools and databases for a relatively small number of requests. The cost-recovery fee per registration of an exclusion string at registry level could be in excess of USD 100 per string. This does not include the work of registrars whose fees are subject to competition on price and service level.

It must be noted that in addition to the out-of-pocket costs in requesting an exclusion string, the applicant must take into account the potential dispute resolution service provider fees in case of challenges by third parties.

Challenges to exclusion request

A third party can challenge an exclusion request on the basis of legitimate rights to use a name to which the exclusion applies. For instance, if an exclusion request for macintosh.nom has been lodged in the registry, a third party can challenge the implicit exclusion of michael.macintosh.nom by going through an accredited dispute-resolution service provider. The fee for the dispute-resolution service (which includes the arbitrator fee) has to be paid by the trade owner requesting the exclusion.

We expect a quick education process telling trademark holders that they can not exclude second level domains when they are family names. For instance, michael.macintosh.nom is a perfectly legitimate domain under the .nom policy, and will most probably win the challenge request, unless Mr. Macintosh is intending to use the domain for purposes which may conflict with the trademark Macintosh.

Consolidation of challenges to exclusion requests

As soon as a challenge to an exclusion request has been recorded by the registry, this fact is published on the appropriate web site run by registry with pointers to the relevant dispute resolution provider web page(s). All challenges received within the following three months will be consolidated in a single dispute case. In order to avoid abusive or frivolous repetitive challenges, the requesting trademark holder is only obliged to pay for one (consolidated) case per year at most, as the cost of such dispute will be substantial.

Anyone not willing to participate in a consolidated case or wishing to challenge the exclusion request outside of the allowed time window must pay the dispute resolution provider fee. (The dispute resolution providers should be all those ICANN accredited UDRP service providers willing to solve these challenges).

Possible result of panel decisions

Double-label exclusions

If the challenge involves a dual-label request, the result can be to either maintain the exclusion or allow one of the challengers to register the name.

In assigning the domain to a challenger, the panel will base its decision on priority

Example: Suppose the mickey.mouse.nom exclusion request is challenged by three persons who can prove they are, respectively, named Michael Maus, Mickey Mouse and Michael Mouse and the administrative panel decides against the exclusion request. In this case, priority should be given to the challenger whose name matches the exclusion string mickey.mouse.nom.

If many Mr. Mickey Mouse have submitted challenges, preference would go to the first challenger in time.

Single-label exclusion

To challenge a single label exclusion (e.g. macintosh.nom), the challenger must specify the third-level label for which he or she wishes to challenge the exclusion (e.g. john.macintosh.nom).

The panel will first examine the legitimacy of the exclusion request, i.e. the fact that it matches a famous trademark. If this condition is not met, the exclusion request falls with the rendering of the panel decision.

If the exclusion request as such is deemed legitimate but the panel recognizes that a given third-level string overrides the trademark rights, a decision is granted with respect to that specific string.

If the panel recognizes that the trademark underlying the exclusion request has the status of a famous trademark, it can rule that the challengers who obtain the right to register a third-level domain name containing the exclusion string will be restricted in their use to non-conflicting purposes.

Evaluation study after one year of operation

CORE-II will conduct an evaluation study after one year of operation of this policy, in consultation with all relevant parties and will publish the results for public consideration and policy modifications.

Discussion

The solution described here is not perfect. Working Group B of the DNSO has not reached consensus on a uniform protection mechanism for famous trademarks in new gTLDs, and there is no universally accepted famous marks list. This solution is being proposed for the initial phase of launching new TLDs and can either be refined or replaced in the future.

E5.6. Whois Data

How will complete, up-to-date, reliable, and conveniently provided Whois data be maintained, updated, and accessed concerning registrations in the TLD?

Data made available publicly

The CORE registry will only publish data within limits allowed by applicable privacy laws and as defined by the registration agreement.

This data is updated within minutes of being changed in the registry.

The domain holder has the contractual responsibility to ensure that his or her data remains up to date.

Data made available to third parties with a legitimate interest

Provision of detailed whois data is subject to the signature of an agreement with the recipient party. The recipient must prove that it has a legitimate interest in the data requested. The agreement must be specific to domains for which a claim of legitimate interest is made. The data may only be used for the purpose of protecting that legitimate interest.

Please refer to answer to E7 below for the issue of the agent for communication.

E6. Dispute Resolution.

Describe the policies for domain name and other dispute resolution. If you are proposing variations to the policies followed in .com, .net, and .org, consider the following questions:

E6.1. UDRP adapted to .nom

To what extent are you proposing to implement the Uniform Dispute Resolution Policy?

Principle

The registration under .nom will be subject to a modified Uniform Dispute Resolution Policy adapted to personal domains.

Other than that, the .nom-UDRP should be as close as possible to the existing version for .com/.net/.org. For instance, if a trademark holder claims violation of trademark right, the existing UDRP terms can apply.

Dot nom-adapted UDRP

UDRP Clause 4a of the existing UDRP specifies that a complainant must prove that the following three elements are present to support the claim:

a) complainant has a trademark right in the domain name

b) the applicant has no right or legitimate interest

c) the applicant domain has been registered and is being used in bad faith

For the purposes of a .nom-adapted UDRP these criteria need be to slightly adapted in the following sense:

With respect to clause 4 a of the UDRP, we propose to change it in the following way:

a) complainant has a trademark right or his or her personal name is identical or similar to the domain name

b) the domain name does not match the name, or common abbreviation or derivation of the domain holder's name nor a pseudonym under which the domain holder is widely known. (E.g. Norma Jean Baker could prove that she is widely known as Marlyn Monroe).

c) the domain name has been registered and is being used in bad faith (this would remain unchanged)

UDRP Clause 4b(i) should not apply as long as no transfer policy is implemented.

UDRP Clause 4b(ii) should be changed to extend to personal names beyond trademarks or service marks.

UDRP Clause 4b(iii) should be extended to include that the domain name is primarily for the purpose of attacking or denigrating a third person whose name corresponds, or is strongly related to the domain name. The purpose is not to restrict free speech, but to safeguard the use of the domain name by those who have that corresponding name.

UDRP Clause 4b(iv) should be extended in an analogous fashion to the proposed extension of Clause 4b(iii) to safeguard the rights of persons.

Example. The policy allows Mr. John McDonald to register and keep john.mcdonald.nom. However, a complaint against him from McDonald's Corporation could succeed if he used the domain for commercial purposes conflicting with McDonald's legitimate interests.

UDRP Clause 4c(ii) is no longer needed.

(The above modifications of the UDRP reflect CORE's suggestion after extensive but urgent consultations. It is our opinion that such a modified policy should be formally adopted by ICANN. We would encourage the DNSO to use a fast track procedure to ensure RFCs comments, Name Council vote and final ICANN Board adoption not to unduly delay the launch of the TLD.)

E6.2. Supplemental Dispute Procedures

Please describe any additional, alternative, or supplemental dispute resolution procedures you are proposing.

Exclusion requests

(see famous marks protection at E5.5)

E7. Data Privacy, Escrow, and Whois.

Describe the proposed policies on data privacy, escrow and Whois service.

Privacy considerations

The specific nature of the .nom domain as a personal TLD implies that particularly stringent criteria apply to protection of personal privacy. Contact details such as address, telephone and fax addresses that are typically available on traditional TLD whois servers need to be given a different treatment here.

Registrants must have the ability to prevent this data from becoming publicly available. On the other hand, third parties may have legitimate reasons to verify the identity, the location and other contact details of the domain holder.

The name of the domain holder must be public. (In most cases it will even be similar to the domain name). The jurisdiction (location, if applicable the state, and the country of the domain holder's address) must also be shown. In case the domain holder chooses not to disclose further contact details, he or she must designate an authorized agent for contact whose full contact information will appear in the whois.

Data management

The data supplied by a registrant is usually kept on three levels.

Data shown on the Whois

Domain holder name

Jurisdiction (location)

Registrar

Name and address of designated agent for contact (person or professional able to contact domain holder) (this is optional)

Name servers

Technical contact

Date of registration

Last modification

Expiration of registration

(Note: the concept of "administrative contact" is not appropriate for personal domains. The concept of "zone contact" is not used anymore. The billing contact information is not needed at the Whois level.)

At the express request of the domain holder, the Whois service may contain additional internet-related data such as pgp public keys, key IDs, or other value-added information.

Data input into the registry by registrars on behalf of customers

In addition to the data shown on the whois, all the data required by the registration agreement is stored in the registry. This data includes:

Domain holder name and address

Domain holder email address and alternative email address

Optional telephone, fax

Representations formally made by customer in registering

The registry also stores historic data in this respect.

(The reason for the Registry to store this data is to protect registrants in case the registrar disappearing, going bankrupt or, otherwise leaving the TLD service. In those cases, this information, critical to the registrant, to prove his rights over the domain, the representations he made, etc. would disappear with the registrar.

A TLD managed as a public service for personal use cannot leave all registrants at that risk, without some guarantees that allow the continuity of the service through other registrars chosen by the registrant.)

Data collected by registrar

Within the limits of applicable privacy legislation and the privacy guarantees of the registration agreement, the registrar may collect additional data. An example of such an item is the billing information.

If the registrant provides optional data expressly specified in the registration agreement, then this data must also be stored at the registry level, as storage in the registrar's database is not deemed sufficient.

Data Escrow

The entire registry data is deposited with an escrow partner on a daily basis. This data will be at the disposal for any successor registry. The compliance of the escrow data can be verified by an independent auditor.

E8. Billing and Collection.

Describe variations in or additions to the policies for billing and collection.

The billing and collection concept is identical to that currently used for .com, .net and .org, namely, the prepayment of registrations by registrars. The registry operator determines the extent to which payment securities such as letters of credit are accepted.

E9. Services and Pricing.

What registration services do you propose to establish charges for and, for each such service, how much do you propose to charge?

Registrations and renewals

The registry charges registrars on a linear basis for registrations and renewals, each domain-year correspond to the standard fee determined by the registry operator on a cost-recovery basis. The price per registration is expected to decrease over time as the number of registrations increases.

The registrars compete with each other in terms of service level and price and are free to set their own pricing.

Re-authentication of domain holder

When a domain holder looses the ability to prove his authority over the domain name by electronic means, an audit trail may have to be recorded in the registry so that the information remains accessible even in case of change of registrar. Re-authentication also causes considerable overhead at registrar level. The registry will charge the registrar a cost-recovery fee for the related system usage, who in turn charges a fee to the domain holder. Re-authentication may also be performed by another registrar in the case of registrar transfers. The expected cost-recovery fee on registry level is in the order of USD 10.

Exclusion requests

The registry operator charges registrars a cost-recovery fee for inserting trademark exclusion requests. The prepayment method is identical to that used in domain registrations and is based on the number of strings registered. However, the cost per string is higher because of the less favorable ratio between the number of registrations and overhead caused by the service (special database, tools, inquiries, documentation). The expected cost-recovery fee per string on registry level is in the order of USD 100.

Trademark owners can only register an exclusion request by going through registrars who compete in terms of service level and price. Consequently registrars are free to set their own pricing for these services.

Additional cost-recovery charges

As needs for additional services arise and require central co-ordination processes under the responsibility of the registry operator, additional cost-recovery charges may be established.

E10. Other.

Please describe any policies concerning topics not covered by the above questions.

[E] II. REGISTRATION POLICIES DURING THE START-UP PERIOD

(Required for all TLDs)

E11. In this section, you should thoroughly describe all policies (including implementation details) that you propose to follow during the start-up phase of registrations in the TLD, to the extent they differ from the General TLD Policies covered in items E1-E9. The following questions highlight some of the areas that should be considered for start-up policies:

E12. Potential initial rush

How do you propose to address the potential rush for registration at the initial opening of the TLD? How many requested registrations do you project will be received by the registry operator within the first day, week, month, and quarter? What period do you believe should be considered the TLD's "start-up period," during which special procedures should apply?

Objectives and Methodology

The methods proposed by CORE pursues two objectives: (a) to ensure an orderly and fair TLD launch process (b) to avoid performance bottlenecks during the launch period. The initial rush effect is proportional to the overall speculative interest aroused by the TLD.

This effect is limited in the case of restricted TLDs, but not necessarily null. Moreover, an additional leveraging effect is caused if users perceive a "limited-time" ability to obtain a relative advantage over others.

The danger inherent in the initial onslaught is to see unfair practices in the sales process (transparency issue) and to experience avoidable bottlenecks in various stages of the registration, screening, policing and conflict resolution processes. The fairness issue can reach from grey zones in business ethics (e.g. auctioning of front queue positions) to outright fraud (false pre-registrations). Moreover, the absence of a transparent framework can push registrars into ethical grey zones for simple competition and market share considerations, even if the company would actually prefer to steer clear.

Any attempt to deal with the initial onslaught by "brute force" (plentiful processing power in the registry) bears the seed of failure in itself. However, fast central systems perform, client systems feeding the central system can match their speed.

The attempt to deal with the initial onslaught by throttling mechanisms (artificial bottlenecks) would only displace the problem onto the rogue registration queues held by registrars and exacerbate problems related to business ethics, transparency and fairness.

CORE's proposed methodology therefore comprises the following measures:

(a) The registry centrally manages transparent application queues over a sufficient period of time ahead of domain activation. (As queues are inevitable, our intention is to minimize as much as possible the technical, ethical and business risks of the queues)

(b) The TLD launch mechanism is designed to limit, but not eliminate, the advantage of early application.

Centrally managed transparent application queues

Central queues by registrar

The existence of transparent central queues automatically reduces the attractiveness of rogue queues on the periphery. Rather than a single queue, there are as many queues as there are registrars. This effect of course only works if the queue-building phase is long enough for users to learn about it when it already has started. The suggestion here is that it should have several weeks duration.

Having separate queues by registrar means a registrar starting to fill in its queue earlier than others will not gain an advantage in doing so. Nothing can be gained by submitting all the applications as soon as the door opens.

Each registrar can add domains into its queue at any time during the queue-building phase, but it cannot change the order in which the domains will be submitted. As soon as a domain is entered into the queue, the SRS debits the member registrar's account by the standard registration fee. The registrar can also delete domains from the queue and get a refund from the registry, provided its deletions do not exceed a certain proportion (e.g. 50 percent) as set by the Advisory Council.

Transparency

Applicants can ascertain that their registrars or resellers indeed entered their respective domain name application thanks to a queue-building lookup service. This lookup mechanism is offered on the registry's level.

The queue building lookup service is anonymous and only works with a domain name as search argument. The only information shown is
(1) the domain name,
(2) an optional verification string the applicant can specify (this enables the applicant to identify his or her application on the lookup service)
(3) a unique transaction ID
(4) the creation date and time of the application record.

(In the case of domain names reflecting the applicant's name, the degree of anonymity of all other personal data is ensured).

If several applications for the same domain exist, all applications are shown. Access is based on the port 43 Whois protocol.

A registrar may handle only one pre-registration application for the same domain. This is enforced at the registry level. (The reasons being are: i) not to diminish chances of customer = best execution obligation of registrar to his customer; and ii) enforceable method of avoiding duplication of same registration for probability enhancement).

It is important to point out that the name and contact details of the applicant are recorded in the registry but not shown on the queue lookup service.

Pre-registration application agreement

The standard pre-registration application agreement contains the terms of the registration agreement plus additional clauses specific to the queue building process. In particular, it specifies:

(a) the nature of the queue building process

(b) the fact that the applicant has no certainty of obtaining the domain applied for

(c) the fact that exclusion requests entered during the queue building process (see E5.5) will have precedence over pre-registration applications irrespective of relative timing.

Limiting the advantage of early application

The advantage of an early application can be reduced through the addition of objective randomness. This is justifiable from a fairness perspective because there is no moral merit to having submitted an application slightly ahead of someone else and CORE does not want to encourage or grant special rights to those pre-registering names before the real launch of the TLD. The meaning of "slightly" in this context must be seen in relationship to the time it takes for potentially interested people to learn about the possibility of registering a given domain.

Randomization of front queue positions

Before queues are submitted to the round robin process (see below), the first X percent of each registrar's queue are randomly reordered by the registry. The X percent parameter should be unknown until the end of the queue building process. It may be between 0 and 100 percent but the intention is not to make it higher than it need to be.

The practical objective is to make it no more likely to get a given domain by registering as soon as the door opens than by registering a couple of days or weeks later. It also removes the incentive of registrars to artificially rearrange queues before submitting them.

Note: As an assurance against tampering, the random reordering can be defined in a traceable fashion, i.e. by an algorithm that allows recalculation with identical results. This is possible because the combined state of all registrars' queues is a random pattern from the perspective of an individual registrar's queue. The combined queue state can therefore be used as random seed information.

Random end timing of queue-building phase

When the queue-building phase ends, the registration systems run the round-robin process and thereafter switches over to a continuous registration state (first come, first served).

Note: the concept of random opening timing is also used in electronic securities exchanges, albeit for a slightly different reason. On securities exchanges, the opening price could be manipulated by last-second interventions, so the period over which the opening time is spread with even likelihood is 60 or 120 seconds. In the domain registrations, registrars could keep many registrations for the very end of the queue-building period. The random end margin of the queue-building period would have to be in the order of a week long.

Round Robin Process

The result of the queue-building process and the random reordering of the first portion in each registrar's queue goes into the so-called round robin process.

The next successful registration is retained from each registrar randomly numbered from 1 through n in that order. (In other words, a failed application does not count as a turn. This can be done because there are sufficient others safeguards against submission of artificially inflated queues.) For each failed application, the registrar account is re-credited with the amount originally debited for the application.

For the next rotation, the same order from 1 to n is used, and so on. If a given registrar's queue is empty when at any given turn, then the process continues with the next registrar in line.

Note: Contrary to CORE's earlier specifications, the round robin rotation order will not be re-randomized at each round. The reason is that the effect of re-randomization would be negligible and incommensurate to cost and loss of transparency in this case.

E13. No use Rationing Option

Do you propose to place limits on the number of registrations per registrant? Per registrar? If so, how will these limits be implemented?

There are legitimate reasons for a person to use several names. Moreover the exclusion method, the dispute resolution policy and the no-transfer policy provide sufficient assurances against abuse. It is therefore not planned to apply any rationing scheme.

E14. Price-based Demand Management

Will pricing mechanisms be used to dampen a rush for registration at the initial opening of the TLD? If so, please describe these mechanisms in detail.

At registry level, pricing is based on the cost-recovery mechanism. On top of that, registrars establish service levels and pricing in a competitive environment. Fee may be higher during the initial phase for purely economic reasons.

E15. Sunrise Period

Will you offer any "sunrise period" in which certain potential registrants are offered the opportunity to register before registration is open to the general public? If so, to whom will this opportunity be offered (those with famous marks, registered trademarks, second-level domains in other TLDs, pre-registrations of some sort, etc.)? How will you implement this?

The exclusion request mechanism is an ongoing protection instrument for trademarks. In conjunction with the queue-building process (see E12) it also represents a sunrise period provision because exclusion requests registered during the queue-building phase take precedence over pre-registration applications irrespective of relative timing.

[E] III. REGISTRATION RESTRICTIONS

(Required for restricted TLDs only)

E16. As noted in the New TLD Application Process Overview, a restricted TLD is one with enforced restrictions on (1) who may apply for a registration within the domain, (2) what uses may be made of those registrations, or (3) both. In this section, please describe in detail the restrictions you propose to apply to the TLD. Your description should should define the criteria to be employed, the manner in which you propose they be enforced, and the consequences of violation of the restrictions. Examples of matters that should be addressed are:

E17. Registration Criteria

Describe in detail the criteria for registration in the TLD. Provide a full explanation of the reasoning behind the specific policies chosen.

Registrations under .nom are restricted to individuals. A limited exception is constituted by the exclusion requests; however these do not allow use of the domain.

The .nom domains are for personal use only. However, this does not ipso facto require non-commercial use unless there is conflict with legitimate trademark interests. These factors can only be assessed ex post by a court, arbitrator or dispute-resolution framework. (See dispute resolution at E6.1).

E18. Application Process

Describe the application process for potential registrants in the TLD.

As described above, the application process is based on the pre-payment principle and requires full contact details as well certain representations (which may be determinant in case of conflict) to be stored in the registry. Domains are assigned on a first-come, first-served basis except for the special provision linked to the sunrise period and the queue-building process.

E19. Enforcement Procedures

Describe the enforcement procedures and mechanisms for ensuring registrants meet the registration requirements.

For reasons of cost and practicability, the pre-screening process is exclusively based on computer verification of data formats and the computer-verifiable completeness. As a matter of fact, the cultural diversity of potential registrants makes it impossible to centrally enforce any further pre-screening. The presence of the registrar in the various environments facilitates their use screening mechanisms based on the local legal environment and customs.

The post-registration enforcement procedures are based on the third-party complaint process and the dispute resolution process.

E20. Appeal Process

Describe any appeal process from denial of registration.

The exclusion request framework provides for a challenge procedure (see E5.5). As there is not discretion in the assignment process, there is no need for any other formal appeal process.

E21. Third Party complaints

Describe any procedure that permits third parties to seek cancellation of a TLD registration for failure to comply with restrictions.

A third party can file a complaint concerning the following cases of false information:

- false personal contact information

- false agent for contact information

- false name server (lame delegation).

The complainant contacts a registrar (complaining registrar) of his or her choice and requests the lodging of a complaint in the registry. This transaction is charged for by the registry to the complaining registrar on cost-recovery basis. In case the registry determines that there is a large-scale pattern of negligence on the part of a maintaining registrar, it may assign a share of the cost to the latter.

The SRS sends a complaint advice to the maintaining registrar of the domain(s) involved. The maintaining registrar must respond within one week at least to indicate that the matter is being dealt with. In the absence of a response, the procedure continues in the same fashion as it would if the maintaining registrar reported being unable to correct the situation or to provide satisfactory answers to the effect that the complaint is not valid.

If the maintaining registrar is unable to settle the complaint, the SRS sends an electronic final notice to the all available registrant contact information. If the holder of the infringing domain does not correct the situation within three weeks, the domain is put on hold, i.e. no longer active. Once this has happened, the domain name holder may reactivate the domain through a re-authentication process (see E9 above ), provided all errors corrected and the domain has not expired in the meantime.

[E] IV. CONTEXT OF THE TLD WITHIN THE DNS

(Required for all TLDs)

E22. This section is intended to allow you to describe the benefits of the TLD and the reasons why it would benefit the global Internet community or some segment of that community. Issues you might consider addressing include:

E23. Differentiation from other TLDs

What will distinguish the TLD from existing or other proposed TLDs? How will this distinction be beneficial?

There are several causes:

-.Nom TLD is for personal use only, which is not the case for the current gTLD (see E25).

-Access is more evenly spread, not the domain of a happy few (two-dot policy implies a shared second level and a third exclusively delegated level)

- Low-cost, long term (see E1 above)

- Mobilizes resources and innovation from companies to individuals' needs.

- It is the basis on which to build future services for individual, in particular those related to convenient low-cost individual authentication.

E24. Target Community

What community and/or market will be served or targeted by this TLD? To what extent is that community or market already served by the DNS?

The underlying community of the .nom TLD is not bound geographically, professionally or systemically. The .nom TLD is devoted to individuals at large, whether or not they are current Internet users. It serves their long-term personal use independently from their activity at a given stage in their lives.

E25. Meeting presently unmet needs

Please describe in detail how your proposal would enable the DNS to meet presently unmet needs.

Current gTLDs are designed for corporate and organizational use. The currently available low-cost names for individuals are strongly linked to professional activities or to service providers. Moreover, many ccTLDs are very restricted for rules that de iure or de facto exclude individuals.

E26. Utility to Internet Users

How would the introduction of the TLD enhance the utility of the DNS for Internet users? For the community served by the TLD?

Widely used memorable personal messaging addresses are key for the development of the Internet. They are of considerable utility not only for the respective domain name holders but also for all their correspondents.

E27. Enhancement of Competition

How would the proposed TLD enhance competition in domain-name registration services, including competition with existing TLD registries?

The competition between TLDs is limited by the linguistic meaning of the TLDs. The best demonstration of this fact lies in the different orders of magnitude of usage between comparably marketed TLDs. More importantly, the end-user cannot easily move from one TLD to another once he has started relying on his domain.

This means that different TLDs can be to a certain extent competitive among themselves before the user i.e. the registrant, before the later performs the registration, but no competition whatsoever exists once the registration has been performed and the domain name has been consistently used. To use the usual example: No matter what Amazon.com may think about the services and prices offered by the registry managing.com, it would be both uneconomical and unfeasible to move to say amazon.biz. This is not only related to the cost involved in the creation of the name specific goodwill, but also to the very nature of the web. The hundred of thousands of links directed to Amazon.com would not resolve.

In the current technology stage, domain name portability within the registry is the only way to ensure robust competition in registration services.

The registrar activity is the critical element where competition must be fostered, while at the same time, the registry should not have independent motives for empire-building.

CORE has a robust and proven competitive registrar model. It is an open non-profit association with objective, non-discriminatory membership criteria, and where all the members have the same voting rights. The validity of this model has been also proven by the experience of Nominet, DeNIC, RIPE NCC and several other ccTLD registries. The existing experience has clearly shown that funding of a common co-ordination resource guaranteed by the fact that the registrars have a vital interest in its existence and in maintaining its fair and orderly functioning.

CORE specifically has been able to prove its viability in the light of the extremely difficult circumstances of the past three years which could not have been anticipated by any of the members. No for-profit venture would likely have survived this situation.

The proposed registrar model has been developed in order to enhance competition on registrar level.

[E] V. VALUE OF PROPOSAL AS A PROOF OF CONCEPT

(Required for all TLDs)

E28. Recent experience in the introduction of new TLDs is limited in some respects. The current program of establishing new TLDs is intended to allow evaluation of possible additions and enhancements to the DNS and possible methods of implementing them. Stated differently, the current program is intended to serve as a "proof of concept" for ways in which the DNS might evolve in the longer term. This section of the application is designed to gather information regarding what specific concept(s) could be evaluated if the proposed TLD is introduced, how you propose the evaluation should be done, and what information would be learned that might be instructive in the long-term management of the DNS. Well-considered and articulated responses to this section will be positively viewed in the selection process. Matters you should discuss in this section include:

E29. Concepts proved or disproved

What concepts are likely to be proved/disproved by evaluation of the introduction of this TLD in the manner you propose?

Restrictive TLD without costly manual pre-screening and post verification

".nom" as a TLD proposes an innovative concept restrictive TLD without costly manual pre-screening and post verification. Currently we have two main types of TLDs. Those completely unrestricted e.g. ".com" or many ccTLDs, or at the other end, restricted TLDs where comprehensive and manual pre-screening is performed e.g. ".int", ".mil" and some ccTLDs (".es", ".se"). Indeed, a third type had been initially designed, we could called them charter TLD or TLDs with special purposes e.g. ".org" or ".net" are good examples, but also a clear example that when the charter is not enforced at any level, the special purpose disappears and those TLDs rapidly became purely unrestricted.

Between intentioned charter with no consequences attached to its violation and the costs and delays and even the arbitrarieties attached to comprehensive pre-screening, we offer the possibility of a charter TLD with ex post enforcement.

".nom" is intended for personal use and its restricted to individuals as registrants. A number of declarations and representations have to be made when performing the registration. Nevertheless, the system does not check whether an individual is really named as he pretends to be or nor does it investigates the intentions deep inside that individual. How could that be performed by the registrars or the registry? In no way. Not only intentions are only true and known on the beholder side, but even concepts as identify are different to check in a multijurisdictional, multilingual, multicultural world as ours.

But some consequences have to be derived from the charter infringement. If I pretend to be John McDonald registering "john.mcdonald.nom" and I am not, if I declare that I would use the domain for strict personal use and I advertise my burger restaurant under "john.mcdonald.nom", if I provide false contact information, if I designate servers over which I have no authority (lame delegation), a policy that leaves the situation unchanged and my domain name status unaltered, a policy that does not take all this into account would be a very bad policy.

False contact information, including false agent for contact information and lame delegation can be dealt with the third party complaint procedure explained above in E21.Desviated use i.e. non personal use, or identity suplantation are the pillars of the dispute resolution provisions. Both mechanisms work ex post, that is, after registration is performed, only in case of conflict with a third party. The cost will be borne by those infringing the charter and not necessarily be spread among other legitimate users.

This mechanism will certainly need an education process, but we hope that ".nom" model will be used for future TLD expansion.

Gradual evolution from strong restriction to subtle restriction (evolve as you learn)

The Internet is becoming an ubiquitous facility and is experimenting an exponential growth, but many of its features were designed not so long time ago for a much smaller and less diversified network as it is now and will probably become during the near future.

DNS policies, like many others, are therefore far from stable and mature and a certain degree of experimentation is still required. Nevertheless, it is clear that some choices cannot be undone. This is why CORE proposes a somewhat initial policies for the first personal use domain restrictive charter that could be relaxed as the system stabilizes and some initial fears disappear. ".Nom" policies will evolve as we learn how it works, what its shortcomings and strengths are. Two examples are mentioned below:

a) non-transfer policy

This would probably not lead to a real problem in most cases, but it also implies a violation of the charter. Taking also into consideration that reselling domains is the primary goal of those performing massive registrations (cybersquatting or domain warehousing) a policy limiting or preventing transfers would certainly make such behavior marginal. However, there is always a but.

There are many circumstances in which a domain name transfer appears to be perfectly legitimate and that shows that a long term simple "non transfer" policy would be harmful.

In the long term, it is possible that the community, the intellectual property interests and the ICANN processes establish, if they prefer "free" transfer policy. In our approach, this could always be done, but the other way round; that is, moving from an unrestricted transfer policy to a restricted or non-transfer policy would be nearly impossible.

b) Another example will be the two-dot policy discussed below (see two-dots policy heading).

Exclusion request mechanism

Protection of famous trademarks has been an ubiquitous problem in new gTLDs discussion for the past years. The WIPO report published in April 1999 came to no conclusion on this issue. The DNSO Working Group B was also unable to recommend a clear and universal solution for the protection of Intellectual Property rights on the launch of new TLDs and on famous trademarks in particular.

The "exclusion list" concept has large support except that no one knows how to establish it in an authoritative way. The "sunrise period" with its many variations also had strong support but again no consensus was reached. ICANN itself has finally not agreed on any given methodology and leaves the choices upon on the new TLDs sponsors.

With this historic record in mind, it is fair to say that we are less than sure to have found the definitive and universal solution to the protection of famous trademarks, but we do propose a mechanism that combines many good points from both "sunrise period" and "exclusion list". Our exclusion mechanism is based on self selection. Initially nobody decides what is a famous trademark to be included in that list or not. It is up to the trademark holder to take such decision, but as this exclusion mechanism is attached with a challenge framework, it is expected that the community will soon learn about the relative marriage to use it, that is, as the party asking for the exclusion pays the cost of the challenge, parties loosing the challenges will see no need to remain in the exclusion mechanism, and will teach third parties about rational expectations in this field. The exclusion mechanism works as a "sunrise period" (or "sunset period") as it is open before the actual launch of the TLD, alone with the queue building process (and taking precedence over queue entries) but it is also an ongoing mechanism (close to the much discussed "exclusion list"). It is probable that the exclusions will be initially a little bit inflated and this would adjust over the time.

Indeed a mechanism such the one described and proposed could possible be even more useful for other commercially oriented TLD(that under ".nom" policies where many other safeguards have been built in).

This is also part of the proof of concept approach. We experiment under less dangerous circumstances (".nom") and if the experiment reasonably succeeds, it can be "exported" to other new TLDs in the future.

Two Dots policy

".nom" being a personal use TLD is intended for wide spread use, and is bound to limit domain name speculation. In order to accommodate a larger number of users, we have adopted the so called "two-dot" policy. All registrants must share the second level domain with any other interested registrant, while they are delegated the third level on an exclusive basis.

Our policy allows John Smith, Joe Smith, Peter Smith and so on to get a unique, reasonable and usable domain name. If we initially allow exclusive registration at the second level, only one lucky Smith in the world would get it, leaving outside the rest of the Smiths. Moreover, the Smith getting the smith.nom domain on an exclusive basis would probably like to act as a sharing domain name company, offering its services on a third level to other Smiths, but without any control from a policy point of view and without any competition.

The system is indeed not perfect, there will be always conflicts between people wanting exactly the same domain whether it is a second, third or any other level, but the DNS and this TLD should not be mistaken by a world directory of all the users of Internet. It is simply a tool providing unique and memorable addresses for users in the Internet. If later on, it is proven that users strongly prefer exclusive second level domains, and this can be addressed without harming any other policy objective, the ".nom" policy could be relaxed in the sense that delegation could be performed at the second level for those strings still available.

.shop proposal

According to the .nom model; .shop could function in the following way:

This TLD would provide simple linguistic means to remember names and to discover vendors for a certain category of products/services

The new top level domain would get the name "shop". Each registrable domain would consist of three labels (including the "shop"). In the following, the labels are called L1, L2 and L3 from right to left.

myname.flower.shop

L3 L2 L1

L1 would, of course, always be "shop". L2 would be a so-called generic term. The L2 term would be shared among multiple domain holders (detailed later), that means that two different domain holders could register two different domains containing the same term at L2.

L3 would be an arbitrary term. A list of reserved terms (e.g. "www", "web", "ftp") would be set up to avoid a circumvention of the scheme (details also later).

L2 specific Policies

As mentioned above, the L2 term would be a generic one. The intuitive way would be to set up a dictionary of allowed terms. But this solution has many disadvantages. First, someone would have to decide which is a generic term and which is not. Since not only English terms would be demanded by the domain name holders but terms in other languages also, the deciding instance would have to have the capability to decide over all existing written languages. For instance, both myname.flower.shop and minename.bloomen.shop would be allowed. It would need a tremendous effort to create such an instance.

Therefore another solution could be used, which would be based on a self-regulatory way. It would be combined with the policies for domain name disputes and trademark disputes:

On registration, the domain name holder would declare that

- the L2 term is a generic term

- he would agree to the use of the L2 by other domain name holders, who are not related to him in any way. This means in detail, that if the term consists of or contains a trademark or a term protected by other means (e.g. names of famous people), he would waive his rights regarding the specific label.

Any party could demand the removal of a L2 if it contained a trademark or otherwise protected terms. The demanding party would prove via the dispute resolution policy that at least one domain name holder violated his rights. If he succeeds, a similar mechanism of exclusion to the one described in .nom, would apply.

A complaints committee could handle any complaints related to L2 not covered by the protected term issue. If relevant causes were to exist, specific L2 terms could be added to the exclusion list. The cause that a certain term would not be a generic term would not be relevant enough as long as it would not be in the public interest. Otherwise, the existing uniform dispute resolution framework could be sufficient.

L3 specific Policies

The L3 would be unrestricted; it could contain any terms. The standard dispute policies would apply.

Value Added Services

Significant added services for this TLD could be a directory of existing shops. This directory would be reachable via HTTP by the URLs "http://shop" and "http://L2.shop" , where L2 would not be the second level label of the domain name. The directory would be financed by the registry. The following rules would apply to fulfil the spirit of equal opportunity:

- The directory could not contain any advertisement except implicitly by the list of domain name holders.

- The domain name holder could not be charged to be included in the directory. The restrictions could not be relaxed by paying additional fees.

- The domain name holder could add additional data to his records, e.g. countries served, key words, major products. The amount of data could be limited to prevent misuse.

- The user could specify filter and sort criteria. If two domain name holders were to share the same sort criteria (e.g. located in the same city), the order would be random and would change at least on a day-by-day basis.

Intellectual Property Provisions

As Intellectual Property protection and on top of applying the current UDRP an extension of the .nom exclusion mechanism could be used. In fact, the exclusion mechanism could apply to a diversity of TLD, and not be TLD specific. CORE has prepared a proposal in this regard where the exclusion functionality works as a TLD (.tmx) and it will be submitted in due time.

Dispute Resolution

The registry would implement the Uniform Dispute Resolution Policy to its full extent.

Registration Policies during Start-Up Period

See the proposal for the .nom domain.

E30. [Proposed Evaluation Method]

How do you propose that the results of the introduction should be evaluated? By what criteria should the success or lack of success of the TLD be evaluated?

The success of .nom or lack thereof cannot be evaluated according to the number of registrations. For one thing, we propose an initial restrictive policy, and a certain education period will be needed to stabilize mechanisms as the exclusion list. .Nom will prove its utility if a growing number of individuals wish to organize a long term personal domain space (including the development of related services such as, personal certificates, PKI, public key directories, etc.) Its policies should be evaluated in the mid-term based on a decreasing conflict curve (a sign of success) or an increasing one (a call for immediate review).

E31. [Long-term value for DNS]

In what way would the results of the evaluation assist in the long-range management of the DNS?

The success of .nom will prove that charter domain names with ex post enforcement of the charter criteria instead of extensive ex ante scrutiny are viable and useful.

Secondly, it would help in developing names spaces for purposes other than commercial, and would serve the scalability of Internet as it allows for a certain degree of domain name sharing (two-dot policy).

It also would help reconciling the public information needs attached to the whois service to private considerations.

E32. [Other reasons]

Are there any reasons other than evaluation of the introduction process that this particular TLD should be included in the initial introduction?

We think that all the points have been addressed throughout this proposal.

[E] (Signature)

By signing this application through its representative, the Applicant attests that the information contained in this Description of TLD Policies, and all referenced supporting documents, are true and accurate to the best of Applicant's knowledge.

_______________________________
Signature

Werner Staub____________________
Name (please print)

Head of CORE Secretariat__________
Title

CORE Internet Council of Registrars__
Name of Applicant Entity

September 30, 2000________________
Date