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