28 Abuse Prevention and Mitigation

Prototypical answer:

1 Synopsis < b r/>< b r/> This chapter provides details on the Abuse Prevention and Mitigation pro- < b r/> cedures as provided by the ZA Central Registry as currently in use for the < b r/> co.za 2nd level domain, and as intended for use in the dotDurban TLD on < b r/> ratification by the dotDurban TLD policy committee and in accordance with < b r/> industry best practises and the ICANN Registrar and Registry Accredita- < b r/> tion Agreement policies. < b r/>< b r/>< b r/> 2 Abuse Policies and Procedures < b r/>< b r/> 2.1 Implementation Plan: Abuse Point of Contact < b r/>< b r/> The ZA Central Registry is committed to protecting consumers, registrars < b r/> and the greater internet community against fraudulent, deceptive and unfair < b r/> business practices and to provide online advisory assistance to eliminate or < b r/> at the very least minimize such practices within the dotDurban TLD name < b r/> space immediately after delegation. The ZA Central Registry, in consulta- < b r/> tion with the dotDurban Policy Oversight Committee , intends investigating < b r/> and implementing the following strategy to ensure that the above objectives < b r/> are achieved: < b r/>< b r/> 1. Setting up a dedicated online complaints portal with access to email, < b r/> telephone and fax contact details ; < b r/>< b r/> 2. Appointing a dedicated Complaints Officer who will attend to com- < b r/> plaints or channel them to the relevant divisions within the registry to < b r/> expedite resolution thereof; < b r/>< b r/> 3. Creating policies that will clearly set out inter alia: the scope and < b r/> ambit of complaints that will be dealt with; the process that will be < b r/> followed to deal with domain related complaints; the course of action < b r/> that will be available to the registry to deal with complaints depending < b r/> on their nature. < b r/>< b r/>< b r/> 2.2 Domain Complaints Policy < b r/>< b r/> Policies handling complaints pertaining to the dotDurban domain name will < b r/> be drafted and approved by the dotDurban Policy Oversight Committee . < b r/> What follows is a brief outline of some of the aspects that must be included < b r/> as part of the policy framework and content < b r/>< b r/> 2.2.1 Background < b r/>< b r/> This document sets out the ZA Central Registry policy on handling com- < b r/> plaints relating to registrants, accredited registrars and resellers in the dot- < b r/> Durban TLD domain name space. < b r/>< b r/>< b r/> 2.2.2 Definitions Clause < b r/>< b r/> In this part of the policy it would be imperative to define terms such as < b r/> complainant (a party who has lodged a complaint regarding a dotDurban < b r/> domain name or a service provided by an accredited registrar or reseller), < b r/> domain complainant ( make it subject to the clause that defines what com- < b r/> plaints will be covered within the scope of the policy); industry complaints < b r/> (make it subject to clause that describes what complaints are covered within < b r/> the parameters of this policy), respondent (person who lodges a complaint < b r/> with the ZA Central Registry). < b r/>< b r/>< b r/> 2.2.3 Jurisdiction to handle domain name complaints < b r/>< b r/> This clause should define the ability of the ZA Central Registry to han- < b r/> dle complaints that fall exclusively within the dotDurban domain name < b r/> space and list those complaints which the ZA Central Registry will not be < b r/> competent to handle such as domain complaints relating to generic Top < b r/> Level Domains or other country code Top Level Domains; web-hosting, < b r/> web-management or web-design services which generally fall within the con- < b r/> tractual sphere; internet access or email services which again falls outside < b r/> the registry function; offensive or objectionable website content. Reference < b r/> should also be made to relevant policies that may be developed and which < b r/> may contain their own internal authority or institution mandated to deal < b r/> with breaches thereof. Referrals to these institutions must be possible and < b r/> perhaps a link should be provided to the appropriate authority or institution. < b r/>< b r/>< b r/> 2.2.4 Complaints Management Process < b r/>< b r/> This clause should give details of how complaints should be communicated < b r/> to the Complaints Officer, i.e. whether by fax, email or post; whether the re- < b r/> spondent will be given an opportunity to respond to the complaint; stipulate < b r/> the time frames (specific or within a reasonable period of time) within which < b r/> the complaint will be resolved; and how the complainant will be notified of < b r/> the outcome of the investigations conducted regarding the complaint. < b r/>< b r/> 2.2.5 What constitutes domain complaints⁄industry domain com- < b r/> plaints? < b r/>< b r/> This clause should set out the type of complaints that will be addressed < b r/> by the Complaints Officer. For example, domain complaints may include < b r/> but not be limited to: cybersquatting, spam, phishing, ownership of domain < b r/> names, transfer of domain names from one registrant to another, breach < b r/> of any dotDurban published policies; mismanagement of the dotDurban < b r/> domain name space by an accredited registrar or domain name reseller, < b r/> breaches of the registrar agreement or any Codes of Conduct that may exist. < b r/> Complaints that fall outside the competence of the Complaints Officer must < b r/> also be specifically mentioned. For example, that the Complaints Officer < b r/> would not entertain complaints that relate to competing rights in a domain < b r/> name or any commercial disputes between registrars and resellers and⁄or < b r/> registrars⁄resellers and registrants. The dotDurban Policy Oversight Com- < b r/> mittee would have to decide how broad or narrow this component should < b r/> be. < b r/>< b r/>< b r/> 2.2.6 Kinds of decisions⁄actions that can be taken < b r/>< b r/> This will depend on the nature of the complaint that is lodged and will < b r/> have to be streamlined by the Policy Oversight Committee. Sample of de- < b r/> cisions⁄actions could be: < b r/>< b r/> 1. In the case of a registrar or reseller being in breach of the registrar < b r/> accreditation agreement or any published policy, the action could be < b r/> to notify the registrar or reseller of the breach and to give them an < b r/> opportunity (time-based) to remedy the breach or risk more stringent < b r/> action being taken, such as, to deny or cancel the registration, renewal < b r/> or transfer of any .durban domain names, or to place any .durban < b r/> domain name on registry lock, hold or similar status; < b r/>< b r/> 2. In the case of an unauthorized⁄unlawful transfer, it could be a reversal < b r/> of that transfer; < b r/>< b r/> 3. Request the registrar⁄reseller to submit a full explanation of what < b r/> transpired and tender an apology for any abusive practice that has < b r/> negatively affected the complainant. < b r/>< b r/> 3 Whois Accuracy < b r/>< b r/> 3.1 Ad-hoc Validation Process < b r/>< b r/> Currently, authentication of registrar⁄registrant data on the Whois database < b r/> is governed in two ways. Firstly, the ZA Central Registry registrar accredi- < b r/> tation agreement contains a number of provisions that places an obligation < b r/> on the registrars to ensure that the data uploaded on the registry system is < b r/> correct and updated on a periodic basis, failing which, accreditation status < b r/> may be lost. The registrar accreditation agreement also places an obligation < b r/> on the registrar to enter into contracts, which incorporate the key principles < b r/> enunciated in the accreditation agreement as well as any additional legal re- < b r/> quirements, with their registrants. This places a reciprocal duty on both the < b r/> registrar and registrant community to ensure that at the very least, infor- < b r/> mation maintained on the whois database is accurate, complete and current. < b r/>< b r/> Secondly, the ZA Central Registry has a process (clause 7.3 in terms of the < b r/> registration agreement, and a subsequent form 15 manual takedown process) < b r/> in place to ensure that domain related data submitted to the registry is ac- < b r/> curate and complete. The ZA Central Registry conducts ad hoc surveys or < b r/> scrutiny of its Whois that shows that material information is missing on the < b r/> Whois database and⁄or may also receive complaints from third parties that < b r/> critical information on a particular domain is missing or inaccurate. The < b r/> clause 7.3 process is activated to handle abusive practices of this nature. < b r/> This process entails giving the registrar⁄registrant formal written notice by < b r/> email⁄fax⁄postage to its billing⁄admin⁄tech contact to update the Whois < b r/> database within 14 to 21 days, failing which the domain will be deleted. < b r/> Upon expiry of this a Whois look-up is conducted and if the domain contact < b r/> details have not been updated then the registrar⁄registrant is given a final < b r/> 24 hour period to attend to our update request. If the Registrant contact < b r/> details are not updated within the initial and extended periods then a take < b r/> down request in terms of form 15 is formally processed and the domain is < b r/> subsequently deleted. This process is properly documented and all efforts < b r/> are made to ensure that the registrar⁄registrant receives proper notification < b r/> and a reasonable opportunity to ensure that the domain details are com- < b r/> plete and accurate. Within the dotDurban gTLD context the dotDurban < b r/> Policy Oversight Committee will need to endorse this process or adapt it < b r/> for implementation in the dotDurban gTLD space. < b r/>< b r/> 4 Registrar Requirements < b r/>< b r/> Notwithstanding the ICANN Registrar Agreement for accredited registrars < b r/> the proposed registrar accreditation agreement for the dotDurban TLD will < b r/> include the following measures to ensure compliance to address abuse pre- < b r/> vention, abusive behavior and address service levels for law enforcement < b r/> requests. < b r/>< b r/> COMMENCEMENT AND DURATION < b r/>< b r/>< b r/> a Duration < b r/> b Registrar may Terminate < b r/>< b r/> REGISTRAR ACCREDITATION < b r/>< b r/>< b r/> a Requirement for Accreditation < b r/> b Registrar Service < b r/> c Non-Exclusivity < b r/> d Continuous Disclosure < b r/>< b r/> LOSS OF REGISTRARʹS ACCREDITATION < b r/>< b r/>< b r/> a Loss of Accreditation < b r/> b Consequences of Loss of Accreditation < b r/>< b r/> WARRANTIES < b r/>< b r/>< b r/> a Information Provided to the Registry < b r/> b The Registryʹs Reliance < b r/>< b r/> USE OF THE REGISTRY NAME AND LOGO < b r/>< b r/>< b r/> a Grant of Licence < b r/> b Other Use not Permitted < b r/>< b r/> GENERAL OBLIGATIONS OF REGISTRAR < b r/>< b r/>< b r/> a Registrar Services < b r/> b Compliance with Published Policies < b r/>< b r/> c Notification of changes to Published Policies < b r/> d Compliance with Code of Practice < b r/> e Inconsistencies < b r/> f No Limitation < b r/>< b r/> PAYMENT OF FEES < b r/>< b r/>< b r/> a Assessment Fee: < b r/> b Accreditation Fees: < b r/> c Annual Fee: < b r/> d Transaction Fees: < b r/> e Insurance: < b r/> f Value Added Tax (VAT): < b r/> g Timely Payment: < b r/> h Interest on Late Payment: < b r/> i No Set-Off: < b r/>< b r/> APPLICATION FOR A DOMAIN NAME < b r/>< b r/>< b r/> a Consideration by Registrar < b r/> b Compliance with Published Policies < b r/> c Final Check by the Registry < b r/> d Approved Domain Name Applications < b r/> e Rejected Domain Name Applications < b r/> f Notice of Registration < b r/>< b r/> REGISTRANT AGREEMENTS < b r/>< b r/>< b r/> a Registrant Agreement < b r/> b The Registryʹs Requirements < b r/> c No Inconsistent Terms < b r/> d Make Information Available to the Registrant < b r/> e Registrarʹs Agency: < b r/>< b r/> REGISTRANT DATA < b r/>< b r/>< b r/> a Submit to the Registry Operator < b r/>< b r/> b Updated Registrant Data < b r/> c Access to Registrant Data < b r/> d Information to be Publicly Available < b r/>< b r/> TRANSFER BETWEEN REGISTRARS < b r/>< b r/>< b r/> a Transfers < b r/> b Acknowledgement < b r/>< b r/> NON-SOLICITATION OF REGISTRANTS < b r/>< b r/>< b r/> a Use of WHOIS Service Information < b r/> b No Application < b r/>< b r/> REGISTRARʹS OTHER OBLIGATIONS < b r/>< b r/>< b r/> a Positive Covenants < b r/> b Negative Covenants < b r/> c Insurance < b r/> d Enquiries and Complaints < b r/>< b r/> CONTROL OF RESELLERS < b r/>< b r/>< b r/> a Appointment of Resellers < b r/> b Responsibility of the Registrar < b r/> c Reseller Agreement < b r/>< b r/> PRIVACY < b r/>< b r/>< b r/> INTELLECTUAL PROPERTY RIGHTS < b r/>< b r/>< b r/> a Registrant Data: < b r/>< b r/> OBLIGATIONS OF THE REGISTRY < b r/>< b r/>< b r/> a General obligations < b r/>< b r/> CONFIDENTIALITY < b r/>< b r/> a Delivery or Destruction of Confidential Information < b r/>< b r/> LIMITATIONS OF LIABILITY < b r/>< b r/>< b r/> a Disclaimer < b r/> b Effect of Legislation < b r/> c Exclusion of Implied Warranties < b r/> d General Exclusion of Liability < b r/> e Specific Performance < b r/> f Limitation of Liability < b r/> g Aggregate Liability < b r/> h Consequential Losses < b r/>< b r/> DISPUTE RESOLUTION < b r/>< b r/>< b r/> DEFAULT AND TERMINATION < b r/>< b r/>< b r/> a Consequences of Default: < b r/>< b r/> CONSEQUENCES OF TERMINATION < b r/>< b r/>< b r/> a Rights and Obligations on Termination: < b r/> b Survival: < b r/> c Forced Transfer: < b r/>< b r/> PROHIBITION OF ASSIGNMENT < b r/>< b r/>< b r/> a No Assignment: < b r/> b No Change of Control: < b r/> c Fees and Expenses: < b r/> d Details: < b r/>< b r/> GENERAL < b r/>< b r/>< b r/> a Entire Agreement and Variations: < b r/> b Further Assurance: < b r/> c Legal Costs and Expenses: < b r/>< b r/> d Waiver and Exercise of Rights: < b r/> e Time of the Essence: < b r/> f Non-Solicitation: < b r/>< b r/> NOTICES < b r/>< b r/>< b r/> a Service of Notice: < b r/>< b r/> INTERPRETATION < b r/>< b r/>< b r/> a Governing Law and Jurisdiction: < b r/> b Persons < b r/> c Joint and Several: < b r/> d Legislation: < b r/> e Severance: < b r/> f Rule of Construction: < b r/> g Force Majeure < b r/> h Currency: < b r/> i Business Day: < b r/> j Number and Gender: < b r/>< b r/>< b r/> 5 Domain Operation Control Policies < b r/>< b r/> The domain operation control policies will include adequate controls to en- < b r/> sure proper access to domain functions by registrars and token based control < b r/> of domain operations by registrants as defined by the following framework. < b r/>< b r/> THE REGISTRY SYSTEM AND SERVICES < b r/>< b r/>< b r/> a Introduction < b r/> b Access to the Registry System < b r/> c Registrar Support Services < b r/> d dotDurban TLD Registrar Interface < b r/>< b r/> NEW REGISTRATIONS < b r/>< b r/>< b r/> a Domain Name Registration Process < b r/>< b r/> b Managing Domain Names < b r/> c Registrar Maintenance < b r/> d Locking Domain Names < b r/>< b r/> CANCELLATIONS, REINSTATEMENTS AND DELETIONS < b r/>< b r/>< b r/> a Canceling a Domain Name other than During a Grace Period < b r/> b Canceling a Domain Name during a Grace Period < b r/> c Cancellation of Non-Renewed Domain Names < b r/> d Reinstating Cancelled Domain Names < b r/> e Status Change Notifications to Registrars < b r/> f Status Change Notifications to Registrants < b r/>< b r/> CHANGES TO REGISTRANT INFORMATION < b r/>< b r/>< b r/> a Registrant Notification < b r/> b Registrant Change Reinstatement < b r/> c Registrar Guidelines < b r/>< b r/> CHANGES TO ZONE RECORDS < b r/>< b r/>< b r/> a General < b r/> b Principles < b r/>< b r/> TRANSFERS BETWEEN REGISTRARS < b r/>< b r/>< b r/> a Registrant Notification < b r/> b Registrant Token Control < b r/> c Transfer Control Process (Including Registrant Token Based Con- < b r/> trol) < b r/> d Transfer Reimbursements < b r/>< b r/>< b r/> 5.1 Authentication and Notification Mechanisms < b r/>< b r/> The dotDurban TLD Registry implementation will support password based < b r/> authentication for Contact and Domain Registry objects. These password < b r/> based authentication mechanisms may bypass object locks (EPP client Ac- < b r/> tion Prohibited statuses) depending on usage. One-time passwords may be < b r/>< b r/> utilized to issue emergency transfers or suspensions if deemed necessary by < b r/> the dotDurban Policy Oversight Committee . < b r/>< b r/> The dotDurban TLD Registry implementation employs out-of-band notifica- < b r/> tion to the Domain Registrant. The notification system, usually Email⁄SMS < b r/> based, is utilized whenever a Domain or Contact object transform command < b r/> is executed. The notification provides the Registrant an opportunity to < b r/> query and, if applicable, cancel the action or transfer the domain. Addi- < b r/> tionally, the notification system allows Domain Registrants to vote via Web < b r/> or Email on Domain Transfer requests. If, at any point in the process, the < b r/> Registrant feels that the requesting Registrar is being abusive the registrant < b r/> may issue an abuse complaint as per section 2.2 of this document. < b r/>< b r/> In addition to the out-of-band notification system, the Registry also em- < b r/> ploys EPP based Poll messages for the current sponsor of the EPP object. < b r/> A Poll message notifying the sponsoring Registrar will be queued if any < b r/> transform command is executed on the Registry. < b r/>< b r/>< b r/> 6 Orphan Glue Record Policy < b r/>< b r/> The dotDurban Registry implementation may prohibit the use of Host cre- < b r/> ate⁄update commands, thus forcing the requester to create Host associations < b r/> via the Domain create⁄update commands. The process ensures that a host < b r/> cannot be edited directly and glue cannot be adjusted without knowledge of < b r/> the superordinate domain. The Zone publication procedures will not pub- < b r/> lish Glue records for Host objects if the superordinate domain is not owned < b r/> and published by the same Registrar. The process inherently prevents the < b r/> creation and publication of orphan glue. < b r/> If at any point orphan glue records should exist the ZA Central Registry < b r/> will provide a policy for removing it based on document ICANN document < b r/> sac-048-en.pdf as published by the ICANN Security and Stability Advisory < b r/> Committee (SSAC) dated 12 May 2011. < b r/>< b r/>< b r/> 7 Resource Planning < b r/>< b r/> In the interim post delegation phase, the abuse point of contact portfolio will < b r/> be staffed by the ZA Central Regtistry. < b r/>

Similar gTLD applications: (3)