Sentan Registry Services, Inc. is a private, for-profit corporation (Delaware, 
USA).

NeuLevel and NeuStar are private, for-profit corporations (Delaware, USA). 

Japan Registry Services Co., Ltd. is a for-profit corporation (Japan). 

Sentan:				21 (12 direct employees and 9 contracted staff) 
NeuLevel Registry Subcontract: 	35
JPRS:				133 
NeuStar:			375

[RESPONSE IS CONFIDENTIAL]

WHY SENTAN
· Commitment for full compliance with all existing and future ICANN consensus 
policies 

· Leadership in the development and adoption of new ICANN consensus policies by 
devoting expert personnel and financial resources to the process

· Implementation of an improved transfer process by migrating the .NET registry 
to a thick data EPP model, strictly enforcing the ICANN Inter-Registrar 
Transfer Policy, creating online transfer dispute process, and automated 
transfer undo command

· Requirement for registrars to implement the Redemption Grace Period (RGP)

· Contractual commitment to implement IDNs in compliance with the ICANN 
guidelines, including an improved implementation of stakeholder language 
policies

· Employment of a dedicated, Vice President for Policy and Compliance

· Adoption of mechanisms to improve the accuracy of WHOIS information, protect 
the privacy of domain name registrants, and mitigate WHOIS data mining

· The provision of seminars for the registrars and the Internet community on 
policy compliance

· A more global perspective on policy development and compliance

Policy compliance creates a level playing field for all ICANN registry 
operators. ICANN's 2004 Strategic Plan demonstrates the importance of 
developing policies that ensure global interoperability, technical stability, 
and network security. We believe there are 3 essential components of policy 
compliance. The first is a technical ability, commercial willingness, and 
corporate culture that enables, indeed demands, compliance. The second is the 
resources to actively participate in and contribute to ICANN's bottom-up 
consensus driven policy development process. The third is understanding and 
agreement, by the registry, that a registry must act in the best interest of 
the Internet community and customers when introducing new registry services.  
Sentan's mission structure and business plan fully embody these components.

If selected, Sentan will comply with all of ICANN's existing and future 
consensus policies. Sentan will lead the development of future ICANN policies 
by continuing to devote expert personnel and financial resources to ICANN's 
policy development process. We will have a Vice President of policy and 
compliance focused on .NET policy. In addition, we will have support from 
Sentan's board members, and from management and employees at both parent 
companies. Sentan's parent companies have an outstanding international track 
record in development, implementation, and compliance with ICANN policies.

A Track Record of Participation in ICANN's Policy Development Process

Sentan's commitment to policy compliance is born from its parent companies, 
NeuLevel and JPRS. These companies have a peerless record of compliance, as 
detailed below.

NeuLevel is an industry leader in the development and implementation of 
policies across ICANN's registry, registrar, and technical constituencies. 
NeuLevel's Director of Legal and Policy (Jeff Neuman) was appointed by ICANN to 
serve on the 2002 Names Policy Development Process Assistance Group, 
responsible for establishing the ICANN's Policy Development Process for the 
reformed ICANN. Currently Neuman serves as one of the co-chairs of the WHOIS 
Task Force and is a member of the WSIS Planning Group. He has also served as a 
member of the transfer assistance group responsible for drafting the Transfer 
Dispute Resolution Policy. This policy is critical for determining the process 
registries must implement to enforce new Transfer Policies. 

NeuLevel's staff have served as members of the GNSO Council; former DNSO Names 
Council, and Chairman of the gTLD Registries Constituency. The team has also 
participated in the Redemption Grace Period Technical Committee, Transfer Task 
Force, Implementation Committee, Transfer Assistance Group, gTLD Registries 
Constituency, and the Country Code Names Supporting Organization (ccNSO) 
Launching Group and Council. 

NeuLevel's Jon Peterson currently holds a position on the Security and 
Stability Advisory Committee. Finally, NeuLevel is a consistent sponsor of 
ICANN meetings and has hosted numerous seminars on advanced DNS-related 
services, including ENUM, IPv6, and DNSSEC. 

JPRS is one of the first ccTLDs to recognize ICANN's function in establishing, 
disseminating, and overseeing implementation of the technical standards and 
practices that relate to the operation of the global domain-name system. JPRS 
considers ICANN to be the appropriate international entity to oversee the 
technical coordination of the Internet in a manner that will preserve it as an 
effective and convenient mechanism for global communication. 

As a demonstration of its commitment to ICANN, JPRS was the second ccTLD to 
formalize its relationship with ICANN by entering into a ccTLD agreement. 
Demonstrating JPRS' recognition of ICANN's continuing responsibility for global 
Internet policy to promote stability and global interoperability, JPRS 
representatives have served on the IDN Registry Implementation Committee and on 
the ccNSO Launching Group. In addition, JPRS was one of the founding members of 
the ccNSO, currently serves on the ccNSO Council, and currently chairs the 
ccNSO Accountability Framework Working Group. 

Like its parent companies, Sentan will devote significant resources towards its 
participation in the ICANN policy development process, including active 
participation in the gTLD Registries Constituency and GNSO/ICANN Task Forces. 
To ensure the highest levels of participation in the ICANN process, Sentan's 
staff will include a Vice President of Policy and Compliance, who will be 
devoted to servicing the ICANN community. Moreover, our multiple language 
support for registrars, discussed in Parts 2:2 and 2:5.b.xix, will increase 
education, awareness, and understanding of ICANN policies amongst registrars 
and will facilitate compliance.

COMPLIANCE WITH ICANN'S INTER-REGISTRAR TRANSFER POLICY
Sentan believes that portability of domain name management between registrars 
is vital to ensure a registrant's right to choose the manager of their domain 
portfolio. The transfer policy is a direct outcome of competition amongst 
registrars and has encouraged innovation at the registrar level. At the same 
time, domain name registrants must also be protected from unauthorized 
transfers, slamming and other abusive practices.  Sentan's compliance is 
ensured by the mechanism described below.

IMPROVED TRANSFERS IN AN EPP REGISTRY 
Transfer policy is poorly implemented in the current .NET environment. We 
believe the genesis of these problems stems from registry use of the RRP 
protocol, which contains no automated mechanism to validate whether a transfer 
request was authorized by the domain name registrant. In 2001, several new 
registries were introduced including .BIZ (operated by NeuLevel). The number of 
complaints about transfers in these new TLDs is minimal. This is primarily due 
to the fact these new registries were launched using the EPP protocol which has 
a built-in mechanism, the Authorization Info Code (AuthInfo) which 
substantially minimizes the incidence of slamming and unauthorized transfers.

An AuthInfo is essentially a code assigned by a registrar to a particular 
domain name. This code acts as an extra security measure, allowing only the 
owner of the domain to make a transfer. EPP-based registries require that 
registrars provide a valid AuthInfo with all transfer requests. Since the 2001 
introduction of AuthInfo in .BIZ (using the EPP protocol) no transfer related 
disputes involving unauthorized transfers or slamming have been reported nor 
have there been any disputes filed under the Transfer Dispute Resolution 
Process described below. The incidence of transfer related problems in .BIZ is 
very low.

IMPROVED TRANSFERS IN A THICK REGISTRY
The "thick" registry data model standardizes data formats such that transfers 
are less frequently "not acknowledged" (or "nacked") due to inconsistent 
contact data formats between losing and gaining registrars. Moreover, the thick 
data collection model provides an authoritative source for registrars in cases 
where there is a dispute over the authorization of a transfer request. These 
benefits are further discussed in Part 2:8.

SENTAN SOLUTION FOR IMPLEMENTATION OF THE INTER-REGISTRAR DOMAIN NAME TRANSFER 
POLICY AND DELETES PROCESS
Sentan's solution for managing domain name transfers in the .NET gTLD will not 
only improve competition among .NET domain name registrars, but will combine 
all of the advantages of a thick EPP registry with state-of-the-art 
implementation of ICANN's Inter-Registrar Transfer Policy. By selecting Sentan, 
registrars and registrants will see immediate benefits from the thick, EPP 
registry. They will also see benefits from Sentan's implementation of the Inter-
Registrar Transfer Policy as well as the introduction of key improvements to 
the transfer and dispute process described in Part 2:7.iii.

Under the Inter-Registrar Transfer Policy, the registry is essentially 
responsible for helping to ensure compliance with new transfer rules. The 
registry must also preside over first-level disputes between registrars. Sentan 
is firmly committed to enforcing each registrar's obligations under the 
transfer policy, including, but not limited to, those rules specifically 
targeted towards an EPP-based TLD. Specifically, we will ensure that:

· Registrars provide the Registered Name Holder (RNH) with a unique AuthInfo 
within 5 calendar days of the RNH's initial request or provide facilities for 
the RNH to generate and manage their own, unique AuthInfo.

· Registrars do not employ a mechanism for complying with a RNH's request for 
AuthInfo that is more restrictive than the mechanism offered by that registrar 
for other changes to the RNH's record.

· The Registrar of Record (RDR) must not refuse to release an AuthInfo to the 
RNH solely because there is a dispute over payment between the RNH and the 
registrar. 

Subject to ICANN approval, Sentan proposes to introduce a set of graduated 
enforcement mechanisms against registrars who fail to comply with the above EPP-
based transfer policy. Absent extenuating circumstances, if a violation is 
found, Sentan will issue a written warning to the offending registrar with 
instructions that its practices need to be brought into compliance within 15 
days. If the registrar fails to comply, or if a second violation is found 
within a 90 day period, the registrar will be suspended from new adds or 
incoming transfers for a period of 5 days. In addition, the registry has the 
option of giving the AuthInfo directly to the registrant. If, after an 
additional 15 days of suspension, the violation is not cured, or upon the 
receipt of a third complaint in a 6-month period, a 15 day suspension will be 
issued. If, 15 days after the second suspension, the violation is not cured, or 
if there is a fourth complaint in a 1-year period, the registrar will be 
suspended for 30 days, or until such time as the registrar is compliant.

The use of AuthInfo, a thick registry, and strict enforcement will 
significantly reduce transfer disputes. Nevertheless, Sentan recognizes that 
some disputes over unauthorized transfers and slamming will occur. Sentan will 
adopt a state-of-the-art online dispute resolution process that is modeled on 
the established process operated by Sentan's, primary technical operator, 
NeuLevel, for .BIZ. Sentan will base its supplemental rules and forms on the 
supplemental rules and forms already adopted for the .BIZ gTLD.

Sentan recognizes that until all registrars have completed their transition to 
our EPP-based .NET registry, the volume of transfer disputes in .NET may be 
greater than that experienced by other EPP registries. Therefore, we will 
implement a fully automated online submission tool for registrars to file 
disputes under the Transfer Dispute Resolution Process. The online submission 
tool will make it easier for registrars to provide the required information to 
manage transfer disputes. In addition, it will provide an automated mechanism 
to voluntarily withdraw or settle a transfer dispute, upload supporting 
documentation, request an extension to file a response, or concede a dispute. 
Moreover, the online submission tool will make it easier for Sentan to provide 
more beneficial reports to registrars and ICANN regarding dispute statistics. 

Finally, Sentan will implement an automated transfer undo mechanism in cases 
where a registrar has accidentally initiated a transfer and desires to return 
the name to its original state. This is described further in Part 2:7.iii. For 
more information on the operational aspects of transfers, please see Part 
2:5.b.v.

COMPLIANCE WITH OTHER ICANN POLICIES

Redemption Grace Period

The Redemption Grace Period (RGP) has delivered substantial benefits to 
registrants. Sentan's technical operator, NeuLevel, was instrumental in the 
development of that policy having served on the RGP Implementation Committee. 
In addition, NeuLevel was the first registry to contractually commit to 
implement the policy. The RGP allows registrars to restore domains that may 
have accidentally been deleted by registrants or registrars. NeuLevel remains 
the only registry to have developed a completely automated RGP solution. During 
ICANN's 2004 meeting in Malaysia, the RGP solution was praised in the joint 
registry/registrar constituency meeting. NeuLevel is also the only registry to 
offer a tiered pricing approach, allowing registrants whose names were 
accidentally deleted to restore the domain for free during the first 5 days 
following deletion. NeuLevel will use this same implementation for Sentan in 
its technical operation of the .NET registry. 

In addition, as discussed in Part 2:7.iii, because the RGP is not a "consensus 
policy", neither ICANN, nor existing registries, can amend registrars' 
contracts to require registrars to implement the RGP. We advocate full RGP 
compliance. We recommend that ICANN take the opportunity to appropriately 
modify the Registry-Registrar Agreements. 

Internationalized Domain Names (IDN)

As described in Part 2:5.b.xvii, Sentan will accept IDN registrations with the 
prefix of xn-- in the third and fourth positions in accordance with the 
Guidelines for the Implementation of Internationalized Domain Names version 1.0 
dated June 20, 2003 (Guidelines). Both NeuLevel and JPRS have agreed to be 
bound by the Guidelines. By agreeing to be bound by those Guidelines, both 
NeuLevel and JPRS have been recognized by ICANN as having "demonstrated its 
leadership in helping to achieve practical solutions to the many technical and 
operational challenges that IDN deployment poses." JPRS remains one of the few 
ccTLD operators to have committed, in writing, to conform to the Guidelines. 

WHOIS 

The management of WHOIS data is a controversial topic in the ICANN policy 
arena. The debate is centered around the public display and dissemination of 
WHOIS information. Although each of the current consensus policies is aimed at 
the registrars, including the WHOIS Data Reminder Policy and the WHOIS 
Marketing Restriction Policy, Sentan has developed a number of tools described 
in Part 2:7.iii that will both improve the accuracy of WHOIS information, 
improve the privacy of domain name registrants, and reduce the amount of WHOIS 
data mining. These enhancements include a modified thick WHOIS Display, a WHOIS 
Address Validator, adoption of the IRIS protocol, and throttling of WHOIS 
display. In addition, NeuLevel and JPRS have comprehensive experience in 
securely handling WHOIS information including personal data.

ICANN Policy Education

Sentan commits to hosting periodic policy compliance seminars for registrars 
and end users to facilitate the understanding and implementation of ICANN 
policies. These meetings, occurring in conjunction with ICANN meetings, will be 
open to the entire Internet community. Topics covered in these global seminars 
will include IDN resolution, progress made on the development of an open source 
IDN browser plug-in, health of the DNS, DNSSEC, Anycast deployment, and IPv6, 
transfers, deletes, and data accuracy.

WHY SENTAN
· Provides registrar support on a global basis and in multiple languages and 
time zones

· Commits to the most stringent code of conduct in the industry including, at 
Sentan's expense, a third-party audit of Sentan's compliance with the Code

· Commits to equal access certifications similar to that set forth in Appendix 
H of the existing .BIZ Agreement

· Provides 24/7/365 customer support and incentive programs to registrars 
during the transition process from RRP to EPP on an equivalent basis

· Provides new registry services aimed at improving equivalent access

Sentan is uniquely positioned to operate the .NET registry under a strict code 
of conduct which includes principles of neutrality and fair-treatment. This 
will enable robust competition between registrars from a neutral base, 
regardless of what language they use or region they operate in.

Just as ICANN operates for the benefit of the Internet community by carrying 
out its activities in ways that enable fair competition and open entry into 
Internet-related markets, the .NET registry manager must also demonstrate that 
it will treat registrars equally and fairly in providing access to registry 
services. Sentan's primary technology provider, NeuLevel, currently has in 
place mechanisms to ensure equivalent access to all registry services in 
its .BIZ operations. Sentan is committed to ensuring that ICANN-accredited 
registrars are afforded equal access to all of Sentan's registry services. 
Sentan will leverage all of NeuLevel's resources to accomplish this by 
implementing the following measures:

· Name registration and other services will be available to registrars in 
multiple languages and time zones

· A registry code of conduct will be a foundation of all Sentan's operations

TIME ZONE AND LANGUAGE SUPPORT
Access to support from the .NET registry in multiple time zones and languages 
is necessary not only for the expansion and globalization of the Internet, but 
also to promote competition among registrars. .NET registrars and end users 
must be provided timely, reliable and accurate responses to questions about 
their domain names. Sentan will provide sophisticated, multilingual on-demand 
support available via telephone, email, and the registry website.

Sentan will have registrar support and outreach offices in 3 diverse geographic 
regions: Asia (Tokyo, Japan), Europe (Rome, Italy) and North America (Sterling, 
Virginia). These three offices will provide support in multiple time zones for 
ICANN-accredited registrars, outreach for new registrars, and for support of 
ICANN's policy development process. For more information, see Part 2:3.iii.

Sentan will provide in-house 24/7, language support, (written and oral) in 
English, French, German, Italian, Japanese, Chinese (multiple versions), 
Korean, and Spanish. Within 12 months of transition, Sentan will add Russian, 
Arabic, and Portuguese to this in-house capability. Language groups have been 
chosen to maximize coverage of existing .NET customers and the online community 
at large. We will add further capability depending on demand from registrars. 
In addition, from day 1 of operation, Sentan will utilize a third party 
translation service that provides 24-hour operation with instant access to 
interpreters in over 100 languages. This service, LLE-Link, currently operates 
under contract to NeuLevel, Sentan's technical operator.

In addition to customer support, Sentan will offer .NET WHOIS services in 
multiple languages to better serve the global market. The WHOIS service will be 
offered in English, Japanese, Chinese (simplified and traditional), Korean, 
Spanish, German, French and Italian. Sentan is also exploring the possibility 
of providing WHOIS in Portuguese, Russian, and Arabic.

ENSURING EQUIVALENT ACCESS
Sentan will ensure that all registrars receive equivalent access to all of its 
registry services by agreeing to the guidelines set forth in the strict code of 
conduct provided below. The concept of a registry code of conduct is not new to 
Sentan, as its parent, NeuLevel, was the first gTLD registry to introduce and 
implement the code for the .BIZ registry. Since then, a registry code of 
conduct has become a de facto requirement for the operation of all gTLD 
registries managed by ICANN, including the .COM, .NET, .ORG and .INFO gTLDs. In 
order to ensure strict compliance, Sentan will commit to having an independent 
auditor review Sentan's compliance with its code of conduct on an annual basis. 
Sentan will pay for the audit and the results will be provided to ICANN.

.NET TLD Code of Conduct
Sentan will, at all times, operate as a neutral third-party provider of 
registry services. The Internet community requires that the operator of 
the .NET registry conduct itself in a fair, efficient and neutral manner. 
Therefore, in its provision of neutral Registry Services, as defined by ICANN 
in the .NET registry agreement, Sentan will comply with the following registry 
code of conduct:
 
1. Sentan will conduct periodic reviews of its policy and operational 
structures to ensure continuing operation of the .NET gTLD.

2. Sentan will not, and will require that its subcontractors do not, directly 
or indirectly, show any preference or provide any special consideration to any 
ICANN-accredited registrars in the .NET registry versus any other ICANN-
accredited registrars in the .NET registry.

3. All ICANN-accredited registrars in the .NET registry shall have equal access 
to registry services provided by Sentan and its subcontractors as set forth in 
Appendix H of the registry agreement.

4. Sentan and its owners shall not, in any way attempt, either to warehouse 
domain names or attempt to register domain names in its own right, except for 
names designated for operational purposes in compliance with the registry 
agreement.

5. Any shareholder, subsidiary, affiliate, or other related entity of Sentan 
that also operates as a provider of registry or registrar services shall 
maintain separate books of account with respect to its registrar operations 
separate from those of Sentan.

6. Neither Sentan, nor its shareholders, subsidiaries, affiliates, or other 
related entities shall have access to user data or proprietary information of 
an ICANN-accredited registrar, except as necessary for registry management and 
operations. 

7. Sentan will ensure that no user data or proprietary information from any 
ICANN-accredited registrar is disclosed to its affiliates, subsidiaries, or 
other related entities, except as necessary for registry management and 
operations.

8. Confidential information about Sentan's business services will not be shared 
with employees of any ICANN-accredited registrars, except (a) as necessary for 
registry management and operations or (b) if such information is made available 
to all ICANN-accredited registrars on the same terms and conditions.

9. No member of Sentan's Board of Directors will simultaneously serve on the 
Board of Directors of an ICANN-accredited registrar that obtains registry 
services from Sentan.

10. No employee of Sentan will hold a greater than 5% interest, financial or 
otherwise, in a company that obtains registry services from Sentan.

11. No employee of Sentan will also be an employee of any Sentan subsidiary, 
affiliate or other related entity that also operates as an ICANN-accredited 
registrar.

12. Sentan will ensure that no user data or proprietary information from any 
registry operated or controlled by Sentan is disclosed to any other registry 
operated or controlled by Sentan.

13. Sentan will conduct internal neutrality reviews on a regular basis. In 
addition, Sentan and ICANN may mutually agree on an independent party to 
conduct a neutrality review of Sentan for ensuring that Sentan and its owners 
comply with all the provisions of this code of conduct. The neutrality review 
may be conducted as often as once per year.

MECHANISMS TO EMPLOY EQUAL ACCESS ON EXISTING AND FUTURE REGISTRY SERVICES
In addition to abiding by the above code of conduct, the next registry for .NET 
must be able to provide evidence to ICANN that it will treat each of its 
registrars equally and fairly to facilitate competition. Sentan does that by 
proposing measures that NeuLevel has successfully implemented in its operations 
of the .BIZ gTLD as well as the introduction of new services to the ICANN 
registrar community. These measures include the following:

· Developing and implementing a statement on equal access and non-
discriminatory practices.

· Providing standard registry services on an equal basis.

· Providing equal assistance to registrars during the migration process to EPP.

· Providing improved registrar services designed to ensure that each registrar 
can provide value added services to their customers on an equal basis including 
an Ad-Hoc Reporting Tool, CSR Chat Tool, Auth Info Code Validator, Automated 
Registrar Messaging System, and a web-based interface tool to make it easier to 
add and manage.NET IDN names. (For more information see Part 2:3.a and 
2:3.b.ii).

COMPLIANCE WITH EQUAL ACCESS PROVISIONS 
NeuLevel, the primary technical operator for Sentan, has an outstanding record 
in its compliance with Exhibit H (Equal Access Certification) of its own 
registry agreement with ICANN for the operation of the .BIZ gTLD. Likewise, 
Sentan (and its subcontractors) will comply with the strict equal access 
requirements contained within the same Statement on Equal Access and Non-
discriminatory Practices used in .BIZ (the Statement). The Statement details 
our internal mechanisms for ensuring that registrars of the .NET gTLD are 
treated fairly by the registry. With respect to the Statement, Sentan will 
accomplish the following:

· Provide all registrars around the globe with the opportunity to register 
domain names pursuant to the terms and conditions of a registry-registrar 
agreement;

· Provide all ICANN-accredited registrars with equivalent access to the 
registry-registrar protocol; and

· Certify to ICANN on an annual basis that Sentan, in its capacity as the .NET 
TLD registry, is providing all ICANN-accredited registrars with such equivalent 
access.

Sentan proposes to implement the Statement by taking the following affirmative 
steps:

· Abiding by a registry code of conduct.

· Ensuring that financial statements for Sentan are prepared using United 
States Generally Accepted Accounting Principles. 

· Conducting business and technical operations from different premises than any 
ICANN-accredited registrar. 

· Restricting access to Sentan premises and facilities to assigned personnel 
employed or contracted by Sentan. 

· Implementing an access to data policy including procedural safeguards for 
ensuring that data and information of the registry business are not utilized to 
advantage one ICANN-accredited registrar over another. 

· Providing formal training about equivalent access to all Sentan personnel and 
other employees who have a need to know its registry business. 

· Providing a compliance vice president for ensuring that Sentan acts in 
accordance with equal access and non-discriminatory practices.

· Requiring that all Sentan personnel sign a non-disclosure agreement and a 
certification acknowledging their understanding of the requirements and 
certifying that they will strictly comply with the provisions of the Statement. 

For the .NET gTLD, Sentan will meet these well-developed requirements.

REGISTRAR TRANSITION PROGRAM
As set forth in Part 2:8, Sentan will provide assistance to registrars during 
the RRP to EPP transition process on an equivalent basis. Such services will 
ensure that registrars are able to efficiently transition to Sentan's EPP 
platform in a timely manner. More specifically, Sentan will:

· Provide assistance with the transition from RRP to EPP through NeuLevel's 
customer support, which operates 24/7 via telephone, email, and the registry 
website;

· Offer a `data scrubbing' service to all registrars to ease the transition of 
registrars to Sentan's thick EPP1.0 platform by accepting data files from 
interested registrars and working with them to prepare the data for the 
migration to EPP1.0; and

· Offer a cash incentive program to registrars for transitioning names to the 
thick EPP1.0 platform. The program is described in Part 2:8.

SUMMARY OF SERVICES
· Sentan will provide all ICANN-accredited registrars with registry-registrar 
agreements for the .NET gTLD that guarantee equivalent access to registry 
services, including to its shared registration system. 

· Under the new management of the .NET registry, Sentan commits to ICANN's view 
that there is an obligation to refrain from throttling registry-registrar 
agreements regardless of the number of accreditations

· Sentan will ensure that every registrar has the ability get the same number 
of connections to the shared registry system no matter how many new registrar 
accreditations are issued by ICANN. 

· Every registrar will also be given the same number of connections in the 'add 
storm' pool giving each registrar an equal opportunity to register domain names 
that have been deleted and are available for re-registration. Please see Part 
2:5.b.iv.

IMPROVED REGISTRY SERVICES TO .NET REGISTRARS AND REGISTRANTS 
Committing to treat each ICANN-accredited registrar equally ensures a 
competitive environment among registrars. However, smaller registrars are often 
disadvantaged because they have fewer resources than those registrars who have 
a high volume of domain name transactions. In response to this, Sentan will 
introduce into the .NET domain name space a number of different services, each 
of which are aimed at ensuring equal access to registrars along with improving 
competition among the registrars. Brief descriptions of these services are 
provided below. More information on these services can be found in Part 2:3a 
and 2.3.b.ii. 

· Registrar Ad-Hoc Reporting Tool:  The Ad-Hoc Reporting Tool allows each 
registrar to create custom reports of their own transaction data from the 
registry database. Although larger registrars with greater internal resources 
are able to do this themselves, Sentan will provide this tool to enable all 
registrars to run custom queries in-house. Providing a tool that enables these 
types of custom reports, regardless of the size of the registrar, will increase 
efficiency and decrease the cost of operation, thereby enhancing competition 
and enabling better customer service.

· Customer Support Chat Tool:  Sentan believes, based on the experience of 
NeuLevel, that many non-English speaking registrars, have difficulty 
communicating verbally with registries even if translator services are 
provided. These customers find it easier to communicate with the registry by 
instant messaging tools, rather than by voice or email communications. Sentan 
will  implement a Customer Support Chat tool for the .NET gTLD that will be 
available to all registrars, and will provide non-English speaking registrars 
an equal level of support as those who are fluent in English.

· AuthInfo Code Validator (AuthInfo):  Allows a registrar to query the registry 
database to ensure that an AuthInfo submitted by a potential transferor is 
valid. This will save registrars time and resources in managing invalid codes.

· Registrar Administration Tool (RAT): Sentan's technical operator will operate 
a secure web-based system that provides access to the SRS via EPP, allowing 
registrars to easily manage domains, contacts, and hosts through a series of 
user-friendly screens. The tool, known as the "RAT", allows registrars to 
easily process transactions and avoid having to contact customer support, 
saving them time and increasing their productivity.

· Automated Registry-Registrar Messaging System:  Sentan will institute a 
system of automated messaging for Registry Notices in a machine-readable or 
Really Simple Syndication (RSS) format. Numerous registrars have requested that 
all existing ICANN-accredited registries move to a standardized system of 
machine-readable messaging. This will enable messages to be resent 
automatically to resellers and registrants. We believe this automated messaging 
service will help all registrars better inform their customers and resellers 
about planned registry outages, events, and services. It will allow registrars 
of all sizes to compete more efficiently with one another. 

SUMMARY
Sentan commits to ensuring that ICANN-accredited registrars have equal access 
to all existing and future registry services in .NET. registrars, regardless of 
their size, will be treated on an equivalent basis. 

WHY SENTAN
· Currently available RRP test environment for .NET-demonstrating our readiness 
and commitment

· Seamless RRP support at transition-providing operational continuity for 
registrars

· A smooth, low-cost migration to EPP 1.0-designed to maximize schedule 
flexibility for registrars

· A financial incentive program for prompt migration-providing business 
rationale to accelerate migration 

· Provisions for maintaining the smooth flow of transfers-bridging the 
differences between RRP and EPP

OVERVIEW
Since the registry-registrar model was originally established in the .NET gTLD, 
registrars have interacted with the registry using RRP as originally documented 
in RFC 2832 (version 1.1.0) and subsequently evolved in RFC 3632 (version 
2.0.0). The RRP protocol has evolved through 3 additional releases to its 
current release 2.1.2 in April 2004, but these changes have not been publicly 
documented as RFCs. The design goal of RRP was to support a `thin' registry 
model and it was not designed with extensibility in mind. The EPP specification 
uses more modern technologies (e.g. XML) and has already proven its 
adaptability. For example, in the .US ccTLD, the US "NEXUS" requirements were 
addressed using an EPP extension.
 
Sentan will move the .NET registry to EPP Version 1.0 as specified in RFCs 
3730, 3731, 3732, 3733, 3734, and 3735. NeuLevel was the first gTLD registry 
operator to introduce EPP 1.0 into production use and welcomes this migration. 
Sentan's .NET protocol migration plan will support RRP at the time of 
transition and provide registrars a smooth, low-cost migration from RRP to EPP 
1.0. This migration is also an integral part of the overall registry transition 
plan and we have incorporated it into our plan in Part 2:8. 

This protocol migration plan is bolstered by NeuLevel's previous experience 
with registrar protocol migration to EPP 1.0. NeuLevel announced availability 
of EPP 1.0 in October 2004, an upgrade from the previous pre-RFC version of the 
protocol. As part of this upgrade, NeuLevel deployed software that 
simultaneously supported both versions of EPP. This approach, which allowed 
registrars to migrate individually on a flexible schedule, was well received by 
the registrar community. 

Our protocol migration plan provides ample time and flexibility for registrars 
to make adjustments to internal systems. However, it also allows an individual 
registrar that wishes to be aggressive to proceed at its own pace, not being 
required to wait for other registrars to migrate. Registrars will receive 
comprehensive documentation on all aspects of this migration during pre-
transition outreach. This section describes dates for the migration in terms of 
the transition date, which is assumed to be June 30, 2005. Many dates in the 
plan were chosen to avoid the end-of-year holiday period. Further detail about 
our transition plan can be found in Part 2:8.

AVAILABILITY OF PRE-TRANSITION RRP TEST ENVIRONMENTS
Sentan recognizes that registrars have interacted with the .NET registry for 
many years using RRP. We will enable registrars to use existing RRP client 
software, unmodified, to interact with our RRP service. That is, while we are 
basing our RRP server implementation on RFC 2832 and RFC 3632, we will bring 
our software into compliance with the de facto .NET protocol, rather than 
taking a position that our interpretation of the RFCs might take precedence 
over the current operating mode of .NET. To proactively address RRP support 
prior to the transition, NeuLevel has already launched an RRP Operational Test 
and Evaluation (OT&E) environment. Various active .NET registrars are 
initiating testing efforts in the environment using their existing software. 
NeuLevel is working with these registrars and incorporating feedback on .NET 
protocol compatibility. The OT&E launch, far in advance of ICANN selection, 
demonstrates Sentan's capability and commitment to a smooth transition. 

In addition to the OT&E environment, NeuLevel will have an RRP scripted server 
within 30 days of ICANN selection. A scripted server is the environment where 
registrar certification testing occurs. It supports a documented test case 
suite, checks the client's RRP input, and provides a defined set of responses. 
These tests ensures that a client can communicate at the protocol level. 
Successfully completing this step is a certification requirement unless the 
registrar had been previously RRP certified by the Incumbent; for these 
registrars, certification will be automatically granted. After RRP 
certification (via testing or being grandfathered), a registrar can begin 
testing in the OT&E environment. The OT&E environment enforces the full suite 
of business rules for RRP operations and has an active database.

SEAMLESS RRP SUPPORT AT OPERATOR TRANSITION
The pre-transition testing by registrars will fully exercise NeuLevel's RRP 
protocol service. By incorporating feedback from the test environment, the 
protocol service will become completely compatible with the Incumbent's 
implementation. Consequently, when the .NET SRS is cut over to Sentan, a 
registrar will only need to make configuration changes in its RRP client (e.g. 
RRP server hostname, digital certificate, login, and password). We expect that 
registrars will also perform minor network (e.g. firewall) changes to enable 
connectivity.

SUPPORT FOR EPP 1.0
Sentan is firmly committed to EPP 1.0 support through the use of NeuLevel's SRS 
and EPP 1.0 toolkit. Additionally, in order to maintain currency with evolving 
standards, Sentan will implement support for updates to RFCs 3730, 3731, 3732, 
3733, 3734, and 3735 after their adoption as a Proposed Standard [RFC 2026, 
section 4.1.1]. This support will be available in production within 135 days of 
ICANN's approval of the Proposed Standard specifications. To support protocol 
evolution, we will adopt flexible policies to support registrar's use of 
obsolete extensions and will implement applicable EPP extensions under 
standards consideration and make them available in a test environment.

NeuLevel built its SRS from the ground up as an EPP platform and it has been 
operating reliably and at scale since 2001. Additionally, to support protocol 
evolution, it has an architecture to simultaneously support multiple 
provisioning protocols (now including RRP) without adapters or proxies. No 
other EPP-based SRS has consistently demonstrated such a combination of 
flexibility, scalability, and performance.

A SMOOTH, LOW-COST TRANSITION TO EPP 1.0
Since 2001, all new gTLD registries have launched with a version of EPP. As an 
example of EPP market penetration, over 55% of .NET registrars are currently 
using EPP in the .BIZ gTLD. As a group, these registrars account for over 98% 
of all .NET domains, according to the August 2004 report to ICANN on .NET. 
Clearly, the pure protocol aspects of the EPP transition are not a new 
challenge for these registrars.

Sentan's overall transition and migration program includes the migration 
of .NET to a "thick" registry data model along with the migration from RRP to 
EPP (A full description of "thick" data model solution is in Part 2:5.b.xii.). 
One way the plan ensures registrars a smooth, low-cost migration to EPP 1.0 is 
by providing significant schedule flexibility, which in turn helps to control 
registrar labor costs. A transition plan that does not provide flexibility can 
easily cause a registrar to either reschedule other projects or to hire more 
labor; each increases the cost of transition, either in absolute terms or 
opportunity cost. Our plan features oriented toward flexibility include support 
for RRP and EPP 1.0 during migration; and self-selected protocol testing and 
transition dates and number of migration steps. Together, these features allow 
a registrar to take a customized path through protocol migration. Also, our 
plan does not require EPP extensions for the migration, further controlling 
development cost.

STAGES OF PROTOCOL MIGRATION
Here we summarize the essential impacts of a thick data collection model on 3 
types of registry data objects (Domain, Host, and Contact), comparing RRP to 
EPP in the context of the registry data model.
 
Object Type - Domain
· RRP - References to Host object(s) not required for creation, but required
  for inclusion in the zone
· EPP 1.0 - References to Host object(s) not required for creation, but   
  required for inclusion in the zone; references to Contact object(s) required
  for creation

Object Type - Host
· RRP - None
· EPP 1.0 - None

Object Type - Contact
· RRP - Does not exist in RRP
· EPP 1.0 - Exists in EPP

As shown above, the key difference between the protocols, in the context of the 
thick model we propose for .NET, is the Contact object and its relationship to 
the Domain object. This means that Contact data collection and establishing 
linkages between Domains and Contacts is the heart of the protocol migration. 
Recognizing these differences in the data collection model, our registrar 
migration plan has three distinct variations, each building upon the other.

· Stage 1 - An initial stage that allows for EPP use with thin data.
· Stage 2 - A stage for Contact data population with partial enforcement of 
            thick data.
· Stage 3 - The final stage enforcing the thick data rules.

These stages are each compliant with the EPP 1.0 RFCs and will be supported by 
the same toolkit. The only differences between stages result from the varying 
enforcement of business rules at the SRS. These stages are sequential. A 
registrar can choose to begin at any stage, but must progress to Stage 3 (fully 
thick EPP 1.0) to complete the migration. The following identifies the key 
differences between the stages from the perspective of the EPP contact object 
and its relationship to the domain object.

Contact operations allowed?	Do Domains accept Contact object references?
Stage 1		No				No, not in thin model
Stage 2		Yes				Yes, optional
Stage 3		Yes				Yes, required

Examining these further, we describe how these stages isolate complexity and 
are the key to offering flexibility to registrars.

Stage 1 - EPP with the current thin data model. Contact operations are not 
allowed and Domain operations do not accept Contact object references. By 
eliminating the Contact object entirely, the Stage 1 certification process is 
far simpler than Stage 2 or 3 certification. We anticipate this will be the 
initial certification level chosen by those registrars who are not currently 
transacting with an EPP-based registry because it allows them to begin using 
EPP with a limited scope.

Stage 2 - EPP during transition to the thick data collection model. Contact 
operations are allowed with all appropriate enforcement of protocol rules and 
Domain operations optionally accept Contact object references. Due to the 
inclusion of Contact operations, certification for Stage 2 is more challenging 
than for Stage 1 for registrars lacking production EPP experience. After 
careful deliberation, due to the migration to thick data, we decided to make 
Contact object references optional for Domain objects in Stage 2. This decision 
was made because we understand that registrars may be prepared to begin 
populating Contact data "in the background" before migrating their online 
registration system to a thick model. If Domains require Contact references, 
registrars would be required to make a flash cut to the thick data model. We 
recognize that a flash cut could seriously compromise operational stability for 
these registrars and are thus providing Stage 2.

Stage 3 - EPP with the thick data collection model. Contact operations are 
allowed with all appropriate enforcement of protocol rules for those Contact 
objects and Domain operations ("create" and "update") require Contact 
references. This means, for example, that a Domain being updated to add a Host 
will have validation business rules applied to ensure that it has required 
Contact references. Certification for Stage 3 is comparable in scope to that 
for Stage 2. We anticipate that registrars who are currently transacting with 
an EPP-based registry will select either Stage 2 or 3 as their initial 
certification level.

For each of these EPP 1.0 stages, NeuLevel will provide a scripted server with 
an OT&E environment. CSR and registrar relations staff will carefully track 
each registrar's progress throughout protocol migration and will provide 
assistance as appropriate. Each registrar will be required to test with a 
scripted server in order to be certified. Once certified, Sentan will not 
require testing in OT&E, we will certainly encourage registrars to leverage it 
for increased stability during the transition period.

TIMELINE FOR PROTOCOL PROGRESSION IN MIGRATION
In our protocol migration plan, a registrar has a great deal of flexibility in 
selecting a protocol progression (the sequence of protocols used in 
production). In production, a registrar can select any protocol for which it is 
certified and is supported at that time. Production support for all protocols 
will be available Transition day. In .NET OT&E, RRP is currently supported and 
the EPP variations will be supported on May 1, 2005. Production operation and 
OT&E support for the various protocols ends on the following dates:

· RRP: Dec. 1, 2005 (Transition + 5 months)
· EPP 1.0 Stage 1: Feb. 1, 2006 (Transition + 7 months)
· EPP 1.0 Stage 2: Mar. 1, 2006 (Transition + 8 months)
· EPP 1.0 Stage 3: N/A, ongoing support

This is depicted graphically in Part 2:8, Exhibit 8-2b. The variety of possible 
paths from RRP to EPP 1.0 Stage 3 is depicted in Part 2:8, Exhibit 8-2a.

We anticipate a variety of progressions and different schedules will be 
exercised during the migration period. We believe that this flexibility is a 
key feature in our plan. Our registrar relations team will work closely with 
individual registrars to tailor a custom migration schedule for each registrar. 
Our goal in developing this flexible approach is to make migration smooth for 
individual registrars. Based on our collective experience, the best way to 
achieve this is to allow registrars to set scope and timing. Given the 
principle of equal access, new registrars who achieve ICANN accreditation 
during the migration period will have the option of being certified for any 
protocol supported at that time. While having this flexibility, new registrars 
will be subject to the same timing for protocol migration as existing .NET 
registrars.

For a registrar, changing protocols is a formal process involving scheduling 
the change with registry customer support. Registry operations will conduct 
weekly protocol migrations during which the SRS will be provisioned with the 
new registrar protocol configuration information. These provisioning events 
will not require SRS downtime, but a registrar being migrated must disconnect 
and reconnect with the new protocol. Upon the dates of termination of support 
for RRP, EPP 1.0 Stage 1, and EPP 1.0 Stage 2, any registrar that has not 
transitioned to a supported protocol will lose the ability to interact with the 
registry and will remain unable to interact until it transitions to a supported 
protocol. No action will be taken against domains sponsored by the registrar 
(e.g. names sponsored by the registrar will not be removed from the zone). As 
always, the registry customer support staff, using standard procedures, will be 
available to perform emergency DNS-related changes to the registrar's sponsored 
names.

INCENTIVE FOR MIGRATION
One of the challenges of allowing registrars to determine the timing of 
protocol migration is the natural tendency of other important registrar 
activities to take precedence over the migration. This increases the 
probability of a late burst of migrations. To provide an incentive to 
registrars to complete the migration in advance of the required dates, Sentan 
offers 2 different rebate programs to registrars. These are described in detail 
in Part 2:8.9. In designing these programs, we collected feedback from many 
registrars on their previous transition and migration experiences. We have 
carefully designed it to provide incentive for the registrars to complete the 
protocol and data model migrations promptly.

MAINTAINING SMOOTH FLOW OF TRANSFERS
Our discussion of protocol migration has focused on data differences between 
RRP and EPP. A migration plan would not be complete without addressing domain 
name transfers. Our plan addresses transfers and will seamlessly allow them to 
proceed smoothly throughout the protocol migration period.

The current transfer process in the .NET registry is based on RRP rules. In 
order to ensure a smooth migration, NeuLevel will maintain RRP transaction 
semantics (including the RRP email notification mechanism) from Transition day 
until the end of RRP support. During this period of RRP-based transfers, any 
registrar using EPP 1.0 (all variations of which, as described above, will be 
supported on transition day) will still perform transfers using EPP, complete 
with the poll command, however the SRS will not validate the domain's AuthInfo 
code when performing the transfer. NeuLevel will perform this adaptation in a 
way that is transparent to both EPP- and RRP-based registrars and independent 
of the sponsoring registrar's current protocol. The details of this adaptation 
are available in Part 2:8.9. The adaptation of transfer mechanisms, including 
notification, is important to provide because it allows registrars to convert 
from RRP to EPP without regard for the registry's "native" transfer mechanism. 
An alternative that did not include such an adapter would actually be a 
disincentive to a registrar moving to EPP because the registrar would be 
required to perform the adaptation by itself. Upon RRP retirement, all 
registrars will be using EPP 1.0 and the transfer semantics will change to the 
EPP model, validating AuthInfo.

[RESPONSE IS CONFIDENTIAL]

[RESPONSE IS CONFIDENTIAL]

[RESPONSE IS CONFIDENTIAL]

[RESPONSE IS CONFIDENTIAL]

[RESPONSE IS CONFIDENTIAL]

[RESPONSE IS CONFIDENTIAL]

[RESPONSE IS CONFIDENTIAL]

[RESPONSE IS CONFIDENTIAL]

[RESPONSE IS CONFIDENTIAL]

[RESPONSE IS CONFIDENTIAL]