IV. Provisions for Equivalent Access by Accredited Registrars
C20. The selected successor operator for the .org registry will be
required to provide all ICANN-accredited registrars having registry-registrar
agreements in effect with equivalent access to registry services through a
shared registry system, under which those registrars will provide services
(either directly or through resellers) to registrants. This section of the .org
Proposal covers the applicant's proposed arrangements for interacting with
registrars in a manner that provides equivalent access.
C21. Describe in detail your proposed methods of providing registry
services on an equivalent basis to all accredited registrars having
registry-registrar agreements in effect. Your description should include any
measures intended to make registration, technical assistance, and other services
available to ICANN-accredited registrars in different time zones and relevant
languages. In addition, describe the Registry Code of Conduct and other
commitments you propose to make to ensure that all such registrars receive
equivalent access to registry services. In preparing your response to this item,
you may wish to refer to Appendices H and I of the registry agreements ICANN has
entered for unsponsored TLDs (e.g., .biz, .com, .info, .name, and .pro).
The UIA Team will ensure that all Registry Services are made available to every
operational ICANN-accredited registrar in an equivalent manner through the use
of efficient operational and technical processes, as well as response/escalation
procedures to address any challenges. The processes include: certification of
registrars, customer support, registry Code of Conduct assurance, and technical
elements of equivalent access.
Certification of Registrars
To date, more than 100 registrars have been successfully certified to
register .org domain names. The UIA Team intends to build upon this means of
promoting registrar competition by implementing a simple, efficient method of
preparing new registrars for production. Some key features of this process are:
- Consistent application of all criteria used in this process for all
registrars, as documented in ramp-up files.
- Initial welcome packages, containing detailed explanation of all required
steps and technical resources, mailed overnight within 24 hours of receipt
of ICANN notice that registrar has achieved accreditation. Once registrar
returns signed Confidentiality Agreement, it may complete all remaining
steps in any order it chooses. These steps include contact information
sheet, executed Registry-Registrar Agreements, corporate formation
documents, surety instrument, payment security, credit information and
technical certification.
- Contract administrators to manage the entire process across various
functional groups within the UIA Team. The process is coordinated through a
document/information management system in which steps are recorded so that
each group can monitor progress and ensure consistent and timely completion
for all registrars.
- Availability of UIA customer and technical support for the registrar
during technical testing and all other phases.
- Regular contact between the registrar and the UIA Team to provide status
updates and offer any assistance in fulfilling the requirements.
Customer Support
The UIA Team believes that superior, prompt customer support to all registrars
is an essential element to the success of the .org TLD. In this regard,
Diversitas plans to provide:
- 7x24x365 customer support through a team of trained customer service
representatives.
- Representatives available to address questions and assist customers in every
time zone at the customer's convenience.
- Use of Language Line, a telephone translation service also available
7x24x365, enables the UIA Team to communicate effectively and immediately with
all of its customers without additional expense to the customer.
- Established escalation procedures whereby technical, legal or other
high-level issues are promptly forwarded to the appropriate groups, ensuring
suitable, professional, and timely responses.
Registry Code of Conduct
The Registry Code of Conduct contained in Appendix I of the existing unsponsored
TLD Registry Agreements serves as a model of superior business practices. As
referred to in Section C19 hereof, the UIA Team will develope a training course
for all relevant employees and contractors. As is the intent of the Code of
Conduct, the fundamental theme of the training course is avoiding and preventing
preferential treatment of any ICANN-accredited registrar. At the conclusion of
each course, all participants will be required, as a material condition of
employment, to execute an Organizational Conflict of Interest (OCI) Avoidance Certification that certifies their
agreement to avoid conflicts and to report any potential conflicts. This course
will also contain:
- A detailed policy regarding proper use and dissemination of confidential
and sensitive information and data, to be distributed during the course and at
various other times throughout the year. Participants are further instructed on
the proper methods of safeguarding and destroying such material.
- An Information Control Matrix, a document governing which employees or group
of employees are entitled to which type of information. The OCI course
emphasizes that sensitive information is distributed only to those employees or
contractors having a legitimate need to know for purposes of performing their
job function.
- A detailed review of the Code of Conduct, as well as all items contained in
the Equivalent Access Certification (Appendix H to existing non-sponsored TLD
Registry Agreements).
UIA will implement this OCI program for all personnel providing support to
the UIA Team for the .org TLD. A Compliance Officer who will be a member of the
Diversitas staff will manage the compliance program.
As an additional means of monitoring compliance with the Code of Conduct and
the Equivalent Access Certification, Diversitas plans to continue the use of periodic
reviews and department surveys conducted by the Policy and Compliance group. As
highlighted in Section C19 of this proposal, these surveys, recorded in written
form and kept on file, are intended to provide evidence that each of the
equivalent access requirements in Appendix H of the .org registry agreement are being
met.
Technical Elements of Equivalent Access
As discussed in detail in Section C17.10, the UIA Team has implemented a system
whereby each operational registrar is assured equivalent access to the SRS
through its use of connections to the various pools: the Guarantee Pool,
Overflow Pool, and finally, the Automated Batch Pool. This system recognizes and
appreciates the various business models utilized by registrars while at the same
time providing a fair and level playing field.
C22. VeriSign, Inc., the current operator of the .org
registry uses a registry-registrar protocol (RRP) documented in RFC 2832. At the
time of the transition, the selected successor operator will be required to
continue to support the RRP (unless a migration of registrars in .org to another
protocol has already been completed by that time). In addition, the selected
successor operator will be required to implement support for the IETF provreg
working group's protocol specification for an Extensible Provisioning Protocol (EPP)
no later than 135 days after it is adopted as a Proposed Standard [RFC 2026,
section 4.1.1]. Provide a detailed description of your plan for supporting RRP
at the time of transition, for supporting EPP within the required time frame,
and for providing registrars with a smooth, low-cost migration path from RRP to
EPP.
As described in section C.17.2, the UIA Team will support the Registry
Registrar Protocol (RRP) described in RFC 2832 at the start of registry
operations. The existing VGRS implementation of RRP will be used to ensure
that initial operations will not be subject to extended outages due to load or
new software implementation defects. Additionally, existing registrar software
systems will be able to function without any significant change, ensuring that
initial registrar costs are minimized and reliability is assured.
Support for EPP will be phased in gradually. Though the IETF has not yet
produced proposed standards for EPP, VGRS has been developing an
implementation of the protocol using existing Internet-Draft documents to
minimize the amount of time required to support the protocol once proposed
standards are finally published. The VGRS implementation of EPP is being
developed to the same exacting standards of reliability and performance
required of the .com and .net registries, and the lengthy (but deliberate)
development effort will ensure that the implementation is sound and ready for
production deployment in the future.
Support for RRP will be eliminated only after support for EPP has been
introduced and a lengthy period of parallel operations has been completed. A
complete migration to EPP will allow registry and registrars to support a
single provisioning protocol stack, allowing each to simplify operations and
reduce costs. Newly accredited registrars will have ample opportunity to
develop an implementation of EPP.
The transition process and timeline is illustrated in Figure C22.
Figure C22: RRP to EPP Transition Process
- RRP will be used at the start of registry operations to minimize the
transition impact for registrars. EPP implementation based on Internet-Draft
documents will continue in preparation for implementation and deployment based
on proposed standard documents.
- Transition from RRP to EPP requires the existence of proposed standards for
EPP. If proposed standards exist at the start of registry operations,
transition efforts will begin immediately. If proposed standards do not exist
at the start of registry operations, the formal transition process will begin
when proposed standards are formally announced by the IETF.
- Within 135 days of proposed standards for EPP being announced by the IETF
(or within 135 days after the start of registry operations if proposed
standards exist at the start of registry operations), EPP will be made
available to registrars for development and testing in an Operational Test
& Evaluation (OT&E) environment. The OT&E environment will allow
registrars and the registry to fine tune their protocol implementations before
beginning live operations.
- UIA will continue to maintain a "thin" registry for .org.
Transition to a "thick" registry would require a costly and
error-introducing migration of data from the registrars to the registry,
whereas continuing the "thin" .org registry preserves current
registrar operating models, doesn't require registrars to archive and deliver
registrant and contact data to the registry, and eliminates the possibility of
introducing data consistency errors as part of populating a "thick"
registry.
- 90 calendar days after the introduction of EPP in the OT&E environment,
both EPP and RRP will be supported in the "live" production
environment. Both protocols will be available to access the same data sets,
ensuring that inter-registrar data views remain consistent and independent of
the protocol being used by any particular registrar. The OT&E environment
will remain available on an ongoing basis for development and testing.
- Support for both EPP and RRP will continue during a minimum parallel
operations period of 90 calendar days. The parallel operations period may be
extended as needed to ensure that the transition is proceeding smoothly and
the stability of the .org registry is maintained.
- Support for RRP will be terminated at the end of the parallel operations
period.
Transition to EPP will impact both the .org registry and the
registrars of .org domains. The UIA Team will take several steps to help
provide a smooth, low-cost migration path from RRP to EPP, including:
VGRS has unparalleled experience in providing registry
services using RRP. Transition to a new provisioning protocol introduces
several risks to the stability of .org, including data inconsistency, software
defects and errors, systems performance, and systems reliability. The
experience gained through three years of ongoing operations with RRP, coupled
with demonstrated ability to maintain a reliable, scalable registry, will help
ensure that the period of initial registry operations will proceed without
failure.
The UIA Team is committed to the development of EPP in the
IETF. All of the core protocol specifications were written and edited by Scott
Hollenbeck, a VGRS Engineering Principal. Mr. Hollenbeck produced the first
set of protocol specifications, coordinated the initial effort to publicize
the protocol, worked within the IETF to form the provreg working group, and
provided ongoing efforts to edit the documents as they've evolved through the
IETF's review processes. Mr. Hollenbeck and other team members will remain
actively involved in the protocol development and transition efforts to help
ensure that the migration from RRP is as smooth and low-cost as possible.
To simplify registrar efforts in the EPP conversion, VGRS will
perform EPP migration efforts for .org along with those for .com and .net.
Back to
Table of Contents
|