Back

29 Rights Protection Mechanisms

gTLDFull Legal NameE-mail suffixDetail
.sncfSociété Nationale des Chemins de fer Francais S N C Fsncf.FrView
A. RIGHTS PROTECTION MECHANISMS TO BE IMPLEMENTED BY SNCF

The core purpose of SNCF in operating the .SNCF gTLD domain is to ensure a secure online space for responsible Internet users. In particular, SNCF seeks to establish a trusted and reliable platform for Internet users who wish find information on products and services related to the .SNCF gTLD. Therefore, SNCF has a strong interest in ensuring that all of its policies are implemented and continually enforced. SNCF will implement and adhere to any rights protection mechanisms (RPMs) that may be mandated from time to time by ICANN in line with Specification 7 of the Registry agreement. This includes the Sunrise processes, the Trademark Clearinghouse and Trademark Claims processes, the Uniform Domain Name Dispute Resolution Policy (UDRP), the Uniform Rapid Suspension (URS) and WHOIS processes.

The eligibility criteria for the .SNCF require that each registrant meet the eligibility criteria for the .SNCF as set out in the draft registration policy in Question 28. Prospective registrants must provide all required supporting documentation as requested by the Registry from time to time. Because of these eligibility criteria, the registry does not anticipate that third parties and⁄or trademark owners unrelated to the SNCF will incur costs in relation to the .SNCF gTLD. Furthermore, the identity of registrants will be pre-verified before the registration of any domain names which will lessen the risk of rights infringements.

In the event that third parties perceive that their rights have been infringed, they will have a speedy right of recourse open to them. Given that SNCF has resolved to ensure that abusive use of .SNCF gTLD domain names will not be permitted nor tolerated and that the risk that such abuses inherently create negative publicity and loss of goodwill, SNCF is committed to ensuring that any abuse will be swiftly and effectively addressed, and that systems are in place to mitigate rights protection issues.

Abuses and complaints against domain names in the .SNCF registry will be quickly addressed in the manner set forth in the response to Question 28.

SNCF will go beyond the required rights protection mechanisms defined in Specification 7 of the Registry Agreement by also participating in solutions to monitor potentially malicious conduct over the Internet as outlined below and in the answer to Question 28. This may occur via private contracts with a qualified anti-phishing solutions vendor who will both monitor the TLD zone for abuse and take action to remedy the abuse, and⁄or this may occur via participation in a broader program such as the Abusive Domain Name Resolution Suspension Process (ADNRS) in development by the Anti-Phishing Working Group. Additionally, the measures below will be available at the time of opening up of the registry and will be enforced through contractual means:

- Acceptable use policy: SNCF publicizes its Acceptable use policy which will define abuse, abuse handling processes and the consequences of abuse;
- Rapid Takedown or Suspension Based on Court Orders: SNCF or its approved registrar(s) complies promptly with any order from a court of competent jurisdiction that directs it to take any action on a domain name that is within its technical capabilities as a gTLD registry. These orders may be issued when abusive content, such as child pornography, counterfeit goods, or illegal pharmaceuticals, is associated with the domain name;
- Anti-Abuse Process: SNCF implements an anti-abuse process that is executed based on the type of domain name takedown requested. The anti-abuse process is for malicious exploitation of the DNS infrastructure, such as phishing, botnets, and malware;
- Authentication Procedures: AFNIC, SNCF’s selected backend registry services provider, ensures that data modification is managed through strict authentication and access policies as set out in Question 28;
- DNSSEC Signing Service: Domain Name System Security Extensions (DNSSEC) helps mitigate pharming attacks that use cache poisoning to redirect unsuspecting users to fraudulent websites or addresses. It uses public key cryptography to digitally sign DNS data when it comes into the system and then validate it at its destination. The .SNCF is DNSSEC-enabled as part of AFNIC’s core backend registry services

SNCF will also ensure in all cases that its approved Registrar(s) will adopt appropriate anti-abuse mechanisms, respond to abuse processes and third party rights protection mechanisms and processes, in dealing with any domain name registrations, renewals and use. This will ensure that highly skilled, specialized and scalable resources are on hand to address any possible rights protection issues both during the startup phase of the TLD and continually during operations of the TLD. SNCF will ensure that Registrar(s) are contractually bound to provide high quality and responsive management of rights protection queries.

B. REGISTRY OPERATOR PROVIDED RIGHTS PROTECTION MECHANISMS

SNCF acknowledges that it must provide (a) a sunrise registration service for at least 30 days during the pre-launch phase giving eligible trademark owners an early opportunity to register second-level domains in new gTLDs; and (b) a trademark claims service for at least the first 60 days that second-level registrations are open.

.SNCF has engaged AFNIC to provide certain registry operation services, amongst which are the technical functions required to implement the mechanisms outlined below in respect of sunrise periods, trademark claims periods and the interaction with the Trademark Clearinghouse. The manner in which these elements will be addressed by the various parties is set out in this section. It should be noted that because ICANN, as of the time of this application submission, has not issued final guidance with respect to the Trademark Clearinghouse, .SNCF cannot fully detail the specific implementation of the Trademark Clearinghouse within this application. .SNCF will adhere to all processes and procedures to comply with the ICANN guidance once this guidance is finalized.

Sunrise Services
SNCF acknowledges that all new gTLDs must provide a sunrise registration service for at least 30 days before general registration of domain names.

SNCF confirms that it will implement a sunrise service pre-registration procedure for domain names for 30 days prior to the launch of the general registration of domain names. Prior to the Sunrise Period commencing, SNCF will establish and then notify its registry service provider of the sunrise eligibility requirements for the gTLD. Registrants may register domain names which meet the sunrise eligibility requirements and are registered in the Trademark clearinghouse. The registrant of any registrations of domain names during this period must agree to be subject to the Sunrise Dispute Resolution Policy (SDRP) consistent with Section 6 of the Trademark Clearinghouse Rules as set forth by ICANN. During this period, SNCF, and its approved registrar(s), will verify whether or not a particular domain name is eligible to be registered on an individual case by case basis before adding the necessary command to the Shared Registry Service (SRS) to register the applicable domain name. If there are multiple sunrise applications for an identical domain name, the domain name will be allocated through an auction mechanism.

Trademark Claims Service – Land-rush service
SNCF will provide a trademark claims service for a minimum of sixty (60) days. During this period, SNCF (or its approved registrars on its behalf) shall validate each request for registration of a domain name against trademarks registered in the Trademark Clearinghouse and shall (where applicable) provide notice to each prospective Registrant of a domain name that it is an identical match (as defined in the gTLD Applicant Guidebook) to the mark holder validated in the Trademark Clearinghouse, in the form required by ICANN. The Approved Registrar(s) will then require each registrant to provide the warranties set out in the gTLD Applicant Guidebook before registration of the particular domain name. Those warranties will include receipt and understanding of the Trademark Claims Notice and confirmation that registration and use of said domain name will not infringe on the trademark rights of the mark holders listed. Without receipt of said warranties, SNCF or its approved Registrar(s) will not process the domain name registration.

SNCF and⁄or its approved registrar(s) (as applicable) will be responsible for determining whether a domain name is eligible to be registered and will do so for each domain name before submitting an add command to the gTLD Shared Registry Service to register the applicable domain name.

Following the registration of a domain name, the holders of trademarks that have been previously validated by the Trademark Clearinghouse as an identical match will receive a notice of the domain name registration by SNCF or its approved registrar (as applicable), in the form required by ICANN.

If there are competing applications for an identical domain name, the domain name will be allocated through an auction to be held after the conclusion of the trademark claims⁄land-rush period.

General registration period
Following the expiry of the trademark claims⁄land-rush service, SNCF will provide registrations of domain names from eligible registrants on a first come, first served basis in accordance with the draft registration policy set out in the answer to Question 28.

C. Dispute Resolution

SNCF will comply with the dispute resolution mechanisms required by ICANN including the Trademark Post-Delegation Dispute Resolution Procedure (PDDRP), the Registration Restriction Dispute Resolution Procedure (RRDRP), the Uniform Rapid Suspension (URS), and the Uniform Dispute Resolution Procedure (UDRP). SNCF will implement all determinations and decisions under these mechanisms.

After a domain name is registered, trademark holders can object to the registration through the UDRP or URS. Objections to the operation of the gTLD can be made through the PDDRP. The following descriptions provide implementation details of each post-launch rights protection mechanisms for the .SNCF gTLD:

- UDRP: The UDRP provides a mechanism for complainants to object to domain name registrations. The complainant files its objection with a UDRP provider and the domain name registrant has an opportunity to respond. The UDRP provider makes a decision based on the papers filed. If the complainant is successful, ownership of the domain name registration is transferred to the complainant. If the complainant is not successful, ownership of the domain name remains with the domain name registrant. SNCF and entities operating on its behalf adhere to all decisions rendered by UDRP providers.

- URS: As provided in the Applicant Guidebook and the Registry agreement, all registries are required to implement the URS. Similar to the UDRP, a complainant files its objection with a URS provider. The URS provider conducts an administrative review for compliance with filing requirements. If the complaint passes review, the URS provider notifies the registry operator and locks the domain. A lock means that the registry restricts all changes to the registration data, but the name will continue to resolve. After the domain is locked, the complaint is served to the domain name registrant, who has an opportunity to respond. If the complainant is successful, the registry operator is informed and the domain name is suspended for the balance of the registration period; the domain name will not resolve to the original website, but to an informational web page provided by the URS provider. If the complainant is not successful, the URS is terminated and full control of the domain name registration is returned to the domain name registrant. Similar to the existing UDRP, SNCF and entities operating on its behalf adhere to decisions rendered by the URS providers. The contact details of the .SNCF gTLD abuse point of contact will be provided to all URS providers.

- PDDRP: As provided in the Applicant Guidebook, all registries are required to implement the PDDRP. The PDDRP provides a mechanism for a complainant to object to the registry operator’s manner of operation or use of the gTLD. The complainant files its objection with a PDDRP provider, who performs a threshold review. The registry operator has the opportunity to respond and the provider issues its determination based on the papers filed, although there may be opportunity for further discovery and a hearing. SNCF participates in the PDDRP process as specified in the Applicant Guidebook.

All registrations of domain names will be subject to compliance through contractual means with the above procedures and policies, should disputes occur. SNCF will act as the primary contact for handling inquiries relating to malicious conduct in the gTLD. The abuse point of contact described in the response to Question 28 above will be tasked with also responding to complaints in relation to rights protection.

The primary abuse point of contact will investigate and respond to all complaints and incidents in a timely manner and be empowered to take effective action within well-defined written criteria to guide those actions. Action will be taken in line with what is set out in the answers to Question 28 and 29 and the registration policy for the .SNCF TLD.

D. WHOIS

SNCF will comply with the requirements set out in specification 4 of the registry agreement to ensure readily available information on registrants. SNCF’s mechanisms for ensuring complete and accurate WHOIS data are described in the response to Question 28.

E. Resource planning

Resource planning specific to backend Registry activities
Initial Implementation

Thanks to the experience and prior investment by its Registry Service Provider (AFNIC), the .SNCF already supports the above mentioned functions and appropriate support systems.

One aspect to be considered for resource planning is the registry systemʹs connection to the Trademark Clearinghouse; since the involved API is not fully defined at the time of writing, some software development will have to be done in order to integrate the Clearinghouse into the sunrise workflow, as well as to incorporate it into the designated Trademark Claims Service. It is estimated that a Software Developer will be allocated to work 10 man days on the development of this feature.

Staff are already on hand and will be assigned this work as soon as ICANN releases the relevant technical specifications.

Ongoing maintenance

In support of the SNCF staff allocated to the operation of the rights protections mechanisms mentioned (see below), the Registry Service Provider (AFNIC) will set up a team of highly experienced individuals with a distinct track record in handling dispute and managing TLDs in a manner that very significantly minimizes the risk of problems. These individuals have direct experience from launch management and dispute resolution concerning the different French ccTLDs.

This team will be composed of expert-level staff for respectively handling and advising on issues and individual cases. Their skill set will primarily be consisting of administrative and legal training, as well as domain name policy expertise.

Resource planning specific to other Registry activities and third party registrars
SNCF has effectively mitigated the risk of abuse in the gTLD and foresees dedicating a member of staff to act as the primary point of contact for handling inquiries relating to malicious or abusive conduct in the TLD. SNCF is committed to ensuring that sufficient resources are made available at all times. SNCF may engage its third party registrar(s) and its selected backend registry services provider to perform some or all of the tasks associated with rights protection issues. This will ensure that highly skilled, specialized and scalable resources are on hand to address any possible abuse issues both during the startup phase of the TLD and continually during operations of the TLD.

.

gTLDFull Legal NameE-mail suffixDetail
.banqueGEXBAN SASgexban.netView

A. RIGHTS PROTECTION MECHANISMS TO BE IMPLEMENTED BY .banque

The core purpose of GEXBAN in operating the .banque gTLD domain is to ensure a secure online space for responsible Internet users. In particular, .banque seeks to establish a trusted and reliable platform for Internet users who wish find information on products and services related to .banque gTLD. Therefore, GEXBAN has a strong interest in ensuring that all of its policies are implemented and continually enforced. .banque will implement and adhere to any rights protection mechanisms (RPMs) that may be mandated from time to time by ICANN in line with Specification 7 of the Registry agreement. This includes the Sunrise processes, the Trademark Clearinghouse and Trademark Claims processes, the Uniform Domain Name Dispute Resolution Policy (UDRP), the Uniform Rapid Suspension (URS) and WHOIS processes.

The eligibility criteria for the .banque require that each registrant meet the eligibility criteria for the .banque as set out in the draft registration policy in Question 28. Prospective registrants must provide all required supporting documentation as requested by the Registry from time to time. Because of these eligibility criteria, the registry does not anticipate that third parties and⁄or trademark owners unrelated to the . GEXBAN will incur costs in relation to the .banque gTLD. Furthermore, the identity of registrants will be pre-verified before the registration of any domain names which will lessen the risk of rights infringements.

In the event that third parties perceive that their rights have been infringed, they will have a speedy right of recourse open to them. Given that GEXBAN has resolved to ensure that abusive use of .banque gTLD domain names will not be permitted nor tolerated and that the risk that such abuses inherently create negative publicity and loss of goodwill, .banque is committed to ensuring that any abuse will be swiftly and effectively addressed, and that systems are in place to mitigate rights protection issues.

Abuses and complaints against domain names in the .banque spacewill be quickly addressed in the manner set forth in the response to Question 28.

GEXBAN will go beyond the required rights protection mechanisms defined in Specification 7 of the Registry Agreement by also participating in solutions to monitor potentially malicious conduct over the Internet as outlined below and in the answer to Question 28. This may occur via private contracts with a qualified anti-phishing solutions vendor who will both monitor the TLD zone for abuse and take action to remedy the abuse, and⁄or this may occur via participation in a broader program such as the Abusive Domain Name Resolution Suspension Process (ADNRS) in development by the Anti-Phishing Working Group. Additionally, the measures below will be available at the time of opening up of the registry and will be enforced through contractual means:

- Acceptable use policy: GEXBAN publicizes its Acceptable use policy which will define abuse, abuse handling processes and the consequences of abuse;

- Rapid Takedown or Suspension Based on Court Orders: GEXBAN or its approved registrar(s) complies promptly with any order from a court of competent jurisdiction that directs it to take any action on a domain name that is within its technical capabilities as a gTLD registry. These orders may be issued when abusive content, such as child pornography, counterfeit goods, or illegal pharmaceuticals, is associated with the domain name;

- Anti-Abuse Process: GEXBAN implements an anti-abuse process that is executed based on the type of domain name takedown requested. The anti-abuse process is for malicious exploitation of the DNS infrastructure, such as phishing, botnets, and malware;

- Authentication Procedures: AFNIC, GEXBAN’s selected backend registry services provider for .banque , ensures that data modification is managed through strict authentication and access policies as set out in Question 28;

- DNSSEC Signing Service: Domain Name System Security Extensions (DNSSEC) helps mitigate pharming attacks that use cache poisoning to redirect unsuspecting users to fraudulent websites or addresses. It uses public key cryptography to digitally sign DNS data when it comes into the system and then validate it at its destination. The .banque is DNSSEC-enabled as part of AFNIC’s core backend registry services


GEXBAN will also ensure in all cases that its approved Registrar(s) will adopt appropriate anti-abuse mechanisms, respond to abuse processes and third party rights protection mechanisms and processes, in dealing with any domain name registrations, renewals and use. This will ensure that highly skilled, specialized and scalable resources are on hand to address any possible rights protection issues both during the startup phase of the TLD and continually during operations of the TLD. GEXBAN will ensure that registrar(s) are contractually bound to provide high quality and responsive management of rights protection queries.


B. REGISTRY OPERATOR PROVIDED RIGHTS PROTECTION MECHANISMS

GEXBAN acknowledges that it must provide (a) a sunrise registration service for at least 30 days during the pre-launch phase giving eligible trademark owners an early opportunity to register second-level domains in new gTLDs; and (b) a trademark claims service for at least the first 60 days that second-level registrations are open.

GEXBAN has engaged AFNIC to provide certain registry operation services, amongst which are the technical functions required to implement the mechanisms outlined below in respect of sunrise periods, trademark claims periods and the interaction with the Trademark Clearinghouse. The manner in which these elements will be addressed by the various parties is set out in this section. It should be noted that because ICANN, as of the time of this application submission, has not issued final guidance with respect to the Trademark Clearinghouse, .banque cannot fully detail the specific implementation of the Trademark Clearinghouse within this application. .banque will adhere to all processes and procedures to comply with the ICANN guidance once this guidance is finalized.


SUNRISE SERVICES

GEXBAN acknowledges that all new gTLDs must provide a sunrise registration service for at least 30 days before general registration of domain names.

GEXBAN confirms that it will implement a sunrise service pre-registration procedure for domain names for 30 days prior to the launch of the general registration of domain names. Prior to the Sunrise Period commencing, GEXBAN will establish and then notify its registry service provider of the sunrise eligibility requirements for the gTLD. Registrants may register domain names which meet the sunrise eligibility requirements and are registered in the Trademark clearinghouse. The registrant of any registrations of domain names during this period must agree to be subject to the Sunrise Dispute Resolution Policy (SDRP) consistent with Section 6 of the Trademark Clearinghouse Rules as set forth by ICANN. During this period, GEXBAN, and its approved registrar(s), will verify whether or not a particular domain name is eligible to be registered on an individual case by case basis before adding the necessary command to the Shared Registry Service (SRS) to register the applicable domain name. If there are multiple sunrise applications for an identical domain name, the domain name will be allocated through an auction mechanism.


TRADEMARK CLAIMS SERVICE – LAND-RUSH SERVICE

GEXBAN will provide a trademark claims service for a minimum of sixty (60) days. During this period, GEXBAN (or its approved registrars on its behalf) shall validate each request for registration of a domain name against trademarks registered in the Trademark Clearinghouse and shall (where applicable) provide notice to each prospective Registrant of a domain name that it is an identical match (as defined in the gTLD Applicant Guidebook) to the mark holder validated in the Trademark Clearinghouse, in the form required by ICANN. The Approved Registrar(s) will then require each registrant to provide the warranties set out in the gTLD Applicant Guidebook before registration of the particular domain name. Those warranties will include receipt and understanding of the Trademark Claims Notice and confirmation that registration and use of said domain name will not infringe on the trademark rights of the mark holders listed. Without receipt of said warranties, GEXBAN or its approved registrar(s) will not process the domain name registration.

GEXBAN and⁄or its approved registrar(s) (as applicable) will be responsible for determining whether a domain name is eligible to be registered and will do so for each domain name before submitting an add command to the gTLD Shared Registry Service to register the applicable domain name.

Following the registration of a domain name, the holders of trademarks that have been previously validated by the Trademark Clearinghouse as an identical match will receive a notice of the domain name registration by GEXBAN or its approved Registrar (as applicable), in the form required by ICANN.

If there are competing applications for an identical domain name, the domain name will be allocated through an auction to be held after the conclusion of the trademark claims⁄land-rush period.


GENERAL REGISTRATION PERIOD

Following the expiry of the trademark claims⁄land-rush service, GEXBAN will provide registrations of domain names from eligible registrants on a first come, first served basis in accordance with the draft registration policy set out in the answer to Question 28.


C. DISPUTE RESOLUTION

GEXBAN will comply with the dispute resolution mechanisms required by ICANN including the Trademark Post-Delegation Dispute Resolution Procedure (PDDRP), the Registration Restriction Dispute Resolution Procedure (RRDRP), the Uniform Rapid Suspension (URS), and the Uniform Dispute Resolution Procedure (UDRP). GEXBAN will implement all determinations and decisions under these mechanisms.

After a domain name is registered, trademark holders can object to the registration through the UDRP or URS. Objections to the operation of the gTLD can be made through the PDDRP. The following descriptions provide implementation details of each post-launch rights protection mechanisms for the .banque gTLD:

- UDRP: The UDRP provides a mechanism for complainants to object to domain name registrations. The complainant files its objection with a UDRP provider and the domain name registrant has an opportunity to respond. The UDRP provider makes a decision based on the papers filed. If the complainant is successful, ownership of the domain name registration is transferred to the complainant. If the complainant is not successful, ownership of the domain name remains with the domain name registrant. GEXBAN and entities operating on its behalf adhere to all decisions rendered by UDRP providers.

- URS: As provided in the Applicant Guidebook and the Registry agreement, all registries are required to implement the URS. Similar to the UDRP, a complainant files its objection with a URS provider. The URS provider conducts an administrative review for compliance with filing requirements. If the complaint passes review, the URS provider notifies the registry operator and locks the domain. A lock means that the registry restricts all changes to the registration data, but the name will continue to resolve. After the domain is locked, the complaint is served to the domain name registrant, who has an opportunity to respond. If the complainant is successful, the registry operator is informed and the domain name is suspended for the balance of the registration period; the domain name will not resolve to the original website, but to an informational web page provided by the URS provider. If the complainant is not successful, the URS is terminated and full control of the domain name registration is returned to the domain name registrant. Similar to the existing UDRP, GEXBAN and entities operating on its behalf adhere to decisions rendered by the URS providers. The contact details of the .banque gTLD abuse point of contact will be provided to all URS providers.

- PDDRP: As provided in the Applicant Guidebook, all registries are required to implement the PDDRP. The PDDRP provides a mechanism for a complainant to object to the registry operator’s manner of operation or use of the gTLD. The complainant files its objection with a PDDRP provider, who performs a threshold review. The registry operator has the opportunity to respond and the provider issues its determination based on the papers filed, although there may be opportunity for further discovery and a hearing. GEXBAN participates in the PDDRP process as specified in the Applicant Guidebook.


All registrations of domain names will be subject to compliance through contractual means with the above procedures and policies, should disputes occur. GEXBAN will act as the primary contact for handling inquiries relating to malicious conduct in the gTLD. The abuse point of contact described in the response to Question 28 above will be tasked with also responding to complaints in relation to rights protection.

The primary abuse point of contact will investigate and respond to all complaints and incidents in a timely manner and be empowered to take effective action within well-defined written criteria to guide those actions. Action will be taken in line with what is set out in the answers to Question 28 and 29 and the registration policy for .banque.


D. WHOIS

GEXBAN will comply with the requirements set out in specification 4 of the registry agreement to ensure readily available information on registrants. GEXBAN mechanisms for ensuring complete and accurate WHOIS data are described in the response to Question 28.


E. RESOURCE PLANNING

RESOURCE PLANNING SPECIFIC TO BACKEND REGISTRY ACTIVITIES
INITIAL IMPLEMENTATION

Thanks to the experience and prior investment by its Registry Service Providers (AFNIC), the .banque Registry already supports the above mentioned functions and appropriate support systems.

One aspect to be considered for resource planning is the registry systemʹs connection to the Trademark Clearinghouse; since the involved API is not fully defined at the time of writing, some software development will have to be done in order to integrate the Clearinghouse into the sunrise workflow, as well as to incorporate it into the designated Trademark Claims Service. It is estimated that a Software Developer will be allocated to work 10 man days on the development of this feature.

Staff are already on hand and will be assigned this work as soon as ICANN releases the relevant technical specifications.


ONGOING MAINTENANCE

In support of the Registry Operator’s staff allocated to the operation of the rights protections mechanisms mentioned (see below), the Registry Service Provider (AFNIC) will set up a team of highly experienced individuals with a distinct track record in handling dispute and managing TLDs in a manner that very significantly minimizes the risk of problems. These individuals have direct experience from launch management and dispute resolution concerning the different French ccTLDs.

This team will be composed of expert-level staff for respectively handling and advising on issues and individual cases. Their skill set will primarily be consisting of administrative and legal training, as well as domain name policy expertise.


RESOURCE PLANNING SPECIFIC TO OTHER REGISTRY ACTIVITIES AND THIRD PARTY REGISTRARS

GEXBAN has effectively mitigated the risk of abuse in the gTLD and foresees dedicating a member of staff to act as the primary point of contact for handling inquiries relating to malicious or abusive conduct in the TLD. GEXBAN is committed to ensuring that sufficient resources are made available at all times. GEXBAN may engage its third party registrar(s) and its selected backend registry services provider to perform some or all of the tasks associated with rights protection issues. This will ensure that highly skilled, specialized and scalable resources are on hand to address any possible abuse issues both during the startup phase of the TLD and continually during operations of the TLD.